Best Practices zum Schützen von Dienstkonten

Dienstkonten unterscheiden sich von Nutzerkonten dadurch, dass sie sowohl eine Ressource als auch ein Hauptkonto sind:

  • Als Hauptkonto kann einem Dienstkonto Zugriff auf Ressourcen gewährt werden, z. B. auf einen Cloud Storage-Bucket.
  • Als Ressource kann auf ein Dienstkonto zugegriffen und dieses von anderen Hauptkonten, darunter Nutzer und Gruppen, imitiert werden.

Zum Schutz von Dienstkonten sollten Sie deren duale Natur berücksichtigen:

  • Da Dienstkonten Hauptkonten sind, müssen Sie deren Berechtigungen einschränken, um mögliche Schäden durch ein manipuliertes Dienstkonto zu reduzieren.
  • Da Dienstkonten Ressourcen sind, müssen Sie sie vor Manipulationen schützen.

Dienstkonten können auf verschiedene Weise missbraucht werden:

  • Eskalation von Berechtigungen: Ein böswilliger Akteur kann Zugriff auf Ressourcen erlangen, auf die er sonst nicht zugreifen könnte, indem er die Identität des Dienstkontos annimmt.
  • Spoofing: Ein böswilliger Akteur kann die Identität eines Dienstkontos stehlen, um seine Identität zu verheimlichen.
  • Nicht-Nachverfolgbarkeit: Ein böswilliger Akteur kann seine Identität und seine Aktionen verbergen, indem er ein Dienstkonto dazu veranlasst, Vorgänge für ihn auszuführen. In einigen Fällen kann es unmöglich sein, diese Aktionen auf den böswilligen Akteur zurückzuverfolgen.
  • Informationsoffenlegung: Ein böswilliger Akteur kann aus der Existenz bestimmter Dienstkonten Informationen über Ihre Infrastruktur, Anwendungen oder Prozesse ableiten.

In diesem Leitfaden werden Best Practices vorgestellt, mit denen Sie die Berechtigungen von Dienstkonten einschränken, um diese ernsten Risiken zu minimieren.

Berechtigungen von Dienstkonten einschränken

Dienstkonten sind Hauptkonten und können wie reguläre Nutzerkonten Zugriff auf Ressource erhalten.

Verwenden Sie nie automatische Rollenzuweisungen für Standarddienstkonten

Einige Google Cloud-Dienste erstellen Standarddienstkonten, wenn Sie ihre API zum ersten Mal in einem Google Cloud-Projekt aktivieren. Standardmäßig wird diesen Dienstkonten die Rolle Bearbeiter (roles/editor) für Ihr Cloud-Projekt zugewiesen, mit der sie alle Ressourcen im Cloud-Projekt lesen und ändern können. Die Rolle wird der Einfachheit halber zugewiesen, ist aber für die Arbeit der Dienste nicht erforderlich: Google Cloud-Dienste verwenden Dienst-Agents, um auf Ressourcen in Ihrem Cloud-Projekt zuzugreifen. nicht die Standarddienstkonten.

Wenn Sie verhindern möchten, dass Standarddienstkonten automatisch die Rolle Bearbeiter zugewiesen wird, aktivieren Sie für Ihre Organisation die Einschränkung Automatische IAM-Zuweisungen für Standarddienstkonten deaktivieren (constraints/iam.automaticIamGrantsForDefaultServiceAccounts). Wenn Sie die Einschränkung auf mehrere Cloud-Projekte anwenden möchten, konfigurieren Sie sie im Ordner oder auf dem Organisationsknoten. Durch das Anwenden der Einschränkung wird die Rolle Bearbeiter nicht aus vorhandenen Standarddienstkonten entfernt.

Verlassen Sie sich beim Anhängen eines Dienstkontos an eine VM-Instanz nicht auf Zugriffsbereiche

Wenn Sie einer VM-Instanz ein Dienstkonto anhängen, können Sie einen oder mehrere Zugriffsbereiche angeben. Mit Zugriffsbereichen können Sie einschränken, auf welche Dienste die VM zugreifen kann. Die Einschränkungen werden zusätzlich zu den IAM-Richtlinien (Identity and Access Management) angewendet.

Zugriffsbereiche sind grobe Ressourcen. Mit dem Bereich https://www.googleapis.com/auth/devstorage.read_only können Sie beispielsweise den Zugriff auf schreibgeschützte Cloud Storage-Vorgänge einschränken, aber nicht auf bestimmte Buckets. Daher sind Zugriffsbereiche nicht geeignet, um detaillierte IAM-Richtlinien zu ersetzen.

