Préparer la reprise avant un changement de durcissement : accès console, sauvegarde, retour arrière automatique planifié et journal des modifications

Objectif

Faire en sorte qu'un changement de durcissement touchant le réseau, l'authentification ou le pare-feu s'annule de lui-même s'il prive l'opérateur de son accès, au lieu d'exiger un accès physique ou hors bande pour le réparer.

Prérequis

Un accès hors bande à l'hôte, indépendant du changement à effectuer (console série, IPMI ou hyperviseur, ou accès console du fournisseur cloud), dont l'accessibilité est vérifiée avant de commencer ; l'autorisation de planifier une tâche ponctuelle sur le système d'exploitation cible.

Étapes

1. Vérifier que l'accès hors bande fonctionne à l'instant même, avant de toucher à quoi que ce soit — et non « il fonctionnait le mois dernier ». Si l'accès console dépend lui-même du changement testé (par exemple parce que le changement affecte le bastion), préparer le changement depuis une session qui ne dépend pas de l'élément modifié.
2. Sauvegarder précisément ce qui va changer : le fichier de configuration, le jeu de règles de pare-feu ou l'export de GPO concerné, avec un horodatage dans le nom du fichier, et pas simplement « des sauvegardes récentes existent quelque part ».
3. Armer un retour arrière planifié et inconditionnel avant d'appliquer le changement risqué :
   • Linux, tâche ponctuelle et transitoire (en root) : systemd-run --unit=rollback-net --on-active=10min /usr/local/sbin/rollback-network.sh. Le minuteur --on-active= de systemd se déclenche relativement à l'instant présent, quel que soit le sort du shell courant ou de la session SSH ; la commande crée rollback-net.timer et rollback-net.service.
   • Linux, file d'attente classique : echo /usr/local/sbin/rollback-network.sh | at now + 10 minutes, avec at, documenté comme un outil permettant de « queue, examine, or delete jobs for later execution » (mettre en file, consulter ou supprimer des tâches à exécuter plus tard) — atq liste les tâches en attente, atrm en annule une une fois le succès confirmé. Le paquet at et un atd en cours d'exécution sont nécessaires ; ils sont absents de nombreuses installations minimales.
   • Windows : Register-ScheduledTask avec un déclencheur construit par New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10), exécutant un script de retour arrière sous un principal indépendant du changement, par exemple New-ScheduledTaskPrincipal -UserId SYSTEM -RunLevel Highest.
4. Appliquer le changement de durcissement.
5. Confirmer le succès par le canal qui sera utilisé par la suite (et pas seulement dans la session actuelle, qui peut rester valide par exception). Si c'est confirmé, annuler le retour arrière planifié (atrm <job>, systemctl stop rollback-net.timer ou Unregister-ScheduledTask -TaskName <name> -Confirm:$false) et vérifier qu'il a bien disparu (atq, systemctl list-timers, Get-ScheduledTask).
6. Consigner dans un journal des modifications le changement, son horodatage, l'emplacement de la sauvegarde et l'identifiant de la tâche de retour arrière avant de passer à la tâche suivante : c'est ce qui permettra de relier un incident ultérieur à une action précise et datée.

Résultat attendu

Si le changement casse le chemin d'accès utilisé, la tâche planifiée se déclenche sans intervention et restaure la configuration précédente dans le délai choisi ; si le changement réussit, le retour arrière est annulé et ne se déclenche jamais.

Limites et base de vérification

Un retour arrière planifié n'est utile que si le script de retour arrière est lui-même correct et a été testé avec le format de sauvegarde précis produit à l'étape 2 — tester ce script au moins une fois dans une fenêtre hors production. Le comportement au redémarrage varie : un minuteur transitoire systemd-run est perdu au redémarrage, de sorte qu'un changement qui ne prend effet qu'après un redémarrage n'est pas couvert ; les tâches at sont conservées dans le répertoire de spool et survivent à un redémarrage, si bien qu'un retour arrière en retard peut encore s'exécuter dès que atd redémarre ; une tâche planifiée Windows persiste jusqu'à ce qu'elle soit supprimée. Si une tâche semble ne pas s'être déclenchée, vérifier l'état de atd, de systemd ou du Planificateur de tâches. Aucune de ces étapes n'exige à elle seule un redémarrage.