Best Practices für die Verwendung von Dienstkonten

Dienstkonten stehen für nicht-menschliche Nutzer. Sie sind für Szenarien gedacht, in denen eine Arbeitslast, z. B. eine benutzerdefinierte Anwendung, auf Ressourcen zugreifen oder Aktionen ohne Beteiligung der Endnutzer ausführen muss.

Dienstkonten unterscheiden sich auf mehrere Arten von normalen Nutzerkonten:

• Sie haben kein Passwort und können nicht für browserbasierte Anmeldungen verwendet werden.
• Sie werden als Ressourcen erstellt und verwaltet, die zu einem Google Cloud-Projekt gehören. Im Gegensatz dazu werden Nutzer in Cloud Identity- oder Google Workspace-Konten verwaltet.
• Sie sind für Google Cloud spezifisch. Im Gegensatz dazu arbeiten Nutzer, die in Cloud Identity oder Google Workspace verwaltet werden, mit einer Vielzahl an Google-Produkten und -Diensten.
• Sie sind sowohl eine Ressource als auch ein Hauptkonto:
  • 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 Nutzern und Gruppen, imitiert werden.

Obwohl Dienstkonten ein nützliches Tool sind, gibt es mehrere Möglichkeiten, wie ein Dienstkonto missbraucht werden kann:

• 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.

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.

In diesem Leitfaden werden Best Practices für die Verwaltung, Verwendung und Sicherung von Dienstkonten vorgestellt.

Verwendungsbedingungen für Dienstkonten

Nicht jedes Szenario erfordert ein Dienstkonto für den Zugriff auf Google Cloud-Dienste und viele Szenarien können mit einer sichereren Methode authentifiziert werden als durch die Verwendung eines Dienstkontoschlüssels. Wir empfehlen, nach Möglichkeit keine Dienstkontoschlüssel zu verwenden.

Wenn Sie auf Google Cloud-Dienste über die Google Cloud CLI, Cloud-Clientbibliotheken und Tools zugreifen, die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) wie Terraform oder REST unterstützen, verwenden Sie das folgende Diagramm, um eine Authentifizierungsmethode auszuwählen:

Dieses Diagramm führt Sie durch die folgenden Fragen:

1. Führen Sie Code in einer Entwicklungsumgebung für einzelne Nutzer aus, z. B. Ihrer eigenen Workstation, Cloud Shell oder einer virtuellen Desktop-Oberfläche?
   1. Falls ja, fahren Sie mit Frage 4 fort.
   2. Falls nein, fahren Sie mit Frage 2 fort.
2. Führen Sie Code in Google Cloud aus?
   1. Falls ja, fahren Sie mit Frage 3 fort.
   2. Falls nein, fahren Sie mit Frage 5 fort.
3. Führen Sie Container in Google Kubernetes Engine oder GKE Enterprise aus?
   1. Wenn ja, verwenden Sie die Identitätsföderation von Arbeitslasten für GKE, um Dienstkonten an Kubernetes-Pods anzuhängen.
   2. Falls nicht, fügen Sie der Ressource ein Dienstkonto hinzu.

4. Erfordert Ihr Anwendungsfall ein Dienstkonto?

   Sie können beispielsweise die Authentifizierung und Autorisierung für Ihre Anwendung in allen Umgebungen konsistent konfigurieren.

   1. Falls nein, authentifizieren Sie sich mit Nutzeranmeldedaten.
   2. Falls ja, übernehmen Sie die Identität eines Dienstkontos mit Nutzeranmeldedaten.
5. Wird Ihre Arbeitslast bei einem externen Identitätsanbieter authentifiziert, der die Identitätsföderation von Arbeitslasten unterstützt?
   1. Falls ja, konfigurieren Sie die Identitätsföderation von Arbeitslasten, damit Anwendungen, die lokal oder auf anderen Cloud-Anbietern ausgeführt werden, ein Dienstkonto verwenden können.
   2. Falls nicht, erstellen Sie einen Dienstkontoschlüssel.

Dienstkonten verwalten

Dienstkonten unterscheiden sich von normalen Nutzerkonten nicht nur darin, wie sie verwendet werden, sondern auch darin, wie sie zu verwalten sind. In folgenden Abschnitten finden Sie Best Practices für die Verwaltung von Dienstkonten.

Best Practices:

