# Sauvegardes immuables contre les rançongiciels : notre politique pour un parc > Un chiffrement malveillant qui toucherait aussi les sauvegardes rendrait un parc entier irrécupérable. Architecture de sauvegardes immuables mise en place pour s'en prémunir. - Auteur : Clément Hadrot - Publié le : 2025-12-17 - Mis à jour le : 2025-12-17 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/sauvegardes-immuables-contre-rancongiciels-politique-parc/ ## L’essentiel - Une sauvegarde accessible en écriture depuis le serveur de production est une sauvegarde vulnérable - L'immuabilité repose sur un verrou de rétention, pas seulement sur un accès distant - Le test de restauration reste indispensable même avec des sauvegardes immuables Un scénario a fini par obséder notre équipe technique après la lecture de plusieurs retours d'expérience d'agences touchées par des rançongiciels : que se passe-t-il si le compte qui exécute les sauvegardes nocturnes est lui-même compromis, et que l'attaquant, avant de chiffrer les fichiers de production, prend le temps de supprimer ou de corrompre également les sauvegardes accessibles depuis ce même compte ? Cet article ne revient pas sur le chiffrement des sauvegardes au repos, sujet distinct déjà traité en 2022. Il détaille l'architecture de sauvegardes immuables que nous avons mise en place pour un parc de sites clients, précisément pour répondre à ce scénario de compromission simultanée de la production et des sauvegardes. ## Le problème structurel des sauvegardes classiques Une architecture de sauvegarde classique, même bien chiffrée et stockée hors du serveur de production, reste vulnérable si le compte qui écrit les nouvelles sauvegardes dispose également des droits de suppression sur les anciennes. C'est très généralement le cas : le script de sauvegarde nocturne a besoin d'écrire de nouveaux fichiers, mais aussi, souvent, de purger les sauvegardes les plus anciennes pour respecter une politique de rétention. Ce même compte, s'il est compromis, peut donc tout aussi bien supprimer l'historique complet des sauvegardes avant que l'attaque ne soit détectée. L'immuabilité change ce rapport de force : une fois écrite, une sauvegarde ne peut plus être modifiée ni supprimée avant l'expiration d'une durée de rétention fixée à l'avance, même par le compte qui l'a créée, même par un compte administrateur du service de stockage lui-même dans certaines configurations. > L'essentiel à retenir : Une sauvegarde accessible en écriture depuis le serveur de production est une sauvegarde vulnérable ; L'immuabilité repose sur un verrou de rétention, pas seulement sur un accès distant ; Le test de restauration reste indispensable même avec des sauvegardes immuables ## Le verrou de rétention, mécanisme central Le mécanisme technique repose sur une fonctionnalité de type *Object Lock*, disponible sur les stockages compatibles S3 (dont plusieurs offres européennes comme Scaleway Object Storage ou OVHcloud Object Storage), en mode `COMPLIANCE` ou `GOVERNANCE`. En mode conformité, aucun compte, y compris administrateur du bucket, ne peut supprimer un objet avant l'expiration de la période de rétention configurée — une garantie forte, mais qui impose une vraie rigueur sur la durée choisie, puisqu'elle ne peut pas être raccourcie a posteriori. ``` aws s3api put-object --bucket sauvegardes-parc \ --key site-client/2025-12-17.sql.gz \ --body ./2025-12-17.sql.gz \ --object-lock-mode COMPLIANCE \ --object-lock-retain-until-date 2026-01-16T00:00:00Z ``` Chaque sauvegarde quotidienne est ainsi verrouillée pour trente jours à compter de sa création, une durée jugée suffisante pour détecter la quasi-totalité des scénarios d'attaque, y compris ceux où le chiffrement malveillant reste discret plusieurs semaines avant son déclenchement effectif. ## Un compte d'écriture qui ne peut pas lire ni lister Second principe de l'architecture : le compte technique qui exécute les sauvegardes nocturnes dispose uniquement d'un droit d'écriture (`s3:PutObject`) sur le bucket concerné, sans droit de suppression (`s3:DeleteObject`) ni même de liste complète du contenu existant. Même totalement compromis, ce compte ne peut ni supprimer les sauvegardes précédentes, ni les parcourir pour cibler une suppression sélective. - Le compte d'écriture des sauvegardes n'a aucun droit de suppression, quelle que soit la politique de rétention affichée. - Un compte distinct, utilisé uniquement en cas de restauration, dispose des droits de lecture nécessaires. - La purge des sauvegardes expirées est déclenchée par un compte tiers, distinct des deux précédents, exécuté sur une infrastructure séparée. ## Ce que l'immuabilité ne remplace pas Un verrou de rétention protège contre la suppression et la modification, pas contre l'absence de test de restauration. Une sauvegarde immuable mais corrompue dès l'écriture — par exemple si le chiffrement malveillant s'est déjà propagé aux fichiers avant leur sauvegarde — reste inutilisable au moment d'en avoir besoin, quelle que soit la solidité du verrou qui la protège. > L'immuabilité protège une sauvegarde de la suppression. Elle ne garantit jamais qu'elle soit exploitable. Ces deux propriétés se testent séparément, et aucune des deux ne dispense de l'autre. ## Le test de restauration reste non négociable Sur ce parc, un test de restauration complet est désormais exécuté mensuellement sur un environnement isolé, en remontant une sauvegarde choisie aléatoirement parmi les trente derniers jours disponibles. Ce test vérifie non seulement l'intégrité technique de l'archive, mais aussi la cohérence fonctionnelle du site restauré : connexion à l'administration, affichage correct des pages, absence d'erreurs PHP dans les journaux du site restauré. ## Ce qu'on en retient Une architecture de sauvegarde immuable ne dispense d'aucune des disciplines classiques de sauvegarde : elle ajoute une garantie contre un scénario précis, la suppression malveillante de l'historique, sans remplacer le chiffrement, la séparation des comptes ni le test de restauration régulier. C'est une couche supplémentaire, pas un substitut.