Statt sich auf Zugriffsbereiche zu verlassen sollten Sie ein dediziertes Dienstkonto erstellen und detaillierten IAM-Richtlinien nutzen, um einzuschränken, auf welche Ressourcen das Dienstkonto zugreifen kann.

Verwenden Sie nie Gruppen, um Dienstkonten Zugriff auf Ressourcen zu gewähren

In Organisationen ist es üblich, dass mehrere Mitarbeiter ähnliche oder sich überschneidende Jobfunktionen ausführen und daher einen ähnlichen Zugriff auf Ressourcen benötigen. Mit Gruppen können Sie diese Gemeinsamkeiten nutzen, um den Verwaltungsaufwand zu verringern.

Dienstkonten sind für Anwendungen vorgesehen. Es ist selten, dass mehrere Anwendungen dieselbe Funktion ausführen und daher ähnliche oder identische Zugriffsanforderungen haben. Stattdessen sind Anwendungen in der Regel eindeutig und die Ressourcen, auf die sie Zugriff benötigen, variieren normalerweise für jede Anwendung.

Werden Gruppen verwendet, um Dienstkonten Zugriff auf Ressourcen zu gewähren, kann dies zu unerwünschten Ergebnissen führen:

  • Es können viele Gruppen entstehen, die jeweils nur ein oder einige Dienstkonten enthalten.
  • Es kann zu einer "Berechtigungswucherung" kommen: Im Laufe der Zeit wird einer Gruppe Zugriff auf eine zunehmende Anzahl an Ressourcen gewährt, obwohl jedes Mitglied der Gruppe nur Zugriff auf einen Untersatz der Ressourcen benötigt.

Ist der Zweck der Gruppen nicht klar definiert, sollten Sie Gruppen nicht verwenden. Gewähren Sie stattdessen Dienstkonten direkt den Zugriff auf die benötigten Ressourcen.

Verwenden Sie nie die domainweite Delegierung

Die domainweite Delegierung ermöglicht es Dienstkonten, die Identität eines beliebigen Nutzers in einem Cloud Identity- oder Google Workspace-Konto zu übernehmen. Mit der domainweiten Delegierung können Dienstkonten bestimmte Verwaltungsaufgaben in Google Workspace und Cloud Identity ausführen oder auf Google APIs zugreifen, die Dienstkonten von außerhalb der Google Cloud nicht unterstützen.

Die domainweite Delegierung beschränkt Dienstkonten nicht darauf, die Identität eines bestimmten Nutzers vorzugeben. Stattdessen kann es beliebige Nutzer in einem Cloud Identity- oder Google Workspace-Konto imitieren, einschließlich Super Admins. Wenn Sie einem Dienstkonto die Verwendung der domainweiten Delegierung gestatten, kann das Dienstkonto ein Angriffsziel für Rechteausweitungsangriffe werden.

Vermeiden Sie die Verwendung der domainweiten Delegierung, wenn Sie Ihre Aufgabe direkt mit einem Dienstkonto oder dem OAuth-Zustimmungsablauf ausführen können.

Wenn Sie die domainweite Delegierung nicht vermeiden können, schränken Sie die Reihe der OAuth-Bereiche ein, die das Dienstkonto verwenden kann. OAuth-Bereiche beschränken zwar nicht, welche Nutzer die Identität des Dienstkontos übernehmen können, aber sie beschränken die Arten von Nutzerdaten, auf die das Dienstkonto zugreifen kann.

Zugriffsbeschränkungen für Anmeldedaten nutzen, um Zugriffstokens einzuschränken

Google-Zugriffstoken sind Inhabertokens, was ihre Verwendung nicht an eine bestimmte Anwendung gebunden ist. Wenn Ihre Anwendung ein Zugriffstoken an eine andere Anwendung übergibt, kann sie von dieser Anwendung auf die gleiche Weise verwendet werden. Wenn ein Zugriffstoken an einen böswilligen Nutzer weitergegeben wird, kann es das Token verwenden, um Zugriff zu erhalten.

Da Zugriffstokens Inhabertokens sind, müssen Sie sie davor schützen, dass sie übernommen oder für nicht autorisierte Parteien sichtbar werden. Sie können mögliche Schäden durch ein übernommenes Zugriffstoken begrenzen, indem Sie die Ressourcen einschränken, auf die es Zugriff gewährt. Dieser Vorgang wird als "Downscoping" bezeichnet.

Mit Grenzwerten für den Zugriff auf Anmeldedaten können Sie Zugriffstokens einschränken, wenn Sie ein Zugriffstoken an eine andere Anwendung oder eine andere Komponente Ihrer Anwendung übergeben. Legen Sie die Zugriffsgrenze so fest, dass das Token genügend Zugriff auf die erforderlichen Ressourcen gewährt, aber nicht mehr.

