Auf kompromittierte Google Cloud-Anmeldedaten reagieren

Wenn Sie vermuten, dass Ihre Anmeldedaten gehackt wurden, müssen Sie sofort Maßnahmen ergreifen, um die Auswirkungen des Hackings auf IhrGoogle Cloud -Konto zu begrenzen.

Google Cloud -Anmeldedaten steuern den Zugriff auf Ihre Ressourcen, die auf Google Cloudgehostet werden. Google Cloud umfasst sowohl langlebige als auch kurzlebige Anmeldedaten. Damit Ihre Daten sicher und vor Angreifern geschützt sind, müssen Sie die Anmeldedaten mit größter Sorgfalt behandeln und schnell auf mutmaßliche Sicherheitslücken reagieren.

Google Cloud Anmeldedaten

In der folgenden Tabelle werden häufig verwendete Google Cloud Anmeldedaten beschrieben.

Anmeldedaten Beschreibung
Private Schlüssel für Dienstkonten (JSON- und p12-Dateien)

Typ:Langlebige Dienstanmeldedaten

Typische Standorte:

  • Entwicklerworkstations
  • Anwendungsserverumgebungen
  • Quellcode-Repositories
  • Systeme zur Verwaltung von Secrets

Abhilfemaßnahmen:Dienstkontoschlüssel und ‑tokens
Dienstkontotokens (OAuth 2.0-Zugriffstokens)

Typ:Kurzlebige Anmeldedaten

Typische Standorte:

  • Arbeitsspeicher der Anwendungs-Laufzeit
  • Produktionsarbeitslasten (dynamisch von Instanzmetadatenservern abgerufen)
  • Entwicklerarbeitsplätze oder CI/CD-Pipelines

Abhilfemaßnahmen:Dienstkontoschlüssel und ‑tokens
API-Schlüssel

Typ:Langlebige Dienstanmeldedaten

Typische Standorte:

  • Frontend-Quellcode
  • Backend-Konfigurationsdateien
  • Systeme zur Verwaltung von Secrets oder Umgebungsvariablen

Abhilfe:API-Schlüssel
OAuth 2.0-Client-ID-Schlüssel

Typ:Langlebige Dienstanmeldedaten

Typische Standorte:

  • Konfigurationsdateien für das Webserver-Backend
  • Systeme zur Verwaltung von Secrets

Abhilfemaßnahmen:OAuth 2.0-Client-ID-Schlüssel
Anmeldedaten für die Google Cloud CLI

Typ:Langlebige Nutzeranmeldedaten

Typischer Speicherort:Basisverzeichnis des Nutzers. Führen Sie den Befehl gcloud auth list aus, um aktive Anmeldedaten aufzulisten.

Abhilfemaßnahmen:Nutzeranmeldedaten und Google Cloud CLI-OAuth-Tokens
OAuth-Zugriffstokens für die Google Cloud CLI

Typ:Kurzlebige Anmeldedaten

Typischer Standort:Entwicklerarbeitsplätze

Abhilfemaßnahmen:Nutzeranmeldedaten und gcloud CLI-OAuth-Tokens
Standardanmeldedaten für Anwendungen

Typ:Langlebige Nutzeranmeldedaten

Typischer Standort:Entwicklerarbeitsplätze

Abhilfe:Standardanmeldedaten für Anwendungen
Browser-Cookies

Typ:Langlebige Nutzeranmeldedaten

Typischer Speicherort:Browserspezifisch, werden aber in der Regel auf Entwicklerworkstations gespeichert

Abhilfe:Browser-Cookies
Föderierte Zugriffstokens des Security Token Service für die Identitätsföderation von Arbeitslasten

Typ:Kurzlebige Anmeldedaten

Typische Standorte:

  • Laufzeitumgebungen für externe Arbeitslasten
  • CI/CD-Bereitstellungspipelines

Abhilfe:Föderierte Zugriffstokens für Security Token Service
Föderierte Zugriffstokens des Security Token Service für die Workforce Identity-Föderation

Typ:Kurzlebige Anmeldedaten

Typische Standorte:

  • Entwicklerworkstations
  • Clientanwendungen und ‑scripts von Drittanbietern

Abhilfe:Föderierte Zugriffstokens für Security Token Service

Google Cloud -Ressourcen vor gehackten Anmeldedaten schützen

