Si les acronymes PRA (Plan de Reprise d’Activité) et PCA (Plan de Continuité d’Activité) sont désormais bien connus, leur périmètre respectif l’est moins.
Le PRA se concentre lui, sur le Système d’Information. Le PCA quant à lui, voit son périmètre étendu à l’ensemble des activités essentielles de l’entreprise, comprenant le Système d’Information évidemment.
Chez ILKI, afin d’éviter toute confusion, lorsque nous traitons que de l’informatique nous préférons utiliser les acronymes suivants : PSI (Plan de Secours Informatique) qui peut se décliner soit en PRI (Plan de Reprise Informatique) soit en PCI (Plan de Continuité Informatique).
Il est également important de bien comprendre que la mise en place d’un PSI intervient dans un contexte de sinistre, il est donc indispensable :
Et bien tout dépend de votre contexte !
Pour autant, certains sinistres types sont à prendre en compte : perte physique d’une salle informatique, perte de liaison réseau, perte de services essentiels (métiers, infrastructure…), atteinte à la maintenabilité du système d’information (cyberattaque).
Une chose est sûre : on ne peut pas se protéger contre 100% des risques. Les causes pouvant être multiples, il est essentiel d’associer à chaque risque une probabilité de survenance et un impact en cas de survenance. La combinaison de ces deux paramètres permet de définir un niveau de risque et donc cibler les risques les plus importants à prendre en compte.
RPO/RTO, le point clé de la construction d’une architecture de PSI
Et oui, encore et toujours des acronymes :
Ce couple RPO/RTO est à définir par application ou groupe d’applications.
Une nouvelle fois, les besoins sont au centre de la réflexion. Ces derniers sont à définir en lien avec les métiers, qui sont eux, les mieux placés pour établir ce qui est acceptable en cas de sinistre.
Cependant, la définition des besoins et les spécificités métiers doit être accompagnée. En effet, la compréhension des tenants et des aboutissants des choix évite une réponse par défaut autrement dit le plus souvent un couple 0/0 pour zéro perte de données et zéro interruption si cela n’est pas le plus pertinent.
C’est uniquement à partir de cette définition de RPO/RTO qu’il sera alors possible de définir l’architecture cible et les mécanismes à utiliser pour répondre aux besoins exprimés.
La construction d’une infrastructure hautement disponible (et ce à tous les niveaux) va évidemment permettre de limiter les sinistres, notamment en diminuant, voire en supprimant, l’impact en cas de survenance de pannes sur :
Pour éliminer la présence de SPOF (Single Point Of Failure), une méthode simple : la redondance à tous les niveaux ! On double tout, jusqu’aux chemins physiques des fibres pour éviter le fameux « coup de pelleteuse ».
Même si la réplication asynchrone et synchrone permettent de diminuer les RPO/RTO, pour atteindre un niveau optimal, rien de telle qu’une application pensée pour être hautement disponible au niveau applicatif.
D’ailleurs, les applications dites Cloud Native, sont développées sur le principe du « design for failure » : l’infrastructure, ça tombe en panne !
Pas la peine de rappeler que les cyberattaques sont de plus en plus présentes et évoluées. De ce fait, depuis quelques années, les cyberattaques entrainent des arrêts de services complets des SI au travers le chiffrement de toutes les données par exemple (ransomware/cryptolocker). Le problème avec les cyberattaques est que la probabilité de survenance est de plus en plus forte mais l’impact reste difficile à anticiper.
Dans ce contexte, les sauvegardes sont souvent le dernier rempart, et sont donc à protéger sérieusement pour éviter qu’elles ne soient exploitées ou corrompues.
Heureusement, il existe des moyens de ralentir la progression des attaquants, d’empêcher l’accès aux données de sauvegarde voire, de sécuriser ces données via des mécanismes d’immuabilité et/ou d’air gap. Mais ce sujet mériterait un article complet !
On associe généralement la construction d’un PSI uniquement avec les briques techniques associées, mais il ne faut surtout pas oublier les aspects organisationnels et fonctionnels :
La constitution d’une cellule de crise, incluant des décisionnaires et les équipes techniques, est donc une étape cruciale. Elle est en charge des prises de décisions autour du PRA (déclenchement, pilotage, communications…) mais également du bon maintien à jour des processus et procédures.
Enfin, ne pas oublier :
Vous l’aurez compris, la construction d’un PRA ne s’improvise pas et mobilise de nombreux acteurs et ressources mais est indispensable à votre activité. N’oubliez pas aussi que votre PRA doit évoluer en même temps que votre SI.
