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

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

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

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

Esempi di configurazione di casi d'uso di scambio di dati sicuri

Questa sezione contiene casi d'uso di esempio per lo scambio di dati in modo sicuro tra i perimetri di servizio.

Accedere a una risorsa Google Cloud al di fuori 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:

In uscita da un perimetro

Supponiamo che tu abbia 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. Poi definisci la seguente regola di 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 di uscita eseguendo il seguente comando:

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

Per ulteriori informazioni sul comando gcloud access-context-manager perimeters update, consulta gcloud access-context-manager perimeters update.

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

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

Uscita da un perimetro e ingresso in un altro perimetro

Supponiamo che tu abbia 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 di uscita che consenta l'iscrizione 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 di ingresso 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 per il traffico in entrata e in uscita eseguendo i seguenti 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

Condividere dati PHI anonimizzati con un'organizzazione partner

Il seguente diagramma mostra un perimetro attorno a un segmento di dati costituito da dati sanitari protetti (PHI), un secondo perimetro attorno a un segmento di dati anonimizzati e un'organizzazione partner distinta. Il segmento di dati 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.

Ingresso nel perimetro ed entrata e uscita dal perimetro

Vuoi definire regole di ingresso e uscita che consentano di condividere i dati anonimizzati con l'organizzazione partner e consentano al segmento di dati 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 assumere che il progetto dell'organizzazione partner sia 999. Puoi definire le seguenti regole per il traffico 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 per il traffico in entrata e in uscita eseguendo i seguenti 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

Concedere l'accesso a un'immagine del 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 al di fuori del perimetro:

Esportazione in un progetto di immagini

Supponiamo che tu abbia 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. Poi definisci la seguente regola di uscita in un file e lo salviamo 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 di uscita eseguendo il seguente 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 al di fuori del perimetro che devono leggere da una risorsa BigQuery all'interno di un perimetro:

Esportazione in un progetto di immagini

Puoi assumere 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 al di fuori del perimetro di vari partner. Definisci la seguente regola di ingresso 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 di ingresso eseguendo il seguente comando:

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

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

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

Puoi assumere 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 esterna al perimetro per consentire a un partner di scrivere dati nel bucket all'interno del perimetro. Definisci una regola di ingresso 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 di ingresso eseguendo il seguente comando:

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

Condividere 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 la raccolta dei dati dei log da tutto il deployment di 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 condivisi, che si trova nel proprio perimetro. Il progetto di log non deve accedere a risorse diverse dai log.

Supponiamo che tu abbia 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 dei log, definisci la seguente regola di uscita in un file e salvalo 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

È possibile specificare una configurazione simile per qualsiasi altro perimetro di dati sensibili che deve scrivere nel perimetro dei log.

Passaggi successivi