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 assumere l'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 possono contribuire a sostituire le chiavi degli account di servizio.

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

• Spoofing: un malintenzionato potrebbe tentare di falsificare l'identità di un altro utente per ottenere un 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 a cui non avrebbe altrimenti accesso.
• Non ripudio: un utente malintenzionato potrebbe nascondere la propria identità e le sue azioni utilizzando credenziali esterne che rendono difficile il reperimento delle azioni.

Questa guida presenta 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

Best practice:

Utilizza la federazione delle identità per i carichi di lavoro per le applicazioni che hanno accesso a credenziali ambientali.
Utilizza uno scambio di token aggiuntivo per usare credenziali dell'ambiente non supportate dalla federazione delle identità per i carichi di lavoro.
Utilizza la federazione delle identità per i carichi di lavoro per ridurre il numero di credenziali che richiedono la rotazione.

Utilizza la federazione delle identità per i carichi di lavoro per le applicazioni che hanno accesso a credenziali ambientali

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

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

Se le credenziali dell'ambiente 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 di ambiente utilizzano un formato diverso, potresti essere in grado di scambiarle con un token OIDC o un'asserzione SAML prima di utilizzarle per la federazione delle identità dei carichi di lavoro.

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

Usa uno scambio di token aggiuntivo per usare credenziali ambientali non supportate dalla federazione delle identità per i carichi di lavoro

In alcuni casi, un'applicazione potrebbe avere accesso alle credenziali dell'ambiente, 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 consente di convertire le credenziali ambientali in un tipo di credenziale da utilizzare per la federazione delle identità dei 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 (ADFS) 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 utilizzi il formato JWT. Utilizzando questo token di accesso e la federazione delle identità per i carichi di lavoro, puoi quindi consentire all'applicazione di eseguire uno 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 ti evita di 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 di secret diversa) per l'autenticazione con il provider di identità. In genere, questo secret è archiviato come parte della 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'altro secret.
2. Utilizzare i token emessi dal provider di identità esistente e scambiarli con le credenziali Google utilizzando la federazione delle identità per i carichi di lavoro.

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 a sua volta può contribuire a migliorare la sicurezza.

Protezione contro le minacce di spoofing

Un pool Workload Identity non contiene identità o account utente, il che lo rende diverso da una directory utente come Cloud Identity. Un pool di identità del carico di lavoro rappresenta invece 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 Workload Identity e i relativi provider, la stessa identità esterna potrebbe essere rappresentata come più entità IAM diverse oppure più identità esterne potrebbero essere mappate alla stessa entità IAM. Tali ambiguità potrebbero consentire a malintenzionati di lanciare attacchi di spoofing.

La seguente sezione descrive le best practice per evitare mappature ambigue e ridurre il rischio di minacce di spoofing.

Best practice:

Utilizza un progetto dedicato per gestire i pool e i provider di Workload Identity.
Utilizza i vincoli dei criteri dell'organizzazione per disabilitare la creazione di provider di pool di Workload Identity in altri progetti.
Utilizza un singolo provider per pool di identità dei carichi di lavoro per evitare collisioni dei soggetti.
Evita la federazione con lo stesso provider di identità due volte.
Proteggi l'endpoint dei metadati OIDC del tuo provider di identità.
Utilizza l'URL del provider del pool di Workload Identity come pubblico.
Utilizza attributi immutabili nelle mappature degli attributi.
Utilizza attributi non riutilizzabili nelle mappature degli attributi.
Non consentire la modifica delle mappature degli attributi.
Non fare affidamento su attributi che non sono stabili o autorevoli.

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

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

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

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

Utilizza 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 per creare provider di pool di Workload Identity possono creare pool di identità per carichi di lavoro e provider che potrebbero essere ridondanti per 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 negare la creazione di nuovi provider di pool di identità per carichi di lavoro per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione di provider e pool di identità dei carichi di lavoro applicando un vincolo del criterio che consente determinati account AWS o provider OIDC attendibili.

Utilizza un singolo provider per 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à dei carichi di lavoro. 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 comporta il rischio di conflitti dei soggetti: 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 questa collisione è che più identità esterne sono mappate alla stessa entità IAM, rendendo le identità esterne indistinguibili in Cloud Audit Logs.

Per evitare conflitti tra i soggetti, utilizza un singolo provider per pool di identità dei carichi di lavoro. Se devi federare con più provider, crea più pool di identità per carichi di lavoro, ciascuno utilizzando un singolo provider di identità per carichi di lavoro.

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

Puoi federare con lo stesso provider di identità più volte creando più provider di pool di identità per carichi di lavoro che utilizzano la stessa configurazione o una configurazione simile. Se questi provider appartengono allo stesso pool di Workload Identity, una configurazione di questo tipo può causare collisioni dei soggetti. Se i provider appartengono a pool di Workload Identity diversi, non possono verificarsi conflitti degli oggetti 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 a quali risorse ha accesso una determinata identità esterna. Una tale ambiguità può anche aumentare il rischio 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'accesso dell'identità esterna.

Per ridurre al minimo il rischio di ambiguità, evita la federazione con lo stesso provider di identità più volte. Crea invece un singolo pool e provider di Workload Identity 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 dei 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 tuo provider di identità. La federazione delle identità dei carichi di lavoro utilizza i metadati dell'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 il deployment del provider viene eseguito 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 sfruttare questa configurazione lanciando un attacco man in the middle (MITM) in cui riconfigura il bilanciatore del carico in modo che passi le richieste JWKS a un endpoint dannoso che gestisce un set di chiavi diverso. La sostituzione del JWKS consente a un utente malintenzionato di firmare token che sono considerati validi dalla federazione delle identità dei carichi di lavoro e potrebbero consentire lo spoofing delle identità di altri utenti.

Per proteggerti dagli scambi di JWKS, assicurati che il deployment dell'IdP sia stato protetto 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 pubblico dei token (codificato nell'attestazione aud) corrisponda all'impostazione del pubblico consentita del provider. Allo stesso modo, quando imposti la federazione con un provider SAML, la federazione delle identità per i carichi di lavoro controlla che l'asserzione SAML specifichi una restrizione del pubblico corrispondente al pubblico previsto.

Per impostazione predefinita, la federazione delle identità per i carichi di lavoro prevede che il 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à dei carichi di lavoro. La richiesta di token e asserzioni per l'utilizzo di questo URL come pubblico contribuisce a ridurre il rischio di un attacco vicecomparso. In un attacco di questo tipo, un utente malintenzionato presenta un token o un'asserzione SAML alla federazione delle identità del carico di lavoro che non era destinata a essere utilizzata per la federazione delle identità dei carichi di lavoro, ma per alcune altre API.

La richiesta che il token o l'asserzione contenga l'URL del provider del pool di identità dei carichi di lavoro di destinazione per garantire che i client possano utilizzare solo token e asserzioni emessi specificamente per la federazione delle identità dei carichi di lavoro.

Utilizza attributi immutabili nelle mappature degli attributi

Per concedere a un'autorizzazione di identità esterna per impersonare un account di servizio, crea un'associazione IAM che fa riferimento all'identità esterna per oggetto, gruppo o attributo personalizzato. Il soggetto, il gruppo e gli attributi personalizzati dell'identità esterna derivano dagli attributi che il provider di identità esterno passa alla federazione delle identità dei carichi di lavoro durante lo scambio dei 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 ad attributi modificabili, gli utenti potrebbero perdere accidentalmente l'accesso a determinate risorse modificando il proprio profilo utente. O peggio ancora, i malintenzionati potrebbero essere in grado di ottenere l'accesso non autorizzato ad altre risorse modificando deliberatamente gli 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.

Utilizza attributi non riutilizzabili nelle mappature degli attributi

Quando concedi un'autorizzazione di identità esterna per impersonare un account di servizio e successivamente elimini 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 determinati attributi con l'utente precedentemente eliminato (ad esempio, lo stesso indirizzo email), gli utenti vecchi e nuovi non saranno distinguibili per la federazione delle identità dei carichi di lavoro. Di conseguenza, un'associazione IAM che doveva fare riferimento solo al vecchio utente potrebbe essere applicata anche al nuovo utente.

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

Se i criteri della tua azienda consentono il riutilizzo di attributi come gli indirizzi email, evita di utilizzarli nelle mappature degli attributi e utilizzane uno diverso che sia garantito che sia univoco nel tempo.

Non consentire la modifica delle mappature degli attributi

La federazione delle identità per i carichi di lavoro utilizza le mappature degli attributi per selezionare quali attributi forniti dal provider di identità esterno devono essere incorporati in un token STS e la modalità di traduzione dei nomi degli attributi. La configurazione delle mappature degli attributi è un passaggio fondamentale per la configurazione della 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 delle identità per i carichi di lavoro: se hai concesso a un'entità o un set federato la possibilità di impersonare un account di servizio e in seguito modifichi la mappatura degli attributi, potresti cambiare 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 con questa autorizzazione includono:

• Proprietario (roles/owner)
• Amministratore pool Workload Identity IAM (roles/iam.workloadIdentityPoolAdmin)