Nicht genutzte Berechtigungen anhand von Rollenempfehlungen ermitteln

Wenn Sie eine Anwendung zum ersten Mal bereitstellen, sind Sie vielleicht nicht sicher, welche Rollen und Berechtigungen die Anwendung wirklich benötigt. Das bedeutet, dass Sie dem Dienstkonto der Anwendung gegebenenfalls mehr Berechtigungen erteilen.

Gleichermaßen können sich die Zugriffsanforderungen einer Anwendung im Laufe der Zeit ändern. Möglicherweise sind einige der Rollen und Berechtigungen, die Sie zu Beginn erteilt haben, irgendwann nicht mehr erforderlich.

Verwenden Sie Rollenempfehlungen, um zu ermitteln, welche Berechtigungen eine Anwendung tatsächlich nutzt und welche Berechtigungen möglicherweise nicht verwendet werden. Passen Sie die IAM-Richtlinien der betroffenen Ressourcen an, um sicherzustellen, dass einer Anwendung nie mehr Zugriff gewährt wird, als sie tatsächlich benötigt.

Schutz vor Rechteausweitungen

Ein Dienstkonto, dem keine Rollen zugewiesen wurden, das keinen Zugriff auf Ressourcen hat und keine Firewallregel umfasst ist normalerweise von nur geringem Wert. Sobald Sie einem Dienstkonto Zugriff auf Ressourcen gewährt haben, erhöht sich der Wert des Dienstkontos: Das Dienstkonto ist für Sie nützlicher, wird aber auch attraktiver für Rechteausweitungs-Angriffe.

Nehmen wir als Beispiel ein Dienstkonto an, das uneingeschränkten Zugriff auf einen Cloud Storage-Bucket mit vertraulichen Informationen hat. In dieser Situation ist das Dienstkonto praktisch genauso wertvoll wie der Cloud Storage-Bucket selbst: Anstatt direkt auf den Bucket zuzugreifen, kann ein böswilliger Akteur möglicherweise versuchen, die Kontrolle über das Dienstkonto zu übernehmen. Wenn dieser Versuch erfolgreich ist, kann der böswillige Akteur seine Berechtigungen eskalieren, indem er die Identität des Dienstkontos annimmt und damit Zugriff auf die vertraulichen Informationen im Bucket gewährt.

Die Techniken zur Eskalation von Berechtigungen unter Einsatz von Dienstkonten lassen sich in der Regel folgenden Kategorien zuordnen:

  • Direkter Identitätsdiebstahl: Möglicherweise gewähren Sie einem Nutzer versehentlich die Erlaubnis, ein Dienstkonto zu imitieren oder einen Dienstkontoschlüssel für ein Dienstkonto zu erstellen. Wenn das Dienstkonto mehr Berechtigungen hat als der Nutzer selbst, kann der Nutzer diese Funktion nutzen, um seine Berechtigungen zu eskalieren und Zugriff auf Ressourcen zu erhalten, auf die er sonst nicht zugreifen kann.
  • Indirekter Identitätsdiebstahl: Wenn ein Nutzer die Identität eines Dienstkontos nicht direkt übernehmen kann, kann er das möglicherweise indirekt tun, falls das Dienstkonto von einer CI/CD-Pipeline verwendet wird oder eine VM-Instanz oder ein anderes Automatisierungssystem auf sie zugreifen können: Wenn das System keine angemessenen Zugriffsbeschränkungen implementiert, kann der Nutzer Vorgänge ausführen, die er selbst nicht durchführen darf, und so seine Berechtigungen eskalieren.
  • IAM-Richtlinien, Gruppen oder benutzerdefinierte Rollenänderungen: Ein Nutzer, der keinen Zugriff auf ein privilegiertes Dienstkonto hat, hat möglicherweise dennoch die Berechtigung, die IAM-Richtlinien des Dienstkontos zu ändern und Cloud-Projekte oder Ordner einzubeschließen. Der Nutzer könnte dann eine dieser IAM-Richtlinien erweitern, um sich (direkt oder indirekt) die Annahme der Identität des Dienstkontos zu gewähren.

In folgenden Abschnitten werden Best Practices zum Schutz von Dienstkonten vor der Gefahr einer Rechteausweitung beschrieben.

Vermeiden Sie es, Nutzern die Übernahme der Identität von Dienstkonten zu ermöglichen, die mehr Rechte haben als sie selbst.

Durch die Übernahme der Identität eines Dienstkontos erhalten Nutzer Zugriff auf einige oder alle Ressourcen, auf die das Dienstkonto zugreifen kann. Wenn das Dienstkonto umfassendere Zugriffsrechte hat als der Nutzer, ist es privilegierter als der Nutzer.

