Sicherheitsloganalysen in Google Cloud

Last reviewed 2024-05-21 UTC

In diesem Leitfaden erfahren Sicherheitsexperten, wie Sie Google Cloud-Logs zur Verwendung in Sicherheitsanalysen einrichten können. Durch Sicherheitsanalysen kann Ihre Organisation besser Bedrohungen wie Malware, Phishing, Ransomware und schlecht konfigurierte Assets verhindern, erkennen und darauf reagieren.

Diese Seite enthält Anleitungen für Folgendes:

• Aktivieren der zu analysierenden Logs.
• Leiten Sie diese Logs an ein einzelnes Ziel weiter, je nach dem ausgewählten Sicherheitsanalysetool, z. B.Log Analytics, BigQuery, Google Security Operations oder eine Drittanbieter-Technologie für Sicherheitsinformationen und Ereignisverwaltung (SIEM).
• Analysieren dieser Logs, um Ihre Cloudnutzung zu prüfen und potenzielle Bedrohungen für Ihre Daten und Arbeitslasten zu erkennen. Dazu Beispielabfragen aus dem Projekt Community Security Analytics (CSA).

Die Informationen in diesem Leitfaden sind Teil der Autonomic Security Operations von Google Cloud. Dazu gehören die Engineering-gestützte Transformation von Erkennungs- und Reaktionspraktiken und Sicherheitsanalysen, um Ihre Bedrohungserkennungsfunktionen zu verbessern.

In diesem Leitfaden stellen Logs die zu analysierende Datenquelle bereit. Sie können jedoch die Konzepte aus diesem Leitfaden auf die Analyse anderer sicherheitsbezogener Daten von Google Cloud anwenden, z. B. Sicherheitsergebnisse aus Security Command Center. Security Command Center Premium bietet eine Liste regelmäßig aktualisierter verwalteter Detektoren, mit denen Sie Bedrohungen, Sicherheitslücken und Fehlkonfigurationen in Ihren Systemen nahezu in Echtzeit identifizieren können. Durch Analysieren dieser Signale aus Security Command Center und die Korrelation mit Logs, die in Ihrem Sicherheitsanalysetool aufgenommen wurden, wie in dieser Anleitung beschrieben, können Sie eine breitere Perspektive potenzieller Sicherheitsbedrohungen erhalten.

Das folgende Diagramm zeigt, wie Sicherheitsdatenquellen, Sicherheitsanalysetools und CSA-Abfragen zusammenarbeiten.

Das Diagramm beginnt mit den folgenden Sicherheitsdatenquellen: Logs aus Cloud Logging, Asset-Änderungen aus Cloud Asset Inventory und Sicherheitsergebnisse aus Security Command Center. Das Diagramm zeigt dann, dass diese Sicherheitsdatenquellen an das Sicherheitsanalysetool Ihrer Wahl weitergeleitet werden: Log Analytics in Cloud Logging, BigQuery, Google Security Operations oder eine Drittanbieter-SIEM-Technologie. Schließlich zeigt das Diagramm die Verwendung von CSA-Abfragen mit Ihrem Analysetool, um die sortierten Sicherheitsdaten zu analysieren.

Workflow für Sicherheitsloganalysen

In diesem Abschnitt werden die Schritte zum Einrichten von Sicherheitsloganalysen in Google Cloud beschrieben. Der Workflow besteht aus den drei im folgenden Diagramm dargestellten Schritten, die in den folgenden Abschnitten beschrieben werden:

• Logs aktivieren: In Google Cloud sind viele Sicherheitslogs verfügbar. Jedes Log enthält unterschiedliche Informationen, die zur Beantwortung bestimmter Sicherheitsfragen nützlich sein können. Einige Logs wie Audit-Logs zur Administratoraktivität sind standardmäßig aktiviert. Andere müssen manuell aktiviert werden, da in Cloud Logging zusätzliche Aufnahmekosten anfallen. Daher muss der erste Schritt im Workflow darin bestehen, die Sicherheitslogs zu priorisieren, die für Ihre Sicherheitsanalyseanforderungen am relevantesten sind, und diese Logs einzeln zu aktivieren.

  Damit Sie Logs im Hinblick auf die von ihnen bereitgestellte Sichtbarkeit und Bedrohungserkennungs-Abdeckung prüfen können, enthält dieser Leitfaden ein Logbereichstool. Dieses Tool ordnet jedes Log den relevanten Bedrohungstaktiken und -techniken in der MITRE ATT&CK®-Matrix for Enterprise zu. Das Tool ordnet außerdem die Event Threat Detection-Regeln in Security Command Center den Logs zu, von denen sie abhängen. Mit dem Logbereichstool können Sie Logs unabhängig vom verwendeten Analysetool auswerten.

• Logs weiterleiten: Nachdem Sie die zu analysierenden Logs identifiziert und aktiviert haben, müssen Sie im nächsten Schritt die Logs aus Ihrer Organisation weiterleiten und aggregieren, einschließlich enthaltener Ordner, Projekte und Rechnungskonten. Wie Sie Logs weiterleiten, hängt vom verwendeten Analysetool ab.

  In diesem Leitfaden werden allgemeine Logweiterleitungsziele beschrieben. Außerdem erfahren Sie, wie Sie mit einer aggregierten Cloud Logging-Senke organisationsweite Logs an einen Cloud Logging-Log-Bucket oder ein BigQuery-Dataset weiterleiten, je nachdem, ob Sie Log Analytics oder BigQuery für die Analyse verwenden möchten.

• Logs analysieren: Nachdem Sie die Logs an ein Analysetool weitergeleitet haben, besteht der nächste Schritt darin, eine Analyse dieser Logs durchzuführen, um potenzielle Sicherheitsbedrohungen zu identifizieren. Wie Sie die weitergeleiteten Logs analysieren, hängt vom verwendeten Analysetool ab. Wenn Sie Log Analytics oder BigQuery verwenden, können Sie die Logs mithilfe von SQL-Abfragen analysieren. Wenn Sie Google Security Operations verwenden, analysieren Sie die Logs mithilfe von YARA-L-Regeln. Wenn Sie ein SIEM-Tool eines Drittanbieters verwenden, verwenden Sie die durch dieses Tool angegebene Abfragesprache.

  In dieser Anleitung finden Sie SQL-Abfragen, mit denen Sie die Logs in Log Analytics oder BigQuery analysieren können. Die SQL-Abfragen in diesem Leitfaden stammen aus dem Projekt Community Security Analytics (CSA). CSA ist ein Open-Source-Set grundlegender Sicherheitsanalysen, das Ihnen eine Basis von vorgefertigten Abfragen und Regeln bietet, die Sie wiederverwenden können, um mit der Analyse Ihrer Google Cloud-Protokolle zu beginnen.

In den folgenden Abschnitten wird ausführlich beschrieben, wie Sie die einzelnen Schritte im Sicherheits-Logs-analyse-Workflow einrichten und anwenden.

Logs aktivieren

Die Aktivierung von Logs umfasst folgende Schritte:

1. Ermitteln Sie die benötigten Logs mit dem Logbereichstool in diesem Leitfaden.
2. Zeichnen Sie den Logfilter auf, der vom Logbereichstool für die spätere Konfiguration der Logsenke generiert wurde.
3. Aktivieren Sie Logging für jeden identifizierten Logtyp oder Google Cloud-Dienst. Je nach Dienst müssen Sie möglicherweise auch die entsprechenden Audit-Logs zum Datenzugriff aktivieren, wie weiter unten in diesem Abschnitt beschrieben.

Logs mit dem Logbereichstool identifizieren

Mit dem Logbereichstool, das in diesem Abschnitt beschrieben wird, können Sie die Logs ermitteln, die Ihren Sicherheits- und Complianceanforderungen entsprechen. Dieses Tool bietet eine interaktive Tabelle, in der wertvolle sicherheitsrelevante Logs in Google Cloud aufgelistet werden, darunter Cloud-Audit-Logs, Access Transparency-Logs, Netzwerklogs und verschiedene Plattformlogs. Dieses Tool ordnet jeden Logtyp den folgenden Bereichen zu:

• MITRE ATT&CK®-Bedrohungstaktiken und -techniken, die mit diesem Log überwacht werden können
• Verstöße gegen die Compliance mit der CIS Google Cloud Computing Platform, die in diesem Log erkannt werden können.
• Event Threat Detection-Regeln, die auf diesem Log basieren.

Das Logbereichstool generiert auch einen Logfilter, der unmittelbar nach der Tabelle angezeigt wird. Wenn Sie die benötigten Logs finden, wählen Sie diese im Tool aus, um den Logfilter automatisch zu aktualisieren.

Im Folgenden wird erläutert, wie Sie das Logbereichstool verwenden:

• Klicken Sie auf den Schieberegler neben dem Lognamen, um ein Log im Logbereichstool auszuwählen oder zu entfernen.
• Klicken Sie auf den Schieberegler neben der Überschrift Logtyp, um alle Logs auszuwählen oder zu entfernen.
• Klicken Sie neben der Überschrift MITRE-ATT&CK-Taktiken und -Techniken auf , um zu sehen, welche MITRE-ATT&CK-Techniken von jedem Logtyp überwacht werden können.

Logbereichstool

Logfilter aufzeichnen

