Connecter Sophos Firewall à Sophos Fusion

Il n’est pas obligatoire de connecter un Sophos Firewall à Sophos Fusion (anciennement Sophos Central). Un pare-feu unique peut être entièrement géré localement via le WebAdmin. Cependant, la connexion à Sophos Fusion est souvent avantageuse dans de nombreux environnements, car elle offre des fonctionnalités supplémentaires de gestion, de sauvegarde, de reporting et de sécurité.

Cet article aide à décider quand Sophos Fusion est pertinent et quand une gestion locale suffit.

Le nom actuel de la plateforme est Sophos Fusion, anciennement Sophos Central. Les menus du pare-feu, les boutons et l’alerte d’enregistrement peuvent encore utiliser Sophos Central ; suivez les libellés affichés dans l’interface lors de la procédure. Un pare-feu géré de manière centralisée peut également être intégré comme passerelle ZTNA pour accéder aux ressources internes. L’enregistrement seul ne configure pas cette passerelle et n’accorde aucun accès à ces ressources ; planifiez séparément le déploiement ZTNA et sa politique d’accès.

Réponse courte

Si vous exploitez uniquement un Sophos Firewall localement et ne souhaitez pas utiliser les fonctionnalités Central, Sophos Fusion n’est pas nécessaire.

Si vous gérez plusieurs pare-feux, souhaitez analyser les journaux de manière centralisée, stocker des sauvegardes de configuration dans le cloud ou utilisez d’autres produits Sophos comme Sophos Endpoint, Sophos Fusion offre des avantages significatifs.

La décision ne devrait pas se limiter à connecter ou non le pare-feu. Il est plus important de déterminer quelles fonctionnalités Central doivent réellement être activées. Un pare-feu peut être enregistré dans Sophos Fusion sans que toutes les fonctions de gestion, de reporting ou de sauvegarde soient utilisées en production.

Zero Touch : déploiement à l’aide d’un fichier de configuration

Outre la gestion des pare-feux existants, Sophos Fusion propose également Zero Touch : de nouveaux pare-feux peuvent être installés à l’aide d’un fichier de configuration Zero Touch. Un compte Sophos Fusion est nécessaire ; l’interface peut encore porter le nom Sophos Central. Cette possibilité est pertinente pour planifier de nouvelles installations sur site lorsque le déploiement doit être préparé via Central. Elle ne doit pas être confondue avec l’accès distant ultérieur à WebAdmin ni avec la distribution d’une politique de groupe.

Avant de choisir le mode de déploiement, précisez le tenant prévu, les administrateurs responsables et leurs autorisations, l’appareil et son numéro de série, les besoins en licences ainsi que la connexion Internet. Pour la gestion Central ultérieure, une connexion IPv4 fonctionnelle reste nécessaire ; les exigences de licence décrites dans cet article continuent de s’appliquer. Zero Touch n’est ni une condition préalable à l’exploitation locale ni une méthode de réparation pour un pare-feu déjà en production.

Distinguez clairement les tâches :

• Nouvelle installation avec Zero Touch : le fichier de configuration sert au déploiement d’un nouveau pare-feu. Cette présentation décrit cette fonctionnalité, mais ne fournit pas de procédure complète pour créer ou appliquer le fichier. Planifiez ce mode de déploiement avant l’installation ; ne déduisez pas une procédure Zero Touch des étapes OTP qui suivent.
• Configuration locale, claim et licences : Configurer Sophos Firewall, effectuer le claim et activer les licences décrit la configuration locale de base, l’affectation au tenant par le claim, ainsi que l’activation ou la synchronisation des licences, qui constituent des opérations distinctes. Ces tâches ne doivent pas être assimilées à l’enregistrement pour la gestion.
• Connecter un pare-feu existant : la méthode OTP décrite plus bas suppose que le pare-feu est configuré et revendiqué par un claim dans le bon tenant. L’OTP l’enregistre pour Central Management, mais ne remplace ni le claim ni l’activation des abonnements. L’affectation du pare-feu à un client par un partenaire ne remplace pas non plus le claim.
• Gérer plusieurs pare-feux ensemble : Utiliser Sophos Fusion Firewall Groups en toute sécurité explique les politiques communes et les effets de Full Sync. La gestion des groupes est une tâche d’exploitation distincte, et non le mode d’installation Zero Touch.

Avantages de la connexion à Sophos Fusion

Vue d’ensemble centrale

Dans Sophos Fusion, vous pouvez voir les pare-feux enregistrés en un seul endroit. Cela est particulièrement utile lorsque plusieurs sites ou appliances de la même organisation sont gérés.

Avantages typiques :

• Vue d’ensemble du statut des pare-feux
• Numéros de série et informations sur les licences
• Statut du firmware et de la sécurité
• Rapports centraux
• Passage rapide d’un pare-feu à l’autre

Gestion via Sophos Fusion

Avec Manage from Sophos Central, vous pouvez accéder à la gestion du pare-feu via Sophos Fusion. C’est souvent plus sûr que de publier directement la console WebAdmin sur Internet.

L’accès à la gestion ne remplace pas une stratégie d’administration rigoureuse. Les comptes administrateurs, le MFA, les rôles, Device Access et les règles ACL doivent toujours être configurés avec soin. Selon Sophos, Central Firewall Management nécessite en plus un abonnement payant actif autre que Base Firewall ou une licence de support Sophos active donnant droit à cette fonction, par exemple Enhanced Support. La licence Base Firewall seule ne suffit pas ; tous les contrats de support ne donnent pas automatiquement ce droit.

Un point technique est souvent oublié : Sophos Fusion ne peut gérer des pare-feux que si chaque pare-feu accède à Internet en IPv4. Dans les environnements exclusivement IPv6 ou très strictement segmentés, ce chemin doit être vérifié avant l’activation.

Si les modifications via Central n’arrivent pas comme prévu sur le pare-feu, vous devriez également vérifier la Sophos Fusion Firewall Management Task Queue. Vous y verrez si des politiques de groupe ou des tâches de pare-feu basées sur l’API sont en attente, ont échoué ou ont été ignorées.

Utiliser Sophos Fusion Firewall Groups en sécurité explique comment plusieurs pare-feux reçoivent une politique commune et ce que font réellement Full Sync et Skip full sync.

Pour plusieurs sites, Central peut également orchestrer les connexions VPN basées sur les routes, les interfaces XFRM, les routes et les règles. Configurer et vérifier un groupe de connexions SD-WAN dans Sophos Fusion explique la planification, la résolution des conflits et la validation locale.

Limites de Central Firewall Management

Central Firewall Management est un chemin d’administration supplémentaire, mais il ne remplace pas complètement l’administration locale du pare-feu, les journaux locaux et un accès d’urgence testé. Surtout avec plusieurs administrateurs, des groupes de pare-feux et des clusters HA, il faut connaître les principales limites pour ne pas confondre un comportement normal de la plateforme avec une erreur de configuration.

Observations courantes en exploitation :

• Deux administrateurs ouvrent le même pare-feu via Central en même temps : une seule session Central Manager peut être active par pare-feu. Si un deuxième administrateur reprend la session, le premier peut voir un chargement continu ou une erreur de connexion. Coordonnez les accès, fermez les sessions parallèles et, si nécessaire, vérifiez directement dans le WebAdmin local.
• Un rôle read-only ou helpdesk ne voit pas les pare-feux regroupés : tester les rôles dans Central avec de vrais comptes avant de les utiliser en production. Certaines vues ou fonctions de groupe ne sont pas visibles pour tous les rôles.
• Les paires HA apparaissent deux fois ou sur plusieurs pages : il peut s’agir d’un problème d’affichage ou de pagination. Pour décider, vérifiez également l’état HA local sur le pare-feu.
• Les règles de pare-feu ne peuvent pas être déplacées au niveau du groupe comme localement : toutes les actions du WebAdmin local ne sont pas reproduites de la même manière dans les groupes Central. Après une modification de groupe, validez localement l’ordre des règles et leur effet.
• Des groupes importés ou des règles WAF se comportent de manière inattendue dans Central : après un import de configuration, une synchronisation complète ou un import de règles WAF, vérifier la vue Central, le pare-feu cible et la Task Queue.

En production, Sophos Fusion coordonne les opérations, mais le pare-feu reste le point de validation des effets critiques. Après une modification de groupe, une tâche de firmware, un ajustement WAF ou une intervention HA, vérifiez également localement les règles, les services, l’état HA, les journaux et les connexions concernées.

Sauvegardes de configuration dans Sophos Fusion

Le pare-feu peut envoyer des sauvegardes de configuration à Sophos Fusion. Cela est utile si une appliance doit être remplacée ou restaurée et que les sauvegardes locales ne sont pas disponibles.

Dans Sophos Fusion, vous pouvez configurer des sauvegardes planifiées pour les pare-feux enregistrés. Les intervalles disponibles sont Daily, Weekly et Monthly. Cela permet, par exemple, de définir que certains pare-feux envoient une sauvegarde de configuration à Sophos Fusion quotidiennement, hebdomadairement ou mensuellement.

La documentation actuelle de Sophos sur les sauvegardes indique Global Settings > Products and Services > Firewall > Schedule Backup pour la planification. Si le chemin Firewall Management > Backup illustré dans la capture est absent de votre interface, utilisez cet accès.

Sophos Fusion ne conserve pas indéfiniment toutes les sauvegardes automatiques. Par défaut, les cinq sauvegardes les plus récentes sont conservées et les plus anciennes sont supprimées. Une sauvegarde peut aussi être marquée pour une conservation permanente. Dans les clusters HA, Primary et Auxiliary apparaissent dans le planning de sauvegarde, mais selon Sophos seule la sauvegarde du Primary est générée.

Deux détails sont importants pour l’exploitation : Sophos Fusion tente une sauvegarde jusqu’à cinq fois et génère une alerte ainsi qu’un e-mail au Fusion Admin si l’échec persiste. Si un pare-feu est retiré de la gestion Sophos Fusion, Sophos Fusion supprime les fichiers de sauvegarde associés. Les sauvegardes cloud sont donc utiles, mais ne remplacent pas une stratégie rigoureuse de sauvegarde et de restauration.

Cependant, il ne faut pas se fier uniquement à une seule méthode de sauvegarde. Pour les systèmes en production, des sauvegardes locales ou externes régulières restent utiles. Les mots de passe de sauvegarde et la clé maître de stockage sécurisé sont également importants.

Central Firewall Reporting

Avec Central Firewall Reporting, le pare-feu envoie les données de journaux et de rapports à Sophos Fusion. Cela permet d’évaluer les rapports sur de longues périodes et de les rechercher de manière centralisée.

Dans Sophos Fusion, des tableaux de bord, le Report Hub, le Report Generator, des modèles enregistrés et des exportations planifiées sont disponibles. Vous pouvez créer des rapports pour des pare-feux individuels ou plusieurs pare-feux, filtrer les périodes, rechercher des événements spécifiques et exporter les résultats en PDF, CSV ou HTML. Pour des évaluations régulières, les rapports peuvent également être planifiés et fournis automatiquement.

Selon Sophos, l’enregistrement des modèles, les exportations planifiées et les téléchargements nécessitent une licence Central Firewall Reporting Advanced. Pour les rapports couvrant plusieurs pare-feux, tous les pare-feux sélectionnés doivent disposer de la licence appropriée.

Modèles de rapport typiques :

• Antivirus
• Bandwidth usage
• Cloud app risks and usage
• Firewall
• IPS
• Log viewer and search
• SD-WAN
• SD-WAN SLA trend
• SD-WAN bandwidth usage
• Security posture assessment
• Synchronize app
• Threat geo activity
• Threats and events blocked
• VPN usage
• Web usage
• Web user risks
• X-Ops
• Zero-day protection

La durée de conservation dépend de la licence :

• Abonnement actif au pare-feu : jusqu’à 7 jours, pour des rapports de base et des rétrospectives courtes
• Xstream Protection / Central Orchestration : jusqu’à 30 jours, selon l’offre groupée et les droits associés
• Central Firewall Reporting Advanced : jusqu’à 365 jours, avec 100 Go de stockage supplémentaire par licence

L’activation précise et le choix des journaux sont décrits dans l’article détaillé Activer Central Firewall Reporting.

Sécurité synchronisée et Security Heartbeat

Lorsque Sophos Endpoint et Sophos Firewall sont exploités ensemble via Sophos Fusion, la sécurité synchronisée peut être utilisée. Le pare-feu et l’endpoint échangent alors des informations de sécurité.

Exemples :

• Le pare-feu voit le Security Heartbeat des endpoints.
• Les appareils avec un Heartbeat rouge peuvent être automatiquement restreints.
• Les vues du réseau et des endpoints sont mieux reliées.
• En cas d’incidents, il est plus rapide de voir quel utilisateur ou appareil est affecté.

C’est l’une des plus grandes valeurs ajoutées lorsque, en plus du pare-feu, Sophos Endpoint, MDR ou XDR est utilisé.

Security Heartbeat peut aussi transmettre au pare-feu l’identité de domaine Windows d’un endpoint administré. Configurer Synchronized User ID Authentication décrit le processus sécurisé pour le pilote, la règle et la HA.

Valider Security Heartbeat après l’enregistrement

La présence du pare-feu dans Sophos Fusion ne prouve pas encore que Security Heartbeat fonctionne pour les endpoints. Il faut un compte Sophos Fusion, au moins un endpoint géré par Sophos Fusion avec une licence d’évaluation ou complète, ainsi qu’un abonnement Network Protection valide sur le pare-feu. Lors de l’enregistrement, SFOS active automatiquement Security Heartbeat et Synchronized Application Control.

Un seul endpoint pilote géré convient pour une première validation contrôlée :

1. Sous System > Sophos Central, vérifier que le pare-feu est enregistré et que Security Heartbeat est actif.

2. Dans Sophos Fusion, sous My Products > Firewall Management > Firewalls, confirmer l’alerte A new firewall has been successfully registered to Sophos Central. Cette alerte prouve l’enregistrement, mais pas encore l’effet d’une règle.

3. Pour l’endpoint pilote dans Sophos Fusion, vérifier le tenant, l’état de santé actuel et les événements de la même période.

4. Sous Control Center > User & device insights > Security Heartbeat, vérifier si le compteur Connected correspond de manière plausible à l’état attendu de l’endpoint pilote. Selon Sophos, la vue détaillée reste vide lorsque tous les endpoints sont verts ; elle ne répertorie individuellement que les endpoints rouges et jaunes.

5. Vérifier la règle de pare-feu réellement appliquée. Sous Configure Synchronized Security Heartbeat, distinguer les exigences minimales de heartbeat pour la source et pour la destination, et vérifier celles qui s’appliquent au flux pilote. Sans condition de heartbeat configurée, l’état est uniquement visible ; ne pas déduire une restriction d’accès du seul compteur. Vérifier également les exceptions existantes sous Web > Exceptions : Sophos documente qu’une exception aux contrôles de politique peut laisser passer des requêtes Web malgré Block clients with no heartbeat. Ne pas créer une telle exception pour contourner un échec du pilote.

6. Ce n’est qu’après avoir établi cette référence qu’il faut activer une condition de heartbeat dans une règle pilote au périmètre restreint, activer la journalisation, puis tester le trafic autorisé avec un endpoint sain.

Contradiction dans la documentation Sophos : la présentation générale de Security Heartbeat pour SFOS 22 et 23 affirme sans nuance, dans la section VPN, qu’en cas d’état Missing, tout le trafic de cet endpoint est bloqué par le pare-feu. La description détaillée de Heartbeat fait au contraire dépendre l’effet sur l’accès des règles et mentionne expressément l’exception aux contrôles de politique sous Web > Exceptions : les requêtes Web ne sont pas bloquées malgré Block clients with no heartbeat. Ces affirmations ne sont pas compatibles entre elles en tant que garantie générale d’isolement. Pour une validation sûre, il faut donc vérifier la règle réellement appliquée, les exigences minimales distinctes pour Source heartbeat et Destination heartbeat, les exceptions applicables et le résultat réel de l’accès. L’affichage Missing ne prouve pas à lui seul un isolement complet.

Il ne faut pas provoquer un état rouge pour ce test en désactivant ou en manipulant la protection de l’endpoint. Si Central, Control Center et l’effet de la règle ne correspondent pas, ou si Missing apparaît, analyser méthodiquement les alertes Missing Heartbeat à l’aide de la zone, du chemin, du Rule ID et des journaux.

Pour la vue plus large Control Center > User & device insights, consultez Évaluer User & Device Insights en toute sécurité. Cet article explique les compteurs Heartbeat et d’applications, les détections Zero-Day, l’UTQ, les erreurs SSL/TLS et les sessions du pare-feu, avec leurs différentes fenêtres temporelles et la distinction entre masquer une erreur et modifier une politique de déchiffrement. Ces indicateurs locaux ne sont pas équivalents à Central Reporting et ne prouvent pas que chaque endpoint ou connexion est protégé.

Définir le périmètre de surveillance Heartbeat et vérifier le chemin réseau

Sous System > Sophos Central > Optional configurations > Missing heartbeat zones, sélectionnez uniquement les zones dans lesquelles des endpoints Sophos gérés sont attendus. Les heartbeats manquants ne sont détectés que dans les zones sélectionnées ; les imprimantes, les appareils des invités, les équipements IoT et les clients utilisant un autre EDR n’obtiennent pas de Sophos Heartbeat par l’enregistrement. La liste des zones et les conditions de heartbeat des règles de pare-feu correspondantes doivent être cohérentes. Sophos documente un cas particulier : si une politique de heartbeat bloque une zone, mais qu’aucune zone n’est ajoutée dans ce champ, le widget Control Center peut tout de même afficher Missing. Une liste vide ne prouve donc pas qu’aucune politique n’affecte le trafic.

