Une sauvegarde immuable est une copie qu’aucune opération ne peut modifier ni effacer pendant une durée fixée à l’avance. Ni un administrateur qui voulait faire de la place, ni un attaquant disposant de tous les droits du domaine. Voilà le bloc autour duquel se construit une vraie défense anti-ransomware, parce que c’est le seul que l’intrus ne franchit pas en volant des identifiants.
Le ransomware d’aujourd’hui ne se jette plus sur vos fichiers de production. Il prend le temps de chercher où sont vos sauvegardes, puisqu’il sait que c’est votre unique issue, et il les détruit avant de lancer le chiffrement. Le scénario que je vois revenir tient en une phrase : des copies posées sur un partage réseau, accessibles avec les comptes du domaine. Quand l’Active Directory tombe (l’annuaire central Windows qui gère comptes et droits sur tout le parc), cette porte s’ouvre avec les mêmes clés que toutes les autres. L’attaquant efface, puis chiffre, et vous ne découvrez le vide qu’au moment de restaurer.
Protéger ses sauvegardes d’un ransomware, c’est appliquer la règle 3-2-1, les rendre immuables pendant une durée fixée, et garder au moins une copie hors ligne ou isolée que l’attaquant du réseau ne peut pas atteindre.
Le socle pour éviter ça n’a rien de neuf : trois copies des données, réparties sur deux types de supports, dont une conservée hors site. C’est la règle 3-2-1. L’idée n’est pas de multiplier les disques pour le plaisir, mais qu’aucun événement unique ne puisse tout emporter. Une baie qui crame, une inondation, un chiffrement généralisé : quand les copies sont diversifiées et dispersées, il en reste une debout. Reste qu’une copie qui survit physiquement peut encore se faire effacer logiquement, et c’est là qu’intervient l’immuabilité. Tant que la rétention court, la copie est gelée. Le verrouillage S3 Object Lock (un mécanisme du stockage objet qui scelle un fichier pour une durée donnée) tient même contre le compte root du bucket, c’est-à-dire le propriétaire tout-puissant de l’espace de stockage, ce qui fait précisément rager un attaquant qui contrôle le réseau, possède les droits, et bute quand même sur un verrou qu’aucun privilège ne lève.
L’immuabilité ne couvre pourtant pas tout. Gardez en plus au moins une copie hors ligne, débranchée ou très fortement isolée : réseau dédié, comptes séparés, aucun chemin direct depuis la production. Une bande sortie du robot et rangée dans une armoire ne se chiffre pas à distance. Et toutes ces précautions ne valent rien sans une vérification que peu de gens font : remonter réellement la copie. Je teste ces archives comme les sauvegardes courantes, restauration complète, chronométrée, validée. Le jour de l’attaque, on veut dérouler une procédure connue, pas découvrir que l’image est corrompue depuis trois mois ou que personne ne se souvient du mot de passe du coffre.
Un client industriel m’a appelé un lundi matin dans cette impasse. Il « sauvegardait » depuis des années : NAS bien rempli, tâches vertes tous les soirs. Le NAS, c’est le boîtier de stockage partagé sur le réseau où atterrissaient les copies — sauf qu’il était joint au domaine, donc accessible avec les comptes du parc. L’attaquant l’avait vidé le vendredi soir avant de chiffrer, et il ne restait rien. On a repris à froid, en posant cette fois une copie immuable côté objet et une bande hebdomadaire qui dort dans une armoire. Six mois plus tard, une nouvelle tentative a effacé le NAS comme la première fois. Cette fois, la bande de la semaine précédente était intacte. Restauration en une journée, pas de rançon. La vraie question n’a jamais été « est-ce que je sauvegarde », mais « est-ce que mes sauvegardes tiendraient face à quelqu’un qui contrôle entièrement mon réseau ». Pour ce client, la réponse était devenue oui, et le ransomware était passé de catastrophe à mauvaise semaine.