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

Mit der Workload Identity-Föderation können Anwendungen, die außerhalb von Google Cloud ausgeführt werden, die Identität eines Dienstkontos mithilfe von Anmeldedaten eines externen Identitätsanbieters übernehmen.

Die Workload Identity-Föderation kann zur Verbesserung der Sicherheit beitragen, indem Anwendungen die Authentifizierungsmechanismen nutzen, die die externe Umgebung bereitstellt, und Dienstkontoschlüssel können ersetzt werden.

Wenn Sie eine Workload Identity-Föderation sicher verwenden möchten, müssen Sie sie so konfigurieren, dass Sie vor folgenden Bedrohungen geschützt sind:

  • Spoofing: Ein böswilliger Akteur kann versuchen, die Identität eines anderen Nutzers zu vorzutäuschen, um nicht autorisierten Zugriff auf Google Cloud-Ressourcen zu erhalten.
  • Rechteausweitung: Ein böswilliger Akteur kann die Workload Identity-Föderation nutzen, um Zugriff auf Ressourcen zu erhalten, auf die er sonst keinen Zugriff hätte.
  • Nachweisbarkeit: Ein böswilliger Akteur kann seine Identität und Aktionen mithilfe von externen Anmeldedaten verbergen, die die Rückverfolgung der Aktionen zu ihm erschweren.

In diesem Leitfaden werden Best Practices für die Entscheidung vorgestellt, wann die Workload Identity-Föderation verwendet werden soll und wie Sie sie so konfigurieren, dass Risiken minimiert werden.

Wann sollte die Workload Identity-Föderation verwendet werden?

Best Practices:

Workload Identity-Föderation für Anwendungen verwenden, die Zugriff auf Ambient-Anmeldedaten haben
Zusätzlichen Tokenaustausch verwenden, um Ambient-Anmeldedaten zu verwenden, die von der Workload Identity-Föderation nicht unterstützt werden
Workload Identity-Föderation verwenden, um die Anzahl der Anmeldedaten zu reduzieren, die eine Rotation erfordern

Workload Identity-Föderation für Anwendungen verwenden, die Zugriff auf Ambient-Anmeldedaten haben

Anwendungen, die bei anderen Cloud-Anbietern als Google Cloud ausgeführt werden, haben häufig Zugriff auf Ambient-Anmeldedaten. Diese Anmeldedaten können von der Anwendung abgerufen werden, ohne dass eine zusätzliche Authentifizierung erforderlich ist. Hier einige Beispiele:

  • In AWS können in EC2 bereitgestellte Anwendungen Instanzprofile verwenden, um eine Rolle anzunehmen und temporäre Anmeldedaten zu erhalten.
  • In Azure können Anwendungen verwaltete Identitäten verwenden, um Zugriffstokens abzurufen.
  • In GitHub-Aktionen können Workflows ID-Tokens abrufen, die die Identität des Bereitstellungsjobs widerspiegeln.

Wenn die Ambient-Anmeldedaten OpenID Connect-Tokens (OIDC), SAML-Assertions oder AWS-Anmeldedaten sind, können Sie die Workload Identity-Föderation konfigurieren, damit Anwendungen diese Anmeldedaten gegen kurzlebige Google-Zugriffstokens austauschen können. Wenn die Ambient-Anmeldedaten ein anderes Format haben, können Sie sie möglicherweise zuerst gegen ein OIDC-Token oder eine SAML-Assertion austauschen und dann für die Workload Identity-Föderation verwenden.

Verwenden Sie die Workload Identity-Föderation, wenn eine Anwendung auf Google Cloud zugreifen muss und Zugriff auf Ambient-Anmeldedaten hat.

Zusätzlichen Tokenaustausch verwenden, um Ambient-Anmeldedaten zu verwenden, die von der Workload Identity-Föderation nicht unterstützt werden

In einigen Fällen kann eine Anwendung Zugriff auf Ambient-Anmeldedaten haben, die Arten von Anmeldedaten werden jedoch nicht von der Workload Identity-Föderation unterstützt. Prüfen Sie in diesen Fällen, ob Sie mit einem zusätzlichen Tokenaustausch die Ambient-Anmeldedaten in einen Anmeldedatentyp konvertieren können, den Sie für die Workload Identity-Föderation verwenden können.

