Best Practices für die Verwaltung von Dienstkontoschlüsseln

Im Gegensatz zu normalen Nutzern haben Dienstkonten keine Passwörter. Stattdessen verwenden Dienstkonten RSA-Schlüsselpaare zur Authentifizierung: Wenn Sie den privaten Schlüssel des Schlüsselpaars eines Dienstkontos kennen, können Sie den privaten Schlüssel dazu verwenden, ein JWT-Inhabertoken zu erstellen. Das Inhabertoken verwenden Sie dann dazu, ein Zugriffstoken anzufordern. Das resultierende Zugriffstoken bezieht sich auf die Identität des Dienstkontos und Sie können es verwenden, um im Namen des Dienstkontos mit Google Cloud APIs zu interagieren.

Mit dem privaten Schlüssel können Sie sich als Dienstkonto authentifizieren. Der Zugriff auf den privaten Schlüssel ähnelt in etwa dem Passwort eines Nutzers. Der private Schlüssel wird als Dienstkontoschlüssel bezeichnet. Die von Dienstkonten verwendeten Schlüsselpaare fallen in zwei Kategorien: von Google verwaltet und vom Nutzer verwaltet.

Dienstkontoschlüssel können zu einem Sicherheitsrisiko werden, wenn sie nicht sorgfältig verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zur Authentifizierung auswählen. Die Hauptbedrohungen, die durch Dienstkontoschlüssel entstehen, sind:

  • Datenleck: Dienstkontoschlüssel können versehentlich an Orten vorhanden sein, an denen sie nicht gespeichert werden sollen. Ein böswilliger Akteur kann einen gehackten Dienstkontoschlüssel verwenden, um sich zu authentifizieren und in Ihrer Umgebung Ressourcen zu beanspruchen.
  • Eskalation von Berechtigungen: Wenn ein böswilliger Akteur Zugriff auf einen schlecht gesicherten Dienstkontoschlüssel erhält, kann er mit dem Schlüssel möglicherweise seine Berechtigungen eskalieren.
  • Offenlegung von Informationen: Dienstkontoschlüssel können unbeabsichtigt vertrauliche Metadaten offenlegen.
  • Keine Nachvollziehbarkeit: Durch die Authentifizierung mit einem Dienstkontoschlüssel und die Möglichkeit, dass das Dienstkonto Vorgänge in seinem Namen ausführt, kann ein böswilliger Akteur seine Identität und seine Aktionen verbergen.

Diese Bedrohungen können Sie am besten verringern, indem Sie vom Nutzer verwaltete Dienstkontoschlüssel vermeiden und nach Möglichkeit immer andere Methoden zur Authentifizierung von Dienstkonten verwenden. Sie können auch IAM-Bedingungen und VPC Service Controls verwenden, um einzuschränken, auf welche Ressourcen möglicherweise von einem manipulierten Dienstkonto aus zugegriffen werden kann.

Für Situationen, in denen Sie keine sichereren Alternativen zu Dienstkontoschlüsseln verwenden können, werden in diesem Leitfaden Best Practices für die Verwaltung, Verwendung und Sicherung von Dienstkontoschlüsseln vorgestellt.

Schutz vor Anmeldedatenlecks

Wie Nutzername und Passwort sind Dienstkontoschlüssel eine Form von Anmeldedaten. Wenn ein Nutzer Zugriff auf einen gültigen Dienstkontoschlüssel hat, kann er ihn zum Authentifizieren und Zugreifen auf die Ressourcen verwenden, auf die das jeweilige Dienstkonto Zugriff hat.

Für böswillige Akteure können Dienstkontoschlüssel noch wertvoller sein als ein gehacktes Passwort: Der Versuch, sich mit einem gehackten Passwort anzumelden, ist selten erfolgreich, wenn das Nutzerkonto mit einer Bestätigung in zwei Schritten und Identitätsbestätigungen konfiguriert wurde. Im Gegensatz dazu ist die Authentifizierung mithilfe eines gehackten Dienstkontoschlüssels wahrscheinlich erfolgreich, da Dienstkonten keiner zusätzlichen Anmeldungsüberprüfung unterliegen.

Böswillige Akteure können an verschiedenen Stellen nach Dienstkontoschlüsseln suchen, zum Beispiel:

  • Quellcode-Repositories von Open-Source-Projekten
  • Öffentliche Cloud Storage-Buckets
  • Öffentliche Datendumps beschädigter Dienste

Neben öffentlichen Standorten können böswillige Nutzer nach Dienstkontoschlüsseln an privaten Standorten suchen, die sie gehackt haben. Hier einige Beispiele:

  • E-Mail-Posteingänge
  • Dateifreigaben
  • Sicherungsspeicher
  • Temporäre Dateisystemverzeichnisse

