Un plan de reprise d'activité après sinistre (PRA) est la procédure documentée de restauration des services informatiques suite à une panne. Il précise quels systèmes doivent être remis en service, dans quel ordre, la durée de chaque intervention, le niveau de perte de données acceptable et les personnes responsables de l'opération. Il constitue le volet technique du plan de continuité d'activité. Alors qu'un plan de continuité d'activité assure le maintien des opérations par tous les moyens, un plan de reprise d'activité vise spécifiquement à remettre en service les systèmes eux-mêmes.
- Une liste système priorisée, héritée de analyse commerciale plutôt qu'inventé par l'informatique.
- Un objectif de récupération et un seuil de perte de données acceptable pour chaque système.
- Des manuels d'exploitation suffisamment détaillés pour qu'une personne autre que le personnel habituel puisse les suivre.
- L'ordre de dépendance est important, car les systèmes restaurés dans le mauvais ordre ne peuvent pas redémarrer.
- Un compte rendu de test, puisqu'une procédure de récupération non testée est une hypothèse.
Qu’est-ce qu’un plan de reprise après sinistre ?
Un plan de reprise d'activité (PRA) décrit comment les services technologiques sont rétablis après un incident les mettant hors service : panne matérielle, perte de données dans un centre de données, modification ratée, interruption d'une région cloud, ransomware. Il répond à trois questions pour chaque système concerné : dans quel délai doit-il être rétabli ? Quelle quantité de données récentes pouvons-nous nous permettre de perdre ? Et quelles sont les procédures exactes à suivre pour le remettre en service ?
Le mot « catastrophe » est trompeur. La plupart des incidents ne sont pas dramatiques. Une base de données corrompue, une migration ratée ou un certificat expiré sur un service critique vous conduiront au même plan d'intervention qu'une inondation. Préparer un plan uniquement pour les scénarios catastrophiques vous oblige à improviser face aux problèmes bien plus courants.
La planification de la reprise d'activité fait partie intégrante du dispositif plus global de continuité d'activité , qui définit les priorités et les délais de reprise. Si l'architecture technologique a été conçue sans ces éléments, le plan protège les systèmes dans un ordre qui n'a pas été validé par rapport aux besoins de l'entreprise.
Comment choisir une approche de rétablissement ?
L'objectif de reprise détermine l'architecture, et l'architecture détermine le coût. Ce compromis conditionne tout le reste du plan, et il est préférable de le définir explicitement plutôt que de se contenter de ce que l'infrastructure existante prend en charge. Trois grandes options existent, mais le vocabulaire technique employé est inutilement complexe pour des concepts pourtant assez simples.
| Restauration de sauvegarde | Veille chaude | Actif-actif | |
|---|---|---|---|
| Ce que c'est | Reconstruisez le service à partir de la dernière sauvegarde après une panne. | Une deuxième copie restait active mais inactive, et basculait en cas de besoin. | Deux copies actives se partagent le travail, il n'y a donc rien à allumer |
| fenêtre de perte de données | Depuis la dernière sauvegarde | Minutes de données | Près de zéro |
| Il est temps de restaurer | Heures en jours | Minutes à heures | Près de zéro |
| Protège contre | Données erronées ou cryptées | Perte d'infrastructure | Perte de site ou de région |
| Coût permanent | Stockage uniquement | Partie d'un second domaine | Deux propriétés habitables |
| Adapté à | Services capables de tolérer une panne | Services les plus critiques | Des services qui ne peuvent pas s'arrêter |
Rares sont les organisations qui nécessitent une approche uniforme. La méthode la plus efficace consiste à hiérarchiser les services : un petit nombre de services critiques bénéficient d’une protection coûteuse, la majorité d’une protection adaptée, et les services restants sont restaurés à partir de sauvegardes. Appliquer une approche unique de manière uniforme conduit soit à des dépenses excessives pour des activités qui pourraient supporter une journée de restauration, soit à imposer aux quelques services critiques un délai de reprise inacceptable pour l’entreprise.
Deux modes de défaillance se répètent. Le premier consiste à choisir une cible de récupération sans tenir compte du coût de l'architecture sous-jacente, ce qui a pour conséquence de s'engager sur une tâche que l'infrastructure ne peut pas accomplir. Le second est l'achat d'une réplication en supposant qu'il s'agit d'une solution de récupération, alors qu'un jeu de données corrompu ou chiffré est répliqué avec la même fidélité qu'un jeu de données sain. La réplication protège contre les pertes d'infrastructure. Les sauvegardes protègent contre les données corrompues ; les deux ne sont pas interchangeables.
Que doit contenir un plan de reprise après sinistre ?
Par système, et non par organisation. Un document unique décrivant l'approche en général n'est pas utilisable à trois heures du matin par la personne de garde.
- Objectifs de rétablissement: l'objectif temporel et la perte de données acceptable pour ce système, déterminés par l'analyse métier qui les a définis.
- Ordre de dépendance: ce qui doit être exécuté en premier. L'authentification, le réseau, le DNS et les bases de données précèdent généralement les applications qui en ont besoin.
- Le manuel d'exploitation: les étapes concrètes, rédigées de manière à ce qu'un ingénieur compétent qui n'est pas propriétaire du système puisse les exécuter.
- Accès et identifiants: comment un accès privilégié est obtenu pendant un incident, et est conservé dans un endroit qui survit à la panne.
- Restauration de données: où se trouvent les sauvegardes, comment vérifier leur intégrité et combien de temps prend réellement une restauration en fonction des volumes de données réels.
- Vérification: comment confirmer que le service fonctionne réellement et non pas seulement qu'il est en cours d'exécution.
- Rôles et escalade: qui décide de l'invoquer, qui l'exécute, qui communique et qui autorise un repli.
Parmi ces éléments, l'ordre des dépendances est le plus crucial, car une erreur à ce niveau engendre des défaillances qui ressemblent davantage à un dysfonctionnement du système qu'à une simple erreur de séquencement. Une application restaurée avant la base de données qu'elle consulte, ou avant le service d'identité auprès duquel elle s'authentifie, ne démarrera pas, et l'équipe perdra un temps précieux à diagnostiquer le mauvais problème. Ce schéma général se vérifie dans la plupart des environnements système.
Le détail qui manque le plus souvent est la durée réelle d'une restauration. Une sauvegarde effectuée pendant la nuit peut prendre beaucoup plus de temps à restaurer en production, et si personne ne l'a mesurée, le temps de récupération cible reste une estimation.
Il convient de fixer une limite. Un plan de reprise d'activité permet de restaurer les systèmes. La solution de contournement mise en œuvre par l'entreprise pendant cette restauration, pour un risque spécifique identifié, relève quant à elle d'un plan de contingence . Les organisations qui ne conservent que le plan technologique constatent souvent que personne n'a convenu de la manière dont l'activité se poursuivra entre-temps.
Il y a un enjeu plus important derrière tout cela.
Cette page aborde un aspect de la résilience des entreprises. Real Resilience — le cadre d'IO qui relie la sécurité, la confidentialité et la gouvernance de l'IA — offre une vision d'ensemble.
Comment tester un plan de reprise après sinistre ?
C’est lors des tests que les plans de reprise d’activité gagnent en crédibilité, et il existe une progression. Chaque niveau coûte plus cher et apporte davantage de preuves ; un programme qui ne dépasse jamais le premier niveau n’a pas permis d’obtenir de résultats significatifs.
| Type de test | Ce que cela prouve | Ce que ça coûte |
|---|---|---|
| Procédure pas à pas | Que la documentation soit complète et compréhensible par une personne qui ne l'a pas rédigée. | Quelques heures. Aucun système n'a été touché. |
| Exercice sur table | Que chacun connaisse son rôle et que la prise de décision et la gestion des situations conflictuelles fonctionnent sous pression. | Une demi-journée avec les bonnes personnes. |
| Restauration des composants | Que les sauvegardes sont effectivement restaurables et que la durée réelle de la restauration est connue. | Modéré. Nécessite un environnement isolé. |
| Basculement partiel | Qu'un service unique puisse fonctionner à partir de son état de récupération, dépendances comprises. | Planification importante. Risques liés au service. |
| basculement complet | Que l'environnement entier puisse fonctionner en mode de récupération, en charge, pendant que l'entreprise poursuit son activité. | Élevé. Nécessite généralement une fenêtre de planification. |
Consignez les échecs. Un journal de tests détaillant les problèmes rencontrés et corrigés constitue une preuve plus convaincante de la capacité opérationnelle qu'une série de tests réussis, qui suggèrent généralement des tests insuffisamment exigeants. La consignation des résultats, des responsables et des dates permet de transformer les tests en actions d'amélioration plutôt qu'en simples garanties.
Quelles normes encadrent la reprise après sinistre ?
Aucune norme n'est exclusivement dédiée à la reprise après sinistre, les exigences sont donc réparties entre plusieurs normes, ce qui explique en partie pourquoi la planification de la reprise finit souvent par être déconnectée de tout le reste.
- ISO 22301: le système de gestion certifiable de la continuité des activités. Il définit les priorités d'analyse et de reprise que doit intégrer un plan technologique.
- ISO / IEC 27031: des conseils spécifiques sur la préparation des TIC à la continuité des activités, qui correspondent le mieux à la reprise après sinistre en tant que discipline.
- ISO 27001L'annexe A comprend des contrôles sur la sécurité de l'information en cas de perturbation, la préparation des TIC pour la continuité et la sauvegarde de l'information, de sorte que la capacité de récupération est examinée lors d'un audit.
- Règles sectoriellesLes organisations réglementées sont soumises à des exigences supplémentaires, par exemple en matière de continuité et de reprise d'activité. Guide de mise en œuvre de NIS 2.
Travailler conjointement selon les normes ISO 22301 et ISO 27001 permet de fournir la plupart des preuves exigées par ces réglementations, sous une forme ayant déjà fait l'objet d'un audit indépendant.
Commencer votre essai gratuit
Envie d'explorer ?
Inscrivez-vous pour votre essai gratuit dès aujourd'hui et découvrez toutes les fonctionnalités de conformité qu'ISMS.online a à offrir.
Quel est le lien entre la reprise après sinistre et la résilience ?
La reprise après sinistre restaure les systèmes. La résilience, quant à elle, désigne la capacité plus globale à absorber les perturbations de toute nature, y compris les événements imprévus. Le lien entre les deux réside dans le fait que la reprise dépend entièrement de mécanismes de contrôle externes au plan de reprise : l’immuabilité des sauvegardes, le maintien du fonctionnement des accès privilégiés en cas d’indisponibilité du fournisseur d’identité, l’évaluation du fournisseur hébergeant l’environnement de reprise et le bon fonctionnement du processus de réponse aux incidents.
Le concept de boucle de résilience intègre la sécurité de l'information (ISO 27001), la protection des données ( ISO 27701) et la gouvernance de l'IA (ISO 42001) au sein d'un système unique et interconnecté, la reprise d'activité servant de cadre supplémentaire à ces mêmes contrôles. Les ransomwares illustrent parfaitement ce problème : ils constituent simultanément un incident de sécurité, une potentielle violation de données personnelles et une opération de récupération. Une organisation qui gère ces trois aspects séparément doit donc y faire face à trois reprises. La structure permettant d'éviter cette situation est décrite dans le cadre de résilience des entreprises.
Comment prouver l'efficacité d'un plan de reprise après sinistre ?
Personne de crédible n'accepte l'existence d'un plan comme preuve. Ce qui fait foi, c'est le plan lui-même, avec les objectifs de rétablissement actuels, les rapports de tests indiquant les dates et les participants, les défaillances que ces tests ont révélées, les mesures correctives mises en œuvre et la confirmation que le plan correspond toujours à la situation décrite.
Générées en temps réel, ces preuves sont toujours disponibles. Constituées avant un audit ou une vérification préalable chez un client, elles permettent généralement de constater l'écart entre le patrimoine documenté et le patrimoine réel. La démarche est décrite dans le document « Comment prouver la résilience » , et le score de résilience fournit un point de référence.
Pourquoi choisir ISMS.online pour la planification de la reprise après sinistre ?
Les plans de reprise d'activité échouent bien plus souvent en raison de problèmes de mise à jour que de problèmes de contenu. ISMS.online a été conçu pour garantir leur adéquation avec le système existant.
- Plans liés aux systèmes qu'ils couvrentChaque entrée est liée à l'actif, à son propriétaire et aux commandes dont il dépend, ce qui permet de visualiser les dérives.
- Objectifs de récupération hérités, non inventés: les objectifs définis par l'analyse commerciale se répercutent sur le plan technologique.
- Calendriers et résultats des tests réunis: planifier les exercices, consigner les échecs et suivre les actions correctives au même endroit que le plan.
- Un seul ensemble de contrôles, chaque framework: contrôles de sauvegarde, d'accès et de fournisseurs cartographiés une seule fois et réutilisés dans les normes ISO 22301, ISO 27031, ISO 27001, ISO 27701 et ISO 42001.
- Dépendances des fournisseurs évaluéesLes tiers dont dépend discrètement votre récupération sont gérés dans le même système.
- S'appuyant sur une expertise approfondie: mise en œuvre guidée par des spécialistes ayant mené des programmes de redressement dans des environnements réglementés.
- Conçu pour le marché britannique et les marchés réglementés.: conçu pour les organisations qui doivent prouver leur capacité de redressement aux auditeurs et aux clients.
Découvrez comment tout cela s'articule sur la plateforme de résilience d'entreprise , ou réservez une démonstration.
FAQ
Quelle est la différence entre un plan de reprise après sinistre et un plan de continuité d'activité ?
Un plan de reprise après sinistre (PRA) permet de rétablir les services technologiques. Un plan de continuité d'activité (PCA) assure la continuité de l'activité malgré les interruptions, par tous les moyens disponibles, y compris en travaillant manuellement pendant les pannes de systèmes. La reprise après sinistre est une composante essentielle de la continuité d'activité et non une alternative. Les objectifs de reprise définis dans le PRA doivent découler de l'analyse métier sur laquelle repose le PCA.
Quelles devraient être les valeurs du RTO et du RPO ?
Ces deux objectifs découlent de l'analyse d'impact sur l'activité plutôt que des capacités actuelles de l'infrastructure. L'objectif de délai de reprise est défini à partir du seuil à partir duquel une interruption d'activité devient inacceptable, avec une marge de sécurité. L'objectif de point de reprise dépend de la quantité de données récentes que l'entreprise pourrait reconstituer ou se permettre de perdre. Fixer l'un ou l'autre de ces objectifs en fonction des capacités techniques actuelles aboutit à des cibles systématiquement atteintes et qui ne prouvent rien.
Quelle est la différence entre la veille active et la veille active ?
La veille à chaud maintient une seconde instance du service en fonctionnement mais inactive. Elle ne sert personne tant qu'un basculement n'est pas effectué. La reprise implique donc une commutation manuelle, qui prend du temps et peut engendrer des erreurs. L'architecture active-active, quant à elle, repose sur deux instances actives gérant simultanément la charge de travail. Ainsi, en cas de défaillance de l'une, l'autre reste opérationnelle et aucune interruption n'est nécessaire. L'architecture active-active supprime l'étape de basculement et s'avère par conséquent plus coûteuse, car elle nécessite l'exploitation et la gestion de deux environnements de production au lieu d'un environnement de secours.
À quelle fréquence un plan de reprise après sinistre doit-il être testé ?
Un test significatif nécessite au moins une fois par an, avec des simulations plus fréquentes et une révision complète à chaque modification importante de l'environnement. La fréquence importe moins que la progression : une organisation qui utilise le même jeu de simulation chaque année sait que ses employés maîtrisent leurs rôles, mais n'a pour autant aucune preuve qu'une restauration fonctionne à grande échelle. Variez le type de test afin d'examiner différentes hypothèses.
L'hébergement dans le cloud élimine-t-il le besoin d'un plan de reprise après sinistre ?
Non. Les plateformes cloud fournissent les éléments de base d'une architecture résiliente, mais les zones de disponibilité et les services gérés sont des options de configuration et non des paramètres par défaut, et des pannes régionales peuvent survenir. Le cloud ne protège pas non plus contre la suppression ou le chiffrement de données, les erreurs de configuration ou la compromission d'un compte. Dans le cloud, la protection évolue : elle se concentre davantage sur la configuration, les sauvegardes immuables et la récupération de compte que sur le matériel, mais elle ne disparaît pas pour autant.
Les ransomwares constituent-ils un scénario de reprise après sinistre ?
C'est bien plus que cela. Un ransomware est un incident de sécurité, souvent une violation de données personnelles et une opération de récupération simultanées, qui remet en cause les hypothèses sur lesquelles reposent les plans de reprise d'activité classiques. Les sauvegardes peuvent être chiffrées ou supprimées ; l'immuabilité et les copies hors ligne sont donc essentielles, et l'environnement peut devoir être reconstruit plutôt que restauré sur place, car une restauration dans un système compromis le réinfecte.
