Cette page a été traduite par l'API Cloud Translation.

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 depuis et vers le ressources et clients protégés par des 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.

Vous pouvez configurer des groupes d'identités identités (Preview) dans les règles d'entrée et de sortie. Pour un exemple de cas d'utilisation, consultez Exemple d'utilisation de groupes d'identités et d'identités tierces dans les 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

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.
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.
Minimisez le risque d'exfiltration en limitant le service, les méthodes, Projets, réseaux VPC et identités Google Cloud utilisés pour exécuter l'échange de données.
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.
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.
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 de l'entrée et de la sortie sont indépendantes de l'opération appelée sur la ressource. Ainsi, les définitions font référence à la direction 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. 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 gcloud storage 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 dans un réseau VPC situé en dehors du périmètre écrit dans un bucket Cloud Storage situé dans le 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 gcloud storage 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 gcloud storage 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).
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 dans le périmètre.

Dans les exemples BigQuery et Compute Engine, une règle d'entrée ne suffit pas, car la tâche BigQuery ou le disque Compute Engine se trouvent en dehors du périmètre. Une règle de sortie est requise pour autoriser une requête API implique 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 située en dehors le périmètre (la tâche BigQuery ou l'instance Compute Engine disque).

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 une périmètre de service A et un bucket b dans un périmètre de service B. Dans cet exemple, pour que le client Cloud Storage copie des 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 l'ensemble 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 du périmètre B pour autoriser l'accès 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'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 :

- ingressFrom:
    identityType: ANY_IDENTITY | ANY_USER_ACCOUNT | ANY_SERVICE_ACCOUNT
    *OR*
    identities:
    - PRINCIPAL_IDENTIFIER
    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: : (vous devez utiliser cet attribut ou l'attribut identityType) commence une liste de comptes de service, de comptes utilisateur, de groupes Google ou les identités ayant accès aux ressources du périmètre.
PRINCIPAL_IDENTIFIER : spécifiez un compte utilisateur, un compte de service, un groupe Google ou une identité tierce à laquelle vous souhaitez accorder l'accès aux ressources du périmètre. Utilisez le format spécifié dans IAM v1 Identifiants des principaux API. Par exemple, utilisez la méthode group:GROUP_NAME@googlegroups.com pour spécifier un groupe Google.

VPC Service Controls n'accepte que les identités v1 commençant par le user, serviceAccount, group (aperçu), et principal (Preview) dans l'IAM v1 identifiants principaux de l'API.
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 depuis un réseau VPC appartenant au projet.

Cette valeur peut être supprimée lorsque le projet associé est définitivement supprimé. Toutefois, la suppression de cette valeur n'entraîne pas d'erreur. Vérifiez toujours si cette valeur existe lorsque vous résolvez des problèmes.
- 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 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.

Lorsqu'une requête vers une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises pour la même opération pour que la règle d'entrée travail. Par exemple, si une requête à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations dans 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 sont pas créées dans la même opération. À d'éviter ce problème, spécifiez toutes les autorisations en même temps 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 élément accessLevel ou 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. 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:
    - PRINCIPAL_IDENTIFIER

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

Lorsqu'une requête vers une ressource nécessite plusieurs autorisations, vous devez spécifier toutes les autorisations requises pour la même opération pour que la règle de sortie travail. Par exemple, si une requête à une ressource BigQuery nécessite les autorisations bigquery.jobs.create et bigquery.tables.create, vous devez spécifier ces deux autorisations dans la même opération. De plus, si vous spécifiez plusieurs fois les autorisations pour la même ressource en utilisant console Google Cloud, les autorisations ne sont pas créées lors de la même opération. À d'éviter ce problème, spécifiez toutes les autorisations en même temps pour la ressource.
resources: : 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. Vous pouvez définir ce champ sur "*" pour autoriser l'accès en sortie à n'importe quelle ressource Google Cloud.
externalResources: : cet attribut n'est utilisé que pour spécifier les ressources BigQuery Omni. Cet attribut est une liste des 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 valeurs autorisées et des identités au sein du 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é). Ce permet de créer une liste de comptes de service, de comptes utilisateur, de groupes Google ou des identités tierces pouvant accéder aux ressources spécifiées en dehors du périmètre.
PRINCIPAL_IDENTIFIER : spécifiez un compte utilisateur, un compte de service, un groupe Google ou une identité tierce pouvant accéder aux ressources spécifiées en dehors du périmètre. Utilisez le format spécifié dans IAM v1 Identifiants des principaux API. Par exemple, utilisez le format group:GROUP_NAME@googlegroups.com pour spécifier un groupe Google.

VPC Service Controls n'accepte que les identités v1 commençant par le user, serviceAccount, group (aperçu), et principal (Preview) dans l'IAM v1 identifiants principaux de l'API.

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 :

Identification des ressources Google Cloud à l'aide de libellés plutôt que par projet.
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.
Les types d'identité ANY_SERVICE_ACCOUNT et ANY_USER_ACCOUNT ne peuvent pas être utilisés pour autoriser les opérations suivantes :
- Toutes les opérations Container Registry.
- Toutes les opérations de service notebooks.googleapis.com.
- Opérations Cloud Storage utilisant des URL signées.
- Avec les fonctions Cloud Run, le déploiement d'une fonction Cloud à partir de la machine locale.
- Exportez les journaux d'un récepteur Cloud Logging vers une ressource Cloud Storage.
- Toutes les opérations de l'interface utilisateur Web Apache Airflow dans Cloud Composer.

Limites

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

Étape suivante

Terminez cet codelab. pour savoir comment résoudre les cas de non-respect des règles d'entrée et de sortie.