Best practice per l'utilizzo della federazione delle identità della forza lavoro

La federazione delle identità per la forza lavoro federà la tua Google Cloud organizzazione con un provider di identità (IdP) esterno per attivare il Single Sign-On (SSO).

Puoi applicare queste best practice per utilizzare la federazione delle identità per la forza lavoro in modo efficace e ridurre al minimo i rischi per la sicurezza.

Scegliere l'architettura giusta

Le sezioni seguenti descrivono i fattori chiave per la scelta di un'architettura di federazione che soddisfi i tuoi requisiti.

Considerazioni sull'architettura:

Scegli un pattern di architettura di federazione.
Utilizzo della federazione delle partizioni per servizio, non per utente.

Scegliere un pattern di architettura di federazione

I quattro pattern seguenti descrivono i modi comuni per federare un'organizzazione con un IdP esterno: Google Cloud

Prima di eseguire la federazione, valuta i vantaggi e i limiti di ciascun pattern e scegli quello che soddisfa i tuoi requisiti. Per ulteriori informazioni, consulta la sezione Modelli di architettura per la federazione delle identità.

Utilizzo della federazione delle partizioni per servizio

In generale, ti consigliamo di partizionare l'utilizzo della federazione per servizio, anziché per utente. La suddivisione dell'utilizzo per servizio presenta meno svantaggi complessivi.

Per ridurre la complessità, ti consigliamo di utilizzare Cloud Identity o la federazione delle identità per la forza lavoro. Tuttavia, a seconda dei tuoi requisiti, potresti aver bisogno di entrambi in parallelo, come descritto nel pattern ibrido.

Se utilizzi la federazione Cloud Identity e la federazione delle identità per la forza lavoro in parallelo, puoi partizionare il loro utilizzo nei seguenti modi:

  • Partiziona per utente: partiziona gli utenti in due coorti: una che utilizza la federazione delle identità della forza lavoro e una che utilizza la federazione di Cloud Identity.

    • Vantaggio: ogni utente ha una sola identità nei servizi Google e un solo metodo di accesso.

    • Svantaggi: il partizionamento per utenti presenta diversi svantaggi, tra cui:

      • La gestione dei gruppi di accesso può essere complessa perché le policy di autorizzazione IAM devono contenere una combinazione di tipi di principal e non puoi utilizzare gli stessi gruppi per gli utenti di Cloud Identity e della federazione delle identità per la forza lavoro.

      • Gli utenti di coorti diverse non possono condividere link tra loro perché la Google Cloud console, Gemini Enterprise e altri strumenti utilizzano URL diversi a seconda della modalità di accesso degli utenti.

      • Gli utenti di coorti diverse potrebbero avere accesso a set di funzionalità diversi.

  • Partiziona per servizio: configura ogni servizio, ad esempio Google Cloud o Gemini Enterprise, in modo che conceda l'accesso esclusivamente agli utenti di Workforce Identity Federation o agli utenti di Cloud Identity, ma mai a entrambi.

    • Vantaggio: semplifica l'amministrazione e garantisce un insieme coerente di funzionalità per diversi utenti.
    • Svantaggio: ad alcuni dipendenti potrebbe essere necessario assegnare due identità: una che utilizza la federazione delle identità per la forza lavoro e una che utilizza Cloud Identity.

Ti consigliamo di eseguire il partizionamento per servizio, separando in particolare Gemini Enterprise e NotebookLM Enterprise dagli altri servizi. Gemini Enterprise e la Google Cloud console sono strumenti separati progettati per attività diverse. Eventuali differenze nelle procedure di accesso devono avere un impatto minimo sull'esperienza utente complessiva.

Per contribuire a imporre questo partizionamento, utilizza i vincoli delle policy dell'organizzazione.

Rafforzare la governance del gruppo

Per utilizzare in modo efficace la federazione delle identità per la forza lavoro, devi gestire l'accesso utilizzando i gruppi e stabilire procedure chiare per la loro gestione.

Le autorizzazioni di un utente per accedere alle risorse non vengono determinate durante l'autenticazione. L'accesso viene invece valutato quando l'utente tenta di accedere alla risorsa in base ai criteri associati a quella risorsa specifica. Questi criteri possono includere quanto segue:

Le policy definiscono l'accesso per singole entità o set di entità:

  • Entità: un utente autenticato identificato da un identificatore dell'entità. Un identificatore dell'entità della forza lavoro è simile al seguente: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    L'identificatore dell'entità contiene quanto segue:

    • POOL_ID: identifica in modo univoco un pool di identità della forza lavoro.
    • SUBJECT: identifica in modo univoco un utente specifico. Il valore e il formato dipendono dal tuo IdP e dalla mappatura degli attributi.

  • Set di entità: utenti che corrispondono a criteri specifici. La federazione delle identità per la forza lavoro supporta tre insiemi di entità: basati su gruppi (membri di un gruppo), basati su attributi e con caratteri jolly (tutti gli utenti).

La concessione dell'accesso a singoli principal può essere utile in situazioni specifiche, ma tende a scalare male a causa dei seguenti problemi:

  • L'aggiunta delle entità una alla volta fa sì che i criteri di autorizzazione crescano e diventino sempre più difficili da gestire.
  • La gestione dell'accesso individuale richiede modifiche frequenti alle policy di autorizzazione.
  • Le norme potrebbero diventare sempre più incoerenti nel tempo.

Per una gestione dell'accesso scalabile ed efficace, l'utilizzo di insiemi di entità basati su gruppi offre i seguenti vantaggi:

  • Puoi gestire l'accesso aggiungendo o rimuovendo membri dai gruppi utilizzando gli strumenti e i processi di identità esistenti.
  • Riduci le dimensioni e la complessità delle policy di autorizzazione.
  • Assicurati che gli utenti con lo stesso ruolo abbiano lo stesso accesso alle risorse.

Per utilizzare i gruppi per gestire l'accesso, devi configurare il tuo IdP esterno in determinati modi e tenere conto di eventuali limitazioni che l'IdP impone ai gruppi.

Le sezioni seguenti descrivono le best practice per utilizzare i gruppi in modo efficace ed evitare i limiti dell'IdP.

