Considérons une application de facturation arrêtée un lundi matin. Les fichiers de la veille existent dans les sauvegardes, mais l’équipe doit encore rétablir la base de données, les comptes, les clés et les échanges avec les autres logiciels. Retrouver une copie est une première étape ; reprendre la facturation demande un service utilisable.
Un test de restauration permet d’examiner cette chaîne avant un incident. Il mesure le temps nécessaire, révèle les dépendances oubliées et vérifie que les personnes désignées savent exécuter la procédure. Sa valeur tient au résultat observé dans des conditions décrites.
Fixer les objectifs à partir de l’activité
Le RTO (Recovery Time Objective) fixe le délai maximal de remise en service de l’application. Le RPO (Recovery Point Objective) fixe la perte maximale de données admissible, exprimée en durée avant l’incident. Ces objectifs servent à choisir la fréquence des sauvegardes, les réplicas et les ressources nécessaires à la restauration.
Dans notre exemple, l’entreprise pourrait viser une remise en service en quatre heures et accepter au maximum deux heures de données manquantes. Ces valeurs sont des hypothèses illustratives. Une application de soins, un système de paiement et des archives n’appellent pas nécessairement les mêmes objectifs.
Ces choix orientent la fréquence des copies, leur emplacement et les moyens de secours. Une sauvegarde quotidienne ne répond pas, à elle seule, à un objectif de deux heures de perte de données. De même, une copie distante très récente peut demander longtemps à transférer si la connexion ou le stockage de destination limite le débit.
L’équipe décrit aussi le travail possible pendant l’arrêt. Les moyens temporaires, les interlocuteurs à prévenir et l’ordre de reprise des applications complètent les objectifs techniques. Ils évitent de restaurer d’abord le système le plus facile lorsque l’activité dépend d’un autre.
Préparer une copie que l’incident ne détruit pas
La règle 3-2-1-1-0 prévoit trois copies, dont les données de production, sur deux types de stockage. Une copie est conservée hors site et une copie est hors ligne ou immuable. La vérification des sauvegardes et les tests de restauration visent zéro erreur non résolue. L’architecture précise les comptes d’administration et les clés nécessaires pour accéder à chaque copie.
Un compte d’administration compromis peut permettre la suppression des serveurs de production et des sauvegardes accessibles avec les mêmes permissions. Des identités d’administration séparées et une rétention immuable limitent cette propagation. Les tests vérifient les droits de lecture, de restauration et de suppression, y compris ceux qui administrent le logiciel de sauvegarde.
L’équipe protège également les clés nécessaires à la restauration. Une sauvegarde chiffrée devient inutilisable si la seule copie de sa clé disparaît avec le serveur d’origine. Les accès de secours et les informations permettant de les récupérer doivent rester disponibles dans les conditions de l’exercice.
Restaurer un service avec ses dépendances
L’essai progresse du plus simple au plus complet. La restauration d’un fichier vérifie la récupération d’un contenu. Celle d’un dossier vérifie aussi les permissions. La restauration d’un service ajoute l’application, ses données et les composants nécessaires à son fonctionnement.
Le service de test reste isolé de la production. Une application restaurée ne doit pas envoyer de vraies factures, lancer un paiement ni synchroniser d’anciennes données vers un système actif. L’équipe prévoit les accès réseau et les paramètres qui empêchent ces effets tout en permettant les vérifications utiles.
Le chronomètre commence au point défini dans le scénario. L’équipe consigne séparément l’accès aux sauvegardes, le transfert, la remise en route et les essais métier. Le temps total comprend les attentes et les difficultés rencontrées ; le seul temps de copie donnerait une vision incomplète de la reprise.
Transformer le résultat en décision
Après la restauration, les tests applicatifs vérifient l’ouverture d’un dossier, la recherche d’un document, la création d’une facture de test ou la consultation d’un historique, selon les fonctions du logiciel. L’équipe compare les données récupérées au point de reprise attendu et contrôle les droits, les interfaces et les clés.
Supposons que l’exercice de facturation dure six heures pour un objectif de quatre. La mesure ne signifie pas simplement que le test a échoué. Elle permet d’identifier les deux heures consacrées, par exemple, à retrouver un accès et à corriger une dépendance. L’organisation peut améliorer la procédure, prévoir une ressource de secours ou revoir son objectif en connaissance de cause.
| Élément du compte rendu | Utilité pour la prochaine décision |
|---|---|
| Scénario et périmètre | Définir les incidents que l’exercice représente |
| Copie et point de reprise | Vérifier la fraîcheur des données récupérées |
| Durées mesurées | Comparer la reprise à l’interruption acceptable |
| Essais métier et intégrité | Confirmer que le service est utilisable |
| Écarts et responsables | Affecter les corrections et fixer leur vérification |
Une seconde personne doit pouvoir reprendre la procédure avec les accès prévus. L’exercice vérifie ainsi la transmission des connaissances, autant que la technologie. Les tests sont rejoués après une migration ou une modification des dépendances de l’application, en complément des exercices planifiés selon les objectifs de reprise.
La restauration traite la disponibilité et la perte de données. Lorsqu’un attaquant a exfiltré et publié des fichiers, leur restauration sur l’infrastructure interne ne retire pas les copies déjà diffusées. Les mesures de confidentialité et la gestion de l’incident restent donc nécessaires.
Une organisation dispose d’une capacité de reprise crédible lorsqu’elle connaît les conditions du test, ses résultats et ses limites. Le prochain investissement peut répondre à un écart précis, et le prochain exercice vérifier que cet écart a diminué.
Références
- OFCS | mesures de protection contre les rançongiciels
- Les scénarios d’attaque et leurs conséquences pour l’organisation
Les objectifs et l’exemple chiffré servent ici à expliquer la méthode ; chaque organisation définit ses propres scénarios et critères de reprise.