Best Practices zum Schutz von Entwickleranmeldedaten

Best Practices zum Schutz von Entwickler-Workstations und zur Vermeidung von Diebstahl und Missbrauch von Google Cloud Anmeldedaten, einschließlich Google Cloud CLI OAuth-Bearer Tokens, Standardanmeldedaten für Anwendungen und lokalen Schlüsseln.

Dieses Dokument richtet sich an Sicherheitsteams oder Cloud-Architekten, die ihre Cloud-Ressourcen vor unberechtigtem Zugriff schützen. Hier erfahren Sie mehr über die verfügbaren Steuerelemente, mit denen Sie die Auswirkungen manipulierter Anmeldedaten von Entwicklern proaktiv reduzieren und Ihre Umgebung korrigieren können, nachdem ein Endpunkt manipuliert wurde.

Das Risiko manipulierter Anmeldedaten

Ein Angreifer kann Anmeldedaten manipulieren, wenn er Zugriff auf einen Endpunkt erhält, auf dem ein legitimes Nutzerkonto oder Dienstkonto bereits mit Google Cloud oder der gcloud CLI 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.

Übersicht über Anmeldedaten für Entwickler

Die folgenden Google Cloud Anmeldedaten sind in der Regel auf Entwickler- Workstations zu finden:

In den folgenden Abschnitten wird beschrieben, wie die einzelnen Anmeldedatentypen gespeichert und verwendet werden.

gcloud CLI OAuth-Tokens

Die gcloud CLI verwendet OAuth 2.0-Zugriff tokens, um Anfragen für Google Cloud 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 standardmäßig nach 60 Minuten ab, kann aber unter erweiterten Einschränkungen der Lebensdauer bis zu 12 Stunden gültig sein. Andere Anmeldedatentypen können jedoch persistent sein.

Wenn Sie die gcloud CLI mit einem Nutzerkonto autorisieren, initiiert die gcloud CLI 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 CLI ein Zugriffstoken und ein Aktualisierungstoken, mit denen sie neue Zugriffstokens anfordern kann. Das langlebige Aktualisierungstoken bleibt erhalten, bis seine Ablaufbedingungen erfüllt sind met.

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

Wenn Sie die gcloud CLI in einer Google Cloud Umgebung wie Compute Engine oder Cloud Shell ausführen, kann die Anwendung automatisch Anmeldedaten finden und als Dienst konto authentifizieren. In Compute Engine kann eine Anwendung wie die gcloud CLI 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.

Standardanmeldedaten für Anwendungen

Standardanmeldedaten für Anwendungen werden von Anwendungen verwendet, um sich bei Google Cloud APIs zu authentifizieren. Entwickler können Standardanmeldedaten für Anwendungen generieren, indem sie gcloud auth application-default login ausführen. Mit diesem Befehl wird eine JSON-Datei im Klartext ($HOME/.config/gcloud/application_default_credentials.json oder %APPDATA%\gcloud\application_default_credentials.json) geschrieben, die ein OAuth 2.0-Aktualisierungstoken und Anmeldedaten für Clientbibliotheken enthält.

Jede Clientbibliothek oder jedes benutzerdefinierte Skript kann diese Anmeldedaten verwenden, um Google Cloud APIs aufzurufen.

Da Standardanmeldedaten für Anwendungen im Klartext gespeichert werden, kann jeder nicht vertrauenswürdige Prozess oder jedes nicht vertrauenswürdige Skript, das im Kontext des Nutzers ausgeführt wird, direkt auf die Datei zugreifen oder Befehle wie gcloud auth application-default print-access-token verwenden, um aktive Zugriffstokens abzurufen.

Typische Malware zielt oft auf das Verzeichnis ~/.config/gcloud/ ab, um application_default_credentials.json zu sammeln.

Weitere Informationen finden Sie unter Standardanmeldedaten für Anwendungen.

Dienstkontoschlüssel

Dienstkontoschlüssel sind private JSON-Schlüsseldateien, die aus der Google Cloud Console heruntergeladen werden. Diese Schlüssel werden von Anwendungen verwendet, um sich bei Google Cloud APIs zu authentifizieren. Dienstkontoschlüssel können an den folgenden Orten gespeichert werden:

  • gcloud CLI-Konfigurationsverzeichnis nach Ausführung von gcloud auth activate-service-account
  • Das lokale Dateisystem
  • Ein internes Code-Repository

