Best practice per l'utilizzo della federazione delle identità per i carichi di lavoro

La federazione delle identità per i carichi di lavoro consente alle applicazioni in esecuzione al di fuori di Google Cloud di appropriarsi dell'identità di un account di servizio utilizzando le credenziali di un provider di identità esterno.

L'utilizzo della federazione delle identità per i carichi di lavoro può aiutarti a migliorare la sicurezza consentendo alle applicazioni di utilizzare i meccanismi di autenticazione forniti dall'ambiente esterno e può aiutarti a sostituire le chiavi degli account di servizio.

Per utilizzare la federazione delle identità per i carichi di lavoro in sicurezza, devi configurarla in modo da proteggerti dalle seguenti minacce:

• Spoofing:un malintenzionato potrebbe tentare di rubare l'identità di un altro utente per ottenere accesso non autorizzato alle risorse Google Cloud.
• Escalation dei privilegi: un utente malintenzionato potrebbe sfruttare la federazione delle identità per la forza lavoro per ottenere l'accesso a risorse a cui altrimenti non avrebbe accesso.
• Non ripudio: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile risalire alle sue azioni.

Questa guida presenta le best practice per decidere quando utilizzare la federazione delle identità dei carichi di lavoro e come configurarla in modo da ridurre al minimo i rischi.

Quando utilizzare la federazione delle identità per i carichi di lavoro

Utilizza la federazione di Workload Identity per le applicazioni che hanno accesso alle credenziali ambient

Le applicazioni in esecuzione su cloud provider diversi da Google Cloud spesso hanno accesso alle credenziali ambient. Si tratta di credenziali che l'applicazione può ottenere senza dover eseguire un'autenticazione aggiuntiva. Ecco alcuni esempi:

• Su AWS, le applicazioni di cui è stato eseguito il deployment su EC2 possono utilizzare i profili istanza per assumere un ruolo e ottenere credenziali temporanee.
• In Azure, le applicazioni possono utilizzare le identità gestite per ottenere token di accesso.
• In GitHub Actions, i flussi di lavoro possono ottenere token ID che riflettono l'identità del job di deployment.

Se le credenziali di contesto sono token OpenID Connect (OIDC), assert SAML o credenziali AWS, puoi configurare la federazione delle identità per i workload per consentire alle applicazioni di scambiare queste credenziali con token di accesso Google di breve durata. Se le credenziali ambient utilizzano un formato diverso, potresti essere in grado di scambiarle per un token OIDC o un'affermazione SAML in un secondo momento e utilizzarle per la federazione delle identità del carico di lavoro.

Utilizza la federazione delle identità di carico di lavoro ogni volta che un'applicazione deve accedere a Google Cloud e ha accesso alle credenziali di ambiente.

Utilizza uno scambio di token aggiuntivo per utilizzare le credenziali ambient non supportate dalla federazione di Workload Identity

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali dell'ambiente, ma i tipi di credenziali non sono supportati da Workload Identity Federation. In questi casi, controlla se uno scambio di token aggiuntivo ti consente di convertire la credenziale ambientale in un tipo di credenziale che puoi utilizzare per la federazione di Workload Identity.

Ad esempio, se l'applicazione viene eseguita in un ambiente Active Directory, potrebbe avere accesso alle credenziali Kerberos. Se nel tuo ambiente è presente un provider di identità come Active Directory Federation Services (AD FS) che supporta l'autenticazione Windows integrata, puoi utilizzare queste credenziali Kerberos per autenticarti al provider di identità e ottenere un token di accesso OAuth che utilizza il formato JWT. Utilizzando questo token di accesso e la federazione Workload Identity, puoi consentire all'applicazione di eseguire un secondo scambio di token per ottenere credenziali Google di breve durata.

L'accodamento degli scambi di token aumenta la complessità e potrebbe introdurre dipendenze aggiuntive, ma ti consente di non dover gestire e proteggere le chiavi degli account di servizio.

Utilizza la federazione delle identità per i carichi di lavoro per ridurre il numero di credenziali che richiedono la rotazione

