La virtualisation a simplifié la sauvegarde au point de créer une illusion de sécurité. Prendre une image complète d’une machine en quelques minutes donne le sentiment d’être couvert.
Trois caractéristiques propres à ces environnements produisent pourtant des situations où rien n’est récupérable.
Piège n° 1 : confondre instantané et sauvegarde
Un instantané fige l’état d’une machine à un instant donné, en conservant les modifications ultérieures dans des fichiers différentiels. C’est un mécanisme de retour arrière court, conçu pour annuler une mise à jour qui se passe mal.
Ce n’est pas une sauvegarde, pour trois raisons :
- Il dépend du disque d’origine. Si le stockage sous-jacent est perdu ou chiffré, l’instantané l’est aussi.
- Il dégrade les performances et grossit indéfiniment s’il est conservé.
- Il est administré depuis la même console que les machines qu’il protège.
Une organisation dont la stratégie de reprise repose sur des instantanés n’a pas de sauvegarde au sens de la règle 3-2-1. Elle a un mécanisme d’annulation.
Piège n° 2 : la console d’administration comme point unique
C’est le problème structurant. Dans un environnement virtualisé, un compte disposant des droits d’administration sur l’hyperviseur peut, en quelques commandes, supprimer l’intégralité des machines, des instantanés et souvent des sauvegardes si celles-ci sont pilotées depuis le même plan d’administration.
C’est exactement ce que cherche un attaquant dans la phase de neutralisation des défenses, et c’est plus rapide que de chiffrer machine par machine.
Trois mesures s’imposent :
- Cloisonner l’administration de la virtualisation comme un niveau à part entière — comptes dédiés, postes dédiés, authentification renforcée. Voir le cloisonnement par niveaux.
- Séparer l’administration de la sauvegarde de celle de l’hyperviseur. Un administrateur de la virtualisation ne doit pas pouvoir supprimer les sauvegardes.
- Disposer d’une copie immuable ou déconnectée, hors de portée de tout compte du plan d’administration.
Piège n° 3 : le stockage partagé
Machines de production, machines de sauvegarde et parfois les sauvegardes elles-mêmes résident sur la même baie.
La redondance de la baie protège contre la panne d’un disque. Elle ne protège ni contre un chiffrement, ni contre une erreur de manipulation, ni contre la perte du site — même logique que pour la redondance en trompe-l’œil.
La question à se poser : si cette baie disparaît, que reste-t-il ? Si la réponse est « rien », la stratégie de sauvegarde est à revoir indépendamment de sa qualité technique.
Ce qui doit être sauvegardé et qu’on oublie
Sauvegarder les machines virtuelles ne suffit pas à reconstruire un environnement. Il manque presque toujours :
- La configuration de l’infrastructure virtuelle : réseaux virtuels, règles de placement, politiques de stockage, droits.
- Les composants d’administration eux-mêmes. Restaurer cent machines sans la console qui les orchestre est une opération longue et manuelle.
- Les secrets : certificats, clés, identifiants de service. Voir la gestion des secrets.
- La documentation de reconstruction, qui doit être accessible hors du système à reconstruire.
Ce dernier point est régulièrement pris en défaut lors des exercices de crise : la procédure de reprise est stockée sur un serveur de fichiers qui fait partie du périmètre indisponible.
La cohérence applicative
Une sauvegarde de machine prise sans coordination avec l’application produit une image cohérente au niveau du disque, pas au niveau des données.
Pour une base de données, cela signifie une restauration qui démarre mais dont les données sont dans un état intermédiaire. Le mécanisme de sauvegarde doit donc dialoguer avec l’application pour figer proprement les écritures avant l’instantané.
Ce point ne se découvre qu’au moment du test de restauration, ce qui est une raison supplémentaire d’en faire.
Le test spécifique à mener
Au-delà du test de restauration classique, un scénario propre à ces environnements mérite d’être joué :
La console d’administration est indisponible ou compromise, et les comptes d’administration ne sont plus fiables. Que fait-on ?
Questions à trancher :
- Où sont les identifiants nécessaires à la reconstruction, si l’annuaire et le gestionnaire de secrets sont indisponibles ?
- La sauvegarde est-elle atteignable sans passer par le plan d’administration compromis ?
- Combien de temps pour reconstruire l’infrastructure d’accueil avant même de commencer à restaurer ?
- Sait-on vérifier que ce qu’on restaure n’est pas déjà compromis ?
La troisième question est celle qui fait exploser les délais annoncés. Restaurer des données est rapide ; reconstruire l’environnement qui les accueille ne l’est pas.
Le cas des environnements hébergés
Les mêmes principes s’appliquent, avec une nuance : la réplication assurée par le fournisseur protège contre la panne matérielle, pas contre la suppression, l’erreur ou le chiffrement.
Deux points à vérifier contractuellement : la durée réelle de rétention des copies, et la possibilité d’exporter les sauvegardes hors de l’environnement du fournisseur. Sans cette seconde capacité, la réversibilité annoncée est théorique — voir la responsabilité partagée.
Les six vérifications
- Des instantanés sont-ils comptés comme des sauvegardes dans votre plan de reprise ?
- Un compte d’administration de l’hyperviseur peut-il supprimer les sauvegardes ?
- Existe-t-il une copie hors du stockage de production, immuable ou déconnectée ?
- La configuration de l’infrastructure virtuelle est-elle sauvegardée, pas seulement les machines ?
- Les sauvegardes de bases sont-elles cohérentes au niveau applicatif ?
- Quand a-t-on chronométré une reconstruction complète, console comprise ?
Sources
- ISO/IEC 27002:2022, mesures 8.13 (sauvegarde), 8.9 (gestion de la configuration) et 5.30 (continuité des TIC)
- ANSSI — guides sur les rançongiciels et la sauvegarde
- Règlement (UE) 2016/679 (RGPD), article 32
Aller plus loin
L’évaluation de votre dispositif de reprise fait partie de l’audit 360, et son exploitation dans la durée de notre maintien en condition de sécurité.