Der vom Logbereichstool automatisch generierte Logfilter enthält alle Logs, die Sie im Tool ausgewählt haben. Sie können den Filter unverändert verwenden oder den Logfilter je nach Ihren Anforderungen weiter verfeinern. Sie können beispielsweise Ressourcen nur in einem oder in mehreren bestimmten Projekten einschließen (oder ausschließen). Sobald Sie einen Logfilter haben, der Ihren Logging-Anforderungen entspricht, müssen Sie den Filter für dessen Verwendung bei der Weiterleitung der Logs speichern. Sie können den Filter beispielsweise in einem Texteditor speichern oder ihn in einer Umgebungsvariablen speichern:

1. Kopieren Sie im Abschnitt "Automatisch generierter Logfilter", der auf das Tool folgt, den Code für den Logfilter.
2. Optional: Bearbeiten Sie den kopierten Code, um den Filter zu verfeinern.

3. Erstellen Sie in Cloud Shell eine Variable zum Speichern des Logfilters:

   export LOG_FILTER='LOG_FILTER'
   

   Ersetzen Sie LOG_FILTER durch den Code für den Logfilter.

Dienstspezifische Plattformlogs aktivieren

Für jedes der Plattform-Logs, das Sie im Logbereichstool auswählen, müssen diese Logs (in der Regel auf Ressourcenebene) für jeden Dienst einzeln aktiviert werden. Zum Beispiel werden Cloud DNS-Logs auf VPC-Netzwerkebene aktiviert. Ebenso werden VPC-Flusslogs auf der Subnetzebene für alle VMs im Subnetz aktiviert und Firewallregel-Logs auf der Ebene einzelner Firewallregeln.

Für jedes Plattformlog gibt es eine eigene Anleitung zum Aktivieren des Loggings. Sie können jedoch das Logbereichstool verwenden, um die relevanten Anleitungen für jedes Plattformlog schnell zu öffnen.

So aktivieren Sie das Logging für ein bestimmtes Plattformlog:

1. Suchen Sie im Logbereichstool das Plattformlog, das Sie aktivieren möchten.
2. Klicken Sie in der Spalte Standardmäßig aktiviert auf den Link Aktivieren, der diesem Log entspricht. Der Link führt Sie durch detaillierte Anleitungen, wie Sie das Logging für diesen Dienst aktivieren.

Audit-Logs zum Datenzugriff aktivieren

Wie Sie im Logbereichstool sehen können, bieten die Audit-Logs zum Datenzugriff aus Cloud-Audit-Logs eine umfassende Abdeckung bei der Bedrohungserkennung. Ihr Volumen kann jedoch recht groß sein. Die Aktivierung dieser Audit-Logs zum Datenzugriff kann daher zu zusätzlichen Gebühren beim Aufnehmen, Speichern, Exportieren und Verarbeiten dieser Logs führen. In diesem Abschnitt wird erläutert, wie Sie diese Logs aktivieren, und es werden einige Best Practices beschrieben, die Sie dabei unterstützen, einen Kompromiss zwischen Mehrwert und Kosten zu finden.

Hinweis: Audit-Logs für den Datenzugriff können personenidentifizierbare Informationen wie Anruferidentitäten und IP-Adressen enthalten. Sie müssen die entsprechenden Einstellungen für die Zugriffssteuerung und Aufbewahrung im Analysetool anwenden, um Ihre Logdaten zu sichern, diese Daten nur so lange wie nötig aufzubewahren und dann sicher zu löschen.

Audit-Logs zum Datenzugriff sind – außer bei BigQuery – standardmäßig deaktiviert. Wenn Sie Audit-Logs zum Datenzugriff für andere Google Cloud-Dienste als BigQuery konfigurieren möchten, müssen Sie sie explizit mit der Google Cloud Console odermit der Google Cloud-Befehlszeile aktivieren, um IAM-Richtlinienobjekte (Identity and Access Management) zu bearbeiten. Wenn Sie Audit-Logs zum Datenzugriff aktivieren, können Sie auch konfigurieren, welche Arten von Vorgängen aufgezeichnet werden. Für den Datenzugriff stehen drei Audit-Logtypen zur Verfügung:

• ADMIN_READ: Zeichnet Vorgänge auf, bei denen Metadaten oder Konfigurationsinformationen gelesen werden.
• DATA_READ: Zeichnet Vorgänge auf, die von Nutzern bereitgestellte Daten lesen.
• DATA_WRITE: Zeichnet Vorgänge auf, die von Nutzern bereitgestellte Daten schreiben.

Beachten Sie, dass Sie die Aufzeichnung von ADMIN_WRITE-Vorgängen, die Metadaten oder Konfigurationsinformationen schreiben, nicht konfigurieren können. ADMIN_WRITE-Vorgänge sind in Audit-Logs zu Administratoraktivitäten aus Cloud-Audit-Logs enthalten und können daher nicht deaktiviert werden.

Best Practice: Aktivieren Sie Audit-Logs zum Datenzugriff auf Ordner- oder Organisationsebene, um die Compliance für alle untergeordneten Projekte dieses Ordners oder dieser Organisation sicherzustellen. Wenn Sie die Audit-Logs auf Ordner- oder Organisationsebene aktivieren, gilt die Audit-Richtlinie für alle vorhandenen und neuen Projekte in diesem Ordner oder dieser Organisation. Diese Audit-Richtlinie kann nicht auf Projektebene deaktiviert werden.

Volumen der Audit-Logs zum Datenzugriff verwalten

Wenn Sie Audit-Logs zum Datenzugriff aktivieren, besteht das Ziel darin, ihren Wert in Bezug auf die Sicherheit und Transparenz zu maximieren und gleichzeitig die Kosten und den Verwaltungsaufwand zu begrenzen. So filtern Sie Logs mit geringem Wert und hohem Volumen heraus, um dieses Ziel zu erreichen:

• Priorisieren Sie relevante Dienste, z. B. Dienste, die sensible Arbeitslasten, Schlüssel und Daten hosten. Bestimmte Beispiele für Dienste, die Sie möglicherweise gegenüber anderen priorisieren möchten, finden Sie unter Beispielkonfiguration für Audit-Logs zum Datenzugriff.

• Priorisieren Sie relevante Projekte wie Projekte, die Produktionsarbeitslasten hosten, anstatt Projekte, die Entwickler- und Staging-Umgebungen hosten. Fügen Sie dem Logfilter für die Senke den folgenden Ausdruck hinzu, um alle Logs aus einem bestimmten Projekt herauszufiltern. Ersetzen Sie PROJECT_ID durch die ID des Projekts, aus dem Sie alle Logs herausfiltern möchten:

  Projekt	Logfilterausdruck
  Alle Logs eines bestimmten Projekts ausschließen	NOT logName =~ "^projects/PROJECT_ID"

• Priorisieren Sie einen Teil der Datenzugriffsvorgänge wie ADMIN_READ, DATA_READ oder DATA_WRITE für einen minimalen Satz von aufgezeichneten Vorgängen. Einige Dienste wie Cloud DNS schreiben beispielsweise alle drei Arten von Vorgängen. Sie können das Logging jedoch nur für ADMIN_READ-Vorgänge aktivieren. Nachdem Sie einen oder mehrere dieser drei Arten von Datenzugriffsvorgängen konfiguriert haben, können Sie bestimmte Vorgänge mit hohem Volumen ausschließen. Sie können diese Vorgänge mit hohem Volumen ausschließen, indem Sie den Logfilter der Senke ändern. Sie aktivieren beispielsweise das vollständige Audit-Logging für den Datenzugriff, einschließlich DATA_READ-Vorgänge für einige wichtige Speicherdienste. Wenn Sie in dieser Situation bestimmte Lesevorgänge mit hohem Traffic ausschließen möchten, können Sie dem Logfilter der Senke die folgenden empfohlenen Logfilterausdrücke hinzufügen:

  Dienst	Logfilterausdruck
  Logs mit hohem Volumen aus Cloud Storage ausschließen	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  Logs mit hohem Volumen aus Cloud SQL ausschließen	NOT (resource.type="cloudsql_database" AND protoPayload.request.cmd="select")

• Priorisieren Sie relevante Ressourcen wie Ressourcen, die Ihre sensibelsten Arbeitslasten und Daten hosten. Sie können Ihre Ressourcen nach dem Wert der verarbeiteten Daten und ihrem Sicherheitsrisiko klassifizieren, z. B. ob sie extern zugänglich sind oder nicht. Obwohl Audit-Logs zum Datenzugriff pro Dienst aktiviert sind, können Sie bestimmte Ressourcen oder Ressourcentypen über den Logfilter herausfiltern.

• Schließen Sie bestimmte Hauptkonten aus, damit ihre Datenzugriffe nicht aufgezeichnet werden. Beispielsweise haben Sie die Möglichkeit, die Aufzeichnung der Vorgänge für Ihre internen Testkonten auszuschließen. Weitere Informationen finden Sie in der Dokumentation zu Audit-Logs zum Datenzugriff unter Ausnahmen festlegen.

Hinweis: Zusätzlich zum Logfilter der Senke können Logs wie in diesem Abschnitt beschrieben herausgefiltert werden. Sie können jedoch aus Kostengründen ausschließen, dass diese Logs in Cloud Logging aufgenommen werden. Wenn Sie verhindern möchten, dass diese Logs aufgenommen werden, können Sie die in diesem Abschnitt aufgeführten Logfilterausdrücke als Ausschlussfilter auf die vordefinierte _Default-Senke anwenden, die Logs (einschließlich Audit-Logs zum Datenzugriff) in den _Default-Log-Bucket weiterleitet. Ausschlussfilter haben den umgekehrten Effekt eines Logfilters, bei dem es sich um einen Einschlussfilter handelt. Wenn Sie diese Ausdrücke als Ausschlussfilter konfigurieren, müssen Sie den vorangehenden booleschen Operator NOT aus den Filterausdrücken in diesem Abschnitt entfernen.

