Proteggi lo scambio di dati con regole in entrata e in uscita

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

Per una panoramica delle regole in entrata e in uscita, consulta Regole in entrata e in uscita.

Per istruzioni su come configurare le policy per le regole in entrata e in uscita, consulta Configurazione delle policy in entrata e in uscita.

Esempi di configurazione per casi d'uso di scambio sicuro di dati

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

Accedi a una risorsa 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 si trova all'esterno del perimetro:

Traffico 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'organizzazione diversa. Quindi, definisci la seguente regola in uscita in un file e salva 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 saperne di più sul comando gcloud access-context-manager perimeters update, consulta gcloud access-context-manager perimeters update.

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:

Traffico in uscita da un perimetro e in entrata in 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 consente la sottoscrizione 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 in entrata e in uscita eseguendo questi comandi:

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

Condividi dati PHI anonimizzati con un'organizzazione partner

Il seguente diagramma mostra un perimetro attorno a un segmento di dati contenente dati sanitari protetti (PHI), un secondo perimetro attorno a un segmento di dati anonimizzati e un'organizzazione partner separata. Il segmento di PHI è in grado di manipolare i dati nel segmento di dati anonimizzati e i dati del segmento di dati anonimizzati vengono condivisi con l'organizzazione partner.

Traffico in entrata nel perimetro e in uscita dal perimetro

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

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 presupporre 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 in entrata e in uscita eseguendo questi comandi:

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 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 Compute Engine in un progetto di immagini di terze parti che si trova all'esterno del perimetro:

Traffico in uscita verso il progetto di immagini

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. Quindi, definisci la seguente regola in uscita in un file e salva il file 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

Leggi un set di dati BigQuery consentendo l'accesso privato da una rete VPC che si trova all'esterno del 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:

Traffico in uscita verso il progetto di immagini

Puoi supporre di utilizzare 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 che si trova all'esterno del perimetro di vari partner. Definisci la seguente regola in entrata in un file e salva il file 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 una maggiore flessibilità e controllo, BigQuery utilizza - permission: methodSelectors anziché - method: methodSelectors, che viene utilizzato dalla maggior parte dei servizi. Un singolo metodo BigQuery (RunQuery) può operare in modi diversi su diverse risorse e l'allineamento al modello di autorizzazioni consente maggiore flessibilità e controllo.

Carica in un bucket Cloud Storage (scrittura) consentendo l'accesso privato da una rete VPC che si trova all'esterno del perimetro

Puoi supporre di utilizzare 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 che si trova all'esterno del perimetro per permettere a un partner di scrivere dati nel bucket all'interno del perimetro. Definisci una regola in entrata e salva 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 la condivisione dei log a progetti in più perimetri

In questo caso d'uso, supponiamo che un'azienda abbia un progetto condiviso per la raccolta dei dati di log dall'intero deployment Google Cloud . L'azienda deve essere in grado di registrare i dati di più perimetri dei Controlli di servizio VPC diversi nel progetto di log condiviso, che si trova nel proprio perimetro. Il progetto di log non deve accedere ad altre risorse oltre ai log.

Supponiamo di aver definito i seguenti tre perimetri:

# 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 Logs, 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 in uscita eseguendo questi 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