Créer ou restaurer une sauvegarde Sophos Firewall

Une sauvegarde Sophos Firewall est plus qu’un simple fichier pour les urgences. Elle est la base pour les mises à jour du firmware, le remplacement de matériel, les migrations de XG à XGS, le reimage, les travaux HA et les processus de récupération propres. Si la sauvegarde, la clé maître de stockage sécurisé et la compatibilité de restauration ne sont pas préparées, un changement planifié peut rapidement se transformer en une interruption inutilement longue.

Cet article explique comment créer et restaurer des sauvegardes Sophos Firewall, quelles informations supplémentaires doivent être documentées et quels contrôles sont importants avant une restauration sur un autre matériel ou plateforme.

⚠️ Important : Une sauvegarde n’est utile que si elle est localisable, déchiffrable et compatible avec l’environnement cible. Avant les mises à jour du firmware, le reimage, les modifications HA ou les migrations, il est essentiel de vérifier consciemment le fichier de sauvegarde, le mot de passe de sauvegarde, la clé maître de stockage sécurisé, la version cible et le processus de restauration.

Guide vidéo

Quel chemin de récupération convient ?

La sauvegarde et la restauration ne sont souvent qu’une partie du problème. Selon la situation, une autre procédure peut être plus appropriée :

En pratique, ces processus se chevauchent. Avant un reimage, une sauvegarde est presque toujours nécessaire. Avant un cas de support, le numéro de série, la version du firmware, les journaux et les étapes précédentes sont importants. Après une mise à jour contrôlée par Central, la file d’attente des tâches peut expliquer pourquoi une modification n’est pas encore arrivée sur le pare-feu.

Pourquoi une sauvegarde seule ne suffit pas

Une sauvegarde téléchargée réduit le risque, mais ne résout pas automatiquement tous les problèmes de récupération. En pratique, il faut également :

• un emplacement de stockage sécurisé en dehors du pare-feu
• une attribution claire au pare-feu, au numéro de série, à l’emplacement et à la version SFOS
• la clé maître de stockage sécurisé (SSMK) appropriée
• le mot de passe de sauvegarde, si la sauvegarde a été chiffrée
• des informations documentées sur le WAN, le VLAN, le HA, le VPN et les licences
• un plan de restauration vérifié pour le remplacement de matériel, le reimage ou la migration

Surtout avant une mise à jour du firmware, un reimage via clé USB ou un contrôle de mise à niveau SFOS 22, la sauvegarde ne doit pas seulement être créée, mais aussi vérifiée techniquement.

Avant la première sauvegarde : vérifier la clé maître de stockage sécurisé

Avant d’utiliser des sauvegardes chiffrées en production, la clé maître de stockage sécurisé (SSMK) doit être définie et documentée en toute sécurité. Sans cette clé, une restauration sur un nouvel appareil ou dans certains scénarios de récupération peut échouer.

Cela est particulièrement pertinent lorsque :

• un pare-feu de remplacement est préparé
• une migration vers un autre modèle est prévue
• les configurations sont déplacées entre matériel, appliance virtuelle et cloud
• les sauvegardes sont stockées en dehors du pare-feu

Le SSMK doit être placé dans un gestionnaire de mots de passe ou une autre procédure de récupération sécurisée. Il ne doit pas être connu d’une seule personne. Si la clé est recherchée uniquement en cas d’urgence, un temps précieux de récupération est déjà perdu.

Créer une sauvegarde : manuelle et automatique

Le chemin WebAdmin est :

Backup & Firmware > Backup & Restore

Sauvegarde manuelle avant les changements

Pour une sauvegarde immédiate, utilisez Backup Now. La sauvegarde ne doit pas rester uniquement dans le dossier de téléchargement du navigateur, mais être consciemment stockée.

Avant ces travaux, une sauvegarde manuelle doit toujours être créée :