Eine effektive Möglichkeit, die Möglichkeit von Datenlecks bei Dienstkontoschlüsseln zu verringern, besteht darin, die Anzahl der Schlüssel im Umlauf zu verringern und die Erstellung neuer Schlüssel zu behindern. In den folgenden Abschnitten wird beschrieben, wie Sie die Anzahl der Dienstkontoschlüssel im Umlauf begrenzen und welche anderen Maßnahmen Sie dabei unterstützen können, Datenlecks von Dienstkonten zu verringern.

Best Practices:

Alternativen zum Erstellen von Dienstkontoschlüsseln anbieten.
Mit Einschränkungen für Organisationsrichtlinien Nutzung von Dienstkontoschlüssel durch Projekte limitieren.
Keine Dienstkontoschlüssel an temporären Speicherorten belassen.
Keine Dienstkontoschlüssel zwischen Nutzern weitergeben.
Keine Dienstkontoschlüssel an Quellcode-Repositories senden.
Keine Dienstkontoschlüssel in Programmbinärdateien einbetten.
Nicht verwendete Dienstkontoschlüssel anhand von Statistiken und Messwerten ermitteln.
Dienstkontoschlüssel rotieren, um das Sicherheitsrisiko durch gehackte Schlüssel zu reduzieren.
Mit Ablaufzeiten das automatische Ablaufen von Schlüsseln festlegen.
Geleakte Schlüssel mithilfe von Einschränkungen für Organisationsrichtlinien automatisch deaktivieren.

Alternativen zum Erstellen von Dienstkontoschlüsseln anbieten

Sorgen Sie dafür, dass Nutzer in Ihrer Organisation Alternativen kennen und den zusätzlichen Risiko- und Verwaltungsaufwand für die Verwendung eines Dienstkontoschlüssels rechtfertigen können:

  • Ihre Entwickler über sicherere Alternativen zu Dienstkontoschlüsseln informieren
  • Richten Sie einen Prozess ein, der Entwicklern bei der Entscheidung für die geeignete Authentifizierungsmethode für ihren Anwendungsfall hilft, bevor sie einen neuen Dienstkontoschlüssel erstellen.
  • Verwenden Sie Einschränkungen für Organisationsrichtlinien, um das Erstellen neuer Dienstkontoschlüssel zu verhindern, und erlauben Sie nur Ausnahmen für Projekte, die gezeigt haben, dass sie keine sicherere Alternative verwenden können.

Mit Einschränkungen für Organisationsrichtlinien Nutzung von Dienstkontoschlüssel durch Projekte limitieren

Angesichts der sichereren Alternativen zu Dienstkontoschlüsseln ist es besser, die Verwendung von Dienstkontoschlüsseln als Ausnahme und nicht als Norm zu betrachten.

Verwenden Sie Einschränkungen für Organisationsrichtlinien, um eine unnötige Nutzung von Dienstkontoschlüsseln zu verhindern:

Wenn Sie Einschränkungen für Organisationsrichtlinien ändern möchten, benötigen Sie die Berechtigung orgpolicy.policy.set. Da weder die Inhaberrolle (roles/owner) noch die Bearbeiterrolle (roles/editor) diese Berechtigung enthält, können Einschränkungen auch in Nicht-Produktionsumgebungen wirksam werden, in denen einige Hauptkonten möglicherweise Inhaber- oder Bearbeiterzugriff auf Projekte haben.

Keine Dienstkontoschlüssel an temporären Speicherorten belassen

Wenn Sie einen Dienstkontoschlüssel mithilfe der Google Cloud Console erstellen, laden die meisten Browser den neuen Schlüssel sofort herunter und speichern ihn in einem Downloadordner auf Ihrem Computer. Sie sollten den Schlüssel sofort an den Speicherort verschieben, an dem Sie ihn speichern möchten. Achten Sie darauf, nicht versehentlich eine Kopie im Downloadordner oder im Papierkorb zu belassen.

Sie können das Risiko, versehentlich Kopien von Dienstkontoschlüsseln an temporären Speicherorten zu belassen, verringern. Dazu verwenden Sie das Google Cloud CLI: Mit dem Befehl gcloud iam service-accounts keys create können Sie Dienstkontoschlüssel direkt an den gewünschten Speicherort schreiben. Auf den meisten Betriebssystemen passt die gcloud CLI außerdem Dateiberechtigungen automatisch an, sodass die Datei nur für Sie zugänglich ist.

