Controlli di servizio VPC - Codelab sulla protezione di BigQuery I

1. Introduzione

In questo codelab imparerai a proteggere l'API BigQuery utilizzando Controlli di servizio VPC. Il codelab non prevede 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 di progetto. La query viene eseguita in un progetto e la tabella (in cui vengono salvati i risultati) viene creata in un altro progetto, imitando una configurazione in cui i dati possono essere archiviati in un progetto ma devono essere accessibili utilizzando un progetto diverso.

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

• Scoprire come correggere le violazioni del traffico in entrata e in uscita utilizzando rispettivamente le regole in entrata e in uscita.
• Scopri perché si è verificata 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à:

• 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 un criterio di accesso con ambito
• Come creare e configurare un perimetro di servizio
• Come trovare le violazioni dei criteri di sicurezza nei log

Configurazione

La nostra configurazione iniziale è strutturata nel seguente modo:

Se hai completato il tutorial di base sui controlli di servizio VPC, puoi riutilizzare gli stessi progetti, cartelle e perimetro di servizio.

• Un'organizzazione Google Cloud.
• Una cartella all'interno dell'organizzazione. In questo codelab lo chiameremo codelab-folder.
• Due progetti Google Cloud posizionati nella stessa cartella, codelab-folder. Per questo codelab, li chiamiamo project-1 e project-2
  • Se la cartella e i progetti non sono già stati creati, nella console Google Cloud crea una cartella nell'organizzazione e crea due nuovi progetti nella cartella creata.
• Le autorizzazioni richieste:
  • 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 delle istanze Compute Engine: assegnati a livello di progetto
• 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 Autore 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). e avrai i ruoli necessari per configurare le risorse necessarie per l'intero codelab.

Crea un perimetro di servizio regolare

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

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

Nel perimetro, non limitare ancora nessun 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 utilizzeremo la rete VPC predefinita denominata default.

• Puoi consultare la 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é la rete abbia almeno una subnet.

Costo

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

Le risorse che comportano costi sono BigQuery e istanze 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 query su 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, quest'ultimo non protegge ancora alcun servizio.
2. Da project-2, esegui questa 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 (rimane in project-2):

