Sophos SIEM: Azure Event Hubs und Blob-Logs anbinden

Sophos Next-Gen SIEM kann eigene Logquellen über Azure Event Hubs oder über einen Azure Storage Account aufnehmen. Event Hubs liefert einen Ereignisstrom; bei Storage liest eine bereitgestellte Azure Function Logdateien aus einem Blob-Pfad und leitet sie weiter. Die zwei Setups sind nicht austauschbar.

Für beide Wege benötigt man eine Next-Gen-SIEM-Subscription, eine aktive Azure-Subscription und die nötigen Rechte in Sophos Fusion sowie Azure. Eine vorbereitete Datenquelle muss die gewünschten Logs tatsächlich in den Event Hub beziehungsweise Blob-Container schreiben. Für die allgemeine Integrationseinrichtung gelten passende Admin-/Super-Admin-Rechte; die Azure-Rechte werden auf die jeweils benötigten Ressourcen und die genehmigte Bereitstellung begrenzt.

Die Custom-Transportübersicht hilft bei der Auswahl. Diese Anbindung ist kein in Azure laufender Syslog Data Collector und keine automatische Ersetzung einer bestehenden Cloud- oder Microsoft-365-Integration.

Event Hubs: Voraussetzungen und Zugang vorbereiten

Unterstützt werden Standard, Premium oder Dedicated, nicht der Basic-Tier. Die aktuelle Sophos-Anleitung verlangt einen aus dem Internet erreichbaren Event Hub und nennt dabei alle IPv4-Adressen. Das ist eine sicherheitsrelevante Architekturvoraussetzung, keine pauschale Empfehlung, einen vorhandenen privaten Hub zu öffnen. Passt das nicht zu den eigenen Netzvorgaben, wird die Anbindung vor einer Firewalländerung mit den Verantwortlichen und Sophos geklärt.

Vor der Sophos-Konfiguration müssen ausgewählte Logkategorien tatsächlich in diesen Event Hub gestreamt werden, etwa über Azure-Monitor-Diagnoseeinstellungen. Welche Daten die Quelle liefert, bestimmt deren Konfiguration; eine erfolgreiche Verbindung aktiviert nicht nachträglich alle Auditlogs.

1. Im Azure-Portal die zu integrierende Event Hubs namespace öffnen und auf Overview den Host name erfassen.
2. Unter Entities > Event Hubs den richtigen Hub öffnen und dessen Name notieren. Namespace und Hubname nicht verwechseln.
3. Beim Hub Settings > Shared access policies > Add öffnen und eine dedizierte Policy für Sophos erstellen.
4. Für diese Policy Listen wählen. Sende- oder Verwaltungsrechte werden für den beschriebenen Leseweg nicht zusätzlich benötigt.
5. Die neue Policy öffnen und deren Primary Connection String geschützt speichern. Sie enthält ein Secret; Namespace, Policyname und gegebenenfalls EntityPath müssen zum vorgesehenen Hub gehören.

Die echte Connection String wird weder in Tickets noch in diese KB kopiert. Owner und das in Azure unterstützte Rotationsverfahren gehören in die Betriebsdokumentation.

Event Hubs in Sophos Fusion verbinden

1. Security Operations > Integrations > Marketplace > Custom öffnen.
2. Bei Azure Event Hubs auf Set Up klicken und unter Add an integration einen eindeutigen Namen vergeben.
3. Die zuvor geprüften Werte in Event Hubs Namespace Hostname, Event Hubs Name und Event Hubs Primary Connection String eintragen.
4. Mit Done erstellen und die Verbindung unter Configured integrations kontrollieren.
5. Ein neues, freigegebenes Quellereignis bis in den Hub und anschliessend bis Sophos verfolgen. Quelle, Tenant, Zeit und benötigte Felder müssen zusammenpassen.

Der Sophos-Consumer nutzt dynamisch verfügbare Partitionen bis zu einer Grenze von 200 Partitionen. Das ist keine Durchsatzgarantie. Der Hub-Betreiber verantwortet die passende serverseitige Kapazität. ServerBusyException im API Query Log kann auf ein Durchsatzlimit hinweisen. Bevor weitere Partitionen oder Consumer geplant werden, werden Ereignismenge und Azure-Kapazität geprüft; für eine Erhöhung paralleler Consumer verweist Sophos an den Support. Aggressives erneutes Anlegen der Integration behebt kein Kapazitätsproblem.

Storage: Blob-Pfad und Function-Plan festlegen

Für den Storage-Weg benötigt man einen Storage Account, einen Blob Container mit den gewünschten Logs und einen unterstützten Azure-Function-Service-Plan. Isolated wird nicht unterstützt. Die Sophos-Konfiguration bietet folgende Zuordnungen:

• Basic: B1, B2, B3.
• Dynamic: Y1.
• Premium: P0V3, P1MV3, P1V2, P1V3, P2MV3, P2V2, P2V3, P3MV3, P3V2, P3V3, P4MV3, P5MV3.

Diese Liste ist der Dokumentationsstand vom 5. Oktober 2026. Vor der Bereitstellung werden angebotener Plan, Region, Kapazität und Azure-Kosten geprüft. Der für Event Hubs passende Tier ist keine Auswahl für die Function.

Der Data Source Key bezeichnet den Containerordner, in dem die Logdateien entstehen. Bei einem Pfad wie MicrosoftInsights/2024-02-03/02hr/part=01/00004.json ist MicrosoftInsights das von Sophos gezeigte Beispiel für diesen Key. Man übernimmt den eigenen Logprefix, nicht blind dieses Beispiel und nicht den vollständigen Dateinamen. Ein falscher Prefix kann relevante Dateien ausschliessen oder andere Daten aufnehmen.

Storage-Integration und Azure Function bereitstellen

1. Storage-Account- und Blob-Container-Namen, Logprefix und vorgesehenen Function-Plan im richtigen Azure-Konto ermitteln. Vorher ein aktuelles Testobjekt im vorgesehenen Containerpfad belegen.
2. In Sophos Security Operations > Integrations > Marketplace > Custom öffnen und bei Azure Storage Accounts Set Up wählen.
3. Einen Integrationsnamen sowie Storage Account Name, Function App Name und Data Source Key erfassen. Der Functionname kennzeichnet den Zweck, etwa FachanwendungLogsForwarder; er ersetzt keine Prüfung der tatsächlich erzeugten Ressourcen.
4. Azure Function Service Plan Type, Azure Function Service Plan Code und Azure Function Service Plan Num Workers wählen. Der dokumentierte Standard für Workers ist 1; bei Basic B2/B3 nennt Sophos maximal 3. Zusätzliche Worker nicht als pauschale Fehlerbehebung einstellen.
5. Mit Done die Konfiguration erstellen. Das generierte AzureFunction.json-ARM-Template wird automatisch heruntergeladen. Es wird geschützt aufbewahrt und vor der Ausführung auf Ressourcen, Rechte und Kosten geprüft.
6. Im Azure-Portal das Deployment eines eigenen Templates öffnen, Build your own template in the editor wählen, AzureFunction.json laden und Save wählen.
7. Eine passende Resource Group auswählen oder anlegen. Der Storage Account darf in einer anderen Subscription beziehungsweise Resource Group als die Function liegen. Storage Account Subscription ID und Storage Account Resource Group werden nur entsprechend dieser tatsächlichen Abweichung angepasst.
8. Mit Review + Create die Parameter prüfen und nach der internen Freigabe Create wählen. Deploymentstatus und tatsächlich erzeugte Function kontrollieren, anschliessend die Integration in Sophos prüfen.

Die Quelle muss weiterhin Logs in den richtigen Blob-Container schreiben. Ein erfolgreiches ARM-Deployment allein beweist weder diesen Quellpfad noch die Weiterleitung. Eine rückwirkende vollständige Übernahme alter Containerdateien wird nicht vorausgesetzt; gewünschte Historie wird separat bestätigt.

Datenfluss abnehmen und Fehler zuordnen

Sophos nennt für diese Integrationen Azure Commercial Cloud sowie die dokumentierten US-Government-/DoD-/GCC-/GCC-High-Umgebungen. Daraus wird keine automatische Verfügbarkeit in jedem Tenant oder jeder Azure-Region abgeleitet; vor dem Deployment werden konkrete Umgebung und Endpoint geprüft.

Für beide Transporte wird ein neues harmloses Testereignis dokumentiert. Bei Event Hubs prüft man Quelle, Stream, Listen-Policy und Verbindungsdaten; bei Storage erst Blob-Pfad, dann Function-Deployment und deren Fehler. Erst danach werden Integrationsstatus und der für diese Datenquelle bestätigte Suchweg in Sophos verglichen.

Unterstützte Logtypen werden nach ihren jeweiligen Produktintegrationen normalisiert, andere können in generic landen. Die SIEM-Anleitung zu Parsern und Erkennungsgrenzen beschreibt die zusätzliche Prüfung. Ein grüner Connector, eine Datei oder ein Event-Hub-Counter beweist keine vollständige Normalisierung und keine Detection. Fehlen nur bestimmte Ereignisse, prüft man Logkategorien, Zeitfenster und Felder statt sofort Credentials zu erweitern.

Pause und Rückbau planen

Vor dem Rückbau dokumentiert man alle Datenquellen, die Hub, Container, Policy oder Function gemeinsam nutzen. Eine Pause erfolgt über den für die konkrete Quelle unterstützten Exportweg und wird anschliessend kontrolliert. Ein gemeinsam genutzter Hub oder Storage Account wird dafür nicht gelöscht.

Erst wenn Historie, benötigte Nachweise, Abhängigkeiten und Wiederanlauf geklärt sind, entfernt man die dedizierte Verbindung sowie nicht mehr benötigte Azure-Ressourcen und Secrets über deren dokumentierte Verfahren. Das Entfernen des Sophos-Eintrags garantiert weder das Löschen historischer Daten noch das Ende aller Azure-Kosten. Der weiterhin benötigte bisherige Logpfad wird nach einer Rücknahme erneut mit einem Testereignis abgenommen.