Dienstkonto-Anmeldedaten

Wie jedes andere Hauptkonto kann sich ein Dienstkonto bei Google authentifizieren, ein OAuth 2.0-Zugriffstoken abrufen und Google APIs aufrufen. Dieser Vorgang ist bei Dienstkonten jedoch anders als bei Nutzern.

Dienstkonten werden mit einer der folgenden Methoden authentifiziert:

• Kurzlebige Anmeldedaten abrufen
• Mit einem Dienstkontoschlüssel ein JSON Web Token (JWT) signieren und gegen ein Zugriffstoken austauschen

Kurzlebige Anmeldedaten für das Dienstkonto

Die sicherste Methode zur Authentifizierung als Dienstkonto besteht darin, kurzlebige Anmeldedaten für das Dienstkonto in Form eines OAuth 2.0-Zugriffstokens abzurufen. Standardmäßig laufen diese Token nach einer Stunde ab.

Kurzlebige Anmeldedaten für Dienstkonten sind nützlich, wenn Sie vertrauenswürdigen Dienstkonten eingeschränkten Zugriff auf Ressourcen gewähren müssen. Sie stellen außerdem ein geringeres Risiko dar als langlebige Anmeldedaten wie Dienstkontoschlüssel.

In vielen Fällen werden diese Anmeldedaten automatisch abgerufen. Sie müssen sie nicht selbst erstellen oder verwalten. Hier sind einige Beispiele:

• Wenn Sie einen Befehl der Google Cloud CLI ausführen und das Flag --impersonate-service-account einfügen, erstellt die gcloud CLI kurzlebige Anmeldedaten für das Dienstkonto und führt den Befehl mit diesen Anmeldedaten aus.

• Wenn Sie ein Dienstkonto an eine Compute Engine-VM-Instanz anhängen, können Arbeitslasten auf dieser Instanz die Cloud-Clientbibliotheken verwenden, um auf Google Cloud-Dienste zuzugreifen. Die Cloud-Clientbibliotheken verwenden Standardanmeldedaten für Anwendungen, um kurzlebige Anmeldedaten für das Dienstkonto abzurufen.

  Weitere Informationen zu Anwendungen mithilfe der Anmeldedaten des Dienstkontos authentifizieren.

• Wenn Sie eine Identitätsföderation von Arbeitslasten konfiguriert haben, können die Cloud-Clientbibliotheken Anmeldedaten von Ihrem Identitätsanbieter verwenden, um kurzlebige Anmeldedaten für Dienstkonten zu generieren.

Sie können auch die Service Account Credentials API verwenden, um kurzlebige Anmeldedaten manuell zu erstellen. Sie können beispielsweise einen Dienst erstellen, der Nutzern kurzlebige Anmeldedaten für das Dienstkonto zur Verfügung stellt, damit sie vorübergehend auf Google Cloud-Ressourcen zugreifen können.

Die Service Account Credentials API kann die folgenden Arten von Anmeldedaten erstellen:

• OAuth 2.0-Zugriffstoken
• OIDC-ID-Tokens (OpenID Connect)
• Selbstsignierte JSON Web Tokens (JWTs)
• Selbstsignierte binäre Blobs

Weitere Informationen zu Kurzlebige Anmeldedaten für das Dienstkonto erstellen.

Audit-Logs interpretieren

Mit Cloud-Audit-Logging können Sie für Ihre Google Cloud-Ressourcen herausfinden, wer was wo und wann getan hat.

Wenn Sie kurzlebige Anmeldedaten verwenden, um die Identität eines Dienstkontos zu übernehmen, erstellen die meisten Google Cloud-Dienste Logeinträge, die die folgenden Identitäten enthalten:

• Das Dienstkonto, für das die kurzlebigen Anmeldedaten eine Identitätsübernahme durchführen
• Die Identität, die die kurzlebigen Anmeldedaten erstellt hat

Anhand dieser Logeinträge können Sie das Hauptkonto identifizieren, das die kurzlebigen Anmeldedaten erstellt hat, sowie das Dienstkonto, dessen Identität vom Hauptkonto angenommen wurde.

Hinweis: Bei einigen Google Cloud-Diensten, einschließlich App Engine und Google Kubernetes Engine, wird die Identität, die die kurzlebigen Anmeldedaten erstellt hat, nicht geloggt.

Beispiele für Audit-Log-Einträge, die die Identitätsübertragung für ein Dienstkonto anzeigen, finden Sie unter Identität eines Dienstkontos für den Zugriff auf Google Cloud übernehmen.

Selbst initiierter Identitätswechsel

Beim Selbst initiierten Identitätswechsel verwenden Sie die Anmeldeinformationen eines Dienstkontos, um neue Anmeldedaten für das Dienstkonto zu erstellen.

Die Service Account Credentials API verhindert die folgenden Arten von Selbst initiiertem Identitätswechsel:

