Sicherheitsloganalysen in Google Cloud

Last reviewed 2022-12-14 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.
• Exportieren dieser Logs in das Analysetool Ihrer Wahl, z. B. BigQuery, Chronicle oder Drittanbieter-Lösungen zur Sicherheits- 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, wie diese Sicherheitsdatenquellen in das Sicherheitsanalysetool Ihrer Wahl exportiert werden: BigQuery, Chronicle oder ein SIEM eines Drittanbieters. Schließlich zeigt das Diagramm die Verwendung von CSA-Abfragen mit Ihrem Analysetool, um die exportierten Sicherheitsdatenquellen zu analysieren.

Workflow für Sicherheitsloganalysen

In diesem Abschnitt werden die Schritte zum Einrichten von Sicherheitsloganalysen in Google Cloud beschrieben. Der erste Schritt zum Einrichten von Sicherheitsloganalysen besteht darin, die Logs zu aktivieren, die Sie analysieren möchten. Anschließend müssen Sie die Logs exportieren. Schließlich müssen Sie die Logs analysieren. Das folgende Diagramm enthält eine grafische Darstellung dieser drei Schritte.

Jeder Schritt im Prozess besteht aus verschiedenen Komponenten, wie in der folgenden Liste beschrieben:

• 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 Cloud-Audit-Logging 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 exportieren: Nachdem Sie die zu analysierenden Logs identifiziert und aktiviert haben, besteht der nächste Schritt darin, die Logs in ein Analysetool wie BigQuery, Chronicle oder eine SIEM-technologie eines Drittanbieters zu exportieren.

  Wie Sie Logs exportieren, hängt vom verwendeten Analysetool ab. In dieser Anleitung werden die verschiedenen Exportoptionen kurz beschrieben. Anschließend erfahren Sie, wie Sie Logs mithilfe einer Logsenke in BigQuery exportieren.

• Logs analysieren: Nachdem Sie die Logs in ein Analysetool exportiert haben, müssen Sie als Nächstes eine Analyse der exportierten Logs durchführen, um potenzielle Sicherheitsbedrohungen zu identifizieren. Wie Sie die exportierten Logs analysieren, hängt vom verwendeten Analysetool ab. Wenn Sie ein BigQuery-Dataset verwenden, können Sie die Logs mithilfe von SQL-Abfragen analysieren. Wenn Sie Chronicle 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 entweder in Ihrem BigQuery-Dataset oder Ihrem SIEM-Tool eines Drittanbieters analysieren können. Die in dieser Anleitung bereitgestellten SQL-Abfragen stammen aus dem Projekt Community Security Analytics (CSA). CSA ist ein Open-Source-Satz von grundlegenden Sicherheitsanalysen, die Ihnen eine Grundlage für vordefinierte Abfragen und Regeln bieten, mit denen Sie Ihre Google Cloud-Logs analysieren können.

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

Logs aktivieren

So aktivieren Sie Logs:

• Identifizieren der zu exportierenden Logs mithilfe des Logbereichstool in dieser Anleitung.
• Aufzeichnung des Logfilters, der vom Logbereichstool für die spätere Konfiguration der Logsenke generiert wurde.
• Logging für jedes ausgewählte Log oder jeden ausgewählten Dienst aktivieren.

Beachten Sie, dass das Logging nicht standardmäßig für alle Dienste aktiviert ist. Durch die Auswahl von Logs im Logbereichstool werden diese nicht automatisch aktiviert. Achten Sie darauf, dass die richtige Logging-Stufe für die spezifischen Dienste aktiviert ist, an denen Sie interessiert sind. Je nach Dienst müssen Sie möglicherweise sowohl die entsprechenden Audit-Logs für den Datenzugriff aus Cloud-Audit-Logs als auch die Plattformlogs aktivieren, wie weiter unten in diesem Abschnitt beschrieben.

Logs mit dem Logbereichstool identifizieren

Das Logbereichstool besteht aus der folgenden interaktiven Tabelle und dem folgenden Logfilter. Dieses Tool listet wertvolle sicherheitsrelevante Logs in Google Cloud auf, einschließlich Cloud-Audit-Logs, Access Transparency-Logs, Netzwerklogs und mehreren Plattformlogs. Wenn Sie dieses Tool verwenden möchten, wählen Sie zuerst die Logs aus, die Sie gemäß Ihren Sicherheits- und Complianceanforderungen exportieren und analysieren möchten. Jedes von Ihnen ausgewählte Log wird dem Logfilter hinzugefügt, den das Tool generiert.

Das Tool hilft Ihnen bei der Beurteilung, welche Logs ausgewählt werden sollten. Dazu ordnet es jeden Logtyp den folgenden Bereichen zu:

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

Logbereichstool

Die interaktive Tabelle in diesem Abschnitt dient als Tool zur Bestimmung von Logbereichen. Der vom Tool generierte Logfilter wird im Abschnitt "Automatisch generierter Logfilter" nach der Tabelle angezeigt. Identifizieren Sie mit dem Tool die Logs, die Sie exportieren möchten:

• 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.

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 filtern (oder ausschließen). Sobald Sie einen Logfilter haben, der Ihren Logging-Anforderungen entspricht, müssen Sie den Filter für dessen Verwendung beim Export der Logs speichern. Sie können den Filter beispielsweise in einem Texteditor speichern oder ihn in einer Umgebungsvariablen speichern:

1. Verwenden Sie das Logbereichstool, um die Logs auszuwählen, die Sie exportieren möchten.
2. Kopieren Sie im Abschnitt "Automatisch generierter Logfilter", der auf das Tool folgt, den Code für den Logfilter.
3. Optional: Bearbeiten Sie den kopierten Code, um den Filter zu verfeinern.

4. 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. Diese zusätzlichen Gebühren fallen während des gesamten Analyseprozesses durch Gebühren für Cloud Logging und im Zusammenhang mit den Kosten für Ihr Sicherheitsanalysetool an. 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.

Auditprotokolle für den 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-Logsenke 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 vorherigen 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 Cloud-Projekte verwenden, um Logvolumen zu begrenzen und dabei gleichzeitig wertvolle Sicherheit und Transparenz zu erhalten:

Stufe	Dienste	Audit-Logtypen für Datenzugriffe	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. Mit Überwachen von diesem Zugriff 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 exportieren

Nachdem die Logs identifiziert und aktiviert wurden, werden sie im nächsten Schritt in das Analysetool exportiert. Der Exportvorgang hängt von den Analysetools ab, die Sie verwenden, wie im folgenden Diagramm gezeigt.

Das Diagramm zeigt die folgenden Exportprozesse:

• Wenn Sie Chronicle verwenden und dieser vordefinierten Logsatz Ihre Sicherheitsanalyseanforderungen erfüllt, können Sie Logs automatisch direkt in Chronicle exportieren mit der eingebauten Chronicle-Aufnahme, wie im Diagramm dargestellt. Sie können diese vordefinierten Satz von Logs auch in der Spalte Exportierbar direkt nach Chronicle des Logbereichstool ansehen. Weitere Informationen zum Exportieren dieser vordefinierten Logs finden Sie unter Google Cloud-Logs in Chronicle aufnehmen.

• Wenn Sie BigQuery oder ein SIEM-Lösung eines Drittanbieters verwenden oder einen erweiterten Satz von Logs in Chronicle 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 Logsenke, die die ausgewählten Logs angemessen weiterleitet. Wenn Sie BigQuery verwenden, benötigen Sie lediglich diese Logsenke, um die Logs an BigQuery weiterzuleiten. Wenn Sie eine SIEM-Lösung eines Drittanbieters verwenden, muss die Logsenke die ausgewählten Logs in Pub/Sub oder Cloud Storage aggregieren, bevor die Logs in Ihr Analysetool gezogen werden können.

Die Exportprozesse nach Chronicle und ein SIEM eines Drittanbieters werden in dieser Anleitung nicht behandelt. In den folgenden Abschnitten werden jedoch die Schritte und die Details beschrieben, die Sie zum Exportieren von Logs nach BigQuery benötigen:

1. Dataset für den Logging-Export in BigQuery einrichten

2. Logsenke für BigQuery konfigurieren

   In diesem Abschnitt wird gezeigt, wie Sie die Logsenke für BigQuery konfigurieren. Sie können die in diesem Beispiel beschriebenen Konzepte zur Logsenke jedoch auf den Export von Logs in ein SIEM-Tool eines Drittanbieters oder auf den Export einer erweiterten Gruppe von Logs nach Chronicle anwenden. Der Hauptunterschied ist das Ziel der Logsenke. Anstelle von BigQuery ist das Ziel entweder ein Cloud Storage-Bucket oder ein Pub/Sub-Thema, aus dem das nachgelagerte Analysetool die Logs abruft (wie im Diagramm dargestellt).

3. IAM-Richtlinienberechtigungen für das BigQuery-Dataset festlegen

4. Prüfen, ob die Logs in BigQuery exportiert wurden

Dataset für das BigQuery-Dataset einrichten