Avant de modifier le périmètre ou une règle pilote, consignez la liste initiale des zones, le Rule ID, les options de heartbeat, ainsi que l’IP, l’adresse MAC et l’état actuel de l’endpoint pilote. Appliquez uniquement la modification prévue, au périmètre restreint. Comparez ensuite le même endpoint dans Central et Control Center, générez un flux de test autorisé avec l’endpoint sain, puis vérifiez le Rule ID correspondant et le résultat de l’accès dans le Log Viewer. Si l’accès change de manière inattendue, restaurez la liste des zones et les options de règle consignées, répétez le même flux et analysez le chemin réseau plutôt que d’assouplir globalement les exigences de heartbeat.

Le canal Heartbeat documenté utilise une connexion TLS chiffrée vers 52.5.76.173 sur TCP 8347. Central fournit les certificats qui permettent au pare-feu d’associer les endpoints à la bonne organisation ; un port ouvert ne suffit pas à établir cette relation de confiance. Vérifiez ces limites de topologie avant de diagnostiquer un état manquant :

• Un VPN établi avant la connexion heartbeat peut détourner ce trafic du pare-feu local. Pour Sophos Connect IPsec, vérifiez Remote access VPN > IPsec > Advanced settings > Send Security Heartbeat through tunnel par rapport à la politique de connexion prévue.
• Derrière un routeur intermédiaire sans NAT, un endpoint peut toujours partager son état de santé, mais le pare-feu ne peut pas détecter un heartbeat manquant. La présence d’un état de santé ne prouve pas que la surveillance Missing fonctionne sur ce chemin.
• Derrière une passerelle NAT, les endpoints ne peuvent pas partager leur état de santé avec le pare-feu. Cette limitation est différente de celle du cas routé sans NAT.
• En mode TAP, au moins une interface de la zone LAN, connectée en permanence, doit être accessible aux endpoints. Le trafic recopié par mirroring ne suffit pas : les endpoints reçoivent les adresses des interfaces LAN via Central et tentent d’envoyer leur heartbeat à l’une d’elles.

Interpréter l’état de santé sans supposer un isolement automatique

Connected (vert) correspond à l’état sain déclaré par l’endpoint, sans garantir que toute menace a été écartée. Warning (jaune) peut indiquer une PUA, un malware inactif ou nettoyé, ou des signatures qui n’ont pas été mises à jour depuis 24 heures. At risk (rouge) nécessite une investigation, par exemple en présence d’un malware actif qui n’a pas pu être supprimé, de trafic réseau malveillant ou d’une protection qui ne fonctionne pas correctement. Missing (rouge) est différent : le pare-feu voit du trafic, mais ne reçoit aucun état de santé correspondant. Comparez les événements de l’endpoint avant de considérer ces deux libellés rouges comme un même incident.

La vue détaillée des endpoints rouges et jaunes fournit le nom d’hôte, l’IP, l’utilisateur et le temps écoulé depuis le changement d’état. Une entrée Missing peut rester dans Control Center et dans les rapports après que l’endpoint a quitté le réseau ; elle change lorsque l’endpoint se reconnecte. Ne supprimez pas une telle entrée uniquement pour rendre le tableau de bord vert. Le guide Missing Heartbeat lié plus haut explique la collecte des éléments de diagnostic, les compromis liés aux temporisations, le comportement Modern Standby pris en charge et le nettoyage au périmètre restreint. Les endpoints envoient leur heartbeat toutes les 15 secondes ; la diffusion des listes d’endpoints rouges et jaunes toutes les 30 secondes et le délai de détection Missing de 60 secondes par défaut sont des mécanismes distincts. Allonger les délais de détection ou de notification peut également retarder de véritables alertes.

La protection contre les mouvements latéraux est un autre contrôle distinct : les autres endpoints cessent de communiquer avec un endpoint rouge uniquement lorsque la politique endpoint correspondante dans Central s’applique. Le pare-feu partage les adresses MAC et les états de santé en tant que proxy de couche 2 au sein du même domaine de diffusion. Ne supposez pas que cela isole les endpoints entre réseaux routés ou remplace les conditions de heartbeat appliquées au trafic qui traverse le pare-feu.

La présentation de SFOS 22 décrit l’identité utilisateur synchronisée avec le nom de domaine, le nom d’utilisateur et Active Directory. Celle de SFOS 23 documente en plus User Principal Name (UPN) et la validation des comptes auprès d’Active Directory ou Microsoft Entra ID. N’appliquez pas cette description de SFOS 23 à un déploiement SFOS 22 et ne supposez pas que l’enregistrement seul configure l’authentification des identités ; vérifiez le firmware réellement utilisé et la configuration du serveur d’authentification avant d’utiliser des règles basées sur l’identité.

Ce que Sophos Fusion ne remplace pas

Sophos Fusion est utile, mais ne remplace pas une configuration rigoureuse du pare-feu.

Central ne remplace pas :

• une planification rigoureuse des zones et des interfaces
• des règles de pare-feu restrictives
• le renforcement de l’accès aux appareils
• le MFA pour les administrateurs et les portails
• le dépannage local avec Log Viewer et Packet Capture
• des sauvegardes documentées et des tests de restauration
• un système Syslog externe, si la conformité ou une conservation longue est requise

Sophos Fusion est donc une couche supplémentaire de gestion et de reporting, mais pas un raccourci pour une configuration de base sécurisée.

Vérifications avant l’enregistrement

Avant de connecter le pare-feu à Sophos Fusion, il est important de préciser les objectifs de cet enregistrement. Cela évite par la suite une répartition floue des responsabilités, des tenants en double ou l’activation de services inutiles.

Questions préalables importantes :

