Best Practices zum Schutz vor kompromittierten OAuth-Tokens für die Google Cloud CLI

Last reviewed 2024-02-15 UTC

In diesem Dokument wird beschrieben, wie Sie die Auswirkungen eines Angreifers minimieren können, der die von der gcloud CLI verwendeten OAuth-Tokens manipuliert.

Ein Angreifer kann diese OAuth-Tokens gefährden, wenn er Zugriff auf einen Endpunkt erhält, auf dem ein legitimes Nutzerkonto oder Dienstkonto bereits bei der gcloud-Befehlszeile authentifiziert wurde. Der Angreifer kann diese Tokens dann an einen anderen von ihm kontrollierten Endpunkt kopieren, um Anfragen zu senden, die die legitime Identität imitieren. Auch wenn Sie den Zugriff des Angreifers auf den manipulierten Endpunkt entfernen, kann der Angreifer weiterhin authentifizierte API-Anfragen mit den kopierten Tokens stellen. Sie können den Zugriff auf Ihre Systeme steuern, indem Sie kurzlebige und kontextsensitive Anmeldedaten verwenden, um dieses Risiko zu verringern.

Dieses Dokument richtet sich an Sicherheitsteams oder Cloud-Architekten, die ihre Cloud-Ressourcen vor unberechtigtem Zugriff schützen. In diesem Dokument werden die verfügbaren Steuerelemente vorgestellt, mit denen Sie die Auswirkungen manipulierter OAuth-Tokens der gcloud-Befehlszeile proaktiv reduzieren und Ihre Umgebung korrigieren können, nachdem ein Endpunkt manipuliert wurde.

Übersicht

Um die Funktionsweise dieser Bedrohung zu verstehen, müssen Sie wissen, wie die gcloud CLI OAuth 2.0-Anmeldedaten speichert und wie diese Anmeldedaten missbraucht werden können, wenn sie von einem Angreifer manipuliert werden.

Von der gcloud CLI gespeicherte Anmeldedaten

Die gcloud-Befehlszeile verwendet OAuth 2.0-Zugriffstokens, um Anfragen für Google APIs zu authentifizieren. Der OAuth-Ablauf variiert je nach den verwendeten Anmeldedatentypen. Im Allgemeinen ist das Zugriffstoken und andere Anmeldedaten jedoch lokal zugänglich. In jedem Fall läuft das Zugriffstoken nach 60 Minuten ab, andere Anmeldedatentypen können jedoch persistent sein.

Wenn Sie die gcloud-Befehlszeile mit einem Nutzerkonto autorisieren, initiiert die gcloud-Befehlszeile einen dreibeinigen OAuth-Zustimmungsvorgang für den Zugriff auf Google Cloud APIs im Namen des Nutzers. Nachdem der Nutzer den Zustimmungsablauf abgeschlossen hat, erhält die gcloud-Befehlszeile ein Zugriffstoken und ein Aktualisierungstoken, mit denen sie neue Zugriffstokens anfordern kann. In den Standardeinstellungen bleibt das langlebige Aktualisierungstoken erhalten, bis seine Ablaufbedingungen erfüllt sind.

Wenn Sie die gcloud-Kommandozeile mit einem Dienstkonto autorisieren, initiiert die gcloud-Kommandozeile einen zweibeinigen OAuth-Ablauf, um als Dienstkontoidentität auf Google Cloud APIs zuzugreifen. Nachdem Sie ein Dienstkonto aus einer privaten Schlüsseldatei aktiviert haben, wird dieser Schlüssel verwendet, um regelmäßig ein Zugriffstoken anzufordern. Der langlebige private Schlüssel wird in der Konfiguration der gcloud-Kommandozeile gespeichert und bleibt gültig, bis Sie den Dienstkontoschlüssel löschen.

Wenn Sie die gcloud-Befehlszeile in einer Google Cloud-Umgebung wie Compute Engine oder Cloud Shell ausführen, kann die Anwendung automatisch Anmeldedaten finden und als Dienstkonto authentifizieren. In Compute Engine kann eine Anwendung wie die gcloud-Befehlszeile beispielsweise den Metadatenserver nach einem Zugriffstoken abfragen. Google verwaltet und rotiert den privaten Signaturschlüssel, der zum Erstellen des Zugriffstokens verwendet wird. Die langlebigen Anmeldedaten werden der Anwendung nicht zur Verfügung gestellt.