Wenn Ihre Anwendung beispielsweise in einer Active Directory-Umgebung ausgeführt wird, hat sie möglicherweise Zugriff auf Kerberos-Anmeldedaten. Wenn Sie in Ihrer Umgebung einen Identitätsanbieter wie Active Directory Federation Services (AD FS) haben, der die integrierte Windows-Authentifizierung unterstützt, können Sie sich mit diesen Kerberos-Anmeldedaten beim Identitätsanbieter authentifizieren und ein OAuth-Zugriffstoken abrufen, das das JWT-Format verwendet. Mit diesem Zugriffstoken und der Workload Identity-Föderation können Sie die Anwendung dann einen zweiten Tokenaustausch durchführen, um kurzlebige Google-Anmeldedaten abzurufen.

Das Verketten von Tokenaustauschvorgängen erhöht die Komplexität und kann zusätzliche Abhängigkeiten mit sich bringen. Sie müssen jedoch keine Dienstkontoschlüssel verwalten und sichern.

Workload Identity-Föderation´verwenden, um die Anzahl der Anmeldedaten zu reduzieren, die eine Rotation erfordern

Anwendungen, die in einen OpenID- oder SAML-Identitätsanbieter eingebunden sind, verwenden häufig einen Clientschlüssel (oder eine andere Form von Secret), um sich beim Identitätsanbieter zu authentifizieren. In der Regel wird dieses Secret als Teil der Anwendungskonfiguration gespeichert. Wenn Sie eine solche Anwendung auf Google Cloud zugreifen lassen möchten, müssen Sie sich zwischen Folgendem entscheiden:

  1. Dienstkontoschlüssel erstellen und zusammen mit dem anderen Secret speichern
  2. Vom vorhandenen Identitätsanbieter ausgestellte Tokens verwenden und mithilfe der Workload Identity-Föderation gegen Google-Anmeldedaten austauschen

Die erste Option erfordert zwei Secrets, aber die zweite Option benötigt nur eins. Wenn Sie die Anzahl der Secrets reduzieren, können Sie die Secret-Rotation vereinfachen, was wiederum die Sicherheit verbessern kann.

Schutz vor Spoofing-Bedrohungen

Ein Workload Identity-Pool enthält keine Identitäten oder Nutzerkonten und unterscheidet sich dadurch von einem Nutzerverzeichnis wie Cloud Identity. Stattdessen stellt ein Workload Identity-Pool eine Ansicht dar, die Identitäten von externen Identitätsanbietern anzeigt, damit sie als IAM-Hauptkonten verwendet werden können.

Je nachdem, wie Sie den Workload Identity-Pool und seine Anbieter konfigurieren, kann dieselbe externe Identität als mehrere verschiedene IAM-Hauptkonten dargestellt werden oder mehrere externe Identitäten können demselben IAM-Hauptkonto zugeordnet werden. Solche Mehrdeutigkeiten können dazu führen, dass böswillige Nutzer Spoofing-Angriffe starten können.

Im folgenden Abschnitt werden Best Practices beschrieben, mit denen Sie mehrdeutige Zuordnungen vermeiden und das Risiko von Spoofing-Bedrohungen reduzieren können.

Best Practices:

Verwenden Sie Attributbedingungen, wenn Sie eine Föderation mit GitHub oder anderen mehrmandantenfähigen Identitätsanbietern einrichten.
Dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern verwenden.
Erstellen von Workload Identity-Poolanbietern in anderen Projekten mithilfe von Einschränkungen für Organisationsrichtlinien deaktivieren.
Einzelnen Anbieter pro Workload Identity-Pool verwenden, um Themenkonflikte zu vermeiden
Zweimalige Föderation mit dem selben Identitätsanbieter vermeiden
OIDC-Metadaten-Endpunkt Ihres Identitätsanbieters schützen
URL des Workload Identity-Poolanbieters als Zielgruppe verwenden
Unveränderliche Attribute in Attributzuordnungen verwenden
Nicht wiederverwendbare Attribute in Attributzuordnungen verwenden
Nicht zulassen, dass Attributzuordnungen geändert werden
Nicht auf Attribute verlassen, die nicht stabil oder zuverlässig sind