Le applicazioni che si integrano con un provider di identità OpenID o SAML spesso utilizzano un client secret (o una forma diversa di segreto) per autenticarsi al provider di identità. In genere, questo segreto viene memorizzato nella configurazione dell'applicazione. Per consentire a un'applicazione di questo tipo di accedere a Google Cloud, devi scegliere tra:

1. Creare una chiave dell'account di servizio e memorizzarla insieme all'altra secret.
2. Utilizzo dei token emessi dal provider di identità esistente e scambio con le credenziali Google mediante la federazione di Workload Identity.

La prima opzione richiede due secret, mentre la seconda ne richiede solo uno. La riduzione del numero di secret può aiutarti a semplificare la rotazione dei secret, il che può contribuire a migliorare la sicurezza.

Protezione dalle minacce di spoofing

Un pool di identità dei carichi di lavoro non contiene identità o account utente, il che lo distingue da una directory utente come Cloud Identity. Un pool Workload Identity rappresenta invece una visualizzazione che mostra le identità dei provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda di come configuri il pool di identità di Workload Identity e i relativi provider, la stessa identità esterna potrebbe essere rappresentata da più entità IAM diverse o diverse identità esterne potrebbero essere mappate allo stesso entità IAM. Queste ambiguità potrebbero consentire ai malintenzionati di lanciare attacchi di spoofing.

La sezione seguente descrive le best practice che ti aiutano a evitare mappature ambigue e a ridurre il rischio di minacce di spoofing.

Utilizzare le condizioni degli attributi durante la federazione con GitHub o altri provider di identità multi-tenant

La federazione delle identità dei carichi di lavoro non gestisce una directory degli account utente, ma implementa le identità basate su claim: pertanto, quando due token vengono emessi dallo stesso provider di identità (IdP) e i relativi claim mappano allo stesso valore google.subject, si presume che i due token identifichino lo stesso utente. Per scoprire quale IdP ha emesso un token, Workload Identity Federation ispeziona e verifica l'URL dell'emittente del token.

Alcuni provider, come GitHub e Terraform Cloud, utilizzano un unico URL emittente per tutti i loro tenant. Per questi fornitori, l'URL dell'emittente identifica tutto GitHub o Terraform Cloud, non un'organizzazione GitHub o Terraform Cloud specifica.

Quando utilizzi questi provider di identità, non è sufficiente consentire a Workload Identity Federation di controllare l'URL dell'emittente di un token per assicurarti che provenga da una fonte attendibile e che i relativi claim siano attendibili. Ti consigliamo di configurare una condizione dell'attributo della federazione delle identità per i carichi di lavoro per verificare che il token provenga da un tenant attendibile o, nel caso di GitHub o Terraform Cloud, da un'organizzazione attendibile.

Per saperne di più, consulta Configurare una condizione dell'attributo.

Utilizza un progetto dedicato per gestire i provider e i pool di identità per i carichi di lavoro

Anziché gestire i provider e i pool di identità per i carichi di lavoro in più progetti, utilizza un unico progetto dedicato per gestire i provider e i pool di identità per i carichi di lavoro. L'utilizzo di un progetto dedicato ti consente di:

• Assicurati che per la federazione delle identità dei carichi di lavoro vengano utilizzati solo provider di identità attendibili.
• Controlla centralmente l'accesso alla configurazione dei provider e dei pool di identità per i carichi di lavoro.
• Applicare mappature e condizioni degli attributi coerenti a tutti i progetti e tutte le applicazioni.

Puoi utilizzare i vincoli dei criteri dell'organizzazione per applicare la disciplina di utilizzo di un progetto dedicato per gestire i pool di identità e i provider di carichi di lavoro.

Utilizza i vincoli dei criteri dell'organizzazione per disattivare la creazione di provider di pool di identità del workload in altri progetti

Gli utenti con l'autorizzazione per creare provider di pool di identità per i carichi di lavoro possono creare provider e pool di identità per i carichi di lavoro che potrebbero essere ridondanti rispetto a quelli che gestisci in un progetto dedicato.