• Mise à jour du firmware ou correctif avec risque de redémarrage ou de changement de comportement
• Modification d’interface, VLAN, routage, SD-WAN ou VPN
• Configuration HA, changement de rôle HA ou maintenance HA
• Modification majeure des règles NAT, WAF ou de pare-feu
• Reimage, réinitialisation d’usine ou remplacement de matériel
• Migration de XG à XGS, de matériel à virtuel ou de virtuel à cloud

Après le téléchargement, il est conseillé de documenter au moins la date, le nom du pare-feu, le numéro de série, la version SFOS et l’objectif de la sauvegarde. Pour des modifications majeures, une comparaison avec Sophos Firewall Config Studio peut aider à comprendre les différences de configuration avant et après le changement.

Configurer des sauvegardes automatiques

Pour éviter d’oublier les sauvegardes, une sauvegarde automatique doit être configurée. Sous Frequency, vous pouvez définir des sauvegardes quotidiennes, hebdomadaires ou mensuelles.

Les sauvegardes générées automatiquement peuvent être stockées localement sur le pare-feu, sur un serveur FTP ou par e-mail. L’emplacement de stockage est moins important que le processus autour :

• Ceux qui stockent des sauvegardes par e-mail ou sur un serveur externe doivent vérifier le chiffrement et la protection d’accès.
• Les sauvegardes locales sur le pare-feu ne sont pas utiles si l’appareil doit être entièrement remplacé ou réinstallé.
• Les sauvegardes Central sont pratiques, mais ne doivent pas être le seul chemin de récupération connu.
• Les sauvegardes automatiques ne remplacent pas une sauvegarde manuelle juste avant des modifications risquées.
• Les anciennes sauvegardes doivent être gérées avec une politique de conservation, d’accès et de suppression.

Si le pare-feu est connecté à Sophos Central, le stockage centralisé des sauvegardes de configuration peut également être utile. La connexion Central est décrite dans l’article Connecter Sophos Firewall à Sophos Central.

Stocker la sauvegarde en toute sécurité

Les sauvegardes de pare-feu contiennent des informations sensibles sur la structure du réseau, les objets, les règles, les services, les VPN, les certificats et parfois des données de compte protégées. Elles doivent donc être traitées comme des fichiers d’infrastructure confidentiels.

Pour l’exploitation, ces règles sont utiles :

• Ne pas stocker les fichiers de sauvegarde non chiffrés dans des dossiers d’équipe généraux.
• Limiter l’accès aux sauvegardes de pare-feu aux administrateurs et aux responsables de la récupération.
• Documenter séparément le mot de passe de sauvegarde et le SSMK, mais de manière accessible.
• Utiliser une convention de nommage claire par site ou pare-feu.
• Après le départ d’un administrateur, vérifier si le stockage des sauvegardes et l’accès au gestionnaire de mots de passe sont toujours appropriés.
• Documenter séparément les informations pertinentes pour la restauration telles que les données d’accès WAN, PPPoE, les données statiques du fournisseur ou l’occupation des ports HA.

Une sauvegarde n’est pas un substitut à la documentation opérationnelle. Surtout pour les clusters HA, plusieurs liaisons WAN ou des environnements VPN complexes, il doit également être documenté quelles interfaces, données de fournisseur et dépendances doivent être vérifiées en premier après une restauration.

Préparer un paquet de récupération par pare-feu

En cas d’urgence, on perd le plus de temps non pas à télécharger le fichier de sauvegarde, mais à rechercher les informations supplémentaires. Pour les pare-feux en production, un petit paquet de récupération devrait donc exister par site ou client.

Ce paquet ne doit pas être une simple fichier texte non protégé à côté de la sauvegarde. Une combinaison de gestionnaire de mots de passe, de documentation opérationnelle interne et de responsabilité claire est préférable. Au moins deux personnes autorisées devraient savoir où se trouvent ces informations et comment y accéder en cas d’urgence.

Après un changement de personnel, une réorganisation du site, un changement de fournisseur, une modification HA ou une grande migration, le paquet de récupération doit être vérifié. Une sauvegarde formellement à jour est peu utile si l’IP WAN documentée, l’occupation des ports ou l’attribution Central ne sont plus correctes.

