[Blog] – Six erreurs qui rendent un PRA inutile

On peut avoir le sentiment du travail bien fait une fois que l’on s’est attelé à son plan de reprise d’activité. Pourtant, en amont comme en aval, il peut persister un certain nombre d’erreurs ou de manquements qui affaiblissent sa portée. Cet article vous guide dans l’écheveau des suites à donner à l’édification d’un PRA pour le garder solide et l’améliorer au fil du temps.

 

Avant-propos

Peut-être avez-vous déjà parcouru quelques-uns de nos cahiers thématiques. Parmi eux, notre cahier Cyber résilience fait une différence notable entre PRA et cyber PRA, à la fois en matière d’organisation, d’outils, de données considérées et bien évidemment d’objectifs. Sur ce dernier point, on se bornera à rappeler qu’un plan de reprise d’activité a d’abord vocation à garantir une reprise rapide suite à un incident matériel majeur (avarie de type inondation, incendie, etc.) et qu’un cyber PRA permet à l’entreprise de redémarrer le cœur vital du système d’information dans un environnement de confiance après le succès d’une cyberattaque.

Pour autant, les erreurs que nous listons ci-dessous s’appliquent à chaque type de PRA. C’est pourquoi cet article implique les deux systèmes, sans distinction, dans ses propos.

 

Tenir son PRA pour acquis

Un PRA est un outil vivant, un plan de bataille en évolution continue. S’il dispose d’une documentation opérationnelle lors de son introduction, celle-ci devient rapidement inapplicable sans suivi. « Un système d’informations est dynamique. Quatre, cinq ou six mois après l’établissement d’un PRA, la documentation associée n’est généralement déjà plus valable » rappelle Benjamin DURAND, Responsable des offres et alliances chez Stordata.

La mise à jour repose sur deux aspects conjugués : une revue régulière mais aussi et surtout, une désignation non nominative des administrateurs en charge de la mise en œuvre. « Si le jour où il faut exécuter le PRA la personne responsable est en congé, votre solution de reprise devient stérile ».

Ne nous le cachons pas, rédiger de la documentation est un travail un peu rébarbatif. C’est pourtant ce que les auditeurs « risques et conformité » contrôlent en premier. Le delta à combler est certes important lors des premières rédactions mais l’effort devient négligeable avec des tests réguliers. Si l’on en fait.

 

Repousser les tests aux calendes grecques

Tester son PRA semble relever d’une difficulté majeure en entreprise, si l’on en juge par les témoignages clients. La pratique est pourtant cruciale pour éliminer les derniers aspects qui auraient pu échapper à la vigilance des équipes. Les échecs rencontrés sont également une source d’information inégalée qui permettront de compléter la documentation : la connaissance tacite et non formulée des procédures ou le shadow IT n’apparaissent qu’à cette étape de test.

« Les équipes exagèrent la difficulté de l’exercice. La bonne méthode consiste à tester le plan de manière unitaire, serveur après serveur, puis au niveau des chaînes applicatives, puis enfin au global. Chaque responsable teste individuellement ses applications en PRA et de façon régulière. »

À terme, les organisations y excellent. Certaines vont jusqu’à mettre en place des modes dégradés en se privant de l’intervention d’un certain nombre de personnes identifiées comme détenant la compétence ou le savoir clé. D’autres choisiront de définir si le test sera traité avec ou sans moyens de communication (mails et chat, plateforme collaborative, réseaux de téléphonie, etc.). « J’ai déjà réalisé des exercices allant jusqu’à vérifier que le stock de post-it et de tableaux blancs est suffisant pour que l’information soit correctement diffusée », se rappelle Benjamin DURAND.

 

Se fier au taux de réussite des backups

Sauvegarder n’est pas restaurer. Pourtant, le taux de réussite des sauvegardes est l’indicateur le plus observé dans les organisations. Or, un pourcentage de réussite même élevé ne garantit ni que les sauvegardes sont cohérentes (quid des transactions en cours au moment de la sauvegarde ?), ni que les applications tier 0 (les plus critiques) ont toutes, étaient prises en compte.

Le travail de sauvegarde, somme toute complexe, commence bien plus tôt et s’appuie sur deux notions : une réflexion commune entre l’équipe backup et les responsables applicatifs et un inventaire applicatif auquel s’ajoute une qualification de criticité des assets sauvegardés. « Un taux de réussite ou d’échec d’une sauvegarde ne renseigne pas sur les omissions. Seul un inventaire mis à jour régulièrement le permet. Il est facile d’oublier une application introduite récemment ».

 

Hasarder les sauvegardes et ne pas systématiser les scans

