Sauvegarde immuable anti-ransomware et verrouillage WORM

Une sauvegarde chiffrée peut être supprimée, remplacée ou rendue irrécupérable par la suppression de sa clé. Une copie immuable traite un autre problème : empêcher une identité compromise, y compris administratrice, de détruire ou d’altérer les points de restauration pendant une durée fixée.

→ Lire l’explication complète de la marmotte

Immuabilité WORM : la garantie à exiger

WORM (Write Once Read Many) signifie qu’un objet écrit peut être relu, mais ni modifié ni supprimé avant l’expiration de sa rétention. La garantie doit être appliquée par le service de stockage, pas par le logiciel de sauvegarde. Une case « protection contre la suppression » dans une console d’administration ne vaut rien si le même compte peut la décocher avant de lancer la suppression. C’est une barrière décorative, très appréciée des présentations commerciales et des attaquants patients.

Le verrouillage de rétention côté fournisseur cloud impose cette propriété dans le plan de données du stockage. Un objet protégé reste indisponible à la suppression via l’interface, l’API (Application Programming Interface), les outils en ligne de commande et les identifiants administrateurs légitimes. Un jeton volé avec des droits étendus peut encore écrire, lire selon la politique, ou tenter de saturer le stockage. Il ne peut pas raccourcir une rétention de conformité ni supprimer la version verrouillée.

Deux modes existent généralement :

Le mode de gouvernance laisse un droit explicite de contournement à certaines identités. Il convient aux erreurs opérationnelles récupérables, mais pas à la copie de dernier recours contre le ransomware.
Le mode de conformité interdit toute suppression ou réduction de rétention jusqu’à l’échéance, y compris aux administrateurs du compte. C’est le mode à retenir pour la copie sanctuarisée.

Le compromis central est brutal : gagner une protection contre l’effacement administrateur impose de perdre la possibilité de corriger une erreur de durée, de purger une donnée trop tôt ou de récupérer immédiatement de l’espace. Une rétention de sept ans accidentellement appliquée à plusieurs pétaoctets ne se négocie pas avec la gravité. Pour une copie anti-ransomware, ce prix est acceptable seulement après validation des durées, des coûts et des données exclues.

L’immuabilité n’est pas le chiffrement. Le chiffrement protège la confidentialité si la clé résiste ; il ne bloque pas un administrateur qui supprime les objets chiffrés ou désactive leur clé. À l’inverse, une copie immuable non chiffrée reste lisible par toute identité disposant d’un accès de lecture. Les deux mécanismes se complètent, comme détaillé dans les principes de cryptographie appliquée.

Architecture de copie isolée et rétention verrouillée

La copie immuable doit vivre dans un périmètre d’identité distinct de la production. Un compte de stockage séparé réduit l’effet d’une compromission du compte principal, à condition que son administration ne repose pas sur les mêmes identités fédérées, les mêmes postes d’administration et le même mécanisme de récupération. Séparer des conteneurs sous le même super-administrateur ne constitue pas une frontière. C’est une cloison en papier avec un logo de conformité.

Le flux recommandé est unidirectionnel : le système de sauvegarde écrit vers le dépôt, mais ne reçoit aucun droit de suppression ni de raccourcissement de rétention. Une identité de restauration, distincte de l’identité d’écriture, lit les sauvegardes depuis un environnement de reprise contrôlé. La séparation des rôles limite la portée d’un jeton de charge de travail compromis.

Une architecture exploitable contient au minimum :

un dépôt activé pour le versionnage et le verrouillage d’objets avant toute écriture ;
une politique de rétention par défaut, afin qu’un oubli applicatif ne crée pas une sauvegarde effaçable ;
une identité d’écriture limitée au préfixe de sauvegarde et à l’ajout d’objets ;
une identité de lecture réservée à la restauration ;
une identité d’administration protégée par MFA (Multi-Factor Authentication), sans usage quotidien ;
des journaux d’audit exportés vers un emplacement distinct et eux-mêmes retenus.

La durée de rétention doit couvrir le délai de détection, le temps nécessaire pour qualifier l’intrusion et une marge de restauration. Une conservation de trente jours ne protège pas contre un chiffrement détecté au trente-et-unième jour, même avec une console remplie de cadenas verts. Prévoir plusieurs fenêtres, par exemple quotidienne courte, hebdomadaire et mensuelle longue, limite les coûts sans concentrer tout le risque sur un point de restauration récent.

