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