On rencontre en entreprise d’admirables cordonniers assez mal chaussés, réalisant d’excellentes sauvegardes, des restaurations opérationnelles, des tests de PRA parfaitement exécutés mais qui se heurteront in fine à la corruption des données. C’est d’autant plus vrai dans un contexte de cyber PRA dans lequel les assaillants vont privilégier la plateforme de sauvegarde afin de faire tomber le dernier rempart.

On veillera alors à positionner une copie des sauvegardes dans une zone de stockage immuable et isolé des réseaux accessibles au public (air-gap) afin d’en limiter, de façon forte, le risque de corruption. Mais ces sauvegardes « air-gapées » sont-elles saines ? C’est une question à laquelle il est devenu très difficile de répondre dans toutes les situations d’attaques informatiques. Le cyber PRA en fait l’objet même de son existence.

Le scan systématique des backups est une bonne pratique dont aucune organisation ne devrait se passer, ne serait-ce que pour rétablir les services le plus vite possible. Les outils de scan récents et doublés de machine learning épargnent aux équipes beaucoup de temps et de ressources en priorisant certains types de fichiers couramment ciblés ou en progressant uniquement en fonction des signaux détectés.

 

S’en tenir aux anciennes méthodes de sécurité

La résilience de la plateforme de backup est au moins aussi importante que la protection des jeux de sauvegarde. On lui appliquera avec rigueur les meilleures pratiques disponibles, à savoir la double authentification, les principes de role-based access (RBAC) pour distinguer les administrateurs autorisés à réaliser les actions les plus critiques des opérateurs appliquant aux backups les actions quotidiennes, ainsi que des mécanismes de quorum visant à obtenir l’approbation d’un tiers pour certaines opérations.

Reste que les plateformes modernes de sauvegarde offrent dorénavant toutes les mécanismes essentiels pour faire face aux nouvelles tentatives d’attaque, mécanismes que nous détaillons dans nombre de nos cahiers thématiques. Nous nous appliquerons ici à citer un exemple qui témoigne du raffinement apporté à la résistance aux attaques de ces plateformes : les horloges monotoniques, qui sont d’ailleurs moins des horloges que des chronomètres, affichent un intervalle de temps écoulé depuis un instant de référence. Ce type de décompte vise à empêcher le système, trompé par la corruption des dates de backups, de supprimer de manière automatique les sauvegardes. Plus robuste, le système ne dit plus quand il faut supprimer mais combien de temps il faut conserver.

 

Penser qu’un PRA n’est qu’une question IT

Il y a une dimension humaine très forte à prendre en compte dans l’établissement d’un PRA et à laquelle on songe assez peu. Sorte de rupture dans les habitudes et le fonctionnement classique d’une entreprise, les circonstances conduisant à déclencher un PRA peuvent induire de nouveaux comportements. « J’ai le souvenir d’une situation surprenante qui a requis la présence d’un vigile pour limiter le flot ininterrompu de sollicitations du service IT qui ne pouvait plus travailler sereinement au rétablissement des services », mentionne Benjamin DURAND. De tels exemples montrent combien la capacité d’une organisation à communiquer avec son personnel en mode dégradé est déterminante.

Mais la reprise d’activité peut également prendre des formes très simples qui ne viennent pas forcément à l’esprit. Comment pallier rapidement une panne du logiciel des caisses enregistreuses, si ce n’est avec des calculatrices et des blocs-notes ? Mais à quand remonte la dernière fois que l’on a vérifié la présence de calculatrices dans les tiroirs et des piles en suffisance ?

 

On le voit, on ne fait jamais complètement le tour d’un plan de reprise d’activité et encore moins en quelques mois. C’est un processus en continu que l’on doit veiller à adapter au fur et à mesure des évolutions des technologies, des usages et dans une certaine mesure, du contexte extrinsèque de l’entreprise, mais ces quelques conseils appliqués avec vigilance sauront contribuer à la résilience de toute l’organisation.

 

Partagez cette actualité

Plus d'actualités Stordata

Services

[Blog] – Six erreurs qui rendent un PRA inutile

On peut avoir le sentiment du travail bien fait une fois que l’on s’est attelé à son plan de reprise d’activité. Pourtant, en amont comme en aval, il peut persister un certain nombre d’erreurs ou de manquements qui affaiblissent sa portée. Cet article vous guide dans l’écheveau des suites à donner à l’édification d’un PRA pour le garder solide et l’améliorer au fil du temps.

Services

[Blog] – Le cloud de proximité : un actif stratégique pour le secteur public

Soyons clairs, un cloud de proximité n’a pas vocation à remplacer les services d’un grand cloud provider. S’il s’agit d’exécuter de grands modèles de langage ou de disposer d’une scalabilité massive, il faudra certainement se tourner vers le cloud public, sauf à disposer des ressources des grands centres de recherche scientifique.