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 einer zentralen Logsenke aggregiert.
Das Diagramm beschreibt Folgendes:
- Logsenken werden auf dem Organisationsknoten so konfiguriert, dass Logs aus allen Projekten in der Ressourcenhierarchie zusammengefasst werden.
- Mehrere Logsenken sind so konfiguriert, dass sie Logs, die einem Filter entsprechen, an verschiedene Ziele für die Speicherung und Analyse senden.
- Das
prj-c-logging-Projekt enthält alle Ressourcen für den Logspeicher und die Analyse. - Optional können Sie zusätzliche Tools konfigurieren, um Logs in ein SIEM zu exportieren.
Der Blueprint verwendet verschiedene Logquellen und schließt diese Logs in den Logsenkenfilter ein, damit die Logs 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 aktiviert der Blueprint keine Datenzugriffslogs, 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. |
|
Der Blueprint aktiviert VPC-Flusslogs für jedes Subnetz. Der Blueprint konfiguriert das Log-Sampling so, dass 50% der Logs erfasst werden, um die Kosten zu senken. Wenn Sie zusätzliche Subnetze erstellen, müssen Sie dafür sorgen, dass für jedes Subnetz VPC-Flusslogs 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 durch den Blueprint automatisiert wird. Weitere Informationen finden Sie unter Daten für Google 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 |
Analysieren Sie Logs aktiv. Führen Sie Ad-hoc-Prüfungen mit dem Log-Explorer in der Console aus oder schreiben Sie SQL-Abfragen, Berichte und Ansichten mit dem verknüpften BigQuery-Dataset. |
|
Speichern Sie Logs langfristig für Compliance-, Audit- und Vorfall-Tracking-Zwecke. Wenn Sie Compliance-Anforderungen für die obligatorische Datenaufbewahrung haben, sollten Sie optional auch die Bucket-Sperre 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 unter Logbereichstool.
Bedrohungsmonitoring mit Security Command Center
Wir empfehlen die Aktivierung von Security Command Center Premium für Ihre Organisation, 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 für alle 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 gängige Containerlaufzeit-Angriffe.
- Virtual Machine Threat Detection: Erkennt potenziell schädliche Anwendungen, die auf virtuellen Maschinen ausgeführt werden.
- Web Security Scanner: Sucht nach OWASP-Top-Ten-Sicherheitslücken in Ihren webbasierten Anwendungen in Compute Engine, App Engine oder Google Kubernetes Engine.
Weitere Informationen zu den Sicherheitslücken und Bedrohungen, die von Security Command Center behoben werden, finden Sie unter Security Command Center-Quellen.
Sie müssen das Security Command Center nach der Bereitstellung des Blueprints aktivieren. Eine Anleitung finden Sie unter Security Command Center für eine Organisation 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. Der Blueprint erstellt das Projekt prj-c-scc mit einem Pub/Sub-Thema, das für diese Integration verwendet werden soll. 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 Chronicle als SIEM verwenden, nehmen Sie Google Cloud-Daten in Chronicle auf.
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.
Benachrichtigungen über logbasierte Messwerte und Leistungsmesswerte
Wenn Sie mit der Bereitstellung von Arbeitslasten auf der Grundlage beginnen, empfehlen wir die Verwendung von Cloud Monitoring zur Messung der Leistungsmesswerte.
Der Blueprint erstellt für jede Umgebung ein Monitoring-Projekt wie prj-p-monitoring. Dieses Projekt wird als den Bereich festlegendes Projekt konfiguriert, um aggregierte Leistungsmesswerte für mehrere Projekte zu erfassen. Der Blueprint stellt ein Beispiel mit logbasierten Messwerten und einer Benachrichtigungsrichtlinie bereit, um E-Mail-Benachrichtigungen zu generieren, wenn Änderungen an der IAM-Richtlinie vorgenommen werden, die auf Cloud Storage-Buckets angewendet wird. So können Sie verdächtige Aktivitäten bei vertraulichen Ressourcen wie dem Bucket im prj-b-seed-Projekt überwachen, das den Terraform-Zustand enthält.
Im Allgemeinen können Sie auch Cloud Monitoring verwenden, um die Leistungsmesswerte und den Status Ihrer Arbeitslastanwendungen zu messen. Abhängig von der operativen Verantwortung für die Unterstützung und Überwachung von Anwendungen in Ihrer Organisation können Sie detailliertere Monitoringprojekte für verschiedene Teams erstellen. Mit diesen Monitoring-Projekten können Sie Leistungsmesswerte aufrufen, Dashboards zum Anwendungszustand erstellen und Benachrichtigungen auslösen, wenn das erwartete SLO nicht erreicht wird.
Das folgende Diagramm zeigt eine allgemeine Ansicht, wie Cloud Monitoring Leistungsmesswerte aggregiert.
Informationen zum effektiven Monitoring von Arbeitslasten auf Zuverlässigkeit und Verfügbarkeit finden Sie im Site Reliability Engineering-Buch von Google, insbesondere im Kapitel zum Überwachen von verteilten Systemen.
Benutzerdefinierte Lösung für automatisierte Loganalyse
Möglicherweise müssen Sie Benachrichtigungen für Sicherheitsereignisse erstellen, die auf benutzerdefinierten Abfragen von Logs 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-Tools zu exportieren.
Der Blueprint unterstützt diese Loganalyse, indem eine zentralisierte Quelle von Logs eingerichtet wird, die Sie mit einem verknüpften BigQuery-Dataset abfragen können. Zur Automatisierung dieser Funktion müssen Sie das Codebeispiel unter bq-log-alerting implementieren und die Grundlagenfunktionen erweitern. Mit dem Beispielcode können Sie regelmäßig eine Logquelle abfragen und ein benutzerdefiniertes Ergebnis an Security Command Center senden.
Im folgenden Diagramm wird der allgemeine Ablauf der automatisierten Loganalyse vorgestellt.
Das Diagramm zeigt die folgenden Konzepte der automatisierten Loganalyse:
- Logs aus verschiedenen Quellen werden in einem zentralisierten Log-Bucket mit Loganalysen und einem verknüpften BigQuery-Dataset zusammengefasst.
- BigQuery-Ansichten sind so konfiguriert, dass Logs für das Sicherheitsereignis abgefragt werden, das Sie beobachten möchten.
- Cloud Scheduler überträgt alle 15 Minuten ein Ereignis an ein Pub/Sub-Thema und löst Cloud Functions aus.
- Cloud Functions fragt die Ansichten nach neuen Ereignissen ab. Wenn Ereignisse gefunden werden, werden sie als benutzerdefinierte Ergebnisse an Security Command Center übertragen.
- Security Command Center veröffentlicht Benachrichtigungen über neue Ergebnisse in einem anderen Pub/Sub-Thema.
- Ein externes Tool wie ein SIEM abonniert das Pub/Sub-Thema, um neue Ergebnisse aufzunehmen.
Das Beispiel hat mehrere Anwendungsfälle, um potenziell verdächtiges Verhalten abzufragen. 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 schreiben. Schreiben Sie eigene Abfragen oder verweisen Sie auf Sicherheitsloganalysen für eine Bibliothek von SQL-Abfragen, mit denen Sie Google Cloud-Logs analysieren können.
Benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen
Damit Sie in Echtzeit auf Ereignisse reagieren können, empfehlen wir Ihnen, Cloud Asset Inventory zu verwenden, um Assetänderungen zu überwachen. 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 Functions führt dann benutzerdefinierten Code aus, um Ihre eigene Geschäftslogik basierend darauf zu erzwingen, ob die Änderung zugelassen werden sollte.
Der Blueprint enthält ein Beispiel für diese benutzerdefinierte Governance-Lösung, die IAM-Änderungen überwacht, die hochsensible Rollen wie Organisationsadministrator, Inhaber und Bearbeiter hinzufügen. Im folgenden Diagramm wird diese Lösung beschrieben.
Das obige Diagramm zeigt diese Konzepte:
- Änderungen an einer Zulassungsrichtlinie werden 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 Functions führt benutzerdefinierten Code aus, um die Richtlinie zu erzwingen. Die Beispielfunktion prüft, ob die Änderung die Rolle "Organisationsadministrator", "Inhaber" oder "Bearbeiter" zu einer Zulassungsrichtlinie hinzugefügt hat. Ist dies der Fall, erstellt die Funktion ein benutzerdefiniertes Sicherheitsergebnis und sendet es an das Security Command Center.
- Optional können Sie dieses Modell verwenden, um Abhilfemaßnahmen zu automatisieren. Schreiben Sie zusätzliche Geschäftslogik in Cloud Functions, um automatisch Maßnahmen für das Ergebnis zu ergreifen, z. B. um die Zulassungsrichtlinie auf den vorherigen Zustand zurückzusetzen.
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
- Mehr über vorbeugende Kontrollen (nächstes Dokument in dieser Reihe) erfahren