Google SecOps-Architektur und ‑Datenflüsse

Unterstützt in:

Google SecOps

Moderne Sicherheitsumgebungen generieren riesige Mengen an Telemetriedaten für cloudnative Infrastruktur, Mikrodienste und verteilte Endpunkte. Ältere SIEM-Architekturen (Security Information and Event Management) haben oft Schwierigkeiten, mit diesen Datenmengen zu skalieren, was zu langsamen Abfragen und einer fragmentierten Sichtbarkeit führt.

Die Google Security Operations-Plattform bietet eine einheitliche, leistungsstarke Sicherheitsanalyseschicht. Es basiert auf derselben Infrastruktur, die auch für die globalen Hauptdienste von Google verwendet wird. Es erfasst und fragt Petabytes an Sicherheitstelemetriedaten mit einer Latenz von weniger als einer Sekunde ab und macht die herkömmliche Unterscheidung zwischen Hot- und Cold-Datenebenen überflüssig.

In diesem Dokument werden die Architektur und die Datenflüsse von Google SecOps beschrieben, einschließlich der Aufnahme, der UDM-Normalisierung, der YARA-L-Bedrohungserkennung und der automatisierten Reaktion.

Konvergenz von Bedrohungsinformationen, Analysen und Reaktionen

Google SecOps vereint bisher getrennte Sicherheitsfunktionen. Es kombiniert SIEM-Analysen und SOAR (Security Orchestration, Automation and Response) in einer eng gekoppelten Plattform. Außerdem werden Bedrohungsinformationen von Google Threat Intelligence und VirusTotal sowie generative KI-Funktionen, die auf Gemini basieren, direkt in Untersuchungs- und Erkennungs-Workflows eingebettet.

Übersicht über die Plattformarchitektur

Google SecOps ist eine spezielle, cloudnative Sicherheitsebene, die auf der Kerninfrastruktur von Google Cloud aufbaut. Es erbt die Skalierbarkeits-, Langlebigkeits- und Leistungseigenschaften der zugrunde liegenden Google-Dienste, einschließlich Spanner und Colossus.

Systemkontext

Google SecOps dient als zentrale Betriebsebene für Ihre Sicherheitsumgebung und verwaltet Daten in drei primären Phasen:

• Eingaben: Telemetriedaten aus Hybridumgebungen werden erfasst, einschließlich lokaler Collectors (z. B. des BindPlane-Agents), APIs von Cloud-Anbietern und direkter SaaS-Connectors (Software-as-a-Service) von Drittanbietern.
• Verarbeitungskern: Normalisiert Rohdaten der Telemetrie in das strukturierte UDM-Schema, wertet Ereignisse mit der YARA-L-Erkennungs-Engine aus und orchestriert Workflows mit der SOAR-Fallverwaltungs-Engine.
• Ausgaben: Liefert Analysten umsetzbare Sicherheitsinformationen und KI-basierte Triage-Erkenntnisse und sendet gleichzeitig automatisierte Eindämmungsbefehle über APIs und Remote-Agents zurück an Zielumgebungen.

Das folgende Diagramm veranschaulicht den Systemkontext und die Datenflüsse.

Vorteile der Infrastruktur

Ein wichtiger architektonischer Vorteil von Google SecOps ist das einheitliche Hot-Storage-Modell. Bei Legacy-Architekturen werden ältere Telemetriedaten in den kalten Datenspeicher verschoben, was Abfragen verlangsamt oder eine manuelle Rehydrierung erfordert. Im Gegensatz dazu werden in Google SecOps alle aufgenommenen Telemetriedaten bis zu 12 Monate lang in einem aktiven, indexierbaren Hot-State aufbewahrt. Mit diesem Design können Sie Abfragen für ein ganzes Jahr mit Verlaufsdaten mit derselben Leistung wie für die letzte Stunde ausführen.

Pipeline zur Datenerhebung und ‑normalisierung