Le catalogue de sauvegarde mérite le même traitement que les blocs sauvegardés. Si un attaquant peut supprimer l’index, la donnée WORM survit mais devient difficile à retrouver dans l’urgence. Une restauration reste possible à partir des objets, mais l’opération se transforme en archéologie numérique, discipline peu compatible avec un incident majeur.

Les principes de séparation d’identité rejoignent ceux exposés dans la section identités et contrôle d’accès. L’immuabilité compense une compromission d’autorisation, elle ne remplace pas la maîtrise des privilèges.

Exemple S3 Object Lock en mode conformité

Amazon S3 (Simple Storage Service) propose Object Lock sur un compartiment créé avec cette option. Object Lock s’appuie sur le versionnage : chaque version protégée reçoit sa propre date de fin de rétention. Le mode COMPLIANCE interdit de réduire cette date ou de supprimer la version avant son échéance.

L’exemple suivant crée un compartiment, active une rétention par défaut de 90 jours et vérifie la configuration. Il suppose AWS CLI (Amazon Web Services Command Line Interface) installé et une identité autorisée à créer le compartiment. Le nom doit être globalement unique.

# Créer le compartiment avec Object Lock dès sa création.
# Cette capacité ne s'ajoute pas ensuite à un compartiment ordinaire.
aws s3api create-bucket \
  --bucket sauvegardes-immutables-exemple-9f31 \
  --region eu-west-3 \
  --create-bucket-configuration LocationConstraint=eu-west-3 \
  --object-lock-enabled-for-bucket

# Fixer une rétention par défaut de 90 jours en mode conformité.
aws s3api put-object-lock-configuration \
  --bucket sauvegardes-immutables-exemple-9f31 \
  --object-lock-configuration \
  'ObjectLockEnabled=Enabled,Rule={DefaultRetention={Mode=COMPLIANCE,Days=90}}'

# Contrôler le verrouillage avant d'autoriser le logiciel de sauvegarde à écrire.
aws s3api get-object-lock-configuration \
  --bucket sauvegardes-immutables-exemple-9f31

La commande de création est irréversible sur ce point : activer Object Lock à l’origine du compartiment évite qu’un dépôt déjà exposé reste modifiable pendant sa phase de préparation. Une politique de compartiment doit ensuite refuser les écritures sans date de rétention explicite si le logiciel de sauvegarde peut la poser, ou s’appuyer sur la rétention par défaut.

Il faut tester une tentative de suppression avec une identité disposant de droits élevés. Le résultat attendu est un refus tant que la date de rétention n’est pas passée. Tester uniquement depuis l’interface du produit de sauvegarde vérifie son interface, pas la propriété de stockage. Ce genre de nuance disparaît vite sous une couche de tableaux de bord, avec la même élégance qu’un éléphant dans une baie informatique.

Surface d’attaque : ce que le verrouillage ne garantit pas

L’immuabilité empêche l’altération d’un objet déjà verrouillé. Elle n’empêche pas le ransomware de chiffrer les données de production avant la prochaine sauvegarde. Si les rétentions sont trop courtes ou si les anciennes générations sont absentes, le dépôt conservera fidèlement des données déjà compromises. Une copie immuable stocke la vérité disponible, pas une vérité magique.

Elle ne bloque pas non plus l’empoisonnement fonctionnel : un attaquant peut modifier silencieusement des données applicatives, faire sauvegarder des versions valides du point de vue technique mais frauduleuses métier, puis attendre. La défense exige des restaurations régulières, des contrôles de cohérence applicative et des jalons de conservation assez anciens.

Les attaques à anticiper sont les suivantes :

vol de l’identité de sauvegarde, suivi d’écritures massives pour épuiser la capacité ;
suppression ou désactivation de la clé de chiffrement du dépôt ;
altération du catalogue, des politiques d’accès ou du pipeline de sauvegarde ;
exfiltration des données si la lecture reste ouverte ;
compromission de la plateforme de virtualisation ou de l’annuaire qui pilote les restaurations ;
destruction du compte ou de la région, selon les garanties du fournisseur et le modèle contractuel.

Une protection WORM ne garantit ni disponibilité du fournisseur, ni capacité réseau, ni intégrité du logiciel qui produit les sauvegardes. Une seconde copie dans un domaine de défaillance distinct reste nécessaire. La continuité et reprise dépend aussi des procédures de restauration, des dépendances applicatives et des accès hors production.

