Architekturmuster für die Identitätsföderation

In diesem Dokument werden vier Architekturmuster für die Föderation von Google Cloudmit einem externen Identitätsanbieter (IdP) verglichen. Außerdem finden Sie hier Anleitungen, die Ihnen bei der Auswahl einer geeigneten Architektur für Ihren Anwendungsfall helfen.

Die vier Architekturmuster sind:

Entscheidungsfaktoren

Bei der Auswahl eines Architekturmusters, das für Ihre Organisation geeignet ist, sollten Sie mehrere Faktoren berücksichtigen, darunter die folgenden:

  • Dienstportfolio: Ihr Portfolio an Google-Diensten und ob es Google Workspace und Dienste überGoogle Cloudhinaus umfasst, z. B. Google Ads, Google Maps oder Chrome Enterprise.
  • Datenstandort: Ihre Anforderungen an Datenstandort und Datenhoheit.
  • Einbindung von Gemini Enterprise in Microsoft 365: Ihre Nutzung von Gemini Enterprise oder NotebookLM Enterprise und ob Sie planen, Gemini Enterprise in Microsoft 365-Dienste einzubinden.

Service portfolio

Die Authentifizierung und Autorisierung werden in Google-Diensten unterschiedlich verwaltet. Dies wirkt sich auf die Konfiguration der Identitätsföderation aus. Diese Unterschiede hängen von zwei Faktoren ab: dem Dienstmodell (SaaS im Vergleich zu PaaS und IaaS) und dem Autorisierungsmodell (IAM im Vergleich zu dienstspezifisch).

Servicemodelle

  • Software as a Service (SaaS): Google verwaltet Dienste wie Gmail, Google Ads oder die Gemini Enterprise-App vollständig. Diese Dienste erfordern keinen Entwicklungsaufwand und sind sofort einsatzbereit. Da SaaS-Dienste auf eine große Zielgruppe ausgerichtet sind, benötigen die meisten Ihrer Nutzer möglicherweise Zugriff darauf.
  • Platform as a Service (PaaS) oder Infrastructure as a Service (IaaS): Die meistenGoogle Cloud -Dienste sind PaaS oder IaaS. Mit diesen Diensten können technische Nutzer benutzerdefinierte Arbeitslasten entwickeln, bereitstellen und ausführen. Da diese Dienste auf ein technisches Publikum ausgerichtet sind, benötigt nur ein Teil Ihrer Nutzer Zugriff.

Autorisierungsmodelle

Google-Dienste implementieren die Autorisierung auf eine von zwei Arten:

  • IAM: Die meisten Google Cloud Dienste verwenden IAM, damit Administratoren den detaillierten Zugriff auf Ressourcen verwalten können.
  • Dienstspezifische Autorisierung: Dienste wie Google Ads, Looker oder Google Workspace verwenden IAM nicht. Stattdessen verwalten Administratoren den Zugriff mit Tools, die für jeden Dienst spezifisch sind.

Diese Faktoren führen zu den folgenden Dienstgruppen:

SaaS PaaS oder IaaS
IAM-basierte Autorisierung Google Cloud SaaS-Dienste wie die Gemini Enterprise-App und NotebookLM Enterprise Google Cloud PaaS- und IaaS-Dienste wie BigQuery oder Compute Engine
Dienstspezifische Autorisierung Google-Dienste, die nicht in der Cloud gehostet werden, z. B. Google Ads, Google Workspace und Google Maps Keine

Um ein Architekturmuster auszuwählen, das für Ihre Organisation geeignet ist, sollten Sie überlegen, welche Dienstgruppen für Ihre Organisation infrage kommen.

Datenstandort

Cloud Identity, Google Workspace und die Mitarbeiteridentitätsföderation verarbeiten personenbezogene Nutzerdaten, um Nutzer zu authentifizieren und Sitzungen zu verwalten. Diese Nutzerinformationen können Folgendes umfassen:

  • Nutzernamen oder E-Mail-Adressen
  • Nutzerattribute wie Vor- und Nachnamen
  • Gruppennamen und ‑mitgliedschaften

Cloud Identity, Google Workspace und die Mitarbeiteridentitätsföderation verarbeiten diese Daten gemäß den Bedingungen für Dienstdaten und speichern sie möglicherweise außerhalb der Standorte Ihrer Organisation oder Ihrer Nutzer:

  • In Cloud Identity und Google Workspace werden Dienstdaten in Google-Rechenzentren gespeichert und möglicherweise in allen Rechenzentren repliziert. Die gespeicherten Daten können Informationen enthalten, die für die Authentifizierung nicht unbedingt erforderlich sind, z. B. Abteilungsnamen, Adressen oder Telefonnummern.
  • Bei der Workforce Identity Federation werden Dienstdaten in Google Cloud-Regionen gespeichert und möglicherweise in allen Regionen repliziert.

