Best Practices für die Verwendung und Verwaltung 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.

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

Wann sind Dienstkonten zu verwenden?

Dienstkonten können für viele verschiedene Zwecke verwendet werden, sind aber nicht immer die beste Wahl. Im folgenden Abschnitt finden Sie Hinweise dazu, wann Sie Dienstkonten verwenden und wann Sie diese vermeiden sollten.

Dienstkonten in unbeaufsichtigten Szenarien verwenden

Nicht jede Anwendung interagiert mit menschlichen Nutzern. Manche Anwendungen können unbeaufsichtigt im Hintergrund ausgeführt werden. Zu unbeaufsichtigten Anwendungen gehören Batchjobs, Worker-Prozesse, die aus einer Warteschlange gelesene Nachrichten weiterleiten, und Ressourcenmonitoring-Agenten.

Wenn eine unbeaufsichtigte Anwendung auf eine Ressource zugreifen muss, z. B. auf einen Cloud Storage-Bucket, muss diese in ihrem eigenen Namen handeln, nicht im Namen eines Endnutzers. Um im eigenen Namen zu handeln, benötigen Anwendungen eine eigene Identität, die nicht mit der Identität eines beliebigen Endnutzers in Zusammenhang steht.

Damit eine Anwendung ihre eigene Identität hat, müssen Sie ein Dienstkonto für die Anwendung erstellen und dem Dienstkonto Zugriff auf die Ressourcen gewähren, auf die die Anwendung zugreifen muss. Wenn Sie zulassen, dass eine Anwendung ihr eigenes Dienstkonto verwendet, funktioniert die Anwendung ohne Nutzerinteraktion. Außerdem stellen Sie damit sicher, dass alle von der Anwendung initiierten Ressourcenzugriffe wieder derselben Anwendung zugeordnet werden können.

Mit Dienstkonten eine Umstellung zwischen Hauptkonten vornehmen

Eine Anwendung, die mit Endnutzern interagiert, kann Google Log-in verwenden, um diese Nutzer zu authentifizieren, ist aber nicht dazu verpflichtet. Stattdessen können Anwendungen sich auf externe Identitätsanbieter verlassen oder ein benutzerdefiniertes Authentifizierungsschema für die Nutzerauthentifizierung implementieren.

Wenn eine Anwendung Drittanbieter- oder benutzerdefinierte Identitäten nutzt und Zugriff auf eine Ressource wie ein BigQuery-Dataset oder einen Cloud Storage-Bucket benötigt, muss sie eine Umstellung zwischen Hauptkonten bewerkstelligen. Da Google Cloud APIs keine Drittanbieter- oder benutzerdefinierten Identitäten erkennen, kann die Anwendung die Identität des Endnutzers nicht an BigQuery oder Cloud Storage übertragen. Stattdessen muss die Anwendung für den Zugriff eine andere Google-Identität nutzen.

Damit eine Anwendung eine Umstellung zwischen Hauptkonten bedingen kann, erstellen Sie ein Dienstkonto für die Anwendung und gewähren ihr Zugriff auf die Ressourcen, auf die die Anwendung zugreifen muss. Immer, wenn eine Anwendung auf eine Google Cloud-Ressource zugreifen muss, sollte diese zuerst den Endnutzer authentifiziert. Anschließend können Sie ihr den Zugriff auf die Ressource erlauben.

Umstellungen zwischen Hauptkonten können den Nutzen von Cloud-Audit-Logs der betroffenen Google Cloud-Ressourcen einschränken: Da die Anwendung ein Dienstkonto für den Zugriff auf Ressourcen verwendet, enthalten Cloud-Audit-Logs möglicherweise keine klare Information darüber, ob eine Aktion im Namen eines bestimmten Endnutzers ausgeführt wurde oder nicht. Damit die Zuverlässigkeit nicht beeinträchtigt wird, erweitern Sie Ihre Anwendung so, dass immer dann ein benutzerdefinierter Logdatensatz geschrieben wird, wenn eine Umstellung zwischen Hauptkonten auftritt. Auf diese Weise können Sie verfolgen, welcher Endnutzer einen Ressourcenzugriff ausgelöst hat.

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 der täglichen Arbeit können Sie Tools wie das gcloud-Befehlszeilentool, 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 das gcloud-Tool und gsutil) oder gcloud auth application-default login (für terraform und andere Drittanbieter) aus. Tools von Drittanbietern verwenden.

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.

Damit Ihre Anwendung sowohl persönliche Anmeldedaten als auch Anmeldedaten von Dienstkonten unterstützt, können Sie mithilfe der Cloud-Clientbibliotheken Anmeldedaten automatisch finden.

Dienstkonten verwenden

Nutzer können sich normalerweise bei Google Cloud authentifizieren, indem sie sich mit einem Nutzernamen und Passwort anmelden oder die Einmalanmeldung (SSO) verwenden. Dienstkonten haben kein Passwort und können SSO nicht verwenden. Stattdessen unterstützen Dienstkonten eine Reihe anderer Authentifizierungsmethoden. Der folgende Abschnitt enthält Best Practices zum Auswählen einer Authentifizierungsmethode.

Dienstkonten 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. Clientbibliotheken erkennen automatisch, ob Anwendung auf einer Compute-Ressource mit einem angehängten Dienstkonto ausgeführt wird.

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.

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. Beispiel: Eine Ihrer lokalen Anwendungen kann Zugriff auf Google Cloud-Ressourcen benötigen, aber Ihr lokaler Identitätsanbieter ist nicht mit OpenID Connect kompatibel und kann daher nicht für die Workload Identity Federation verwendet werden.

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. Es empfiehlt sich, sie an einem sicheren Ort wie einem Key Vault zu speichern und regelmäßig zu rotieren.

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.

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.

Um diese Problem zu umgehen, erstellen Sie für jede Anwendung dedizierte Dienstkonten und vermeiden die Verwendung von Standardkonten.

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. Verwenden Sie in diesen Fällen folgende Methoden:

  • Dienstkontostatistiken zeigen Ihnen, für welche Dienstkonten in den letzten 90 Tagen keine Authentifizierungen durchgeführt wurden.
  • Mit der Aktivitätsanalyse können Sie prüfen, wann ein Dienstkonto zuletzt verwendet wurde.

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.

Nächste Schritte