Échange de données sécurisé à l'aide de règles d'entrée et de sortie

Ce document décrit les cas d'utilisation courants d'échange de données sécurisé, ainsi que des exemples de configurations permettant l'accès entre les clients et les ressources séparés par des périmètres de service.

Pour obtenir une présentation des règles d'entrée et de sortie, consultez la section Règles d'entrée et de sortie.

Pour obtenir des instructions sur la configuration des règles d'entrée et de sortie, consultez la page Configurer des règles d'entrée et de sortie.

Exemples de configuration pour des cas d'utilisation de l'échange de données sécurisé

Cette section contient des exemples de cas d'utilisation d'échanges sécurisés de données entre plusieurs périmètres de service.

• Accéder à une ressource Google Cloud en dehors du périmètre
• Partager des données entre deux organisations utilisant VPC Service Controls à l'aide de Pub/Sub
• Partager des données de santé protégées anonymes avec une organisation partenaire
• Accorder l'accès à une image disque Compute Engine tierce
• Lire un ensemble de données BigQuery en autorisant l'accès privé à partir d'un réseau VPC en dehors du périmètre
• Charger dans un bucket Cloud Storage (écriture) en autorisant l'accès privé à partir d'un réseau VPC en dehors du périmètre
• Partager des journaux dans un périmètre distinct en autorisant les projets de plusieurs périmètres à partager des journaux

Accéder à une ressource Google Cloud en dehors du périmètre

Le schéma suivant présente une ressource Compute Engine située dans un périmètre de service nécessitant un accès à une ressource Cloud Storage, située en dehors du périmètre :

Supposons que vous ayez défini le périmètre suivant :

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - storage.googleapis.com
title: Example

Vous devez accorder un accès en lecture à un bucket Cloud Storage dans project 999, qui se trouve dans une autre organisation. Vous définissez ensuite la règle de sortie suivante dans un fichier, puis enregistrez le fichier sous le nom gcs.yaml :

echo """
- egressTo:
    operations:
      - serviceName: storage.googleapis.com
        methodSelectors:
        - method: google.storage.objects.get
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > gcs.yaml

Appliquez la règle de sortie en exécutant la commande suivante :

gcloud beta access-context-manager perimeters update Example --set-egress-policies=gcs.yaml

Pour en savoir plus sur la commande gcloud access-context-manager perimeters update, consultez la page sur la commande gcloud access-context-manager perimeters update.

Partager des données entre deux organisations utilisant VPC Service Controls à l'aide de Pub/Sub

Le schéma suivant présente deux organisations, Org1 et Org2, qui utilisent VPC Service Controls et partagent des données à l'aide d'un sujet Pub/Sub :

Supposons que vous ayez défini les périmètres suivants :

# Org 1 Perimeter Definition
name: accessPolicies/222/servicePerimeters/Example1
status:
  resources:
  - projects/111
  restrictedServices:
  - pubsub.googleapis.com
title: Example1

# Org 2 Perimeter Definition
name: accessPolicies/333/servicePerimeters/Example2
status:
  resources:
  - projects/222
  restrictedServices:
  - pubsub.googleapis.com
title: Example2

Pour activer l'échange de données, Org1 doit définir la règle de sortie suivante qui autorise l'abonnement et enregistre le fichier sous le nom org1egress.yaml :

# Org1: Org1's perimeter must allow a Pub/Sub subscription to project 222.

echo """
- egressTo:
    operations:
    - serviceName: pubsub.googleapis.com
      methodSelectors:
      - method: Subscriber.CreateSubscription
    resources:
    - projects/222
  egressFrom:
    identityType: ANY_IDENTITY
""" > org1egress.yaml

Org2 doit définir une règle d'entrée correspondante autorisant l'abonnement et enregistrer le fichier sous le nom org2ingress.yaml.

# Org 2: Org2's perimeter must allow a Pub/Sub subscription from network
project 111 in Org1.

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/111
  ingressTo:
    operations:
    - serviceName: pubsub.googleapis.com
      methodSelectors:
      - method: Subscriber.CreateSubscription
    resources:
    - \"*\"
""" > org2ingress.yaml

