Plan de continuité d'activité (informatique)

En informatique, un plan de continuité d'activité (PCA), a pour but de garantir la survie de l'entreprise en cas de sinistre important touchant le système informatique. Il s'agit de redémarrer l'activité le plus rapidement possible avec le minimum de perte de données. Ce plan est un des points essentiels de la politique de sécurité informatique d'une entreprise.

Pour un article plus général, voir Plan de continuité.

Pour les articles homonymes, voir PCA.

Étapes de la mise en place d'un plan de continuité

Pour qu’un plan de continuité soit réellement adapté aux exigences de l’entreprise, il doit reposer sur une analyse de risque et une analyse d’impact :

  • L’analyse de risque débute par une identification des menaces sur l’informatique. Les menaces peuvent être d’origine humaine (attaque délibérée ou maladresse) ou d’origine « naturelle » ; elles peuvent être internes à l’entreprise ou externes. On déduit ensuite le risque qui découle des menaces identifiées ; on mesure l’impact possible de ces risques. Enfin, on décide de mettre en œuvre des mesures d’atténuation des risques en se concentrant sur ceux qui ont un impact significatif. Par exemple, si le risque de panne d’un équipement risque de tout paralyser, on installe un équipement redondant. Les mesures d’atténuation de risque qui sont mises en œuvre diminuent le niveau de risque, mais elles ne l’annulent pas : il subsiste toujours un risque résiduel, qui sera couvert soit par le plan de continuité, soit par d’autres moyens (assurance, voire acceptation du risque)[1]
  • L’analyse d’impact consiste à évaluer quel est l’impact d’un risque qui se matérialise et à déterminer à partir de quand cet impact est intolérable, généralement parce qu’il met en danger les processus essentiels (donc, la survie) de l’entreprise. L’analyse d’impact se fait sur base de désastres : on considère des désastres extrêmes, voire improbables (par exemple, la destruction totale du bâtiment) et on détermine les impacts financiers, humains, légaux, etc., pour des durées d’interruption de plus en plus longues jusqu’à ce qu’on atteigne l’impact maximal tolérable. Le résultat principal de l’analyse d’impact est donc une donnée temporelle : c’est la durée maximale admissible d’une interruption de chaque processus de l’entreprise. En tenant compte des ressources informatiques (réseaux, serveurs, PCs…) dont chaque processus dépend, on peut en déduire le temps maximal d’indisponibilité de chacune de ces ressources, en d’autres termes, le temps maximal après lequel une ressource informatique doit avoir été remise en fonction[1]

Une analyse de risque réussie est le résultat d'une action collective impliquant tous les acteurs du système d'information : techniciens, utilisateurs et managers.

Choix de la stratégie de sécurisation

Il existe plusieurs méthodes pour assurer la continuité de service d'un système d'information. Certaines sont techniques (choix des outils, méthodes de protection d'accès et de sauvegarde des données), d'autres reposent sur le comportement individuel des utilisateurs (extinction des postes informatiques après usage, utilisation raisonnable des capacités de transfert d'informations, respect des mesures de sécurité), sur des règles et connaissances collectives (protection incendie, sécurité d'accès aux locaux, connaissance de l'organisation informatique interne de l'entreprise) et de plus en plus sur des conventions passées avec des prestataires (copie des programmes, mise à disposition de matériel de secours, assistance au dépannage).

Les méthodes se distinguent entre préventives (éviter la discontinuité) et curatives (rétablir la continuité après un sinistre). Les méthodes préventives sont souvent privilégiées, mais décrire les méthodes curatives est une nécessité car aucun système n'est fiable à 100 %.

Mesures préventives

Dans le cadre de l'hébergement de leurs infrastructures et/ou applications, plus de 50 % des organisations interrogées en 2008 par MARKESS International[2] évoquent avoir besoin des solutions suivantes afin d’assurer la continuité de service de leurs applications métiers et infrastructures informatiques et télécoms sous -jacentes :

  • Sauvegarde et restauration de données (pour plus des 2/3 des organisations) ;
  • Planning des actions à mener en cas de crise (64 %) ;
  • Conservation et archivage de données (57 %) ;

Viennent ensuite, par ordre décroissant de citations, les solutions de réplication, mirroring et secours multi-sites ou sur un autre site distant (49 %), de basculement sur un réseau de secours (47 %), d’analyse de procédures et stratégies assurant la continuité de business (47 %), de gestion de bande passante (45 %), de sécurité physique et logique (42 %)…

La sauvegarde des données

La préservation des données passe par des copies de sauvegarde régulières. Il est important de ne pas stocker ces copies de sauvegarde à côté du matériel informatique, voire dans la même pièce car elles disparaitraient en même temps que les données à sauvegarder en cas d'incendie, de dégât des eaux, de vol, etc. Lorsqu'il est probable que les sauvegardes disparaissent avec le matériel, le stockage des copies de sauvegarde peut alors être nécessaire dans un autre lieu différent et distant.

L’analyse d’impact a fourni des exigences exprimées en temps maximal de rétablissement des ressources après un désastre (RTO: Recovery Time Objective ou Durée maximale d'interruption admissible) et la perte maximale de données (RPO Recovery Point Objective ou Perte de données maximale admissible). La stratégie doit garantir que ces exigences seront observées.

Les systèmes de secours

Il s'agit de disposer d'un système informatique équivalent à celui pour lequel on veut limiter l'indisponibilité : ordinateurs, périphériques, systèmes d'exploitation, programmes particuliers, etc. Une des solutions consiste à créer et maintenir un site de secours, contenant un système en ordre de marche capable de prendre le relais du système défaillant. Selon que le système de secours sera implanté sur le site d'exploitation ou sur un lieu géographiquement différent, on parlera d'un secours in situ ou d'un secours déporté.

Pour répondre aux problématiques de recouvrement de désastre, on utilise de plus en plus fréquemment des sites délocalisés, c'est-à-dire physiquement séparés des utilisateurs, de quelques centaines de mètres à plusieurs centaines de kilomètres : plus le site est éloigné, moins il risque d'être touché par un désastre affectant le site de production. Mais la solution est d'autant plus chère, car la bande passante qui permet de transférer des données d'un site vers l'autre est alors généralement plus coûteuse et risque d'être moins performante. Cependant la généralisation des réseaux longues distances et la baisse des coûts de transmission rendent moins contraignante la notion de distance : le coût du site ou la compétence des opérateurs (leur capacité à démarrer le secours rapidement et rendre l'accès aux utilisateurs) sont d'autres arguments de choix.

Les sites de secours (in situ ou déportés) se classent selon les types suivants :

  • salle blanche (une salle machine protégée par des procédures d'accès particulières, généralement secourue électriquement). Par extension, on parle de salle noire pour une salle blanche entièrement pilotée à distance, sans aucun opérateur à l'intérieur.
  • site chaud  : site de secours où l'ensemble des serveurs et autres systèmes sont allumés, à jour, interconnectés, paramétrés, alimentés à partir des données sauvegardées et prêt à fonctionner. Le site doit aussi fournir l'ensemble des infrastructures pour accueillir l'ensemble du personnel à tout moment et permet une reprise d'activité dans des délais relativement courts (quelques heures). Un tel site revient quasiment à doubler les capacités informatiques de l'entreprise (on parle de redondance) et présente donc un poids budgétaire non négligeable.
  • site froid  : site de secours qui peut avoir une autre utilisation en temps normal (ex : gymnase). Les serveurs et autres systèmes sont stockés mais non installés, connectés, etc. Lors d'un sinistre, un important travail doit être effectué pour mettre en service le site ce qui conduit à des temps de reprise long (quelques jours). Mais son coût de fonctionnement, hors période d'activation, est faible voire nul.
  • site tiède : site de secours intermédiaire. En général on trouve des machines installées (mise à jour décalée par rapport au site de production) avec les données sur bande mais non importées dans les systèmes de données.

Il est aussi possible d'utiliser des systèmes distribués sur plusieurs sites (diminution du risque de panne par effet de foisonnement) ou un site de secours mobile qui correspond à un camion transportant des serveurs et autres systèmes, permettant de n'avoir besoin que d'un système de secours pour plusieurs sites, en tablant sur l'improbabilité qu'une panne touche simultanément plusieurs sites.

Plus les temps de rétablissement garantis sont courts, plus la stratégie est coûteuse. Il faut donc choisir la stratégie qui offre le meilleur équilibre entre le coût et la rapidité de reprise.

D'autre part pour des problématiques de haute disponibilité on a recours aussi à de la redondance mais de manière plus locale.

  • Doublement d'alimentation des baies des serveurs
  • Redondance des disques en utilisant la technologie RAID
  • Redondance de serveurs avec des systèmes de load balancing (répartition des requêtes) ou de heartbeat (un serveur demande régulièrement sur le réseau si son homologue est en fonctionnement et lorsque l'autre serveur ne répond pas, le serveur de secours prend le relais).

Il est aussi possible de recourir à un site secondaire de haute disponibilité qui se situe généralement près du site de production (moins de 10 kilomètres) afin de permettre de les relier avec de la fibre optique et synchroniser les données des deux sites en quasi temps réel de manière synchrone ou asynchrone selon les technologies utilisées, les besoins et contraintes techniques.

Une bonne information et un bon partage des rôles

Quel que soit le degré d'automatisation et de sécurisation d'un système informatique, la composante humaine reste un facteur important. Pour limiter le risque de panne, les acteurs d'un SI (service informatique) doivent adopter les comportements les moins risqués pour le système et éventuellement savoir accomplir des gestes techniques.

  • Pour les utilisateurs, il s'agit
    • de respecter les normes d'utilisation de leurs ordinateurs : n'utiliser que les applications référencées par les mainteneurs du SI, ne pas surcharger les réseaux par des communications inutiles (téléchargements massifs, échanges de données inutiles, rester connecté sans nécessité), respecter la confidentialité des codes d'accès ;
    • de savoir reconnaître les symptômes de panne (distinguer un blocage d'accès d'un délai de réponse anormalement long, par exemple) et savoir en rendre compte le plus vite possible.
  • Pour les opérateurs du SI, il s'agit d'avoir la meilleure connaissance du système en termes d'architecture (cartographie du SI) et de fonctionnement (en temps réel si possible), de faire régulièrement les sauvegardes et de s'assurer qu'elles sont utilisables.
  • Pour les responsables, il s'agit de faire les choix entre réalisations internes et prestations externes de manière à couvrir en totalité le champ des actions à conduire en cas de panne (par exemple, rien ne sert d'avoir des machines de secours si on ne prévoit pas la mise à jour de leur système d'exploitation), de passer les contrats avec les prestataires, d'organiser les relations entre les opérateurs du SI et les utilisateurs, de décider et mettre en œuvre les exercices de secours, y compris le retour d'expérience.

Mesures curatives

Selon la gravité du sinistre et la criticité du système en panne, les mesures de rétablissement seront différentes.

La reprise des données

Dans cette hypothèse, seules des données ont été perdues. L'utilisation des sauvegardes est nécessaire et la méthode, pour simplifier, consiste à réimplanter le dernier jeu de sauvegardes. Cela peut se faire dans un laps de temps court (quelques heures), si l'on a bien identifié les données à reprendre et si les méthodes et outils de réimplantation sont accessibles et connus.

Le redémarrage des applications

À un seuil de panne, plus important, une ou des applications sont indisponibles. L'utilisation d'un site de secours est envisageable, le temps de rendre disponible l'application en cause.

Le redémarrage des machines
  • provisoire : utilisation des sites de secours
  • définitif : après dépannage de la machine d'exploitation habituelle, y rebasculer les utilisateurs, en s'assurant de ne pas perdre de données et si possible de ne pas déconnecter les utilisateurs.

Développement du plan

Le plan de reprise contient les informations suivantes :

  • La composition et le rôle des « équipes de pilotage du plan de reprise ». Ces équipes se situent au niveau stratégique :
  1. les dirigeants qui ont autorité pour engager des dépenses ;
  2. le porte-parole responsable des contacts avec les tiers : la presse, les clients et les fournisseurs, etc. ;
  3. au niveau tactique, les responsables qui coordonnent les actions ;
  4. au niveau opérationnel, les équipes de terrain qui travaillent sur le site sinistré et sur le site de remplacement.

La composition de ces équipes doit être connue et à jour, ainsi que les personnes de remplacement et les moyens de les prévenir. Les membres des équipes doivent recevoir une formation.

  • Les procédures qui mettent la stratégie en œuvre. Ceci inclut les procédures d’intervention immédiate (qui prévenir ? qui peut démarrer le plan et sur quels critères ? où les équipes doivent-elles se réunir ? etc.) ;
  • Les procédures pour rétablir les services essentiels, y compris le rôle des prestataires externes ;
  • Les procédures doivent être accessibles aux membres des équipes de pilotage, même en cas d’indisponibilité des bâtiments.

Exercices et maintenance

Le plan doit être régulièrement essayé au cours d’exercices. Un exercice peut être une simple revue des procédures, éventuellement un jeu de rôles entre les équipes de pilotage. Un exercice peut aussi être mené en grandeur réelle, mais peut se limiter à la reprise d’une ressource (par exemple, le serveur principal), ou à une seule fonction du plan (par exemple, la procédure d’intervention immédiate). Le but de l’exercice est multiple :

  • Vérifier que les procédures permettent d'assurer la continuité d'activité
  • Vérifier que le plan est complet et réalisable
  • Maintenir un niveau de compétence suffisant parmi les équipes de pilotage
  • Évaluer la résistance au stress des équipes de pilotage

Un plan doit aussi être revu et mis à jour régulièrement (au moins une fois par an) pour tenir compte de l’évolution de la technologie et des objectifs de l’entreprise. La seule façon efficace de mettre à jour le PCA est d'en sous traiter la maintenance aux métiers afin qu'il soit réactualisé à chaque réunion mensuelle de service.

Plan de continuité d'activité ou plan de secours informatique ?

Le plan de continuité d'activité décrit dans cet article n'est en réalité que le volet informatique d'un plan de continuité d'activité complet d'entreprise. Il s'apparente donc à un plan de secours informatique. Un plan de continuité d'activité (ou "Business Continuity Plan") ne se limite pas à la continuité du système d'information, il prend également en compte le repli des utilisateurs, le risque sanitaire (épidémie, pandémie), l'organisation permettant la gestion de crise (astreintes, cellules de crise...), la communication de crise, des mesures de contournement pour les métiers, les fonctions transverses (RH, logistique, etc.).

Si l'on prend l'exemple d'une banque dont l'informatique est hébergée sur un site distant et qui voit sa salle des marchés détruite par un incendie, celle-ci déclenchera son plan de continuité d'activité en repliant ses équipes sur un site de secours. Ce site de secours est constitué de positions de travail (le terme "position" représente un bureau, un ou deux écrans, une unité centrale, un téléphone), sur lesquels les utilisateurs pourront poursuivre leur activité : leur numéro de téléphone est transféré sur leur position de secours, l'image de leur poste informatique aura été reconstruite, ils disposeront des lignes de communication nécessaires (réseau interne et externe), le site de secours utilisateur est lui-même relié au site d'hébergement informatique (ou au site de secours si celui-ci est également touché par le sinistre). Pour que le redémarrage informatique soit exploitable par les utilisateurs du système, les aspects techniques doivent être croisés avec l'organisation humaine.

Références
  1. « Professional Practices | DRI », sur drii.org (consulté le )
  2. Référentiel de pratiques : Hébergement à Valeur Ajoutée - Réponse aux Défis de la Continuité de Business 2008

Voir aussi

Articles connexes

Bibliographie
  • Catastrophe et management - Plans d'urgence et continuité des systèmes d'information, de Daniel Guinier, Ed. Masson, 1995.
  • Plan de Continuité d'Activité et Système d'Information : vers l'entreprise résiliente, Matthieu Bennasar, Dunod, 2006 et 2e édition 2010 (prix AFISI 2006, meilleur ouvrage de management des SI).
  • Dispositif de gestion de continuité - PRA/PCA : une obligation légale pour certains et un impératif pour tous, Daniel Guinier, Revue Expertises, n°308, , pp.390-396.
  • Les pratiques professionnelles pour la gestion de la continuité d’activités, Disaster Recovery Institute International, 2017

Liens externes
  • Portail de la sécurité informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.