Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare un perimetro dei Controlli di servizio VPC per una rete Virtual Private Cloud

Scopri come configurare un perimetro di servizio utilizzando i Controlli di servizio VPC. Questo tutorial utilizza impostazioni di rete come firewall, Private Service Connect e configurazioni DNS necessarie per utilizzare efficacemente un perimetro VPC Service Controls. Questo tutorial illustra poi come i servizi vengono consentiti o vietati e come fare eccezioni granulari per una lista consentita di servizi specifici.

Obiettivi

Configura un perimetro dei Controlli di servizio VPC con di networking per mitigare i percorsi di esfiltrazione.
Consentire o negare l'accesso ai servizi all'interno del perimetro da parte di richieste che dall'interno o dall'esterno del perimetro.
Consentire o negare l'accesso ai servizi esterni al perimetro dalle richieste che hanno avuto inizio all'interno del perimetro.
Utilizza insieme il criterio di organizzazione Limita l'utilizzo dei servizi delle risorse e i Controlli di servizio VPC.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza Calcolatore prezzi.

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando il le risorse che hai creato. Per ulteriori informazioni, vedi Esegui la pulizia.

Prima di iniziare

Questo tutorial richiede un progetto nella tua organizzazione. Se non hai ancora un'organizzazione Google Cloud, consulta creazione e gestione di un'organizzazione.
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
Enable the APIs
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Make sure that you have the following role or roles on the organization: Access Context Manager Admin, Organization Policy Administrator
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the organization.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  Vai a IAM
2. Seleziona l'organizzazione.
3. Fai clic su Concedi accesso.
4. Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
5. Nell'elenco Seleziona un ruolo, seleziona un ruolo.
6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
7. Fai clic su Salva.
8. Make sure that you have the following role or roles on the project: Compute Admin, DNS Administrator, IAP-Secured Tunnel User, Service Account User, Service Directory Editor
  Check for the roles
  1. In the Google Cloud console, go to the IAM page.
    Go to IAM
  2. Select the project.
  3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
  4. For all rows that specify or include you, check the Role colunn to see whether the list of roles includes the required roles.
  Grant the roles
  1. In the Google Cloud console, go to the IAM page.
    Vai a IAM
  2. Seleziona il progetto.
  3. Fai clic su Concedi accesso.
  4. Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
  5. Nell'elenco Seleziona un ruolo, seleziona un ruolo.
  6. Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
  7. Fai clic su Salva.
  Configura il perimetro dei Controlli di servizio VPC
  
  Per implementare un perimetro dei Controlli di servizio VPC per una rete VPC, è necessario implementare controlli di rete che negano il traffico ai servizi esterni. Le sezioni seguenti descrivono in dettaglio le configurazioni di rete da implementare nelle reti VPC all'interno del perimetro e un esempio di configurazione del perimetro.
  
  prepara la rete VPC
  
  In questa sezione, configuri la connettività privata alle API e ai servizi Google per la tua rete VPC, in modo da gamma di percorsi di rete in uscita verso internet.
  1. In Cloud Shell, imposta le variabili:
    
    gcloud config set project PROJECT_ID gcloud config set compute/region REGION gcloud config set compute/zone ZONE
    
    Sostituisci quanto segue:
    
    PROJECT_ID: l'ID del progetto in cui creerai le risorse
    
    REGION: una regione vicina alla tua posizione, ad esempio us-central1
    
    ZONE: una zona vicina alla tua posizione, ad esempio us-central1-a
  2. Crea una rete VPC e una subnet con l'accesso privato Google abilitato:
    
    gcloud compute networks create restricted-vpc --subnet-mode=custom gcloud compute networks subnets create restricted-subnet \ --range=10.0.0.0/24 \ --network=restricted-vpc \ --enable-private-ip-google-access
  3. Crea un endpoint Private Service Connect e una regola di inoltro configurata per utilizzare il bundle vpc-sc:
    
    gcloud compute addresses create restricted-psc-endpoint \ --global \ --purpose=PRIVATE_SERVICE_CONNECT \ --addresses=10.0.1.1 \ --network=restricted-vpc gcloud compute forwarding-rules create restrictedpsc \ --global \ --network=restricted-vpc \ --address=restricted-psc-endpoint \ --target-google-apis-bundle=vpc-sc
  4. Configura il criterio del server Cloud DNS per reindirizzare le query per le API Google Cloud all'endpoint Private Service Connect:
    
    gcloud dns managed-zones create restricted-dns-zone \ --description="Private DNS Zone to map Google API queries to the Private Service Connect endpoint for Google APIs" \ --dns-name="googleapis.com." \ --networks=restricted-vpc \ --visibility=private gcloud dns record-sets create googleapis.com \ --rrdatas=10.0.1.1 \ --type=A \ --ttl=300 \ --zone=restricted-dns-zone gcloud dns record-sets create *.googleapis.com \ --rrdatas="googleapis.com." \ --type=CNAME \ --ttl=300 \ --zone=restricted-dns-zone
  5. Configura una regola firewall con una priorità bassa per negare tutto il traffico in uscita:
    
    gcloud compute firewall-rules create deny-all-egress \ --priority=65534 \ --direction=egress \ --network=restricted-vpc \ --action=DENY \ --rules=all \ --destination-ranges=0.0.0.0/0
  6. Configurare una regola firewall con una priorità più elevata per consentire al traffico raggiungi l'indirizzo IP utilizzato da Private Service Connect endpoint:
    
    gcloud compute firewall-rules create allow-psc-for-google-apis \ --priority=1000 \ --direction=egress \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:443 \ --destination-ranges=10.0.1.1
    
    Queste regole firewall negano il traffico in uscita in modo ampio, prima di consentire selettivamente il traffico l'endpoint Private Service Connect. Questa configurazione nega il traffico in uscita verso i domini predefiniti normalmente raggiungibili per impostazione predefinita con l'accesso privato Google il regole firewall implicite.
  Crea un perimetro dei Controlli di servizio VPC
  
  In questa sezione crei un perimetro dei Controlli di servizio VPC.
  
  Nota: questo il tutorial implementa un perimetro in modalità di applicazione forzata perché non sono all'interno del perimetro. Se aggiungi un perimetro a un progetto progetti di produzione, consigliamo di eseguire test modalità dry run prima dell'applicazione forzata.
  1. In Cloud Shell, crea un criterio di accesso come prerequisito per creare un perimetro dei Controlli di servizio VPC:
    
    gcloud access-context-manager policies create \ --organization=ORGANIZATION_ID --title "Access policy at organization node"
    
    L'output è simile al seguente:
    
    "Create request issued Waiting for operation [operations/accessPolicies/123456789/create/123456789] to complete...done."
    
    Può esserci un solo container del criterio di accesso nel nodo organizzazione. Se che è già stato creato nella tua organizzazione, l'output è simile al seguente:
    
    "ALREADY_EXISTS: Policy already exists with parent ContainerKey{containerId=organizations/123456789012, numericId=123456789012}"
    
    Se visualizzi questo messaggio, vai al passaggio successivo.
  2. Crea un perimetro dei Controlli di servizio VPC che limiti i servizi Cloud Storage e Compute Engine.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") gcloud access-context-manager perimeters create demo_perimeter \ --title="demo_perimeter" \ --resources=projects/$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") \ --restricted-services="storage.googleapis.com,compute.googleapis.com" \ --enable-vpc-accessible-services \ --policy=$POLICY_ID \ --vpc-allowed-services="RESTRICTED-SERVICES"
    
    Attenzione: in questo tutorial limiti solo i servizi Compute Engine e Cloud Storage. In un perimetro di produzione, consigliamo limitare tutti i servizi supportati per mitigare una serie di percorsi di esfiltrazione.
    Il perimetro di esempio configura il flag --vpc-allowed-services con il valore dell'alias RESTRICTED-SERVICES per consentire il traffico da questo VPC allo stesso insieme di servizi definito con il --restricted-services.
  Verificare i servizi consentiti dal traffico esterno al perimetro
  
  Le sezioni seguenti mostrano in che modo il perimetro di Controlli di servizio VPC consente o nega l'accesso alle richieste effettuate dall'esterno del perimetro e in che modo puoi consentire in modo selettivo l'accesso ai servizi configurando i livelli di accesso e i criteri di ingresso.
  
  Per simulare il traffico dall'esterno del perimetro, puoi eseguire comandi in in Cloud Shell. Cloud Shell è una risorsa esterna al tuo progetto e al tuo perimetro. Il perimetro consente o nega le richieste anche se dispongono di privilegi di Identity and Access Management sufficienti per essere eseguite.
  
  Questo tutorial utilizza l'API Compute Engine, l'API Cloud Storage e l'API Cloud Resource Manager, ma gli stessi concetti si applicano anche ad altri servizi.
  
  Verifica che il perimetro neghi il traffico esterno ai servizi con limitazioni
  
  In questa sezione verificherai che il perimetro nega il traffico esterno con limitazioni.
  
  Il diagramma precedente illustra come a un client autorizzato viene negato l'accesso ai servizi all'interno del perimetro configurato come con restrizioni, ma al client viene consentito l'accesso ai servizi che non hai configurato come con restrizioni.
  
  Nei passaggi seguenti, verificherai questo concetto utilizzando Cloud Shell per tentativo di creare una VM all'interno della tua rete VPC, l'operazione non riesce a causa alla configurazione del perimetro Controlli di servizio VPC.
  1. In Cloud Shell, esegui il seguente comando per creare una VM all'interno della rete VPC.
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Request is prohibited by organization's policy."
    
    La richiesta non va a buon fine perché Cloud Shell si trova al di fuori del tuo perimetro e Compute Engine è configurato con il flag --restricted-services.
  2. In Cloud Shell, esegui questo comando per accedere il servizio Resource Manager, che non è configurato nella --restricted-services flag.
    
    gcloud projects describe PROJECT_ID
    
    Una risposta corretta restituisce i dettagli del progetto. Questa risposta dimostra che il tuo perimetro consente il traffico esterno all'API Cloud Resource Manager.
    
    Hai dimostrato che il perimetro nega il traffico esterno ai servizi configurati in --restricted-services e consente il traffico esterno ai servizi non configurati esplicitamente in--restricted-services.
  Le seguenti sezioni introducono i modelli di eccezione per raggiungere gli utenti con restrizioni dei servizi all'interno del perimetro.
  
  Verificare che un livello di accesso consenta un'eccezione al perimetro
  
  In questa sezione verifichi che un livello di accesso consenta un'eccezione al perimetro. Un livello di accesso è utile quando vuoi creare un'eccezione per il traffico esterno in modo che possa accedere a tutti i servizi con limitazioni all'interno del perimetro e non hai bisogno di eccezioni granulari per ogni servizio o per altri attributi.
  
  Il diagramma precedente illustra in che modo un livello di accesso consente a un client autorizzato di accedere a tutti i servizi soggetti a limitazioni all'interno del perimetro.
  
  Nei passaggi che seguono, verificherai questo concetto creando un livello di accesso e poi inviando una richiesta andata a buon fine al servizio Compute Engine. Questo è consentita anche se hai configurato Compute Engine come limitato.
  1. Da Cloud Shell, crea un file YAML che descriva configurazione di un livello di accesso e applicarlo al tuo perimetro. Questo esempio crea un livello di accesso per l'identità utente che stai attualmente per eseguire il tutorial.
    
    export USERNAME=$(gcloud config list account --format "value(core.account)") cat <<EOF > user_spec.yaml - members: - user:$USERNAME EOF
    
    gcloud access-context-manager levels create single_user_level \ --title="single-user access level" \ --basic-level-spec=user_spec.yaml \ --policy=$POLICY_ID gcloud access-context-manager perimeters update demo_perimeter \ --add-access-levels=single_user_level \ --policy=$POLICY_ID
  2. Da Cloud Shell, esegui di nuovo il comando seguente per tentare per creare una VM:
    
    gcloud compute instances create demo-vm \ --machine-type=e2-micro \ --subnet=restricted-subnet \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --no-address
    
    Questa volta la richiesta funziona. Il tuo perimetro impedisce al traffico esterno utilizzando i servizi limitati, ma il livello di accesso configurato consente un'eccezione.
    
    Nota: dopo aver aggiornato un perimetro di servizio, può essere necessario del tempo prima che le modifiche vengano propagate e applicate. Se ricevi un risultato imprevisto, attendi un minuto e riprova dopo l'aggiornamento completo del perimetro.
  Verificare che un criterio di ingresso consenta un'eccezione granulare al perimetro
  
  In questa sezione verificherai che un criterio in entrata consenta un'eccezione granulare al perimetro. Rispetto al livello di accesso granulare, un criterio di ingresso granulare può configurare attributi aggiuntivi relativi all'origine del traffico e consentire l'accesso a singoli servizi o metodi.
  
  Il diagramma precedente illustra come un criterio in entrata consenta a un di accedere solo a un servizio specificato all'interno del perimetro, senza consentire ad altri servizi soggetti a restrizioni.
  
  Nei passaggi successivi, verificherai questo concetto sostituendo il livello di accesso con un criterio di ingresso che consente a un client autorizzato di accedere solo al servizio Compute Engine, ma non consente l'accesso ad altri servizi con limitazioni.
  1. Dalla scheda Cloud Shell, esegui il seguente comando per rimuovere il livello di accesso.
    
    gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
  2. Dalla scheda Cloud Shell, crea un criterio in entrata che consenta alla tua identità utente di accedere solo al servizio Compute Engine e applica il criterio al perimetro.
    
    cat <<EOF > ingress_spec.yaml - ingressFrom: identities: - user:$USERNAME sources: - accessLevel: '*' ingressTo: operations: - methodSelectors: - method: '*' serviceName: compute.googleapis.com resources: - '*' EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-ingress-policies=ingress_spec.yaml \ --policy=$POLICY_ID
  3. Dalla scheda Cloud Shell, esegui il seguente comando per creare un bucket Cloud Storage all'interno del perimetro.
    
    gcloud storage buckets create gs://PROJECT_ID-01
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is prohibited by organization's policy."
    
    Cloud Shell è un client esterno al perimetro, Il perimetro dei Controlli di servizio VPC blocca che comunicano con i servizi limitati all'interno del perimetro.
  4. Dalla scheda Cloud Shell, esegui il seguente comando per effettuare una richiesta al servizio Compute Engine all'interno del perimetro.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Una risposta corretta restituisce i dettagli di demo-vm. Questa risposta dimostra che il perimetro consente il traffico esterno che soddisfa le delle condizioni del criterio in entrata al servizio Compute Engine.
  Verificare i servizi consentiti dal traffico all'interno del perimetro
  
  Le seguenti sezioni mostrano come il perimetro dei Controlli di servizio VPC consente o nega le richieste ai servizi dall'interno del perimetro e come puoi consentire selettivamente il traffico in uscita verso servizi esterni in base ai criteri di traffico in uscita.
  
  Per dimostrare la differenza tra il traffico all'interno e all'esterno del perimetro, le sezioni seguenti utilizzano sia Cloud Shell all'esterno del perimetro sia un' istanza Compute Engine creata all'interno del perimetro. Comandi che esegui la sessione SSH sull'istanza Compute Engine all'interno utilizza l'identità dell'account di servizio collegato, mentre i comandi da Cloud Shell al di fuori del perimetro, usa la tua identità. Se segui la configurazione consigliata per il tutorial, il perimetro consente o nega le richieste anche se dispongono di privilegi IAM sufficienti per essere eseguite.
  
  Questo tutorial utilizza l'API Compute Engine, l'API Cloud Storage e API Cloud Resource Manager, ma gli stessi concetti si applicano anche ad altri servizi.
  
  Verifica che il perimetro consenta il traffico interno ai servizi con limitazioni al suo interno
  
  In questa sezione, verifichi che il perimetro consenta il traffico dagli endpoint di rete all'interno del perimetro se il servizio è configurato anche nei servizi accessibili tramite VPC.
  
  Il diagramma precedente illustra in che modo un perimetro consente al traffico proveniente dagli endpoint di rete all'interno del perimetro di raggiungere i servizi con limitazioni che hai anche configurato come servizi accessibili da VPC. I servizi che non hai configurato come servizi accessibili dalla VPC non possono essere raggiunti dagli endpoint di rete all'interno del perimetro.
  
  Nei passaggi successivi, verificherai questo concetto stabilendo un protocollo SSH all'istanza Compute Engine all'interno del perimetro, le richieste ai servizi.
  1. Da Cloud Shell, crea una regola firewall che consenta l'accesso tramite SSH il traffico verso la tua rete VPC consentendo il traffico in entrata dall'IP 35.235.240.0/20 utilizzato IAP per inoltro TCP servizio:
    
    gcloud compute firewall-rules create demo-allow-ssh \ --direction=INGRESS \ --priority=1000 \ --network=restricted-vpc \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=35.235.240.0/20
  2. Avvia una sessione SSH con questa istanza:
    
    gcloud compute ssh demo-vm --zone=ZONE
    
    Verifica di aver eseguito correttamente la connessione all'istanza demo-vm tramite confermando che il prompt della riga di comando è cambiato per mostrare il nome host del tuo istanza:
    
    username@demo-vm:~$
    
    Se il comando precedente non va a buon fine, potresti visualizzare un messaggio di errore simile al seguente:
    
    "[/usr/bin/ssh] exited with return code [255]"
    
    In questo caso, l'istanza Compute Engine potrebbe non essere stata durante l'avvio. Attendi un minuto e riprova.
  3. Dalla sessione SSH all'interno del perimetro, verifica i servizi che il perimetro consente internamente utilizzando un servizio Google Cloud configurato nella lista consentita dei servizi accessibili dal VPC. Ad esempio, prova qualsiasi comando che utilizza il servizio Compute Engine.
    
    gcloud compute instances describe demo-vm --zone=ZONE
    
    Una risposta positiva restituisce i dettagli di demo-vm. Questa risposta dimostra che il tuo perimetro consente il traffico interno all'API Compute Engine.
  4. Dalla sessione SSH all'interno del tuo perimetro, verifica che i servizi non inclusi nella lista consentita di servizi accessibili da VPC non sono consentiti da della VM. Ad esempio, il seguente comando utilizza Servizio Resource Manager, che non è configurato nel VPC accessibile nella lista consentita di servizi.
    
    gcloud projects describe PROJECT_ID
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."
    
    L'istanza Compute Engine e gli altri endpoint di rete possono richiedere solo i servizi configurati nella lista consentita dei servizi accessibili del VPC. Tuttavia, le risorse serverless o il traffico di servizio provenienti dall'esterno del tuo perimetro potrebbero richiedere questo servizio. Se vuoi impedire che un servizio utilizzati nel tuo progetto, controlla Criterio di utilizzo delle risorse di servizio limitato.
  Verifica che il perimetro neghi il traffico interno ai servizi con limitazioni al di fuori del perimetro
  
  In questa sezione verificherai che il perimetro blocca le comunicazioni all'interno del perimetro ai servizi Google Cloud al di fuori perimetrale.
  
  Il diagramma precedente illustra come il traffico interno non può comunicare con ai servizi con restrizioni al di fuori del perimetro.
  
  Nei seguenti passaggi, verificherai questo concetto tentando di inviare messaggi interni traffico verso un servizio limitato all'interno del perimetro e verso un servizio limitato fuori dal perimetro.
  1. Dalla sessione SSH all'interno del perimetro, esegui il seguente comando per creare un bucket di archiviazione al suo interno. Questo comando funziona perché il servizio Cloud Storage è configurato sia in restricted-services e accessible-services.
    
    gcloud storage buckets create gs://PROJECT_ID-02
    
    Una risposta positiva crea il bucket di archiviazione. Questa risposta dimostra che il tuo perimetro consente il traffico interno al servizio Cloud Storage.
  2. Dalla sessione SSH all'interno del perimetro, esegui il seguente comando per leggere da un bucket esterno al perimetro. Questo il bucket pubblico consente l'autorizzazione di sola lettura per allUsers, ma il perimetro nega il traffico dall'interno del tuo perimetro a un servizio limitato all'esterno lungo il perimetro.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.storage.objects.describe) HTTPError 403: Request is prohibited by organization's policy."
    
    Questa risposta dimostra che puoi utilizzare i servizi soggetti a restrizioni all'interno del perimetro, ma una risorsa all'interno del perimetro non può comunicare con i servizi soggetti a restrizioni all'esterno del perimetro.
  Verificare che un criterio in uscita consenta un'eccezione al perimetro
  
  In questa sezione verificherai che un criterio in uscita consenta un'eccezione al perimetro.
  
  Il diagramma precedente illustra come il traffico interno può comunicare con una specifica risorsa esterna quando concedi un'eccezione limitata con il criterio in uscita.
  
  Nei passaggi successivi, verificherai questo concetto creando un criterio di uscita e poi accedendo a un bucket Cloud Storage pubblico al di fuori del perimetro consentito dal criterio di uscita.
  1. Apri una nuova sessione Cloud Shell facendo clic su Apri una nuova scheda in Cloud Shell. Nei passaggi successivi, passerai dalla prima scheda con la sessione SSH all'interno del perimetro alla seconda scheda in Cloud Shell all'esterno del perimetro, dove il prompt della riga di comando inizia con username@cloudshell.
  2. Dalla scheda Cloud Shell, crea un criterio in uscita che consenta in uscita dall'identità dell'account di servizio collegato di demo-vm utilizzando google.storage.objects.get a un bucket pubblico in un bucket progetto. Aggiorna il perimetro con il criterio in uscita.
    
    export POLICY_ID=$(gcloud access-context-manager policies list \ --organization=ORGANIZATION_ID \ --format="value(name)") export SERVICE_ACCOUNT_EMAIL=$(gcloud compute instances describe demo-vm \ --zone=ZONE) \ --format="value(serviceAccounts.email)"
    
    cat <<EOF > egress_spec.yaml - egressFrom: identities: - serviceAccount:$SERVICE_ACCOUNT_EMAIL egressTo: operations: - methodSelectors: - method: 'google.storage.objects.get' serviceName: storage.googleapis.com resources: - projects/950403849117 EOF
    
    gcloud access-context-manager perimeters update demo_perimeter \ --set-egress-policies=egress_spec.yaml \ --policy=$POLICY_ID
  3. Torna alla scheda con la sessione SSH per la VM all'interno del tuo perimetro, dove il prompt della riga di comando inizia con username@demo-vm.
  4. Dalla sessione SSH all'interno del tuo perimetro, effettua un'altra richiesta alla nel bucket Cloud Storage e verificare che funzioni.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    L'output è simile al seguente:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Questa risposta dimostra che i criteri del perimetro e del traffico in uscita consentono il traffico proveniente da un'identità specifica a uno specifico bucket Cloud Storage.
    
    Nota: dopo aver aggiornato un perimetro di servizio, può essere necessario del tempo prima che le modifiche vengano propagate e applicate. Se ricevi un risultato imprevisto, attendi minuto e riprova una volta completato l'aggiornamento del perimetro.
  5. Dalla sessione SSH all'interno del tuo perimetro, puoi anche testare altri non consentiti esplicitamente dall'eccezione del criterio in uscita. Per Ad esempio, il seguente comando richiede l'google.storage.buckets.list autorizzazione negata dal tuo perimetro.
    
    gcloud storage ls gs://solutions-public-assets/vpcsc-tutorial/*
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.storage.cp) Request is prohibited by organization's policy."
    
    Questa risposta dimostra che il perimetro nega il traffico interno l'elenco degli oggetti nel bucket esterno, a indicare che il criterio in uscita consente di utilizzare metodi esplicitamente specificati.
  Per ulteriori riferimenti sui pattern comuni per la condivisione di dati al di fuori del servizio perimetrale, vedi scambio sicuro di dati con regole di traffico in entrata e in uscita.
  
  (Facoltativo) Configurare il criterio Utilizzo delle risorse di servizio limitato
  
  Potresti anche avere requisiti di conformità o requisiti interni per consentire l'utilizzo nel tuo ambiente solo di API approvate singolarmente. In questo caso, puoi anche configurare il servizio di criteri dell'organizzazione Utilizzo delle risorse dei servizi con limitazioni. Se applichi il criterio dell'organizzazione a un progetto, limiti i servizi che possono essere creati in quel progetto. Tuttavia, le norme dell'organizzazione non impediscono ai servizi di questo progetto di comunicare con i servizi di altri progetti. I Controlli di servizio VPC, invece, ti consentono di definire un perimetro per impedire la comunicazione con i servizi esterni al perimetro.
  
  Ad esempio, se definisci un criterio dell'organizzazione per consentire in Compute Engine e negare Cloud Storage nel progetto, una VM non è stato possibile creare un bucket Cloud Storage in progetto. Tuttavia, la VM può effettuare richieste a un bucket Cloud Storage in un altro progetto, quindi l'esfiltrazione con il servizio Cloud Storage è possibile. I passaggi riportati di seguito mostrano come implementare e testare questo scenario:
  1. Passa alla scheda Cloud Shell, dove il prompt della riga di comando inizia con username@cloudshell.
  2. Dalla scheda Cloud Shell, crea un file YAML che descrive Servizio Criteri dell'organizzazione che consentirà solo l'utilizzo di Compute Engine e negare tutti gli altri servizi, quindi applicarlo al tuo progetto.
    
    cat <<EOF > allowed_services_policy.yaml constraint: constraints/gcp.restrictServiceUsage listPolicy: allowedValues: - compute.googleapis.com inheritFromParent: true EOF
    
    gcloud resource-manager org-policies set-policy allowed_services_policy.yaml \ --project=PROJECT_ID
  3. Torna alla scheda con la sessione SSH per la VM all'interno del tuo perimetro, dove il prompt della riga di comando inizia con username@demo-vm.
  4. Dalla sessione SSH all'interno del tuo perimetro, esegui questo comando lo stesso bucket di archiviazione creato in precedenza all'interno di questo progetto.
    
    gcloud storage buckets describe gs://PROJECT_ID
    
    L'output è simile al seguente:
    
    "ERROR: (gcloud.storage.buckets.create) HTTPError 403: Request is disallowed by organization's constraints/gcp.restrictServiceUsage constraint for 'projects/123456789' attempting to use service 'storage.googleapis.com'."
    
    Questa risposta dimostra che il servizio Criteri dell'organizzazione nega il servizio Cloud Storage all'interno del progetto, a prescindere dalla configurazione del perimetro.
    
    Nota: dopo aver aggiornato un servizio di criteri dell'organizzazione, può essere necessario del tempo prima che le modifiche vengano propagate e applicate. Se ricevi un risultato imprevisto, attendi un minuto e riprova dopo l'aggiornamento completo del perimetro.
  5. Dalla sessione SSH all'interno del tuo perimetro, esegui questo comando per visualizzare un bucket di archiviazione all'esterno del perimetro consentito in uscita.
    
    gcloud storage cat gs://solutions-public-assets/vpcsc-tutorial/helloworld.txt
    
    L'output è simile al seguente:
    
    "Hello world! This is a sample file in Cloud Storage that is viewable to allUsers."
    
    Una risposta corretta restituisce i contenuti di helloworld.txt nella Cloud Storage. Questa risposta dimostra che i criteri di perimetro e di uscita consentono al traffico interno di raggiungere un sistema di archiviazione esterno bucket in determinate condizioni limitate, ma il Servizio Criteri dell'organizzazione nega servizio Cloud Storage nel progetto a prescindere dalla configurazione perimetrale. I servizi esterni al progetto potrebbero comunque essere utilizzati per l'esfiltrazione se sono consentiti dal perimetro, indipendentemente dal servizio di criterio dell'organizzazione per l'utilizzo delle risorse dei servizi con limitazioni.
    
    Negare la comunicazione con Cloud Storage o altri servizi Google fuori dal perimetro, Utilizzo limitato delle risorse di servizio Il servizio Criteri dell'organizzazione da solo non è sufficiente; devi configurare un Perimetro Controlli di servizio VPC. I Controlli di servizio VPC mitigano i percorsi di esfiltrazione dei dati e Utilizzo di risorse di servizio con limitazioni è un controllo di conformità per impedire la creazione di servizi non approvati all'interno del tuo ambiente. Utilizza questi controlli insieme per bloccare una serie di percorsi di esfiltrazione e consentire selettivamente i servizi approvati per l'uso interno nel completamente gestito di Google Cloud.
  Esegui la pulizia
  Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
  
  L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
  
  Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
  
  Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.
  Delete a Google Cloud project:
  gcloud projects delete PROJECT_ID
  Sebbene il perimetro dei Controlli di servizio VPC non generi alcun costi aggiuntivi, deve essere ripulito per evitare disordine e risorse inutilizzate che fa parte della tua organizzazione.
  1. Nel selettore di progetti nella parte superiore della console Google Cloud, seleziona l'organizzazione che hai usato durante questo tutorial.
  2. Nella console Google Cloud, vai alla pagina Controlli di servizio VPC.
    
    Vai a Controlli di servizio VPC
  3. Sotto l'elenco dei perimetri, seleziona quello che vuoi eliminare e fai clic su Elimina.
  4. Nella finestra di dialogo, fai di nuovo clic su Elimina per confermare l'eliminazione.
  Passaggi successivi
  - Informazioni su best practice per l'abilitazione dei Controlli di servizio VPC.
  - Scopri quali servizi sono supportati in VPC Service Controls.
  - Scopri come attivare i servizi accessibili tramite VPC.
  - Scopri di più sulla configurazione di Private Service Connect per accedere alle API di Google.
  - Per altre architetture di riferimento, diagrammi, tutorial e le best practice Centro architetture cloud.

Configurare un perimetro dei Controlli di servizio VPC per una rete Virtual Private Cloud

Obiettivi

Costi

Prima di iniziare

Check for the roles

Grant the roles

Check for the roles

Grant the roles

Configura il perimetro dei Controlli di servizio VPC

prepara la rete VPC

Crea un perimetro dei Controlli di servizio VPC

Verificare i servizi consentiti dal traffico esterno al perimetro

Verifica che il perimetro neghi il traffico esterno ai servizi con limitazioni

Verificare che un livello di accesso consenta un'eccezione al perimetro

Verificare che un criterio di ingresso consenta un'eccezione granulare al perimetro

Verificare i servizi consentiti dal traffico all'interno del perimetro

Verifica che il perimetro consenta il traffico interno ai servizi con limitazioni al suo interno

Verifica che il perimetro neghi il traffico interno ai servizi con limitazioni al di fuori del perimetro

Verificare che un criterio in uscita consenta un'eccezione al perimetro

(Facoltativo) Configurare il criterio Utilizzo delle risorse di servizio limitato

Esegui la pulizia

Passaggi successivi