Zum Inhalt springen
Avanet
Anmelden

Sophos XDR Data Collector in AWS, Azure und GCP bereitstellen

Sophos Fusion Admin

Ein Sophos XDR Data Collector empfängt Syslog-Ereignisse und leitet sie verschlüsselt an XDR weiter. Die Cloud-Bereitstellung beginnt unter Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Danach wird für AWS, Azure oder GCP eine zur konkreten Collector-Konfiguration gehörende Vorlage erzeugt und im eigenen Cloud-Konto ausgerollt.

Die drei Wege sind keine austauschbaren VM-Images. AWS verwendet eine AMI mit CloudFormation und EC2 User Data, Azure eine VHD mit ARM-Vorlage und Custom Data, GCP eine Terraform-Konfiguration für Infrastructure Manager. Dieses Runbook beschreibt diese Cloud-Pfade; die SVA-Migration und das On-Premises-Deployment bleiben getrennt.

Vor der Bereitstellung Netz, Zuständigkeit und Kosten klären

Benötigt werden der richtige Sophos-Tenant, ein freigegebenes Cloud-Konto beziehungsweise Projekt und die Cloud-Rechte für die gewählte Vorlage. Instanz, Datenträger, Load Balancer und weitere Ressourcen können Cloud-Kosten verursachen. Vor dem Ausrollen werden Vorlage, Zielnetz, Sicherheitsregeln, Verantwortliche und Rückbauumfang geprüft. Generierte Konfigurationen und enthaltene Zugangsdaten werden zugriffsgeschützt behandelt.

Für jede Quelle hält man fest, welche Ereignisse sie im erwarteten Format an welche Zieladresse sendet. Standard-Syslog-Eingänge sind UDP/514 und TCP/601. Regeln werden auf die benötigten Quellnetze begrenzt, nicht pauschal für das Internet geöffnet. Der Collector benötigt ausgehend TCP/443 zum tatsächlich zugewiesenen regionalen XDR-Uplink sowie DNS über UDP/TCP 53 und Bootstrap-Zeitsynchronisation über UDP 123. Die konkreten regionalen Ziele werden im Collector-Migrationsrunbook eingeordnet; sie sind vor dem Change mit der aktuellen Safelist abzugleichen.

Ohne eigene NTP-Vorgabe nutzen Nicht-AWS-Collector die dokumentierten Pool-Server, AWS dagegen 169.254.169.123. Nach erfolgreichem Verbindungsaufbau übernimmt der Backend-Kanal den Zeitabgleich; Admiral kann dann ntp.collector anzeigen. Der Host-Proxy ist optional. Die allgemeine Collector-Hilfe schliesst fest konfigurierte authentifizierte Proxys aus, obwohl einzelne Einrichtungsseiten eine Syntax mit Benutzer/Passwort zeigen. Ein produktiver authentifizierter Proxy-Pfad wird deshalb erst nach Klärung mit Sophos eingeplant; Zugangsdaten im Template lösen diesen Quellenkonflikt nicht.

Gemeinsame Anlage in Sophos Fusion

  1. Security Operations > Integrations > Data Collectors > Actions > Add Collector öffnen.
  2. Cloud-Hosted wählen und mit Next fortfahren.
  3. Einen eindeutigen Name und Hostname sowie bei Bedarf Beschreibung, Host Proxy und eigene NTP-Server eintragen. Tenant, Netzzuordnung und Werte vor Create Collector prüfen.
  4. Create Collector wählen und anschliessend den passenden Cloud Service Provider auswählen. Die weiteren Angaben und Dateien gehören nur zu diesem Collector; sie dürfen nicht für mehrere unabhängige Instanzen wiederverwendet werden.

AWS: CloudFormation, ein Collector und ein NLB

Vorausgesetzt sind die richtige 12-stellige AWS Account ID, eine im Sophos-Dialog unterstützte Region und ein vorhandenes geeignetes VPC mit Subnetzen. Die Beispielvorlage erzeugt eine Launch Template mit AMI/User Data, eine statisch auf eine Instanz ausgelegte Auto Scaling Group, einen Network Load Balancer und Sicherheitsregeln für Syslog.

Der NLB arbeitet auf Layer 4 und unterstützt TCP sowie UDP. Sein stabiler DNS-Name bleibt auch bei einem Instanzersatz als Quellziel verwendbar. Ein Application Load Balancer oder klassischer ELB ist für diesen dokumentierten Aufbau kein Ersatz. Der AWS-Collector unterstützt in diesem Aufbau kein HA; die Auto Scaling Group bleibt auf Grösse 1. Zwei gleichzeitig laufende Instanzen mit identischer User Data sind nicht unterstützt.

