« On a des sauvegardes » — la question suivante est la bonne

« On a des sauvegardes. » C’est la phrase que nous entendons le plus souvent en audit, et c’est presque toujours vrai. Les sauvegardes tournent, le rapport quotidien passe au vert, la case est cochée.

Puis on demande quand la dernière restauration complète a été testée, et la conversation change de nature.

Sauvegarder n’est pas restaurer

Une sauvegarde qui se déroule sans erreur prouve une seule chose : les données ont été copiées quelque part. Elle ne dit rien de la capacité à les remettre en service, et c’est pourtant la seule chose qui compte le jour où il faut le faire.

Les écarts se découvrent invariablement pendant la crise. Une base restaurée dans un état incohérent avec les fichiers applicatifs. Une machine virtuelle qui redémarre mais dont personne ne connaît le mot de passe local. Une application qui exige une licence réémise par un éditeur injoignable un dimanche. Un jeu de sauvegarde complet, mais dont la restauration prend onze jours parce que le lien de récupération n’a jamais été dimensionné pour un volume total.

Aucun de ces problèmes n’apparaît dans un rapport de sauvegarde. Tous apparaissent au premier test.

La question qui prime sur toutes les autres

Avant même la fréquence ou la rétention : votre sauvegarde est-elle atteignable depuis un compte d’administration du domaine ?

Si la réponse est oui, elle sera chiffrée en même temps que le reste. C’est devenu une étape standard : l’attaquant identifie la solution de sauvegarde, supprime les points de restauration, puis déclenche le chiffrement. La sauvegarde qui existait le matin n’existe plus le soir.

La parade porte un nom d’usage — la règle du 3-2-1 — mais l’essentiel tient à une seule clause : au moins une copie hors d’atteinte, soit physiquement déconnectée, soit sur un stockage immuable où l’effacement est techniquement impossible pendant une durée fixée. Sans cela, tout le reste est décoratif.

Ce que révèle un test chronométré

Le test utile n’est pas de restaurer un fichier — ça marche toujours. C’est de remettre en service un applicatif réellement utilisé, sur une infrastructure vierge, en partant des sauvegardes et de la documentation, sans l’aide de la personne qui a construit le système.

Deux chiffres en sortent, et ce sont ceux qui intéressent une direction générale : combien de temps la remise en service prend réellement, et quelle quantité de travail est perdue entre le dernier point de sauvegarde et l’incident. Ces deux nombres se comparent à ce que l’activité peut absorber. Le plus souvent, l’écart est considérable, et il est la vraie information de l’exercice.

Un test par an sur le système le plus critique suffit à faire émerger l’essentiel. Une demi-journée, deux personnes.

Le détail qui fait perdre une journée

La procédure de restauration est presque toujours stockée sur le système d’information qu’elle est censée aider à reconstruire.

Le jour de l’incident, l’intranet est indisponible, la messagerie aussi, le gestionnaire de mots de passe est peut-être compromis. Il faut alors reconstituer de mémoire, à plusieurs, sous pression.

Une version imprimée dans un classeur, avec les contacts éditeurs, les numéros de contrat, les identifiants de secours en enveloppe scellée et l’ordre de redémarrage des applications, coûte une matinée à produire. C’est probablement la meilleure heure de travail investie dans un plan de continuité.

Sources

• ANSSI — recommandations relatives aux sauvegardes et à la continuité d’activité ; « Attaques par rançongiciels, tous concernés »
• Règlement (UE) 2016/679 (RGPD), article 32 — capacité à rétablir la disponibilité des données en cas d’incident