Wenn Sie einem Nutzer die Berechtigung erteilen, ein privilegierteres Dienstkonto zu imitieren, kann dies es dem Nutzer erlauben, seine Berechtigungen absichtlich temporär zu steigern – ähnlich wie bei der Verwendung des sudo-Tools unter Linux oder der Prozesshöhe unter Windows. Wenn Sie nicht mit einem Szenario konfrontiert sind, in der eine solche vorübergehende Rechteberechtigung erforderlich ist, sollten Sie es Nutzern nie erlauben, die Identität eines privilegierteren Dienstkontos zu übernehmen.

Zu den Berechtigungen, die es Nutzern ermöglichen, die Identität eines Dienstkontos zu übernehmen, gehören:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

Zu den Rollen, die einigen dieser Berechtigungen haben, gehören unter anderem:

  • Inhaber (roles/owner)
  • Bearbeiter (roles/editor)
  • Dienstkontonutzer (roles/iam.serviceAccountUser)
  • Ersteller von Dienstkonto-Token (roles/iam.serviceAccountTokenCreator)
  • Zentraler Dienstkontoadministrator (roles/iam.serviceAccountKeyAdmin)
  • Dienstkontoadministrator (roles/iam.serviceAccountAdmin)
  • Workload Identity-Nutzer (roles/iam.workloadIdentityUser)
  • Deployment Manager-Bearbeiter (roles/deploymentmanager.editor)
  • Cloud-Build-Bearbeiter (roles/cloudbuild.builds.editor)

Bevor Sie einem Nutzer eine dieser Rollen zuweisen, sollten Sie sich folgende Fragen stellen:

  • Auf welche Ressourcen innerhalb und außerhalb des aktuellen Cloud-Projekts könnte der Nutzer zugreifen, wenn er die Identität des Dienstkontos annimmt?
  • Ist diese Zugriffsebene gerechtfertigt?
  • Gibt es ausreichende Schutzmaßnahmen, mit denen kontrolliert wird, unter welchen Bedingungen der Nutzer die Identität des Dienstkontos übernehmen kann?

Weisen Sie die Rolle nicht zu, wenn Sie nicht alle Fragen bestätigen können. Stattdessen sollten Sie dem Nutzer ein anderes, weniger privilegiertes Dienstkonto zuweisen.

Erlauben Sie es Nutzern nie, die IAM-Richtlinien von privilegierteren Dienstkonten zu ändern

Welche Nutzer ein Dienstkonto verwenden oder dessen Identität übernehmen dürfen, wird durch die IAM-Richtlinie des Dienstkontos erfasst. Die IAM-Richtlinie kann von Nutzern geändert oder erweitert werden, die die Berechtigung iam.serviceAccounts.setIamPolicy für das jeweilige Dienstkonto haben. Zu den Rollen, die diese Berechtigung enthalten, gehören:

  • Inhaber (roles/owner)
  • Sicherheitsadministrator (roles/iam.securityAdmin)
  • Dienstkontoadministrator (roles/iam.serviceAccountAdmin)

Mit Rollen mit der Berechtigung iam.serviceAccounts.setIamPolicy haben Nutzer die vollständige Kontrolle über ein Dienstkonto:

  • Der Nutzer kann sich selbst die Berechtigung erteilen, die Identität des Dienstkontos zu übernehmen. Dadurch kann er auf dieselben Ressourcen wie das Dienstkonto zugreifen.
  • Der Nutzer kann anderen Nutzern einen identischen oder ähnlichen Zugriff auf das Dienstkonto gewähren.

Bevor Sie Nutzern eine dieser Rollen zuweisen sollten Sie sich fragen, auf welche Ressourcen innerhalb und außerhalb des aktuellen Cloud-Projekts Nutzer zugreifen können, wenn Sie die Identität des Dienstkontos übernehmen. Erlauben Sie Nutzern nie, die IAM-Richtlinie eines Dienstkontos zu ändern, wenn das Dienstkonto mehr Berechtigungen als der Nutzer hat.

Erlauben Sie es Nutzern nie, Dienstkontoschlüssel zu erstellen oder hochzuladen

Dienstkontoschlüssel ermöglichen es Anwendungen oder Nutzern, sich als Dienstkonto zu authentifizieren. Im Gegensatz zu anderen Formen des Identitätsdiebstahls eines Dienstkontos ist für die Verwendung eines Dienstkontoschlüssels keine vorherige Authentifizierung erforderlich. Jeder, der einen Dienstkontoschlüssel besitzt, kann ihn verwenden.

