Sichere Datenaustausch-Setups für ein-/ausgehenden Traffic ermöglichen den Zugriff auf/von Clients und Ressourcen, die durch Service Perimeter getrennt sind. Der Zugriff wird durch Regeln für ein- und ausgehenden Traffic definiert.
Eine Übersicht über Regeln für ein- und ausgehenden Traffic finden Sie unter Regeln für ein- und ausgehenden Traffic.
Eine Anleitung zum Anwenden von Richtlinien für ein- und ausgehenden Traffic finden Sie unter Richtlinien für ein- und ausgehenden Traffic konfigurieren.
Konfigurationsbeispiele für Anwendungsfälle des sicheren Datenaustauschs
Dieser Abschnitt enthält die folgenden Beispiele für sichere Anwendungsfälle im Datenaustausch:
- Zugriff auf eine Google Cloud-Ressource außerhalb des Perimeters gewähren
- Freigabe über Pub/Sub zwischen zwei Organisationen, in denen beide VPC Service Controls verwenden
- PHI, anonymisiertes Datensegment und Partnerorganisation
- Compute Engine-Laufwerks-Image eines Drittanbieters
- Privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zum Zugriff auf ein BigQuery-Dataset erlauben
- Privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zum Laden in einen Cloud Storage-Bucket erlauben (Schreibzugriff)
- Projekten aus mehreren Perimetern erlauben, Logs in einem separaten Perimeter freizugeben
Zugriff auf eine Google Cloud-Ressource außerhalb des Perimeters gewähren
Angenommen, Sie haben den folgenden Perimeter definiert, der durch Listen des Perimeters mit gcloud ermittelt wird:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com title: Example
Sie möchten nun Lesezugriff auf einen Cloud Storage-Bucket in Projekt 999 gewähren, der sich in einer anderen Organisation befindet. Sie definieren die folgende Ausgangsregel und speichern diese 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
Freigabe über Pub/Sub zwischen zwei Organisationen, in denen beide VPC Service Controls verwenden
In diesem Beispiel teilen die beiden Organisationen Org1 und Org2 mithilfe von VPC Service Controls Daten über ein Pub/Sub-Thema.
Angenommen, Sie haben die folgenden Perimeter mithilfe der Liste der Perimeter mit gcloud 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
Damit diese Anzeigenplattform aktiviert wird, muss Org1 eine Regel für ausgehenden Traffic definieren, die das Abo zulässt.
# 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.
# 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 """ > 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
PHI, anonymisiertes Datensegment und Partnerorganisation
In diesem Beispiel möchten Sie einen Perimeter um ein PHI-Datensegment (Protected Health Information) und einen zweiten Perimeter um ein anonymisiertes Datensegment herum definieren. Sie möchten die Freigabe anonymisierter Daten für eine Partnerorganisation aktivieren und gleichzeitig Ihrem PHI-Segment ermöglichen, die Daten im anonymisierten Datensegment zu bearbeiten.
Angenommen, Sie haben die folgenden zwei Perimeter definiert, die durch Auflisten des Perimeters mit gcloud ermittelt werden:
# 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
Wir gehen auch davon aus, dass das Projekt der Partnerorganisation 999 ist. Dazu definieren Sie die folgenden Richtlinien:
# 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 """ > 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
Führen Sie den folgenden Befehl aus, um die Regeln für ausgehenden Traffic anzuwenden:
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
Compute Engine-Laufwerks-Image eines Drittanbieters
In diesem Beispiel wird die Verwendung eines Compute Engine-Laufwerk-Images in einem Drittanbieter-Image-Projekt autorisiert, das sich außerhalb aller Perimeter befindet.
Angenommen, Sie haben den folgenden Perimeter definiert, der durch Listen des Perimeters mit gcloud ermittelt wird:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 - projects/222 restrictedServices: - compute.googleapis.com - containerregistry.googleapis.com title: Example
Sie möchten jetzt Lesezugriff auf Laufwerk-Images in Projekt 999 (das sich in einer anderen Organisation befindet) gewähren. Definieren Sie die folgende Regel für ausgehenden Traffic:
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
Privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zum Zugriff auf ein BigQuery-Dataset erlauben
In diesem Beispiel wird davon ausgegangen, dass derselbe Perimeter wie Beispiel 1 verwendet wird:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - bigquery.googleapis.com - containerregistry.googleapis.com title: Example
Nun ist es Ihr Ziel, Zugriff auf ein VPC-Netzwerk außerhalb des Perimeters verschiedener Partner zu gewähren. Dazu definieren Sie eine Regel für eingehenden Traffic:
echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/888 - resource: projects/999 ingressTo: operations: - serviceName: bigquery.googleapis.com methodSelectors: - method: \"*\" """ > 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
Privaten Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zum Laden in einen Cloud Storage-Bucket erlauben (Schreibzugriff)
In diesem Beispiel wird davon ausgegangen, dass derselbe Perimeter wie Beispiel 1 verwendet wird:
name: accessPolicies/222/servicePerimeters/Example status: resources: - projects/111 restrictedServices: - storage.googleapis.com - containerregistry.googleapis.com title: Example
Nun ist es Ihr Ziel, den Zugriff von einem VPC-Netzwerk außerhalb des Perimeters zu ermöglichen, damit ein Partner Daten in den Perimeter laden kann. Definieren Sie dazu eine Regel für eingehenden Traffic:
echo """ - ingressFrom: identityType: ANY_IDENTITY sources: - resource: projects/222 ingressTo: operations: - serviceName: storage.googleapis.com methodSelectors: - method: google.storage.objects.create """ > 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
Projekten aus mehreren Perimetern erlauben, Logs in einem separaten Perimeter freizugeben
In diesem Anwendungsfall verfügt ein Unternehmen über ein freigegebenes Projekt zur Erfassung von Logging-Daten aus seiner Google Cloud-Bereitstellung. Es möchte Daten aus mehreren verschiedenen VPC Service Controls-Perimetern in diesem freigegebenen Logprojekt protokollieren können, das in seinem eigenen Perimeter enthalten ist. Es möchte nicht, dass das Logprojekt auf andere Ressourcen als die Logs selbst zugreifen kann.
Angenommen, Sie haben die folgenden drei Perimeter definiert, die durch Auflisten der Perimeter mit gcloud aufgeführt werden:
# 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 Logs schreiben können, sollten Sie Folgendes verwenden:
echo """ - egressTo: operations: - serviceName: logging.googleapis.com methodsSelectors: - method: LoggingServiceV2.WriteLogEntries - method: LoggingService.WriteLogEntries resources: - projects/999 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.