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 in entrata e in uscita, consulta Regole in entrata e in uscita.

Per istruzioni su come configurare i criteri delle regole in entrata e in uscita, consulta Configurare i criteri per le regole in entrata e in uscita.

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

Questa sezione contiene esempi di casi d'uso su come scambiare dati in modo sicuro tra perimetri di servizio.

• Accedere a una risorsa Google Cloud all'esterno del perimetro
• Condividere i dati utilizzando Pub/Sub tra due organizzazioni che utilizzano i Controlli di servizio VPC
• Condividere dati di tipo PHI anonimizzati con l'organizzazione partner
• Concedere l'accesso a un'immagine disco Compute Engine di terze parti
• Leggi 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 all'esterno del perimetro
• Condividi i log in un perimetro separato consentendo ai progetti di più perimetri di condividere i log

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, esterna al 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'altra organizzazione. 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 perimetri update.

Condividere 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 mediante 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 in uscita che consente l'abbonamento 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 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

Condividere dati di tipo PHI anonimizzati con un'organizzazione partner

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

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

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 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 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 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 progetto immagine di terze parti 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. Puoi quindi definire la seguente regola in uscita in un file e salvare 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 esterna al perimetro

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

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 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 maggiori flessibilità e controllo, BigQuery utilizza - permission: methodSelectors anziché - method: methodSelectors 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 più flessibilità e controllo.

Carica in un bucket Cloud Storage (scrittura) consentendo l'accesso privato da una rete VPC 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 all'esterno del perimetro per consentire 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 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 di dati di log in tutto il deployment Google Cloud. L'azienda deve essere in grado di registrare i dati da più perimetri dei Controlli di servizio VPC diversi nel progetto di log condivisi, che si trova nel proprio perimetro. Il progetto dei log non deve accedere a risorse diverse dai log.

Supponi 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 dei log, definisci la seguente regola in 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 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

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

Passaggi successivi

• Configurazione dei criteri in entrata e in uscita
• Accesso sensibile al contesto con regole in entrata
• Regole in entrata e in uscita