Beispielkonfiguration für Audit-Logs zum Datenzugriff

Die folgende Tabelle enthält eine Basiskonfiguration für Audit-Logs zum Datenzugriff. Diese können Sie für Google Cloud-Projekte verwenden, um Logvolumen zu begrenzen und dabei gleichzeitig wertvolle Sicherheit und Transparenz zu erhalten:

Stufe	Dienste	Audit-Logtypen zum Datenzugriff	MITRE-ATT&CK-Taktiken
Authentifizierungs- und Autorisierungsdienste	IAM Identity-Aware Proxy (IAP)^1 Cloud KMS Secret Manager Resource Manager	ADMIN_READ DATA_READ	Erkennung Anmeldedatenzugriff Rechteausweitung
Bild: Speicherdienste	BigQuery (standardmäßig aktiviert) Cloud Storage^1, 2	DATA_READ DATA_WRITE	Erfassung Exfiltration
Infrastruktur-Dienste	Compute Engine- Organisationsrichtlinie	ADMIN_READ	Logo: Discovery

¹ Durch Aktivieren von Audit-Logs zum Datenzugriff für IAP oder Cloud Storage können große Logvolumen generiert werden, wenn hoher Traffic zu IAP-geschützten Webressourcen oder zu Cloud Storage-Objekten auftritt.

² Wenn Sie Audit-Logs zum Datenzugriff für Cloud Storage aktivieren, ist die Verwendung von authentifizierten Browserdownloads für nicht öffentliche Objekte möglicherweise nicht mehr möglich. Weitere Informationen und Vorschläge zu Problemumgehungen für dieses Problem finden Sie in der Cloud Storage-Fehlerbehebungsanleitung.

Beachten Sie in der Beispielkonfiguration, wie Dienste basierend auf den zugrunde liegenden Daten, Metadaten oder Konfigurationen in Vertraulichkeitsstufen gruppiert werden. Diese Ebenen veranschaulichen die folgende empfohlene Detaillierungsgrad des Audit-Loggings für den Datenzugriff:

• Authentifizierungs- und Autorisierungsdienste: Für diese Dienststufe empfehlen wir, alle Datenzugriffsvorgänge zu prüfen. Mit dieser Prüfungsstufe können Sie den Zugriff auf Ihre vertraulichen Schlüssel, Secrets und IAM-Richtlinien überwachen. Durch das Überwachen dieses Zugriffs können Sie möglicherweise MITRE-ATT&CK-Taktiken wie Erkennung, Anmeldedatenzugriff und Rechteausweitung erkennen.
• Speicherdienste: Für diese Dienststufe empfehlen wir, Datenzugriffsvorgänge zu prüfen, die von Nutzern bereitgestellte Daten umfassen. Diese Prüfungsstufe hilft Ihnen, den Zugriff auf Ihre wertvollen und vertraulichen Daten zu überwachen. Mit Überwachen von diesem Zugriff können Sie möglicherweise MITRE-ATT&CK-Taktiken wie die Erfassung und Exfiltration Ihrer Daten erkennen.
• Infrastrukturdienste: Für diese Dienststufe empfehlen wir, Datenzugriffsvorgänge zu prüfen, die Metadaten oder Konfigurationsinformationen enthalten. Diese Prüfungsstufe hilft Ihnen, das Scannen der Infrastrukturkonfiguration zu überwachen. Mit Überwachen von diesem Zugriff können Sie möglicherweise MITRE-ATT&CK-Taktiken wie Entdeckung bezüglich Ihrer Arbeitslasten erkennen.

Logs weiterleiten

Nachdem die Logs identifiziert und aktiviert wurden, werden im nächsten Schritt die Logs an ein Ziel weitergeleitet. Das Weiterleitungsziel, der Pfad und die Komplexität variieren je nach den verwendeten Analysetools, wie im folgenden Diagramm dargestellt.

Das Diagramm zeigt die folgenden Weiterleitungsoptionen:

• Wenn Sie Log Analytics verwenden, benötigen Sie eine aggregierte Senke, um die Logs in Ihrer gesamten Google Cloud-Organisation in einem einzigen Cloud Logging-Bucket zusammenzufassen.

• Wenn Sie BigQuery verwenden, benötigen Sie eine aggregierte Senke zum Zusammenfassen der Logs aus Ihrer Google Cloud-Organisation in einem einzigen BigQuery-Dataset.

• Wenn Sie Google Security Operations verwenden und diese vordefinierte Teilmenge von Logs Ihren Anforderungen an die Sicherheitsanalyse entspricht, können Sie diese Logs mithilfe der integrierten Google Security Operations-Aufnahme automatisch in Ihrem Google Security Operations-Konto zusammenfassen. Sie können sich diesen vordefinierten Satz von Logs auch in der Spalte Exportierbar direkt nach Google Security Operations des Logbereichstools ansehen. Weitere Informationen zum Exportieren dieser vordefinierten Logs finden Sie unter Google Cloud-Logs in Google Security Operations aufnehmen.

• Wenn Sie BigQuery oder ein SIEM-Lösung eines Drittanbieters verwenden oder einen erweiterten Satz von Logs in Google Security Operations exportieren möchten, zeigt das Diagramm, dass ein Zwischenschritt erforderlich ist zwischen dem aktivieren und analysieren von Logs. Dieser zusätzliche Schritt besteht aus der Konfiguration einer aggregierten Senke, die die ausgewählten Logs entsprechend weiterleitet. Wenn Sie BigQuery verwenden, benötigen Sie lediglich diese Senke, um die Logs an BigQuery weiterzuleiten. Wenn Sie ein SIEM-Tool eines Drittanbieters verwenden, muss die Senke die ausgewählten Logs in Pub/Sub oder Cloud Storage aggregieren, bevor die Logs in Ihr Analysetool importiert werden können.

Hinweis: Wenn Sie Log Analytics (oder BigQuery) verwenden und bereits eine aggregierte Senke zum Speichern von Logs in einem zentralen Logging-Bucket (oder einem zentralen BigQuery-Dataset) konfiguriert haben, können Sie diesen Abschnitt des Leitfadens überspringen und stattdessen einfach die Senke mit dem Logfilter aus dem vorherigen Abschnitt aktualisieren. Führen Sie bei Log Analytics ein Upgrade Ihres vorhandenen Log-Buckets für die Verwendung von Log Analytics durch.

Die Weiterleitungsoptionen für Google Security Operations und ein SIEM-Tool eines Drittanbieters werden in dieser Anleitung nicht behandelt. In den folgenden Abschnitten werden die detaillierten Schritte zum Weiterleiten von Logs an Log Analytics oder BigQuery beschrieben:

1. Einzelnes Ziel einrichten
2. Aggregierte Logsenke erstellen
3. Zugriff auf die Senke gewähren
4. Lesezugriff auf das Ziel konfigurieren
5. Prüfen, ob die Logs an das Ziel weitergeleitet werden

Einzelnes Ziel einrichten

Loganalyse

Hinweis: Sie können diesen Schritt überspringen, wenn Sie einen Cloud Logging-Bucket verwenden, der bereits in dem Google Cloud-Projekt vorhanden ist, in dem Sie die Logs aggregieren möchten. Sie können den _Default-Bucket verwenden. Wir empfehlen jedoch, in diesen Fall einen separaten Bucket zu erstellen.

1. Öffnen Sie die Google Cloud Console in dem Google Cloud-Projekt, in dem Sie Logs zusammenfassen möchten.

   Zur Google Cloud Console

2. Führen Sie in einem Cloud Shell-Terminal folgenden gcloud-Befehl aus, um einen Log-Bucket zu erstellen:

   gcloud logging buckets create BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID
   

   Dabei gilt:

   • PROJECT_ID: die ID des Google Cloud-Projekts, in dem die aggregierten Logs gespeichert werden.
   • BUCKET_NAME: der Name des neuen Logging-Buckets.

   • BUCKET_LOCATION: der geografische Standort des neuen Logging-Buckets. Die unterstützten Standorte sind global, us und eu. Weitere Informationen zu diesen Speicherregionen finden Sie unter Unterstützte Regionen. Wenn Sie keinen Standort angeben, wird die Region global verwendet. Dies bedeutet, dass sich die Logs in einer beliebigen der Regionen befinden können.

     Hinweis: Nachdem Sie den Bucket erstellt haben, können Sie die Region des Buckets nicht mehr ändern.

3. Prüfen Sie, ob der Bucket erstellt wurde:

   gcloud logging buckets list --project=PROJECT_ID
   

4. (Optional) Legen Sie die Aufbewahrungsdauer der Logs im Bucket fest. Im folgenden Beispiel wird die Aufbewahrungsdauer von im Bucket gespeicherten Logs auf 365 Tage verlängert:

   gcloud logging buckets update BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID \
     --retention-days=365
   

5. Führen Sie diese Schritte aus, um den neuen Bucket für die Verwendung von Log Analytics zu aktualisieren.

BigQuery

1. Öffnen Sie die Google Cloud Console in dem Google Cloud-Projekt, in dem Sie Logs zusammenfassen möchten.

   Zur Google Cloud Console