Puoi impedire la creazione di nuovi provider di pool di identità dei carichi di lavoro utilizzando il constraints/iam.workloadIdentityPoolProviders vincolo dei criteri dell'organizzazione con una regola impostata su Rifiuta tutto.

Applica questi vincoli alla radice della gerarchia dell'organizzazione per negare la creazione di nuovi fornitori di pool di identità del workload per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione di provider e pool di identità per i carichi di lavoro applicando un vincolo dei criteri che consenta determinati account AWS o provider OIDC attendibili.

Utilizza un singolo provider per pool di identità di workload per evitare collisioni degli oggetti

La federazione Workload Identity ti consente di creare più di un provider per pool di identità del workload. L'utilizzo di più provider può essere utile se le identità sono gestite da più provider, ma vuoi nascondere questa complessità ai carichi di lavoro in esecuzione su Google Cloud.

L'utilizzo di più provider introduce il rischio di collisioni degli oggetti, in cui la mappatura degli attributi per google.subject di un provider restituisce lo stesso valore della mappatura degli attributi di un altro provider. Il risultato di una collisione di questo tipo è che più identità esterne vengono mappate allo stesso principale IAM, rendendole indistinguibili in Cloud Audit Logs.

Per evitare conflitti di soggetti, utilizza un singolo provider per pool di identità per i carichi di lavoro. Se devi eseguire la federazione con più provider, crea più pool di identità di carico di lavoro, ognuno dei quali utilizza un singolo provider di identità di carico di lavoro.

Evita di eseguire la federazione con lo stesso provider di identità due volte

Puoi eseguire la federazione con lo stesso provider di identità più volte creando più provider di pool di identità di carico di lavoro che utilizzano la stessa configurazione o una simile. Se questi provider appartengono allo stesso pool di identità del workload, questa configurazione può portare a collisioni degli oggetti. Se i provider appartengono a pool di identità del workload diversi, non possono verificarsi collisioni degli oggetti soggetti e la stessa identità esterna viene rappresentata come entità IAM diverse.

La mappatura di una singola identità esterna a più entità IAM rende più difficile analizzare le risorse a cui ha accesso una determinata identità esterna. Questa ambiguità può anche aumentare il rischio durante il tentativo di revocare l'accesso: un amministratore potrebbe revocare l'accesso per un entità, ma potrebbe non essere a conoscenza dell'esistenza di un'altra entità, causando inavvertitamente il mantenimento dell'accesso da parte dell'identità esterna.

Per ridurre al minimo il rischio di ambiguità, evita di eseguire la federazione con lo stesso fornitore di servizi di identità più di una volta. Crea invece un singolo provider e un pool Workload Identity e utilizza una mappatura degli attributi e una condizione che ne garantisca l'utilizzo per tutte le identità esterne che richiedono l'accesso alle risorse Google Cloud.

Proteggi l'endpoint dei metadati OIDC del tuo provider di identità

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità del workload scarica periodicamente i metadati OIDC dal tuo provider di identità. La federazione di Workload Identity utilizza i metadati e il set di chiavi web JSON (JWKS) dell'IdP per convalidare i token.

Per garantire l'autenticità, la comunicazione con il tuo provider di identità è protetta tramite TLS. Se il provider viene implementato dietro un bilanciatore del carico o un proxy inverso che termina TLS, la connessione TLS garantisce l'autenticità del bilanciatore del carico o del proxy inverso, ma non del provider di identità effettivo.

Un malintenzionato potrebbe trarre vantaggio da questa configurazione lanciando un attacco man-in-the-middle (MITM) in cui riconfigura il bilanciatore del carico in modo da far passare le richieste JWKS a un endpoint dannoso che fornisce un insieme diverso di chiavi. Lo scambio del file JWKS consente a un malintenzionato di firmare token considerati validi da Workload Identity Federation e potrebbe consentire di rubare le identità di altri utenti.

Per proteggerti dallo scambio di JWKS, assicurati che l'identità provider sia implementata in modo da difenderla dagli attacchi MITM.

