Sauvegarde immuable : protéger son VPS des ransomwares

Un ransomware ne se contente plus de chiffrer les données de production. Lorsqu’un attaquant obtient des privilèges suffisants sur un VPS, un serveur dédié ou un compte d’administration, il cherche aussi à supprimer les snapshots, les archives distantes et les sauvegardes accessibles depuis la machine compromise. Une politique de sauvegarde classique, même automatisée et quotidienne, ne suffit donc pas toujours à préserver la capacité de reprise.

La sauvegarde immuable répond à ce risque : pendant une durée définie, les objets sauvegardés ne peuvent ni être modifiés ni supprimés, y compris si les identifiants utilisés pour envoyer les sauvegardes sont compromis. Elle ne remplace ni le durcissement du serveur ni la supervision, mais elle limite fortement l’impact opérationnel d’une compromission.

Pour un administrateur de VPS ou de serveur dédié, l’enjeu est pragmatique : disposer d’au moins une copie récupérable après un incident grave, sans rendre l’exploitation quotidienne inutilement complexe. Cela passe par un stockage correctement verrouillé, une séparation des accès, une rétention cohérente et des tests de restauration réels.

Pourquoi une sauvegarde classique ne suffit plus face aux ransomwares

Une sauvegarde est utile uniquement si elle est disponible, intègre et restaurable au moment où l’incident survient. Or, de nombreux environnements modestes concentrent les droits sur une même machine ou un même compte : le VPS héberge l’application, exécute le script de sauvegarde et possède une clé API donnant accès au stockage distant. Cette organisation est simple, mais elle crée un point de défaillance évident.

Un attaquant qui prend le contrôle du serveur avec les droits root, ou qui récupère les secrets présents dans les variables d’environnement, fichiers de configuration ou dépôts Git, peut notamment :

chiffrer les volumes locaux et les fichiers de sauvegarde présents sur le serveur ;
supprimer les archives distantes si la clé possède des autorisations de suppression ;
effacer ou dégrader des snapshots accessibles depuis le même compte d’hébergement ;
modifier les tâches planifiées, les scripts cron ou les pipelines afin de remplacer les bonnes sauvegardes par des données chiffrées ;
voler les données avant chiffrement, ce qui transforme l’incident en problème de disponibilité, de confidentialité et parfois de conformité.

Un snapshot de disque reste très utile pour une erreur de manipulation, une mise à jour ratée ou une panne logique récente. Mais il ne doit pas être considéré automatiquement comme une sauvegarde anti-ransomware. Sa valeur dépend de son emplacement, de ses droits de suppression, de sa durée de conservation et du cloisonnement entre le serveur de production et le compte qui l’administre.

Il faut également distinguer la disponibilité et la sauvegarde. La réplication d’une base de données, un volume répliqué ou un cluster haute disponibilité peuvent répliquer rapidement une corruption ou un chiffrement. Ces mécanismes réduisent une interruption de service ; ils ne garantissent pas un retour à un état antérieur sain.

Avant de revoir l’architecture de sauvegarde, commencez par vérifier les fondations de sécurité du serveur. Les mesures de base détaillées dans notre guide pour sécuriser un serveur Linux restent indispensables : mises à jour, accès SSH contrôlé, comptes limités, pare-feu, journalisation et supervision. Une sauvegarde immuable est une ceinture de sécurité, pas une autorisation implicite à négliger la prévention.

Immutabilité, air gap et règle 3-2-1-1-0 : les notions essentielles

Une sauvegarde immuable est une sauvegarde soumise à une règle de conservation qui interdit sa modification et/ou sa suppression pendant une période donnée. Dans le stockage objet compatible S3, cette fonction est généralement appelée Object Lock. Selon le service, elle s’appuie sur la gestion des versions et sur une date de rétention attachée aux objets ou à leurs versions.

Il est important de ne pas confondre immutabilité et chiffrement. Le chiffrement protège la confidentialité des archives si un support ou un compte de stockage est exposé. L’immuabilité protège leur intégrité et leur disponibilité contre une suppression ou une altération prématurée. Une stratégie robuste a besoin des deux.

Les modes de rétention à comprendre

Les implémentations S3 Object Lock distinguent habituellement deux logiques :

Governance : la suppression avant l’échéance est bloquée pour les utilisateurs ordinaires, mais une identité disposant d’une autorisation spécifique peut contourner le verrouillage. Ce mode peut convenir à certains usages opérationnels, à condition que le droit de contournement soit très fortement restreint.
Compliance : la rétention ne peut pas être raccourcie ou contournée avant son terme, y compris par un administrateur du compte selon les règles du service. Ce mode offre une protection plus forte, mais une erreur de durée peut entraîner des coûts de stockage impossibles à réduire avant l’échéance.

Le legal hold, lorsqu’il est proposé, fonctionne différemment : il bloque la suppression sans date de fin prédéfinie, jusqu’à sa levée explicite. Il est surtout adapté à une obligation légale ou à une enquête, pas nécessairement à la rotation quotidienne des sauvegardes.

L’air gap désigne une séparation entre la production et une copie de sauvegarde. Dans un contexte VPS, il est souvent logique plutôt que physique : autre compte cloud, autre tenant, autre fournisseur, identifiants distincts et accès d’administration séparés. Une copie déconnectée physiquement existe aussi, mais elle est moins simple à automatiser. L’objectif est qu’une compromission de la production ne donne pas immédiatement le pouvoir de détruire la dernière copie saine.

La règle 3-2-1-1-0 comme cadre de décision

La règle 3-2-1 est connue : conservez trois copies des données, sur deux types de supports, dont une hors site. La variante 3-2-1-1-0 ajoute une copie hors ligne ou immuable, puis zéro erreur après vérification de la sauvegarde et de la restauration.

Il ne s’agit pas d’une certification ni d’une promesse d’invulnérabilité. C’est un cadre utile pour poser les bonnes questions. Pour une application hébergée sur un VPS, on peut par exemple avoir :

les données de production sur le volume principal ;
une sauvegarde locale de courte durée, utile pour une restauration rapide ;
une archive chiffrée dans un stockage objet distinct ;
une version immuable de cette archive pendant une durée définie ;
un contrôle automatisé et un exercice de restauration périodique.

La copie immuable doit être suffisamment ancienne pour précéder la compromission, mais pas seulement. Beaucoup de ransomwares restent discrets avant de chiffrer. Une rétention trop courte peut donc ne conserver que des données déjà altérées. La durée adaptée dépend du délai de détection réaliste de votre organisation, de vos contraintes réglementaires et du budget.

Choisir un stockage objet verrouillable et bien isolé

Le stockage objet est souvent une solution adaptée aux sauvegardes de VPS et de serveurs dédiés : il est accessible via API, se prête à l’automatisation et peut proposer des mécanismes d’immuabilité. Amazon S3 propose S3 Object Lock. Backblaze B2 propose Object Lock. MinIO, qui peut être déployé sur une infrastructure maîtrisée, propose également des fonctions de verrouillage d’objets compatibles avec l’approche S3. Les capacités précises, les modes disponibles et les conditions d’activation doivent toutefois être vérifiés dans la documentation du fournisseur retenu avant tout déploiement.

Le choix ne doit pas se limiter au tarif du gigaoctet. Vérifiez au minimum les points suivants :

la prise en charge explicite de l’immuabilité ou d’Object Lock ;
la possibilité d’activer le verrouillage avant l’envoi des premières archives ;
la localisation des données, vos exigences de souveraineté et vos obligations contractuelles ;
les coûts de stockage, de requêtes et de sortie de données lors d’une restauration complète ;
la gestion des versions, du cycle de vie et de la rétention ;
la disponibilité d’une journalisation des accès et des opérations d’administration ;
la possibilité d’utiliser des comptes, rôles ou clés d’accès distincts.

Attention à un point récurrent : une règle de cycle de vie conçue pour supprimer les anciennes versions peut entrer en conflit avec une période de rétention immuable. Les règles de conservation ne doivent pas être paramétrées indépendamment. Il faut documenter l’ordre logique : durée de rétention minimale, durée de conservation totale, puis politique de suppression après expiration.

Pour limiter le risque lié au fournisseur ou au compte principal, une organisation peut conserver une copie secondaire dans un autre environnement. Cela n’implique pas forcément deux clouds publics : un stockage objet séparé, administré via un compte distinct et protégé par une authentification multifacteur, constitue déjà une amélioration notable par rapport à un bucket administré avec les mêmes identifiants que le VPS.

Mettre en place une sauvegarde immuable sur un VPS ou serveur dédié

La méthode la plus fiable consiste à séparer les responsabilités : l’identité présente sur le serveur doit pouvoir écrire une sauvegarde, mais elle ne doit pas pouvoir supprimer les sauvegardes existantes, modifier la politique de rétention ni administrer le compte de stockage.

1. Définir précisément ce qui doit être sauvegardé

Une image complète du serveur peut être utile, mais elle n’est pas toujours nécessaire ni suffisante. Identifiez les composants qui permettent réellement de reconstruire le service :

base de données et journaux nécessaires à une restauration cohérente ;
fichiers utilisateurs, médias et documents métier ;
configurations applicatives et infrastructure as code ;
secrets nécessaires à la restauration, avec un stockage séparé et contrôlé ;
configuration DNS, certificats, règles de pare-feu et paramètres du service lorsque leur recréation est coûteuse.

Pour PostgreSQL, des outils comme pg_dump ou pg_basebackup répondent à des besoins différents. Pour MariaDB ou MySQL, mariadb-dump ou mysqldump peuvent produire des exports logiques. Le choix dépend du volume, du temps de restauration acceptable et du besoin éventuel de restauration à un instant donné. Un simple archivage des fichiers de données d’une base active n’est pas nécessairement cohérent.

Les outils de sauvegarde généralistes tels que restic, BorgBackup ou Kopia peuvent gérer chiffrement, déduplication et rétention selon leur configuration et leur dépôt cible. Avant de les associer à une politique d’immuabilité, consultez leur documentation ainsi que celle du stockage : le comportement des suppressions, des verrous et des versions doit être compris de bout en bout.

2. Créer des identités séparées

Évitez d’utiliser le compte propriétaire du stockage, ou une clé administrateur, dans un script exécuté sur le VPS. Créez une identité dédiée à l’écriture des sauvegardes. Accordez-lui le minimum d’autorisations nécessaires sur un emplacement précis. En particulier, examinez avec attention les droits de suppression, de modification de politique, de gestion de rétention et de contournement du mode governance.

Le compte d’administration du stockage doit être distinct, protégé par authentification multifacteur et utilisé uniquement pour les opérations exceptionnelles : création du bucket, revue des règles, audit, ou procédure de restauration. Les identifiants d’envoi de sauvegarde doivent être stockés hors du code source, avec des permissions de fichiers restrictives. Une rotation planifiée des clés réduit l’exposition, mais elle doit être documentée : une clé révoquée sans mise à jour du serveur peut interrompre les sauvegardes silencieusement.

3. Activer l’immuabilité puis automatiser l’envoi

Configurez le bucket ou le dépôt avec une politique de verrouillage avant la mise en production. Définissez ensuite une rétention adaptée aux jeux de données. Une base de données critique peut demander des points de restauration fréquents et une conservation plus longue que des fichiers statiques reproductibles depuis un dépôt de code.

Le script d’automatisation doit produire des journaux exploitables et retourner un code d’erreur en cas d’échec. Un cron qui lance une commande sans alerte n’est pas un contrôle suffisant. Envoyez les résultats vers un outil de supervision, une boîte de réception dédiée ou un système d’alerting. Les approches de supervision présentées dans notre article sur le monitoring serveur selon l’infrastructure peuvent aider à suivre les échecs, l’espace disponible et l’âge de la dernière sauvegarde valide.

Enfin, ne supprimez pas automatiquement les archives locales avant d’avoir confirmé que l’envoi distant est terminé et vérifiable. Une sauvegarde locale à très court terme peut accélérer une restauration, mais elle ne remplace pas la copie immuable distante.

Rétention, chiffrement et coûts : trouver un équilibre réaliste

Une rétention immuable trop faible réduit la protection ; une rétention excessive consomme du stockage et peut immobiliser des données devenues inutiles. Il n’existe pas de durée universelle. Commencez par qualifier vos données et vos objectifs.

Le RPO (Recovery Point Objective) correspond à la quantité de données que vous acceptez de perdre entre deux sauvegardes. Le RTO (Recovery Time Objective) correspond au temps maximal acceptable pour remettre le service en état. Ces deux objectifs influencent directement la fréquence, le format et la localisation des sauvegardes.

Exemple concret : un site vitrine dont le contenu change rarement n’a pas les mêmes exigences qu’une boutique qui enregistre des commandes toute la journée. Pour le premier, une sauvegarde quotidienne peut être cohérente. Pour le second, il peut être nécessaire de sauvegarder la base plus souvent et de prévoir une procédure de restauration testée capable de remettre en ligne les composants essentiels dans le délai attendu.

Chiffrez les archives avant ou pendant leur envoi, mais traitez la gestion des clés comme un composant critique. Si la seule clé de déchiffrement réside sur le VPS compromis, la sauvegarde peut être inutilisable. Si elle est stockée dans le même compte cloud avec des droits d’administration trop larges, l’attaquant peut aussi la supprimer ou la remplacer. Conservez une procédure documentée et protégée pour récupérer les secrets de restauration, avec un accès réservé aux personnes habilitées.