Wenn Sie den Verdacht haben, dass Anmeldedaten gehackt wurden, widerrufen Sie sie und geben Sie sie noch einmal aus. Gehen Sie sorgfältig vor, damit es zu keinem Dienstausfall kommt, wenn Sie Anmeldedaten widerrufen.

Im Allgemeinen generieren Sie zur erneuten Ausgabe von Anmeldedaten neue Anmeldedaten, stellen diese für alle Dienste und Nutzer bereit, die sie benötigen, und widerrufen dann die alten Anmeldedaten.

Die folgenden Abschnitte enthalten spezifische Anleitungen für die einzelnen Arten von Anmeldedaten.

Dienstkontoschlüssel und ‑tokens

Führen Sie die folgenden Schritte aus, um einen kompromittierten Dienstkontoschlüssel zu ersetzen und kompromittierte kurzlebige Dienstkontotokens zu blockieren.

Kurzlebige Dienstkonto-Tokens sind unabhängig von den Anmeldedaten oder Berechtigungen, die zum Generieren verwendet wurden, und können nicht widerrufen werden. Dienstkonto-Zugriffstokens sind Bearertokens und bleiben bis zu ihrem Ablaufdatum gültig (standardmäßig bis zu 60 Minuten oder bis zu 12 Stunden, wenn eine Richtlinie für die verlängerte Lebensdauer von Tokens konfiguriert ist).

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.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Reagieren auf kompromittierte Dienstkontoschlüssel und ‑tokens benötigen:

  • Dienstkontoschlüssel verwalten: Service Account Key Admin (roles/iam.serviceAccountKeyAdmin) für das Projekt, das das Dienstkonto enthält
  • Dienstkonten deaktivieren, aktivieren oder löschen: Service Account Admin (roles/iam.serviceAccountAdmin) für das Projekt, das das Dienstkonto enthält
  • Ablehnungsrichtlinien anwenden, um aktive Tokens zu blockieren: Ablehnungs-Administrator (roles/iam.denyAdmin) für die Organisation
  • Rollen für die Identitätsübernahme widerrufen: Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin), Dienstkontoadministrator (roles/iam.serviceAccountAdmin) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Reagieren auf kompromittierte Dienstkontoschlüssel und ‑tokens erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um auf manipulierte Dienstkontoschlüssel und ‑tokens zu reagieren:

  • Dienstkontoschlüssel verwalten:
    • iam.serviceAccountKeys.create für das Projekt, das das Dienstkonto enthält
    • iam.serviceAccountKeys.delete für das Projekt, das das Dienstkonto enthält
    • iam.serviceAccountKeys.list für das Projekt, das das Dienstkonto enthält
  • Dienstkonten deaktivieren, aktivieren oder löschen:
    • iam.serviceAccounts.disable für das Projekt, das das Dienstkonto enthält
    • iam.serviceAccounts.enable für das Projekt, das das Dienstkonto enthält
    • iam.serviceAccounts.delete für das Projekt, das das Dienstkonto enthält
  • Ablehnungsrichtlinien anwenden, um aktive Tokens zu blockieren: iam.denypolicies.create für die Organisation
  • Identitätswechselrollen entziehen:
    • resourcemanager.projects.setIamPolicy für das Projekt
    • iam.serviceAccounts.setIamPolicy für das Projekt, das das Dienstkonto enthält

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Auf manipulierte Dienstkontoschlüssel und ‑tokens reagieren

  1. So sperren Sie ein manipuliertes Dienstkonto-Token:

    • Deaktivieren Sie das Dienstkonto, das die Anmeldedaten darstellt.

    • Wenden Sie eine IAM-Ablehnungsrichtlinie für den Dienstkontoprincipal (principal://iam.googleapis.com/projects/-/serviceAccounts/SA_EMAIL_ADDRESS) in Ihren Projekten oder Ordnern an. Die IAM-Ablehnungsrichtlinie verweigert den Zugriff auf vertrauliche APIs und Berechtigungen für aktive Tokens und Arbeitslasten, damit Sie den Vorfall untersuchen können, ohne das Dienstkonto zu löschen.

    • Löschen Sie das Dienstkonto.

    Wenn Sie das Dienstkonto deaktivieren oder löschen, verliert jede Arbeitslast, die das Dienstkonto verwendet, sofort den Zugriff auf Ihre Ressourcen.

  2. So ersetzen Sie einen kompromittierten Dienstkontoschlüssel:

    1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

      Zur Seite „Dienstkonten“

    2. Suchen Sie nach dem betroffenen Dienstkonto.

    3. Erstellen Sie bei Bedarf einen neuen Schlüssel für das Dienstkonto und stellen Sie den neuen Schlüssel an allen Stellen bereit, an denen der alte Schlüssel verwendet wurde.

    4. Deaktivieren Sie den alten Schlüssel, um zu prüfen, ob der neue Schlüssel wie erwartet funktioniert.

    5. Löschen Sie den alten Schlüssel.

    Weitere Informationen finden Sie unter Dienstkontoschlüssel erstellen und löschen.

  3. Wenn unautorisierte Hauptkonten möglicherweise die Berechtigung zum Generieren von Tokens haben, widerrufen Sie die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator). Eine Anleitung finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

  4. Warten Sie nach der Behebung des Vorfalls mindestens 60 Minuten nach dem Deaktivieren des Dienstkontos, damit das manipulierte Token ablaufen kann. Wenn Sie eine Richtlinie mit verlängerter Lebensdauer mit constraints/iam.allowServiceAccountCredentialLifetimeExtension festlegen, warten Sie die in der Einschränkung angegebene Zeit, bevor Sie das Dienstkonto wieder aktivieren.

  5. Nach Ablauf der erforderlichen Wartezeit aktivieren Sie das Dienstkonto wieder und setzen Sie die „deny“-Richtlinie zurück.

