Utiliser Sophos Firewall Config Studio

Sophos Firewall Config Studio est un outil Sophos basé sur un navigateur qui vous permet d’afficher, de comparer et de préparer des configurations de pare-feu. C’est particulièrement utile si vous souhaitez non seulement savoir si quelque chose a changé, mais également quelle règle, objet ou paramètre est affecté.

En pratique, Config Studio s’adapte bien à trois situations :

• Comparez deux configurations avant et après une fenêtre de maintenance.
• Rendre une configuration de pare-feu existante plus lisible pour examen, transfert ou audit.
• Préparer les modifications avant de les implémenter sur un pare-feu de production.

Cependant, Config Studio ne remplace pas une sauvegarde, un processus de modification ou un test. C’est un outil d’analyse et de préparation. Les modifications doivent continuer à être vérifiées de manière contrôlée, documentées et sécurisées avec un plan de restauration.

Guide vidéo

Ce que Config Studio peut faire

Config Studio est le successeur ou l’évolution de l’ancien Sophos Firewall Configuration Viewer. Pour l’exploitation, trois fonctions sont surtout importantes :

La valeur ajoutée la plus importante réside dans la comparaison. Si vous avez besoin de savoir ce qui a réellement changé après une mise à jour, une migration ou une modification, vous pouvez avancer beaucoup plus rapidement avec une différence visible qu’en lisant manuellement les fichiers de sauvegarde.

Quand utiliser Config Studio

Config Studio est particulièrement intéressant pour les modifications qui affectent plusieurs zones du pare-feu.

Exemples typiques :

• Migration de XG vers XGS.
• Restauration sur un autre matériel ou une appliance virtuelle.
• Révision d’un large ensemble de règles de pare-feu.
• Comparaison avant et après une mise à jour du firmware.
• Test après une conversion majeure NAT ou VPN.
• Remise d’un pare-feu d’une équipe à une autre.
• Analyse après un changement imprévu.

Lorsqu’il s’agit d’une seule connexion en direct, d’autres outils sont généralement plus directs. Log Viewer, Policy Test et Packet Capture sont mieux adaptés aux problèmes de circulation. L’article Test de la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture montre ce processus.

Faites une sauvegarde propre au préalable

Config Studio fonctionne avec les données de configuration. Par conséquent, une sauvegarde complète et à jour du pare-feu doit d’abord être créée.

Le chemin WebAdmin est :

Backup & Firmware > Backup & Restore

Ce processus est recommandé pour un travail productif :

1. Créez une sauvegarde actuelle du pare-feu.
2. Stockez la sauvegarde en toute sécurité en dehors du pare-feu.
3. Si un changement est prévu, documentez également l’état cible souhaité.
4. Créez une deuxième sauvegarde après la modification.
5. Comparez les deux configurations dans Config Studio.

Le sujet réel de sauvegarde et de restauration est décrit dans l’article Sophos Firewall Créer ou restaurer une sauvegarde. Secure Storage Master Key, la compatibilité de restauration et le mappage d’interface y sont également répertoriés.

⚠️ Les sauvegardes du pare-feu contiennent des informations sensibles sur la structure du réseau, les règles, les objets, les VPN et les services. Avant d’utiliser un outil d’analyse, il convient de savoir clairement en interne où le fichier sera traité, qui y a accès et comment il sera ensuite supprimé ou archivé.

Traitez Entities.xml en toute sécurité

Config Studio fonctionne avec la configuration exportée. Le traitement s’effectue dans le navigateur de l’appareil ; les données de configuration ne sont pas téléversées vers un service externe. Le fichier reste néanmoins sensible, car il décrit très précisément la structure du pare-feu.

Pour l’exploitation, il faut donc planifier non seulement le téléchargement du fichier, mais aussi la manipulation ultérieure :

• Ouvrez le fichier uniquement sur un appareil administrateur de confiance.
• Ne partagez pas le fichier via un stockage cloud privé, des messageries ou des listes de distribution de courrier électronique non contrôlées.
• Limiter l’accès aux participants au changement, à l’audit ou à la migration.
• Supprimez le fichier une fois l’analyse terminée ou archivez-le dans un emplacement de stockage défini et protégé.
• Lors de la transmission au support ou à des partenaires externes, précisez d’abord quelles données sont incluses et si elles sont approuvées.

Une convention de dénomination simple est particulièrement utile pour les audits et les migrations. Exemple : firewall-standort-vor-change-2026-06-21.xml et firewall-standort-nach-change-2026-06-21.xml. Cela permettra plus tard de préciser quel fichier représente quel état et s’il a été créé avant ou après une fenêtre de maintenance.

Vérifier la configuration sous forme de rapport

Le rapport de configuration permet de lire un pare-feu de manière structurée. Ceci est particulièrement utile lors de la reprise d’un environnement existant ou lorsque vous avez besoin de comprendre quelles règles et quels objets sont en place avant un audit.

Lors de la révision, vous ne devriez pas simplement rechercher « beaucoup de règles ». Les questions opérationnelles spécifiques sont plus importantes :

• Existe-t-il des règles avec des sources, des cibles ou des services très larges ?
• Les anciennes règles VPN, NAT ou WAF sont-elles toujours actives ?
• Y a-t-il des objets qui portent plusieurs fois des noms similaires ?
• Les accès de gestion sont-ils strictement limités à vos propres réseaux ?
• La journalisation, IPS, la protection Web, TLS Inspection ou NDR sont-elles délibérément définies ?
• Les groupes de règles, les noms et les descriptions correspondent-ils aux opérations réelles ?

Pour l’accès à la gestion, vous devez également vérifier Device Access configurer correctement. Les règles normales de pare-feu ne contrôlent pas qui peut accéder aux services locaux du pare-feu tels que le portail WebAdmin, SSH, User Portal ou VPN.

Comparez deux configurations

La comparaison est le cas d’utilisation le plus important de Config Studio. Vous chargez deux versions de configuration, puis vérifiez quelles entrées ont été ajoutées, supprimées ou modifiées.

Les paires de comparaison utiles sont :

La comparaison ne remplace pas le Audit Trail. Config Studio montre ce qui est différent entre deux configurations. Le Audit Trail permet de savoir qui a effectué quelle modification et quand. Dans une analyse propre, vous utilisez les deux : limitez d’abord la période de temps et les responsables à l’aide de journaux d’audit, puis vérifiez en détail la différence de configuration.

Classer le résultat de la différence

Une comparaison de configuration n’est utile que si le résultat est trié. Tous les changements ne sont pas techniquement pertinents, et tous les changements manquants ne sont pas automatiquement non critiques.

Lors de la révision, vous devez trier les différences en groupes :

Les modifications apportées aux règles de pare-feu, aux règles NAT, aux interfaces, aux VPN, aux certificats, à l’authentification, à Device Access ainsi qu’aux hôtes et services sont particulièrement importantes. Dans ces domaines, une petite différence peut influencer directement si un service reste accessible, si un tunnel VPN est acheminé ou si l’accès administrateur est possible depuis le bon réseau.

Pour des révisions de modifications productives, vous ne devez pas simplement enregistrer le résultat de Config Studio. Une courte note est utile : fichiers de sauvegarde vérifiés, objets visibles, modifications attendues, modifications inattendues, questions ouvertes et décision quant à savoir si la modification est terminée ou doit être retravaillée.

Préparer les modifications

Config Studio peut également modifier des configurations ou apporter des modifications au format API ou curl. Ceci est puissant, mais ne doit pas être considéré comme un raccourci pour des changements massifs non testés. Si ces exportations sont utilisées de manière productive, l’accès à XML API doit être correctement restreint.

Les modifications préparées doivent passer au moins par ces points de contrôle :

1. Préparez les modifications dans Config Studio.
2. Vérifiez les objets, règles et dépendances concernés.
3. Si possible, validez la modification dans un environnement de test ou de remplacement.
4. Préparez un plan de sauvegarde et de restauration pour le pare-feu de production.
5. Appliquez les modifications dans la fenêtre de maintenance.
6. Vérifiez ensuite Log Viewer, les services concernés et la comparaison de la configuration.

Vous devez être particulièrement prudent avec les configurations NAT, VPN, Interfaces, Device Access, Authentification et HA. Une différence apparemment minime peut avoir un impact direct sur l’accessibilité ou le comportement de basculement.

⚠️ La sortie de l’éditeur de Config Studio ne doit jamais être copiée directement du navigateur vers un pare-feu de production sans vérifier les dépendances, sauvegarder, tester et restaurer. Cela est particulièrement vrai pour les modifications massives apportées aux objets, aux règles, aux VPN et aux interfaces.

Utilisation dans les migrations

Config Studio est un bon outil pour les migrations, mais pas la première étape. Vous devez d’abord vérifier si la sauvegarde correspond à la plate-forme cible.

Questions importantes :

• Est-ce que la migration de XG vers XGS ?
• Le nombre ou l’ordre des interfaces change-t-il ?
• Allez-vous passer du matériel au virtuel ou au cloud ?
• Un cluster HA est-il impliqué ?
• Un mappage d’interface doit-il être ajusté après la restauration ?
• Existe-t-il d’anciennes configurations VPN, RED, sans fil ou héritées ?

Config Studio doit être inséré au bon endroit dans cet ordre. Il montre les différences et facilite la révision, mais ne décide pas à lui seul si une restauration est techniquement prise en charge ou si le nouveau pare-feu fonctionne réellement correctement après la migration.

Une sensation d’intestin vert après l’importation ne suffit pas pour être accepté. Vous devez définir à l’avance quels services doivent fonctionner après la migration, quelles règles sont critiques et quels points de mesure sont vérifiés. Cela inclut au moins Log Viewer, Policy Test, Packet Capture, les journaux centraux et les tests utilisateur ou site les plus importants.

Pour les projets XG vers XGS, Quelle est la différence entre un pare-feu XG et XGS ? convient également. Si un cluster HA est en jeu, Sophos Firewall Configurer la haute disponibilité doit également être pris en compte avant la restauration.

Dépannage des analyses de Config Studio

L’importation ne fonctionne pas

Si Config Studio ne parvient pas à charger un fichier, vous devez d’abord vérifier si le bon fichier d’exportation a été réellement utilisé. Pour Config Studio, le Entities.xml de Backup & Firmware > Import export est pertinent, et non une sauvegarde compressée ou une capture d’écran du pare-feu.

Vérifiez également :

• Le fichier a été complètement téléchargé.
• Le navigateur ne bloque pas les fichiers locaux ou les fonctions JavaScript.
• Le fichier provient d’une version du pare-feu Sophos prise en charge.
• L’exportation n’a pas été éditée manuellement par la suite.

Diff contient beaucoup de changements

De nombreuses différences ne signifient pas automatiquement qu’un changement était mauvais. Des modifications liées au système peuvent survenir lors de mises à jour du micrologiciel, de migrations ou de tests de restauration. Ce qui est crucial est de savoir si les domaines techniquement pertinents sont plausibles : règles, NAT, interfaces, VPN, certificats, authentification, hôtes et services et Device Access.

Si la comparaison devient confuse, vous devez d’abord filtrer par module et ne pas tout évaluer en même temps. Pour les perturbations après une modification, la combinaison de Config Studio, Audit Trail, Log Viewer et Packet Capture est souvent plus rapide qu’un examen manuel complet de tous les objets.

L’exportation de l’éditeur ne correspond pas à l’importation prévue

Si une exportation préparée ne répond pas aux attentes, le changement ne doit pas être importé de manière productive et improvisée. Vérifiez d’abord :

• La configuration initiale correcte a-t-elle été utilisée ?
• Y a-t-il des objets dépendants qui manquent dans le système cible ?
• Les noms, zones, interfaces et services correspondent-ils au pare-feu cible ?
• L’accès à XML API est-il autorisé et suffisamment limité pour le compte utilisé ?
• Existe-t-il une sauvegarde actuelle et un chemin de retour ?

Pour les sorties API ou curl, la vérification du compte API, de l’adresse IP source et des droits fait partie du changement. L’article Sophos Firewall XML API Sécurisation de l’accès décrit cette partie plus en détail.

Erreurs typiques

Liste de contrôle pour les administrateurs

Avant utilisation :

• Créer une sauvegarde actuelle.
• Réguler l’accès aux fichiers de sauvegarde en interne.
• Traitez Entities.xml uniquement sur un appareil administrateur de confiance.
• Définir l’objectif de l’analyse : audit, migration, revue des modifications ou dépannage.
• Préparer les horaires pertinents et changer les billets.

En comparant :

• Sélectionnez les versions de sauvegarde correctes.
• Vérifiez séparément les entrées ajoutées, supprimées et modifiées.
• Portez une attention particulière aux règles de pare-feu, NAT, Interfaces, Hôtes et services, VPN et Device Access.
• Comparez tout changement notable avec configuration-audit.log.
• Documenter les changements inattendus et les attribuer à une personne responsable.

Après analyse :

• Documenter le résultat.
• Clarifier les différences inattendues.
• Enregistrez un nouvel état de sauvegarde pour des modifications productives.
• Si une restauration ou une importation est prévue, définissez au préalable la fenêtre de restauration et de maintenance.

FAQ