Google SecOps verwendet eine Ingestion-Pipeline mit hohem Durchsatz, die unstrukturierte Rohlogs in das strukturierte Unified Data Model (UDM) umwandelt. Bei der Normalisierung werden die einzelnen Ereignisse in der Pipeline mit Kontextmetadaten aus dem Entity Context Graph angereichert.

Architektur der Sammlung

Die Datenaufnahme erfolgt über drei primäre Vektoren:

• Collectors: Agentbasierte Collectors (z. B. der BindPlane-Agent oder OpenTelemetry-Agents), die in lokalen Netzwerken bereitgestellt werden, um Syslog- und Paketdaten zu aggregieren. Collectors puffern, komprimieren und verschlüsseln Telemetriedaten auf der Transportebene (TLS), bevor sie an Google SecOps weitergeleitet werden.
• Ingestion APIs: Direkte REST API-Endpunkte, über die strukturierte und unstrukturierte Telemetriedaten aus Cloud-Diensten, benutzerdefinierten Anwendungen und serverlosen Pipelines aufgenommen werden.
• Integrationen von Drittanbietern: Integrierte, pullbasierte Connectors, die Protokolle, Benachrichtigungen und Verzeichnisdaten direkt von externen SaaS-Plattformen und Cloud-APIs (z. B. Microsoft 365 oder Microsoft Entra ID) abrufen.

Ablauf der Pipeline für Datenerhebung und ‑vorbereitung

Im folgenden Diagramm sind die einzelnen Transformationsschritte von Rohdaten zum UDM-Format dargestellt.

Unified Data Model – Schemaübersicht

Mit dem einheitlichen Datenmodell (Unified Data Model, UDM) werden unterschiedliche Anbieterlogs in einem einzigen strukturierten Schema normalisiert. Diese Standarddarstellung vereinfacht die Analyse und Suche, da dafür gesorgt wird, dass gleichwertige Entitäten (z. B. IP-Adressen, Nutzernamen oder Datei-Hashes) in allen Log-Quellen dieselben Feldpfade haben.

UDM-Schemaarchitektur

Im UDM wird ein stark typisiertes, hierarchisches Schema verwendet, um Sicherheitsereignisse und ‑entitäten darzustellen. Dabei werden Daten in die folgenden logischen Kernstrukturen unterteilt:

• Metadaten: Kontext zum Log-Ereignis selbst, einschließlich des Ereigniszeitstempels, der Erfassungszeit, des Produktnamens des Anbieters und des Ereignistyps.
• Prinzipal: Die agierende Entität, die die Aktivität initiiert hat, z. B. der ursprüngliche Nutzer, Host, die IP-Adresse oder der Prozess.
• Ziel: Die Entität, die direkt von der Aktivität betroffen ist, z. B. die Zieldatei, der Zielhost oder das Nutzerkonto.
• Quelle, Vermittler und Beobachter: Sekundäre Netzwerkbeteiligte (z. B. Weiterleitungsproxys, Firewalls oder Routing-Hops), die an der Transaktion beteiligt sind.
• Netzwerk: Attribute des Netzwerkprotokolls und Transaktionsartefakte (einschließlich Anwendungsprotokolle, DNS-Abfragen und Details zu HTTP-Anfrage).
• Sicherheitsergebnis: Die vom Sicherheitsgerät gemeldete Aktion oder der Schweregrad (z. B. ALLOWED, BLOCKED oder QUARANTINED).
• Erweiterungen: Anbieterspezifische benutzerdefinierte Felder und Schlüssel/Wert-Paare, die nicht zum Standardschema gehören. Weitere Informationen zu Mapping-Definitionen und zur Parserentwicklung finden Sie unter Benutzerdefinierte Parser konfigurieren und Wichtige UDM-Felder.

UDM-Klassendiagramm

Das folgende Diagramm zeigt eine strukturelle Übersicht des UDM.

Sucharchitektur