Die Verwendung eines Dienstkontoschlüssels zur Authentifizierung ähnelt anderen Formen des Identitätsdiebstahls. Wenn Sie einem Nutzer Zugriff auf einen Dienstkontoschlüssel oder die Berechtigung zum Erstellen eines neuen Dienstkontoschlüssels gewähren, kann er die Identität des Dienstkontos übernehmen und auf alle Ressourcen zugreifen, auf die dieses Dienstkonto zugreifen kann.

Das erstellen oder hochladen eines Dienstkontoschlüssels erfordert die Berechtigung iam.serviceAccountKeys.create, die in den Rollen Dienstkontoschlüssel-Administrator (roles/iam.serviceAccountKeyAdmin ) und Bearbeiter (roles/editor) enthalten ist.

Bevor Sie einem Nutzer eine Rolle zuweisen, die die Berechtigung iam.serviceAccountKeys.create enthält, fragen Sie sich, auf welche Ressourcen innerhalb und außerhalb des aktuellen Cloud-Projekts dieser Nutzer Zugriff erhalten kann, wenn er die Identität des Dienstkontos übernimmt. Erlauben Sie Nutzern nie, Dienstkontoschlüssel für Dienstkonten zu erstellen, die mehr Berechtigungen haben als sie.

Wenn für Ihr Cloud-Projekt keine Dienstkontoschlüssel erforderlich sind, wenden Sie die Organisationsrichtlinieneinschränkungen Erstellung von Dienstkontoschlüsseln deaktivieren und Hochladen von Dienstkontoschlüsseln deaktivieren auf das Cloud-Projekt oder den einschließenden Ordner an. Diese Beschränkungen verhindern, dass Nutzer Dienstkontoschlüssel erstellen oder hochladen, einschließlich der Nutzer mit der Berechtigung iam.serviceAccountKeys.create für ein Dienstkonto.

Gewähren Sie nie Zugriff auf Dienstkonten auf Cloud-Projekt- oder Ordnerebene

Dienstkonten sind Ressourcen und Teil der Ressourcenhierarchie. Sie können den Zugriff auf Dienstkonten daher auf einer der folgenden Ebenen verwalten:

  • Das einzelne Dienstkonto
  • Das einschließende Cloud-Projekt
  • Ein übergeordneter Ordner des Cloudprojekts
  • Organisationsknoten

Die Verwaltung des Zugriffs auf der Ebene des Cloudprojekts oder auf einer höheren Ebene der Ressourcenhierarchie kann den Verwaltungsaufwand verringern, aber auch zu einer übermäßigen Vergabe von Berechtigungen führen. Wenn Sie einem Nutzer zum Beispiel die Rolle "Ersteller von Dienstkonto-Tokens" in einem Cloud-Projekt gewähren, kann dieser Nutzer ein beliebiges Dienstkonto im Cloud-Projekt imitieren. Die Möglichkeit eines Identitätsdiebstahls bedeutet, dass der Nutzer potenziell Zugriff auf alle Ressourcen hat, auf die diese Dienstkonten zugreifen können, einschließlich Ressourcen außerhalb des Cloud-Projekts.

Um die übermäßige Vergabe von Berechtigungen zu vermeiden, verwalten Sie den Zugriff auf Dienstkonten nicht auf Cloudprojekt- oder Ordnerebene. Verwalten Sie den Zugriff stattdessen für jedes Dienstkonto.

Führen Sie nie Code aus weniger geschützten Quellen auf Rechenressourcen aus, an die ein privilegiertes Dienstkonto angehängt ist.

Wenn Sie ein Dienstkonto an eine Rechenressource anhängen, z. B. eine VM-Instanz oder eine Cloud Run-Anwendung, können Prozesse, die auf dieser Ressource ausgeführt werden, den Metadatenserver verwenden, um Zugriffstokens und ID-Tokens anzufordern Mit diesen Tokens kann der Prozess die Identität des Dienstkontos übernehmen und in dessen Namen auf Ressourcen zugreifen.

Standardmäßig ist der Zugriff auf den Metadatenserver nicht auf bestimmte Prozesse oder Nutzer beschränkt. Stattdessen kann jeder Code, der auf der Compute-Ressource ausgeführt wird, auf den Metadatenserver zugreifen und ein Zugriffstoken abrufen. Dieser Code kann Folgendes umfassen:

  • Den Code Ihrer Anwendung.
  • Von Endnutzern übermittelten Code, wenn Ihre Anwendung eine serverseitige Skriptauswertung zulässt.
  • Code, der aus einem Remote-Quell-Repository gelesen wurde, wenn die Compute-Ressource Teil eines CI/CD-Systems ist.
  • Skripts für das Starten und Herunterfahren, die von einem Cloud Storage-Bucket bereitgestellt werden.
  • Gastrichtlinien, von VM Manager verteilt.

