Identitätsanbieter konfigurieren

Um die Zugriffssteuerung für Datenquellen zu erzwingen und Daten in Gemini Enterprise zu schützen, müssen Sie einen Identitätsanbieter konfigurieren. Dazu müssen Sie den Identitätsanbieter einrichten und die Berechtigungen für Ihre Datenquellen verwalten. Google verwendet Ihren Identitätsanbieter, um den Endnutzer zu identifizieren, der eine Suche durchführt, und um festzustellen, ob dieser Zugriff auf die Dokumente hat, die als Ergebnisse zurückgegeben werden.

Identitätsanbietertyp auswählen

Der Typ des Identitätsanbieters, den Sie auswählen, hängt von den Datenquellen ab, die mit Ihrer Gemini Enterprise-App verbunden sind. Gemini Enterprise unterstützt folgende Optionen:

Typ des Identitätsanbieters Geeignet für
Google-Identität Google Identity ist der empfohlene Identitätsanbieter für Gemini Enterprise.

Google Identity unterstützt:
  • Alle Google-Quellen für selbst erhobene Daten, die Datenaufnahme oder Datenföderation verwenden. Sie müssen Google Identity verwenden, wenn Sie eine Verbindung zu Google Workspace-Datenquellen herstellen.
  • Alle Datenquellen von Drittanbietern, die Datenföderation verwenden, wobei sich Nutzer direkt beim Drittanbieterdienst über OAuth authentifizieren.
  • Alle Drittanbieter-Datenquellen, die die Datenaufnahme verwenden, mit Ausnahme von Microsoft 365-Datenquellen wie SharePoint, OneDrive oder Outlook, für die Microsoft Entra ID und Workforce Identity Federation erforderlich sind.
Bevor Sie Google Identity konfigurieren, müssen Sie das eindeutige Nutzerattribut Ihrer Organisation ermitteln, in der Regel die E-Mail-Adresse des Nutzers. Wenn Nutzer mehr als eine E-Mail-Adresse haben, müssen Sie einen E-Mail-Alias hinzufügen.
Externer Identitätsanbieter Wenn Sie Gemini Enterprise nur mit Datenquellen von Drittanbietern verbinden und bereits einen Drittanbieter-Identitätsanbieter verwenden, der OIDC oder SAML 2.0 unterstützt, z. B. Microsoft Entra ID, Okta oder AD FS, können Sie entweder Google Identity oder die Mitarbeiteridentitätsföderation verwenden. Google empfiehlt, für neue Einrichtungen Google Identity zu verwenden. Bestandskunden, die bereits die Workforce Identity-Föderation verwenden, können sich dafür entscheiden, diese weiterhin zu nutzen. Weitere Informationen finden Sie unter Workforce Identity-Föderation.

Bevor Sie die Workforce Identity-Föderation konfigurieren, müssen Sie die eindeutigen Nutzerattribute Ihrer Organisation ermitteln und sie der Workforce Identity-Föderation zuordnen.

Zugriffssteuerung für Google Workspace-Connectors

Wenn Sie die Fundierung mit Unternehmensdaten und die Suche mit Google Workspace-Connectors (z. B. Personen aus Google Workspace oder Google Groups) verwenden, hält sich Gemini Enterprise strikt an die Zugriffskontrolllisten (ACLs) und Berechtigungen des Quellsystems.

Grundprinzip: Keine Rechteausweitung

Nutzer, die mit Gemini Enterprise interagieren, können nur Informationen sehen und Antworten auf Informationen fundieren, auf die sie bereits direkt in der Google Workspace-Quellanwendung zugreifen dürfen. Gemini Enterprise umgeht niemals die Zugriffssteuerung des Quellsystems und gewährt keine zusätzlichen Berechtigungen.

  • Personen aus Google Workspace (Verzeichnis): Die Sichtbarkeit von Nutzern in Such- und Fundierungsergebnissen richtet sich nach den Einstellungen für die Sichtbarkeit im Verzeichnis Ihrer Organisation. Wenn die Sichtbarkeit eines Nutzers im Google Workspace-Verzeichnis beispielsweise auf seine eigene Abteilung oder Organisationseinheit beschränkt ist, kann er mit Gemini Enterprise nur Kollegen innerhalb dieser Abteilung finden. Sie können keine Profile von Mitarbeitern in eingeschränkten Abteilungen aufrufen.

  • Google Groups:Die Inhaltssuche und Fundierung richten sich nach den Einstellungen für Gruppenmitgliedschaft und Zugriff. Nutzer können nur Inhalte aus Google Groups suchen und ansehen, in denen sie Mitglied sind und für die sie eine Leseberechtigung haben. Nichtmitglieder können Diskussionen aus privaten Gruppen nicht über Gemini Enterprise finden oder ansehen.

Wo Berechtigungen verwaltet werden

Sie konfigurieren die Einstellungen für die Zugriffssteuerung und Sichtbarkeit nicht in den Gemini Enterprise-Connector-Einstellungen in der Google Cloud Console. Stattdessen konfiguriert ein Google Workspace-Administrator die Berechtigungs-, Mitgliedschafts- und Sichtbarkeitseinstellungen im Quellsystem:

  • Sichtbarkeit des Nutzerprofils: Der Google Workspace-Administrator konfiguriert die Sichtbarkeit des Nutzerprofils in der Admin-Konsole. Weitere Informationen finden Sie unter Verzeichnisfreigabe einrichten.

  • Gruppenzugriff und -mitgliedschaft: Der Google Workspace-Administrator konfiguriert den Gruppenzugriff und die Gruppenmitgliedschaft in Google Groups oder in der Admin-Konsole. Weitere Informationen finden Sie unter Gruppen einrichten und verwalten.

Mitarbeiteridentitätsföderation für externe Identitätsanbieter

In diesem Abschnitt wird beschrieben, wie Sie die Mitarbeiteridentitätsföderation für Drittanbieter-Identitätsanbieter konfigurieren. Optional können Sie prüfen, ob die Einrichtung der Mitarbeiteridentitätsföderation wie erwartet funktioniert.

Identitätsföderation von Arbeitslasten konfigurieren

Weitere Informationen zum Konfigurieren der Mitarbeiteridentitätsföderation mit Ihrem Drittanbieter-Identitätsconnector finden Sie in den folgenden Ressourcen:

Identitätsanbieter Ressourcen
Entra ID
Okta
OIDC oder SAML 2.0

Attributzuordnung konfigurieren

Mit der Attributzuordnung können Sie Ihre Drittanbieter-Identitätsinformationen über die Mitarbeiteridentitätsföderation mit Google verbinden.

Beachten Sie beim Konfigurieren der Attributzuordnung in der Mitarbeiteridentitätsföderation Folgendes:

  • Das Attribut google.subject wird für die Attributzuordnung, die Lizenzzuweisung und die Freigabe von Notebooks verwendet. Wir empfehlen, google.subject der E-Mail-Adresse des Nutzers in Kleinbuchstaben zuzuordnen, da bei der Lizenzzuweisung zwischen Groß- und Kleinschreibung unterschieden wird.

  • Wenn Ihre Organisation mehrere eindeutige Kennungen hat, ordnen Sie diese eindeutigen Organisationskennungen über das Attribut attribute.as_user_identifier_number between 1 and 50 zu.

    Wenn Ihre Organisation beispielsweise sowohl E-Mail-Adressen als auch Principal Names als Nutzer-IDs in verschiedenen Anwendungen verwendet und der Principal Name in Ihrem Drittanbieter-Identitätsanbieter als preferred_username festgelegt ist, können Sie ihn mithilfe der Attributzuordnung der Workforce Identity-Föderation (z. B. attribute.as_user_identifier_1=assertion.preferred_username) Gemini Enterprise zuordnen.

Die folgenden Beispiele zeigen die erforderlichen Attributzuordnungen für gängige Identitätsanbieter. Sie können weitere Attributzuordnungen hinzufügen, um zusätzliche eindeutige Kennungen zu unterstützen, wie oben beschrieben.

  • Entra ID mit OIDC-Protokoll
    In diesem Beispiel wird die E-Mail-Adresse verwendet, um Nutzer klar zu identifizieren.

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

  • Entra ID mit OIDC-Protokoll
    In diesem Beispiel wird die E-Mail-Adresse verwendet, um Nutzer klar zu identifizieren.

    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 mit OIDC-Protokoll
    In diesem Beispiel wird die E-Mail-Adresse verwendet, um Nutzer klar zu identifizieren.

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

  • Okta mit SAML-Protokoll
    In diesem Beispiel wird die Subjekt-Assertion des JWT verwendet, um Nutzer klar zu identifizieren.

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

Optional: Einrichtung der Mitarbeiteridentitätsföderation prüfen