Google SecOps bietet leistungsstarke Suchmechanismen, die auf verschiedene Untersuchungs-Workflows zugeschnitten sind. Sie können normalisierte Telemetriedaten im Hot Storage abfragen, Mustervergleiche mit nicht geparsten Rohlogs durchführen oder strukturierte Falldaten durchsuchen. Hinweise zur Optimierung finden Sie unter Best Practices für die UDM-Suche.

In der folgenden Tabelle sind die wichtigsten Suchfunktionen der Plattform zusammengefasst:

Suchtyp	Architekturfunktion
UDM-Suche	Die primäre strukturierte Suchmaschine, mit der normalisierte, indexierte UDM-Ereignisse im 12-Monats-Zeitraum abgefragt werden. Es ermöglicht das Filtern, Aggregieren und Korrelieren über mehrere Felder hinweg für unterschiedliche Protokollquellen.
Rohlog-Scan	Durchsucht die ursprünglichen, nicht geparsten Textstrings der aufgenommenen Logs. Diese Funktion unterstützt reguläre Ausdrücke (`regex`) und Teilstring-Suchen für Artefakte und benutzerdefinierte Parameter, die keiner bestimmten UDM-Syntax zugeordnet sind.
Suche in natürlicher Sprache	Gemini AI wird verwendet, um Fragen in natürlicher Sprache direkt in die formale UDM-Suchsyntax zu übersetzen. So werden die Erstellung von Abfragen und die Untersuchungs-Workflows beschleunigt.
Cases durchsuchen	Eine spezialisierte Suchmaschine in der Antwortschicht, die Untersuchungsfälle, Benachrichtigungen, Playbooks und Metadaten zu kommentierten Einheiten in der SOAR-Datenbank abfragt.

Schleife für Bedrohungserkennung und ‑abwehr

Die Google SecOps-Architektur schafft eine kontinuierliche Feedbackschleife zwischen der Analyse zur Erkennung und der automatisierten Reaktion. Durch Erkennungsregeln werden Warnmeldungen mit hoher Genauigkeit generiert, die Reaktionsworkflows auslösen. Die Ergebnisse von Untersuchungen liefern Feedback, mit dem die zukünftige Erkennungslogik optimiert und angepasst wird.

Architektur des Erkennungstrichters

Die Erkennungs-Engine verwendet einen mehrstufigen Trichteransatz, um große Mengen an rohen Sicherheitstelemetriedaten in Warnungen mit hoher Genauigkeit zu filtern:

1. Erfassung und Normalisierung: Rohlogs werden kontinuierlich erfasst und in standardmäßige UDM-Ereignisstrukturen formatiert.
2. Anreicherung: Ereignisse werden dynamisch mit Aliaszuordnungen, kontextbezogenen Asset-Daten und globalen Threat Intelligence-Informationen aus Quellen wie Google Threat Intelligence angereichert.
3. Erkennungsauswertung: Die zustandsbehaftete YARA-L 2.0-Engine wertet angereicherte Ereignisse anhand von Verhaltens- und Bedrohungsregeln über längere Zeiträume hinweg aus. Richtlinien zur Optimierung von Regeln finden Sie unter Best Practices für YARA-L.
4. Priorisierung und Gruppierung: Abgestimmte Erkennungen werden in Benachrichtigungen zusammengefasst, dynamische Risikobewertungen werden zugewiesen und sie werden in einheitliche Fälle gruppiert.

Durch die Kombination von kontextbezogenen Asset-Daten mit Threat Intelligence werden mit dieser Trichterstrategie harmlose Anomalien herausgefiltert (weniger Falschmeldungen) und echte Bedrohungen hervorgehoben (weniger Falschmeldungen). So kann sich Ihr Sicherheitsteam auf umsetzbare Vorfälle konzentrieren.

Automatisierte Problembehebung und Feedback-Schleife

Die Pipeline für Erkennung und Reaktion kombiniert die zustandsbehaftete Regelauswertung mit automatisierter Triage und Eindämmung:

1. Kontinuierliche Evaluierung: Angereicherte UDM-Telemetriestreams über die zustandsorientierte YARA-L 2.0-Erkennungs-Engine.
2. Anfragenerstellung und KI-Triage: Wenn eine Regelbedingung erfüllt ist, generiert Google SecOps eine Benachrichtigung und öffnet eine Anfrage. Ein KI-basierter Agent für die Priorisierung und Untersuchung führt dynamische Suchvorgänge und Threat Intelligence-Lookups aus, um die Ergebnisse zu bewerten.
3. Automatisierte Playbook-Ausführung: Wenn die KI-Triage ein echtes Positiv bestätigt, löst die Plattform automatisierte Reaktions-Playbooks aus, z. B. das Isolieren eines Endpunkts oder das Sperren eines Nutzerkontos über Remote-Agents. Wenn der Fall als Falschmeldung eingestuft wird, wird er automatisch geschlossen.
4. Kontinuierliche Optimierung: Die Ergebnisse der Abhilfemaßnahmen und die Triage-Entscheidungen der Analysten werden verwendet, um die Erkennungsschwellen zu optimieren und zukünftige falsch-positive Ergebnisse zu reduzieren.

Ebene für Bedrohungserkennung

Die YARA-L 2.0-Engine wertet eingehende UDM-Telemetriedaten mithilfe einer mehrstufigen Streamingpipeline aus, um Verhaltensanomalien und Angriffsmuster mit mehreren Ereignissen über längere Zeiträume hinweg zu erkennen. Sie können auch YARA-L-Regeln mit Gemini generieren und verfeinern.

Der Verarbeitungslebenszyklus für jede YARA-L-Regel umfasst fünf verschiedene Bewertungsphasen:

1. Aufnahme (Ingest): Angereicherte UDM-Ereignisse werden in Echtzeit in die Pipeline für die Erkennungsbewertung eingegeben.
2. Filtern (Filter): Eingehende Ereignisse werden anhand der Ereigniskriterien der Regel (Abschnitt events) ausgewertet. Nicht übereinstimmende Ereignisse werden verworfen, während übereinstimmende Ereignisse zur zustandsbehafteten Auswertung weitergeleitet werden.
3. Abstimmungszeitraum (Window): Abgestimmte Ereignisse werden anhand der angegebenen Korrelationsschlüssel über einen definierten Zeitraum (von Sekunden bis zu 12 Monaten) gruppiert. Die Engine verfolgt mehrere gleichzeitige zustandsbehaftete Zeitgeber (TimerStart bis TimerEnd), wenn Ereignisse eintreffen.
4. Bedingungsauswertung (Condition): Wenn das Abgleichsfenster geschlossen oder ausgelöst wird, wertet die Engine die Schwellenwertanforderungen und mathematischen Ausdrücke aus, die im condition-Abschnitt der Regel definiert sind, z. B. Ereigniszahlen, eindeutige Schwellenwerte oder Datenzusammenführungen.
5. Auslösen (Trigger): Wenn die Bedingung als True ausgewertet wird, generiert die Engine eine Erkennung, die eine Benachrichtigung auslöst und einen Fall in der Reaktionsebene öffnet oder aktualisiert. Wenn False, wird der Status gelöscht, ohne dass eine Benachrichtigung ausgelöst wird.

Zustandsautomat für die Regelausführung

Das folgende Diagramm veranschaulicht den Lebenszyklus einer Regelausführung.

Antwortarchitektur und Remote-Ausführung

Google SecOps SOAR ist die Reaktionssäule der Plattform. Sie fungiert als Orchestrierungs-Engine über der Analyseschicht, um Warnungen zu erfassen, Fälle zu priorisieren und automatisierte Reaktions-Workflows auszuführen.

Orchestrierung, Automatisierung und Untersuchung

Die Reaktionsebene umfasst spezielle Tools, die entwickelt wurden, um die Workflows des Security Operations Center (SOC) in den Bereichen Untersuchung, Fallverwaltung und Playbook-Automatisierung zu optimieren:

• Fallverwaltung: Gruppieren Sie verwandte Warnungen in einheitlichen Fällen, sortieren und filtern Sie Warteschlangen für Vorfälle, weisen Sie Aufgaben zu und arbeiten Sie bei Untersuchungen mit vollständiger Audit-Nachverfolgung zusammen.
• Playbook Designer: Erstellen Sie automatisierte Reaktions-Playbooks mit einem visuellen No-Code-Drag-and-Drop-Canvas mit vorgefertigten Integrationsaktionen.
• Integrierte Entwicklungsumgebung (IDE): Mit der integrierten, codebasierten IDE können Sie benutzerdefinierte Python-Scripts schreiben, vorhandene Aktionsintegrationen ändern und komplexe Automatisierungsworkflows debuggen.
• Untersuchungsansichten und Graph Investigator: Mit graphbasierten Untersuchungsansichten können Sie Angriffspfade und Beziehungen zwischen Entitäten visualisieren. In den Zusammenfassungen für bestimmte Einheiten (z. B. Asset-, IP-Adresse-, Hash-, Domain- und Nutzeransichten) werden relevante Zeitachse-Ereignisse sofort angezeigt.
• Dashboards und Berichte: Mit sofort einsatzbereiten Dashboards oder benutzerdefinierten Berichtswidgets können Sie SOC-Betriebsmetriken, die Arbeitslast von Analysten und die durchschnittliche Reaktionszeit (Mean Time to Respond, MTTR) im Blick behalten.

SOAR-Komponentenarchitektur

Das folgende Diagramm zeigt, wie eingehende Benachrichtigungen in die Case-Management-Engine fließen und automatisierte Abhilfeworkflows in visuellen Playbooks und benutzerdefinierten IDE-Integrationen auslösen.

Architektur von Remote-Agents

Um Abhilfemaßnahmen in privaten Netzwerken (z. B. in lokalen Rechenzentren oder Virtual Private Clouds) auszuführen, setzt Google SecOps auf eine sichere Remote-Agent-Architektur, die nur ausgehende Verbindungen unterstützt.

Bei diesem Modell initiiert die Google SecOps-Plattform niemals eingehende Verbindungen zu Ihrer privaten Umgebung:

1. Aufgabeninitiierung: Wenn für eine Playbook-Aktion eine lokale Ausführung erforderlich ist, veröffentlicht Google SecOps die Anleitung in einer sicheren Publisher-Warteschlange, die in Google Cloudgehostet wird.
2. Asynchrones Polling: Der Remote-Agent, der in Ihrer privaten Umgebung bereitgestellt wird, fragt die Publisher-Warteschlange kontinuierlich über eine ausgehende, TLS-verschlüsselte Verbindung ab.
3. Lokale Ausführung: Wenn eine Aufgabenanweisung abgerufen wird, führt der Remote-Agent die erforderliche Aktion lokal für interne Sicherheitstools oder Netzwerkendpunkte aus, z. B. das Deaktivieren eines Kontos oder das Blockieren eines Firewall-Ports.
4. Statusberichte: Nach Abschluss gibt der Remote-Agent den Aktionsstatus und die Ausführungsprotokolle über TLS an die Publisher-Warteschlange zurück. Dort werden sie abgerufen und in der SOAR-Fallansicht angezeigt.

Sicherheit, Compliance und gemeinsame Verantwortung

Als cloudnative Plattform basiert Google SecOps auf einem Modell der gemeinsamen Verantwortung: Google ist für die Sicherheit der Plattform verantwortlich, während Sie für die Sicherheit in der Plattform verantwortlich sind.

Modell der gemeinsamen Verantwortung

Google SecOps übernimmt das grundlegende Sicherheitsdesign, die Rechenfunktionen und die Speicherarchitektur der Google Cloud -Infrastruktur. Bei diesem Modell gilt Folgendes:

• Google verwaltet:physische Sicherheit der Rechenzentren, zugrunde liegende Cloud-Infrastruktur, Plattformverfügbarkeit und Standardverschlüsselung von Daten im Ruhezustand und während der Übertragung.
• Sie verwalten:Data Governance, Zugriffssteuerung und Daten-RBAC, die über die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM), benutzerdefinierte Erkennungsregeln und Mandanten-Compliance-Einstellungen konfiguriert werden.

