Sauvegardes : vérifier la restauration avant la crise

Distinguer la copie du service rendu

Un service numérique repose rarement sur un seul fichier. Il peut dépendre d’une base de données, d’une configuration, de comptes d’administration, d’un certificat ou d’un composant exploité par un prestataire. Une copie disponible peut donc rester inutilisable si une de ces dépendances n’est pas accessible.

Le guide de l’ANSSI consacré aux sauvegardes traite cette capacité comme un élément de réponse aux incidents opérationnels et de sécurité. Cybermalveillance.gouv.fr recommande notamment de protéger les copies et de tester leur restauration. Ces repères invitent à examiner le dispositif dans son ensemble, sans garantir qu’une configuration particulière convient à tous les systèmes.

Se poser la question de l’usage final

Pour un service documentaire, retrouver des fichiers ne suffit pas si les utilisateurs ne peuvent pas les ouvrir ou si les versions utiles manquent. Pour une application de commande, démarrer le serveur ne prouve pas que les transactions et les droits d’accès sont cohérents. L’exercice doit donc préciser le résultat attendu par le métier.

Préparer un test maîtrisé

Le premier choix porte sur le périmètre. Il peut s’agir d’un ensemble de données, d’une application ou d’un parcours métier plus complet. Le responsable du test décrit l’environnement utilisé, les autorisations requises et les personnes à contacter en cas d’effet imprévu. Il précise ce qui sera volontairement exclu de l’exercice.

Recenser les dépendances avant le démarrage

La liste comprend les copies à utiliser, les outils nécessaires, les accès, la documentation et les interventions de tiers. Les informations qui permettent la restauration doivent elles-mêmes rester accessibles dans le scénario testé. Une procédure conservée uniquement sur le service indisponible illustre une dépendance à traiter.

Définir les critères de réussite

Un test devient difficile à interpréter lorsque la réussite est définie après coup. Avant de commencer, convenir des données à retrouver, des fonctions à vérifier et des personnes habilitées à valider le résultat. Le temps mesuré doit correspondre à un début et à une fin clairement décrits.

Mesurer sans transformer une hypothèse en engagement

Le délai observé dans un environnement d’essai n’est pas automatiquement celui d’une crise réelle. L’exercice peut disposer d’équipes déjà réunies ou d’un système de remplacement disponible. Ces conditions doivent apparaître dans le compte rendu. Il devient alors possible de comparer les tests et d’identifier les écarts avec les besoins métier.

• Vérifier la lisibilité et la cohérence d’un échantillon défini à l’avance.
• Contrôler les accès nécessaires aux utilisateurs concernés.
• Exécuter le parcours métier retenu dans le protocole.
• Relever les temps, les interventions manuelles et les dépendances non prévues.

Dérouler un exercice fictif

Imaginons une organisation qui souhaite vérifier la récupération de son espace documentaire. Elle choisit un périmètre de test isolé, un ensemble de documents et un représentant du métier. Cet exemple est pédagogique : il ne correspond pas à un client ou à une prestation réalisée par T-SCOP.

1. Préparer : identifier la copie, les accès et les versions à retrouver ; confirmer les conditions d’arrêt.
2. Restaurer : suivre la procédure approuvée et noter les étapes qui nécessitent une information supplémentaire.
3. Contrôler : vérifier l’ouverture des documents, leur version et les droits du groupe d’utilisateurs retenu.
4. Conclure : conserver les résultats, les limites du test et les actions à faire arbitrer.

Si les documents sont récupérés mais que les droits ne peuvent pas être rétablis, le compte rendu doit le dire explicitement. Déclarer l’ensemble du test réussi masquerait le travail restant. À l’inverse, un échec partiel fournit une information utile lorsqu’il permet de localiser une dépendance et de préparer une correction.

Transformer les écarts en décisions

Le compte rendu peut distinguer les constats techniques, les conséquences pour l’activité et les décisions attendues. Chaque action possède un responsable, une priorité et une preuve de clôture. Une correction qui modifie la procédure ou le périmètre de sauvegarde peut nécessiter une nouvelle vérification.

Ces écarts alimentent le registre des risques numériques. Les arbitrages de moyens ou de priorité peuvent ensuite être examinés dans le cadre de la gouvernance cybersécurité. Cette liaison donne un sens aux résultats de l’exercice au-delà de la seule équipe technique.

La fréquence et l’étendue des tests doivent être adaptées aux changements du système, aux besoins de l’activité et aux exigences applicables. L’objectif de cet article est de fournir des questions de préparation, sans promettre une disponibilité, une conformité ou un niveau de protection qu’un exercice isolé ne permettrait pas de démontrer.