Sophos XDR Data Collectors uitrollen in AWS, Azure en GCP

Een Sophos XDR Data Collector ontvangt syslog-events en stuurt ze versleuteld naar XDR. Clouddeployment begint onder Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Daarna wordt voor AWS, Azure of GCP een template voor de specifieke collectorconfiguratie gegenereerd en in het eigen cloudaccount uitgerold.

De drie routes gebruiken geen onderling uitwisselbare VM-images. AWS gebruikt een AMI met CloudFormation en EC2 User Data, Azure een VHD met ARM-template en Custom Data, GCP een Terraform-configuratie voor Infrastructure Manager. Dit runbook beschrijft deze cloudroutes; SVA-migratie en on-premises deployment blijven apart.

Vooraf netwerk, verantwoordelijkheid en kosten vastleggen

Nodig zijn de juiste Sophos-tenant, een goedgekeurd cloudaccount of project en cloudrechten voor de gekozen template. Instanties, disks, load balancers en andere resources kunnen cloudkosten veroorzaken. Controleer vóór uitrollen template, doelnetwerk, beveiligingsregels, verantwoordelijken en verwijderingsscope. Beperk toegang tot gegenereerde configuraties en eventuele daarin opgenomen credentials.

Leg per bron vast welke gebeurtenissen deze in het verwachte formaat naar welk doeladres stuurt. Standaard syslog-ingangen zijn UDP/514 en TCP/601. Beperk regels tot benodigde bronnetwerken in plaats van ze voor het hele internet open te stellen. Uitgaand heeft de collector TCP/443 naar de toegewezen regionale XDR-uplink nodig, plus DNS via UDP/TCP 53 en bootstrap-tijdsynchronisatie via UDP 123. Het collectormigratierunbook duidt de regionale doelen; vergelijk deze vóór de wijziging met de actuele safelist.

Zonder eigen NTP-instelling gebruiken niet-AWS-collectors de gedocumenteerde poolservers; AWS gebruikt 169.254.169.123. Na verbinding verloopt tijdsynchronisatie via het backendkanaal; Admiral kan dan ntp.collector tonen. Host Proxy is optioneel. De algemene collectorhulp sluit vast geconfigureerde geauthenticeerde proxy’s uit, hoewel sommige installatiepagina’s syntax met gebruiker/wachtwoord tonen. Stem een geauthenticeerd productieproxypad daarom eerst met Sophos af; credentials in de template lossen dit bronnenconflict niet op.

Gemeenschappelijke aanmaak in Sophos Fusion

1. Open Security Operations > Integrations > Data Collectors > Actions > Add Collector.
2. Kies Cloud-Hosted en ga verder met Next.
3. Voer een unieke Name en Hostname in, eventueel met beschrijving, Host Proxy en eigen NTP-servers. Controleer tenant, netwerktoewijzing en waarden vóór Create Collector.
4. Kies Create Collector en daarna de passende Cloud Service Provider. Verdere gegevens en bestanden horen alleen bij deze collector en mogen niet voor meerdere onafhankelijke instanties worden hergebruikt.

AWS: CloudFormation, één collector en een NLB

Vereist zijn de juiste 12-cijferige AWS Account ID, een in de Sophos-dialoog ondersteunde regio en een geschikt bestaand VPC met subnetten. De voorbeeldtemplate maakt een Launch Template met AMI/User Data, een statisch op één instantie ingestelde Auto Scaling Group, een Network Load Balancer en syslog-beveiligingsregels.

De NLB werkt op Layer 4 en ondersteunt TCP en UDP. De stabiele DNS-naam blijft bij vervanging van een instantie als doel voor bronnen bruikbaar. Een Application Load Balancer of klassieke ELB vervangt deze gedocumenteerde opzet niet. De AWS-collector ondersteunt in deze opzet geen HA; de Auto Scaling Group blijft op grootte 1. Twee gelijktijdige instanties met dezelfde User Data worden niet ondersteund.

AWS-configuratie uitrollen

1. Kies in de Sophos-dialoog Amazon Web Services (AWS), voer de Account ID in en selecteer de ondersteunde AWS-regio.
2. Bewaar en controleer zo nodig de YAML-template via Download. Launch Console opent CloudFormation Create stack met de gegenereerde template.
3. Koppel CollectorName, VpcId en Subnets aan de bedoelde omgeving. Controleer VpcCidr en de aanvullende SyslogIngress tegen werkelijk toegestane bronnetwerken. 0.0.0.0/0 is een onbeperkt IPv4-bronbereik en wordt niet als standaard overgenomen.
4. Controleer InstanceType. De Sophos-template gebruikt c5.xlarge met 4 vCPU’s en 8 GB RAM. In een eigen template moet de aanvullende datadisk minimaal 200 GB groot blijven en aan /dev/sdb gekoppeld zijn.
5. Laat bij EBS-encryptie KmsCmkArn en de benodigde sleutelpolicy door de AWS-verantwoordelijke controleren. Een onjuiste policy kan herhaald mislukte instantiestarts veroorzaken.
6. Controleer met Next de stackopties. Rol pas met Create stack uit nadat de concrete resources en beveiligingsregels zijn goedgekeurd.
7. Bewaar na succesvolle deployment CTPxCollectorDnsName onder stack-Outputs. Dit NLB-DNS-adres is het doel voor de bedoelde syslog-bronnen, niet een tijdelijke EC2-IP.

