Configurer une sauvegarde restic résistante au ransomware

Parcours « Administrateur système » — étape 14/15

← 13Configurer une détection open source avec Wazuh15Tester une restauration après sinistre simulé →

Configurer une sauvegarde restic résistante au ransomware

Un ransomware (logiciel de rançon) bien opéré cherche les sauvegardes avant de chiffrer la production, avec les identifiants d’administration qu’il a déjà volés. Ce guide monte une chaîne de sauvegarde avec restic, un serveur de dépôt en ajout seul et une copie hors site verrouillée, puis la vérifie jusqu’à la restauration réelle. La position défendue : le nombre de copies compte moins que le nombre de copies qu’un compte administrateur compromis ne peut pas détruire, et une sauvegarde jamais restaurée n’est qu’une hypothèse de sauvegarde.

Explication de la marmotte

Une bonne sauvegarde ressemble à des photocopies de documents précieux rangées chez plusieurs personnes de confiance, dont une dans un coffre de banque que même le propriétaire ne peut pas vider avant une date fixée. Si un cambrioleur brûle la maison, les copies survivent. Encore faut-il vérifier de temps en temps qu’elles sont lisibles.

→ Lire l’explication complète de la marmotte

Prérequis : objectifs de reprise et domaines de compromission

Avant tout outil, deux chiffres par système : le RPO (Recovery Point Objective, perte de données maximale admise) et le RTO (Recovery Time Objective, durée maximale d’interruption). Ils fixent la fréquence des sauvegardes et le débit de restauration à valider.

Ensuite, la notion qui décide de tout : deux copies n’en font qu’une si le même compte peut détruire les deux. Le serveur de sauvegarde ne doit donc pas être joint à l’annuaire de production, ne doit accepter aucun compte de ce domaine, et la machine sauvegardée ne doit détenir qu’un droit d’écriture sans suppression. L’éditorial sur la règle 3-2-1 face au rançongiciel, dans la section éditoriaux, développe ce raisonnement ; ce guide l’applique. La continuité d’activité au sens large (bascule, redondance) relève de la section réseaux et n’est pas couverte ici.

Matériel : un hôte de sauvegarde dédié avec son propre disque, un compartiment S3 (Simple Storage Service, ou compatible) supportant l’Object Lock, restic 0.16 ou plus récent, rest-server et rclone.

Étapes 1 à 3 : architecture 3-2-1 avec copie immuable

Étape 1, trois copies sur deux supports. Copie 1 : les données de production. Copie 2 : un dépôt restic sur l’hôte de sauvegarde, servi par rest-server. Copie 3 : la réplique de ce dépôt dans un compartiment S3 distant. Le dépôt restic est chiffré côté client (AES-256, Advanced Encryption Standard, et authentifié par Poly1305) : le stockage distant ne voit que des blocs opaques.

Étape 2, ajout seul sur la copie locale. rest-server lancé avec --append-only refuse toute suppression venant d’un client. Un attaquant installé sur le serveur de fichiers peut écrire de nouveaux instantanés, pas effacer les anciens. Le nettoyage (forget --prune) s’exécute uniquement sur l’hôte de sauvegarde, avec un accès local au disque. Borg offre l’équivalent avec borg serve --append-only forcé dans authorized_keys.

Étape 3, verrou de conformité sur la copie hors site. Object Lock existe en deux modes. Le mode GOVERNANCE se contourne avec la permission s3:BypassGovernanceRetention, donc par un administrateur du compte cloud, donc par l’attaquant qui l’a compromis. Le mode COMPLIANCE ne se lève pas avant l’échéance, même par le compte racine. La recommandation est sans nuance : COMPLIANCE, avec une durée supérieure au temps de présence plausible d’un attaquant avant chiffrement, soit au moins 30 jours. Le prix : une erreur de volumétrie se paie jusqu’à l’échéance, sans remise possible. Seul l’hôte de sauvegarde détient les identifiants S3 ; la production ne les voit jamais.

