Best practice per l'utilizzo degli account di servizio nelle pipeline

Le pipeline di deployment ti consentono di automatizzare il processo di acquisizione di codice o elementi predefiniti e di eseguirne il deployment in un ambiente Google Cloud. Inoltre, possono essere un'alternativa all'utilizzo di strumenti interattivi come la console Google Cloud o Google Cloud CLI.

Le pipeline di deployment sono diverse dagli strumenti interattivi come la console Google Cloud o gcloud CLI per il modo in cui interagiscono con Identity and Access Management e devi prendere in considerazione queste differenze quando proteggi le risorse Google Cloud.

Prima che Google Cloud ti consenta di accedere a una risorsa, esegue un controllo di accesso. Per eseguire questo controllo, IAM in genere prende in considerazione:

• La tua identità
• La risorsa a cui stai tentando di accedere e i relativi criteri di autorizzazione e di rifiuto IAM
• Il contesto della richiesta (eventualmente con ora e posizione)

In una pipeline di deployment, raramente chiami direttamente le API Google Cloud. Utilizza invece gli strumenti per accedere alle risorse Google Cloud. Strumenti come la console Google Cloud o l'interfaccia alla gcloud CLI richiedono di autorizzare prima lo strumento ad accedere alle risorse per tuo conto. Fornendo questa autorizzazione, autorizzi lo strumento a utilizzare la tua identità per effettuare chiamate API.

Come la console Google Cloud o gcloud CLI, una pipeline di deployment agisce per tuo conto: prende le modifiche, espresse come codice sorgente, e le esegue su Google Cloud. Tuttavia, a differenza della console Google Cloud o dell'interfaccia alla gcloud CLI, una pipeline di deployment in genere non utilizza la tua identità per eseguire il deployment:

1. In qualità di utente, in genere non interagisci direttamente con una pipeline di deployment. Interagisci invece con un sistema di controllo del codice sorgente (SCM) inviando le modifiche al codice in un repository di codice sorgente o approvando le revisioni del codice.

2. La pipeline di deployment legge le modifiche al codice inviate dal sistema SCM e le esegue su Google Cloud.

   Per eseguire il deployment, in genere la pipeline di deployment non può utilizzare la tua identità perché:

   1. Il codice sorgente e i relativi metadati potrebbero non indicare che sei stato tu l'autore o che le informazioni sull'autore non sono a prova di manomissione (come nel caso di commit Git non firmati)
   2. L'identità che hai utilizzato per inviare il codice sorgente potrebbe essere diversa dalla tua identità Google e le due identità non possono essere mappate

   La maggior parte delle pipeline di deployment esegue quindi i deployment con la propria identità utilizzando un account di servizio.

3. Quando la pipeline di deployment accede a Google Cloud, IAM consente o nega l'accesso in base all'identità dell'account di servizio utilizzato dalla pipeline, non all'identità del tuo account utente.

Consentire a una pipeline di deployment di utilizzare un account di servizio per accedere a Google Cloud offre alcuni vantaggi:

• Il ciclo di vita di un account di servizio è scollegato dal ciclo di vita degli account utente. Configurando una pipeline per l'utilizzo di un account di servizio, ti assicuri che il codice possa essere dispiegato anche se l'autore del codice non fa più parte della tua organizzazione.
• Quando gestisci le risorse utilizzando una pipeline di deployment, non è necessario concedere agli utenti alcun accesso alle risorse oppure puoi limitare le autorizzazioni all'accesso di sola lettura. Questo approccio può semplificare la gestione dei criteri IAM e ti consente di forzare gli utenti a utilizzare la pipeline di deployment per eseguire tutte le modifiche.

Tuttavia, l'utilizzo di un account di servizio introduce anche nuove minacce. Queste includono:

• Spoofing:un malintenzionato potrebbe tentare di rubare l'identità della pipeline di deployment o di rubare le sue credenziali per ottenere l'accesso alle risorse.
• Escalation dei privilegi: la pipeline potrebbe essere indotta a eseguire azioni che non dovrebbe eseguire, diventando di fatto un procuratore confuso.
• Non ripudio: dopo che una pipeline ha eseguito un'operazione, potrebbe essere difficile ricostruire perché è stata eseguita e da quale sviluppatore o modifica del codice è stata attivata.
• Manipolazioni: una pipeline potrebbe essere utilizzata in modo improprio per minare l'integrità o i controlli di sicurezza dei tuoi ambienti cloud.
• Divulgazione di informazioni:gli utenti malintenzionati potrebbero tentare di utilizzare la pipeline di deployment per esfiltrare dati riservati.

Proteggiti dalle minacce di spoofing

Per concedere a una pipeline di deployment l'accesso a Google Cloud, in genere svolgi quanto segue:

1. Crea un account di servizio
2. Concedi all'account di servizio l'accesso alle risorse richieste
3. Configura la pipeline di deployment in modo che utilizzi l'account di servizio

Dal punto di vista di IAM, l'account di servizio rappresenta la pipeline di deployment, ma la pipeline di deployment e l'account di servizio sono due entità distinte. Se non è protetto correttamente, un malintenzionato potrebbe essere in grado di utilizzare lo stesso account di servizio, in modo da "falsificare" l'identità della pipeline di deployment.

La sezione seguente descrive le best practice che possono aiutarti a ridurre il rischio di queste minacce.

Evita di collegare gli account di servizio alle istanze VM utilizzate dai sistemi CI/CD

Per le applicazioni di cui è stato eseguito il deployment su Compute Engine e che richiedono l'accesso alle risorse di Google Cloud, in genere è meglio collegare un account di servizio all'istanza VM sottostante. Per i sistemi CI/CD che utilizzano le VM Compute Engine per eseguire pipeline di deployment diverse, questa pratica può essere problematica se la stessa istanza VM potrebbe essere utilizzata per eseguire pipeline di deployment diverse che richiedono ciascuna l'accesso a risorse diverse.

Anziché utilizzare account di servizio collegati per consentire alle pipeline di deployment di accedere alle risorse, consenti a ogni pipeline di deployment di utilizzare un account di servizio separato. Evita di collegare un account di servizio alle istanze VM utilizzate dai sistemi CI/CD oppure collega un account di servizio limitato all'accesso solo a servizi essenziali come Cloud Logging.

Utilizza account di servizio dedicati per ogni pipeline di deployment

Quando consenti a più pipeline di deployment di utilizzare lo stesso account di servizio, IAM non può distinguere tra le pipeline: le pipeline hanno accesso alle stesse risorse e i log di controllo potrebbero non contenere informazioni sufficienti per determinare quale pipeline di deployment ha attivato l'accesso o la modifica di una risorsa.

Per evitare questa ambiguità, mantieni una relazione 1:1 tra le pipeline di deployment e gli account di servizio. Crea un account di servizio dedicato per ogni pipeline di deployment e assicurati di:

• Incorpora il nome o l'ID della pipeline di deployment nell'indirizzo email dell'account di servizio. Seguire uno schema di denominazione coerente ti aiuta a determinare la pipeline di deployment dal nome dell'account di servizio e viceversa.
• Concedi all'account di servizio l'accesso solo alle risorse necessarie per la pipeline di deployment specifica.

Utilizza la federazione delle identità per i carichi di lavoro, se possibile

Alcuni sistemi CI/CD come GitHub Actions o GitLab consentono alle pipeline di deployment di ottenere token conformi a OpenID Connect che verificano l'identità della pipeline di deployment. Puoi consentire alle pipeline di deployment di utilizzare questi token per simulare l'identità di un account di servizio utilizzando la federazione delle identità per i carichi di lavoro.

L'utilizzo della federazione di Workload Identity ti aiuta a evitare i rischi associati all'utilizzo delle chiavi degli account di servizio.

Utilizzare i Controlli di servizio VPC per ridurre l'impatto delle credenziali trapelate