Folgen Sie der Anleitung zum Einrichten eines Datasets, das Ihre exportierten Protokolle hostet. Wenn Sie zusammengefasste Logs verwenden, sollten Sie das BigQuery-Dataset in einem der Google Cloud-Projekte in Ihrer Organisation erstellen. Wenn Sie Logexporte für ein einzelnes Projekt verwenden, sollten Sie das BigQuery-Dataset im selben Projekt erstellen.

Best Practice: Legen Sie das Attribut Standardpartitionsablauf des Datasets fest, um die Gesamtgröße des Logging-Exportspeichers und der damit verbundenen Kosten im Laufe der Zeit zu begrenzen. Dies ist während oder nach der Erstellung des Datasets möglich. Wenn Sie detailliertere Aufbewahrungsanforderungen basierend auf dem Logtyp haben, können Sie dieses Attribut auf Tabellenebene überschreiben, nachdem die Logsenke mit dem Exportieren von Logs begonnen und die entsprechenden Tabellen erstellt hat.

Logsenke für BigQuery konfigurieren

Zum Konfigurieren des Logging-Exports erstellen Sie eine Logsenke mit dem zuvor generierten und gespeicherten Logfilter. Zur Vereinfachung der Verwaltung und Abfrage der Daten konfigurieren Sie die Logsenke so, dass Daten in partitionierte Tabellen exportiert werden, in denen Daten nach Tagen partitioniert werden basierend auf dem Feld timestamp des Logeintrags. Mit diesem Ansatz partitionierter Tabellen können Sie die Abfragekosten reduzieren. Verringern Sie dazu die Anzahl der als Teil von Abfragen gescannten Daten. Ein weiterer Vorteil partitionierter Tabellen ist, dass Sie den Ablauf der Partition festlegen können - auf der Ebene der einzelnen Tabelle oder des gesamten Datasets -, sodass die Logging-Daten nur so lange wie nötig aufbewahrt werden. Beispielsweise können Sie Auditprotokolldaten für drei Jahre aufbewahren. Ältere Daten werden dann automatisch gelöscht, wenn die Partitionen ablaufen.

Verwenden Sie in der gcloud CLI den Befehl gcloud logging sinks create oder den API-Aufruf organizations.sinks.create, um Folgendes zu erstellen: Eine Senke mit dem entsprechenden Logging-Filter. Im folgenden Beispiel wird mit dem Befehl gcloud eine Senke mit dem Namen gcp_logging_sink_bq für die Organisation erstellt. Die Senke enthält alle untergeordneten Projekte und gibt den zu verwendenden Logfilter an.

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

Dabei gilt:

• PROJECT_ID: die ID des Projekts, in dem sich Ihr BigQuery-Dataset befindet.
• DATASET_ID: die ID für Ihr BigQuery-Dataset.
• LOG_FILTER: der Logfilter, den Sie aus dem Logbereichstool gespeichert haben.
• ORGANIZATION_ID: die ID für Ihre Organisation.

Der Befehl gcloud logging sinks create gibt eine Antwort zurück, die der folgenden ähnelt:

Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_bq].
Please remember to grant `serviceAccount:[e-mail]` the WRITER role on the dataset..
More information about sinks can be found at /logging/docs/export/configure_export

Kopieren Sie in der Antwortausgabe den Wert aus dem Feld serviceAccount und speichern Sie ihn für die Verwendung im nächsten Abschnitt. Der in der vorherigen Beispielausgabe angezeigte serviceAccount-Wert ist beispielsweise [e-mail].

Der im Feld serviceAccount angezeigte Wert gibt die Kennung des Dienstkontos an, das der gerade erstellten Senke zugeordnet ist. Diese Kennzeichnung ist die Identität des Autors für die Senke. Solange Sie dieser Identität keinen Schreibzugriff auf das BigQuery-Dataset erteilen, schlägt der Export von Logeinträgen aus dieser Senke fehl. Sie gewähren im nächsten Abschnitt Schreibzugriff auf die Autorenidentität der Senke.

IAM-Richtlinienberechtigungen für das BigQuery-Dataset festlegen

Damit die Logsenke exportierte Logs in BigQuery schreiben kann, müssen Sie die Identität des Autors der Senke dem BigQuery-Dataset hinzufügen und dieser Identität Bearbeiterberechtigungen erteilen. Andernfalls schlägt der Schreibvorgang fehl.

So fügen Sie dem Dienstkonto 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 die exportierten Logs 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 die Identität des Autors der Senke ein. Beachten Sie, dass diese Identität der Wert des Felds serviceAccount ist, der in der Antwort angegeben wird, die nach dem Erstellen der Logsenke generiert wurde.

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

   

Nachdem Sie den Logging-Export mithilfe dieses Filters erstellt haben, werden die Protokolldateien im konfigurierten Projekt in das BigQuery-Dataset eingepflegt.

