Google SecOps-Architektur und Datenflüsse

Unterstützt in:

Google SecOps

Moderne Sicherheitsumgebungen generieren riesige Mengen an Telemetriedaten in cloudnativer Infrastruktur, Mikrodiensten und verteilten Endpunkten. Ältere SIEM-Architekturen (Security Information and Event Management) können oft nicht mit diesen Datenmengen skaliert werden, was zu langsamen Abfragen und einer fragmentierten Sichtbarkeit führt.

Die Google Security Operations-Plattform bietet eine einheitliche, leistungsstarke Ebene für die Sicherheitsanalyse. Sie basiert auf derselben Infrastruktur, die auch für die globalen Hauptdienste von Google verwendet wird. Petabytes an Telemetriedaten werden mit einer Latenz von weniger als einer Sekunde aufgenommen und abgefragt. Dabei wird die herkömmliche Unterscheidung zwischen aktiven und inaktiven Datenebenen aufgehoben.

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

Konvergenz von Informationen, Analysen und Reaktionen

Google SecOps vereint bisher getrennte Funktionen für den Sicherheitsbetrieb. SIEM-Analysen und SOAR (Security Orchestration, Automation and Response) werden in einer eng gekoppelten Plattform kombiniert. Außerdem werden Bedrohungsinformationen von Google Threat Intelligence und VirusTotal sowie generative KI-Funktionen von Gemini direkt in Workflows zur Untersuchung und Erkennung eingebettet.

Übersicht über die Plattformarchitektur

Google SecOps ist eine spezielle, cloudnative Sicherheitsebene, die auf der Kern Google Cloud infrastruktur basiert. Sie übernimmt die Skalierbarkeit, Zuverlässigkeit und Leistung 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 Hauptphasen:

• Eingaben: Telemetriedaten aus Hybridumgebungen werden aufgenommen, einschließlich lokaler Collectors (z. B. des BindPlane-Agents), Cloud-Anbieter-APIs und direkter SaaS-Connectors (Software-as-a-Service) von Drittanbietern.
• Verarbeitungskern: Rohdaten werden in das strukturierte UDM-Schema normalisiert, Ereignisse werden mit der YARA-L-Erkennungs-Engine ausgewertet und Workflows werden mit der SOAR-Fallverwaltungs-Engine orchestriert.
• Ausgaben: Analysten erhalten verwertbare Informationen zur Sicherheit und KI-Triage-Ergebnisse. Gleichzeitig werden über APIs und Remote-Agents automatisierte Befehle zur Eindämmung an Zielumgebungen gesendet.

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

Vorteile der Infrastruktur

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

Pipeline für Datenerhebung und -normalisierung

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

Architektur der Datenerhebung

Die Datenaufnahme erfolgt über drei Hauptvektoren:

• Collectors: Agentenbasierte 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, die strukturierte und unstrukturierte Telemetriedaten aus Clouddiensten, benutzerdefinierten Anwendungen und serverlosen Pipelines aufnehmen.
• Drittanbieterintegrationen: Integrierte, pullbasierte Connectors, die Logs, Benachrichtigungen und Verzeichnisdaten direkt von externen SaaS-Plattformen und Cloud-APIs abrufen (z. B. Microsoft 365 oder Microsoft Entra ID).

Pipeline für Datenerhebung und -vorbereitung

Das folgende Diagramm zeigt die einzelnen Transformationsschritte von Rohdaten zum UDM-Format.

Übersicht über das Unified Data Model-Schema

Das Unified Data Model (UDM) normalisiert unterschiedliche Anbieterlogs in ein einziges, strukturiertes Schema. Diese Standarddarstellung vereinfacht die Analyse und Suche, da äquivalente Entitäten (z. B. IP-Adressen, Nutzernamen oder Dateihashes) in allen Logquellen einheitliche Feldpfade haben.

UDM-Schemaarchitektur

Das UDM verwendet ein stark typisiertes, hierarchisches Schema zur Darstellung von Sicherheitsereignissen und -entitäten. Die Daten sind in folgende logische Kernstrukturen unterteilt:

• Metadaten: Kontext zum Logereignis selbst, einschließlich des Zeitstempels des Ereignisses, der Aufnahmezeit, des Produktnamens des Anbieters und des Ereignistyps.
• Prinzipal: Die aktive 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. Weiterleitungs-Proxys, 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 Aktion oder der Schweregrad, der vom Sicherheitsgerät gemeldet wird (z. B. ALLOWED, BLOCKED, oder QUARANTINED).
• Erweiterungen: Anbieterspezifische benutzerdefinierte Felder und Schlüssel/Wert-Paare, die außerhalb des Standardschemas liegen. Weitere Informationen zu Zuordnungsdefinitionen und zur Parserentwicklung finden Sie unter Benutzerdefinierte Parser konfigurieren und Wichtige UDM-Felder.

