Plan de reprise d'activité : le PRA à l'épreuve
du rançongiciel

Le 27 juin 2017, NotPetya entre chez Maersk par la mise à jour piégée d'un logiciel comptable ukrainien et efface en quelques heures l'informatique d'un des premiers armateurs mondiaux. La suite est publique, racontée par le dirigeant du groupe à Davos en janvier 2018 : de l'ordre de 4 000 serveurs et 45 000 postes réinstallés en une dizaine de jours. Ce que cette reconstruction doit au hasard mérite d'être retenu : tous les contrôleurs de domaine avaient été détruits, sauf un, dans une agence du Ghana, épargné parce qu'une coupure de courant l'avait laissé hors ligne au mauvais moment. Sans ce disque, l'annuaire ne pouvait plus être reconstruit, et le plan de reprise s'arrêtait là.

L'idée la plus répandue au sujet du plan de reprise d'activité, c'est qu'on en a un dès lors qu'on a des sauvegardes. C'était à peu près vrai tant que le sinistre de référence était l'incendie de salle machine ou la baie de disques qui lâche. Ça ne l'est plus depuis que le sinistre de référence est un adversaire qui a passé des semaines dans le système d'information, qui a lu la documentation d'exploitation avant vous, et qui a commencé son travail par les sauvegardes.

PCA et PRA : deux plans qui ne répondent pas à la même question

Le plan de continuité d'activité (PCA) répond à une question métier : comment l'entreprise continue-t-elle à livrer, facturer, soigner ou produire pendant que le système d'information est indisponible ? Il parle de modes dégradés, de procédures manuelles, de cellule de crise, de communication aux clients et aux autorités. Le plan de reprise d'activité (PRA), qu'on appelle aussi PRA informatique ou plan de reprise après sinistre, répond à une question technique : dans quel ordre, depuis quelles sauvegardes et en combien de temps le système est-il remis en état de marche. Le second est le volet technique du premier.

La confusion est fréquente, et elle a un coût pratique. Une organisation peut disposer d'une infrastructure de reprise irréprochable et rester paralysée parce que personne n'a écrit qui décide, qui parle à la presse et comment on continue à travailler sans messagerie. Les établissements de santé français en ont donné plusieurs illustrations publiques entre 2019 et 2022 : pendant des semaines, les équipes ont fonctionné au papier et au téléphone, ce qui relève du PCA, pendant que la reconstruction du système d'information suivait son propre calendrier. Le sujet est développé dans l'article consacré à la cyberattaque sur un hôpital, où le mode dégradé est la partie visible de la crise.

RTO et RPO : les deux chiffres qui commandent le reste

Tout PRA se ramène à deux valeurs. Le RTO (Recovery Time Objective) est la durée d'interruption que l'activité accepte avant que le service ne redevienne utilisable. Le RPO (Recovery Point Objective) est la quantité de données que l'on accepte de perdre, mesurée en temps écoulé depuis la dernière sauvegarde réellement exploitable.

         <-------- RPO -------->|<--------- RTO --------->
   ------+----------------------+-------------------------+------>
         ^                      ^                         ^
   derniere sauvegarde       incident                service remis
   reellement exploitable     (T zero)               en production

   RPO = ce que l'on accepte de PERDRE   (volume de donnees)
   RTO = ce que l'on accepte d'ATTENDRE  (duree d'interruption)

Ces deux nombres sont des décisions de direction, pas des réglages d'administrateur système : ils fixent le budget de l'infrastructure de reprise. Descendre le RPO d'une journée à quinze minutes, c'est passer de la sauvegarde nocturne à de la journalisation continue. Descendre le RTO de trois jours à quatre heures, c'est financer un site de secours tenu à chaud. Le piège classique consiste à écrire le chiffre qui rassure le comité de direction sans jamais le confronter à l'arithmétique : restaurer 12 To depuis un stockage distant sur un lien à 1 Gb/s demande plus de vingt-six heures au débit théorique, avant même de parler de décompression, de vérification d'intégrité et de remontée applicative. Un RTO de quatre heures posé au-dessus de cette réalité est un souhait.

Le PRA de manuel a été écrit pour l'incendie, pas pour un adversaire

Un incendie, une inondation ou une panne de baie ont trois propriétés confortables : l'événement est daté, il ne cherche pas vos sauvegardes, et il ne vous observe pas pendant que vous réagissez. Un rançongiciel inverse les trois. L'intrusion initiale précède le chiffrement de plusieurs semaines, l'attaquant identifie et neutralise les sauvegardes avant de déclencher quoi que ce soit, et il choisit son moment, en général un vendredi soir ou une veille de jour férié, quand l'astreinte est mince. La chaîne complète, du courriel piégé au chiffrement, est détaillée dans l'article de fond sur le rançongiciel.

La conséquence la plus lourde concerne le RPO. Face à une panne, le point de reprise est la dernière sauvegarde. Face à une intrusion, il faut d'abord établir depuis quand l'environnement est compromis, et le point de reprise devient le résultat d'une investigation. Le chiffre écrit dans le plan ne sert plus à rien : il est remplacé par une date qu'on découvre au bout de quelques jours d'analyse.

Une sauvegarde atteignable depuis le domaine n'est pas une sauvegarde

La règle 3-2-1, trois copies sur deux supports dont une hors site, reste un bon point de départ. Elle est insuffisante seule, parce qu'elle raisonne en termes de localisation et jamais en termes d'accessibilité. Trois copies parfaitement réparties mais toutes joignables avec un compte privilégié de l'annuaire forment une seule cible logique. De même, la réplication n'est pas une sauvegarde : elle recopie fidèlement le chiffrement sur le site secondaire, souvent en quelques minutes.

Le cas de l'hébergeur danois CloudNordic, en août 2023, a le mérite de la clarté : l'entreprise a annoncé publiquement que le chiffrement avait atteint ses systèmes de sauvegarde et de réplication en même temps que la production, et que les données de nombreux clients étaient définitivement perdues. Ce qui manquait n'était pas une copie supplémentaire, mais une copie hors d'atteinte.

• Immuabilité : verrouillage d'objet (Object Lock) sur le stockage d'archivage, instantanés en écriture unique côté baie, rétention que même l'administrateur ne peut pas raccourcir avant échéance. C'est la seule protection qui résiste à un attaquant disposant des droits d'administration.
• Une copie réellement hors ligne : bande sortie du robot, disque débranché, coffre. Peu élégant, très efficace, et le seul support dont on soit certain qu'aucune commande à distance ne l'atteint.
• Isolation d'authentification : la console de sauvegarde ne se connecte pas à l'annuaire de production, ses comptes sont locaux, protégés par un second facteur, et distincts des comptes d'administration du parc.
• Vérification automatique des restaurations : un travail de sauvegarde en vert prouve qu'un fichier a été écrit, rien de plus. La déclinaison courante de la règle, dite 3-2-1-1-0, ajoute précisément ces deux exigences : une copie immuable ou hors ligne, et zéro erreur à la vérification.

Restaurer depuis une sauvegarde compromise, c'est réinviter l'attaquant

L'accès de l'attaquant est presque toujours plus ancien que le chiffrement. Restaurer l'image de la semaine précédente remet donc en service, avec les données, le compte de service créé pour l'occasion, la tâche planifiée qui rappelle une infrastructure de commande, l'outil d'administration à distance installé par le prestataire fantôme et la clé publique ajoutée dans un fichier d'autorisation. Des organisations se sont fait chiffrer une seconde fois pendant leur propre reprise, faute d'avoir traité ce point.

Quelques principes limitent le risque. Le point de restauration se choisit à partir de la chronologie établie par l'investigation, pas à partir du calendrier des sauvegardes. Les serveurs d'infrastructure se reconstruisent depuis des images de référence plutôt que de se restaurer, les données étant réinjectées ensuite. Tous les secrets sont renouvelés, comptes de service, clés d'API, certificats, et le compte krbtgt réinitialisé deux fois avec l'intervalle de réplication entre les deux. Enfin, la restauration se déroule sur un réseau séparé du réseau compromis, avec des postes d'administration neufs. Et la faille d'entrée se referme avant la remise en ligne, ce qui suppose de savoir laquelle c'était : la discipline décrite dans l'article sur la gestion des vulnérabilités et l'ordonnancement proposé dans le plan de remédiation s'appliquent en sortie de crise comme en régime de croisière.

L'annuaire : la dépendance qu'on découvre le jour J

Tout le reste en dépend. L'hyperviseur s'authentifie sur l'annuaire, la console de sauvegarde aussi, le serveur de fichiers n'a plus de sens sans lui, et la messagerie non plus. La restauration d'une forêt Active Directory est pourtant une procédure à part entière : restaurer un contrôleur de domaine à la légère depuis un instantané de machine virtuelle provoque des incohérences de réplication qui se paient plus tard, la reconstruction commence par un seul contrôleur par domaine, suivie d'un nettoyage des métadonnées et d'une saisie des rôles à maître unique. Cette procédure doit exister sur papier, à jour, hors du système qu'elle sert à relever. C'est exactement le point sur lequel Maersk a tenu par accident.

Le PRA rangé sur le système qui vient de tomber

Le plan est un document sur l'espace collaboratif interne, l'annuaire des contacts est dans la messagerie, les mots de passe d'administration dans un coffre qui s'authentifie sur le domaine, et le standard téléphonique est en voix sur IP sur le même réseau. Chiffrez le tout un vendredi soir : il ne reste ni procédure, ni numéro de téléphone, ni moyen de se connecter à quoi que ce soit. Ce scénario n'a rien d'exotique, il est la règle plutôt que l'exception.

La parade est peu coûteuse. Une copie hors ligne du plan, chiffrée sur un support détenu par deux personnes, et une copie papier dans un coffre. Des comptes de secours locaux, scellés, testés une fois par an. Un canal de communication indépendant du système d'information, avec les numéros personnels de la cellule de crise. Et la liste des interlocuteurs à prévenir : assureur, prestataire de réponse à incident, autorité de contrôle, clients sous contrat. Les délais de notification applicables aux entités concernées sont détaillés dans le guide sur la directive NIS2, et ils commencent à courir au moment le plus défavorable, celui où personne ne sait encore ce qui se passe.

Ce que le chronomètre apprend, et que le plan ignore

Vérifier qu'un travail de sauvegarde s'est terminé sans erreur ne teste rien. Seule la restauration effective, chronométrée, dans un environnement isolé, produit une information exploitable. Et cette information est presque toujours la même : le délai réel dépasse le RTO affiché. Les raisons sont banales et cumulatives, débit du lien de restauration, ordre des dépendances, licences à réactiver, matériel de remplacement à commander, effectif disponible un samedi, connecteur d'authentification qui pointe sur un annuaire pas encore relevé.

La British Library a documenté publiquement cet écart après l'attaque du 28 octobre 2023. Son rapport de retour d'expérience, publié en mars 2024, explique que la reprise a été entravée par une infrastructure vieillissante qu'on ne pouvait pas simplement remettre en service telle quelle : il a fallu reconstruire plutôt que restaurer, et le catalogue en ligne est resté indisponible pendant des mois. Aucun plan ne survit à ce genre de découverte s'il n'a jamais été confronté à l'infrastructure réelle.

Ce que NIS2 et DORA attendent réellement

L'article 21.2 (c) de la directive NIS2 range la continuité des activités, la gestion des sauvegardes, la reprise des activités et la gestion des crises parmi les mesures minimales exigées des entités essentielles et importantes. Le texte ne prescrit ni format ni outil, ce qui déçoit souvent les organisations en quête d'une liste à cocher. La contrainte réelle est ailleurs, à l'article 21.2 (f) : il faut évaluer l'efficacité des mesures adoptées. Un plan classé sans restauration testée ne démontre rien du tout. Les seuils d'assujettissement et l'effet ricochet sur les sous-traitants sont traités dans le guide NIS2 pour les PME, et la façon dont un dossier de preuve technique se construit dans l'article sur l'audit NIS2.

Côté financier, le règlement DORA est nettement plus directif. Son article 11 impose une politique de continuité des activités liée aux technologies de l'information, des plans de réponse et de rétablissement, et leur test à une fréquence au moins annuelle. Son article 12 traite spécifiquement des politiques de sauvegarde et des méthodes de restauration, avec une exigence que beaucoup d'organisations hors secteur financier gagneraient à s'appliquer d'elles-mêmes : les systèmes de sauvegarde doivent être séparés, physiquement et logiquement, des systèmes source. Le détail du dispositif est repris dans l'article consacré au règlement DORA.

Un mot sur la répartition des rôles. Rédiger un plan de continuité, animer une cellule de crise ou conduire un exercice de gestion de crise relèvent du conseil en gouvernance : own2pwn ne le fait pas et ne délivre aucune attestation. Ce qu'un travail offensif apporte à ce dossier est plus étroit et plus vérifiable : établir par où un attaquant entrerait, ce qui est réellement exposé, et si les chemins qui mènent à la console de sauvegarde sont aussi étroits que le schéma le prétend.

À retenir

• Le PCA maintient l'activité pendant le sinistre, le PRA remet le système d'information en service. Les deux se préparent, l'un ne remplace pas l'autre.
• RTO et RPO sont des décisions métier qui fixent le budget. Face à un rançongiciel, le RPO n'est plus une valeur planifiée mais le résultat d'une investigation.
• La règle 3-2-1 ne protège de rien si les trois copies sont atteignables depuis l'annuaire. Il faut de l'immuabilité, du hors ligne, et une console de sauvegarde à l'authentification isolée.
• Restaurer avant d'avoir daté l'intrusion remet l'attaquant en production. Les serveurs d'infrastructure se reconstruisent, les secrets se renouvellent, l'annuaire suit une procédure dédiée disponible hors ligne.
• Le plan doit exister hors du système qu'il sert à relever : copie papier, comptes de secours scellés, canal de communication indépendant.
• Tant qu'aucune restauration n'a été chronométrée, le RTO affiché reste un chiffre de réunion. Le test annuel sert d'abord à mesurer son écart avec le délai réel, écart que NIS2 (article 21.2 (c) et (f)) et DORA (articles 11 et 12) attendent de vous voir traiter.

Un plan de reprise se juge le jour de la restauration, mais il se joue bien avant, sur la porte que l'attaquant a trouvée ouverte des semaines plus tôt. Savoir ce que votre organisation expose réellement sur internet, et par où une intrusion commencerait, est le préalable technique à toute cette discussion : c'est ce que fait notre plateforme de gestion de la surface d'attaque externe. Pour confronter cette exposition à un scénario d'attaque réel, dites-le-nous depuis la page contact.