Hoppa till innehållet
Avanet
Logga in

Driftsätt Sophos XDR Data Collectors i AWS, Azure och GCP

Sophos Fusion Admin

En Sophos XDR Data Collector tar emot syslog-händelser och skickar dem krypterat till XDR. Molndriftsättning börjar under Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Därefter skapas en mall för AWS, Azure eller GCP, kopplad till den specifika collectorkonfigurationen, och driftsätts i det egna molnkontot.

De tre vägarna använder inte utbytbara VM-avbilder. AWS använder en AMI med CloudFormation och EC2 User Data, Azure en VHD med ARM-mall och Custom Data, GCP en Terraform-konfiguration för Infrastructure Manager. Runbooken beskriver dessa molnvägar; SVA-migrering och lokal driftsättning är separata.

Klarlägg nätverk, ansvar och kostnader före driftsättning

Rätt Sophos-tenant, godkänt molnkonto eller projekt och molnbehörigheter för vald mall krävs. Instanser, diskar, lastbalanserare och andra resurser kan ge molnkostnader. Granska mall, målnät, säkerhetsregler, ansvariga och avvecklingsomfattning före driftsättning. Skydda genererade konfigurationer och eventuella credentials som de innehåller.

Dokumentera vilka händelser varje källa skickar i förväntat format till vilken måladress. Standardingångar för syslog är UDP/514 och TCP/601. Begränsa regler till nödvändiga källnät, öppna inte för hela internet. Collectorn behöver utgående TCP/443 till sin tilldelade regionala XDR-uplink, DNS över UDP/TCP 53 och bootstrap-tidssynkronisering över UDP 123. Migreringsrunbooken beskriver regionala mål; jämför dem med aktuell safelist före ändringen.

Utan egna NTP-inställningar använder collectors utanför AWS dokumenterade poolservrar; AWS använder 169.254.169.123. Efter lyckad anslutning sköter backendkanalen tidssynkroniseringen; Admiral kan då visa ntp.collector. Host Proxy är valfritt. Den allmänna collectorhjälpen utesluter fast konfigurerade autentiserade proxyer, även om vissa installationssidor visar syntax med användare/lösenord. Klarlägg därför en autentiserad produktionsproxy med Sophos först; credentials i mallen löser inte källkonflikten.

Gemensamt skapande i Sophos Fusion

  1. Öppna Security Operations > Integrations > Data Collectors > Actions > Add Collector.
  2. Välj Cloud-Hosted och fortsätt med Next.
  3. Ange unikt Name och Hostname, vid behov beskrivning, Host Proxy och egna NTP-servrar. Kontrollera tenant, nättilldelning och värden före Create Collector.
  4. Välj Create Collector och sedan rätt Cloud Service Provider. Efterföljande inställningar och filer hör bara till denna collector och får inte återanvändas för flera oberoende instanser.

AWS: CloudFormation, en collector och en NLB

Rätt 12-siffriga AWS Account ID, en region som Sophos-dialogen stöder och ett lämpligt befintligt VPC med subnät krävs. Exempelmallen skapar en Launch Template med AMI/User Data, en statiskt dimensionerad Auto Scaling Group med en instans, en Network Load Balancer och syslog-säkerhetsregler.

NLB arbetar på Layer 4 och stöder TCP och UDP. Dess stabila DNS-namn kan fortsatt användas som källornas mål när instansen byts ut. En Application Load Balancer eller klassisk ELB ersätter inte denna dokumenterade konstruktion. AWS-collectorn stöder inte HA i detta upplägg; Auto Scaling Group ska ha storlek 1. Två samtidiga instanser med identisk User Data stöds inte.

Driftsätt AWS-konfigurationen

  1. Välj Amazon Web Services (AWS) i Sophos-dialogen, ange Account ID och välj den stödda AWS-regionen.
  2. Spara och granska vid behov YAML-mallen via Download. Launch Console öppnar CloudFormations Create stack med den genererade mallen.
  3. Koppla CollectorName, VpcId och Subnets till avsedd miljö. Kontrollera mallens VpcCidr och extra SyslogIngress mot faktiskt tillåtna källnät. 0.0.0.0/0 är ett obegränsat IPv4-källintervall och ska inte antas vara standard.
  4. Kontrollera InstanceType. Sophos-mallen använder c5.xlarge med 4 vCPU:er och 8 GB RAM. I en egen mall måste den extra datadisken vara minst 200 GB och fortsatt kopplad som /dev/sdb.
  5. Om EBS-kryptering ska användas kontrollerar AWS-ansvarig KmsCmkArn och nyckelpolicyn. Fel policy kan orsaka återkommande misslyckade instansstarter.
  6. Granska stackalternativ med Next. Driftsätt med Create stack först när resurserna och säkerhetsreglerna godkänts.
  7. Spara CTPxCollectorDnsName från stackens Outputs efter lyckad driftsättning. Denna NLB-DNS-adress är målet för syslog-källorna, inte en tillfällig EC2-IP.

Kontrollera collectorstatus i Sophos Fusion. Eftersom AWS tilldelar adresser dynamiskt betyder en tom Address-kolumn inte automatiskt fel. Undersök startloopar i Auto Scaling Group via AWS-händelser; kontrollera särskilt KMS-nyckelpolicyn vid Client.InternalError: Client error on launch och aktiv EBS-kryptering. Starta inte fler instanser med samma konfiguration parallellt.

Azure: färsk ARM-mall och avgränsade driftsättningsrättigheter

En Azure-prenumeration och ett lämpligt Virtual Network med subnät krävs. Sophos exempelmalls behörighetskrav är Owner eller Contributor + User Access Administrator. Begränsa dem till nödvändig omfattning och godkänd driftsättning, i stället för att ge dem permanent till alla collectoroperatörer.

Mallen kopierar VHD till ett Storage Account med privat container, skapar en Managed Image och en enda collector-VM med Network Security Group. Storage Account är avsett för denna uppgift. VHD-filens SAS-URL gäller bara tre timmar från att ARM-mallen genereras. Försök därför inte bara igen med en gammal oförändrad mall.

Mallar hämtade från och med 3 augusti 2026 använder ett tillfälligt Azure Deployment Script utanför Virtual Network för VHD-överföringen. Detta kräver ingen bootstrap-VM, bootstrap-NSG eller extra bootstrap-undantagsregel för utgående trafik i VNet. Äldre mallar använde en annan konstruktion med tillfällig VM och städcontainer; för inte över deras undantag förebyggande till en ny installation. Använd en färsk mall vid ny driftsättning.

Driftsätt Azure-konfigurationen

  1. Välj Microsoft Azure i Sophos-dialogen. Använd Download ARM Template vid behov; Deploy in Azure öppnar den förberedda sidan Custom deployment.
  2. Välj Subscription och rätt Resource group. En egen resursgrupp förenklar identifiering och avveckling, men är inget skäl att flytta gemensamma nätresurser dit.
  3. Välj Azure-region som passar avsett VNet. Ange Vm Name och Vm Size; Sophos rekommenderar Standard_D4s_v3 i aktuell guide.
  4. Ange exakt VNet-resursgrupp, Azure Virtual Network och Azure Virtual Network Subnet. Ange en ledig lämplig Static Private IP eller lämna tomt för automatisk tilldelning.
  5. Behåll de genererade standardvärdena för Utc Now och Random Seed. De ger unika driftsättningsnamn respektive ett tillfälligt lösenord under driftsättningen.
  6. Granska genererade NSG-regler: dokumenterat är inkommande UDP/514 och TCP/601 från VNet samt nödvändig utgående XDR-, DNS- och NTP-trafik. Beakta andra egna nät- och säkerhetskrav i mallen.
  7. Granska Marketplace-villkoren och starta med Purchase först efter resursgodkännande. Jämför sedan Azure-resultatet med collectorstatus i Sophos Fusion.

I en anpassad mall förblir extra datadisken minst 200 GB och kopplad som /dev/sdc. Inte heller Azure stöder HA i detta dokumenterade upplägg; ett eventuellt egenanvänt VM Scale Set får bara köra en instans med denna Custom Data. En fungerande collector-VM aktiverar inte ensam en Microsoft 365-auditintegration; konfigurera och verifiera den datakällan separat.

GCP: Infrastructure Manager och ett eget Service Account

GCP kräver ett godkänt projekt, aktiverat Infrastructure Manager API, Cloud Shell eller redan tillgänglig gcloud CLI och ett user-managed Service Account. Det Google-hanterade kontot <numeric ID>@cloudservices.gserviceaccount.com är enligt Sophos olämpligt.

Driftsättningsadministratören skapar kontot, exempelvis infra-manager-sa, med de dokumenterade rollerna roles/compute.instanceAdmin.v1, roles/compute.securityAdmin och roles/config.agent i målprojektet. De tillåter skapande av instanser/diskar, hantering av brandväggsregler och arbete med Infrastructure Manager. Godkännande av dessa skrivrättigheter är ett separat förberedelsesteg; en läsande collectorgranskning behöver dem inte.

Generera och tillämpa GCP-konfigurationen

  1. Välj Google Cloud Platform (GCP) i Sophos-dialogen och ange GCP Project ID.
  2. Tilldela det avsedda user-managed Service Account under Service Agent ID. Använd inte Google-managed Service Agent trots fältnamnet.
  3. Kontrollera GCP Region, GCP Zone, Network Name, Subnet Name och avsett Network CIDR. CIDR ska passa brandväggsreglernas avsedda omfattning; ange ingen generell internetöppning.
  4. Spara det genererade Terraform-arkivet med Download. Öppna Cloud Shell i rätt GCP-projektkonsol, ladda upp rätt ZIP och packa upp i en egen katalog. Filnamnet måste höra till den nygenererade collectorn.
unzip collector-*.zip -d collector-infrastructure

Tillverkarexemplet använder ett jokertecken. Arbetskatalogen måste därför innehålla exakt det avsedda arkivet; använd exakt filnamn om flera filer matchar. Granska Terraform-filer för resurser, nätverk, brandväggsregler och identitet innan tillämpning. Konfigurationen skapar en Compute-instans med nätverksgränssnitt och en datadisk på minst 200 GB som /dev/sdb.

Sophos dokumenterar följande driftsättningskommando:

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"

Ersätt PROJECT_ID överallt med godkänt målprojekt och LOCATION med en stödd Infrastructure Manager-plats. Service Account-namnet måste stämma med det faktiskt skapade kontot. taegis-collector namnger driftsättningsresursen och får inte oavsiktligt skriva över en annan befintlig driftsättning. apply skapar eller ändrar verkliga molnresurser; kör först efter granskning och godkännande.

Sophos anger gcloud infra-manager previews create som föregående förhandsgranskningsväg. Även förhandsgranskningar görs i rätt projekt med godkänt konto och ersätter inte kontroll av ändringarna som visas. Kontrollera collectorstatus och källor efter lyckad Apply. Enligt guiden ska Provisioning upphöra inom högst tio minuter; utred annars driftsättnings- och anslutningsfel i stället för att skapa samma driftsättning flera gånger okontrollerat.

Shared VPC: skilj nätverksprojekt och serviceprojekt

Standardmallen förutsätter nätverk och instans i samma projekt. Med Shared VPC äger Host Project VPC, subnät och brandväggsregler; Service Project innehåller collectorinstans och disk. Båda projekten måste finnas först.

Organisationsadministratören aktiverar Shared VPC i värdprojektet och ansluter serviceprojektet. Det kräver roles/compute.xpnAdmin på organisationsnivå, ingen vanlig projektroll. Därefter får infra-manager-sa från serviceprojektet även roles/compute.securityAdmin för brandväggsregler och roles/compute.networkUser för nätanvändning i värdprojektet.

I Sophos-guiden fylls Network Project ID med värdprojektets ID; övriga projektuppgifter pekar fortsatt på serviceprojektet. Även PROJECT_ID i Apply-målet och Service Account-adressen förblir serviceprojektets ID. Läs tillbaka tilldelningen separat före godkännande: att byta alla platshållare till värdprojektet skulle upphäva avsedd resursseparering.

Verifiera källor och bevara beständig konfiguration

Efter lyckad molndriftsättning måste collectorn kunna nås i Sophos Fusion. Låt därefter en begränsad pilotkälla skicka rätt syslog-format till korrekt molnmål. Jämför källa, tid, händelsetyp och förväntade fält via XDR-sökvägen. En frisk collector eller lyckad molnstack bevisar inte fullständig insamling och normalisering.

Driftrunbooken beskriver källvyer, backlog och Admiral. Flytta fler källor först efter pilotacceptans; bevara gamla loggvägar till överenskommen acceptans. En collector ersätter varken SIEM-rättighet och retentionsinventering eller en produktspecifik API-integration.

Om collectorkonfigurationen senare ändras i Sophos Fusion sparas de nya installationsfilerna och även molndriftsättningen uppdateras: AWS CloudFormation-stack med aktuell mall, Azure-driftsättning med aktuell ARM-mall, GCP-driftsättning med ny Terraform-konfiguration. Annars kan ett framtida instansbyte återanvända gamla bootstrap-värden. Enbart en lyckad onlineändring bevisar inte denna beständighet.

Vid återställning pekas källorna först tillbaka till den bevarade tidigare vägen och färska händelser verifieras där. Ta därefter bort bara tydligt identifierade collectorresurser enligt molnets ändringsprocess. Gemensamma VPC/VNet, subnät, nycklar eller Service Accounts får inte raderas som generell ”collectorstädning”. Infrastrukturåterställning återför inte automatiskt historiska händelser som redan gått förlorade eller normaliserats fel.