Für Dienstkontoschlüssel auf Endpunkten von Entwicklern gilt keine Bestätigung in zwei Schritten, es gibt keine Sitzungslängenbeschränkungen und sie laufen nicht automatisch ab.

Ein Angreifer, der einen Dienstkontoschlüssel stiehlt, kann Zugriffstokens für Dienstkonten erstellen, um den dauerhaften Zugriff aufrechtzuerhalten.

Weitere Informationen finden Sie unter Best Practices für die Verwaltung von Dienstkontoschlüsseln.

SSH-Schlüssel

SSH-Schlüssel werden zur Authentifizierung bei Compute Engine-Instanzen verwendet. Entwickler können SSH-Schlüssel mit gcloud compute ssh generieren. Mit diesem Befehl werden lokale private Schlüssel in ~/.ssh/google_compute_engine generiert. SSH-Schlüssel sind langlebig.

Ein Angreifer kann einen gestohlenen SSH-Schlüssel verwenden, um auf eine VM zuzugreifen und dann den Metadatenserver abzufragen, um ein angehängtes Dienstkonto-Token zu extrahieren. Bei diesem Angriff werden externe Perimeter-Firewalls umgangen.

Anstelle von SSH-Schlüsseln sollten Sie OS Login mit Bestätigung in zwei Schritten verwenden. Weitere Informationen finden Sie unter Bestätigung in zwei Schritten für Remote-Serverzugriff erzwingen.

Browser-Cookies

Browser-Cookies authentifizieren HTTP-Webanfragen an die Google Cloud Console und Cloud Shell. Browser-Cookies werden automatisch erstellt, wenn sich ein Nutzer in der Google Cloud Console anmeldet.

Die Cookies werden im Profilverzeichnis des Browsers auf der lokalen Workstation gespeichert. Google Chrome speichert Cookies beispielsweise unter Linux in ~/.config/google-chrome/ oder unter Windows in %LOCALAPPDATA%\Google\Chrome\User Data.

Browser-Cookies sind langlebige Anmeldedaten, die nur ungültig werden, wenn sich ein Nutzer abmeldet, wenn ein Sitzungstimeout auftritt oder wenn ein Administrator die Nutzersitzung in der Admin-Konsole zurücksetzt.

Ein Angreifer, der diese Cookies stiehlt, kann sie in einen anderen Browser importieren, um aktive Google Cloud Console-Sitzungen zu übernehmen und die Authentifizierung zu umgehen.

Um das Risiko gestohlener Sitzungscookies zu verringern, legen Sie die Sitzungslänge für Google Cloud Dienste fest.

Zugriffstokens für die Mitarbeiteridentitätsföderation

Entwickler können die Mitarbeiteridentitätsföderation verwenden, um sich über einen externen Identitätsanbieter zu authentifizieren, damit sie auf Google Cloud Ressourcen zugreifen können.

Um sich mit einer föderierten Identität anzumelden, verwenden Entwickler eine Konfigurationsdatei für die Anmeldung (die mit dem gcloud iam workforce-pools create-login-config Befehl erstellt wird) und melden sich in der gcloud CLI an. Nach der Authentifizierung mit dem externen Identitätsanbieter tauscht der Security Token Service den Autorisierungscode gegen ein kurzlebiges föderiertes Zugriffstoken und ein OAuth-Aktualisierungstoken aus.

Die gcloud CLI speichert Anmeldedaten-Metadaten und Aktualisierungstokens in einer lokalen Anmeldedatenbank und speichert aktive Zugriffstokens im gcloud CLI-Konfigurationsverzeichnis im Cache. Föderierte Zugriffstokens sind kurzlebige Anmeldedaten, die nach einer bestimmten Zeit ablaufen (standardmäßig 60 Minuten).

Ein Angreifer, der einen Endpunkt manipuliert, kann aktive föderierte Zugriffstokens extrahieren oder gcloud auth print-access-token verwenden, um die Identität des Mitarbeiters zu übernehmen. Wenn die Mitarbeiteridentität über Berechtigungen zur Identitätsübernahme verfügt, kann der Angreifer auch Zugriffstokens für Dienstkonten anfordern, um Berechtigungen zu eskalieren.