Keine Dienstkontoschlüssel zwischen Nutzern weitergeben

Wenn Sie eine Anwendung bereitstellen, für die ein Dienstkontoschlüssel erforderlich ist, sind Sie möglicherweise nicht berechtigt, einen Dienstkontoschlüssel selbst zu erstellen. Stattdessen müssen Sie möglicherweise eine andere Person bitten, einen Dienstkontoschlüssel für Sie zu erstellen.

In Szenarien, in denen mehrere Nutzer an der Erstellung und Bereitstellung eines Dienstkontoschlüssels beteiligt sind, besteht ein höheres Risiko, dass Kopien des Schlüssels in Postfächern, Chat-Verläufen oder an anderen Speicherorten verbleiben. Wenn eine Weitergabe zwischen Nutzern erforderlich ist, kann es sicherer sein, einen Dienstkontoschlüssel hochzuladen:

  1. Erstellen Sie als Nutzer, der die Anwendung bereitstellt, ein selbst signiertes Zertifikat, das ein RSA-2048-Bit-Schlüsselpaar auf dem Zielcomputer verwendet. Zum Erstellen des Zertifikats können Sie openssl, certutil, New-SelfSignedCertificate oder andere Betriebssystemtools verwenden.
  2. Übergeben Sie die Zertifikatsdatei an den Nutzer mit der Berechtigung zum Hochladen des Zertifikats, behalten Sie aber den privaten Schlüssel auf dem Zielcomputer. Achten Sie beim Übergeben des Zertifikats darauf, dass es nicht ersetzt oder manipuliert werden kann. Sie müssen es jedoch nicht vertraulich behandeln.
  3. Als Nutzer mit den erforderlichen Berechtigungen zum Verwalten von Dienstkontoschlüsseln laden Sie das Zertifikat hoch, um es mit einem Dienstkonto zu verknüpfen.

Wenn Sie diesen Prozess verwenden, verhindern Sie, dass der private Schlüssel weitergegeben wird, und tauschen stattdessen nur öffentliche Informationen zwischen Nutzern aus.

Keine Dienstkontoschlüssel an Quellcode-Repositories senden

Dienstkontoschlüssel sind Anmeldedaten, die vor unbefugtem Zugriff geschützt werden müssen. Wenn Sie einen Dienstkontoschlüssel an ein Quellcode-Repository senden, besteht ein erhöhtes Risiko, dass der Schlüssel für nicht autorisierte Nutzer und böswillige Akteure zugänglich ist:

  • Böswillige Akteure scannen den Quellcode von öffentlichen Quell-Repositories möglicherweise nach gehackten Schlüsseln.
  • Sie entscheiden zu einem späteren Zeitpunkt, ein ehemals privates Quell-Repository in ein öffentliches Repository umzuwandeln und prüfen es dann nicht mehr auf Schlüssel.
  • Andere Teammitglieder speichern Kopien des Quellcodes auf ihrer Workstation.

Wenn Sie an Code arbeiten, der einen Dienstkontoschlüssel verwendet, speichern Sie den Dienstkontoschlüssel immer getrennt vom Quellcode, um das Risiko zu verringern, versehentlich den Schlüssel an das Quell-Repository zu senden. In vielen Fällen können Sie diese Risiken weiter reduzieren, indem Sie während der Entwicklung überhaupt keine Dienstkontoschlüssel verwenden und Ihre persönlichen Anmeldedaten anstelle von Dienstkontoschlüsseln verwenden.

Richten Sie außerdem das Versionsverwaltungssystem so ein, dass es das versehentliche Senden von Dienstkontoschlüsseln erkennt:

Keine Dienstkontoschlüssel in Programmbinärdateien einbetten

Dienstkontoschlüssel sind Strings, die einem bestimmten Muster entsprechen und auch dann identifiziert werden können, wenn sie in andere Dateien oder Binärdateien eingebettet sind. Wenn ein böswilliger Akteur Zugriff auf die Binärdatei hat, kann er alle in die Binärdatei eingebetteten Dienstkontoschlüssel extrahieren.

Programmbinärdateien für serverseitige Anwendungen können in Artefakt-Repositories gehostet oder zu Debugging-Zwecken in Entwickler-Workstations kopiert werden. Sie sollten Dienstkontoschlüssel von Programmbinärdateien trennen und so sicherstellen, dass ein Nutzer, der auf die Binärdatei zugreifen kann, nicht implizit auf die Anmeldedaten des Dienstkontos zugreift.

  • Verwenden Sie für clientseitige Anwendungen wie Tools, Desktop-Programme oder mobile Apps keine Dienstkonten. Lassen Sie Nutzer stattdessen mit ihren eigenen Anmeldedaten über den OAuth-Zustimmungsvorgang authentifizieren.
  • Betten Sie bei serverseitigen Anwendungen keine Dienstkontoschlüssel in die Binärdatei ein. Halten Sie stattdessen die Schlüssel von der Binärdatei der Anwendung getrennt.