Nutzeranmeldedaten und gcloud CLI-OAuth-Tokens

Legen Sie fest, wie Sie auf die primäre Bedrohung durch einen manipulierten Endpunkt und die sekundäre Bedrohung durch manipulierte Tokens reagieren. 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.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden Google Workspace-Administratorrollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Widerrufen des Nutzerzugriffs und zum Ungültigmachen von OAuth-Tokens der gcloud CLI in der Google Workspace Admin-Konsole benötigen:

Weitere Informationen zum Zuweisen von Administratorrollen in Google Workspace finden Sie unter Administratorrollen in der Google Admin-Konsole zuweisen.

gcloud CLI-Tokens für bestimmte Nutzerkonten ungültig machen

Führen Sie die folgenden Schritte aus, um den Zugriff eines Nutzers auf die gcloud CLI zu entfernen und alle kompromittierten Tokens ungültig zu machen:

  1. Führen Sie einen der folgenden Schritte aus, um den Zugriff eines Nutzers auf die Google Cloud CLI zu entfernen:

    Wenn der Nutzer noch einmal auf die Google Cloud CLI zugreift, wird er aufgefordert, die Anwendung neu zu autorisieren.

  2. Wenn Sie eine bestimmte kompromittierte Token-String extrahiert oder abgefangen haben (entweder ein Aktualisierungstoken oder ein Zugriffstoken), können Sie sie direkt über den Google OAuth 2.0-Widerrufsendpunkt ungültig machen:

    curl -d "token=TOKEN_STRING" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -X POST "https://oauth2.googleapis.com/revoke"

    Wenn Sie diesen Befehl ausführen, um ein Aktualisierungstoken zu widerrufen, werden sowohl das Aktualisierungstoken als auch alle zugehörigen Zugriffstokens widerrufen. Wenn Sie diesen Befehl ausführen, um ein Zugriffstoken zu widerrufen, wird auch das zugehörige Aktualisierungstoken ungültig.

  3. Wenn Sie die Google Cloud -Sitzungssteuerung noch nicht erzwungen haben, aktivieren Sie diese sofort mit einer kurzen Re-Authentifizierungsfrequenz. 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.

gcloud CLI-Tokens für viele Nutzerkonten 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 Google Workspace Admin SDK verwendet, um alle Nutzeridentitäten in Ihrem Google Workspace- oder Cloud Identity-Konto zu identifizieren, die Zugriff auf die gcloud CLI haben. Wenn ein Nutzer die gcloud CLI autorisiert hat, widerruft das Script das Aktualisierungstoken und das Zugriffstoken und zwingt den Nutzer, 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)
      }
    }
  }
}

Standardanmeldedaten für Anwendungen

