Sauvegarde 3-2-1 avec copies immuables : protection contre les ransomwares pas à pas

Ce que vous allez mettre en place

Les attaquants qui pénètrent dans un réseau essaient en général de supprimer ou de chiffrer les sauvegardes avant de chiffrer les serveurs. Une sauvegarde qu’un compte administrateur volé peut supprimer ne suffit donc pas. Ce guide construit avec BackupZit une protection en couches : une sauvegarde principale sur un stockage local, une copie dans un autre lieu et un stockage où les sauvegardes ne peuvent pas être détruites avant la fin d’une période définie, même avec les identifiants du stockage. BackupZit est gratuit et open source (AGPLv3) ; tout ce qui est décrit ici fait partie du produit gratuit.

• La règle 3-2-1
• 1. Stockage principal
• 2. Stockage immuable
• 3. Chiffrement
• 4. Tâche et rétention
• 5. Copie hors site
• 6. Tests de restauration
• 7. Alertes et détection
• 8. Protéger la console
• Après une attaque
• Limites

La règle 3-2-1, et 3-2-1-1-0

La règle 3-2-1 : 3 copies de vos données, sur 2 supports différents, dont 1 hors site. L’extension 3-2-1-1-0 ajoute 1 copie immuable ou hors ligne et 0 erreur lors de la vérification des sauvegardes. Dans BackupZit :

Il vous faut une console BackupZit avec des agents sur les machines à protéger ; les guides Proxmox VE, Hyper-V et images disque Windows montrent ces premières étapes.

Étape 1 — Stockage principal pour des restaurations rapides

Dans la console, ouvrez Stockage → Ajouter une cible de stockage. Pour la première copie, choisissez un stockage du réseau local, afin que sauvegardes et restaurations tournent à pleine vitesse : un partage SMB sur un serveur de fichiers ou un NAS, ou un serveur Linux ou NAS en SFTP (sa clé d’hôte est épinglée). Donnez à la cible un compte dédié qui ne peut écrire que dans le dossier des sauvegardes, et n’intégrez pas le stockage de sauvegarde au domaine Windows.

À l’enregistrement, la console teste aussitôt la cible — un mauvais mot de passe, une mauvaise clé d’hôte ou un mauvais partage apparaît maintenant et non à la première sauvegarde. Tester la connexion dans la liste des stockages refait le test.

Étape 2 — Ajouter un stockage immuable

BackupZit propose deux types de stockage où les sauvegardes ne peuvent être ni supprimées ni écrasées avant la fin de leur période. Idéalement, il est aussi hors site : une seule cible couvre alors les deux exigences.

Option A : S3 avec Object Lock