Clés, supervision et reprise des sauvegardes immuables

Lorsque le dépôt utilise une clé gérée par le client, la durée de vie de cette clé doit dépasser la dernière rétention des objets qu’elle chiffre, plus la fenêtre de restauration. Désactiver ou détruire une clé rend les sauvegardes immuables indisponibles sans les supprimer. C’est une indisponibilité parfaitement conforme au mécanisme, donc parfaitement catastrophique au mauvais moment.

Une KEK (Key Encryption Key), clé servant à chiffrer d’autres clés, peut protéger les clés de données du dépôt dans un KMS (Key Management Service), service de gestion de clés. La rotation doit conserver la capacité de déchiffrer les versions historiques. Remplacer une clé sans conserver ses versions antérieures transforme la rotation en broyeur de restauration.

La supervision doit alerter sur les changements de rétention, les refus de suppression, les créations d’identités privilégiées, les pics d’écriture et les échecs de sauvegarde. Un refus de suppression inattendu peut signaler une attaque, mais aussi une politique correctement appliquée. Sans corrélation avec les journaux d’identité et les volumes écrits, l’alerte devient une sirène qui hurle pour célébrer son propre fonctionnement.

La reprise doit être exercée depuis des identités et un environnement séparés. Restaurer un fichier ne valide pas une restauration : il faut reconstruire l’application, ses droits, ses bases de données et ses dépendances, puis vérifier le résultat métier. Les secrets de récupération, les clés historiques et la documentation d’accès doivent être conservés hors du périmètre de production. Une sauvegarde qu’aucune identité survivante ne peut lire est une sculpture conceptuelle coûteuse.

🐝 Ce qui arrive si on s’en passe

Sans verrouillage appliqué par le stockage, une identité compromise n’a même pas besoin d’appeler une suppression visible : il lui suffit d’ajouter une règle de cycle de vie qui fait expirer les versions anciennes, et la purge s’exécute ensuite sous l’identité du service de stockage, sans action attribuable à l’attaquant au moment de l’effacement. Le versionnage seul ne protège pas davantage, puisque les versions précédentes restent supprimables par quiconque détient le droit adéquat. Autre perte, moins visible : aucun point de restauration ne peut être prouvé intact après la date de compromission. Chaque sauvegarde accessible pendant la fenêtre d’intrusion doit alors être traitée comme suspecte et vérifiée avant usage, ce qui allonge la reprise précisément quand le délai compte le plus.

🦫 Explication de la marmotte 🍫

Une copie de sauvegarde immuable est une copie dont la durée de conservation est fixée au moment où elle est enregistrée. Pendant cette durée, le service qui garde les fichiers refuse de les modifier ou de les supprimer. Ce refus s’applique même si un pirate a volé les identifiants d’un administrateur ayant beaucoup de droits.

Le mécanisme doit être activé avant d’écrire les sauvegardes. Le stockage garde alors plusieurs versions d’un même fichier et attribue une date de fin de protection à chaque version. Le logiciel de sauvegarde envoie les données. Une autre identité est prévue pour les relire lors d’une restauration. L’identité qui envoie les données ne doit pas pouvoir retirer la protection.

Le chiffrement reste nécessaire pour empêcher la lecture des fichiers volés, mais il ne remplace pas ce verrouillage. Si la clé de chiffrement est supprimée, les sauvegardes restent présentes mais deviennent illisibles. La clé doit donc être gardée plus longtemps que les sauvegardes qu’elle protège.

Cette méthode échoue contre des données déjà abîmées avant leur copie, contre une durée de conservation trop courte, ou contre un stockage rempli par des écritures malveillantes. Elle ne remplace pas les tests de restauration. Il faut vérifier régulièrement qu’une application entière peut repartir avec une ancienne copie, ses données, ses accès et ses paramètres.

Pages voisines

La citent

Sauvegarde immuable anti-ransomware et verrouillage WORM

Elle cite

: les deux pages se citent l’une l’autre.

Sauvegarde immuable anti-ransomware et verrouillage WORM

Sauvegarde immuable anti-ransomware et verrouillage WORM

Immuabilité WORM : la garantie à exiger

Architecture de copie isolée et rétention verrouillée

Exemple S3 Object Lock en mode conformité

Surface d’attaque : ce que le verrouillage ne garantit pas

Clés, supervision et reprise des sauvegardes immuables

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines