In diesem Dokument werden gängige Anwendungsfälle für den sicheren Datenaustausch sowie Beispielkonfigurationen beschrieben, die den Zugriff zwischen Clients und Ressourcen ermöglichen, die durch Dienstperimeter getrennt sind.
Eine Übersicht über Regeln für ein- und ausgehenden Traffic finden Sie unter Regeln für ein- und ausgehenden Traffic.
Eine Anleitung zum Konfigurieren von Richtlinien für eingehenden und ausgehenden Traffic finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic konfigurieren.
Konfigurationsbeispiele für Anwendungsfälle des sicheren Datenaustauschs
Dieser Abschnitt enthält Beispielanwendungsfälle für den sicheren Austausch von Daten zwischen Dienstperimetern.
- Auf eine Google Cloud Ressource außerhalb des Perimeters zugreifen
- Daten mithilfe von Pub/Sub zwischen zwei Organisationen teilen, die VPC Service Controls verwenden
- Anonymisierte PHI-Daten für Partnerorganisation freigeben
- Zugriff auf ein Compute Engine-Speicherabbild eines Drittanbieters gewähren
- BigQuery-Dataset lesen, indem Sie den privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zulassen
- Daten in einen Cloud Storage-Bucket laden (schreiben), indem Sie den privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zulassen
- Logs in einem separaten Perimeter freigeben, indem Sie für Projekte aus mehreren Perimetern die Freigabe von Logs zulassen
Auf eine Google Cloud Ressource außerhalb des Perimeters zugreifen
Das folgende Diagramm zeigt eine Compute Engine-Ressource innerhalb eines Dienstperimeters, die Zugriff auf eine Cloud Storage-Ressource außerhalb des Perimeters benötigt:

Angenommen, Sie haben den folgenden Perimeter definiert:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com - storage.googleapis.com title: Example
Sie müssen Lesezugriff auf einen Cloud Storage-Bucket in project 999 gewähren, das sich in einer anderen Organisation befindet. Dann definieren Sie die folgende Regel für ausgehenden Traffic in einer Datei und speichern die Datei als gcs.yaml:
echo """
- egressTo:
operations:
- serviceName: storage.googleapis.com
methodSelectors:
- method: google.storage.objects.get
resources:
- projects/999
egressFrom:
identityType: ANY_IDENTITY
""" > gcs.yaml
Wenden Sie die Ausgangsregel mit dem folgenden Befehl an:
gcloud beta access-context-manager perimeters update Example --set-egress-policies=gcs.yaml
Weitere Informationen zum Befehl gcloud access-context-manager perimeters update finden Sie unter gcloud access-context-manager perimeters update.
Daten mithilfe von Pub/Sub zwischen zwei Organisationen teilen, die VPC Service Controls verwenden
Das folgende Diagramm zeigt zwei Organisationen, Org1 und Org2, die VPC Service Controls verwenden und Daten mithilfe eines Pub/Sub-Themas freigeben:

Angenommen, Sie haben die folgenden Perimeter definiert:
# 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
Um den Datenaustausch zu aktivieren, muss Org1 die folgende Ausgangsregel definieren, die das Abo zulässt, und die Datei als org1egress.yaml zu speichern:
# 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 muss eine entsprechende Regel für eingehenden Traffic definieren, die das Abo zulässt, und die Datei als org2ingress.yaml zu speichern.
# 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
Wenden Sie die Regeln für ein- und ausgehenden Traffic mit den folgenden Befehlen an:
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
Anonymisierte PHI-Daten für Partnerorganisation freigeben
Das folgende Diagramm zeigt einen Perimeter um ein PHI-Datensegment (Protected Health Information) und einen zweiten Perimeter um ein anonymisiertes Datensegment herum und eine separate Partnerorganisation. Das PHI-Segment kann die Daten im anonymisierten Datensegment bearbeiten und die Daten aus dem anonymisierten Datensegment wird für die Partnerorganisation freigegeben.

Sie möchten Regeln für eingehenden und ausgehenden Traffic definieren, die die Freigabe anonymisierter Daten für die Partnerorganisation ermöglichen und Ihrem PHI-Segment die Bearbeitung der Daten im anonymisierten Datensegment ermöglichen.
Angenommen, Sie haben die folgenden Perimeter definiert:
# 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
Sie können auch davon ausgehen, dass das Projekt der Partnerorganisation 999 ist. Sie können die folgenden Regeln für eingehenden und ausgehenden Traffic definieren:
# 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
Wenden Sie die Regeln für ein- und ausgehenden Traffic mit den folgenden Befehlen an:
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
Zugriff auf ein Compute Engine-Speicherabbild eines Drittanbieters gewähren
Das folgende Diagramm zeigt eine Compute Engine-Ressource in einem Dienstperimeter, die Zugriff auf ein Compute Engine-Speicherabbild in einem Image-Projekt eines Drittanbieters außerhalb des Perimeters benötigt:

Angenommen, Sie haben den folgenden Perimeter definiert:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 - projects/222 restrictedServices: - compute.googleapis.com - containerregistry.googleapis.com title: Example
Sie müssen nun Lesezugriff auf Speicherabbilder in project 999 gewähren, das sich in einer anderen Organisation befindet. Dann definieren Sie die folgende Regel für ausgehenden Traffic in einer Datei und speichern die Datei als compute.yaml:
echo """
- egressTo:
operations:
- serviceName: compute.googleapis.com
methodSelectors:
- method: InstancesService.Insert
resources:
- projects/999
egressFrom:
identityType: ANY_IDENTITY
""" > compute.yaml
Wenden Sie die Ausgangsregel mit dem folgenden Befehl an:
gcloud beta access-context-manager perimeters update Example --set-egress-policies=compute.yaml
BigQuery-Dataset lesen, indem Sie den privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zulassen
Das folgende Diagramm zeigt mehrere Partner-VPC-Netzwerke außerhalb des Perimeters, die aus einer BigQuery-Ressource innerhalb eines Perimeters lesen müssen:

Sie können davon ausgehen, dass Sie denselben Perimeter wie in Beispiel 1 verwenden:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com title: Example
Ihr Ziel ist es, Lesezugriff von einem VPC-Netzwerk außerhalb des Perimeters verschiedener Partner zu ermöglichen. Definieren Sie die folgende Regel für eingehenden Traffic in einer Datei und speichern Sie die Datei als 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
Führen Sie den folgenden Befehl aus, um die Regel für eingehenden Traffic anzuwenden:
gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml
Für mehr Flexibilität und Kontrolle verwendet BigQuery - permission: methodSelectors anstelle von - method: methodSelectors, die von den meisten Diensten genutzt werden. Eine einzelne BigQuery-Methode (RunQuery) für verschiedene Ressourcen kann unterschiedlich ausgeführt werden und bietet mit dem Berechtigungsmodell bessere Flexibilität sowie Kontrolle.
Daten in einen Cloud Storage-Bucket laden (schreiben), indem Sie den privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zulassen
Sie können davon ausgehen, dass Sie denselben Perimeter wie in Beispiel 1 verwenden:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - storage.googleapis.com - containerregistry.googleapis.com title: Example
Ihr Ziel ist es, den Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zu ermöglichen, damit ein Partner Daten in den Bucket innerhalb des Perimeters schreiben kann. Sie definieren eine Regel für eingehenden Traffic und speichern die Datei als 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
Führen Sie den folgenden Befehl aus, um die Regel für eingehenden Traffic anzuwenden:
gcloud beta access-context-manager perimeters update Example --set-ingress-policies=partneringress.yaml
Logs in einem separaten Perimeter freigeben, indem Sie für Projekte aus mehreren Perimetern die Freigabe von Logs zulassen
Nehmen wir in diesem Anwendungsfall an, dass ein Unternehmen ein freigegebenes Projekt für die Erhebung von Logdaten aus seiner gesamten Google Cloud -Bereitstellung hat. Das Unternehmen muss in der Lage sein, Daten aus mehreren verschiedenen VPC Service Controls-Perimetern im freigegebenen Logprojekt zu protokollieren, das in seinem eigenen Perimeter enthalten ist. Das Logprojekt sollte auf keine anderen Ressourcen als die Logs zugreifen.
Angenommen, Sie haben die folgenden drei Perimeter definiert:
# 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
Damit Sensitive1 und Sensitive2 Logs in den Logperimeter schreiben können, definieren Sie die folgende Regel für ausgehenden Traffic in einer Datei und speichern Sie die Datei als 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
Führen Sie den folgenden Befehl aus, um die Regeln für ausgehenden Traffic anzuwenden:
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
Eine ähnliche Konfiguration kann für jeden anderen vertraulichen Datenperimeter angegeben werden, der in den Logperimeter schreiben muss.
Nächste Schritte
- Richtlinien für ein- und ausgehenden Traffic konfigurieren
- Kontextsensitiver Zugriff mit Eingangsregeln
- Regeln für ein- und ausgehenden Traffic