profciel.fr
// cyber

Sauvegarde en CIEL : tant qu’on n’a pas restauré, on n’a rien prouvé

Une activité courte pour transformer un avis de sécurité Veeam en vrai réflexe technicien : version, rôle, restauration, preuve.

· 3 min de lecture · cybersécurité · sauvegarde · Veeam · ransomware · Bac Pro CIEL

Une phrase revient souvent quand on parle cybersécurité :

“C’est bon, on a des sauvegardes.”

En atelier, cette phrase ne vaut pas grand-chose tant qu’on n’a pas une trace : quoi est sauvegardé, où, avec quels droits, et quand la dernière restauration a vraiment été testée.

Signal de départ : même l’outil de sauvegarde doit être maintenu

Le 27 mai 2026, le CERT-FR publie un avis sur de multiples vulnérabilités dans Veeam Backup & Replication. L’avis indique des risques d’élévation de privilèges et d’atteinte à l’intégrité des données pour les versions antérieures à 13.0.2.29.

Le bulletin éditeur Veeam KB4852, publié le même jour, précise que les vulnérabilités corrigées touchent Veeam Backup & Replication 13.0.1.2067 et les versions 13 antérieures, avec correction à partir de 13.0.2.29.

Ce n’est pas un prétexte pour faire peur aux élèves. C’est beaucoup plus utile que ça : montrer qu’un plan de sauvegarde se vérifie comme n’importe quel système.

L’activité : 30 minutes, sans drama

Objectif : faire produire une preuve simple, pas un exposé Wikipédia.

1. Lire l’avis comme un technicien

Donner aux élèves deux sources :

  • l’avis CERT-FR ;
  • le bulletin éditeur Veeam.

Questions rapides :

Quel est le produit concerné ?
Quelle version est indiquée comme corrigée ?
Quels sont les risques cités par le CERT-FR ?
Quelle action est recommandée ?

Le but n’est pas de mémoriser les CVE. Le but est d’apprendre à passer de :

“J’ai vu passer une faille”

à :

“Quel produit ? Quelle version ? Quel risque ? Quelle décision ? Quelle trace ?”

2. Appliquer à un mini-lab

Pas besoin de Veeam pour travailler la compétence. On peut faire le même raisonnement avec une VM, un dossier partagé ou un petit service local.

Exemple de mini-lab :

VM : debian-web-01
Service : mini site HTML local
Donnée à protéger : /srv/www/
Sauvegarde : archive horodatée vers un dossier séparé
Preuve attendue : restauration dans /tmp/restore-test/ + comparaison

Commande possible côté Linux :

mkdir -p /tmp/restore-test
cp -a /srv/www/. /tmp/restore-test/
diff -qr /srv/www /tmp/restore-test

Si diff ne remonte rien, ce n’est pas “magique”. C’est une preuve minimale que la copie restaurée correspond au dossier source au moment du test.

3. Poser les bonnes questions

Faire remplir une fiche courte :

Élément sauvegardé :
Emplacement de la sauvegarde :
Date/heure du test :
Méthode de restauration :
Résultat observé :
Preuve fournie : capture, log, commande, hash, diff...
Point faible repéré :
Amélioration proposée :

Exemples de points faibles que les élèves peuvent repérer :

  • sauvegarde stockée sur la même machine que la donnée ;
  • droits trop larges sur le dossier de backup ;
  • aucune restauration testée ;
  • sauvegarde non horodatée ;
  • absence de journalisation ;
  • confusion entre “copie” et “plan de reprise”.

Le message à faire passer

Une sauvegarde, ce n’est pas un bouton rassurant dans une interface.

Pour un futur technicien CIEL, une sauvegarde correcte doit pouvoir être expliquée en quatre phrases :

  1. ce qu’on protège ;
  2. comment on le protège ;
  3. comment on restaure ;
  4. quelle preuve montre que ça marche.

Le reste, c’est de la décoration.

Sources