Controlli di servizio VPC - Codelab sulla protezione di BigQuery I

1. Introduzione

In questo codelab imparerai a proteggere l'API BigQuery utilizzando i Controlli di servizio VPC. Il codelab inizia senza alcun servizio API protetto dal perimetro di servizio, consentendo l'esecuzione di query su set di dati pubblici e il salvataggio dei risultati in una tabella del progetto. La query viene eseguita in un progetto e la tabella (in cui vengono salvati i risultati) viene creata in un altro progetto, simulando una configurazione in cui i dati possono essere archiviati in un progetto, ma è necessario accedervi utilizzando un progetto diverso.

Successivamente, introdurremo un perimetro di servizio per proteggere il progetto di dati. Scoprirai come correggere le violazioni osservate utilizzando le regole in entrata e in uscita e in seguito aggiungerai un livello di accesso per limitare l'accesso utilizzando gli indirizzi IP interni. Gli obiettivi di questo codelab sono:

• Scopri come correggere le violazioni in entrata e in uscita utilizzando rispettivamente le regole in entrata e in uscita.
• Comprendere il motivo di una violazione specifica.
• Analizza l'ambito della correzione della violazione applicata.
• Modifica la correzione (regola in entrata / in uscita) per cambiarne l'ambito sfruttando l'opzione per consentire il traffico dagli indirizzi IP interni in una rete VPC utilizzando i livelli di accesso.

2. Configurazione e requisiti delle risorse

Prima di iniziare

In questo codelab, presupponiamo che tu sappia già:

• Le nozioni di base per eseguire una query BigQuery: puoi consultare questo codelab per scoprire come eseguire query sul set di dati di Wikipedia in BigQuery
• Come creare e gestire una cartella
• Come creare un progetto in una cartella o spostare un progetto esistente in una cartella
• Come creare una policy di accesso con ambito
• Come creare e configurare un perimetro di servizio
• Come trovare le violazioni delle norme di sicurezza nei log

Configurazione

La nostra configurazione iniziale è progettata nel seguente modo:

Se hai completato il tutorial di base sui Controlli di servizio VPC, puoi riutilizzare gli stessi progetti, la stessa cartella e lo stesso perimetro di servizio.

• Un'organizzazione Google Cloud.
• Una cartella nell'organizzazione. Per questo codelab lo chiameremo codelab-folder.
• Due progetti Google Cloud inseriti nella stessa cartella, codelab-folder. Per questo codelab, li chiameremo project-1 e project-2
  • Se non hai ancora creato la cartella e i progetti, nella console Google Cloud, crea una cartella nell'organizzazione e crea due nuovi progetti nella cartella creata.
• Le autorizzazioni obbligatorie:
  • Ruoli IAM per la gestione delle cartelle: assegnati a livello di cartella
  • Ruoli IAM per la gestione dei progetti: assegnati a livello di progetto
  • Ruoli IAM necessari per configurare i Controlli di servizio VPC: assegnati a livello di organizzazione
  • Ruoli IAM per la gestione di BigQuery: assegnati a livello di progetto
  • Ruoli IAM per la gestione dell'istanza Compute Engine: assegnati a livello di progetto
• L'account di fatturazione per entrambi i progetti, project-2 e project-1.

Ai fini di questo codelab, puoi concederti i seguenti ruoli predefiniti: Amministratore cartelle e Creatore progetto (a livello di cartella), Proprietario (a livello di progetto), Amministratore BigQuery (a livello di progetto) e Amministratore Gestore contesto accesso (a livello di organizzazione). In questo modo, avrai i ruoli necessari per configurare le risorse richieste per l'intero codelab.

Crea un perimetro di servizio regolare

In questo codelab utilizzeremo un perimetro di servizio normale che protegge project-1.

• Crea un perimetro normale, perimeter-1 e aggiungi project-1.

Nel perimetro, non limitare ancora alcun servizio. Lo faremo più tardi.

Creare una VM Compute Engine

In questo codelab utilizzeremo un'istanza Compute Engine in project-2, che si trova in us-central1 e utilizza la rete VPC predefinita denominata default.

• Puoi fare riferimento alla documentazione come linea guida per creare un'istanza Compute Engine da un'immagine pubblica.

Per questo codelab, utilizzeremo la rete VPC predefinita, denominata default. Puoi anche utilizzare qualsiasi altra rete, purché abbia almeno una subnet.

Costo

