Utiliser Sophos Central Firewall Groups et Full Sync en sécurité

Un Firewall Group dans Sophos Central est un modèle de configuration partagé par plusieurs pare-feu. Il réduit le travail, mais change aussi la responsabilité : dès qu’un pare-feu suit entièrement le groupe, les règles, objets et paramètres pris en charge sont gérés de manière centralisée.

La décision critique intervient lors de l’ajout du pare-feu. Avec Full Sync, il adopte toute la configuration prise en charge du groupe. Avec Skip full sync, la configuration actuelle est d’abord conservée, mais les modifications ultérieures du groupe sont tout de même distribuées. Skip full sync ne sépare donc pas durablement le pare-feu du groupe.

⚠️ Avant le premier Full Sync, créer un backup actuel du pare-feu, garder une session d’administrateur local ouverte et tester la voie de reprise. Un task Central réussi ne prouve pas que le routing, le NAT, l’authentification et le trafic de production fonctionnent correctement.

Parcours rapide pour une introduction sûre

Choisir un pare-feu pilote représentatif et inventorier sa configuration locale, l’ordre des règles et les dépendances.
Créer un groupe vide sous My Products > Firewall Management > Firewalls > Create New Group.
Choisir consciemment Use Sophos default ou Import existing configuration et vérifier la group policy obtenue avant l’affectation.
Ajouter d’abord le pare-feu pilote avec Skip full sync uniquement si sa configuration actuelle doit être conservée.
Déployer une petite modification de groupe clairement identifiable et vérifier la Task Queue.
Valider la modification localement sur le pare-feu avec un trafic de test réel.
Planifier seulement ensuite d’autres pare-feu, des sous-groupes ou un Full Sync.

Ce que gère un Firewall Group

La group policy s’ouvre avec Manage Policy. Elle ressemble au WebAdmin local, mais s’applique à tous les pare-feu affectés. Central distribue les objets et paramètres pris en charge ; une configuration purement locale ou liée aux interfaces ne fait pas automatiquement partie du modèle.

C’est particulièrement important entre des sites différents. Une règle partagée ne fonctionne que si ses zones, interfaces dynamiques, réseaux, services et dépendances sont résolus de manière cohérente sur chaque cible. Des sous-groupes planifiés ou des Dynamic Objects conviennent mieux aux valeurs propres aux sites que des corrections locales ultérieures.

Objets, paramètres et sous-groupes

Des objets tels que les règles de pare-feu, règles NAT, FQDN Hosts et IP Hosts peuvent être créés et supprimés dans une group policy. Les sous-groupes héritent de copies en lecture seule des objets du Parent, mais peuvent les utiliser comme base de leurs propres règles. Si un objet Parent est utilisé dans un sous-groupe, Central empêche sa suppression et indique la dépendance.

Les paramètres avec un bouton Apply sont configurés uniquement dans le Parent supérieur et hérités par tous les sous-groupes. Un sous-groupe ne peut pas les remplacer séparément. Avant de construire une hiérarchie, il faut déterminer quelles valeurs doivent réellement être identiques sur tous les sites.

Créer le groupe et choisir la configuration initiale

Sous My Products > Firewall Management > Firewalls > Create New Group, deux points de départ sont disponibles :

Use Sophos default : crée une nouvelle group policy à partir des valeurs par défaut Sophos. Le résultat est facile à suivre pour un nouveau design construit volontairement dans Central.
Import existing configuration : utilise comme modèle la configuration d’un pare-feu existant prise en charge par Central. Les interfaces et autres configurations locales ne sont pas entièrement importées.

La création du groupe peut échouer pendant l’import si des règles font référence à des types d’utilisateurs non pris en charge. Sophos cite les utilisateurs AD, Sophos Live, L2TP et PPTP. Avant l’import, vérifier les règles concernées, les objets utilisateur et la Task Queue ; ne pas forcer l’import en supprimant spontanément des règles de production.

Un groupe vide est souvent le point de départ le plus sûr. La policy peut être préparée et vérifiée avant d’affecter un pare-feu. Connecter Sophos Firewall à Sophos Central explique l’enregistrement du pare-feu.

Bien choisir Full Sync ou Skip full sync

Full Sync

Full Sync applique au pare-feu toute la configuration prise en charge du groupe. Il convient lorsque la group policy représente l’état cible et que les écarts locaux peuvent être remplacés volontairement.

Avant l’exécution, comparer au minimum les règles de pare-feu et NAT, Hosts, Services, dépendances d’authentification, certificats, VPN, policies Web et TLS ainsi que les Local Service ACL. Un backup actuel, un accès de gestion et une fenêtre de maintenance font partie du changement.

Skip full sync

Avec Skip full sync, la configuration existante n’est pas entièrement remplacée lors de l’affectation du pare-feu. Celui-ci peut d’abord différer des autres membres. Les objets et paramètres nouveaux ou modifiés ultérieurement dans le groupe lui sont néanmoins distribués.