1. Créez le bucket avec Object Lock activé — sur AWS, Wasabi et Backblaze B2, une option à la création du bucket ; sur MinIO, mc mb --with-lock.
2. Ajoutez une règle de cycle de vie qui supprime les versions non courantes après un jour (MinIO : mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Supprimer une sauvegarde verrouillée ajoute seulement un marqueur de suppression ; la règle libère l’espace une fois les verrous expirés.
3. Dans la console, ajoutez une cible de type Compatible S3 (AWS, Wasabi, Backblaze B2, MinIO, …) avec le point de terminaison, le bucket et une clé d’accès pour ce bucket.
4. Cochez Sauvegardes immuables (S3 Object Lock, mode conformité) pendant … jours (30 par défaut) et choisissez une période au moins aussi longue que la rétention à protéger.

Chaque fichier écrit par les agents est alors verrouillé en mode conformité pour cette période plus un jour : personne — ni un attaquant muni des clés, ni le propriétaire du bucket — ne peut le supprimer ou l’écraser avant. Les données qu’une nouvelle sauvegarde réutilise depuis les anciennes voient leur verrou prolongé, si bien que chaque point de restauration est protégé pendant toute la période. Sur un stockage immuable, le test de connexion se contente de se connecter et de lister, et il vérifie que le bucket a bien Object Lock.

Option B : dépôt renforcé sur votre propre serveur Linux

Un serveur Linux dédié exécute backupzit-repo (les paquets deb et rpm sont joints à chaque version GitHub) :

apt install ./backupzit-repo_*.deb       # ou : dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env          # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console    # affiche la clé d’accès une seule fois
backupzit-repo fingerprint               # empreinte du certificat

Dans la console, ajoutez une cible de type Dépôt renforcé (backupzit-repo sous Linux, immuable) avec l’adresse du serveur (port 8500 par défaut), la clé d’accès et l’empreinte.

• Les agents et la console peuvent seulement ajouter des fichiers ; les fichiers existants ne sont jamais écrasés.
• Chaque fichier reçoit l’attribut immuable (chattr +i) pour la période définie sur ce serveur, plus un jour. Même root ne peut le supprimer sans retirer d’abord l’attribut.
• Les suppressions venant des clients — par la rétention ou par un attaquant muni de la clé d’accès — ne font que masquer les fichiers jusqu’à la fin de leur période.
• La période se règle uniquement sur le serveur du dépôt ; la console et les agents ne peuvent pas la modifier.

Après la mise en place, désactivez SSH et tout autre accès à distance sur ce serveur et protégez sa console locale, l’iDRAC/iLO ou l’accès à l’hyperviseur : la protection ne vaut que ce que vaut son compte root.

Étape 3 — Chiffrement et clé de récupération

Laissez Chiffrer les sauvegardes (AES-256) activé (par défaut). Le contenu des fichiers, leurs noms, l’arborescence et les listes d’instantanés sont chiffrés en AES-256-GCM avant de quitter l’agent, et toute modification des données est détectée. L’immuabilité empêche la suppression, le chiffrement empêche la lecture — il vous faut les deux.

Pour chaque cible chiffrée, la console affiche une Clé de récupération et propose une fiche de récupération. Conservez-la hors ligne et à l’écart des sauvegardes : avec la clé, l’emplacement du stockage et ses identifiants, vous pouvez restaurer même sans la console ; sans la clé, personne ne peut lire les sauvegardes — pas même le support BackupZit.

Étape 4 — Tâche de sauvegarde et rétention

Créez la tâche sous Tâches de sauvegarde avec le stockage principal de l’étape 1. Sous Conserver les sauvegardes, réglez les N plus récentes ainsi que des points de restauration quotidiens, hebdomadaires et mensuels — par exemple 3 récentes, 7 quotidiennes, 4 hebdomadaires et 6 mensuelles gardent environ six mois avec une vingtaine de points de restauration. La déduplication ne stocke qu’une fois les données inchangées.

Objectif de point de récupération (RPO), heures indique l’âge maximal de la dernière bonne sauvegarde, p. ex. 26 pour une tâche quotidienne. Une tâche qui le dépasse apparaît sur le tableau de bord et est signalée, ce qui repère aussi un agent hors ligne depuis des jours ou une planification supprimée par erreur.

Étape 5 — Copie hors site avec une tâche de copie

Créez une seconde tâche et choisissez Copie de sauvegarde. Sous Copier les sauvegardes de, sélectionnez la tâche de l’étape 4 et, comme Cible de stockage, la cible immuable ou hors site de l’étape 2.

• L’agent de la tâche source copie les sauvegardes existantes ; la machine protégée n’est pas relue.
• Seules les données absentes de la destination sont envoyées, rechiffrées avec la clé de la destination.
• Après chaque sauvegarde de la tâche source (par défaut) garde la copie à jour ; une planification normale fonctionne aussi, p. ex. une fois par nuit pour une ligne lente.
• La copie a sa propre rétention, p. ex. 7 quotidiennes sur le NAS et 12 mensuelles dans le cloud. Chaque point de restauration est verrouillé N jours à partir de sa création ; avec un verrou de 30 jours, les points mensuels plus anciens ne sont donc plus protégés. Un verrou plus long en protège davantage, mais occupe aussi plus de données.

Les sauvegardes de fichiers et de VM (Proxmox VE, Hyper-V, VMware) se restaurent depuis la copie comme depuis l’original ; les copies d’images disque avec l’agent en ligne de commande. Copier maintenant lance une copie immédiatement.

Étape 6 — Tests de restauration et vérification des données

Une sauvegarde n’est prouvée qu’une fois restaurée. Sous Paramètres → Tests de restauration :

• Tester automatiquement la sauvegarde la plus récente de chaque tâche (chaque semaine par défaut) : un échantillon aléatoire de fichiers de la sauvegarde la plus récente est restauré dans un dossier temporaire, vérifié octet par octet avec les sommes de contrôle stockées puis supprimé ; pour les images disque, des blocs aléatoires sont vérifiés. Cela éprouve l’accès au stockage, les identifiants, la clé et les données.
• Vérifier les données stockées (chaque mois par défaut) : chaque élément de données de chaque dépôt est lu et vérifié, ce qui révèle tôt un disque de NAS défaillant ou une corruption silencieuse. Sur S3 et Azure, la vérification ne tourne qu’avec Aussi sur le stockage cloud (S3, Azure) — elle télécharge tout, attention aux frais de téléchargement.
• Les tâches de VM Proxmox peuvent ajouter un test de démarrage qui lance chaque VM depuis la sauvegarde, réseau déconnecté.

Tester la restauration et Vérifier les données sur la page d’une tâche les lancent immédiatement. Les résultats apparaissent dans Activité et Rapports ; un test en échec envoie une alerte comme tout échec.

Étape 7 — Alertes et détection des ransomwares

Une copie hors site qui échoue depuis des semaines n’est pas une copie. Configurez Paramètres → Notifications par e-mail (vérifiez avec Envoyer un e-mail de test) et laissez Échecs activé : un e-mail par exécution échouée avec la raison — sauvegardes, copies, restaurations et tests de restauration — plus, si vous le souhaitez, un rapport quotidien. Paramètres → Chat et webhooks envoie la même chose vers Slack, Microsoft Teams ou n’importe quel point de terminaison HTTP. Sur le tableau de bord, Nécessite votre attention liste les tâches en échec, les planifications et RPO manqués, les agents hors ligne et les stockages pleins à 90 % ou qui le seront dans 30 jours.

Chaque sauvegarde est aussi comparée à l’historique récent de sa tâche. Elle est marquée suspecte quand bien plus de fichiers que d’habitude ont changé, que les nouvelles données ne se compressent plus (les fichiers chiffrés ressemblent à du hasard), que le nombre de fichiers a chuté d’un tiers ou plus ou que le volume de nouvelles données a brusquement augmenté. BackupZit envoie alors une alerte, la place sous sauvegardes suspectes à examiner et suspend la rétention de la tâche (La rétention est suspendue), afin que les dernières sauvegardes saines ne soient pas supprimées même si des sauvegardes endommagées continuent d’arriver. Après avoir vérifié la machine, cliquez sur Examiné — reprendre la rétention.

Étape 8 — Protéger la console

Le stockage immuable protège les sauvegardes ; la console décide toujours de ce qui est sauvegardé et conservé. Sous Paramètres → Connexion et sécurité, exigez l’authentification à deux facteurs pour les administrateurs et activez l’Approbation à quatre yeux : supprimer des tâches ou des cibles de stockage, raccourcir la rétention, reprendre la rétention après une sauvegarde suspecte et désactiver l’approbation exigent alors un second utilisateur. Gardez la console sur le réseau interne, ne publiez pas le port 8443 sur Internet et utilisez un VPN pour l’administration à distance. Avec Paramètres → Sauvegarde de la console, la console se sauvegarde aussi elle-même chaque jour sur une cible de stockage réseau.

Après une attaque

Si des sauvegardes ont été supprimées ou écrasées, lisez le stockage tel qu’il était avant l’attaque — en lecture seule, sur S3 avec Object Lock et sur le dépôt renforcé :

backupzit-agent snapshots --repo <dépôt> --as-of 2026-10-01T14:30
backupzit-agent restore   --repo <dépôt> --as-of 2026-10-01T14:30 --target D:\Restore latest

Sur un dépôt renforcé, l’administrateur peut aussi faire réapparaître les fichiers masqués, pour que les sauvegardes reprennent normalement :

backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00

Limites à connaître

• L’immuabilité ne dure que le temps du verrou. Une sauvegarde supprimée disparaît vraiment à la fin de sa période ; choisissez donc la période en fonction du temps pendant lequel une attaque pourrait passer inaperçue.
• Un dépôt renforcé n’est sûr que dans la mesure où son compte root et l’accès à sa console, à l’iDRAC/iLO ou à son hyperviseur le sont.
• SMB, SFTP et les disques locaux n’ont pas d’immuabilité propre ; combinez-les avec une copie immuable ou hors ligne.
• Les données verrouillées occupent de l’espace jusqu’à la fin du verrou, même après suppression ; sans la règle de cycle de vie, l’espace S3 n’est pas libéré.
• L’immuabilité ne nettoie pas les données : des fichiers chiffrés avant la sauvegarde sont sauvegardés chiffrés. Restaurez un point antérieur à l’attaque — la détection conserve ces points en suspendant la rétention.
• Sans la clé de récupération, personne ne peut lire les sauvegardes chiffrées.
• L’approbation à quatre yeux s’applique à la console ; les groupes d’administrateurs dans Active Directory ou Entra ID doivent être protégés là-bas.

Et ensuite

Téléchargez BackupZit, découvrez la protection contre les ransomwares et toutes les cibles de stockage, ou lisez les chapitres sur les cibles de stockage et la protection contre les ransomwares dans le guide intégré à la console. La façon dont BackupZit lui-même est conçu et publié figure sur la page sécurité. La mise en place des tâches est décrite dans les guides Proxmox VE, Hyper-V, Microsoft 365 et restauration bare-metal de Windows. Les questions sont les bienvenues dans les GitHub Discussions. Les entreprises peuvent obtenir un support commercial de MaxZit (en anglais uniquement).