AWS-Konfiguration ausrollen

  1. Im Sophos-Dialog Amazon Web Services (AWS) wählen, Account ID eingeben und die unterstützte AWS-Region auswählen.
  2. Bei Bedarf die YAML-Vorlage mit Download sichern und prüfen. Launch Console öffnet die CloudFormation-Seite Create stack mit der erzeugten Vorlage.
  3. CollectorName, VpcId und Subnets der vorgesehenen Umgebung zuordnen. Den im Template verwendeten VpcCidr und das zusätzliche SyslogIngress gegen die wirklich zulässigen Quellnetze prüfen. 0.0.0.0/0 wäre ein unbeschränkter IPv4-Quellbereich und wird nicht als Standard übernommen.
  4. InstanceType prüfen. Die Sophos-Vorlage verwendet c5.xlarge mit 4 vCPUs und 8 GB RAM. Die zusätzliche Datendisk muss bei einer eigenen Vorlage mindestens 200 GB gross und als /dev/sdb zugeordnet bleiben.
  5. Falls EBS-Verschlüsselung vorgesehen ist, KmsCmkArn und die erforderliche Schlüsselpolicy durch den AWS-Verantwortlichen prüfen lassen. Eine ungeeignete Policy kann eine Schleife fehlschlagender Instanzstarts auslösen.
  6. Mit Next die Stack-Optionen prüfen. Erst nach Freigabe der konkreten Ressourcen und Sicherheitsregeln mit Create stack ausrollen.
  7. Nach erfolgreicher Bereitstellung unter Stack-Outputs den Wert CTPxCollectorDnsName sichern. Diese NLB-DNS-Adresse ist das Ziel für die vorgesehenen Syslog-Quellen, nicht eine vorübergehende EC2-IP.

Den Collector-Status in Sophos Fusion kontrollieren. Weil AWS Adressen dynamisch zuweist, ist eine leere Address-Spalte dort nicht automatisch ein Fehler. Schleifen in der Auto Scaling Group werden anhand der AWS-Ereignisse eingegrenzt; bei Client.InternalError: Client error on launch und aktiver EBS-Verschlüsselung insbesondere die KMS-Schlüsselpolicy prüfen. Nicht parallel weitere Instanzen derselben Konfiguration starten.

Azure: frische ARM-Vorlage und begrenzte Bereitstellungsrechte

Vorausgesetzt sind eine Azure-Subscription und ein passendes Virtual Network mit Subnetz. Für die Sophos-Beispielvorlage sind Owner oder die Kombination Contributor + User Access Administrator erforderlich. Diese Rechte werden auf den benötigten Geltungsbereich und den freigegebenen Bereitstellungsvorgang abgestimmt, nicht automatisch allen Collector-Betreibern dauerhaft gegeben.

Die Vorlage kopiert die VHD in einen Storage Account mit privatem Container, erstellt ein Managed Image und eine einzelne Collector-VM mit Network Security Group. Der Storage Account ist für diese Aufgabe bestimmt. Die SAS-URL der VHD gilt nur drei Stunden ab Erzeugung der ARM-Vorlage. Eine alte Vorlage wird deshalb nicht unverändert erneut versucht.

Seit 3. August 2026 heruntergeladene Vorlagen verwenden für den VHD-Transfer ein temporäres Azure Deployment Script ausserhalb des Virtual Network. Dafür braucht es keine Bootstrap-VM, Bootstrap-NSG oder zusätzliche Bootstrap-Ausgangsfreigabe im VNet. Ältere Vorlagen hatten einen anderen Ablauf mit temporärer VM und Cleanup-Container; dessen Ausnahmen werden nicht vorsorglich in eine neue Bereitstellung übernommen. Für einen neuen Rollout eine frische Vorlage verwenden.

Azure-Konfiguration ausrollen

  1. Im Sophos-Dialog Microsoft Azure wählen. Bei Bedarf Download ARM Template verwenden; mit Deploy in Azure die vorbereitete Custom deployment-Seite öffnen.
  2. Subscription und die richtige Resource group wählen. Eine eigene Ressourcengruppe erleichtert die Zuordnung und den späteren Rückbau, ist aber kein Grund, gemeinsame Netzressourcen hineinzuziehen.
  3. Die Azure-Region passend zum vorgesehenen VNet wählen. Vm Name und Vm Size festlegen; Sophos empfiehlt in der aktuellen Anleitung Standard_D4s_v3.
  4. Ressourcengruppe des VNet, Azure Virtual Network und Azure Virtual Network Subnet exakt zuordnen. Bei Static Private IP eine freie passende Adresse eintragen oder für automatische Zuweisung leer lassen.
  5. Utc Now und Random Seed auf den generierten Standardwerten belassen. Sie dienen eindeutigen Deployment-Namen beziehungsweise dem temporären Passwort während der Bereitstellung.
  6. Die erzeugten NSG-Regeln prüfen: dokumentiert sind eingehend UDP/514 und TCP/601 aus dem VNet sowie ausgehend der erforderliche XDR-, DNS- und NTP-Verkehr. Andere eigene Netz- und Sicherheitsvorgaben müssen in der Vorlage berücksichtigt werden.
  7. Marketplace-Bedingungen prüfen und erst nach der Ressourcenfreigabe mit Purchase die Bereitstellung starten. Anschliessend Azure-Deploymentergebnis und Collector-Status in Sophos Fusion abgleichen.

Bei einer angepassten Vorlage bleibt die zusätzliche Datendisk mindestens 200 GB gross und als /dev/sdc zugeordnet. Auch Azure unterstützt in diesem dokumentierten Aufbau kein HA; ein gegebenenfalls selbst verwendetes VM Scale Set darf nur eine Instanz mit dieser Custom Data betreiben. Eine funktionierende Collector-VM allein aktiviert keine Microsoft-365-Auditintegration; diese Datenquelle wird separat konfiguriert und geprüft.

GCP: Infrastructure Manager und ein eigener Service Account

Für GCP werden ein freigegebenes Projekt, aktivierte Infrastructure Manager API, Cloud Shell oder eine bereits verfügbare gcloud CLI und ein user-managed Service Account benötigt. Der automatisch verwaltete Account <numeric ID>@cloudservices.gserviceaccount.com ist dafür laut Sophos nicht geeignet.

Der für die Bereitstellung zuständige Administrator richtet den Account, beispielsweise infra-manager-sa, mit den dokumentierten Rollen roles/compute.instanceAdmin.v1, roles/compute.securityAdmin und roles/config.agent im Zielprojekt ein. Sie erlauben das Erstellen von Instanzen/Disks, das Verwalten von Firewallregeln und die Arbeit von Infrastructure Manager. Die Freigabe dieser Schreibrechte ist ein eigener Vorbereitungsschritt; ein lesender Collector-Review benötigt sie nicht.

GCP-Konfiguration erzeugen und anwenden

  1. Im Sophos-Dialog Google Cloud Platform (GCP) wählen und die GCP Project ID eintragen.
  2. Unter Service Agent ID den dafür vorgesehenen user-managed Service Account zuordnen. Trotz der Feldbezeichnung nicht den Google-managed Service Agent verwenden.
  3. GCP Region, GCP Zone, Network Name, Subnet Name und den vorgesehenen Network CIDR kontrollieren. Der CIDR-Wert muss zu den beabsichtigten Firewallregeln passen; keine pauschale Internetfreigabe eintragen.
  4. Mit Download das erzeugte Terraform-Archiv sichern. In der richtigen GCP-Projektkonsole Cloud Shell öffnen, das konkrete ZIP hochladen und in ein eigenes Verzeichnis entpacken. Der gewählte Dateiname muss zum neu erzeugten Collector gehören.
unzip collector-*.zip -d collector-infrastructure

Das Herstellerbeispiel verwendet einen Dateiplatzhalter. Im Arbeitsverzeichnis muss deshalb genau das beabsichtigte Archiv liegen; bei mehreren passenden Dateien stattdessen dessen exakten Namen verwenden. Die Terraform-Dateien vor dem Anwenden auf Ressourcen, Netze, Firewallregeln und Identität prüfen. Die Konfiguration erzeugt eine Compute-Instanz mit Netzwerkschnittstelle und eine mindestens 200 GB grosse Datendisk unter /dev/sdb.

Für die Bereitstellung dokumentiert Sophos folgenden Befehl:

gcloud infra-manager deployments apply \
  projects/PROJECT_ID/locations/LOCATION/deployments/taegis-collector \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-manager-sa@PROJECT_ID.iam.gserviceaccount.com \
  --local-source="./collector-infrastructure" \
  --tf-version-constraint="1.5.7"

PROJECT_ID wird überall durch das freigegebene Zielprojekt ersetzt, LOCATION durch eine unterstützte Infrastructure-Manager-Location. Der Service-Account-Name muss mit dem tatsächlich bereitgestellten Account übereinstimmen. taegis-collector bezeichnet die Deployment-Ressource und darf nicht unbeabsichtigt ein bestehendes anderes Deployment überschreiben. apply erstellt beziehungsweise ändert echte Cloud-Ressourcen; diesen Befehl erst nach Prüfung und Freigabe anwenden.

Sophos nennt gcloud infra-manager previews create als vorgelagerten Vorschauweg. Auch eine Vorschau wird im richtigen Projekt mit freigegebenem Account ausgeführt; sie ersetzt keine Prüfung der angezeigten Änderungen. Nach einem erfolgreichen Apply Collector-Status und Quellen prüfen. Laut Anleitung sollte Provisioning innerhalb von höchstens zehn Minuten verlassen werden; bleibt der Zustand bestehen, Deployment- und Verbindungsfehler untersuchen statt das gleiche Deployment unkontrolliert mehrfach anzulegen.

Shared VPC: Netzwerk- und Serviceprojekt trennen

Standardmässig erwartet die Vorlage Netzwerk und Instanz im selben Projekt. Bei Shared VPC besitzt das Host Project VPC, Subnetze und Firewallregeln; das Service Project enthält Collector-Instanz und Disk. Beide Projekte müssen vorliegen.

Der Organisationsadministrator aktiviert Shared VPC im Hostprojekt und ordnet das Serviceprojekt zu. Dafür ist roles/compute.xpnAdmin auf Organisationsebene erforderlich, keine gewöhnliche Projektrolle. Anschliessend erhält der im Serviceprojekt liegende infra-manager-sa im Hostprojekt zusätzlich roles/compute.securityAdmin für Firewallregeln und roles/compute.networkUser für die Netznutzung.

Im Sophos-Wizard wird Network Project ID mit der Hostprojekt-ID gefüllt; die übrigen Projektangaben bleiben beim Serviceprojekt. Auch PROJECT_ID im Apply-Ziel und in der Service-Account-Adresse bleibt die Serviceprojekt-ID. Vor der Freigabe diese Zuordnung getrennt zurücklesen: Ein Wechsel aller Platzhalter zum Hostprojekt würde die beabsichtigte Ressourcentrennung aufheben.

Quellen abnehmen und Konfiguration dauerhaft erhalten

Nach erfolgreichem Cloud-Deployment muss der Collector in Sophos Fusion erreichbar sein. Danach eine begrenzte Pilotquelle mit passendem Syslog-Format an die richtige Cloud-Zieladresse senden lassen. Quelle, Zeit, Ereignistyp und erwartete Felder im XDR-Suchweg vergleichen. Ein gesunder Collector oder ein erfolgreicher Cloud-Stack beweist noch keine vollständige Datenaufnahme und Normalisierung.

Das Betriebsrunbook erklärt Quellansicht, Backlog und Admiral. Erst nach der Pilotabnahme weitere Quellen umstellen; bestehende Logwege bis zur vereinbarten Abnahme erhalten. Ein Collector ersetzt weder das SIEM-Entitlement und Retention-Inventar noch eine produktspezifische API-Integration.

Wird die Collector-Konfiguration später in Sophos Fusion geändert, die neuen Bereitstellungsdateien sichern und auch die vorhandene Cloud-Bereitstellung nachführen: AWS-CloudFormation-Stack mit aktueller Vorlage, Azure-Deployment mit aktueller ARM-Vorlage, GCP-Deployment mit der neuen Terraform-Konfiguration. Andernfalls kann ein späterer Instanzersatz wieder die alten Bootstrap-Werte verwenden. Eine erfolgreiche Online-Änderung allein belegt diese Persistenz nicht.

Für einen Rückbau zuerst Quellen auf den erhaltenen vorherigen Pfad zurückstellen und dort frische Ereignisse nachweisen. Danach nur die eindeutig zugeordneten Collector-Ressourcen nach dem jeweiligen Cloud-Change-Verfahren entfernen. Gemeinsam genutzte VPCs/VNets, Subnetze, Schlüssel oder Service Accounts werden nicht als pauschale „Collector-Bereinigung“ gelöscht. Ein Infrastruktur-Rollback stellt nicht automatisch bereits ausgefallene oder falsch normalisierte historische Ereignisse wieder her.