So prüfen Sie mit der Funktion zum Audit-Logging der Mitarbeiteridentitätsföderation, ob Anmeldungen erfolgreich waren und die Attributzuordnung korrekt ist:

  1. Aktivieren Sie Audit-Logs für die Security Token Service API für Datenzugriffsaktivitäten.

    1. Rufen Sie in der Google Cloud Console die Seite Audit-Logs auf:

      Zu Audit Logs

      Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift IAM & Admin lautet.

    2. Wählen Sie ein vorhandenes Projekt, einen Ordner oder eine Organisation in Google Cloud aus.
    3. Audit-Logs zum Datenzugriff aktivieren.
      1. Eine detaillierte Anleitung zum Aktivieren von Audit-Logs finden Sie in der Logging-Dokumentation.
      2. Wählen Sie für die Security Token Service API den Audit-Logtyp Administrator-Lesezugriff aus. Weitere Informationen finden Sie unter Beispiellogs für die Mitarbeiteridentitätsföderation.

  2. Aktivieren Sie das detaillierte Logging in Ihrem Personalpool. Das Feature „Erweiterte Gruppen für die Mitarbeiteridentitätsföderation“ für Microsoft Entra IDs erzeugt keine detaillierten Audit-Log-Informationen.

    1. Rufen Sie die Seite Mitarbeiteridentitätspools auf.

      Zu Workforce Identity-Pools

    2. Wählen Sie in der Tabelle den Pool aus.

    3. Stellen Sie den Button Detaillierte Audit-Logging aktivieren auf die Position „Ein“.

    4. Klicken Sie auf Pool speichern.

  3. Klicken Sie im Bereich Anbieter auf die Anmelde-URL für Ihren Anbieter und melden Sie sich als Nutzer des Personalpools in der Google Cloud Konsole an.

  4. Sehen Sie sich die Audit-Logs an, die bei Ihrer Anmeldung generiert wurden.

    1. Rufen Sie die Seite Mitarbeiteridentitätspools auf.

      Zu Workforce Identity-Pools

    2. Wählen Sie in der Tabelle den Pool aus, in dem Sie sich angemeldet haben.

    3. Klicken Sie neben Logs auf Ansehen.

    4. Entfernen Sie auf der Seite „Audit-Log“ den protoPayload.resourceName-Filter aus der Abfrage.

    5. Klicken Sie auf Abfrage ausführen.

  5. Suchen Sie in den Audit-Logs nach einem Eintrag mit der google.identity.sts.SecurityTokenService.WebSignIn-Methode, der mit dem Zeitstempel der Anmeldung übereinstimmt.

  6. Prüfen Sie, ob das Feld metadata.mapped_attributes im Log mit dem Attribut übereinstimmt, das Sie beim Konfigurieren der Mitarbeiteridentitätsföderation für Drittanbieter-Identitätsanbieter verwendet haben.

    Beispiel:

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

Beschränkungen

Wenn Sie Ihre Datenquellen über einen Connector verbinden, um Datenspeicher zu erstellen, gelten folgende Einschränkungen:

  • Pro Dokument sind 3.000 Leser zulässig. Jedes Hauptkonto zählt als ein Leser. Ein Hauptkonto kann eine Gruppe oder ein einzelner Nutzer sein.

  • Sie können pro im Gemini Enterprise-Agentspace unterstütztem Standort (global, us oder eu) einen Identitätsanbietertyp auswählen. Wenn Sie die Mitarbeiteridentitätsföderation verwenden, muss der Workforce Identity-Pool selbst am Standort global (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>) erstellt werden und kann mit jedem unterstützten Gemini Enterprise-Standort verknüpft werden.

  • Wenn die Einstellungen des Identitätsanbieters durch Ändern des Identitätsanbietertyps oder des Personalpools aktualisiert werden, werden vorhandene Datenspeicher nicht automatisch auf die neuen Einstellungen aktualisiert. Sie müssen diese Datenspeicher löschen und neu erstellen, um die neuen Identitätseinstellungen anzuwenden.

  • Wenn Sie eine Datenquelle als zugriffsgesteuert festlegen möchten, müssen Sie diese Einstellung beim Erstellen des Datenspeichers auswählen. Sie können diese Einstellung für vorhandene Datenspeicher weder aktivieren noch deaktivieren.

  • Wenn Sie eine Vorschau der UI-Ergebnisse für Suchanwendungen anzeigen möchten, die die Zugriffssteuerung von Drittanbietern verwenden, müssen Sie sich in der föderierten Konsole anmelden oder die Web-App verwenden. Weitere Informationen finden Sie unter App als Vorschau.

Verbindung zu Ihrem Identitätsanbieter herstellen

Im folgenden Abschnitt wird beschrieben, wie Sie über die Google Cloud -Console eine Verbindung zu Ihrem Identitätsanbieter herstellen.

Hinweis

Führen Sie vor dem Herstellen einer Verbindung zum Identitätsanbieter folgende Schritte aus:

  • Administratoren Berechtigungen erteilen

  • Wenn Sie einen externen Identitätsanbieter über die Mitarbeiteridentitätsföderation verbinden, konfigurieren Sie die Mitarbeiteridentitätsföderation.

