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 all'esterno di Google Cloud di impersonare 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 sostituire le chiavi dell'account di servizio.

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

  • Spoofing: un utente malintenzionato potrebbe tentare di eseguire lo spoofing dell'identità di un altro utente per ottenere accesso non autorizzato alle risorse Google Cloud.
  • Riassegnazione dei privilegi: un utente malintenzionato potrebbe sfruttare la federazione delle identità per i carichi di lavoro per accedere a risorse altrimenti non autorizzate.
  • Non abbandono: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile il reperimento delle azioni.

Questa guida illustra le best practice per decidere quando utilizzare la federazione delle identità per i 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 delle identità per i carichi di lavoro per le applicazioni che hanno accesso alle credenziali ambient

Le applicazioni eseguite su cloud provider diversi da Google Cloud spesso hanno accesso alle credenziali Ambient. Sono le credenziali che l'applicazione può ottenere senza dover eseguire alcuna autenticazione aggiuntiva. Ecco alcuni esempi:

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

Se le credenziali ambientali sono token OpenID Connect (OIDC), asserzioni SAML o credenziali AWS, puoi configurare la federazione delle identità per i carichi di lavoro 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 prima essere in grado di scambiarle con un token OIDC o un'asserzione SAML e poi utilizzarle per la federazione delle identità per i carichi di lavoro.

Utilizza la federazione delle identità per i carichi di lavoro ogni volta che un'applicazione ha bisogno di accedere a Google Cloud e ha accesso alle credenziali ambient.

Utilizza uno scambio di token aggiuntivo per utilizzare credenziali ambient non supportate dalla federazione delle identità per i carichi di lavoro.

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali Ambient, ma i tipi di credenziali non sono supportati dalla federazione delle identità per i carichi di lavoro. In questi casi, verifica se uno scambio di token aggiuntivo ti consente di convertire le credenziali Ambient in un tipo di credenziale che puoi utilizzare per la federazione delle identità per i carichi di lavoro.

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 integrata di Windows, puoi utilizzare queste credenziali Kerberos per eseguire l'autenticazione con il provider di identità e ottenere un token di accesso OAuth che utilizza il formato JWT. Utilizzando questa federazione dei token di accesso e dell'identità dei carichi di lavoro, puoi consentire all'applicazione di eseguire un secondo scambio di token per ottenere credenziali Google di breve durata.

La concatenazione degli scambi di token aumenta la complessità e potrebbe introdurre ulteriori dipendenze, ma può impedirti di 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 secret) per l'autenticazione al provider di identità. In genere, questo secret è archiviato nella configurazione dell'applicazione. Per consentire a una tale applicazione di accedere a Google Cloud, devi decidere tra:

  1. Creazione di una chiave dell'account di servizio e archiviazione insieme all'altro secret.
  2. Utilizzo dei token emessi dal provider di identità esistente e scambio delle credenziali Google con la federazione delle identità per i carichi di lavoro.

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

Protezione dalle minacce di spoofing

Un pool Workload Identity non contiene alcuna identità o account utente, il che lo rende diverso da una directory utente come Cloud Identity. Invece, un pool di identità del carico di lavoro rappresenta una vista che mostra le identità provenienti da provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda di come configuri il pool di identità del carico di lavoro e i relativi provider, la stessa identità esterna potrebbe essere rappresentata da più entità IAM diverse o più identità esterne potrebbero essere mappate alla stessa entità IAM. Tali ambiguità potrebbero consentire ai malintenzionati di lanciare attacchi di spoofing.

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

Utilizza un progetto dedicato per gestire i pool e i provider di Workload Identity

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

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

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

Usa i vincoli dei criteri dell'organizzazione per disabilitare la creazione di provider di pool di Workload Identity in altri progetti

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

Puoi impedire la creazione di nuovi provider di pool di Workload Identity utilizzando il vincolo del criterio dell'organizzazione constraints/iam.workloadIdentityPoolProviders con una regola impostata su Nega tutti.

Applica questi vincoli alla radice della gerarchia organizzativa per impedire per impostazione predefinita la creazione di nuovi provider di pool di identità per i carichi di lavoro. Crea eccezioni per i progetti in cui vuoi consentire la gestione di pool e provider di identità per i carichi di lavoro mediante l'applicazione di un vincolo di criteri che consente determinati account AWS o provider OIDC attendibili.

Utilizza un unico provider per ogni pool di Workload Identity per evitare collisioni dei soggetti

La federazione delle identità per i carichi di lavoro consente di creare più di un provider per pool di identità. L'utilizzo di più provider può essere utile se le identità sono gestite da più provider, ma si vuole nascondere questa complessità ai carichi di lavoro in esecuzione su Google Cloud.

L'utilizzo di più provider introduce un rischio di collisioni di oggetti, dove la mappatura degli attributi per google.subject di un provider restituisce lo stesso valore della mappatura degli attributi per un altro provider. Il risultato di una collisione è che più identità esterne sono mappate alla stessa entità IAM, rendendo le identità esterne indistinguibili negli audit log di Cloud.

Per evitare conflitti, utilizza un singolo provider per ogni pool di identità del carico di lavoro. Se devi eseguire la federazione con più provider, crea più pool di Workload Identity, ognuno utilizzando un singolo provider di identità per i carichi di lavoro.

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

Puoi federare più volte lo stesso provider di identità creando più provider di pool di identità di carico di lavoro che utilizzano la stessa configurazione o un sistema simile. Se questi provider appartengono allo stesso pool di identità del carico di lavoro, una configurazione di questo tipo può causare collisioni di soggetti. Se i provider appartengono a diversi pool di Workload Identity, non possono verificarsi collisioni di 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 particolare identità esterna. Una tale ambiguità può anche aumentare i rischi quando si tenta 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 l'identità esterna per mantenere l'accesso.

Per ridurre al minimo il rischio di ambiguità, evita di federare più volte lo stesso provider di identità. Crea invece un singolo pool e provider di identità per i carichi di lavoro e utilizza una mappatura e una condizione degli attributi che ne garantiscano l'utilizzo per tutte le identità esterne che richiedono l'accesso alle risorse Google Cloud.

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

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

Per garantire l'autenticità, la comunicazione con il tuo provider di identità è protetta tramite TLS. Se viene eseguito il deployment del provider 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 utente malintenzionato potrebbe essere in grado di sfruttare questa configurazione lanciando un attacco man in the middle (MITM) in cui riconfigura il bilanciatore del carico per passare le richieste JWK a un endpoint dannoso che pubblica un set diverso di chiavi. Lo scambio del JWKS consente a un utente malintenzionato di firmare token considerati validi dalla federazione delle identità per i carichi di lavoro e che potrebbero consentire loro di eseguire lo spoofing di identità di altri utenti.

Per proteggerti dallo scambio JWKS, assicurati che il tuo IdP sia sottoposto a deployment in modo da proteggerlo dagli attacchi MITM.

Utilizza l'URL del provider del pool di Workload Identity come pubblico

Quando esegui la federazione con un provider OpenID Connect, la federazione delle identità per i carichi di lavoro verifica che il segmento di pubblico dei token (codificato nella richiesta aud) corrisponda all'impostazione dei segmenti di pubblico consentita del provider. Allo stesso modo, quando esegui la federazione con un provider SAML, la federazione delle identità per i carichi di lavoro verifica che l'asserzione SAML specifichi una limitazione dei segmenti di pubblico corrispondente al segmento di pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro prevede che il segmento di pubblico corrisponda all'URL https://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 consente di ridurre il rischio diconfusal'attacco. In questo caso, un utente malintenzionato presenta un token o un'asserzione SAML alla federazione del carico di lavoro che non era destinato a essere utilizzato per la federazione delle identità per i carichi di lavoro, ma per qualche altra API.

Richiedendo il token o l'asserzione in modo che contengano l'URL del provider del pool di identità del carico di destinazione, puoi assicurarti che i client possano utilizzare solo i token e le emissioni emessi in modo specifico per la federazione delle identità per i carichi di lavoro.

Utilizzare attributi immutabili nelle mappature degli attributi

Per concedere a un account di servizio un'autorizzazione di identità esterna, devi creare un'associazione IAM che faccia riferimento all'identità esterna per soggetto, gruppo o attributo personalizzato. L'oggetto, il gruppo e gli attributi personalizzati dell'identità esterna vengono ricavati dagli attributi che il provider di identità esterno passa alla federazione delle identità per i carichi di lavoro durante lo scambio di token.

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

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

Utilizzare attributi non riutilizzabili nelle mappature degli attributi

Quando concedi un'autorizzazione di identità esterna per impersonare un account di servizio ed elimini successivamente l'utente nel provider di identità esterno, l'associazione IAM dell'account di servizio rimane attiva.

Se in un secondo momento aggiungi un nuovo utente al provider di identità esterno e l'utente condivide alcuni attributi con l'utente eliminato in precedenza (ad esempio, lo stesso indirizzo email), gli utenti nuovi ed esistenti non saranno distinguibili dalla federazione delle identità per i carichi di lavoro. Di conseguenza, un'associazione IAM che intendeva fare riferimento solo al vecchio utente potrebbe essere applicata anche al nuovo utente.

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

Se i criteri aziendali consentono il riutilizzo di attributi come gli indirizzi email, evita di utilizzare questi attributi nella mappatura degli attributi e utilizza invece un attributo diverso per garantirne l'unicità nel tempo.

Protezione da minacce di non ripudiamento

Ogni volta che noti attività sospette in una delle tue risorse su Google Cloud, gli audit log di Cloud sono 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, assume l'identità di un account di servizio. Negli audit log di Cloud, qualsiasi attività eseguita dall'applicazione è attribuita all'account di servizio impersonato. Per ricostruire la catena completa degli eventi che hanno portato all'attività, devi essere in grado di correlare gli audit log di Cloud ai log del tuo provider di identità in modo da poter scoprire quale identità esterna è stata coinvolta e perché è stata eseguita un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere un audit trail non raffrontabile.