Best practice:

Distinguere i diversi tipi di gruppi.
Utilizza i gruppi di accesso per concedere l'accesso alle risorse.
Utilizza i gruppi di applicazione per limitare l'accesso alle risorse.
Non utilizzare gruppi organizzativi e di collaborazione per gestire l'accesso.
Utilizza i gruppi organizzativi e di collaborazione solo per Gemini Enterprise.

Distinguere i diversi tipi di gruppi

L'elenco seguente descrive quattro tipi di gruppi comunemente presenti nelle organizzazioni:

  • Gruppi di accesso: utilizzati solo per concedere l'accesso ai servizi Google o alle Google Cloud risorse. Rappresentano le funzioni lavorative e semplificano l'assegnazione dei ruoli necessari per svolgere queste funzioni.
  • Gruppi organizzativi: questi gruppi rappresentano sottoinsiemi della struttura di un'organizzazione e in genere provengono da dati delle risorse umane. Potrebbero essere basati su reparto, struttura di reporting, posizione geografica o altri raggruppamenti organizzativi.
  • Gruppi di collaborazione: questi gruppi rappresentano gruppi di lavoro, membri di progetti o utenti che vogliono collaborare a un progetto o discutere di un argomento specifico e possono essere utilizzati per la distribuzione di email. I gruppi di collaborazione vengono spesso creati in modo ad hoc e self-service.
  • Gruppi di applicazione: i gruppi di applicazione, chiamati anche gruppi di policy, vengono utilizzati per limitare l'accesso, a differenza dei gruppi di accesso, che vengono utilizzati per concedere l'accesso. Ad esempio, i confini di accesso dell'entità, le policy di negazione o l'applicazione dell'autenticazione a più fattori. I gruppi di accesso possono consentire ai membri di uscire volontariamente da un gruppo. Tuttavia, l'appartenenza a un gruppo di applicazione non è volontaria.

I gruppi che devi federare dipendono dai seguenti servizi che utilizzi:

  • Per Google Cloud, hai bisogno solo di gruppi di accesso e gruppi di applicazione.
  • Per Gemini Enterprise, sono necessari gruppi di accesso, gruppi di applicazione e, se utilizzi connettori basati sull'importazione dati, determinati gruppi di organizzazione e collaborazione.

Quando configuri la federazione delle identità per la forza lavoro, escludi i tipi di gruppo non pertinenti per evitare di superare i limiti dei token con il tuo IdP. Questo approccio ti aiuta a ridurre il rischio di superare i limiti imposti dal tuo IdP e a garantire un utilizzo più coerente dei gruppi.

Concedere l'accesso alle risorse utilizzando i gruppi di accesso

Per gestire l'accesso in modo efficace, ti consigliamo di utilizzare set di entità che vengono mappati ai gruppi di accesso. I gruppi di accesso esistono solo per fornire l'accesso. Rappresentano le funzioni lavorative e semplificano l'assegnazione dei ruoli necessari per svolgere queste funzioni.

Configura i gruppi di accesso nel seguente modo:

  1. Nel tuo IdP, crea gruppi di accesso che rappresentano le funzioni lavorative.
  2. Mappa i gruppi di accesso ai set di entità per utilizzarli in IAM.
  3. Crea associazioni di policy per concedere ai set di entità l'accesso alle risorse necessarie per ogni funzione lavorativa.
  4. Nel provider di identità esterno, aggiungi o rimuovi utenti dai gruppi in base alle loro funzioni lavorative.

Utilizza i gruppi di accesso per le policy che concedono l'accesso, tra cui:

  • Criteri di autorizzazione di IAM
  • Regole di traffico in entrata dei Controlli di servizio VPC

Assicurati che i gruppi di accesso siano sufficientemente granulari. Ad esempio, i seguenti gruppi rappresentano gruppi di accesso efficaci:

  • widget-sales-dashboard-readers: concede l'accesso in lettura a un set di dati BigQuery specifico e al dashboard associato.

  • dev-ssh-users: concede l'accesso OS Login alle VM Compute Engine nell'ambiente di sviluppo.

    Al contrario, i seguenti tipi di gruppi non sono generalmente adatti all'uso come gruppi di accesso:

    • I gruppi di amministratori generali come cloud-admins spesso non sono specifici in merito ai carichi di lavoro o agli ambienti a cui si applicano.

    • I gruppi organizzativi come australia-fte rappresentano gruppi come team o per località, anziché per funzione lavorativa.

    • I gruppi di comunicazione come security-discuss sono progettati per le mailing list o la collaborazione, anziché per un gruppo di accesso.

    Per mantenere i gruppi di accesso granulari, crea un nuovo insieme di gruppi di accesso per ogni carico di lavoro o progetto di cui esegui l'onboarding in Google Cloud. In questo modo, puoi scalare il numero di gruppi di accesso in base al numero di workload che esegui su Google Cloud.

Limitare l'accesso alle risorse utilizzando i gruppi di applicazione

I gruppi di applicazione sono simili ai gruppi di accesso, ma in genere differiscono per i seguenti aspetti:

  • Non consentono ai membri di uscire volontariamente dal gruppo.
  • Non sono specifiche per un workload.

Utilizza i gruppi di applicazione per le policy che riducono l'accesso, tra cui:

  • Criteri di negazione IAM
  • Limiti di accesso dell'entità
  • Policy dell'organizzazione

Esempi di gruppi di applicazione includono users-in-restricted-locations, fedramp-low e mfa-users. Il numero di gruppi di applicazione è in genere ridotto e difficilmente influisce sul numero totale di iscrizioni ai gruppi di un utente.

Non utilizzare gruppi organizzativi e di collaborazione per gestire l'accesso

Per gestire l'accesso in modo efficace, puoi utilizzare gruppi di accesso e gruppi di applicazione anziché gruppi organizzativi o di collaborazione.

