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 en provenance et à destination des ressources et 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. Limitez les risques d'exfiltration en définissant exactement quels service, méthodes, projets Google Cloud et identités sont autorisés à 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

  • 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. Par exemple :

    • 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).

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).

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. Exemple :

  • Pour autoriser un client Cloud Storage situé à l'intérieur du périmètre A à copier des objets entre un bucket Cloud Storage a situé à l'intérieur du périmètre A et un bucket Cloud Storage b situé à l'intérieur du périmètre B, les règles d'entrée et de sortie suivantes seront 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 pour le 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 de sortie peuvent être configurées à l'aide de Google Cloud Console, d'un fichier JSON ou d'un fichier YAML. L'exemple suivant utilise le format .yaml :

- ingressFrom:
    identityType: ANY_IDENTITY
    *OR*
    identities:
    - serviceAccount:service-account
    sources:
    - resource: projects/project
      *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: (soit cet attribut, soit l'attribut identityType doit être utilisé) : cet attribut ouvre une liste de comptes de service autorisés à accéder aux ressources du périmètre.

  • serviceAccount : compte de service 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.

  • - resource: (soit cet attribut, soit l'attribut accessLevel doit être utilisé) : spécifie le projet extérieur au périmètre auquel l'accès est accordé.

  • - 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) : marque le début d'une liste de méthodes auxquelles un client qui satisfait les conditions du bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant faire l'objet de restrictions pour les services, consultez la section Méthodes de service compatibles avec les restrictions.

  • - 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.

  • 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 élément accessLevel ou resource (projet Google Cloud), 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

Les règles d'entrée peuvent être configurées à l'aide de Google Cloud Console, d'un fichier JSON ou d'un fichier 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
    *OR*
    identities:
    - serviceAccount:service-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) : marque le début d'une liste de méthodes auxquelles un client qui satisfait les conditions du bloc from est autorisé à accéder. Pour obtenir la liste des méthodes et autorisations pouvant faire l'objet de restrictions pour les services, consultez la section Méthodes de service compatibles avec les restrictions.

  • - 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.

  • resources: (soit cet attribut, soit l'attribut externalResources doit être utilisé). Cet attribut est constitué d'une liste de ressources Google Cloud spécifiées par leurs projets et auxquelles les clients situés au sein d'un périmètre peuvent accéder. Ce champ peut être défini sur \"*\" pour autoriser l'accès en sortie à n'importe quelle ressource Google Cloud.

  • externalResources: (soit cet attribut, soit l'attribut resources doit être utilisé). Cet attribut est une liste des ressources externes auxquelles les clients situés au sein d'un périmètre peuvent accéder. Cet attribut n'accepte que les ressources AWS ou Azure. Pour Amazon S3, le format accepté est s3://BUCKET_NAME. Pour Azure Storage, le format est azure://myaccount.blob.core.windows.net/CONTAINER_NAME.

  • egressFrom: (obligatoire) Ouvre le bloc from qui répertorie les opérations de service autorisées sur les ressources Google Cloud dans des projets spécifiés 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 démarre une liste de comptes de service pouvant accéder aux ressources spécifiées en dehors du périmètre.

  • serviceAccount : Un compte de service 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.