Attributbedingungen bei einer Föderation mit GitHub oder anderen mehrmandantenfähigen Identitätsanbietern verwenden

Die Workload Identity-Föderation verwaltet kein Verzeichnis mit Nutzerkonten, sondern implementiert stattdessen anforderungsbasierte Identitäten: Wenn also zwei Tokens vom selben Identitätsanbieter (Identity Provider, IdP) ausgegeben werden und ihre Anforderungen demselben google.subject-Wert zugeordnet sind, wird davon ausgegangen, dass die beiden Tokens denselben Nutzer identifizieren. Die Workload Identity-Föderation prüft und verifiziert die Aussteller-URL des Tokens, um herauszufinden, welcher IdP ein Token ausgestellt hat.

Einige Anbieter wie GitHub und Terraform Cloud verwenden für alle Mandanten eine einzige Aussteller-URL. Für diese Anbieter identifiziert die Aussteller-URL GitHub oder Terraform Cloud insgesamt und nicht eine bestimmte GitHub- oder Terraform Cloud-Organisation.

Wenn Sie diese Identitätsanbieter verwenden, reicht es nicht aus, dass die Workload Identity-Föderation die Aussteller-URL eines Tokens prüfen kann, um sicherzugehen, dass sie von einer vertrauenswürdigen Quelle stammt und dass seine Anforderungen vertrauenswürdig sind. Wir empfehlen Ihnen, eine Attributbedingung für die Workload Identity-Föderation zu konfigurieren, um zu prüfen, ob das Token von einem vertrauenswürdigen Mandanten oder im Fall von GitHub oder Terraform Cloud von einer vertrauenswürdigen Organisation stammt.

Weitere Informationen finden Sie unter Attributbedingung konfigurieren.

Dediziertes Projekt zum Verwalten von Workload Identity-Pools und -Anbietern verwenden

Anstatt Workload Identity-Pools und -Anbieter über mehrere Projekte hinweg zu verwalten, verwenden Sie ein einzelnes, dediziertes Projekt, um Workload Identity-Pools und -Anbieter zu verwalten. Ein dediziertes Projekt hilft bei Folgendem:

  • Dafür sorgen, dass nur vertrauenswürdige Identitätsanbieter für die Workload Identity-Föderation verwendet werden
  • Zugriff auf die Konfiguration von Workload Identity-Pools und -Anbietern zentral steuern
  • Konsistente Attributzuordnungen und Bedingungen auf alle Projekte und Anwendungen anwenden

Sie können Einschränkungen für Organisationsrichtlinien verwenden, um die Verwendung eines dedizierten Projekts zur Verwaltung von Workload Identity-Pools und -Anbietern zu erzwingen.

Erstellen von Workload Identity-Poolanbietern in anderen Projekten mithilfe von Einschränkungen für Organisationsrichtlinien deaktivieren

Nutzer mit der Berechtigung zum Erstellen von Workload Identity-Poolanbietern können Workload Identity-Pools und -Anbieter erstellen, die für die von Ihnen in einem dedizierten Projekt verwalteten redundant sein können.

Sie können das Erstellen neuer Workload Identity-Poolanbieter verhindern, indem Sie die Organisationsrichtlinieneinschränkung constraints/iam.workloadIdentityPoolProviders mit einer Regel verwenden, die auf Alle ablehnen gesetzt ist.

Wenden Sie diese Einschränkungen im Stammverzeichnis Ihrer Organisationshierarchie an, um die Erstellung neuer Workload Identity-Poolanbieter standardmäßig zu verweigern. Erstellen Sie Ausnahmen für die Projekte, in denen Sie die Verwaltung von Workload Identity-Pools und -Anbietern zulassen möchten. Wenden Sie dazu eine Richtlinieneinschränkung an, die bestimmte, vertrauenswürdige AWS-Konten oder OIDC-Anbieter zulässt.

Einzelnen Anbieter pro Workload Identity-Pool verwenden, um Themenkonflikte zu vermeiden

