Protezione dello scambio di dati con le regole per il traffico in entrata e in uscita

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo documento descrive i casi d'uso comuni relativi allo scambio di dati sicuro e alle configurazioni di esempio per consentire l'accesso tra client e risorse separati da perimetri di servizio.

Per una panoramica delle regole di traffico in entrata e in uscita, vedi Regole in entrata e in uscita.

Per istruzioni su come configurare i criteri delle regole di traffico in entrata e in uscita, vedi Configurare i criteri in entrata e in uscita.

Esempi di configurazione dei casi d'uso sicuri di Data Exchange

Questa sezione contiene esempi di casi d'uso sullo scambio sicuro di dati tra perimetri di servizio.

Accedere a una risorsa di Google Cloud all'esterno del perimetro

Il seguente diagramma mostra una risorsa Compute Engine all'interno di un perimetro di servizio che richiede l'accesso a una risorsa Cloud Storage, che è esterna al perimetro:

In uscita da un perimetro

Supponiamo di aver definito il seguente perimetro:

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

Devi concedere l'accesso in lettura a un bucket Cloud Storage in project 999, che si trova in un'altra organizzazione. Puoi quindi definire la seguente regola in uscita in un file e salvare il file come gcs.yaml:

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

Applica la regola in uscita eseguendo questo comando:

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

Per maggiori informazioni sul comando gcloud access-context-manager perimeters update, consulta l'aggiornamento dei perimetri gcloud access-context-manager.

Condividi i dati utilizzando Pub/Sub tra due organizzazioni che utilizzano i Controlli di servizio VPC

Il seguente diagramma mostra due organizzazioni, Org1 e Org2, che utilizzano i controlli di servizio VPC e condividono i dati utilizzando un argomento Pub/Sub:

In uscita da un perimetro in entrata a un altro perimetro

Supponiamo di aver definito i seguenti perimetri:

# 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

Per abilitare lo scambio di dati, Org1 deve definire la seguente regola in uscita che consente la sottoscrizione e salvare il file come 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 deve definire una regola in entrata corrispondente che consenta l'abbonamento e salvare il file come 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

Applica le regole di traffico in entrata e in uscita eseguendo i comandi seguenti:

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

Condividere dati PHI anonimi con un'organizzazione partner

Il seguente diagramma mostra un perimetro intorno a un segmento di dati PHI (Protected Health Information), un secondo perimetro intorno a un segmento di dati anonimo e un'organizzazione partner separata. Il segmento PHI è in grado di manipolare i dati nel segmento di dati anonimizzato e i dati del segmento anonimo vengono condivisi con l'organizzazione partner.

In entrata nel perimetro e in uscita fuori dal perimetro

Vuoi definire regole di traffico in entrata e in uscita che consentano la condivisione dei dati anonimizzati con l'organizzazione partner e consentano al segmento PHI di manipolare i dati nel segmento di dati anonimizzato.

Supponiamo di aver definito i seguenti perimetri:

# 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

Puoi anche presumere che il progetto dell'organizzazione partner sia 999. Puoi definire le seguenti regole in entrata e in uscita:

# 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

Applica le regole di traffico in entrata e in uscita eseguendo i comandi seguenti:

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

Concedi l'accesso a un'immagine disco di Compute Engine di terze parti

Il seguente diagramma mostra una risorsa Compute Engine in un perimetro di servizio che richiede l'accesso a un'immagine disco di Compute Engine in un progetto immagine di terze parti all'esterno del perimetro:

In uscita verso un progetto immagine

Supponiamo di aver definito il seguente perimetro:

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

Ora devi concedere l'accesso in lettura alle immagini disco in project 999, che si trova in un'altra organizzazione. Puoi quindi definire la seguente regola in uscita in un file e salvarlo come compute.yaml:

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

Applica la regola in uscita eseguendo questo comando:

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

Leggere un set di dati BigQuery consentendo l'accesso privato da una rete VPC esterna al perimetro

Il seguente diagramma mostra più reti VPC partner all'esterno del perimetro che devono leggere da una risorsa BigQuery all'interno di un perimetro:

In uscita verso un progetto immagine

Puoi supporre che utilizzi lo stesso perimetro dell'esempio 1:

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

Il tuo obiettivo è consentire l'accesso in lettura da una rete VPC all'esterno del perimetro di vari partner. Definisci la seguente regola in entrata in un file e salvalo come 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

Applica la regola in entrata eseguendo questo comando:

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

Per flessibilità e controllo maggiori, BigQuery utilizza - permission: methodSelectors anziché - method: methodSelectors, che viene utilizzato dalla maggior parte dei servizi. Un singolo metodo di BigQuery (RunQuery) può funzionare in modi diversi su diverse risorse e l'allineamento con il modello di autorizzazioni consente una maggiore flessibilità e controllo.

Caricarla in un bucket Cloud Storage (scrittura) consentendo l'accesso privato da una rete VPC esterna al perimetro

Puoi supporre che utilizzi lo stesso perimetro dell'esempio 1:

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

Il tuo obiettivo è consentire l'accesso da una rete VPC all'esterno del perimetro per consentire a un partner di scrivere dati nel bucket all'interno del perimetro. Puoi definire una regola in entrata e salvare il file come 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

Applica la regola in entrata eseguendo questo comando:

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

Condividi i log in un perimetro separato consentendo ai progetti di più perimetri di condividere i log

In questo caso d'uso, supponiamo che un'azienda abbia un progetto condiviso per raccogliere i dati di log da tutto il suo deployment Google Cloud. L'azienda deve essere in grado di registrare i dati da più perimetri Controlli di servizio VPC diversi nel progetto dei log condivisi, che è in un proprio perimetro. Il progetto dei log non deve accedere ad alcuna risorsa diversa dai log.

Supponiamo di aver definito i tre perimetri seguenti:

# 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

Per consentire a Sensitive1 e Sensitive2 di scrivere log nel perimetro dei log, definisci la seguente regola in uscita in un file e salva il file come 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

Applica le regole di uscita eseguendo i seguenti comandi:

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

Una configurazione simile può essere specificata per qualsiasi altro perimetro di dati sensibili che deve scrivere nel perimetro dei log.

Passaggi successivi