Nicht verwendete Dienstkontoschlüssel anhand von Statistiken und Messwerten ermitteln

Zur Minimierung der Anzahl gültiger Dienstkontoschlüssel sollten Sie Schlüssel deaktivieren, sobald sie nicht mehr verwendet werden. Löschen Sie dann die Schlüssel, wenn Sie sicher sind, dass sie nicht mehr benötigt werden. Wenn Sie sich nicht sicher sind, ob ein Schlüssel noch verwendet wird, können Sie Dienstkontostatistiken und Authentifizierungsmesswerte verwenden:

Da Dienstkonten zu einem Google Cloud-Projekt gehören, müssen Statistiken und Messwerte für jedes Projekt einzeln verfolgt werden.

Dienstkontoschlüssel rotieren, um das Sicherheitsrisiko durch gehackte Schlüssel zu reduzieren

Sie können zwar die Wahrscheinlichkeit verringern, dass ein Dienstkontoschlüssel versehentlich gehackt wird, aber das Risiko kann nur schwer ganz beseitigt werden.

Die Schlüsselrotation ist der Prozess, bei dem Ihre vorhandenen Schlüssel durch neue Schlüssel ersetzt und dann die ersetzten Schlüssel ungültig werden. Wir empfehlen, regelmäßig alle von Ihnen verwalteten Schlüssel zu rotieren, einschließlich der Dienstkontoschlüssel.

Durch die Rotation von Dienstkontoschlüsseln kann das Risiko von gehackten oder gestohlenen Schlüsseln verringert werden. Wenn ein Schlüssel versehentlich gehackt wurde, kann es den böswilligen Akteuren Tage oder Wochen dauern, bis er den Schlüssel erkennt. Wenn Sie Ihre Dienstkontoschlüssel regelmäßig rotieren, ist die Wahrscheinlichkeit höher, dass die gehackten Schlüssel ungültig sind, bis ein böswilliger Akteur sie erhält.

Mit einem etablierten Prozess zur Rotation von Dienstkontoschlüsseln können Sie schnell reagieren, wenn Sie vermuten, dass ein Dienstkontoschlüssel manipuliert wurde.

Wenn Sie das öffentliche/private Schlüsselpaar selbst generiert, den privaten Schlüssel in einem Hardware-Sicherheitsmodul (HSM) gespeichert und den öffentlichen Schlüssel in Google hochgeladen haben, müssen Sie den Schlüssel möglicherweise nicht regelmäßig erneuern. Sie können den Schlüssel jedoch rotieren, wenn Sie der Meinung sind, dass er möglicherweise manipuliert wurde.

Mit Ablaufzeiten Schlüssel automatisch ablaufen lassen

Standardmäßig haben Dienstkontoschlüssel, die Sie erstellen und von IAM herunterladen, keine Ablaufzeit und bleiben gültig, bis Sie sie löschen. Wenn Sie eine Ablaufzeit für Dienstkontoschlüssel festlegen, kann Ihr Sicherheitsrisiko verringert werden, indem die Lebensdauer der nichtflüchtigen Anmeldedaten reduziert wird. Mit dem Festlegen von Ablaufzeiten sind jedoch andere Risiken verbunden. Beispielsweise kann das Festlegen einer Ablaufzeit dazu führen, dass Arbeitslasten fehlschlagen, wenn ihre Schlüssel ablaufen.

Ablaufzeiten verwenden, wenn Sie vorübergehend auf ein System zugreifen müssen, das einen Dienstkontoschlüssel erfordert. Verwenden Sie beispielsweise Ablaufzeiten, wenn Sie Folgendes tun:

  • Entwickeln von Code in einer Nicht-Produktionsumgebung für eine Anwendung, die sich nur mit Dienstkontoschlüsseln authentifizieren kann
  • Verwendung eines Drittanbietertools, das sich nur mit Dienstkontoschlüsseln authentifizieren kann