Wenn Code von Nutzern übergeben oder von einem Remote-Speicherort ausgelesen wird, müssen Sie dafür sorgen, dass dieser vertrauenswürdig ist und dass die Remote-Speicherorte zumindest so gut geschützt sind wie das angehängte Dienstkonto. Wenn ein Remote-Speicherort weniger sicher ist als das Dienstkonto, kann ein böswilliger Akteur eventuell seine Berechtigungen eskalieren. Dies kann durch das Einfügen von Schadcode erreicht werden, der die Berechtigungen des Dienstkontos an diesem Speicherort verwendet.

Beschränken Sie den Shell-Zugriff auf VMs, an die ein privilegiertes Dienstkonto angehängt ist

Einige Compute-Ressourcen unterstützen den interaktiven Zugriff und ermöglichen es Nutzern, Shell-Zugriff auf das System zu erhalten. Beispiel:

  • Mit Compute Engine können Sie sich über SSH oder RDP bei einer VM-Instanz anmelden.
  • In Google Kubernetes Engine können Sie mithilfe von kubectl exec einen Befehl ausführen oder eine Shell in einem Kubernetes-Container starten.

Wenn einer VM-Instanz ein privilegiertes Dienstkonto zugewiesen ist, kann jeder Nutzer mit Shell-Zugriff auf das System die Identität des Dienstkontos übernehmen und in dessen Namen auf Ressourcen zugreifen. Wenn Sie verhindern möchten, dass Nutzer diese Möglichkeit missbrauchen, um ihre Berechtigungen zu eskalieren, müssen Sie dafür sorgen, dass der Shell-Zugriff mindestens so gut gesichert ist wie das angehängte Dienstkonto.

Bei Linux-Instanzen können Sie mit OS Login erzwingen, dass der SSH-Zugriff restriktiver ist als der Zugriff auf das angehängte Dienstkonto. Um eine Verbindung zu einer VM-Instanz herzustellen, für die OS Login aktiviert ist, muss ein Nutzer nicht nur OS Login verwenden dürfen, sondern auch die iam.serviceAccounts.actAs-Berechtigung für das angehängte Dienstkonto haben.

Diese Zugriffsebene gilt nicht für VM-Instanzen, die metadatenbasierte Schlüssel oder Windows-Instanzen verwenden: SSH-Schlüssel in Metadaten veröffentlichen oder Windows-Anmeldedaten anfordern macht den Zugriff auf die Metadaten der VM-Instanz und die iam.serviceAccounts.actAs-Berechtigung für das angehängte Dienstkonto erforderlich. Nachdem der SSH-Schlüssel veröffentlicht oder die Windows-Anmeldedaten empfangen wurden, werden nachfolgende Anmeldungen jedoch nicht mehr den zusätzlichen IAM-Berechtigungsprüfungen unterzogen.

Wenn eine VM-Instanz ein benutzerdefiniertes Linux-Authentifizierungsmodul zur Authentifizierung verwendet oder Mitglied einer Active Directory-Domain ist, ist es möglich, dass Nutzer die sonst nicht berechtigt sind, die Identität des Dienstkontos zu übernehmen sich anmelden dürfen.

Erwägen Sie vor allem für VM-Instanzen, die kein OS Login verwenden, den Shell-Zugriff durch ein Identity-Aware Proxy einzuschränken. Gewähren Sie die Rolle "IAP-gesicherter Tunnel" nur Nutzern, die die Identität des mit der VM-Instanz verbundenen Dienstkontos übernehmen dürfen.

Beschränkung des Zugriffs auf Metadatenserver auf ausgewählte Nutzer und Prozesse

Wenn Sie ein Dienstkonto an eine VM-Instanz anhängen, können auf der VM bereitgestellte Arbeitslasten auf den Metadatenserver zugreifen, um Tokens für die Dienstkonten anzufordern. Standardmäßig ist der Zugriff auf den Metadatenserver nicht auf einen bestimmten Prozess oder Nutzer auf der VM beschränkt: Prozesse, die als Nutzer mit geringen Berechtigungen ausgeführt werden, z. B. nobody unter Linux oder LocalService unter Windows, haben vollständigen Zugriff auf den Metadatenserver und können Tokens für das Dienstkonto abrufen.

Um den Zugriff auf den Metadatenserver auf bestimmte Nutzer zu beschränken, konfigurieren Sie die Host-Firewall des Gastbetriebssystems so, dass nur diese Nutzer ausgehende Verbindungen zum Metadatenserver öffnen können.

