Durcir ses sauvegardes : ce qui resiste vraiment a un ransomware en 2026

La regle 3-2-1-1-0, que nous avons detaillee dans un precedent article, pose le cadre : trois copies, deux supports, une copie hors site, une copie immuable, zero erreur de restauration. Ce cadre est aujourd'hui largement connu. Le probleme n'est plus de l'enoncer, il est de le tenir vraiment. Car une sauvegarde conforme sur le papier peut quand meme tomber le jour de l'attaque.

Les chiffres des editeurs de securite convergent sur ce point : selon le rapport Sophos State of Ransomware 2024, environ 94 % des attaques par ransomware cherchent a compromettre les sauvegardes, et parmi celles dont les sauvegardes ont ete ciblees, plus de la moitie ont vu ces sauvegardes effectivement detruites. Les rapports Veeam situent la proportion d'attaques visant les sauvegardes autour de 89 a 93 % selon les annees. Ces chiffres viennent d'editeurs interesses, mais la tendance est constante et coherente avec ce que nous observons. Cet article ne reprend donc pas la regle, il regarde son durcissement operationnel.

Pourquoi une sauvegarde conforme peut quand meme tomber

Le scenario type est connu des equipes de reponse a incident. La cible de sauvegarde est bien presente, immuable meme, mais sa console d'administration est accessible avec le meme compte que le reste du domaine. L'attaquant, qui a pris le temps de s'installer, compromet ce compte, modifie la retention ou desactive l'immutabilite sur les nouvelles sauvegardes, attend, puis chiffre. La sauvegarde existait. Elle n'a pas protege.

Le durcissement consiste a fermer ces portes. Il ne demande pas d'outil exotique, mais de la rigueur d'exploitation sur cinq points.

Isoler le plan de sauvegarde du reste du SI

La cible de sauvegarde ne doit pas etre joignable comme un partage de fichiers ordinaire. Les sauvegardes connectees en SMB ou NFS depuis la production tombent avec la production. Les bonnes pratiques : un reseau dedie ou segmente pour la sauvegarde, des protocoles applicatifs plutot que des partages reseau bruts, et au moins une copie reellement hors ligne ou en stockage immuable distinct. L'objectif est qu'une compromission de la production ne donne pas mecaniquement acces aux sauvegardes.

Des comptes dedies, separes, en MFA

L'administration de la sauvegarde ne doit jamais reposer sur les comptes d'administration courants du domaine. Comptes dedies, distincts de ceux de la production et du stockage cible, avec authentification multifacteur obligatoire et separation des roles : celui qui administre la sauvegarde n'est pas celui qui administre le stockage. Un compte administrateur unique pour tout reste l'une des failles les plus frequentes et les plus graves.

L'immutabilite, oui, mais bien configuree

Activer l'immutabilite ne suffit pas si la duree de retention immuable est trop courte. Les analyses de reponse a incident (Mandiant) montrent que les attaquants restent souvent plusieurs semaines dans le reseau avant de declencher le chiffrement, frequemment de l'ordre de deux a trois semaines en mediane. Une immutabilite de sept jours peut donc deja etre compromise au moment de la detection. Une retention immuable d'au moins 30 jours sur les sauvegardes quotidiennes critiques, plus longue sur les hebdomadaires et mensuelles, est un minimum raisonnable. Cote technologies, Object Lock S3, cibles Linux durcies, snapshots verrouilles, WORM sur NAS ou bande hors site restent les options credibles.

Superviser les jobs, et pas seulement les lancer

Un job de sauvegarde qui echoue en silence est un risque majeur. Le durcissement passe par une supervision active : alerte immediate en cas d'echec, suivi de l'age de la derniere sauvegarde valide, de la duree des jobs et de l'espace restant sur la cible. C'est le lien direct avec la supervision d'exploitation traitee dans l'article 01 de ce pack. Une console de sauvegarde dont les notifications dorment dans une boite mail jamais consultee n'est pas une supervision.

Une sauvegarde non testee n'est pas une sauvegarde. C'est une promesse.

Le test de restauration documente

Le zero de 3-2-1-1-0 (zero erreur de restauration) est celui que presque personne ne tient vraiment. Le test minimum, a conduire au moins trimestriellement : restaurer une VM ou un service representatif dans un environnement isole, verifier le demarrage et l'integrite des donnees, mesurer le temps reel de remise en service, et documenter le resultat. Cette trace ecrite est aussi ce que demandent les assureurs cyber dans leurs questionnaires de souscription, dont les exigences se sont durcies.

Une checklist de durcissement en dix points

A passer en revue sur votre dispositif actuel : 1, cible de sauvegarde non accessible en partage reseau depuis la production ; 2, au moins une copie immuable ou hors ligne ; 3, retention immuable d'au moins 30 jours sur le critique ; 4, comptes de sauvegarde dedies et separes ; 5, MFA sur la console d'administration ; 6, separation des roles sauvegarde / stockage ; 7, supervision active des jobs avec alerte sur echec ; 8, suivi de l'age de la derniere sauvegarde valide ; 9, test de restauration trimestriel documente ; 10, secrets et cles de chiffrement stockes separement et proteges.

Pour aller plus loin

Chez SPMDIGITAL, nous auditons et durcissons les dispositifs de sauvegarde des PME et ETI, avec Proxmox Backup Server, Veeam, ARX One ou Beemo selon le contexte, en partant de cette checklist. Si votre sauvegarde coche la case 3-2-1-1-0 mais que sa console est administree avec le compte de tout le monde, le durcissement est prioritaire.