Organigramme du processus de reprise après sinistre (systèmes informatiques)
Un organigramme du processus de reprise après sinistre informatique : critères d'appel, priorisation des RTO et RPO, basculement, restauration des données, validation et restauration automatique.
Qu'est-ce que le processus organigramme du processus de reprise après sinistre (systèmes informatiques) ?
La reprise après sinistre est la partie technique du travail de continuité : restaurer les systèmes informatiques et les données après un événement que la gestion ordinaire des incidents ne peut pas résoudre, comme une perte de site, une panne de stockage ou une panne à grande échelle chez un fournisseur d'hébergement. Il ne s’agit pas de continuité des activités. Un plan de continuité couvre la manière dont l'organisation continue ses activités pendant que les systèmes sont en panne (solutions manuelles, locaux alternatifs, personnel, fournisseurs, engagements clients) ; ce processus couvre les serveurs, les données et l'ordre dans lequel ils reviennent. Les deux se rejoignent à un moment donné : les priorités de récupération utilisées ici doivent provenir de l'analyse d'impact sur l'activité dans le plan de continuité, et non du jugement d'un ingénieur pendant la panne.
Il ne s’agit pas non plus du processus de gestion des incidents ni de la réponse aux incidents de sécurité. Un seul service défaillant dans le cadre d’opérations normales reste avec le centre de services et n’atteint jamais l’invocation. Si la perturbation est provoquée par une attaque, le processus de réponse aux incidents de sécurité se déroule parallèlement à celui-ci et décide quand la restauration est sûre, car la reconstruction avant que la portée ne soit comprise peut réintégrer l'attaquant ou détruire les preuves. D’un autre côté, le rétablissement est un changement planifié et appartient au contrôle des modifications et non au flux d’urgence.
La plupart des plans de reprise après sinistre échouent sur les mêmes points : aucun critère convenu pour l'invocation, donc des heures passent pendant que les gens débattent pour savoir si cela compte ; récupération dans un ordre arbitraire, de sorte que les applications apparaissent avant les services d'identité et de base de données dont elles dépendent ; une restauration qui est transmise aux utilisateurs avant que quiconque ne la vérifie ; et une déclaration indiquant que le service est de retour et qu'aucun propriétaire d'application n'a réellement vérifié. Ce modèle présente le flux sur cinq voies et cinq phases, avec une décision d'appel, un contrôle d'intégrité avec une boucle de re-restauration et une porte de validation appartenant aux propriétaires de l'application plutôt qu'à l'équipe d'infrastructure qui a effectué le travail.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs avec un propriétaire pour chaque étape (détection/opérations, coordinateur DR, gestion, équipe d'infrastructure, propriétaires d'applications) sur cinq phases : détection et évaluation, appel, récupération, validation, restauration automatique et examen.
- Détection et évaluation, où « Événement perturbateur détecté » alimente « Évaluer l'impact et les systèmes affectés » et « Transmettre au coordinateur DR » avant que quoi que ce soit ne soit déclaré.
- Un message « Critères d'appel DR satisfaits ? » décision dans la voie du coordinateur DR : la branche non rencontrée se termine à 'Traité comme un incident standard', la branche rencontré passe à 'Autoriser l'invocation DR' dans la voie Gestion, en conservant la déclaration avec le rôle autorisé.
- Mobilisation et priorisation : 'Mobiliser l'équipe DR' puis 'Prioriser les systèmes par RTO et RPO', avec une note expliquant ce que signifie chaque cible et pourquoi les dépendances partagées (identité, réseau, bases de données) sont récupérées avant les applications qui en ont besoin.
- Récupération dans le couloir Infrastructure : « Basculer vers le site de récupération », « Restaurer les données à partir d'une sauvegarde » et « Intégrité des données vérifiée ? » décision dont la branche défaillante exécute « Restaurer à partir d’une copie antérieure » et revient à l’étape de restauration.
- Validation et clôture : « Exécuter les contrôles de validation de l'application » et un « Les services fonctionnent comme prévu ? » porte qui renvoie les défauts à l'équipe d'infrastructure, suivi de « Communication des services restaurés aux utilisateurs », de la planification du rétablissement, de la mise hors service, de l'examen post-événement et d'un plan et d'un calendrier de tests mis à jour.
Quand utiliser ce modèle
- Documenter un plan de reprise après sinistre ou la section de récupération des TIC d'un plan de continuité, de sorte que la séquence et le propriétaire de chaque étape tiennent sur une seule page.
- Se mettre d'accord sur les critères d'invocation et sur qui détient le pouvoir de déclarer un sinistre, avant qu'une panne ne force la question à 3 heures du matin.
- Préparation d'un test DR ou d'un exercice théorique : les décisions, les boucles et les transferts vous donnent un script pour tester le plan.
- Briefer les ingénieurs de garde qui pourraient devoir exécuter une partie de la reprise sans les personnes qui ont rédigé le plan.
- Montrer à un auditeur ou à un client que la récupération des TIC est documentée et répétée (un diagramme illustre le processus ; il ne démontre pas en soi la conformité à une quelconque norme).
Comment cela fonctionne
Renommez les voies selon les rôles que vous avez réellement
Remplacez Détection/Opérations, coordinateur DR, gestion, équipe d'infrastructure et propriétaires d'applications par vos rôles réels : NOC ou surveillance, responsable de la continuité des services informatiques, responsable de la rotation de crise, équipes de plateforme et de base de données, propriétaires de services nommés. Les petites organisations fusionnent souvent les voies du coordinateur et de l'infrastructure ; si une voie ne contient personne, supprimez-la plutôt que de la laisser sans personnel.
Écrivez vos critères d'invocation sur la décision
Assurez-vous que les « Critères d'appel DR sont satisfaits ? » suffisamment objectif pour que quelqu'un postule sous pression : site principal inaccessible, panne prévue plus longue que le RTO d'un système de premier niveau, stockage principal ou base de données irrécupérable en place. Nommez le rôle autorisé à invoquer et un adjoint, et enregistrez comment ils sont contactés en dehors des heures de travail.
Attachez de vrais chiffres RTO et RPO à chaque système
Prenez les objectifs de l'analyse d'impact sur l'entreprise, et non de ce que l'infrastructure réalise actuellement, et répertoriez-les par niveaux en fonction de « Prioriser les systèmes par RTO et RPO ». Enregistrez l'ordre des dépendances ainsi que l'ordre de priorité, car une application de premier niveau ne peut pas être validée avant que les services d'identité, de réseau et de base de données en dessous ne soient opérationnels.
Décrivez votre mécanisme de récupération actuel
« Basculer vers le site de récupération » signifie quelque chose de différent pour l'infrastructure répliquée, une réserve chaude, une deuxième région cloud et une reconstruction à partir d'un support de sauvegarde. Mettez le mécanisme, le lien du runbook, l'emplacement des informations d'identification et des comptes brisés, ainsi que toute modification manuelle du DNS ou du réseau dans la zone de commentaires, afin que le graphique soit utilisable lors d'une récupération et pas seulement lors d'un examen.
Définir ce que signifie « intégrité vérifiée » et qui le dit
Définissez les contrôles derrière « Intégrité des données vérifiée ? » : nombre d'enregistrements, contrôles de cohérence et de référence, tests de fumée au niveau de l'application, comparaison avec le dernier bon état connu. Décidez ce que signifie « une copie antérieure », combien de tentatives de restauration vous effectuez avant de passer au niveau supérieur, et notez que chaque pas en arrière augmente la perte de données que vous devrez déclarer par rapport au RPO.
Ajoutez une restauration automatique, puis testez le graphique et conservez la version
Confirmez que le chemin de restauration correspond à votre façon de travailler : fenêtre, resynchronisation des données à partir du site de récupération, approbation du contrôle des modifications et point auquel la reprise après sinistre est formellement interrompue. Ensuite, exercez le graphique, comparez le temps de récupération et la perte de données que vous avez atteint par rapport à vos objectifs lors de l'examen post-événement, et publiez la version approuvée afin que les gens répètent la même révision qu'ils suivraient en direct.
Questions fréquentes
Quelle est la différence entre la reprise après sinistre et la continuité des activités ?
La continuité des activités consiste à permettre à l'organisation de fournir ses produits et services pendant une interruption, par tous les moyens disponibles : solutions manuelles, locaux alternatifs, personnel redéployé, fournisseurs de secours, communications avec les clients. La reprise après sinistre constitue la partie informatique de cette démarche : restaurer les systèmes, les données et l’infrastructure dont dépend l’organisation. Le travail de continuité fixe les priorités, car l'analyse d'impact sur l'entreprise décide quelles activités sont les plus importantes et combien de temps elles peuvent être interrompues ; la reprise après sinistre hérite de ces délais en tant qu'objectifs RTO et RPO et les respecte. Un plan de reprise après sinistre sans apport de continuité a tendance à récupérer ce qui est le plus facile à récupérer en premier.
Que signifient réellement RTO et RPO ?
Le RTO, l'objectif de temps de récupération, est le délai cible dans lequel un système ou un service doit être à nouveau utilisable, mesuré à partir de la perturbation plutôt qu'à partir du moment où quelqu'un signe le formulaire d'invocation. Le RPO, l'objectif du point de restauration, est le moment auquel les données doivent être restaurées, mesuré à rebours à partir de la perturbation. En pratique, il s'agit de la perte de données maximale que l'organisation est prête à accepter. Ils génèrent différents investissements : le RTO est défini par la rapidité avec laquelle vous pouvez mettre en place l'infrastructure (capacité de veille, automatisation, répétition), tandis que le RPO est limité par la fréquence à laquelle les données sont copiées, de sorte que les sauvegardes nocturnes ne peuvent pas prendre en charge un RPO inférieur à environ une journée, quelle que soit la rapidité d'exécution de la restauration. Les deux termes sont définis dans les normes de continuité d'activité telles que la norme ISO 22301.
Qui doit autoriser l’invocation de DR, et quand ?
Invocation doit être associé à un rôle capable d'accepter le coût et le risque de basculement, généralement un cadre ou le responsable de la crise, avec un adjoint nommé et un itinéraire documenté en dehors des heures d'ouverture. Il est volontairement séparé du rôle de coordinateur DR dans ce schéma : le coordinateur évalue et recommande, la direction autorise, et le coordinateur exécute ensuite la reprise. Le déclencheur doit être écrit à l'avance et pouvoir être testé par rapport aux données disponibles au début d'une panne, car l'erreur coûteuse consiste à ne pas l'invoquer trop tôt ; il faut trois heures pour décider si cela compte pendant que l'horloge RTO fonctionne.
Que se passe-t-il si les données restaurées échouent au contrôle d'intégrité ?
Le graphique boucle plutôt que de continuer : « Intégrité des données vérifiée ? » renvoie une branche ayant échoué à « Restaurer à partir d'une copie antérieure », qui est réinjectée dans l'étape de restauration afin que la vérification soit à nouveau exécutée. C'est dans cette boucle que le RPO est testé dans des conditions réelles, car chaque retour à une copie plus ancienne augmente la perte de données que vous devrez déclarer, et à un moment donné, la réponse honnête est que l'objectif ne peut pas être atteint et que l'entreprise doit savoir à quelle période elle doit reconstruire manuellement. Il vaut la peine de convenir à l'avance du nombre de tentatives que vous effectuez, de qui est autorisé à accepter un point de récupération pire que le RPO et de la manière dont l'écart est enregistré.
À quelle fréquence le processus de reprise après sinistre doit-il être testé ?
Assez souvent, le plan reflète la situation actuelle et les résultats sont écrits. La plupart des organisations effectuent un mélange : des contrôles de restauration fréquents sur les sauvegardes, des tests de basculement de composants ou partiels tout au long de l'année et un exercice plus complet sur un cycle régulier, généralement annuel, les secteurs réglementés et les services critiques en attendant davantage. Ce qui compte plus que l’intervalle, c’est ce qui est testé. Une restauration qui n'est jamais réellement montée et lue ne prouve rien, et un exercice qui ignore les étapes de validation et de restauration tend à cacher les deux problèmes les plus préjudiciables en cas d'événement réel : les propriétaires d'applications découvrent des erreurs que personne n'avait anticipées et aucun itinéraire convenu pour revenir au site principal.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus passe le relais à Diagramme du processus de gestion des changements (ITIL).
Suit
- Diagramme du processus de gestion des changements (ITIL) — Diagramme du processus de gestion des changements ITIL : accueil des RFC, tri standard, normal et urgence, approbation du CAB, planification, déploiement et retour arrière.
Fait partie de
- Continuité des activités