Controleer collectorstatus in Sophos Fusion. Omdat AWS adressen dynamisch toewijst, betekent een lege Address-kolom daar niet automatisch een fout. Onderzoek herhaalde starts in de Auto Scaling Group aan de hand van AWS-events; controleer bij Client.InternalError: Client error on launch met actieve EBS-encryptie vooral de KMS-sleutelpolicy. Start niet parallel extra instanties met dezelfde configuratie.

Azure: verse ARM-template en afgebakende deploymentrechten

Vereist zijn een Azure-subscription en een geschikt Virtual Network met subnet. De Sophos-voorbeeldtemplate vereist Owner of Contributor + User Access Administrator. Stem deze rechten af op de benodigde scope en goedgekeurde deployment, in plaats van ze standaard permanent aan alle collectorbeheerders toe te kennen.

De template kopieert de VHD naar een Storage Account met private container, maakt een Managed Image en één collector-VM met Network Security Group. Het Storage Account is voor deze taak bedoeld. De SAS-URL van de VHD is slechts drie uur geldig vanaf het genereren van de ARM-template. Probeer daarom een oude template niet simpelweg ongewijzigd opnieuw.

Templates die op of na 3 augustus 2026 zijn gedownload, gebruiken voor de VHD-overdracht een tijdelijk Azure Deployment Script buiten het Virtual Network. Hiervoor zijn geen bootstrap-VM, bootstrap-NSG of aanvullende bootstrap-uitgangsuitzondering in het VNet nodig. Oudere templates gebruikten een ander ontwerp met tijdelijke VM en cleanup-container; neem die uitzonderingen niet preventief over in een nieuwe deployment. Gebruik voor een nieuwe uitrol een verse template.

Azure-configuratie uitrollen

1. Kies Microsoft Azure in de Sophos-dialoog. Gebruik zo nodig Download ARM Template; Deploy in Azure opent de voorbereide pagina Custom deployment.
2. Kies Subscription en de juiste Resource group. Een eigen resourcegroep vereenvoudigt identificatie en latere verwijdering, maar rechtvaardigt niet om gedeelde netwerkresources daarin te plaatsen.
3. Kies een Azure-regio passend bij het bedoelde VNet. Stel Vm Name en Vm Size in; Sophos adviseert in de huidige handleiding Standard_D4s_v3.
4. Wijs de VNet-resourcegroep, Azure Virtual Network en Azure Virtual Network Subnet exact toe. Vul bij Static Private IP een vrij passend adres in of laat het veld leeg voor automatische toewijzing.
5. Laat Utc Now en Random Seed op de gegenereerde standaardwaarden. Ze dienen respectievelijk voor unieke deploymentnamen en het tijdelijke wachtwoord tijdens deployment.
6. Controleer de gegenereerde NSG-regels: gedocumenteerd zijn inkomend UDP/514 en TCP/601 uit het VNet, plus het benodigde uitgaande XDR-, DNS- en NTP-verkeer. Verwerk andere eigen netwerk- en beveiligingseisen in de template.
7. Controleer Marketplace-voorwaarden en start pas na resourcegoedkeuring met Purchase. Vergelijk daarna het Azure-deploymentresultaat met collectorstatus in Sophos Fusion.

Bij een aangepaste template blijft de extra datadisk minimaal 200 GB en gekoppeld aan /dev/sdc. Ook Azure ondersteunt in deze gedocumenteerde opzet geen HA; een eventueel zelf gebruikt VM Scale Set mag maar één instantie met deze Custom Data draaien. Een werkende collector-VM activeert op zichzelf geen Microsoft-365-auditintegratie; configureer en controleer die bron apart.

GCP: Infrastructure Manager en een eigen Service Account

GCP vereist een goedgekeurd project, geactiveerde Infrastructure Manager API, Cloud Shell of een al beschikbare gcloud CLI en een user-managed Service Account. De door Google beheerde account <numeric ID>@cloudservices.gserviceaccount.com is volgens Sophos niet geschikt.

De deploymentbeheerder maakt de account, bijvoorbeeld infra-manager-sa, met de gedocumenteerde rollen roles/compute.instanceAdmin.v1, roles/compute.securityAdmin en roles/config.agent in het doelproject. Deze staan het maken van instanties/disks, beheren van firewallregels en Infrastructure-Manager-werkzaamheden toe. Goedkeuring van deze schrijfrechten is een aparte voorbereiding; een alleen-lezen collectorreview heeft ze niet nodig.

GCP-configuratie genereren en toepassen