• Dans quel tenant Sophos Fusion le pare-feu doit-il être enregistré ?
• Qui dispose dans le tenant des droits nécessaires pour Firewall Management, Reporting, Backup et les sujets de licence ?
• Le pare-feu est-il déjà enregistré dans un autre compte Central ?
• Le pare-feu dispose-t-il d’un abonnement payant actif autre que Base Firewall ou d’une licence de support Sophos active donnant droit à Central Firewall Management, par exemple Enhanced Support ? Vérifier la licence précise, pas seulement l’existence d’un contrat de support.
• Le pare-feu dispose-t-il d’une connexion IPv4 fonctionnelle vers Internet ?
• Central doit-il être utilisé uniquement pour l’inventaire et la vue des licences, ou aussi pour Management, Reporting et Backups ?
• Des groupes de pare-feux sont-ils utilisés, et les rôles Admin, Helpdesk et Read-only ont-ils été testés en pratique ?
• Les journaux du pare-feu peuvent-ils être envoyés à Sophos Fusion au regard des exigences de protection des données ou de conformité ?
• Existe-t-il une sauvegarde locale actuelle et une Secure Storage Master Key documentée ?
• Est-il clair qui vérifie les alertes, les rapports et les tâches échouées après l’enregistrement ?

Si le pare-feu est déjà dans le mauvais compte, il convient d’abord de vérifier Transférer Sophos Firewall vers un autre compte Sophos Fusion. Pour la classification des différents comptes et portails, consultez Portails Sophos : SophosID, Central, Support et accès au pare-feu.

Quand il n’est pas nécessaire de connecter le pare-feu

Une connexion à Sophos Fusion n’est pas nécessaire si :

• un seul pare-feu est géré localement
• aucun rapport Central n’est requis
• aucune intégration Sophos Endpoint n’est prévue
• la gestion cloud n’est pas souhaitée pour des raisons organisationnelles
• les journaux sont déjà envoyés à un SIEM ou à un serveur Syslog dédié

Dans ces cas, le pare-feu peut être exploité localement. Il est alors important d’organiser correctement les sauvegardes, les mises à jour du firmware, la surveillance et la journalisation autrement.

Quand Sophos Fusion est recommandé

Sophos Fusion est particulièrement recommandé si :

• plusieurs pare-feux sont gérés
• les administrateurs travaillent depuis différents sites
• les pare-feux ne doivent pas être directement accessibles via WebAdmin depuis Internet
• les sauvegardes de configuration doivent être stockées de manière centralisée
• le reporting du pare-feu est nécessaire
• Sophos Endpoint, MDR, XDR ou d’autres produits Sophos Fusion sont utilisés
• Security Heartbeat et Synchronized Security doivent être utilisés

Activer la connexion

La connexion est configurée sur le pare-feu sous System > Sophos Central.

Les procédures suivantes utilisent les libellés d’interface en anglais documentés pour SFOS 22 et SFOS 23 ; l’interface locale peut encore afficher Sophos Central. Un administrateur local du pare-feu doit avoir accès à ce menu. Central Firewall Management nécessite toujours un abonnement payant actif autre que Base Firewall ou une licence de support Sophos active donnant droit à cette fonction, par exemple Enhanced Support. Base Firewall seul ne suffit pas, et le chemin de gestion via Internet fonctionne uniquement en IPv4.

Avant de générer un OTP : le pare-feu doit déjà être configuré et revendiqué par un claim dans le tenant Sophos Fusion prévu. Si la configuration ou le claim n’est pas terminé, suivre d’abord Configurer Sophos Firewall, effectuer le claim et activer les licences, puis vérifier l’affectation de l’appareil et des licences. L’enregistrement ultérieur par OTP connecte le pare-feu existant à Central Management ; il ne revendique pas sa propriété et n’active pas les abonnements. L’affectation du pare-feu à un client par un partenaire ne remplace pas non plus le claim.

Il existe deux méthodes d’enregistrement typiques :

• OTP depuis Sophos Fusion : utile lorsqu’un partenaire, une équipe projet ou un administrateur du pare-feu ne doit pas utiliser les identifiants Super Admin du tenant Central sur le pare-feu. Dans Sophos Fusion, le pare-feu existant est ajouté sous My Products > Firewall Management > Firewalls > Add Firewall avec son numéro de série, puis un OTP est généré.
• Identifiants Sophos Fusion : utile lorsqu’on enregistre directement le pare-feu avec un compte administrateur Sophos Fusion approprié. Sophos parle ici d’un Central Super Admin.

Pour les paires HA, il faut travailler avec précision. Lors d’un enregistrement par OTP, les deux numéros de série sont saisis dans Sophos Fusion ; pour les nouvelles paires HA, l’OTP est utilisé sur le Primary.

Générer un OTP dans le bon tenant

Pour un pare-feu déjà configuré et revendiqué par un claim, générez l’OTP dans Central avant de passer aux étapes d’enregistrement local :

1. Connectez-vous au tenant prévu. Un partenaire doit d’abord affecter le pare-feu au bon client dans Partner Dashboard, puis ouvrir la console Central Admin de ce client. L’affectation au client ne remplace pas le claim.
2. Ouvrez My Products > Firewall Management > Firewalls > Add Firewall et choisissez Join a firewall that is configured or deployed.
3. Dans Enter Device Serial Number, saisissez le numéro de série prévu et cliquez sur Next. Pour une paire HA, saisissez les deux numéros de série séparés par une virgule et vérifiez qu’ils correspondent à la paire prévue.
4. Laissez Register using OTP sélectionné et choisissez Copy OTP and Finish. L’OTP est valable 14 jours. Partagez-le uniquement avec l’administrateur du pare-feu autorisé, via le canal approuvé de partage des secrets ; n’incluez pas l’OTP, les mots de passe ou des captures d’écran contenant des identifiants non masqués dans un dossier de support.
5. Sur le pare-feu, choisissez Register > Use OTP, collez l’OTP dans Enter OTP et cliquez sur Register. Pour une nouvelle paire HA, saisissez l’OTP uniquement sur l’appareil primaire. Activez ensuite les services Central prévus et obtenez leur approbation comme décrit ci-dessous.

Si l’OTP a expiré ou si l’enregistrement échoue, vérifiez d’abord le tenant prévu, le claim, les numéros de série et la connectivité IPv4. Obtenez un nouvel OTP depuis le bon tenant si nécessaire ; ne répétez pas le désenregistrement et ne changez pas le propriétaire pour contourner l’erreur. Ne considérez l’enregistrement comme validé que lorsque les numéros de série et l’état des services concordent dans les deux vues.

La méthode alternative avec identifiants exige un Central Super Admin. Un compte administrateur appartenant à un Central Enterprise sub-estate ne peut pas être utilisé pour cet enregistrement. Distinguez bien le compte du tenant du rôle d’administrateur local du pare-feu ; l’OTP permet à l’administrateur local d’effectuer l’enregistrement sans recevoir le mot de passe Super Admin du tenant.

Procédure typique sur le pare-feu :

1. Se connecter au pare-feu.
2. Ouvrir System > Sophos Central.
3. Sélectionner Register.
4. Sélectionner Use OTP ou Use email address.
5. Saisir l’OTP ou les identifiants Sophos Fusion.
6. Terminer l’enregistrement.
7. Activer Sophos Central services.
8. Sélectionner les services souhaités.

Selon les besoins, ces options peuvent être activées :

• Use Sophos Central reporting / Send reports and logs to Sophos Central : envoie les données de journaux et de rapports à Sophos Fusion.
• Use Sophos Central management / Manage from Sophos Central : permet l’accès de gestion via Sophos Fusion.
• Send configuration backup to Sophos Central : stocke les sauvegardes de configuration dans Sophos Fusion. En pratique, cette option dépend de la configuration de Central Management et doit être approuvée dans Sophos Fusion.

Seules les fonctions réellement utilisées doivent être activées. Dans les environnements soumis à des exigences de protection des données ou de conformité, il faut clarifier au préalable quelles données de journaux peuvent être envoyées à Sophos Fusion.

Après l’activation des services, un compte avec le rôle Super admin dans le tenant Sophos Fusion concerné doit accepter les services dans Sophos Fusion :

1. Se connecter à Sophos Fusion.
2. Ouvrir My Products > Firewall Management > Firewalls.
3. Rechercher le pare-feu avec Approval Pending.
4. Sélectionner accept-services.
5. Sur le pare-feu, vérifier si le statut passe de Waiting for approval from Sophos Central à Managed ou connecté.

Le changement de statut peut prendre quelques minutes. Si l’affichage ne change pas immédiatement, il ne faut pas réenregistrer plusieurs fois. Vérifier d’abord le statut Central, la connexion Internet, le DNS et l’heure.

Si un filtre de trafic sortant se trouve devant le pare-feu, les services et ports Sophos sortants correspondants pour Central, le reporting et les sauvegardes doivent également être accessibles.

Placer une paire HA sous gestion Central

Distinguez les deux situations de départ avant toute modification. Consignez les deux numéros de série, les versions du firmware, les rôles primaire et auxiliaire, l’état HA local et les états des services Central. Conservez des sauvegardes de configuration à jour, leurs mots de passe et la Secure Storage Master Key, et gardez un accès d’administration local fonctionnel. La création d’une paire HA est une modification de maintenance distincte, pas un raccourci pour dépanner l’enregistrement ; Planifier et exploiter les variantes HA de Sophos Firewall traite de la configuration de référence, de la synchronisation et du plan de récupération.

• Deux pare-feux autonomes sont déjà gérés de manière centralisée : préparez la HA localement à partir de la configuration prévue pour le primaire. Les deux appareils doivent exécuter la même version du firmware. Sophos documente les modes Active-Active et Active-Passive ; après la création de la paire, Central devrait afficher une seule paire HA, et non deux cibles de gestion indépendantes. Suivez la procédure de préparation HA avant de laisser la synchronisation remplacer la configuration de l’auxiliaire.
• Une paire HA existe, mais n’est pas gérée de manière centralisée : travaillez sur le primaire. La documentation spécifique à la HA nomme la vue d’enregistrement Central synchronization et l’action Register both HA devices. Après l’enregistrement, activez la gestion Central puis, à côté du pare-feu primaire dans Central, sélectionnez Approval Pending > accept-services avec le compte Super Admin autorisé. Pour la méthode OTP, utilisez les deux numéros de série et la saisie sur le primaire uniquement, comme décrit plus haut, plutôt que d’enregistrer chaque nœud indépendamment.

Attendez quelques minutes, puis confirmez que Central affiche une seule paire avec une icône HA et les numéros de série prévus. Vérifiez localement les rôles primaire et auxiliaire ainsi que la synchronisation, puis contrôlez l’accès de gestion et un flux de test autorisé en production. Les modifications de configuration dans Central s’appliquent aux deux pare-feux ; l’affichage d’un seul objet ne prouve pas que seul le primaire est affecté.

Si l’affichage reste séparé ou présente des doublons, comparez l’état HA local, les deux numéros de série, le tenant, l’approbation des services et la Task Queue avant de modifier l’enregistrement. Pour un retour arrière limité à la gestion, restaurez les états des services Central consignés et vérifiez l’accès local et le bon fonctionnement de la HA. Ne dissolvez pas la paire HA, ne relancez pas l’assistant de configuration et ne forcez pas le désenregistrement via la CLI pour corriger un problème d’affichage. Annuler la création de la paire HA nécessite le plan de récupération HA approuvé séparément ; tout problème d’enregistrement non résolu ou toute ambiguïté sur les nœuds concernés doit être transmis à Sophos Support avec les états collectés.

Diagnostiquer sans risque un enregistrement bloqué

Avec Approval Pending ou Waiting for approval from Sophos Central, il ne faut ni relancer l’enregistrement ni désenregistrer trop vite le pare-feu. Vérifier d’abord le tenant et le numéro de série, l’approbation par un Super admin du tenant concerné sous My Products > Firewall Management > Firewalls, l’accès Internet IPv4, le DNS, l’heure et les services sortants requis. En HA, les deux numéros de série doivent être saisis dans Central et l’OTP sur le nœud primaire. Si le statut reste bloqué après correction, conserver des captures des deux affichages, l’heure, les numéros de série et les rôles HA pour Sophos Support.

Effacer la configuration Synchronized Security uniquement dans le cadre d’une opération approuvée par le support. La documentation Device Console pour SFOS 22 et 23 décrit system synchronized-security central_registration deregister pour supprimer la configuration Synchronized Security de Sophos Fusion ou Sophos Central lorsqu’elle bloque l’enregistrement ou le désenregistrement. Le cas visé ici est celui d’un pare-feu existant dont l’enregistrement reste bloqué par Synchronized Security après les vérifications ci-dessus, avec cette cause confirmée par Sophos Support. Il ne s’agit ni du désenregistrement complet de l’appareil via Deregister dans la section suivante, ni d’un nettoyage de la base de données interne par SQL. Cette commande modifie l’état ; ce n’est ni un diagnostic en lecture seule ni une solution générale à Approval Pending.

Avant toute exécution, consigner dans le dossier de support le tenant prévu et le tenant actuel, l’appareil et son numéro de série, la version exacte de SFOS avec le build, l’état d’enregistrement, les services Central actifs, Security Heartbeat, Synchronized Application Control, ainsi que les règles concernées et leur effet actuel. En HA, inclure les deux numéros de série, les rôles primaire et auxiliaire, l’état de synchronisation et le périmètre des nœuds concernés expressément confirmé. Tester et conserver un accès local autorisé à WebAdmin et à la console, indépendant du chemin de gestion Central. Garder une sauvegarde locale à jour, son mot de passe et la Secure Storage Master Key disponibles.

Ne pas exécuter sans approbation spécifique au build. Sophos Support doit d’abord confirmer que l’effacement convient à ce cas, les effets attendus sur l’enregistrement, les services, le trafic dépendant de Heartbeat et la HA, ainsi que la procédure de récupération, y compris tout enregistrement ou toute approbation de services nécessaire. La syntaxe documentée ne garantit ni le maintien des services ni une restauration réversible de l’état précédent ; une sauvegarde seule ne démontre pas non plus cette voie de récupération. Si les effets, le périmètre des nœuds ou la récupération restent incertains, suspendre l’exécution et maintenir le dossier auprès du support. Ne pas remplacer cette opération par des modifications SQL ou un désenregistrement complet forcé.

Après une opération expressément approuvée, vérifier selon le plan du support l’enregistrement dans le bon tenant et les deux vues d’état, les services prévus et l’accès local indépendant. Contrôler aussi Security Heartbeat avec l’endpoint pilote géré, la reconnaissance des applications si elle s’applique, l’effet des règles concernées, le trafic de production, les journaux et, en HA, les rôles et la synchronisation. Un pare-feu à nouveau visible ne suffit pas à prouver le succès. En cas d’écart, conserver l’état et suivre le plan de récupération approuvé avec Sophos Support plutôt que de relancer la commande.

Modifier les services Central ou désenregistrer

Désactiver Security Heartbeat, Synchronized Application Control ou Sophos Central management ne désenregistre pas le pare-feu de Central. Les services ne sont toutefois pas indépendants : désactiver Security Heartbeat désactive également Synchronized Application Control, et les endpoints et le pare-feu cessent d’échanger leurs informations d’état de santé. Une pause de Heartbeat affecte donc plusieurs services.

Avant la modification, noter sous System > Sophos Central les états d’activation ou de désactivation précédents de Security Heartbeat et de Synchronized Application Control, ainsi que l’état du service concerné. Désactiver ensuite le service prévu, enregistrer, puis vérifier les états des services affectés et confirmer que le pare-feu reste enregistré.

Pour revenir en arrière, restaurer le service concerné et les deux états documentés, puis faire accepter dans Central toute nouvelle demande d’approbation par un Super admin du tenant concerné. Vérifier explicitement Security Heartbeat et Synchronized Application Control séparément, sans supposer que la seule activation de Heartbeat rétablit correctement les deux. Si Heartbeat était actif auparavant, utiliser un endpoint pilote géré pour vérifier l’état de santé actuel et le compteur Connected correspondant dans Control Center, comme décrit plus haut. Si Synchronized Application Control était actif auparavant, vérifier également la reconnaissance des applications sous Applications > Synchronized Application Control avec l’endpoint pilote ; Utiliser Application Control de manière ciblée explique la procédure de validation adaptée.

Le désenregistrement complet est une étape distincte et planifiée :

1. Créer une sauvegarde locale à jour et conserver son mot de passe ainsi que la Secure Storage Master Key. Consigner le tenant, les numéros de série, les services actifs, les groupes de pare-feux, les tâches en attente, le reporting et les sauvegardes Central. En HA, noter les deux nœuds et leurs rôles.
2. Tester l’accès WebAdmin local avec un compte autorisé. Terminer les tâches Central en attente ou consigner leur état, puis choisir une fenêtre de maintenance. Ne pas utiliser les sauvegardes Central comme seul moyen de retour arrière : elles sont supprimées lorsque le pare-feu est retiré de Central Management.
3. Sur le pare-feu, ouvrir System > Sophos Central et choisir Deregister. Ne pas employer de commandes Device Console ou Advanced Shell non documentées comme raccourci.
4. Vérifier localement que le pare-feu n’apparaît plus comme géré par Central. Sous My Products > Firewall Management > Firewalls, contrôler l’état de l’objet ; un objet restant ne signifie pas que l’enregistrement fonctionne. Vérifier ensuite l’accès local, le trafic de production, les journaux et, en HA, l’état du cluster.

Pour annuler le changement, enregistrer à nouveau le pare-feu avec le processus OTP ou avec les identifiants d’un super administrateur, faire accepter les services requis dans Central par un Super admin du tenant concerné et répéter les tests propres à chaque service. Si Deregister n’est pas disponible, si l’opération reste bloquée ou si la portée HA est ambiguë, ne pas la forcer en CLI. Transmettre les états conservés à Sophos Support.

Contrôler après la connexion

