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 Controlli di servizio VPC. 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 controlli di rete aggiuntivi per ridurre i percorsi di esfiltrazione.
- Consenti o nega l'accesso ai servizi all'interno del perimetro da richieste che provengono dall'interno o dall'esterno del perimetro.
- Consentire o negare l'accesso ai servizi esterni al perimetro da 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 in base all'utilizzo previsto, utilizza il Calcolatore prezzi.
Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.
Prima di iniziare
Questo tutorial richiede un progetto all'interno della tua organizzazione. Se non hai ancora un'organizzazione Google Cloud, consulta la sezione sulla creazione e gestione di un'organizzazione.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
-
In the Google Cloud console, 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
-
In the Google Cloud console, go to the IAM page.
Go to IAM - Select the organization.
-
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.
- 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
-
In the Google Cloud console, go to the IAM page.
Vai a IAM - Seleziona l'organizzazione.
- Fai clic su Concedi accesso.
-
Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
- Nell'elenco Seleziona un ruolo, seleziona un ruolo.
- Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
- Fai clic su Salva.
-
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
-
In the Google Cloud console, go to the IAM page.
Go to IAM - Select the project.
-
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.
- 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
-
In the Google Cloud console, go to the IAM page.
Vai a IAM - Seleziona il progetto.
- Fai clic su Concedi accesso.
-
Nel campo Nuove entità, inserisci il tuo identificatore utente. In genere si tratta dell'indirizzo email di un Account Google.
- Nell'elenco Seleziona un ruolo, seleziona un ruolo.
- Per concedere altri ruoli, fai clic su Aggiungi un altro ruolo e aggiungi ogni ruolo aggiuntivo.
- 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, devi implementare controlli di rete che impediscano il traffico verso i 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 per mitigare una serie di percorsi di uscita della rete su internet.
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
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
Crea un endpoint Private Service Connect e una regola di forwarding 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
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
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
Configura una regola del firewall con una priorità più alta per consentire al traffico di raggiungere l'indirizzo IP utilizzato dall'endpoint Private Service Connect:
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 di firewall negano il traffico in uscita in modo generico, prima di consentire in modo selettivo il traffico in uscita all'endpoint Private Service Connect. Questa configurazione nega il traffico in uscita per i domini predefiniti che sono normalmente raggiungibili per impostazione predefinita con l'accesso privato Google e le regole del firewall implicite.
Crea un perimetro dei Controlli di servizio VPC
In questa sezione crei un perimetro dei Controlli di servizio VPC.
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."
Nel nodo dell'organizzazione può essere presente un solo contenitore dei criteri di accesso. Se nella tua organizzazione è già stato creato un criterio, 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.
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"
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 tuo perimetro, puoi eseguire comandi 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 verifichi che il perimetro neghi il traffico esterno ai servizi soggetti a 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 successivi, verificherai questo concetto utilizzando Cloud Shell per tentare di creare una VM all'interno della tua rete VPC, il che non va a buon fine a causa della configurazione del perimetro dei Controlli di servizio VPC.
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
.In Cloud Shell, esegui il comando seguente per accedere al servizio Resource Manager, che non è configurato nel flag
--restricted-services
.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 sezioni seguenti introducono pattern di eccezione per raggiungere i servizi soggetti a limitazioni 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 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. Questa richiesta è consentita anche se hai configurato Compute Engine come limitato.
Da Cloud Shell, crea un file YAML che descriva la configurazione di un livello di accesso e applicalo al tuo perimetro. Questo esempio crea un livello di accesso per l'identità utente che stai attualmente utilizzando 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
Da Cloud Shell, esegui di nuovo il seguente comando per tentare di 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 perimetro impedisce al traffico esterno di utilizzare i servizi con limitazioni, ma il livello di accesso configurato consente un'eccezione.
Verificare che un criterio di ingresso consenta un'eccezione granulare al perimetro
In questa sezione, verifichi 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 di ingresso consente a un cliente autorizzato di accedere solo a un servizio specificato all'interno del perimetro, senza consentire l'accesso ad altri servizi con limitazioni.
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.
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
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
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, pertanto il perimetro dei Controlli di servizio VPC impedisce a Cloud Shell di comunicare con i servizi con limitazioni all'interno del perimetro.
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 al servizio Compute Engine di ricevere traffico esterno che soddisfa le condizioni del criterio di ingresso.
Verificare i servizi consentiti dal traffico all'interno del perimetro
Le sezioni seguenti mostrano come il perimetro di Controlli di servizio VPC consente o nega le richieste ai servizi dall'interno del perimetro e come puoi consentire in modo selettivo l'uscita verso i servizi esterni in base ai criteri di 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. I comandi eseguiti dalla sessione SSH sull'istanza Compute Engine all'interno del perimetro utilizzano l'identità dell'account di servizio collegato, mentre i comandi eseguiti da Cloud Shell all'esterno del perimetro utilizzano 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 l'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 seguenti, verifichi questo concetto stabilendo una connessione SSH all'istanza Compute Engine all'interno del perimetro, quindi inviando richieste ai servizi.
Da Cloud Shell, crea una regola firewall che consenta il traffico SSH alla tua rete VPC consentendo l'ingresso dall'intervallo di indirizzi IP 35.235.240.0/20 utilizzato dal servizio IAP per l'inoltro TCP:
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
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
verificando che il prompt della riga di comando sia cambiato per mostrare il nome host dell'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'avvio dell'istanza Compute Engine potrebbe non essere stato completato. Attendi un minuto e riprova.
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 corretta restituisce i dettagli di
demo-vm
. Questa risposta dimostra che il tuo perimetro consente il traffico interno all'API Compute Engine.Dalla sessione SSH all'interno del perimetro, verifica che i servizi non inclusi nella lista consentita dei servizi accessibili del VPC non siano consentiti dalla VM. Ad esempio, il seguente comando utilizza il servizio Resource Manager, che non è configurato nella lista consentita dei servizi accessibili al VPC.
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 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 l'utilizzo di un servizio nel tuo progetto, consulta il Criterio relativo all'utilizzo delle risorse dei servizi con limitazioni.
Verifica che il perimetro neghi il traffico interno ai servizi con limitazioni al di fuori del perimetro
In questa sezione, verifichi che il perimetro blocchi la comunicazione dai servizi all'interno del perimetro ai servizi Google Cloud al di fuori del perimetro.
Il diagramma precedente illustra in che modo il traffico interno non può comunicare con i servizi soggetti a limitazioni al di fuori del perimetro.
Nei passaggi seguenti, verifichi questo concetto tentando di inviare traffico interno a un servizio limitato all'interno del perimetro e a un servizio limitato al di fuori del perimetro.
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
che inaccessible-services
.gcloud storage buckets create gs://PROJECT_ID-02
Una risposta corretta crea il bucket di archiviazione. Questa risposta dimostra che il tuo perimetro consente il traffico interno al servizio Cloud Storage.
Dalla sessione SSH all'interno del perimetro, esegui il seguente comando per leggere da un bucket esterno al perimetro. Questo secchio pubblico consente l'autorizzazione di sola lettura a
allUsers
, ma il perimetro nega il traffico dall'interno del perimetro a un servizio soggetto a limitazioni al di fuori del 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 verifichi che un criterio in uscita consenta un'eccezione al perimetro.
Il diagramma precedente illustra come il traffico interno può comunicare con una risorsa esterna specifica quando concedi un'eccezione specifica con il criterio di 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.
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 conusername@cloudshell
.Dalla scheda Cloud Shell, crea un criterio di uscita che consenta l'uscita dall'identità dell'account di servizio collegato di
demo-vm
utilizzando il metodogoogle.storage.objects.get
in un bucket pubblico in un progetto esterno. 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
Torna alla scheda con la sessione SSH alla VM all'interno del tuo perimetro, dove il prompt della riga di comando inizia con
username@demo-vm
.Dalla sessione SSH all'interno del tuo perimetro, effettua un'altra richiesta al bucket Cloud Storage e verifica 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 le norme di perimetro e di uscita consentono il traffico interno da un'identità specifica a un bucket Cloud Storage specifico.
Dalla sessione SSH all'interno del perimetro, puoi anche testare altri metodi non consentiti esplicitamente dall'eccezione per i criteri di uscita. Ad esempio, il seguente comando richiede l'autorizzazione
google.storage.buckets.list
che è 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 dall'elenco degli oggetti nel bucket esterno, indicando che il criterio di uscita consente strettamente i metodi specificati esplicitamente.
Per ulteriori riferimenti su pattern comuni per la condivisione di dati al di fuori del perimetro del servizio, consulta Protezione dello scambio di dati con le regole per il traffico in entrata e in uscita.
(Facoltativo) Configura il criterio di utilizzo delle risorse del servizio con limitazioni
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 Compute Engine e negare Cloud Storage nel tuo progetto, una VM in questo progetto non potrà creare un bucket Cloud Storage. Tuttavia, la VM può inviare richieste a un bucket Cloud Storage in un altro progetto, quindi l'esfiltrazione con il servizio Cloud Storage è ancora possibile. I passaggi seguenti mostrano come implementare e testare questo scenario:
- Passa alla scheda Cloud Shell, dove il prompt della riga di comando inizia con
username@cloudshell
. Dalla scheda Cloud Shell, crea un file YAML che descriva il servizio Organization Policy che consentirà solo l'utilizzo del servizio Compute Engine e negherà tutti gli altri servizi, quindi applicalo 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
Torna alla scheda con la sessione SSH alla VM all'interno del tuo perimetro, dove il prompt della riga di comando inizia con
username@demo-vm
.Dalla sessione SSH all'interno del perimetro, esegui il seguente comando per visualizzare lo stesso bucket di archiviazione che hai 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 Organization Policy nega il servizio Cloud Storage all'interno del progetto, indipendentemente dalla configurazione del perimetro.
Dalla sessione SSH all'interno del perimetro, esegui il seguente comando per visualizzare un bucket di archiviazione esterno al perimetro consentito dal criterio di 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 positiva restituisce i contenuti di
helloworld.txt
nel bucket di archiviazione esterno. Questa risposta dimostra che il tuo perimetro e il tuo criterio di uscita consentono al traffico interno di raggiungere un bucket di archiviazione esterno in determinate condizioni limitate, ma il servizio Organization Policy nega il servizio Cloud Storage nel tuo progetto indipendentemente dalla configurazione del perimetro. 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.Per negare la comunicazione con Cloud Storage o altri servizi Google al di fuori del perimetro, il servizio di criteri dell'organizzazione Utilizzo delle risorse dei servizi con limitazioni non è sufficiente. Devi configurare un perimetro di Controlli di servizio VPC. I Controlli di servizio VPC mitigano i percorsi di esfiltrazione dei dati e Utilizzo di risorse di servizi 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 in modo selettivo i servizi approvati per l'uso interno nel tuo ambiente.
Esegui la pulizia
Delete a Google Cloud project:
gcloud projects delete PROJECT_ID
Sebbene il perimetro di Controlli di servizio VPC non generi costi aggiuntivi, deve essere ripulito per evitare risorse inutilizzate e disordine nella tua organizzazione.
- Nel selettore dei progetti nella parte superiore della console Google Cloud, seleziona l'organizzazione che hai utilizzato durante questo tutorial.
Nella console Google Cloud, vai alla pagina Controlli di servizio VPC.
Nell'elenco dei perimetri, seleziona quello che vuoi eliminare e fai clic su Elimina.
Nella finestra di dialogo, fai di nuovo clic su Elimina per confermare l'eliminazione.
Passaggi successivi
- Scopri le best practice per attivare i 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 best practice, visita il Cloud Architecture Center.