• Kurzlebige Anmeldedaten für ein Dienstkonto verwenden, um ein neues Zugriffstoken für das Dienstkonto zu generieren

  Selbstsignierte JSON Web Tokens (JWTs) sind die Ausnahme von dieser Regel. Sie können ein selbstsigniertes JWT für ein Dienstkonto verwenden, um ein neues Zugriffstoken für das Dienstkonto zu generieren.

• Kurzlebige Anmeldedaten für ein Dienstkonto zum Signieren eines binären Objekts (Blob) oder von JWTs, die zum Aufrufen der folgenden APIs verwendet werden können:

  • Identity and Access Management API
  • Service Account Credentials API
  • OAuth 2.0 API

Google Cloud verhindert diese Art der selbst initiierten Identitätswechsel, da böswillige Nutzer gestohlene Tokens unbefristet aktualisieren können.

Wenn Sie versuchen, auf eine der verbotenen Arten die Identität zu wechseln, kann der folgende Fehler auftreten:

FAILED_PRECONDITION: You can't create a token for the same service account that
you used to authenticate the request.

Wenn dieser Fehler auftritt, versuchen Sie, mit anderen Anmeldedaten kurzlebige Anmeldedaten für Ihr Dienstkonto zu generieren, z. B. mit den Anmeldedaten Ihres Endnutzers oder den Anmeldedaten eines anderen Dienstkontos.

Dienstkontoschlüssel

Jedes Dienstkonto ist einem öffentlichen/privaten RSA-Schlüsselpaar zugeordnet. Die Service Account Credentials API verwendet dieses interne Schlüsselpaar, um kurzlebige Anmeldedaten für Dienstkonten zu erstellen und Blobs und JSON-Web-Tokens (JWTs) zu signieren. Dieses Schlüsselpaar wird als von Google verwaltetes Schlüsselpaar bezeichnet.

Darüber hinaus können Sie mehrere öffentliche/private RSA-Schlüsselpaare erstellen, die als nutzerverwaltete Schlüsselpaare bezeichnet werden, und den privaten Schlüssel zum Authentifizieren bei Google APIs verwenden. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet.

Von Google verwaltete Schlüsselpaare

Von Google verwaltete Schlüsselpaare werden von der Service Account Credentials API und von Google Cloud-Diensten wie App Engine und Compute Engine verwendet, um kurzlebige Anmeldedaten für Dienstkonten zu generieren.

Von Google verwaltete Schlüssel, die aktiv zum Signieren verwendet werden, werden gemäß den Best Practices für die Sicherheit regelmäßig rotiert. Der Rotationsprozess folgt einem probabilistischen Ansatz. Die Verwendung des neuen Schlüssels wird während der Lebensdauer des Schlüssels schrittweise aufwärts- und abwärtsskaliert.

Der private Schlüssel in einem von Google verwalteten Schlüsselpaar wird immer treuhänderisch aufbewahrt. Sie können nicht direkt darauf zugreifen.

Der öffentliche Schlüssel in einem von Google verwalteten Schlüsselpaar ist öffentlich zugänglich, sodass jeder die mit dem privaten Schlüssel erstellten Signaturen überprüfen kann. Sie können auf den öffentlichen Schlüssel in verschiedenen Formaten zugreifen:

• X509Certificate: https://www.googleapis.com/service_accounts/v1/metadata/x509/SERVICE_ACCOUNT_EMAIL
• JSON-Webschlüssel (JWK): https://www.googleapis.com/service_accounts/v1/jwk/SERVICE_ACCOUNT_EMAIL
• Rohformat: https://www.googleapis.com/service_accounts/v1/metadata/raw/SERVICE_ACCOUNT_EMAIL

Wenn Sie den öffentlichen Schlüssel herunterladen und im Cache speichern, empfehlen wir, ihn für höchstens 24 Stunden im Cache zu speichern, damit Sie immer den aktuellen Schlüssel haben. Unabhängig davon, wann Sie den öffentlichen Schlüssel abrufen, ist er mindestens 24 Stunden nach dem Abruf gültig.

Von Nutzern verwaltete Schlüsselpaare

Sie können von Nutzern verwaltete Schlüsselpaare für ein Dienstkonto erstellen und sich dann mit dem privaten Schlüssel aus jedem Schlüsselpaar bei Google APIs authentifizieren. Dieser private Schlüssel wird als Dienstkontoschlüssel bezeichnet.

Die Cloud-Clientbibliotheken können Dienstkontoschlüssel verwenden, um automatisch ein OAuth 2.0-Zugriffstoken abzurufen. Sie können auch einen Dienstkontoschlüssel verwenden, um ein JWT manuell zu signieren und dann das signierte JWT zum Anfordern eines Zugriffstokens verwenden. Weitere Informationen zu OAuth 2.0 für Server-zu-Server-Anwendungen verwenden.