Alle Compliance-Anforderungen, Regeln zum Datenstandort und Zugriffsrichtlinien werden von Ihrer Organisationshierarchie über Ordner und Projekte bis hinunter zu Ihrem Compliance-konformen Mandanten übernommen und durchgesetzt.

Compliance und Eignung für Unternehmen

Um strenge behördliche und organisatorische Governance-Anforderungen zu erfüllen, bietet Google SecOps Compliance-konforme Mandanten. In diesen Mandanten werden strenge Sicherheitsstandards durch Assured Workloads erzwungen, die sowohl die Einhaltung regulatorischer Anforderungen als auch technische Datenschutzpakete unterstützen.

Unterstützte Frameworks zur Einhaltung regulatorischer Anforderungen:

• FedRAMP:Moderate und High Impact Levels (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• DoD Impact Levels:IL4 und IL5 (IL4_AND_IL5)
• Gesundheitswesen und Finanzwesen:HIPAA und PCI DSS (HIPAA, PCI_DSS)

Wenn Sie einen Compliance-konformen Mandanten bereitstellen möchten, verknüpfen Sie Ihre Google SecOps-Instanz mit einem Google Cloud -Projekt, das sich in einem Assured Workloads-Ordner befindet, der für das erforderliche Kontrollpaket konfiguriert ist.

Datenstandort und Zugriffstransparenz

Google SecOps erzwingt eine strikte logische Mandantenisolation und unterstützt Access Transparency, damit Sie eine überprüfbare Kontrolle und Audit-Sichtbarkeit über den administrativen Datenzugriff haben.

Unterstützte Pakete für Datensicherheit und ‑standort:

• Kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK): Steuern und verwalten Sie die Schlüssel, die zum Verschlüsseln ruhender Daten (CMEK_V1) verwendet werden.
• Erweiterter Datenspeicherort:Erzwingen Sie regionale Grenzen für den Datenspeicherort und die Zugriffssteuerung für Administratoren (DRZ_ADVANCED).
• VPC Service Controls:Mit VPC Service Controls (VPC-SC) können Sie sichere, benutzerdefinierte Perimeter um Ihre Cloud-Sicherheitsressourcen einrichten.

Die Sicherheitsarchitektur der Plattform basiert auf einem vierstufigen Vererbungsmodell, bei dem Ihre administrativen Sicherheitskontrollen auf den gehärteten Grundlagen der Google-Kerninfrastruktur aufbauen:

Der vierstufige Sicherheits-Stack:

1. Kundenseitige Sicherheitsebene: Ihre erstklassigen administrativen Steuerelemente, einschließlich der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC), die über Identity and Access Management (IAM) verwaltet wird, kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) und regionale Richtlinien zum Datenstandort.
2. Plattformsicherheitsebene: Logische Mandantenisolation, Standardverschlüsselung für ruhende und übertragene Daten (TLS) und Access Transparency-Audit-Logging.
3. Google-Infrastrukturschicht: Kerninfrastruktur für Compute und Speicher, einschließlich Borg-Clusterverwaltung, Colossus-Speicher und globalen Spanner-Datenbanken.
4. Physische Sicherheitsebene: Fundamentale Sicherheit, die durch die Google-Rechenzentren für Unternehmen, die biometrische Multi-Faktor-Authentifizierung und die benutzerdefinierten Titan-Sicherheitschips (roots of trust) unterstützt wird.

Wenn Access Transparency aktiviert ist und ein Google-Support- oder Entwicklerexperte beispielsweise auf Ihre Mandantendaten zugreift, um ein Support-Ticket zu bearbeiten, muss er eine gültige kryptografische Zugriffsbegründung einreichen. Diese Zugriffsanfrage wird sicher aufgezeichnet und ist nahezu in Echtzeit in Ihren Audit-Logs sichtbar.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten