Sauvegarde : l'enjeu décisif, c'est la restauration

La plupart des entreprises disposent d'une sauvegarde. Beaucoup moins ont vérifié qu'elle permet réellement de restaurer leurs données, et dans quel délai. C'est pourtant la seule question qui compte le jour d'un incident.

Lorsqu'un serveur tombe ou qu'un rançongiciel chiffre les données, deux points déterminent l'impact sur l'activité : le temps nécessaire pour redémarrer, et la quantité de données perdues. Un indicateur « sauvegarde réussie » ne renseigne sur aucun des deux.

Les causes d'échec les plus fréquentes

Les incidents observés en entreprise relèvent presque toujours des mêmes situations :

• Un périmètre incomplet : une application ajoutée après la mise en place de la sauvegarde, une base hébergée sur un autre serveur, des données restées sur des postes.
• Une copie exposée : un disque de sauvegarde connecté en permanence au réseau, chiffré par l'attaquant en même temps que les données de production.
• Une procédure absente : des données intactes, mais aucun ordre de redémarrage défini, ce qui transforme une restauration de quelques heures en plusieurs jours d'arrêt.

Une sauvegarde n'est pas un produit, c'est une chaîne : périmètre, supports, isolement, procédure et responsabilités. L'Agence nationale de la sécurité des systèmes d'information (ANSSI) en détaille les bonnes pratiques dans son guide Sauvegarde des systèmes d'information — les fondamentaux, une référence publique et gratuite.

La règle 3-2-1-1-0

La règle 3-2-1 est largement connue. Face aux rançongiciels, elle s'enrichit de deux exigences supplémentaires :

• 3 copies des données : les données de production et deux sauvegardes ;
• 2 supports de nature différente ;
• 1 copie hors site, à l'abri d'un sinistre sur vos locaux ;
• 1 copie hors ligne ou immuable, qu'un attaquant ne peut ni modifier ni supprimer, même avec des droits d'administrateur ;
• 0 erreur lors des vérifications de restauration.

La distinction entre hors site et hors ligne est essentielle. Une sauvegarde hébergée à l'extérieur mais accessible depuis votre réseau avec des identifiants d'administrateur peut être chiffrée par un attaquant qui les a obtenus. La copie hors ligne — sur bande ou sur un support déconnecté — ou immuable, verrouillée par le logiciel pendant une durée définie, est la seule à résister à ce scénario.

Le serveur de sauvegarde doit également être isolé du domaine de production et disposer de comptes d'administration distincts : sans cette séparation, la compromission de l'annuaire entraîne celle des sauvegardes.

Tester la restauration

Une sauvegarde qui n'a jamais été restaurée reste une hypothèse. Un test de restauration se prépare comme un exercice :

• une cible précise : un fichier, une boîte aux lettres, un serveur, une base de données ;
• un environnement qui n'affecte pas la production ;
• une mesure de la durée de restauration ;
• un compte rendu daté : éléments restaurés, durée, difficultés rencontrées.

Ces tests révèlent presque toujours un point bloquant : une licence à réactiver, un mot de passe local inconnu, une application dépendante d'un autre service. L'identifier lors d'un test prend quelques heures ; pendant un incident, plusieurs jours.

Pour une PME, un rythme réaliste consiste à effectuer un test ciblé chaque trimestre et une restauration complète du serveur le plus critique une fois par an. Deux précautions s'imposent : définir l'ordre de restauration — les services d'infrastructure comme l'annuaire et le DNS avant les applications métier — et, après une attaque, ne pas restaurer une machine compromise à l'identique, mais la réinstaller avant de réimporter des données contrôlées.

RPO et RTO : deux objectifs fixés par la direction

Le dimensionnement de la sauvegarde découle de deux objectifs, qui relèvent de la direction et non du seul service informatique.

• Le RPO (Recovery Point Objective) correspond à la perte de données maximale acceptable. Avec une sauvegarde quotidienne, il est de 24 heures : une journée de saisies, de commandes ou de documents à reconstituer.
• Le RTO (Recovery Time Objective) correspond à la durée d'interruption maximale acceptable. Quelques heures sans messagerie peuvent se gérer ; plusieurs jours sans logiciel de production, rarement.

Ces deux valeurs déterminent la fréquence des sauvegardes, le choix des supports et le besoin éventuel d'une infrastructure de secours. Un RPO inférieur à 24 heures ne peut généralement pas être atteint par la seule sauvegarde : il nécessite des mécanismes de réplication.

Du plan de sauvegarde au plan de reprise

Le plan de reprise d'activité formalise l'ensemble : quoi restaurer, dans quel ordre, avec quels moyens, par qui et avec quels accès. Il intègre des éléments souvent oubliés : les supports d'installation et les configurations des applications métier, la sauvegarde de l'infrastructure de sauvegarde elle-même et la liste des contacts. Il prévoit enfin la possibilité d'isoler immédiatement les sauvegardes du réseau au début d'un incident.

Les environnements Microsoft 365 entrent dans ce périmètre. La corbeille et les stratégies de rétention ne constituent pas une sauvegarde : elles sont limitées dans le temps et modifiables par tout compte administrateur, y compris compromis. La messagerie et les fichiers hébergés dans le cloud doivent être sauvegardés au même titre que le reste ; nous l'intégrons à nos missions de gestion de parc informatique.

Faire le point sur vos sauvegardes

MG Solutions accompagne les entreprises dans l'audit de leurs sauvegardes, la mise en place de la règle 3-2-1-1-0, les tests de restauration et la rédaction du plan de reprise. Nos prestations sont détaillées sur la page cybersécurité en entreprise.

Professionnels : 02 51 67 51 22 · hotline@mg-solutions.fr