Konfigurieren Sie zur Risikominimierung die Sitzungsdauer in Ihrem Mitarbeiteridentitätspool auf die kürzestmögliche Dauer und stimmen Sie sie mit den Richtlinien für die erneute Authentifizierung und das Sitzungstimeout Ihres externen Identitätsanbieters ab. Weitere Informationen zum Speichern und Verwalten der Anmeldedaten finden Sie unter Best Practices für die Verwendung der Identitätsföderation von Arbeitslasten.

Auswirkungen manipulierter Anmeldedaten

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 Client bibliothek 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 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 Anmeldedaten auf einen anderen Endpunkt kopieren, den er steuert, um seinen Zugriff aufrechtzuerhalten. Der Diebstahl von Anmeldedaten birgt eine weitere Gefahr. Der Angreifer kann die langlebigen Anmeldedaten auch dann noch verwenden, wenn Sie den Zugriff auf den manipulierten Endpunkt entfernen.

Wenn es dem Angreifer gelingt, Anmeldedaten von Entwicklern zu manipulieren, kann er die folgenden Aktionen durchführen:

  • 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.
  • Zugriffstokens auf unbestimmte Zeit anfordern, indem er ein nichtflüchtiges OAuth-Aktualisierungstoken (aus der gcloud CLI oder Standardanmeldedaten für Anwendungen) oder einen privaten Schlüssel verwendet, der mit einem Dienstkonto verknüpft ist.
  • Authentifizierung mit dem Nutzerpasswort oder der Bestätigung in zwei Schritten umgehen, da die Tokens nach dem Anmeldevorgang gewährt werden.
  • Gestohlene SSH-Schlüssel verwenden, um auf Compute Engine-Instanzen zuzugreifen und den Metadatenserver abzufragen, um angehängte Dienstkonto-Tokens zu stehlen.
  • Gestohlene Browser-Cookies verwenden, um aktive Google Cloud Console-Sitzungen zu übernehmen, ohne dass das Passwort des Nutzers oder die Bestätigung in zwei Schritten erforderlich ist.
  • Gestohlene föderierte Zugriffstokens verwenden, um auf Ressourcen zuzugreifen, die Mitarbeiteridentitätspools gewährt wurden, oder Berechtigungen zu eskalieren, indem er die Identität von Dienstkonten übernimmt.

Best Practices zur Risikominimierung

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

Sitzungslänge für Google Cloud Dienste festlegen

Legen Sie die Sitzungs länge für Google Cloud Dienste fest, um zu reduzieren, wie lange ein Angreifer ein manipuliertes Token ausnutzen kann. Für neue Kunden wird automatisch eine Standardsitzungslänge von 16 Stunden erzwungen. Kunden, die ihre Google Cloud Organisation vor 2023 erstellt haben, haben möglicherweise eine Standardeinstellung, die keine erneute Authentifizierung erfordert. Prüfen Sie diese Einstellung, um sicherzustellen, dass Sie eine Richtlinie für die erneute Authentifizierung mit einer Sitzungslänge zwischen 1 und 24 Stunden haben. Die Richtlinie für die erneute Authentifizierung zwingt den Nutzer, die gcloud CLI regelmäßig mit seinem Passwort oder Sicherheitsschlüssel neu zu authentifizieren.

Die Sitzungslänge für Google Cloud Dienste unterscheidet sich von der Sitzungslänge für Google-Dienste, die Websitzungen für die Anmeldung in Google Workspace-Diensten steuert, aber nicht die erneute Authentifizierung für Google Cloudsteuert. Wenn Sie Google Workspace-Dienste verwenden, legen Sie die Sitzungslänge 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 Console und Google Cloud Google Cloud APIs zu schützen. Konfigurieren Sie eine Chrome Enterprise Premium-Zugriffsebene und -Bindung, um selektiv Attribute zuzulassen, die bei jeder API-Anfrage ausgewertet werden, einschließlich IP-basierter Zugriff oder zertifikatbasierter Zugriff für Mutual TLS. 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, gehen Sie so vor:

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.

