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 :
- 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.
- 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.
- Un client Compute Engine dans un périmètre de service appelant une opération Compute Engine
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'ensembleb
, - une règle de sortie dans le périmètre
B
pour autoriser l'accès au bucket Cloud Storagea
, - 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ètreB
.
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 blocfrom
, qui répertorie les sources et identités extérieures au périmètre autorisées.identityType:
(soit cet attribut, soit l'attributidentities
doit être utilisé) : cet attribut définit les types d'identités pouvant être utilisés à partir dessources
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'attributidentityType
) 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 IAMv1
Identifiants des principaux API. Par exemple, utilisez la méthodegroup:GROUP_NAME@googlegroups.com
pour spécifier un groupe Google.VPC Service Controls n'accepte que les identités
v1
commençant par leuser
,serviceAccount
,group
(aperçu), etprincipal
(Preview) dans l'IAMv1
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'attributaccessLevel
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'attributaccessLevel
) 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'attributresource
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'attributaccessLevel
sur"*"
, la règle d'entrée autorise l'accès depuis n'importe quelle origine du réseau.ingressTo:
(obligatoire) : ouvre le blocto
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 blocfrom
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 valeurserviceName
valide. Pour obtenir la liste des services disponibles, consultez la section Produits compatibles.methodSelectors:
(obligatoire siserviceName
n'est pas"*"
) : début d'une liste de méthodes auxquelles un client qui satisfait les conditions du blocfrom
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'attributpermission
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'attributmethod
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
etbigquery.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émentaccessLevel
ouresource
(projet Google Cloud ou réseau VPC), ou définir l'attributaccessLevel
sur"*"
.
- Attribut
identityType
ouidentities
- 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 blocto
, 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 blocfrom
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 siserviceName
n'est pas"*"
) : début d'une liste de méthodes auxquelles un client qui satisfait les conditions du blocfrom
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'attributpermission
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'attributmethod
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
etbigquery.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é ests3://BUCKET_NAME
. Pour Azure Storage, le format accepté estazure://myaccount.blob.core.windows.net/CONTAINER_NAME
.egressFrom:
(obligatoire) : démarre le blocfrom
qui répertorie les valeurs autorisées et des identités au sein du périmètre.identityType:
(soit cet attribut, soit l'attributidentities
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'attributidentityType
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 IAMv1
Identifiants des principaux API. Par exemple, utilisez le formatgroup:GROUP_NAME@googlegroups.com
pour spécifier un groupe Google.VPC Service Controls n'accepte que les identités
v1
commençant par leuser
,serviceAccount
,group
(aperçu), etprincipal
(Preview) dans l'IAMv1
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
etANY_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.