Sauvegarde cloud immuable : six tests pour vérifier qu’un stockage WORM protège vraiment vos données

Le tableau de bord affiche une mention rassurante : Object Lock activé, rétention immuable ou WORM. Puis survient l’incident. Un compte d’administration compromis tente de supprimer les sauvegardes, un bucket disparaît de l’inventaire, une clé de chiffrement n’est plus disponible ou la région principale devient inaccessible. La question n’est alors plus de savoir si le fournisseur propose une fonction d’immuabilité. Il faut vérifier ce que cette fonction protège réellement, contre qui, pendant combien de temps et avec quelles preuves.

WORM signifie Write Once, Read Many : les données peuvent être écrites puis lues, mais pas modifiées ou supprimées pendant une période définie. Cette propriété est précieuse contre les ransomwares et les erreurs d’administration. Elle reste toutefois locale à un périmètre précis : une version d’objet, une politique de rétention, un compte, une clé et parfois une région. Une sauvegarde peut donc être impossible à effacer tout en étant mal répliquée, invisible après une suppression logique ou illisible au moment de la restauration.

Le bon réflexe consiste à transformer la promesse technique en protocole de vérification. Les six scénarios suivants ne remplacent pas la documentation du fournisseur ; ils obligent l’équipe à confronter cette documentation à son propre environnement, à ses permissions et à ses procédures de crise.

1. Commencer par définir ce que « immuable » doit empêcher

Avant de lancer une commande de suppression, il faut préciser l’objet du test. Une sauvegarde cloud immuable peut viser plusieurs protections différentes, que l’on confond trop facilement.

La première concerne le contenu lui-même : une version donnée ne doit plus pouvoir être modifiée ni supprimée avant la fin de sa rétention. Dans Amazon S3, Object Lock fonctionne avec le versioning et protège une version précise par une période de rétention ou une conservation légale. Le bucket n’est donc pas une boîte uniformément verrouillée : plusieurs versions et plusieurs états peuvent coexister.

La deuxième protection concerne la durée. Une rétention temporelle fixe une date jusqu’à laquelle l’objet reste protégé. Une conservation légale, elle, maintient le verrou tant qu’elle n’est pas levée explicitement. Chez Azure Blob Storage, les politiques de rétention temporelles et les conservations légales répondent à cette même distinction générale : un blob protégé ne peut pas être modifié ou supprimé pendant la période prévue ou jusqu’à la levée de la conservation, comme le décrit la documentation Microsoft sur l’immuabilité Blob.

La troisième protection est administrative. Qui peut modifier la durée ? Qui peut retirer une conservation légale ? Qui peut supprimer le compte, le bucket ou la clé de chiffrement ? Une configuration parfaitement verrouillée contre une suppression d’objet peut rester vulnérable à une compromission plus large de l’environnement.

Enfin, il y a la récupérabilité. L’immuabilité n’est pas une restauration. Elle ne prouve ni que les métadonnées de sauvegarde sont intactes, ni que le catalogue sait retrouver les objets, ni que la clé permettant de les déchiffrer existe encore. C’est pourquoi chaque test doit associer une action hostile, un résultat attendu et une preuve conservée : journal d’audit, réponse de l’API, état de la version, date de rétention et résultat de restauration.

2. Vérifier le verrou au niveau de l’objet, pas seulement du bucket

Le premier contrôle consiste à suivre une sauvegarde réelle de bout en bout. Créez un objet de test ou utilisez une copie non critique, activez la politique prévue, puis observez son identifiant de version, sa date de fin de rétention et, si le scénario le prévoit, sa conservation légale. Le but est de pouvoir répondre à une question simple : quelle donnée exacte doit survivre à l’effacement ?

Dans S3, le versioning est une condition structurante. Une écriture ultérieure ne remplace pas forcément la version protégée ; elle peut créer une nouvelle version. Cela protège l’ancienne donnée, mais peut aussi produire une confusion opérationnelle : l’application ou le catalogue consulte-t-il la bonne version ? Une équipe qui vérifie uniquement qu’un nouvel objet est encore accessible peut passer à côté de la version historique qu’elle devra restaurer pendant la crise.

Le test doit donc capturer les métadonnées avant et après chaque action : identifiant de version, statut de rétention, date d’expiration, présence d’une conservation légale et résultat de la lecture. Les règles Lifecycle méritent aussi une vérification. Selon AWS, elles ne peuvent pas supprimer une version encore verrouillée ; en revanche, une version dont la rétention est arrivée à expiration devient supprimable, sauf si une conservation légale reste active. Une politique automatique ne doit donc pas être considérée comme une garantie indépendante : elle obéit à l’état du verrou.

Le même raisonnement vaut pour les autres clouds, même si les objets et les politiques portent des noms différents. Google Cloud Storage permet de verrouiller une politique de rétention au niveau du bucket. Après verrouillage, sa durée ne peut plus être réduite ni la politique supprimée ; le bucket verrouillé ne peut pas non plus être supprimé tant que tous ses objets n’ont pas satisfait leur durée de rétention. Cette irréversibilité est utile, mais elle augmente aussi le coût d’une mauvaise durée : il faut la tester avec une donnée représentative et une procédure de restauration connue.

La preuve attendue à cette étape n’est pas une capture d’écran. C’est un dossier reproductible : commande ou appel API utilisé, identité ayant effectué l’opération, réponse obtenue, journaux correspondants et état du fichier après tentative de lecture. Un audit pourra alors distinguer une politique activée d’une protection effectivement observée.

3. Scénario 1 : un identifiant compromis tente de raccourcir la rétention

Le premier adversaire réaliste n’est pas forcément un logiciel malveillant sophistiqué. C’est un compte légitime dont les identifiants ont été volés, ou une clé d’accès trop puissante utilisée par erreur. Le test consiste à employer un rôle proche de celui qui serait compromis et à lui faire tenter trois opérations : raccourcir la rétention, retirer une conservation légale et supprimer la version protégée.

Cette distinction est essentielle dans S3. Le mode Gouvernance permet à certains principaux disposant de la permission s3:BypassGovernanceRetention de contourner la rétention. Le mode Conformité, lui, ne permet pas de raccourcir la rétention ni de supprimer la version protégée pendant la période prévue, d’après les considérations de gestion d’Object Lock. Une organisation qui affirme « le bucket est immuable » doit donc préciser dans quel mode il se trouve et quelles identités possèdent ce contournement.

Le test ne cherche pas à démontrer qu’aucun administrateur ne peut jamais agir. Il cherche à cartographier le chemin d’attaque. Un rôle d’exploitation peut-il désactiver le verrou ? Un administrateur du compte peut-il supprimer le bucket ? Une procédure d’urgence possède-t-elle le droit de contournement ? Les journaux enregistrent-ils la tentative et l’identité qui l’a effectuée ?

Le résultat attendu varie selon le niveau de protection choisi, mais il doit être explicite. En mode Gouvernance, une suppression réussie avec la permission dédiée n’est pas nécessairement un échec de la fonction : c’est la preuve que cette permission devient un contrôle critique à isoler, surveiller et retirer des rôles courants. En mode Conformité, la tentative doit échouer pendant la période de rétention. Dans les deux cas, l’équipe doit conserver l’erreur retournée et vérifier que la version reste lisible.

Azure et Google Cloud ajoutent une décision comparable autour de la politique elle-même. Azure distingue la rétention et la conservation légale. Google Cloud rend la politique irréductible après verrouillage. La question opérationnelle reste la même : qui peut activer le mécanisme, qui peut encore gérer les données sans réduire la protection, et comment une équipe indépendante le vérifie-t-elle avant l’incident ?

4. Scénarios 2 et 3 : suppression logique, bucket effacé et ransomware

Une suppression réussie à l’interface ne signifie pas forcément que la donnée protégée a disparu. Dans S3, une suppression simple peut créer un delete marker, c’est-à-dire un marqueur qui masque les versions précédentes lors d’une consultation ordinaire. AWS précise que ce marqueur n’est pas lui-même protégé par WORM. La version verrouillée peut donc subsister tout en devenant moins visible pour une application qui ne demande pas explicitement les versions.

Le deuxième test consiste à supprimer l’objet avec le même type d’outil que celui utilisé en production, puis à vérifier deux chemins : la lecture normale et l’inventaire des versions. Si le fichier n’apparaît plus dans le premier chemin mais reste récupérable dans le second, la protection contre la destruction est présente, mais le processus de restauration doit savoir contourner ce masquage. Il faut documenter cette nuance, faute de quoi une équipe sous pression pourrait conclure trop vite que la sauvegarde a été perdue.

Le scénario suivant élargit l’action : suppression du bucket, du compte de stockage ou d’un ensemble de données. Le WORM d’un objet n’est pas automatiquement une protection contre toutes les opérations de gestion autour de lui. Avec Google Cloud, le verrouillage d’une politique empêche notamment de supprimer le bucket tant que les objets n’ont pas terminé leur durée de rétention. Mais cette propriété doit être vérifiée dans le contexte exact des permissions et des services utilisés par l’organisation.

Le troisième test simule un ransomware. Il ne s’agit pas nécessairement de déployer un logiciel malveillant : une procédure contrôlée peut tenter de parcourir le dépôt avec un compte de sauvegarde compromis, de réécrire des objets, d’ajouter des versions et de déposer des marqueurs de suppression. L’équipe observe ensuite ce qui reste, ce que le catalogue affiche et combien de temps il faut pour isoler le compte.

La CISA recommande des sauvegardes isolées, chiffrées, immuables et testées régulièrement face aux ransomwares. Ces qualificatifs se complètent. Une copie accessible avec les mêmes identifiants que les systèmes de production n’est pas réellement isolée ; une copie verrouillée mais jamais restaurée n’est pas encore une capacité de reprise démontrée. Le résultat du test doit inclure les données survivantes, les alertes déclenchées, la procédure de révocation des accès et le temps nécessaire pour retrouver un point sain.

5. Scénarios 4 et 5 : expiration de la rétention et restauration partielle

Une période de rétention n’est pas un bouclier éternel. Quand elle expire, la version S3 redevient supprimable, sauf si une conservation légale demeure active. C’est exactement le comportement qu’il faut tester plutôt que supposer : que se passe-t-il le jour de l’expiration, quelle règle Lifecycle s’applique, qui reçoit l’information et les anciennes versions restent-elles couvertes par la politique attendue ?

Un test accéléré, réalisé dans un environnement dédié, peut vérifier la transition entre trois états : version protégée, version arrivée à expiration, version maintenue par une conservation légale. L’objectif n’est pas de supprimer une donnée importante, mais de constater le changement de droits et de le relier aux journaux. Cette vérification révèle souvent une décision qui n’a jamais été formalisée : la durée protège-t-elle la sauvegarde pendant la fenêtre réglementaire, pendant le délai de détection d’une compromission ou pendant toute la durée nécessaire à l’exploitation ?

Il faut ensuite quitter le terrain de la suppression pour celui de la restauration. Une restauration complète vérifie que l’environnement peut redémarrer, mais elle ne dit pas toujours si un seul fichier, une table ou une machine virtuelle peut être récupéré rapidement. Le scénario de restauration partielle prend un objet ou un sous-ensemble connu, recherche la bonne version malgré un éventuel marqueur de suppression, déchiffre son contenu et vérifie son intégrité dans un emplacement séparé.

Cette séquence doit être mesurée sans transformer le test en concours de vitesse. Notez le temps de recherche, les droits requis, les dépendances au catalogue, le volume réellement restauré et les contrôles qui prouvent que le contenu correspond à la sauvegarde choisie. Une restauration qui réussit uniquement grâce à un administrateur possédant des droits exceptionnels n’est pas forcément inutilisable, mais cette dépendance doit apparaître dans le plan de crise.

Azure documente des politiques WORM temporelles et des conservations légales qui empêchent les modifications et suppressions pendant la protection. Google Cloud rappelle, avec Bucket Lock, qu’une politique verrouillée ne peut plus être réduite. Dans les deux cas, l’irréversibilité de la rétention ne dispense pas de vérifier la restauration : elle rend simplement plus difficile une suppression volontaire ou accidentelle pendant la fenêtre définie.

6. Scénario 6 : perte d’une région, réplication et clés de chiffrement

La copie dans une autre zone ou une autre région est souvent présentée comme la réponse à la panne du site principal. Elle ne doit pourtant pas être confondue avec l’immuabilité. Une redondance peut reproduire une suppression ou un remplacement. Microsoft l’explique pour Azure : les suppressions et remplacements sont répliqués sur les copies, tandis que la géoréplication protège contre certaines pannes régionales. Une copie géographique n’est donc pas automatiquement une copie protégée contre un administrateur hostile.

Dans S3, la réplication d’un bucket Object Lock exige que la destination ait elle aussi le versioning et Object Lock activés, selon les conditions de réplication AWS. Cette exigence doit figurer dans la grille de contrôle, avec la configuration de la destination, ses propres permissions et sa propre durée de rétention. Une destination simplement « répliquée » mais non verrouillée peut conserver une copie sans offrir le même niveau de résistance à l’effacement.

La réplication est en outre asynchrone. Une donnée écrite juste avant la panne peut ne pas encore être présente dans la destination. La documentation AWS sur la réplication en continu rappelle aussi qu’une réplication nouvellement configurée ne copie pas automatiquement tous les objets antérieurs. Le test doit donc inclure un objet créé avant la configuration, un objet créé après et un objet écrit pendant une fenêtre de retard. Pour chacun, on note s’il existe dans la destination, avec quelles métadonnées WORM et dans quel délai.

La dernière vérification porte sur le chiffrement. Object Lock ne protège pas contre la perte ou la suppression de la clé de chiffrement : AWS indique que des objets immuables peuvent devenir illisibles si la clé KMS correspondante est supprimée. Une sauvegarde peut ainsi survivre à un DELETE tout en échouant à la lecture. Le test doit donc restaurer un objet chiffré depuis la destination, puis contrôler la gouvernance du cycle de vie de la clé, les identités autorisées à l’utiliser et la capacité à récupérer le secret depuis le périmètre de reprise.

À la fin de ce scénario, l’équipe doit pouvoir produire une carte simple : copie primaire, copie distante, état de la réplication, délai acceptable, versions protégées, clés disponibles et procédure de restauration lorsque la région principale est inaccessible. Si l’un de ces éléments dépend encore d’un service situé dans la région perdue, la limite doit être écrite, pas laissée à l’interprétation.

7. Transformer les résultats en preuve de résilience

Une bonne campagne de test ne se termine pas par la mention « conforme » dans un tableur. Elle laisse une trace qui permet de refaire l’expérience après une modification de rôle, de fournisseur, de politique Lifecycle ou de topologie de réplication. Pour chaque scénario, conservez l’identité utilisée, l’objet ou le jeu de données concerné, la configuration avant test, l’action effectuée, le message de refus ou de succès, les journaux d’audit et le résultat de lecture ou de restauration.

La grille peut rester concise si elle sépare clairement les questions. Le verrou porte-t-il sur la version attendue ? Un compte compromis peut-il réduire la durée ? Une suppression logique masque-t-elle encore une donnée récupérable ? La date d’expiration produit-elle le comportement prévu ? La clé de chiffrement est-elle disponible indépendamment du système de production ? La destination régionale possède-t-elle ses propres protections ? Enfin, une restauration complète et une restauration partielle ont-elles été exécutées avec des droits et des outils réellement disponibles en crise ?

Les écarts ne doivent pas être traités comme des détails de configuration. Si le mode Gouvernance est contournable, la permission correspondante doit devenir un accès exceptionnel surveillé. Si les delete markers perturbent le catalogue, la procédure de restauration doit rechercher les versions. Si la réplication est asynchrone, le plan doit définir la perte de données acceptable et la manière de mesurer le retard. Si les clés KMS sont dans le même périmètre de panne, leur séparation et leur récupération deviennent un chantier prioritaire.

La fréquence des tests dépend du rythme de changement, mais le principe est stable : une sauvegarde qui n’a pas été restaurée récemment reste une hypothèse. La CISA insiste sur les tests réguliers de restauration ; cette recommandation est probablement la plus pragmatique du dispositif. Elle force l’organisation à confronter la politique WORM au catalogue, aux droits, aux dépendances réseau, aux clés et au temps réellement disponible.

Le résultat recherché n’est pas une promesse absolue. Aucun mécanisme unique ne couvre simultanément l’effacement, la compromission des identifiants, la perte d’une région, l’indisponibilité d’une clé et l’absence de procédure. Une sauvegarde cloud immuable devient crédible lorsque ses limites sont connues, ses accès sont séparés, sa réplication est vérifiée et sa restauration produit régulièrement une preuve exploitable.

Conclusion

Le mot « immuable » décrit une propriété technique précise, pas un état général de sécurité. Dans un stockage WORM, une version peut être protégée pendant une période déterminée, tandis qu’un marqueur de suppression, une destination mal configurée ou une clé perdue compromet la récupération. C’est cette différence entre l’objet verrouillé et le système de sauvegarde complet qui mérite l’attention.

La méthode la plus fiable est donc empirique : tenter de raccourcir la rétention avec un compte compromis, supprimer un objet et rechercher ses versions, simuler un ransomware, observer l’expiration, restaurer un sous-ensemble, puis couper l’accès à une région et vérifier la copie distante. Chaque scénario doit produire une preuve et faire émerger une limite assumée.

Une équipe qui connaît ces réponses ne se contente pas de posséder une sauvegarde cloud immuable. Elle sait ce qui survivra, ce qui sera encore lisible, qui pourra le restaurer et dans quel délai. En situation de crise, cette précision vaut davantage qu’un simple badge « WORM activé ».

Équipe Daymain