Best practice per l'utilizzo della federazione di Workload Identity

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 può 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 utente malintenzionato potrebbe tentare di eseguire lo spoofing dell'identità di un altro utente per ottenere l'accesso non autorizzato alle risorse Google Cloud.
• escalation dei privilegi: un utente malintenzionato potrebbe sfruttare la federazione delle identità per ottenere l'accesso alle risorse a cui non avrebbe altrimenti accesso.
• Non ripudio: un utente malintenzionato potrebbe nascondere la propria identità e le proprie azioni utilizzando credenziali esterne che rendono difficile il recupero di azioni da questi soggetti.

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 di Workload Identity

Best practice:

Utilizza la federazione delle identità per i carichi di lavoro per le applicazioni che hanno accesso alle credenziali ambientali.
Usa uno scambio di token aggiuntivo per utilizzare le credenziali ambientali che non sono supportate dalla federazione delle identità per i carichi di lavoro.
Utilizza la federazione di Workload Identity per ridurre il numero di credenziali che richiedono la rotazione.

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

Le applicazioni in esecuzione su provider di servizi cloud diversi da Google Cloud hanno spesso accesso alle 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 le identità gestite per ottenere i 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 ambientali sono credenziali 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 a Google di breve durata. Se le credenziali Ambient utilizzano un formato diverso, potresti essere in grado di scambiare le credenziali con un token OIDC o un'asserzione SAML e quindi di 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 deve accedere a Google Cloud e ha accesso alle credenziali ambientali.

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

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

Ad esempio, se la tua applicazione viene eseguita in un ambiente Active Directory, potrebbe avere accesso alle credenziali Kerberos. Se nel tuo ambiente hai un provider di identità come Active Directory Federation Services (AD FS) che supporta l'autenticazione integrata di Windows, puoi usare queste credenziali Kerberos per eseguire l'autenticazione presso il provider di identità e ottenere un token di accesso OAuth che utilizzi il formato JWT. Utilizzando questa federazione di token di accesso e di identità del carico di lavoro, puoi consentire all'applicazione di eseguire un secondo scambio di token per ottenere le credenziali di Google di breve durata.

La concatenazione degli scambi di token aumenta la complessità e potrebbe introdurre ulteriori dipendenze, ma può evitare di dover gestire e proteggere le chiavi degli account di servizio.

Usa 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 nel provider di identità. In genere, questo secret viene archiviato come parte della configurazione dell'applicazione. Per consentire a un'applicazione di accedere a Google Cloud, devi decidere tra:

1. Creare una chiave dell'account di servizio e archiviarla insieme all'altro secret.
2. Utilizzo dei token emessi dal provider di identità esistente e dello scambio per le credenziali Google mediante 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, che a sua volta può migliorare la sicurezza.

Protezione dalle 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. Invece, un pool di identità del carico di lavoro rappresenta una vista che mostra le identità dei provider di identità esterni in modo che possano essere utilizzate come entità IAM.

A seconda della configurazione del pool Workload Identity e dei relativi provider, la stessa identità esterna potrebbe essere rappresentata da più entità IAM oppure più identità esterne potrebbero essere mappate alla stessa entità IAM. Tali ambiguità potrebbero consentire a utenti malintenzionati di lanciare attacchi di spoofing.

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

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 Workload Identity in altri progetti.
Utilizza un unico provider per pool di identità dei carichi di lavoro per evitare conflitti tra i soggetti.
Evita di federare due volte con lo stesso provider di identità.
Proteggi l'endpoint dei metadati OIDC del tuo provider di identità.
Utilizza l'URL del provider del pool 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.

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

Anziché gestire pool e provider di identità del carico di lavoro tra più progetti, usa un singolo progetto dedicato per gestire pool e provider di identità del carico 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 in modo centralizzato l'accesso alla configurazione dei pool e dei provider di Workload Identity.
• Applica mappature e condizioni degli attributi coerenti a tutti i progetti e a tutte le applicazioni.

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

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

Gli utenti con l'autorizzazione per creare provider di pool di identità del carico di lavoro possono creare pool di identità e fornitori di carichi di lavoro che potrebbero essere ridondanti da 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 nella directory principale della gerarchia organizzativa per negare la creazione di nuovi provider di pool di identità per impostazione predefinita. Crea eccezioni per i progetti in cui vuoi consentire la gestione di pool e provider di identità del carico di lavoro applicando un vincolo di criterio che consente alcuni account AWS o provider OIDC attendibili e attendibili.

