Le message « sauvegarde terminée » rassure jusqu’au jour où un attaquant utilise le compte d’administration pour supprimer les copies. Une stratégie de sauvegarde contre les ransomwares doit précisément envisager cette situation : les protections habituelles ont été contournées et une personne malveillante cherche maintenant à rendre la restauration impossible.
La sauvegarde immuable répond à une partie de ce risque. Elle empêche la modification ou la suppression de certaines données pendant une durée définie, selon les garanties du mécanisme utilisé. Elle ne promet ni une entreprise invulnérable, ni un redémarrage immédiat. Sa valeur dépend des droits d’administration, de la rétention, des clés et des essais de récupération.
Une copie inaccessible au moment critique n’est pas une solution.
En bref — Séparez les identités qui produisent les sauvegardes de celles qui peuvent en modifier les règles. Protégez plusieurs générations, vérifiez les restrictions sur un périmètre de test et restaurez régulièrement dans un environnement isolé. L’immuabilité protège des copies ; le plan de reprise permet de les utiliser.
Ce qu’il faut rendre impossible à l’attaquant
Un ransomware peut chiffrer des fichiers de production, mais une attaque peut également viser les consoles de sauvegarde, les comptes cloud, les catalogues et les moyens de récupération. Elle peut inclure du vol de données. L’immuabilité n’empêche pas l’exfiltration : une copie protégée ne retire pas à l’attaquant les informations qu’il a déjà obtenues.
L’objectif est plus précis : conserver au moins un ensemble exploitable que l’adversaire ne puisse pas effacer ou réécrire avec les accès qu’il détient. Cela impose d’étudier les chemins d’administration, et pas seulement l’emplacement des fichiers.
Une sauvegarde sur un autre disque peut disparaître avec le même compte. Un partage réseau « réservé aux sauvegardes » peut être modifiable par un administrateur compromis. Une réplication peut reproduire très vite une suppression légitime en apparence. Le fait d’avoir plusieurs copies ne prouve donc pas leur indépendance.
La première carte à dessiner comporte quatre éléments : production, outil de sauvegarde, stockage des copies et identités d’administration. Ajoutez les dépendances telles que l’annuaire, la messagerie de récupération et le gestionnaire de clés. Si tout repose sur la même identité, le cloisonnement affiché reste limité.
Cette réflexion complète la distinction entre stockage cloud et véritable sauvegarde. La disponibilité d’un fichier synchronisé ne garantit pas la récupération d’un état antérieur fiable.
Immuable, hors ligne, versionné : trois propriétés différentes
Une copie versionnée conserve plusieurs états. Elle peut aider après une mauvaise modification, mais les anciennes versions restent parfois supprimables par un compte suffisamment privilégié. Il faut vérifier les permissions et la politique de conservation. Une copie hors ligne n’est pas accessible en permanence depuis le système de production. Elle limite certains chemins d’attaque, à condition que la rotation des supports, le stockage et les accès soient organisés. Un disque externe laissé branché en permanence ne présente pas cette même séparation.
Une copie immuable bénéficie d’une restriction technique de modification ou de suppression pour une période donnée. Le terme recouvre cependant des implémentations différentes : verrouillage d’objets, stockage avec rétention, appliance spécialisée ou autre mécanisme. Il faut lire précisément ce qui est protégé et contre quels rôles.
Ces propriétés peuvent se compléter. Elles ne sont pas interchangeables. Une copie immuable accessible depuis la console cloud peut rester dépendante du compte, de la facturation, des clés ou de la disponibilité du fournisseur. Une copie hors ligne peut être inutilisable si personne ne connaît son format ou son mot de passe.
Le nombre de copies ne remplace donc pas la diversité des scénarios de récupération. Deux emplacements administrés avec les mêmes secrets peuvent constituer une seule faiblesse opérationnelle.
Comprendre ce que le verrouillage couvre
Dans un stockage objet, la protection porte souvent sur des versions d’objets et non sur une apparence globale de dossier. Cette précision explique pourquoi une console peut sembler afficher une suppression alors qu’une version protégée subsiste, ou pourquoi une nouvelle version peut être créée sans modifier l’ancienne.
La documentation d’Object Lock d’Amazon S3 illustre cette distinction. Elle décrit notamment un mode de gouvernance, pouvant être contourné avec des autorisations spécifiques, et un mode de conformité comportant des restrictions plus fortes pendant la rétention. Ce n’est pas une recommandation commerciale : c’est un exemple de la différence entre un label et ses règles exactes.
Pour toute solution, posez les mêmes questions. Un administrateur peut-il raccourcir la rétention ? Supprimer une version ? Désactiver les futures protections ? Changer les politiques sur les prochaines copies ? Effacer le compte ou retirer les clés nécessaires au déchiffrement ? Ces actions ne relèvent pas forcément du même mécanisme.
Un verrouillage fort n’autorise pas non plus l’improvisation. Une erreur de rétention peut engager des dépenses de stockage durables ou empêcher une suppression attendue. Les besoins de conservation et les obligations relatives aux données personnelles doivent être examinés avant la généralisation.
Le bon résultat n’est pas « personne ne peut plus rien faire ». C’est les copies nécessaires restent protégées, les responsabilités sont maîtrisées et leur récupération demeure possible.
Fixer la rétention à partir du risque et du métier
Deux indicateurs structurent les besoins. Le RPO représente la perte de données maximale que l’organisation accepte de subir, exprimée dans le temps. Le RTO correspond au délai visé pour remettre le service à disposition. Ces objectifs appartiennent au métier autant qu’à l’informatique.
Une sauvegarde quotidienne ne répond pas au même besoin qu’une protection permettant de récupérer un état récent dans la journée. Et conserver beaucoup de versions ne réduit pas automatiquement le temps nécessaire pour remettre une application en fonctionnement.
La durée d’immuabilité doit aussi tenir compte du délai de détection. Si une compromission reste invisible plusieurs semaines, une courte conservation peut ne préserver que des copies déjà contaminées ou incomplètes. Aucun nombre de jours universel ne convient à toutes les entreprises : il faut relier la durée aux scénarios, à l’historique nécessaire et à la capacité de détection.
Dans un exemple fictif, une PME vise au maximum quatre heures de perte sur sa base de commandes et une reprise en une journée ouvrée. Une sauvegarde nocturne unique ne satisfait pas le premier objectif. Elle doit revoir la fréquence ou les mécanismes de protection de cette base, puis mesurer une restauration cohérente. Le simple ajout d’une rétention de trente jours ne résout pas cet écart.
Séparez les données selon leurs besoins. Un dossier commercial modifié chaque semaine, une base transactionnelle et les configurations réseau ne demandent pas nécessairement les mêmes rythmes. La granularité réduit les arbitrages coûteux et aide à justifier la politique de conservation.
Séparer les comptes sans perdre la possibilité de reprendre Les comptes de sauvegarde devraient disposer des droits nécessaires à leur fonction, sans devenir des administrateurs universels. Les opérations sensibles méritent une authentification forte, des comptes individuels et une supervision adaptée. Les accès d’urgence doivent rester disponibles, documentés et protégés.
La séparation doit être effective. Créer un second compte dont le mot de passe est stocké dans un dossier lisible par tous les administrateurs de production apporte peu. De même, une procédure de récupération reposant uniquement sur une messagerie compromise peut annuler une partie des précautions.
Identifiez les rôles : exploitation quotidienne, changement de politique, restauration, gestion des clés et validation métier. Une petite structure ne pourra pas toujours attribuer chaque rôle à une personne distincte. Elle peut néanmoins organiser une validation supplémentaire pour les changements critiques et conserver une trace exploitable.
Protégez également les clés de chiffrement. Une copie chiffrée dont la clé a disparu n’est pas récupérable par magie. Le plan doit préciser où se trouvent les moyens de déchiffrement, qui y accède et comment leur disponibilité sera vérifiée pendant une crise.
Les prestataires doivent entrer dans cette cartographie. Leurs comptes, leurs outils de télémaintenance et leurs procédures de départ font partie du périmètre. La sécurité des accès distants professionnels devient alors une dépendance directe de la stratégie de sauvegarde.
Tester le verrouillage avant de lui confier les données importantes
Commencez sur un espace de test, avec des fichiers sans valeur sensible et une durée adaptée à l’expérimentation. Vérifiez les restrictions avec les différents rôles prévus. L’objectif est de constater ce que permet réellement chaque profil, sans tenter des opérations risquées sur les sauvegardes de production.
Consignez les résultats : création d’une nouvelle version, demande de suppression, changement de rétention, consultation de l’historique et récupération d’une version antérieure. Les intitulés des boutons ne suffisent pas ; notez les réponses de l’outil et les objets concernés.
Vérifiez aussi ce qui arrive aux copies futures. Une protection correcte sur les anciennes versions ne compense pas une politique modifiée qui laisse les prochaines sauvegardes sans rétention. La surveillance doit donc inclure les changements de configuration.
Les alertes nécessitent un destinataire et un délai de traitement. Une notification de sauvegarde échouée envoyée à une ancienne adresse ne protège rien. Définissez ce qui déclenche une intervention immédiate : perte de plusieurs points de restauration, désactivation d’un travail critique, modification de droits ou chute inexpliquée du volume protégé.
Un contrôle périodique doit examiner les exclusions. Un dossier nouvellement créé, une application migrée ou une nouvelle base peuvent rester en dehors du périmètre si personne ne met l’inventaire à jour.
Restaurer une activité, pas seulement un fichier
Un essai de restauration commence par un environnement séparé. Remettre directement des données dans une production encore compromise risque de les exposer à nouveau. Le contexte de l’incident doit être compris et la remédiation coordonnée avec les personnes compétentes.
La restauration doit respecter les dépendances : identité, réseau, stockage, base de données, application, puis accès des utilisateurs selon l’architecture. Une base restaurée sans ses paramètres ou sans une version applicative compatible peut ne servir à rien. Choisissez un point dont la qualité est vérifiée. « Le plus récent » n’est pas toujours le meilleur si l’intégrité est douteuse. Les journaux, les alertes et l’analyse de l’incident aident à borner la période, sans garantir à eux seuls l’absence de compromission.
Contrôlez ensuite le résultat métier : ouvrir un dossier, retrouver une commande, vérifier un total connu, exécuter un traitement et confirmer les droits. Un fichier présent et une application démarrée ne prouvent pas que les données sont cohérentes.
Mesurez toutes les étapes, y compris l’attente d’un support, le téléchargement, le déchiffrement et la validation. Si le RTO vise huit heures mais que la récupération des archives prend déjà une journée, l’écart doit être corrigé avant l’incident.
Pour une première campagne, retenez un service prioritaire et un échantillon de données représentatif. Élargissez ensuite. Un exercice limité mais documenté apporte davantage qu’une déclaration générale de conformité non démontrée.
Inclure les nouveaux services dans le périmètre
Une migration peut laisser des sauvegardes parfaitement exécutées sur un ancien serveur tandis que les nouvelles données s’accumulent ailleurs. À chaque création d’application ou changement d’hébergement, vérifiez donc le propriétaire des données, leur emplacement et leur inclusion dans la protection.
Les services en ligne demandent une vérification particulière. Une fonction de restauration proposée par l’éditeur peut avoir un périmètre ou une fenêtre limités. L’entreprise doit connaître les éléments effectivement récupérables : documents, permissions, historiques ou configuration. Un export manuel ne restitue pas nécessairement toutes ces relations.
L’inventaire doit suivre les usages.
Lors de la revue, demandez au métier de citer un dossier récent et faites confirmer sa protection. Ce contrôle ne remplace pas un audit exhaustif, mais il détecte des écarts très concrets. L’ajout d’une nouvelle source doit ensuite être documenté, avec un premier essai de récupération et une vérification de la rétention appliquée.
Anticiper le coût et les preuves de fonctionnement
Le stockage protégé se cumule avec les versions conservées. Le budget dépend du volume initial, des modifications quotidiennes, de la durée, de la compression éventuelle et des frais d’opérations ou de récupération. La facture du stockage seul ne décrit pas le coût de reprise.
Un calcul illustratif fictif : avec 2 To au départ et 30 Go de nouvelles données conservées chaque jour pendant trente jours, on obtient environ 2,9 To avant prise en compte des suppressions, de la déduplication et des règles du service. Ce calcul grossier ne constitue pas un devis ; il sert à identifier les paramètres à mesurer.
Demandez au fournisseur comment sont facturés les téléchargements, les restaurations massives, les appels techniques et la conservation minimale. Prévoyez aussi le temps humain consacré aux essais. Une solution bon marché dont la reprise n’est jamais exercée peut coûter cher au premier incident.
Le dossier de preuve peut rester sobre : inventaire couvert, politique approuvée, résultats des tâches, contrôle des droits, essai de verrouillage et compte rendu de restauration. Chaque document doit être daté et rattaché à un responsable.
La question à poser lors de la revue suivante est concrète : si les comptes de production étaient compromis cette nuit, quelles données pourrions-nous remettre en service demain, avec quels moyens indépendants ? Une réponse testée vaut davantage qu’un badge « immuable » sur une console.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