Best Practice: Sie können basierend auf Ihren Anforderungen eine Richtlinie mit den niedrigsten Berechtigungen implementieren. Sie können die Dataset-Berechtigungen basierend auf bestimmten Google Cloud-Nutzerkonten, Google Groups oder Google Cloud-Dienstkonten konfigurieren. Verwenden Sie IAM-Berechtigungen, um Zugriff auf das BigQuery-Dataset zu gewähren.

Prüfen, ob die Logs nach BigQuery exportiert wurden

Wenn Sie die Logs in ein BigQuery-Dataset exportieren, erstellt Cloud Logging BigQuery-Tabellen, die die exportierten 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.

Sowohl Logs zu Administratoraktivitäten als auch Datenzugriffe 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 Beispielfragen für die Sicherheit, die nach Art der Frage gruppiert sind. In der Anleitung finden Sie auch Informationen zu den einzelnen Fragen in dieser Liste. Wenn Sie die mit jeder Frage verknüpften CSA-Abfragen verwenden möchten, ersetzen Sie MY_DATASET_ID durch das BigQuery-Dataset, das Sie zuvor in diesem Dokument erstellt haben, und ersetzen Sie MY_PROJECT_ID durch die Google Cloud-Projekt-ID, in der sich das Dataset befindet.

• 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?
• 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?
• 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?
• 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?
• 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?
• 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. Solche Anmeldeversuche können über die Google Cloud Console, die Google Workspace-Admin-Konsole oder die gcloud-Befehlszeile erfolgen.

backends/bigquery/sql/1_02_suspicious_login_attempt.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/1_03_excessive_login_failures.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/1_10_access_attempts_blocked_by_VPC_SC.sql

Auf GitHub ansehen

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 HTTP(S)-Load-Balancing-Logs 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.

backends/bigquery/sql/1_20_access_attempts_blocked_by_IAP.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/2_02_user_added_to_privileged_group.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/2_20_permissions_granted_over_SA.sql

Auf GitHub ansehen

SELECT
 timestamp,
 logName,
 protopayload_auditlog.authenticationInfo.principalEmail,
 protopayload_auditlog.methodName,
 protopayload_auditlog.resourceName,
 bindingDelta
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 400 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy"
  AND bindingDelta.action = 'ADD'

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.

backends/bigquery/sql/2_30_service_accounts_or_keys_created_by_non_approved_identity.sql

Auf GitHub ansehen

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-Back-End-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 Back-End-Dienst. Alle Abfrageergebnisse weisen möglicherweise darauf hin, dass versucht wird, die Verteidigung eines Back-End-Dienstes zu umgehen, der im Internet zugänglich sein könnte.

backends/bigquery/sql/2_40_user_access_modified_in_IAP.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/3_01_logging_settings_modified.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/3_02_vpc_flows_logging_disabled.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/3_11_unusual_number_of_firewall_rules_modified.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/3_20_virtual_machines_deleted.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/4_01_unusually_high_api_usage_by_user_identity.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/4_11_autoscaling_usage_frequency_by_day.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/5_01_users_who_most_frequently_accessed_data.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/5_04_users_who_accessed_data_in_table.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/5_05_tables_most_frequently_accessed.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/5_06_BQ_queries_top.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/5_20_top_data_access_actions.sql

Auf GitHub ansehen

SELECT
  ANY_VALUE(_TABLE_SUFFIX),
  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.

backends/bigquery/sql/6_10_connection_from_new_IP.sql

Auf GitHub ansehen

SELECT
  jsonPayload.connection.src_ip as src_ip,
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance, --- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  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 HTTP(S)-Load-Balancing-Logs, 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 Ihr HTTP(S)-Load-Balancing konfiguriert haben. Diese Abfrage setzt auch voraus, dass Sie das HTTP(S)-Load-Balancing-Logging aktiviert haben, wie in den Anweisungen unter dem Link zum Aktivieren im Logbereichstool angegeben.

backends/bigquery/sql/6_20_connections_blocked_by_cloud_armor.sql

Auf GitHub ansehen

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.

backends/bigquery/sql/6_30_virus_or_malware_detected_by_cloud_IDS.sql

Auf GitHub ansehen

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" OR "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.

backends/bigquery/sql/6_40_DNS_top_queried_domains.sql

Auf GitHub ansehen

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

Nächste Schritte

• Andere Exportszenarien ansehen:

  • Szenario – Export für Compliance-Anforderungen
  • Szenario – Export nach Splunk

• Google Cloud-Logs in Chronicle aufnehmen

• Google Cloud-Sicherheitsdaten in Ihr SIEM-System exportieren

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