Vermeiden Sie Ablaufzeiten in diesen Szenarien:

  • Produktionsarbeitslasten: In der Produktion kann ein abgelaufener Dienstkontoschlüssel einen versehentlichen Ausfall verursachen. Verwenden Sie stattdessen Schlüssel, die nicht ablaufen, und verwalten Sie ihren Lebenszyklus mit Schlüsselrotation.
  • Nicht-Produktionsarbeitslasten, die dauerhaften Zugriff benötigen, z. B. eine CI-Pipeline (Continuous Integration).
  • Schlüsselrotationssysteme, die verhindern, dass ein Schlüssel nach einer bestimmten Zeit verwendet wird. Weitere Informationen zu empfohlenen Strategien für die Schlüsselrotation finden Sie unter Schlüsselrotation für Dienstkonten.

Wenn Sie die Gültigkeit von Dienstkontoschlüsseln begrenzen möchten, können Sie eine Ablaufzeit für neu erstellte Schlüssel in Ihrem Projekt, Ordner oder Ihrer Organisation konfigurieren. Die Ablaufzeit gilt nicht für vorhandene Schlüssel.

Alternativ können Sie einen Dienstkontoschlüssel hochladen und ein Gültig bis-Datum in der X.509-Zertifikatsdatei angeben. Nach Ablauf des Ablaufdatums kann der Schlüssel nicht mehr zur Authentifizierung verwendet werden. Er bleibt jedoch mit dem Dienstkonto verknüpft, bis Sie ihn löschen.

Mit Einschränkungen für Organisationsrichtlinien die gehackten Schlüssel automatisch deaktivieren

Auch wenn Sie alle Best Practices für Dienstkontoschlüssel befolgen, können Ihre Dienstkontoschlüssel gehackt werden.

Achten Sie darauf, dass die Einschränkung „Reaktion bei zugänglichen Dienstkontoschlüsseln“ auf DISABLE_KEY festgelegt ist, um die gehackten Anmeldedaten zu verwalten. Wenn Sie die Einschränkung auf diesen Wert setzen, deaktiviert Google Cloud automatisch alle gehackten Schlüssel, die erkannt werden.

Weitere Best Practices für die Verwaltung manipulierter Anmeldedaten finden Sie unter Umgang mit manipulierten Google Cloud-Anmeldedaten.

Schutz vor Rechteeskalation

Die Verwendung von Dienstkontoschlüsseln kann Sie Angriffen in Form von Rechteeskalationen aussetzen, wenn die Schlüssel weniger sicher sind als die Ressourcen, auf die sie Zugriff gewähren.

Nehmen wir als Beispiel einen böswilligen Akteur, der sich bereits erfolgreich in Ihrer Umgebung befindet, und nun versucht, auf bestimmte Google Cloud-Ressourcen zuzugreifen. Auch wenn die Berechtigungen für den Zugriff auf diese Ressourcen möglicherweise nicht ausreichen, reichen die Berechtigungen möglicherweise aus, um auf einen Dienstkontoschlüssel zuzugreifen, der auf einer VM, einer Dateifreigabe oder an einem anderen weniger sicheren Speicherort gespeichert ist. Durch die Authentifizierung mit dem Dienstkontoschlüssel kann der böswillige Akteur die Identität des Dienstkontos annehmen. Das Dienstkonto kann dem böswilligen Akteur möglicherweise Zugriff auf Ressourcen gewähren, auf die er zuvor keinen Zugriff hatte, und damit die Berechtigungen des böswilligen Akteurs eskalieren.

Da ein Dienstkontoschlüssel indirekt Zugriff auf Ressourcen in Google Cloud gewährt, müssen Sie den Schlüssel als genauso wertvoll und schützenswert wie die Ressourcen selbst betrachten.

In den folgenden Abschnitten werden Best Practices zum Schutz von Dienstkontoschlüsseln und zur Reduzierung des Risikos von unbefugtem Zugriff und der daraus resultierenden Rechteeskalation beschrieben.

Best Practices:

Speichern von Schlüsseln in einem Dateisystem vermeiden.
Schlüssel mit HSM oder TPM speichern.
Einen softwarebasierten Schlüsselspeicher verwenden.
Keine Schlüssel in Secret Manager oder anderen cloudbasierten Secret-Speichern speichern.
Bearbeiterrolle nicht in Projekten verwenden, die das Erstellen oder Hochladen von Dienstkontoschlüsseln zulassen.
Keine Dienstkontoschlüssel für die domainweite Delegierung verwenden.

Schlüssel nicht in einem Dateisystem speichern