Wenn Sie einem Nutzer Zugriff auf eine Ressource gewähren, speichert IAM seine Hauptkonto-ID in einer Rollenbindung. Google Cloud verarbeitet Rollenbindungen gemäß den Bedingungen für Dienstdaten und speichert sie möglicherweise in allen Google Cloud Regionen.

Die auf dieser Seite beschriebenen Architekturmuster erfordern die Speicherung von Nutzerinformationen, unterscheiden sich jedoch in der Dauer der Speicherung:

Bei vielen IdPs können Sie das Sperren oder Löschen von Nutzerkonten automatisieren, wenn sich der entsprechende Nutzerkontostatus im IdP ändert. Je nach Ihrem IdP und seiner Konfiguration kann das Löschen des Nutzerkontos bis zum Ablauf einer bestimmten Kulanzfrist verzögert werden. Dadurch kann sich die Dauer verlängern, in der Google Clouddiese Nutzerinformationen speichert.

Einbindung von Gemini Enterprise in Microsoft 365

Mit Gemini Enterprise können Sie über zwei Arten von Connectors eine Verbindung zu Microsoft 365-Diensten herstellen:

  • Connectors für die Datenaufnahme: Diese Connectors crawlen Microsoft 365, um einen Suchindex in Google Cloudzu erstellen. Wenn ein Nutzer einen Prompt sendet, verwendet Gemini Enterprise diesen Index, um nach Inhalten zu suchen. Der Zugriff wird lokal geprüft, indem die von Microsoft 365 abgerufenen Access Control Lists (ACLs) ausgewertet werden.
  • Föderierte Connectors: Diese Connectors fragen Microsoft 365 für jeden Prompt ab. Sie verwenden die delegierte Autorisierung, damit Microsoft 365 die Zugriffsprüfungen direkt ausführen kann.

Für Connectors, die auf der Datenaufnahme basieren, gelten bestimmte Anforderungen für die Nutzerföderation:

  • Berücksichtigung der Gruppenmitgliedschaft: Microsoft 365-ACLs können Einträge für Gruppen und Nutzer enthalten. Um zu prüfen, ob ein Nutzer auf Inhalte zugreifen kann, müssen Connectors alle Gruppen berücksichtigen, denen der Nutzer angehört. Wenn der Connector nur eine Teilmenge der Gruppen des Nutzers kennt, kann der Zugriff fälschlicherweise zugelassen oder verweigert werden.
  • Kennzeichenkonvertierung: Zum Auswerten von ACLs muss der Connector die von Microsoft 365 verwendeten Nutzer- und Gruppenkennzeichen in die von Google Cloudverwendeten Kennzeichen konvertieren.

Wenn Sie die Mitarbeiteridentitätsföderation verwenden, kann Gemini Enterprise Kennungen zuverlässig konvertieren und ACLs auswerten, wenn Sie Attributzuordnungen konfigurieren, die mit Gemini Enterprise kompatibel sind.

Wenn Sie die Cloud Identity- oder Google Workspace-Föderation verwenden, steuert Microsoft Entra ID die Attributzuordnungen für die Nutzer- und Gruppenbereitstellung und nicht Google Cloud. Entra bestimmt die Konvertierungsregeln für Nutzer- und Gruppenkennungen, die komplexe Transformationen umfassen können. Um eine ACL auszuwerten, muss der Gemini Enterprise-Connector dieselben Konvertierungsregeln anwenden. Der Connector hat jedoch keinen Einblick in die Entra-Konfiguration. Wenn Sie also die Cloud Identity- oder Google Workspace-Föderation verwenden, kann Gemini Enterprise Nutzer- und Gruppenkennungen nicht zuverlässig konvertieren und ACLs nicht zuverlässig auswerten.

Welches Architekturmuster für Ihre Organisation geeignet ist, hängt davon ab, wie Sie Gemini Enterprise nutzen und ob Sie planen, auf der Datenerfassung basierende Connectors zu verwenden.

Architekturmuster

Das folgende Flussdiagramm zeigt, wie diese Faktoren bestimmen, welches Muster die Anforderungen Ihrer Organisation erfüllt:

Flussdiagramm zur Auswahl des Musters für die Identitätsföderation.

  1. Nutzt ein erheblicher Teil Ihrer Organisation Google Workspace?

  2. Nutzen Sie neben Google Cloud auch andere Dienste wie Google Ads oder Google Maps?

    • Wenn Ja, fahren Sie mit Entscheidung 3 fort.
    • Falls Nein, fahren Sie mit Entscheidung 4 fort.

  3. Planen Sie, Gemini Enterprise zu verwenden und in Microsoft 365 einzubinden?

  4. Planen Sie, Gemini Enterprise zu verwenden?

  5. Haben Sie Anforderungen an den Speicherort von Daten, die Sie dazu verpflichten, die Speicherung von Nutzerinformationen zu minimieren?

Cloud Identity- oder Google Workspace-Föderation

Wählen Sie dieses Muster aus, wenn Ihre Organisation eines der folgenden Kriterien erfüllt:

  • Ein erheblicher Teil Ihrer Organisation nutzt bereits Google Workspace.
  • Sie verwenden Google-Dienste, die über Google Cloud hinausgehen, z. B. Google Ads oder Google Maps, planen aber nicht, Gemini Enterprise über Connectors auf Grundlage der Datenaufnahme in Microsoft 365 zu integrieren.
  • Sie verwenden nur Google Cloud -Dienste, planen nicht, Gemini Enterprise zu verwenden, und haben keine strengen Anforderungen an den Datenspeicherort, um die Speicherung von Nutzerdaten zu minimieren.

Bei diesem Muster wird die Mitarbeiteridentitätsföderation nicht verwendet. Stattdessen verbinden Sie Ihr Cloud Identity- oder Google Workspace-Konto mit Ihrem IdP und verwenden die Vorab-Nutzer- und Gruppenbereitstellung.

Architektur der Cloud Identity- und Google Workspace-Föderation.

Bei diesem Muster müssen Sie Nutzer und Gruppen bereitstellen, bevor sich Nutzer anmelden können. Andernfalls schlägt der Anmeldeversuch fehl:

  • Nutzerbereitstellung: Sorgt für ein rechtzeitiges Onboarding und Offboarding von Nutzern.
  • Gruppenbereitstellung: Mit Gruppen können Sie den Zugriff auf Google-Dienste und Google Cloud -Ressourcen verwalten.

Wenn nur ein Teil der Nutzer in Ihrer Organisation Google Workspace benötigt, fügen Sie Ihrem Konto sowohl ein Google Workspace- als auch ein Cloud Identity-Abo hinzu und weisen Sie nur den Nutzern, die Google Workspace benötigen, Google Workspace-Lizenzen zu.

Vorteile

  • Nutzer können sich bei Google-Diensten authentifizieren, unabhängig davon, ob diese Dienste IAM verwenden oder nicht. Legen Sie im Cloud Identity- oder Google Workspace-Konto fest, welche Google-Dienste Nutzer verwenden dürfen.
  • Sie können die Einmalanmeldung (SSO) und die Vorab-Bereitstellung auf eine Teilmenge von Nutzern beschränken und bestimmte Nutzer, z. B. Nutzer mit Notfallzugriff, weiterhin direkt in Cloud Identity oder Google Workspace verwalten.
  • Sie können Gruppen über Ihren externen IdP bereitstellen, Gruppen lokal in Ihrem Cloud Identity- oder Google Workspace-Konto verwalten oder beide Ansätze kombinieren.

Einschränkungen

  • Die Bereitstellung von Nutzerkonten im Voraus verursacht zusätzlichen Aufwand und kann den Onboarding-Prozess verlangsamen.

  • Sie können die Standorte, an denen Cloud Identity oder Google Workspace Nutzerdaten und Gruppendaten speichert, nicht steuern oder einschränken. Da Google Nutzer- und Gruppendaten gemäß den Bedingungen für Dienstdaten verarbeitet und speichert, fallen diese Daten nicht unter die Steuerelemente für die Datenregion. Google kann diese Daten an Google-Rechenzentrumsspeicherorten replizieren.

  • Gemini Enterprise bietet eingeschränkte Unterstützung für die Verbindung zu Microsoft-Datenquellen, wenn Sie die Cloud Identity-Föderation oder die Google Workspace-Föderation verwenden.

Workforce Identity-Föderation, ohne Synchronisierung

Wählen Sie dieses Muster aus, wenn Ihre Organisation die folgenden Kriterien erfüllt:

  • Sie nutzen nur Google Cloud -Dienste.
  • Sie verwenden Gemini Enterprise, möchten aber die Gruppenbeschränkungen Ihres IdP einhalten.
  • Sie haben Anforderungen an den Datenstandort, die eine Minimierung der Speicherung personenbezogener Nutzerinformationen erfordern.

Architektur der Workforce Identity-Föderation ohne Synchronisierung.

In diesem Muster verwenden Sie die Workforce Identity-Föderation, um IhreGoogle Cloud -Organisation mit Ihrem externen IdP zu verbinden.

Für dieses Muster ist keine Nutzer- oder Gruppenbereitstellung erforderlich. Jedes Mal, wenn sich ein Nutzer anmeldet, übergibt der Identitätsanbieter die erforderlichen Informationen zum Nutzer, einschließlich Gruppenmitgliedschaften und benutzerdefinierter Attribute, an Google Cloud. Google Cloud speichert diese Informationen nur für die Dauer der Nutzersitzung.

Vorteile

  • Sie müssen Nutzerkonten oder Gruppen nicht inGoogle Cloudspeichern oder verwalten.
  • Mit dem Muster können Sie Connectors auf Grundlage der Datenaufnahme verwenden, um Gemini Enterprise in Microsoft 365 zu integrieren.

Einschränkungen

  • Die Workforce Identity-Föderation ist ein IAM-Feature und ermöglicht Nutzern nur den Zugriff auf Dienste, die IAM verwenden. Nutzer, die sich über die Mitarbeiteridentitätsföderation authentifizieren, können nicht auf Google-Dienste wie Google Ads, Looker oder die Google Marketing Platform zugreifen.
  • Nutzer, die sich mit der Mitarbeiteridentitätsföderation authentifizieren, können nicht auf einige Google Cloud Funktionen zugreifen. Weitere Informationen finden Sie unter Identity-Föderation: Produkte und Einschränkungen.
  • Viele IdPs begrenzen die Anzahl der Gruppenmitgliedschaften, die sie in einer SAML-Assertion oder einem ID-Token an die Workforce Identity-Föderation übergeben können. Damit Sie diese Limits nicht überschreiten, müssen Sie möglicherweise die Gruppenverwaltung optimieren und die Arten von Gruppen einschränken, die in Zusicherungen oder Tokens enthalten sind.
  • Wenn Sie Ressourcen wie ein NotebookLM Enterprise-Notebook freigeben, können Sie nicht nach einer Gruppe anhand des Namens suchen. Stattdessen müssen Nutzer ihre Kennungen manuell eingeben.

Wenn Sie Microsoft Entra ID verwenden, können Sie eine Variante dieses Musters verwenden, indem Sie zusätzliche Attribute konfigurieren. Wenn Sie zusätzliche Attribute konfigurieren, führt die Workforce Identity-Föderation während der Nutzerauthentifizierung einen Rückruf an die Microsoft Graph API aus, um Gruppenmitgliedschaften abzurufen. Mit dieser Konfiguration können Sie die Gruppenmitgliedschaftsbeschränkungen von Entra für SAML-Assertionen und ID-Tokens umgehen und bis zu 999 Gruppenmitgliedschaften pro Nutzer verwenden.

Workforce Identity-Föderation mit SCIM

Wählen Sie dieses Muster aus, wenn Ihre Organisation die folgenden Kriterien erfüllt:

  • Sie nutzen nur Google Cloud -Dienste. Sie verwenden also keine externen Google-Dienste wie Google Ads oder Google Maps.
  • Sie möchten Gemini Enterprise oder NotebookLM Enterprise verwenden und benötigen Unterstützung für bis zu 2.000 Gruppenmitgliedschaften pro Nutzer oder die Möglichkeit, Gruppen beim Freigeben von Ressourcen anhand des Namens zu suchen.

Architektur der Mitarbeiteridentitätsföderation mit SCIM.

Bei diesem Muster verwenden Sie die Mitarbeiteridentitätsföderation, um IhreGoogle Cloud -Organisation zu föderieren. Wenn Sie die Anzahl der Gruppen erhöhen möchten, die Sie für Gemini Enterprise verwenden können, konfigurieren Sie SCIM so, dass Informationen zur Gruppenmitgliedschaft vorab bereitgestellt werden.

Vorteile

  • Mit dem Muster können Sie Connectors auf Grundlage der Datenaufnahme verwenden, um Gemini Enterprise in Microsoft 365 zu integrieren.
  • Sie können bis zu 2.000 Gruppenmitgliedschaften pro Nutzer verwenden,um den Zugriff auf Gemini Enterprise und NotebookLM Enterprise zu steuern und Zugriffsprüfungen durch Connectors durchführen zu lassen, die auf der Gemini Enterprise-Datenaufnahme basieren.
  • Wenn Sie Ressourcen wie ein NotebookLM Enterprise-Notebook freigeben, können Sie Gruppen anhand des Namens suchen, um die Nutzerfreundlichkeit zu verbessern.

Einschränkungen

  • Die Unterstützung für SCIM-bereitgestellte Gruppen ist auf Gemini Enterprise und NotebookLM Enterprise beschränkt. Andere Dienste können nur die Gruppenmitgliedschaften nutzen, die Ihr IdP in der SAML-Assertion oder dem ID-Token übergibt.
  • Die Workforce Identity-Föderation ist ein IAM-Feature und ermöglicht Nutzern nur den Zugriff auf Dienste, die IAM verwenden. Nutzer, die sich über die Mitarbeiteridentitätsföderation authentifizieren, können nicht auf Google-Dienste wie Google Ads, Looker oder die Google Marketing Platform zugreifen.
  • Nutzer, die sich mit der Mitarbeiteridentitätsföderation authentifizieren, können nicht auf alle Google Cloud -Funktionen zugreifen. Weitere Informationen finden Sie unter Identitätsföderation: Produkte und Einschränkungen.

Hybrid Cloud Identity und Mitarbeiteridentitätsföderation

Wählen Sie dieses Muster aus, wenn Ihre Organisation die folgenden Kriterien erfüllt:

  • Sie verwenden Google-Dienste, die über Google Cloud hinausgehen, z. B. Google Ads oder Google Maps.
  • Sie möchten Gemini Enterprise verwenden und in Microsoft 365 einbinden.

Architektur der hybriden Cloud Identity- und Mitarbeiteridentitätsföderation.

Bei diesem Muster werden zwei der vorherigen Muster kombiniert:

  • Sie verwenden die Mitarbeiteridentitätsföderation (synchronisationsfrei oder mit SCIM), um den Zugriff auf Gemini Enterprise und NotebookLM Enterprise zu verwalten.
  • Sie verwenden die Cloud Identity- oder Google Workspace-Föderation, um den Zugriff auf andere Dienste zu verwalten, einschließlich Google Cloud und nicht cloudbasierter Google-Dienste.

Vorteile

Mit diesem Muster lassen sich die Vorteile der beiden vorherigen Muster kombinieren:

  • Sie können Gemini Enterprise ohne Funktionseinschränkungen mit Microsoft-Datenquellen verbinden.
  • Nutzer können sich bei Google-Diensten authentifizieren, unabhängig davon, ob diese Dienste IAM verwenden oder nicht.
  • Alle Google Cloud Funktionen nutzen

Einschränkungen

  • Sie müssen zwei separate Relying-Party-Konfigurationen in Ihrem externen IdP verwalten: eine für Cloud Identity und eine für die Workforce Identity-Föderation.
  • Je nachdem, ob Sie einen Nutzer für die Verwendung von Cloud Identity oder der Mitarbeiteridentitätsföderation konfigurieren, kann sich die Anmeldung unterscheiden.
  • Bei der Verwaltung von IAM-Zulassungsrichtlinien müssen Sie je nach Authentifizierungsmethode des Nutzers unterschiedliche Hauptkonto-IDs verwenden. Ein Nutzer, der in Ihrem externen IdP als bob@example.com bekannt ist, kann in IAM beispielsweise die Prinzipal-ID bob@example.com oder principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID haben, je nachdem, ob er sich mit der Cloud Identity-Föderation oder der Mitarbeiteridentitätsföderation authentifiziert.
  • Sie können keine Gruppen erstellen, die sowohl Cloud Identity-Nutzer als auch Workforce Identity-Föderationsprinzipale enthalten. Cloud Identity-Gruppen können nur Cloud Identity-Nutzer und Mitarbeiteridentitätsgruppen nur Workforce Identity Federation-Principals enthalten.
  • Wenn die Mitarbeiteridentitätsföderation über Gemini Enterprise hinaus verwendet wird, müssen Nutzer möglicherweise zwischen Identitäten wechseln oder wissen nicht, wie sie sich authentifizieren sollen.

Nächste Schritte