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

Le pipeline di deployment consentono di automatizzare il processo di acquisizione del codice o artefatti e il loro deployment in un ambiente Google Cloud e possono essere un'alternativa all'utilizzo di strumenti interattivi come la console Google Cloud o Google Cloud CLI.

Le pipeline di deployment sono diverse da strumenti interattivi come la console Google Cloud o gcloud CLI nelle modalità di interazione con Identity and Access Management devi tenere in considerazione queste differenze al momento di proteggere 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 (che potrebbe includere ora e luogo)

In una pipeline di deployment, raramente chiami direttamente le API Google Cloud. Utilizza invece di accesso alle risorse Google Cloud. Strumenti come la console Google Cloud oppure gcloud CLI richiedono prima di autorizzare lo strumento ad accedere le risorse per tuo conto. Fornendo questa autorizzazione, concedi allo strumento l'autorizzazione a utilizzare la tua identità quando effettui 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, ed esegue il deployment a Google Cloud. Tuttavia, a differenza della console Google Cloud o dell'interfaccia a riga di comando gcloud, 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 a 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 ne esegue il deployment in Google Cloud.

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

   1. Il codice sorgente e i relativi metadati potrebbero non indicare che eri tu sull'autore o le informazioni sull'autore non sono a prova di manomissione (come nel caso commit Git non firmati)
   2. L'identità utilizzata per inviare il codice sorgente potrebbe essere diversa da l'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à. mediante 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 presenta alcuni vantaggi:

• Il ciclo di vita di un account di servizio è disconnesso dal ciclo di vita dell'utente . Configurando una pipeline per l'utilizzo di un account di servizio, è possibile eseguire il deployment del codice anche se l'autore del codice non è più dell'organizzazione.
• Quando gestisci le risorse utilizzando una pipeline di deployment, non devi 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'uso 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 con l'inganno a eseguire azioni che non dovrebbe eseguire, diventando di fatto un vicepresidente confuso.
• Non ripudio: dopo che una pipeline ha eseguito un'operazione, potrebbe difficile ricostruire il perché e quale sviluppatore modifica del codice da cui è 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 per utilizzare l'account di servizio

Da un punto di vista IAM, l'account di servizio rappresenta la pipeline di deployment, ma la pipeline di deployment e l'account di servizio sono due entità separate. 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 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 service account all'istanza VM sottostante. Per sistemi CI/CD che utilizzano le VM di Compute Engine per eseguire diverse pipeline di deployment, può rappresentare un problema se la stessa istanza VM può essere utilizzata per eseguire delle pipeline di deployment, ognuna delle quali richiede 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 quando è possibile

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

L'utilizzo della federazione delle identità per i carichi di lavoro 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 utente malintenzionato riesce a rubare un token di accesso o una chiave dell'account di servizio da un delle pipeline di deployment, potrebbero tentare di utilizzare questa credenziale accedono alle tue risorse da una macchina diversa che controllano.

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 sulle origini da cui Google Cloud alle risorse a cui è possibile accedere posizionando i progetti in un perimetro di servizio VPC e utilizzando le regole in entrata:

• Se la tua pipeline di deployment viene eseguita su Google Cloud, puoi configurare regola in entrata per consentire l'accesso solo dal progetto che contiene il tuo sistema CI/CD.
• Se la pipeline di deployment viene eseguita al di fuori di Google Cloud, puoi creare un livello di accesso permette l'accesso solo da località geografiche o intervalli IP specifici. Quindi crea un'istanza Regola in entrata che consente l'accesso per i client che soddisfano questo livello di accesso.

Proteggiti dalle minacce di manomissione

Alcuni dati archiviati su Google Cloud possono essere sono importanti per impedire la modifica o l'eliminazione non autorizzate. Se non autorizzata la modifica o l'eliminazione è particolarmente preoccupante, puoi caratterizzare come dati ad alta integrità.

Per mantenere l'integrità dei tuoi dati, devi assicurarti che l'account Google Cloud e risorse usate per archiviare e gestire i dati siano configurati in modo sicuro devono preservare 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 si trasforma in un punto debole che potrebbe consentire ai malintenzionati manomettere dati o 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 criteri di rifiuto
• Vincoli dei criteri dell'organizzazione
• Perimetri Controlli di servizio VPC, livelli di accesso e criteri in entrata

Questi controlli di sicurezza sono risorse a sé stanti. La manomissione dei controlli di sicurezza compromette l'integrità delle risorse a cui si applicano. Pertanto, l'integrità dei controlli di sicurezza deve essere 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, per mantenere l'integrità dei controlli di sicurezza. Di conseguenza, devi considerare l'integrità della pipeline di deployment stessa tanto importante quanto l'integrità dei controlli di sicurezza che gestisce e le risorse a cui tali controlli si applicano.

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