Dienstkontoschlüssel, die mit der Google Cloud Console oder der gcloud CLI erstellt wurden, sind JSON-Dateien. Sie können diese Dateien in das Dateisystem des Computers kopieren, auf dem sie benötigt werden. Das Speichern von Dienstkontoschlüsseln als Dateien in einem Dateisystem kann jedoch auch mehrere Risiken bergen, darunter:

  • Einige Dateisysteme wie NTFS verwenden standardmäßig übernommene Berechtigungen. Sofern nicht deaktiviert, kann eine Berechtigung, die einem übergeordneten Ordner hinzugefügt wird, versehentlich dazu führen, dass eine Schlüsseldatei allgemein zugänglich und für nicht autorisierte Nutzer sichtbar wird.
  • In einer virtualisierten Umgebung können böswillige Nutzer die Dateisystemsicherheit untergraben, wenn sie auf das zugrunde liegende virtuelle Laufwerk zugreifen.
  • Änderungen am Dateisystemzugriff und an Berechtigungen werden häufig nicht über Audit-Logging protokolliert. Wenn Dateiberechtigungen versehentlich geändert werden und der Schlüssel für nicht autorisierte Nutzer sichtbar wird, ist es möglicherweise schwierig zu analysieren, wann und von wem diese Änderungen vorgenommen wurden.
  • Falls ein böswilliger Akteur Zugriff auf Dateien erhält, kann er die Dateien einfach kopieren und dann exfiltrieren.

Vermeiden Sie nach Möglichkeit die Speicherung von Dienstkontoschlüsseln in einem Dateisystem. Wenn Sie das Speichern von Schlüsseln auf dem Laufwerk nicht vermeiden können, müssen Sie den Zugriff auf die Schlüsseldatei beschränken, die Dateizugriffsprüfung konfigurieren und das zugrunde liegende Laufwerk verschlüsseln.

HSM oder TPM zum Speichern von Schlüsseln verwenden

Wenn Sie einen Dienstkontoschlüssel mit der Google Cloud Console oder der gcloud CLI erstellen, wird der private Schlüssel von Google Cloud generiert und Ihnen angezeigt. Viele mit Dienstkontoschlüsseln verbundene Sicherheitsrisiken beruhen auf der Tatsache, dass der private Schlüssel vorübergehend oder dauerhaft in Klartext verfügbar ist und daher schwer zu schützen ist.

Anstatt ein Schlüsselpaar in Google Cloud erzeugen zu lassen, können Sie ein Hardwaresicherheitsmodul (HSM) oder ein Trusted Platform Module (TPM) verwenden, um Schlüssel zu erstellen und zu verwalten:

  1. Verwenden Sie ein HSM oder TPM, um ein RSA-Schlüsselpaar zu generieren.
  2. Verwenden Sie das Schlüsselpaar, um ein selbst signiertes Zertifikat zu erstellen.
  3. Laden Sie das Zertifikat als Dienstkontoschlüssel hoch.
  4. Die Anwendung kann die HSM oder TPM Signing API verwenden, um das JWT für die Authentifizierung des Dienstkontos zu signieren.

Mit einem HSM oder TPM können Sie einen privaten Schlüssel verwenden, ohne den Schlüssel im Klartext anzuzeigen. Wenn Sie HSM oder TPM zur Verwaltung von Dienstkontoschlüsseln verwenden, können Sie die Zugriffssteuerung erzwingen und so das Risiko verringern, dass Schlüssel in andere Systeme kopiert werden.

Einige Plattformen bieten Abstraktionen, mit denen Sie ein TPM nutzen können, ohne direkt damit interagieren zu müssen. Unter Windows können Sie beispielsweise TPM-geschützte Schlüssel verwalten, indem Sie die CryptoNG API in Kombination mit Microsoft Platform Crypto Provider verwenden.

Von einem TPM verwaltete Dienstkontoschlüssel sind für eine physische oder virtuelle Maschine eindeutig. So können weiterhin mehrere Maschinen ein gemeinsames Dienstkonto verwenden lassen. Verknüpfen Sie dazu den Schlüssel jeder Maschine mit einem gemeinsamen Dienstkonto.

Softwarebasierten Schlüsselspeicher verwenden

Wenn die Verwendung eines hardwarebasierten Schlüsselspeichers nicht praktikabel ist, verwenden Sie einen softwarebasierten Schlüsselspeicher zum Verwalten von Dienstkontoschlüsseln. Ähnlich wie bei hardwarebasierten Optionen können Nutzer oder Anwendungen bei Verwendung eines softwarebasierten Schlüsselspeichers Dienstkontoschlüssel verwenden, ohne den privaten Schlüssel anzuzeigen. Softwarebasierte Schlüsselspeicherlösungen können Sie dabei unterstützen, den Schlüsselzugriff detailliert zu steuern und sicherzustellen, dass jeder Schlüsselzugriff protokolliert wird.