Utilizza l'URL del provider del pool di identità del workload come segmento di pubblico

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità del workload verifica che il pubblico dei token (codificato nell'attestazione aud) corrisponda all'impostazione del pubblico consentita del provider. Analogamente, quando esegui la federazione con un fornitore SAML, la federazione delle identità del workload controlla che l'affermazione SAML specifichi una limitazione del pubblico corrispondente al pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro si aspetta che il segmento di pubblico corrisponda all'URLhttps://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID che identifica in modo univoco il provider del pool di identità per i carichi di lavoro. Richiedere token e asserzioni per utilizzare questo URL come pubblico contribuisce a ridurre il rischio di un attacco di agente confuso. In questo tipo di attacco, un malintenzionato presenta a Workload Identity Federation un token o un'affermazione SAML che non era destinato a essere utilizzato per Workload Identity Federation, ma per un'altra API.

Richiedere che il token o l'affermazione contenga l'URL del fornitore del pool di identità del carico di lavoro di destinazione ti consente di assicurarti che i client possano utilizzare solo token e affermazioni emessi specificamente per la federazione delle identità del carico di lavoro.

Utilizzare attributi immutabili nelle mappature degli attributi

Per concedere a un'identità esterna l'autorizzazione a rubare l'identità di un account di servizio, crea un'associazione IAM che fa riferimento all'identità esterna in base a soggetto, gruppo o un attributo personalizzato. Gli attributi soggetto, gruppo e personalizzati dell'identità esterna derivano dagli attributi che il provider di identità esterno passa a Workload Identity Federation durante lo scambio di token.

Alcuni fornitori di identità consentono agli utenti di modificare alcuni dei propri attributi. Ad esempio, un utente potrebbe avere il permesso di modificare il proprio indirizzo email o i propri alias. Se le associazioni IAM fanno riferimento ad attributi modificabili, gli utenti potrebbero perdere accidentalmente l'accesso a determinate risorse modificando il proprio profilo utente. O peggio, gli utenti malintenzionati potrebbero riuscire ad accedere in modo non autorizzato ad altre risorse modificando deliberatamente i propri attributi utente in modo che corrispondano alle associazioni IAM esistenti.

Per proteggerti da questa minaccia di spoofing, limita le mappature degli attributi agli attributi che non possono essere modificati dall'utente o che non possono essere modificati affatto.

Utilizzare attributi non riutilizzabili nelle mappature degli attributi

Quando concedi a un'identità esterna l'autorizzazione a simulare l'identità di un account di servizio e successivamente elimini l'utente nel provider di identità esterno, il vincolo IAM dell'account di servizio rimane in vigore.

Se in un secondo momento aggiungi un nuovo utente al tuo provider di identità esterno e questo condivide determinati attributi con l'utente eliminato in precedenza (ad esempio lo stesso indirizzo email), gli utenti vecchi e nuovi non saranno distinguibili per la federazione delle identità di Workload. Di conseguenza, un'associazione IAM che doveva fare riferimento solo all'utente precedente potrebbe essere applicata anche al nuovo utente.

Per evitare queste ambiguità, utilizza mappature degli attributi che si basano esclusivamente su attributi che non possono essere riutilizzati nel tempo, ad esempio un ID utente univoco.

Se le norme della tua azienda consentono il riutilizzo di attributi come gli indirizzi email, evita di utilizzarli nelle mappature degli attributi e utilizza un attributo diverso che sia garantito come univoco nel tempo.

Non consentire la modifica delle mappature degli attributi

La federazione delle identità per i carichi di lavoro utilizza mappature degli attributi per selezionare quali degli attributi forniti dal provider di identità esterno devono essere incorporati in un token STS e come devono essere tradotti i nomi degli attributi. La configurazione delle mappature degli attributi è un passaggio chiave per impostare la relazione di attendibilità tra il provider di identità esterno e Google Cloud.

Le mappature degli attributi sono fondamentali anche per la sicurezza dell'utilizzo della federazione Workload Identity: se hai concesso a un'entità federata o all'entità impostato la possibilità di rubare l'identità di un account di servizio e poi modifichi la mappatura degli attributi, potresti modificare gli utenti che hanno accesso all'account di servizio.

Per modificare le mappature degli attributi è necessaria l'autorizzazione iam.googleapis.com/workloadIdentityPoolProviders.update. I ruoli contenente questa autorizzazione includono:

• Proprietario (roles/owner)
• IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)