Se un malintenzionato riesce a rubare un token di accesso o una chiave dell'account di servizio da una delle tue pipeline di deployment, potrebbe tentare di utilizzare questa credenziale e accedere alle tue risorse da un'altra macchina sotto il suo controllo.

Per impostazione predefinita, IAM non prende in considerazione la geolocalizzazione, l'indirizzo IP di origine o il progetto Google Cloud di origine quando prende decisioni di accesso. Pertanto, una credenziale rubata potrebbe essere utilizzabile da qualsiasi luogo.

Puoi imporre limitazioni alle origini da cui è possibile accedere alle risorse Google Cloud inserendo i progetti in un perimetro di servizio VPC e utilizzando le regole di ingresso:

• Se la pipeline di deployment viene eseguita su Google Cloud, puoi configurare una regola di ingresso per consentire l'accesso solo dal progetto che contiene il sistema CI/CD.
• Se la pipeline di deployment viene eseguita al di fuori di Google Cloud, puoi creare un livello di accesso che consenta l'accesso solo da determinate località geografiche o intervalli di indirizzi IP. Quindi crea una regola di ingresso che consenta l'accesso ai client che soddisfano questo livello di accesso.

Proteggere il dispositivo dalle minacce di manomissione

Per alcuni dati archiviati su Google Cloud, potresti ritenere particolarmente importante impedire la modifica o l'eliminazione non autorizzata. Se la modifica o l'eliminazione non autorizzata è di particolare preoccupazione, puoi caratterizzare i dati come ad alta integrità.

Per mantenere l'integrità dei dati, devi assicurarti che le risorse Google Cloud impiegate per archiviare e gestire i dati siano configurate in modo sicuro e che mantengano la loro integrità.

Le pipeline di deployment possono aiutarti a mantenere l'integrità dei tuoi dati e delle tue risorse, ma possono anche rappresentare un rischio: se la pipeline di uno dei suoi componenti non soddisfa i requisiti di integrità delle risorse che gestisce, la pipeline di deployment diventa un punto debole che potrebbe consentire a malintenzionati di manomettere i tuoi dati o le tue risorse.

La sezione seguente descrive le best practice che possono aiutarti a ridurre il rischio di minacce di manomissione.

Limita l'accesso ai controlli di sicurezza

Per garantire la sicurezza e l'integrità dei tuoi dati e delle tue risorse su Google Cloud, utilizzi controlli di sicurezza come:

• Criteri di autorizzazione e di negazione
• Vincoli dei criteri dell'organizzazione
• Perimetri, livelli di accesso e criteri in entrata dei Controlli di servizio VPC

Questi controlli di sicurezza sono risorse a sé stanti. La manomissione dei controlli di sicurezza compromette l'integrità delle risorse a cui si applicano. Di conseguenza, devi considerare l'integrità dei controlli di sicurezza almeno tanto importante quanto l'integrità delle risorse a cui si applicano.

Se consenti a una pipeline di deployment di gestire i controlli di sicurezza, è compito della stessa mantenere l'integrità dei controlli di sicurezza. Di conseguenza, devi considerare l'integrità della pipeline di deployment stessa almeno quanto l'integrità dei controlli di sicurezza che gestisce e le risorse a cui si applicano questi controlli.

Puoi limitare l'impatto di una pipeline di deployment sull'integrità delle risorse:

• Non concedere alle pipeline di deployment l'accesso a criteri di autorizzazione, criteri di negazione e altri controlli di sicurezza e limitare il loro accesso ad altre risorse
• Concedere l'accesso solo a controlli di sicurezza selezionati, ad esempio i criteri di autorizzazione e di rifiuto di una risorsa o un progetto specifici, senza concedere l'accesso a controlli più ampi che interessano più risorse o progetti

Se la pipeline di deployment, i relativi componenti e l'infrastruttura di base non sono in grado di soddisfare le esigenze di integrità di determinati controlli di sicurezza, è meglio evitare di consentire alle pipeline di deployment di gestire questi controlli di sicurezza.

Proteggiti dalle minacce di non ripudio