Die Sicherheit eines softwarebasierten Schlüsselspeichers hängt normalerweise davon ab, wie der Masterschlüssel geschützt ist. Bevor Sie einen softwarebasierten Schlüsselspeicher verwenden, sollten Sie Folgendes prüfen:

  • Wie wird der Masterschlüssel im Ruhezustand gesichert?
  • Wie funktioniert der Versiegelungsprozess und wer kann ihn initiieren?
  • Wie sind die Schlüssel vor dem Extrahieren aus dem Speicher geschützt?
  • Wie wird der Schlüsselspeicher vor Störungen durch einen böswilligen Akteur geschützt, der Zugriff auf Shell oder Hypervisor des zugrunde liegenden Systems erhalten hat?

Kein Speichern von Schlüsseln im Secret Manager oder in anderen cloudbasierten Secret-Speichern

Es wird nicht empfohlen, Secret Manager von Google Cloud zum Speichern und Rotieren von Dienstkontoschlüsseln zu verwenden. Dies liegt daran, dass Ihre Anwendung für den Zugriff auf Secret Manager-Secrets eine Identität benötigt, die Google Cloud erkennen kann. Wenn Ihre Anwendung bereits eine Identität hat, die Google Cloud erkennen kann, kann sie sich mit dieser Identität bei Google Cloud authentifizieren, anstatt einen Dienstkontoschlüssel zu verwenden.

Dasselbe Konzept gilt für andere cloudbasierte Secret-Verwaltungsdienste wie Azure KeyVault und AWS Secret Manager. Wenn eine Anwendung bereits eine Identität hat, die diese Cloud-Anbieter erkennen können, kann sie sich mit dieser Identität bei Google Cloud authentifizieren, anstatt einen Dienstkontoschlüssel zu verwenden.

Bearbeiterrolle nicht in Projekten verwenden, die das Erstellen oder Hochladen von Dienstkontoschlüsseln zulassen

Ein wesentlicher Unterschied zwischen den einfachen Rollen "Bearbeiter" (roles/editor) und "Inhaber" (roles/owner) besteht darin, dass Sie mit der Rolle "Bearbeiter" keine IAM-Richtlinien oder -Rollen ändern können. Mit der Bearbeiterrolle können Sie Ihren eigenen Zugriff daher nicht einfach erweitern oder anderen Nutzern Zugriff auf Projektressourcen gewähren.

Die Beschränkungen der Rolle "Bearbeiter" können untergraben werden, wenn ein Projekt Dienstkonten enthält. Da die Bearbeiterrollen Berechtigung zum Erstellen oder Hochladen von Dienstkontoschlüsseln gewähren, kann ein böswilliger Akteur neue Schlüssel für vorhandene Dienstkonten erstellen und diese Schlüssel verwenden, um entweder seinen eigenen Zugriff zu eskalieren oder die Schlüssel an andere Nutzer zu übergeben, damit diese Zugriff auf Projektressourcen erhalten.

Anstatt die Rolle "Bearbeiter" oder eine andere einfache Rolle zu verwenden, sollten Sie die spezifischeren vordefinierten Rollen verwenden oder benutzerdefinierte Rollen erstellen, die ausschließlich die erforderlichen Berechtigungen gewähren.

Wenn Sie die Rolle "Bearbeiter" verwenden müssen, deaktivieren Sie das Hochladen für den Dienstkontoschlüssel und für das Erstellen des Schlüssels mithilfe von Einschränkungen für Organisationsrichtlinien. Dies stellt sicher, dass die Bearbeiterrolle nicht für die Rechteeskalation missbraucht werden kann.

Keine Dienstkontoschlüssel für die domainweite Delegierung verwenden

Durch die domainweite Delegierung kann die Identität eines Nutzers übernommen werden, sodass ein Zugriff auf die Daten eines Nutzers ohne manuelle Autorisierung des Nutzers möglich wird. Obwohl die Beispiele für die Verwendung einer domainweiten Delegierung im Allgemeinen die Nutzung von Dienstkontoschlüsseln empfehlen, sind diese für eine domainweite Delegierung nicht erforderlich.

Wenn Sie die domainweite Delegierung verwenden, vermeiden Sie Dienstkontoschlüssel und verwenden Sie stattdessen die signJwt API:

  1. Authentifizieren Sie ein Dienstkonto zuerst mithilfe eines angehängten Dienstkontos, einer Workload Identity oder einer Workload Identity-Föderation.
  2. Erstellen Sie ein JWT und verwenden Sie die Anforderung sub dazu, die E-Mail-Adresse des Nutzers festzulegen, für den Sie den delegierten Zugriff anfordern.
  3. Verwenden Sie die signJwt API, um das JWT zu signieren.
  4. Übergeben Sie das signierte JWT an die OAuth2-Token-Ressource, um ein Zugriffstoken zu erhalten.

Wenn Sie diesem Ansatz folgen, müssen Sie keinen Dienstkontoschlüssel verwalten. Dies führt zu einer einfacheren Sicherung.

Schutz vor der Offenlegung von Informationen

Best Practices:

Offenlegung vertraulicher Informationen in hochgeladenen X.509-Zertifikaten vermeiden.

Offenlegung vertraulicher Informationen in hochgeladenen X.509-Zertifikaten vermeiden

Für jeden Dienstkontoschlüssel können Sie in IAM ein X.509-Zertifikat vom Endpunkt https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL herunterladen. Dieser Endpunkt ist öffentlich und erfordert keine Authentifizierung.

Für von Google und vom Nutzer verwaltete Schlüssel, die Sie mit der Google Cloud Console oder der gcloud CLI erstellt haben, werden die X.509-Zertifikate automatisch mit einfachen Metadaten wie die E-Mail-Adresse und das Ablaufdatum erstellt.

Bei hochgeladenen Dienstkontoschlüsseln ist das vom öffentlichen Endpunkt bereitgestellte X.509-Zertifikat dasselbe Zertifikat wie das hochgeladene. Wenn das hochgeladene Zertifikat optionale Attribute wie Adressen oder Standortinformationen enthielt, die im gemeinsamen Namen eingebettet waren, werden diese Informationen auch öffentlich zugänglich. Ein böswilliger Akteur kann diese Informationen nutzen, um mehr über Ihre Umgebung zu erfahren.

Damit keine vertraulichen Informationen offengelegt werden, fügen Sie den hochgeladenen X.509-Zertifikaten keine optionalen Attribute hinzu und verwenden Sie einen generischen Subject.

Schutz vor Nichterkennungs-Bedrohungen

Wenn Sie verdächtige Aktivitäten bemerken, die sich auf Ihre Google Cloud-Ressourcen auswirken und deren Ursprünge analysieren möchten, benötigen Sie Daten, mit denen Sie die Kette von Ereignissen rekonstruieren können, die zu der verdächtigen Aktivität geführt haben. Die primäre Datenquelle für eine solche Analyse sind in der Regel Audit-Logs.

Die Analyse von Audit-Logs kann schwieriger werden, wenn Dienstkonten beteiligt sind: Wenn eine Aktivität von einem Dienstkonto initiiert wurde, enthält der Logeintrag die E-Mail-Adresse des Dienstkontos, aber Sie müssen auch herausfinden, welcher Nutzer oder welche Anwendung das Dienstkonto zu diesem Zeitpunkt verwendet hat.

Die folgenden Abschnitte enthalten Best Practices zur Verwendung von Dienstkontoschlüsseln, um deren Nutzung besser verfolgen zu können.

Best Practices:

Für jede Anwendung ein eigenes Dienstkonto verwenden.
Für jeden Computer, der eine Anwendung ausführt, einen eigenen Schlüssel verwenden.

Für jede Anwendung ein eigenes Dienstkonto verwenden

Alle Audit-Logeinträge enthalten ein Feld principalEmail, in dem das Hauptkonto angegeben ist, das die Aktivität initiiert hat. Wenn Sie einen Dienstkontoschlüssel für mehrere Anwendungen freigeben, kann es schwierig sein, zu ermitteln, welche Anwendung eine Aktivität ausgeführt hat, da Audit-Logeinträge denselben principalEmail-Wert enthalten.

Anstatt einen Schlüssel für mehrere Anwendungen freizugeben, erstellen Sie für jede Anwendung ein eigenes Dienstkonto. Auf diese Weise können Sie im Feld principalEmail die Anwendung identifizieren, die mit einem Dienstkonto verknüpft ist. Damit können Sie die Kette von Ereignissen rekonstruieren, die zu einer verdächtigen Aktivität geführt haben.

Für jeden Computer, der eine Anwendung ausführt, einen eigenen Schlüssel verwenden

Wenn Sie mehrere Kopien derselben Anwendung auf mehreren Computern ausführen, können Sie mit dem Feld principalEmail die Anwendung identifizieren, aber nicht die Maschine, von der eine bestimmte Aktivität stammt.

Erstellen Sie für jede Kopie der Anwendung individuelle Schlüssel, um die potenziellen Quellen verdächtiger Aktivitäten einzugrenzen. So können Sie das Feld serviceAccountKeyName verwenden, das viele Dienste zu Audit-Logeinträgen hinzufügen, um zu unterscheiden, von welchem Computer eine Aktivität stammt.

Nächste Schritte