Appliquez les règles d'entrée et de sortie en exécutant les commandes suivantes :

gcloud beta access-context-manager perimeters update Example2 1--set-egress-policies=org1egress.yaml

gcloud beta access-context-manager perimeters update Example1 1--set-ingress-policies=org2ingress.yaml

Partager des données de santé protégées anonymes avec une organisation partenaire

Le schéma suivant montre un périmètre autour d'un segment de données de données de santé protégées, un deuxième périmètre autour d'un segment de données anonymes, et une organisation partenaire distincte. Le segment de données de santé protégées est capable de manipuler les données du segment de données anonymes, et les données du segment de données anonymes sont partagées avec l'organisation partenaire.

Vous souhaitez définir des règles d'entrée et de sortie qui permettent le partage de données anonymes avec l'organisation partenaire et qui permettent à votre segment de données de santé protégées de manipuler les données du segment de données anonymes.

Supposons que vous ayez défini les périmètres suivants :

# PhiPerimeter
name: accessPolicies/222/servicePerimeters/PhiPerimeter
status:
  resources:
  - projects/111
  restrictedServices:
  - storage.googleapis.com
  - bigquery.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: PhiPerimeter

# AnonPerimeter
name: accessPolicies/222/servicePerimeters/AnonPerimeter
status:
  resources:
  - projects/222
  restrictedServices:
  - storage.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: AnonPerimeter

Vous pouvez également supposer que le projet de l'organisation partenaire est 999. Vous pouvez définir les règles d'entrée et de sortie suivantes :

# Anon Perimeter

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/111
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.Write
      - method: google.storage.objects.create
    resources:
    - \"*\"
""" > anoningress.yaml

echo """
- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.Write
      - method: google.storage.objects.create
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > anonegress.yaml

# PHI Perimeter

echo """
- egressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: \"*\"
    resources:
    - projects/222
  egressFrom:
    identityType: ANY_IDENTITY
""" > phiegress.yaml

Appliquez les règles d'entrée et de sortie en exécutant les commandes suivantes :

gcloud beta access-context-manager perimeters update AnonPerimeter --set-ingress-policies=anoningress.yaml --set-egress-policies=anonegress.yaml

gcloud beta access-context-manager perimeters update PhiPerimeter --set-egress-policies=phiegress.yaml

Accorder l'accès à une image disque Compute Engine tierce

Le schéma suivant illustre une ressource Compute Engine dans un périmètre de service qui nécessite l'accès à une image disque Compute Engine dans un projet d'image tiers situé en dehors du périmètre :

Supposons que vous ayez défini le périmètre suivant :

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  - projects/222
  restrictedServices:
  - compute.googleapis.com
  - containerregistry.googleapis.com
title: Example

Vous devez maintenant accorder un accès en lecture aux images disque dans project 999, qui se trouve dans une autre organisation. Vous définissez ensuite la règle de sortie suivante dans un fichier, puis enregistrez le fichier sous le nom compute.yaml :

echo """
- egressTo:
    operations:
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: InstancesService.Insert
    resources:
    - projects/999
  egressFrom:
    identityType: ANY_IDENTITY
""" > compute.yaml

Appliquez la règle de sortie en exécutant la commande suivante :

gcloud beta access-context-manager perimeters update Example --set-egress-policies=compute.yaml

Lire un ensemble de données BigQuery en autorisant l'accès privé à partir d'un réseau VPC en dehors du périmètre

Le schéma suivant montre plusieurs réseaux VPC partenaires en dehors du périmètre qui doivent lire les données d'une ressource BigQuery située dans un périmètre :

Supposons que vous utilisiez le même périmètre que celui de l'exemple 1 :

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
title: Example

Votre objectif est d'autoriser l'accès en lecture à partir d'un réseau VPC situé en dehors du périmètre de divers partenaires. Définissez la règle d'entrée suivante dans un fichier et enregistrez le fichier sous le nom partneringress.yaml :

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/888
    - resource: projects/999
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - permission: bigquery.datasets.get
      - permission: bigquery.tables.list
      - permission: bigquery.tables.get
      - permission: bigquery.tables.getData
      - permission: bigquery.jobs.create
    resources:
    - \"*\"

