TL;DR — La sauvegarde immuable est une protection réelle contre le ransomware, pas un mythe marketing. Basée sur le principe WORM et un verrou temporel non révocable, elle bloque le chiffrement et la suppression des sauvegardes, même par un compte administrateur compromis. Elle reste inefficace face à l’exfiltration de données et à un plan de restauration jamais testé.
La sauvegarde immuable fonctionne. Ce n’est pas un mythe. Mais elle n’est une vraie protection contre le ransomware que si trois conditions sont réunies : un verrou temporel réellement non révocable, une séparation des identités, et une restauration testée à l’échelle.
Le reste, c’est du marketing.
Soyons clairs sur le problème initial. Depuis 2020, les groupes de ransomware ne chiffrent plus d’abord les données de production. Ils commencent par les sauvegardes. Ils cherchent la console Veeam, le partage CIFS du repository, le compte de service surprivilégié. Puis ils suppriment. Ensuite seulement ils chiffrent.
Résultat : une entreprise avec des sauvegardes « propres » mais accessibles depuis l’Active Directory de production n’a, en réalité, aucune sauvegarde.
L’immuabilité répond précisément à ce scénario. Elle ne rend pas la donnée invisible. Elle la rend non modifiable et non supprimable pendant une durée définie.
La sauvegarde immuable repose sur le principe WORM (Write Once, Read Many). Une fois écrite, la donnée ne peut plus être altérée. Ni par un utilisateur, ni par un administrateur, ni par un processus malveillant.
Trois familles d’implémentation coexistent en 2026 :
| Mécanisme | Principe | Niveau de résistance |
|---|---|---|
| Object Lock S3 (mode Compliance) | Verrou objet géré par le stockage, non révocable même par le compte root | Très élevé |
| Object Lock S3 (mode Governance) | Verrou contournable avec une permission spécifique | Moyen — à éviter seul |
| Hardened Linux Repository (ex. Veeam XFS + immutability flag) | Attribut i posé par un service isolé, sans accès SSH ni domaine | Élevé |
| Bande LTO en coffre | Air gap physique réel | Très élevé, mais RTO long |
| Snapshots verrouillés (SnapLock, Immutable Snapshots) | Verrou au niveau du système de fichiers baie | Élevé si baie hors domaine |
Le point critique est le suivant : le mode Governance n’est pas de l’immuabilité. C’est une suggestion. Un attaquant disposant du bon rôle IAM lève le verrou en une commande. J’ai vu des DSI convaincus d’être immuables alors que leur bucket était en Governance avec une politique IAM permissive.
Vérifiez ce paramètre avant toute autre chose.
Il faut cadrer le périmètre honnêtement. La sauvegarde immuable couvre un risque précis, pas l’ensemble du risque ransomware.
Ce qu’elle protège efficacement :
Ce qu’elle ne protège pas du tout :
En pratique, la sauvegarde immuable est une condition nécessaire mais insuffisante. C’est un filet, pas un bouclier.
L’ancienne règle 3-2-1 ne suffit plus. Le standard opérationnel actuel est le 3-2-1-1-0 :
Le dernier chiffre est le plus négligé. Une sauvegarde immuable non vérifiée n’a aucune valeur démontrable. Les outils modernes proposent du SureBackup ou équivalent : montage automatique de la VM dans un réseau isolé, test de boot, test applicatif.
Automatisez-le. Hebdomadairement. Sinon vous découvrirez le problème le jour J.
Concernant la durée de rétention immuable : ne descendez pas sous 14 jours. Le temps de dwell moyen d’un attaquant avant déclenchement se compte en semaines. Une rétention de 7 jours laisse une fenêtre exploitable. Pour les données réglementées, alignez la rétention immuable sur l’obligation légale (souvent 5 ou 10 ans en environnement financier ou santé).
Voici ce que je constate le plus souvent en audit d’infrastructure de sauvegarde.
1. Le serveur de backup dans le domaine de production. Si votre serveur Veeam ou Commvault est joint à l’AD compromis, l’attaquant hérite d’un accès privilégié. Sortez-le du domaine. Utilisez des comptes locaux avec MFA.
2. Object Lock en mode Governance. Déjà évoqué. C’est l’erreur la plus fréquente et la plus grave.
3. Un seul jeu d’identifiants. Le compte qui écrit les sauvegardes ne doit pas pouvoir modifier la politique de rétention. Séparez les rôles.
4. Pas de MFA sur la console de sauvegarde. Évident, rarement appliqué. La console de backup est une cible de premier rang.
5. Aucun test de restauration à l’échelle réelle. Restaurer un fichier fonctionne toujours. Restaurer 40 VM en parallèle avec les dépendances applicatives, c’est un autre exercice. Faites-le une fois par an, en conditions dégradées.
Ajoutons un point de gouvernance. La sauvegarde immuable doit figurer dans votre PRA (Plan de Reprise d’Activité) avec des RTO et RPO chiffrés par application critique. Sans cette cartographie, vous restaurez à l’aveugle.
La directive NIS 2, transposée en droit français, impose aux entités essentielles et importantes des mesures de gestion de crise et de continuité d’activité. L’ANSSI, dans ses guides sur la sécurisation des systèmes d’information, recommande explicitement des sauvegardes déconnectées ou protégées contre l’altération.
Concrètement, la sauvegarde immuable devient un élément d’audit. Un assureur cyber vous la demandera. Un auditeur NIS 2 vous demandera la preuve du test de restauration.
Documentez donc : configuration du verrou, durée de rétention, rapports de vérification automatisés, comptes-rendus d’exercices de restauration. Cette traçabilité vaut autant que la technologie elle-même.