Ce mode convient à une adoption contrôlée de certaines futures modifications Central. Il ne convient pas lorsque des administrateurs locaux et Central veulent gérer indépendamment le même objet. Avant chaque modification, il faut savoir si un objet existant ou portant le même nom sur le pilote sera écrasé ou complété.

Un Force sync ultérieur applique toute la configuration du groupe. Pour une paire HA, cette action n’est disponible que sur le pare-feu actif. Elle n’est déclenchée qu’après avoir documenté et validé techniquement l’écart entre l’état local et la group policy.

Modifier et distribuer la group policy

Dans My Products > Firewall Management > Firewalls, ouvrir Manage Policy depuis le menu du groupe.
Modifier uniquement la règle, l’objet ou le paramètre prévu.
Revenir dans Central et développer le task sous My Products > Firewall Management > Tasks Queue.
Documenter le statut, les pare-feu concernés, l’Entity, l’heure et le message d’erreur.
Ne valider localement qu’après Successful ou après avoir clairement compris un statut partiel.

Pour les règles de pare-feu et NAT, Top et Bottom s’appliquent uniquement dans la policy Central. Les règles Central sont insérées au-dessus des règles locales. Une gestion mixte peut donc produire des matches différents de ceux attendus. Sur les pare-feu gérés de manière centralisée, les règles liées doivent être maintenues dans Central et vérifiées avec la Firewall Rule ID ou NAT Rule ID réelle.

Valider l’effet localement

Un task réussi montre que Central a traité la demande. La validation technique s’effectue sur chaque pare-feu concerné :

L’objet ou le paramètre attendu est-il visible et complet ?
L’ordre effectif des règles est-il correct ?
Un flux de test défini correspond-il aux règles de pare-feu et NAT attendues ?
Les chemins aller et retour, le DNS, l’authentification et les services dépendants fonctionnent-ils ?
Un test volontairement interdit reste-t-il bloqué ?
L’Audit Trail montre-t-il l’administrateur, l’heure et la modification attendus ?

Sur plusieurs sites, documenter le succès ou l’échec pour chaque pare-feu. Un déploiement partiellement réussi n’est pas un succès du groupe. Tester les règles Sophos Firewall explique les Rules, Policy Test, Log Viewer et Packet Capture.

Délimiter les erreurs en sécurité

Le pare-feu reste désynchronisé

Vérifier d’abord l’appartenance au groupe, la connexion Central, la licence, le statut du task et le message exact. Utiliser Retry seulement après correction de la cause. Skip retire uniquement le task du traitement ; la configuration omise reste techniquement ouverte.

Une règle locale se comporte autrement après un push

Vérifier l’ordre effectif, la Rule ID, la résolution des objets et le NAT. Les règles Central se trouvent au-dessus des règles locales. La solution n’est pas d’ajouter une autre règle Allow large, mais de définir clairement la propriété et l’ordre du bloc concerné.

L’import d’un pare-feu existant échoue

Sauvegarder l’erreur et les Entities référencées. Vérifier ensuite les références d’utilisateurs non prises en charge, les interfaces locales et les autres dépendances non importables. Si la cause reste incertaine, transmettre les données du task et le backup à Sophos Support plutôt que de supprimer des objets de production à titre d’essai.

Rollback et exploitation

Un pare-feu peut être retiré du groupe, mais les policies déjà distribuées par Central restent sur le pare-feu. Le retrait n’est donc pas un rollback automatique. Vérifier localement les éléments documentés avant de supprimer ou remplacer une règle ou un objet.

Pour une exploitation fiable, chaque modification de groupe nécessite un responsable, une référence de task, un test local et une décision de rollback. Tester d’abord les changements importants sur un pilote ou un sous-groupe. Les Audit Trail Logs et un backup actuel restent nécessaires avec la gestion Central.

Liste de contrôle

Pare-feu pilote et voie de reprise de gestion testés.
Backup et configuration initiale sauvegardés.
Use Sophos default ou Import existing configuration choisi consciemment.
Full Sync ou Skip full sync correspond au modèle de propriété prévu.
Objets, paramètres, sous-groupes et dépendances vérifiés.
Task Queue affiche le statut attendu pour chaque pare-feu.
Ordre des règles, Rule IDs et trafic réel validés localement.
Le rollback tient compte des policies qui restent après le retrait du groupe.

FAQ

Skip full sync est-il une exception permanente aux modifications du groupe ?

Non. La configuration existante est d’abord conservée lors de l’affectation, mais les modifications ultérieures de la group policy sont distribuées au pare-feu.

Le retrait d'un pare-feu du groupe annule-t-il les modifications Central ?

Non. Les policies déjà distribuées restent sur le pare-feu. Un rollback doit vérifier et restaurer explicitement les règles, objets et paramètres concernés.