Pattern di architettura per la federazione delle identità

Questo documento confronta quattro pattern architetturali per la federazione Google Cloud con un provider di identità (IdP) esterno. Fornisce inoltre indicazioni per aiutarti a scegliere un'architettura adatta al tuo caso d'uso.

I quattro pattern architetturali sono i seguenti:

Fattori decisionali

Per scegliere un pattern architetturale adatto alla tua organizzazione, prendi in considerazione diversi fattori, tra cui i seguenti:

Portfolio di servizi

I servizi Google gestiscono l'autenticazione e l'autorizzazione in modo diverso. Ciò influisce sulla configurazione della federazione delle identità. Due fattori determinano queste differenze: il modello di servizio SaaS rispetto a PaaS e IaaS e il modello di autorizzazione IAM rispetto a quello specifico del servizio.

Modelli di servizio

  • Software as a Service (SaaS): Google gestisce completamente servizi come Gmail, Google Ads o l'app Gemini Enterprise. Questi servizi non richiedono alcuno sforzo di sviluppo e sono pronti all'uso. Poiché i servizi SaaS si rivolgono a un pubblico ampio, la maggior parte degli utenti potrebbe richiedere l'accesso.
  • Platform as a Service (PaaS) o Infrastructure as a Service (IaaS): la maggior parte dei Google Cloud servizi sono PaaS o IaaS. Questi servizi consentono agli utenti tecnici di sviluppare, eseguire il deployment e gestire carichi di lavoro personalizzati. Poiché questi servizi si rivolgono a un pubblico tecnico, solo un sottoinsieme dei tuoi utenti richiede l'accesso.

Modelli di autorizzazione

I servizi Google implementano l'autorizzazione in uno dei due modi seguenti:

  • IAM: la maggior parte dei Google Cloud servizi utilizza IAM per consentire agli amministratori di gestire l'accesso granulare alle risorse.
  • Autorizzazione specifica del servizio: servizi come Google Ads, Looker o Google Workspace non utilizzano IAM. Gli amministratori gestiscono invece l'accesso utilizzando strumenti specifici per ogni servizio.

Questi fattori comportano i seguenti gruppi di servizi:

SaaS PaaS o IaaS
Autorizzazione basata su IAM Google Cloud Servizi SaaS come l' app Gemini Enterprise e NotebookLM Enterprise Google Cloud Servizi PaaS e IaaS come BigQuery o Compute Engine
Autorizzazione specifica del servizio Servizi Google non cloud come Google Ads, Google Workspace, e Google Maps Nessuno

Per scegliere un pattern architetturale adatto alla tua organizzazione, valuta quali gruppi di servizi si applicano alla tua organizzazione.

Residenza dei dati

Per autenticare gli utenti e gestire le sessioni, Cloud Identity, Google Workspace e la federazione delle identità per la forza lavoro elaborano le informazioni personali degli utenti. Queste informazioni utente possono includere:

  • Nomi utente o indirizzi email
  • Attributi utente come nomi e cognomi
  • Nomi e appartenenze ai gruppi

Cloud Identity, Google Workspace e la federazione delle identità per la forza lavoro elaborano questi dati in base ai termini per i dati dei servizi e potrebbero archivarli al di fuori delle località dell'organizzazione o degli utenti:

  • Cloud Identity e Google Workspace archiviano i dati dei servizi nei data center Google e potrebbero replicarli in tutti i data center. I dati archiviati potrebbero includere informazioni non essenziali per l'autenticazione, come nomi di reparti, indirizzi o numeri di telefono.
  • La federazione delle identità per la forza lavoro archivia i dati dei servizi in Google Cloud regioni e potrebbe replicarli in tutte le regioni.

Se concedi a un utente l'accesso a una risorsa, IAM memorizza il suo identificatore principale in un'associazione di ruoli. Google Cloud elabora le associazioni di ruoli in base ai termini per i dati dei servizi e potrebbe archiviarli in tutte le Google Cloud regioni.

I pattern architetturali descritti in questa pagina richiedono l'archiviazione delle informazioni utente, ma differiscono per la durata di archiviazione di queste informazioni:

Molti IdP consentono di automatizzare la sospensione o l'eliminazione degli account utente quando lo stato dell'account utente corrispondente cambia nell'IdP. A seconda dell'IdP e della sua configurazione, l'IdP potrebbe ritardare l'eliminazione dell'account utente fino alla scadenza di un determinato periodo di tolleranza, il che può estendere la durata di archiviazione delle informazioni utente. Google Cloud