Wenn Sie den Verdacht haben, dass Standardanmeldedaten für Anwendungen gehackt wurden, können Sie sie widerrufen. Diese Vorgehensweise kann zu einem vorübergehenden Ausfall führen, bis die Datei mit den Anmeldedaten neu erstellt wurde.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die Rolle Sicherheitsadministrator oder Super Admin zuzuweisen, damit Sie die Berechtigungen erhalten, die Sie zum Entfernen des Zugriffs verbundener Anwendungen in der Google Workspace Admin-Konsole benötigen.

Für lokale Befehle, die auf Entwicklerarbeitsplätzen ausgeführt werden, sind keine Administratorrollen erforderlich. Weitere Informationen zum Zuweisen von Administratorrollen in Google Workspace finden Sie unter Administratorrollen in der Google Admin-Konsole zuweisen.

Standardanmeldedaten für Anwendungen widerrufen

Führen Sie einen dieser Schritte aus:

  • Als Google Workspace-Administrator entfernen Sie den Zugriff auf die Google-Authentifizierungsbibliothek aus der Liste der verbundenen Anwendungen des Nutzers. Weitere Informationen finden Sie unter Zugriff auf Anwendungen von Drittanbietern ansehen und entfernen.

  • Bitten Sie den Inhaber der kompromittierten Anmeldedaten, Folgendes auszuführen:

    1. Installieren und initialisieren Sie die gcloud CLI, falls noch nicht geschehen.

    2. Widerrufen Sie die Anmeldedaten:

      gcloud auth application-default revoke

    3. Wenn Sie die gcloud CLI nicht ausführen können, gehen Sie so vor:

      1. Sie können den Zugriff auf die Google Auth Library über myaccount.google.com/permissions oder den OAuth 2.0-Widerrufs-Endpunkt widerrufen.

      2. Löschen Sie die Datei application_default_credentials.json manuell:

        • Linux, macOS: $HOME/.config/gcloud/application_default_credentials.json
        • Windows: %APPDATA%\gcloud\application_default_credentials.json

    4. Erstellen Sie die Datei mit den Anmeldedaten mit Ihrer Nutzeridentität neu:

      gcloud auth application-default login

API-Schlüssel

So generieren Sie einen kompromittierten API-Schlüssel neu:

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle API-Schlüssel-Administrator (roles/serviceusage.apiKeysAdmin) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von API-Schlüsseln benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Verwalten von API-Schlüsseln erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um API-Schlüssel zu verwalten:

  • apikeys.keys.create
  • apikeys.keys.delete
  • apikeys.keys.update
  • apikeys.keys.getKeyString
  • apikeys.keys.list
  • apikeys.keys.get

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

API-Schlüssel neu generieren

  1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf.

    Zu den Anmeldedaten

  2. Klicken Sie auf den Namen des API-Schlüssels, den Sie rotieren möchten.

  3. Klicken Sie auf Schlüssel rotieren.

  4. Geben Sie einen Namen ein und bestätigen Sie die Einschränkungen.

  5. Klicken Sie auf Erstellen.

  6. Aktualisieren Sie Ihre Anwendungen, damit sie den neuen API-Schlüssel verwenden.

  7. Klicken Sie unter Vorheriger Schlüssel auf Vorherigen Schlüssel löschen.

Weitere Informationen finden Sie unter API-Schlüssel rotieren.

OAuth 2.0-Client-ID-Schlüssel

Das Ändern eines Client-ID-Secrets führt zu einem temporären Ausfall, während das Secret rotiert wird.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle OAuth Config Editor (roles/oauthconfig.editor) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Zurücksetzen von OAuth 2.0-Client-ID-Secrets benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen, die zum Zurücksetzen von OAuth 2.0-Client-ID-Secrets erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um OAuth 2.0-Client-ID-Secrets zurückzusetzen:

  • clientauthconfig.clients.createSecret
  • clientauthconfig.clients.getWithSecret
  • clientauthconfig.clients.update
  • clientauthconfig.clients.get

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

OAuth 2.0-Client-ID-Secret zurücksetzen

  1. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten auf.

    Zu den Anmeldedaten

  2. Wählen Sie die gehackte OAuth 2.0-Client-ID aus und bearbeiten Sie sie.

  3. Klicken Sie auf Secret zurücksetzen.

  4. Stellen Sie das neue Secret für Ihre Anwendung bereit.