""" > partneringress.yaml

Appliquez la règle d'entrée en exécutant la commande suivante :

gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml

Pour plus de flexibilité et de contrôle, BigQuery utilise - permission: methodSelectors plutôt que la méthode - method: methodSelectors qui est utilisée par la plupart des services. Une seule méthode BigQuery (RunQuery) peut fonctionner de différentes manières sur plusieurs ressources, et l'alignement avec le modèle d'autorisations offre plus de flexibilité et de contrôle.

Charger dans un bucket Cloud Storage (écriture) en autorisant l'accès privé à partir d'un réseau VPC en dehors du périmètre

Supposons que vous utilisiez le même périmètre que celui de l'exemple 1 :

name: accessPolicies/222/servicePerimeters/Example
status:
  resources:
  - projects/111
  restrictedServices:
  - storage.googleapis.com
  - containerregistry.googleapis.com
title: Example

Votre objectif est d'autoriser l'accès depuis un réseau VPC situé en dehors du périmètre pour permettre à un partenaire d'écrire des données dans le bucket situé à l'intérieur du périmètre. Vous définissez une règle d'entrée et enregistrez le fichier sous le nom partneringress.yaml :

echo """
- ingressFrom:
    identityType: ANY_IDENTITY
    sources:
    - resource: projects/222
  ingressTo:
    operations:
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: google.storage.objects.create
    resources:
    - \"*\"
""" > partneringress.yaml

Appliquez la règle d'entrée en exécutant la commande suivante :

gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml

Partager des journaux dans un périmètre distinct en autorisant les projets de plusieurs périmètres à partager des journaux

Dans ce cas d'utilisation, supposons qu'une entreprise dispose d'un projet partagé pour la collecte de données de journaux provenant de son déploiement Google Cloud. L'entreprise doit pouvoir consigner les données provenant de différents périmètres VPC Service Controls dans le projet de journaux partagés, qui se trouve dans son propre périmètre. Le projet de journaux ne doit accéder à aucune ressource autre que les journaux.

Supposons que vous ayez défini les trois périmètres suivants :

# Sensitive 1
name: accessPolicies/222/servicePerimeters/Sensitive1
status:
  resources:
  - projects/111
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Sensitive Data 1

# Sensitive 2
name: accessPolicies/222/servicePerimeters/Sensitive2
status:
  resources:
  - projects/222
  restrictedServices:
  - bigquery.googleapis.com
  - containerregistry.googleapis.com
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Sensitive Data 2

#Logs
name: accessPolicies/222/servicePerimeters/Logs
status:
  resources:
  - projects/777
  restrictedServices:
  - logging.googleapis.com
  vpcAccessibleServices:
    enableRestriction: true
    allowedServices:
    - RESTRICTED_SERVICES
title: Logs Perimeter

Pour autoriser Sensitive1 et Sensitive2 à écrire des journaux dans le périmètre Logs, définissez la règle de sortie suivante dans un fichier et enregistrez le fichier sous le nom logsegress.yaml :

echo """
- egressTo:
    operations:
    - serviceName: logging.googleapis.com
      methodSelectors:
      - method: LoggingServiceV2.WriteLogEntries
      - method: LoggingService.WriteLogEntries
    resources:
    - projects/777
  egressFrom:
    identityType: ANY_IDENTITY
""" > logsegress.yaml

Appliquez les règles de sortie en exécutant les commandes suivantes :

gcloud beta access-context-manager perimeters update Sensitive1 --set-egress-policies=logsegress.yaml

gcloud beta access-context-manager perimeters update Sensitive2 --set-egress-policies=logsegress.yaml

Une configuration similaire peut être spécifiée pour tout autre périmètre de données sensibles devant écrire des données dans le périmètre de journaux.

Étape suivante

• Configurer des règles d'entrée et de sortie
• Accès contextuel à l'aide de règles d'entrée
• Règles d'entrée et de sortie