1. Kies Google Cloud Platform (GCP) in de Sophos-dialoog en voer GCP Project ID in.
2. Wijs bij Service Agent ID de bedoelde user-managed Service Account toe. Gebruik ondanks de veldnaam niet de Google-managed Service Agent.
3. Controleer GCP Region, GCP Zone, Network Name, Subnet Name en de bedoelde Network CIDR. De CIDR moet bij de beoogde firewallregels passen; vul geen algemene internetvrijgave in.
4. Bewaar het gegenereerde Terraform-archief via Download. Open Cloud Shell in de juiste GCP-projectconsole, upload het concrete ZIP-bestand en pak het uit in een eigen map. De bestandsnaam moet bij de nieuw gegenereerde collector horen.

unzip collector-*.zip -d collector-infrastructure

Het leveranciersvoorbeeld gebruikt een wildcard. De werkmap moet daarom precies het bedoelde archief bevatten; gebruik bij meerdere overeenkomende bestanden de exacte bestandsnaam. Controleer vóór toepassen de Terraform-bestanden op resources, netwerken, firewallregels en identiteit. De configuratie maakt een Compute-instantie met netwerkinterface en een datadisk van minimaal 200 GB onder /dev/sdb.

Sophos documenteert het volgende deploymentcommando:

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"

Vervang overal PROJECT_ID door het goedgekeurde doelproject en LOCATION door een ondersteunde Infrastructure-Manager-locatie. De Service-Account-naam moet overeenkomen met de daadwerkelijk aangemaakte account. taegis-collector benoemt de deploymentresource en mag niet onbedoeld een andere bestaande deployment overschrijven. apply maakt of wijzigt echte cloudresources; voer dit pas na controle en goedkeuring uit.

Sophos noemt gcloud infra-manager previews create als voorafgaande previewmogelijkheid. Ook een preview wordt in het juiste project met een goedgekeurde account uitgevoerd en vervangt geen controle van de getoonde wijzigingen. Controleer na een geslaagde Apply collectorstatus en bronnen. Volgens de handleiding moet Provisioning binnen maximaal tien minuten eindigen; onderzoek anders deployment- en verbindingsfouten in plaats van dezelfde deployment onbeheerst meermaals aan te maken.

Shared VPC: netwerk- en serviceproject scheiden

Standaard verwacht de template netwerk en instantie in hetzelfde project. Bij Shared VPC bezit het Host Project VPC, subnetten en firewallregels; het Service Project bevat collectorinstantie en disk. Beide projecten moeten al bestaan.

De organisatiebeheerder activeert Shared VPC in het hostproject en koppelt het serviceproject. Hiervoor is roles/compute.xpnAdmin op organisatieniveau nodig, geen gewone projectrol. Daarna krijgt infra-manager-sa uit het serviceproject in het hostproject aanvullend roles/compute.securityAdmin voor firewallregels en roles/compute.networkUser voor netwerkgebruik.

Vul in de Sophos-wizard Network Project ID met de hostproject-ID; laat overige projectgegevens naar het serviceproject verwijzen. Ook PROJECT_ID in het Apply-doel en het Service-Account-adres blijft de serviceproject-ID. Lees deze toewijzing vóór goedkeuring apart terug: alle placeholders door het hostproject vervangen zou de bedoelde resourcescheiding opheffen.

Bronnen valideren en configuratie blijvend bewaren

Na succesvolle clouddeployment moet de collector in Sophos Fusion bereikbaar zijn. Laat daarna een beperkte pilotbron in passend syslog-formaat naar het juiste clouddoel verzenden. Vergelijk bron, tijd, gebeurtenistype en verwachte velden via het XDR-zoekpad. Een gezonde collector of geslaagde cloudstack bewijst geen volledige opname en normalisatie.

Het beheerrunbook verklaart bronweergave, backlog en Admiral. Zet verdere bronnen pas na pilotvalidatie om; behoud bestaande logpaden tot de afgesproken acceptatie. Een collector vervangt noch SIEM-entitlement en retentie-inventaris, noch een productspecifieke API-integratie.

Als de collectorconfiguratie later in Sophos Fusion wordt gewijzigd, bewaar dan de nieuwe deploymentbestanden en werk ook de bestaande clouddeployment bij: de AWS-CloudFormation-stack met actuele template, Azure-deployment met actuele ARM-template en GCP-deployment met de nieuwe Terraform-configuratie. Anders kan een latere instantie-vervanging oude bootstrapwaarden terugbrengen. Alleen een geslaagde onlinewijziging bewijst deze persistentie niet.

Herstel voor terugbouw eerst de bronnen naar het behouden eerdere pad en toon daar verse events aan. Verwijder daarna alleen eenduidig toegewezen collectorresources via de betreffende cloudwijzigingsprocedure. Verwijder gedeelde VPC’s/VNets, subnetten, sleutels of Service Accounts niet als algemene “collectoropruiming”. Een infrastructuurrollback herstelt niet automatisch eerder uitgevallen of verkeerd genormaliseerde historische gebeurtenissen.