Configura provider di identità

Per applicare controllo dell'accesso all'origine dati e proteggere i dati in Gemini Enterprise, devi configurare un provider di identità. Ciò comporta la configurazione del provider di identità e la gestione delle autorizzazioni per le origini dati. Google utilizza il tuo provider di identità per identificare l'utente finale che esegue una ricerca e determinare se ha accesso ai documenti restituiti come risultati.

Scegli il tipo di provider di identità

Il tipo di provider di identità che scegli dipende dalle origini dati connesse alla tua app Gemini Enterprise. Gemini Enterprise supporta le seguenti opzioni:

Tipo di provider di identità Quando utilizzarlo
Google Identity Google Identity è il provider di identità consigliato per Gemini Enterprise.

Google Identity supporta:
  • Tutte le origini dati proprietari di Google che utilizzano l'importazione dati o la federazione dei dati. Devi utilizzare Google Identity quando ti connetti a origini dati di Google Workspace.
  • Tutte le origini dati di terze parti che utilizzano la federazione dei dati, in cui gli utenti eseguono l'autenticazione direttamente con il servizio di terze parti utilizzando OAuth.
  • Tutte le origini dati di terze parti che utilizzano l'acquisizione dei dati, ad eccezione delle origini dati Microsoft 365, come SharePoint, OneDrive o Outlook, che richiedono Microsoft Entra ID e la federazione delle identità per la forza lavoro.
Prima di configurare l'identità Google, determina l'attributo utente univoco utilizzato dalla tua organizzazione, in genere l'email dell'utente. Se gli utenti hanno più di un indirizzo email, devi aggiungere un alias email.
Provider di identità di terze parti Quando connetti Gemini Enterprise solo a origini dati di terze parti e utilizzi già un provider di identità di terze parti che supporta OIDC o SAML 2.0, come Microsoft Entra ID, Okta o AD FS, puoi utilizzare Google Identity o la federazione delle identità per la forza lavoro. Google consiglia di utilizzare Google Identity per le nuove configurazioni. I clienti esistenti che utilizzano già la federazione delle identità per la forza lavoro possono scegliere di continuare a utilizzarla. Per ulteriori informazioni, consulta Federazione delle identità per la forza lavoro.

Prima di configurare la federazione delle identità della forza lavoro, determina gli attributi utente univoci utilizzati dalla tua organizzazione e mappali alla federazione delle identità per la forza lavoro.

Controllo dell'accesso per i connettori Google Workspace

Quando utilizzi la ricerca e la base dei dati aziendali con i connettori Google Workspace (ad esempio Persone di Google Workspace o Google Gruppi), Gemini Enterprise rispetta rigorosamente gli elenchi di controllo dell'accesso (ACL) e le autorizzazioni del sistema di origine.

Principio fondamentale: nessuna escalation dei privilegi

Un utente che interagisce con Gemini Enterprise può visualizzare e basare le risposte solo sulle informazioni a cui è già autorizzato ad accedere direttamente nell'applicazione Google Workspace di origine. Gemini Enterprise non aggira mai i controlli dell'accesso al sistema di origine né concede autorizzazioni aggiuntive.

  • Persone di Google Workspace (Directory): la visibilità degli utenti nei risultati di ricerca e di base rispetta le impostazioni di visibilità della directory della tua organizzazione. Ad esempio, se la visibilità di un utente nella directory di Google Workspace è limitata al proprio reparto o unità organizzativa, può trovare colleghi solo all'interno di quel reparto utilizzando Gemini Enterprise. Non possono visualizzare i profili dei dipendenti dei reparti con accesso limitato.

  • Gruppi Google:l'individuazione e la fondatezza dei contenuti rispettano le impostazioni di accesso e appartenenza al gruppo. Un utente può cercare e visualizzare solo i contenuti di Google Gruppi di cui è membro e per i quali dispone dell'autorizzazione di visualizzazione. Gli utenti non membri non possono scoprire o visualizzare le discussioni dei gruppi privati tramite Gemini Enterprise.

Dove gestire le autorizzazioni

