Règles d'entrée et de sortie

Cette page décrit les règles d'entrée et de sortie pour VPC Service Controls. VPC Service Controls utilise des règles d'entrée et de sortie pour autoriser l'accès vers et depuis les ressources et les clients protégés par les périmètres de service.

Les blocs de règles d'entrée et de sortie spécifient la direction de l'accès autorisé en provenance ou à destination des différentes identités et ressources. Les règles d'entrée et de sortie peuvent remplacer et simplifier les cas d'utilisation qui nécessitaient par le passé une ou plusieurs liaisons de périmètre.

Pour savoir comment appliquer des règles d'entrée et de sortie à votre périmètre de service, consultez la page Configurer des règles d'entrée et de sortie.

Pour obtenir une liste de cas d'utilisation et d'exemples de l'échange de données sécurisé, reportez-vous à la section Échange de données sécurisé à l'aide de règles d'entrée et de sortie.

Pour obtenir une liste de cas d'utilisation et d'exemples d'accès contextuel, consultez la section Accès contextuel à l'aide de règles d'entrée.

Avantages des règles d'entrée et de sortie

  1. Les règles d'entrée et de sortie vous permettent d'échanger des données de manière privée et efficace, au sein d'une même organisation ou entre plusieurs organisations, à l'aide des API de service Google Cloud.
  2. Les règles d'entrée et de sortie vous permettent d'accorder l'accès aux ressources Google Cloud hébergées dans un périmètre en fonction du contexte de la requête API :
    1. Appliquez des contraintes sur les types d'identité ou les identités autorisés en fonction du réseau, de l'adresse IP ou de l'appareil source.
    2. Restreignez les méthodes et API Google Cloud accessibles en fonction du réseau, de l'adresse IP, de l'appareil et du type d'identité source.
  3. Réduisez les risques d'exfiltration en limitant le service, les méthodes, les projets Google Cloud, les réseaux VPC et les identités exacts utilisés pour exécuter l'échange de données.
  4. Accordez un accès en lecture seule aux ensembles de données et aux images externes qui ne sont pas gérés par vos soins.
  5. Assurez-vous que les clients des segments disposant de privilèges inférieurs n'ont pas accès aux ressources Google Cloud situées dans des segments dotés de privilèges supérieurs, tout en autorisant l'accès dans l'autre sens.
  6. Simplifiez les configurations qui nécessitaient par le passé une ou plusieurs liaisons de périmètre.

Définition de l'entrée et de la sortie

Les définitions des entrées et des sorties sont indépendantes de l'opération appelée sur la ressource. Ainsi, les définitions font référence à la direction de la requête, et non à la direction du transfert des données.

  • Entrée : désigne tout accès aux ressources d'un périmètre de service par un client API extérieur au périmètre de service. Exemple :

    • Un client Cloud Storage situé en dehors d'un périmètre de service, appelant des opérations de lecture, d'écriture ou de copie Cloud Storage sur une ressource Cloud Storage au sein du périmètre.
  • Sortie : fait référence à tout accès impliquant un client API ou des ressources au sein du périmètre de service, ainsi que des ressources extérieures au périmètre de service. Exemples :

    • Un client Compute Engine dans un périmètre de service appelant une opération Compute Engine create, pour laquelle la ressource d'image se trouve en dehors du périmètre.
    • Un client Cloud Storage, à l'intérieur ou à l'extérieur du périmètre, qui appelle une commande copy pour laquelle un bucket se trouve à l'intérieur du périmètre et l'autre à l'extérieur.

Modèle de stratégie

Une règle d'entrée ou de sortie est composée de blocs from et to dans lesquels :

  • from fait référence aux attributs du client API.
  • to fait référence aux attributs des services et des ressources Google Cloud.

Plusieurs règles d'entrée et de sortie peuvent être associées à un même périmètre de service. Un appel de service Google Cloud est autorisé ou refusé en fonction de la sémantique suivante :

  • Une requête provenant d'un client extérieur au périmètre à destination d'une ressource Google Cloud située dans le périmètre est autorisée si les conditions de la règle d'entrée nécessaire sont remplies.
  • Une requête provenant d'un client situé dans le périmètre vers une ressource Google Cloud extérieure au périmètre est autorisée si les conditions de la règle de sortie nécessaires sont remplies.
  • Un appel d'API impliquant une ressource Google Cloud à l'intérieur du périmètre et une ressource Google Cloud extérieure au périmètre est autorisé s'il existe une règle d'entrée satisfaite par le client (si celui-ci ne se trouve pas dans le périmètre) et une règle de sortie satisfaite par la ressource externe.

Exemples de requêtes API autorisées par des règles d'entrée

  • Un client Cloud Storage situé en dehors du périmètre télécharge des objets depuis un bucket Cloud Storage situé à l'intérieur du périmètre vers la machine locale (par exemple, à l'aide de la commande gsutil cp).
  • Un client BigQuery situé en dehors du périmètre exécute une tâche BigQuery dans un projet situé au sein du périmètre, afin d'interroger un ensemble de données BigQuery à l'intérieur du périmètre (à l'aide de la commande bq query, par exemple).
  • Une VM Compute Engine d'un réseau VPC situé en dehors du périmètre écrit dans un bucket Cloud Storage situé à l'intérieur du périmètre.

Exemples de requêtes API autorisées par des règles de sortie

  • Un client Cloud Storage à l'intérieur du périmètre copie les objets entre un bucket Cloud Storage situé en dehors du périmètre et un bucket à l'intérieur de celui-ci (à l'aide de la commande gsutil cp, par exemple).
  • Un client BigQuery à l'intérieur du périmètre utilise une tâche BigQuery dans un projet en dehors du périmètre pour interroger un ensemble de données BigQuery à l'intérieur du périmètre (par exemple, à l'aide de la commande bq query)

Exemples de requêtes API autorisées par une combinaison de règles d'entrée et de sortie

  • Un client Cloud Storage situé en dehors du périmètre copie des objets entre un bucket Cloud Storage en dehors du périmètre et un bucket à l'intérieur de celui-ci (par exemple, à l'aide de la commande gsutil cp)
  • Un client BigQuery situé en dehors du périmètre exécute une tâche BigQuery dans un projet situé en dehors du périmètre, pour interroger un ensemble de données BigQuery à l'intérieur du périmètre (par exemple, à l'aide de la commande bq query).
  • Un client Compute Engine situé en dehors du périmètre créant un disque Compute Engine en dehors du périmètre à l'aide d'une clé Cloud KMS située à l'intérieur du périmètre

Dans les exemples BigQuery et Compute Engine, une règle d'entrée n'est pas suffisante, car la tâche BigQuery ou le disque Compute Engine se trouve en dehors du périmètre. Une règle de sortie est nécessaire pour autoriser une requête API impliquant une ressource Google Cloud à l'intérieur du périmètre (l'ensemble de données BigQuery ou la clé Cloud KMS) et une ressource extérieure à ce périmètre (la tâche BigQuery ou le disque Compute Engine).

Requêtes API impliquant plusieurs périmètres de service

Lorsque les ressources accessibles et/ou le client API appartiennent à différents périmètres de service, la requête API doit être autorisée par les règles de tous les périmètres concernés. Prenons l'exemple d'un client Cloud Storage et d'un bucket a dans un périmètre de service A et d'un bucket b dans un périmètre de service B. Dans cet exemple, pour que le client Cloud Storage copie les objets du bucket a vers le bucket b, et du bucket b vers le bucket a, les règles d'entrée et de sortie suivantes sont requises:

  • une règle de sortie dans le périmètre A pour autoriser l'accès au bucket Cloud Storage b ;
  • une règle de sortie dans le périmètre B pour autoriser l'accès au bucket Cloud Storage a ;
  • une règle d'entrée dans le périmètre B pour autoriser l'accès au client Cloud Storage situé en dehors du périmètre B.