Integrazione di Gemini Enterprise con Microsoft 365

Gemini Enterprise consente di connettersi ai servizi Microsoft 365 utilizzando due tipi di connettori:

  • Connettori basati sull'acquisizione dei dati: questi connettori eseguono la scansione di Microsoft 365 per creare un indice di ricerca in Google Cloud. Quando un utente invia un prompt, Gemini Enterprise utilizza questo indice per cercare i contenuti ed esegue i controlli di accesso localmente valutando gli elenchi di controllo dell'accesso (ACL) ottenuti da Microsoft 365.
  • Connettori federati: questi connettori eseguono query su Microsoft 365 per ogni prompt. Utilizzano l'autorizzazione delegata per consentire a Microsoft 365 di eseguire direttamente i controlli di accesso.

I connettori basati sull'acquisizione dei dati introducono requisiti specifici per la federazione degli utenti:

  • Rilevamento dell'iscrizione al gruppo: gli ACL di Microsoft 365 possono includere voci per gruppi e utenti. Per valutare se un utente può accedere ai contenuti, i connettori devono considerare tutti i gruppi a cui appartiene l'utente. Se il connettore è a conoscenza solo di un sottoinsieme dei gruppi dell'utente, potrebbe consentire o negare l'accesso in modo errato.
  • Conversione degli identificatori: per valutare gli ACL, il connettore deve convertire gli identificatori di utenti e gruppi utilizzati da Microsoft 365 e gli identificatori utilizzati da Google Cloud.

Quando utilizzi la federazione delle identità per la forza lavoro, Gemini Enterprise può convertire in modo affidabile gli identificatori e valutare gli ACL se configuri le mappature degli attributi in modo che siano compatibili con Gemini Enterprise.

Quando utilizzi la federazione di Cloud Identity o Google Workspace, Microsoft Entra ID controlla le mappature degli attributi per il provisioning di utenti e gruppi anziché Google Cloud. Entra determina le regole di conversione per gli identificatori di utenti e gruppi, che potrebbero comportare trasformazioni complesse. Per valutare un ACL, il connettore Gemini Enterprise deve applicare le stesse regole di conversione, ma non ha visibilità sulla configurazione di Entra. Pertanto, quando utilizzi la federazione di Cloud Identity o Google Workspace, Gemini Enterprise non può convertire in modo affidabile gli identificatori di utenti e gruppi e non può valutare in modo affidabile gli ACL.

Per determinare quale pattern architetturale è adatto alla tua organizzazione, valuta l'utilizzo di Gemini Enterprise e se prevedi di utilizzare connettori basati sull'acquisizione dei dati.

Pattern architetturali

Il seguente diagramma di flusso mostra come questi fattori determinano quale pattern soddisfa i requisiti della tua organizzazione:

Diagramma di flusso che mostra come selezionare il pattern di federazione delle identità.

  1. Una parte significativa della tua organizzazione utilizza Google Workspace?

  2. Utilizzi servizi oltre a Google Cloud come Google Ads o Google Maps?

    • In caso affermativo, vai alla decisione 3.
    • In caso contrario, vai alla decisione 4.

  3. Prevedi di utilizzare Gemini Enterprise e di integrarlo con Microsoft 365?

  4. Prevedi di utilizzare Gemini Enterprise?

  5. Hai requisiti di residenza dei dati che richiedono di ridurre al minimo l'archiviazione delle informazioni utente?

Federazione di Cloud Identity o Google Workspace

Seleziona questo pattern quando la tua organizzazione soddisfa uno dei seguenti criteri:

  • Una parte significativa della tua organizzazione utilizza già Google Workspace.
  • Utilizzi servizi Google oltre a Google Cloud , come Google Ads o Google Maps, ma non prevedi di integrare Gemini Enterprise con Microsoft 365 utilizzando connettori basati sull'importazione dati.
  • Utilizzi solo i servizi, non prevedi di utilizzare Gemini Enterprise e non hai requisiti di residenza dei dati rigorosi per ridurre al minimo l'archiviazione dei dati utente. Google Cloud

In questo pattern non utilizzi la federazione delle identità per la forza lavoro. Federi invece il tuo account Cloud Identity o il tuo account Google Workspace con il tuo IdP e utilizzi il provisioning degli utenti e dei gruppi in anticipo.

Architettura della federazione di Cloud Identity e Google Workspace.

In questo pattern, devi eseguire il provisioning di utenti e gruppi prima che gli utenti possano accedere; in caso contrario, il tentativo di accesso non riesce:

  • Provisioning degli utenti: consente di garantire l'onboarding e l'offboarding tempestivi degli utenti.
  • Provisioning dei gruppi: consente di utilizzare i gruppi per gestire l'accesso ai servizi e alle risorse Google . Google Cloud

Se solo un sottoinsieme degli utenti della tua organizzazione ha bisogno di Google Workspace, aggiungi al tuo account sia un abbonamento a Google Workspace sia un abbonamento a Cloud Identity e assegna le licenze di Google Workspace solo agli utenti che ne hanno bisogno.

Vantaggi

Limitazioni

  • Il provisioning degli account utente in anticipo aggiunge un overhead e può rallentare la procedura di onboarding.

  • Non puoi controllare o limitare le località utilizzate da Cloud Identity o Google Workspace per archiviare i dati utente e i dati dei gruppi. Poiché Google elabora e archivia i dati utente e i dati dei gruppi in base ai termini per i dati dei servizi, i controlli della regione di dati non coprono questi dati e Google potrebbe replicarli nelle località dei data center Google.

  • Gemini Enterprise fornisce un supporto limitato per la connessione alle origini dati Microsoft quando utilizzi la federazione di Cloud Identity o Google Workspace.

Federazione delle identità per la forza lavoro, senza sincronizzazione

Seleziona questo pattern quando la tua organizzazione soddisfa i seguenti criteri:

  • Utilizzi solo i servizi. Google Cloud
  • Utilizzi Gemini Enterprise, ma prevedi di rimanere entro i limiti dei gruppi che sono imposti dal tuo IdP.
  • Hai requisiti di residenza dei dati che richiedono di ridurre al minimo l'archiviazione delle informazioni personali degli utenti.

Architettura della federazione delle identità per la forza lavoro, senza sincronizzazione.

In questo pattern, utilizzi la federazione delle identità per la forza lavoro per federare la tua Google Cloud organizzazione con il tuo IdP esterno.

Questo pattern non richiede il provisioning degli utenti o dei gruppi. Ogni volta che un utente accede, l'IdP trasmette le informazioni richieste sull' utente, inclusi gli attributi personalizzati e le appartenenze ai gruppi, a Google Cloud, e Google Cloud conserva queste informazioni solo per la durata della sessione utente.

Vantaggi

  • Non devi archiviare o gestire account utente o gruppi in Google Cloud.
  • Il pattern consente di utilizzare connettori basati sull'importazione dati per integrare Gemini Enterprise con Microsoft 365.

Limitazioni

  • La federazione delle identità per la forza lavoro è una funzionalità IAM e consente agli utenti di accedere solo ai servizi che utilizzano IAM. Gli utenti che eseguono l'autenticazione utilizzando la federazione delle identità per la forza lavoro non possono accedere ai servizi Google come Google Ads, Looker o Google Marketing Platform.
  • Gli utenti che eseguono l'autenticazione utilizzando la federazione delle identità per la forza lavoro non possono accedere ad alcune funzionalità Google Cloud . Per i dettagli, consulta Federazione delle identità: prodotti e limitazioni.
  • Molti IdP limitano il numero di appartenenze ai gruppi che possono trasmettere alla federazione delle identità per la forza lavoro in un'asserzione SAML o in un token ID. Per rimanere entro questi limiti, potrebbe essere necessario rafforzare la governance dei gruppi e limitare i tipi di gruppi da includere nelle asserzioni o nei token.
  • Quando condividi risorse come un notebook NotebookLM Enterprise, non puoi cercare un gruppo per nome. Gli utenti devono invece inserire manualmente i propri identificatori.

Se utilizzi Microsoft Entra ID, puoi utilizzare una variante di questo pattern configurando attributi aggiuntivi. Quando configuri attributi aggiuntivi, la federazione delle identità per la forza lavoro esegue un callback all'API Microsoft Graph durante l'autenticazione utente per recuperare le appartenenze ai gruppi. Questa configurazione consente di superare i limiti di iscrizione al gruppo di Entra per le asserzioni SAML e i token ID e di utilizzare fino a 999 iscrizioni al gruppo per utente.

Federazione delle identità per la forza lavoro con SCIM

Seleziona questo pattern quando la tua organizzazione soddisfa i seguenti criteri:

  • Utilizzi solo i servizi. Google Cloud Ovvero, non utilizzi servizi Google esterni come Google Ads o Google Maps.
  • Prevedi di utilizzare Gemini Enterprise o NotebookLM Enterprise e devi supportare fino a 2000 appartenenze ai gruppi per utente o la possibilità di cercare i gruppi per nome quando condividi le risorse.