Per utilizzare le risorse/API cloud, devi abilitare la fatturazione nella console Google Cloud. Ti consigliamo di arrestare le risorse utilizzate per evitare addebiti di fatturazione oltre questo codelab. I nuovi utenti di Google Cloud possono usufruire del programma di prova senza costi di 300 $.

Le risorse che comportano costi sono l'istanza BigQuery e Compute Engine. Puoi stimare il costo utilizzando il Calcolatore prezzi di BigQuery e il Calcolatore prezzi di Compute Engine.

3. Accesso a BigQuery senza limitazioni dei Controlli di servizio VPC

Esegui una query sul set di dati pubblico e salva i risultati in project-1

1. Accedi a project-2 e project-1 per verificare se riesci ad accedere all'API BigQuery visitando la pagina BigQuery Studio. Dovresti essere in grado di farlo perché, anche se project-1 si trova in un perimetro di servizio, il perimetro non protegge ancora alcun servizio.
2. Da project-2, esegui la seguente query per eseguire una query su un set di dati pubblico.

SELECT  name, SUM(number) AS total
FROM  `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY   name
ORDER BY total DESC
LIMIT 10;

Dopo aver eseguito la query sul set di dati pubblico (rimanendo in project-2):

1. Fai clic su Salva risultati e seleziona la tabella BigQuery. (fai riferimento allo screenshot riportato di seguito).
2. Seleziona project-1 come progetto di destinazione.
3. Assegna al set di dati il nome codelab_dataset. Seleziona CREA NUOVO SET DI DATI, a meno che tu non stia utilizzando un set di dati esistente.
4. Assegna alla tabella il nome codelab-table.
5. Fai clic su Salva.

I dati del set di dati pubblico sono stati archiviati correttamente in project-1 in seguito all'esecuzione della query da project-2.

Query Dataset salvata in project-1 da project-2

Mentre ti trovi in project-2 BigQuery Studio, esegui la seguente query per selezionare i dati da:

• Progetto: project-1
• Set di dati: codelab_dataset
• Tabella: codelab-table

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

La query dovrebbe essere eseguita correttamente, perché né project-2 né project-1 sono limitati all'utilizzo di BigQuery. L'accesso a BigQuery è consentito da e verso qualsiasi posizione, a condizione che l'utente disponga delle autorizzazioni IAM appropriate.

Questo diagramma illustra la procedura quando un principal esegue una query su un set di dati BigQuery. Ogni query BigQuery avvia un job BigQuery, che esegue l'operazione effettiva, in questo scenario, il recupero dei dati. L'accesso principale viene dimostrato da un'istanza Compute Engine e da internet, durante l'esecuzione di query da un set di dati pubblico e da un progetto Google Cloud separato. La procedura per eseguire query sui dati (GetData) ha esito positivo, senza essere bloccata dai Controlli di servizio VPC.

4. Proteggi l'API BigQuery nel progetto del set di dati di origine

Modifica la configurazione del perimetro perimeter-1 e limita il servizio API BigQuery insieme alla risorsa protetta project-1.

Verificare l'applicazione forzata del perimetro di servizio

Da project-2, esegui la seguente query in BigQuery Studio, come nel passaggio precedente:

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Si verificherà una violazione dei Controlli di servizio VPC RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER

L'audit log della violazione si troverà in project-1, perché è lì che si è verificata la violazione del perimetro. I log possono essere filtrati con l'vpcServiceControlsUniqueId osservato (sostituisci VPC_SC_DENIAL_UNIQUE_ID con l'ID univoco osservato).

severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"

La violazione è un egressViolations con:

• principalEmail: [account utente che esegue la query]
• callerIp: [L'indirizzo IP dello user agent che esegue la query]

     "egressViolations": [
       {
         "targetResource": "projects/project-2",
         "sourceType": "Resource",
         "source": "projects/project-1",
         "servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
         "targetResourcePermissions": [ "bigquery.jobs.create"]
       }      ],

5. Correzione della violazione per creare il job BigQuery

La violazione dei Controlli di servizio VPC ha bigquery.jobs.create come autorizzazione di destinazione a causa del funzionamento di BigQuery. Quando utilizzi la console Google Cloud (o lo strumento a riga di comando bq) per gestire i dati BigQuery, BigQuery crea job, che vengono poi utilizzati per completare le azioni desiderate. Nel frattempo, il primo evento consiste nel creare un job BigQuery.

Questo diagramma mostra quando un principal esegue una query da project-2 per un set di dati in project-1. L'operazione per creare un job BigQuery dal progetto del set di dati (project-1) nel progetto da cui viene eseguita la query (project-2) non riesce a causa di una violazione dell'uscita dei Controlli di servizio VPC dovuta al perimetro di servizio perimeter-1 che protegge l'API BigQuery. Con il perimetro in vigore, non è possibile avviare alcuna richiesta API BigQuery da project-1 verso l'esterno del perimetro o dall'esterno del perimetro verso il progetto protetto, a meno che non sia consentito dalle configurazioni del perimetro di servizio.

Una violazione dell'uscita può essere corretta creando una regola di uscita basata su:

• origine (DA): ovvero l'indirizzo email e il contesto dell'utente (ad es. indirizzo IP del chiamante, stato del dispositivo, posizione e così via)
• destinazione (TO): ovvero la risorsa, il servizio e il metodo o l'autorizzazione di destinazione.

Per correggere la violazione dell'uscita osservata, crea una regola di uscita che consenta il traffico verso targetResource (project-2) da parte dell'account utente che esegue la query ([e-mail]) sul servizio BigQuery e il metodo/ l'autorizzazione bigquery.jobs.create.

Comportamento previsto della regola di uscita configurata:

• FROM | Identities: solo l'identità specificata [e-mail] deve essere autorizzata ad attraversare il confine del perimetro.
• TO | projects: l'identità specificata può attraversare i confini del perimetro solo se la destinazione è il progetto specificato project-2.
• TO | Servizi: l'identità specificata può avviare il traffico al di fuori del perimetro, verso il progetto specificato solo se la chiamata API riguarda il servizio e il metodo specificati. Altrimenti, ad esempio se provano un altro servizio protetto dal perimetro di servizio, l'operazione verrà bloccata perché altri servizi non sono consentiti.

Testa la correzione: regola in uscita

Una volta implementata la regola di uscita, esegui la stessa query.

SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;

Si verificherà un'altra violazione, questa volta una violazione dell'ingresso NO_MATCHING_ACCESS_LEVEL. La nuova violazione è diversa dalla prima in termini di progetto di destinazione e metodo.

La correzione di una violazione dei Controlli di servizio VPC non significa che non si verificheranno altre violazioni. Una nuova chiamata API con un contesto diverso da quelli consentiti dalla policy già configurata causerà una violazione diversa.

La nuova violazione è una violazione in entrata con

• principalEmail: [account utente che esegue la query]
• callerIp: [L'indirizzo IP dello user agent che esegue la query]

ingressViolations: [
0: {
 servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
 targetResource: "projects/project-1"
 targetResourcePermissions: [0: "bigquery.tables.getData"]}
 ]

La violazione del metodo bigquery.tables.getData è dovuta a una chiamata API avviata dal job BigQuery che tenta di recuperare i dati dalla tabella BigQuery.

Per prevedere le violazioni previste, è importante capire come funziona un determinato servizio API.

6. Correzione della violazione per ottenere i dati della tabella BigQuery

Una regola in entrata corregge una violazione in entrata, fornendo al contempo un controllo granulare su chi è autorizzato a superare il confine del perimetro di servizio, nonché il contesto dell'accesso consentito, ad esempio il progetto di origine/ destinazione e il metodo API a cui può accedere.

Una violazione in entrata viene corretta da una regola in entrata configurata con:

• origine (DA): ovvero l'indirizzo email e il contesto dell'utente (ad es. indirizzo IP del chiamante, stato del dispositivo, posizione e così via)
• destinazione (TO): ovvero la risorsa, il servizio e il metodo o l'autorizzazione di destinazione.

La regola in entrata consentirà il traffico verso project-1 da parte dell'utente specificato sul servizio e sul metodo specificati.

Comportamento previsto dalla regola in entrata configurata:

• FROM | Identities: solo l'identità specificata [e-mail] deve essere autorizzata ad attraversare il confine del perimetro.
• TO | projects: l'identità specificata può attraversare i confini del perimetro solo se la destinazione è il progetto specificato project-1.
• A | Servizi: l'identità specificata può avviare il traffico all'interno del perimetro solo se la chiamata API è per l'API BigQuery e il metodo specificato bigquery.tables.getData.

L'esecuzione della stessa query dovrebbe funzionare correttamente senza violazioni dei Controlli di servizio VPC.

Abbiamo limitato correttamente l'API BigQuery in project-1 in modo che possa essere utilizzata solo da [e-mail] e non da [e-mail].

Questo diagramma illustra il modo in cui due diversi principal tentano di eseguire query sullo stesso set di dati. L'accesso da parte di [e-mail] (linee blu tratteggiate) è negato da Controlli di servizio VPC, perché non è consentito eseguire operazioni BigQuery da o verso project-1 in base alla configurazione del perimetro di servizio. L'accesso da parte di [e-mail] (linea continua verde) è riuscito, perché le configurazioni dei Controlli di servizio VPC consentono di eseguire operazioni da e verso project-1.

7. Limitare il traffico consentito dal perimetro di servizio in base all'indirizzo IP interno

La configurazione attuale consente all'utente designato di eseguire query su BigQuery in project-1 da qualsiasi posizione, ovunque su internet, se gli viene concessa l'autorizzazione IAM per eseguire query sui dati e finché utilizza il proprio account. Dal punto di vista della sicurezza, ciò implica che se l'account viene compromesso, chiunque ottenga l'accesso all'account è in grado di accedere ai dati BigQuery senza ulteriori restrizioni.

Ulteriori limitazioni possono essere implementate utilizzando il livello di accesso nelle regole in entrata e in uscita per specificare il contesto utente. Ad esempio, puoi consentire l'accesso in base all'IP di origine in combinazione con una regola in entrata configurata in precedenza che autorizza l'accesso in base all'identità del chiamante. L'accesso per IP di origine è fattibile sia per gli intervalli CIDR IP pubblici, a condizione che al client utente sia assegnato un IP pubblico, sia utilizzando un indirizzo IP interno se il client utente opera da un progetto Google Cloud.

Crea un livello di accesso con una condizione di accesso basata sull'indirizzo IP interno

Nella stessa cartella della policy di accesso con ambito, apri la pagina Gestore contesto accesso per creare un livello di accesso.

1. Nella pagina Gestore contesto accesso, seleziona CREA LIVELLO DI ACCESSO.
2. Nel riquadro Nuovo livello di accesso:
   1. Fornisci un titolo: puoi utilizzare codelab-al.
   2. Nella sezione Condizioni, fai clic su Subnet IP.
   3. Seleziona la scheda IP privato e fai clic su SELEZIONA RETI VPC.
   4. Nel riquadro Aggiungi reti VPC, puoi sfogliare e trovare la rete default o inserire manualmente il nome completo della rete nel formato //compute.googleapis.com/projects/project-2/global/networks/default.
   5. Fai clic su AGGIUNGI RETE VPC.
   6. Fai clic su SELEZIONA SUBNET IP.
   7. Seleziona la regione in cui si trova l'istanza VM. Per questo codelab, è us-central1.
   8. Fai clic su SALVA.

Abbiamo creato un livello di accesso, che non viene ancora applicato in modo forzato a nessun perimetro o policy in entrata/in uscita.

Aggiungere il livello di accesso alla regola in entrata

Per garantire che l'utente autorizzato dalla regola in entrata venga verificato anche in base al livello di accesso, è necessario configurare il livello di accesso nella regola in entrata. La regola di ingresso che autorizza l'accesso ai dati delle query si trova in perimeter-1. Modifica la regola di ingresso per definire l'origine come livello di accesso codelab-al.

Test di nuove configurazioni

Dopo l'aggiunta del livello di accesso nella regola di ingresso, la stessa query BigQuery non verrà eseguita a meno che non venga eseguita dal client nella rete VPC default per il progetto project-2. Per verificare questo comportamento, esegui la query dalla console Google Cloud mentre il dispositivo endpoint è connesso a internet. La query terminerà senza esito positivo, con l'indicazione di una violazione dell'ingresso.

Per impostazione predefinita:

• L'ambito di accesso di un'istanza di Compute Engine è impostato per impostazione predefinita su accesso predefinito, che non consente l'accesso all'API BigQuery.
• A un'istanza Compute Engine verrà associato l'account di servizio predefinito di Compute Engine. Nel frattempo, tutti i comandi eseguiti dalla VM verranno eseguiti come questo service account, che deve essere nel formato [e-mail].
  Sia l'ambito di accesso che il service account collegato alla VM possono essere modificati.

La stessa query può essere eseguita dalla rete VPC default, che si trova in project-2. Allo stesso modo, l'esecuzione della stessa query BigQuery da un'istanza Compute Engine situata in project-2 utilizzando la rete VPC default non andrà a buon fine. Questo perché la regola di ingresso è ancora configurata per consentire solo l'entità [e-mail]. Tuttavia, la VM utilizza il service account predefinito di Compute Engine.

Per eseguire correttamente lo stesso comando dall'istanza Compute Engine in project-2,assicurati che:

• La VM ha l'ambito di accesso per utilizzare l'API BigQuery. Per farlo, seleziona Consenti l'accesso completo a tutte le API di Cloud come ambito di accesso della VM.
• Il service account collegato alla VM deve disporre delle autorizzazioni IAM per:
  • Crea job BigQuery in project-2
  • Recupera i dati BigQuery dalla tabella BigQuery che si trova in project-1
• Il service account Compute Engine predefinito deve essere consentito dalla regola di ingresso e di uscita.

Ora dobbiamo aggiungere il service account Compute Engine predefinito alle regole in entrata (per consentire il recupero dei dati dalla tabella BigQuery) e alla regola in uscita (per consentire la creazione di job BigQuery).

Da un'istanza Compute Engine in project-2 sulla rete VPC default, esegui il seguente comando di query bq:

bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'

Con la configurazione attuale, il comando BigQuery avrà esito positivo solo se:

• vengono eseguiti su una VM utilizzando la rete VPC predefinita in project-2 e
• che si trova nella regione us-central1 specificata (subnet IP) e
• vengono eseguiti utilizzando l'account di servizio Compute Engine predefinito configurato nel perimetro di servizio.

La query del comando BigQuery non andrà a buon fine se eseguita da qualsiasi altra posizione, tra cui:

• se viene eseguito su una VM che utilizza la rete VPC predefinita in project-2, ma si trova in una regione diversa dalla subnet aggiunta nel livello di accesso oppure
• se eseguito dall'utente [e-mail] con un client utente su internet.

Questo diagramma illustra l'accesso avviato dallo stesso principal, [e-mail], da due località diverse: internet e un'istanza Compute Engine. L'accesso a BigQuery direttamente da internet (linee tratteggiate blu) è bloccato dai Controlli di servizio VPC, mentre l'accesso da una VM (linee continue verdi), durante la rappresentazione del service account predefinito di Compute Engine, è consentito. L'accesso consentito è dovuto al fatto che il perimetro di servizio è configurato per consentire l'accesso alle risorse protette da un indirizzo IP interno.

8. Esegui la pulizia

Sebbene non siano previsti addebiti separati per l'utilizzo dei controlli di servizio VPC quando il servizio non è in uso, è una best practice pulire la configurazione utilizzata in questo laboratorio. Puoi anche eliminare l'istanza VM e i set di dati BigQuery o i progetti Google Cloud per evitare addebiti. L'eliminazione del progetto Cloud interrompe la fatturazione per tutte le risorse utilizzate al suo interno.

• Per eliminare l'istanza VM, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina Istanze VM.
  • Seleziona la casella di controllo a sinistra del nome dell'istanza VM, quindi seleziona Elimina e fai di nuovo clic su Elimina per confermare.
• Per eliminare il perimetro di servizio, completa i seguenti passaggi:
  • Nella console Google Cloud, seleziona Sicurezza e poi Controlli di servizio VPC al livello in cui è definita l'ambito della policy di accesso, in questo caso a livello di cartella.
  • Nella pagina Controlli di servizio VPC, nella riga della tabella corrispondente al perimetro che vuoi eliminare, fai clic su Elimina.
• Per eliminare il livello di accesso, completa i seguenti passaggi:
  • Nella console Google Cloud, apri la pagina Gestore contesto accesso nell'ambito della cartella.
  • Nella griglia, individua la riga del livello di accesso che vuoi eliminare, seleziona il menu con tre puntini, quindi seleziona Elimina.
• Per chiudere i progetti, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla pagina Impostazioni di IAM e amministrazione del progetto che vuoi eliminare.
  • Nella pagina delle impostazioni IAM e amministrazione, seleziona Arresto.
  • Inserisci l'ID progetto e seleziona Chiudi comunque.

9. Complimenti!

In questo codelab hai creato un perimetro dei Controlli di servizio VPC, lo hai applicato e ne hai risolto i problemi.

Scopri di più

Puoi anche esplorare i seguenti scenari:

• Esegui la stessa query sul set di dati pubblico dopo che il progetto è protetto dai Controlli di servizio VPC.
• Aggiungi project-2 nello stesso perimetro di project-1.
• Aggiungi project-2 nel proprio perimetro e mantieni project-1 nel perimetro attuale.
• Esegui query per aggiornare i dati nella tabella, non solo per recuperarli.

Licenza

Questo lavoro è concesso in licenza ai sensi di una licenza Creative Commons Attribution 2.0 Generic.