Suchen Sie nach sicheren Alternativen für die Authentifizierung, um Anwendungsfälle zu reduzieren oder zu beseitigen, die von einem Dienstkontoschlüssel abhängen. Erzwingen Sie außerdem die constraints/iam.disableServiceAccountKeyCreation und constraints/iam.disableServiceAccountKeyUpload Einschränkungen der Organisationsrichtlinie, um das Erstellen von Dienstkontoschlüsseln zu deaktivieren.

Prinzip der geringsten Berechtigung anwenden

Berücksichtigen Sie beim Entwerfen von IAM-Richtlinien (Identity and Access Management) die geringste Berechtigung. Gewähren Sie Nutzern nur die Rollen, die sie zum Ausführen einer Aufgabe im kleinstmöglichen Bereich benötigen. Prüfen und wenden Sie Rollen empfehlungen 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 Anmeldedaten ist zwar wichtig, Sie sollten aber auch das Risiko berücksichtigen, dass ein Angreifer Ihre vertrauenswürdigen Endpunkte manipuliert. Wenn ein Angreifer Zugriff auf Ihre vertrauenswürdigen Endpunkte hat, kann er gcloud CLI-Befehle oder anderen Code direkt auf den Endpunkten 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 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önnten?
  • 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 Controls-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 Incident Response 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.

Informationen zum Bewerten und Reagieren auf eine Manipulation finden Sie unter Auf manipulierte Google Cloud Anmeldedaten reagieren.

Anmeldedaten auf Hacking prüfen

Beachten Sie Folgendes, um ein potenzielles Hacking zu erkennen:

  • Suchen Sie in Ihren Code-Repositories nach Secrets, indem Sie Tools wie die Anomalieerkennung oder Secret-Scans verwenden.

  • Konfigurieren Sie in Cloud-Audit-Logs Benachrichtigungen für Folgendes:

    • iamcredentials.googleapis.com -Methoden (z. B. GenerateAccessToken, GenerateIdToken, SignJwt), um die Erstellung von Dienstkonto-Tokens zu prüfen

      Für diese Logs müssen Sie Datenzugriffslogs aktivieren.

    • protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail , um die Identitätsübernahme von Nutzern und Dienstkonten zu prüfen

    • sts.googleapis.com-Austauschanfragen für anomale Identitätsassertions

  • Achten Sie im Security Command Center auf die folgenden Bedrohungsbefunde von Event Threat Detection:

    • Persistenz: Neue Region
    • Persistenz: Neuer User-Agent
    • Persistenz: Neue API-Methode
    • E-Mail: Zugriff vom Anonymisierungs-Proxy
    • Berechtigungseskalation: Anomale Dienstkonto-Identitätsübernahme für Administratoraktivitäten
    • Berechtigungseskalation: Anomale Dienstkonto-Identitätsübernahme für Administratoraktivitäten
    • Erstzugriff: Gehackter Dienstkontoschlüssel verwendet
    • Persistenz: Dienstkontoschlüssel erstellt
    • Erstzugriff: Verdächtige Anmeldung blockiert
    • Erstzugriff: Konto deaktiviert – Gehackt

    Für jede Bedrohung werden empfohlene Untersuchung sschritte bereitgestellt, die Ihnen bei der Reaktion helfen.

  • Überwachen Sie Nutzeranmeldungen in Google Workspace und Cloud Identity. Zur besseren Nachverfolgung von Problemen sollten Sie die Logs nach Cloud Logging exportieren.

  • Überwachen Sie Logs von Chrome Enterprise Premium und VPC Service Controls auf Zugriffsversuche außerhalb des Perimeters mit gestohlenen Tokens.

  • Mit Cloud Monitoring können Sie Anomalien bei der Nutzung von Dienstkontoschlüsseln überwachen.

Achten Sie darauf, dass Ihr Sicherheitscenter (SOC) sofort benachrichtigt wird und die Playbooks, Tools und den Zugriff hat, die erforderlich sind, um schnell auf eine mutmaßliche Manipulation von Anmeldedaten zu reagieren. Sie können das Security Command Center auch in Ihr vorhandenes SIEM einbinden oder Logszur weiteren Analyse in Google Security Operations importieren.

Nächste Schritte