Dienstkonten als Ressourcen verwalten.
Dienstkonten für einzelne Zwecke erstellen.
Namens- und Dokumentationskonventionen befolgen.
Nicht verwendete Dienstkonten identifizieren und deaktivieren.
Deaktivieren Sie nicht verwendete Dienstkonten, bevor sie gelöscht werden
.

Dienstkonten als Ressourcen verwalten

Standardnutzerkonten werden normalerweise gemäß den joiner-mover-leaver-Prozessen einer Organisation verwaltet: Wenn ein Mitarbeiter beitritt, wird für ihn ein neues Nutzerkonto erstellt. Wechselt er die Abteilungen, wird sein Nutzerkonto aktualisiert. Wenn er das Unternehmen verlässt, wird das Konto des Nutzers gesperrt oder gelöscht.

Dienstkonten sind dagegen keinem bestimmten Mitarbeiter zugeordnet. Stattdessen sollten Sie Dienstkonten als Ressourcen betrachten, die zu einer anderen Ressource gehören oder Teil dieser Ressource sind, z. B. einer bestimmten VM-Instanz oder Anwendung.

Um Dienstkonten effektiv zu verwalten, sollten Sie sie nicht isoliert betrachten. Betrachten Sie sie stattdessen im Kontext der Ressource, mit der sie verknüpft sind. Verwalten Sie das Dienstkonto und die zugehörige Ressource als eine Einheit: Wenden Sie dieselben Prozesse, denselben Lebenszyklus und dieselbe Sorgfalt auf das Dienstkonto und dessen zugehörige Ressource an und verwalten Sie sie mit denselben Tools.

Dienstkonten für einen einzigen Zweck erstellen

Die gemeinsame Nutzung eines Dienstkontos über mehrere Anwendungen hinweg kann die Verwaltung des Dienstkontos erschweren:

• Die Anwendungen haben möglicherweise unterschiedliche Lebenszyklen. Wenn eine Anwendung außer Betrieb genommen wird, ist möglicherweise nicht klar, ob das Dienstkonto ebenfalls außer Betrieb genommen werden kann oder nicht.
• Im Laufe der Zeit können sich die Zugriffsanforderungen von Anwendungen ändern. Wenn Anwendungen dasselbe Dienstkonto verwenden, müssen Sie dem Dienstkonto möglicherweise immer mehr Ressourcen zur Verfügung stellen, was wiederum das Gesamtrisiko erhöht.
• Cloud-Audit-Logs enthalten den Namen des Dienstkontos, das eine Änderung durchgeführt oder auf Daten zugegriffen hat, aber sie zeigen nicht den Namen der Anwendung, die das Dienstkonto verwendet hat. Wenn sich mehrere Anwendungen ein Dienstkonto teilen, können Sie die Aktivität möglicherweise nicht zur richtigen Anwendung zurückverfolgen.

Insbesondere erstellen einige Google Cloud-Dienste, einschließlich App Engine und Compute Engine, standardmäßig ein Standarddienstkonto mit der Rolle "Bearbeiter" (roles/editor) für das Projekt. Wenn Sie eine Ressource wie eine Compute Engine-VM-Instanz erstellen und kein Dienstkonto angeben, kann die Ressource automatisch das Standarddienstkonto verwenden. Obwohl das Standarddienstkonto Ihnen den Einstieg erleichtert, ist es sehr riskant, ein solches Dienstkonto für mehrere Anwendungen freizugeben.

Sie können mehrere Maßnahmen ergreifen, um diese Komplikationen zu vermeiden:

• Erstellen Sie für jede Anwendung dedizierte Dienstkonten und vermeiden Sie die Verwendung von Standarddienstkonten.
• Verwenden Sie nie automatische Rollenzuweisungen für Standarddienstkonten
• Verwenden Sie die Tools von Google, um die Nutzung von Dienstkonten zu verstehen. Damit können Sie die Nutzung überwachen und verhindern, dass Dienstkonten von mehreren Anwendungen gemeinsam genutzt werden.

Namens- und Dokumentationskonvention nutzen

Halten Sie sich beim Erstellen neuer Dienstkonten an eine Namenskonvention, um die Verknüpfung zwischen einem Dienst und einer Anwendung oder Ressource verfolgen zu können:

• Fügen Sie der E-Mail-Adresse des Dienstkontos ein Präfix hinzu, das die Verwendung des Kontos angibt. Beispiel:
  • vm- für Dienstkonten, die einer VM-Instanz angehängt sind.
  • wi- für Dienstkonten, die von der Workload Identity verwendet werden.
  • wif- für Dienstkonten, die von der Workload Identity Federation verwendet werden.
  • onprem- für Dienstkonten, die von lokalen Anwendungen verwendet werden.
• Betten Sie den Namen der Anwendung in die E-Mail-Adresse des Dienstkontos ein, z. B. vm-travelexpenses@, wenn die VM eine Anwendung für Reisekosten ausführt.
• Verwenden Sie das Beschreibungsfeld, um eine Kontaktperson, Links zu relevanten Dokumentationen oder andere Hinweise hinzuzufügen.

Nehmen Sie nie vertrauliche Informationen oder Begriffe in die E-Mail-Adresse eines Dienstkontos auf.

Nicht verwendete Dienstkonten identifizieren und deaktivieren

Wenn ein Dienstkonto nicht mehr verwendet wird, deaktivieren Sie das Dienstkonto. Durch das Deaktivieren nicht verwendeter Dienstkonten verringern Sie das Risiko, dass Dienstkonten für eine spätere Bewegung oder die Rechteausweitung durch einen böswilligen Akteur missbraucht werden.

Wenn es sich um zweckgebundene Dienstkonten handelt, die einer bestimmten Ressource zugeordnet sind, z. B. einer VM-Instanz, deaktivieren Sie das Dienstkonto, sobald die verknüpfte Ressource deaktiviert oder gelöscht wird.

Bei Dienstkonten, die für mehrere Zwecke oder für mehrere Ressourcen verwendet werden, kann es schwieriger sein, festzustellen, ob das Dienstkonto noch verwendet wird. In diesen Fällen können Sie die Aktivitätsanalyse verwenden, um die neuesten Authentifizierungsaktivitäten für Ihre Dienstkonten aufzurufen.

Deaktivieren Sie nicht verwendete Dienstkonten, bevor sie gelöscht werden

Wenn Sie ein Dienstkonto löschen und dann ein neues Dienstkonto mit dem gleichen Namen erstellen, wird dem neuen Dienstkonto eine andere Identität zugewiesen. Daher gilt für das neue Dienstkonto keine der ursprünglichen IAM-Bindungen. Wenn Sie dagegen ein Dienstkonto deaktivieren und wieder aktivieren, bleiben alle IAM-Bindungen unverändert.

Um zu vermeiden, dass IAM-Bindungen versehentlich verloren gehen, sollten Sie Dienstkonten nicht sofort löschen. Deaktivieren Sie stattdessen ein Dienstkonto, wenn es nicht mehr benötigt wird, und löschen es erst, nachdem ein bestimmter Zeitraum abgelaufen ist.

Löschen Sie niemals Standarddienstkonten wie das App Engine- oder Compute Engine-Standarddienstkonto. Diese Dienstkonten können nicht neu erstellt werden. Dazu muss die jeweilige API deaktiviert und dann wieder aktiviert werden. Dadurch kann Ihre vorhandene Bereitstellung beeinträchtigt werden. Wenn Sie die Standarddienstkonten nicht verwenden, deaktivieren Sie sie stattdessen.

Dienstkontoberechtigungen einschränken

Dienstkonten sind Hauptkonten und können wie reguläre Nutzerkonten Zugriff auf eine Ressource erhalten. Dienstkonten haben jedoch oft umfassenderen Zugriff auf mehr Ressourcen als ein typischer Nutzer. Wenn Sie Ihren Anwendungen Funktionen hinzufügen, erhalten diese Dienstkonten im Laufe der Zeit auch immer mehr Zugriff. Sie könnten auch vergessen, den nicht mehr benötigten Zugriff zu widerrufen.

Best Practices:

Verwenden Sie nie automatische Rollenzuweisungen für Standarddienstkonten
Verlassen Sie sich beim Anhängen von Dienstkonten an VM-Instanzen nie auf Zugriffsbereiche.
Verwenden Sie Gruppen nie, um Dienstkonten Zugriff auf Ressourcen zu gewähren.
Verwenden Sie nie die domainweite Delegierung.
Mit Dienstkonten nie ohne Zustimmung des Nutzers auf dessen Nutzerdaten zuzugreifen.
IAM Credentials API für temporäre Rechteausweitung verwenden
Nutzen Sie Zugriffsbeschränkungen für Anmeldedaten, um Zugriffstokens einzuschränken
Nicht genutzte Berechtigungen anhand von Rollenempfehlungen ermitteln.
Verwenden Sie Statistiken zum "Lateral Movement", um das "Lateral Movement" zu begrenzen.

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 Google Cloud-Projekt zugewiesen, mit der sie alle Ressourcen im Google 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 Google 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 Google 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.

Wenn Sie diese Einschränkung anwenden, haben Standarddienstkonten in neuen Projekten keinen Zugriff auf Ihre Google Cloud-Ressourcen. Sie müssen den Standarddienstkonten die entsprechenden Rollen zuweisen, damit sie auf Ihre Ressourcen zugreifen können.

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 Zulassungsrichtlinien 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 "allow"-Richtlinien zu ersetzen.

Statt sich auf Zugriffsbereiche zu verlassen, sollten Sie ein dediziertes Dienstkonto erstellen und detaillierte "allow"-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.

Mit Dienstkonten nie ohne Zustimmung des Nutzers auf dessen Nutzerdaten zuzugreifen

Eine Anwendung benötigt möglicherweise Zugriff auf sensible oder personenbezogene Nutzerdaten. Beispiele für solche Daten sind das Postfach oder der Kalender eines Nutzers, in Google Drive gespeicherte Dokumente oder ein BigQuery-Dataset, das vertrauliche Daten enthält.

Die Verwendung eines Dienstkontos für den Zugriff auf Nutzerdaten kann sinnvoll sein, wenn die Anwendung unbeaufsichtigte Hintergrundaufgaben wie Indexierungen oder Scans zum Schutz vor Datenverlust (Data Loss Prevention, DLP) ausführt, oder wenn der Endnutzer sich nicht mit einer Google-Identität authentifiziert hat. In allen anderen Szenarien, in denen eine Anwendung im Namen eines Endnutzers handelt, sollten Sie keine Dienstkonten verwenden.

Anstatt ein Dienstkonto für den Zugriff auf Nutzerdaten zu verwenden (und möglicherweise eine Umstellung der Hauptkonten herbeizuführen), verwenden Sie den OAuth-Zustimmungsablauf, um die Zustimmung des Endnutzers anzufordern. Lassen Sie die Anwendung dann unter der Identität des Endnutzers handeln. Durch die Verwendung von OAuth anstelle eines Dienstkontos stellen Sie Folgendes sicher:

• Nutzer können prüfen, über welche Ressourcen sie der Anwendung Zugriff gewähren. Außerdem können sie ihre Einwilligung explizit ausdrücken oder ablehnen.
• Nutzer können ihre Einwilligung auf der Seite Mein Konto jederzeit widerrufen.
• Sie benötigen dann kein Dienstkonto, das uneingeschränkten Zugriff auf alle Nutzerdaten hat.

Wenn Sie zulassen, dass eine Anwendung Anmeldedaten von Endnutzern verwendet, übergeben Sie die Berechtigungsprüfungen an Google Cloud APIs. Dadurch wird das Risiko verringert, dass Daten, auf die ein Nutzer keinen Zugriff haben soll, aufgrund eines Codierungsfehlers (Problem des falschen Deputy) versehentlich angezeigt werden.

IAM Credentials API für temporäre Rechteausweitung verwenden

Einige Anwendungen erfordern nur zu bestimmten Zeiten oder unter bestimmten Umständen Zugriff auf bestimmte Ressourcen. Beispiel:

• Eine Anwendung benötigt während des Starts möglicherweise Zugriff auf Konfigurationsdaten, den sie nach der Initialisierung nicht mehr benötigt.
• Eine Supervisor-Anwendung kann in regelmäßigen Abständen Hintergrundjobs starten, bei denen jeder Job unterschiedliche Zugriffsanforderungen hat.

In solchen Szenarien widerspricht die Verwendung eines einzelnen Dienstkontos, dem Zugriff auf alle Ressourcen gewährt wird, dem Prinzip der geringsten Berechtigung. Die Anwendung hat jederzeit Zugriff auf mehr Ressourcen, als sie tatsächlich benötigt.

Damit die verschiedenen Teile Ihrer Anwendung nur auf die erforderlichen Ressourcen zugreifen können, verwenden Sie die IAM Credentials API für die temporäre Rechteausweitung:

• Erstellen Sie für jeden Teil der Anwendung oder für jeden Anwendungsfall separate Dienstkonten und gewähren Sie jedem Dienstkonto nur Zugriff auf die erforderlichen Ressourcen.
• Erstellen Sie ein weiteres Dienstkonto, das als Supervisor fungiert. Weisen Sie dem Supervisor-Dienstkonto für die anderen Dienstkonten die Rolle Dienstkonto-Tokenersteller zu, damit es kurzlebige Zugriffstokens für diese Dienstkonten anfordern kann.
• Teilen Sie Ihre Anwendung so auf, dass ein Teil der Anwendung als Token-Broker dient und gewähren Sie nur diesem Teil der Anwendung die Verwendung der Supervisor-Dienstkonten.
• Verwenden Sie den Token-Broker, um kurzlebige Dienstkonten für die anderen Teile der Anwendung bereitzustellen.

Informationen zum Erstellen kurzlebiger Anmeldedaten finden Sie unter Kurzlebige Anmeldedaten für ein Dienstkonto erstellen.

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.

Hinweis: Das "Downscoping" wird nur von Cloud Storage unterstützt.

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 "allow"-Richtlinien der betroffenen Ressourcen an, damit einer Anwendung nur so viel Zugriff gewährt wird, wie sie tatsächlich benötigt.

Mit Statistiken zum "Lateral Movement" das "Lateral Movement" begrenzen

Ein "Lateral Movement" besteht, wenn ein Dienstkonto in einem Projekt die Berechtigung hat, die Identität eines Dienstkontos in einem anderen Projekt zu übernehmen. Beispielsweise kann es sein, dass ein Dienstkonto in Projekt A erstellt wurde, aber berechtigt ist, die Identität eines Dienstkontos in Projekt B zu übernehmen.

Diese Berechtigungen können zu einer Kette von Identitätsübertragungen über Projekte hinweg führen, die Hauptkonten unbeabsichtigten Zugriff auf Ressourcen gewähren. Ein Hauptkonto könnte beispielsweise die Identität eines Dienstkontos in Projekt A übernehmen und dann die Identität dieses Dienstkontos dazu verwenden ein Dienstkonto in Projekt B zu übernehmen. Wenn das Dienstkonto in Projekt B die Berechtigung hat, die Identität anderer Dienstkonten in anderen Projekten Ihrer Organisation zu übernehmen, kann das Hauptkonto weiterhin die Identität des Dienstkontos verwenden, um von Projekt zu Projekt zu wechseln. Dabei werden die Berechtigungen übernommen.

Hinweis: Das Anhängen eines Dienstkontos aus einem Projekt an eine Ressource in einem anderen Projekt stellt kein "Lateral Movement" dar, da es dem Dienstkonto keine Berechtigungen zum Identitätswechsel gewährt.

Recommender bietet Statistiken zum "Lateral Movement", mit denen Sie dieses Problem beheben können. Statistiken zum "Lateral Movement" zeigen Rollen, mit denen ein Dienstkonto in einem Projekt die Identität eines Dienstkontos in einem anderen Projekt übernehmen kann. Informationen zum Aufrufen und Verwalten von Statistiken zum "Lateral Movement" finden Sie unter Statistiken zum "Lateral Movement" verwalten.

Einige Statistiken zum "Lateral Movement" sind mit Rollenempfehlungen verknüpft. Sie können diese Empfehlungen anwenden, um das "Lateral Movement" zwischen Projekten zu reduzieren. Weitere Informationen finden Sie unter Empfehlungen prüfen und anwenden.

Schutz vor Bedrohungen durch Rechteausweitung

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:

• Als Dienstkonto authentifizieren: Sie können einem Nutzer versehentlich die Berechtigung erteilen, die Identität eines Dienstkontos zu übernehmen oder für ein Dienstkonto einen Dienstkonto-Schlüssel zu erstellen. Wenn das Dienstkonto mehr Berechtigungen hat als der Nutzer selbst, kann sich der Nutzer als Dienstkonto authentifizieren, um seine Berechtigungen zu eskalieren und Zugriff auf Ressourcen zu erhalten, auf die er sonst nicht zugreifen kann.

• Ressourcen mit einem angehängten Dienstkonto verwenden: Wenn ein Nutzer die Berechtigung hat, CI/CD-Pipelines, VM-Instanzen oder andere Automatisierungssysteme mit angehängten Dienstkonten aufzurufen und zu ändern, dann können sie möglicherweise Aktionen mit den angehängten Dienstkonten dieser Ressourcen ausführen. Daher sind sie möglicherweise nicht berechtigt, die Identität des Dienstkontos zu übernehmen. Allerdings können sie mit den Berechtigungen des Dienstkontos weiterhin Aktionen ausführen, die sie selbst nicht ausführen dürften.

  Wenn ein Nutzer beispielsweise SSH-Zugriff auf eine Compute Engine-VM-Instanz hat, kann er Code auf der Instanz ausführen, um auf jede Ressource zuzugreifen, auf die das angehängte Dienstkonto der Instanz zugreifen kann.

• "allow"-Richtlinien, Gruppen oder benutzerdefinierte Rollenänderungen: Ein Nutzer, der keinen Zugriff auf ein privilegiertes Dienstkonto hat, hat möglicherweise dennoch die Berechtigung, die "allow"-Richtlinien des Dienstkontos zu ändern, einschließlich Google Cloud-Projekte oder Ordner. Der Nutzer könnte dann eine dieser „allow“-Richtlinien erweitern, um sich selbst (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.

Best Practices:

Vermeiden Sie die Übernahme der Identität von Dienstkonten, die mehr Privilegien haben als die übernehmenden Nutzer selbst.
Nutzer sollten niemals die "allow"-Richtlinien von Dienstkonten ändern dürfen, die mehr Berechtigungen als der Nutzer haben..
Lassen Sie Nutzer nie Dienstkontoschlüssel erstellen oder hochladen.
Gewähren Sie nie Zugriff auf Dienstkonten auf Google Cloud-Projekt- oder Ordnerebene.
Führen Sie keinen Code aus weniger geschützten Quellen für Compute-Ressourcen aus, an die ein privilegiertes Dienstkonto angehängt ist.
Beschränken Sie den Shell-Zugriff auf VMs, an die ein privilegiertes Dienstkonto angehängt sind.
Beschränken Sie den Metadaten-Server-Zugriff auf ausgewählte Nutzer und Prozesse.

Vermeiden Sie es, Nutzern die Authentifizierung als 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 praktisch privilegierter als der Nutzer.

Wenn Sie einem Nutzer die Berechtigung erteilen, ein privilegiertes Dienstkonto zu übernehmen, kann dies dazu führen, dass ein Nutzer seine Berechtigungen bewusst vorübergehend erweitert – ähnlich wie bei der Verwendung des sudo-Tools unter Linux oder der Prozesserweiterung 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.

Nutzer können indirekt auch die Berechtigungen eines Dienstkontos erhalten, indem sie sie an eine Ressource anhängen und dann den Code auf dieser Ressource ausführen. Beim Ausführen von Code auf diese Weise handelt es sich nicht um die Übernahme der Identität eines Dienstkontos, da es nur um eine authentifizierte Identität geht (die des Dienstkontos). Allerdings kann einem Nutzer Zugriff gewährt werden, den er sonst nicht hätte.

Zu den Berechtigungen, die es Nutzern ermöglichen, die Identität eines Dienstkontos zu übernehmen oder ein Dienstkonto an eine Ressource anzuhängen, gehören:

• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.actAs
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• iam.serviceAccountKeys.create
• 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.

Nutzern nicht das Ändern der "allow"-Richtlinien von Dienstkonten erlauben, die mehr Berechtigungen als der Nutzer haben

Welche Nutzer ein Dienstkonto verwenden oder dessen Identität übernehmen dürfen, wird durch die "allow"-Richtlinie des Dienstkontos bestimmt. Die "allow"-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. Nutzern sollten niemals die "allow"-Richtlinie eines Dienstkontos ändern dürfen, das 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 dem Effekt der Identitätsübernahme eines Dienstkontos. Wenn ein Nutzer Zugriff auf einen Dienstkontoschlüssel oder die Berechtigung zum Erstellen eines neuen Dienstkontoschlüssels hat, kann er sich als Dienstkonto authentifizieren 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 Google 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 sich der Prozess als Dienstkonto authentifizieren 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 an eine VM-Instanz ein privilegiertes Dienstkonto angehängt ist, kann sich jeder Nutzer mit Shell-Zugriff auf das System als das Dienstkonto authentifizieren und 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 für die Authentifizierung verwendet oder Mitglied einer Active Directory-Domain ist, können sich möglicherweise auch Nutzer anmelden, die sonst nicht berechtigt wären, sich als Dienstkonto zu authentifizieren. Weitere Informationen finden Sie unter Best Practices zum Ausführen von Active Directory in Google Cloud.

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 Nutzerrolle „IAP-gesicherter Tunnel“ (roles/iap.tunnelResourceAccessor) 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.

Vor Bedrohungen in puncto Offenlegung von Informationen schützen

Best Practices:

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

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 "allow"-Richtlinie der Ressource eine Rollenbindung hinzufügen. Wie die Ressource selbst ist die "allow"-Richtlinie Teil des anderen Cloud-Projekts. Ihre Sichtbarkeit wird auch von diesem anderen Cloud-Projekt gesteuert.

Das Aufrufen von "allow"-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 "allow"-Richtlinie aufrufen kann, 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 "allow"-Richtlinie kann beispielsweise eine Bindung für ein Dienstkonto mit der E-Mail-Adresse [e-mail] 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 [e-mail] auswählen, vermeiden Sie Informationen zu der Art 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.

Best Practices:

Verwenden Sie Dienstkontoschlüssel nur, wenn es keine praktikable Alternative gibt.
Aktivieren Sie Datenzugriffslogs für IAM APIs.
Stellen Sie sicher, dass der CI-/CD-Verlauf mit Cloud-Audit-Logs korreliert.
Erstellen Sie benutzerdefinierte Logeinträge für einzelne Nutzer einer Anwendung.

Verwenden Sie Dienstkontoschlüssel nur, wenn es keine praktikable Alternative gibt

Wenn Sie keine sichereren Authentifizierungsmethoden verwenden können, müssen Sie möglicherweise einen Dienstkontoschlüssel für die Anwendung erstellen. Die Authentifizierung mit einem Dienstkontoschlüssel führt jedoch zu einer Nichterkennungs-Bedrohung. Cloud-Audit-Logs erstellen ein Log, wenn ein Dienstkonto eine Ressource ändert. Wenn das Dienstkonto jedoch mit einem Dienstkontoschlüssel authentifiziert wird, gibt es keine zuverlässige Möglichkeit, herauszufinden, wer den Schlüssel verwendet hat. Bei der Authentifizierung als Dienstkonto durch Übernahme der Identität des Dienstkontos mit Nutzeranmeldedaten wird dagegen das Hauptkonto protokolliert, das als Dienstkonto fungiert hat.

Wir empfehlen, die Erstellung von Dienstkontoschlüsseln zu verhindern. Wenden Sie dazu die Organisationsrichtlinien-Einschränkung Erstellen von Dienstkontoschlüsseln deaktivieren auf das Google Cloud-Projekt oder den umschließenden Ordner an. Wenn Sie Dienstkontoschlüssel für ein Szenario verwenden müssen, das mit keiner der empfohlenen Alternativen gelöst werden kann, gewähren Sie eine Ausnahme von der Richtlinieneinschränkung, die so enggefasst wie möglich ist, und lesen Sie die Best Practices für die Verwaltung von Dienstkontoschlüsseln.

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 Google 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. Terraform kann diesen Header automatisch hinzufügen, wenn Sie einen Anfragegrund angeben.

  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.

Benutzerdefinierte Logeinträge für einzelne Nutzer einer Anwendung erstellen

Dienstkonten sind auch nützlich für Anwendungen, bei denen sich ein Nutzer mit einem benutzerdefinierten Authentifizierungsschema authentifiziert und dann indirekt auf Google Cloud-Ressourcen zugreift. Diese Anwendungen können bestätigen, dass der Nutzer authentifiziert und autorisiert ist, und dann ein Dienstkonto verwenden, um sich bei Google Cloud-Diensten zu authentifizieren und auf Ressourcen zuzugreifen. Cloud-Audit-Logs protokollieren jedoch, dass das Dienstkonto auf eine Ressource zugegriffen hat, und nicht, welcher Nutzer die Anwendung verwendet hat.

Um diesen Zugriff zum Nutzer zurückzuverfolgen, entwickeln Sie eine Anwendungslogik, die jedes Mal einen benutzerdefinierten Logeintrag schreibt, wenn ein Nutzer auf eine Ressource zugreift, und korrelieren Sie die benutzerdefinierten Logeinträge mit Cloud-Audit-Logs.

Nächste Schritte

• Best Practices für die Verwaltung von Dienstkontoschlüsseln
• Best Practices für die Verwendung von Dienstkonten in Bereitstellungspipelines
• Best Practices für die Verwendung der Workload Identity-Föderation