Cloud-Flow-Logs an Sophos XDR und SIEM anbinden

Cloud-Flow-Logs beschreiben Netzwerkverbindungen, nicht den vollständigen Paketinhalt. Sophos XDR kann solche Daten aus AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) und Oracle Cloud Infrastructure (OCI) aufnehmen. Der richtige Weg hängt von der Quelle ab: S3 und Lambda bei AWS, Azure Storage und Function bei Network Watcher, Pub/Sub bei GCP und Streaming bei OCI.

Netflow-Telemetrie dieser Integrationen benötigt Sophos Next-Gen SIEM. Bei GCP und OCI liefern dieselben Integrationen zusätzlich andere Schemas; daraus folgt keine pauschale SIEM-Pflicht für sämtliche Cloud-Audit- oder Sicherheitsdaten. Zuerst werden benötigte Ereigniskategorien, Tenant, Fusion-Upgrade und Entitlement geklärt. Die SIEM-Einordnung und Retention-Planung erklärt den kaufmännischen Rahmen.

Diese direkten Cloud-Anbindungen sind kein in der Cloud installierter Syslog-Collector. Für diesen anderen Betriebsweg gilt das XDR-Collector-Runbook.

Vor dem ersten Cloud-Change

Benötigt werden die zum Ziel-Tenant gehörende Produktkachel unter Security Operations > Integrations > Marketplace, freigegebene Cloud-Administrationsrechte für die jeweiligen Ressourcen und ein verantwortliches Team für laufende Kosten, Schlüssel und Datenqualität. Verfügbarkeit und sichtbare Felder werden im eigenen Tenant geprüft; fehlende Kacheln werden nicht durch eine ähnlich benannte Integration ersetzt.

Pro Quelle dokumentiert man Cloud-Konto beziehungsweise Subscription, Region, gewünschte Logkategorien, Zielintegration und Aufnahmebeginn. Berechtigungen werden auf den vorgesehenen Datenweg begrenzt. Eine für die Einrichtung nötige Administrationsrolle ist kein Grund, dauerhaft persönliche Administratorzugänge als Integrationsidentität zu verwenden. Cloud-Ressourcen wie Lambda, Storage oder Pub/Sub können eigene Kosten verursachen.

Ein grüner Integrationsstatus bestätigt die Verbindung, nicht bereits die vollständige Datenaufnahme. Zur Abnahme braucht man ein genehmigtes Testereignis mit Quellnachweis und Uhrzeit sowie den passenden normalisierten Datensatz. Die Integrationsgrundlagen erklären Rechte, Datenfluss und Response-Abgrenzung.

AWS VPC Flow Logs über ein eigenes S3-Bucket

AWS VPC Flow Logs werden aus einem eigenen Amazon-S3-Bucket aufgenommen. Sophos stellt dafür ein CloudFormation-Template bereit, das eine Lambda-Funktion zur Weiterleitung erstellt. Voraussetzung sind ein AWS-Konto, ein Bucket für die Flow-Logs und Rechte zur Erstellung der erforderlichen Lambda-, CloudFormation- und IAM-Ressourcen.

Im Sophos-Marketplace AWS VPC Flow Logs öffnen. Unter Configured integrations > Add new die S3-Information lesen, mit Next fortfahren, einen eindeutigen Integrationsnamen erfassen und Done wählen. Das nach der Provisionierung erzeugte CloudFormation-Template herunterladen und zugriffsbeschränkt ablegen.
In AWS den gewünschten VPC-Flow-Log-Export auf genau das vorgesehene S3-Bucket richten. Als Logging-Ziel ist Amazon S3 erforderlich. Nur das AWS-Standardformat verwenden; ein eigenes Format kann die Normalisierung und Erkennung beeinträchtigen.
In derselben AWS-Region wie das Log-Bucket CloudFormation > Create stack öffnen, das heruntergeladene Template hochladen und einen Stacknamen ohne Leerzeichen wählen. IntegrationType auf awsvpcflow setzen und unter NotificationBucket den Bucketnamen eintragen, keine URL oder S3-URI. Wenn bewusst SNS statt S3-Benachrichtigungen verwendet wird, gehört dessen ARN in SNSNotificationarn. Die verbleibenden Template-Parameter anhand des geplanten Datenwegs prüfen.
Die IAM-Ressourcenerstellung nach Rechteprüfung bestätigen, den Stack erstellen und auf CREATE_COMPLETE warten. Ein separates Bucket für das Template muss dafür nicht öffentlich gemacht werden.
In Lambda die durch den Stack erstellte Funktion öffnen und unter Function overview > Add Trigger das Log-Bucket als S3-Quelle hinzufügen. Event Type: All Object Create Events wählen. Prefix ist nur der tatsächliche Log-Präfix im Bucket; ohne Präfix bleibt das Feld leer. Suffix leer lassen. Die Kostenfolge der Lambda-Ausführung prüfen und den Trigger hinzufügen.
Einen passenden, harmlosen Netzwerkfluss im ausgewählten VPC-Bereich erzeugen. Zuerst den Flow-Log-Datensatz im Bucket belegen, danach denselben Zeitbereich und dieselben Verbindungsmerkmale in Sophos im Schema netflow prüfen.

Das von Sophos verlangte Standardformat lautet:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Bei ausbleibenden Daten zuerst Exportziel, neu erzeugte Objekte, Region und Trigger-Präfix vergleichen. Das Template setzt Reserved Concurrency standardmässig auf 5; dieser Wert ist keine Dimensionierungsgarantie. Last und CloudWatch-Metriken bestimmen den Bedarf. Rate Exceeded kann eine AWS-Concurrency-Quote betreffen; wiederholte Neuanlagen der Sophos-Integration lösen diese Begrenzung nicht.

Azure Network Watcher über Storage und Azure Function

Network Watcher liefert NSG Flow Logs oder VNet Flow Logs in ein Azure Storage Account. Neue NSG Flow Logs lassen sich nicht mehr erstellen. Für neue Quellen deshalb VNet Flow Logs planen. Bestehende NSG Flow Logs können bis zu ihrer Ablösung angebunden werden; Microsoft stellt die Funktion am 30. September 2027 ein. Ihre Migration auf VNet Flow Logs vor diesem Termin einplanen. Beide vorhandenen Logtypen benötigen getrennte Sophos-Integrationen, weil sie unterschiedliche Blob-Container beziehungsweise Data Source Keys verwenden.

Vorliegen müssen eine aktive Azure-Subscription, das Storage Account mit Blob-Container und aktivierten Flow-Logs sowie ein unterstützter Azure-Function-Serviceplan. Dokumentiert sind Basic mit B1, B2 oder B3, Dynamic mit Y1 und bestimmte Premium-Codes. Der Typ Isolated ist nicht unterstützt. Einen Premium-Code nur aus der aktuell angebotenen Liste wählen, nicht aus einem ähnlich benannten Azure-Tarif ableiten.

In Network Watcher für eine neue Quelle VNet Flow Logs auf das vorgesehene Storage Account schreiben lassen; bestehende NSG Flow Logs nur als Übergang bis zur Migration verwenden. Storage-Account- und Blob-Container-Namen notieren und prüfen, ob tatsächlich neue Flow-Log-Objekte ankommen.
Im Sophos-Marketplace Microsoft Azure Network Watcher - Azure Storage Account öffnen. Unter Azure Storage Accounts > Set Up eine Integration anlegen.
Storage Account Name exakt übernehmen. Function App Name ist eine eigene beschreibende Bezeichnung, etwa NSGFlowLogsForwarder; sie ist kein fester Produktwert. Den Data Source Key passend zum Logtyp setzen: insights-logs-networksecuritygroupflowevent für NSG oder insights-logs-flowlogflowevent für VNet.
Azure Function Service Plan Type, den dazu passenden Service Plan Code und Num Workers festlegen. Standardmässig ist ein Worker eingetragen. Bei Basic mit B2 oder B3 sind höchstens drei Worker dokumentiert. Diese Grenze nicht auf andere Servicepläne verallgemeinern.
Mit Done das Template AzureFunction.json erzeugen und herunterladen. Im Azure-Portal das Template über Deploy a custom template > Build your own template in the editor laden. Resource Group und Parameter prüfen, dann Review + Create und Create wählen.
Storage Account und Function dürfen in verschiedenen Subscription IDs oder Resource Groups liegen. In diesem Fall Storage Account Subscription ID und Storage Account Resource Group im Deployment ausdrücklich auf die tatsächliche Quelle setzen.
Nach dem Deployment ein erwartetes Flow-Ereignis zuerst im richtigen Container und danach als netflow in Sophos nachweisen. Bei zwei Logtypen jede Integration einzeln abnehmen.

Fehlen Daten trotz bereitgestellter Function, werden Container, Data Source Key, Subscription-/Resource-Group-Zuordnung und Serviceplan verglichen. Eine zweite Integration für denselben Datenstrom kann Duplikate erzeugen; sie ist kein allgemeiner Reparaturschritt.

GCP über Pub/Sub

GCP liefert cloudaudit, thirdpartyalert und – mit SIEM – netflow. Unterstützte Quellen umfassen Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs und GKE-Dataplane-V2-Logs. Es werden nur die bewusst ausgewählten Kategorien eingeschlossen.

Im richtigen GCP-Projekt unter Pub/Sub > Topics ein Topic erstellen. Unter Subscriptions eine Subscription für dieses Topic anlegen und die Acknowledgement deadline auf 300 Sekunden setzen.
Unter Logging > Log router > Create Sink einen Sink mit Ziel Cloud Pub/Sub topic auf dieses Topic richten. Die Inclusion Filter auf die benötigten Logquellen begrenzen. Organisations- und Folder-Logs benötigen einen dafür vorgesehenen aggregierten Sink; ein Projekt-Sink deckt diese Bereiche nicht automatisch ab.
Ein dediziertes Service Account anlegen. An der Pub/Sub-Subscription unter Add Principal dessen Service-Account-ID die Rolle Pub/Sub Subscriber zuweisen.
Zusätzlich eine Custom Role mit monitoring.timeSeries.list erstellen und dem Service Account zuweisen. Ein bereits für Sophos XDR verwendetes Konto kann wiederverwendet werden, wenn auch diese erforderliche Berechtigung freigegeben ist.
Für dieses Konto einen JSON-Schlüssel erzeugen und geschützt ablegen. Im Sophos-Marketplace GCP > Configured integrations > Add new öffnen, Integrationsname, Project ID und Pub/Sub-Subscription ID eintragen und unter Upload Key File die richtige JSON-Datei hochladen.
Die gewählten Quellen tatsächlich aktivieren: Data-Access-Auditlogs erfordern eine ausdrückliche Auswahl der Dienste unter IAM & Admin > Audit Logs. SCC-Findings werden über den dafür eingerichteten Pub/Sub-Export geliefert. VPC Flow Logs werden auf Subnet-Ebene aktiviert; ihre Sampling-Eigenschaften begrenzen die Aussagekraft gegenüber vollständigem Paketmitschnitt.
Bei GKE Dataplane V2 muss diese Funktion bereits bei der Cluster-Erstellung gewählt sein; danach die benötigte Network Policy Logging-Konfiguration und den passenden Sink-Filter prüfen. Einen bestehenden Cluster nicht allein für einen Logging-Pilot ungeplant ersetzen.
Pro aktivierter Logkategorie ein geeignetes Testereignis erzeugen und Quellnachweis, Pub/Sub-Datenweg und normalisiertes Schema getrennt prüfen.

Bei einer Schlüsselrotation zuerst den neuen JSON-Schlüssel erstellen und in der bestehenden Sophos-Integration hinterlegen. Im API Query Log zeigt secrets cache invalidated. Integration was updated. Restarting. die Aktualisierung an. Erst nach erneut nachgewiesener Datenaufnahme den alten Schlüssel in GCP löschen. Ein erfolgreicher Datei-Upload allein genügt nicht.

OCI über Streaming

OCI stellt cloudaudit, http, nids und – mit SIEM – netflow bereit. Für den Datenweg werden ein OCI-Stream, die gewünschten Logs und ein Service Connector benötigt. Die Integrationsidentität braucht für das Lesen des Streams stream-pull; pauschale Administrationsrechte für den laufenden Abruf sind dafür nicht erforderlich.

Einen dedizierten Logging-Benutzer und die freigegebene Gruppen-/Compartment-Struktur vorbereiten. Dem Benutzer nur den nötigen Lesezugriff auf den vorgesehenen Stream erteilen.
In OCI Streams > Create Stream den vorgesehenen Stream Pool wählen. Die Stream-Pool-OCID notieren; sie ist nicht mit einer beliebigen Stream- oder Compartment-ID austauschbar.
Über Connector Hub die freigegebenen Audit-, Flow-, Load-Balancer-, WAF- oder Firewall-Logs in diesen Stream leiten. Vor dem Sophos-Schritt prüfen, dass der Connector Daten in das richtige Streaming-Ziel überträgt. Ein anderes Connector-Ziel liefert diesen Stream nicht automatisch mit Daten.
Im Sophos-Marketplace OCI > Configured integrations > Add new öffnen. Name, dedizierten Username, dessen Auth token, Stream Pool ID, Tenant Name, Topic Name für den Stream und Region eintragen.
Bei verschachtelten Compartments ist Tenant Name der Tenancy-Name ohne angehängte Compartment-Kette. Für federierte Benutzer im dokumentierten OracleIdentityCloudService-Fall wird dagegen beispielsweise acme/OracleIdentityCloudService verwendet; acme steht hier für den eigenen Tenancy-Namen. Die beiden Fälle nicht vermischen.
Mit Done speichern und ein passendes Quellereignis in OCI, im Streaming-Datenweg und anschliessend im erwarteten Sophos-Schema nachweisen. Ein Cloud-Audit-Ereignis ist kein Test für den zusätzlich gewünschten netflow-Datenstrom.

Bei fehlender Aufnahme werden zuerst Stream Pool, Streamname, Region, Auth-Token und stream-pull geprüft. Geht nur eine Ereigniskategorie verloren, stehen Quellauswahl und Service-Connector-Routing vor einer pauschalen Neuerstellung der Integration.

Datenqualität und Rückbau kontrollieren

Die Abnahme dokumentiert pro Ereigniskategorie Quelle, Aufnahmebeginn, Zeitfenster, normalisiertes Schema und ein reproduzierbares Beispiel. Ereigniszeit und Zeitzone werden gegen den Quellnachweis verglichen. Ein gewöhnlicher Flow oder ein Auditdatensatz muss keine Detection oder einen MDR-Case erzeugen. Eine grüne Verbindung oder ein gefundener Datensatz beweist auch keine mehrjährige Retention.

Zum Rückbau zuerst den eigenen Datenweg und gemeinsam genutzte Ressourcen erfassen. Nur den freigegebenen Quell-Export, Sink, Trigger oder Connector stoppen; ein gemeinsames Bucket, Topic, Storage Account oder Stream nicht pauschal löschen. Nach Kontrolle, dass keine neuen Datensätze eintreffen, die zugehörige Sophos-Konfiguration und ausschliesslich dafür verwendete Schlüssel beziehungsweise Cloud-Ressourcen nach dem Change- und Aufbewahrungsentscheid entfernen. Die Löschung einer Verbindung ist kein Nachweis, dass historische Telemetrie gelöscht wurde.

Für einen fehlgeschlagenen Pilot bleiben vorherige, benötigte Logpfade erhalten. Der Rückweg besteht aus der dokumentierten Rücknahme der neuen Routing- oder Exportänderung und deren Kontrolle. Bereits übertragene Daten, Cloud-Kosten und verlorene Ereignisse lassen sich dadurch nicht automatisch zurücknehmen.