Achtung: Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen. Wenn Sie sich mit einem Dienstkontoschlüssel authentifizieren müssen, sind Sie für die Sicherheit des privaten Schlüssels und für andere Vorgänge verantwortlich, die unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschrieben werden. Wenn Sie keinen Dienstkontoschlüssel erstellen können, ist das Erstellen von Dienstkontoschlüsseln für Ihre Organisation möglicherweise deaktiviert. Weitere Informationen finden Sie unter Standardmäßig sichere Organisationsressourcen verwalten.

Jedes Dienstkonto kann bis zu zehn Dienstkontoschlüssel haben. Google speichert nur den öffentlichen Teil eines nutzerverwalteten Schlüsselpaars.

Es gibt verschiedene Möglichkeiten, ein nutzerverwaltetes Schlüsselpaar für ein Dienstkonto zu erstellen:

• Verwenden Sie die IAM API, um ein nutzerverwaltetes Schlüsselpaar automatisch zu erstellen. Google generiert ein öffentliches/privates Schlüsselpaar; speichert nur den öffentlichen Schlüssel; und gibt den privaten Schlüssel zurück.
• Erstellen Sie selbst ein nutzerverwaltetes Schlüsselpaar und laden Sie dann nur den öffentlichen Schlüssel hoch. Google sieht den privaten Schlüssel nie.

Von Nutzern verwaltete Schlüssel sind äußerst leistungsstarke Anmeldedaten. Wenn Sie die Verwendung von nutzerverwalteten Schlüsseln einschränken möchten, können Sie die folgenden Einschränkungen für Organisationsrichtlinien für eine Organisation, ein Projekt oder einen Ordner erzwingen:

• constraints/iam.disableServiceAccountKeyCreation: verhindert, dass Hauptkonten nutzerverwaltete Dienstkontoschlüssel erstellen.
• constraints/iam.disableServiceAccountKeyUpload: verhindert, dass Hauptkonten einen öffentlichen Schlüssel für ein Dienstkonto hochladen.

Wenn Sie diese Einschränkungen erzwingen, weil Sie die Identitätsföderation von Arbeitslasten verwenden, können Sie mit den Einschränkungen für Organisationsrichtlinien für die Identitätsföderation von Arbeitslasten angeben, welche Identitätsanbieter zulässig sind.

Ablaufzeiten für von Nutzern verwaltete Schlüssel

Wenn Sie einen von Nutzern verwalteten Dienstkontoschlüssel erstellen, läuft der Schlüssel standardmäßig nie ab. Sie können diese Standardeinstellung ändern, indem Sie eine Ablaufzeit für alle neu erstellten Schlüssel in Ihrem Projekt, Ordner oder Ihrer Organisation festlegen. Eine Ablaufzeit gibt die Anzahl der Stunden an, für die ein neu erstellter Schlüssel gültig ist.

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.

Um Ausfälle zu vermeiden, sollten Sie keine Ablaufzeit festlegen, es sei denn, die Einschränkung der Organisationsrichtlinie constraints/iam.disableServiceAccountKeyCreation ist bereits für einen längeren Zeitraum vorhanden. Wenn Sie eine Ablaufzeit festlegen, müssen Sie auch das Erzwingen der Einschränkung constraints/iam.disableServiceAccountKeyCreation beenden. Weitere Informationen zu dieser Einschränkung finden Sie unter Lebensdauer von Dienstkontoschlüsseln begrenzen.

Wichtig: Wenn die Einschränkung constraints/iam.disableServiceAccountKeyCreation nicht vorhanden war, müssen Sie eng mit den Nutzern des Projekts, Ordners oder der Organisation zusammenarbeiten, um zu bestätigen, dass keine ihrer vorhandenen Ressourcen permanente Dienstkontoschlüssel erfordert. Wenn eine Ressource permanente Dienstkontoschlüssel erfordert und Sie eine Ablaufzeit festlegen, kommt es wahrscheinlich zu einem Ausfall.

So legen Sie eine Ablaufzeit fest:

1. Identifizieren Sie das Projekt, den Ordner oder die Organisation, für die Sie eine Ablaufzeit für Dienstkontoschlüssel festlegen möchten.
2. Fügen Sie eine Organisationsrichtlinie hinzu, die die Einschränkung constraints/iam.serviceAccountKeyExpiryHours erzwingt. Nachdem Sie diese Einschränkung für Ihr Projekt, Ihren Ordner oder Ihre Organisation erzwungen haben, gilt die Ablaufzeit für alle neu erstellten Dienstkontoschlüssel innerhalb dieser übergeordneten Ressource. Vorhandene Schlüssel sind nicht betroffen.

Ablaufzeiten werden in Stunden gemessen. Verwenden Sie als Best Practice kurze Ablaufzeiten wie 8 Stunden, 24 Stunden (1 Tag); oder 168 Stunden (7 Tage). Kurze Ablaufzeiten sorgen dafür, dass Ihr Team einen gut erprobten Prozess zum Aktualisieren von Schlüsseln hat. Beginnen Sie mit der kürzesten Ablaufzeit, die Ihren Anforderungen entspricht, und erhöhen Sie sie nur, wenn es unbedingt notwendig ist.