Abilita log degli accessi ai dati per le API IAM

Per aiutarti a identificare e comprendere gli scenari di rappresentazione degli account di servizio, servizi come Compute Engine includono una sezione serviceAccountDelegationInfo negli audit log di Cloud. Quando un'applicazione utilizza la federazione delle identità per i carichi di lavoro, questa sezione include l'oggetto dell'entità utilizzata per impersonare l'account di servizio.

Non tutti i servizi includono dettagli sul furto d'identità negli audit log di Cloud. Per mantenere un audit trail non recuperabile, devi anche registrare tutti gli eventi di rappresentazione attivando i log di accesso ai dati per l'API Security Token Service e l'API Identity and Access Management. Abilita questi log per tutti i progetti Cloud che contengono pool di carichi di lavoro o account di servizio utilizzati per la federazione delle identità per i carichi di lavoro.

Abilitando questi log, ti assicuri che venga aggiunta una voce agli audit log di Cloud ogni volta che un'applicazione utilizza la federazione delle identità per i carichi di lavoro per scambiare una credenziale esterna e per impersonare un account di servizio.

Utilizzare una mappatura dell'oggetto univoca

L'oggetto principale utilizzato nella sezione serviceAccountDelegationInfo nelle voci degli audit log di Cloud è determinato dalla mappatura degli attributi del provider di pool di Workload Identity per google.subject.

Quando individui 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.

Allo stesso modo, quando un'identità esterna è stata compromessa e devi scoprire se l'identità è stata utilizzata per accedere alle risorse di Google Cloud, devi essere in grado di trovare le voci degli audit log di Cloud che corrispondono all'identità esterna.

Quando definisci la mappatura degli attributi per un provider di pool di Workload Identity, scegli una mappatura univoca per google.subject in modo che:

  • Un'identità esterna viene mappata esattamente a un valore google.subject.
  • Un valore google.subject corrisponde a una sola identità esterna.
  • Puoi cercare un'identità esterna in base al valore di google.subject.

L'utilizzo di una mappatura degli attributi che soddisfa questi criteri di univocità ti aiuta ad assicurarti di cercare identità esterne in base al loro valore di google.subject e viceversa.

Protezione dalle minacce di escalation dei privilegi

Per applicare il principio del privilegio minimo quando si utilizza la federazione delle identità per i carichi di lavoro, è necessario:

  • Limitare il numero di identità esterne che possono assumere 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 utente malintenzionato può utilizzare un'identità esterna per aumentare i privilegi e accedere alle risorse a cui non dovrebbe avere accesso.

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

Utilizza account di servizio che risiedono nello stesso progetto delle risorse a cui hai bisogno di accedere

Quando un client utilizza la federazione delle identità per i carichi di lavoro utilizzando le librerie client o l'API REST, si esegue un processo a tre fasi:

  1. Ottieni una credenziale dal provider di identità affidabile.
  2. Scambia le credenziali con un token del servizio token di sicurezza.
  3. Utilizza il token del servizio di token di sicurezza per impersonare un account di servizio e ottenere un token di accesso di Google di breve durata.

Nell'ultimo passaggio, utilizza un account di servizio che risiede nello stesso progetto delle risorse a cui hai bisogno di accedere. L'utilizzo di un account di servizio gestito nello stesso progetto ti consente di applicare autorizzazioni di accesso più restrittive e facilita il compito di decidere quando l'account di servizio potrebbe non essere più necessario.

Utilizzare un account di servizio dedicato per ogni applicazione

Se hai più applicazioni che utilizzano la federazione delle identità per i carichi di lavoro per accedere alle risorse nello stesso progetto, crea un account di servizio dedicato per ogni applicazione. L'utilizzo di account di servizio specifici per le applicazioni consente di evitare l'eccesso di autorizzazioni concedendo l'accesso solo alle risorse necessarie per ogni singola applicazione.

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

Prima che un'identità esterna possa assumere l'identità di un account di servizio, devi concedergli il ruolo roles/iam.workloadIdentityUser nell'account di servizio. Quando concedi questo ruolo, evita di concederlo a tutti i membri del pool Workload Identity. Invece, concedi il ruolo a identità esterne specifiche o a identità che soddisfano determinati criteri.

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

Quando successivamente esegui l'onboarding di nuovi carichi di lavoro in Google Cloud, potrebbe essere necessario modificare la configurazione del provider di identità o dell'attributo del pool di identità del carico di lavoro per consentire identità aggiuntive aggiuntive.

Se concedi il ruolo di roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi garantire di poter crescere in modo sicuro un pool di identità del carico di lavoro senza concedere inavvertitamente un accesso di rappresentazione di identità esterne superiore a quello necessario.

Passaggi successivi