Vai al contenuto
Avanet
Accedi

Implementare Sophos XDR Data Collectors in AWS, Azure e GCP

Sophos Fusion Admin

Un Sophos XDR Data Collector riceve eventi syslog e li inoltra cifrati a XDR. Il deployment cloud inizia in Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Si genera poi un template AWS, Azure o GCP, associato alla specifica configurazione, da distribuire nel proprio account cloud.

I tre percorsi non usano immagini VM intercambiabili. AWS utilizza AMI con CloudFormation ed EC2 User Data, Azure VHD con ARM e Custom Data, GCP Terraform per Infrastructure Manager. La guida descrive il cloud; migrazione SVA e deployment locale restano separati.

Chiarire rete, responsabilità e costi prima del deployment

Servono tenant Sophos corretto, account o progetto cloud autorizzato e permessi per il template scelto. Istanze, dischi, load balancer e altre risorse possono generare costi. Prima del deployment esaminare template, rete, regole, responsabili e ambito di rimozione. Proteggere configurazioni generate ed eventuali credentials incluse.

Per ogni sorgente annotare eventi, formato previsto e destinazione. Gli ingressi syslog standard sono UDP/514 e TCP/601. Limitare le regole alle reti sorgente necessarie senza aprire a tutta Internet. Servono TCP/443 in uscita all’uplink XDR regionale assegnato, DNS tramite UDP/TCP 53 e sincronizzazione bootstrap tramite UDP 123. Il runbook di migrazione spiega le destinazioni regionali; confrontarle con la safelist attuale prima del change.

Senza NTP personalizzato, i collector non AWS usano i pool documentati, AWS 169.254.169.123. Dopo la connessione sincronizza il canale backend; Admiral può mostrare ntp.collector. Host Proxy è facoltativo. La guida generale esclude proxy autenticati configurati rigidamente, benché alcune pagine mostrino sintassi utente/password. Chiarire prima con Sophos un proxy autenticato in produzione; le credentials nel template non risolvono la contraddizione.

Creazione comune in Sophos Fusion

  1. Aprire Security Operations > Integrations > Data Collectors > Actions > Add Collector.
  2. Scegliere Cloud-Hosted e Next.
  3. Inserire Name e Hostname unici, eventualmente descrizione, Host Proxy e NTP propri. Verificare tenant, rete e valori prima di Create Collector.
  4. Scegliere Create Collector, poi il Cloud Service Provider. Dati e file successivi appartengono solo a questo collector e non vanno riutilizzati per più istanze indipendenti.

AWS: CloudFormation, un collector e un NLB

Servono il corretto AWS Account ID a 12 cifre, una regione supportata nel dialogo Sophos e VPC esistente con subnet adeguate. Il template crea Launch Template con AMI/User Data, Auto Scaling Group staticamente dimensionato a un’istanza, Network Load Balancer e regole syslog.

NLB opera a Layer 4 e supporta TCP e UDP. Il DNS stabile resta utilizzabile dalle sorgenti anche sostituendo l’istanza. Un Application Load Balancer o ELB classico non sostituisce questo disegno documentato. Il collector AWS non supporta HA in questa configurazione; mantenere Auto Scaling Group a 1. Due istanze simultanee con User Data identica non sono supportate.

Distribuire la configurazione AWS

  1. In Sophos scegliere Amazon Web Services (AWS), inserire Account ID e selezionare regione AWS supportata.
  2. Se necessario salvare ed esaminare YAML con Download. Launch Console apre Create stack CloudFormation con il template.
  3. Associare CollectorName, VpcId e Subnets all’ambiente previsto. Controllare VpcCidr e SyslogIngress aggiuntivo rispetto alle reti realmente autorizzate. 0.0.0.0/0 è un intervallo sorgente IPv4 senza restrizioni, da non adottare come predefinito.
  4. Controllare InstanceType. Il template Sophos usa c5.xlarge, 4 vCPU e 8 GB RAM. In un template proprio il disco aggiuntivo deve restare almeno 200 GB e associato a /dev/sdb.
  5. Se è prevista cifratura EBS, far verificare KmsCmkArn e key policy al responsabile AWS. Una policy errata può causare ripetuti lanci falliti.
  6. Esaminare opzioni con Next. Avviare Create stack solo dopo approvazione di risorse e regole specifiche.
  7. Dopo il successo conservare CTPxCollectorDnsName negli Outputs dello stack. Questo DNS NLB è la destinazione syslog, non un IP EC2 temporaneo.

