Un PRA, Plan de Reprise d’Activité ou Disaster Recovery Plan (DRP) en anglais, est toujours dépendant de deux indicateurs importants que sont le RTO et le RPO.
Le RPO, Recovery Point Objective, fait référence à la quantité de données pouvant être perdues durant le sinistre. Il est en lien avec le niveau de préjudice accepté et signifie le seuil de données acceptable.
Quant au RTO, Recovery Time Objective, il définit la quantité de temps pendant laquelle le système (donc l’application) peut être hors service sans causer des dégâts.
Ces deux critères sont donc essentiels et décrivent la corrélation entre le but (RPO) et la priorité (RTO) lors de la situation de repli.
Improvisation ?
L’exercice de repli, simulation ou incident réel, doit de ce fait être parfaitement maîtrisé au niveau fonctionnel, métier et technique. Il faut une vraie stratégie.
La réussite d’un PRA est basée sur la bonne réflexion globale. C’est-à-dire, dès la conception de son système d’information. Si nécessaire l’existant doit être revisité pour éviter les réponses inacceptables du genre, je cite « je n’étais pas là ».
Cette réflexion globale doit à la fois être fonctionnelle, business et technique. C’est un équilibre fragile, il faut le reconnaître. Il faut le préserver.
Si la connaissance et la stratégie ne sont pas au rendez-vous, votre PRA sera mort-né !
Le PRA ne s’improvise pas. Tout doit être millimétré afin de respecter les RPO et RTO sans évidemment déroger aux règles de sécurité.
Le PRA idéal
Le PRA idéal est d’avoir une reprise d’activité rapide, voire presque invisible pour le business et les utilisateurs.
Ce n’est pas un fruit miraculeux du hasard si beaucoup de stratèges se basent sur ce principe d’un PRA actif, c’est-à-dire deux sites actifs. Il s’agit d’un LAN étendu, l’un représentant le site de Production tandis que l’autre le PRA. Pour imager, c’est le principe de redondance.
Dans cette situation le RPO et RTO ne peuvent être qu’excellents.
Les tests du PRA restent transparents.
L’autre choix alternatif du PRA
Certains font quelquefois le choix d’un PRA inactif, c’est-à-dire deux sites dont un seul est actif, celui de la Production.
Ils gardent généralement un lien permanent entre la Production et le PRA afin que le site passif (celui du PRA) puisse contenir une copie à jour des données.
Cette situation offre en priorité un bon RPO.
Le RTO dépendra de votre capacité à reconstruire les composants d’infrastructure nécessaires pour faire revivre les données.
Les tests réguliers du PRA peuvent être gênants.
Les autres choix restants
Il n’y aucun intérêt pour moi d’en parler puisque le temps et la technologie ont largement évolué.
Un PRA physique, à l’ère de l’informatique hybride, n’est plus adapté à mon sens, mais tout se fait lorsque vous décidez de vivre dangereusement. L’amour du risque 😊
Au mieux, cette situation vaut vase clos, au titre d’un LAB ou d’une bulle d’homologation. Ce ne sera jamais un PRA de ma fenêtre, ne serait-ce que vis-à-vis des clients applicatifs et bureautiques.
Focus sur Active Directory
Avoir une copie de son Active Directory dans un site passif est une très mauvaise idée.
Ce n’est en aucun cas une bonne façon de mener un PRA, pour Active Directory ou les autres annuaires d’ailleurs.
Un annuaire fonctionne de façon transactionnelle pour rappel et les autres progiciels sont sensibles à la bonne qualité de la consistance de l’annuaire.
Si vous mettez en œuvre un site inactif contenant une copie de votre annuaire en Production, alors il y aura fatalement des risques associés. Ils entraînent des conséquences sérieuses pour la sécurité et la stabilité de l’environnement (non-conformité, complexité de gestion …)
Sachant qu’un contrôleur de domaine Active Directory peut être masqué et la protection de l’annuaire est possible avec la combinaison de quatre méthodes classiques (corbeille, cliché instantané, état système et BMR), aller restaurer son annuaire dans un réseau isolé de la Production relève du non-sens.
Par conséquent, en aucun cas votre annuaire Active Directory ne doit se trouver copié sur un site déconnecté de la Production. C’est de l’inconscience !
Il est recommandé de suivre le PRA Active Directory selon la description de l’éditeur (forest recovery) pour les cas extrêmes.
PRA, PCA et sauvegarde
Les indicateurs RPO et les RTO nécessitent d’être jugés et jaugés.
Ces derniers doivent être régulièrement soumis à des évaluations, car ils peuvent évoluer avec le temps.
Des simulations régulières doivent être menées faisant que la frontière être le PRA et PCA devienne de plus en plus mince pour vous.
La sauvegarde est l’autre élément important du PRA et du PCA. Pour faire simple, deux sites actifs ne couvrent pas le scenario du ransomware. La sauvegarde doit être parfaite quel que soit votre plan de repli imaginé. Il est important de s’en tenir aux bonnes pratiques.
Préparation
La réelle complexité d’un PRA réside dans la capacité de l’entreprise à construire intelligemment un site passif non isolé en tenant compte des indicateurs RTO et RPO.
Pour en tenir compte, il faut préalablement les définir.
Pour les définir, il faut une analyse de son business ainsi que de son parc applicatif.
Passer d’un site actif vers un site passif nécessite la suppression de toutes les adhérences entre les applications et les services d’infrastructure. Une pareille opération se planifie et se prépare.
Cette complexité d’un PRA est rarement technique. Elle est liée essentiellement à la stratégie et aux historiques des applications. Enfin, il y a un peu aussi du manque d’engagement des acteurs techniques, soyons clairs là-dessus (la paresse, le manque de maîtrise technique et cætera).
Autrefois, nous faisions des PRA physiques entre sites déconnectés. En résumé, nous avions un plan écrit et des bandes ou cassettes. L’objectif était d’avoir de la data pour relancer le business. Ce temps est révolu.
De nos jours, avec la qualité des liens réseaux et l’avancée des technologies (vmware, veeam et autres), nous pouvons nous permettre que les sites puissent communiquer entre eux de façon permanente.
Tout est une question de design et de réflexion.
Conclusion
Si le site de repli (PRA) n’est pas synchronisé avec le site actif (Production), alors vous ne pouvez pas avoir un RPO acceptable. La considération des risques peut trancher cet aspect, faut-il encore clairement le formaliser.
Si l’infrastructure est programmable, alors le PRA ne peut être qu’automatisable. Il l’est un peu moins forcément quand le site de repli est déconnecté 😒
Aucune discipline, surtout pas l’Active Directory, ne doit être une contrainte dans un PRA bien réfléchi, de sa construction jusqu’à sa simulation.
L’informatique offre maintenant maintes solutions souples et intelligentes même si des rats considèrent toujours l’informatique comme un centre de coût. On s’en parlera quand l’infrastructure en question sera par terre.
Si vous avez plus de contraintes que de prérequis en forgeant votre plan autour du PRA, alors il y a une anomalie. Cela signifie tout simplement que vous avez un problème de fond et des trous dans la raquette.