Documentation de référence sur les règles d'entrée

Les règles d'Ingress peuvent être configurées à l'aide de la console Google Cloud, d'un fichier JSON ou YAML. L'exemple suivant utilise le format .yaml :

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - serviceAccount:service-account
    - user:user-account
    sources:
    - resource: resource
      *OR*
    - accessLevel: access-level
  ingressTo:
    operations:
    - serviceName: service
      methodSelectors:
      - method: method
      *OR*
      - permission: permission
    resources:
    - projects/project
  • - ingressFrom: (obligatoire) : ouvre le bloc from, qui répertorie les sources et identités extérieures au périmètre autorisées.

  • identityType: (soit cet attribut, soit l'attribut identities doit être utilisé) : cet attribut définit les types d'identités pouvant être utilisés à partir des sources spécifiées (origine de réseau). Valeurs acceptables : ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY autorise toutes les identités. ANY_USER_ACCOUNT autorise tous les utilisateurs humains. ANY_SERVICE_ACCOUNT autorise tous les comptes de service.

  • identities: (cet attribut ou l'attribut identityType doit être utilisé) : cet attribut démarre une liste de comptes de service ou de comptes utilisateur pouvant accéder aux ressources du périmètre. L'Ingress par des identités de fédération d'identité de charge de travail n'est pas acceptée.

  • serviceAccount : compte de service auquel l'accès aux ressources du périmètre est accordé.

  • user : compte utilisateur auquel l'accès aux ressources du périmètre est accordé.

  • sources: (obligatoire) : cet attribut fait référence à une liste d'origines de réseau. Chaque valeur de la liste est un niveau d'accès ou un projet Google Cloud. Si vous définissez l'attribut accessLevel sur \"*\", la règle d'entrée autorise l'accès depuis n'importe quelle origine du réseau. Si vous définissez cet attribut sur un projet Google Cloud, la règle d'entrée autorise l'accès à partir d'un réseau VPC appartenant au projet.

  • - resource: (utilisez cet attribut ou l'attribut accessLevel) : spécifie un projet ou un réseau VPC situé en dehors du périmètre auquel vous souhaitez accorder l'accès. Pour spécifier un projet, utilisez le format suivant: projects/<project_number>. Pour spécifier un réseau VPC, utilisez le format suivant: //compute.googleapis.com/projects/<project-id>/global/networks/<network_name>.

  • - accessLevel: (soit cet attribut, soit l'attribut resource doit être utilisé) : indique le niveau d'accès extérieur au périmètre auquel l'accès est accordé. Si vous définissez l'attribut accessLevel sur \"*\", la règle d'entrée autorise l'accès depuis n'importe quelle origine du réseau.

  • ingressTo: (obligatoire) : ouvre le bloc to qui répertorie les opérations de service autorisées sur les ressources Google Cloud spécifiées au sein du périmètre.

  • operations: (obligatoire) : marque le début de la liste des services et actions/méthodes auxquels un client qui satisfait les conditions du bloc from est autorisé à accéder.

  • - serviceName: (obligatoire) : ce champ peut être un nom de service valide ou être défini sur \"*\" pour autoriser l'accès à tous les services. Par exemple, bigquery.googleapis.com est une valeur serviceName valide. Pour obtenir la liste des services disponibles, consultez la section Produits compatibles.

  • methodSelectors: (obligatoire si serviceName n'est pas \"*\") : début d'une liste de méthodes auxquelles un client remplissant les conditions de bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant être restreintes pour les services, consultez la section Restrictions de méthode de service compatibles.

  • - method: (soit cet attribut, soit l'attribut permission doit être utilisé) : Ce champ peut être une méthode de service valide ou peut être défini sur \"*\" pour autoriser l'accès à toutes les méthodes du service spécifié.

  • - permission: (soit cet attribut, soit l'attribut method doit être utilisé) : Ce champ doit être une autorisation de service valide. L'accès aux ressources au sein du périmètre sera autorisé pour les opérations nécessitant cette autorisation.

    Lorsqu'une requête adressée à une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises au cours de la même opération pour que la règle d'entrée fonctionne. Par exemple, si une requête adressée à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations lors de la même opération. De plus, si vous spécifiez les autorisations plusieurs fois pour la même ressource à l'aide de la console Google Cloud, elles ne seront pas créées lors de la même opération. Pour éviter ce problème, spécifiez toutes les autorisations à la fois pour la ressource.

  • resources: (obligatoire) : Cet attribut spécifie la liste des ressources Google Cloud du périmètre de service auxquelles le client extérieur peut accéder. Ce champ peut être défini sur \"*\" pour autoriser l'accès entrant à n'importe quelle ressource Google Cloud à l'intérieur du périmètre.

Pour créer une règle d'entrée fonctionnelle, vous devez spécifier les attributs suivants :

  • Attribut sources Vous devez spécifier un accessLevel ou un resource (projet Google Cloud ou réseau VPC), ou définir l'attribut accessLevel sur \"*\".
  • Attribut identityType ou identities
  • Attribut resources
  • Attribut serviceName

Une fois que vous avez terminé de configurer votre fichier de règles d'entrée, consultez la section Mettre à jour les règles d'entrée et de sortie pour savoir comment appliquer votre fichier de règles d'entrée à votre périmètre de service.

Documentation de référence sur les règles de sortie

Vous pouvez configurer les règles de sortie à l'aide de la console Google Cloud, ou à l'aide d'un fichier JSON ou YAML. L'exemple suivant utilise le format .yaml :

- egressTo:
    operations:
    - serviceName: service-name
      methodSelectors:
      - method: method
      *OR*
      - permission: permission
    resources:
    - projects/project
    *OR*
    externalResources:
    - external-resource-path
  egressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - serviceAccount:service-account
    - user:user-account
  • - egressTo: (obligatoire) : ouvre le bloc to, qui répertorie les opérations de service autorisées sur les ressources Google Cloud dans des projets spécifiés extérieurs au périmètre.

  • operations: (obligatoire) : marque le début de la liste des services et actions/méthodes auxquels un client qui satisfait les conditions du bloc from est autorisé à accéder.

  • - serviceName: (obligatoire) : ce champ peut être un nom de service valide ou être défini sur \"*\" pour autoriser l'accès à tous les services. Pour obtenir la liste des services disponibles, consultez la section Produits compatibles.

  • methodSelectors: (obligatoire si serviceName n'est pas \"*\") : début d'une liste de méthodes auxquelles un client remplissant les conditions de bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant être restreintes pour les services, consultez la section Restrictions de méthode de service compatibles.

  • - method: (soit cet attribut, soit l'attribut permission doit être utilisé). Ce champ peut être une méthode de service valide ou peut être défini sur \"*\" pour autoriser l'accès à toutes les méthodes du service spécifié.

  • - permission: (soit cet attribut, soit l'attribut method doit être utilisé). Ce champ doit être une autorisation de service valide. L'accès aux ressources spécifiées en dehors du périmètre sera autorisé pour les opérations nécessitant cette autorisation.

    Lorsqu'une requête adressée à une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises dans la même opération pour que la règle de sortie fonctionne. Par exemple, si une requête adressée à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations lors de la même opération. De plus, si vous spécifiez les autorisations plusieurs fois pour la même ressource à l'aide de la console Google Cloud, elles ne seront pas créées lors de la même opération. Pour éviter ce problème, spécifiez toutes les autorisations à la fois pour la ressource.

  • resources: : cet attribut est une liste de ressources Google Cloud spécifiées par leurs projets auxquelles les clients situés dans un périmètre peuvent accéder. Vous pouvez définir ce champ sur \"*\" pour autoriser l'accès de sortie à n'importe quelle ressource Google Cloud.

  • externalResources: : cet attribut n'est utilisé que pour spécifier des ressources BigQuery Omni. Il s'agit d'une liste de ressources externes compatibles avec BigQuery Omni auxquelles les clients situés au sein d'un périmètre peuvent accéder. Vous ne pouvez spécifier que des ressources Amazon S3 ou Azure Blob Storage. Pour Amazon S3, le format accepté est s3://BUCKET_NAME. Pour Azure Storage, le format accepté est azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: (obligatoire) : démarre le bloc from qui répertorie les sources et les identités autorisées dans le périmètre.

  • identityType: (soit cet attribut, soit l'attribut identities doit être utilisé). Cet attribut définit les types d'identités permettant d'accéder aux ressources spécifiées en dehors du périmètre. Valeurs acceptables : ANY_IDENTITY, ANY_USER_ACCOUNT, ANY_SERVICE_ACCOUNT. ANY_IDENTITY autorise toutes les identités. ANY_USER_ACCOUNT autorise tous les utilisateurs humains. ANY_SERVICE_ACCOUNT autorise tous les comptes de service.

  • identities: (soit cet attribut, soit l'attribut identityType doit être utilisé). Cet attribut lance une liste de comptes de service ou de comptes utilisateur pouvant accéder aux ressources spécifiées en dehors du périmètre. La sortie par les identités de la fédération d'identité de charge de travail n'est pas acceptée.

  • serviceAccount : Un compte de service pouvant accéder aux ressources spécifiées en dehors du périmètre.

  • user : compte utilisateur pouvant accéder aux ressources spécifiées en dehors du périmètre.

Une fois que vous avez terminé de configurer votre fichier de règles de sortie, consultez la section Mettre à jour les règles d'entrée et de sortie pour savoir comment appliquer votre fichier de règles d'entrée à votre périmètre de service.

Tester le fonctionnement des règles d'entrée et de sortie à l'aide du mode de simulation

Si vous ne souhaitez pas accorder l'accès à toutes les méthodes d'un service, il peut parfois être difficile de déterminer la liste exacte des méthodes à autoriser. Ce cas de figure peut se produire, car une méthode donnée pour un service peut entraîner l'appel d'une autre méthode sur un service Google Cloud distinct. Par exemple, BigQuery charge une table à partir d'un bucket Cloud Storage pour exécuter une requête.

Pour déterminer l'ensemble exact des méthodes à autoriser, vous pouvez utiliser le mode de simulation de VPC Service Controls. Pour ce faire, vous devez commencer par activer un périmètre en mode de simulation sans aucune règle d'entrée ou de sortie, puis collecter la liste des méthodes appelées à partir du journal d'audit. Ensuite, toujours en mode de simulation, ajoutez progressivement ces méthodes aux règles d'entrée et de sortie jusqu'à l'arrêt des cas de non-respect. À ce stade, la configuration peut être transférée du mode test vers le mode forcé.

Fonctionnalités non compatibles

Les fonctionnalités suivantes ne sont actuellement pas compatibles avec les règles d'entrée et de sortie :

  1. Identification des ressources Google Cloud à l'aide de libellés plutôt que par projet.
  2. Spécification de groupes dans le champ identities d'une règle from d'entrée ou de sortie.
  3. Certains services ne sont pas compatibles avec les règles d'entrée ou de sortie par méthode. Consultez la section Restrictions relatives aux méthodes de service compatibles.
  4. Les types d'identité ANY_SERVICE_ACCOUNT et ANY_USER_ACCOUNT ne peuvent pas être utilisés pour autoriser les opérations suivantes :

Limites

Pour plus d'informations sur les limites d'entrée et de sortie, consultez la page Quotas et limites.