Après l’enregistrement, il ne suffit pas de vérifier si le pare-feu est visible dans Sophos Fusion. Ce qui est crucial, c’est de savoir si les services activés fonctionnent réellement et si les responsabilités sont claires.

Contrôle post-enregistrement utile :

1. Vérifier dans Sophos Fusion si le modèle, le numéro de série et le statut de la licence sont affichés correctement.
2. Sur le pare-feu, sous System > Sophos Central, vérifier si les services souhaités sont actifs et connectés.
3. Si Manage from Sophos Central est utilisé, ouvrez My Products > Firewall Management > Firewalls dans Central et cliquez sur le nom du pare-feu pour ouvrir sa console WebAdmin. Attendez quelques secondes et vérifiez l’accès avec le rôle administrateur prévu ; gardez un accès d’administration local fonctionnel disponible pendant le test.
4. Si le reporting est actif, vérifier dans le Log Viewer et dans Sophos Fusion si les événements actuels arrivent.
5. Si les sauvegardes cloud sont actives, configurer la sauvegarde planifiée et documenter le dernier point de sauvegarde réussi.
6. Vérifier les alertes, les rôles et les responsabilités dans Sophos Fusion.
7. Si des modifications sont distribuées via Central, contrôler la Central Firewall Management Task Queue.

Surtout avec plusieurs pare-feux, l’enregistrement doit figurer dans la documentation interne : tenant, numéro de série, emplacement, service Central actif, conservation des rapports, intervalle de sauvegarde et personne responsable.

Valider séparément les services Central

Après l’enregistrement, il ne faut pas seulement vérifier l’état global de Central. Les différents services ont des symptômes d’erreur différents et doivent donc être validés séparément.

• Enregistrement et inventaire : le pare-feu apparaît dans le bon tenant, et le numéro de série, le modèle, la licence et le site sont corrects.
• Manage from Sophos Central : l’accès via Central fonctionne avec le rôle administrateur prévu, sans que WebAdmin reste inutilement ouvert depuis le WAN.
• Central Reporting : un événement déclenché volontairement apparaît dans le Report Hub avec le bon pare-feu, la bonne heure et l’ID de règle ou le type de journal correct.
• Sauvegardes Central : une sauvegarde planifiée ou manuelle se termine correctement, et l’intervalle, le mot de passe et la Secure Storage Master Key sont documentés.
• Conservation des sauvegardes : les cinq sauvegardes Central les plus récentes et une éventuelle sauvegarde conservée durablement sont connues. En HA, il est clair que le Primary crée la sauvegarde.
• Alertes de sauvegarde : les échecs de sauvegarde Central génèrent des alertes et des notifications par e-mail qui sont contrôlées par une personne responsable.
• Central Tasks : après une modification Central, la Task Queue est contrôlée jusqu’à ce que la tâche soit terminée avec succès ou transmise au niveau de support approprié.
• Security Heartbeat : Sophos Fusion affiche l’état attendu de l’endpoint pilote et le compteur correspondant dans Control Center est cohérent. Les restrictions basées sur des règles ne sont testées que progressivement après avoir établi cette référence.
• Alertes et responsabilité : il est clair qui contrôle régulièrement les tâches échouées, les problèmes de sauvegarde, les lacunes de reporting et les alertes de licence.

Cette séparation évite une erreur d’exploitation typique : un pare-feu peut être visible dans Sophos Fusion alors que le reporting, les sauvegardes ou les tâches Central ne fonctionnent pas correctement.

Erreurs typiques

Le pare-feu est enregistré dans le mauvais compte Central

Cela arrive souvent lors de changements de prestataires, avec des comptes de test ou en présence de plusieurs comptes SophosID historiques. Dans ce cas, il ne faut pas simplement tenter un deuxième enregistrement. Clarifiez d’abord où se trouve actuellement le pare-feu, qui a accès au tenant et si un transfert de compte est nécessaire.

Central Management est confondu avec WebAdmin local

Manage from Sophos Central est un moyen d’accès supplémentaire. La console WebAdmin locale, les utilisateurs administrateurs locaux, le MFA, Device Access et SSH restent des contrôles de sécurité indépendants. Il est particulièrement important que WebAdmin ne reste pas accessible depuis le WAN simplement parce que Central Management n’a pas encore été testé.

La vue Central n’est pas validée localement

Pour les stratégies de groupe, les clusters HA, les règles WAF et les tâches de firmware, Central ne doit pas être considéré comme la seule source de vérité. Central peut indiquer qu’une modification est planifiée, appliquée ou visible. L’important est de savoir si le pare-feu concerné a traité la modification et si le trafic ou le service réel fonctionne ensuite.

En pratique : après des modifications Central, vérifier la Task Queue, la vue WebAdmin locale, le Log Viewer et, si nécessaire, l’Audit Trail. Si l’interface Central charge sans fin, si une paire HA semble apparaître deux fois ou si une règle de groupe ne peut pas être déplacée, ce n’est pas automatiquement un problème de règle de pare-feu.

Le reporting est activé, mais aucune donnée exploitable n’arrive

Dans ce cas, vérifiez d’abord si Send reports and logs to Sophos Central est activé, si les types de journaux appropriés sont activés et si le pare-feu peut atteindre Sophos Fusion. Ensuite, consultez l’article Activer Central Firewall Reporting pour les détails sur le choix des journaux, la conservation et les rapports.

La sauvegarde cloud est comprise comme la seule sauvegarde

Les sauvegardes Central sont pratiques, mais elles ne remplacent pas une planification complète de la récupération. Pour les sites critiques, il doit également être clair où se trouvent les sauvegardes locales, qui connaît le mot de passe de sauvegarde, si la clé maître de stockage sécurisé est documentée et comment se déroulerait une restauration ou une réinstallation à partir d’une image.

Personne ne vérifie les tâches et alertes Central

Central n’est utile que si les notifications et les tâches échouées sont également traitées. Surtout pour les politiques de groupe, les tâches de firmware, le reporting et les sauvegardes, il doit être clair qui vérifie les avertissements et comment les erreurs sont transmises au niveau compétent en interne.

Questions fréquentes