Usa un unico provider per ogni pool di identità dei carichi di lavoro, per evitare conflitti tra i soggetti

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

L'utilizzo di più provider introduce il rischio di conflitti tra soggetti, in cui 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 questa collisione è che più identità esterne vengono mappate alla stessa entità IAM, rendendo le identità esterne indistinguibili in Cloud Audit Logs.

Per evitare conflitti tra soggetti, utilizza un unico provider per ogni pool di identità dei carichi di lavoro. Se hai bisogno di federare più provider, crea più pool di identità del carico di lavoro, ognuno utilizzando un singolo provider di identità.

Evita di eseguire 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à del carico 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ò portare a collisioni di oggetti. Se i provider appartengono a diversi pool di identità dei carichi di lavoro, non possono verificarsi conflitti ed è invece rappresentata la stessa identità esterna 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. 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à, mantenendo inavvertitamente l'accesso dell'identità esterna.

Per ridurre al minimo il rischio di ambiguità, evita la federazione con lo stesso provider di identità più di una volta. Creare invece un unico pool di identità e un singolo provider per i carichi di lavoro e utilizzare 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 provider di identità. La federazione delle identità per i 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 provider di identità è protetta tramite TLS. Se il deployment del provider avviene 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 riuscire a sfruttare questa configurazione lanciando un attacco man in the middle (MITM) in cui riconfigura il bilanciatore del carico per consentirgli di passare le richieste JWKS a un endpoint dannoso che gestisce un set di chiavi diverso. Cambiare JWKS consente a un utente malintenzionato di firmare token considerati validi dalla federazione delle identità del carico di lavoro e potrebbe consentire di falsificare le identità di altri utenti.

Per proteggerti dallo scambio di JWKS, assicurati che il deployment dell'IdP sia eseguito in modo da proteggerlo dagli attacchi MITM.

Utilizza l'URL del provider del pool di identità del carico di lavoro come pubblico

Quando fai fede con un provider OpenID Connect, la federazione delle identità del carico di lavoro verifica che il pubblico dei token (codificati nella rivendicazione aud) corrisponda all'impostazione del pubblico consentita del provider. Analogamente, quando esegui la federazione con un provider SAML, la federazione delle identità per i carichi di lavoro verifica che l'asserzione SAML specifichi una restrizione del pubblico che corrisponde 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à del carico di lavoro. La richiesta di token e asserzioni per l'utilizzo di questo URL come segmento di pubblico consente di ridurre il rischio di attacchi confusi. In questo attacco, un utente malintenzionato presenta un token o un'asserzione SAML per la federazione delle identità per i carichi di lavoro che non erano destinati a essere utilizzati per la federazione delle identità dei carichi di lavoro, ma per alcune altre API.

Richiedere il token o l'asserzione per contenere l'URL del provider di pool di identità del carico di lavoro ti aiuta a garantire che i client possano utilizzare solo token e assence rilasciati specificamente per la federazione delle identità per i carichi di lavoro.

Utilizza attributi immutabili nelle mappature degli attributi

Per concedere un'autorizzazione di identità esterna al fine di impersonare un account di servizio, crea un'associazione IAM che fa riferimento all'identità esterna in base all'oggetto, al gruppo o a un attributo personalizzato. L'oggetto, il gruppo e gli attributi personalizzati dell'identità esterna vengono derivati dagli attributi trasmessi dal provider di identità esterno alla federazione delle identità del carico di lavoro durante lo scambio di token.

Alcuni provider di identità consentono agli utenti di modificare alcuni dei propri attributi. Ad esempio, a un utente può essere consentito modificare il proprio indirizzo email o gli alias, Se le associazioni IAM si riferiscono ad attributi modificabili, gli utenti potrebbero perdere accidentalmente l'accesso a determinate risorse modificando il proprio profilo utente. Oppure, peggio, i malintenzionati potrebbero essere in grado di ottenere l'accesso non autorizzato ad altre risorse modificando intenzionalmente i loro 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 che 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 e in seguito elimini l'utente nel provider di identità esterno, l'associazione IAM dell'account di servizio rimane attiva.

Se in seguito 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 vecchi e nuovi non saranno distinguibili per la federazione delle identità per i carichi di lavoro. Di conseguenza, un'associazione IAM che fa riferimento solo al vecchio utente potrebbe essere applicata anche al nuovo utente.

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