Mit der Workload Identity-Föderation können Sie mehr als einen Anbieter pro Workload Identity-Pool erstellen. Die Verwendung mehrerer Anbieter kann nützlich sein, wenn Identitäten von mehreren Anbietern verwaltet werden, Sie diese Komplexität aber vor Arbeitslasten, die in Google Cloud ausgeführt werden, verbergen möchten.

Die Verwendung mehrerer Anbieter birgt das Risiko von Themenkonflikten, bei denen die Attributzuordnung für google.subject eines Anbieters denselben Wert zurückgibt wie die Attributzuordnung für einen anderen Anbieter. Dies hat zur Folge, dass mehrere externe Identitäten demselben IAM-Hauptkonto zugeordnet werden. Dadurch sind die externen Identitäten in Cloud-Audit-Logs nicht mehr zu unterscheiden.

Verwenden Sie einen einzigen Anbieter pro Workload Identity-Pool, um Themenkonflikte zu vermeiden. Wenn Sie eine Föderation mit mehreren Anbietern einrichten müssen, erstellen Sie mehrere Workload Identity-Pools mit jeweils einem einzelnen Workload Identity-Anbieter.

Zweimalige Föderation mit dem selben Identitätsanbieter vermeiden

Sie können mehrmals eine Föderation mit demselben Identitätsanbieter einrichten, indem Sie mehrere Workload Identity-Poolanbieter erstellen, die dieselbe oder eine ähnliche Konfiguration verwenden. Wenn diese Anbieter zum selben Workload Identity-Pool gehören, kann eine solche Konfiguration zu Themenkonflikten führen. Wenn die Anbieter zu verschiedenen Workload Identity-Pools gehören, können keine Themenkonflikte auftreten. Stattdessen wird dieselbe externe Identität als unterschiedliche IAM-Hauptkonten dargestellt.

Die Zuordnung einer einzelnen externen Identität zu mehreren IAM-Hauptkonten macht es schwieriger zu analysieren, auf welche Ressourcen eine bestimmte externe Identität Zugriff hat. Eine solche Mehrdeutigkeit kann auch das Risiko erhöhen, wenn versucht wird, den Zugriff zu widerrufen: Ein Administrator könnte den Zugriff für ein Hauptkonto widerrufen, aber nicht wissen, dass ein anderes Hauptkonto vorhanden ist, wodurch versehentlich die externe Identität den Zugriff behält.

Vermeiden Sie es, mehrmals eine Föderation mit demselben Identitätsanbieter einzurichten, um das Risiko von Mehrdeutigkeiten zu minimieren. Erstellen Sie stattdessen einen einzelnen Workload Identity-Pool und -Anbieter und verwenden Sie eine Attributzuordnung und eine Bedingung, die dafür sorgt, dass er für alle externen Identitäten verwendet werden kann, die Zugriff auf Google Cloud-Ressourcen benötigen.

OIDC-Metadaten-Endpunkt Ihres Identitätsanbieters schützen

Wenn Sie eine Föderation mit einem OpenID Connect-Anbieter einrichten, lädt die Workload Identity-Föderation regelmäßig die OIDC-Metadaten Ihres Identitätsanbieters herunter. Die Workload Identity-Föderation verwendet die Metadaten des IdP und das JSON Web Key Set (JWKS), um Tokens zu validieren.

Um die Authentizität zu gewährleisten, wird die Kommunikation mit Ihrem Identitätsanbieter mithilfe von TLS gesichert. Wenn Ihr Anbieter hinter einem Load-Balancer oder einem Reverse-Proxy bereitgestellt wird, der TLS beendet, sorgt die TLS-Verbindung für die Authentizität des Load-Balancers oder Reverse-Proxys, aber nicht des tatsächlichen Identitätsanbieters.

Ein böswilliger Nutzer kann diese Konfiguration möglicherweise nutzen, indem er einen Man-in-the-Middle-Angriff startet (MITM), bei dem er den Load-Balancer so neu konfiguriert, dass er JWKS-Anfragen an einen schädlichen Endpunkt übergeben kann, der einen anderen Schlüsselsatz bereitstellt. Der Austausch des JWKS ermöglicht einem böswilligen Akteur das Signieren von Tokens, die von der Workload Identity-Föderation als gültig betrachtet werden, und möglicherweise das Spoofing der Identitäten anderer Nutzer.

