No Immutable or Air-Gapped Backup Copy

Toutes les copies de sauvegarde sont modifiables ou supprimables depuis le réseau, avec des privilèges suffisants : réplication en ligne vers un second site joignable, stockage accessible en écriture, rétention réglable par un administrateur. Il n’existe aucune copie dont la destruction exigerait autre chose que des privilèges volés — ni immuabilité technique (verrouillage en écriture non révocable pendant la rétention), ni déconnexion réelle.

C’est structurel : la sauvegarde est conçue contre la panne et l’erreur humaine — restaurer vite, restaurer souvent — et non contre un adversaire qui détient les privilèges d’administration. Ce sont deux modèles de menace différents que l’architecture confond. La règle des « trois copies, deux supports, une distante » est souvent satisfaite sur le papier… avec trois copies toutes joignables depuis le même plan d’administration.

Face à un rançongiciel opéré par un humain, les sauvegardes sont une cible primaire, traitée avant le chiffrement. Si toutes les copies sont atteignables, la capacité de restauration disparaît au moment exact où elle devient nécessaire.

C’est la variable qui sépare les deux issues d’un chiffrement massif : restauration en jours, ou reconstruction en semaines — avec, entre les deux, une négociation qui ne se poserait pas autrement, menée en position de faiblesse maximale puisque l’attaquant sait ce qu’il a détruit.

Deux nuances qui coûtent cher quand on les découvre tard :

• la copie survivante doit être antérieure à la compromission : une copie immuable de données déjà chiffrées ou piégées fige le problème, pas la solution ;
• elle doit être restaurable : un jeu jamais testé, un catalogue perdu, une durée de restauration jamais mesurée transforment la copie survivante en promesse.

Un exercice sur table d’une heure suffit, à condition de le jouer honnêtement : donner à l’adversaire hypothétique vos propres privilèges maximaux, et énumérer comment détruire chaque copie de sauvegarde. Si toutes les copies tombent, le pattern est présent.

Vérifications précises :

• le verrouillage d’immuabilité est-il réellement activé — pas seulement supporté par le produit — et sa durée couvre-t-elle un temps de séjour réaliste (semaines) ?
• l’immuabilité résiste-t-elle à l’administrateur du stockage lui-même, ou un compte suffisamment privilégié peut-il la lever ?
• la copie « hors ligne » est-elle réellement déconnectée, ou simplement « sur un autre réseau » joignable par rebond ?
• qui peut réduire la rétention, et cette opération est-elle possible seul, immédiatement, sans délai de grâce ?
• la dernière restauration d’essai depuis la copie protégée date de quand, et combien de temps a-t-elle pris ?

Établir au moins une copie hors d’atteinte des privilèges de production :

• stockage à immuabilité vérifiée — verrouillage en écriture non révocable pendant la durée de rétention, y compris par l’administrateur du stockage — ou copie réellement déconnectée, avec une rotation qui borne la fenêtre de perte acceptable ;
• dimensionner la durée d’immuabilité sur le temps de séjour : des semaines, pas des jours ;
• protéger le catalogue de sauvegarde au même niveau que les données : sans lui, les données existent mais la restauration devient une expédition ;
• tester périodiquement la restauration depuis cette copie : intégrité, complétude, durée — la durée mesurée devient une donnée d’entrée du plan de continuité, pas une découverte d’incident ;
• articuler avec la séparation du plan de confiance (voir MFL-003) : l’immuabilité borne l’impact, la séparation réduit la probabilité. Les deux se complètent, aucun ne remplace l’autre.

Si l’intrusion est détectée avant l’impact, la priorité absolue est de créer ce qui manque : une copie hors d’atteinte, maintenant — export vers un stockage déconnecté ou verrouillé, même partiel, en commençant par les données irremplaçables. Chaque heure compte : la destruction des sauvegardes précède le chiffrement, la fenêtre est courte.

Si la destruction a déjà eu lieu, inventorier avant de conclure :

• instantanés au niveau des baies de stockage, réplicas secondaires, exports historiques oubliés, copies chez des tiers, données résidant dans des services externes qui ont leur propre rétention ;
• vérifier si la suppression est logique ou physique : selon la solution et le stockage, des jeux « supprimés » restent récupérables, parfois avec l’aide du support de l’éditeur de la solution ;
• prélever et préserver ce qui reste avant toute manipulation du stockage : les tentatives de récupération improvisées détruisent ce qu’elles cherchent.