Un disque externe débranché après chaque rotation hebdomadaire reste la variante air-gapped (physiquement déconnectée) la moins chère, à condition qu’une procédure humaine le débranche vraiment. Un disque « hors ligne » monté en permanence est un volume de plus, chiffré dans le même lot.

Étape 4 : script de sauvegarde et de vérification reproductible

Côté hôte de sauvegarde, une fois pour toutes :

# Dépôt restic servi en ajout seul, un sous-dépôt par client,
# TLS (Transport Layer Security) obligatoire
rest-server --path /srv/restic --listen :8000 --append-only --private-repos \
  --tls --tls-cert /etc/rest-server/cert.pem --tls-key /etc/rest-server/key.pem

# Compartiment hors site verrouillé en mode conformité, 30 jours par défaut
aws s3api create-bucket --bucket sauvegardes-restic-hs \
  --object-lock-enabled-for-bucket --region eu-west-3 \
  --create-bucket-configuration LocationConstraint=eu-west-3
aws s3api put-object-lock-configuration --bucket sauvegardes-restic-hs \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

# Réplication quotidienne : "copy" et non "sync", pour ne jamais propager
# une suppression vers la copie hors site
rclone copy /srv/restic s3-verrou:sauvegardes-restic-hs --immutable

Côté serveur sauvegardé, le script lancé chaque nuit par un minuteur systemd :

/usr/local/sbin/sauvegarde.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY="rest:https://sauvegarde.interne:8000/srv-fichiers/"
export RESTIC_PASSWORD_FILE=/etc/restic/depot.pass   # 0400, root seul
PING="https://supervision.interne/ping/srv-fichiers"

echec() { curl -fsS -m 10 "$PING/fail" >/dev/null; exit 1; }

# Sauvegarde. Code retour 3 : fichiers illisibles, instantané incomplet
restic backup /srv/donnees --exclude-caches --tag quotidien || echec

# Intégrité : structure du dépôt, puis relecture de 5 % des blocs
# avec contrôle de leur empreinte SHA-256 (Secure Hash Algorithm)
# et de leur authentification
restic check --read-data-subset=5% || echec

# Signal de succès : c'est son ABSENCE qui déclenche l'alerte
curl -fsS -m 10 "$PING" >/dev/null

Le point décisif est la dernière ligne. Une alerte sur échec ne voit pas un minuteur désactivé, un serveur éteint ou un script supprimé : rien ne s’exécute, donc rien n’échoue. Le signal inverse (« alerter si aucun succès en 26 heures ») couvre ces pannes silencieuses. Sur un sous-ensemble tournant de 5 %, la totalité du dépôt est relue en vingt nuits environ.

Étape 5 : le test de restauration trimestriel

Une fois par trimestre, sur une machine isolée du réseau de production :

1. récupérer le mot de passe du dépôt depuis son lieu de conservation hors infrastructure (coffre physique, enveloppe scellée) ; un mot de passe stocké uniquement sur le serveur sauvegardé disparaît avec lui ;
2. restaurer depuis la copie hors site, pas depuis la copie locale : c’est elle qui servira le jour du sinistre ;
3. restic restore latest --target /restauration, puis démarrer réellement l’application sur ces données ;
4. chronométrer de bout en bout et comparer au RTO ;
5. consigner les écarts : dépendances oubliées, ordre de redémarrage, comptes de service absents.

Cette étape est la plus souvent abandonnée parce qu’elle ne produit aucun livrable visible. Une sauvegarde verte pendant trois ans qui restaure un répertoire vide reste, pour le tableau de bord, un succès.

Surface d’attaque et limites

Attaques connues : suppression via les identifiants de sauvegarde (contrée par l’ajout seul et le verrou), attente patiente au-delà de la rétention pour que seules des versions déjà compromises subsistent (contrée par une rétention longue et par une alerte sur la taille anormale des instantanés, signe d’un chiffrement en cours), vol du mot de passe du dépôt (contré par sa conservation hors ligne, voir la section cryptographie).

Ce que la chaîne ne garantit pas : elle ne protège pas contre l’exfiltration préalable des données, puisque la double extorsion ne dépend pas de la capacité de restaurer ; elle ne remplace pas un plan de reprise d’activité ; et elle ne dit rien de la propreté des données restaurées, qui peuvent contenir la porte dérobée de l’attaquant. Restaurer la production dans l’état exact de l’intrusion reste une manière très fiable de revivre la même semaine.

🐝 Ce qui arrive si on s’en passe

Sans copie immuable ni hors ligne, un compte d’administration compromis dispose exactement des mêmes droits sur les sauvegardes que sur les données de production : les instantanés sont supprimés ou chiffrés avant que le chiffrement des serveurs ne devienne visible, et la négociation devient la seule option restante. Sans vérification d’intégrité automatisée, un dépôt corrompu ou un travail interrompu se signale uniquement le jour de la restauration, c’est-à-dire trop tard. Sans alerte sur échec, une tâche planifiée qui ne s’exécute plus produit un silence indiscernable d’un succès, et la profondeur réelle de l’historique se réduit sans que personne l’observe. Sans test de restauration périodique, le délai de reprise reste une estimation jamais mesurée : clés de chiffrement du dépôt égarées, ordre de redémarrage des services inconnu, dépendances absentes de la sélection sauvegardée.

🦫 Explication de la marmotte 🍫

Un logiciel de rançon chiffre les fichiers d’une entreprise pour exiger de l’argent. Avant de le faire, les attaquants cherchent et détruisent les sauvegardes, en utilisant les mots de passe d’administration qu’ils ont volés. Une sauvegarde utile doit donc exister en trois exemplaires, sur deux types de stockage, dont un loin des locaux. Surtout, au moins un exemplaire doit être impossible à effacer. Ici, le serveur de sauvegarde accepte de recevoir de nouvelles copies mais refuse toute demande de suppression venant des machines sauvegardées. La copie lointaine est placée dans un stockage en ligne réglé pour interdire toute suppression pendant trente jours, même par le propriétaire du compte. Chaque nuit, un programme copie les données, les chiffre, puis relit une partie de ce qu’il a écrit pour vérifier que rien n’est abîmé. S’il réussit, il envoie un signal à un outil de surveillance ; si ce signal manque, une alerte part, ce qui détecte aussi les sauvegardes qui ne se lancent plus du tout. Enfin, chaque trimestre, quelqu’un restaure réellement les données sur une machine séparée, redémarre l’application et mesure le temps nécessaire. Sans cet essai, personne ne sait si la sauvegarde fonctionne.

À lire aussi

• Tester une restauration après sinistre simuléGuide pratique pour préparer, exécuter et mesurer un test de restauration après un sinistre simulé dans un environnement isolé.
• Test de restauration des sauvegardesLes tests de restauration révèlent les défaillances opérationnelles, cryptographiques et applicatives qu'un audit de sauvegarde ne peut pas prouver.
• Continuité, sauvegardes, PRA/PCA et haute disponibilitéRelier réseau, stockage, serveurs, sauvegardes et continuité d’activité pour concevoir des services résistants aux pannes, erreurs et incidents.
• Gérer une crise cloud multi-tenantGestion de crise lors d'un incident cloud multi-tenant affectant indirectement la disponibilité d'un service.

Pages voisines

La citent

• Continuité, sauvegardes, PRA/PCA et haute disponibilité
• Guide d'hygiène informatique ANSSI en 42 mesures, mode d'emploi
• Test de restauration des sauvegardes

Configurer une sauvegarde restic résistante au ransomware

Elle cite

• ⇄Lien dans les deux sens :Sauvegarde immuable anti-ransomware et verrouillage WORM
• ⇄Lien dans les deux sens :La règle 3-2-1 à l'épreuve du rançongiciel
• ⇄Lien dans les deux sens :Ransomware-as-a-Service et double extorsion

⇄ : les deux pages se citent l’une l’autre.