Sauvegarde immuable Proxmox : protéger ses backups du ransomware en 2026

D’après le State of Ransomware 2024 de Sophos, 94 % des attaques par ransomware tentent désormais de compromettre les sauvegardes avant de chiffrer la production, et 57 % de ces tentatives réussissent à détruire ou chiffrer au moins une partie des backups. Pour une équipe IT qui s’appuie sur Proxmox Backup Server, le constat est sans appel : un backup qui peut être effacé par un attaquant disposant d’un compte d’administration n’est plus un backup en 2026, c’est un fichier comme les autres.

Cet article décrit ce qu’est concrètement une sauvegarde immuable dans le contexte Proxmox, les mécanismes que PBS expose pour la mettre en œuvre, la façon dont Cloud-PBS livre cette immuabilité par datastore isolé à ses clients, et l’évolution prévue de l’offre vers un palier air-gapped sur bande LTO ouvert d’abord aux clients français à partir du troisième trimestre 2026.

Pourquoi le ransomware cible en priorité les sauvegardes

Le scénario d’attaque a profondément changé entre 2018 et 2025. À l’époque, un ransomware classique chiffrait les fichiers visibles sur le poste contaminé puis tentait de se propager latéralement. La rançon se négociait sur la donnée chiffrée. Aujourd’hui, un ransomware sérieux (LockBit 4, Akira, Play, BlackBasta) suit un manuel beaucoup plus discipliné : intrusion initiale par phishing ou faille externe, escalade vers un compte Domain Admin sous 24 à 72 heures, recherche du serveur de sauvegarde, destruction ou chiffrement des backups, exfiltration de données pour double extorsion, puis seulement chiffrement de la production.

Pourquoi cet ordre ? Parce que la valeur de négociation pour l’attaquant est exactement proportionnelle à votre incapacité à restaurer. Si vos sauvegardes sont accessibles, fonctionnelles et récentes, vous payez 0 €. Si vos sauvegardes sont détruites, vous payez le montant qui vous permet d’éviter une faillite. Le calcul est limpide.

L’erreur la plus courante observée chez les clients qui nous appellent en remédiation est la suivante : un Proxmox Backup Server installé sur le même réseau d’administration que les nœuds Proxmox VE qu’il protège, accessible via le même Domain Admin que le reste du domaine Active Directory ou LDAP. Une fois cet admin compromis, l’attaquant se connecte simplement en SSH au PBS, lance un proxmox-backup-manager prune agressif sur tous les datastores, supprime les VM templates et reboote la machine. La sauvegarde est partie. La production sera chiffrée le soir même.

Une sauvegarde immuable casse cette chaîne d’attaque à un endroit précis : le moment où l’attaquant essaie de supprimer ou modifier les snapshots de backup avec les privilèges qu’il a obtenus.

Ce qu’est vraiment une sauvegarde immuable

Le terme “immuable” est galvaudé par le marketing. Techniquement, une sauvegarde est immuable si elle satisfait deux propriétés : elle ne peut pas être modifiée après écriture (Write Once Read Many, WORM), et elle ne peut pas être effacée avant l’expiration d’un délai de rétention défini hors du périmètre que peut compromettre l’attaquant. C’est la deuxième condition qui distingue une vraie immuabilité d’une fausse.

Trois couches peuvent fournir cette propriété :

1. L’immuabilité applicative, gérée par l’outil de backup lui-même via des permissions qui empêchent le compte d’écriture de supprimer ce qu’il a écrit. C’est la couche que PBS expose nativement par son modèle de propriété et de privilèges par datastore.
2. L’immuabilité stockage, fournie par la couche infrastructure : ZFS avec snapshots immuables et destruction interdite par ACL, S3 Object Lock en mode Compliance, repository Linux durci type Veeam Hardened Repository, ou volumes WORM dédiés.
3. L’immuabilité hors ligne, le tier ultime : la donnée vit sur un média physiquement déconnecté la plupart du temps, typiquement bande LTO en coffre, ou datastore isolé électriquement air-gapped. Aucune attaque réseau ne peut l’atteindre par construction.

La règle 3-2-1-1-0 que recommandent l’ANSSI, le NCSC britannique et le CISA américain consolide ces couches : trois copies des données, sur deux supports différents, avec une copie hors site, une copie hors ligne ou immuable, et zéro erreur de vérification. Le “1” qui a été ajouté à la règle 3-2-1 historique est exactement le tier immuable. Les obligations de l’article 21 de la directive NIS2, transposée en droit français en 2025, vont dans le même sens : sauvegardes capables de résister à une compromission interne, tests de restauration documentés, conservation dans l’Union européenne.

Les mécanismes d’immuabilité dans Proxmox Backup Server

Proxmox Backup Server n’est pas un produit propriétaire avec un bouton “immutability mode” comme on en trouve chez Veeam ou Rubrik. C’est un moteur de sauvegarde Open Source qui expose plusieurs primitives, et c’est la combinaison de ces primitives qui produit l’immuabilité réelle.