A un certo punto potresti notare attività sospette che interessano una delle tue risorse su Google Cloud. In questo caso, devi essere in grado di scoprire di più sull'attività e, idealmente, di ricostruire la catena di eventi che l'ha generata.

Cloud Audit Logs ti consente di scoprire quando è stato eseguito l'accesso alle risorse o quando sono state modificate e quali utenti sono stati coinvolti. Sebbene Cloud Audit Logs fornisca un punto di partenza per analizzare le attività sospette, le informazioni fornite da questi log potrebbero non essere sufficienti: se utilizzi pipeline di deployment, devi anche essere in grado di correlare Cloud Audit Logs con i log prodotti dalla pipeline di deployment.

Questa sezione contiene le best practice che possono aiutarti a mantenere un audit trail in Google Cloud e nelle pipeline di deployment.

Assicurati di poter correlare i log della pipeline di deployment con Cloud Audit Logs

Cloud Audit Logs contengono timestamp e informazioni sull'utente che ha avviato un'attività. Se utilizzi un service account di servizio per ogni pipeline di deployment, queste informazioni ti consentono di identificare la pipeline di deployment che ha avviato l'attività e potrebbero anche aiutarti a restringere le modifiche al codice e le esecuzioni della pipeline che potrebbero essere state responsabili. Tuttavia, identificare l'esecuzione esatta della pipeline e la modifica del codice che ha generato l'attività può essere difficile senza ulteriori informazioni che ti consentano di correlare Cloud Audit Logs con i log della pipeline di deployment.

Puoi arricchire Cloud Audit Logs in modo che contengano più informazioni in diversi modi, tra cui:

• Quando utilizzi Terraform, specifica un motivo della richiesta che indichi l'esecuzione della pipeline CI/CD.
• Aggiungi un'X-Goog-Request-Reason intestazione HTTP alle richieste API e passa l'ID dell'esecuzione della pipeline di deployment.
• Utilizza un User-Agent personalizzato che incorpora l'ID dell'esecuzione della pipeline di deployment.

Puoi anche arricchire i log emessi dalla pipeline di deployment:

• Registra le richieste API eseguite da ogni esecuzione della pipeline CI/CD.
• Ogni volta che l'API restituisce un ID operazione, registralo nei log del sistema CI/CD.

Allinea i periodi di conservazione dei log della pipeline di deployment e di Cloud Audit Logs

Per analizzare attività sospette relative a una pipeline di deployment, in genere sono necessari più tipi di log, tra cui audit log dell'attività di amministrazione, audit log di accesso ai dati e i log della pipeline di deployment.

Cloud Logging conserva i log solo per un determinato periodo di tempo. Per impostazione predefinita, questo periodo di conservazione è più breve per gli audit log di accesso ai dati rispetto agli audit log Attività di amministrazione. Il sistema che esegue la pipeline di deployment potrebbe anche eliminare i log dopo un determinato periodo di tempo. A seconda della natura della pipeline di deployment e dell'importanza delle risorse gestite dalla pipeline, questi periodi di conservazione predefiniti potrebbero non essere sufficienti o non essere allineati.

Per assicurarti che i log siano disponibili quando ti servono, assicurati che i periodi di conservazione dei log utilizzati dai diversi sistemi siano allineati e sufficientemente lunghi.

Se necessario, personalizza il periodo di conservazione per gli audit log di accesso ai dati o configura un destinatario personalizzato per inoltrare i log a una posizione di archiviazione personalizzata.

Proteggere dalle minacce di divulgazione di informazioni

Quando l'account di servizio di una pipeline di deployment ha accesso a dati riservati, un malintenzionato potrebbe tentare di utilizzare la pipeline di deployment per esfiltrare questi dati. L'accesso ai dati di una pipeline di deployment può essere diretto o indiretto:

• Diretto: l'account di servizio della pipeline di deployment potrebbe avere l'autorizzazione per leggere dati riservati da Cloud Storage, BigQuery o altre posizioni. Questo accesso potrebbe essere stato concesso intenzionalmente, ma potrebbe anche essere un risultato accidentale della concessione di un accesso eccessivo.

  Se un malintenzionato ottiene l'accesso a una pipeline di deployment con accesso diretto ai dati riservati, potrebbe provare a utilizzare il token di accesso dell'account di servizio per accedere ai dati ed estrarli.

• Indiretta: per eseguire il deployment della configurazione o di nuove versioni software, l'account di servizio di una pipeline di deployment potrebbe avere l'autorizzazione per creare o eseguire nuovamente il deployment di istanze VM, applicazioni Cloud Run o altre risorse di calcolo. Alcune di queste risorse di calcolo potrebbero avere un account di servizio collegato che concede l'accesso ai dati riservati.

  In questa situazione, un malintenzionato potrebbe tentare di compromettere la pipeline di deployment in modo da eseguire il deployment di codice dannoso in una delle risorse di calcolo e consentire a questo codice di esfiltrare dati riservati.

Questa sezione contiene best practice che possono aiutarti a limitare il rischio di divulgazione di dati riservati.

Evita di concedere l'accesso diretto ai dati riservati

Per eseguire il deployment di infrastrutture, configurazioni o nuove versioni software, spesso una pipeline di deployment non richiede l'accesso ai dati esistenti. Spesso è sufficiente limitare l'accesso alle risorse che non contengono dati o almeno non contengono dati riservati.

Ecco alcuni modi per ridurre al minimo l'accesso ai dati esistenti potenzialmente riservati:

• Anziché concedere all'account di servizio di una pipeline di deployment l'accesso a un intero progetto, concedi l'accesso solo a risorse specifiche.
• Concedi l'accesso in scrittura senza consentire l'accesso in lettura. Ad esempio, concedendo il ruolo Creatore oggetti Storage (roles/storage.objectCreator), puoi consentire a un account di servizio di caricare nuovi oggetti in un bucket Cloud Storage senza concedere l'autorizzazione a leggere i dati esistenti.
• Limita l'infrastruttura come codice (IaC) alle risorse meno riservate, ad esempio utilizza l'IaC per gestire reti o istanze VM, ma non per gestire set di dati BigQuery riservati.

Utilizza i Controlli di servizio VPC per contribuire a impedire l'esfiltrazione di dati

Puoi ridurre il rischio di esfiltrazione indiretta dei dati implementando le risorse Google Cloud in un perimetro di Controlli di servizio VPC.

Se la pipeline di deployment viene eseguita all'esterno di Google Cloud o fa parte di un perimetro diverso, puoi concedere all'account di servizio della pipeline l'accesso al perimetro configurando una regola di ingresso. Se possibile, configura la regola di ingresso in modo che consenta l'accesso solo dagli indirizzi IP utilizzati dalla pipeline di deployment e solo ai servizi di cui la pipeline di deployment ha effettivamente bisogno.

Proteggiti dalle minacce di escalation dei privilegi

Quando una pipeline di deployment utilizza un account di servizio per accedere alle risorse Google Cloud, lo fa indipendentemente dallo sviluppatore o dall'utente che ha creato una modifica di codice o di configurazione. La disconnessione tra l'account di servizio della pipeline e l'identità dello sviluppatore rende le pipeline di deployment vulnerabili agli attacchi di agente confuso, in cui un utente malintenzionato ingannevolmente fa eseguire alla pipeline un'azione che non è autorizzato a eseguire e che la pipeline potrebbe anche non essere prevista per eseguire.

Questa sezione contiene le best practice che possono aiutarti a ridurre il rischio che la pipeline di deployment venga utilizzata in modo improprio per escalation dei privilegi.

Limita l'accesso alla pipeline di deployment e a tutti gli input

La maggior parte delle pipeline di deployment utilizza un repository di codice sorgente come fonte principale di input e potrebbe attivarsi automaticamente non appena rileva una modifica del codice in determinati branch (ad esempio il ramo main). In genere, le pipeline di deployment non possono verificare se il codice e la configurazione trovati nel repository del codice sorgente sono autentici e attendibili. La sicurezza di questa architettura dipende quindi da:

• Controllo di chi può inviare codice e configurazione al repository e ai branch utilizzati dalla pipeline di deployment.
• Applicazione di criteri che devono essere soddisfatti prima che le modifiche possano essere committate, ad esempio revisioni del codice, analisi statica o test automatici.

Affinché questi controlli siano efficaci, devi anche assicurarti che i malintenzionati non possano aggirarli:

• Modifica della configurazione del repository del codice sorgente o della pipeline di deployment.
• Manipolazione dell'infrastruttura (ad esempio VM e archiviazione) alla base della pipeline di deployment.
• Modifica o sostituzione di input esterni al repository del codice sorgente, ad esempio pacchetti, immagini container o librerie.

Se gestite da una pipeline di deployment, le risorse su Google Cloud possono essere sicure solo quanto la pipeline di deployment, la relativa configurazione, l'infrastruttura e gli input. Pertanto, devi proteggere questi componenti così come vuoi che vengano protette le tue risorse Google Cloud.

Evitare di consentire a una pipeline di deployment di modificare i criteri

Per la maggior parte dei tipi di risorse, IAM definisce un'autorizzazioneRESOURCE_TYPE.setIamPolicy. Questa autorizzazione consente a un utente di modificare il criterio di autorizzazione IAM di una risorsa per concedere l'accesso ad altri utenti o per modificare ed estendere il proprio accesso. A meno che non sia vincolato da un criterio di rifiuto, la concessione di un'autorizzazione *.setIamPolicy a un account utente o di servizio ha l'effetto di concedere l'accesso completo alla risorsa.

Se possibile, evita di consentire a una pipeline di deployment di modificare l'accesso alle risorse. Quando concedi all'account di servizio della pipeline l'accesso alle risorse Google Cloud, utilizza ruoli che non includono autorizzazioni *.setIamPolicy ed evita di utilizzare i ruoli di base Editor e Proprietario.

Per alcune pipeline di deployment, la concessione dell'autorizzazione per modificare i criteri di autorizzazione o di divieto potrebbe essere inevitabile: ad esempio, lo scopo di una pipeline di deployment potrebbe essere creare nuove risorse o gestire l'accesso alle risorse esistenti. In questi scenari, puoi comunque limitare la misura in cui il deployment può modificare l'accesso:

• Concedi l'autorizzazione *.setIamPolicy solo per risorse specifiche e non per l'intero progetto.
• Utilizzo dei criteri di negazione IAM per limitare l'insieme di autorizzazioni che possono essere concesse o per limitare le entità a cui possono essere concesse.
• Utilizzo delle condizioni IAM per limitare i ruoli che la pipeline può concedere e consentire solo i ruoli che non includono le autorizzazioni *.setIamPolicy.

Non rivelare le credenziali dell'account di servizio nei log

I log generati da una pipeline di deployment sono spesso accessibili a un gruppo più grande di utenti, inclusi quelli che non dispongono dell'autorizzazione per modificare la configurazione della pipeline. È possibile che questi log rivelino accidentalmente le credenziali tramite l'eco:

• Contenuti delle variabili di ambiente
• Argomenti della riga di comando
• Output della diagnostica

Se i log rivelano accidentalmente credenziali come i token di accesso, queste credenziali potrebbero essere usate in modo improprio da utenti malintenzionati per eseguire la riassegnazione dei privilegi. Ecco alcuni modi per impedire ai log di rivelare le credenziali:

• Evita di passare token di accesso o altre credenziali come argomenti della riga di comando
• Evita di memorizzare le credenziali nelle variabili di ambiente
• Se possibile, configura il sistema CI/CD in modo da rilevare e mascherare automaticamente i token e altre credenziali

Passaggi successivi

• Scopri di più sulla federazione di Workload Identity e sulle best practice per l'utilizzo della federazione di Workload Identity.
• Consulta il nostro blueprint per le basi aziendali e le indicazioni su autenticazione e autorizzazione.
• Scopri di più sulle best practice per l'utilizzo degli account di servizio.