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 Protokolle aus mehreren Quellen in mehreren Projekten in einem zentralen Protokoll-Sink zusammenfasst.
Das Diagramm beschreibt Folgendes:
- Logs werden am Organisationsknoten konfiguriert, um Logs aus allen Projekten in der Ressourcenhierarchie zu aggregieren.
- Es sind mehrere Logsenke konfiguriert, um Protokolle, die mit einem Filter übereinstimmen, an verschiedene Ziele für die Speicherung und Analyse zu senden.
- Das
prj-c-logging-Projekt enthält alle Ressourcen für den Log-Speicher und die ‑Analyse. - Optional können Sie zusätzliche Tools konfigurieren, um Protokolle in eine SIEM zu exportieren.
Der Blueprint verwendet verschiedene Protokollquellen und schließt diese Protokolle in den Logsenkefilter ein, damit sie an ein zentrales Ziel exportiert werden können. In der folgenden Tabelle werden die Protokollquellen beschrieben.
Logquelle |
Beschreibung |
|---|---|
Sie können Audit-Logs für 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, sie aber mit Ausschlussfiltern ausschließen. |
|
Standardmäßig sind in der Vorlage keine Protokolle zum Datenzugriff aktiviert, da das Volumen und die Kosten dieser Protokolle 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. |
|
Im Blueprint sind VPC-Fluss-Logs für jedes Subnetz aktiviert. Im Blueprint wird das Log-Sampling so konfiguriert, dass 50% der Logs abgetastet werden, um 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-Protokolle für verwaltete Zonen. Wenn Sie zusätzliche verwaltete Zonen erstellen, müssen Sie diese DNS-Protokolle aktivieren. |
|
Erfordert einen einmaligen Aktivierungsschritt, der nicht vom Blueprint automatisiert wird. Weitere Informationen finden Sie unter Daten für Google Cloud-Dienste freigeben. |
|
Erfordert einen einmaligen Aktivierungsschritt, der nicht vom Blueprint automatisiert wird. Weitere Informationen finden Sie unter Access Transparency aktivieren. |
In der folgenden Tabelle werden die Log-Sinks 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. Sie können Ad-hoc-Analysen mit dem Logs Explorer in der Konsole ausführen oder SQL-Abfragen, Berichte und Ansichten mit dem verknüpften BigQuery-Dataset schreiben. |
|
Logs langfristig zu Compliance-, Audit- und Vorfall-Tracking-Zwecken speichern. Wenn Sie Compliance-Anforderungen für die obligatorische Datenaufbewahrung haben, empfehlen wir Ihnen, 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 Logsenkefiltern finden Sie im Logbereichstool.
Bedrohungsmonitoring mit Security Command Center
Wir empfehlen, Security Command Center Premium für Ihre Organisation 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 gängige Container-Laufzeitangriffe.
- Virtual Machine Threat Detection:Erkennt potenziell schädliche Anwendungen, die auf virtuellen Maschinen ausgeführt werden.
- Web Security Scanner:Scannt Ihre webbasierten Anwendungen in der Compute Engine, App Engine oder Google Kubernetes Engine auf die zehn wichtigsten OWASP-Sicherheitslücken.
Weitere Informationen zu den Sicherheitslücken und Bedrohungen, die in Security Command Center berücksichtigt werden, finden Sie unter Security Command Center-Quellen.
Sie müssen 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. Mit dem Blueprint wird das prj-c-scc-Projekt mit einem Pub/Sub-Thema erstellt, 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 Google SecOps als SIEM verwenden, nehmen Sie Google Cloud-Daten in Google SecOps 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.
Benutzerdefinierte Lösung für automatisierte Loganalyse
Möglicherweise müssen Sie Benachrichtigungen für Sicherheitsereignisse erstellen, die auf benutzerdefinierten Abfragen in Protokollen 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 zentrale Protokollquelle eingerichtet wird, die Sie mit einem verknüpften BigQuery-Dataset abfragen können. Wenn Sie diese Funktion automatisieren möchten, müssen Sie das Codebeispiel unter bq-log-alerting implementieren und die Funktionen der Foundation erweitern. Mit dem Beispielcode können Sie regelmäßig eine Protokollquelle abfragen und ein benutzerdefiniertes Ergebnis an das Security Command Center senden.
Das folgende Diagramm zeigt den Ablauf der automatisierten Protokollanalyse.
Das Diagramm zeigt die folgenden Konzepte der automatisierten Protokollanalyse:
- Logs aus verschiedenen Quellen werden in einem zentralen Logs-Bucket mit Log Analytics und einem verknüpften BigQuery-Dataset zusammengefasst.
- BigQuery-Ansichten sind so konfiguriert, dass Protokolle nach dem 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-Funktionen fragen die Ansichten nach neuen Ereignissen ab. Wenn Ereignisse gefunden werden, werden sie als benutzerdefinierte Ergebnisse an das Security Command Center gesendet.
- Das 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 zu übernehmen.
Das Beispiel enthält mehrere Nutzungsfälle, um nach potenziell verdächtigem Verhalten zu suchen. 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. Sie können eigene Abfragen schreiben oder sich Sicherheitsprotokollanalysen ansehen, um eine Bibliothek mit SQL-Abfragen für die Analyse von Google Cloud-Protokollen zu erhalten.
Benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen
Wenn Sie auf Ereignisse in Echtzeit reagieren möchten, empfehlen wir Ihnen, mit Cloud Asset Inventory 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 Run 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, durch die hochsensible Rollen wie „Organization Admin“, „Owner“ und „Editor“ hinzugefügt werden. Das folgende Diagramm beschreibt diese Lösung.
Das vorherige Diagramm zeigt diese Konzepte:
- An einer Zulassungsrichtlinie werden Änderungen 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-Funktionen führen benutzerdefinierten Code aus, um Ihre Richtlinie durchzusetzen. Die Beispielfunktion enthält eine Logik, mit der geprüft wird, ob durch die Änderung einer Zulassungsrichtlinie die Rollen „Administrator für die Organisation“, „Inhaber“ oder „Bearbeiter“ hinzugefügt wurden. In diesem Fall erstellt die Funktion ein benutzerdefiniertes Sicherheitsergebnis und sendet es an das Security Command Center.
- Optional können Sie dieses Modell verwenden, um Maßnahmen zur Behebung von Problemen zu automatisieren. Sie können zusätzliche Geschäftslogik in Cloud Run-Funktionen schreiben, um automatisch Maßnahmen zu ergreifen, z. B. die Zulassungsrichtlinie wieder in ihren vorherigen Zustand zu versetzen.
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