Se un malintenzionato dispone dell'autorizzazione per modificare le mappature degli attributi, potrebbe essere in grado di cambiare le regole di mappatura in modo da rubare l'identità e ottenere l'accesso a un account di servizio. Per evitare queste modifiche dannose, assicurati che solo alcuni utenti amministrativi abbiano l'autorizzazione per modificare le mappature degli attributi.

Valuta la possibilità di creare un progetto Google Cloud dedicato per la gestione dei pool di identità dei workload, in modo da limitare il rischio che agli utenti venga concesso inavvertitamente uno di questi ruoli a un livello superiore nella gerarchia delle risorse.

Non fare affidamento su attributi non stabili o autorevoli

Un provider di identità utilizza gli attributi per comunicare informazioni sugli utenti autenticati. In genere, i fornitori di servizi di identità garantiscono che alcuni attributi sono autorevoli, ma altri no. Ad esempio, un fornitore di servizi di identità esterno potrebbe incorporare sia un nome utente sia un ID utente in un token OIDC. Entrambi gli attributi identificano univocamente un utente e potrebbero sembrare intercambiabili. Tuttavia, il provider di identità esterno potrebbe garantire che l'ID utente sia stabile e autorevole, ma consentire la modifica dei nomi utente.

Se le mappature degli attributi si basano su attributi non stabili o autorevoli, un malintenzionato potrebbe essere in grado di rubare l'identità modificando il proprio profilo utente nel provider di identità esterno. Ad esempio, potrebbe cambiare il proprio nome utente con quello di un utente eliminato di recente nel provider di identità esterno, ma che ha ancora accesso a un account servizio su Google Cloud.

Per evitare questi attacchi di spoofing, assicurati che le mappature degli attributi si basino solo su attributi che il provider di identità esterno garantisce essere stabili e autorevoli.

Protezione contro le minacce di non ripudio

Ogni volta che noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs è un'importante fonte di informazioni per scoprire quando si è verificata l'attività e quali utenti sono stati coinvolti.

Quando un'applicazione utilizza la federazione delle identità per i carichi di lavoro, sostituisce un account di servizio. In Cloud Audit Logs, qualsiasi attività eseguita dall'applicazione viene attribuita all'account di servizio sostituito. Per ricostruire la catena completa di eventi che hanno portato all'attività, devi essere in grado di correlare Cloud Audit Logs con i log del tuo provider di identità in modo da scoprire quale identità esterna è stata coinvolta e perché è stata eseguita un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere una tracciabilità non contestabile.

Attivare i log di accesso ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di furto d'identità degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo in Cloud Audit Logs. Quando un'applicazione utilizza la federazione di Workload Identity, questa sezione include l'oggetto dell'entità di servizio utilizzata per rubare l'identità dell'account di servizio.

Non tutti i servizi includono i dettagli di furto d'identità in Cloud Audit Logs. Per contribuire a mantenere una traccia di controllo non ripudiabile, devi anche registrare tutti gli eventi di furto d'identità attivando i log di accesso ai dati per l'API Security Token Service e l'API Identity and Access Management. Attiva questi log per tutti i progetti Cloud che contengono pool di identità per i carichi di lavoro o account di servizio utilizzati per la federazione delle identità per i carichi di lavoro.

Se attivi questi log, ti assicuri che venga aggiunta una voce a Cloud Audit Logs ogni volta che un'applicazione utilizza la federazione delle identità per i carichi di lavoro per scambiare una credenziale esterna e finge di essere un account di servizio.

Utilizza una mappatura dell'oggetto univoca

L'oggetto principale utilizzato nella sezione serviceAccountDelegationInfo nelle voci dei log di controllo di Cloud è determinato dalla mappatura degli attributi del fornitore del pool di identità per i carichi di lavoro per google.subject.

Quando rilevi attività sospette e devi scoprire quale identità esterna è stata coinvolta, devi essere in grado di cercare un'identità esterna in base al valore google.subject corrispondente.