Se i criteri della tua azienda consentono il riutilizzo di attributi come gli indirizzi email, non utilizzare questi attributi nelle mappature degli attributi e utilizza invece 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 le mappature degli attributi per selezionare gli attributi forniti dal provider di identità esterno da incorporare in un token STS e il modo in cui i nomi degli attributi devono tradurre. 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 delle identità per i carichi di lavoro: se hai concesso un'entità federata o un'entità impostata sulla possibilità di rubare l'identità di un account di servizio, quindi cambi la mappatura degli attributi, puoi 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 che contengono 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 poter falsificare la propria identità e ottenere l'accesso a un account di servizio. Per evitare modifiche dannose, assicurati che solo alcuni utenti amministrativi abbiano l'autorizzazione per modificare le mappature degli attributi.

Valuta la possibilità di creare un progetto Cloud dedicato per la gestione dei pool di Workload Identity, in modo da 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 che non sono stabili o autorevoli

Un provider di identità utilizza gli attributi per comunicare informazioni sugli utenti autenticati. In genere i provider di identità garantiscono che alcuni attributi siano autorevoli, mentre 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 consenta la modifica dei nomi utente.

Se le mappature degli attributi si basano su attributi che non sono stabili o autorevoli, un utente malintenzionato potrebbe essere in grado di 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 dal provider di identità esterno, ma che ha ancora accesso a un account di servizio su Google Cloud.

Per evitare attacchi di spoofing, assicurati che le mappature degli attributi si basino solo sugli attributi garantiti dal provider di identità esterno per garantire stabilità e autorevole.

Protezione dalle minacce non respinte

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

Quando un'applicazione utilizza la federazione delle identità per il carico di lavoro, impersona un account di servizio. In Cloud Audit Logs, qualsiasi attività eseguita dall'applicazione viene attribuita all'account di servizio rappresentato. Per ricostruire l'intera catena di eventi che hanno generato l'attività, devi poter correlare Cloud Audit Logs con i log del provider di identità in modo da poter identificare l'identità esterna coinvolta e il motivo per cui è stata eseguita un'attività.

Questa sezione descrive le best practice che possono aiutarti a mantenere un percorso di controllo non ripetibile.

Best practice:

Abilita i log di accesso 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 rappresentazione degli account di servizio, i servizi come Compute Engine includono una sezione serviceAccountDelegationInfo nell'Cloud Audit Logs. 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 di rappresentazione in Cloud Audit Logs. Per contribuire a mantenere un audit trail non irreversibile, 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 identità del carico di lavoro o account di servizio utilizzati per la federazione delle identità per i carichi di lavoro.

Se abiliti 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 rubare l'identità di un account di servizio.

Utilizza una mappatura univoca del soggetto

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

Quando individui un'attività sospetta e devi sapere quale identità esterna è stata coinvolta, devi 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 poter trovare voci di Cloud Audit Logs corrispondenti all'identità esterna.

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

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

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

Protezione contro le minacce all'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 accessibili a un account di servizio

Una configurazione eccessivamente permissiva può comportare una situazione in cui un utente malintenzionato può utilizzare un'identità esterna per riassegnare i privilegi e le risorse di accesso a cui non deve avere accesso.

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

Best practice:

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

Utilizza account di servizio che si trovano 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, segue una procedura in tre passaggi:

1. Ottieni una credenziale dal provider di identità attendibile.
2. Scambia le credenziali di un token dal Security Token Service.
3. Utilizzare il token del Security Token Service per impersonare un account di servizio e ottenere un token di accesso a Google di breve durata.

Nell'ultimo passaggio, utilizza un account di servizio che si trova nello stesso progetto delle risorse a cui hai bisogno di 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 un 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 di ottenere autorizzazioni eccessive concedendo solo l'accesso 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 impersonare 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. Al contrario, concedi il ruolo a identità esterne specifiche o a identità che corrispondono a determinati criteri.

Inizialmente, il numero di utenti esterni che richiedono l'accesso alle risorse Google Cloud potrebbe essere ridotto. La condizione dell'attributo del pool di identità del carico di lavoro e la configurazione del provider di identità potrebbero pertanto consentire solo alcune identità esterne di utilizzare la federazione delle identità per i carichi di lavoro.

Quando in seguito esegui l'onboarding di nuovi carichi di lavoro in Google Cloud, potresti dover modificare la configurazione del provider di identità o la condizione degli attributi del pool Workload Identity, in modo da consentire identità esterne aggiuntive.

Se concedi il ruolo roles/iam.workloadIdentityUser solo a identità esterne specifiche, puoi assicurarti di far crescere in sicurezza un pool di identità del carico di lavoro senza concedere involontariamente più accesso di rappresentazione delle identità esterne rispetto a quanto necessario.

Passaggi successivi

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