Non configurare le impostazioni di controllo dell'accesso e visibilità nelle impostazioni del connettore Gemini Enterprise nella console Google Cloud . Un amministratore di Google Workspace configura invece le impostazioni di autorizzazione, appartenenza e visibilità nel sistema di origine:

  • Visibilità del profilo utente:l'amministratore di Google Workspace configura la visibilità del profilo utente nella Console di amministrazione Google. Per saperne di più, consulta Configurare la condivisione della directory.

  • Accesso e appartenenza ai gruppi: l'amministratore di Google Workspace configura l'accesso e l'appartenenza ai gruppi in Google Gruppi o nella Console di amministrazione Google. Per saperne di più, consulta Configurare e gestire i gruppi.

Federazione delle identità per la forza lavoro per i provider di identità di terze parti

Questa sezione descrive come configurare la federazione delle identità per la forza lavoro per i provider di identità di terze parti. Se vuoi, puoi verificare se la configurazione della federazione delle identità per la forza lavoro funziona come previsto.

Configura la federazione delle identità per la forza lavoro

Per informazioni dettagliate sulla configurazione della federazione delle identità per la forza lavoro con il connettore di identità di terze parti, consulta le seguenti risorse:

Provider di identità Risorse
Entra ID
Okta
OIDC o SAML 2.0

Configura la mappatura degli attributi

La mappatura degli attributi ti aiuta a collegare le informazioni sull'identità di terze parti a Google utilizzando la federazione delle identità per la forza lavoro.

Quando configuri la mappatura degli attributi nella federazione delle identità per la forza lavoro, tieni presente quanto segue:

  • L'attributo google.subject viene utilizzato per la mappatura degli attributi, l'assegnazione delle licenze e la condivisione dei blocchi note. Ti consigliamo di mappare google.subject all'indirizzo email dell'utente in minuscolo, poiché l'assegnazione delle licenze è sensibile alle maiuscole e minuscole.

  • Se la tua organizzazione ha più di un identificatore univoco, mappa questi attributi organizzativi univoci utilizzando l'attributo attribute.as_user_identifier_number between 1 and 50.

    Ad esempio, se la tua organizzazione utilizza sia l'indirizzo email sia il nome dell'entità come identificatori dell'utente in diverse applicazioni e il nome dell'entità è impostato come preferred_username nel tuo provider di identità di terze parti, puoi mapparlo a Gemini Enterprise utilizzando la mappatura degli attributi della federazione delle identità per la forza lavoro (ad esempio, attribute.as_user_identifier_1=assertion.preferred_username).

Gli esempi seguenti mostrano le mappature degli attributi richiesti per i provider di identità comuni. Puoi aggiungere altre mappature degli attributi per supportare identificatori univoci aggiuntivi, come descritto in precedenza.

  • Entra ID con protocollo OIDC
    Questo esempio utilizza l'email per identificare in modo univoco gli utenti.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • Entra ID con protocollo SAML
    Questo esempio utilizza l'email per identificare in modo univoco gli utenti.

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • Okta con protocollo OIDC
    Questo esempio utilizza l'email per identificare in modo univoco gli utenti.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • Okta con protocollo SAML
    Questo esempio utilizza l'asserzione del soggetto del JWT per identificare in modo univoco gli utenti.

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

(Facoltativo) Verifica la configurazione della federazione delle identità della forza lavoro

Per verificare gli accessi riusciti e la mappatura degli attributi corretta utilizzando la funzionalità di audit log della federazione delle identità per la forza lavoro:

  1. Attiva gli audit log per l'API Security Token Service dell'attività di accesso ai dati.

    1. Nella console Google Cloud , vai alla pagina dei log di controllo.

      Vai agli audit log

      Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo IAM e amministrazione.

    2. Seleziona un progetto, una cartella o un'organizzazione Google Cloud esistente.
    3. Abilita gli audit log di accesso ai dati.
      1. Consulta la documentazione sulla registrazione per la procedura dettagliata su come attivare gli audit log.
      2. Per l'API Security Token Service, seleziona il tipo di audit log Lettura amministratore. Per ulteriori informazioni, consulta Log di esempio per la federazione delle identità per la forza lavoro.

  2. Attiva la registrazione dettagliata nel pool di forza lavoro. La funzionalità Gruppi estesi della federazione delle identità per la forza lavoro per Microsoft Entra ID non produce informazioni dettagliate sui log di controllo.

    1. Vai alla pagina Pool di identità per la forza lavoro:

      Vai a Pool di identità per la forza lavoro

    2. Nella tabella, seleziona il pool.

    3. Fai clic sul pulsante di attivazione/disattivazione Enable detailed audit logging (Attiva il logging dettagliato degli audit) in modo che sia impostato su On.

    4. Fai clic su Save pool (Salva pool).

  3. Nella sezione Providers, fai clic sull'Sign in URL (URL di accesso) del tuo provider e accedi alla console Google Cloud come utente del pool di forza lavoro.

  4. Visualizza gli audit log generati al momento dell'accesso.

    1. Vai alla pagina Pool di identità per la forza lavoro:

      Vai a Pool di identità per la forza lavoro

    2. Nella tabella, seleziona il pool a cui hai eseguito l'accesso.

    3. Fai clic su View (Visualizza) accanto a Logs (Log).

    4. Nella pagina degli audit log, cancella il filtro protoPayload.resourceName dalla query.

    5. Fai clic su Esegui query.

  5. Controlla gli audit log per una voce con il metodo google.identity.sts.SecurityTokenService.WebSignIn che corrisponde al timestamp di accesso.

  6. Verifica che il campo metadata.mapped_attributes nel log corrisponda all'attributo che hai utilizzato durante la configurazione della federazione delle identità per la forza lavoro per i provider di identità di terze parti.

    Ad esempio:

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

Limitazioni

Quando colleghi le origini dati utilizzando un connettore per creare datastore, si applicano le seguenti limitazioni:

  • Sono consentiti 3000 lettori per documento. Ogni entità viene conteggiata come lettore, dove un'entità può essere un gruppo o un singolo utente.

  • Puoi selezionare un tipo di provider di identità per ogni località supportata in Gemini Enterprise.

  • Se le impostazioni del provider di identità vengono aggiornate modificando il tipo di provider di identità o il pool di forza lavoro, i datastore esistenti non verranno aggiornati automaticamente con le nuove impostazioni. Devi eliminare e ricreare questi datastore per applicare le nuove impostazioni dell'identità.

  • Per impostare un'origine dati come controllata dall'accesso, devi selezionare questa impostazione durante la creazione del datastore. Non puoi attivare o disattivare questa impostazione per un datastore esistente.

  • Per visualizzare l'anteprima dei risultati dell'interfaccia utente per le app di ricerca che utilizzano il controllo dell'accesso di terze parti, devi accedere alla console federata o utilizzare l'app web. Consulta Visualizzare l'anteprima dell'app.

Connettersi al provider di identità

La sezione seguente descrive come connettersi al tuo provider di identità utilizzando la consoleGoogle Cloud .

Prima di iniziare

Prima di connettere il provider di identità:

  • Concedere le autorizzazioni agli amministratori.

  • Se stai connettendo un provider di identità di terze parti utilizzando la federazione delle identità per la forza lavoro, configura la federazione delle identità per la forza lavoro.

Connetti il provider di identità

Per specificare un provider di identità per Gemini Enterprise e attivare il controllo dell'accesso dell'accesso all'origine dati:

  1. Nella console Google Cloud , vai alla pagina Gemini Enterprise.

    Gemini Enterprise

  2. Fai clic su Settings (Impostazioni) > Authentication (Autenticazione).

  3. Fai clic su Add identity provider (Aggiungi provider di identità) per la sede che vuoi aggiornare.

  4. Fai clic su Add identity provider (Aggiungi provider di identità) e seleziona il tipo di provider di identità.
    Se selezioni 3rd party identity (Identità di terze parti), devi anche selezionare il pool di forza lavoro che si applica alle tue origini dati.

  5. Fai clic su Salva modifiche.

Concedi autorizzazioni agli utenti

Gli utenti devono disporre del ruolo Utente Gemini Enterprise (roles/discoveryengine.agentspaceUser) per accedere, gestire e condividere le app.

Tipo di provider di identità Descrizione
Google Identity
Provider di identità di terze parti

Impatto delle modifiche alle impostazioni del provider di identità sui connettori di importazione

Quando modifichi le impostazioni dell'identità, ad esempio il provider di identità o il pool di federazione delle identità per la forza lavoro, i datastore esistenti che utilizzano l'importazione dei dati non vengono aggiornati automaticamente. Per applicare le nuove impostazioni dell'identità, devi eliminare e ricreare i datastore interessati.

La tabella seguente riepiloga le modifiche all'impostazione dell'identità che richiedono la ricreazione del datastore:

Tipo di modifica Richiede la ricreazione del datastore
Passaggio da Google Identity a un provider di identità di terze parti Sì
Passaggio completo a un nuovo pool di federazione delle identità per la forza lavoro Sì
Modifica del mapping degli attributi all'interno del provider di identità corrente No
Passaggio a un nuovo provider all'interno dello stesso pool di federazione delle identità per la forza lavoro. Ad esempio, utilizzando Entra anziché Okta. No

Modifiche all'identità utente

Gemini Enterprise associa la cronologia della chat, i notebook e gli agenti creati da un utente all'identificatore principale dell'utente. Se utilizzi la federazione delle identità per la forza lavoro, l'identificatore entità include il valore che la mappatura degli attributi assegna a google.subject. Ad esempio:

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

Impatto di una modifica del valore dell'oggetto

Se il valore mappato a google.subject cambia per un utente, Gemini Enterprise lo considera un nuovo utente. Ad esempio, ciò si verifica quando il nome principale utente (UPN) o l'indirizzo email dell'utente cambia in Microsoft Entra ID e la mappatura degli attributi utilizza questo attributo. Gli identificatori dell'entità sono sensibili alle maiuscole, quindi anche una modifica delle maiuscole e minuscole è una modifica.

Dopo la modifica, si applica quanto segue:

  • L'utente non può accedere alla cronologia chat, ai notebook o agli agenti associati all'identificatore principale precedente.
  • Gemini Enterprise non esegue la migrazione dei dati dal precedente identificatore principale al nuovo identificatore principale.
  • Le licenze e i ruoli IAM concessi all'identificatore dell'entità precedente non si applicano al nuovo identificatore dell'entità.

Prepararsi a una modifica del valore del soggetto

Per ridurre l'impatto di una modifica del valore dell'oggetto:

Risolvere i problemi relativi agli errori di autenticazione

Se gli utenti ricevono errori HTTP 401 che segnalano credenziali di autenticazione non valide quando accedono a Gemini Enterprise, controlla quanto segue.

Controlli di base

  • Stato del browser: chiedi all'utente di svuotare la memorizzazione nella cache del browser ed eliminare i cookie oppure di accedere da una finestra di navigazione privata o in incognito.
  • Account con accesso eseguito: assicurati che l'utente acceda con l'account previsto dalla configurazione del tuo identity provider. Se utilizzi la federazione delle identità della forza lavoro, l'identità dell'utente deve corrispondere al mapping degli attributi.
  • Orologio del dispositivo: assicurati che l'orologio del dispositivo sia sincronizzato, ad esempio utilizzando il protocollo NTP (Network Time Protocol). La deriva dell'orologio sul dispositivo può causare un errore di autenticazione.

Norme di rete e del provider di identità

  • Proxy e firewall: proxy, firewall o gateway web sicuri che ispezionano il traffico TLS possono rimuovere o modificare l'intestazione Authorization. Assicurati che questi dispositivi non modifichino le richieste ai domini Google.
  • Policy di accesso del provider di identità: controlla se le policy di accesso nel tuo provider di identità, ad esempio le policy di accesso condizionale in Microsoft Entra ID, bloccano l'accesso a causa della conformità del dispositivo, degli intervalli di indirizzi IP o della posizione.
  • Accesso sensibile al contesto: se la tua organizzazione utilizza l'accesso sensibile al contesto con Google Cloud o Google Workspace, verifica se un livello di accesso basato sull'IP blocca le richieste effettuate da Gemini Enterprise per conto dell'utente. Queste richieste provengono dai server di Google, non dalla rete dell'utente, quindi non corrispondono agli intervalli IP aziendali. Aggiungi un livello di accesso che consenta l'ID client OAuth 2.0 utilizzato da Gemini Enterprise, combinato con il livello di accesso basato su IP come condizione OR. Le richieste rifiutate vengono visualizzate negli audit log della tua organizzazione per contextawareaccess.googleapis.com.
  • Risoluzione DNS: assicurati che i resolver DNS risolvano correttamente i domini Google, inclusi *.google.com e *.googleapis.com.

Raccogliere informazioni diagnostiche

Se l'errore persiste, acquisisci un file HAR (HTTP Archive) e i log della console del browser mentre riproduci l'errore, quindi contatta l'assistenza clienti Google Cloud. I file HAR possono contenere informazioni sensibili, come cookie e token.

Passaggi successivi