I gruppi organizzativi rappresentano team o sottoinsiemi della struttura di un'organizzazione e in genere provengono dai dati delle risorse umane. Questi gruppi non sono adatti per gestire l'accesso alle risorse Google Cloud per i seguenti motivi:

  • Le responsabilità e la composizione del team potrebbero cambiare nel tempo. Ad esempio, un team potrebbe trasferire un carico di lavoro a un altro team o due team potrebbero unirsi. La gestione dell'accesso con i gruppi organizzativi potrebbe richiedere una serie di modifiche ai criteri durante queste transizioni.
  • I membri di un gruppo organizzativo raramente hanno bisogno di un accesso identico alle risorse. La concessione dell'accesso a un gruppo organizzativo spesso concede ad alcuni membri più accesso di quanto necessario.

I gruppi di collaborazione sono in genere autogestiti e consentono ai membri di partecipare con l'approvazione di un altro membro o senza approvazione. Puoi utilizzare i gruppi di collaborazione per concedere l'accesso può portare a un eccesso di autorizzazioni e all'escalation dei privilegi.

Per impedire l'utilizzo dei gruppi organizzativi e di collaborazione per la gestione dell'accesso, configura il tuo IdP in modo da escludere queste iscrizioni ai gruppi nei token o nelle asserzioni utilizzati per la federazione delle identità per la forza lavoro.

Utilizzare i gruppi organizzativi e i gruppi di collaborazione solo per Gemini Enterprise

Sebbene i gruppi organizzativi e di collaborazione non siano adatti per gestire l'accesso alle risorse Google Cloud , potresti averne bisogno per Gemini Enterprise:

  • Valutazione ACL: quando utilizzi connettori basati sull'importazione dati per integrare Gemini Enterprise con Microsoft 365, potresti riscontrare documenti con elenchi di controllo dell'accesso (ACL) che fanno riferimento a gruppi organizzativi e di collaborazione. Se Gemini Enterprise non ha accesso alle iscrizioni di un utente a questi gruppi, potrebbe non valutare correttamente se l'utente è autorizzato ad accedere a questi documenti.
  • Condivisione dei notebook: NotebookLM consente agli utenti di condividere i notebook. Consentire agli utenti di condividere i notebook con i gruppi di collaborazione è spesso più comodo che limitare la condivisione ai singoli utenti.

Per assicurarti che i gruppi organizzativi e di collaborazione siano disponibili solo per Gemini Enterprise, puoi configurare il tuo IdP nel seguente modo:

  • Utilizza SCIM per eseguire il provisioning dei gruppi di collaborazione e dell'organizzazione e delle relative appartenenze.
  • Escludi le iscrizioni ai gruppi organizzativi e di collaborazione nei token o nelle asserzioni utilizzati per la federazione delle identità per la forza lavoro.

Gestisci i pool di identità della forza lavoro

Un pool di identità per la forza lavoro definisce uno spazio dei nomi per gli identificatori delle entità e funge da contenitore per la configurazione della federazione. A differenza di una directory utenti, un pool non memorizza informazioni su utenti o gruppi.

Best practice:

Utilizza un solo pool per IdP.
Scegli un nome univoco e significativo per il pool.
Considera i pool come risorse con privilegi elevati.
Valuta i rischi quando estendi la federazione ai partner.

Utilizzare un unico pool per IdP

I pool di identità della forza lavoro sono una risorsa a livello di organizzazione, non a livello di progetto. Questo design riflette il fatto che i pool di identità per la forza lavoro gestiscono l'autenticazione in un'organizzazione, anziché in un singolo progetto o workload. Google Cloud

Per la maggior parte delle organizzazioni, il numero di pool di identità della forza lavoro deve corrispondere al numero di IdP:

  • Se la tua organizzazione utilizza un unico IdP per gestire l'autenticazione, utilizza un unico pool di identità per la forza lavoro.
  • Se la tua organizzazione utilizza più IdP, ad esempio a causa di un'acquisizione, utilizza un pool di identità della forza lavoro per ogni IdP.

Limitare il numero di pool di identità della forza lavoro ti aiuta a garantire quanto segue:

  • Non è necessario creare o modificare i pool di identità per la forza lavoro quando esegui l'onboarding di nuovi carichi di lavoro in Google Cloud.
  • Puoi utilizzare IAM per controllare a quali progetti e risorse all'interno di Google Cloud possono accedere i singoli utenti.

Scegliere un nome univoco e significativo per il pool

Per rendere univoci a livello globale gli identificatori delle entità, l'identità della forza lavoro codifica il nome del pool di identità della forza lavoro nell'identificatore dell'entità. Quando scegli un nome per un pool di identità della forza lavoro, tieni presente i seguenti vincoli:

  • Unicità: scegli un nome univoco in Google Cloud e non rivendicato da un'altra organizzazione.
  • Immutabilità: non puoi modificare il nome di un pool di identità per la forza lavoro. Scegli un nome che rimanga significativo nel tempo, evitando nomi di iniziative temporanee.
  • Esperienza utente: a seconda della configurazione di accesso, gli utenti potrebbero dover inserire il nome del pool durante l'accesso. Scegli un nome breve e facile da ricordare.

Considerare i pool come risorse con privilegi elevati

Il pool e il provider di identità della forza lavoro determinano la modalità di accesso degli utenti e controllano il modo in cui le identità e le appartenenze ai gruppi vengono derivate dal provider di identità esterno. Poiché questi componenti controllano la logica di autenticazione, sono fondamentali per la sicurezza della tua organizzazione. Google Cloud La compromissione di questi componenti potrebbe consentire ai malintenzionati di eseguire attacchi di spoofing.

Per eseguire un attacco di spoofing, i malintenzionati potrebbero tentare le seguenti azioni:

  • Modifica delle mappature degli attributi: la modifica delle mappature degli attributi può consentire a un malintenzionato di autenticarsi come un'altra persona e ottenere un accesso privilegiato non autorizzato.
  • Aggiunta di un provider dannoso: l'aggiunta di un provider può consentire a un malintenzionato di bypassare l'IdP della tua organizzazione e autenticarsi utilizzando un IdP diverso che controlla.

I pool e i provider di identità della forza lavoro sono risorse fondamentali per la sicurezza che richiedono la seguente protezione:

  • Limitare l'accesso agli utenti non federati: limita l'accesso amministrativo a un numero ridotto di utenti Cloud Identity o Google Workspace, incluso almeno un utente con accesso di emergenza.
  • Proteggi gli utenti amministrativi: richiedi la verifica in due passaggi per tutti gli utenti amministrativi e con accesso di emergenza.
  • Accesso just-in-time: utilizza Privileged Access Manager (PAM) per concedere l'accesso amministrativo just-in-time anziché concedere l'accesso permanente.

Considera i rischi quando estendi la federazione ai partner

La federazione Google Cloud con un IdP esterno utilizzando la federazione delle identità per la forza lavoro stabilisce una relazione di trust. Utilizzando la federazione, ti affidi all'IdP esterno per eseguire le seguenti azioni:

  • Esegui l'autenticazione a più fattori (MFA) che soddisfi i tuoi requisiti di sicurezza.
  • Fornire asserzioni accurate in merito alle identità degli utenti e alle iscrizioni ai gruppi.
  • Segui le procedure di governance delle identità che garantiscono l'offboarding tempestivo degli utenti e che le appartenenze ai gruppi riflettano con precisione i ruoli attuali.

La federazione delle identità per la forza lavoro fornisce meccanismi limitati per convalidare le asserzioni effettuate da un IdP esterno. Nello specifico, la federazione delle identità per la forza lavoro non supporta l'MFA post-SSO nello stesso modo di Cloud Identity.

Prima di utilizzare la federazione delle identità per la forza lavoro per consentire a partner esterni o collaboratori di accedere alle tue risorse Google Cloud , determina se questo livello di attendibilità è appropriato. Non utilizzare la federazione delle identità per la forza lavoro per l'accesso dei partner, a meno che tu non ti fidi del partner e del suo IdP per soddisfare costantemente i tuoi standard di sicurezza.

Gestisci i provider di pool di identità della forza lavoro

Un provider di pool di identità della forza lavoro definisce una relazione di federazione con un IdP esterno e contiene la configurazione per quanto segue:

  • L'IdP da utilizzare per Single Sign-On.
  • La mappatura degli attributi da utilizzare per derivare gli identificatori delle entità dai token o dalle asserzioni fornite dall'IdP.
  • (Facoltativo) Il tenant SCIM da utilizzare per cercare le informazioni sull'iscrizione al gruppo.

Best practice:

Scegli un nome del fornitore significativo.
Utilizza il portale delle applicazioni dell'IdP per esporre i singoli servizi.
Utilizza un singolo provider per pool per evitare collisioni di soggetti.
Utilizza lo stesso pool e lo stesso fornitore per la Google Cloud console e Gemini Enterprise.
Utilizza un URI emittente specifico del tenant.
Evita di utilizzare il flusso implicito di OpenID Connect (OIDC).

Scegliere un nome significativo per il fornitore

Quando crei un provider di pool di identità per la forza lavoro, devi assegnargli un nome. A differenza dei nomi dei pool di identità della forza lavoro, questo nome non deve essere univoco a livello globale e non viene codificato negli identificatori principali. Tuttavia, a seconda della configurazione di accesso, gli utenti potrebbero dover inserire il nome del provider durante l'accesso. Per migliorare l'esperienza utente, scegli un nome significativo e facile da ricordare, ad esempio entra o staff.

Evita di utilizzare nomi come oidc o saml, perché questi acronimi potrebbero non essere familiari agli utenti.

Mostrare i singoli servizi nel portale delle applicazioni IdP

Provider di identità come Microsoft Entra ID e Okta forniscono un portale delle applicazioni che consente agli utenti di scoprire e accedere alle applicazioni assegnate. Utilizza il portale per ottimizzare l'esperienza utente nel seguente modo:

  • Configura il portale in modo che mostri i servizi Google pertinenti singolarmente anziché un singolo link Google Cloud .
  • Configura i link per consentire l'accesso automatico all'utente.

La seguente tabella elenca i servizi Google comuni che supportano la federazione delle identità della forza lavoro e gli URL per l'accesso automatico:

Applicazione URL
Google Cloud Console della federazione delle identità per la forza lavoro, nota anche come console (federata) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
App web IAP URL dell'app, ad esempio https://iap.example.com/

Sostituisci quanto segue:

  • POOL: il nome del pool di identità della forza lavoro.
  • PROVIDER: il nome del fornitore del pool.
  • WEBAPP_ID: l'ID dell'app web Gemini Enterprise.
  • PROJECT_NUMBER: il numero del progetto NotebookLM Enterprise.

Utilizza un singolo fornitore per pool per evitare conflitti di argomenti

Puoi utilizzare la federazione delle identità per la forza lavoro per aggiungere più provider a un pool di forza lavoro. L'aggiunta di un secondo provider è utile durante le migrazioni in cui consenti temporaneamente agli utenti di autenticarsi utilizzando IdP diversi. Al di là di situazioni temporanee, evita di utilizzare più provider per i seguenti motivi:

  • Collisioni di soggetti: l'utilizzo di più fornitori introduce il rischio di collisioni di soggetti. In questi conflitti, il mapping dell'attributo google.subject per un provider restituisce lo stesso valore di un altro provider. Questa collisione mappa più identità esterne alla stessa entità IAM, rendendole indistinguibili in Cloud Audit Logs.
  • Compatibilità IAP: IAP richiede che i pool di identità della forza lavoro abbiano un unico provider per reindirizzare automaticamente gli utenti non autenticati all'IdP. Se aggiungi un altro provider, IAP non può autenticare gli utenti.

Se devi eseguire la federazione con più provider, crea più pool di workforce e configura un provider per ogni pool.

Utilizzare lo stesso pool e lo stesso fornitore per la console Google Cloud e Gemini Enterprise

Se utilizzi la federazione delle identità per la forza lavoro sia per Gemini Enterprise che per Google Cloud, utilizza un unico provider per garantire che gli utenti possano accedere a entrambi i servizi contemporaneamente senza eseguire di nuovo l'accesso. Se utilizzi provider separati con mappature degli attributi diverse, gli utenti potrebbero riscontrare situazioni in cui il loro accesso alle risorse varia a seconda del provider con cui accedono.

Utilizzare un URI emittente specifico per il tenant

Quando configuri un provider, specifichi un URI emittente per identificare in modo univoco il tuo IdP. Tuttavia, a seconda della configurazione dell'IdP, l'URI emittente potrebbe non essere univoco per il tenant della tua organizzazione. Ad esempio, se utilizzi un URI dell'emittente generico o condiviso, come l'endpoint comune di Microsoft Entra ID (https://login.microsoftonline.com/common/v2.0), potresti consentire inavvertitamente agli utenti di altre organizzazioni di autenticarsi nella tua organizzazione Google Cloud.

Per contribuire a impedire l'accesso cross-tenant non intenzionale, utilizza un URI dell'emittente specifico per il tenant. Se il tuo IdP non fornisce un URI dell'emittente specifico per il tenant, configura una condizione dell'attributo per limitare l'accesso al tuo tenant specifico.

Evita di utilizzare il flusso implicito OpenID Connect (OIDC)

Quando configuri un provider OIDC, preferisci il flusso del codice di autorizzazione al flusso implicito. Il flusso implicito è deprecato nella versione 2.1 della specifica OAuth perché è vulnerabile alla perdita e all'iniezione di token. L'utilizzo del flusso del codice di autorizzazione contribuisce a ridurre il rischio di intercettazione dei token.

Gestisci utenti

Puoi gestire gli utenti utilizzando la federazione delle identità per la forza lavoro. La federazione delle identità per la forza lavoro deriva l'identificatore dell'entità di un utente dal token o dall'asserzione dell'utente eseguendo i seguenti passaggi:

  1. Determina l'identificatore del soggetto applicando la mappatura degli attributi per google.subject. L'identificatore soggetto deve identificare in modo univoco un utente all'interno di un pool di identità della forza lavoro, ma non deve essere univoco in Google Cloud.

  2. Deriva l'identificatore principale aggiungendo l'identificatore soggetto a un prefisso che identifica il pool di identità della forza lavoro. L'identificatore principale risultante è univoco in Google Cloud e ha il seguente formato:

    principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
subject/SUBJECT

Quando un utente che ha eseguito l'autenticazione utilizzando la federazione delle identità della forza lavoro accede a una risorsa, IAM utilizza l'identificatore dell'entità per valutare i binding dei ruoli nelle policy di autorizzazione e lo registra in Cloud Audit Logs.

Best practice:

Utilizza un identificatore soggetto immutabile.
Non riutilizzare gli identificatori del soggetto.
Microsoft Entra ID: utilizza il nome utente principale come identificatore del soggetto.

Utilizzare un identificatore del soggetto immutabile

Quando l'identificatore del soggetto di un utente cambia, cambia anche il suo identificatore principale. Di conseguenza, Google Cloud non li riconosce più come lo stesso utente:

  • L'utente non può accedere alle risorse a cui aveva accesso in precedenza perché il suo nuovo identificatore entità non corrisponde più agli identificatori entità elencati nei criteri di autorizzazione.
  • Le voci di Cloud Audit Logs contengono solo il nuovo identificatore dell'entità e non possono più essere correlate ai log che utilizzavano il vecchio identificatore dell'entità.

Per mantenere stabile l'identificatore principale di un utente, utilizza una mappatura degli attributi che restituisca un valore stabile per google.subject.

Molti IdP generano automaticamente un identificatore numerico univoco o in formato UUID per gli utenti. Questi identificatori sono unici e stabili, il che li rende ottimi candidati per google.subject. Tuttavia, l'utilizzo di questi identificatori come google.subject può generare identificatori di entità lunghi e criptici che potrebbero essere difficili da utilizzare.

Per aiutarti a scegliere un identificatore per google.subject, tieni presente i seguenti requisiti in ordine di priorità decrescente:

  1. Unicità: il valore identifica in modo univoco un utente nel tuo IdP.
  2. Usabilità: il valore è significativo o almeno facilmente ricercabile nella directory utenti del tuo IdP.
  3. Immutabilità: il valore è immutabile o almeno modificabile solo dagli amministratori.

Non riutilizzare gli identificatori soggetto

Molti IdP applicano vincoli di unicità a determinati identificatori utente, ma consentono il riutilizzo degli identificatori. Ad esempio, un IdP potrebbe non consentirti di creare due utenti con lo stesso nome utente bob. Tuttavia, una volta eliminato l'account utente bob, il provider di identità potrebbe consentirti di creare un nuovo account utente e assegnargli di nuovo il nome utente bob.

Se la mappatura degli attributi del tuo fornitore per google.subject fa riferimento a un identificatore utente che consente il riutilizzo, potresti riscontrare collisioni di soggetti: la federazione delle identità per la forza lavoro non può distinguere tra un vecchio utente e un nuovo utente se il loro google.subject è lo stesso. Di conseguenza, il nuovo utente potrebbe ottenere l'accesso a risorse destinate solo al vecchio utente.

Per evitare collisioni degli argomenti, esegui una o entrambe le seguenti operazioni:

Microsoft Entra ID: utilizza il nome utente principale come identificatore del soggetto

Questa best practice si applica solo se utilizzi Microsoft Entra ID come IdP.

Se utilizzi Microsoft Entra ID, gli identificatori che puoi utilizzare come identificatore del soggetto includono quanto segue:

  • Nome dell'entità utente (upn)
  • ID oggetto (oid)
  • Indirizzo email (l'indirizzo principale in proxyAddresses)

Tra queste opzioni, ti consigliamo di utilizzare il nome principale utente come identificatore del soggetto per i seguenti motivi:

  • Tutti gli utenti hanno un nome principale utente.
  • I nomi principali utente identificano in modo univoco un utente.
  • I nomi principali utente tendono a essere significativi e semplici da utilizzare.
  • I nomi principali utente incorporano un nome di dominio, che identifica in modo univoco il tenant Microsoft Entra ID a cui è associato l'utente.
  • La tua organizzazione potrebbe avere un criterio in vigore che vieta o disciplina il riutilizzo degli identificatori utente principali.

Al contrario, l'ID oggetto e l'indirizzo email di un utente sono meno adatti per i seguenti motivi:

  • Un ID oggetto (oid) è immutabile, ma formattato come GUID. Questo formato li rende difficili da utilizzare e non significativi per gli esseri umani.
  • L'indirizzo email non è un attributo obbligatorio e potrebbe non essere compilato per tutti gli utenti.

Indipendentemente dall'identificatore scelto, ti consigliamo di evitare di applicare trasformazioni come la forzatura degli identificatori in minuscolo.

Gestisci gruppi

La federazione delle identità per la forza lavoro può determinare l'iscrizione al gruppo di un utente dalle seguenti fonti:

  • L'asserzione SAML o il token ID fornito dall'IdP.
  • L'API Microsoft Graph, se utilizzi Microsoft Entra ID come IdP.
  • Il tenant SCIM associato al provider del pool di identità per la forza lavoro.

Per impostazione predefinita, la federazione delle identità della forza lavoro utilizza solo l'asserzione SAML o il token ID:

Origine Google Cloud Gemini Enterprise
Token SAML o ID
API Microsoft Graph - -
Tenant SCIM - -

Se utilizzi Microsoft Entra ID come IdP, puoi attivare la funzionalità attributi aggiuntivi. La federazione delle identità per la forza lavoro utilizza quindi solo l'API Microsoft Graph come origine per le appartenenze ai gruppi:

Origine Google Cloud Gemini Enterprise
Token SAML o ID - -
API Microsoft Graph
Tenant SCIM - -

Se utilizzi Gemini Enterprise, puoi configurare la federazione delle identità per la forza lavoro in modo che utilizzi un tenant SCIM, il che modifica il comportamento nel seguente modo:

  • Gemini Enterprise utilizza le appartenenze ai gruppi del tenant SCIM e ignora le informazioni sull'appartenenza ai gruppi dell'asserzione SAML o del token ID.
  • Google Cloud utilizza le informazioni sull'iscrizione al gruppo dell'asserzione SAML o del token ID e ignora le informazioni sull'iscrizione al gruppo del tenant SCIM.
Origine Google Cloud Gemini Enterprise
Token SAML o ID -
API Microsoft Graph - -
Tenant SCIM -

Per ogni iscrizione al gruppo, la federazione delle identità per la forza lavoro deriva un identificatore principale eseguendo i seguenti passaggi:

  1. Determina l'identificatore del gruppo eseguendo una delle seguenti operazioni:
    • Asserzione SAML o token ID: applica la mappatura degli attributi per google.groups.
    • Tenant SCIM: applica la mappatura delle rivendicazioni per google.group.
    • API Microsoft Graph: segui extra-attributes-type nella configurazione del provider.

  2. Deriva l'identificatore principale aggiungendo l'identificatore del gruppo a un prefisso che identifica il pool di identità della forza lavoro. L'identificatore principale risultante è univoco in Google Cloud e ha il seguente formato:

    principalSet://iam.googleapis.com/locations/global/workforcePools/\
POOL_ID/group/GROUP_ID

Quando un utente autenticato utilizzando la federazione delle identità per la forza lavoro accede a una risorsa, IAM utilizza questi identificatori di entità per valutare i binding dei ruoli nelle policy di autorizzazione.

Best practice:

Utilizza un identificatore di gruppo immutabile.
Riduci le appartenenze ai gruppi nelle asserzioni o nei token.
Microsoft Entra ID: utilizza l'ID oggetto come identificatore del gruppo.

Utilizzare un identificatore di gruppo immutabile

Tutte le policy IAM fanno riferimento ai gruppi in base al loro identificatore principale. Quando rinomini un gruppo nel tuo IdP in modo che il suo identificatore cambi, Google Cloud non lo riconosce più come lo stesso gruppo:

  • Le associazioni di ruoli IAM esistenti continuano a fare riferimento al vecchio identificatore dell'entità e diventano inefficaci.
  • I membri del gruppo rinominato perdono l'accesso perché il nuovo identificatore principale del gruppo non corrisponde più ad alcun binding dei ruoli IAM.

Per evitare queste interruzioni, configura la mappatura degli attributi e delle rivendicazioni in modo da utilizzare un valore stabile e immutabile, ad esempio un ID univoco generato dal fornitore di identità. Evita di utilizzare nomi visualizzati o indirizzi email come identificatori di gruppo, perché potrebbero cambiare durante le modifiche organizzative.

Ridurre le appartenenze ai gruppi nelle asserzioni o nei token

Per impostazione predefinita, il tuo IdP potrebbe includere più appartenenze a gruppi nelle asserzioni SAML o nei token ID di quanto ti serva per gestire l'accesso a Gemini Enterprise e alle risorse Google Cloud . L'inclusione di appartenenze a gruppi non necessarie crea più rischi:

  • Perdita parziale dell'accesso: molti IdP impongono limiti al numero di appartenenze a gruppi che possono includere in un token o un'asserzione. Quando un utente supera questo limite (superamento del limite del gruppo), il provider di identità potrebbe eliminare alcune appartenenze al gruppo, causando la perdita dell'accesso a determinate risorse.
  • Errori di accesso: la federazione delle identità per la forza lavoro limita le dimensioni e il numero di appartenenze ai gruppi che la mappatura degli attributi google.groups può produrre. Gli utenti che superano uno di questi limiti non possono accedere.
  • Utilizzo incoerente dei gruppi: se esponi i gruppi a Google Cloud, i proprietari dei progetti potrebbero decidere di utilizzare questi gruppi per gestire l'accesso alle risorse, anche se non avevi mai previsto che determinati gruppi venissero utilizzati in Google Cloud.

I seguenti approcci possono aiutarti a mitigare questi rischi e a ridurre il numero di appartenenze a gruppi nelle asserzioni o nei token:

  • Filtra per tipo di gruppo: alcuni IdP, tra cui Microsoft Entra ID, ti consentono di configurare un filtro che determina quali gruppi includere nelle asserzioni o nei token. Puoi configurare un filtro per escludere i tipi di gruppo non pertinenti in base alla tua configurazione e ai servizi che prevedi di utilizzare.

    La tabella seguente indica i tipi di gruppi che potresti dover includere nelle asserzioni o nei token, a seconda dei servizi che prevedi di utilizzare:

    Tipo di gruppo Google Cloud Gemini (senza sincronizzazione) Gemini (SCIM)
    Gruppi di accesso -
    Gruppi di applicazione -
    Gruppi organizzativi Non necessario * -
    Gruppi di collaborazione Non necessario * -

    * Obbligatorio solo se utilizzi connettori basati sull'importazione dei dati.

    • Per gestire l'accesso a Google Cloud, devi includere gruppi di accesso e gruppi di applicazione.
    • Il filtro necessario per gestire l'accesso a Gemini Enterprise dipende dall'utilizzo di SCIM. Se utilizzi SCIM, Gemini Enterprise ignora le appartenenze ai gruppi incluse nelle asserzioni o nei token, quindi non devi includere gruppi specifici di Gemini Enterprise. Se non utilizzi SCIM, devi includere i gruppi di accesso e i gruppi di applicazione necessari per Gemini Enterprise. A seconda che tu preveda di utilizzare connettori basati sull'importazione dei dati, potresti anche dover includere determinati gruppi di organizzazione e collaborazione.

  • Assegnazione: alcuni IdP, tra cui Microsoft Entra ID, consentono di limitare le appartenenze ai gruppi nei token e nelle asserzioni ai gruppi assegnati, ovvero i gruppi che assegni esplicitamente alla configurazione della relying party.

  • Filtro attributi aggiuntivi: se utilizzi Microsoft Entra ID e hai attivato la funzionalità attributi aggiuntivi, puoi specificare un filtro utilizzando il flag --extra-attributes-filter. La federazione delle identità per la forza lavoro passa questo filtro all'API Microsoft Graph quando richiede le iscrizioni ai gruppi.

Per testare o risolvere i problemi relativi ai filtri, utilizza lo strumento Debug token IdP nella console Google Cloud o attiva la registrazione di audit dettagliata.

Microsoft Entra ID: utilizza l'ID oggetto come identificatore del gruppo

Questa best practice si applica solo se utilizzi Microsoft Entra ID come IdP.

Se utilizzi Microsoft Entra ID, gli identificatori che puoi utilizzare come identificatore del gruppo includono quanto segue:

  • ID oggetto (oid)
  • Indirizzo email
  • Nome visualizzato

Tra queste opzioni, ti consigliamo di utilizzare l'ID oggetto (oid) come identificatore del gruppo per i seguenti motivi:

  • Tutti i gruppi hanno un ID oggetto. Al contrario, l'indirizzo email è un campo facoltativo che potrebbe essere compilato solo per i gruppi Microsoft 365.
  • L'ID oggetto è univoco e immutabile. Al contrario, il nome visualizzato di un gruppo può cambiare e potrebbe non essere univoco.

Indipendentemente dall'identificatore scelto, ti consigliamo di evitare di applicare trasformazioni come la forzatura dei caratteri minuscoli.

Gestisci accesso

Best practice per i limiti di accesso e la gestione just-in-time (JIT).

Best practice:

Utilizza gli utenti Cloud Identity per l'accesso di emergenza.
Utilizza Cloud Identity per l'accesso con privilegi elevati.
Utilizza i vincoli delle policy dell'organizzazione per gestire la federazione.
Non concedere l'accesso a tutti i membri di un pool.
Limita la durata della sessione.
Allinea la durata della sessione ai requisiti di accesso JIT.

Utilizzare gli utenti Cloud Identity per l'accesso di emergenza

Per garantire l'accesso continuo ai tuoi ambienti Google Cloud , crea utenti con accesso di emergenza per ogni ambiente.

Gli utenti con accesso di emergenza forniscono l'accesso al tuo ambiente Google Cloud quando i servizi sono configurati in modo errato, compromessi o non funzionano normalmente. Gli utenti con accesso di emergenza dispongono di privilegi elevati. Affidarsi alla federazione delle identità per la forza lavoro per autenticare gli utenti con accesso di emergenza comporta i seguenti rischi:

  • Un errore nella configurazione del provider di pool di identità per la forza lavoro può causare il blocco dell'accesso.
  • Un'interruzione del servizio che interessa l'IdP esterno può impedirti di utilizzare un utente con accesso di emergenza quando ne hai più bisogno.
  • La compromissione dell'IdP esterno può consentire agli autori delle minacce di autenticarsi come utente con accesso di emergenza e ottenere un ampio accesso alle tue risorse Google Cloud.

Per mitigare questi rischi, utilizza Cloud Identity o Google Workspace per gli utenti con accesso di emergenza, anche se utilizzi la federazione delle identità per la forza lavoro per altri utenti:

  • Crea utenti con accesso di emergenza in Cloud Identity.
  • Escludi questi utenti dal Single Sign-On e consenti loro di autenticarsi utilizzando un nome utente e una password.
  • Proteggi questi utenti registrandoli alla verifica in due passaggi con un token di sicurezza.

Per ulteriori informazioni sugli utenti con accesso di emergenza, consulta Best practice per l'accesso continuo a Google Cloud.

Utilizzare Cloud Identity per l'accesso con privilegi elevati

Gli utenti con privilegi elevati hanno un ampio accesso al tuo ambiente Google Cloud. Ecco alcuni esempi di questi utenti:

  • Utenti con il ruolo Amministratore organizzazione (roles/resourcemanager.organizationAdmin)
  • Utenti con il ruolo Amministratore sicurezza (roles/iam.securityAdmin) o un ruolo simile che può modificare le policy di autorizzazione in parti significative della gerarchia delle risorse Google Cloud

Se utilizzi la federazione delle identità per la forza lavoro per utenti con privilegi elevati, qualsiasi configurazione errata o compromissione nel tuo IdP esterno può influire sulla sicurezza delle tue risorse Google Cloud . In particolare, la compromissione dell'IdP esterno può consentire agli autori malintenzionati di autenticarsi come utente con privilegi elevati e ottenere un ampio accesso alle tue risorse Google Cloud .

Per mitigare questi rischi, utilizza Cloud Identity per gli utenti con privilegi elevati:

  • Crea utenti con privilegi elevati in Cloud Identity.
  • Proteggi questi utenti registrandoli alla verifica in due passaggi con un token di sicurezza.
  • Se hai federato Cloud Identity con un IdP esterno, attiva verifiche SSO aggiuntive e la verifica in due passaggi per questi utenti.

Ulteriori verifiche SSO potrebbero sembrare ridondanti se l'IdP applica già l'autenticazione a più fattori, ma questa impostazione aiuta a proteggere gli utenti se l'IdP viene compromesso. Le verifiche SSO aggiuntive sono una funzionalità supportata da Cloud Identity, ma non disponibile per la federazione delle identità per la forza lavoro.

Utilizzare i vincoli dei criteri dell'organizzazione per gestire la federazione

Se utilizzi Cloud Identity per scopi diversi dall'accesso di emergenza o con privilegi elevati, partiziona l'utilizzo della federazione Cloud Identity e della federazione delle identità per la forza lavoro in base al servizio. Per applicare questa pratica, utilizza i vincoli personalizzati delle policy dell'organizzazione per limitare i tipi di entità consentiti in progetti specifici.

Ad esempio, puoi limitare la federazione delle identità della forza lavoro a Gemini Enterprise procedendo nel seguente modo:

  • Applica un vincolo della policy dell'organizzazione personalizzato al tuo progetto Gemini Enterprise che utilizza la funzione MemberTypeMatches per limitare i tipi di entità consentiti a iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet. Questi sono i tipi di entità utilizzati dalla federazione delle identità per la forza lavoro.
  • Per tutti gli altri progetti, applica un vincolo che consenta tutti i tipi di principal tranne iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet.

L'utilizzo di vincoli personalizzati delle policy dell'organizzazione ti aiuta a garantire la coerenza e a evitare l'utilizzo accidentale di tipi di principal errati.

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

La federazione delle identità della forza lavoro supporta un identificatore entità jolly che utilizza il seguente formato:

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

Questo identificatore corrisponde a ogni utente che il tuo IdP consente di autenticare su Google Cloud.

Non utilizzare questo identificatore jolly per concedere le autorizzazioni. Man mano che la base utenti del tuo IdP cresce, la concessione dell'accesso con l'identificatore dell'entità jolly porta a un eccesso di autorizzazioni.

Crea invece gruppi di accesso nel tuo IdP e utilizzali per gestire l'accesso alle risorse. Questo approccio contribuisce a garantire che l'accesso sia regolato dall'appartenenza intenzionale al gruppo anziché dall'autenticazione riuscita, riducendo il rischio di concessione eccessiva di autorizzazioni.

Limita la durata della sessione

Quando un utente accede, la federazione delle identità per la forza lavoro avvia una sessione. La sessione consente a un utente di:

  • Utilizza e sposta la console (federata), Gemini Enterprise o altri portali che supportano la federazione delle identità per la forza lavoro.
  • Utilizza applicazioni web protette da IAP.
  • Ottieni token di aggiornamento federati e token di accesso federati, ad esempio, eseguendo gcloud auth login.

Una sessione rimane valida finché non si verifica una delle seguenti condizioni:

  • La durata della sessione raggiunge il limite definito dal pool di identità per la forza lavoro.
  • La durata della sessione raggiunge il limite definito nell'attributo SessionNotOnOrAfter nell'asserzione SAML dell'utente, se presente.
  • L'utente esce.

Se le sessioni rimangono valide per periodi prolungati, aumenta il rischio di furto di token e le informazioni sull'iscrizione al gruppo potrebbero diventare obsolete:

  • Gli utenti potrebbero mantenere l'accesso più a lungo del previsto se le autorizzazioni vengono revocate nel provider di identità.
  • Gli utenti potrebbero non essere in grado di esercitare l'accesso appena concesso finché non si riautenticano e non stabiliscono una nuova sessione.

Per ridurre questi rischi, limita la durata della sessione in modo che gli utenti debbano accedere di nuovo almeno una volta al giorno.

Allineare la durata della sessione ai requisiti di accesso JIT

Per gestire l'accesso con privilegi, i tuoi IdP potrebbero supportare gruppi just-in-time (JIT) che i membri possono attivare temporaneamente. L'utilizzo di gruppi just-in-time per gestire l'accesso privilegiato a Google Cloud o Gemini Enterprise può introdurre i seguenti rischi:

  • Attivazione ritardata: se un utente ha una sessione di federazione delle identità per la forza lavoro attiva durante l'attivazione della sua appartenenza al gruppo just-in-time, la modifica dell'appartenenza non ha effetto finché l'utente non si disconnette e non accede di nuovo. In alternativa, se il provider del pool di identità della forza lavoro utilizza SCIM, la modifica dell'iscrizione non ha effetto finché non viene eseguito il provisioning della modifica dell'iscrizione al gruppo.
  • Revoca ritardata: se l'appartenenza a un gruppo scade, l'utente non perde l'accesso privilegiato finché non si disconnette e non esegue nuovamente l'accesso o finché la modifica dell'appartenenza al gruppo non viene eseguita utilizzando SCIM. A seconda della durata della sessione, questo ritardo può compromettere lo scopo della scadenza dell'abbonamento.

Per mitigare questi rischi, configura la durata della sessione del pool di identità della forza lavoro in modo che sia sufficientemente breve.

Monitorare l'attività

Ogni volta che noti un'attività sospetta che interessa una risorsa in Google Cloud, Cloud Audit Logs fornisce informazioni essenziali per determinare quando si è verificata l'attività e quali utenti sono stati coinvolti.

Abilita i log di accesso ai dati

La federazione delle identità della forza lavoro può generare log che ti consentono di monitorare le attività di accesso e di scambio di token. L'API Security Token Service scrive questi log, che includono i seguenti metodi:

  • google.identity.sts.SecurityTokenService.WebSignIn
  • google.identity.sts.SecurityTokenService.WebSignOut
  • google.identity.sts.v1.SecurityTokenService.ExchangeToken
  • google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

Tutti i log relativi alle attività di accesso e scambio di token sono classificati come log di accesso ai dati e sono disattivati per impostazione predefinita. Per acquisire questi log, attiva i log di accesso ai dati per l'API Security Token Service nella tua organizzazioneGoogle Cloud . Per aumentare ulteriormente la verbosità dei log di accesso, attiva audit log dettagliato.

Per monitorare altre attività correlate all'autenticazione, ti consigliamo di attivare e utilizzare i seguenti log:

Passaggi successivi