Déployer les Sophos XDR Data Collectors sur AWS, Azure et GCP

Un Sophos XDR Data Collector reçoit des événements syslog et les transmet chiffrés à XDR. Le déploiement cloud commence dans Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Un template AWS, Azure ou GCP, associé à la configuration précise du collector, est ensuite généré et déployé dans son propre compte cloud.

Ces trois chemins n’utilisent pas des images VM interchangeables. AWS emploie une AMI avec CloudFormation et EC2 User Data, Azure une VHD avec ARM et Custom Data, GCP une configuration Terraform pour Infrastructure Manager. Ce guide couvre le cloud ; migration SVA et déploiement local restent distincts.

Clarifier réseau, responsabilités et coûts avant déploiement

Il faut le bon tenant Sophos, un compte ou projet cloud autorisé et les permissions du template choisi. Instances, disques, load balancers et autres ressources peuvent générer des frais cloud. Examiner template, réseau cible, règles, responsables et périmètre de retrait avant déploiement. Protéger les configurations générées et les credentials qu’elles contiennent.

Pour chaque source, consigner événements, format attendu et destination. Les entrées syslog standard sont UDP/514 et TCP/601. Restreindre les règles aux réseaux sources nécessaires plutôt qu’à Internet entier. Le collector nécessite en sortie TCP/443 vers son uplink XDR régional attribué, DNS sur UDP/TCP 53 et synchronisation initiale sur UDP 123. Le guide de migration explique les destinations régionales ; les comparer à la safelist actuelle avant changement.

Sans NTP personnalisé, les collectors hors AWS utilisent les serveurs pool documentés ; AWS utilise 169.254.169.123. Une fois connecté, le canal backend synchronise l’heure ; Admiral peut afficher ntp.collector. Host Proxy est facultatif. L’aide générale exclut les proxies authentifiés codés en dur, alors que certaines pages d’installation montrent une syntaxe utilisateur/mot de passe. Clarifier d’abord avec Sophos une telle configuration en production ; placer des credentials dans le template ne résout pas ce conflit.

Création commune dans Sophos Fusion

Ouvrir Security Operations > Integrations > Data Collectors > Actions > Add Collector.
Choisir Cloud-Hosted, puis Next.
Renseigner des Name et Hostname uniques, éventuellement description, Host Proxy et serveurs NTP. Vérifier tenant, réseau et valeurs avant Create Collector.
Choisir Create Collector, puis le Cloud Service Provider adapté. Les données et fichiers suivants appartiennent seulement à ce collector et ne doivent pas être réutilisés pour plusieurs instances indépendantes.

AWS : CloudFormation, un collector et un NLB

Il faut le bon AWS Account ID à 12 chiffres, une région proposée par Sophos et un VPC existant adapté avec subnets. Le template crée une Launch Template avec AMI/User Data, un Auto Scaling Group statiquement dimensionné à une instance, un Network Load Balancer et des règles syslog.

Le NLB fonctionne en Layer 4 et prend en charge TCP et UDP. Son DNS stable reste utilisable comme destination des sources lors du remplacement de l’instance. Un Application Load Balancer ou ELB classique ne remplace pas cette architecture documentée. Le collector AWS ne prend pas en charge la HA dans cette configuration ; garder l’Auto Scaling Group à 1. Deux instances simultanées avec User Data identique ne sont pas supportées.

Déployer la configuration AWS

Dans Sophos, choisir Amazon Web Services (AWS), saisir Account ID et sélectionner une région AWS supportée.
Si nécessaire, enregistrer et examiner le YAML via Download. Launch Console ouvre Create stack de CloudFormation avec le template généré.
Associer CollectorName, VpcId et Subnets à l’environnement voulu. Vérifier VpcCidr et SyslogIngress supplémentaire face aux réseaux réellement autorisés. 0.0.0.0/0 est une plage source IPv4 sans restriction, à ne pas reprendre comme défaut.
Contrôler InstanceType. Le template Sophos utilise c5.xlarge, 4 vCPU et 8 Go de RAM. Dans un template personnalisé, le disque supplémentaire doit garder au moins 200 Go et son association /dev/sdb.
En cas de chiffrement EBS, faire vérifier KmsCmkArn et la stratégie de clé par le responsable AWS. Une mauvaise stratégie peut provoquer des lancements échoués répétés.
Examiner les options avec Next. N’exécuter Create stack qu’après approbation des ressources et règles précises.
Après succès, conserver CTPxCollectorDnsName dans les Outputs du stack. Ce DNS du NLB est la destination syslog, pas une IP EC2 temporaire.

Contrôler l’état dans Sophos Fusion. AWS attribue les adresses dynamiquement : une colonne Address vide n’est pas forcément une erreur. Examiner les boucles de lancement via les événements AWS ; avec Client.InternalError: Client error on launch et EBS chiffré, vérifier notamment la stratégie KMS. Ne pas démarrer d’autres instances identiques en parallèle.

Azure : template ARM récent et permissions délimitées

Une souscription Azure et un Virtual Network adapté avec subnet sont nécessaires. Le template Sophos exige Owner ou Contributor + User Access Administrator. Limiter ces droits au périmètre et à l’opération approuvés, sans les donner durablement à tous les exploitants.

Le template copie la VHD dans un Storage Account à conteneur privé, crée une Managed Image et une unique VM collector avec Network Security Group. Ce stockage est réservé à cette tâche. La SAS URL de la VHD n’est valable que trois heures après génération du template ARM. Ne pas simplement réessayer un vieux template inchangé.

Les templates téléchargés depuis le 3 août 2026 utilisent un Azure Deployment Script temporaire hors du Virtual Network pour copier la VHD. Aucune bootstrap VM, bootstrap NSG ou exception de sortie bootstrap supplémentaire n’est nécessaire dans le VNet. Les anciens templates utilisaient une VM temporaire et un conteneur de nettoyage ; ne pas transférer préventivement leurs exceptions à un nouveau déploiement. Utiliser un template récent.

Déployer la configuration Azure

Choisir Microsoft Azure dans Sophos. Utiliser Download ARM Template si besoin ; Deploy in Azure ouvre Custom deployment préparé.
Choisir Subscription et le bon Resource group. Un groupe dédié facilite identification et retrait, sans justifier d’y déplacer des ressources réseau partagées.
Choisir une région adaptée au VNet. Définir Vm Name et Vm Size ; Sophos recommande Standard_D4s_v3 dans le guide actuel.
Associer exactement groupe du VNet, Azure Virtual Network et Azure Virtual Network Subnet. Saisir une Static Private IP libre et adaptée ou laisser vide pour affectation automatique.
Garder Utc Now et Random Seed aux valeurs générées. Elles servent aux noms uniques et au mot de passe temporaire pendant le déploiement.
Examiner les NSG : entrées documentées UDP/514 et TCP/601 depuis le VNet, sorties XDR, DNS et NTP nécessaires. Intégrer les autres exigences internes au template.
Examiner les conditions Marketplace et démarrer Purchase seulement après approbation des ressources. Comparer résultat Azure et état dans Sophos Fusion.

En cas d’adaptation, garder le disque supplémentaire d’au moins 200 Go sur /dev/sdc. Azure ne supporte pas non plus la HA dans ce modèle ; un éventuel VM Scale Set personnalisé ne peut exécuter qu’une instance avec cette Custom Data. Une VM fonctionnelle n’active pas seule une intégration d’audit Microsoft 365 ; configurer et vérifier cette source séparément.

GCP : Infrastructure Manager et Service Account dédié

GCP nécessite projet autorisé, Infrastructure Manager API activée, Cloud Shell ou gcloud CLI déjà disponible, et user-managed Service Account. Le compte Google-managed <numeric ID>@cloudservices.gserviceaccount.com n’est pas adapté selon Sophos.

L’administrateur du déploiement crée le compte, par exemple infra-manager-sa, avec roles/compute.instanceAdmin.v1, roles/compute.securityAdmin et roles/config.agent dans le projet cible. Ils permettent création d’instances/disques, gestion des règles et travail d’Infrastructure Manager. L’autorisation de ces droits d’écriture est une préparation séparée ; une revue en lecture seule ne les exige pas.

Générer et appliquer la configuration GCP

Choisir Google Cloud Platform (GCP) et renseigner GCP Project ID.
Dans Service Agent ID, associer le user-managed Service Account prévu. Malgré l’intitulé, ne pas utiliser le Google-managed Service Agent.
Vérifier GCP Region, GCP Zone, Network Name, Subnet Name et Network CIDR. Le CIDR doit correspondre aux règles prévues, sans ouverture Internet générale.
Enregistrer l’archive Terraform avec Download. Ouvrir Cloud Shell dans le bon projet, charger le ZIP précis et l’extraire dans un répertoire dédié. Le fichier choisi doit appartenir au collector nouvellement généré.

unzip collector-*.zip -d collector-infrastructure

L’exemple fabricant utilise un joker. Le répertoire doit donc contenir exactement l’archive voulue ; s’il y a plusieurs correspondances, utiliser le nom exact. Examiner ressources, réseaux, règles et identité dans Terraform avant application. La configuration crée une instance Compute avec interface et un disque de données d’au moins 200 Go sur /dev/sdb.

Sophos documente la commande suivante :

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"

Remplacer partout PROJECT_ID par le projet autorisé et LOCATION par une localisation Infrastructure Manager supportée. Le nom du Service Account doit correspondre au compte créé. taegis-collector identifie la ressource de déploiement et ne doit pas écraser involontairement une autre existante. apply crée ou modifie des ressources cloud réelles ; l’exécuter seulement après examen et approbation.

Sophos indique gcloud infra-manager previews create comme prévisualisation préalable. Elle aussi s’exécute dans le bon projet avec un compte autorisé, sans remplacer la lecture des changements proposés. Après Apply réussi, vérifier état et sources. Selon le guide, Provisioning doit se terminer sous dix minutes ; sinon rechercher les erreurs de déploiement et connexion plutôt que recréer sans contrôle le même déploiement.

Shared VPC : séparer projets réseau et service

Par défaut, le template attend réseau et instance dans le même projet. En Shared VPC, le Host Project possède VPC, subnets et règles ; le Service Project contient instance collector et disque. Les deux doivent préexister.

L’administrateur d’organisation active Shared VPC sur le projet hôte et associe le projet de service. roles/compute.xpnAdmin est requis au niveau organisation, pas une simple fonction projet. Le infra-manager-sa du projet de service reçoit ensuite sur le projet hôte roles/compute.securityAdmin pour les règles et roles/compute.networkUser pour l’usage réseau.

Dans Sophos, remplir Network Project ID avec le projet hôte ; laisser les autres champs sur le projet de service. PROJECT_ID dans la cible Apply et l’adresse du Service Account reste aussi l’ID du projet de service. Relire séparément ces affectations avant approbation : remplacer tous les paramètres par le projet hôte annulerait la séparation prévue.

Valider les sources et conserver une configuration persistante

Après déploiement cloud, le collector doit être joignable dans Sophos Fusion. Faire ensuite envoyer une source pilote limitée au bon format syslog vers la destination correcte. Comparer source, heure, type et champs attendus dans la recherche XDR. Un collector sain ou un stack réussi ne prouve pas ingestion et normalisation complètes.

Le guide d’exploitation explique vues sources, backlog et Admiral. Ne basculer d’autres sources qu’après acceptation du pilote ; préserver les anciennes voies jusqu’à l’acceptation convenue. Un collector ne remplace ni droits SIEM et inventaire de rétention, ni une intégration API spécifique.

Après modification ultérieure dans Sophos Fusion, conserver les nouveaux fichiers et actualiser aussi le déploiement cloud : stack AWS CloudFormation avec template actuel, Azure avec ARM actuel, GCP avec nouvelle configuration Terraform. Sinon, un remplacement d’instance peut réintroduire d’anciens paramètres bootstrap. Un changement en ligne réussi ne prouve pas cette persistance.

Pour retirer l’installation, remettre d’abord les sources sur la voie antérieure conservée et y vérifier des événements récents. Supprimer ensuite seulement les ressources clairement attribuées au collector, selon le processus cloud. Ne pas supprimer VPC/VNet, subnets, clés ou Service Accounts partagés comme « nettoyage collector » général. Le retour arrière d’infrastructure ne restaure pas automatiquement les événements historiques perdus ou mal normalisés.