2. Führen Sie in einem Cloud Shell-Terminal folgenden bq mk-Befehl aus, um ein Dataset zu erstellen:

   bq --location=DATASET_LOCATION mk \
       --dataset \
       --default_partition_expiration=PARTITION_EXPIRATION \
       PROJECT_ID:DATASET_ID
   

   Dabei gilt:

   • PROJECT_ID: die ID des Google Cloud-Projekts, in dem die aggregierten Logs gespeichert werden.
   • DATASET_ID: die ID des neuen BigQuery-Datasets.

   • DATASET_LOCATION: der geografische Standort des Datasets. Nachdem ein Dataset erstellt wurde, kann der Standort nicht mehr geändert werden.

     Hinweis: Wenn Sie als Dataset-Standort EU oder eine Region in der EU auswählen, werden Ihre grundlegenden BigQuery-Kundendaten in der EU gespeichert. Grundlegende BigQuery-Kundendaten sind in den dienstspezifischen Nutzungsbedingungen definiert.

   • PARTITION_EXPIRATION: die Standardlebensdauer (in Sekunden) der Partitionen in den partitionierten Tabellen, die von der Logsenke erstellt werden. Die Logsenke konfigurieren Sie im nächsten Abschnitt. In der von Ihnen konfigurierten Logsenke werden partitionierte Tabellen verwendet, die nach dem Zeitstempel des Logeintrags partitioniert sind. Partitionen (einschließlich zugehöriger Logeinträge) werden PARTITION_EXPIRATION Sekunden nach dem Datum der Partition gelöscht.

     Best Practice: Legen Sie das Attribut für den Standardpartitionsablauf des Datasets anhand Ihrer Logaufbewahrungsanforderungen fest, damit ältere Logs veralten und ablaufen. Dies ist während oder nach der Erstellung des Datasets möglich. Auf diese Weise können Sie Logs so lange wie nötig aufbewahren und gleichzeitig die Gesamtgröße des Logspeichers und die damit verbundenen Kosten begrenzen. Wenn Sie detailliertere Aufbewahrungsanforderungen basierend auf dem Logtyp haben, können Sie dieses Attribut auf Tabellenebene überschreiben, nachdem die Logsenke mit dem Weiterleiten von Logs begonnen und die entsprechenden partitionierten Tabellen erstellt hat. Beispiel: Sie müssen Cloud-Audit-Log-Daten drei Jahre lang aufbewahren, aber VPC-Flusslogs und Logs für Firewallregeln müssen nur 90 Tage lang aufbewahrt werden. Wenn Sie keine Standardablaufzeit für Partitionen auf Dataset-Ebene und keine Ablaufzeit für Partitionen beim Erstellen der Tabelle festlegen, sind Partitionen unbegrenzt gültig.

Aggregierte Logsenke erstellen

Sie leiten Ihre Organisationslogs an Ihr Ziel weiter, indem Sie eine aggregierte Senke auf Organisationsebene erstellen. Konfigurieren Sie die Senke mit dem vom Logbereichstool generierten Logfilter, um alle im Logbereichstool ausgewählten Logs einzuschließen.

Hinweis: Wenn Sie Logs an dieses neue Ziel weiterleiten, bedeutet das nicht, dass Ihre Logs an dieses Ziel umgeleitet werden. Stattdessen werden Ihre Logs zweimal gespeichert: im übergeordneten Google Cloud-Projekt sowie im neuen Ziel. Um dieses doppelte Speichern von Logs zu vermeiden, fügen Sie einen Ausschlussfilter in der _Default-Senke jedes untergeordneten Google Cloud-Projekts in Ihrer Organisation hinzu. Wenn Sie verhindern möchten, dass Logs in die _Default-Senken von zukünftigen Google Cloud-Projekten in Ihrer Organisation aufgenommen werden, deaktivieren Sie die _Default-Senke in der Standardeinstellungen Ihrer Organisation.

Loganalyse

1. Führen Sie in einem Cloud Shell-Terminal folgenden gcloud-Befehl aus, um eine aggregierte Senke auf Organisationsebene zu erstellen:

   gcloud logging sinks create SINK_NAME \
     logging.googleapis.com/projects/PROJECT_ID/locations/BUCKET_LOCATION/buckets/BUCKET_NAME \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --include-children
   

   Ersetzen Sie Folgendes:

   • SINK_NAME: der Name der Senke, die die Logs weiterleitet.
   • PROJECT_ID: die ID des Google Cloud-Projekts, in dem die aggregierten Logs gespeichert werden.
   • BUCKET_LOCATION: der Speicherort des Logging-Buckets, den Sie für die Logspeicherung erstellt haben.
   • BUCKET_NAME: der Name des Logging-Buckets, den Sie für die Logspeicherung erstellt haben.
   • LOG_FILTER: der Logfilter, den Sie aus dem Logbereichstool gespeichert haben.
   • ORGANIZATION_ID: die Ressourcen-ID für Ihre Organisation.

   Das Flag --include-children ist wichtig, damit Logs aus allen Google Cloud-Projekten innerhalb Ihrer Organisation berücksichtigt werden. Weitere Informationen finden Sie unter Logs auf Organisationsebene sortieren und an unterstützte Ziele weiterleiten.

2. Prüfen Sie, ob die Senke erstellt wurde:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Rufen Sie den Namen des Dienstkontos ab, das der soeben erstellten Senke zugeordnet ist:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   Die Ausgabe sieht dann ungefähr so aus:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Kopieren Sie den gesamten String für writerIdentity ab serviceAccount:. Diese Kennzeichnung ist das Dienstkonto der Senke. Solange Sie diesem Dienstkonto keinen Schreibzugriff auf den Log-Bucket gewähren, schlägt die Logweiterleitung von dieser Senke fehl. Sie gewähren im nächsten Abschnitt Schreibzugriff auf die Autorenidentität der Senke.

BigQuery

1. Führen Sie in einem Cloud Shell-Terminal folgenden gcloud-Befehl aus, um eine aggregierte Senke auf Organisationsebene zu erstellen:

   gcloud logging sinks create SINK_NAME \
     bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --use-partitioned-tables \
     --include-children
   

   Ersetzen Sie Folgendes:

   • SINK_NAME: der Name der Senke, die die Logs weiterleitet.
   • PROJECT_ID: die ID des Google Cloud-Projekts, in dem Sie die Logs zusammenfassen möchten.
   • DATASET_ID: die ID des von Ihnen erstellten BigQuery-Datasets.
   • LOG_FILTER: der Logfilter, den Sie aus dem Logbereichstool gespeichert haben.
   • ORGANIZATION_ID: die Ressourcen-ID für Ihre Organisation.

   Das Flag --include-children ist wichtig, damit Logs aus allen Google Cloud-Projekten innerhalb Ihrer Organisation berücksichtigt werden. Weitere Informationen finden Sie unter Logs auf Organisationsebene sortieren und an unterstützte Ziele weiterleiten.

   Das Flag --use-partitioned-tables ist wichtig, damit Daten basierend auf dem Feld timestamp des Logeintrags nach Tag partitioniert werden. Dies vereinfacht die Abfrage der Daten und senkt die Abfragekosten, da die Menge der durch Abfragen gescannten Daten reduziert wird. Ein weiterer Vorteil partitionierter Tabellen ist, dass Sie auf Dataset-Ebene einen Standardablauf für Partitionen festlegen können, um Ihre Aufbewahrungsanforderungen für Logs zu erfüllen. Sie haben bereits einen Standardpartitionsablauf festgelegt, als Sie das Dataset-Ziel im vorherigen Abschnitt erstellt haben. Sie können auch einen Partitionsablauf auf der Ebene einzelner Tabellen festlegen, um eine detaillierte Kontrolle über die Datenaufbewahrung basierend auf dem Logtyp zu ermöglichen.

2. Prüfen Sie, ob die Senke erstellt wurde:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Rufen Sie den Namen des Dienstkontos ab, das der soeben erstellten Senke zugeordnet ist:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   Die Ausgabe sieht dann ungefähr so aus:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Kopieren Sie den gesamten String für writerIdentity ab serviceAccount:. Diese Kennzeichnung ist das Dienstkonto der Senke. Solange Sie diesem Dienstkonto keinen Schreibzugriff auf das BigQuery-Dataset gewähren, schlägt die Logweiterleitung von dieser Senke fehl. Sie gewähren im nächsten Abschnitt Schreibzugriff auf die Autorenidentität der Senke.

Zugriff auf die Senke gewähren

Nachdem Sie die Logsenke erstellt haben, müssen Sie ihr Schreibzugriff auf das Ziel gewähren, sei es der Logging-Bucket oder das BigQuery-Dataset.

Hinweis: Um Logs an eine durch einen Dienstperimeter geschützte Ressource weiterzuleiten, müssen Sie das Dienstkonto für diese Senke einer Zugriffsebene hinzufügen und es dann dem Zieldienstperimeter zuweisen. Dies ist für nicht aggregierte Senken nicht erforderlich. Weitere Informationen finden Sie unter VPC Service Controls: Cloud Logging.

Loganalyse

So fügen Sie dem Dienstkonto der Senke die Berechtigungen hinzu:

1. Öffnen Sie in der Google Cloud Console die Seite „IAM“.

   Zur IAM-Seite

2. Achten Sie darauf, dass Sie das Google Cloud-Zielprojekt ausgewählt haben, das den Logging-Bucket enthält, den Sie für den zentralen Logspeicher erstellt haben.

3. Klicken Sie auf Zugriff gewähren.

