Reprise d’activité après sinistre : comment élaborer la stratégie et rédiger le PRA
Ce deuxième article de notre série sur la reprise après sinistre à l'ère du cloud s’intéresse à la mise au point des plans de reprise d'activité (PRA) en tenant compte des services cloud.
Les stratégies et les procédures de reprise d'activité après sinistre participent à protéger les systèmes et infrastructures informatiques de l'entreprise, comme expliqué dans le premier volet de cette série d’articles.
Après l'évaluation des risques (Risk Assessment, RA) et l'analyse d'impact sur l'activité (AIA, ou BIA en anglais), nous devons examiner les services informatiques critiques qui sous-tendent les activités critiques de l'entreprise. L’enjeu est de savoir comment définir une stratégie de reprise après sinistre et comment développer des plans de reprise d'activité (PRA) suffisamment détaillés.
Dans cet article, nous étudions l'importance de développer des stratégies de reprise après sinistre, notamment en cas de recours à des fournisseurs de services cloud, et les moyens de les traduire en PRA et en activités de réponse à incident. Nous définirons aussi les éléments d'un plan de reprise d'activité après sinistre et leur contenu. Des stratégies de reprise après sinistre bien définies, qui dépendent de nombreux facteurs, notamment en cas de recours à des fournisseurs cloud, forment le socle des plans de reprise d'activité après sinistre.
Intégrer le RPO et le RTO dans la stratégie de reprise après sinistre
Avant de plonger en détail dans la stratégie et la planification de la reprise d'activité après sinistre, intéressons-nous à deux mesures essentielles : le délai de récupération (en anglais, RTO) et l'objectif de point de récupération (en anglais, RPO).
Selon la norme internationale ISO/IEC 27031:2011 de récupération après sinistre, le RTO ou délai de reprise est « la période au terme de laquelle les niveaux minimums de services et/ou produits, ainsi que les systèmes, applications ou fonctions de soutien, doivent être rétablis suite à une interruption ».
Et le RPO est défini comme le « moment avant un incident qui correspond aux données qu’il faut rétablir après l’incident ». Le RPO est directement lié à la fréquence des sauvegardes. Moins il s’est écoulé de temps entre la dernière sauvegarde et l’incident, plus les données seront à jour. Les deux mesures servent dans l'élaboration des stratégies de reprise après sinistre.
RPO/RTO et le cloud
Notez que le recours à des services cloud ainsi que les politiques de cybersécurité influent sur ces deux indicateurs. On peut par exemple calculer plus facilement le RTO d'un datacenter sur site puisque toutes les opérations se déroulent dans les locaux de l'entreprise. À l'inverse, pour les opérations IT déportées vers des services cloud, le RTO dépend du fournisseur cloud qui peut ou non proposer un délai acceptable. Il en va de même quand les données se trouvent dans un service cloud.
Avec des systèmes de stockage de données sur site, il est aussi plus facile de maîtriser le RPO, alors qu’aucun fournisseur de stockage cloud ou externalisé n'offrira de RPO fiable. Pour ces deux raisons, il est fortement recommandé de négocier un accord de niveau de service (SLA) qui convient des performances que le fournisseur doit assurer.
Stratégie et plans détaillés dans le processus de planification de la reprise après sinistre
La Figure 1 représente les étapes du cycle de vie de la reprise d'activité après sinistre informatique d'après la norme ISO 27031:2011. Elle montre qu'en plus du développement de la stratégie, il faut prendre en compte d'autres activités avant de développer des PRA.
On voit par exemple que la politique de reprise après sinistre est une partie essentielle du processus global de la reprise d'activité. C'est un élément important à examiner lors des audits : son élaboration est cruciale. Éventuellement après l'évaluation des risques et l'analyse d'impact sur l'entreprise, l'analyse des écarts aide à dégager des pistes d'amélioration du processus global de planification de la reprise après sinistre.
L'analyse d'impact sur l'activité, l'évaluation des risques et les analyses des écarts font ressortir des critères de performance à prendre en compte dans les plans de reprise après sinistre. Ces activités servent aussi à repérer les ressources nécessaires pour atteindre les niveaux de performances fixés. Les analyses d'impact et les évaluations des risques doivent intégrer aussi les ressources humaines en temps normal, et pas uniquement en cas de crise.
Définition de la stratégie
Quand les systèmes et fonctions essentiels et les objectifs de délai de reprise (RTO) et de point de récupération (RPO) sont établis et approuvés, l'étape suivante consiste à définir les stratégies de réponses aux événements perturbateurs qui surviennent.
Selon la norme ISO 27031 : « les stratégies définissent les approches à suivre pour mettre en œuvre la résilience nécessaire de manière à mettre en place les principes de prévention des incidents, de détection, de réponse, de récupération et de restauration. »
Les stratégies définissent « quoi » faire dans le cadre d'une réponse à incident, alors que les plans décrivent « comment » mener les activités de réponse et de récupération.
Quand vous aurez repéré tout ce qui est critique — systèmes, données, réseaux, éléments de cybersécurité et fournisseurs de services cloud —, reportez-vous au Tableau 1 pour commencer à formuler des stratégies de protection.
Plusieurs facteurs sont éventuellement à prendre en compte lors de l'élaboration d’un tel tableau :
- budget,
- options de la direction quant aux risques,
- enjeux de cybersécurité,
- disponibilité des ressources (en particulier des services cloud),
- évaluation coûts/bénéfices,
- contraintes humaines,
- contraintes technologiques,
- obligations réglementaires...
Facteurs clés dans l'élaboration d'une stratégie de reprise après sinistre
Il convient d'accorder une grande importance aux aspects suivants pendant l'élaboration des stratégies de reprise d'activité après sinistre, surtout en cas d'utilisation de services cloud.
1/ L'humain. Cette problématique recouvre la disponibilité des talents en interne ou en externe, les besoins en formation des employés et des sous-traitants, la redondance des compétences critiques pour disposer d'un référent principal et d'un secondaire, la documentation à disposition des collaborateurs, et le suivi pour pérenniser l'acquisition des connaissances par les collaborateurs et les sous-traitants.
Le recours aux services cloud allonge la liste des points à prendre en compte, par exemple :
- la sécurité des données et des systèmes,
- les qualifications des personnels du prestataire cloud,
- l'éventualité que des employés malintentionnés du fournisseur cloud endommagent ou volent les ressources des clients,
- l'empressement des représentants du fournisseur cloud à répondre aux questions en toute honnêteté,
- et la capacité des collaborateurs du fournisseur à traiter les besoins du client.
2/ Les installations physiques. Nous nous intéressons ici à la disponibilité d'autres espaces de travail sur le même site, sur un autre site de l'entreprise, dans un lieu tiers, au domicile des collaborateurs, ou encore dans des espaces de travail déplaçables, par exemple une remorque aménagée.
Il faut aussi prendre en compte la sécurité du site, les procédures d'accès des employés, les badges et l'emplacement de l'espace de secours par rapport au site principal. Il n'est pas toujours possible de visiter en personne les installations des fournisseurs cloud. De plus, les systèmes et les données des clients sont parfois stockés dans plusieurs datacenters. Les utilisateurs doivent donc être disposés à céder aux fournisseurs cloud la responsabilité de protéger leurs actifs dans des datacenters sécurisés et respectueux de l'environnement.
3/ Les Considérations technologiques. Cette catégorie regroupe des éléments divers comme :
- l'accès à des installations matérielles prévues pour les systèmes (par exemple plancher surélevé),
- un système de chauffage, de ventilation et de climatisation approprié (HVAC), ,
- une alimentation électrique principale suffisante,
- une infrastructure compatible voix-données,
- la distance depuis le site principal au site technologique de secours,
- la prise en compte des besoins en personnel sur un site technologique de secours,
- la disponibilité des technologies de basculement (vers un système de secours) et de restauration (retour à la normale) en vue de la récupération,
- le besoin de prise en charge de systèmes existants,
- et des capacités de sécurité physique et informatique sur le site de secours.
Chaque élément doit être soumis à un examen méticuleux en cas de recours à un fournisseur de services cloud. Nous recommandons de les inclure dans les accords de niveau de service (SLA).
4/ Les données. Il convient d'inclure :
- la sauvegarde régulière des données critiques dans une zone de stockage sécurisée conformément aux critères RTO/RPO,
- la ou les méthodes de stockage de données (par exemple disque, bande ou support optique),
- les critères de connectivité et de bande passante pour garantir la sauvegarde des données critiques conformément aux délais RTO/RPO,
- les fonctionnalités de protection des données dans le site de stockage de secours,
- et la disponibilité de l'assistance technique apportée par des fournisseurs de services tiers compétents.
Ces questions sont essentielles en cas de recours à un fournisseur de services cloud. Et, en particulier :
- quelles sont les ressources disponibles pour stocker les systèmes et les données des clients et y accéder ?
- Comment leurs périmètres réseau sont-ils protégés contre les cyberattaques ?
- Comment les exigences RTO et RPO du client sont-elles satisfaites ?
- Comment leurs PRA sont-ils testés ?
5/ Les fournisseurs. C'est la partie où il faut identifier des fournisseurs principaux et de secours pour tous les systèmes et les processus critiques, y compris le sourcing de talents, et contractualiser les relations. Trouver des fournisseurs de secours est particulièrement important dans les domaines clés suivants :
- matériel informatique (serveurs, baies),
- alimentation électrique (batteries, onduleurs, protection électrique),
- réseau (services réseau voix et données),
- réparation et remplacement des composants,
- et plusieurs services de livraison (Fedex et UPS).
Si certains de ces risques sont réduits en passant par un fournisseur de services cloud, la prudence recommande de maintenir des sauvegardes des données et des applications critiques et de se constituer un stock de composants système critiques.
6/ Les politiques et les procédures. Parmi les étapes clés de cette section :
- définir les politiques de la reprise d'activité après sinistre IT et les faire approuver par la direction,
- définir des procédures détaillées (par exemple pour lancer la sauvegarde de données vers des sites de secours sécurisés),
- transférer les opérations vers un autre lieu,
- récupérer les systèmes et les données dans les sites de secours,
- et reprendre les opérations dans le site d'origine ou dans un nouveau lieu.
En cas de recours à des services cloud, assurez-vous de prendre en compte les aspects cloud dans toutes les politiques de reprise après sinistre et les documents de procédure afférents.
Enfin, faites bien valider par la hiérarchie les stratégies, les politiques et les procédures planifiées. Préparez-vous à démontrer que les stratégies proposées concordent avec les objectifs commerciaux et les stratégies de continuité de l'activité de l'entreprise.
Traduire les stratégies en PRA
Une fois les stratégies de reprise après sinistre définies, la prochaine étape est de les traduire en plans et procédures. En illustration, le Tableau 2 ci-dessous s'inscrit dans la continuité du Tableau 1. Il montre les systèmes critiques et les menaces associées, la stratégie de réponse et les (nouvelles) étapes de réponse, la stratégie de récupération et les (nouvelles) étapes de récupération. Cette démarche aide à définir les grandes étapes qui intègrent le PRA.
À l'aide du Tableau 2, développez les grandes étapes en procédures détaillées étape par étape, selon vos besoins. Organisez-les selon la séquence appropriée.
Développer le PRA
Les plans de reprise d'activité après sinistre détaillent étape par étape le processus de réponse à un événement perturbateur. Les procédures doivent assurer un processus facile à suivre et reproductible de récupération des actifs informatiques endommagés et de retour à leur opération normale aussi rapide que possible. Le cas échéant, en cas de transfert de personnel vers un site de secours, il faut développer les procédures afférentes. L'utilisation des ressources sauvegardées en cloud passe par des étapes à définir obligatoirement en collaboration avec le fournisseur cloud. Les procédures doivent suivre la bonne séquence.
Reportez-vous aux normes internationales ISO/IEC 24762 (Lignes directrices pour les services de secours en cas de catastrophe dans les technologies de l'information et des communications) et ISO/IEC 27035 (Gestion des incidents de sécurité de l'information) lorsque vous élaborez vos PRA.
Réponse aux incidents
En plus de recourir aux stratégies élaborées, les plans de reprise d'activité après sinistre IT doivent inclure un processus de réponse aux incidents (ISO/IEC 27035) pour les phases initiales de la gestion de l'incident et les étapes à suivre.
Comme dans la Figure 2 ci-dessous, les actions en réponse à incident doivent précéder les actions de reprise d'activité après sinistre. En cas d'utilisation de services cloud, collaborez avec votre fournisseur pour intégrer ses activités de réponse à incident dans votre PRA.
Remarque : la gestion des urgences fait partie de la Figure 2 et représente les activités nécessaires pour répondre à des situations où il y a des blessés, ou à d'autres, comme les incendies qui exigent une prise en charge par les sapeurs-pompiers.
Structure du PRA
Cette étape détaille la structure et les éléments d'un plan de reprise d'activité après sinistre selon les normes ISO 27031 et ISO 24762. Dans les meilleurs PRA, une ou deux pages de garde résument les actions clés, par exemple le point de rassemblement du personnel en cas d'évacuation du bâtiment, et listent les contacts importants, par exemple les fournisseurs cloud et les espaces de travail de secours, les coordonnées pour faciliter l'autorisation et le déclenchement du plan.
1/ Introduction. Après ces premières pages de situation d'urgence vient l'introduction du PRA, qui explicite l'objectif et le périmètre du plan. Cette section précise la ou les personnes qui ont approuvé le plan et celles qui ont autorisé son activation. On y trouve aussi la liste et les liens vers tout autre plan ou document utile, notamment les politiques.
2/ Rôles et responsabilités. La section suivante doit définir les rôles et responsabilités des membres de l'équipe de reprise après sinistre, leurs coordonnées, les plafonds de dépense, par exemple en cas d'achat de matériel, et le cadre de leur autorité en cas de catastrophe. Le recours à des services cloud implique de définir les mêmes paramètres concernant le fournisseur cloud.
3/ Réponse aux incidents. Le processus de réponse aux incidents sert à repérer quand une situation hors de l'ordinaire survient, par exemple grâce à des alarmes système, à évaluer rapidement la situation et les dégâts éventuels pour en déterminer provisoirement la gravité, à contenir l'incident et à le maîtriser autant que possible, et à informer la direction, les fournisseurs de services cloud et les autres partenaires clés.
4/ Activation du plan. L'étape suivante, selon les constatations des activités de réponse à incident, est de déterminer s'il faut lancer les plans de reprise d'activité après sinistre et lesquels en particulier. Ces activités doivent être bien coordonnées avec les fournisseurs de services cloud.
Quand les PRA sont invoqués, les activités de réponse à incident peuvent se réduire voire, selon l'incident, prendre fin pour laisser la place aux plans de reprise d'activité après sinistre. L'utilisation d'un fournisseur cloud peut aussi réduire les activités de réponse à incident puisqu'il doit être impliqué rapidement dans le processus.
Cette section définit les critères de lancement du plan et de coordination avec le fournisseur cloud, les données nécessaires et la personne qui détermine le lancement.
Cette partie du plan doit comprendre les zones principales et secondaires de rassemblement du personnel, les procédures d'alerte et d'activation des membres de l'équipe de reprise d'activité après sinistre et des fournisseurs cloud, et les procédures de sortie du plan si la direction détermine que le PRA n'est pas la réponse appropriée.
5/ Historique du document. Section énumérant les modifications apportées au document du plan et leurs dates. Elle doit comprendre les dates des modifications, les modifications elles-mêmes, et la ou les personnes qui les ont approuvées. Cette section doit précéder le plan.
6/ Procédures. Quand le plan est lancé, les équipes de reprise après sinistre et celles du fournisseur cloud, si celui-ci a bien été informé, effectuent les activités de réponse et de récupération selon les plans. Plus le plan est détaillé, plus la récupération de l'actif informatique affecté et le retour à son fonctionnement normal sont probables.
Il est essentiel que le ou les fournisseurs cloud sachent quoi faire lors de l'incident. Améliorez les PRA à l'aide des procédures et des informations de récupération pertinentes obtenues auprès du ou des fournisseurs cloud. Élaborez vos PRA en étroite collaboration avec les fournisseurs cloud et assurez-vous ainsi que leurs procédures d'urgence sont bien documentées.
7/ Annexes. Placées à la fin du plan, ces annexes comprennent par exemple l'inventaire des systèmes, des applications et des actifs réseau, ainsi que les contrats et accords de niveau de service, les coordonnées des fournisseurs cloud ou autre, et toute documentation supplémentaire utile à la reprise.
Activités suivantes
Une fois vos PRA terminés, ils sont prêts pour une phase d'exercice. Les exercices des plans de reprise d'activité après sinistre sont particulièrement importants en cas de recours à un fournisseur cloud, car celui-ci aura la responsabilité de récupérer des systèmes et des données critiques. Le processus permettra de déterminer si les systèmes et les données sont effectivement récupérés et remis en service comme prévu.
Trois autres activités complémentaires ont lieu en parallèle : la sensibilisation des employés, leur formation et la gestion documentaire. Elles sont essentielles en ce sens qu'elles servent à s'assurer que les membres du personnel sont bien informés des PRA et de leurs responsabilités en cas de sinistre, et que les membres des équipes de reprise après sinistre et les représentants des fournisseurs cloud sont formés aux rôles et responsabilités précisés dans les plans.
La documentation considérable issue de la planification de la reprise après sinistre implique aussi de commencer à gérer les documents et les changements. Cette démarche, d'autant plus importante en cas de recours à un fournisseur de services cloud, assurera que les clients sont bien informés des actions que le fournisseur doit mener.
Obtenez autant de documentation que possible du fournisseur pour rester complémentaire de ses activités. Assurez la coordination avec les activités de gestion documentaire de l'entreprise et de gestion des changements lors de la planification de la reprise après sinistre.