Unter Linux können Sie die Optionen --uid-owner und --gid-owner verwenden, um eine iptables-Regel einzurichten, die nur für bestimmte Nutzer oder Gruppen gilt. Unter Windows können Sie mit dem Befehl Set-NetFirewallSecurityFilter eine Firewallregel anpassen, sodass sie für ausgewählte Nutzer oder Gruppen gilt.

Schutz vor Spoofing-Bedrohungen

Workload Identity Federation ermöglicht es Ihnen, einseitige Vertrauensstellungen zwischen Google Cloud-Projekten und externen Identitätsanbietern zu erstellen. Nachdem Sie diese Vertrauensstellung hergestellt haben, können Sie Anmeldedaten des externen Identitätsanbieters gegen ein STS-Token (Security Token Service) austauschen. Sie können das STS-Token dann für den Zugriff auf ein Dienstkonto oder für dessen Identitätsübernahme verwenden.

STS-Tokens unterscheiden sich von Zugriffstokens insofern, als sie nicht einer bestimmten Google-Identität entsprechen. STS-Tokens entsprechen auch nicht unbedingt einer bestimmten Identität beim externen Identitätsanbieter. Stattdessen stellt ein STS-Token eine Reihe von Attributen dar. Je nachdem, was diese Attribute sind, können sie einer oder mehreren Identitäten bei dem externen Identitätsanbieter entsprechen.

Wenn die durch ein STS-Token dargestellten Attribute mehrdeutig sind oder falsch verwendet werden, können böswillige Akteure ihre Identität manipulieren. Im folgenden Abschnitt finden Sie Best Practices zum Schutz vor solchen Spoofing-Bedrohungen.

Lassen Sie nie zu, 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 einer föderierten Haupt- oder Hauptkontogruppe die Berechtigung gegeben haben, die Identität eines Dienstkontos zu übernehmen und später die Attributzuordnung zu ändern, können 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 Cloud-Projekts für die Verwaltung von Workload-Identitätspools, um das Risiko zu begrenzen, dass Nutzern eine dieser Rollen versehentlich auf einer höheren Ebene in der Ressourcenhierarchie zugewiesen wird.

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

Wenn Sie Workload Identity Federation verwenden, vertrauen Sie einem externen Identitätsanbieter, um Nutzer zu authentifizieren und genaue Informationen zum authentifizierten Nutzer an Google Cloud zu melden.

Ein Identitätsanbieter verwendet Attribute, um Informationen zu authentifizierten Nutzern zu kommunizieren. Während manche dieser Attribute in der Regel autoritativ sein müssen, gibt es andere nicht, beispielsweise kann ein externer Identitätsanbieter sowohl einen Nutzernamen als auch eine Nutzer-ID in ein OpenID Connect-ID-Token einbetten. Beide Attribute identifizieren einen Nutzer eindeutig und scheinen untereinander austauschbar zu sein. Externer Identitätsanbieter kann Nutzern jedoch trotzdem die Möglichkeit geben, ihren Nutzernamen zu ändern. Dabei ist die stabile und autoritative Nutzer-ID garantiert.

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 Nutzername 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 zuverlässig garantiert, um solche Spoofing-Angriffe zu verhindern.

Schutz vor der Offenlegung von Informationen

Geben Sie in Dienstkonto-E-Mail-Adressen keine vertraulichen Informationen an.

Wenn Sie einem Dienstkonto Zugriff auf eine Ressource in einem anderen Cloud-Projekt gewähren möchten, können Sie der IAM-Richtlinie der Ressource eine Rollenbindung hinzufügen. Wie die Ressource selbst ist die IAM-Richtlinie Teil des anderen Cloud-Projekts. Ihre Sichtbarkeit wird auch von diesem anderen Cloud-Projekt gesteuert.

Das Aufrufen von IAM-Richtlinien wird in der Regel nicht als privilegierter Vorgang betrachtet. Viele Rollen enthalten die erforderliche Berechtigung *.getIamPolicy, einschließlich der einfachen Rolle Betrachter.

Ein Nutzer, der eine IAM-Richtlinie aufrufen darf, kann auch die E-Mail-Adressen der Hauptkonten sehen, denen Zugriff auf die Ressource gewährt wurde. Im Fall von Dienstkonten können E-Mail-Adressen Hinweise für böswillige Nutzer geben.

Eine IAM-Richtlinie kann beispielsweise eine Bindung für ein Dienstkonto mit der E-Mail-Adresse jenkins@deployment-project-123.gserviceaccount.com enthalten. Diese E-Mail-Adresse zeigt einem böswilligen Akteur nicht nur, dass es ein Cloud-Projekt mit der ID deployment-project-123 gibt, sondern auch, dass das Cloud-Projekt einen Jenkins-Server ausführt. Wenn Sie einen allgemeineren Namen wie deployer@deployment-project-123.gserviceaccount.com auswählen, vermeiden Sie Informationen zu der Art der Software, die Sie in deployment-project-123 ausführen.