4. Geben Sie im Feld Neue Hauptkonten das Dienstkonto der Senke ohne das Präfix serviceAccount: ein. Wie bereits erwähnt, stammt diese Identität aus dem Feld writerIdentity, das Sie im vorherigen Abschnitt nach dem Erstellen der Senke abgerufen haben.

5. Wählen Sie im Drop-down-Menü Rolle auswählen die Option Logs Bucket Writer.

6. Klicken Sie auf IAM-Bedingung hinzufügen, um den Zugriff des Dienstkontos auf den von Ihnen erstellten Log-Bucket einzuschränken.

7. Geben Sie für die Bedingung einen Titel und eineBeschreibung ein.

8. Wählen Sie im Drop-down-Menü Bedingungstyp die Option Ressource > Name.

9. Wählen Sie im Drop-down-Menü Operator die Option Endet mit.

10. Geben Sie im Feld Wert den Standort und Namen des Buckets so ein:

    locations/BUCKET_LOCATION/buckets/BUCKET_NAME
    

11. Klicken Sie auf Speichern, um die Bedingung hinzuzufügen.

12. Klicken Sie auf Speichern, um die Berechtigungen festzulegen.

BigQuery

So fügen Sie dem Dienstkonto der Senke die Berechtigungen hinzu:

1. Wechseln Sie in der Google Cloud Console zu BigQuery:

   BigQuery aufrufen

2. Öffnen Sie das BigQuery-Dataset, das Sie für den zentralen Logspeicher erstellt haben.

3. Klicken Sie im Tab „Dataset-Informationen“ auf das Drop-down-Menü Freigabe und dann auf Berechtigungen.

4. Klicken Sie in der Seitenleiste mit den Dataset-Berechtigungen auf Hauptkonto hinzufügen.

5. Geben Sie im Feld Neue Hauptkonten das Dienstkonto der Senke ohne das Präfix serviceAccount: ein. Wie bereits erwähnt, stammt diese Identität aus dem Feld writerIdentity, das Sie im vorherigen Abschnitt nach dem Erstellen der Senke abgerufen haben.

6. Wählen Sie im Drop-down-Menü Rolle die Option BigQuery-Dateneditor aus.

7. Klicken Sie auf Speichern.

Nachdem Sie Zugriff auf die Senke gewährt haben, werden die Logeinträge in das Senkenziel aufgenommen: den Logging-Bucket oder das BigQuery-Dataset.

Lesezugriff auf das Ziel konfigurieren

Da Ihre Logsenke jetzt Logs aus Ihrer gesamten Organisation an ein einziges Ziel weiterleitet, können Sie in allen diesen Logs suchen. Verwenden Sie IAM-Berechtigungen, um Berechtigungen zu verwalten und bei Bedarf Zugriff zu gewähren.

Loganalyse

So gewähren Sie Zugriff zum Aufrufen und Abfragen der Logs in Ihrem neuen Log-Bucket:

1. Öffnen Sie in der Google Cloud Console die Seite „IAM“.

   Zur IAM-Seite

   Achten Sie darauf, dass Sie das Google Cloud-Projekt ausgewählt haben, das Sie zum Zusammenfassen der Logs verwenden.

2. Klicken Sie auf Hinzufügen.

3. Geben Sie im Feld Neues Hauptkonto Ihr E-Mail-Konto ein.

4. Wählen Sie im Drop-down-Menü Rolle auswählen die Option Logs-Ansicht-Zugriffsfunktion.

   Diese Rolle gibt dem neu hinzugefügten Hauptkonto Lesezugriff auf alle Ansichten für alle Buckets im Google Cloud-Projekt. Um den Zugriff eines Nutzers zu beschränken, fügen Sie eine Bedingung hinzu, durch die der Nutzer nur aus Ihrem neuen Bucket lesen kann.

   1. Klicken Sie auf Bedingung hinzufügen.

   2. Geben Sie für die Bedingung einen Titel und eineBeschreibung ein.

   3. Wählen Sie im Drop-down-Menü Bedingungstyp die Option Ressource > Name.

   4. Wählen Sie im Drop-down-Menü Operator die Option Endet mit.

   5. Geben Sie im Feld Wert den Standort und den Namen des Buckets und die Standard-Logansicht _AllLogs so ein:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      Hinweis: Cloud Logging erstellt automatisch die Ansicht _AllLogs für jeden Bucket, in der alle Logs im Bucket angezeigt werden. Wenn Sie genauer festlegen möchten, welche Logs in diesem Log-Bucket angezeigt und abgefragt werden können, können Sie anstelle von _AllLogs eine benutzerdefinierte Logansicht erstellen und verwenden.

   6. Klicken Sie auf Speichern, um die Bedingung hinzuzufügen.

5. Klicken Sie auf Speichern, um die Berechtigungen festzulegen.

BigQuery

Führen Sie die Schritte im Abschnitt Zugriff auf ein Dataset gewähren der BigQuery-Dokumentation aus, um Zugriff zum Aufrufen und Abfragen der Logs in Ihrem BigQuery-Dataset zu gewähren.

Prüfen, ob die Logs an das Ziel weitergeleitet werden

Loganalyse

Wenn Sie Logs an einen Log-Bucket weiterleiten, der auf Log Analytics aktualisiert wurde, können Sie alle Logeinträge über eine einzige Logansicht mit einem einheitlichen Schema für alle Logtypen aufrufen und abfragen. Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Logs ordnungsgemäß weitergeleitet werden.

1. Rufen Sie in der Google Cloud Console die Seite „Log Analytics“ auf.

   Zu "Log Analytics"

   Achten Sie darauf, dass Sie das Google Cloud-Projekt ausgewählt haben, das Sie zum Zusammenfassen der Logs verwenden.

2. Klicken Sie auf den Tab Logansichten.

3. Maximieren Sie die Logansichten unter dem von Ihnen erstellten Log-Bucket (BUCKET_NAME), wenn sie nicht bereits maximiert sind.

4. Wählen Sie die Standard-Logansicht _AllLogs aus. Sie können jetzt das gesamte Logschema im rechten Bereich prüfen, wie im folgenden Screenshot gezeigt:

   

5. Klicken Sie neben _AllLogs auf Abfrage. Dadurch wird der Abfrageeditor mit einer SQL-Beispielabfrage gefüllt, um kürzlich weitergeleitete Logeinträge abzurufen.

6. Klicken Sie auf Abfrage ausführen, um die weitergeleiteten Logeinträge aufzurufen.

Je nach dem Aktivitätsniveau in Google Cloud-Projekten in Ihrer Organisation müssen Sie möglicherweise einige Minuten warten, bis einige Logs generiert und dann an den Log-Bucket weitergeleitet wurden.

BigQuery

Wenn Sie die Logs an ein BigQuery-Dataset weiterleiten, erstellt Cloud Logging BigQuery-Tabellen, die die Logeinträge enthalten, wie im folgenden Screenshot dargestellt:

Der Screenshot zeigt, wie Cloud Logging jede BigQuery-Tabelle basierend auf dem Namen des Logs, zu dem ein Logeintrag gehört, angibt. Beispiel: Die im Screenshot ausgewählte Tabelle cloudaudit_googleapis_com_data_access enthält Audit-Logs zum Datenzugriff mit der Log-ID cloudaudit.googleapis.com%2Fdata_access. Zusätzlich zum Benennen anhand des entsprechenden Logeintrags wird jede Tabelle auch anhand der Zeitstempel für jeden Logeintrag partitioniert.

Je nach dem Aktivitätsniveau in Google Cloud-Projekten in Ihrer Organisation müssen Sie möglicherweise einige Minuten warten, bis einige Logs generiert und dann an Ihr BigQuery-Dataset weitergeleitet wurden.

Hinweis: Sowohl Logs zur Administratoraktivität als auch Logs zum Datenzugriff werden in BigQuery geladen, wobei das Logeintragsfeld protoPayload in BigQuery in protoPayload_auditlog umbenannt wird. Weitere Informationen zu Schemakonvertierungen von Cloud Logging vor dem Schreiben in BigQuery finden Sie unter Felder in exportierten Audit-Logs.

Logs analysieren

Sie können viele verschiedene Abfragen für Ihre Audit- und Plattformlogs ausführen. Die folgende Liste enthält einige Beispielsicherheitsfragen, die Sie bei Ihren eigenen Logs stellen können. Für jede Frage in dieser Liste gibt es zwei Versionen der entsprechenden CSA-Abfrage: eine für Log Analytics und eine für BigQuery. Verwenden Sie die Abfrageversion, die mit dem zuvor von Ihnen eingerichteten Senkenziel übereinstimmt.

Loganalyse

Bevor Sie eine der folgenden SQL-Abfragen verwenden, ersetzen Sie MY_PROJECT_ID durch die ID des Google Cloud-Projekts, in dem Sie den Log-Bucket erstellt haben (also PROJECT_ID), und MY_DATASET_ID durch die Region und den Namen dieses Log-Buckets (BUCKET_LOCATION.BUCKET_NAME).

Zu "Log Analytics"

BigQuery

Bevor Sie eine der folgenden SQL-Abfragen verwenden, ersetzen Sie MY_PROJECT_ID durch die ID des Google Cloud-Projekts, in dem Sie das BigQuery-Dataset erstellt haben (also PROJECT_ID)), und MY_DATASET_ID durch den Namen dieses Datasets, also DATASET_ID.

BigQuery aufrufen