Wenn Sie sich mit Föderation von Workload Identity authentifizieren, authentifizieren sich Anwendungen auf der Grundlage von Anmeldedaten eines externen Identitätsanbieters und erhalten ein föderiertes, kurzlebiges Zugriffstoken. Weitere Informationen zum Speichern und Verwalten der langlebigen Anmeldedaten des externen Identitätsanbieters finden Sie unter Best Practices für die Verwendung der Workload Identity-Föderation.

Wie ein Angreifer manipulierte OAuth-Tokens verwenden kann

Wenn es einem Angreifer gelingt, einen Endpunkt zu manipulieren, sind Anmeldedaten wie OAuth-Tokens wertvolle Ziele, da sie es Angreifern ermöglichen, ihren Zugriff aufrechtzuerhalten oder zu eskalieren.

Ein Entwickler kann möglicherweise beim Schreiben und Debuggen von Code die eigenen Anmeldedaten aufrufen. Beispielsweise muss sich ein Entwickler möglicherweise für die Verwendung von REST-Anfragen an Google Cloud-Dienste authentifizieren, wenn er mit einer nicht unterstützten Clientbibliothek arbeitet. Der Entwickler kann die Anmeldedaten auf verschiedene Arten aufrufen. Dazu gehören:

Ein Angreifer könnte jedoch dieselben Techniken verwenden, nachdem er einen Endpunkt manipuliert hat.

Wenn ein Angreifer einen Endpunkt wie eine Entwickler-Workstation manipuliert, besteht die primäre Bedrohung darin, dass der Angreifer gcloud CLI-Befehle oder anderen Code mit den entsprechenden Anmeldedaten der authentifizierten Identität ausführen kann. Darüber hinaus könnte der Angreifer die OAuth-Tokens auf einen anderen Endpunkt kopieren, den er steuert, um seinen Zugriff aufrechtzuerhalten. Der Diebstahl von Anmeldedaten birgt die Gefahr, dass der Angreifer die langlebigen OAuth-Tokens auch dann noch verwenden kann, wenn Sie den Zugriff auf den manipulierten Endpunkt entfernen.

Wenn es dem Angreifer gelingt, OAuth-Token zu manipulieren, kann er die folgenden Aktionen durchführen:

  • Ein Angreifer kann die Identität des manipulierten Nutzers oder Dienstkontos übernehmen. API-Traffic, der die manipulierten Tokens verwendet, wird so erfasst, als ob er vom manipulierten Nutzer oder Dienstkonto stammt. Dadurch wird es schwierig, normale und schädliche Aktivitäten in Logs zu unterscheiden.
  • Ein Angreifer kann das Zugriffstoken auf unbestimmte Zeit aktualisieren, indem er ein nichtflüchtiges Aktualisierungstoken verwendet, das mit einem Nutzer oder einem privaten Schlüssel verbunden ist, der zu einem Dienstkonto gehört.
  • Ein Angreifer kann die Authentifizierung mit dem Nutzerpasswort oder der Bestätigung in zwei Schritten umgehen, da die Tokens nach dem Anmeldevorgang gewährt werden.

Best Practices zur Risikominimierung

Implementieren Sie die in den folgenden Abschnitten beschriebenen Steuerelemente, um das Risiko einer Manipulation von gcloud CLI-Tokens zu verringern. Wenn Sie die Best Practices für die Sicherheit befolgen, die im Unternehmensgrundlagen-Blueprint oder im Design der Landing-Zone in der Google Cloud beschrieben werden, sind diese Steuerelemente möglicherweise bereits vorhanden.

Sitzungsdauer für Google Cloud-Dienste festlegen

