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 Methoden zum Verknüpfen einer Google Cloud-Organisation mit einem externen IdP:

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 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 aufteilen: Teilen Sie Ihre Nutzer in zwei Kohorten auf: eine mit Workforce Identity-Föderation 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 folgenden:

      • 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, in Gemini Enterprise und in 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 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 Gemini Notebook Enterprise von anderen Diensten zu trennen. Gemini Enterprise und die Google Cloud -Konsole sind separate Tools, die für unterschiedliche Aufgaben entwickelt wurden. 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.

Gruppen-Governance 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. Die Bewertung erfolgt auf Grundlage der Richtlinien, die an diese bestimmte Ressource angehängt 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 in der Regel nur schwer skalieren, da folgende Probleme auftreten:

  • Wenn Sie Hauptkonten einzeln hinzufügen, werden Zulassungsrichtlinien immer umfangreicher und schwieriger zu verwalten.
  • Die individuelle Zugriffsverwaltung erfordert häufige Änderungen an den Zulassungsrichtlinien.
  • Richtlinien können mit der Zeit immer inkonsistenter werden.

Für eine skalierbare und effektive Zugriffsverwaltung bietet die Verwendung von gruppenbasierten Prinzipalgruppen 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:

Verschiedene 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:

Verschiedene 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 Boundaries, Ablehnungsrichtlinien oder die Erzwingung der Multi-Faktor-Authentifizierung. Mit Zugriffsgruppen können Mitglieder eine Gruppe freiwillig verlassen. Die Mitgliedschaft in einer Enforcement-Gruppe ist jedoch nicht freiwillig.

Welche Gruppen Sie föderieren müssen, hängt 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 Datenaufnahme 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 Prinzipalgruppen, 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 Prinzipalsets zu, damit Sie sie in IAM verwenden können.
  3. Erstellen Sie Richtlinienbindungen, um den Prinzipalgruppen Zugriff auf die Ressourcen zu gewähren, die für die einzelnen Jobfunktionen 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.

    Die folgenden Arten von Gruppen sind dagegen 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 Jobfunktionen dar.

    • Kommunikationsgruppen wie security-discuss sind für E‑Mail-Listen oder die Zusammenarbeit vorgesehen 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 folgenden Punkten:

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

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 wirkt sich wahrscheinlich nicht auf die Gesamtzahl der Gruppenmitgliedschaften eines Nutzers aus.

Organisationseinheiten und Gruppen für die Zusammenarbeit 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 stammen in der Regel aus 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. Wenn Sie den Zugriff mit Organisationsgruppen verwalten, kann es während dieser Übergänge zu einer Kaskade von Richtlinienänderungen kommen.
  • 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 mit oder ohne Genehmigung eines anderen Mitglieds beitreten. 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 Token oder Zusicherungen ausgeschlossen werden, die für die Mitarbeiteridentitätsföderation verwendet werden.

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

Obwohl Organisations- und Kollaborationsgruppen nicht gut geeignet sind, um den Zugriff auf Google Cloud Ressourcen zu verwalten, benötigen Sie sie möglicherweise für Gemini Enterprise:

  • ACL-Auswertung: Wenn Sie datenaufnahmefähige 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 Gemini Notebook Enterprise können Nutzer Notebooks freigeben. Nutzern zu erlauben, Notebooks für Gruppen zur Zusammenarbeit freizugeben, ist oft praktischer, als die Freigabe auf einzelne Nutzer zu beschränken.

Damit Organisations- und Kollaborationsgruppen nur für 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 in einer Google Cloud Organisation und nicht in einem einzelnen Projekt oder einer einzelnen 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 Mitarbeiteridentitäts-Pool verwenden.
  • Wenn Ihre Organisation mehrere IdPs verwendet, z. B. aufgrund einer Übernahme, 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 Google Cloud eindeutig ist und nicht von einer anderen Organisation beansprucht wird.
  • Unveränderlichkeit: Der Name eines Workforce Identity-Pools kann nicht geändert werden. Wählen Sie einen Namen, der im Laufe der Zeit aussagekräftig bleibt, und vermeiden Sie temporäre Namen für 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 Mitarbeiteridentitätspool und der 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. Eine Kompromittierung dieser Komponenten könnte es böswilligen Akteuren ermöglichen, Spoofing-Angriffe durchzuführen.

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

  • Attributzuordnungen ändern: Wenn ein böswilliger Akteur Attributzuordnungen ändert, kann er sich als eine andere Person authentifizieren und unbefugten 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 einschränken: Beschränken Sie den Administratorzugriff auf eine kleine Anzahl von Cloud Identity- oder Google Workspace-Nutzern, darunter mindestens ein Nutzer mit Notfallzugriff.
  • 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, verlassen Sie sich darauf, dass der externe IdP die folgenden Aktionen ausführt:

  • Führen Sie die Multi-Faktor-Authentifizierung (MFA) durch, die Ihren Sicherheitsanforderungen entspricht.
  • Genaue Behauptungen in Bezug auf Nutzeridentitäten und Gruppenmitgliedschaften aufstellen.
  • Halten Sie sich an Prozesse zur Identitätsverwaltung, die sicherstellen, 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 Hauptkonto-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.
Denselben Pool und Anbieter für die Google Cloud Console und Gemini Enterprise verwenden:
Verwenden Sie einen mandantenspezifischen Aussteller-URI.
Vermeiden Sie die Verwendung des impliziten OpenID Connect (OIDC)-Ablaufs.

Aussagekräftigen Anbieternamen auswählen

Wenn Sie einen Workforce Identity-Poolanbieter 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 die Verwendung von Namen wie oidc oder saml, da diese Akronyme für Nutzer möglicherweise unbekannt sind.

Einzelne Dienste in Ihrem IdP-Anwendungsportal anzeigen

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 können Sie das Portal nutzen, um die Nutzerfreundlichkeit zu optimieren:

  • Konfigurieren Sie das Portal so, dass relevante Google-Dienste einzeln anstatt über einen einzelnen Google Cloud Link angezeigt werden.
  • Links konfigurieren, um den Nutzer automatisch anzumelden

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
Gemini Notebook 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 Projektnummer von Gemini Notebook Enterprise.

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 Identitätsanbietern zu authentifizieren. Vermeiden Sie die Verwendung mehrerer Anbieter aus folgenden Gründen:

  • Kollisionen von Identitäten: Die Verwendung mehrerer Anbieter birgt das Risiko von Kollisionen von Identitäten. Bei solchen Konflikten wird für die google.subject-Attributzuordnung für einen Anbieter derselbe Wert wie für einen anderen Anbieter zurückgegeben. Bei dieser Kollision werden mehrere externe Identitäten demselben IAM-Hauptkonto zugeordnet, sodass sie in Cloud-Audit-Logs nicht voneinander unterschieden werden können.
  • IAP-Kompatibilität: Für IAP ist es erforderlich, dass Workforce Identity-Pools einen einzelnen Anbieter haben, um nicht authentifizierte Nutzer automatisch an den IdP weiterzuleiten. Wenn Sie einen zusätzlichen Anbieter hinzufügen, kann IAP Nutzer nicht authentifizieren.

Wenn Sie die Föderation mit mehreren Anbietern benötigen, erstellen Sie mehrere Workforce-Pools und konfigurieren Sie für jeden Pool einen Anbieter.

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 unbeabsichtigten mandantenübergreifenden Zugriff zu verhindern, verwenden Sie einen mandantenspezifischen 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 Autorisierungscode-Vorgang dem impliziten Vorgang vorziehen. Der implizite Ablauf ist in Version 2.1 der OAuth-Spezifikation als veraltet eingestuft, da er anfällig für Token-Lecks und ‑Injections 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 über Google Cloudhinweg eindeutig sein.

  2. Leiten Sie die Hauptkonto-ID ab, indem Sie die Subjekt-ID an ein Präfix anhängen, das den Workforce Identity-Pool identifiziert. Die resultierende Hauptkonto-Kennzeichnung 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 Subjekt-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. Google Cloud erkennt sie daher nicht mehr als denselben Nutzer:

  • Der Nutzer kann nicht auf Ressourcen zugreifen, auf die ihm zuvor Zugriff gewährt wurde, 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 Kennung oder eine Kennung im UUID-Format für Nutzer. Diese IDs sind eindeutig und stabil und eignen sich daher gut für google.subject. Wenn Sie diese IDs jedoch als google.subject verwenden, kann das zu langen, kryptischen Prinzipal-IDs führen, mit denen sich nur schwer arbeiten lässt.

Berücksichtigen Sie die folgenden Anforderungen in absteigender Priorität, um eine Kennung 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 Eindeutigkeitsbeschränkungen für bestimmte Nutzerkennungen, erlauben aber die Wiederverwendung von Kennungen. Ein Identitätsanbieter lässt es beispielsweise 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 einen Nutzer-Identifier verweist, der wiederverwendet werden kann, kann es zu Subject-Kollisionen kommen: Die Mitarbeiteridentitätsföderation kann nicht zwischen einem alten und einem neuen Nutzer unterscheiden, wenn deren google.subject identisch ist. Dadurch erhält der neue Nutzer möglicherweise Zugriff auf Ressourcen, die nur für den alten Nutzer vorgesehen sind.

So verhindern Sie, dass sich Themen überschneiden:

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-Haupt-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, Transformationen wie das Erzwingen von Kleinbuchstaben für Kennungen zu vermeiden.

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 Mitarbeiteridentitätsfö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 Workforce Identity-Fö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 Informationen zu Gruppenmitgliedschaften 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 Mitarbeiteridentitätsföderation eine Prinzipal-ID ab, indem sie die folgenden Schritte ausführt:

  1. So ermitteln Sie die Gruppen-ID:
    • 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-Kennzeichnung 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 über die Mitarbeiteridentitätsfö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 IdP 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 IdP 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), kann es sein, dass der IdP einige Gruppenmitgliedschaften 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 Verwendung von Gruppen: Wenn Sie Gruppen für Google Cloudfreigeben, 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, darunter Microsoft Entra ID, können Sie einen Filter konfigurieren, der bestimmt, welche Gruppen in Assertionen 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 Connectors für die Datenaufnahme verwendet werden.

    • 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 auf Grundlage der 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 IdP-Token debuggen in der Google Cloud Console oder aktivieren Sie die detaillierte Audit-Protokollierung.

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, Transformationen wie das Erzwingen von Kleinbuchstaben zu vermeiden.

Zugriff verwalten

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

Best Practices:

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

Cloud Identity-Nutzer für 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, manipuliert 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 dies die folgenden 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 können, 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 Cloud-Ressourcen 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:

  • Nutzer mit Notfallzugriff in Cloud Identity erstellen
  • 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 den Zugriff mit hohen Berechtigungen verwenden

Nutzer mit hohen Berechtigungen 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 in wichtigen Teilen 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:

  • Nutzer mit hohen Berechtigungen in Cloud Identity erstellen
  • 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 föderiert haben, aktivieren Sie für diese Nutzer zusätzliche 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, unterteilen 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 der Organisationsrichtlinie auf Ihr Gemini Enterprise-Projekt an, in der 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 ID 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 Gewähren des Zugriffs mit der Platzhalter-Prinzipal-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.

Sitzungslänge 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:

Wenn Sitzungen über einen längeren Zeitraum gültig bleiben, steigt das Risiko eines Token-Diebstahls und Gruppenmitgliedschaftsinformationen können veralten:

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

Um diese Risiken zu minimieren, sollten Sie die Sitzungslänge begrenzen, sodass Nutzer sich 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 Workforce Identity-Pool-Anbieter 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 der 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 Datenzugriffsprotokolle 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 detailliertes Audit-Logging.

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

Nächste Schritte