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

Le pipeline di deployment consentono di automatizzare il processo di acquisizione di codice o artefatti predefiniti e di eseguirne il deployment in un ambiente Cloud de Confiance by S3NS . Possono essere un'alternativa all'utilizzo di strumenti interattivi come la console Cloud de Confiance o Google Cloud CLI.

Le pipeline di deployment differiscono dagli strumenti interattivi come la console Cloud de Confiance o gcloud CLI nel modo in cui interagiscono con Identity and Access Management e devi tenere conto di queste differenze quando proteggi le tue risorse Cloud de Confiance.

Prima di consentire l'accesso a una risorsa, Cloud de Confiance esegue un controllo dell'accesso. Per eseguire questo controllo, IAM in genere considera:

• La tua identità e le eventuali policy sul confine di accesso dell'entità associate
• La risorsa a cui stai tentando di accedere e i relativi criteri di autorizzazione e di negazione IAM
• Il contesto della tua richiesta (che potrebbe includere ora e posizione)

In una pipeline di deployment, raramente chiami direttamente le API Cloud de Confiance . Utilizzi invece strumenti per accedere alle risorse Cloud de Confiance . Strumenti come la Cloud de Confiance console o gcloud CLI richiedono di autorizzare prima lo strumento ad accedere alle risorse per tuo conto. Fornendo questa autorizzazione, concedi allo strumento l'autorizzazione a utilizzare la tua identità quando effettua chiamate API.

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

1. In genere, in qualità di utente non interagisci direttamente con una pipeline di deployment. Interagisci invece con un sistema di controllo del codice sorgente (SCM) eseguendo il push delle 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 il deployment su Cloud de Confiance.

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

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

   Pertanto, la maggior parte delle pipeline di deployment esegue i deployment con la propria identità utilizzando unaccount di serviziot.

3. Quando la pipeline di deployment accede a Cloud de Confiance, IAM consente o nega l'accesso esclusivamente in base all'identità delaccount di serviziot 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 Cloud de Confiance presenta alcuni vantaggi:

• Il ciclo di vita di un account di servizio è indipendente da quello degli account utente. Se configuri una pipeline in modo che utilizzi un account di servizio, ti assicuri che il codice possa essere implementato anche se l'autore non fa più parte della tua 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 in sola lettura. Questo approccio può semplificare la gestione delle norme di autorizzazione e negazione IAM e 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. tra cui:

• Spoofing:un malintenzionato potrebbe tentare di falsificare l'identità della pipeline di deployment o rubarne le 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 confused deputy.
• Non ripudio:dopo che una pipeline ha eseguito un'operazione, potrebbe diventare difficile ricostruire perché è stata eseguita e da quale sviluppatore o modifica del codice è stata attivata.
• Manomissione:una pipeline potrebbe essere utilizzata in modo improprio per compromettere l'integrità o i controlli di sicurezza dei tuoi ambienti cloud.
• Divulgazione di informazioni:i malintenzionati potrebbero tentare di utilizzare la pipeline di deployment per estrarre dati riservati.

Proteggiti dalle minacce di spoofing

Per concedere a una pipeline di deployment l'accesso a Cloud de Confiance, in genere devi:

1. Crea un account di servizio
2. Concedi al account di servizio l'accesso alle risorse richieste
3. Configura la pipeline di deployment per utilizzare il account di servizio

Dal punto di vista di IAM, il account di servizio rappresenta la pipeline di deployment, ma la pipeline di deployment e ilaccount di serviziot sono due entità separate. Se non è protetto correttamente, un malintenzionato potrebbe essere in grado di utilizzare lo stesso account di servizio, che gli consente di "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 service account a istanze VM utilizzate dai sistemi CI/CD

Per le applicazioni di cui è stato eseguito il deployment su Compute Engine che devono accedere alle risorse Cloud de Confiance, in genere è consigliabile 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 può essere utilizzata per eseguire pipeline di deployment diverse che richiedono l'accesso a risorse diverse.

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

Utilizza service account dedicati per 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 i service account. 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 del account di servizio. Seguire uno schema di denominazione coerente ti aiuta a determinare quali service account sono connessi a quali pipeline di deployment.
• Concedi al account di servizio l'accesso solo alle risorse necessarie alla pipeline di deployment specifica.

Utilizza la federazione delle identità per i workload, se possibile

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

L'utilizzo della federazione delle identità per i workload ti aiuta a evitare i rischi associati all'utilizzo account di servizio account.

Utilizza i Controlli di servizio VPC per ridurre l'impatto delle credenziali compromesse

Se un malintenzionato riesce a rubare un token di accesso o una chiave 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 che controlla.

Per impostazione predefinita, IAM non tiene conto della geolocalizzazione, dell'indirizzo IP di origine o del progetto di origine Cloud de Confiance 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 tue risorse Cloud de Confianceinserendo i tuoi progetti in un perimetro di servizio VPC e utilizzando regole in entrata:

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

Proteggiti dalle minacce di manomissione

Per alcuni dati che memorizzi su Cloud de Confiance, potrebbe essere particolarmente importante impedire modifiche o eliminazioni non autorizzate. Se la modifica o l'eliminazione non autorizzata è un problema particolare, puoi caratterizzare i dati come dati ad alta integrità.

Per mantenere l'integrità dei tuoi dati, devi assicurarti che le risorse che utilizzi per archiviarli e gestirli siano configurate in modo sicuro e che mantengano la loro integrità. Cloud de Confiance

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, allora la pipeline di deployment si trasforma in un punto debole che potrebbe consentire agli autori 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.

Limitare l'accesso ai controlli di sicurezza

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

• Policy di autorizzazione e di negazione
• Vincoli delle policy dell'organizzazione
• Perimetri, livelli di accesso e criteri in entrata di Controlli di servizio VPC

Questi controlli di sicurezza sono risorse a sé stanti. La manomissione dei controlli di sicurezza mette a rischio l'integrità delle risorse a cui si applicano i controlli di sicurezza. 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, spetta alla pipeline di deployment mantenere l'integrità dei controlli di sicurezza. Di conseguenza, devi considerare l'integrità della pipeline di deployment stessa almeno altrettanto importante quanto l'integrità dei controlli di sicurezza che gestisce e delle risorse a cui si applicano questi controlli.

Puoi limitare l'impatto di una pipeline di deployment sull'integrità delle tue risorse nel seguente modo:

• 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 i criteri di negazione 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 i requisiti di integrità di determinati controlli di sicurezza, è meglio evitare che le pipeline di deployment gestiscano 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 Cloud de Confiance. In questo caso, devi essere in grado di scoprire di più sull'attività e, idealmente, ricostruire la catena di eventi che l'hanno causata.

Cloud Audit Logs ti consente di scoprire quando le risorse sono state consultate o modificate e quali utenti sono stati coinvolti. Sebbene Cloud Audit Logs fornisca un punto di partenza per l'analisi di 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 best practice che possono aiutarti a mantenere un audit trail in Cloud de Confiance e nelle pipeline di deployment.

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

Cloud Audit Logs contiene 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 il campo delle modifiche al codice e delle esecuzioni della pipeline che potrebbero essere responsabili. Tuttavia, identificare l'esecuzione esatta della pipeline e la modifica del codice che ha portato all'attività può essere difficile senza ulteriori informazioni che consentano di correlarCloud Audit Logsit con i log della pipeline di deployment.

Puoi arricchire Cloud Audit Logs in modo che contenga 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 trasmetti 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 correlate a una pipeline di deployment, in genere hai bisogno di 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 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 di deployment, questi periodi di conservazione predefiniti potrebbero essere insufficienti o non allineati.

Per assicurarti che i log siano disponibili quando ne hai bisogno, verifica 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 sink personalizzato per indirizzare i log a una posizione di archiviazione personalizzata.

Proteggiti dalle minacce di divulgazione delle informazioni

Quando il account di servizio di una pipeline di deployment ha accesso a dati confidenziali, 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: il 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 il risultato accidentale della concessione di un accesso eccessivo.

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

• Indiretto: per eseguire il deployment della configurazione o di nuove versioni del software, il account di servizio di una pipeline di deployment potrebbe avere l'autorizzazione per creare o eseguire nuovamente il deployment di risorse di computing, come le istanze VM di Compute Engine. Alcune di queste risorse potrebbero avere un account di servizio collegato che concede l'accesso a dati riservati.

  In questa situazione, un malintenzionato potrebbe tentare di compromettere la pipeline di deployment in modo da eseguire il deployment di codice dannoso su 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, una pipeline di deployment spesso non richiede l'accesso ai dati esistenti. Spesso, invece, è sufficiente limitare l'accesso alle risorse che non contengono dati o che 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 alla creazione 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 IaC per gestire le istanze VM o le reti, ma non per gestire i set di dati BigQuery riservati.

Utilizzare i Controlli di servizio VPC per impedire l'esfiltrazione di dati

Puoi ridurre il rischio di esfiltrazione indiretta di dati deployando le tue risorse Cloud de Confiance in un perimetro dei Controlli di servizio VPC.

Se la pipeline di deployment viene eseguita al di fuori di Cloud de Confianceo fa parte di un perimetro diverso, puoi concedere al 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, Cloud de Confiance lo fa indipendentemente dallo sviluppatore o dall'utente che ha creato una modifica al codice o alla configurazione. La mancata corrispondenza tra il account di servizio della pipeline e l'identità dello sviluppatore rende le pipeline di deployment soggette ad attacchi confused deputy, in cui un utente malintenzionato induce la pipeline a eseguire un'azione che non è autorizzato a eseguire personalmente e che la pipeline potrebbe non dover eseguire.

Questa sezione contiene best practice che possono aiutarti a ridurre il rischio che la tua pipeline di deployment venga utilizzata in modo improprio per l'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 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 affidabili. La sicurezza di questa architettura dipende quindi da:

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

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.
• Manomissione dell'infrastruttura (ad esempio VM e spazio di archiviazione) alla base della pipeline di deployment.
• Modifica o sostituzione degli input al di fuori del repository di codice, ad esempio pacchetti, immagini container o librerie.

Quando sono gestite da una pipeline di deployment, le tue risorse su Cloud de Confiance possono essere sicure solo quanto la pipeline di deployment, la sua configurazione, l'infrastruttura e gli input. Pertanto, devi proteggere questi componenti così come vuoi che le tue risorseCloud de Confiance siano protette.

Evita che una pipeline di deployment modifichi le policy

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

Se possibile, evita che una pipeline di deployment modifichi l'accesso alle risorse. Quando concedi l'accesso del account di servizio della pipeline alle risorse Cloud de Confiance , utilizza ruoli che non includono alcuna autorizzazione *.setIamPolicy ed evita di utilizzare i ruoli di base Editor e Proprietario.

Per alcune pipeline di deployment, la concessione dell'autorizzazione a modificare le policy di autorizzazione o di negazione potrebbe essere inevitabile: ad esempio, lo scopo di una pipeline di deployment potrebbe essere quello di 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:

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

Non rivelare le credenziali del account di servizio nei log

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

• Contenuto 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 utilizzate in modo illecito da malintenzionati per aumentare i loro privilegi. Ecco alcuni modi per impedire che i log rivelino le credenziali:

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

Passaggi successivi

• Scopri di più sulla federazione delle identità per i workload e sulle best practice per l'utilizzo della federazione delle identità per i workload.
• Consulta il nostro blueprint delle basi aziendali e le indicazioni su autenticazione e autorizzazione.
• Scopri di più sulle best practice per l'utilizzo dei service account.