1. Fragen zur Anmeldung und zum Zugriff
   • Wird ein verdächtiger Anmeldeversuch von Google Workspace gemeldet?
   • Gibt es übermäßige Anmeldeversuche einer Nutzeridentität?
   • Gibt es Zugriffsversuche, die gegen VPC Service Controls verstoßen?
   • Gibt es Zugriffsversuche, die gegen die Zugriffssteuerungen von Identity-Aware Proxy verstoßen?
2. Fragen zu Berechtigungsänderungen
   • Wurde ein Nutzer zu Gruppen mit umfangreichen Berechtigungen hinzugefügt?
   • Wurden Berechtigungen über ein Dienstkonto gewährt?
   • Gibt es Dienstkonten oder Schlüssel, die von einer nicht genehmigten Identität erstellt wurden?
   • Wurde ein Nutzer zu einer IAM-Richtlinie hinzugefügt oder daraus entfernt?
3. Fragen zur Bereitstellung von Aktivitäten
   • Wurden Änderungen an den Logging-Einstellungen vorgenommen?
   • Sind VPC-Flusslogs deaktiviert?
   • Wurde in der letzten Woche eine ungewöhnliche Anzahl von Firewallregeln geändert?
   • Wurden in der letzten Woche VMs gelöscht?
4. Fragen zur Arbeitslastnutzung
   • Gibt es in der letzten Woche eine ungewöhnlich hohe API-Nutzung durch eine Nutzeridentität?
   • Wie hoch war die Autoscaling-Nutzung pro Tag im letzten Monat?
5. Fragen zum Datenzugriff
   • Welche Nutzer haben in der letzten Woche am häufigsten auf Daten zugegriffen?
   • Welche Nutzer haben letzten Monat auf die Daten in der Tabelle "accounts" zugegriffen?
   • Auf welche Tabellen wird am häufigsten zugegriffen und von wem?
   • Was sind die Top-10-Abfragen für BigQuery der vergangenen Woche?
   • Was sind die häufigsten Aktionen, die im Datenzugriffslog des letzten Monats aufgezeichnet wurden?
6. Fragen zur Netzwerksicherheit
   • Gibt es Verbindungen von einer neuen IP-Adresse zu einem bestimmten Subnetzwerk?
   • Wurden Verbindungen durch Google Cloud Armor blockiert?
   • Gibt es einen von Cloud IDS erkannten Virus oder Malware mit hohem Schweregrad?
   • Was sind die häufigsten abgefragten Cloud DNS-Domains aus Ihrem VPC-Netzwerk?

Fragen zur Anmeldung und zum Zugriff

Mit diesen Beispielabfragen wird eine Analyse durchgeführt, um verdächtige Anmeldeversuche oder Versuche des ersten Zugriffs auf Ihre Google Cloud-Umgebung zu erkennen.

Hinweis: Die Anmeldeaktivität wird in Cloud Identity-Logs erfasst, die im Google Workspace Login Audit enthalten sind. Damit Sie Anmeldeaktivitäten analysieren und einige der Abfragen in diesem Abschnitt verwenden können, müssen Sie die Google Workspace-Datenfreigabe für Google Cloud aktivieren. Weitere Informationen zum Freigeben von Google Workspace-Audit-Logs für Google Cloud finden Sie unter Audit-Logs für Google Workspace ansehen und verwalten.

Wird ein verdächtiger Anmeldeversuch von Google Workspace gemeldet?

Bei der Suche in Cloud Identity-Logs, die Teil des Google Workspace Login Audits sind, erkennt die folgende Abfrage verdächtige Anmeldeversuche, die von Google Workspace gemeldet wurden. Diese Anmeldeversuche können über die Google Cloud Console, die Admin-Konsole oder die gcloud CLI erfolgen.

Loganalyse

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name, parameter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter.name) = "is_suspicious"
  AND JSON_VALUE(parameter.boolValue) = "true"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND protopayload_auditlog.metadataJson IS NOT NULL
  AND protopayload_auditlog.serviceName = "login.googleapis.com"
  AND protopayload_auditlog.methodName = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter, '$.name') = "is_suspicious"
  AND JSON_VALUE(parameter, '$.boolValue') = "true"

Gibt es übermäßige Anmeldeversuche einer Nutzeridentität?

Durch die Suche in Cloud Identity-Logs, die Teil des Google Workspace Login Audits sind, erkennt die folgende Abfrage Nutzer, die innerhalb der letzten 24 Stunden mindestens drei aufeinanderfolgende Anmeldefehler hatten.

Loganalyse

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND protopayload_auditlog.serviceName="login.googleapis.com"
  AND protopayload_auditlog.methodName="google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

Gibt es Zugriffsversuche, die gegen VPC Service Controls verstoßen?

Durch das Analysieren von Audit-Logs zu Richtlinienverstößen aus Cloud-Audit-Logs erkennt die folgende Abfrage Zugriffsversuche, die von VPC Service Controls blockiert werden. Abfrageergebnisse können auf potenzielle schädliche Aktivitäten wie Zugriffsversuche aus nicht autorisierten Netzwerken mit gestohlenen Anmeldedaten hinweisen.

Loganalyse