1. Fai clic su Salva risultati e seleziona la tabella BigQuery. (fai riferimento allo screenshot 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 non utilizzi 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 in project-1 a seguito dell'esecuzione della query da project-2.

Set di dati di query salvato in project-1 da project-2

Mentre rimani in project-2 BigQuery Studio, esegui questa query per selezionare i dati:

• 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 luogo, purché l'utente disponga delle autorizzazioni IAM appropriate.

Questo diagramma illustra il processo quando un'entità esegue query su un set di dati BigQuery. Ogni query BigQuery avvia un job BigQuery, che quindi esegue l'operazione effettiva, in questo scenario, il recupero dei dati. L'accesso dell'entità 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 avuto esito positivo e non è 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 in modo che la risorsa protetta sia project-1.

Verifica l'applicazione del perimetro di servizio

Da project-2, esegui questa 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 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER dei Controlli di servizio VPC

Il log di controllo delle violazioni verrà posizionato in project-1, perché è qui che si è verificata la violazione per attraversare il perimetro. I log possono essere filtrati con l'oggetto 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 è una 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 la creazione di un 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 è la creazione di un job BigQuery.

Questo diagramma mostra quando un'entità 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 del traffico in uscita dei Controlli di servizio VPC a causa del perimetro di servizio perimeter-1 che protegge l'API BigQuery. Quando il perimetro è attivo, nessuna richiesta API BigQuery può essere avviata da project-1 verso l'esterno del perimetro o avviata all'esterno del perimetro, verso il progetto protetto. salvo nei casi consentiti dalle configurazioni del perimetro di servizio.

Una violazione in uscita può essere risolta creando una regola in uscita basata su:

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

Per correggere la violazione in uscita osservata, crea una regola in uscita che consenta il traffico verso la risorsa target (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 dalla regola in uscita configurata:

• FROM | Identità: solo l'identità specificata [e-mail] deve essere autorizzata a attraversare il confine del perimetro.
• A | Progetti: l'identità specificata può oltrepassare i confini del perimetro solo se la destinazione è il progetto specificato project-2.
• A | Servizi: l'identità specificata può avviare traffico all'esterno del perimetro, verso il progetto specificato solo se la chiamata API riguarda il servizio e il metodo specificati. In caso contrario, ad esempio se provano a usare un altro servizio protetto dal perimetro di servizio, l'operazione verrà bloccata perché non sono consentiti altri servizi.

Testa la correzione: regola in uscita

Dopo aver applicato la regola in 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 del traffico in entrata di tipo NO_MATCHING_ACCESS_LEVEL. La nuova violazione è diversa dalla prima in termini di progetto e metodo di destinazione.

La correzione di una violazione dei Controlli di servizio VPC non implica che non si verifichino altre violazioni. Una nuova chiamata API con un contesto diverso da quello consentito dal criterio già configurato causerà una violazione diversa.

La nuova violazione è una violazione del traffico 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 per il metodo bigquery.tables.getData è dovuta a una chiamata API avviata dal job BigQuery che tenta di ottenere dati dalla tabella BigQuery.

È importante capire come funziona un determinato servizio API per prevedere le violazioni previste.

6. Correzione della violazione per ottenere i dati delle tabelle BigQuery

Una regola in entrata corregge una violazione del traffico in entrata, fornendo al contempo un controllo granulare su chi è autorizzato ad attraversare il confine del perimetro di servizio insieme al contesto dell'accesso consentito, come il progetto di origine/ destinazione e il metodo API a cui possono accedere.

Una violazione del traffico in entrata viene risolta da una regola in entrata configurata con:

• source (FROM): ovvero l'indirizzo email e il contesto dell'utente (ad es.indirizzo IP del chiamante, stato del dispositivo, posizione e così via).
• destinazione (TO): la risorsa, il servizio, 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 | Identità: solo l'identità specificata [e-mail] deve essere autorizzata a attraversare il confine del perimetro.
• A | Progetti: l'identità specificata può oltrepassare i confini del perimetro solo se la destinazione è il progetto specificato project-1.
• A | Servizi: l'identità specificata può avviare traffico all'interno del perimetro solo se la chiamata API riguarda l'API BigQuery e il metodo specificato bigquery.tables.getData.

D'ora in poi l'esecuzione di una query identica dovrebbe funzionare correttamente senza violazioni dei Controlli di servizio VPC.

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

Questo diagramma mostra come due entità diverse tentano di eseguire query sullo stesso set di dati. L'accesso tramite [e-mail] (linee blu tratteggiate) è negato dai Controlli di servizio VPC perché la configurazione del perimetro di servizio non consente loro di eseguire operazioni BigQuery da o verso project-1. L'accesso tramite [e-mail] (linea continua verde) è riuscito, perché le configurazioni dei Controlli di servizio VPC possono eseguire operazioni da e verso project-1.

7. Limita 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 località; da qualsiasi luogo su internet, se agli utenti viene concessa l'autorizzazione IAM per eseguire query sui dati, purché utilizzino il proprio account. Dal punto di vista della sicurezza, ciò implica che se l'account viene compromesso, qualsiasi individuo che vi abbia accesso è in grado di accedere ai dati BigQuery senza alcuna limitazione aggiuntiva.

È possibile implementare ulteriori restrizioni utilizzando il livello di accesso nelle regole in entrata e in uscita per specificare il contesto dell'utente. Ad esempio, puoi consentire l'accesso basato sull'IP di origine insieme a una regola in entrata configurata in precedenza che autorizza l'accesso in base all'identità del chiamante. L'accesso tramite IP di origine è fattibile per entrambi gli intervalli CIDR IP pubblici, a condizione che al client utente sia assegnato un IP pubblico, o mediante l'utilizzo di un indirizzo IP interno se il client utente opera da un progetto Google Cloud.

Crea livello di accesso con una condizione di accesso all'indirizzo IP interno

Nella stessa cartella dei criteri 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. Specifica un titolo: puoi usare 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. Dal 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 è ancora applicato a nessun criterio perimetrale o in entrata/in uscita.

Aggiungi livello di accesso alla regola in entrata

Per fare in modo che l'utente consentito 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 in entrata che autorizza l'accesso ai dati delle query è nel campo perimeter-1. Modifica la regola in entrata per definire l'origine come livello di accesso codelab-al.

Test di nuove configurazioni

Dopo l'aggiunta del livello di accesso nella regola in entrata, la stessa query BigQuery avrà esito negativo 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 verrà chiusa senza successo, accompagnati da un'indicazione di una violazione del traffico in entrata.

Per impostazione predefinita:

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

La stessa query può essere eseguita dalla rete VPC default, situata in project-2. Allo stesso modo, anche l'esecuzione della stessa query BigQuery da un'istanza Compute Engine situata in project-2 utilizzando la rete VPC default avrà esito negativo. Questo perché la regola in entrata è ancora configurata per consentire solo l'entità [e-mail]. Tuttavia, la VM utilizza l'account di servizio predefinito di Compute Engine.

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

• La VM ha un ambito di accesso per utilizzare l'API BigQuery. Per farlo, seleziona Consenti l'accesso completo a tutte le API Cloud come ambito di accesso alla VM.
• L'account di servizio collegato alla VM richiede le autorizzazioni IAM per:
  • Crea job BigQuery in project-2
  • Ottieni i dati BigQuery dalla tabella BigQuery situata in project-1
• L'account di servizio Compute Engine predefinito deve essere consentito dalla regola in entrata e in uscita.

Ora dobbiamo aggiungere l'account di servizio predefinito di Compute Engine nelle regole in entrata (per consentire il recupero di dati dalla tabella BigQuery) e nella regola in uscita (per consentire la creazione di job BigQuery).

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

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
• che si trova nella regione us-central1 specificata (subnet IP)
• utilizzando l'account di servizio Compute Engine predefinito configurato nel perimetro di servizio.

La query del comando BigQuery avrà esito negativo se eseguita da qualsiasi altra origine, ad esempio:

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

Questo diagramma mostra l'accesso avviato dalla stessa entità, [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 è consentito l'accesso da una VM (linee continue verdi) durante l'identità dell'account di servizio predefinito di Compute Engine. L'accesso consentito è dovuto alla configurazione del perimetro di servizio per consentire l'accesso alle risorse protette da un indirizzo IP interno.

8. Esegui la pulizia

Anche se non è previsto alcun addebito separato per l'utilizzo di Controlli di servizio VPC quando il servizio non è in uso, è consigliabile eseguire la pulizia della configurazione utilizzata in questo lab. Per evitare addebiti, puoi anche eliminare l'istanza VM e i set di dati BigQuery o i progetti Google Cloud. L'eliminazione del progetto Cloud interrompe la fatturazione per tutte le risorse utilizzate all'interno del progetto.

• 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, quindi fai di nuovo clic su Elimina per confermare.
• Per eliminare il perimetro di servizio, completa i seguenti passaggi:
  • Nella console Google Cloud, seleziona Sicurezza, quindi Controlli di servizio VPC al livello in cui si trova l'ambito del criterio di accesso, in questo caso a livello di cartella.
  • Nella pagina Controlli di servizio VPC, nella riga della tabella corrispondente al perimetro da 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 Cartella.
  • Nella griglia, identifica la riga relativa al livello di accesso che vuoi eliminare, seleziona il menu con tre puntini e poi Elimina.
• Per arrestare i progetti, completa i seguenti passaggi:
  • Nella console Google Cloud, vai alla sezione IAM e Impostazioni amministratore del progetto che vuoi eliminare.
  • Nella piattaforma IAM e pagina Impostazioni amministratore, seleziona Arresto.
  • Inserisci l'ID progetto e seleziona Arresta comunque.

9. Complimenti!

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

Scopri di più

Puoi anche esplorare i seguenti scenari:

• Esegui la stessa query su un 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 delle query per aggiornare i dati della tabella, non solo per recuperarli.

Licenza

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