Weitere Informationen finden Sie unter OAuth 2.0 einrichten und OAuth 2.0 für den Zugriff auf Google APIs verwenden.

Föderierte Zugriffstokens für Security Token Service

Wenn externe Identitätssitzungen manipuliert werden, müssen Sie neue Tokenaustausche beenden und aktive föderierte Zugriffstokens widerrufen. Diese Aufgabe gilt für Zugriffstokens, die von der Workload Identity-Föderation oder der Workforce Identity-Föderation ausgestellt werden.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten der Workload Identity-Föderation und der Mitarbeiteridentitätsföderation zum Blockieren von föderierten Tokens benötigen:

  • Workload Identity-Pools und -Anbieter verwalten: Workload Identity-Pool-Administrator (roles/iam.workloadIdentityPoolAdmin) für das Projekt, das den Workload Identity-Pool enthält
  • Workforce Identity-Pools und -Anbieter verwalten: Workforce Pool Admin (roles/iam.workforcePoolAdmin) für die Organisation, die den Workforce Identity-Pool enthält
  • Ablehnungsrichtlinien anwenden, um aktive Tokens zu blockieren: Administrator ablehnen (roles/iam.denyAdmin) für die Organisation
  • Identitätsübernahme des Dienstkontos verwalten: Dienstkonto-Administrator (roles/iam.serviceAccountAdmin) für das Projekt, das das Dienstkonto enthält

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Verwalten der Workload Identity Federation und der Workforce Identity Federation zum Blockieren von föderierten Tokens erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um die Workload Identity-Föderation und die Workforce Identity-Föderation zum Blockieren von föderierten Tokens zu verwalten:

  • Workload Identity-Pools und -Anbieter verwalten:
    • iam.workloadIdentityPools.update für das Projekt, das den Workload Identity-Pool enthält
    • iam.workloadIdentityPoolProviders.update für das Projekt, das den Workload Identity-Pool enthält
  • Workforce Identity-Pools und -Anbieter verwalten:
    • iam.workforcePools.update für die Organisation, die den Mitarbeiteridentitätspool enthält
    • iam.workforcePoolProviders.update für die Organisation, die den Mitarbeiteridentitätspool enthält
  • Ablehnungsrichtlinien anwenden, um aktive Tokens zu blockieren:
    • iam.denypolicies.create für die Organisation
    • iam.denypolicies.update für das Projekt, den Ordner oder die Organisation
  • Identitätsübernahme des Dienstkontos verwalten: iam.serviceAccounts.setIamPolicy für das Projekt, das das Dienstkonto enthält

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Föderierte Zugriffstokens blockieren

  1. Führen Sie einen dieser Schritte aus:

  2. Wenn Sie den sofortigen Zugriff für aktive Bearer-Tokens (die bis zu einer Stunde gültig sind) blockieren möchten, führen Sie einen der folgenden Schritte aus:

    • Wenn Sie den direkten Zugriff auf Ressourcen blockieren möchten, widerrufen Sie die IAM-Rollen für das betroffene Hauptkonto oder die betroffene Hauptkontogruppe oder wenden Sie eine temporäre IAM-Ablehnungsrichtlinie an.

    • Wenn die föderierte Identität die Identität eines Dienstkontos übernimmt (roles/iam.workloadIdentityUser), führen Sie die Schritte unter Dienstkontoschlüssel und -tokens aus. Entfernen Sie die Rollenbindung zur Identitätsübernahme, um zukünftige Probleme mit der Identitätsübernahme zu vermeiden.

  3. Rotieren Sie die kompromittierten Anmeldedaten in Ihrem Identitätsanbieter, widerrufen Sie aktive Sitzungen oder löschen Sie die kompromittierte Identität.

Browser-Cookies

So entwerten Sie Browser-Cookies für einen Nutzer:

Erforderliche Rollen

Wenn Sie die Berechtigungen benötigen, um einen Nutzer abzumelden und ein Passwort in der Google Workspace-Admin-Konsole zu erzwingen, bitten Sie Ihren Administrator, Ihnen die Rolle Nutzerverwaltungsadministrator oder Super Admin zuzuweisen.