Wenn Sie einem Dienstkonto Zugriff auf Ressourcen in einem Cloud-Projekt mit weniger kontrollierten Zugriffsrechten gewähren, etwa einer Sandbox oder einem Cloud-Entwicklungsprojekt, achten Sie darauf, dass die E-Mail-Adresse des Dienstkontos keine Informationen preisgibt. Besonders sollten Sie keine vertraulichen Informationen offenlegen, die Angreifern Hinweise geben könnten.

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 Cloud-Audit-Logs anzeigen, dass die Aktivität von einem Dienstkonto ausgeführt wurde, reicht diese Information allein vielleicht nicht aus, um die gesamte Ereigniskette zu reproduzieren: Sie müssen auch herausfinden können, welcher Nutzer oder welche Anwendung das Dienstkonto dazu veranlasst hat, die Aktivität auszuführen.

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

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. Dieser Abschnitt gibt an, ob und von welchem Nutzer die Identität des Dienstkontos übernommen wurde.

Nicht alle Dienste enthalten Details zur Identitätsübertragung in ihren Cloud-Audit-Logs. Um alle Identitätsübertragungsereignisse aufzuzeichnen, müssen Sie auch Datenzugriffslogs für die folgenden APIs aktivieren:

  • Identity and Access Management (IAM) API in allen Cloud-Projekten, die Dienstkonten enthalten
  • Security Token Service API in allen Cloud-Projekten, die Workload Identity-Pools enthalten

Durch das Aktivieren dieser Logs sorgen Sie dafür, dass den Cloud-Audit-Logs immer ein Eintrag hinzugefügt wird, wenn ein Nutzer ein Zugriffstoken oder ein ID-Token für ein Dienstkonto anfordert.

Sicher stellen, dass der CI-/CD-Verlauf mit Cloud-Audit-Logs korreliert

Dienstkonten werden häufig von CI/CD-Systemen verwendet, um Bereitstellungen durchzuführen, nachdem eine Codeänderung erfolgreich geprüft und für die Bereitstellung genehmigt wurde. In der Regel speichern CI/CD-Systeme einen Verlauf der Ereignisse, die zu einer Bereitstellung führen. Dieser Verlauf kann die IDs der entsprechenden Codeüberprüfungen, Commits und Pipelineausführungen sowie Informationen darüber enthalten, wer die Bereitstellung genehmigt hat.

Wenn eine Bereitstellung Ressourcen in Google Cloud ändert, werden diese Änderungen in den Cloud-Audit-Logs der entsprechenden Ressourcen erfasst. Cloud-Audit-Logs enthalten Informationen zu dem Nutzer oder Dienstkonto, das die Änderung initiiert hat. In einer Bereitstellung, die durch ein CI/CD-System ausgelöst wird, reicht das Dienstkonto selbst jedoch häufig nicht aus, um die gesamte Ereigniskette zu rekonstruieren, die zu der Änderung geführt hat.

Um für Ihr CI-/CD-System und Google Cloud einen konsistenten Audit-Trail einzurichten, müssen Sie sicherstellen, dass Cloud-Audit-Logs mit Ereignissen im Verlauf des CI/CD-Systems korreliert werden können. Wenn Sie in den Cloud-Audit-Logs ein unerwartetes Ereignis feststellen, können Sie mit dieser Korrelation feststellen, ob die Änderung tatsächlich vom CI/CD-System ausgeführt wurde, warum sie vorgenommen wurde und wer sie genehmigt hat.

Es gibt folgende Möglichkeiten, eine Beziehung zwischen Cloud-Audit-Logdatensätzen und Ereignissen im Verlauf des CI/CD-Systems herzustellen:

  • Aufzeichnen der API-Anfragen, die bei jeder CI-/CD-Pipelineausführung ausgeführt werden.
  • Jedes Mal, wenn die API eine Vorgangs-ID zurückgibt, die ID in den Logs des CI/CD-Systems vermerken.
  • Fügen Sie den API-Anfragen den HTTP-Header X-Goog-Request-Reason hinzu und übergeben Sie die ID der Ausführung der CI/CD-Pipeline. Alternativ können Sie die Informationen in den Header User-Agent einbetten, damit sie in Cloud-Audit-Logs erfasst werden.

Konfigurieren Sie die Protokolldateien und den Commit-Verlauf, um die Verfolgbarkeit sicherzustellen. Sie können diese Daten unveränderlich machen, damit bösartige Akteure ihre Spuren nicht rückwirkend verbergen können.

Nächste Schritte