Analogamente, quando un'identità esterna è stata compromessa e devi scoprire se è stata utilizzata per accedere alle risorse Google Cloud, devi essere in grado di trovare le voci Cloud Audit Logs corrispondenti all'identità esterna.

Quando definisci la mappatura degli attributi per un provider di pool di identità di carico di lavoro, scegli una mappatura univoca per google.subject in modo che:

• Un'identità esterna viene mappata a un solo valore google.subject.
• Un valore google.subject viene mappato a una sola identità esterna.
• Puoi cercare un'identità esterna in base al relativo valore google.subject.

L'utilizzo di una mappatura degli attributi che soddisfa questi criteri di unicità ti aiuta a garantire che tu possa cercare le identità esterne in base al loro valore google.subject, e i valori google.subject in base alle loro identità esterne.

Protezione dalle minacce di escalation dei privilegi

Per applicare il principio del privilegio minimo quando utilizzi la federazione delle identità per i carichi di lavoro, devi:

• limitare il numero di identità esterne che possono rubare l'identità di un account di servizio
• limitare le risorse a cui un account di servizio può accedere

Una configurazione eccessivamente permissiva può portare a una situazione in cui un malintenzionato può utilizzare un'identità esterna per eseguire la riassegnazione dei propri privilegi e accedere a risorse a cui non dovrebbe avere accesso.

Le sezioni seguenti forniscono best practice che possono aiutarti a proteggerti dalle minacce di escalation dei privilegi.

Utilizza account di servizio che si trovano nello stesso progetto delle risorse a cui devi accedere

Quando un client utilizza la federazione delle identità di carico di lavoro utilizzando le librerie client o l'API REST, segue una procedura in tre passaggi:

1. Ottieni una credenziale dal provider di identità attendibile.
2. Scambia la credenziale con un token del servizio token di sicurezza.
3. Utilizza il token del Security Token Service per rubare l'identità di un account di servizio e ottenere un token di accesso Google di breve durata.

Per l'ultimo passaggio, utilizza un account di servizio che si trovi nello stesso progetto delle risorse a cui devi accedere. L'utilizzo di un account di servizio gestito nello stesso progetto ti consente di applicare autorizzazioni di accesso più restrittive e semplifica la decisione di quando l'account di servizio potrebbe non essere più necessario.

Utilizza un account di servizio dedicato per ogni applicazione

Se hai più applicazioni che utilizzano la federazione di Workload Identity per accedere alle risorse nello stesso progetto, crea un account di servizio dedicato per ogni applicazione. L'utilizzo di account di servizio specifici per l'applicazione ti consente di evitare di concedere troppe autorizzazioni concedendo l'accesso solo alle risorse richieste da ogni singola applicazione.

Evita di concedere l'accesso a tutti i membri di un pool

Prima che un'identità esterna possa rubare l'identità di un account di servizio, devi concederle il ruolo roles/iam.workloadIdentityUser nell'account di servizio. Quando concedi questo ruolo, evita di concederlo a tutti i membri del pool di identità di carico di lavoro. Al contrario, concedi il ruolo a identità esterne specifiche o a identità che corrispondono a determinati criteri.

Inizialmente, il numero di utenti esterni che devono accedere alle risorse Google Cloud potrebbe essere ridotto. La condizione dell'attributo del pool di identità per i carichi di lavoro e la configurazione del provider di identità potrebbero quindi consentire solo a poche identità esterne di utilizzare la federazione delle identità per i carichi di lavoro.

Quando in un secondo momento esegui l'onboarding di nuovi workload in Google Cloud, potrebbe essere necessario modificare la configurazione del provider di identità o la condizione dell'attributo del pool di identità del workload in modo da consentire identità esterne aggiuntive.

Se concedi il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di poter far crescere in sicurezza un pool di identità di workload senza concedere inavvertitamente più accessi di simulazione dell'identità di identità esterne del necessario.

Passaggi successivi

• Scopri le best practice per l'utilizzo degli account di servizio.
• Scopri di più sulle best practice per la gestione delle chiavi degli account di servizio.