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 di dati sicuro e esempi 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 i criteri per le regole in entrata e in uscita, consulta Configurazione dei criteri di traffico in entrata e in uscita.

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

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

• Accedere a una risorsa Google Cloud al di fuori del perimetro
• Condividere i dati utilizzando Pub/Sub tra due organizzazioni che utilizzano Controlli di servizio VPC
• Condividere dati PHI anonimizzati con l'organizzazione partner
• Concedi l'accesso a un'immagine disco di Compute Engine di terze parti
• Leggere un set di dati BigQuery consentendo l'accesso privato da una rete VPC esterna al perimetro
• Carica in un bucket Cloud Storage (scrittura) consentendo l'accesso privato da una rete VPC esterna al perimetro
• Condividere i log in un perimetro separato consentendo ai progetti di più perimetri di condividerli

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:

Supponi 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 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.

Condividi i dati mediante 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:

Supponi 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 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 di traffico 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 costituito da informazioni sanitarie protette (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.

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

Supponi 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 di traffico 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

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 di Compute Engine in un'immagine di terze parti progetto esterno al perimetro:

Supponi 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. 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 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 al di fuori del perimetro che devono leggere da una risorsa BigQuery all'interno di un perimetro:

Si può presumere 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 diversi su diverse risorse e l'allineamento con il modello di autorizzazioni consente con 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

L'obiettivo è consentire l'accesso da una rete VPC esterna al perimetro a: consentire a un partner di scrivere dati nel bucket all'interno del perimetro. Tu definisci 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 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 condiviso, 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

• Configurazione dei criteri per il traffico in entrata e in uscita
• Accesso sensibile al contesto con le regole in entrata
• Regole per il traffico in entrata e in uscita