Déployer Sophos Server Protection sur AWS EC2 et les VM Azure

Une instance EC2 ou une VM Azure est protégée dans son système d’exploitation invité par Sophos Server Protection. Sur Windows Server, utilisez le programme d’installation Windows Server ; sur les serveurs Linux pris en charge, utilisez Sophos Protection for Linux (SPL). L’emplacement de la VM ne change pas le choix de l’agent serveur. Sophos Firewall déployé comme appliance virtuelle sur AWS ou Azure protège et achemine le trafic réseau ; il ne remplace pas l’agent installé dans le système invité. Sophos Cloud Optix est un produit distinct de gestion de la posture et de l’inventaire cloud, qui n’est pas nécessaire à l’installation de l’agent serveur : selon l’annonce de fin de vie de Sophos, le support et l’accès prendront fin le 30 septembre 2026. Il ne faut donc pas s’appuyer sur ce produit pour établir un nouveau processus, ou un processus pérenne, d’inventaire et de nettoyage des ressources cloud. Vérifiez séparément que Server Protection et les fonctionnalités requises sont disponibles dans votre tenant et couverts par votre contrat.

En bref : choisissez une VM représentative, validez son système d’exploitation et son mode de protection, testez sa connexion à Sophos Fusion depuis son réseau cloud réel, puis installez le programme d’installation serveur propre au tenant. Contrôlez ensuite My Products > Server > Servers et les détails du serveur. Ne lancez la vague suivante qu’après avoir vérifié l’enregistrement, le groupe, les stratégies, l’état de l’agent et le bon fonctionnement de l’application. Pour les instances éphémères, prévoyez également un rapprochement distinct avec l’inventaire cloud.

Avant le pilote : définir la protection et le chemin réseau

1. VM et contrat : recensez le compte AWS ou l’abonnement Azure, la région, le rôle de la VM, la version de Windows ou la distribution Linux, l’architecture et le cycle de vie. Vérifiez la prise en charge actuelle de ce système d’exploitation invité précis et des composants nécessaires. Confirmez la licence de votre tenant, la référence de l’offre serveur souscrite et les conditions contractuelles applicables à ces VM ; la présence d’un bouton de téléchargement ne prouve pas que vous disposez des droits d’utilisation.
2. Mode de protection : choisissez entre la protection complète contre les malwares de Sophos et XDR Sensor. XDR Sensor seul ne protège pas contre les malwares et nécessite une protection tierce active. Avant tout changement de mode, identifiez les conflits possibles avec les logiciels de sécurité déjà installés et prévoyez une procédure de retour arrière pour la VM concernée.
3. Connexion sortante : depuis le sous-réseau prévu, vérifiez que le DNS, HTTPS, les destinations Sophos nécessaires au tenant et, le cas échéant, le proxy ou le Message Relay sont accessibles pendant l’installation et l’exploitation. Les Security Groups, Network Security Groups, routes cloud, passerelles NAT, pare-feu et dispositifs d’inspection TLS peuvent modifier ce chemin. La liste actuelle des destinations autorisées et les procédures de diagnostic du proxy figurent dans les exigences réseau et proxy. Ne considérez pas une liste figée d’adresses IP cloud comme un substitut aux destinations Sophos.
4. Pilote et critères d’acceptation : choisissez un petit groupe de VM représentatif des rôles serveur, des versions du système d’exploitation, des segments réseau et, si nécessaire, des chemins passant par un proxy. Notez les noms, le groupe de serveurs attendu, les stratégies visées, la fenêtre de redémarrage, le test de la charge applicative et les critères d’arrêt. Si plusieurs sous-réseaux ou images sont utilisés, prévoyez au moins un test adapté à chaque chemin différent.

Exemple : une VM applicative Windows et une VM de traitement Linux situées dans deux sous-réseaux privés distincts constituent deux cas pilotes, pas un seul test réseau. Le succès de l’installation sur la première VM ne prouve pas que la seconde peut atteindre sa destination de mise à jour via sa passerelle NAT ou son proxy.

Installer l’agent dans le système invité et préparer correctement les images

Dans My Environment > Installers > Server Protection, sélectionnez le Windows Server Installer ou le Linux Server Installer correspondant au mode de protection validé, depuis le bon tenant Sophos Fusion. Sur une VM Windows individuelle, transférez SophosSetup.exe de manière sécurisée, lancez-le avec les droits d’administrateur local, tenez compte des vérifications préalables affichées et terminez l’installation, y compris le redémarrage demandé. Sur une VM Linux, transférez SophosSetup.sh de manière sécurisée, rendez-le exécutable et lancez d’abord sudo ./SophosSetup.sh --test, puis, si le test réussit, sudo ./SophosSetup.sh. Vérifiez ensuite l’enregistrement dans le tenant et l’état de l’agent local ; la seule fin d’exécution du programme d’installation ne suffit pas. Le mode de protection, les options avancées de la CLI, les journaux et le dépannage sont décrits dans Installer et déployer Windows Server Protection et Installer et déployer SPL. Stockez le programme d’installation propre au tenant et son adresse de téléchargement uniquement dans un dépôt de paquets protégé, jamais dans une image de VM ou un dépôt de code public.

Ne clonez pas telle quelle une VM maître déjà enregistrée. Pour intégrer SPL dans une image de référence Linux, désenregistrez la VM maître après l’installation avec registerCentral --deregister, conformément à la procédure de création d’une image de référence Linux. Arrêtez-la immédiatement, puis créez l’image alors qu’elle est éteinte. Si vous redémarrez entre-temps la VM maître, elle risque de s’enregistrer à nouveau ; désenregistrez-la encore une fois avant de créer l’image. Démarrez deux clones et vérifiez qu’ils possèdent des identités distinctes.

Le processus de création d’une image Windows Server est différent : avant de préparer l’image, vérifiez si Tamper Protection est désactivé pour cette configuration et si Server Lockdown ou Update Cache sont actifs ; ne créez pas d’image de référence à partir d’un serveur sur lequel ces derniers sont actifs. Les VM maîtres chiffrées avec BitLocker ou dotées de composants Sophos Encryption sont également exclues. Avec le programme d’installation Windows Server propre au tenant, exécutez SophosSetup.exe --goldimage en tant qu’administrateur conformément à la procédure de création d’une image de référence Windows (également valable pour les serveurs). Vérifiez l’installation et l’état de l’agent, réactivez Tamper Protection, puis arrêtez la VM maître avant de prendre le cliché de l’image. Au premier démarrage, chaque clone doit recevoir son nom d’ordinateur définitif, différent de celui de la VM maître, suffisamment tôt pour que Sophos le détecte : Sophos reconnaît les clones au changement de nom, et non à l’ID de l’instance cloud. Si l’attribution du nom est retardée, consultez le mode Timeout décrit dans le guide ; le mode Notification y concerne VMware Horizon Instant Clone et ne doit pas être appliqué systématiquement à EC2 ou Azure. Ne supposez pas qu’une installation Windows ordinaire est prête à être clonée. Ici aussi, validez séparément deux clones dans Fusion.

Vérifier la vague cloud et arrêter le déploiement en cas de problème

Après l’installation ou le démarrage d’un clone pilote, ouvrez chaque serveur attendu sous My Products > Server > Servers. Deux clones exécutés simultanément doivent apparaître comme deux objets serveur distincts. Pour la validation, conservez une table de correspondance externe associant compte AWS ou abonnement Azure, région, ID d’instance EC2 ou ID de ressource de VM Azure, ID de serveur Fusion, propriétaire et date de création ; la liste des serveurs n’affiche pas automatiquement les ID cloud. Dans les détails, vérifiez Summary, Status et Policies, ainsi que la dernière activité, l’état de l’agent, les composants installés et les stratégies serveur effectivement appliquées. La première Default Policy attribuée automatiquement n’est pas nécessairement la stratégie prévue pour la production. Comparez ensuite le fonctionnement des services, l’accès à l’application, les sauvegardes et un test représentatif de la charge applicative avant et après tout redémarrage nécessaire.

Si une VM n’apparaît pas dans Fusion, vérifiez d’abord le tenant et les filtres, puis le DNS, le proxy, le chemin réseau sortant et les journaux d’installation en suivant le guide Windows ou Linux adapté. Si les clones ne sont pas distinguables, interrompez le déploiement des images et revérifiez l’étape de gestion des identités de la procédure d’image de référence. En cas de composants incorrects, de mauvais état de l’agent ou de perturbation de la charge applicative, n’autorisez pas de nouvelle vague ; isolez et analysez la vague concernée au lieu de réappliquer à l’aveugle le programme d’installation et les stratégies.

Traiter séparément les instances supprimées et les appareils inactifs

Les VM éphémères peuvent avoir été supprimées alors que leur entrée reste visible dans Sophos Fusion. Une ancienne valeur Last Active ne prouve ni qu’une instance cloud a été supprimée ni qu’il existe un délai universel de nettoyage automatique. Rapprochez régulièrement la table de correspondance externe entre compte ou abonnement, région, ID d’instance ou de ressource cloud et ID de serveur Fusion de l’inventaire AWS ou Azure et de l’inventaire des appareils Fusion. Conservez le propriétaire, les dates importantes du cycle de vie et la preuve de l’événement EC2 Terminate ou Azure VM Delete. Un nom d’hôte réutilisé ou une VM Azure arrêtée ne prouve pas que l’objet serveur associé est hors service.

Le rapprochement manuel suivi d’un Delete ciblé reste la méthode de base : ne supprimez l’objet qu’après avoir obtenu la preuve de la suppression de la ressource cloud et établi une correspondance sans ambiguïté entre les ID. Sauvegardez d’abord les alertes et données d’investigation nécessaires, recherchez d’éventuels doublons et documentez le retrait ou la protection de remplacement. Dans Fusion, Delete ne remplace ni la désinstallation de l’agent sur une VM encore en service ni la gestion du cycle de vie dans le cloud.

Par ailleurs, Sophos décrit dans Removal of inactive devices une règle Server configurable pour les appareils inactifs : elle peut cibler des groupes ou s’appliquer globalement avec des exceptions par groupe (ces exceptions ne s’appliquent pas aux règles ciblées). Elle repose sur l’inactivité, pas sur la confirmation d’un événement EC2 Terminate ou Azure Delete, et ne désinstalle aucun agent. Avant de l’activer dans votre tenant, testez sur un ensemble d’appareils la sélection des groupes, le délai, les exceptions, la conservation des données et les conséquences pour les VM de production arrêtées ou temporairement injoignables ; ne présumez ni d’un délai universel ni d’un effet sur les licences. L’ancienne intégration Cloud Optix offrait, pour les environnements AWS ou Azure existants liés au même tenant et équipés de l’agent serveur, un nettoyage distinct lors de la suppression des instances. Désactivé par défaut, il ne pouvait être activé que par un Super Admin et ne s’appliquait pas rétroactivement aux instances déjà supprimées. La fin du support et de l’accès le 30 septembre 2026 en fait un simple élément de contexte historique, et non une recommandation pour une nouvelle mise en place ou une automatisation pérenne. Aucun fonctionnement non confirmé n’est promis pour les hooks de suppression liés à l’autoscaling, l’automatisation par API ou le décompte des licences.