TP – Sauvegarder, subir un sinistre, restaurer en chronométrant

BTS SIO SISR 2e année – Bloc 3 – S16 – en binôme : un tape, l'autre lit ; on échange les rôles à chaque partie

Note

But. Mettre en place une sauvegarde avec versions, constater qu'une sauvegarde accessible à un compte compromis est détruite, qu'une sauvegarde isolée résiste, restaurer après un sinistre simulé en chronométrant, puis estimer un temps de reprise réaliste.

Durée : 3 h 10. Prérequis : cours S16 lu ; S02, S10, S15.

Note

Comment ce TP fonctionne. Tu anticipes (« J'anticipe »), tu manipules, tu notes ce que tu constates, puis tu expliques (« Je comprends »). Un bilan de compétences clôt la séance.

Binôme : ____________ / ____________

Le laboratoire

Une machine virtuelle Debian avec un compte sudo. Elle joue deux rôles grâce à deux comptes :

Compte	Rôle	Droits
`prod`	Le serveur de production, qui sera « compromis »	Propriétaire des données
`sauve`	Le serveur de sauvegarde	Propriétaire du dépôt de sauvegarde, lit les données

Note

Une seule machine suffit pour voir le principe (séparation des comptes). En réalité, le serveur de sauvegarde est une autre machine, idéalement hors de l'annuaire de production : un attaquant administrateur de la machine ici (root) pourrait tout effacer. Cette limite est le sujet de la partie G.

Contraintes. Instantané de la machine avant de commencer ; paquet restic ; tu notes la sortie de chaque commande (capture datée). Le mot de passe du dépôt utilisé ici (Mdp-Depot-Lab-1) est un mot de passe de laboratoire.

Partie A – Objectifs de reprise de l'Atelier Verdier (≈ 25 min)

Reprends le dossier de la séance S02 (nuit : copie du serveur de fichiers vers un NAS ; 35 salariés ; machines à commande numérique ; ERP hébergé).

J'anticipe. Si le serveur de fichiers est chiffré un mardi à 10 h, combien de jours de travail perdraient-ils avec la sauvegarde actuelle ? Que se passe-t-il dans l'atelier ? ______________________

Activité	Impact d'un arrêt (une heure, un jour, une semaine)	DMIA proposée	PDMA proposée	RTO visé	RPO visé
Bureau d'études (plans)
Comptabilité et paie
Atelier (programmes de découpe)
Messagerie

Je comprends. Qui décide de ces valeurs ? Pourquoi un RPO d'une heure coûte-t-il plus cher qu'un RPO de 24 heures ? ______________________

Partie B – Préparer le laboratoire (≈ 20 min)

sudo apt install -y restic
sudo useradd -m -s /bin/bash prod
sudo useradd -m -s /bin/bash sauve
sudo mkdir -p /srv/donnees/Plans /srv/donnees/Compta
for i in $(seq 1 20); do sudo head -c 300000 /dev/urandom | sudo tee /srv/donnees/Plans/plan$i.dwg >/dev/null; done
for i in $(seq 1 10); do echo "ecriture $i" | sudo tee /srv/donnees/Compta/piece$i.txt >/dev/null; done
sudo chown -R prod:sauve /srv/donnees
sudo chmod -R 750 /srv/donnees
sudo install -d -o sauve -g sauve -m 700 /srv/sauvegarde

Je comprends. Que signifient les droits 750 sur les données et 700 sur /srv/sauvegarde ? Qui peut lire les données ? Qui peut lire la sauvegarde ? ______________________

Partie C – Une sauvegarde avec versions (≈ 30 min)

Les commandes de sauvegarde s'exécutent en tant que sauve (le serveur de sauvegarde « tire » les données).

sudo su - sauve
export RESTIC_PASSWORD="Mdp-Depot-Lab-1"
restic init -r /srv/sauvegarde/depot
restic backup -r /srv/sauvegarde/depot /srv/donnees
exit

Modifie ensuite une pièce comptable, puis refais une sauvegarde :

echo "correction" | sudo tee -a /srv/donnees/Compta/piece1.txt
sudo su - sauve
export RESTIC_PASSWORD="Mdp-Depot-Lab-1"
restic backup -r /srv/sauvegarde/depot /srv/donnees
restic snapshots -r /srv/sauvegarde/depot
exit

J'anticipe. Combien de versions (instantanés) verras-tu ? La deuxième sauvegarde sera-t-elle aussi volumineuse que la première ? ______________________

Je comprends. Qu'apporte la conservation de plusieurs versions face à un rançongiciel ? Quel paramètre détermine « jusqu'où on peut remonter » ? ______________________

Prends maintenant le manifeste (liste des empreintes) de l'état sauvegardé, pour pouvoir prouver la restauration :

sudo find /srv/donnees -type f | sort | sudo xargs sha256sum | sudo tee /root/manifeste.sha256 | wc -l

Vérifier l'intégrité

sudo su - sauve
export RESTIC_PASSWORD="Mdp-Depot-Lab-1"
restic check -r /srv/sauvegarde/depot
restic forget -r /srv/sauvegarde/depot --keep-last 1 --dry-run
exit

L'option --dry-run simule la suppression des anciennes versions sans rien supprimer.

Point de contrôle : capture des deux instantanés, du nombre de lignes du manifeste, de restic check.

Partie D – La mauvaise conception, puis le sinistre (≈ 40 min)

D1 – Une sauvegarde « sur un partage accessible »

Pour comparer, crée un deuxième dépôt écrit par le compte de production (comme un NAS monté en permanence) :

sudo install -d -o prod -g prod -m 755 /srv/depot-mal
sudo su - prod
export RESTIC_PASSWORD="Mdp-Depot-Lab-1"
restic init -r /srv/depot-mal
restic backup -r /srv/depot-mal /srv/donnees
exit

D2 – Le sinistre

Le compte prod est « compromis » : l'attaquant a ses droits. Simule son action (uniquement dans le laboratoire) :

sudo su - prod
# 1. Chiffrement simule : renommage de tous les fichiers de donnees
find /srv/donnees -type f -exec mv {} {}.verrou \;
ls /srv/donnees/Compta | head -3
# 2. Tentative de destruction des sauvegardes
rm -rf /srv/depot-mal/*
ls /srv/depot-mal
cat /srv/sauvegarde/depot/config
ls /srv/sauvegarde
exit

J'anticipe. Quelle sauvegarde survivra ? Pourquoi ? ______________________

Sauvegarde	Détruite ?	Message obtenu	Pourquoi
`/srv/depot-mal` (accessible à `prod`)
`/srv/sauvegarde/depot` (isolée)

Je comprends. Retrouve ici deux faiblesses du NAS de l'Atelier Verdier (séance S02, séance S15). ______________________

Point de contrôle : captures des deux tentatives.

Partie E – Restaurer en chronométrant (≈ 30 min)

sudo mkdir /srv/restauration
sudo chown sauve /srv/restauration
sudo su - sauve
export RESTIC_PASSWORD="Mdp-Depot-Lab-1"
time restic restore latest -r /srv/sauvegarde/depot --target /srv/restauration
exit

Vérifie que ce qui est restauré est identique à l'état d'avant le sinistre :

cd /srv/restauration
sudo sed 's#/srv/donnees#/srv/restauration/srv/donnees#' /root/manifeste.sha256 | sudo sha256sum -c 2>&1 | grep -vc ': OK'

Le chiffre affiché est le nombre de fichiers non conformes : il doit valoir 0.

Mesure	Valeur
Volume restauré
Durée mesurée (`real`)
Débit (volume ÷ durée)
Fichiers non conformes

Je comprends. Pourquoi la vérification par empreinte est-elle plus fiable que « j'ouvre quelques fichiers » ? Que faut-il faire avant de remettre ces données en service sur la production (séance S15) ? ______________________

Partie F – Estimer un vrai temps de reprise (≈ 25 min)

L'Atelier Verdier a environ 400 Go de plans (séance S02).

J'anticipe. Avec ton débit mesuré, combien de temps faudrait-il pour restaurer 400 Go ? ______________________

Calcule : durée = 400 Go ÷ débit. Puis discute :

Ton essai portait sur un tout petit volume. Pourquoi l'extrapolation est-elle optimiste ? (cours, partie 4)
Ajoute les étapes qui ne figurent pas dans le chronomètre : reconstruction de la machine, éradication, vérifications, changement des mots de passe, remise en service. Fais une estimation prudente du temps de reprise total : ______________________
Cette estimation est-elle compatible avec la DMIA que tu as proposée en partie A ? Sinon, que proposes-tu (copie locale plus rapide, restauration par priorité, PCA) ? ______________________

Ordre de reprise

Classe les éléments de l'Atelier Verdier dans l'ordre de remise en service et justifie : serveur de fichiers, messagerie, PC des machines à commande numérique, NAS, accès distant, poste de la comptable.

Rang	Élément	Justification
1
2
3
4
5
6

Partie G – Aller plus loin : la copie scellée et ses limites (≈ 20 min)

sudo tar -C /srv -cf /srv/sauvegarde/scelle.tar restauration
sudo chown sauve /srv/sauvegarde/scelle.tar
sudo chattr +i /srv/sauvegarde/scelle.tar
sudo su - sauve -c 'rm -f /srv/sauvegarde/scelle.tar'
lsattr /srv/sauvegarde/scelle.tar
sudo chattr -i /srv/sauvegarde/scelle.tar

L'attribut +i rend le fichier immuable : même son propriétaire ne peut ni le supprimer ni le modifier.

Je comprends.

Un attaquant qui obtient les droits root de cette machine peut-il retirer cet attribut ? Que montre la dernière commande ? ______________________
Qu'ajoutent donc une machine séparée, une copie hors ligne ou un stockage verrouillé (cours, partie 3) ? ______________________
Quelle copie recommandes-tu à l'Atelier Verdier avec un budget de 8 000 € (séance S02), et quelle fréquence de test ? ______________________

Warning

Mettre l'attribut +a (ajout seulement) sur tout le dépôt de restic bloque l'outil lui-même (il renomme et supprime des fichiers temporaires). Pour une sauvegarde « ajout seulement » réelle, on s'appuie sur un serveur de dépôt prévu pour cela ou un stockage verrouillé (non testés dans ce laboratoire).

Retour en entreprise (si ta situation le permet)

Observer : ton entreprise a-t-elle des objectifs de reprise écrits ? Quand a-t-on testé une restauration pour la dernière fois ? Existe-t-il une copie hors ligne ?
Documenter : compare avec la règle 3-2-1 renforcée du cours.

Rendu

Compte rendu PDF, nommé RENDU-B3A2-S16-NOM.pdf, contenant le tableau des objectifs (A), les captures datées des parties C à E, le tableau de comparaison (D), l'estimation (F) et les réponses de la partie G.

Bilan de la séance

Compétence du référentiel	Ce que j'ai fait dans cette séance	Niveau
B3.4 – Garantir la disponibilité, l'intégrité et la confidentialité des services informatiques et des données de l'organisation face à des cyberattaques
B3.5A – Assurer la cybersécurité d'une infrastructure réseau, d'un système, d'un service

Note

Je sais faire, sans aide :

Distinguer PCA et PRA, et définir RPO et RTO ;
Expliquer pourquoi une sauvegarde accessible est détruite par un rançongiciel ;
Mettre en place une sauvegarde isolée avec versions ;
Restaurer, chronométrer et prouver la conformité ;
Estimer un temps de reprise avec prudence.

Ce que je dois reprendre : ______________________