UDM-Klassendiagramm

Das folgende Diagramm bietet eine strukturelle Übersicht des UDM.

Sucharchitektur

Google SecOps bietet leistungsstarke Suchmechanismen, die auf verschiedene Untersuchungs-Workflows zugeschnitten sind. Sie können normalisierte Telemetriedaten im warmen Datenspeicher abfragen, Muster in nicht geparsten Rohlogs suchen oder strukturierte Falldaten durchsuchen. Optimierungshinweise finden Sie unter Best Practices für die UDM-Suche.

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

Suchtyp	Architektonische Funktion
UDM-Suche	Die primäre strukturierte Suchmaschine, die normalisierte, indexierte UDM-Ereignisse im 12-Monats-Fenster abfragt. Sie ermöglicht die Filterung, Aggregation und Korrelation über mehrere Logquellen hinweg.
Rohlog-Scan	Scannt die ursprünglichen, nicht geparsten Textstrings der aufgenommenen Logs. Diese Funktion unterstützt reguläre Ausdrücke (`regex`) und Teilstring-Suchen nach Artefakten und benutzerdefinierten Parametern, die nicht einer bestimmten UDM-Syntax zugeordnet sind.
Suche in natürlicher Sprache	Verwendet Gemini AI, um Fragen in natürlicher Sprache direkt in die formale UDM-Suchsyntax zu übersetzen. So werden die Erstellung von Abfragen und Untersuchungs-Workflows beschleunigt.
Fallsuche	Eine spezielle Suchmaschine in der Reaktionsebene, die Untersuchungsfälle, Benachrichtigungen, Playbooks und mit Anmerkungen versehene Entitätsmetadaten in der SOAR-Datenbank abfragt.

Schleife für Bedrohungserkennung und ‑abwehr

Die Google SecOps-Architektur erstellt eine kontinuierliche Feedbackschleife zwischen der Erkennungsanalyse und der automatisierten Reaktion. Erkennungsregeln generieren präzise Benachrichtigungen, die Reaktions-Workflows auslösen. Die Ergebnisse der Untersuchung liefern Feedback, mit dem die zukünftige Erkennungslogik verfeinert und optimiert wird.

Architektur des Erkennungsprozesses

Die Erkennungs-Engine verwendet einen mehrstufigen Prozess, um riesige Mengen an Rohdaten zu Sicherheits-Telemetriedaten in präzise Benachrichtigungen umzuwandeln:

1. Aufnahme und Normalisierung: Rohlogs werden kontinuierlich aufgenommen und in standardmäßige UDM-Ereignisstrukturen formatiert.
2. Anreicherung: Ereignisse werden dynamisch mit Aliaszuordnungen, Kontextdaten zu Assets und globalen Bedrohungsinformationen aus Quellen wie Google Threat Intelligence angereichert.
3. Bewertung der Erkennung: Die zustandsbehaftete YARA-L 2.0-Engine bewertet angereicherte Ereignisse anhand von Verhaltens- und Bedrohungsregeln über längere Zeiträume hinweg. Richtlinien zur Regeloptimierung finden Sie unter Best Practices für YARA-L.
4. Priorisierung und Gruppierung: Übereinstimmende Erkennungen werden zu Benachrichtigungen zusammengefasst, dynamische Risikobewertungen zugewiesen und in einheitliche Fälle gruppiert.

Durch die Kombination von Kontextdaten zu Assets mit Threat Intelligence werden mit dieser Strategie harmlose Anomalien herausgefiltert (weniger falsch positive Ergebnisse) und echte Bedrohungen hervorgehoben (weniger falsch negative Ergebnisse). So kann sich Ihr Sicherheitsteam auf umsetzbare Vorfälle konzentrieren.

Automatisierte Behebung und Feedbackschleife

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

1. Kontinuierliche Evaluierung: Angereicherte UDM-Telemetriedaten werden über die zustandsbehaftete YARA-L 2.0-Erkennungs-Engine gestreamt.
2. Fallerstellung und KI-Triage: Wenn eine Regelbedingung erfüllt ist, generiert Google SecOps eine Benachrichtigung und öffnet einen Fall. Ein KI-basierter Agent für die Triage und Untersuchung führt dynamische Suchen und Threat Intelligence-Abfragen aus, um die Ergebnisse zu bewerten.
3. Automatisierte Playbook-Ausführung: Wenn die KI-Triage ein echtes positives Ergebnis 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 falsch positiv eingestuft wird, wird er automatisch geschlossen.
4. Kontinuierliche Optimierung: Die Ergebnisse der Behebung und die Triage-Entscheidungen der Analysten werden verwendet, um die Erkennungsschwellen zu verfeinern und zukünftige falsch positive Ergebnisse zu reduzieren.

Ebene für Bedrohungserkennung

Die YARA-L 2.0-Engine bewertet eingehende UDM-Telemetriedaten mithilfe einer mehrstufigen Streaming-Pipeline, 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 Verarbeitungszyklus 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 aufgenommen.
2. Filterung (Filter): Eingehende Ereignisse werden anhand der Ereigniskriterien der Regel (events-Abschnitt) bewertet. Ereignisse, die nicht übereinstimmen, werden verworfen, während übereinstimmende Ereignisse zur zustandsbehafteten Bewertung weitergeleitet werden.
3. Fenster für Übereinstimmungen (Window): Übereinstimmende Ereignisse werden über ein definiertes Zeitfenster hinweg nach angegebenen Korrelationsschlüsseln gruppiert (von Sekunden bis zu 12 Monaten). Die Engine verfolgt mehrere gleichzeitige zustandsbehaftete Timer (TimerStart bis TimerEnd), während Ereignisse erfasst werden.
4. Bedingungsbewertung (Condition): Wenn das Fenster für Übereinstimmungen geschlossen oder ausgelöst wird, bewertet die Engine die Schwellenwertanforderungen und mathematischen Ausdrücke, die im condition-Abschnitt der Regel definiert sind (z. B. Ereignisanzahl, unterschiedliche Schwellenwerte oder datenübergreifende Joins).
5. Auslösung (Trigger): Wenn die Bedingung True ergibt, generiert die Engine eine Erkennung, löst eine Benachrichtigung aus und öffnet oder aktualisiert einen Fall in der Reaktionsebene. Bei False wird der Zustand gelöscht, ohne dass eine Benachrichtigung ausgelöst wird.

Zustandsautomat für die Regelausführung

Das folgende Diagramm veranschaulicht den Lebenszyklus einer Regelausführung.

Reaktionsarchitektur und Remote-Ausführung

Google SecOps SOAR ist die Reaktionssäule der Plattform. Sie fungiert als Orchestrierungs-Engine über der Analyseebene, um Benachrichtigungen aufzunehmen, Fälle zu triagieren und automatisierte Reaktions-Workflows auszuführen.

Orchestrierung, Automatisierung und Untersuchung

Die Reaktionsebene umfasst spezielle Tools, mit denen die Workflows des Security Operations Center (SOC) in den Bereichen Untersuchung, Fallverwaltung und Playbook-Automatisierung optimiert werden können:

• Fallverwaltung: Verwandte Benachrichtigungen zu einheitlichen Fällen gruppieren, Vorfallwarteschlangen sortieren und filtern, Aufgaben zuweisen und bei Untersuchungen zusammenarbeiten, einschließlich vollständiger Audit-Logs.
• Playbook-Designer: Automatisierte Reaktions-Playbooks mit einer visuellen Drag-and-drop-Oberfläche ohne Code und vorgefertigten Integrationsaktionen erstellen.
• Integrierte Entwicklungsumgebung (IDE): Mit der integrierten, codebasierten IDE benutzerdefinierte Python-Skripts schreiben, vorhandene Aktionsintegrationen ändern und komplexe Automatisierungs-Workflows debuggen.
• Untersuchungsansichten und Graph Investigator: Angriffspfade und Entitätsbeziehungen mit graphbasierten Untersuchungsansichten visualisieren. Spezielle Entitätszusammenfassungen (z. B. Ansichten für Assets, IP-Adressen, Hashes, Domains und Nutzer) zeigen sofort relevante Zeitachsenereignisse an.
• Dashboards und Berichte: Betriebsmesswerte des SOC, die Arbeitslast der Analysten und die durchschnittliche Reaktionszeit (Mean Time to Respond, MTTR) mit sofort einsatzbereiten Dashboards oder benutzerdefinierten Berichtswidgets verfolgen.

SOAR-Komponentenarchitektur

Das folgende Diagramm veranschaulicht, wie eingehende Benachrichtigungen in die Fallverwaltungs-Engine fließen und automatisierte Behebungs-Workflows über visuelle Playbooks und benutzerdefinierte IDE-Integrationen auslösen.

Architektur des Remote-Agents

Um Behebungsaktionen in privaten Netzwerken auszuführen (z. B. in lokalen Rechenzentren oder Virtual Private Clouds), verwendet Google SecOps 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 Anweisung in einer sicheren Publisher-Warteschlange in Google Cloud.
2. Asynchrone Abfrage: Der in Ihrer privaten Umgebung bereitgestellte Remote-Agent 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 Firewallports).
4. Statusbericht: Nach Abschluss sendet der Remote-Agent den Aktionsstatus und die Ausführungsprotokolle über TLS an die Publisher-Warteschlange. Dort werden sie abgerufen und in der SOAR-Fallansicht angezeigt.

Sicherheit, Compliance und gemeinsame Verantwortung

Als cloudnative Plattform wird Google SecOps nach dem Modell der gemeinsamen Verantwortung betrieben: 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 von Google Cloud infrastruktur. Bei diesem Modell gilt Folgendes:

• Google verwaltet:Physische Sicherheit des Rechenzentrums, zugrunde liegende Cloud-Infrastruktur, Verfügbarkeit der Plattform und Standardverschlüsselung von Daten im Ruhezustand und während der Übertragung.
• Sie verwalten: Data Governance, Zugriffssteuerung und datenbasierte RBAC, die über Identity and Access Management (IAM) konfiguriert werden, benutzerdefinierte Erkennungsregeln und Compliance-Einstellungen für Mandanten.

Alle Complianceanforderungen, Regeln zum Datenstandort und Zugriffsrichtlinien werden von Ihrer Organisationshierarchie über Ordner und Projekte bis hin zu Ihrem Compliance-kontrollierten Mandanten übernommen und erzwungen.

Compliance und Unternehmensbereitschaft

Um strenge behördliche und organisatorische Governanceanforderungen zu erfüllen, bietet Google SecOps Compliance-kontrollierte Mandanten. Diese Mandanten erzwingen strenge Sicherheitsstandards über Assured Workloads und unterstützen sowohl die Einhaltung regulatorischer Anforderungen als auch technische Datenschutzpakete.

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-kontrollierten Mandanten bereitstellen möchten, verknüpfen Sie Ihre Google SecOps-Instanz mit einem Google Cloud Projekt in einem Assured Workloads-Ordner, der für das erforderliche Kontrollpaket konfiguriert ist.

Datenstandort und Zugriffstransparenz

Google SecOps erzwingt eine strenge logische Mandantenisolierung und unterstützt Access Transparency, um Ihnen eine überprüfbare Kontrolle und Auditsichtbarkeit über den administrativen Datenzugriff zu ermöglichen.

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

• Kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK): Sie können die Schlüssel steuern und verwalten, die zum Verschlüsseln von Daten im Ruhezustand verwendet werden (CMEK_V1).
• Erweiterter Datenstandort:Erzwingen Sie regionale Grenzen für den Datenstandort und die administrative Zugriffssteuerung (DRZ_ADVANCED).
• VPC Service Controls: Richten Sie mit VPC Service Controls (VPC-SC) sichere, benutzerdefinierte Perimeter um Ihre Cloud-Sicherheitsressourcen ein.

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

Der vierstufige Sicherheitsstack :

1. Sicherheitskontrollebene des Kunden: Ihre administrativen Kontrollen der obersten Ebene, einschließlich der rollenbasierten Zugriffssteuerung (RBAC), die über Identity and Access Management (IAM) verwaltet wird, kundenverwalteter Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) und regionaler Richtlinien zum Datenstandort.
2. Sicherheitsebene der Plattform: Logische Mandantenisolierung, Standardverschlüsselung für inaktive und übertragene Daten (TLS) und Audit-Logging mit Access Transparency.
3. Google-Infrastrukturebene: Kerninfrastruktur für Computing und Speicher, einschließlich Borg-Clusterverwaltung, verteilter Colossus-Speicher und globaler Spanner-Datenbanken.
4. Physische Sicherheitsebene: Grundlegende Sicherheit, die von Google-Rechenzentren für Unternehmen, biometrischen Multi-Faktor-Kontrollen und benutzerdefinierten Titan-Sicherheitschips (roots of trust) unterstützt wird.

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

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