Zum Schutz vor JWKS-Austausch muss Ihr IdP so bereitgestellt sein, dass er vor MITM-Angriffen geschützt ist.

URL des Workload Identity-Poolanbieters als Zielgruppe verwenden

Wenn Sie eine Föderation mit einem OpenID Connect-Anbieter einrichten, überprüft die Workload Identity-Föderation, dass die Zielgruppe der Tokens (in der Anforderung aud codiert) mit der Einstellung des Anbieters für die zulässige Zielgruppe übereinstimmt. Wenn Sie eine Föderation mit einem SAML-Anbieter einrichten, prüft die Workload Identity-Föderation, ob die SAML-Assertion eine Zielgruppeneinschränkung angibt, die der erwarteten Zielgruppe entspricht.

Standardmäßig erwartet die Workload Identity-Föderation, dass die Zielgruppe mit der URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID übereinstimmt, die den Workload Identity-Poolanbieter eindeutig identifiziert. Durch Anforderung von Tokens und Assertions für die Verwendung dieser URL als Zielgruppe können Sie das Risiko eines Confused-Deputy-Angriffs reduzieren. Bei einem solchen Angriff präsentiert ein böswilliger Akteur ein Token oder eine SAML-Assertion für die Workload Identity-Föderation, die nicht für die Workload Identity-Föderation verwendet werden sollte, sondern für eine andere API.

Sie können dafür sorgen, dass Clients nur Tokens und Assertions verwenden können, die speziell für die Workload Identity-Föderation ausgestellt wurden, indem Sie erforderlich machen, dass das Token oder die Assertion die URL des Workload Identity-Zielpoolanbieters enthält.

Unveränderliche Attribute in Attributzuordnungen verwenden

Um einer externen Identität zu erlauben, die Identität eines Dienstkontos anzunehmen, erstellen Sie eine IAM-Bindung, die auf die externe Identität anhand von Thema, Gruppe oder benutzerdefiniertem Attribut verweist. Das Thema, die Gruppe und die benutzerdefinierten Attribute der externen Identität werden aus den Attributen abgeleitet, die der externe Identitätsanbieter während des Tokenaustauschs an die Workload Identity-Föderation übergibt.

Bei einigen Identitätsanbietern können Nutzer einige ihrer eigenen Attribute ändern. Beispielsweise kann ein Nutzer seine E-Mail-Adresse oder Aliasse ändern. Wenn Ihre IAM-Bindungen auf Attribute verweisen, die geändert werden können, verlieren Nutzer möglicherweise versehentlich den Zugriff auf bestimmte Ressourcen, indem sie ihr Nutzerprofil ändern. Umgekehrt können böswillige Akteure absichtlich einen nicht autorisierten Zugriff auf andere Ressourcen erhalten, indem sie ihre Nutzerattribute absichtlich so ändern, dass sie vorhandenen IAM-Bindungen entsprechen.

Zum Schutz vor Spoofing-Bedrohungen sollten Sie die Attributzuordnungen auf Attribute beschränken, die nicht vom Nutzer oder überhaupt nicht geändert werden können.

Nicht wiederverwendbare Attribute in Attributzuordnungen verwenden

Wenn Sie einer externen Identität die Berechtigung erteilen, die Identität eines Dienstkontos zu übernehmen und den Nutzer anschließend beim externen Identitätsanbieter zu löschen, bleibt die IAM-Bindung des Dienstkontos erhalten.

Wenn Sie später einen neuen Nutzer zu Ihrem externen Identitätsanbieter hinzufügen und der Nutzer bestimmte Attribute mit dem zuvor gelöschten Nutzer gemeinsam hat (z. B. dieselbe E-Mail-Adresse), sind der alte und der neue Nutzer für die Workload Identity-Föderation nicht zu unterscheiden. Daher gilt eine IAM-Bindung, die nur auf den alten Nutzer verweisen sollte, möglicherweise auch für den neuen Nutzer.

Um solche Mehrdeutigkeiten zu vermeiden, verwenden Sie Attributzuordnungen, die ausschließlich Attribute verwenden, die im Laufe der Zeit nicht wiederverwendet werden können, z. B. eine eindeutige Nutzer-ID.

Wenn in Ihrer Unternehmensrichtlinie die Wiederverwendung von Attributen wie E-Mail-Adressen zulässig ist, sollten Sie diese Attribute nicht in Attributzuordnungen verwenden und stattdessen ein anderes Attribut verwenden, das im Laufe der Zeit garantiert eindeutig ist.

Nicht zulassen, dass Attributzuordnungen geändert werden

Bei der Workload Identity-Föderation wird mithilfe von Attributzuordnungen ausgewählt, welche Attribute des externen Identitätsanbieters in ein STS-Token eingebettet werden sollen und wie die Attributnamen übersetzt werden sollen. Die Konfiguration von Attributzuordnungen ist ein wichtiger Schritt zum Einrichten der Vertrauensstellung zwischen dem externen Identitätsanbieter und Google Cloud.

Attributzuordnungen sind auch für die Sicherheit der Workload Identity Federation wichtig: Wenn Sie einem föderierten Hauptkonto oder einer föderierten Hauptkontogruppe die Fähigkeit gegeben haben, die Identität eines Dienstkontos zu übernehmen, und später die Attributzuordnung zu ändern, könnten Sie ändern, welche Nutzer Zugriff auf das Dienstkonto haben.

Zum Ändern von Attributzuordnungen ist die Berechtigung iam.googleapis.com/workloadIdentityPoolProviders.update erforderlich. Rollen mit dieser Berechtigung umfassen:

  • Inhaber (roles/owner)
  • IAM Workload Identity-Pooladministrator (roles/iam.workloadIdentityPoolAdmin)

Wenn ein böswilliger Akteur berechtigt ist, Attributzuordnungen zu ändern, kann er möglicherweise die Zuordnungsregeln so ändern, dass er seine Identität verheimlichen und Zugriff auf ein Dienstkonto erlangen kann. Übertragen Sie nur wenigen administrativen Nutzern die Berechtigung zum Ändern von Attributzuordnungen, um solche schädlichen Änderungen zu verhindern.

Erwägen Sie die Erstellung eines dedizierten Google Cloud-Projekts zur Verwaltung von Workload Identity-Pools, um das Risiko zu verringern, dass Nutzern versehentlich eine dieser Rollen auf einer höheren Ebene in der Ressourcenhierarchie zugewiesen wird.

Verlassen Sie sich nie auf Attribute, die nicht stabil oder zuverlässig sind.

Ein Identitätsanbieter verwendet Attribute, um Informationen zu authentifizierten Nutzern zu kommunizieren. Identitätsanbieter garantieren in der Regel, dass einige Attribute autoritativ sind, aber andere sind es nicht. Ein externer Identitätsanbieter kann beispielsweise sowohl einen Nutzernamen als auch eine Nutzer-ID in ein OIDC-Token einbetten. Beide Attribute identifizieren einen Nutzer eindeutig und scheinen vielleicht untereinander austauschbar zu sein. Der externe Identitätsanbieter kann jedoch garantieren, dass die Nutzer-ID stabil und autoritativ ist, aber erlauben, Nutzernamen zu ändern.

Wenn Ihre Attributzuordnungen auf Attributen basieren, die nicht stabil oder zuverlässig sind, kann ein böswilliger Akteur seine Identität manipulieren, indem er sein Nutzerprofil im externen Identitätsanbieter ändert. Beispielsweise kann ein solcher Akteur seinen Nutzernamen in den eines Nutzers ändern, der kürzlich beim externen Identitätsanbieter gelöscht wurde, aber weiterhin Zugriff auf ein Dienstkonto in Google Cloud hat.

Achten Sie darauf, dass Ihre Attributzuordnungen nur auf Attributen basieren, die der externe Identitätsanbieter als stabil und autoritativ garantiert, um solche Spoofing-Angriffe zu verhindern.

Schutz vor Nichterkennungs-Bedrohungen

Wenn Sie verdächtige Aktivitäten bemerken, die sich auf eine Ihrer Ressourcen in Google Cloud auswirken, sind Cloud-Audit-Logs eine wichtige Informationsquelle, um herauszufinden, wann die Aktivität stattgefunden hat und welche Nutzer beteiligt waren.

Wenn eine Anwendung die Workload Identity-Föderation verwendet, übernimmt sie die Identität eines Dienstkontos. In Cloud-Audit-Logs werden alle von der Anwendung ausgeführten Aktivitäten dem Dienstkonto zugeordnet, dessen Identität übernommenen wurde. Um die vollständige Kette der Ereignisse zu rekonstruieren, die zur Aktivität geführt haben, müssen Sie in der Lage sein, Cloud-Audit-Logs mit den Logs Ihres Identitätsanbieters zu korrelieren, damit Sie herausfinden können, welche externe Identität beteiligt war und warum eine Aktivität ausgeführt wurde.

Dieser Abschnitt enthält Best Practices, mit denen Sie einen prüfbaren Audit-Trail verwalten können.

Best Practices:

Datenzugriffslogs für IAM APIs aktivieren
Eindeutige Themenzuordnung verwenden

Datenzugriffslogs für IAM APIs aktivieren

Damit Sie Szenarien identifizieren und verstehen können, in denen die Identitätsübernahme von Dienstkonten relevant ist, stellen Dienste wie Compute Engine in ihren Cloud-Audit-Logs einen serviceAccountDelegationInfo-Abschnitt bereit. Wenn eine Anwendung die Workload Identity-Föderation verwendet, enthält dieser Abschnitt das Thema des Hauptkontos, das zur Übernahme der Identität des Dienstkontos verwendet wurde.

Nicht alle Dienste enthalten Details zur Identitätsübernahme in ihren Cloud-Audit-Logs. Zur Aufrechterhaltung eines prüfbaren Audit-Trails müssen Sie auch alle Identitätsübernahmeereignisse aufzeichnen, indem Sie für die Security Token Service API und die Identity and Access Management API Datenzugriffslogs aktivieren. Aktivieren Sie diese Logs für alle Cloud-Projekte, die Workload Identity-Pools oder Dienstkonten, die für die Workload Identity-Föderation verwendet werden, enthalten.

Durch die Aktivierung dieser Logs sorgen Sie dafür, dass den Cloud-Audit-Logs immer ein Eintrag hinzugefügt wird, wenn eine Anwendung Workload Identity-Föderation für den Austausch externer Anmeldedaten und die Übernahme der Identität eines Dienstkontos verwendet.

Eindeutige Themenzuordnung verwenden

Das Hauptkontothema, das im Abschnitt "serviceAccountDelegationInfo" in Cloud-Audit-Logs verwendet wird, wird durch die Attributzuordnung Ihres Workload Identity-Poolanbieters für google.subject bestimmt.

Wenn Sie verdächtige Aktivitäten erkennen und herausfinden müssen, welche externe Identität beteiligt war, müssen Sie eine externe Identität anhand des entsprechenden google.subject-Werts ermitteln können.

Wenn eine externe Identität manipuliert wurde und Sie herausfinden müssen, ob die Identität für den Zugriff auf Google Cloud-Ressourcen verwendet wurde, müssen Sie Cloud Audit-Logeinträge finden können, die der externen Identität entsprechen.

Wenn Sie die Attributzuordnung für einen Workload Identity-Poolanbieter definieren, wählen Sie eine eindeutige Zuordnung für google.subject aus, damit Folgendes gilt:

  • Eine externe Identität wird genau einem google.subject-Wert zugeordnet.
  • Ein google.subject-Wert ist genau einer externen Identität zugeordnet.
  • Sie können eine externe Identität anhand ihres google.subject-Werts nachschlagen.

Wenn Sie eine Attributzuordnung verwenden, die diese Eindeutigkeitskriterien erfüllt, können Sie dafür sorgen, dass Sie externe Identitäten anhand ihres google.subject-Werts suchen können und umgekehrt.

Schutz vor Rechteausweitungen