SELECT
  timestamp,
  log_name,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  JSON_VALUE(proto_payload.audit_log.metadata.violationReason) as violationReason, 
  IF(JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations) IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].targetResource),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].targetResource)
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].servicePerimeter),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].servicePerimeter)
  ) AS  servicePerimeter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND JSON_VALUE(proto_payload.audit_log.metadata, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  JSON_VALUE(protopayload_auditlog.metadataJson, '$.violationReason') as violationReason, 
  IF(JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations') IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].targetResource'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].targetResource')
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].servicePerimeter'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].servicePerimeter')
  ) AS  servicePerimeter
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_policy`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND JSON_VALUE(protopayload_auditlog.metadataJson, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

Gibt es Zugriffsversuche, die gegen die IAP-Zugriffssteuerung verstoßen?

Durch die Analyse von Logs des externen Application Load Balancers erkennt die folgende Abfrage Zugriffsversuche, die von IAP blockiert wurden. Alle Abfrageergebnisse weisen möglicherweise auf einen ersten Zugriffsversuch oder einen Sicherheitslücken-Exploit hin.

Loganalyse

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

Fragen zu Berechtigungsänderungen

Mit diesen Beispielabfragen wird eine Analyse der Administratoraktivität ausgeführt, die Berechtigungen ändert, einschließlich Änderungen an IAM-Richtlinien, Gruppen und Gruppenmitgliedschaften, Dienstkonten und allen zugehörigen Schlüsseln. Solche Berechtigungsänderungen bieten möglicherweise einen hohen Zugriff auf sensible Daten oder Umgebungen.

Hinweis: Gruppenänderungen werden im Google Workspace-Administrator-Audit erfasst. Damit Sie die Aktivitäten von Gruppenänderungen analysieren und einige der Abfragen in diesem Abschnitt verwenden können, müssen Sie die Google Workspace-Datenfreigabe für Google Cloud aktivieren. Weitere Informationen zum Freigeben von Google Workspace-Audit-Logs für Google Cloud finden Sie unter Audit-Logs für Google Workspace ansehen und verwalten.

Wurde ein Nutzer zu Gruppen mit umfangreichen Berechtigungen hinzugefügt?

Durch das Analysieren von Audit-Logs zu Google Workspace-Admin-Audits erkennt die folgende Abfrage Nutzer, die einer der stark privilegierten Gruppen hinzugefügt wurden, die in der Abfrage aufgeführt sind. Mit dem regulären Ausdruck in der Abfrage definieren Sie, welche Gruppen (z. B. [e-mail] oder [e-mail]) überwacht werden sollen. Abfrageergebnisse können auf eine schädliche oder versehentliche Rechteausweitung hinweisen.

Loganalyse

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "USER_EMAIL") AS user_email,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "GROUP_EMAIL") AS group_email,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND proto_payload.audit_log.service_name = "admin.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
    WHERE
      JSON_VALUE(x.name) = "GROUP_EMAIL"
      AND REGEXP_CONTAINS(JSON_VALUE(x.value), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "USER_EMAIL") AS userEmail,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "GROUP_EMAIL") AS groupEmail,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND protopayload_auditlog.serviceName = "admin.googleapis.com"
  AND protopayload_auditlog.methodName = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
    WHERE
      JSON_VALUE(x, '$.name') = 'GROUP_EMAIL'
      AND REGEXP_CONTAINS(JSON_VALUE(x, '$.value'), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

Wurden Berechtigungen über ein Dienstkonto gewährt?

Durch das Analysieren von Audit-Logs zur Administratoraktivität aus Cloud-Audit-Logs erkennt die folgende Abfrage alle Berechtigungen, die einem Hauptkonto über ein Dienstkonto gewährt wurden. Beispiele für Berechtigungen, die erteilt werden können, sind die Möglichkeit, die Identität dieses Dienstkontos zu übernehmen oder Dienstkontoschlüssel zu erstellen. Alle Abfrageergebnisse können auf eine Instanzausweitung oder das Risiko von Datenlecks hindeuten.

Loganalyse

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email as grantor,
  JSON_VALUE(bindingDelta.member) as grantee,
  JSON_VALUE(bindingDelta.role) as role,
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.service_data.policyDelta.bindingDeltas)) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND (
    (resource.type = "service_account"
    AND proto_payload.audit_log.method_name LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND proto_payload.audit_log.method_name = "SetIamPolicy"
    AND JSON_VALUE(bindingDelta.role) LIKE "roles/iam.serviceAccount%")
  )
  AND JSON_VALUE(bindingDelta.action) = "ADD"
  -- Principal (grantee) exclusions
  AND JSON_VALUE(bindingDelta.member) NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail as grantor,
  bindingDelta.member as grantee,
  bindingDelta.role,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName,
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND (
    (resource.type = "service_account"
    AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND protopayload_auditlog.methodName = "SetIamPolicy"
    AND bindingDelta.role LIKE "roles/iam.serviceAccount%")
  )
  AND bindingDelta.action = 'ADD'
  -- Principal (grantee) exclusions
  AND bindingDelta.member NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

Gibt es Dienstkonten oder Schlüssel, die von einer nicht genehmigten Identität erstellt wurden?

Durch das Analysieren von Audit-Logs zur Administratoraktivität erkennt die folgende Abfrage alle Dienstkonten oder Schlüssel, die manuell von einem Nutzer erstellt wurden. Beispielsweise können Sie eine Best Practice befolgen, um nur das Erstellen von Dienstkonten durch ein genehmigtes Dienstkonto als Teil eines automatisierten Workflows zu erlauben. Daher wird die Erstellung von Dienstkonten außerhalb dieses Workflows als nicht konform und möglicherweise schädlich eingestuft.

Loganalyse

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(proto_payload.audit_log.response.email) as service_account_email
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="service_account"
  AND proto_payload.audit_log.method_name LIKE "%CreateServiceAccount%"
  AND proto_payload.audit_log.authentication_info.principal_email NOT LIKE "%.gserviceaccount.com"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  JSON_VALUE(protopayload_auditlog.responseJson, "$.email") as serviceAccountEmail
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "%CreateServiceAccount%"
  AND protopayload_auditlog.authenticationInfo.principalEmail NOT LIKE "%.gserviceaccount.com"

Wurde ein Nutzer zu einer IAM-Richtlinie hinzugefügt oder daraus entfernt?

Durch Durchsuchen von Audit-Logs zur Administratoraktivität erkennt die folgende Abfrage alle Nutzer- oder Gruppenzugriffsänderungen für eine IAP-gesicherte Ressource, z. B. einen Compute Engine-Backend-Dienst. Bei der folgenden Abfrage wird in allen IAM-Richtlinienaktualisierungen nach IAP-Ressourcen gesucht, die die IAM-Rolle roles/iap.httpsResourceAccessor enthalten Diese Rolle bietet Berechtigungen für den Zugriff auf die HTTPS-Ressource oder den Backend-Dienst. Alle Abfrageergebnisse weisen möglicherweise darauf hin, dass versucht wird, die Verteidigung eines Backend-Dienstes zu umgehen, der im Internet zugänglich sein könnte.

Loganalyse

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  resource.type,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.response, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND proto_payload.audit_log.service_name = "iap.googleapis.com"
  AND proto_payload.audit_log.method_name LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  resource.type,
  protopayload_auditlog.resourceName,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.responseJson, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND protopayload_auditlog.serviceName = "iap.googleapis.com"
  AND protopayload_auditlog.methodName LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

Fragen zur Bereitstellungsaktivität

Mit diesen Beispielabfragen wird eine Analyse durchgeführt, um verdächtige oder anomale Administratoraktivitäten wie die Bereitstellung und Konfiguration von Ressourcen zu erkennen.

Wurden Änderungen an den Logging-Einstellungen vorgenommen?

Durch Durchsuchen von Audit-Logs zur Administratoraktivität erkennt die folgende Abfrage alle Änderungen, die an Logging-Einstellungen vorgenommen wurden. Mit den Logging-Einstellungen von Monitoring können Sie versehentliche oder böswillige Deaktivierungen von Audit-Logs und ähnlichen Techniken der Verteidigungswehr erkennen.

Loganalyse

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.service_name = "logging.googleapis.com"
  AND log_id = "cloudaudit.googleapis.com/activity"

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  protopayload_auditlog.serviceName = "logging.googleapis.com"

Sind VPC-Flusslogs aktiv deaktiviert?

Durch die Suche nach Audit-Logs zur Administratoraktivität erkennt die folgende Abfrage jedes Subnetz, dessen VPC-Flusslogs aktiv deaktiviert wurden Mit den Einstellungen für das Monitoring von VPC-Flusslogs können Sie versehentliche oder böswillige Deaktivierungen von VPC-Flusslogs und ähnlichen Techniken zum Schutz vor Angriffen erkennen.

Loganalyse

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.method_name = "v1.compute.subnetworks.patch" 
  AND (
    JSON_VALUE(proto_payload.audit_log.request, "$.logConfig.enable") = "false"
    OR JSON_VALUE(proto_payload.audit_log.request, "$.enableFlowLogs") = "false"
  )

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
protopayload_auditlog.methodName = "v1.compute.subnetworks.patch" 
AND JSON_VALUE(protopayload_auditlog.requestJson, "$.logConfig.enable") = "false"

Gibt es in der letzten Woche eine ungewöhnlich hohe Anzahl von Firewallregeln, die geändert wurden?

Durch die Suche nach Audit-Logs zur Administratoraktivität erkennt die folgende Abfrage eine ungewöhnlich hohe Anzahl an Änderungen an Firewallregeln an einem bestimmten Tag in der vergangenen Woche. Um festzustellen, ob ein Ausreißer vorhanden ist, führt die Abfrage eine statistische Analyse der täglichen Anzahl von Änderungen an Firewallregeln aus. Durchschnitts- und Standardabweichungen werden für jeden Tag berechnet. Dazu werden die vorherigen Tageszahlen mit einem Lookback-Window von 90 Tagen berücksichtigt. Ein Ausreißer wird berücksichtigt, wenn die Anzahl der Tage mehr als zwei Standardabweichungen über dem Mittelwert liegt. Die Abfrage, einschließlich des Standardabweichungsfaktors und der Lookback-Windows, können alle so konfiguriert werden, dass sie auf Ihr Cloudbereitstellungs-Aktivitätsprofil passen und falsch positive Ergebnisse minimieren.

Loganalyse

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email IGNORE NULLS) AS actors,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
      AND proto_payload.audit_log.method_name LIKE "v1.compute.firewalls.%"
      AND proto_payload.audit_log.method_name NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
    GROUP BY
      day
  )
)
WHERE
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    ARRAY_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail IGNORE NULLS) AS actors,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND protopayload_auditlog.methodName LIKE "v1.compute.firewalls.%"
    AND protopayload_auditlog.methodName NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
  GROUP BY
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

Wurden in der letzten Woche VMs gelöscht?

Durch Suchen in den Audit-Logs zur Administratoraktivität werden in der folgenden Abfrage alle Compute Engine-Instanzen aufgelistet, die in der letzten Woche gelöscht wurden. Mit dieser Abfrage können Sie Löschvorgänge für Ressourcen prüfen und potenzielle schädliche Aktivitäten erkennen.

Loganalyse

SELECT
  timestamp,
  JSON_VALUE(resource.labels.instance_id) AS instance_id,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance"
  AND proto_payload.audit_log.method_name = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  instance_id
LIMIT
  1000

BigQuery

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance"
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  resource.labels.instance_id
LIMIT
  1000

Fragen zur Arbeitslastnutzung

Mit diesen Beispielabfragen wird eine Analyse durchgeführt, um herauszufinden, wer und was Ihre Cloud-Arbeitslasten und APIs verbraucht. Außerdem können Sie damit potenzielles internes oder externes Verhalten erkennen.

Gibt es in der letzten Woche eine ungewöhnlich hohe API-Nutzung durch eine Nutzeridentität?

Durch die Analyse aller Cloud-Audit-Logs erkennt die folgende Abfrage eine ungewöhnlich hohe API-Nutzung durch eine Nutzeridentität an einem beliebigen Tag der letzten Woche. Eine derart hohe Nutzung kann ein Indikator für einen potenziellen API-Missbrauch, Insiderbedrohungen oder gehackte Anmeldedaten sein. Um festzustellen, ob ein Ausreißer vorhanden ist, führt diese Abfrage eine statistische Analyse der täglichen Anzahl von Aktionen pro Hauptkonto durch. Durchschnitts- und Standardabweichungen werden für jeden Tag und für jedes Hauptkonto berechnet, indem die vorherigen Tageszahlen mit einem Lookback-Window von 60 Tagen überprüft werden. Ein Ausreißer wird berücksichtigt, wenn die tägliche Anzahl für einen Nutzer mehr als drei Standardabweichungen über seinem Mittelwert liegt. Die Abfrage, einschließlich des Standardabweichungsfaktors und der Lookback-Windows, können alle an Ihr Cloud-Bereitstellungsaktivitätsprofil angepasst und falsch positive Ergebnisse minimiert werden.

Loganalyse

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      PARTITION BY principal_email
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      proto_payload.audit_log.authentication_info.principal_email,
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
      AND proto_payload.audit_log.authentication_info.principal_email IS NOT NULL
      AND proto_payload.audit_log.method_name NOT LIKE "storage.%.get"
      AND proto_payload.audit_log.method_name NOT LIKE "v1.compute.%.list"
      AND proto_payload.audit_log.method_name NOT LIKE "beta.compute.%.list"
    GROUP BY
      proto_payload.audit_log.authentication_info.principal_email,
      day
  )
)
WHERE
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    PARTITION BY principalEmail
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail,
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_*`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
    AND protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
    AND protopayload_auditlog.methodName NOT LIKE "storage.%.get"
    AND protopayload_auditlog.methodName NOT LIKE "v1.compute.%.list"
    AND protopayload_auditlog.methodName NOT LIKE "beta.compute.%.list"
  GROUP BY
    protopayload_auditlog.authenticationInfo.principalEmail,
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