Préparer la restauration

Avant une restauration, il faut d’abord clarifier quel est l’objectif poursuivi. Une restauration sur le même appareil après une mauvaise configuration est différente d’une restauration après un reimage, un remplacement de matériel ou un changement de plateforme.

Préparation :

• Une sauvegarde récente de l’état actuel est-elle disponible ?
• Le fichier de sauvegarde est-il clairement attribué au bon pare-feu ?
• Le mot de passe de sauvegarde et le SSMK sont-ils disponibles ?
• La version SFOS du système cible correspond-elle à la sauvegarde ?
• Le chemin de restauration est-il approuvé pour la version source, la version cible et la plateforme cible ?
• La restauration se fait-elle sur le même matériel, un autre modèle, une appliance virtuelle ou un cloud ?
• L’assistant de restauration de sauvegarde apparaîtra-t-il ou un mappage automatique des interfaces sera-t-il effectué ?
• Le HA est-il impliqué ou une sauvegarde HA est-elle restaurée sur une appliance unique ?
• Y a-t-il un accès de gestion local si le WAN, le VPN ou Central ne fonctionne pas immédiatement après la restauration ?

⚠️ Une restauration écrase la configuration actuelle. Sur un pare-feu en production, il est conseillé de créer une nouvelle sauvegarde de l’état actuel avant la restauration, même si la configuration actuelle est incorrecte. Pour les chemins de migration non pris en charge, le pare-feu peut démarrer avec une configuration d’usine après confirmation. Cet avertissement ne doit pas être traité comme un message de restauration normal et confirmé.

Planifier un test de restauration sans risque pour la production

Un test de restauration est utile, mais ne doit pas être effectué à la légère sur un pare-feu en production. L’objectif n’est pas de remplacer régulièrement les appliances en production, mais de vérifier de manière démontrable si les principales conditions de récupération fonctionnent.

Un test de restauration sécurisé peut ressembler à ceci selon l’environnement :

• Récupérer le fichier de sauvegarde de l’emplacement prévu.
• Vérifier le nom du fichier, la date, le nom du pare-feu, le numéro de série et la version SFOS.
• Contrôler le mot de passe de sauvegarde et le SSMK dans le gestionnaire de mots de passe.
• Effectuer un contrôle de compatibilité de restauration de sauvegarde pour le modèle cible prévu.
• Documenter le mappage des interfaces et les écarts de ports avant une migration.
• Vérifier la version cible par rapport aux chemins de mise à niveau et de restauration de sauvegarde pris en charge.
• Tester dans un laboratoire ou un pare-feu de remplacement si la sauvegarde est fondamentalement acceptée.
• Après un test de restauration, ne pas laisser les VPN, les accès WAN ou les connexions Central actifs sans contrôle.

Si aucun laboratoire ou pare-feu de remplacement n’est disponible, un test organisationnel reste possible : trouver la sauvegarde, vérifier l’accès, confirmer le mot de passe/SSMK, évaluer la plateforme cible avec le contrôle de compatibilité et simuler le processus dans le manuel de récupération. Cela ne remplace pas une véritable restauration, mais prévient de nombreux problèmes classiques d’urgence.

Pour les sites critiques, il doit également être clair comment le pare-feu sera à nouveau accessible après un reimage ou un remplacement de matériel : accès local, port de gestion, données WAN, statut de la licence, attribution Sophos Central et contact sur place. Ces informations ne doivent pas seulement figurer dans la sauvegarde, mais dans une documentation opérationnelle séparée.

Restaurer la sauvegarde

La restauration se fait également sous :

Backup & Firmware > Backup & Restore

Procédure de base :

1. Accéder au pare-feu cible via WebAdmin.
2. Sauvegarder l’état actuel, si possible.
3. Sélectionner le fichier de sauvegarde.
4. Démarrer Upload and Restore.
5. Si nécessaire, entrer le mot de passe de sauvegarde ou le SSMK.
6. Attendre le redémarrage et la restauration.
7. Ensuite, vérifier le réseau, les services, le VPN, le HA et la connexion Central.

Lorsqu’un nouveau Sophos Firewall ou un pare-feu de remplacement est déployé, la sauvegarde peut être appliquée après le premier accès à l’appliance. L’adresse IP initiale et le premier accès dépendent du modèle et du type de déploiement. Pour les appliances matérielles, l’accès initial local via l’IP de gestion par défaut ou l’assistant de configuration est courant.

Une fois le pare-feu accessible et l’assistant de configuration terminé, la restauration peut être effectuée comme décrit ci-dessus.

Restauration sur un autre matériel ou d’autres plateformes

Surtout lors des migrations entre XG et XGS ou entre matériel, appliance virtuelle et cloud, il est important de vérifier avant la restauration si la sauvegarde est compatible. Sophos propose un contrôle de compatibilité de restauration de sauvegarde public pour cela.

De plus, la version cible doit être appropriée. Sophos distingue les chemins de mise à niveau et de restauration de sauvegarde approuvés et les migrations non approuvées. Si un pare-feu avertit avant le redémarrage que la migration prévue n’est pas prise en charge, il ne faut pas simplement confirmer. Après une migration non approuvée confirmée, le pare-feu peut démarrer avec une configuration d’usine, ce qui entraîne la perte de la configuration actuelle.

Pour une restauration productive, cela signifie :

• noter d’abord la version source, la version cible, le modèle cible et la plateforme
• amener le pare-feu cible à une version SFOS prise en charge avant la restauration
• effectuer un contrôle de compatibilité de restauration de sauvegarde pour la combinaison spécifique
• prendre au sérieux et documenter les avertissements dans le dialogue de restauration ou de mise à niveau
• en cas de doute, tester d’abord sur du matériel de remplacement ou dans un environnement de test

Assistant de restauration de sauvegarde et mappage automatique des interfaces

Pour les sauvegardes des versions SFOS plus récentes, l’assistant de restauration de sauvegarde apparaît selon la plateforme cible. Il aide à attribuer les interfaces lorsqu’une sauvegarde de XG, SG avec SFOS ou XGS est restaurée sur une série XGS, une appliance virtuelle ou un pare-feu cloud. Cela est particulièrement important si le pare-feu cible a moins de ports, des noms de ports différents, des variantes sans fil ou des modules Flexi-Port.

Pour les sauvegardes très anciennes, l’assistant peut manquer. Dans ce cas, le pare-feu attribue automatiquement les interfaces. C’est plus rapide, mais plus risqué, car l’attribution n’est pas consciemment confirmée dans l’assistant. Après une telle restauration, les interfaces, les zones, les passerelles, les VLAN, le lien HA, les routes SD-WAN, les règles NAT et les VPN doivent être vérifiés avec soin.

Il faut également faire attention à :

• Les ports disponibles et les types de zones correspondent-ils à la plateforme cible ?
• Les interfaces doivent-elles être réattribuées après la restauration ?
• Une sauvegarde HA est-elle restaurée sur une appliance unique ou inversement ?
• Le système cible est-il à un niveau de firmware raisonnable ?
• Une ancienne appliance XG ou SG doit-elle être remplacée en raison du cycle de vie ou de la compatibilité SFOS-22 ?
• Le statut de la licence, le numéro de série et l’attribution Sophos Central sont-ils clarifiés après la restauration ?

Si l’occupation des ports diffère, il faut généralement vérifier ou retravailler un mappage d’interface après la restauration. Avant les migrations de XG à XGS, l’article Quelle est la différence entre un pare-feu XG et XGS ? est également pertinent.

Après des travaux de restauration ou de migration majeurs, une comparaison des configurations peut aider. Utiliser Sophos Firewall Config Studio montre comment comparer les sauvegardes avant et après un changement et examiner les différences inattendues de manière ciblée.

Vérifier après la restauration

Après la restauration, il ne suffit pas de vérifier si le WebAdmin est accessible. Le pare-feu peut être accessible et traiter incorrectement des services importants.

Vérifier directement après la restauration :

• Interfaces, zones, VLAN, ponts, LAG et interfaces alias.
• Liaisons WAN, PPPoE, données statiques du fournisseur et passerelle par défaut.
• Routes SD-WAN, routes statiques et routage dynamique.
• Règles de pare-feu, règles NAT, règles WAF et ordre des règles.
• IPsec, SSL VPN, Sophos Connect, RED et accès distant.
• Certificats, certificats CA, certificat WebAdmin et inspection TLS.
• DNS, DHCP, NTP et serveur d’authentification.
• Statut HA, si un cluster est utilisé.
• Statut de la licence, mises à jour des modèles, correctifs et synchronisation Sophos Central.
• Journalisation, cibles Syslog, rapports de pare-feu Central et rapports locaux.

Pour l’examen technique, selon le problème, Log Viewer, Policy Test et Packet Capture, Packet Capture dans le WebAdmin et Services et journaux peuvent être utiles.

Test d’acceptation après une restauration

Une restauration n’est terminée que lorsque les principales fonctions opérationnelles ont été confirmées par de véritables tests. Un WebAdmin accessible ne prouve que la maniabilité du pare-feu. Il ne prouve pas que le routage, le NAT, le VPN, le WAF, l’authentification ou la journalisation fonctionnent à nouveau correctement.

Pour les pare-feux en production, il devrait donc y avoir une courte matrice d’acceptation. Cette matrice n’a pas besoin d’être compliquée, mais devrait définir par site quel test doit être effectué après une restauration et qui documente le résultat.

Il est important d’avoir un point d’arrêt défini. Si après une restauration des tests fondamentaux comme le WAN, le DNS, l’accès distant ou le HA ne fonctionnent pas, il ne faut pas corriger simultanément à plusieurs endroits. Il est préférable d’avoir un cas d’erreur étroit avec l’heure, la source du test, la cible, la règle affectée et l’extrait de journal. Cela permet de savoir si le problème provient de la sauvegarde, du mappage des interfaces, du matériel cible ou d’une modification ultérieure.

Erreurs typiques

Liste de vérification opérationnelle

Régulièrement :

• Activer les sauvegardes automatiques ou définir un processus de sauvegarde central.
• Vérifier le stockage, l’accès et la conservation des sauvegardes.
• Contrôler le SSMK et le mot de passe de sauvegarde dans le gestionnaire de mots de passe.
• Maintenir à jour le paquet de récupération par site ou pare-feu.
• Vérifier au moins par échantillonnage si les sauvegardes sont localisables et attribuables.

Avant des modifications majeures :

• Créer une sauvegarde manuelle et la stocker de manière externe.
• Documenter le nom du pare-feu, le numéro de série, la version SFOS et l’objectif du changement.
• Vérifier le SSMK, le mot de passe de sauvegarde et l’accès administrateur.
• Définir un plan de retour ou de restauration.
• Pour les migrations, vérifier le contrôle de compatibilité et le mappage des interfaces.
• Ne pas confirmer les avertissements concernant les chemins de restauration ou de migration non pris en charge avant qu’un plan alternatif ne soit en place.

Après une restauration :

• Tester les interfaces, le routage, le NAT, le VPN, le WAF, l’authentification et Central.
• Travailler sur la matrice d’acceptation avec de véritables sources de test, cibles de test et journaux attendus.
• Contrôler le statut et les rôles HA.
• Vérifier les journaux et la surveillance.
• Pour les versions cibles à partir de SFOS 22.0 MR1, vérifier à nouveau si une restauration ou un import a ramené d’anciennes configurations Legacy Remote Access IPsec.
• Créer une nouvelle sauvegarde de l’état cible restauré.
• Documenter les écarts et, si nécessaire, les comparer avec Config Studio.

FAQ