Identitätsanbieter verbinden

So geben Sie einen Identitätsanbieter für Gemini Enterprise an und aktivieren die Zugriffssteuerung für Datenquellen:

  1. Rufen Sie in der Google Cloud Console die Seite Gemini Enterprise auf.

    Gemini Enterprise

  2. Klicken Sie auf Einstellungen > Authentifizierung.

  3. Klicken Sie für den Gemini Enterprise-Standort (global, us oder eu), den Sie aktualisieren möchten, auf Identitätsanbieter hinzufügen.

  4. Klicken Sie auf Identitätsanbieter hinzufügen und wählen Sie den Typ Ihres Identitätsanbieters aus.
    Wenn Sie Drittanbieteridentität auswählen, wählen Sie den Personalpool (in global) aus, der für Ihre Datenquellen gilt.

  5. Klicken Sie auf Änderungen speichern.

Nutzern Berechtigungen erteilen

Nutzer benötigen die Rolle „Gemini Enterprise User“ (roles/discoveryengine.agentspaceUser), um auf Apps zuzugreifen, diese zu verwalten und freizugeben.

Typ des Identitätsanbieters Beschreibung
Google-Identität
  • Wenn Sie Google Identity verwenden, empfiehlt Google, eine Google-Gruppe zu erstellen, die alle Mitarbeiter enthält, die die App verwenden.
  • Als Google Workspace-Administrator können Sie alle Nutzer einer Organisation einer Google-Gruppe hinzufügen. Folgen Sie dazu der Anleitung unter Alle Nutzer Ihrer Organisation einer Gruppe hinzufügen.
  • Weisen Sie Nutzern die Rolle „Gemini Enterprise User“ (roles/discoveryengine.agentspaceUser) zu. Weitere Informationen zum Hinzufügen der Rolle finden sich unter Nutzern Berechtigungen erteilen.
Externer Identitätsanbieter
  • Weisen Sie Ihren Nutzern die Rolle „Gemini Enterprise User“ (roles/discoveryengine.agentspaceUser) zu und ebenso den Personalpoolnutzer in IAM-Richtlinien. Weitere Informationen zum Hinzufügen der Rolle finden sich unter Nutzern Berechtigungen erteilen.
  • Google empfiehlt, Gruppenansprüche für externe Identitäten zu konfigurieren.

Auswirkungen von Änderungen an den Einstellungen des Identitätsanbieters auf Ingestion-Connectors

Wenn Sie Identitätseinstellungen ändern, z. B. den Identitätsanbieter oder den Workforce Identity-Föderationspool, werden vorhandene Datenspeicher, die die Datenaufnahme verwenden, nicht automatisch aktualisiert. Damit die neuen Identitätseinstellungen angewendet werden, müssen Sie die betroffenen Datenspeicher löschen und neu erstellen.

In der folgenden Tabelle wird zusammengefasst, für welche Änderungen an den Identitätseinstellungen ein erneutes Erstellen des Datenspeichers erforderlich ist:

Art der Änderung Datenspeicher muss neu erstellt werden
Zwischen Google-Identität und externem Identitätsanbieter wechseln Ja
Vollständiger Wechsel zu einem neuen Workforce Identity-Föderationspool Ja
Attributzuordnung im aktuellen Identitätsanbieter bearbeiten Nein
Wechsel zu einem neuen Anbieter im selben Workforce Identity-Pool. Verwenden Sie beispielsweise Entra anstelle von Okta. Nein

Änderungen der Nutzeridentität

Gemini Enterprise verknüpft den Chatverlauf, die Notebooks und die von einem Nutzer erstellten Agenten mit der Haupt-ID des Nutzers. Wenn Sie die Mitarbeiteridentitätsföderation verwenden, enthält die Hauptkonto-ID den Wert, den Ihre Attributzuordnung google.subject zuweist. Beispiel:

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

Auswirkungen einer Änderung des Betreffwerts

Wenn sich der Wert, der google.subject zugeordnet ist, für einen Nutzer ändert, wird der Nutzer von Gemini Enterprise als neuer Nutzer behandelt. Das passiert beispielsweise, wenn sich der User Principal Name (UPN) oder die E-Mail-Adresse des Nutzers in Microsoft Entra ID ändert und Ihre Attributzuordnung dieses Attribut verwendet. Bei Hauptkonten wird zwischen Groß- und Kleinschreibung unterschieden. Eine Änderung der Groß- und Kleinschreibung ist also auch eine Änderung.

