Sicherer Datenaustausch mit Regeln für ein- und ausgehenden Traffic

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