Architettura della federazione delle identità per la forza lavoro con SCIM.

In questo pattern, utilizzi la federazione delle identità per la forza lavoro per federare la tua Google Cloud organizzazione. Per aumentare il numero di gruppi che puoi utilizzare per Gemini Enterprise, configura anche SCIM per eseguire il provisioning delle informazioni sull'iscrizione al gruppo in anticipo.

Vantaggi

  • Il pattern consente di utilizzare connettori basati sull'importazione dati per integrare Gemini Enterprise con Microsoft 365.
  • Puoi utilizzare fino a 2000 appartenenze ai gruppi per utente per controllare l'accesso a Gemini Enterprise e NotebookLM Enterprise e consentire ai connettori basati sull'importazione dati di Gemini Enterprise di eseguire i controlli di accesso.
  • Quando condividi risorse come un notebook NotebookLM Enterprise, puoi cercare i gruppi per nome per migliorare l'esperienza utente complessiva.

Limitazioni

  • Il supporto per i gruppi di cui è stato eseguito il provisioning con SCIM è limitato a Gemini Enterprise e NotebookLM Enterprise. Altri servizi possono utilizzare solo le appartenenze ai gruppi che l'IdP trasmette nell'asserzione SAML o nel token ID.
  • La federazione delle identità per la forza lavoro è una funzionalità IAM e consente agli utenti di accedere solo ai servizi che utilizzano IAM. Gli utenti che eseguono l'autenticazione utilizzando la federazione delle identità per la forza lavoro non possono accedere ai servizi Google come Google Ads, Looker o Google Marketing Platform.
  • Gli utenti che eseguono l'autenticazione utilizzando la federazione delle identità per la forza lavoro non possono accedere a alcune Google Cloud funzionalità. Per i dettagli, consulta Federazione delle identità: prodotti e limitazioni.

Cloud Identity ibrido e federazione delle identità per la forza lavoro

Seleziona questo pattern quando la tua organizzazione soddisfa i seguenti criteri:

  • Utilizzi servizi Google oltre a Google Cloud (come Google Ads o Google Maps).
  • Prevedi di utilizzare Gemini Enterprise e di integrarlo con Microsoft 365.

Architettura della federazione delle identità per la forza lavoro e di Cloud Identity ibrido.

Questo pattern combina due dei pattern precedenti:

  • Utilizzi la federazione delle identità per la forza lavoro (senza sincronizzazione o con SCIM) per gestire l'accesso a Gemini Enterprise e NotebookLM Enterprise.
  • Utilizzi la federazione di Cloud Identity o Google Workspace per gestire l'accesso ad altri servizi, inclusi Google Cloud i servizi Google non cloud e.

Vantaggi

Questo pattern consente di combinare i vantaggi dei due pattern precedenti:

  • Puoi connettere Gemini Enterprise alle origini dati Microsoft senza limitazioni delle funzionalità.
  • Gli utenti possono eseguire l'autenticazione ai servizi Google, indipendentemente dal fatto che questi servizi utilizzino o meno IAM.
  • Utilizza l'insieme completo di Google Cloud funzionalità.

Limitazioni

  • Devi gestire due configurazioni di relying party separate nel tuo IdP esterno: una per Cloud Identity e una per la federazione delle identità per la forza lavoro.
  • A seconda che tu configuri un utente per l'utilizzo di Cloud Identity o della federazione delle identità per la forza lavoro, la sua esperienza di accesso potrebbe essere diversa.
  • Quando gestisci i criteri di autorizzazione IAM, devi utilizzare identificatori principali diversi a seconda della modalità di autenticazione di un utente. Ad esempio, un utente noto come bob@example.com nel tuo IdP esterno potrebbe avere l'identificatore principale bob@example.com o principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID in IAM, a seconda che l'utente esegua l'autenticazione utilizzando la federazione di Cloud Identity o la federazione delle identità per la forza lavoro.
  • Non puoi creare gruppi che contengano una combinazione di utenti Cloud Identity e entità della federazione delle identità per la forza lavoro. I gruppi Cloud Identity possono contenere solo utenti Cloud Identity e i gruppi di identità della forza lavoro possono contenere solo entità della federazione delle identità per la forza lavoro.
  • L'estensione dell'utilizzo della federazione delle identità per la forza lavoro oltre Gemini Enterprise può richiedere agli utenti di passare da un'identità all'altra o di non sapere come eseguire l'autenticazione.

Passaggi successivi