Se un utente malintenzionato ha l'autorizzazione per modificare le mappature degli attributi, potrebbe essere in grado di modificare le regole di mappatura in modo da consentire lo spoofing della propria identità e ottenere l'accesso a un account di servizio. Per evitare tali modifiche dannose, assicurati che solo pochi 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 carichi di lavoro, che consente di limitare il rischio che agli utenti venga inavvertitamente concesso 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. I provider di identità in genere garantiscono che alcuni attributi siano autorevoli, ma altri no. Ad esempio, un provider di identità esterno potrebbe incorporare sia un nome utente sia uno User-ID in un token OIDC. Entrambi gli attributi identificano in modo univoco un utente e potrebbero sembrare intercambiabili. Tuttavia, il provider di identità esterno potrebbe garantire che lo User-ID 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 utente malintenzionato potrebbe riuscire a falsificare la propria identità modificando il profilo utente nel provider di identità esterno. Ad esempio, potrebbero cambiare il proprio nome utente con quello di un utente che è stato recentemente eliminato nel provider di identità esterno, ma che ha ancora accesso a un account di servizio su Google Cloud.

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

Protezione da minacce di non ripudio

Quando noti attività sospette che interessano una delle tue risorse su Google Cloud, Cloud Audit Logs 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, simula un account di servizio. Negli audit log di Cloud, qualsiasi attività eseguita dall'applicazione viene attribuita all'account di servizio rappresentato. Per ricostruire l'intera catena 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 poter individuare l'identità esterna coinvolta e perché è stata eseguita un'attività.

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

Best practice:

Abilita i log degli accessi ai dati per le API IAM.
Utilizza una mappatura del soggetto univoca.

Abilita i log degli accessi ai dati per le API IAM

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

Non tutti i servizi includono i dettagli relativi alla rappresentazione in Cloud Audit Logs. Per gestire un audit trail non ripudiabile, 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 Workload Identity 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 a Cloud Audit Logs ogni volta che un'applicazione utilizza la federazione delle identità dei carichi di lavoro per scambiare una credenziale esterna e impersona un account di servizio.

Utilizza una mappatura del soggetto univoca

Il oggetto dell'entità utilizzato nella sezione serviceAccountDelegationInfo nelle voci di Cloud Audit Logs è determinato dalla mappatura degli attributi del provider del pool di identità dei carichi di lavoro per google.subject.

Quando rilevi attività sospette e devi individuare l'identità esterna coinvolta, devi poter cercare un'identità esterna in base al valore google.subject corrispondente.

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

Quando definisci la mappatura degli attributi per un provider di pool di identità di Workload Identity, 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 esattamente un'identità esterna.
• Puoi cercare un'identità esterna in base al suo valore google.subject.

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

Protezione da 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 impersonare 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 riassegnare i propri privilegi e accedere a risorse a cui non dovrebbe avere accesso.

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

Best practice:

Utilizza gli account di servizio che risiedono nello stesso progetto delle risorse a cui devi accedere.
Utilizza un account di servizio dedicato per ogni applicazione.
Evita di concedere l'accesso a tutti i membri di un pool.

Utilizza gli account di servizio che risiedono nello stesso progetto delle risorse a cui devi accedere

Quando un client utilizza la federazione delle identità per i carichi di lavoro utilizzando le librerie client o l'API REST, segue un processo 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 di Security Token Service per impersonare 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 trova nello stesso progetto delle risorse per le quali devi accedere. L'utilizzo di un account di servizio gestito nello stesso progetto consente di applicare autorizzazioni di accesso più restrittive e di decidere più facilmente 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 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 l'applicazione consente di evitare autorizzazioni eccessive concedendo solo l'accesso alle risorse richieste da ogni singola applicazione.

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

Prima che un'identità esterna possa impersonare un account di servizio, devi concedere il ruolo roles/iam.workloadIdentityUser nell'account di servizio. Quando concedi questo ruolo, evita di concederlo a tutti i membri del pool Workload Identity. Concedi invece il ruolo a identità esterne specifiche o a identità che corrispondono a determinati criteri.

Inizialmente, il numero di utenti esterni che hanno bisogno di accedere alle risorse Google Cloud potrebbe essere ridotto. La condizione degli attributi del pool di Workload Identity 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 accetti nuovi carichi di lavoro in Google Cloud, potresti dover modificare la configurazione del provider di identità o la condizione dell'attributo del pool di Workload Identity in modo che consenta identità esterne aggiuntive.

Concedendo il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di poter ampliare in sicurezza un pool di identità per i carichi di lavoro senza concedere inavvertitamente più accessi per la rappresentazione di identità esterne del necessario.

Passaggi successivi

• Scopri le best practice per lavorare con gli account di servizio.
• Scopri di più sulle best practice per la gestione delle chiavi degli account di servizio.