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 in modo efficace un perimetro dei Controlli di servizio VPC. Questo tutorial dimostra poi come i servizi vengono consentiti o negati e come creare eccezioni granulari per una lista consentita di servizi specifici.
Obiettivi
- Configurare un perimetro dei Controlli di servizio VPC con controlli di rete aggiuntivi per ridurre i percorsi di esfiltrazione.
- Consentire o negare l'accesso ai servizi all'interno del perimetro alle richieste che hanno origine all'interno o all'esterno del perimetro.
- Consentire o negare l'accesso ai servizi all'esterno del perimetro alle richieste che hanno origine all'interno del perimetro.
- Combinare l'uso dei Controlli di servizio VPC e della policy dell'organizzazione Limita utilizzo servizi delle risorse.
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 l'addebito di ulteriori costi eliminando le risorse create. Per saperne di più, consulta Esegui la pulizia.
Prima di iniziare
Questo tutorial richiede un progetto all'interno della 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.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
Enable the Compute Engine, Access Context Manager, and Cloud DNS APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.-
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 column 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 l'accesso.
-
Nel campo Nuove entità, inserisci il tuo identificatore dell'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 successivo.
- 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 column 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 l'accesso.
-
Nel campo Nuove entità, inserisci il tuo identificatore dell'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 successivo.
- Fai clic su Salva.
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 progetto per il 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 la policy del server Cloud DNS per reindirizzare le query per le API Google Cloud al tuo 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 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 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 firewall negano il traffico in uscita in modo generico, prima di consentire selettivamente il traffico in uscita verso 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 e le regole firewall implicite.
In Cloud Shell, crea una policy 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."A livello del nodo dell'organizzazione è possibile avere un solo contenitore di policy di accesso. Se nella tua organizzazione è già stata creata una policy, 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 limita 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"
In Cloud Shell, esegui questo comando per creare una VM all'interno della tua 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 riesce perché Cloud Shell si trova all'esterno del perimetro e Compute Engine è configurato con il flag
--restricted-services.In Cloud Shell, esegui questo comando per accedere al servizio Resource Manager, che non è configurato nel flag
--restricted-services.gcloud projects describe PROJECT_ID
Una risposta con esito positivo restituisce i dettagli del progetto. Questa risposta dimostra che il perimetro consente il traffico esterno verso l'API Cloud Resource Manager.
Hai dimostrato che il perimetro nega il traffico esterno ai servizi configurati in
--restricted-servicese consente il traffico esterno ai servizi non configurati esplicitamente in--restricted-services.Da Cloud Shell, crea un file YAML che descrive 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 EOFgcloud 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 questo 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 riesce. Il perimetro impedisce al traffico esterno di utilizzare i servizi limitati, ma il livello di accesso che hai configurato consente un'eccezione.
Dalla scheda di Cloud Shell, esegui questo comando per rimuovere il livello di accesso:
gcloud access-context-manager perimeters update demo_perimeter \ --policy=$POLICY_ID \ --clear-access-levels
Dalla scheda di Cloud Shell, crea una policy in entrata che consenta alla tua identità utente di accedere solo al servizio Compute Engine e applicala al perimetro.
cat <<EOF > ingress_spec.yaml - ingressFrom: identities: - user:$USERNAME sources: - accessLevel: '*' ingressTo: operations: - methodSelectors: - method: '*' serviceName: compute.googleapis.com resources: - '*' EOFgcloud access-context-manager perimeters update demo_perimeter \ --set-ingress-policies=ingress_spec.yaml \ --policy=$POLICY_ID
Dalla scheda di Cloud Shell, esegui questo 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, quindi il perimetro dei Controlli di servizio VPC impedisce a Cloud Shell di comunicare con i servizi limitati all'interno del perimetro.
Dalla scheda di Cloud Shell, esegui questo comando per inviare una richiesta al servizio Compute Engine all'interno del perimetro:
gcloud compute instances describe demo-vm --zone=ZONE
Una risposta positiva restituisce i dettagli di
demo-vm. Questa risposta dimostra che il perimetro consente il traffico esterno che soddisfa le condizioni della policy in entrata al servizio Compute Engine.Da Cloud Shell, crea una regola firewall che permetta il traffico SSH verso la tua rete VPC consentendo il traffico in entrata dall'intervallo di indirizzi IP 35.235.240.0/20 utilizzato dal servizio IAP per il forwarding 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 su questa istanza:
gcloud compute ssh demo-vm --zone=ZONE
Verifica di aver eseguito la connessione all'istanza
demo-vmconfermando che il prompt della riga di comando è cambiato e mostra il nome host dell'istanza:username@demo-vm:~$Se il comando precedente non riesce, 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 aver completato l'avvio. Attendi un minuto e riprova.
Dalla sessione SSH all'interno del perimetro, verifica i servizi consentiti internamente dal perimetro utilizzando un servizio Google Cloud configurato nella lista consentita dei servizi accessibili da VPC. Ad esempio, prova un comando utilizzando 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 verso l'API Compute Engine.Dalla sessione SSH all'interno del perimetro, verifica che il traffico dalla tua VM verso i servizi non inclusi nella lista consentita dei servizi accessibili da VPC venga negato. Ad esempio, il seguente comando utilizza il servizio Resource Manager, che non è configurato nella lista consentita dei servizi accessibili da VPC.
gcloud projects describe PROJECT_ID
L'output è simile al seguente:
"ERROR: (gcloud.projects.list) PERMISSION_DENIED: Request is prohibited by organization's policy."La tua istanza Compute Engine e altri endpoint di rete possono richiedere solo servizi configurati nella lista consentita dei servizi accessibili da VPC. Tuttavia, le risorse serverless o il traffico di servizio proveniente dall'esterno del tuo perimetro potrebbero richiedere questo servizio. Se vuoi impedire l'utilizzo di un servizio nel tuo progetto, consulta la policy Limita utilizzo servizi delle risorse.
Dalla sessione SSH all'interno del perimetro, esegui questo comando per creare un bucket di archiviazione all'interno del perimetro. Questo comando funziona perché il servizio Cloud Storage è configurato sia in
restricted-servicesche inaccessible-services.gcloud storage buckets create gs://PROJECT_ID-02
Una risposta positiva crea il bucket di archiviazione. Questa risposta dimostra che il perimetro consente il traffico interno verso il servizio Cloud Storage.
Dalla sessione SSH all'interno del perimetro, esegui questo comando per leggere da un bucket che si trova all'esterno del perimetro. Questo bucket pubblico consente l'autorizzazione di sola lettura a
allUsers, ma il perimetro nega il traffico dall'interno del perimetro a un servizio limitato all'esterno 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 limitati all'interno del perimetro, ma una risorsa all'interno del perimetro non può comunicare con i servizi limitati all'esterno del perimetro.
Apri una nuova sessione di Cloud Shell facendo clic su Aprire una nuova scheda in Cloud Shell. Nei passaggi successivi alternerai la prima scheda, con la sessione SSH all'interno del perimetro, e la seconda scheda in Cloud Shell all'esterno del perimetro, il cui prompt della riga di comando inizia con
username@cloudshell.Dalla scheda di Cloud Shell, crea una policy in uscita che consenta il traffico in uscita proveniente dall'identità del service account collegato di
demo-vmche utilizza il metodogoogle.storage.objects.getverso un bucket pubblico in un progetto esterno. Aggiorna il perimetro con la policy 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 EOFgcloud access-context-manager perimeters update demo_perimeter \ --set-egress-policies=egress_spec.yaml \ --policy=$POLICY_ID
Torna alla scheda con la sessione SSH sulla VM all'interno del perimetro, il cui prompt della riga di comando inizia con
username@demo-vm.Dalla sessione SSH all'interno del perimetro, invia 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 il perimetro e la policy in uscita consentono il traffico interno da un'identità specifica verso un bucket Cloud Storage specifico.
Dalla sessione SSH all'interno del tuo perimetro, puoi anche testare altri metodi non esplicitamente consentiti dall'eccezione della policy in uscita. Ad esempio, il seguente comando richiede l'autorizzazione
google.storage.buckets.list, che viene negata dal 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 al traffico interno l'elencazione degli oggetti nel bucket esterno, indicando che la policy in uscita consente solo i metodi specificati in modo esplicito.
- Passa alla scheda di Cloud Shell, il cui prompt della riga di comando inizia con
username@cloudshell. Dalla scheda di Cloud Shell, crea un file YAML che descrive il servizio Policy dell'organizzazione che consentirà l'utilizzo solo 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 EOFgcloud resource-manager org-policies set-policy allowed_services_policy.yaml \ --project=PROJECT_ID
Torna alla scheda con la sessione SSH sulla VM all'interno del perimetro, il cui prompt della riga di comando inizia con
username@demo-vm.Dalla sessione SSH all'interno del perimetro, esegui questo 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 Policy dell'organizzazione nega il servizio Cloud Storage all'interno del progetto, indipendentemente dalla configurazione del perimetro.
Dalla sessione SSH all'interno del perimetro, esegui questo comando per visualizzare un bucket di archiviazione all'esterno del perimetro che è consentito dalla policy 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 positiva restituisce i contenuti di
helloworld.txtnel bucket di archiviazione esterno. Questa risposta dimostra che il perimetro e la policy in uscita consentono al traffico interno di raggiungere un bucket di archiviazione esterno in determinate condizioni limitate, ma il servizio Policy dell'organizzazione nega il servizio Cloud Storage nel 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 Policy dell'organizzazione Limita utilizzo servizi delle risorse.Per negare la comunicazione con Cloud Storage o altri servizi Google all'esterno del perimetro, il servizio Policy dell'organizzazione Limita utilizzo servizi delle risorse da solo non è sufficiente, devi configurare un perimetro dei Controlli di servizio VPC. I Controlli di servizio VPC mitigano i percorsi di esfiltrazione dei dati e Limita utilizzo servizi delle risorse è 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 tuo ambiente.
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
- Nel selettore di 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 il perimetro che vuoi eliminare e fai clic su Elimina.
Nella finestra di dialogo, fai di nuovo clic su Elimina per confermare l'eliminazione.
- Scopri di più sulle best practice per l'attivazione dei Controlli di servizio VPC.
- Scopri quali servizi sono supportati dai Controlli di servizio VPC.
- Scopri come attivare i servizi accessibili da VPC.
- Scopri di più sulla configurazione di Private Service Connect per accedere alle API di Google.
Per ulteriori architetture di riferimento, diagrammi, tutorial e best practice, esplora Cloud Architecture Center.
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 negano il traffico verso i servizi esterni. Le sezioni seguenti descrivono in dettaglio le configurazioni di rete che devi implementare nelle reti VPC all'interno del perimetro e presentano una configurazione di esempio 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 in uscita della rete verso internet.
Crea un perimetro dei Controlli di servizio VPC
In questa sezione crei un perimetro dei Controlli di servizio VPC.
Verifica i servizi consentiti per il traffico proveniente dall'esterno del perimetro
Le sezioni seguenti mostrano in che modo il perimetro dei Controlli di servizio VPC consente o nega l'accesso alle richieste provenienti dall'esterno del perimetro e in che modo puoi consentire selettivamente il traffico in entrata ai servizi configurando i livelli di accesso e le policy in entrata.
Per simulare il traffico dall'esterno del perimetro, puoi eseguire comandi in Cloud Shell. Cloud Shell è una risorsa all'esterno del tuo progetto e del perimetro. Il perimetro consente o nega le richieste anche se queste dispongono di privilegi Identity and Access Management sufficienti per essere soddisfatte.
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 verso i servizi limitati
In questa sezione verifichi che il perimetro neghi il traffico esterno verso i servizi limitati.
Il diagramma precedente illustra come a un client autorizzato viene negato l'accesso ai servizi all'interno del perimetro che hai configurato come limitati, ma viene consentito l'accesso ai servizi che non hai configurato come limitati.
Nei passaggi seguenti verifichi questo concetto utilizzando Cloud Shell per tentare di creare una VM all'interno della tua rete VPC; l'operazione non riesce a causa della configurazione del perimetro dei Controlli di servizio VPC.
Le sezioni seguenti introducono i pattern di eccezione per raggiungere i servizi limitati all'interno del perimetro.
Verifica 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 consentire al traffico esterno di accedere a tutti i servizi limitati all'interno del perimetro e non hai bisogno di eccezioni granulari per ogni servizio o altri attributi.
Il diagramma precedente illustra come un livello di accesso consente a un client autorizzato di accedere a tutti i servizi limitati all'interno del perimetro.
Nei passaggi seguenti verifichi questo concetto creando un livello di accesso e poi inviando una richiesta al servizio Compute Engine, che andrà a buon fine. Questa richiesta è consentita anche se hai configurato Compute Engine come servizio limitato.
Verifica che una policy in entrata consenta un'eccezione granulare al perimetro
In questa sezione verifichi che una policy in entrata consenta un'eccezione granulare al perimetro. Rispetto al livello di accesso, che ha una granularità grossolana, una policy in entrata granulare può configurare attributi aggiuntivi dell'origine del traffico e consentire l'accesso a singoli servizi o metodi.
Il diagramma precedente illustra come una policy in entrata consente a un client autorizzato di accedere solo a un servizio specificato all'interno del perimetro, senza consentire l'accesso ad altri servizi limitati.
Nei passaggi seguenti verifichi questo concetto sostituendo il livello di accesso con una policy in entrata che consente a un client autorizzato di accedere solo al servizio Compute Engine, ma non ad altri servizi limitati.
Verifica i servizi consentiti per il traffico proveniente dall'interno del perimetro
Le sezioni seguenti mostrano in che modo il perimetro dei Controlli di servizio VPC consente o nega richieste ai servizi provenienti dall'interno del perimetro e in che modo puoi consentire selettivamente il traffico in uscita ai servizi esterni mediante le policy 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. I comandi eseguiti dalla sessione SSH sull'istanza Compute Engine all'interno del perimetro utilizzano l'identità del service account 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 queste dispongono di privilegi IAM sufficienti per essere soddisfatte.
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 verso i servizi limitati all'interno del perimetro
In questa sezione verifichi che il perimetro consenta il traffico dagli endpoint di rete all'interno del perimetro se il servizio è configurato anche in Servizi accessibili da VPC.
Il diagramma precedente mostra come un perimetro consente al traffico proveniente dagli endpoint di rete all'interno del perimetro di raggiungere i servizi limitati che hai configurato anche come servizi accessibili da VPC. I servizi che non hai configurato come servizi accessibili da VPC non sono raggiungibili 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.
Verifica che il perimetro neghi il traffico interno verso i servizi limitati all'esterno del perimetro
In questa sezione verifichi che il perimetro blocchi la comunicazione dai servizi all'interno del perimetro ai servizi Google Cloud all'esterno del perimetro.
Il diagramma precedente illustra come il traffico interno non può comunicare con i servizi limitati all'esterno 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 all'esterno del perimetro.
Verifica che una policy in uscita consenta un'eccezione al perimetro
In questa sezione verifichi che una policy 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 ristretta con la policy in uscita.
Nei passaggi seguenti verifichi questo concetto creando una policy in uscita, quindi accedendo a un bucket Cloud Storage pubblico che si trova all'esterno del perimetro ed è consentito dalla policy in uscita.
Per ulteriori riferimenti sui pattern comuni per la condivisione di dati all'esterno del perimetro di servizio, consulta Proteggi lo scambio di dati con le regole in entrata e in uscita.
(Facoltativo) Configura la policy Limita utilizzo servizi delle risorse
Potresti anche avere requisiti interni o di conformità per cui consentire l'utilizzo solo di API approvate singolarmente nel tuo ambiente. In questo caso, puoi anche configurare il servizio Policy dell'organizzazione Limita utilizzo servizi delle risorse. Applicando la policy dell'organizzazione in un progetto, limiti i servizi che possono essere creati in quel progetto. Tuttavia, la policy dell'organizzazione non impedisce ai servizi in questo progetto di comunicare con i servizi in altri progetti. Al contrario, i Controlli di servizio VPC ti consentono di definire un perimetro per impedire la comunicazione con i servizi all'esterno del perimetro.
Ad esempio, se definisci una policy 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 nel progetto. 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 che seguono mostrano come implementare e testare questo scenario:
Esegui la pulizia
Sebbene il perimetro dei Controlli di servizio VPC non generi costi aggiuntivi, deve essere pulito per evitare l'accumulo di risorse inutilizzate nella tua organizzazione.
Passaggi successivi
-
-