Le modèle de propriété et le owner-check. Chaque snapshot écrit dans un datastore PBS est marqué avec un owner, qui est le compte ayant créé le snapshot. Lors d’une opération d’écriture ou de suppression, PBS vérifie que le compte qui demande l’opération est bien le propriétaire du snapshot ou dispose d’un privilège supérieur (Datastore.Modify). C’est ce contrôle qui produit l’erreur classique backup owner check failed quand un compte tente d’écraser un snapshot qui ne lui appartient pas.

La séparation des privilèges. PBS distingue six privilèges sur un datastore : Datastore.Audit (lecture des métadonnées), Datastore.Backup (création de snapshots), Datastore.Read (téléchargement et restauration), Datastore.Verify (vérification d’intégrité), Datastore.Modify (modification de la configuration), Datastore.Prune (suppression). Un compte qui ne dispose que de Datastore.Backup peut créer des sauvegardes mais ne peut pas les supprimer ni modifier le datastore. Cette séparation est la base de l’immuabilité applicative côté PBS.

Le chiffrement client-side AES-256. Avant l’envoi vers le datastore, le client proxmox-backup-client ou le module backup de Proxmox VE peut chiffrer chaque chunk avec une clé conservée côté client. La clé n’est jamais transmise au serveur. Un attaquant qui compromet le serveur PBS sans la clé n’a accès qu’à des chunks chiffrés inutilisables. Le détail d’activation se trouve dans le guide d’activation du chiffrement de la documentation Cloud-PBS.

La vérification cryptographique. PBS calcule un hash SHA-256 de chaque chunk à l’écriture, et la commande proxmox-backup-manager verify rejoue ces hash périodiquement. Si un chunk a été altéré sur disque, la vérification échoue et le snapshot concerné est marqué comme corrompu. C’est la garantie d’intégrité chunk par chunk, et c’est elle qui permet d’atteindre le “0” de la règle 3-2-1-1-0 : zéro erreur de vérification.

Les snapshots ZFS du datastore. Quand le datastore PBS vit sur un dataset ZFS, des snapshots ZFS périodiques (gérés par sanoid ou par un script cron simple) ajoutent une couche d’immuabilité sous le niveau PBS. Même si un attaquant parvient à effacer un snapshot PBS, le snapshot ZFS du datastore le préserve et il peut être restauré par rollback. Cette couche n’est pas activée par défaut côté Proxmox, c’est une convention d’opérateur.

Comment Cloud-PBS livre l’immuabilité par datastore

L’architecture Cloud-PBS s’appuie sur ces primitives PBS et les assemble en un service livré clé en main. Quatre choix de design produisent l’immuabilité applicative observable côté client.

Isolation par tenant. Chaque client Cloud-PBS dispose de son propre datastore PBS, dans son propre tenant. Il n’y a pas de mutualisation au niveau du datastore. Un compte client n’a aucune visibilité sur les datastores des autres tenants. Sur les plans Dedicated, l’isolation va jusqu’à une instance PBS dédiée par client, opérée par notre plan de contrôle.

Le compte de service ne peut pas effacer par défaut. Le client dispose de la possibilité de créer plusieurs types de token API. Concrètement, le job de sauvegarde de votre Proxmox VE écrit chaque nuit dans le datastore Cloud-PBS, et un attaquant qui aurait compromis votre PVE et récupéré ce token ne peut pas l’utiliser pour supprimer les snapshots existants si vous avez utilisez la permission “Datastore Backup”. Tout ce que pourra faire l’attaquant sera ajouter des données, ce qui saturera le quota mais n’effacera rien de l’historique.

La rétention est pilotée côté Cloud-PBS. La politique de prune et de garbage collection est appliquée par notre couche d’orchestration, et par défaut pas par votre PVE. Elle vit dans un plan de contrôle isolé du périmètre que votre attaquant peut compromettre. Si vous avez souscrit une rétention 14 jours quotidiens + 4 semaines + 6 mois, ces snapshots restent disponibles indépendamment de ce qui se passe sur votre infrastructure pendant cette fenêtre de rétention.

Régions UE et chiffrement client. Les régions France et Allemagne sont opérées exclusivement chez des opérateurs européens, sous droit européen. Combiné avec le chiffrement client-side AES-256, cela signifie que ni Cloud-PBS, ni un opérateur datacenter, ni une juridiction tierce ne peut accéder en clair à vos sauvegardes. C’est la propriété recherchée à la fois pour le RGPD article 32 et pour NIS2 article 21.

L’effet combiné de ces quatre choix produit, côté client, une immuabilité applicative qui résiste au scénario d’attaque type décrit en début d’article : un Domain Admin compromis sur votre PVE ne peut pas effacer vos backups Cloud-PBS, point.

Checklist : 10 contrôles immuables sur une infra Proxmox

