Continuité et récupération : la restauration que personne n'a testée

Chaque tableau de bord de sauvegarde affiche des coches vertes. Les tâches sont terminées, la politique de rétention satisfaite, le stockage utilisé comme prévu. Rien de tout cela ne vous dit si vous pouvez ramener un contrôleur de domaine à partir d'une installation vierge en moins de quatre heures lors d'un incident réel. L'écart entre « la sauvegarde a réussi » et « la restauration a réussi » est l'endroit où la plupart des plans de continuité échouent silencieusement.

Pourquoi la coche ment

Le logiciel de sauvegarde signale le succès quand il finit d'écrire des octets vers une destination. Il ne sait pas si ces octets sont utilisables. Une sauvegarde SQL Server peut se terminer correctement et rester non restaurable parce que la chaîne du journal des transactions s'est brisée trois jours plus tôt et personne ne l'a remarqué. Les snapshots de machines virtuelles peuvent sembler corrects dans la console tandis que l'écrivain VSS sous-jacent a silencieusement échoué à l'intérieur du système d'exploitation invité, produisant une image cohérente au niveau du crash (et non au niveau de l'application).

Les opérateurs de ransomware le savent. Les groupes exécutant des playbooks de style Conti dans les incidents passés ont délibérément ciblé l'infrastructure de sauvegarde — supprimant les copies fantômes avec vssadmin delete shadows /all /quiet, désactivant les référentiels Veeam, chiffrant les cibles de sauvegarde basées sur NAS accessibles via SMB. Si vos sauvegardes se trouvent sur le même segment réseau que la production avec des identifiants de domaine qui peuvent les modifier, elles sont une cible, pas un filet de sécurité.

Construisez un livret de restauration, pas une politique de sauvegarde

Un plan de continuité a besoin d'instructions de restauration étape par étape écrites pour quelqu'un qui n'est pas la personne qui le fait normalement. Notez:

• Ordre de récupération exact (contrôleurs de domaine et DNS d'abord, puis applications principales, puis tout le reste)
• Où vivent les identifiants pour la console de sauvegarde si votre coffre-fort de mots de passe est également hors ligne
• La commande de restauration spécifique ou le chemin de la console, pas « utiliser Veeam pour restaurer la machine virtuelle »
• Durée prévue par système, basée sur des tests réels mesurés, pas sur les chiffres marketing des fournisseurs

Pour Veeam Backup & Replication, cela signifie documenter les étapes réelles : ouvrir la console, naviguer vers Backups > Disk, clic droit sur le point de restauration, choisir Instant VM Recovery ou Full VM Restore selon le scénario, et sélectionner l'hôte cible avec suffisamment de capacité libre. Si votre hôte principal est également compromis, vous avez besoin d'un second hôte isolé déjà identifié et sous licence.

Testez les restaurations selon un calendrier, pas sur un coup de tête

Choisissez une rotation. Chaque mois, restaurez un système critique vers un VLAN isolé et validez qu'il démarre, s'authentifie et sert les données correctement. Chaque trimestre, exécutez un test d'envergure complète : restaurez votre contrôleur de domaine, votre serveur de fichiers et votre base de données principale vers une infrastructure isolée, puis demandez à quelqu'un en dehors de l'équipe de sauvegarde de se connecter et de tirer un rapport.

Pour les bases de données, ne restaurez pas simplement le fichier .bak — vérifiez-le :

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

Puis restaurez-le réellement vers une instance de test et exécutez DBCC CHECKDB contre elle. Une sauvegarde qui réussit VERIFYONLY peut toujours contenir une corruption logique qui n'apparaît que lorsque vous l'interrogez.

Pour les systèmes Linux utilisant quelque chose comme Bacula ou restic, testez le chemin de restauration réel :

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Puis comparez les fichiers de configuration restaurés avec la production pour confirmer que rien n'a été silencieusement supprimé.

Copies immuables et la règle 3-2-1-1

La règle classique 3-2-1 (trois copies, deux types de médias, une hors site) a besoin d'une mise à jour pour l'ère du ransomware : 3-2-1-1, où le « 1 » supplémentaire est une copie immuable ou isolée. Object Lock sur un stockage compatible S3 (Wasabi, Backblaze B2, ou AWS S3 avec Object Lock activé) empêche la suppression ou la modification pendant une fenêtre de rétention définie, même par un compte avec des identifiants d'administrateur. Configurez-le avec :

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Le mode COMPLIANCE signifie que personne, y compris le compte root, ne peut raccourcir la rétention ou supprimer les objets plus tôt. Cela importe quand l'attaquant a l'accès administrateur du domaine.

Mesurez RTO et RPO avec des chiffres réels, pas des suppositions

Objectif de temps de récupération et objectif de point de récupération ressemblent à des exercices administratifs jusqu'à ce qu'un responsable demande « combien de données perdons-nous et combien de temps sommes-nous hors ligne. » Chronométrez vos trois dernières restaurations de test. Si votre objectif RPO est d'une heure mais que votre tâche de sauvegarde s'exécute seulement toutes les six heures, vous avez un écart documenté, et il est préférable de trouver cet écart dans un exercice sur table que pendant un événement de chiffrement réel à 2 h du matin un samedi.

Exécutez le test, notez l'heure d'horloge réelle, et comparez-la à ce que vous avez promis dans le document de reprise après sinistre. La différence entre ces deux chiffres est l'état réel de votre plan de continuité.

Pour en savoir plus sur le durcissement des systèmes que vous protégez et la construction de flux de réponse aux incidents, consultez les segments connexes Blue Team et Digital Forensics sur Korra Studio.