Sauvegarde immuable : rendre la récupération indépendante de l’attaque

Une sauvegarde classique n’est pas nécessairement une sauvegarde récupérable. Si l’infrastructure de copie partage ses identités, ses droits d’administration ou son plan de contrôle avec la production, sa destruction devient une étape logique de l’attaque. L’immutabilité rompt une partie de cette dépendance : pendant une période fixée à l’avance, les objets sauvegardés ne peuvent être ni réécrits ni supprimés, y compris par un compte d’administration ordinaire. Le mécanisme peut reposer sur un stockage de type WORM, sur un verrouillage d’objets ou sur un support isolé. Il ne remplace toutefois ni la multiplication des copies, ni leur séparation, ni les essais de restauration. Il protège l’état enregistré ; il ne garantit pas que cet état soit sain, complet ou exploitable.

Le problème réellement traité

L’objectif est de conserver un point de reprise malgré la compromission de la production et de certains composants de sauvegarde. Cela concerne les rançongiciels, mais aussi les suppressions accidentelles, les scripts défectueux et les abus de privilèges. Pour une organisation régulée, cette capacité participe à la résilience opérationnelle et à la démonstration que les scénarios de récupération sont maîtrisés. Le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier impose notamment une gestion structurée des risques liés aux technologies de l’information et de la communication, ainsi que des politiques de sauvegarde, de restauration et de rétablissement. L’immutabilité peut contribuer à ces objectifs. Elle ne constitue pas, à elle seule, une preuve de conformité : la gouvernance, les tests, la documentation et la gestion des incidents restent déterminants.

Les arbitrages d’exploitation

• Durée de rétention : une période trop courte peut laisser l’attaque attendre l’expiration des copies saines. Une période trop longue immobilise de la capacité et conserve des données qui ne sont peut-être plus nécessaires. Le réglage doit partir des scénarios de menace, des objectifs de reprise, des exigences de conservation et des règles internes de minimisation.
• Irréversibilité : une erreur de configuration peut devenir impossible à corriger avant l’échéance. Une rétention saisie avec la mauvaise unité, appliquée au mauvais périmètre ou prolongée sans contrôle peut bloquer durablement la suppression. Les changements doivent donc être relus, tracés, testés sur un périmètre limité et soumis à une séparation des rôles.
• Identités d’administration : un stockage déclaré immuable perd une grande partie de son intérêt si le même compte peut modifier la politique, détruire le service, révoquer les clés ou désactiver la réplication. Les identités de sauvegarde doivent être distinctes de celles de la production, protégées par une authentification forte et limitées aux opérations nécessaires.
• Clés de chiffrement : une copie intacte mais privée de sa clé est inutilisable. À l’inverse, des clés accessibles depuis le domaine compromis peuvent faciliter l’exposition des données. Leur cycle de vie, leur sauvegarde, leur rotation, leur récupération et les droits associés doivent être conçus avec le même soin que le stockage lui-même.
• Capacité et coût : l’immutabilité interdit certaines suppressions anticipées et limite les possibilités de correction. Les prévisions doivent intégrer la croissance, les rétentions simultanées, les copies multiples, les journaux et les échecs de traitements. La déduplication ou la compression réduisent parfois le volume physique, mais elles ne dispensent pas d’un dimensionnement prudent.
• Effacement et conservation : l’immutabilité peut entrer en tension avec une demande d’effacement ou une modification de politique. Le RGPD, règlement (UE) 2016/679, prévoit un droit à l’effacement assorti de conditions et d’exceptions. Le traitement concret dépend du contexte juridique et documentaire de l’organisation ; il doit être validé par les fonctions compétentes avant de figer les rétentions.

Adopter quand la restauration est démontrable

L’adoption est pertinente lorsque la suppression des sauvegardes figure parmi les scénarios de risque crédibles, lorsque plusieurs équipes disposent de privilèges élevés ou lorsque les objectifs de continuité exigent une copie indépendante du domaine de production. Elle doit commencer par un inventaire des données et dépendances nécessaires à une reprise : bases de données, configurations, annuaires, certificats, secrets, images système, journaux et documentation opératoire. Il faut ensuite définir les points de reprise attendus, les durées de conservation et l’ordre de restauration. Un essai utile ne se limite pas à vérifier qu’un fichier peut être lu. Il reconstruit un service dans un environnement isolé, contrôle son intégrité, mesure les étapes manuelles et confirme que les clés, identités et compétences sont disponibles. Les résultats doivent être horodatés, attribués, comparables d’un exercice à l’autre et reliés aux changements d’architecture. Une sauvegarde immuable non testée reste une hypothèse.

L’immutabilité n’est pas un isolement absolu. Un attaquant peut encore chiffrer la production avant la sauvegarde, empoisonner progressivement les copies, voler les données ou perturber le catalogue nécessaire à leur localisation. Il faut conserver plusieurs générations, surveiller les anomalies, séparer les plans d’administration et maintenir au moins une voie de récupération qui ne dépende pas des composants compromis. La décision ne doit pas porter seulement sur le support : elle doit couvrir toute la chaîne de restauration.