Une sauvegarde immuable mal chiffrée expose potentiellement les données. Une sauvegarde chiffrée dont la clé est perdue protège très bien des données devenues impossibles à restaurer. La sécurité repose sur l’équilibre entre ces deux risques.

Pour maîtriser les coûts, mesurez le volume réel, le taux de changement quotidien et la durée de conservation avant de choisir une politique définitive. Prenez aussi en compte le coût d’une restauration : récupérer plusieurs téraoctets depuis un stockage objet peut prendre du temps et générer des frais selon le fournisseur. Une stratégie de GreenOps appliquée aux serveurs peut aussi aider à éliminer les données inutiles à la source, sans sacrifier les sauvegardes réellement nécessaires.

Tester la restauration : le seul contrôle qui compte vraiment

Une tâche de sauvegarde réussie ne prouve pas qu’une restauration réussira. Le fichier peut être incomplet, la clé de chiffrement indisponible, la base incohérente ou la documentation insuffisante. La partie « 0 » de la règle 3-2-1-1-0 impose justement de vérifier l’absence d’erreurs après les contrôles de récupération.

Planifiez des tests à intervalles réguliers et après toute modification importante : changement d’outil, migration de base, nouvelle version d’application, modification des droits IAM ou changement de fournisseur. Effectuez ces restaurations dans un environnement isolé afin de ne pas écraser la production.

Un test utile va au-delà du téléchargement d’une archive. Il doit vérifier, selon votre service :

que l’archive sélectionnée est antérieure à un scénario de compromission simulé ;
que le déchiffrement fonctionne avec les clés prévues ;
que les données sont complètes et lisibles ;
que la base de données démarre et répond aux requêtes attendues ;
que l’application peut utiliser la base, les fichiers et sa configuration restaurés ;
que la procédure respecte le RTO annoncé ou révèle clairement les écarts ;
que les accès, les certificats et les paramètres réseau nécessaires au redémarrage sont documentés.

Conservez le résultat de chaque exercice : date, sauvegarde utilisée, durée, difficultés rencontrées et actions correctives. Cette documentation vaut autant que le script de sauvegarde lui-même lorsqu’un incident se produit à un moment de stress, avec plusieurs intervenants.

Adapter la stratégie à votre infrastructure

La meilleure architecture est celle que votre équipe peut maintenir, surveiller et restaurer. Un VPS unique n’a pas nécessairement besoin d’un dispositif aussi complexe qu’un parc de serveurs, mais il ne doit pas dépendre d’une seule copie administrable depuis la production.

Pour un VPS applicatif unique

Privilégiez une sauvegarde automatisée des données et configurations, chiffrée et envoyée vers un stockage objet distinct avec rétention immuable. Ajoutez une alerte sur l’échec des sauvegardes et sur l’absence de sauvegarde récente. Conservez les snapshots du fournisseur pour les incidents courts, sans les considérer comme l’unique mécanisme de reprise.

Pour un serveur dédié avec plusieurs services

Séparez les sauvegardes par périmètre : bases de données, volumes de fichiers, configurations et éventuellement machines virtuelles. Évitez qu’un unique script exécuté avec des privilèges étendus possède aussi les droits d’administration du stockage. Si vous virtualisez vos services, le choix de la plateforme et des sauvegardes doit être préparé avec soin ; notre dossier sur la migration vers Proxmox VE 9 rappelle l’importance de planifier les opérations d’infrastructure plutôt que de les improviser.

Pour une infrastructure conteneurisée

Ne limitez pas la sauvegarde aux images de conteneurs. Les données persistantes, les bases, les manifestes de déploiement, les secrets et les configurations d’entrée réseau sont souvent les éléments déterminants. La reconstruction d’un cluster ou d’une application doit être testée comme un scénario complet, en cohérence avec vos pratiques Kubernetes et votre gestion de configuration.

Conclusion : préparer la reprise avant l’incident

La sauvegarde immuable n’est pas un produit magique : elle est le résultat d’une architecture cohérente. Une copie verrouillée, hors du périmètre d’administration quotidien du VPS, réduit la capacité d’un ransomware à vous priver de toute solution de reprise. Des identifiants séparés, un chiffrement maîtrisé, une rétention adaptée et des tests de restauration transforment ce principe en protection opérationnelle.

Commencez par cartographier vos données critiques, votre dernier point de restauration acceptable et les droits réellement associés à vos sauvegardes. Puis réalisez un premier exercice de restauration sur un environnement isolé : c’est souvent le moyen le plus direct d’identifier les failles à corriger avant qu’un incident ne les révèle.