Nach der Änderung gilt Folgendes:

  • Der Nutzer kann nicht auf den Chatverlauf, die Notebooks oder die Agenten zugreifen, die mit der vorherigen Hauptkonto-ID verknüpft sind.
  • Gemini Enterprise migriert keine Daten von der vorherigen Hauptkonto-ID zur neuen Hauptkonto-ID.
  • Lizenzen und IAM-Rollen, die der vorherigen Hauptkonto-ID zugewiesen wurden, gelten nicht für die neue Hauptkonto-ID.

Auf eine Änderung des Betreffwerts vorbereiten

So reduzieren Sie die Auswirkungen einer Änderung des Subjektwerts:

  • Bevor Sie den UPN oder die E-Mail-Adresse eines Nutzers in Ihrem Identitätsanbieter ändern, informieren Sie den Nutzer und bitten Sie ihn, alle privaten Agenten oder Notebooks freizugeben, die er behalten möchte.
  • Weisen Sie der neuen Hauptkonto-ID eine Gemini Enterprise-Lizenz zu und gewähren Sie ihr die erforderlichen Rollen. Weitere Informationen finden Sie unter Nutzern Berechtigungen erteilen.
  • Übertragen Sie die Inhaberschaft der KI-Agenten, die der Nutzer für andere freigegeben hat, auf die neue Hauptkonto-ID. Sie können die Eigentümerschaft von Agenten, die nicht freigegeben sind, nicht übertragen.

Authentifizierungsfehler beheben

Wenn Nutzer beim Zugriff auf Gemini Enterprise HTTP-401-Fehler erhalten, die auf ungültige Authentifizierungsdaten hinweisen, prüfen Sie Folgendes.

Grundlegende Prüfungen

  • Browserstatus: Bitten Sie den Nutzer, den Browsercache zu leeren und die Cookies zu löschen oder sich über ein Inkognitofenster oder ein privates Browserfenster anzumelden.
  • Angemeldetes Konto: Der Nutzer muss sich mit dem Konto anmelden, das in der Konfiguration Ihres Identitätsanbieters erwartet wird. Wenn Sie die Mitarbeiteridentitätsföderation verwenden, muss die Identität des Nutzers mit Ihrer Attributzuordnung übereinstimmen.
  • Geräteuhr: Achten Sie darauf, dass die Geräteuhr synchronisiert ist, z. B. über das Network Time Protocol (NTP). Eine Zeitabweichung auf dem Gerät kann dazu führen, dass die Authentifizierung fehlschlägt.

Netzwerk- und Identitätsanbieterrichtlinien

  • Proxys und Firewalls: Proxys, Firewalls oder sichere Web-Gateways, die TLS-Traffic prüfen, können den Authorization-Header entfernen oder ändern. Achten Sie darauf, dass diese Geräte keine Anfragen an Google-Domains ändern.
  • Zugriffsrichtlinien des Identitätsanbieters: Prüfen Sie, ob Zugriffsrichtlinien in Ihrem Identitätsanbieter, z. B. Richtlinien für den bedingten Zugriff in Microsoft Entra ID, die Anmeldung aufgrund von Geräte-Compliance, IP-Adressbereichen oder Standort blockieren.
  • Kontextsensitiver Zugriff: Wenn Ihre Organisation den kontextsensitiven Zugriff mit Google Cloud oder Google Workspace verwendet, prüfen Sie, ob eine IP-basierte Zugriffsebene die Anfragen blockiert, die Gemini Enterprise im Namen des Nutzers stellt. Diese Anfragen stammen von Google-Servern, nicht vom Netzwerk des Nutzers. Sie stimmen daher nicht mit den IP-Bereichen des Unternehmens überein. Fügen Sie eine Zugriffsebene hinzu, die die von Gemini Enterprise verwendete OAuth 2.0-Client-ID in Kombination mit der IP-basierten Zugriffsebene als ODER-Bedingung zulässt. Abgelehnte Anfragen werden in den Audit-Logs Ihrer Organisation für contextawareaccess.googleapis.com angezeigt.
  • DNS-Auflösung: Achten Sie darauf, dass Ihre DNS-Resolver Google-Domains, einschließlich *.google.com und *.googleapis.com, korrekt auflösen.

Diagnoseinformationen erfassen

Wenn der Fehler weiterhin auftritt, erfassen Sie eine HAR-Datei (HTTP-Archiv) und die Browserkonsolenlogs, während Sie den Fehler reproduzieren, und wenden Sie sich dann an den Cloud Customer Care. HAR-Dateien können vertrauliche Informationen wie Cookies und Tokens enthalten.

Nächste Schritte