Controllare stato in Sophos Fusion. AWS assegna indirizzi dinamici: la colonna Address vuota non significa necessariamente errore. Analizzare cicli di lancio nell’Auto Scaling Group tramite eventi AWS; con Client.InternalError: Client error on launch ed EBS Encryption attivo, verificare soprattutto la policy KMS. Non avviare altre istanze identiche in parallelo.

Azure: ARM recente e permessi circoscritti

Servono sottoscrizione Azure e Virtual Network con subnet adatto. Il template Sophos richiede Owner oppure Contributor + User Access Administrator. Limitare questi diritti all’ambito e all’operazione autorizzata, senza darli permanentemente a tutti gli operatori.

Il template copia VHD in uno Storage Account con container privato, crea Managed Image e una singola VM collector con Network Security Group. Lo Storage Account è dedicato a questo compito. La SAS URL della VHD vale solo tre ore dalla generazione ARM. Non riprovare semplicemente un vecchio template invariato.

I template scaricati dal 3 agosto 2026 usano un Azure Deployment Script temporaneo esterno al Virtual Network per copiare la VHD. Non servono bootstrap VM, bootstrap NSG o ulteriori eccezioni bootstrap in uscita nel VNet. I vecchi template usavano VM temporanea e container di pulizia: non trasferirne preventivamente le eccezioni a un nuovo deployment. Per un rollout nuovo usare un template appena generato.

Distribuire la configurazione Azure

  1. Scegliere Microsoft Azure in Sophos. Usare Download ARM Template se necessario; Deploy in Azure apre Custom deployment predisposto.
  2. Scegliere Subscription e corretto Resource group. Un gruppo dedicato facilita identificazione e rimozione, senza giustificare lo spostamento di reti condivise.
  3. Selezionare regione adatta al VNet. Impostare Vm Name e Vm Size; Sophos raccomanda Standard_D4s_v3 nella guida attuale.
  4. Associare esattamente gruppo del VNet, Azure Virtual Network e Azure Virtual Network Subnet. Inserire una Static Private IP libera e adatta o lasciare vuoto per assegnazione automatica.
  5. Lasciare Utc Now e Random Seed ai valori generati, destinati rispettivamente a nomi unici e password temporanea di deployment.
  6. Esaminare NSG: ingressi documentati UDP/514 e TCP/601 dal VNet, uscite XDR, DNS e NTP richieste. Considerare altre regole interne nel template.
  7. Leggere condizioni Marketplace e avviare Purchase solo dopo approvazione delle risorse. Confrontare risultato Azure e stato Sophos Fusion.

Nel template personalizzato il disco aggiuntivo resta almeno 200 GB su /dev/sdc. Anche Azure non supporta HA in questo modello; un eventuale VM Scale Set proprio può eseguire una sola istanza con la stessa Custom Data. Una VM funzionante non attiva da sola un’integrazione audit Microsoft 365; configurare e verificare separatamente quella sorgente.

GCP: Infrastructure Manager e Service Account dedicato

GCP richiede progetto autorizzato, Infrastructure Manager API attiva, Cloud Shell o gcloud CLI già disponibile e user-managed Service Account. L’account gestito da Google <numeric ID>@cloudservices.gserviceaccount.com non è adatto secondo Sophos.

L’amministratore di deployment crea l’account, ad esempio infra-manager-sa, con roles/compute.instanceAdmin.v1, roles/compute.securityAdmin e roles/config.agent nel progetto. Consentono creazione istanze/dischi, regole firewall e operazioni Infrastructure Manager. L’approvazione di questi diritti di scrittura è una preparazione separata; una revisione in lettura del collector non li richiede.

Generare e applicare la configurazione GCP

  1. Scegliere Google Cloud Platform (GCP) e inserire GCP Project ID.
  2. In Service Agent ID associare il user-managed Service Account previsto. Non usare Google-managed Service Agent nonostante il nome del campo.
  3. Verificare GCP Region, GCP Zone, Network Name, Subnet Name e Network CIDR. Il CIDR deve corrispondere alle regole volute, senza apertura generale a Internet.
  4. Salvare l’archivio Terraform con Download. Aprire Cloud Shell nel progetto corretto, caricare il preciso ZIP ed estrarlo in una directory dedicata. Il nome scelto deve appartenere al collector appena generato.
unzip collector-*.zip -d collector-infrastructure

L’esempio del fornitore usa un carattere jolly. La directory deve quindi contenere esattamente l’archivio previsto; se corrispondono più file, usare il nome esatto. Verificare risorse, reti, regole e identità nei file Terraform prima di applicare. La configurazione crea istanza Compute con interfaccia e disco dati almeno 200 GB su /dev/sdb.

Sophos documenta il seguente comando:

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"

Sostituire ovunque PROJECT_ID con il progetto autorizzato e LOCATION con una località supportata da Infrastructure Manager. Il Service Account deve corrispondere a quello effettivamente creato. taegis-collector nomina la risorsa deployment e non deve sovrascriverne involontariamente un’altra. apply crea o modifica risorse cloud reali: eseguire solo dopo controllo e approvazione.

Sophos indica gcloud infra-manager previews create come anteprima preliminare. Anche questa va eseguita nel progetto corretto con account autorizzato e non sostituisce l’esame delle modifiche. Dopo Apply riuscito verificare stato e sorgenti. Secondo la guida Provisioning dovrebbe terminare entro dieci minuti; altrimenti indagare deployment e connettività, senza ricreare ripetutamente lo stesso deployment senza controllo.

Shared VPC: separare progetto di rete e di servizio

Il template standard presume rete e istanza nello stesso progetto. Con Shared VPC, Host Project possiede VPC, subnet e regole; Service Project contiene istanza collector e disco. Entrambi devono già esistere.

L’amministratore dell’organizzazione abilita Shared VPC nel progetto host e associa il progetto di servizio. Serve roles/compute.xpnAdmin a livello organizzazione, non un normale ruolo di progetto. Assegnare poi a infra-manager-sa del progetto di servizio, nel progetto host, roles/compute.securityAdmin per le regole e roles/compute.networkUser per la rete.

Nel wizard Sophos compilare Network Project ID con l’ID host; lasciare gli altri riferimenti sul progetto di servizio. Anche PROJECT_ID nel target Apply e nell’indirizzo Service Account resta l’ID del progetto di servizio. Rileggere separatamente queste assegnazioni prima di approvare: cambiare tutti i segnaposto all’host annullerebbe la separazione prevista.

Collaudare le sorgenti e mantenere configurazione persistente

Dopo il deployment cloud, il collector deve essere raggiungibile in Sophos Fusion. Far poi inviare una sorgente pilota limitata nel corretto formato syslog alla destinazione prevista. Confrontare sorgente, ora, tipo e campi attesi nella ricerca XDR. Un collector sano o stack riuscito non dimostra acquisizione e normalizzazione complete.

Il runbook operativo spiega viste sorgenti, backlog e Admiral. Spostare altre sorgenti solo dopo collaudo del pilota; preservare i vecchi percorsi fino all’accettazione concordata. Un collector non sostituisce né diritti SIEM e inventario retention, né un’integrazione API specifica.

Se la configurazione cambia successivamente in Sophos Fusion, conservare nuovi file e aggiornare anche il deployment cloud: stack AWS CloudFormation con template corrente, Azure con ARM corrente, GCP con nuova configurazione Terraform. Altrimenti un futuro cambio istanza può ripristinare vecchi valori bootstrap. Una modifica online riuscita non dimostra tale persistenza.

Per il rollback riportare prima le sorgenti sul percorso precedente conservato e verificarvi eventi recenti. Rimuovere poi solo risorse chiaramente attribuite al collector con la procedura cloud. Non eliminare VPC/VNet, subnet, chiavi o Service Account condivisi come generica “pulizia collector”. Il rollback infrastrutturale non recupera automaticamente eventi storici persi o normalizzati male.