Um das Prinzip der geringsten Berechtigung bei der Verwendung der Workload Identity-Föderation anzuwenden, müssen Sie:

  • Die Anzahl der externen Identitäten begrenzen, die die Identität eines Dienstkontos übernehmen können
  • Die Ressourcen einschränken, auf die ein Dienstkonto zugreifen kann

Eine zu lockere Konfiguration kann dazu führen, dass ein böswilliger Akteur eine externe Identität verwenden kann, um seine Berechtigungen auszuweiten und auf Ressourcen zuzugreifen, die für ihn nicht zugänglich sein sollten.

Die folgenden Abschnitte enthalten Best Practices, die Sie vor Bedrohungen durch Rechteausweitung schützen können.

Best Practices:

Dienstkonten verwenden, die sich im selben Projekt wie die Ressourcen befinden, auf die Sie zugreifen müssen
Für jede Anwendung ein eigenes Dienstkonto verwenden
Zugriff nicht allen Mitgliedern eines Pools gewähren

Dienstkonten verwenden, die sich im selben Projekt wie die Ressourcen befinden, auf die Sie zugreifen müssen

Wenn ein Client die Workload Identity-Föderation mithilfe von Clientbibliotheken oder der REST API verwendet, folgt er einer dreistufigen Vorgehensweise:

  1. Rufen Sie Anmeldedaten vom vertrauenswürdigen Identitätsanbieter ab.
  2. Tauschen Sie die Anmeldedaten gegen ein Token des Security Token Service aus.
  3. Verwenden Sie das Token des Security Token Service, um eine Identität als Dienstkonto zu übernehmen und ein kurzlebiges Google-Zugriffstoken abzurufen.

Verwenden Sie im letzten Schritt ein Dienstkonto, das sich im selben Projekt wie die Ressourcen befindet, auf die Sie zugreifen müssen. Wenn Sie ein Dienstkonto verwenden, das im selben Projekt verwaltet wird, können Sie restriktivere Zugriffsberechtigungen anwenden. Außerdem können Sie leichter entscheiden, wann das Dienstkonto nicht mehr benötigt wird.

Für jede Anwendung ein eigenes Dienstkonto verwenden

Wenn Sie mehrere Anwendungen haben, die die Workload Identity-Föderation verwenden, um auf Ressourcen im selben Projekt zuzugreifen, erstellen Sie für jede Anwendung ein dediziertes Dienstkonto. Mit anwendungsspezifischen Dienstkonten können Sie übermäßige Berechtigungen vermeiden, indem Sie nur den Zugriff auf jene Ressourcen gewähren, die jede einzelne Anwendung benötigt.

Zugriff nicht allen Mitgliedern eines Pools gewähren

Bevor eine externe Identität die Identität eines Dienstkontos übernehmen kann, müssen Sie ihr die Rolle roles/iam.workloadIdentityUser für das Dienstkonto zuweisen. Wenn Sie diese Rolle zuweisen, sollten Sie sie nicht allen Mitgliedern des Workload Identity-Pools zuweisen. Weisen Sie die Rolle stattdessen bestimmten externen Identitäten oder Identitäten, die bestimmten Kriterien entsprechen, zu.

Zu Beginn ist die Anzahl der externen Nutzer, die Zugriff auf Google Cloud-Ressourcen benötigen, möglicherweise gering. Die Attributbedingung des Workload Identity-Pools und die Konfiguration Ihres Identitätsanbieters erlaubt daher möglicherweise nur wenigen externen Identitäten die Verwendung der Workload Identity-Föderation.

Wenn Sie später neue Arbeitslasten in Google Cloud einbinden, müssen Sie möglicherweise die Konfiguration Ihres Identitätsanbieters oder die Attributbedingung des Workload Identity-Pools ändern, um zusätzliche externe Identitäten zuzulassen.

Wenn Sie die Rolle roles/iam.workloadIdentityUser nur bestimmten externen Identitäten zuweisen, können Sie dadurch dafür sorgen, dass Sie einen Workload Identity-Pool sicher erweitern können, ohne versehentlich mehr externen Identitäten als nötig die Identitätsübernahme zu ermöglichen.

Nächste Schritte