Bedrohungserkennungs- und Monitoring-Funktionen werden mit einer Kombination aus integrierten Sicherheitskontrollen aus Security Command Center und benutzerdefinierten Lösungen bereitgestellt, mit denen Sie Sicherheitsereignisse erkennen und darauf reagieren können.
Zentrales Logging für Sicherheit und Audit
Der Blueprint konfiguriert Logging-Funktionen, um Änderungen an Ihren Google Cloud Ressourcen mit Logs zu verfolgen und zu analysieren, die zu einem einzelnen Projekt zusammengefasst werden.
Das folgende Diagramm zeigt, wie der Blueprint Logs aus mehreren Quellen in mehreren Projekten in einem zentralen Log-Sink zusammenfasst.
Das Diagramm beschreibt Folgendes:
- Logsenken werden am Organisationsknoten konfiguriert, um Logs aus allen Projekten in der Ressourcenhierarchie zu aggregieren.
- Mehrere Logsenken sind so konfiguriert, dass Logs, die einem Filter entsprechen, zur Speicherung und Analyse an verschiedene Ziele gesendet werden.
- Das
prj-c-logging-Projekt enthält alle Ressourcen für die Logspeicherung und -analyse. - Optional können Sie zusätzliche Tools konfigurieren, um Logs in ein SIEM zu exportieren.
Im Blueprint werden verschiedene Logquellen verwendet und diese Logs sind im Filter der Logsenke enthalten, damit sie an ein zentrales Ziel exportiert werden können. In der folgenden Tabelle werden die Logquellen beschrieben.
Logquelle |
Beschreibung |
|---|---|
Sie können Audit-Logs zu Administratoraktivitäten nicht konfigurieren, deaktivieren oder ausschließen. |
|
Audit-Logs zu Systemereignissen können nicht konfiguriert, deaktiviert oder ausgeschlossen werden. |
|
Sie können Audit-Logs zu Richtlinienverstößen nicht konfigurieren oder deaktivieren, aber optional mit Ausschlussfiltern ausschließen. |
|
Standardmäßig sind keine Logs zum Datenzugriff aktiviert, da das Volumen und die Kosten dieser Logs hoch sein können. Um festzulegen, ob Sie Datenzugriffslogs aktivieren möchten, bewerten Sie, wo Ihre Arbeitslasten sensible Daten verarbeiten. Überlegen Sie auch, ob Sie Datenzugriffslogs für jeden Dienst und jede Umgebung aktivieren müssen, die mit sensiblen Daten arbeiten. |
|
Mit dem Blueprint werden VPC-Flusslogs für jedes Subnetz aktiviert. Das Blueprint konfiguriert Log-Sampling, um 50% der Logs zu erfassen und so die Kosten zu senken. Wenn Sie zusätzliche Subnetze erstellen, müssen Sie dafür sorgen, dass VPC-Flusslogs für jedes Subnetz aktiviert sind. | |
Der Blueprint aktiviert das Logging von Firewallregeln für jede Firewallrichtlinienregel. Wenn Sie zusätzliche Firewallrichtlinienregeln für Arbeitslasten erstellen, müssen Sie dafür sorgen, dass das Firewallregel-Logging für jede neue Regel aktiviert ist. | |
Der Blueprint aktiviert Cloud DNS-Logs für verwaltete Zonen. Wenn Sie zusätzliche verwaltete Zonen erstellen, müssen Sie diese DNS-Logs aktivieren. | |
Erfordert einen einmaligen Aktivierungsschritt, der nicht vom Blueprint automatisiert wird. Weitere Informationen finden Sie unter Daten fürGoogle Cloud -Dienste freigeben. |
|
Erfordert einen einmaligen Aktivierungsschritt, der nicht durch den Blueprint automatisiert wird. Weitere Informationen finden Sie unter Access Transparency aktivieren. |
In der folgenden Tabelle werden die Logsenken und ihre Verwendung mit unterstützten Zielen im Blueprint beschrieben.
Sink | Ziel |
Zweck |
|---|---|---|
| Logs, die an Cloud Logging-Buckets weitergeleitet werden, mit Log Analytics und einem aktivierten verknüpften BigQuery-Dataset |
Logs aktiv analysieren. Führen Sie Ad-hoc-Untersuchungen mit dem Logs Explorer in der Konsole durch oder schreiben Sie SQL-Abfragen, Berichte und Ansichten mit dem verknüpften BigQuery-Dataset. |
|
Logs werden langfristig für Compliance-, Audit- und Vorfall-Tracking-Zwecke gespeichert. Wenn Sie Compliance-Anforderungen für die obligatorische Datenaufbewahrung haben, empfehlen wir, zusätzlich die Bucket-Sperre zu konfigurieren. |
|
|
Exportieren Sie Logs auf eine externe Plattform wie das vorhandene SIEM. Dies erfordert zusätzliche Arbeit für die Einbindung in Ihre SIEM-Funktion, z. B. die folgenden Mechanismen:
|
Eine Anleitung zum Aktivieren zusätzlicher Logtypen und zum Schreiben von Logsenkenfiltern finden Sie im Logbereichstool.
Bedrohungsmonitoring mit Security Command Center
Wir empfehlen, Security Command Center zu aktivieren, um Bedrohungen, Sicherheitslücken und Fehlkonfigurationen in Ihren Google Cloud -Ressourcen automatisch zu erkennen. Security Command Center erstellt Sicherheitsergebnisse aus mehreren Quellen, darunter:
- Security Health Analytics:erkennt häufige Sicherheitslücken und Fehlkonfigurationen in Google Cloud-Ressourcen.
- Angriffspfadrisiko: Zeigt einen simulierten Pfad, wie ein Angreifer Ihre wichtigen Ressourcen anhand der Sicherheitslücken und Fehlkonfigurationen, die von anderen Quellen von Security Command Center erkannt werden, ausnutzen können.
- Event Threat Detection: wendet Erkennungslogik und proprietäre Bedrohungsinformationen auf Ihre Logs an, um Bedrohungen nahezu in Echtzeit zu identifizieren.
- Container Threat Detection:Erkennt häufige Container-Laufzeitangriffe.
- Virtual Machine Threat Detection:Erkennt potenziell schädliche Anwendungen, die auf virtuellen Maschinen ausgeführt werden.
- Web Security Scanner:Scannt Ihre weborientierten Anwendungen in Compute Engine, App Engine oder Google Kubernetes Engine auf OWASP Top Ten-Sicherheitslücken.
Weitere Informationen zu den Schwachstellen und Bedrohungen, die von Security Command Center behandelt werden, finden Sie unter Security Command Center-Quellen.
Sie müssen Security Command Center aktivieren, nachdem Sie das Blueprint bereitgestellt haben. Eine Anleitung finden Sie unter Security Command Center aktivieren.
Nachdem Sie Security Command Center aktiviert haben, empfehlen wir, die von Security Command Center generierten Ergebnisse in Ihre vorhandenen Tools oder Prozesse zu exportieren, um Bedrohungen zu erkennen und darauf zu reagieren. Mit dem Blueprint wird das prj-c-scc-Projekt mit einem Pub/Sub-Thema für diese Integration erstellt. Verwenden Sie je nach vorhandenen Tools eine der folgenden Methoden, um Ergebnisse zu exportieren:
- Wenn Sie die Console verwenden, um Sicherheitsergebnisse direkt in Security Command Center zu verwalten, konfigurieren Sie Rollen auf Ordner- und Projektebene für Security Command Center, damit Teams Sicherheitsergebnisse nur für die Projekte ansehen und verwalten können, für die sie zuständig sind.
Wenn Sie Google SecOps als SIEM verwenden, nehmen Sie Daten in Google SecOps auf. Google Cloud
Wenn Sie ein SIEM- oder SOAR-Tool mit Integrationen in Security Command Center verwenden, geben Sie Daten für Cortex XSOAR, Elastic Stack, ServiceNow, Splunk oder QRadar an.
Wenn Sie ein externes Tool verwenden, das Ergebnisse aus Pub/Sub aufnehmen kann, konfigurieren Sie kontinuierliche Exporte in Pub/Sub und Ihre vorhandenen Tools so, dass Ergebnisse aus dem Pub/Sub-Thema aufgenommen werden.
Benutzerdefinierte Lösung für automatisierte Loganalyse
Möglicherweise müssen Sie Benachrichtigungen für Sicherheitsereignisse erstellen, die auf benutzerdefinierten Abfragen für Protokolle basieren. Benutzerdefinierte Abfragen können die Funktionen Ihres SIEM ergänzen, indem sie Logs in Google Cloud analysieren und nur die Ereignisse exportieren, die eine Untersuchung erfordern, insbesondere wenn Sie nicht die Möglichkeit haben, alle Cloud-Logs in Ihr SIEM zu exportieren.
Das Blueprint unterstützt diese Loganalyse, indem eine zentrale Quelle für Logs eingerichtet wird, die Sie mit einem verknüpften BigQuery-Dataset abfragen können. Um diese Funktion zu automatisieren, müssen Sie das Codebeispiel unter bq-log-alerting implementieren und die grundlegenden Funktionen erweitern. Mit dem Beispielcode können Sie regelmäßig eine Logquelle abfragen und ein benutzerdefiniertes Ergebnis an Security Command Center senden.
Das folgende Diagramm zeigt den allgemeinen Ablauf der automatisierten Loganalyse.
Das Diagramm veranschaulicht die folgenden Konzepte der automatisierten Loganalyse:
- Logs aus verschiedenen Quellen werden in einem zentralen Log-Bucket mit Log Analytics und einem verknüpften BigQuery-Dataset zusammengefasst.
- BigQuery-Ansichten werden so konfiguriert, dass Protokolle für das Sicherheitsereignis abgefragt werden, das Sie überwachen möchten.
- Cloud Scheduler überträgt alle 15 Minuten ein Ereignis an ein Pub/Sub-Thema und löst Cloud Run-Funktionen aus.
- Cloud Run Functions fragt die Ansichten nach neuen Ereignissen ab. Wenn Ereignisse gefunden werden, werden sie als benutzerdefinierte Ergebnisse an Security Command Center gesendet.
- Security Command Center veröffentlicht Benachrichtigungen zu neuen Ergebnissen in einem anderen Pub/Sub-Thema.
- Ein externes Tool wie ein SIEM abonniert das Pub/Sub-Thema, um neue Ergebnisse aufzunehmen.
Das Beispiel enthält mehrere Anwendungsfälle, mit denen nach potenziell verdächtigem Verhalten gesucht werden kann. Beispiele sind eine Anmeldung aus einer Liste von Super Admins oder anderen von Ihnen angegebenen Konten mit umfangreichen Berechtigungen, Änderungen an den Logging-Einstellungen oder Änderungen an Netzwerkrouten. Sie können die Anwendungsfälle erweitern, indem Sie neue Abfrageansichten für Ihre Anforderungen erstellen. Sie können eigene Abfragen schreiben oder Sicherheitsloganalysen als Bibliothek von SQL-Abfragen verwenden, um Google Cloud -Logs zu analysieren.
Benutzerdefinierte Lösung für Asset-Änderungen
Wenn Sie in Echtzeit auf Ereignisse reagieren möchten, empfehlen wir, Cloud Asset Inventory zum Überwachen von Asset-Änderungen zu verwenden. In dieser benutzerdefinierten Lösung ist ein Asset-Feed so konfiguriert, dass Benachrichtigungen über Änderungen an Ressourcen in Echtzeit an Pub/Sub ausgelöst werden. Cloud Run Functions führt dann benutzerdefinierten Code aus, um Ihre eigene Geschäftslogik basierend darauf zu erzwingen, ob die Änderung zugelassen werden sollte.
Das Blueprint enthält ein Beispiel für diese benutzerdefinierte Governance-Lösung, mit der IAM-Änderungen überwacht werden, bei denen hochsensible Rollen wie „Organisationsadministrator“, „Inhaber“ und „Bearbeiter“ hinzugefügt werden. Das folgende Diagramm veranschaulicht diese Lösung.
Das obige Diagramm veranschaulicht diese Konzepte:
- Es werden Änderungen an einer Zulassungsrichtlinie vorgenommen.
- Der Cloud Asset Inventory-Feed sendet eine Echtzeitbenachrichtigung über die Änderung der Zulassungsrichtlinie an Pub/Sub.
- Pub/Sub löst eine Funktion aus.
- Cloud Run Functions führt benutzerdefinierten Code aus, um Ihre Richtlinie durchzusetzen. Die Beispielfunktion enthält Logik, um zu prüfen, ob durch die Änderung die Rollen „Organisationsadministrator“, „Inhaber“ oder „Bearbeiter“ zu einer Zulassungsrichtlinie hinzugefügt wurden. Wenn ja, erstellt die Funktion ein benutzerdefiniertes Sicherheitsergebnis und sendet es an Security Command Center.
- Optional können Sie dieses Modell verwenden, um Abhilfemaßnahmen zu automatisieren. Schreiben Sie zusätzliche Geschäftslogik in Cloud Run-Funktionen, um automatisch auf das Ergebnis zu reagieren, z. B. indem Sie die Zulassungsrichtlinie auf ihren vorherigen Zustand zurücksetzen.
Darüber hinaus können Sie die von dieser Beispiellösung verwendete Infrastruktur und Logik erweitern, um anderen Ereignissen, die für Ihr Unternehmen wichtig sind, benutzerdefinierte Antworten hinzuzufügen.
Nächste Schritte
- Weitere Informationen zu vorbeugenden Kontrollen (nächstes Dokument in dieser Reihe)