Legen Sie die Sitzungslänge für Google Cloud-Dienste fest, um zu reduzieren, wie lange ein Angreifer ein manipuliertes Token ausnutzen kann. Das Aktualisierungstoken, das das System nach der Authentifizierung gewährt, ist standardmäßig ein langlebiger Anmeldedaten und eine gcloud-Kommandozeilensitzung erfordert keine erneute Authentifizierung. Ändern Sie diese Einstellung, um eine Richtlinie für die erneute Authentifizierung mit einer Sitzungslänge zwischen 1 und 24 Stunden zu konfigurieren. Nach der definierten Sitzungsdauer wird die Aktualisierungsrichtlinie von der Richtlinie zur erneuten Authentifizierung ungültig und der Nutzer wird gezwungen, die gcloud-Befehlszeile mit ihrem Passwort oder Sicherheitsschlüssel regelmäßig neu zu authentifizieren.

Die Sitzungslänge für Google Cloud-Dienste unterscheidet sich von der Sitzungsdauer für Google-Dienste, die Websitzungen für die Anmeldung in Google Workspace-Diensten steuert, aber hat keine Kontrolle über die erneute Authentifizierung für die Google Cloud. Wenn Sie Google Workspace-Dienste verwenden, legen Sie die Sitzungsdauer für beide fest.

VPC Service Controls konfigurieren

Konfigurieren Sie VPC Service Controls in Ihrer Umgebung, um sicherzustellen, dass nur Google Cloud API-Traffic, der aus Ihrem definierten Perimeter stammt, Zugriff auf unterstützte Ressourcen hat. Der Dienstperimeter schränkt den Nutzen kompromittierter Anmeldedaten ein, da der Perimeter Anfragen an eingeschränkte Dienste blockiert, die von Endpunkten stammen, die von Angreifern kontrolliert werden und sich außerhalb Ihrer Umgebung befinden.

Chrome Enterprise Premium konfigurieren

Konfigurieren Sie Chrome Enterprise Premium-Richtlinien, um die Google Cloud Console und Google Cloud APIs zu schützen. Konfigurieren Sie eine Chrome Enterprise Premium-Zugriffsebene und ‑Bindung, um Attribute selektiv zuzulassen, die bei jeder API-Anfrage ausgewertet werden, einschließlich IP-basierten Zugriffs oder Zertifikatbasierten Zugriffs für gegenseitige TLS-Verschlüsselung. Anfragen, die manipulierte Anmeldedaten für die Autorisierung verwenden, aber nicht die in Ihrer Chrome Enterprise Premium-Richtlinie definierten Bedingungen erfüllen, werden abgelehnt.

Chrome Enterprise Premium ist eine nutzerorientierte Steuerung, die Nutzer-API-Traffic ablehnt, der keine definierten Bedingungen erfüllt. VPC Service Controls ist eine ressourcenorientierte Steuerung, mit der die Perimeter definiert werden, zwischen denen Ressourcen kommunizieren können. Hinweis: VPC Service Controls gilt für alle Nutzeridentitäten und Dienstkontoidentitäten. Chrome Enterprise Premium gilt jedoch nur für Nutzeridentitäten in Ihrer Organisation. Wenn sie zusammen verwendet werden, reduzieren Chrome Enterprise Premium und VPC Service Controls die Effektivität von manipulierten Anmeldedaten auf einem vom Angreifer kontrollierten Computer außerhalb Ihrer Umgebung.

Bestätigung in zwei Schritten für Remote-Serverzugriff erzwingen

Wenn Sie Entwicklern den Zugriff auf Compute Engine-Ressourcen über SSH gewähren, konfigurieren Sie OS Login mit Bestätigung in zwei Schritten. Dadurch wird ein zusätzlicher Prüfpunkt erzwungen, bei dem sich ein Nutzer mit seinem Passwort oder Sicherheitsschlüssel neu authentifizieren muss. Ein Angreifer, der manipulierte OAuth-Tokens, aber kein Passwort oder Sicherheitsschlüssel verwendet, wird durch diese Funktion blockiert.

Der Remote Desktop Protocol (RDP)-Zugriff auf Windows-Instanzen in Compute Engine unterstützt den OS Login-Dienst nicht, sodass die Bestätigung in zwei Schritten nicht differenziert für RDP-Sitzungen erzwungen werden kann. Wenn Sie IAP Desktop oder Google Chrome-basierte RDP-Plug-ins verwenden, legen Sie grobe Steuerelemente wie die Sitzungslänge für Google-Dienste fest. Einstellungen für die Bestätigung in zwei Schritten für die Websitzungen des Nutzers und deaktivieren Sie die Einstellung Nutzer dürfen dem Gerät vertrauen unter "Bestätigung in zwei Schritten".

Verwendung von Dienstkontoschlüsseln einschränken

Wenn Sie einen Dienstkontoschlüssel zur Authentifizierung verwenden, wird der Schlüsselwert getrennt von der heruntergeladenen Schlüsseldatei in den Konfigurationsdateien der gcloud CLI gespeichert. Ein Angreifer, der Zugriff auf Ihre Umgebung hat, kann den Schlüssel aus der Konfiguration der gcloud CLI kopieren oder die Schlüsseldatei aus Ihrem lokalen Dateisystem oder internen Code-Repository kopieren. Überlegen Sie daher nicht nur, wie Sie manipulierte Zugriffstokens schützen, sondern auch, wie Sie heruntergeladene Schlüsseldateien für Dienstkonten verwalten.

Prüfen Sie sichere Alternativen für die Authentifizierung, um Ihre Anwendungsfälle, die von einem Dienstkontoschlüssel abhängen, zu reduzieren oder zu beseitigen und die Einschränkung der Organisationsrichtlinie iam.disableServiceAccountKeyCreation zu erzwingen, um das Erstellen von Dienstkontoschlüsseln zu deaktivieren.

Prinzip der geringsten Berechtigung erwägen

Berücksichtigen Sie beim Entwerfen von IAM-Richtlinien die geringste Berechtigung. Gewähren Sie Nutzern die Rollen, die sie zum Ausführen einer Aufgabe im kleinstmöglichen Bereich benötigen. Weisen Sie ihnen keine Rollen zu, die sie nicht benötigen. Prüfen und wenden Sie Rollenempfehlungen an, um IAM-Richtlinien mit nicht verwendeten und übermäßigen Rollen in Ihrer Umgebung zu vermeiden.

Endpunkte schützen

Überlegen Sie, wie ein Angreifer physischen Zugriff oder Remote-Zugriff auf Ihre Endpunkte wie Entwickler-Workstations oder Compute Engine-Instanzen erhalten kann. Ein Plan zur Abwehr von manipulierten OAuth-Tokens ist zwar wichtig, sollten aber auch bedenken, wie auf die Bedrohung reagiert werden muss, wie ein Angreifer Ihre vertrauenswürdigen Endpunkte überhaupt manipulieren kann. Wenn ein Angreifer Zugriff auf Ihre vertrauenswürdigen Endpunkte hat, kann er gcloud-Befehle oder anderen Code direkt auf dem Endpunkt selbst ausführen.

Obwohl ein umfassender Schutz für Entwickler-Workstations den Rahmen dieses Dokuments sprengen würde, sollten Sie prüfen, wie Ihre Sicherheitstools und -abläufe dazu beitragen können, Ihre Endpunkte zu schützen und auf Kompromisse zu überwachen. Berücksichtigen Sie dabei folgende Fragen:

  • Wie wird die physische Sicherheit von Entwickler-Workstations geschützt?
  • Wie können Sie Schwachstellen im Netzwerk erkennen und darauf reagieren?
  • Wie erhalten Nutzer Remote-Zugriff auf SSH- oder RDP-Sitzungen?
  • Wie können andere nichtflüchtige Anmeldedaten wie SSH-Schlüssel oder Dienstkontoschlüssel manipuliert werden?
  • Gibt es Workflows, die nichtflüchtige Anmeldedaten verwenden, die durch kurzlebige Anmeldedaten ersetzt werden können?
  • Gibt es gemeinsam verwendete Geräte, auf denen jemand die zwischengespeicherten Anmeldedaten eines anderen Nutzers auslesen könnte?
  • Kann sich ein Nutzer mit gcloud CLI von einem nicht vertrauenswürdigen Gerät authentifizieren?
  • Wie stellt genehmigter Traffic eine Verbindung zu Ressourcen in Ihrem VPC Service Control-Perimeter her?

Achten Sie darauf, dass Ihre Sicherheitsvorgänge auf jede dieser Fragen eingehen.

Antwortteams aufeinander abstimmen

Stellen Sie im Voraus sicher, dass die Sicherheitsteams, die für die Reaktion auf Vorfälle zuständig sind, über entsprechenden Zugriff auf die Google Cloud Console und die Admin-Konsole verfügen. Wenn separate Teams die Google Cloud Console und die Admin-Konsole verwalten, kann es bei einem Vorfall zu Verzögerungen kommen.

Zum Entfernen des Zugriffs aus einem manipulierten Nutzerkonto benötigt Ihr Team für die Reaktion auf Vorfälle eine Admin-Konsole-Rolle, z. B. Nutzerverwaltungs-Administrator. Um zu beurteilen, ob in Ihren Google Cloud-Ressourcen verdächtige Aktivitäten aufgetreten sind, benötigt dieses Team möglicherweise auch IAM-Rollen wie Sicherheitsprüfer für alle Projekte oder Loganzeige an einer zentralen Logsenke. Die erforderlichen Rollen für Ihr Sicherheitsteam variieren je nach Design und Betrieb Ihrer Umgebung.

Best Practices zur Abhilfe nach einem Sicherheitsvorfall

Legen Sie im Rahmen Ihres Plans zum Vorfallmanagement fest, wie Sie auf die primäre Bedrohung durch einen manipulierten Endpunkt reagieren und wie Sie den potenziellen Schaden, der durch die sekundäre Bedrohung durch manipulierte Token entsteht, begrenzen können. Wenn ein Angreifer dauerhaft Zugriff auf die Entwickler-Workstation hat, kann er nach der erneuten Authentifizierung des legitimen Nutzers möglicherweise noch einmal Tokens kopieren. Wenn Sie den Verdacht haben, dass gcloud CLI-Tokens manipuliert wurden, erstellen Sie ein Ticket bei Cloud Customer Care und befolgen Sie die Empfehlungen in den folgenden Abschnitten. Durch diese Aktionen können Sie die Auswirkungen eines solchen Ereignisses in Ihrer Google Cloud-Organisation begrenzen.

Die Empfehlungen in diesem Abschnitt überschneiden sich mit den allgemeinen Leitlinien zum Umgang mit manipulierten Google Cloud-Anmeldedaten, aber konzentrieren sich speziell auf die Bedrohung von gcloud CLI-Token, die von einem manipulierten Endpunkt kopiert werden.

Mit der Google Cloud-Sitzungssteuerung aktive Tokens für alle Nutzerkonten ablaufen lassen

Wenn Sie die Google Cloud-Sitzungssteuerung noch nicht erzwungen haben, aktivieren Sie dies sofort mit einer kurzen erneuten Authentifizierungshäufigkeit. Mit dieser Steuerung können Sie sicherstellen, dass alle Aktualisierungstoken am Ende der von Ihnen festgelegten Dauer ablaufen. Dadurch wird die Dauer begrenzt, die ein Angreifer die manipulierten Token verwenden kann.

Tokens für manipulierte Nutzerkonten manuell ungültig machen

Lesen Sie die Anleitung zum Umgang mit manipulierten Anmeldedaten für alle Nutzeridentitäten, die möglicherweise manipuliert wurden. Insbesondere ist das Entfernen von gcloud-Anmeldedaten die effektivste Methode für ein Sicherheitsteam, um manipulierte OAuth-Tokens für Nutzeridentitäten zu beheben. Wenn Sie Aktualisierungstokens und Zugriffstokens für die gcloud-Befehlszeile sofort entwerten und den Nutzer dazu auffordern möchten, sich mit seinem Passwort oder Sicherheitsschlüssel neu zu authentifizieren, entfernen Sie die gcloud-Befehlszeile aus der Liste der verbundenen Anwendungen eines Nutzers.

Ein einzelner Nutzer kann auch gcloud CLI-Anmeldedaten für sein eigenes Konto entfernen.

Andere Methoden wie das Sperren des Nutzers, das Zurücksetzen des Passworts des Nutzers oder das Zurücksetzen von Anmeldecookies richten sich nicht speziell auf das Risiko manipulierter OAuth-Tokens. Diese Methoden sind im Allgemeinen nützlich für die Reaktion auf Vorfälle, machen aber die Zugriffstokens, die der Angreifer bereits steuert, nicht ungültig. Wenn Sie beispielsweise festlegen, dass ein Nutzer während einer Untersuchung gesperrt wird, aber keine gcloud CLI-Tokens widerrufen, sind die Zugriffstokens möglicherweise noch gültig, wenn der gesperrte Nutzer wiederhergestellt wird, bevor die Zugriffstokens ablaufen.

Tokens für viele Nutzerkonten programmatisch ungültig machen

Wenn Sie einen Sicherheitsverstoß vermuten, aber nicht feststellen können, welche Nutzer betroffen waren, sollten Sie in Erwägung ziehen, aktive Sitzungen für alle Nutzer in Ihrer Organisation schneller zu widerrufen, als es die Re-Authentifizierungsrichtlinie erlaubt.

Dieser Ansatz kann legitime Nutzer beeinträchtigen und lang andauernde Prozesse beenden, die von Nutzeranmeldedaten abhängen. Wenn Sie sich für diesen Ansatz entscheiden, bereiten Sie eine skriptbasierte Lösung für Ihr Security Operations Center (SOC) vor, die im Voraus ausgeführt wird, und testen Sie sie mit einigen Nutzern.

Im folgenden Beispielcode wird das Workspace Admin SDK verwendet, um alle Nutzeridentitäten in Ihrem Google Workspace- oder Cloud Identity-Konto zu identifizieren, die Zugriff auf die gcloud-Befehlszeile haben. Wenn ein Nutzer die gcloud CLI autorisiert hat, widerruft das Script das Aktualisierungstoken und das Zugriffstoken und zwingt ihn, sich mit seinem Passwort oder Sicherheitsschlüssel neu zu authentifizieren. Eine Anleitung zum Aktivieren der Admin SDK API und zum Ausführen dieses Codes finden Sie in der Kurzanleitung für Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Anmeldedaten für Dienstkonten ungültig machen und rotieren

Im Gegensatz zu Zugriffstokens, die Nutzeridentitäten zugewiesen werden, können Zugriffstokens, die Dienstkonten zugewiesen werden, nicht über die Admin-Konsole oder Befehle wie gcloud auth revoke ungültig gemacht werden. Außerdem gilt die Sitzungsdauer, die Sie in der Google Cloud-Sitzungssteuerung festlegen, für Nutzerkonten in Ihrem Cloud Identity- oder Google Workspace-Verzeichnis, aber nicht für Dienstkonten. Daher muss Ihre Reaktion auf einen Vorfall bei manipulierten Dienstkonten sowohl die nichtflüchtigen Schlüsseldateien als auch die kurzlebigen Zugriffstokens berücksichtigen.

Wenn Sie vermuten, dass die Anmeldedaten für ein Dienstkonto manipuliert wurden, deaktivieren Sie das Dienstkonto, löschen Sie gegebenenfalls Dienstkontoschlüssel, falls vorhanden, und aktivieren Sie anschließend nach 60 Minuten das Dienstkonto. Durch das Löschen eines Dienstkontoschlüssels können die langlebigen Anmeldedaten ungültig werden, sodass ein Angreifer kein neues Zugriffstoken anfordern kann. Die bereits gewährten Zugriffstokens werden jedoch nicht ungültig. Um sicherzustellen, dass Zugriffstokens nicht innerhalb ihrer 60-minütigen Lebensdauer missbraucht werden, müssen Sie das Dienstkonto 60 Minuten lang deaktivieren.

Alternativ können Sie das Dienstkonto löschen und ersetzen, um alle kurz- und langlebigen Anmeldedaten sofort zu widerrufen. Dies erfordert jedoch unter Umständen einen größeren Aufwand, um das Dienstkonto in den Anwendungen zu ersetzen.

Nächste Schritte