Best Practices für die Verwendung der Workforce Identity-Föderation

Bei der Workforce Identity-Föderation wird Ihre Google Cloud Organisation mit einem externen Identitätsanbieter (IdP) zusammengeführt, um die Einmalanmeldung (Single Sign-On, SSO) zu ermöglichen.

Mit diesen Best Practices können Sie die Mitarbeiteridentitätsföderation effektiv nutzen und Sicherheitsrisiken minimieren.

Die richtige Architektur auswählen

In den folgenden Abschnitten werden die wichtigsten Faktoren für die Auswahl einer Föderationsarchitektur beschrieben, die Ihren Anforderungen entspricht.

Überlegungen zur Architektur:

Föderationsarchitekturmuster auswählen
Partitionieren Sie die Föderierungsnutzung nach Dienst und nicht nach Nutzer.

Muster für die Föderationsarchitektur auswählen

Die folgenden vier Muster beschreiben gängige Möglichkeiten, eine Google Cloud-Organisation mit einem externen IdP zu verbinden:

Bevor Sie die Föderation einrichten, sollten Sie die Vor- und Nachteile der einzelnen Muster abwägen und das Muster auswählen, das Ihren Anforderungen entspricht. Weitere Informationen finden Sie unter Architekturmuster für die Identitätsföderation.

Nutzung der Partitionsföderation nach Dienst

Im Allgemeinen empfehlen wir, die Föderationsnutzung nach Dienst und nicht nach Nutzer zu partitionieren. Die Aufteilung der Nutzung nach Dienst hat insgesamt weniger Nachteile.

Um die Komplexität zu verringern, empfehlen wir, entweder Cloud Identity oder die Mitarbeiteridentitätsföderation zu verwenden. Je nach Ihren Anforderungen benötigen Sie möglicherweise jedoch beide parallel, wie im Hybridmuster beschrieben.

Wenn Sie die Cloud Identity-Föderation und die Mitarbeiteridentitätsföderation parallel verwenden, können Sie die Nutzung auf folgende Weise aufteilen:

  • Nach Nutzer partitionieren: Teilen Sie Ihre Nutzer in zwei Kohorten auf: eine mit Workforce Identity Federation und eine mit Cloud Identity-Föderation.

    • Vorteil: Jeder Nutzer hat eine einzige Identität für alle Google-Dienste und eine einzige Anmeldemethode.

    • Nachteile: Die Partitionierung nach Nutzern hat mehrere Nachteile, darunter:

      • Die Verwaltung von Zugriffsgruppen kann komplex sein, da IAM-Zulassungsrichtlinien eine Kombination aus Prinzipaltypen enthalten müssen und Sie nicht dieselben Gruppen für Cloud Identity- und Workforce Identity-Föderationsnutzer verwenden können.

      • Nutzer aus verschiedenen Kohorten können keine Links miteinander teilen, da in der Google Cloud -Konsole, Gemini Enterprise und anderen Tools je nach Anmeldemethode unterschiedliche URLs verwendet werden.

      • Nutzer aus verschiedenen Kohorten haben möglicherweise Zugriff auf unterschiedliche Funktionen.

  • Nach Dienst partitionieren: Konfigurieren Sie jeden Dienst, z. B.Google Cloud oder Gemini Enterprise, so, dass er ausschließlich Zugriff auf Nutzer der Mitarbeiteridentitätsföderation oder Cloud Identity-Nutzer gewährt, aber nie auf beide.

    • Vorteil: Die Verwaltung wird vereinfacht und es wird dafür gesorgt, dass alle Nutzer Zugriff auf dieselben Funktionen haben.
    • Nachteil: Einige Mitarbeiter benötigen möglicherweise zwei Identitäten: eine für die Mitarbeiteridentitätsföderation und eine für Cloud Identity.

Wir empfehlen, nach Dienst zu partitionieren und insbesondere Gemini Enterprise und NotebookLM Enterprise von anderen Diensten zu trennen. Gemini Enterprise und die Google Cloud Konsole sind separate Tools für unterschiedliche Aufgaben. Eventuelle Unterschiede bei den Anmeldevorgängen sollten sich nur minimal auf die Nutzerfreundlichkeit auswirken.

Um diese Partitionierung zu erzwingen, können Sie Einschränkungen für Organisationsrichtlinien verwenden.

Gruppengovernance stärken

Sie sollten den Zugriff mithilfe von Gruppen verwalten und klare Prozesse für die Verwaltung dieser Gruppen festlegen, um die Workforce Identity-Föderation effektiv zu nutzen.

Die Berechtigungen eines Nutzers für den Zugriff auf Ressourcen werden nicht während der Authentifizierung festgelegt. Stattdessen wird der Zugriff bewertet, wenn der Nutzer versucht, auf die Ressource zuzugreifen. Dabei werden die Richtlinien berücksichtigt, die mit dieser bestimmten Ressource verknüpft sind. Diese Richtlinien können Folgendes umfassen:

Richtlinien definieren den Zugriff für einzelne Hauptkonten oder Hauptkontogruppen:

  • Prinzipal: Ein authentifizierter Nutzer, der durch eine Prinzipal-ID identifiziert wird. Eine Workforce-Hauptkonto-ID sieht in etwa so aus: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    Die Prinzipal-ID enthält Folgendes:

    • POOL_ID: identifiziert einen Workforce Identity-Pool eindeutig.
    • SUBJECT: identifiziert einen bestimmten Nutzer eindeutig. Der Wert und das Format hängen von Ihrem IdP und der Attributzuordnung ab.

  • Hauptgruppe: Nutzer, die bestimmte Kriterien erfüllen. Die Workforce Identity-Föderation unterstützt drei Hauptkontogruppen: gruppenbasiert (Mitglieder einer Gruppe), attributbasiert und mit Platzhalter (alle Nutzer).

Der Zugriff auf einzelne Principals kann in bestimmten Situationen nützlich sein, lässt sich aber aus folgenden Gründen in der Regel nur schwer skalieren:

  • Wenn Sie Hauptkonten einzeln hinzufügen, werden Zulassungsrichtlinien immer umfangreicher und schwieriger zu verwalten.
  • Für die individuelle Zugriffsverwaltung sind häufige Änderungen an den „allow“-Richtlinien erforderlich.
  • Richtlinien können mit der Zeit immer uneinheitlicher werden.

Die Verwendung von gruppenbasierten Hauptkontosets für die skalierbare und effektive Zugriffsverwaltung bietet folgende Vorteile:

  • Sie können den Zugriff verwalten, indem Sie Mitglieder zu Gruppen hinzufügen oder daraus entfernen. Dazu können Sie Ihre vorhandenen Identitätstools und ‑prozesse verwenden.
  • Größe und Komplexität von Zulassungsrichtlinien reduzieren
  • Achten Sie darauf, dass Nutzer mit derselben Rolle denselben Ressourcenzugriff haben.

Wenn Sie Gruppen zum Verwalten des Zugriffs verwenden möchten, müssen Sie Ihren externen IdP auf bestimmte Weise konfigurieren und alle Einschränkungen beachten, die der IdP für Gruppen festlegt.

In den folgenden Abschnitten werden Best Practices für die effektive Verwendung von Gruppen und die Vermeidung von IdP-Beschränkungen beschrieben.

Best Practices:

Unterschiedliche Arten von Gruppen unterscheiden:
Zugriff auf Ressourcen mithilfe von Zugriffsgruppen gewähren:
Zugriff auf Ressourcen mit Erzwingungsgruppen einschränken
Verwenden Sie keine Organisations- und Zusammenarbeitsgruppen, um den Zugriff zu verwalten.
Organisationsgruppen und Gruppen für die Zusammenarbeit nur für Gemini Enterprise verwenden:

Unterschiedliche Arten von Gruppen unterscheiden

In der folgenden Liste werden vier Arten von Gruppen beschrieben, die häufig in Organisationen vorkommen:

  • Zugriffsgruppen: Werden nur verwendet, um Zugriff auf Google-Dienste oderGoogle Cloud -Ressourcen zu gewähren. Sie stellen Jobfunktionen dar und vereinfachen die Zuweisung von Rollen, die zum Ausführen dieser Jobfunktionen erforderlich sind.
  • Organisationsgruppen: Diese Gruppen stellen Teilmengen der Organisationsstruktur dar und basieren in der Regel auf Personaldaten. Sie können auf Abteilung, Berichtsstruktur, geografischem Standort oder anderen Organisationsgruppen basieren.
  • Zusammenarbeitsgruppen: Diese Gruppen repräsentieren Arbeitsgruppen, Projektmitglieder oder Nutzer, die an einem Projekt zusammenarbeiten oder ein bestimmtes Thema diskutieren möchten. Sie können für die E-Mail-Verteilung verwendet werden. Zusammenarbeitsgruppen werden oft ad hoc und im Selfservice erstellt.
  • Erzwingungsgruppen: Erzwingungsgruppen, auch Richtliniengruppen genannt, werden verwendet, um den Zugriff einzuschränken. Zugriffsgruppen werden dagegen verwendet, um den Zugriff zu gewähren. Dazu gehören beispielsweise Principal Access Boundary-Richtlinien, Ablehnungsrichtlinien oder das Erzwingen der Multi-Faktor-Authentifizierung. In Zugriffsgruppen können Mitglieder eine Gruppe freiwillig verlassen. Die Mitgliedschaft in einer Enforcement-Gruppe ist jedoch nicht freiwillig.

Die Gruppen, die Sie föderieren müssen, hängen von den folgenden Diensten ab, die Sie verwenden:

  • Für Google Cloudbenötigen Sie nur Zugriffsgruppen und Erzwingungsgruppen.
  • Für Gemini Enterprise benötigen Sie Zugriffsgruppen, Erzwingungsgruppen und, wenn Sie auf der Datenerfassung basierende Connectors verwenden, bestimmte Organisations- und Kollaborationsgruppen.

Wenn Sie die Mitarbeiteridentitätsföderation konfigurieren, schließen Sie irrelevante Gruppentypen aus, um Tokenlimits bei Ihrem IdP zu vermeiden. So können Sie das Risiko verringern, dass Sie die von Ihrem IdP auferlegten Einschränkungen überschreiten, und eine konsistentere Verwendung von Gruppen sicherstellen.

Zugriff auf Ressourcen mithilfe von Zugriffsgruppen gewähren

Um den Zugriff effektiv zu verwalten, empfehlen wir die Verwendung von Prinzipalsets, die Zugriffsgruppen zugeordnet sind. Zugriffsgruppen dienen ausschließlich dazu, Zugriff zu gewähren. Sie stellen Jobfunktionen dar und vereinfachen die Zuweisung der Rollen, die zum Ausführen dieser Funktionen erforderlich sind.

So konfigurieren Sie Zugriffsgruppen:

  1. Erstellen Sie in Ihrem IdP Zugriffsgruppen, die Jobfunktionen darstellen.
  2. Ordnen Sie die Zugriffsgruppen den Prinzipalgruppen zu, damit Sie sie in IAM verwenden können.
  3. Erstellen Sie Richtlinienbindungen, um den Hauptkontengruppen Zugriff auf die Ressourcen zu gewähren, die für die einzelnen Aufgabenbereiche erforderlich sind.
  4. Fügen Sie im externen IdP Nutzer basierend auf ihren Aufgaben den Gruppen hinzu oder entfernen Sie sie daraus.

Verwenden Sie Zugriffsgruppen für Richtlinien, die Zugriff gewähren, einschließlich der folgenden:

  • IAM-Zulassungsrichtlinien
  • VPC Service Controls-Regeln für eingehenden Traffic

Achten Sie darauf, dass die Zugriffsgruppen ausreichend detailliert sind. Die folgenden Gruppen sind beispielsweise effektive Zugriffsgruppen:

  • widget-sales-dashboard-readers: Gewährt Lesezugriff auf ein bestimmtes BigQuery-Dataset und das zugehörige Dashboard.

  • dev-ssh-users: Gewährt OS Login-Zugriff auf Compute Engine-VMs in der Entwicklungsumgebung.

    Im Gegensatz dazu sind die folgenden Gruppentypen in der Regel nicht als Zugriffsgruppen geeignet:

    • Bei allgemeinen Administratorgruppen wie cloud-admins fehlt es oft an Spezifität in Bezug auf die Arbeitslasten oder Umgebungen, für die sie gelten.

    • Organisationsgruppen wie australia-fte stellen Gruppen wie Teams oder Standorte und nicht die Funktion dar.

    • Kommunikationsgruppen wie security-discuss sind für E-Mail-Listen oder die Zusammenarbeit konzipiert und nicht als Zugriffsgruppe.

    Um den Zugriff auf Gruppen detailliert zu steuern, erstellen Sie für jede Arbeitslast oder jedes Projekt, das Sie in Google Cloudeinbinden, eine neue Gruppe von Zugriffsgruppen. So können Sie die Anzahl der Zugriffsgruppen an die Anzahl der Arbeitslasten anpassen, die Sie auf Google Cloudausführen.

Zugriff auf Ressourcen mit Erzwingungsgruppen einschränken

Durchsetzungsgruppen ähneln Zugriffsgruppen, unterscheiden sich aber in der Regel in den folgenden Punkten:

  • Mitglieder können die Gruppe nicht freiwillig verlassen.
  • Sie sind nicht auf eine bestimmte Arbeitslast beschränkt.

Verwenden Sie Erzwingungsgruppen für Richtlinien, die den Zugriff einschränken, einschließlich der folgenden:

  • IAM-Ablehnungsrichtlinien
  • Begrenzungen des Prinzipalzugriffs
  • Organisationsrichtlinien

Beispiele für Durchsetzungsgruppen sind users-in-restricted-locations, fedramp-low und mfa-users. Die Anzahl der Erzwingungsgruppen ist in der Regel gering und hat wahrscheinlich keine Auswirkungen auf die Gesamtzahl der Gruppenmitgliedschaften eines Nutzers.

Organisations- und Kollaborationsgruppen nicht zum Verwalten des Zugriffs verwenden

Um den Zugriff effektiv zu verwalten, können Sie anstelle von Organisations- oder Kollaborationsgruppen Zugriffsgruppen und Erzwingungsgruppen verwenden.

Organisationsgruppen stellen Teams oder Teilmengen der Organisationsstruktur dar und basieren in der Regel auf Personaldaten. Diese Gruppen sind aus folgenden Gründen nicht geeignet, um den Zugriff auf Google Cloud Ressourcen zu verwalten:

  • Die Verantwortlichkeiten und Zusammensetzung des Teams können sich im Laufe der Zeit ändern. Beispielsweise kann ein Team eine Arbeitslast an ein anderes Team übergeben oder zwei Teams können zusammengeführt werden. Die Verwaltung des Zugriffs mit Organisationsgruppen kann während dieser Übergänge eine Kaskade von Richtlinienänderungen erfordern.
  • Mitglieder einer Organisationsgruppe benötigen selten identischen Zugriff auf Ressourcen. Wenn Sie einer Organisationsgruppe Zugriff gewähren, haben einige Mitglieder oft mehr Zugriff als nötig.

Zusammenarbeitsgruppen werden in der Regel selbst verwaltet. Mitglieder können der Gruppe beitreten, wenn ein anderes Mitglied dies genehmigt oder auch ohne Genehmigung. Wenn Sie Kollaborationsgruppen verwenden, um Zugriff zu gewähren, kann dies zu einer Überberechtigung und Rechteausweitung führen.

Wenn Sie verhindern möchten, dass Organisations- und Kollaborationsgruppen für die Zugriffsverwaltung verwendet werden, konfigurieren Sie Ihren IdP so, dass diese Gruppenmitgliedschaften in den Tokens oder Zusicherungen, die für die Mitarbeiteridentitätsföderation verwendet werden, ausgeschlossen werden.

Organisationsgruppen und Gruppen für die Zusammenarbeit nur für Gemini Enterprise verwenden

Obwohl Organisations- und Zusammenarbeitsgruppen nicht gut für die Verwaltung des Zugriffs auf Google Cloud Ressourcen geeignet sind, benötigen Sie sie möglicherweise für Gemini Enterprise:

  • ACL-Auswertung: Wenn Sie auf der Datenaufnahme basierende Connectors verwenden, um Gemini Enterprise in Microsoft 365 einzubinden, werden möglicherweise Dokumente mit Access Control Lists (ACLs) gefunden, die sich auf Organisations- und Kollaborationsgruppen beziehen. Wenn Gemini Enterprise keinen Zugriff auf die Mitgliedschaften eines Nutzers in diesen Gruppen hat, kann es möglicherweise nicht richtig beurteilen, ob der Nutzer berechtigt ist, auf diese Dokumente zuzugreifen.
  • Notebooks freigeben: Mit NotebookLM können Nutzer Notebooks freigeben. Es ist oft praktischer, Nutzern zu erlauben, Notebooks für Gruppen zur Zusammenarbeit freizugeben, als die Freigabe auf einzelne Nutzer zu beschränken.

Damit Organisations- und Kollaborationsgruppen nur in Gemini Enterprise verfügbar sind, können Sie Ihren IdP so konfigurieren:

  • Mit SCIM können Sie Organisations- und Kollaborationsgruppen sowie deren Mitglieder bereitstellen.
  • Schließen Sie Organisations- und Kollaborationsgruppenmitgliedschaften in den Tokens oder Zusicherungen aus, die für die Workforce Identity-Föderation verwendet werden.

Workforce Identity-Pools verwalten

Ein Workforce Identity-Pool definiert einen Namespace für Hauptkonto-IDs und dient als Container für Ihre Föderationskonfiguration. Im Gegensatz zu einem Nutzerverzeichnis werden in einem Pool keine Informationen zu Nutzern oder Gruppen gespeichert.

Best Practices:

Verwenden Sie einen einzelnen Pool pro IdP.
Wählen Sie einen eindeutigen und aussagekräftigen Poolnamen aus.
Pools als Ressourcen mit hohen Berechtigungen behandeln:
Risiken bei der Ausweitung der Föderation auf Partner berücksichtigen

Einen Pool pro IdP verwenden

Mitarbeiteridentitätspools sind Ressourcen auf Organisationsebene und nicht auf Projektebene. Dieses Design spiegelt wider, dass Workforce Identity-Pools die Authentifizierung für eine Google Cloud Organisation und nicht für ein einzelnes Projekt oder eine einzelne Arbeitslast verwalten.

In den meisten Organisationen sollte die Anzahl der Workforce Identity-Pools mit der Anzahl der IdPs übereinstimmen:

  • Wenn Ihre Organisation einen einzelnen IdP zur Verwaltung der Authentifizierung verwendet, sollten Sie einen einzelnen Workforce Identity-Pool verwenden.
  • Wenn Ihre Organisation mehrere IdPs verwendet, z. B. aufgrund einer Akquisition, verwenden Sie einen Mitarbeiteridentitätspool pro IdP.

Wenn Sie die Anzahl der Workforce Identity-Pools begrenzen, können Sie Folgendes sicherstellen:

  • Sie müssen keine Mitarbeiteridentitätspools erstellen oder ändern, wenn Sie neue Arbeitslasten in Google Cloudeinbinden.
  • Mit IAM können Sie steuern, auf welche Projekte und Ressourcen innerhalb von Google Cloud einzelne Nutzer zugreifen können.

Einen eindeutigen und aussagekräftigen Poolnamen auswählen

Damit Hauptkonto-IDs global eindeutig sind, wird der Name des Workforce Identity-Pools in die Hauptkonto-ID codiert. Beachten Sie bei der Auswahl eines Namens für einen Workforce Identity-Pool die folgenden Einschränkungen:

  • Eindeutigkeit: Wählen Sie einen Namen aus, der in Google Cloud eindeutig ist und nicht von einer anderen Organisation beansprucht wird.
  • Unveränderlichkeit: Sie können den Namen eines Workforce Identity-Pools nicht ändern. Wählen Sie einen Namen, der auch langfristig aussagekräftig ist, und vermeiden Sie Namen für vorübergehende Initiativen.
  • Nutzerfreundlichkeit: Je nach Anmeldekonfiguration müssen Nutzer bei der Anmeldung möglicherweise den Poolnamen eingeben. Wählen Sie einen kurzen, einprägsamen Namen.

Pools als Ressourcen mit hohen Berechtigungen behandeln

Der Workforce Identity-Pool und ‑Anbieter bestimmen, wie sich Nutzer anmelden, und steuern, wie Identitäten und Gruppenmitgliedschaften vom externen IdP abgeleitet werden. Da diese Komponenten die Authentifizierungslogik steuern, sind sie von zentraler Bedeutung für die Sicherheit Ihrer Google Cloud Organisation. Wenn diese Komponenten manipuliert werden, können böswillige Nutzer Spoofing-Angriffe starten.

Um einen Spoofing-Angriff durchzuführen, versuchen böswillige Akteure möglicherweise Folgendes:

  • Attributzuordnungen ändern: Wenn Attributzuordnungen geändert werden, kann ein böswilliger Akteur sich als eine andere Person authentifizieren und unberechtigten privilegierten Zugriff erhalten.
  • Schädlichen Anbieter hinzufügen: Wenn Sie einen Anbieter hinzufügen, kann ein böswilliger Akteur den IdP Ihrer Organisation umgehen und sich mit einem anderen IdP authentifizieren, den er kontrolliert.

Workforce Identity-Pools und -Anbieter sind sicherheitskritische Ressourcen, die folgenden Schutz erfordern:

  • Zugriff auf nicht föderierte Nutzer beschränken: Beschränken Sie den Administratorzugriff auf eine kleine Anzahl von Cloud Identity- oder Google Workspace-Nutzern, einschließlich mindestens eines Notfallzugriffsnutzers.
  • Administratoren schützen: Erzwingen Sie die Bestätigung in zwei Schritten für alle Administratoren und Nutzer mit Notfallzugriff.
  • Just-in-Time-Zugriff: Verwenden Sie Privileged Access Manager (PAM), um Administratorzugriff nur bei Bedarf und nicht dauerhaft zu gewähren.

Risiken bei der Ausweitung der Föderation auf Partner berücksichtigen

Durch die Föderation Google Cloud mit einem externen IdP über die Workforce Identity-Föderation wird eine Vertrauensstellung eingerichtet. Wenn Sie die Föderation verwenden, führt der externe IdP die folgenden Aktionen aus:

  • Führen Sie die Multi-Faktor-Authentifizierung (MFA) durch, die Ihren Sicherheitsanforderungen entspricht.
  • Genaue Aussagen zu Nutzeridentitäten und Gruppenzugehörigkeiten treffen.
  • Halten Sie sich an Prozesse zur Identitätsverwaltung, die dafür sorgen, dass Nutzer rechtzeitig deaktiviert werden und die Gruppenmitgliedschaften die aktuellen Rollen widerspiegeln.

Die Mitarbeiteridentitätsföderation bietet nur begrenzte Mechanismen zum Validieren der Zusicherungen eines externen IdP. Insbesondere wird die MFA nach der SSO-Anmeldung bei der Workforce Identity-Föderation nicht auf dieselbe Weise wie bei Cloud Identity unterstützt.

Bevor Sie die Mitarbeiteridentitätsföderation verwenden, um externen Partnern oder Auftragnehmern den Zugriff auf Ihre Google Cloud Ressourcen zu ermöglichen, sollten Sie prüfen, ob dieses Vertrauensniveau angemessen ist. Verwenden Sie die Workforce Identity-Föderation für den Partnerzugriff nur, wenn Sie dem Partner und seinem IdP vertrauen, dass sie Ihre Sicherheitsstandards durchgehend einhalten.

Workforce Identity-Pool-Anbieter verwalten

Ein Anbieter von Mitarbeiteridentitätspools definiert eine Föderationsbeziehung mit einem externen IdP und enthält die Konfiguration für Folgendes:

  • Der IdP, der für die Einmalanmeldung verwendet werden soll.
  • Die Attributzuordnung, die zum Ableiten von Prinzipal-IDs aus Tokens oder Assertions verwendet werden soll, die vom IdP bereitgestellt werden.
  • Optional: Der SCIM-Mandant, der zum Nachschlagen von Informationen zur Gruppenmitgliedschaft verwendet werden soll.

Best Practices:

Wählen Sie einen aussagekräftigen Anbieternamen aus.
Einzelne Dienste über das Anwendungsportal Ihres Identitätsanbieters verfügbar machen
Einzelnen Anbieter pro Pool verwenden, um Themenkonflikte zu vermeiden
Verwenden Sie denselben Pool und Anbieter für die Google Cloud Console und Gemini Enterprise.
Verwenden Sie einen mandantenspezifischen Aussteller-URI.
Vermeiden Sie die Verwendung des impliziten OpenID Connect-Ablaufs (OIDC).

Aussagekräftigen Anbieternamen auswählen

Wenn Sie einen Workforce Identity-Pool-Anbieter erstellen, müssen Sie ihm einen Namen zuweisen. Im Gegensatz zu Namen von Personalpools muss dieser Name nicht global eindeutig sein und wird nicht in Haupt-IDs codiert. Je nach Anmeldekonfiguration müssen Nutzer bei der Anmeldung jedoch möglicherweise den Namen des Anbieters eingeben. Um die Nutzerfreundlichkeit zu verbessern, sollten Sie einen aussagekräftigen, einprägsamen Namen wählen, z. B. entra oder staff.

Vermeiden Sie Namen wie oidc oder saml, da diese Akronyme für Nutzer möglicherweise nicht bekannt sind.

Einzelne Dienste im Anwendungsportal Ihres IdP präsentieren

Identitätsanbieter wie Microsoft Entra ID und Okta bieten ein Anwendungsportal, über das Nutzer die ihnen zugewiesenen Anwendungen finden und darauf zugreifen können. So optimieren Sie die Nutzerfreundlichkeit über das Portal:

  • Konfigurieren Sie das Portal so, dass relevante Google-Dienste einzeln anstatt als einzelner Google Cloud Link angezeigt werden.
  • Konfigurieren Sie Links, mit denen der Nutzer automatisch angemeldet wird.

In der folgenden Tabelle sind gängige Google-Dienste aufgeführt, die die Workforce-Identitätsföderation unterstützen, sowie die URLs für die automatische Anmeldung:

Anwendung URL
Google Cloud Console für die Mitarbeiteridentitätsföderation, auch als Console (föderiert) bezeichnet 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
IAP-Web-Apps App-URL, z. B. https://iap.example.com/

Ersetzen Sie Folgendes:

  • POOL: der Name des Workforce Identity-Pools.
  • PROVIDER: der Name des Poolanbieters.
  • WEBAPP_ID: die ID der Gemini Enterprise Web-App.
  • PROJECT_NUMBER: die NotebookLM Enterprise-Projektnummer.

Einzelnen Anbieter pro Pool verwenden, um Themenkonflikte zu vermeiden

Mit der Workforce Identity-Föderation können Sie einem Workforce-Pool mehrere Anbieter hinzufügen. Das Hinzufügen eines zweiten Anbieters ist bei Migrationen nützlich, bei denen Sie Nutzern vorübergehend erlauben, sich mit verschiedenen IdPs zu authentifizieren. Vermeiden Sie die Verwendung mehrerer Anbieter aus folgenden Gründen:

  • Themenkonflikte: Die Verwendung mehrerer Anbieter birgt das Risiko von Themenkonflikten. Bei solchen Konflikten gibt die Attributzuordnung für google.subject eines Anbieters denselben Wert zurück wie die eines anderen Anbieters. Bei dieser Kollision werden mehrere externe Identitäten demselben IAM-Hauptkonto zugeordnet. Dadurch sind die externen Identitäten in Cloud-Audit-Logs nicht mehr zu unterscheiden.
  • IAP-Kompatibilität: Für IAP ist es erforderlich, dass Workforce Identity-Pools einen einzelnen Anbieter haben, damit nicht authentifizierte Nutzer automatisch zum IdP weitergeleitet werden. Wenn Sie einen zusätzlichen Anbieter hinzufügen, kann IAP Nutzer nicht authentifizieren.

Wenn Sie eine Föderation mit mehreren Bereitstellern einrichten müssen, erstellen Sie mehrere Workforce-Pools und konfigurieren Sie für jeden Pool einen Bereitsteller.

Denselben Pool und Anbieter für die Google Cloud Console und Gemini Enterprise verwenden

Wenn Sie die Mitarbeiteridentitätsföderation sowohl für Gemini Enterprise als auch für Google Cloudverwenden, sollten Sie einen einzigen Anbieter nutzen, damit Nutzer gleichzeitig auf beide Dienste zugreifen können, ohne sich noch einmal anmelden zu müssen. Wenn Sie separate Anbieter mit unterschiedlichen Attributzuordnungen verwenden, kann es vorkommen, dass Nutzer je nach Anbieter, mit dem sie sich anmelden, unterschiedlichen Zugriff auf Ressourcen haben.

Mandantenspezifischen Aussteller-URI verwenden

Wenn Sie einen Anbieter konfigurieren, geben Sie einen Aussteller-URI an, um Ihren IdP eindeutig zu identifizieren. Je nach IdP-Konfiguration ist der Aussteller-URI jedoch möglicherweise nicht eindeutig für den Mandanten Ihrer Organisation. Wenn Sie beispielsweise einen generischen oder freigegebenen Aussteller-URI wie den gemeinsamen Microsoft Entra ID-Endpunkt (https://login.microsoftonline.com/common/v2.0) verwenden, erlauben Sie möglicherweise versehentlich Nutzern aus anderen Organisationen, sich bei Ihrer Google Cloud-Organisation zu authentifizieren.

Um unbeabsichtigte tenantübergreifende Zugriffe zu verhindern, verwenden Sie einen tenantspezifischen Aussteller-URI. Wenn Ihr IdP keinen mandantenspezifischen Aussteller-URI bereitstellt, konfigurieren Sie eine Attributbedingung, um den Zugriff auf Ihren spezifischen Mandanten zu beschränken.

Vermeiden Sie die Verwendung des impliziten OpenID Connect-Ablaufs (OIDC)

Wenn Sie einen OIDC-Anbieter konfigurieren, sollten Sie den Autorisierungscodefluss dem impliziten Ablauf vorziehen. Der implizite Vorgang ist in Version 2.1 der OAuth-Spezifikation veraltet, da er anfällig für Token-Lecks und ‑Injektionen ist. Durch die Verwendung des Autorisierungscode-Ablaufs wird das Risiko des Abfangens von Tokens verringert.

Nutzer verwalten

Sie können Nutzer mit der Workforce Identity-Föderation verwalten. Bei der Mitarbeiteridentitätsföderation wird die Prinzipal-ID eines Nutzers aus dem Token oder der Assertion des Nutzers abgeleitet. Dazu werden die folgenden Schritte ausgeführt:

  1. Bestimmen Sie die Subjekt-ID, indem Sie die Attributzuordnung für google.subject anwenden. Die Subjekt-ID muss einen Nutzer in einem Mitarbeiteridentitätspool eindeutig identifizieren, muss aber nicht Google Cloudeindeutig sein.

  2. Leiten Sie die Hauptkonto-ID ab, indem Sie die Betreff-ID an ein Präfix anhängen, das den Mitarbeiteridentitätspool identifiziert. Die resultierende Hauptkonto-ID ist für Google Cloud eindeutig und hat das folgende Format:

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

Wenn ein Nutzer, der sich über die Mitarbeiteridentitätsföderation authentifiziert hat, auf eine Ressource zugreift, verwendet IAM die Hauptkonto-ID, um Rollenbindungen in Zulassungsrichtlinien auszuwerten und in Cloud-Audit-Logs aufzuzeichnen.

Best Practices:

Unveränderliche Betreff-ID verwenden:
Subjekt-IDs nicht wiederverwenden:
Microsoft Entra ID: UPN als Subjekt-ID verwenden

Unveränderliche Subjekt-ID verwenden

Wenn sich die Subjekt-ID eines Nutzers ändert, ändert sich auch seine Haupt-ID. Daher werden sie von Google Cloud nicht mehr als derselbe Nutzer erkannt:

  • Der Nutzer kann nicht auf Ressourcen zugreifen, auf die er zuvor Zugriff hatte, da seine neue Hauptkonto-ID nicht mehr mit den Hauptkonto-IDs übereinstimmt, die in Zulassungsrichtlinien aufgeführt sind.
  • Cloud-Audit-Logs-Einträge enthalten nur die neue Hauptkonto-ID und können nicht mehr mit Logs korreliert werden, in denen die alte Hauptkonto-ID verwendet wurde.

Damit die primäre Kennung eines Nutzers stabil bleibt, verwenden Sie eine Attributzuordnung, die einen stabilen Wert für google.subject ergibt.

Viele IdPs generieren automatisch eine eindeutige numerische oder UUID-formatierte Kennung für Nutzer. Diese IDs sind eindeutig und stabil und eignen sich daher gut für google.subject. Wenn Sie diese Kennungen jedoch als google.subject verwenden, kann dies zu langen, kryptischen Hauptkonto-Kennungen führen, mit denen sich nur schwer arbeiten lässt.

Berücksichtigen Sie die folgenden Anforderungen in absteigender Priorität, um eine ID für google.subject auszuwählen:

  1. Eindeutigkeit: Der Wert identifiziert einen Nutzer in Ihrem IdP eindeutig.
  2. Nutzerfreundlichkeit: Der Wert ist aussagekräftig oder lässt sich zumindest leicht im Nutzerverzeichnis Ihres Identitätsanbieters finden.
  3. Unveränderlichkeit: Der Wert ist unveränderlich oder kann zumindest nur von Administratoren geändert werden.

Subjekt-IDs nicht wiederverwenden

Viele IdPs erzwingen Eindeutigkeitseinschränkungen für bestimmte Nutzerkennungen, erlauben aber die Wiederverwendung von Kennungen. Beispielsweise lässt ein IdP möglicherweise nicht zu, dass Sie zwei Nutzer mit demselben Nutzernamen bob erstellen. Nachdem Sie das Nutzerkonto bob gelöscht haben, können Sie im IdP möglicherweise ein neues Nutzerkonto erstellen und ihm den Nutzernamen bob zuweisen.

Wenn die Attributzuordnung Ihres Anbieters für google.subject auf eine Nutzer-ID verweist, die wiederverwendet werden kann, kann es zu Subject-Kollisionen kommen: Die Workforce Identity-Föderation kann nicht zwischen einem alten und einem neuen Nutzer unterscheiden, wenn deren google.subject identisch ist. Daher kann der neue Nutzer möglicherweise auf Ressourcen zugreifen, die nur für den alten Nutzer vorgesehen sind.

Führen Sie einen oder beide der folgenden Schritte aus, um Überschneidungen von Themen zu vermeiden:

Microsoft Entra ID: UPN als Subjekt-ID verwenden

Diese Best Practice gilt nur, wenn Sie Microsoft Entra ID als IdP verwenden.

Wenn Sie Microsoft Entra ID verwenden, können Sie die folgenden Kennungen als Subjektkennungen verwenden:

  • Benutzerprinzipalname (upn)
  • Objekt-ID (oid)
  • E‑Mail-Adresse (die primäre Adresse in proxyAddresses)

Von diesen Optionen empfehlen wir, den User Principal Name als Subjekt-ID zu verwenden. Das hat folgende Gründe:

  • Alle Nutzer haben einen User Principal Name.
  • Nutzerprinzipalnamen identifizieren einen Nutzer eindeutig.
  • User Principal Names sind in der Regel aussagekräftig und einfach zu verwenden.
  • Nutzerprinzipalnamen enthalten einen Domainnamen, der den Microsoft Entra ID-Mandanten, dem der Nutzer zugeordnet ist, eindeutig identifiziert.
  • Möglicherweise hat Ihre Organisation eine Richtlinie, die die Wiederverwendung von Nutzer-Hauptkonto-IDs verbietet oder regelt.

Die Objekt-ID und die E-Mail-Adresse eines Nutzers sind aus folgenden Gründen weniger geeignet:

  • Eine Objekt-ID (oid) ist unveränderlich, wird aber als GUID formatiert. Dieses Format ist schwer zu verarbeiten und für Menschen nicht aussagekräftig.
  • Die E-Mail-Adresse ist kein erforderliches Attribut und ist möglicherweise nicht für alle Nutzer vorhanden.

Unabhängig davon, welche Kennung Sie auswählen, empfehlen wir, keine Transformationen wie das Erzwingen von Kleinbuchstaben auf Kennungen anzuwenden.

Gruppen verwalten

Die Mitarbeiteridentitätsföderation kann die Gruppenmitgliedschaft eines Nutzers aus den folgenden Quellen ermitteln:

  • Die vom IdP bereitgestellte SAML-Assertion oder das ID-Token.
  • Die Microsoft Graph API, wenn Sie Microsoft Entra ID als IdP verwenden.
  • Der SCIM-Mandant, der dem Anbieter des Mitarbeiteridentitätspools zugeordnet ist.

Standardmäßig verwendet die Mitarbeiteridentitätsföderation nur die SAML-Assertion oder das ID-Token:

Quelle Google Cloud Gemini Enterprise
SAML- oder ID-Token
Microsoft Graph API - -
SCIM-Mandant - -

Wenn Sie Microsoft Entra ID als IdP verwenden, können Sie die Funktion Zusätzliche Attribute aktivieren. Die Workforce Identity-Föderation verwendet dann nur die Microsoft Graph API als Quelle für Gruppenmitgliedschaften:

Quelle Google Cloud Gemini Enterprise
SAML- oder ID-Token - -
Microsoft Graph API
SCIM-Mandant - -

Wenn Sie Gemini Enterprise verwenden, können Sie die Mitarbeiteridentitätsföderation so konfigurieren, dass ein SCIM-Mandant verwendet wird. Dadurch ändert sich das Verhalten wie folgt:

  • Gemini Enterprise verwendet Gruppenmitgliedschaften aus dem SCIM-Mandanten und ignoriert Gruppenmitgliedschaftsinformationen aus der SAML-Assertion oder dem ID-Token.
  • Google Cloud verwendet Informationen zur Gruppenmitgliedschaft aus der SAML-Assertion oder dem ID-Token und ignoriert Informationen zur Gruppenmitgliedschaft aus dem SCIM-Mandanten.
Quelle Google Cloud Gemini Enterprise
SAML- oder ID-Token -
Microsoft Graph API - -
SCIM-Mandant -

Für jede Gruppenmitgliedschaft leitet die Workforce Identity-Föderation eine Prinzipal-ID ab, indem sie die folgenden Schritte ausführt:

  1. Ermitteln Sie die Gruppen-ID mit einem der folgenden Schritte:
    • SAML-Assertion oder ID-Token: Wenden Sie die Attributzuordnung für google.groups an.
    • SCIM-Mandant: Wenden Sie die Anspruchszuordnung für google.group an.
    • Microsoft Graph API: Folgen Sie extra-attributes-type in der Anbieterkonfiguration.

  2. Leiten Sie die Principal-Kennung ab, indem Sie die Gruppenkennung an ein Präfix anhängen, das den Workforce Identity-Pool identifiziert. Die resultierende Hauptkonto-ID ist für Google Cloud eindeutig und hat das folgende Format:

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

Wenn ein Nutzer, der sich mit der Workforce Identity-Föderation authentifiziert hat, auf eine Ressource zugreift, verwendet IAM diese Hauptkonto-IDs, um Rollenbindungen in Zulassungsrichtlinien auszuwerten.

Best Practices:

Unveränderliche Gruppen-ID verwenden:
Gruppenmitgliedschaften in Zusicherungen oder Tokens reduzieren:
Microsoft Entra ID: Objekt-ID als Gruppen-ID verwenden

Unveränderliche Gruppen-ID verwenden

In allen IAM-Richtlinien wird auf Gruppen anhand ihrer Prinzipal-ID verwiesen. Wenn Sie eine Gruppe in Ihrem Identitätsanbieter umbenennen, sodass sich ihre Kennung ändert, wird sie vonGoogle Cloud nicht mehr als dieselbe Gruppe erkannt:

  • Vorhandene IAM-Rollenbindungen verweisen weiterhin auf die alte Prinzipal-ID und werden inaktiv.
  • Mitglieder der umbenannten Gruppe verlieren den Zugriff, da die neue Prinzipal-ID der Gruppe nicht mehr mit IAM-Rollenbindungen übereinstimmt.

Um diese Unterbrechungen zu vermeiden, konfigurieren Sie die Attribut- und Anspruchszuordnung so, dass ein stabiler, unveränderlicher Wert verwendet wird, z. B. eine vom Identitätsanbieter generierte eindeutige ID. Verwenden Sie keine Anzeigenamen oder E-Mail-Adressen als Gruppenkennungen, da diese sich bei organisatorischen Änderungen ändern können.

Gruppenmitgliedschaften in Zusicherungen oder Tokens reduzieren

Standardmäßig enthält Ihr IdP möglicherweise mehr Gruppenmitgliedschaften in SAML-Assertions oder ID-Tokens als Sie benötigen, um den Zugriff auf Gemini Enterprise- und Google Cloud -Ressourcen zu verwalten. Unnötige Gruppenmitgliedschaften bergen mehrere Risiken:

  • Teilweiser Verlust des Zugriffs: Viele Identitätsanbieter legen Beschränkungen für die Anzahl der Gruppenmitgliedschaften fest, die in ein Token oder eine Assertion aufgenommen werden können. Wenn ein Nutzer dieses Limit überschreitet (Gruppenüberschreitung), werden möglicherweise einige Gruppenmitgliedschaften des Nutzers vom IdP entfernt, wodurch der Nutzer den Zugriff auf bestimmte Ressourcen verliert.
  • Anmeldefehler: Die Mitarbeiteridentitätsföderation beschränkt die Größe und Anzahl der Gruppenmitgliedschaften, die durch die google.groups-Attributzuordnung erzeugt werden können. Nutzer, die eines dieser Limits überschreiten, können sich nicht anmelden.
  • Inkonsistente Gruppennutzung: Wenn Sie Gruppen für Google Cloudverfügbar machen, können Projektinhaber diese Gruppen verwenden, um den Zugriff auf Ressourcen zu verwalten, auch wenn Sie nie beabsichtigt haben, dass bestimmte Gruppen inGoogle Cloudverwendet werden.

Mit den folgenden Ansätzen können Sie diese Risiken minimieren und die Anzahl der Gruppenmitgliedschaften in Zusicherungen oder Tokens reduzieren:

  • Nach Gruppentyp filtern: Bei einigen IdPs, einschließlich Microsoft Entra ID, können Sie einen Filter konfigurieren, der bestimmt, welche Gruppen in Zusicherungen oder Tokens enthalten sein sollen. Sie können einen Filter konfigurieren, um Gruppentypen auszuschließen, die basierend auf Ihrer Konfiguration und den Diensten, die Sie verwenden möchten, nicht relevant sind.

    In der folgenden Tabelle sehen Sie, welche Arten von Gruppen Sie je nach den Diensten, die Sie verwenden möchten, in Zusicherungen oder Tokens einfügen müssen:

    Gruppentyp Google Cloud Gemini (ohne Synchronisierung) Gemini (SCIM)
    Zugriffsgruppen -
    Erzwingungsgruppen -
    Organisationsgruppen Nicht erforderlich * -
    Gruppen für die Zusammenarbeit Nicht erforderlich * -

    * Nur erforderlich, wenn Sie Connectors verwenden, die auf der Datenaufnahme basieren.

    • Wenn Sie den Zugriff auf Google Cloudverwalten möchten, müssen Sie Zugriffs- und Erzwingungsgruppen einbeziehen.
    • Der Filter, der zum Verwalten des Zugriffs auf Gemini Enterprise erforderlich ist, hängt davon ab, ob Sie SCIM verwenden. Wenn Sie SCIM verwenden, werden Gruppenmitgliedschaften, die in Assertionen oder Tokens enthalten sind, in Gemini Enterprise ignoriert. Sie müssen also keine Gruppen einbeziehen, die speziell für Gemini Enterprise gelten. Wenn Sie SCIM nicht verwenden, müssen Sie die für Gemini Enterprise erforderlichen Zugriffsgruppen und Erzwingungsgruppen einbeziehen. Je nachdem, ob Sie Connectors für die Datenaufnahme verwenden möchten, müssen Sie möglicherweise auch bestimmte Organisations- und Kollaborationsgruppen einbeziehen.

  • Zuweisung: Bei einigen IdPs, einschließlich Microsoft Entra ID, können Sie Gruppenmitgliedschaften in Tokens und Zusicherungen auf zugewiesene Gruppen beschränken. Das sind die Gruppen, die Sie der Relying-Party-Konfiguration explizit zuweisen.

  • Filter für zusätzliche Attribute: Wenn Sie Microsoft Entra ID verwenden und die Funktion Zusätzliche Attribute aktiviert haben, können Sie mit dem Flag --extra-attributes-filter einen Filter angeben. Bei der Workforce Identity-Föderation wird dieser Filter an die Microsoft Graph API übergeben, wenn Gruppenmitgliedschaften angefordert werden.

Wenn Sie Filter testen oder Fehler beheben möchten, verwenden Sie das Tool Debug IdP token in der Google Cloud Console oder aktivieren Sie detaillierte Audit-Logs.

Microsoft Entra ID: Objekt-ID als Gruppen-ID verwenden

Diese Best Practice gilt nur, wenn Sie Microsoft Entra ID als IdP verwenden.

Wenn Sie Microsoft Entra ID verwenden, können Sie die folgenden Kennungen als Gruppenkennung verwenden:

  • Objekt-ID (oid)
  • E-Mail-Adresse
  • Anzeigename

Von diesen Optionen empfehlen wir, die Objekt-ID (oid) als Gruppen-ID zu verwenden. Das hat folgende Gründe:

  • Alle Gruppen haben eine Objekt-ID. Die E‑Mail-Adresse ist dagegen ein optionales Feld, das möglicherweise nur für Microsoft 365-Gruppen ausgefüllt wird.
  • Die Objekt-ID ist eindeutig und unveränderlich. Im Gegensatz dazu kann sich der Anzeigename einer Gruppe ändern und ist möglicherweise nicht eindeutig.

Unabhängig davon, welche Kennung Sie auswählen, empfehlen wir, keine Transformationen wie das Erzwingen von Kleinbuchstaben anzuwenden.

Zugriff verwalten

Best Practices für Zugriffsbeschränkungen und Just-in-Time-Verwaltung (JIT).

Best Practices:

Cloud Identity-Nutzer für Notfallzugriff verwenden
Cloud Identity für den Zugriff mit hohen Berechtigungen verwenden:
Föderation mit Einschränkungen für Organisationsrichtlinien verwalten:
Zugriff nicht allen Mitgliedern eines Pools gewähren
Sitzungslänge begrenzen
Sitzungslänge an die Anforderungen für den JIT-Zugriff anpassen

Cloud Identity-Nutzer für den Notfallzugriff verwenden

Damit Sie jederzeit auf Ihre Google Cloud Umgebungen zugreifen können, sollten Sie für jede Umgebung Nutzer mit Notfallzugriff erstellen.

Notfallzugriffsnutzer ermöglichen den Zugriff auf Ihre Google Cloud Umgebung, wenn Dienste falsch konfiguriert, kompromittiert oder nicht normal ausgeführt werden. Nutzer mit Notfallzugriff haben sehr hohe Berechtigungen. Wenn Sie sich auf die Mitarbeiteridentitätsföderation verlassen, um Nutzer mit Notfallzugriff zu authentifizieren, birgt das folgende Risiken:

  • Ein Fehler in der Konfiguration des Anbieters des Workforce Identity-Pools kann dazu führen, dass Sie sich selbst aussperren.
  • Eine Dienstunterbrechung, die den externen IdP betrifft, kann verhindern, dass Sie einen Notfallzugriffsnutzer verwenden, wenn Sie ihn am dringendsten benötigen.
  • Wenn der externe IdP kompromittiert wird, können böswillige Akteure sich als Notfallzugriffsnutzer authentifizieren und umfassenden Zugriff auf Ihre Google CloudRessourcen erhalten.

Um diese Risiken zu minimieren, sollten Sie Cloud Identity oder Google Workspace für Nutzer mit Notfallzugriff verwenden, auch wenn Sie die Workforce Identity Federation für andere Nutzer verwenden:

  • Erstellen Sie Nutzer mit Notfallzugriff in Cloud Identity.
  • Schließen Sie diese Nutzer von der Einmalanmeldung aus und lassen Sie sie sich mit einem Nutzernamen und einem Passwort authentifizieren.
  • Schützen Sie diese Nutzer, indem Sie sie für die Bestätigung in zwei Schritten mit einem Sicherheitsschlüssel registrieren.

Weitere Informationen zu Nutzern mit Notfallzugriff finden Sie unter Best Practices für den kontinuierlichen Zugriff auf Google Cloud.

Cloud Identity für Zugriff mit hohen Berechtigungen verwenden

Hoch privilegierte Nutzer haben umfassenden Zugriff auf Ihre Google Cloud-Umgebung. Beispiele für diese Nutzer:

  • Nutzer mit der Rolle Organisationsadministrator“ (roles/resourcemanager.organizationAdmin)
  • Nutzer mit der Rolle „Sicherheitsadministrator“ (roles/iam.securityAdmin) oder einer ähnlichen Rolle, die „allow“-Richtlinien für wichtige Teile Ihrer Google Cloud -Ressourcenhierarchie ändern kann

Wenn Sie die Workforce Identity-Föderation für Nutzer mit hohen Berechtigungen verwenden, kann sich jede Fehlkonfiguration oder jeder Angriff auf Ihren externen IdP auf die Sicherheit Ihrer Google Cloud Ressourcen auswirken. Insbesondere kann ein Angriff auf den externen IdP dazu führen, dass böswillige Akteure sich als Nutzer mit hohen Berechtigungen authentifizieren und umfassenden Zugriff auf Ihre Google Cloud Ressourcen erhalten.

Um diese Risiken zu minimieren, sollten Sie Cloud Identity für Nutzer mit hohen Berechtigungen verwenden:

  • Erstellen Sie Nutzer mit hohen Berechtigungen in Cloud Identity.
  • Schützen Sie diese Nutzer, indem Sie sie für die Bestätigung in zwei Schritten mit einem Sicherheitsschlüssel registrieren.
  • Wenn Sie Cloud Identity mit einem externen IdP verbunden haben, aktivieren Sie für diese Nutzer die zusätzlichen SSO-Bestätigungen und die Bestätigung in zwei Schritten.

Zusätzliche SSO-Bestätigungen können redundant erscheinen, wenn Ihr IdP bereits eine Multi-Faktor-Authentifizierung erzwingt. Mit dieser Einstellung können Sie jedoch Nutzer schützen, falls der IdP gehackt wird. Zusätzliche SSO-Bestätigungen sind ein Feature, das von Cloud Identity unterstützt wird, aber für die Mitarbeiteridentitätsföderation nicht verfügbar ist.

Einschränkungen für Organisationsrichtlinien verwenden, um die Föderation zu steuern

Wenn Sie Cloud Identity für andere Zwecke als Notfall- oder hochprivilegierten Zugriff verwenden, partitionieren Sie die Nutzung der Cloud Identity-Föderation und der Mitarbeiteridentitätsföderation nach Dienst. Um diese Vorgehensweise zu erzwingen, verwenden Sie benutzerdefinierte Einschränkungen für Organisationsrichtlinien, um einzuschränken, welche Hauptkontotypen in bestimmten Projekten zulässig sind.

Sie können die Workforce Identity-Föderation beispielsweise auf Gemini Enterprise beschränken, indem Sie Folgendes tun:

  • Wenden Sie eine benutzerdefinierte Einschränkung für Organisationsrichtlinien auf Ihr Gemini Enterprise-Projekt an, in dem die Funktion MemberTypeMatches verwendet wird, um die zulässigen Hauptkontotypen auf iam.googleapis.com/WorkforcePoolPrincipal und iam.googleapis.com/WorkforcePoolPrincipalSet zu beschränken. Dies sind die von der Workforce Identity-Föderation verwendeten Haupttypen.
  • Wenden Sie für alle anderen Projekte eine Einschränkung an, die alle Hauptkontotypen außer iam.googleapis.com/WorkforcePoolPrincipal und iam.googleapis.com/WorkforcePoolPrincipalSet zulässt.

Mit benutzerdefinierten Einschränkungen für Organisationsrichtlinien können Sie für Konsistenz sorgen und die versehentliche Verwendung falscher Prinzipaltypen verhindern.

Zugriff nicht allen Mitgliedern eines Pools gewähren

Die Workforce Identity-Föderation unterstützt eine Platzhalter-Hauptkonto-ID mit dem folgenden Format:

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

Diese Kennung entspricht jedem Nutzer, der sich über Ihren Identitätsanbieter beiGoogle Cloudauthentifizieren darf.

Verwenden Sie diesen Platzhalter nicht, um Berechtigungen zu erteilen. Wenn die Nutzerbasis Ihres Identitätsanbieters wächst, führt das Erteilen des Zugriffs mit der Platzhalter-Haupt-ID zu einer Überberechtigung.

Erstellen Sie stattdessen Zugriffsgruppen in Ihrem IdP und verwenden Sie diese Gruppen, um den Zugriff auf Ressourcen zu verwalten. So wird sichergestellt, dass der Zugriff durch die beabsichtigte Gruppenmitgliedschaft und nicht durch eine erfolgreiche Authentifizierung gesteuert wird. Das Risiko einer Überberechtigung wird dadurch verringert.

Sitzungsdauer begrenzen

Wenn sich ein Nutzer anmeldet, wird durch die Mitarbeiteridentitätsföderation eine Sitzung gestartet. Während der Sitzung kann ein Nutzer Folgendes tun:

  • Sie können die Console (föderiert), Gemini Enterprise oder andere Portale, die die Mitarbeiteridentitätsföderation unterstützen, verwenden und zwischen ihnen wechseln.
  • IAP-geschützte Webanwendungen verwenden
  • Föderierte Aktualisierungstokens und föderierte Zugriffstokens abrufen, z. B. durch Ausführen von gcloud auth login.

Eine Sitzung bleibt gültig, bis eines der folgenden Ereignisse eintritt:

  • Die Sitzungslänge erreicht das Limit, das durch den Mitarbeiteridentitätspool definiert ist.
  • Die Sitzungslänge erreicht das Limit, das im Attribut SessionNotOnOrAfter in der SAML-Assertion des Nutzers definiert ist, sofern vorhanden.
  • Der Nutzer meldet sich ab.

Wenn Sitzungen über einen längeren Zeitraum gültig bleiben, erhöht sich das Risiko eines Token-Diebstahls und es kann dazu kommen, dass Informationen zur Gruppenmitgliedschaft veralten:

  • Nutzer behalten möglicherweise länger als beabsichtigt Zugriff, wenn Berechtigungen im IdP widerrufen werden.
  • Nutzer können möglicherweise erst dann auf neu gewährten Zugriff zugreifen, wenn sie sich noch einmal authentifizieren und eine neue Sitzung starten.

Um diese Risiken zu minimieren, sollten Sie die Sitzungslänge begrenzen, sodass sich Nutzer mindestens einmal täglich neu anmelden müssen.

Sitzungslänge an JIT-Zugriffsanforderungen anpassen

Zur Verwaltung des privilegierten Zugriffs unterstützen Ihre Identitätsanbieter möglicherweise Just-in-Time-Gruppen (JIT), die Mitglieder vorübergehend aktivieren können. Die Verwendung von Just-in-Time-Gruppen zur Verwaltung des privilegierten Zugriffs auf Google Cloud oder Gemini Enterprise kann die folgenden Risiken mit sich bringen:

  • Verzögerte Aktivierung: Wenn ein Nutzer eine aktive Sitzung der Mitarbeiteridentitätsföderation hat, während er seine Just-in-Time-Gruppenmitgliedschaft aktiviert, wird die Änderung der Mitgliedschaft erst wirksam, wenn sich der Nutzer ab- und wieder anmeldet. Wenn der Anbieter des Mitarbeiteridentitätspools SCIM verwendet, wird die Mitgliedschaftsänderung erst wirksam, wenn die Änderung der Gruppenmitgliedschaft bereitgestellt wird.
  • Verzögerter Widerruf: Wenn eine Gruppenmitgliedschaft abläuft, verliert der Nutzer den privilegierten Zugriff erst, wenn er sich abmeldet und wieder anmeldet oder die Änderung der Gruppenmitgliedschaft über SCIM bereitgestellt wird. Je nach Sitzungslänge kann diese Verzögerung den Zweck des Ablaufs der Mitgliedschaft untergraben.

Um diese Risiken zu minimieren, konfigurieren Sie die Sitzungslänge Ihres Workforce Identity-Pools so, dass sie ausreichend kurz ist.

Aktivitäten im Blick behalten

Wenn Sie verdächtige Aktivitäten bemerken, die sich auf eine Ressource inGoogle Cloudauswirken, liefern Cloud-Audit-Logs wichtige Informationen, um herauszufinden, wann die Aktivität stattgefunden hat und welche Nutzer beteiligt waren.

Datenzugriffslogs aktivieren

Mit Workforce Identity-Föderation können Sie Logs generieren, mit denen Sie Anmelde- und Tokenaustauschaktivitäten nachverfolgen können. Die Security Token Service API schreibt diese Logs, die die folgenden Methoden enthalten:

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

Alle Logs im Zusammenhang mit Anmelde- und Tokenaustauschaktivitäten werden als Datenzugriffslogs klassifiziert und sind standardmäßig deaktiviert. Damit diese Logs erfasst werden, müssen Sie Datenzugriffslogs für die Security Token Service API in IhrerGoogle Cloud -Organisation aktivieren. Wenn Sie die Ausführlichkeit der Anmeldelogs weiter erhöhen möchten, aktivieren Sie das detaillierte Audit-Logging.

Wenn Sie andere authentifizierungsbezogene Aktivitäten erfassen möchten, empfehlen wir Ihnen, die folgenden Logs zu aktivieren und zu verwenden:

Nächste Schritte