Wie hoch war die Autoscaling-Nutzung pro Tag im letzten Monat?

Durch das Analysieren von Audit-Logs zur Administratoraktivität zeigt die folgende Abfrage die Autoscaling-Nutzung nach Tag für den letzten Monat. Mit dieser Abfrage können Muster oder Anomalien identifiziert werden, die eine weitere Untersuchung der Sicherheit rechtfertigen.

Loganalyse

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  proto_payload.audit_log.method_name,
  COUNT(*) AS counter
FROM
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance_group_manager"
  AND log_id = "cloudaudit.googleapis.com/activity"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

BigQuery

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance_group_manager"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

Fragen zum Datenzugriff

Mithilfe dieser Beispielabfragen werden Analysen durchgeführt, um herauszufinden, wer auf Daten in Google Cloud zugreift oder sie ändert.

Welche Nutzer haben in der letzten Woche am häufigsten auf Daten zugegriffen?

Bei der folgenden Abfrage werden die Audit-Logs zum Datenzugriff verwendet, um die Nutzeridentitäten zu finden, die in der vergangenen Woche am häufigsten auf BigQuery-Tabellendaten zugegriffen haben.

Loganalyse

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND log_id = "cloudaudit.googleapis.com/data_access"
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

Welche Nutzer haben letzten Monat auf die Daten in der Tabelle "accounts" zugegriffen?

Bei der folgenden Abfrage werden die Audit-Logs für den Datenzugriff verwendet, um die Nutzeridentitäten zu finden, die im vergangenen Monat am häufigsten eine bestimmte accounts-Tabelle abgefragt haben. Neben den Platzhaltern MY_DATASET_ID und MY_PROJECT_ID für Ihr BigQuery-Exportziel werden in der folgenden Abfrage die Platzhalter DATASET_ID und PROJECT_ID verwendet. Sie müssen die Platzhalter DATASET_ID und PROJECT_ID ersetzen, um die Zieltabelle anzugeben, deren Zugriff analysiert wird, z. B. die Tabelle accounts in diesem Beispiel.

Loganalyse

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(proto_payload.audit_log.authorization_info) authorization_info
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND authorization_info.permission = "bigquery.tables.getData"
  AND authorization_info.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(protopayload_auditlog.authorizationInfo) authorizationInfo
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND authorizationInfo.permission = "bigquery.tables.getData"
  AND authorizationInfo.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

Auf welche Tabellen wird am häufigsten zugegriffen und von wem?

Bei der folgenden Abfrage werden die Audit-Logs für den Datenzugriff verwendet, um die BigQuery-Tabellen mit den am häufigsten gelesenen und geänderten Daten im letzten Monat zu finden. Diese Abfrage ruft die zugeordnete Nutzeridentität sowie eine Aufschlüsselung der Gesamtzahl der Daten ab, die gelesen und geändert wurden.

Loganalyse

SELECT
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.authentication_info.principal_email,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

BigQuery

SELECT
  protopayload_auditlog.resourceName,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

Was sind die Top-10-Abfragen für BigQuery der vergangenen Woche?

Bei der folgenden Abfrage werden die Audit-Logs für den Datenzugriff verwendet, um die am häufigsten verwendeten Abfragen der letzten Woche zu finden. Außerdem werden die entsprechenden Nutzer und referenzierten Tabellen aufgeführt.

Loganalyse

SELECT
  COALESCE(
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

BigQuery

SELECT
  COALESCE(
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobChange") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

Was sind die häufigsten Aktionen, die im Datenzugriffslog des letzten Monats aufgezeichnet wurden?

Bei der folgenden Abfrage werden alle Cloud-Audit-Logs verwendet, um die 100 häufigsten Aktionen zu finden, die im letzten Monat aufgezeichnet wurden.

Loganalyse

SELECT
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND log_id="cloudaudit.googleapis.com/data_access"
GROUP BY
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

BigQuery

SELECT
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

Fragen zur Netzwerksicherheit

Mit diesen Beispielabfragen wird eine Analyse Ihrer Netzwerkaktivität in Google Cloud durchgeführt.

Gibt es Verbindungen von einer neuen IP-Adresse zu einem bestimmten Subnetzwerk?

Die folgende Abfrage erkennt Verbindungen von jeder neuen Quell-IP-Adresse zu einem bestimmten Subnetz, indem sie VPC-Flusslogs analysiert. In diesem Beispiel gilt eine Quell-IP-Adresse als neu, wenn sie in den letzten 24 Stunden zum ersten Mal über ein Lookback-Window von 60 Tagen erfasst wurde. Sie können diese Abfrage für ein Subnetz verwenden und optimieren, das unter die Vorgaben einer bestimmten Complianceanforderung wie PCI fällt.

Loganalyse

SELECT
  JSON_VALUE(json_payload.connection.src_ip) as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT JSON_VALUE(resource.labels.subnetwork_name)) as subnetNames,
  ARRAY_AGG(DISTINCT JSON_VALUE(json_payload.dest_instance.vm_name)) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND JSON_VALUE(json_payload.reporter) = 'DEST'
  AND JSON_VALUE(resource.labels.subnetwork_name) IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

BigQuery

SELECT
  jsonPayload.connection.src_ip as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT resource.labels.subnetwork_name) as subnetNames,
  ARRAY_AGG(DISTINCT jsonPayload.dest_instance.vm_name) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].compute_googleapis_com_vpc_flows`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND jsonPayload.reporter = 'DEST'
  AND resource.labels.subnetwork_name IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

Wurden Verbindungen durch Google Cloud Armor blockiert?

Die folgende Abfrage erkennt potenzielle Exploit-Versuche durch das Analysieren von Logs des externen Application Load Balancers, um eine Verbindung zu finden, die von der in Google Cloud Armor konfigurierten Sicherheitsrichtlinie blockiert wird. Bei dieser Abfrage wird davon ausgegangen, dass Sie eine Google Cloud Armor-Sicherheitsrichtlinie für Ihren externen Application Load Balancer konfiguriert haben. Diese Abfrage setzt auch voraus, dass Sie das Logging des externen Application Load Balancers aktiviert haben, wie in den Anweisungen unter dem Link zum Aktivieren im Logbereichstool angegeben.

Loganalyse

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(json_payload.enforcedSecurityPolicy.name) AS security_policy_name,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "denied_by_security_policy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  jsonpayload_type_loadbalancerlogentry.enforcedsecuritypolicy.name,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "denied_by_security_policy"
ORDER BY
  timestamp DESC

Gibt es einen von Cloud IDS erkannten Virus oder Malware mit hohem Schweregrad?

Die folgende Abfrage zeigt alle von Cloud IDS erkannten Viren oder Malware mit hohem Schweregrad an, indem sie in Cloud IDS Threat Logs sucht. Bei dieser Abfrage wird davon ausgegangen, dass Sie einen Cloud IDS-Endpunkt konfiguriert haben.

Loganalyse

SELECT
  JSON_VALUE(json_payload.alert_time) AS alert_time,
  JSON_VALUE(json_payload.name) AS name,
  JSON_VALUE(json_payload.details) AS details,
  JSON_VALUE(json_payload.application) AS application,
  JSON_VALUE(json_payload.uri_or_filename) AS uri_or_filename,
  JSON_VALUE(json_payload.ip_protocol) AS ip_protocol,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND JSON_VALUE(json_payload.alert_severity) IN ("HIGH", "CRITICAL")
  AND JSON_VALUE(json_payload.type) = "virus"
ORDER BY 
  timestamp DESC

BigQuery

SELECT
  jsonPayload.alert_time,
  jsonPayload.name,
  jsonPayload.details,
  jsonPayload.application,
  jsonPayload.uri_or_filename,
  jsonPayload.ip_protocol
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].ids_googleapis_com_threat`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND jsonPayload.alert_severity IN ("HIGH", "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY 
  timestamp DESC

Was sind die häufigsten abgefragten Cloud DNS-Domains aus Ihrem VPC-Netzwerk?

Bei der folgenden Abfrage werden die zehn häufigsten abgefragten Cloud DNS-Domains von Ihren VPC-Netzwerken in den letzten 60 Tagen aufgelistet. Bei dieser Abfrage wird davon ausgegangen, dass Sie das Cloud DNS-Logging für Ihre VPC-Netzwerke aktiviert haben, wie in den Anweisungen unter dem Link zum Aktivieren im Logbereichstool angegeben.

Loganalyse

SELECT
  JSON_VALUE(json_payload.queryName) AS query_name,
  COUNT(*) AS total_queries
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND log_id="dns.googleapis.com/dns_queries"
GROUP BY
  query_name
ORDER BY
  total_queries DESC
LIMIT
  10

BigQuery

SELECT
 jsonPayload.queryname AS query_name,
 COUNT(*) AS total_queries
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].dns_googleapis_com_dns_queries`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
GROUP BY
 query_name
ORDER BY
 total_queries DESC
LIMIT
 10

Nächste Schritte

• Weitere Informationen zum Streamen von Logs von Google Cloud zu Splunk

• Google Cloud-Logs in Google Security Operations aufnehmen

• Google Cloud-Sicherheitsdaten in Ihr SIEM-System exportieren

• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center