À adapter à votre périmètre. Si vous cochez moins de 7 sur 10, votre niveau d’immuabilité réelle est inférieur à ce que vous croyez.

1. Le serveur PBS n’est pas administré avec le même Domain Admin que la production. Comptes locaux ou domaine séparé.
2. Le compte d’API utilisé par les jobs de sauvegarde n’a pas Datastore.Prune ni Datastore.Modify sur le datastore cible.
3. L’API token est stocké dans le keyring du nœud PVE et non en clair dans /etc/vzdump.conf.
4. Les clés de chiffrement client AES-256 sont sauvegardées hors ligne, pas seulement sur le PVE qui chiffre.
5. proxmox-backup-manager verify tourne au moins une fois par semaine, avec alerte si un snapshot échoue.
6. La rétention est définie sur le serveur PBS (côté Cloud-PBS pour les clients managés), pas sur le client PVE.
7. MFA activé sur l’interface web PBS pour tous les comptes humains.
8. Sync job vers une seconde cible (autre datastore, autre site, autre opérateur) pour matérialiser le “1 hors site” de 3-2-1-1-0.
9. Test de restauration documenté trimestriel, avec une VM de test restaurée intégralement et bootée.
10. Une copie immuable ou hors ligne existe pour la production critique : snapshots ZFS dédiés du datastore, S3 Object Lock, ou tier air-gapped (voir section suivante).

Les neuf premiers points sont accessibles sur n’importe quel environnement Proxmox, en self-hosted comme en managé. Le dixième est celui où l’on bascule du palier “immuabilité applicative” au palier “immuabilité physique”, et c’est là que se situe le prochain mouvement de Cloud-PBS.

Bientôt : Cloud-PBS air-gapped sur bande LTO, accès anticipé clients français

L’immuabilité applicative et l’isolation par datastore couvrent le scénario d’attaque externe le plus courant. Elles ne couvrent pas deux scénarios extrêmes : un opérateur cloud lui-même compromis (chaîne d’approvisionnement, employé malveillant, contrainte juridique étrangère), et une attaque persistante avancée capable de patienter jusqu’à expiration de la rétention. Pour ces deux cas, il faut un tier physique : la donnée doit vivre la plupart du temps sur un média non connecté.

Cloud-PBS prépare pour le troisième trimestre 2026 un palier d’archivage long terme baptisé Sauvegarde hors ligne, structuré autour de bandes LTO en coffre datacenter. Le principe est conforme à 3-2-1-1-0 strict : la copie air-gapped est écrite sur LTO via un robot dédié, sortie du robot après écriture, conservée en armoire ignifugée à accès tracé, et remontée sur demande pour restauration ponctuelle ou test de récupération.

L’accès anticipé est ouvert d’abord aux clients français pour deux raisons. La première est commerciale : la conformité NIS2 transposée en droit français rend la copie hors ligne pratiquement obligatoire pour les opérateurs essentiels et importants, et la demande est prioritaire sur ce marché. La seconde est logistique : le coffre LTO est physiquement situé en France, et opérer un cycle d’écriture, sortie, réinsertion dans un délai compatible avec un PRA exige une proximité géographique avec les équipes d’exploitation au démarrage du service.

L’extension Allemagne est prévue dans la foulée, sur le même schéma avec un site partenaire à Francfort. L’extension États-Unis arrivera plus tard, conditionnée à la maturité du dispositif côté UE et à la demande exprimée.

Concrètement, pour un client Cloud-PBS existant, le tier air-gapped se présentera comme un sync job supplémentaire depuis votre datastore PBS managé vers la cible LTO, avec une grille tarifaire à l’unité de To et à la fréquence d’archivage. Pour une demande d’inscription en accès anticipé, le formulaire de contact accepte la mention “early access LTO” en sujet, et les premières installations démarreront au cours du troisième trimestre 2026.

Conclusion : l’immuabilité n’est plus un confort, c’est un prérequis

En 2026, une stratégie de sauvegarde Proxmox sans couche immuable vérifiable n’est plus une stratégie défendable face au profil de menace actuel. Les chiffres du State of Ransomware 2024 et la jurisprudence des incidents publics récents le confirment : ce n’est pas la production qui décide de la survie de l’entreprise après une attaque, c’est la qualité opérationnelle des sauvegardes au moment de la restauration.

Proxmox Backup Server fournit les primitives techniques nécessaires pour construire cette couche immuable, et les opérateurs sérieux les assemblent en un service géré. Cloud-PBS livre aujourd’hui l’immuabilité applicative par datastore isolé, conforme NIS2 article 21, dans des régions UE souveraines. Le palier supérieur, l’air-gapped LTO, ouvre en accès anticipé pour les clients français au troisième trimestre 2026.

Pour évaluer votre niveau d’immuabilité actuel ou discuter de l’ouverture d’un compte Cloud-PBS avec rétention longue, contactez-nous ou consultez la page tarifs.