Weitere Informationen zum Zuweisen von Administratorrollen in Google Workspace finden Sie unter Einen Nutzer zum Administrator machen.

Browser-Cookies ungültig machen

Wenn Sie vermuten, dass Browser-Cookies gehackt wurden, führen Sie einen der folgenden Schritte aus:

Bei diesen Aktionen werden alle vorhandenen Cookies ungültig gemacht und der Nutzer wird aufgefordert, sich noch einmal anzumelden.

Unbefugten Zugriff und nicht autorisierte Ressourcen nach dem Widerrufen von Anmeldedaten untersuchen

Nachdem Sie gehackte Anmeldedaten widerrufen und Ihren Dienst wiederhergestellt haben, prüfen Sie den gesamten Zugriff auf Ihre Google Cloud -Ressourcen. Sie können Cloud Logging oder Security Command Center verwenden.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zuzuweisen, damit Sie die nötigen Berechtigungen für diese Aufgabe haben:

  • Audit-Logs in Logging ansehen: Logs Viewer (roles/logging.viewer) für das Projekt, den Ordner oder die Organisation
  • Audit-Logs zum Datenzugriff in Logging ansehen: Betrachter privater Logs (roles/logging.privateLogViewer) für das Projekt, den Ordner oder die Organisation
  • Ergebnisse im Security Command Center ansehen: Security Center-Ergebnisbetrachter (roles/securitycenter.findingsViewer) für das Projekt oder die Organisation

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Untersuchen von unbefugtem Zugriff und Ressourcen erforderlich sind. Maximieren Sie den Abschnitt Erforderliche Berechtigungen, um die notwendigen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

Die folgenden Berechtigungen sind erforderlich, um unbefugten Zugriff und nicht autorisierte Ressourcen zu untersuchen:

  • Audit-Logs in Logging ansehen:
    • logging.logEntries.list für das Projekt, den Ordner oder die Organisation
    • logging.views.access für das Projekt, den Ordner oder die Organisation
  • Audit-Logs zum Datenzugriff in Logging ansehen: logging.privateLogEntries.list für das Projekt, den Ordner oder die Organisation
  • Ergebnisse im Security Command Center ansehen:
    • securitycenter.findings.list für das Projekt oder die Organisation
    • securitycenter.findings.get für das Projekt oder die Organisation

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Unbefugten Zugriff und nicht autorisierte Ressourcen untersuchen

Führen Sie in Logging folgende Schritte aus:

  1. Sehen Sie sich Ihre Audit-Logs in derGoogle Cloud -Konsole an.

    Zum Log-Explorer

  2. Suchen Sie in allen potenziell betroffenen Ressourcen und prüfen Sie, ob alle Kontoaktivitäten (insbesondere im Zusammenhang mit den gehackten Anmeldedaten) so sind wie erwartet.

    Führen Sie beispielsweise Folgendes aus:

    • Suchen Sie nach allen API-Aufrufen, die während des Vorfallzeitraums von der kompromittierten Identität initiiert wurden.
    • Wenn die Identität Berechtigungen für Identitätsdiebstahl hatte, suchen Sie nach Aktionen, bei denen protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail mit dem kompromittierten Prinzipal übereinstimmt.
    • Prüfen Sie, ob während des Vorfalls neue Dienstkontoschlüssel, neue Nutzerkonten oder SSH-Schlüssel auf Projektebene erstellt wurden.

Führen Sie im Security Command Center die folgenden Schritte aus:

  1. Rufen Sie in der Google Cloud Console die Seite Ergebnisse des Security Command Center auf.

    Zu Ergebnissen

  2. Wählen Sie bei Bedarf Ihr Google Cloud Projekt oder Ihre Organisation aus.

  3. Klicken Sie im Bereich Schnellfilter auf einen geeigneten Filter, um das benötigte Ergebnis in der Tabelle Ergebnisse der Ergebnisabfrage aufzurufen. Wenn Sie beispielsweise im Unterabschnitt Anzeigename der Quelle die Option Event Threat Detection oder Container Threat Detection auswählen, werden in den Ergebnissen nur Ergebnisse des ausgewählten Dienstes angezeigt.

    Die Tabelle enthält die Ergebnisse für die ausgewählte Quelle.

  4. Klicken Sie auf den Namen des Ergebnisses unter Kategorie, um Details zu einem bestimmten Ergebnis aufzurufen. Der Bereich mit den Ergebnisdetails wird maximiert und zeigt eine Zusammenfassung der Ergebnisdetails an.

  5. So zeigen Sie alle Ergebnisse an, die durch die Aktionen eines Nutzers ausgelöst wurden:

    1. Kopieren Sie im Detailbereich mit den Ergebnissen die E-Mail-Adresse neben Haupt-E-Mail-Adresse.
    2. Schließen Sie den Bereich.

    3. Geben Sie im Abfrageeditor die folgende Abfrage ein:

      access.principal_email="USER_EMAIL"

      Ersetzen Sie USER_EMAIL durch die zuvor kopierte E-Mail-Adresse.

      Security Command Center zeigt alle Ergebnisse an, die mit Aktionen verknüpft sind, die von dem angegebenen Nutzer ausgeführt wurden.