• Non viene concesso l'accesso alle pipeline di deployment per consentire criteri, criteri di negazione, e altri controlli di sicurezza, limitando il loro accesso ad altre risorse
• Concessione dell'accesso solo a controlli di sicurezza selezionati, ad esempio i criteri di autorizzazione e negare i criteri di una risorsa o di un progetto specifico, 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 sottostante non possono soddisfare le esigenze di integrità di determinati controlli di sicurezza, è meglio evitare e 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 saperne di più sul attività e, idealmente, essere in grado di ricostruire la catena di eventi che l'hanno portata.

Cloud Audit Logs consente di sapere quando le risorse sono state consultate o modificate. 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 dedicato 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. Ma identificare l'esecuzione esatta della pipeline e le modifiche al codice che hanno portato all'attività possono 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 per contenere 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'intestazione HTTP X-Goog-Request-Reason alle richieste API e passare l'ID dell'esecuzione della pipeline di deployment.
• Utilizza un elemento 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, registra l'ID nei log del sistema CI/CD.

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

Per analizzare le attività sospette relative a una pipeline di deployment, di solito Richiede più tipi di log, tra cui gli audit log delle attività di amministrazione, gli audit log degli accessi ai dati e i log 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 delle attività di amministrazione. Il sistema che esegue la pipeline di deployment potrebbe anche eliminare i log dopo un determinato periodo di tempo. In base alla natura della pipeline di deployment e l'importanza delle risorse di deployment, questi periodi di conservazione predefiniti potrebbero essere insufficienti o disallineati.

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 della pipeline di deployment ha accesso a dati riservati, un malintenzionato potrebbe tentare di utilizzare la pipeline di deployment per esfiltrare quei dati. L'accesso ai dati da parte 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 una risultato accidentale della concessione di un accesso eccessivo.

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

• 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. Alcuni di questi le risorse Compute potrebbero avere un account di servizio collegato che concede l'accesso ai dati riservati.

  In questa situazione, un utente malintenzionato potrebbe tentare di compromettere il deployment in modo da eseguire il deployment di codice dannoso in una delle risorse di calcolo, e lasciare che il codice esfiltra i 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 dell'infrastruttura, della configurazione o di nuove versioni del software, spesso non richiede l'accesso ai dati esistenti. Spesso è invece sufficiente limitare l'accesso alle risorse che non contengono qualsiasi dato o comunque non contenga 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 nell'intero progetto, concediamo 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 di dati il deployment delle risorse Google Cloud in un perimetro dei Controlli di servizio VPC.

Se la pipeline di deployment viene eseguita al di fuori di Google Cloud o fa parte di un perimetri diverso, puoi concedere all'account di servizio della pipeline l'accesso configurando una regola in entrata. Se possibile, configura la regola in entrata in modo che consenta l'accesso solo tramite gli indirizzi IP usati dalla pipeline di deployment e che consentono solo l'accesso di cui la pipeline di deployment ha davvero 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 inclini attacchi vicepresidenti confusi, in cui un malintenzionato induce con l'inganno la pipeline a eseguire un'azione non possono fare da sé e la pipeline potrebbe non essere dovrebbe 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 la riassegnazione 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 input e potrebbe attivarsi automaticamente non appena rileva una modifica al codice alcuni rami (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 da:

• Controllo di chi può inviare codice e configurazione al repository e ai rami usata dalla pipeline di deployment.
• Applicazione di criteri che devono essere soddisfatti prima di poter eseguire il commit delle modifiche, ad esempio revisioni del codice riuscite, analisi statiche o test automatici.

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

• Modifica della configurazione del repository di codice sorgente o della pipeline di deployment.
• Manipolazione dell'infrastruttura (ad esempio VM e archiviazione) alla base della pipeline di deployment.
• Modifica o sostituzione degli input al di fuori del 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.

Evita di consentire alla 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.

Quando possibile, evita di consentire alla pipeline di deployment di modificare l'accesso alle risorse. Quando concedi all'account di servizio della pipeline l'accesso alle risorse Google Cloud, usa ruoli che non includono autorizzazioni di *.setIamPolicy ed evita di usare 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 autorizzare 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 diagnostica

Se i log rivelano accidentalmente credenziali come i token di accesso, potrebbero essere utilizzati da malintenzionati per aumentare i loro privilegi. Metodi per impedire i log di rivelare le credenziali includono:

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

Passaggi successivi

• Scopri di più sulla Federazione delle identità per i carichi di lavoro e le best practice per l'utilizzo della federazione delle identità per i carichi di lavoro.
• 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.