🎓 SIO2 · semestre 3⏱️ 3 h (cours + TP)🎯 Bloc 3 – CybersécuritéComprendre pourquoi les rançongiciels s'attaquent d'abord aux sauvegardes, puis concevoir et tester des sauvegardes qui leur résistent, avec Proxmox Backup Server.
🎯 Objectifs
Décrire le déroulement d'une attaque par rançongiciel et expliquer pourquoi les sauvegardes sont visées en premier.
Appliquer la règle 3-2-1-1-0 à un système d'information.
Test express des prérequis 3 questions · 2 minutes · conseillé avant de commencer
1. Que mesure le RPO (Recovery Point Objective) ?
RPO = « jusqu'à quand je peux revenir en arrière » (une sauvegarde par nuit → jusqu'à 24 h de données perdues) ; A, c'est le RTO. À revoir : B3-08 · Analyse de risques.
2. Une sauvegarde incrémentale copie…
B décrit la différentielle. Proxmox Backup Server va plus loin : il découpe les données en blocs et ne stocke chaque bloc qu'une fois (déduplication). À revoir : B2-24 · Sauvegarde.
3. Une copie des données sur un second disque du même serveur est-elle une vraie sauvegarde ?
Une sauvegarde doit survivre à ce qui détruit l'original. Le RAID protège d'une panne de disque, pas d'une suppression ni d'un chiffrement malveillant.
Lundi, 7 h 40 : chez Lorvia Transports, un transporteur voisin et client de Brocéliande Logistique (entreprises fictives), tous les fichiers des serveurs portent l'extension .lock3r. Le NAS de sauvegarde, branché en partage réseau sur le serveur de fichiers, a été chiffré lui aussi, et les attaquants menacent de publier les données des clients.
Le directeur de Brocéliande, inquiet, te demande : « Est-ce que ça peut nous arriver ? Est-ce que nos sauvegardes résisteraient ? » Tu dois analyser la stratégie actuelle, proposer une architecture qui résiste à une attaque, puis prouver qu'une restauration fonctionne vraiment.
Le coursComment se déroule une attaque par rançongiciel, pourquoi elle vise les sauvegardes, puis comment concevoir, isoler, mettre en œuvre et tester des sauvegardes qui lui résistent.
1. Anatomie d'une attaque par rançongiciel
Un rançongiciel ne se déclenche presque jamais dès l'entrée de l'attaquant. Les groupes criminels passent des jours, parfois des semaines, à explorer le réseau, à voler des identifiants et à neutraliser les sauvegardes, avant de lancer le chiffrement d'un seul coup, souvent la nuit ou un week-end.
L'étape ③ décide de tout : si une copie survit, l'entreprise restaure ; sinon, elle est à la merci des attaquants.
Double extorsion : l'attaquant chiffre les données et les a volées avant ; il exige une rançon pour la clé de déchiffrement et une autre pour ne pas les publier. Une bonne sauvegarde répond au chiffrement, pas à la fuite : celle-ci se prévient par le chiffrement des données, le cloisonnement et la détection (fiches B3-09, B3-12).
L'ANSSI, la police et Cybermalveillance.gouv.fr recommandent de ne pas payer : rien ne garantit la remise d'une clé qui fonctionne ni l'effacement des données volées, et le paiement finance les attaques suivantes. La seule réponse fiable est d'avoir prévu une restauration… qui fonctionne.
2. Pourquoi les sauvegardes sont la première cible
Pour l'attaquant, les sauvegardes sont la seule chose qui permet à la victime de ne pas payer. Il les cherche donc méthodiquement, avec les identifiants qu'il a volés. Or, dans beaucoup d'entreprises, la sauvegarde est joignable et administrable depuis le reste du réseau, avec les mêmes comptes.
Ce que fait l'attaquant
Pourquoi ça marche
Ce qui l'en empêche
Chiffre le NAS de sauvegarde monté en lecteur réseau
Le serveur a un accès en écriture permanent au NAS
Pas de partage réseau : la sauvegarde tire les données ou écrit dans un format qu'elle seule gère
Se connecte à la console de sauvegarde et supprime les copies
La console est dans le domaine AD, ouverte aux « Admins du domaine »
Comptes dédiés hors de l'AD, double authentification, réseau d'administration séparé
Efface les clichés instantanés Windows (vssadmin delete shadows /all)
Les clichés sont sur le même serveur que les données
Ne jamais compter sur les clichés comme sauvegarde
Réduit la rétention à 1 jour, attend, puis chiffre
Les réglages de rétention sont modifiables par le même compte
Copie immuable ou hors ligne, que personne ne peut réduire à distance
Supprime les VM répliquées sur le second site
La réplication propage aussi les suppressions et le chiffrement
Une réplication n'est pas une sauvegarde : il faut un historique de versions
Pour bien comprendre : le double des clés
Ranger le double de ses clés dans un tiroir de l'entrée, c'est pratique… mais le cambrioleur qui entre dans la maison le trouve aussi. Une sauvegarde joignable depuis le réseau attaqué, avec les mêmes comptes, subit le même sort que les originaux.
Le double confié au notaire, dans un autre lieu, dans un coffre que personne de la maison ne peut ouvrir à distance, survit au cambriolage : c'est la copie hors site et hors ligne, ou immuable.
Et il faut, de temps en temps, vérifier que ce double ouvre bien la porte : c'est le test de restauration.
3. La règle 3-2-1-1-0
La règle historique « 3-2-1 » protégeait contre les pannes et les sinistres. Face aux rançongiciels, on l'a complétée par deux exigences : une copie que l'attaquant ne peut pas atteindre ou modifier, et la preuve que la restauration fonctionne.
Clique sur chaque chiffre de la règle pour voir ce qu'il exige et la menace qu'il contre.
Choisis un chiffre : son exigence s'affiche ici.
La ligne grise sous chaque chiffre indique la menace qu'il contre.
3-2-1-1-0 : 3 copies, sur 2 supports différents, dont 1 hors site, 1 hors ligne ou immuable, et 0 erreur constatée lors des vérifications et des tests de restauration. Une sauvegarde que l'attaquant peut atteindre avec les identifiants qu'il a volés ne compte pas comme « hors ligne ».
4. Hors site, hors ligne, immuable, chiffrée
Ces quatre mots sont souvent confondus. Ils protègent pourtant contre des menaces différentes, et une bonne architecture les combine.
Hors siteLa copie est dans un autre lieu physique. Elle protège du sinistre, mais pas d'un attaquant si elle est joignable et effaçable à distance avec les mêmes comptes.
Hors ligne (air gap)Le support est déconnecté du réseau en dehors de la fenêtre de copie : disque amovible rangé dans un coffre, bande éjectée. Aucune commande à distance ne peut l'atteindre.
ImmuableLa copie reste en ligne mais ne peut être ni modifiée ni supprimée avant la fin de sa durée de conservation, même par un administrateur : stockage objet avec verrouillage (Object Lock), support WORM, ou serveur distant qui seul décide de ses suppressions.
ChiffréeLa copie est illisible sans la clé. Cela protège la confidentialité (vol d'un disque, hébergeur curieux), pas la disponibilité : une copie chiffrée peut toujours être effacée. La clé est conservée hors du système sauvegardé.
La réplication (miroir, synchronisation, RAID, réplication de VM) n'est pas une sauvegarde : elle recopie aussitôt les fichiers chiffrés par le rançongiciel. Une sauvegarde garde un historique de versions qui permet de revenir à l'état d'avant l'attaque.
Ma sauvegarde résisterait-elle à un rançongiciel ? Réponds pour la stratégie de ton entreprise
Existe-t-il une copie dans un autre lieu que la salle serveur ?Autre bâtiment, autre site de l'entreprise, prestataire.
Les comptes qui administrent les sauvegardes sont-ils distincts de l'AD et protégés par une double authentification ?Un « Admin du domaine » volé ne doit pas suffire à supprimer les copies.
Une copie est-elle hors ligne ou immuable ?Débranchée, ou impossible à supprimer à distance pendant sa durée de conservation.
Une restauration complète a-t-elle été testée et chronométrée depuis moins de trois mois ?Et les vérifications automatiques ne signalent aucune erreur.
Risque majeur : un incendie ou un attaquant détruit originaux et sauvegardes en même temps. Priorité : une copie hors site, par exemple un second PBS sur un autre site qui tire les sauvegardes du premier.
Risque majeur : l'attaquant qui a volé les identifiants du domaine supprime les copies. Priorité : comptes dédiés aux sauvegardes, hors de l'AD, avec double authentification, et droits limités pour les serveurs sauvegardés (partie 5).
Risque élevé : toutes les copies restent effaçables à distance. Priorité : une copie hors ligne (disque amovible, bande) ou immuable, avec une rotation documentée.
Risque caché : la stratégie semble bonne, mais personne ne sait si la restauration fonctionne ni combien de temps elle prend. Priorité : un test de restauration chronométré, comparé au RTO (partie 7).
Stratégie solideTu respectes la règle 3-2-1-1-0. Continue à vérifier chaque mois les alertes de vérification et à refaire un test de restauration par trimestre.
5. Isoler l'administration des sauvegardes
Une sauvegarde résistante est d'abord une sauvegarde séparée : un attaquant qui contrôle le domaine Windows et les hyperviseurs ne doit pas pouvoir, avec ce qu'il a volé, effacer les copies.
Serveur de sauvegarde hors du domaine : Proxmox Backup Server n'est pas joint à l'AD ; ses comptes sont locaux (domaine @pbs) et protégés par une double authentification (TOTP ou clé de sécurité).
Droits minimaux pour les machines sauvegardées : l'hyperviseur Proxmox VE se connecte avec un jeton qui n'a que le rôle DatastoreBackup : il peut créer des sauvegardes et restaurer les siennes, mais pas les supprimer ni modifier la rétention.
Réseau d'administration séparé : PBS utilise le même port TCP 8007 pour l'interface, l'API et les sauvegardes : il n'est joignable que depuis le VLAN de gestion et les serveurs à sauvegarder (filtrage par adresse source) ; ce sont les droits du compte (DatastoreBackup) qui empêchent toute suppression.
Copie distante tirée : le PBS du second site tire (pull) les sauvegardes du premier ; le premier ne possède aucun identifiant pour supprimer quoi que ce soit sur le second. Réserve : laisser l'option Remove vanished de la tâche de synchronisation désactivée, sinon les suppressions faites par l'attaquant au siège se propagent à Rennes.
L'attaquant a « les clés de la maison », mais pas celles du coffre de sauvegarde.
Rôle PBS
Sauvegarder
Restaurer
Supprimer, élaguer
À donner à…
DatastoreBackup
oui
ses propres sauvegardes
non
Hyperviseurs et serveurs sauvegardés
DatastorePowerUser
oui
ses propres sauvegardes
ses propres sauvegardes
À éviter pour les machines sauvegardées
DatastoreReader
non
lecture de tout
non
Contrôle, audit, tests de restauration
DatastoreAdmin
oui
tout
tout
Un ou deux administrateurs des sauvegardes, avec double authentification
6. Proxmox Backup Server en pratique
Proxmox Backup Server (PBS) découpe chaque sauvegarde en blocs (chunks), ne stocke qu'une fois les blocs identiques (déduplication) et peut chiffrer les données chez le client, avant leur envoi. Quatre réglages en font une sauvegarde résistante.
Chiffrement côté clientAES-256-GCM avec une clé qui ne quitte jamais le client. Le PBS stocke des blocs illisibles. On garde une copie de la clé sur papier ou dans un coffre-fort de mots de passe, hors du système sauvegardé : sans elle, aucune restauration n'est possible.
Vérification (verify job)Le PBS relit régulièrement chaque bloc et contrôle sa somme de contrôle. Une sauvegarde corrompue est signalée tout de suite, pas le jour de la restauration.
Rétention (prune) et nettoyage (garbage collection)La politique d'élagage décide quelles sauvegardes garder (par exemple 7 quotidiennes, 4 hebdomadaires, 6 mensuelles) ; le nettoyage libère ensuite les blocs qui ne servent plus. Une rétention longue laisse le temps de détecter une attaque discrète.
Copie distante et hors ligneTâche de synchronisation en mode pull vers un PBS distant, avec Remove vanished désactivé (sinon les suppressions de l'attaquant se propagent), et copie périodique sur datastore amovible (disque USB débranché ensuite) ou sur bande (LTO), que PBS gère nativement.
Proxmox Backup Server 4 shellPBS-SIÈGE · comptes et droits
# proxmox-backup-manager user create sauvegarde@pbs --password 'Phrase-longue-et-unique' # compte des machines sauvegardées # proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id sauvegarde@pbs # proxmox-backup-manager acl list # qui a quels droits, sur quel datastore # proxmox-backup-manager garbage-collection status store1
Debian 13 SRV-LINUXclient de sauvegarde chiffrée
# export PBS_REPOSITORY='sauvegarde@pbs@172.16.50.40:store1' # utilisateur@domaine@serveur:datastore # proxmox-backup-client key create /root/pbs.key --kdf none # clé de chiffrement (sans phrase de passe : sauvegardes planifiées) # proxmox-backup-client key paperkey /root/pbs.key --output-format text # version papier, à mettre au coffre # proxmox-backup-client backup partage.pxar:/srv/partage --keyfile /root/pbs.key # proxmox-backup-client snapshot list # les sauvegardes de ce serveur
Associe chaque besoin au bon élément de PBS. Écris le mot attendu (un seul mot, ou le nom du rôle), puis vérifie avec ✓.
Rôle d'un serveur qui sauvegarde sans pouvoir supprimer ›
Tâche qui relit les blocs pour détecter une corruption ›
Réglage qui décide des sauvegardes à conserver ›
Mode de synchronisation où le site distant tire les copies ›
7. Tester la restauration : le « 0 » de la règle
Une sauvegarde n'a de valeur que si l'on sait restaurer, dans les délais. Le test de restauration est le seul moyen de le prouver : il révèle la clé de chiffrement introuvable, la VM qui ne démarre pas, la procédure que personne ne connaît, ou un RTO intenable.
Un test qui échoue est une bonne nouvelle : le problème est découvert avant l'attaque, pas pendant.
Point de contrôle
Question à se poser
Clé de chiffrement
Peut-on la retrouver si le serveur sauvegardé et le poste de l'administrateur sont détruits ?
Point de restauration
La sauvegarde d'il y a 30 jours est-elle encore là et saine (vérification réussie) ?
Environnement isolé
La VM restaurée démarre-t-elle dans un réseau isolé, sans entrer en conflit avec la production ?
Durée
Combien de temps pour restaurer le serveur le plus critique ? Est-ce compatible avec le RTO du PRA ?
Procédure
Un technicien qui ne l'a jamais fait peut-il la suivre seul avec la documentation ?
Restaurer après un rançongiciel, c'est restaurer avant la date d'entrée de l'attaquant, sinon on réinstalle sa porte dérobée. D'où l'intérêt d'une rétention longue (plusieurs semaines) et d'une restauration dans un réseau isolé, analysée avant la remise en service.
8. Vérifier et dépanner
Symptôme
Cause probable
Vérification et correction
La vérification signale des blocs corrompus
Disque du datastore défaillant
État SMART du disque, restaurer depuis la copie distante, remplacer le support
Restauration impossible : missing key
Sauvegarde chiffrée, clé absente sur la machine de restauration
Reprendre la clé depuis la copie papier ou le coffre-fort ; c'est pour cela qu'on la sort du système
Le datastore se remplit sans fin
Élagage configuré mais nettoyage (garbage collection) jamais lancé
Planifier le garbage collection après l'élagage
permission check failed en supprimant une sauvegarde
Le compte a le rôle DatastoreBackup
C'est le comportement voulu : la suppression se fait avec le compte administrateur du PBS
La copie distante est vide depuis une semaine
Tâche de synchronisation en échec (identifiants, empreinte du certificat, réseau)
Journal des tâches du PBS distant, alerte par courriel sur échec
8.1 Entraîne-toi : les tickets du support
Tu fais partie de l'équipe qui sécurise les sauvegardes de Brocéliande Logistique. Six situations arrivent : lis, observe, puis choisis la meilleure analyse.
File d'attente du support6 tickets · un à la fois · l'explication s'affiche après ta réponse
Ticket n° 1De : directionQuestion
« Notre prestataire dit que nous sommes protégés : le serveur de fichiers copie chaque nuit tout son contenu sur le NAS, monté en lecteur Z:, avec un RAID 1. Est-ce suffisant contre un rançongiciel ? »
Schéma fourni par le prestataire
SRV-FICHIERS ──(partage SMB Z:, écriture)──► NAS (RAID 1)
Copie : robocopy /MIR chaque nuit à 22 h
Quelle est la bonne analyse ?
Analyse : un rançongiciel sur SRV-FICHIERS chiffre aussi le lecteur Z: ; et même sinon, /MIR recopierait la nuit suivante les fichiers chiffrés à la place des bons. Le RAID protège d'une panne de disque, pas d'une écriture malveillante. Il manque : un historique de versions, une copie que le serveur ne peut pas modifier, une copie hors ligne.
Ticket n° 2Alerte du SIEMCritique
« Commande suspecte exécutée sur SRV-FICHIERS à 2 h 03 par le compte adm-backup. »
Analyse : c'est l'étape ③ de l'attaque, juste avant le chiffrement. Réaction immédiate : isoler le serveur du réseau, désactiver le compte adm-backup, alerter l'équipe et vérifier que les copies du PBS (hors domaine) sont intactes. Chaque minute compte (procédure d'incident, fiche B3-16).
« Je teste une restauration de SRV-LINUX sur une VM neuve et j'obtiens une erreur. Les sauvegardes sont pourtant vertes dans l'interface. »
Debian 13 VM de test
# proxmox-backup-client restore host/srv-linux/2026-10-12T22:00:01Z partage.pxar /tmp/r
Error: missing key - manifest was created with key 6c:2f:…:a1
Quelle est la cause ?
Cause : le message indique l'empreinte de la clé attendue. Si SRV-LINUX avait été chiffré par un rançongiciel, la clé aurait disparu avec lui. Correction : restaurer avec --keyfile depuis la copie de la clé ; puis ranger cette copie au coffre (version paperkey) et la noter dans la procédure. C'est exactement ce que le test devait révéler.
Ticket n° 4De : supervisionPriorité basse
« Le datastore store1 du PBS est plein à 94 %, alors que la politique ne garde que 7 sauvegardes quotidiennes et 4 hebdomadaires. »
PBS tâches planifiées
Prune job store1 : quotidien 23:00 OK
Garbage collection : jamais exécuté
Verify job store1 : hebdomadaire OK
Que faut-il corriger ?
Cause : avec la déduplication, un bloc peut servir à plusieurs sauvegardes ; l'élagage ne supprime donc que les index, et c'est le garbage collection qui libère les blocs devenus inutiles. Réduire la rétention ferait au contraire perdre de la profondeur d'historique, précieuse face à une attaque discrète.
Ticket n° 5De : stagiaireQuestion
« Pour simplifier, je propose de joindre le PBS au domaine broceliande.lan et d'y donner tous les droits au groupe Admins du domaine : tout le monde pourra gérer les sauvegardes. »
Proposition du stagiaire
PBS : authentification AD, groupe « Admins du domaine » = DatastoreAdmin
Proxmox VE : jeton DatastoreAdmin
Que réponds-tu ?
Analyse : dans presque toutes les attaques, l'AD tombe d'abord. Lier la sauvegarde à l'AD, c'est donner à l'attaquant la clé du dernier coffre. L'isolement (partie 5) est volontairement « moins pratique » : c'est ce qui le rend efficace.
Ticket n° 6Exercice de criseQuestion
« Après un rançongiciel, l'analyse montre que l'attaquant est entré le 2 octobre et a chiffré le 20. On a des sauvegardes quotidiennes intactes du 1er au 20. Laquelle restaurer ? »
Chronologie de l'attaque
01/10 dernière sauvegarde avant l'intrusion
02/10 intrusion, porte dérobée installée
20/10 chiffrement
Quelle stratégie choisis-tu ?
Analyse : le 19 octobre, la porte dérobée était déjà là : restaurer cette date rendrait l'accès à l'attaquant. On restaure des systèmes sains (1er octobre, ou réinstallation) et on récupère les données plus récentes après contrôle. Sans une rétention d'au moins trois semaines, ce choix aurait été impossible.
9. À l'examen et en entreprise
Justifier une architecture avec la règle 3-2-1-1-0 : où est chaque copie, sur quel support, qui peut la supprimer, comment on la vérifie.
Montrer la séparation des droits : comptes du PBS, rôle du jeton Proxmox VE, double authentification, réseau d'administration.
Prouver la restauration : compte rendu d'un test daté et chronométré, comparé au RTO du PRA (fiche B3-08).
À l'écrit, les sujets décrivent souvent une sauvegarde sur NAS en partage réseau : on attend l'analyse de ses faiblesses face à un rançongiciel et une proposition chiffrée.
10. L'essentiel
Un rançongiciel suit cinq étapes : entrée, propagation, destruction des sauvegardes, exfiltration, chiffrement.
La double extorsion combine chiffrement et menace de publication : la sauvegarde ne répond qu'au chiffrement.
Règle 3-2-1-1-0 : 3 copies, 2 supports, 1 hors site, 1 hors ligne ou immuable, 0 erreur.
Hors site ≠ hors ligne ≠ immuable ≠ chiffrée : chacune contre une menace différente.
La réplication, le RAID et les clichés ne sont pas des sauvegardes : pas d'historique protégé.
Le serveur de sauvegarde est hors du domaine, avec des comptes dédiés et une double authentification.
Les machines sauvegardées n'ont que le rôle DatastoreBackup : créer, pas supprimer.
PBS : chiffrement côté client, vérification, élagage puis garbage collection, copie distante en pull, datastore amovible ou bande.
La clé de chiffrement est conservée hors du système sauvegardé (papier, coffre-fort).
Une restauration se teste, se chronomètre et se fait à une date antérieure à l'intrusion.
La fiche en une image : à refaire de mémoire, sur une feuille, avant de passer aux exercices.
vssadmin delete shadows, wbadmin delete catalog dans les journaux = alerte
Tout cela tient sur une page : utilise le bouton Mémo à imprimer en haut de la fiche.
La pratiqueLe quiz noté pour vérifier tes acquis, les exercices à rendre à ton professeur, puis le TP au labo sur tes machines virtuelles.
11. Quiz noté
8 questions · 10 minutesRéponds à toutes les questions, puis valide. Seule ta première tentative est enregistrée : elle compte dans ton suivi. Ensuite, tu peux t'entraîner autant que tu veux.
1. Pourquoi un rançongiciel s'attaque-t-il aux sauvegardes avant de chiffrer ?
2. Dans la règle 3-2-1-1-0, que signifie le second « 1 » ?
3. Une copie chiffrée sur un PBS protège avant tout…
4. Quel rôle PBS donner au jeton utilisé par Proxmox VE pour sauvegarder les VM ?
5. Pourquoi une réplication de VM vers un second site n'est-elle pas une sauvegarde ?
6. Le datastore PBS se remplit malgré une rétention courte. Quelle tâche manque sans doute ?
7. Où conserver la clé de chiffrement des sauvegardes ?
8. L'attaquant est entré le 2, a chiffré le 20. Quelle sauvegarde des systèmes restaurer ?
12. Exercices : à toi de répondre
Écris ta réponse sous chaque énoncé et envoie-la à ton professeur. Quand il l'a validée, le corrigé s'affiche à la place du cadenas ; s'il te la renvoie « à revoir », lis son commentaire et corrige.
Exercice 1 – Comprendre (SIO2)
Pour chacune de ces solutions, indique si elle est hors site, hors ligne, immuable et/ou chiffrée, et contre quelle menace elle protège : a) un disque USB copié chaque vendredi puis rangé dans le coffre de la direction ; b) une synchronisation OneDrive du dossier Documents ; c) un PBS distant qui tire les sauvegardes du siège ; d) un stockage objet avec verrouillage de 30 jours.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 2 – Configurer (SIO2)
Sur PBS-SIÈGE, écris les commandes pour : créer le compte srv-linux@pbs, lui donner le droit de sauvegarder dans store1 sans pouvoir supprimer, puis, depuis SRV-LINUX, créer une clé de chiffrement et sauvegarder /etc et /srv/partage en une seule commande.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 3 – Dépanner (SIO2)
Lors du test trimestriel, la restauration de la VM SRV-WEB échoue : la vérification du PBS indique que la sauvegarde du dernier dimanche est « corrompue », et la plus ancienne sauvegarde disponible date de six jours. La rétention est réglée à keep-last 7. Analyse la situation et propose trois corrections.
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
Exercice 4 – Concevoir (SIO2)
Brocéliande Logistique sauvegarde aujourd'hui ses serveurs sur un NAS du siège, monté en partage réseau, avec un compte du domaine. Propose une nouvelle architecture conforme à la règle 3-2-1-1-0 (schéma ou tableau), précise qui peut supprimer chaque copie, et décris le test de restauration trimestriel (contenu, durée visée, compte rendu).
Le corrigé s'affichera ici dès que ton professeur aura validé ta réponse. Cherche d'abord par toi-même : c'est en se trompant qu'on retient.
13. Au labo : une sauvegarde chiffrée qui résiste à un compte volé
Objectif
Installer un Proxmox Backup Server dans ton pool, y sauvegarder un dossier de SRV-LINUX de façon chiffrée, avec un compte qui ne peut pas supprimer, vérifier la sauvegarde, la restaurer, puis jouer le rôle de l'attaquant qui a volé ce compte. Durée : 1 h 30. Tes machines et leurs adresses sont dans Mes serveurs et VM ; remplace les adresses de Brocéliande par les tiennes.
Machine
Système
Rôle dans le TP
PBS-01
Proxmox Backup Server 4 (ISO du stockage ISO du labo)
Serveur de sauvegarde : 2 vCPU, 4 Go, un second disque de 32 Go pour le datastore (exemple : 172.16.50.40)
SRV-LINUX
Debian 13
Serveur sauvegardé : dossier /srv/partage
PC-ADMIN
Windows 11 Pro
Navigateur pour l'interface du PBS (https://ADRESSE:8007)
Ce que tu vas obtenir
Un datastore sur un disque dédié, avec vérification, élagage et nettoyage planifiés.
Deux comptes : un compte de sauvegarde sans droit de suppression, un compte d'administration avec double authentification.
Une sauvegarde chiffrée de /srv/partage, sa clé imprimée, et une restauration réussie.
La preuve qu'un compte de sauvegarde volé ne permet pas d'effacer l'historique.
1 Installer PBS et créer le datastore
Crée la VM PBS-01 avec deux disques, installe Proxmox Backup Server sur le premier (adresse fixe dans le réseau des serveurs).
Depuis PC-ADMIN, ouvre https://ADRESSE:8007 (compte root@pam), puis Administration → Stockage / Disques → Répertoire → Créer sur le second disque, avec la case « Ajouter comme datastore » : nom store1.
Dans store1 : Prune & GC → élagage quotidien (garder 7 quotidiennes, 4 hebdomadaires, 3 mensuelles) et garbage collection quotidien ; Verify Jobs → vérification quotidienne.
2 Séparer les droits
Proxmox Backup Server 4 shellPBS-01
# proxmox-backup-manager user create sauvegarde@pbs --password 'Phrase-de-sauvegarde-2026' # compte utilisé par SRV-LINUX # proxmox-backup-manager acl update /datastore/store1 DatastoreBackup --auth-id sauvegarde@pbs # proxmox-backup-manager user create admin-sauv@pbs --password 'Autre-phrase-tres-longue' # administrateur des sauvegardes # proxmox-backup-manager acl update / Admin --auth-id admin-sauv@pbs # proxmox-backup-manager acl list
Connecte-toi ensuite à l'interface avec admin-sauv@pbs et active la double authentification (Configuration → Access Control → onglet Two Factor Authentication → Add → TOTP, avec une application d'authentification sur ton téléphone).
Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
# export PBS_REPOSITORY='sauvegarde@pbs@172.16.50.40:store1' # proxmox-backup-client login # accepter l'empreinte du certificat, saisir le mot de passe # proxmox-backup-client key create /root/pbs.key --kdf none && chmod 600 /root/pbs.key # proxmox-backup-client key paperkey /root/pbs.key --output-format text # copie dans ton compte rendu = « au coffre » # proxmox-backup-client backup partage.pxar:/srv/partage --keyfile /root/pbs.key # proxmox-backup-client snapshot list
Dans l'interface du PBS, la sauvegarde apparaît avec une icône de cadenas (chiffrée). Lance la vérification manuellement (Verify) et contrôle qu'elle est verte.
5 Restaurer un fichier « perdu »
Supprime /srv/partage/facture-114.txt.
Restaure l'archive dans un dossier temporaire, compare, puis remets le fichier en place. Chronomètre l'opération.
Tente la même restauration sans--keyfile : note le message d'erreur et explique-le.
Complète la commande de restauration (remplace la date par celle de ta sauvegarde, lue avec snapshot list) : on attend ici les éléments qui ne changent pas.
Programme ›
Sous-commande ›
Nom de l'archive ›
Option de la clé ›
6 Jouer l'attaquant
Tu as « volé » le compte sauvegarde@pbs et tu contrôles SRV-LINUX. Essaie de faire disparaître l'historique.
Recrée le fichier de clé depuis la version papier (ou depuis la copie gardée dans ton compte rendu) et prouve que la restauration fonctionne de nouveau. Enfin, connecte-toi avec admin-sauv@pbs : lui seul peut supprimer une sauvegarde, et seulement après la double authentification.
7 Valider : le cahier de recette
N°
Test
Commande ou écran
Résultat attendu
OK
1
Le datastore est sur un disque dédié
Datastore store1 → Résumé
Chemin sur le second disque
2
Les droits sont séparés
proxmox-backup-manager acl list
sauvegarde@pbs : DatastoreBackup sur /datastore/store1
3
La sauvegarde est chiffrée
Contenu de store1
Cadenas affiché, empreinte de clé connue
4
La vérification réussit
Tâche Verify
État OK
5
La restauration fonctionne
restore … --keyfile
facture-114.txt identique, durée notée
6
Le compte volé ne peut pas supprimer
snapshot forget
Refusé (permission)
7
Sans clé, pas de restauration
restore sans --keyfile
Erreur « missing key »
8
L'administrateur est protégé
Connexion admin-sauv@pbs
Code TOTP demandé
Suis ta progressionConnecte-toi pour marquer les ressources comme terminées et retrouver ton avancement.