Alle nicht autorisierten Ressourcen löschen

Achten Sie darauf, dass keine unerwarteten Ressourcen wie VMs, App Engine-Anwendungen, Dienstkonten und Cloud Storage-Buckets vorhanden sind, auf die mit gehackten Anmeldedaten zugegriffen werden könnte.

Nachdem Sie alle nicht autorisierten Ressourcen identifiziert haben, können Sie diese Ressourcen sofort löschen. Sofortiges Handeln ist besonders für Compute Engine-Ressourcen wichtig, da Angreifer gehackte Konten verwenden können, um Daten zu exfiltrieren oder Ihre Produktionssysteme anderweitig zu hacken.

Informationen zum Löschen nicht autorisierter Ressourcen finden Sie in der folgenden Dokumentation:

Alternativ können Sie versuchen, nicht autorisierte Ressourcen zu isolieren, damit Ihre Forensikteams zusätzliche Analysen durchführen können.

Customer Care kontaktieren

Wenn Sie Hilfe bei der Suche nach den Google Cloud -Logs und ‑Tools benötigen, die Sie für Ihre Untersuchungs- und Abhilfemaßnahmen benötigen, wenden Sie sich an den Cloud Customer Care und eröffnen Sie einen Supportfall.

Geschützter Kontozugriff

Wenn Sie überhaupt nicht mehr auf Ihr Konto zugreifen können, haben Sie folgende Möglichkeiten:

  • Verwenden Sie das Formular zur Google Workspace-Kontowiederherstellung, das in der Google Workspace Admin Toolbox verfügbar ist. Weitere Informationen

  • Wenn ein Angreifer betrügerische Ressourcen erstellt, während Sie vollständig ausgesperrt sind und Anspruch auf Support haben, gehen Sie so vor:

    1. Rufen Sie in einem Inkognitofenster die Fehlerbehebung für den Supportkontakt auf.

    2. Wählen Sie Ja aus und klicken Sie auf Ticket einreichen.

    3. Füllen Sie das Formular mit Ihren Angaben aus und senden Sie es an uns.

  • Wenn ein Angreifer betrügerische Ressourcen erstellt, während Sie vollständig ausgesperrt sind und keinen Anspruch auf Support haben, gehen Sie so vor:

    1. Rufen Sie in einem Inkognitofenster die Fehlerbehebung für den Supportkontakt auf.

    2. Beantworten Sie die Fragen so:

      Frage zur Fehlerbehebung Erforderliche Auswahl
      Haben Sie Anspruch auf Support? Nein
      Befindest du dich derzeit in der kostenlosen Testphase? Nein
      Sind Sie der Abrechnungsadministrator eines GCP-Rechnungskontos (Google Cloud)? Nein
      Tritt eine dieser Situationen bei Ihnen auf? Ich kann nicht mehr auf mein GCP-Projekt oder mein Rechnungskonto zugreifen und muss den Zugriff wiederherstellen.

    3. Klicken Sie auf Ticket bei unserem Team für die Kontowiederherstellung einreichen.

    4. Füllen Sie das nicht authentifizierte Kontaktformular mit Ihren Daten aus, einschließlich aller Rechnungskonto-IDs oder Zahlungsindikatoren, die Sie zur Bestätigung Ihrer Identität angeben können, und senden Sie es ab.

Nächste Schritte

Implementieren Sie die folgenden Best Practices, um gehackte Anmeldedaten zu vermeiden: