Backups & restauration réseau (jour‑2) : procédures minimales pour firewall/switch/Wi‑Fi controller

Illustration générée par IA — visuel conceptuel.

Objectif (exploitation « jour‑2 »)

En exploitation, un incident réseau n’est pas seulement une panne matérielle. C’est souvent une mauvaise manipulation, une mise à jour ratée, une dérive de configuration, ou une compromission qui impose un retour rapide à un état sain. L’objectif d’une procédure « backups & restauration » n’est donc pas de copier des fichiers, mais de garantir qu’une restauration complète et reproductible est possible, dans un délai compatible avec l’activité (hôtel, bureaux, site multi‑services).

Point clé : un backup non restauré en test reste une hypothèse.

Périmètre minimal à couvrir

Le périmètre doit rester pragmatique : on documente et on sauvegarde ce qui permet de rétablir le service. Le reste (dépendances, secrets, contrats opérateurs) est référencé dans le runbook.

Firewall / routeur edge

• Politiques de filtrage, NAT, objets/adresses, routage.
• VPN (site‑à‑site et accès distant), profils et politiques de sécurité.
• Certificats (si gérés par l’équipement) et paramètres associés.
• Comptes et rôles d’administration (sans exposer les mots de passe dans le DOE).

Switches (cœur, distribution, accès)

• VLAN, trunks, routage L3 (si applicable), ACL, policies.
• Spanning‑Tree / protections L2, agrégations (LACP), uplinks.
• PoE (politiques, priorités), ports critiques.

Contrôleur Wi‑Fi / plateforme de management

• SSID, sécurité, mapping VLAN, portail captif (si utilisé), RADIUS/802.1X (si utilisé).
• Templates et paramètres d’adoption des points d’accès.
• Certificats et identités (quand la solution en dépend).

Dépendances « invisibles » à référencer dans le runbook

Ces briques ne sont pas toujours dans le lot « réseau » (ou ne sont pas toujours sauvegardées au même endroit), mais elles conditionnent le retour en service : DNS/DHCP, NTP, AAA/RADIUS, portail captif, supervision/collecte de logs, bastion/VPN, etc. Sur un hôtel, cette cartographie s’inscrit dans une approche globale de convergence (Wi‑Fi, IPTV, VoIP, CCTV, GRMS). Vous pouvez recouper avec notre article Architecture réseau IP d’un hôtel : comment faire cohabiter Wi‑Fi, IPTV, VoIP, CCTV et GRMS ?.

Règles d’or (pragmatiques) : ce qui évite les mauvaises surprises

1) Distinguer « backup » et « restauration exacte »

Selon les constructeurs, certaines actions « rechargent » une configuration en la fusionnant avec l’existant, alors que l’exploitation attend souvent un remplacement strict (retour à l’état de référence). Cela doit être écrit dans le runbook, par famille d’équipement, avec une procédure validée.

2) Versionner (rotation) et indexer

Conservez plusieurs versions et, surtout, un index exploitable : quel fichier correspond à quel équipement, à quel site, à quelle version logicielle/firmware, et à quel changement. Sans cet index, on « a des backups » mais on ne sait pas lequel restaurer.

3) Anticiper les compatibilités modèle/plateforme/firmware

Une restauration peut être limitée par des contraintes de modèle ou de version. Par exemple, certains éditeurs documentent des limitations de restauration « inter‑plateformes » ou recommandent d’identifier explicitement la version firmware dans le nom du backup. Ces contraintes ne doivent pas être découvertes pendant un incident.

4) Traiter les backups comme des actifs sensibles

Une archive de configuration révèle souvent la topologie, l’adressage, les règles de sécurité et parfois des secrets (selon les produits et options). Protégez donc ces archives comme un actif de cybersécurité : chiffrement, droits minimaux, traçabilité. Sur les établissements hôteliers, ce sujet se rattache directement à la gouvernance des accès et à la segmentation. Pour une lecture plus large, voir Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ? et VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

Runbook « backup & restore » : structure recommandée (prête à intégrer au DOE)

Un runbook utile n’est pas un texte générique : c’est un document actionnable en astreinte. La structure ci‑dessous vise un minimum réaliste.

1) Fiche d’identité (par site / par baie)

• Nom du site, périmètre (bâtiments, étages, zones techniques), plages d’intervention.
• Contacts d’escalade (exploitation, prestataires, opérateurs, supports éditeurs).
• Contraintes d’exploitation (fenêtres de maintenance, périodes à éviter).

2) Inventaire « restaurable » (table obligatoire)

Pour chaque équipement : rôle, modèle, numéro de série, version logicielle/firmware, IP de management, méthode de backup, emplacement des archives, et procédure de restauration (résumée + lien vers documentation constructeur).

3) Procédures normalisées (SOP) : backup et restore

• Procédure backup (quoi, comment, à quel moment, comment vérifier le fichier).
• Procédure restore (pré‑checks, étapes, post‑checks, et conditions de retour arrière).
• Pré‑requis : accès d’admin, serveur de stockage, compte « break‑glass » (si prévu), méthode d’accès distant (VPN/bastion).

4) Check‑list de validation « retour en service »

Prévoyez une check‑list orientée service (et pas seulement « ping OK ») : Internet/failover, VLAN critiques, Wi‑Fi (SSID + authentification), services métiers dépendants, journaux/supervision, etc. Pour structurer la supervision et rendre les alertes actionnables, voir aussi Supervision réseau : quels équipements et indicateurs faut-il réellement surveiller ?.

Rotation & stockage : un modèle minimal (à adapter au projet)

Il n’existe pas une seule « bonne » rotation : elle dépend de la criticité, du volume de changements, et de la capacité à restaurer rapidement. En revanche, la logique doit être explicite, documentée et testée.

Bon repère d’exploitation : s’inspirer d’une approche de type « 3‑2‑1 » (plusieurs copies, supports distincts, et au moins une copie hors site), en y ajoutant, quand c’est pertinent, une copie immuable (protection contre suppression/ransomware). Cette logique est notamment présentée dans une publication NCCoE/NIST sur la protection des données.

Nommage recommandé (exemple)

Adoptez un nommage qui évite les ambiguïtés :

• Site + rôle + modèle + numéro de série
• version firmware
• date/heure + éventuellement référence de ticket

Recommandation pratique : inclure la version firmware dans le nom aide à contrôler les compatibilités lorsque le constructeur les impose ou les recommande.

Coffre à secrets : séparer « configurations » et « identifiants »

Dans un DOE, on évite de disperser des mots de passe dans des PDF, des emails, ou des tableurs non maîtrisés. La bonne approche consiste à séparer :

• Les fichiers de configuration (exports, snapshots, backups) ;
• Les secrets d’exploitation (comptes admin, clés API, RADIUS shared secret, PSK VPN, certificats/keys, SNMP, etc.).

Un coffre à secrets (outil dédié ou mécanisme DSI) permet d’organiser les accès, la traçabilité, et parfois la gestion de versions. Par exemple, HashiCorp Vault propose un secrets engine « KV » ; dans sa version KV v2, Vault conserve un nombre configurable de versions d’un secret, et la commande vault kv rollback permet de revenir à une version précédente (si ce mode KV v2 fait partie de votre architecture et de vos procédures internes).

Attention : le coffre n’est pas « une obligation produit ». C’est une recommandation d’exploitation à cadrer avec la gouvernance du client (IT/RSSI/exploitant), et à recetter (accès nominal + procédure d’urgence « break‑glass »).

Tester la restauration : le protocole d’exercice (le seul moyen d’être sûr)

La recommandation NIST (SP 800‑209) insiste sur l’importance de procédures (SOP) de backup incluant le fait de tester périodiquement les backups et, selon les exigences de restauration, de réaliser un test end‑to‑end vers un environnement de test (sandbox).

Scénarios de test utiles (réseau hôtel / tertiaire)

• Restauration sur équipement « spare » (quand la compatibilité modèle/firmware l’exige).
• Restauration après factory reset (simulation réaliste « matériel remplacé »).
• Avant / après upgrade (snapshot pré‑upgrade + retour arrière documenté).

Preuve de test (livrable interne)

• Date/heure, opérateur, équipement, version firmware, fichier restauré.
• Étapes réalisées + temps de retour service (mesuré).
• Écarts constatés + actions correctives (ce qui change dans le runbook).

Exemples documentés (constructeurs) : points de vigilance à connaître

Les exemples ci‑dessous ne sont pas des « standards universels » : ils illustrent des mécanismes décrits dans des documentations éditeurs, utiles pour écrire un runbook concret selon les marques réellement déployées.

Cisco IOS / IOS‑XE : « merge » vs « restauration exacte »

La documentation Cisco précise que charger une configuration dans la running-config revient à appliquer des commandes (fusion, sans effacement complet). Pour une restauration « exacte », le principe documenté consiste à copier vers la startup-config puis redémarrer (reload) l’équipement.

ArubaOS (contrôleurs) : restauration via copie sur flash puis vers la configuration système

Le guide CLI ArubaOS documente une méthode de restauration qui passe par une copie du fichier sur la flash, puis une copie vers la configuration système, afin d’éviter d’écraser par erreur certains états.

Aruba AOS‑CX (switches) : copie de running‑config

La documentation AOS‑CX décrit la copie de la running configuration via plusieurs protocoles (SCP/SFTP/TFTP) ou support USB, ce qui se traduit en runbook par un export contrôlé, daté et associé à la version logicielle.

UniFi Network Application : sauvegarde/restore via backup « controller level »

La documentation « Cloud UniFi Support » décrit une migration/restauration via un backup (et précise notamment la différence entre un controller level backup et un export partiel selon les cas), ainsi que le fait que la restauration écrase la configuration existante sur la cible. Côté runbook, cela implique de documenter la méthode exacte et d’éviter une restauration « au hasard » pendant une crise.

Ruckus (ZoneDirector / SmartZone) : compatibilité et nommage

Des documentations Ruckus mentionnent des contraintes de restauration selon les plateformes, ainsi qu’une recommandation pratique d’inclure la version firmware dans le nom du fichier de backup. Ces points doivent être recopiés tels quels dans le runbook du site concerné, avec la procédure officielle du produit réellement installé.

Palo Alto Networks (PAN‑OS) : snapshot + export/import via SCP

La documentation PAN‑OS décrit une procédure de sauvegarde en « configuration snapshot » nommé, puis d’export/import via Secure Copy (SCP). En exploitation, cela donne une méthode claire pour tracer le bon fichier et le rejouer sur un équipement cible (si compatible).

Fortinet : restauration de backups chiffrés (exigences à vérifier selon version)

Fortinet publie des informations techniques (selon versions et contextes) dans Fortinet Community et dans des documents FortiOS Best Practices, indiquant que la restauration d’un backup chiffré peut imposer des contraintes strictes de modèle et de version (et nécessiter le mot de passe de chiffrement). Ce point doit être confirmé sur la version exacte du firewall en place, puis testé en exercice.

Recette « retour en service » : check‑list orientée hôtel

Une restauration réussie n’est pas « le firewall répond ». C’est un retour en service des flux critiques. Une check‑list simple, adaptée à la convergence d’un hôtel, couvre généralement :

• WAN principal + bascule (si présente) ;
• VLAN essentiels (invités, staff, administration, CCTV, GRMS/GTB…) ;
• DHCP/DNS (si dans le périmètre) ;
• Wi‑Fi invités : portail captif / isolation / accès Internet (si applicable). Voir Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.
• Wi‑Fi staff / métiers : accès aux services nécessaires, stabilité ;
• Logs (syslog) et supervision (alertes cohérentes après restauration) ;
• Validation par tests « service » (et pas uniquement ICMP), selon le niveau d’exigence du site.

Livrables : ce qu’il faut pouvoir remettre (et reprendre) proprement

Sur des projets hôteliers ou tertiaires, la maintenabilité dépend autant des fichiers que de la documentation d’exploitation. Deux livrables se complètent :

• DOE réseau (schémas, inventaire, exports, méthode de restauration) — voir Documentation réseau : quels schémas et sauvegardes remettre au client ?.
• Runbook jour‑2 (procédures, check‑lists, preuves de tests, scénarios de panne, escalade).

Sans runbook, le DOE reste « descriptif ». Sans DOE, le runbook devient vite incomplet et dépendant d’une seule personne.

Conclusion : le minimum vital, c’est « restaurer en confiance »

Pour sécuriser l’exploitation, concentrez-vous sur un socle simple : sauvegardes versionnées, stockage protégé, secrets gérés séparément, compatibilités explicitées, et tests de restauration avec preuves.

Si vous souhaitez cadrer ce sujet dans un établissement (hôtel, siège, site multi‑bâtiments), un audit « jour‑2 » (inventaire, runbook, exercice de restauration) permet généralement d’identifier rapidement les points de fragilité. Contactez-nous pour structurer une démarche proportionnée à vos risques et à vos contraintes d’exploitation.

Sources (sélection) utilisées pour les exemples documentés

• NIST SP 800‑209 (tests périodiques de backups et test end‑to‑end selon criticité)
• NCCoE/NIST – Protecting Data: Implementing a Data-Centric Approach (repères de protection des données ; approche de type 3‑2‑1 citée dans la publication)
• Cisco IOS‑XE – Managing Configuration Files
• ArubaOS CLI Guide – commande copy / restauration
• AOS‑CX – copy running-config
• Cloud UniFi Support – Move a UniFi controller using Backup and Restore
• Ruckus Support – SmartZone configuration backup restoration (plateformes)
• Ruckus – ZoneDirector backup (recommandation nommage)
• Palo Alto – SCP import/export
• Fortinet Community – Restoring a configuration file with a lower firmware version (pré‑requis de restauration, selon cas et versions)
• FortiOS – Best Practices (PDF) (repères migration/restauration selon versions)
• HashiCorp Vault – KV secrets engine
• HashiCorp Vault – Versioned KV (KV v2) (gestion de versions des secrets)
• HashiCorp Vault – commande kv rollback (KV v2) (retour à une version antérieure)