Best Practices für die Arbeit mit Dienstkonten

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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

Dienstkonten bieten eine Identität für unbeaufsichtigte Anwendungen wie Batchjobs, Worker-Prozesse, die Nachrichten in einer Warteschlange weiterleiten, oder Ressourcen-Monitoring-Agents. Durch Verwendung eines Dienstkontos können diese Anwendungen ohne Nutzerinteraktion ausgeführt werden. Wenn die Anwendung auf eine Ressource zugreift, können Sie mithilfe von Cloud-Audit-Logs diesen Zugriff zu dem Dienstkonto zurückverfolgen, das von der Anwendung verwendet wird.

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. Um diesen Zugriff zum Nutzer zurückzuverfolgen, kann die Anwendung jedes Mal einen benutzerdefinierten Logeintrag schreiben, wenn ein Nutzer auf eine Ressource zugreift. Sie können die benutzerdefinierten Logeinträge mit Cloud-Audit-Logs korrelieren.

Im Gegensatz zu Nutzern können Dienstkonten sich nicht durch Anmeldung mit einem Passwort oder mit Einmalanmeldung (SSO) authentifizieren. Stattdessen unterstützen Dienstkonten eine Reihe anderer Authentifizierungsmethoden. In den folgenden Abschnitten wird beschrieben, wie Sie zwischen den Optionen wählen. Sie können auch das folgende Diagramm verwenden, um eine Authentifizierungsmethode auszuwählen:

Dienstkonten verwenden

Der folgende Abschnitt enthält Best Practices zum Auswählen, wann und wie Dienstkonten verwendet werden sollten.

Best Practices:

Nach Möglichkeit angehängte Dienstkonten verwenden.
Mit Workload Identity Dienstkonten an Kubernetes-Pods anhängen.
Mit Workload Identity Federation können Anwendungen, die lokal oder auf anderen Cloud-Anbietern ausgeführt werden, Dienstkonten verwenden.
Mit der IAM Credentials API Anmeldedaten verwalten.
Dienstkontoschlüssel verwenden, wenn es keine praktikable Alternative gibt.
Mit Dienstkonten nie ohne Zustimmung des Nutzers auf dessen Nutzerdaten zuzugreifen.
Dienstkonten nie während der Entwicklung verwenden.

Nach Möglichkeit angehängte Dienstkonten verwenden

Damit eine in Google Cloud bereitgestellte Anwendung ein Dienstkonto verwenden kann, hängen Sie das Dienstkonto an die zugrunde liegende Compute-Ressource an. Durch Anhängen des Dienstkontos ermöglichen Sie der Anwendung, Tokens für das Dienstkonto abzurufen und die Tokens für den Zugriff auf Google Cloud APIs und Google-Ressourcen zu verwenden.

Verwenden Sie zum Abrufen von Zugriffstokens nach Möglichkeit Clientbibliotheken. Die Clientbibliotheken verwenden Standardanmeldedaten für Anwendungen, um die angehängten Anmeldedaten automatisch zu finden und Zugriffstokens für Ihre Anwendung abzurufen.

Wenn die Verwendung der Clientbibliotheken nicht praktikabel ist, passen Sie Ihre Anwendung so an, dass Tokens vom Metadatenserver programmatisch abgerufen werden. Zu den Rechenressourcen, die den Zugriff auf den Metadatenserver unterstützen, gehören:

Eine vollständige Liste der Compute-Ressourcen, mit denen Sie ein Dienstkonto anhängen können, finden Sie unter Identitätswechsel für Dienstkonten verwalten.

Workload Identity verwenden, um Dienstkonten an Kubernetes-Pods anzuhängen

Wenn Sie Google Kubernetes Engine verwenden, führen Sie möglicherweise eine Kombination verschiedener Anwendungen in einem einzelnen GKE-Cluster aus. Die einzelnen Anwendungen unterscheiden sich wahrscheinlich in den erforderlichen Ressourcen und APIs.

Wenn Sie ein Dienstkonto an einen GKE-Cluster oder einen seiner Knotenpools anhängen, können standardmäßig alle Pods, die im Cluster oder Knotenpool ausgeführt werden, die Identität des Dienstkontos übernehmen. Wenn Sie ein einzelnes Dienstkonto für verschiedene Anwendungen freigeben, ist es schwierig, dem Dienstkonto die richtigen Berechtigungen zuzuweisen:

  • Wenn Sie nur den Zugriff auf Ressourcen gewähren, die alle Anwendungen erfordern, funktionieren einige Anwendungen möglicherweise nicht, da sie nicht auf bestimmte Ressourcen zugreifen können.
  • Wenn Sie Zugriff auf alle Ressourcen gewähren, die für eine bestimmte Anwendung erforderlich sind, gewähren Sie unter Umständen zu viel Zugriff.

Eine bessere Möglichkeit der Zugriffsverwaltung von Ressourcen in einer GKE-Umgebung bietet Workload Identity:

  1. Sie hängen keine Dienstkonten an GKE-Cluster oder -Knotenpools an.
  2. Sie erstellen für jeden Kubernetes-Pod, der Zugriff auf Google APIs oder Ressourcen benötigt, ein dediziertes Dienstkonto.
  3. Sie erstellen ein Kubernetes-Dienstkonto für jeden Kubernetes-Pod, der Zugriff auf Google APIs oder Ressourcen benötigt, und hängen es an den Pod an.
  4. Sie erstellen mit Workload Identity eine Zuordnung zwischen den Dienstkonten und den entsprechenden Kubernetes-Dienstkonten.

Mit Workload Identity Federation können Anwendungen, die lokal oder auf anderen Cloud-Anbietern ausgeführt werden, Dienstkonten verwenden

Wenn Ihre Anwendung lokal oder auf einem anderen Cloud-Anbieter ausgeführt wird, können Sie Dienstkonten nicht an die zugrunde liegenden Compute-Ressourcen anhängen. Die Anwendung kann jedoch Zugriff auf umgebungsspezifische Anmeldedaten wie die folgenden haben:

  • Temporäre Anmeldedaten von AWS
  • Zugriffstokens für Azure Active Directory
  • OpenID-Zugriffstoken oder -ID-Tokens, die von einem lokalen Identitätsanbieter wie Active Directory Federation Services (AD FS) oder KeyCloak ausgegeben wurden

Wenn Ihre Anwendung Zugriff auf eine dieser Anmeldedaten hat und Zugriff auf Google Cloud APIs oder Ressourcen benötigen, verwenden Sie Workload Identity Federation.

Workload Identity Federation ermöglicht es Ihnen, einseitige Vertrauensstellungen zwischen Google Cloud-Projekten und externen Identitätsanbietern zu erstellen. Sobald das Vertrauen eingerichtet ist, können Anwendungen von diesem vertrauenswürdigen Identitätsanbieter ausgegebene Anwendungsdaten verwenden, um die Identität eines Dienstkontos zu übernehmen. Dazu müssen Sie drei verschiedene Schritte ausführen:

  1. Anmeldedaten vom vertrauenswürdigen Identitätsanbieter anfordern, z. B. ein OpenID Connect-ID-Token.
  2. Den Security Token Service (STS) API nutzen, um die Anmeldedaten gegen ein kurzlebiges Google STS-Token auszutauschen.
  3. Das STS-Token verwenden, um sich bei der IAM Service Account Credentials API zu authentifizieren und kurzlebige Google-Zugriffstokens für ein Dienstkonto abzurufen.

Wenn Sie für den Zugriff auf Google Cloud-Dienste eine unterstützte Clientbibliothek oder ein Befehlszeilentool verwenden, läuft der Prozess automatisch ab.

Dank der Workload Identity Federation können Sie Anwendungen erlauben, die Authentifizierungsmechanismen der externen Umgebung zu verwenden. So müssen Sie Dienstkontoschlüssel nicht speichern und verwalten.

Mit der IAM Credentials API Anmeldedaten verwalten

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, sollten Sie die IAM Credentials API verwenden, um kurzlebige Anmeldedaten zu vergeben:

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

Dienstkontoschlüssel verwenden, wenn es keine praktikable Alternative gibt

Es kann vorkommen, dass das Hinzufügen eines Dienstkontos nicht möglich ist und weder Workload Identity noch die Workload Identity Federation sinnvolle Optionen sind. Sie können beispielsweise eine Drittanbieteranwendung verwenden, die auf Ihre Google Cloud-Ressourcen zugreifen muss und die Identitätsföderation nicht unterstützt.

Erstellen Sie in Situationen, in denen andere Authentifizierungsansätze nicht möglich sind, einen Dienstkontoschlüssel für die Anwendung. Mit einem Dienstkontoschlüssel kann sich eine Anwendung als Dienstkonto authentifizieren, ähnlich wie sich ein Nutzer mit einem Nutzernamen und einem Passwort authentifizieren kann. Dienstkontoschlüssel sind eine Art von Secret und müssen vor unbefugtem Zugriff geschützt werden.

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.

Dienstkonten nie während der Entwicklung verwenden

Während Ihrer täglichen Arbeit können Sie Tools wie die Google Cloud CLI, gsutil oder terraform verwenden. Verwenden Sie für die Ausführung dieser Tools kein Dienstkonto. Lassen Sie die Tools stattdessen Ihre Anmeldedaten verwenden. Führen Sie dazu zuerst gcloud auth login (für die gcloud CLI und gsutil) oder gcloud auth application-default login (für terraform und andere Tools von Drittanbietern) aus.

Sie können einen ähnlichen Ansatz zur Entwicklung und Fehlerbehebung von Anwendungen verwenden, die Sie in Google Cloud bereitstellen möchten. Nach der Bereitstellung erfordert die Anwendung möglicherweise ein Dienstkonto. Wenn Sie es auf Ihrer lokalen Workstation ausführen, kann diese Ihre persönlichen Anmeldedaten nutzen.

Verwenden Sie die Cloud-Clientbibliotheken und Standardanmeldedaten für Anwendungen, um dafür zu sorgen, dass Ihre Anwendung sowohl persönliche Anmeldedaten als auch Anmeldedaten für Dienstkonten unterstützt.

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:

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

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.

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

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:

  • 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, ist dies möglicherweise indirekt möglich, wenn das Dienstkonto von einer CI/CD-Pipeline, einer VM-Instanz oder einem anderen Automatisierungssystem verwendet wird, auf das er zugreifen kann. Wenn das System den Nutzer nicht daran hindert, könnte der Nutzer daher Vorgänge ausführen, die er nicht selbst ausführen darf.

    Wenn ein Nutzer beispielsweise SSH-Zugriff auf eine Compute Engine-VM-Instanz hat, kann er indirekt die Identität des Dienstkontos übernehmen, das an die VM-Instanz angehängt ist, und auf alle Google Cloud-Ressourcen zugreifen, für die das Dienstkonto Zugriff hat.

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

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

Datenzugriffslogs für IAM APIs aktivieren
Sicher stellen, dass der CI-/CD-Verlauf mit Cloud-Audit-Logs korreliert.

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

Nächste Schritte