TP07 - Dépôt en ajout seul avec rest-server

Objectif : protéger les sauvegardes contre un attaquant qui prendrait le contrôle de srv01, en remplaçant le dépôt SFTP par un dépôt rest-server en mode ajout seul (append-only), puis appliquer la rétention depuis le serveur de sauvegarde.

Prérequis :

• TP06 terminé (sauvegarde automatisée sur srv01).
• Accès Internet sur bkp01 pour télécharger l’image Docker officielle restic/rest-server.

Actions à réaliser :

1. Déployer rest-server sur bkp01.

   sudo apt -y install docker.io
   sudo mkdir -p /srv/rest-server
   sudo docker run -d --name rest_server --restart unless-stopped \
     -p 8000:8000 -v /srv/rest-server:/data \
     -e OPTIONS="--append-only --private-repos" restic/rest-server
   sudo docker exec -it rest_server create_user srv01

   Choisissez un mot de passe HTTP robuste pour l’utilisateur srv01. Avec --private-repos, cet utilisateur n’accède qu’au dépôt situé sous /srv01/ ; avec --append-only, il peut ajouter des sauvegardes mais ni supprimer ni modifier les existantes.

2. Configurer le client sur srv01.

   openssl rand -base64 32 > /etc/restic/rest.pass
   chmod 600 /etc/restic/rest.pass
   cat > /etc/restic/rest.env <<'EOF'
   RESTIC_REPOSITORY=rest:http://192.168.56.20:8000/srv01/
   RESTIC_PASSWORD_FILE=/etc/restic/rest.pass
   RESTIC_REST_USERNAME=srv01
   RESTIC_REST_PASSWORD=MotDePasseHTTPChoisi
   EOF
   chmod 600 /etc/restic/rest.env
   set -a; . /etc/restic/rest.env; set +a
   restic init

   Remplacez MotDePasseHTTPChoisi par le mot de passe défini à l’étape 1. Le mot de passe HTTP protège l’accès au serveur ; le mot de passe du dépôt (rest.pass) protège le chiffrement des données.

3. Basculer l’automatisation vers le nouveau dépôt. Le client n’ayant plus le droit de supprimer, retirez la ligne forget du script et changez le fichier d’environnement du service :

   sed -i '/restic forget/d' /usr/local/sbin/restic-backup.sh
   sed -i 's#/etc/restic/sftp.env#/etc/restic/rest.env#' /etc/systemd/system/restic-backup.service
   systemctl daemon-reload
   systemctl start restic-backup.service
   restic snapshots

4. Jouer l’attaquant. Depuis srv01, tentez de supprimer les sauvegardes :

   restic forget --keep-last 1 --prune
   echo "code retour : $?"

   La commande échoue : le serveur refuse la suppression des fichiers d’instantanés. Un rançongiciel exécuté avec les droits root de srv01 se heurterait au même refus.

5. Appliquer la rétention côté serveur. Sur bkp01, l’administrateur de la sauvegarde travaille directement sur le dossier du dépôt (il doit connaître le mot de passe du dépôt, conservé dans le gestionnaire de mots de passe) :

   sudo restic -r /srv/rest-server/srv01 snapshots
   sudo restic -r /srv/rest-server/srv01 forget --keep-within 30d --keep-monthly 12 --dry-run
   sudo restic -r /srv/rest-server/srv01 forget --keep-within 30d --keep-monthly 12 --prune

   La documentation recommande --keep-within pour les dépôts en ajout seul : un attaquant pourrait créer de nombreux faux instantanés récents pour faire « sortir » les vrais d’une politique de type --keep-last.

Vérification / résultat attendu :

• Les sauvegardes automatiques de srv01 arrivent dans /srv/rest-server/srv01 sur bkp01.
• Toute tentative de suppression depuis srv01 échoue.
• La rétention appliquée sur bkp01 fonctionne et sudo restic -r /srv/rest-server/srv01 check ne signale aucune erreur.

Pour aller plus loin : en production, activez TLS (--tls, --tls-cert, --tls-key) pour ne pas faire circuler le mot de passe HTTP en clair, filtrez le port 8000 pour n’autoriser que les serveurs sauvegardés, et administrez bkp01 avec des comptes distincts de ceux de la production. L’option --prometheus expose des métriques pour la supervision.