Article · Continuité
Planifier la reprise après sinistre TI, étape par étape
Un plan de reprise après sinistre répond à une question avant qu’elle ne devienne urgente : si nos systèmes tombent demain, que restaurons-nous en premier, comment, qui s’en charge et en combien de temps ? Ce guide explique comment bâtir un plan qu’une petite ou moyenne organisation peut réellement tenir à jour et utiliser.
- Publié le
- Lecture de 7 min
Sur cette page
À retenir
- La reprise après sinistre est le volet TI de la continuité des activités : rétablir les systèmes et les données après une perturbation.
- Une analyse des répercussions sur les activités détermine quels processus comptent le plus et combien de temps chacun peut supporter une interruption.
- Le délai de reprise visé (RTO) et le point de reprise visé (RPO) traduisent la tolérance de l’entreprise en cibles techniques.
- Les guides d’exploitation transforment le plan en instructions détaillées qu’une autre personne peut suivre sous pression.
- Les exercices sur table et les tests techniques de restauration montrent si le plan fonctionne et le gardent à jour.
Reprise après sinistre, continuité des activités et intervention en cas d’incident
Ces notions se chevauchent : il est donc utile de les distinguer. La planification de la continuité des activités porte sur la façon dont l’ensemble de l’organisation continue de fonctionner pendant une perturbation : locaux de rechange, solutions manuelles de contournement, ententes avec les fournisseurs et communications. La reprise après sinistre est le volet technologique de ce plan : rétablir les systèmes, les applications et les données. L’intervention en cas d’incident porte sur la façon de détecter, de contenir et d’analyser un événement de sécurité, comme un rançongiciel ou un compte compromis.
Lors d’une cyberattaque, les trois se déroulent en même temps. L’intervention en cas d’incident détermine quand il est sécuritaire de restaurer, la reprise après sinistre effectue la restauration et la planification de la continuité permet de continuer à servir les clients entre-temps. Un bon plan de reprise renvoie aux deux autres plutôt que d’essayer de les remplacer.
Commencer par une analyse des répercussions sur les activités
Une analyse des répercussions sur les activités (BIA) est une discussion structurée avec les personnes qui font tourner l’entreprise. C’est le fondement de toute décision de reprise.
Dresser la liste des processus essentiels
Repérez les activités qui génèrent des revenus, servent les clients ou permettent de respecter des obligations, comme la facturation, la paie, la planification des horaires, l’accès aux dossiers clients et le courriel.
Cartographier les dépendances
Pour chaque processus, énumérez les applications, les données, les appareils, les services réseau, les identités et les tiers dont il dépend. Incluez les éléments facilement oubliés comme le DNS, la connexion Internet, l’authentification multifacteur et le processeur de paiements.
Estimer les répercussions dans le temps
Demandez ce qui se passe après une heure, un jour et une semaine sans chaque processus, en tenant compte des effets financiers, sur la clientèle, contractuels, juridiques et sur la réputation.
Fixer les seuils de tolérance
Convenez de la durée maximale d’interruption tolérable pour chaque processus et de la quantité de données que l’entreprise pourrait se permettre de ressaisir ou de perdre.
Classer et faire approuver
Regroupez les systèmes en niveaux de reprise et faites approuver les priorités par la direction, car elles orienteront à la fois le plan et le budget.
Le RTO et le RPO en termes concrets
Délai de reprise visé (RTO)
La durée pendant laquelle un système peut être indisponible avant que les répercussions deviennent inacceptables. Un RTO de quatre heures signifie que la méthode de reprise doit pouvoir, de façon réaliste, rétablir le système en quatre heures, y compris le temps de constater le problème et de décider d’agir.
Point de reprise visé (RPO)
La quantité de données, mesurée en temps, que vous pouvez vous permettre de perdre. Un RPO d’une heure exige des sauvegardes ou une réplication au moins toutes les heures ; des sauvegardes nocturnes impliquent la perte possible d’une journée de travail.
Niveaux de priorité
Tous les systèmes n’ont pas besoin des mêmes cibles. Le niveau 1 pourrait comprendre l’identité, le courriel et l’application métier principale ; le niveau 3, des archives qui peuvent attendre plusieurs jours.
Le coût suit les cibles
Des RTO et RPO plus courts coûtent plus cher, en raison de la réplication, de l’infrastructure de relève ou de services de niveau supérieur. L’analyse des répercussions permet à l’entreprise de choisir ses cibles en connaissance de cause.
Choisir les stratégies de reprise
Une fois les cibles fixées, choisissez une méthode de reprise pour chaque niveau et confirmez qu’elle peut les atteindre.
- Restauration à partir des sauvegardes sur le matériel existant ou de remplacement : coût le plus bas, délai de reprise le plus long, convient aux niveaux inférieurs.
- Restauration ou basculement vers une infrastructure infonuagique : les plateformes de sauvegarde capables de démarrer les serveurs protégés dans un environnement infonuagique raccourcissent la reprise sans nécessiter un deuxième bureau.
- Réplication vers des systèmes de relève : des copies presque à jour, prêtes à démarrer, utilisées lorsque le RTO et le RPO sont courts.
- Résilience des logiciels-services (SaaS) : Microsoft 365 et les autres plateformes SaaS retirent la reprise de l’infrastructure de votre plan, mais exigent toujours la sauvegarde des données, la récupération des identités et la planification des accès.
- Reprise en salle blanche en cas de rançongiciel : un environnement isolé où les systèmes restaurés sont analysés et validés avant d’être reconnectés, pour ne pas restaurer l’attaquant avec les données.
- Solutions manuelles de contournement : formulaires papier, chaînes téléphoniques ou exportations en lecture seule qui permettent aux processus essentiels de continuer pendant la restauration des systèmes.
Rédiger des guides d’exploitation faciles à suivre
Un guide d’exploitation (runbook) est une procédure détaillée pour rétablir un système précis ou gérer un scénario précis. Il doit pouvoir être utilisé par un technicien compétent qui n’a jamais touché à ce système, à deux heures du matin, sous pression. Il doit donc indiquer l’emplacement exact des sauvegardes, les comptes à utiliser et l’endroit où sont conservés leurs identifiants, l’ordre des opérations, la façon de valider le résultat et qui appeler si une étape échoue.
L’ordre compte. L’identité vient habituellement en premier, car rien d’autre ne peut être administré sans comptes d’administration et authentification multifacteur fonctionnels. Suivent le réseau et le DNS, puis les données et applications principales, puis les systèmes de niveau inférieur. Consignez explicitement les dépendances pour que personne ne passe une heure à restaurer une application dont le serveur de base de données n’est pas encore rétabli.
Conservez les guides d’exploitation là où ils resteront accessibles pendant le sinistre : une copie imprimée, une copie chiffrée hors ligne ou un emplacement infonuagique distinct qui ne dépend pas de votre locataire principal. Incluez une liste de contacts à jour : personnel, fournisseur TI, fournisseurs Internet et de téléphonie, principaux éditeurs de logiciels, cyberassureur et banque.
Rôles et communications
Attribuez des rôles clairs : un responsable de l’incident qui prend les décisions, un responsable technique qui dirige la reprise, un responsable des communications qui tient informés le personnel, les clients et les fournisseurs, et un secrétaire qui consigne les décisions et les heures. Dans une petite entreprise, une même personne peut cumuler plusieurs rôles, mais chaque rôle doit avoir un remplaçant désigné.
Préparez à l’avance des modèles de communication pour le personnel, les clients et les fournisseurs, et convenez des moyens que vous utiliserez si le courriel et Teams sont indisponibles. Lors d’un incident de sécurité, consultez votre assureur et vos conseillers juridiques avant toute déclaration publique, car la formulation peut avoir une incidence à la fois sur vos obligations en matière de protection des renseignements personnels et sur vos réclamations d’assurance.
Mettre le plan à l’épreuve : exercices sur table et essais techniques
Un plan non testé n’est qu’une hypothèse. Deux types de tests se complètent.
Exercice sur table
Réunissez les décideurs pendant une heure ou deux et déroulez un scénario réaliste, comme un rançongiciel découvert un lundi matin ou un incendie qui force la fermeture du bureau. Un animateur introduit des rebondissements et le groupe discute des décisions en s’appuyant sur le plan. Les lacunes apparaissent rapidement : contacts manquants, autorité mal définie, hypothèses sur les sauvegardes.
Test technique de reprise
Restaurez réellement un système à partir d’une sauvegarde dans un environnement isolé et chronométrez l’opération par rapport au RTO. Faites valider par un utilisateur du côté des affaires que les données sont complètes et que l’application fonctionne.
Bilan après l’exercice
Consignez ce qui a fonctionné, ce qui n’a pas fonctionné, et qui corrigera chaque lacune et pour quand. Mettez les guides d’exploitation à jour immédiatement, pendant que les détails sont frais.
Tenir à jour
Révisez le plan au moins une fois par année et après tout changement important, comme une nouvelle application, un déménagement, un changement de fournisseur ou le roulement de personnel à des postes clés.
Vérifiez votre police de cyberassurance
Bien des polices de cyberassurance imposent des conditions sur la gestion des incidents, comme aviser rapidement l’assureur et faire appel à des firmes d’intervention approuvées. Lisez votre police et intégrez ses exigences au plan, pour que vos décisions de reprise ne compromettent pas votre couverture.
Questions fréquentes
Quelle longueur devrait avoir un plan de reprise après sinistre ?
Assez long pour être utilisable, sans plus. Bien des petites entreprises s’en tirent très bien avec un court document qui couvre les priorités, les rôles et les contacts, accompagné de guides d’exploitation distincts pour chaque système essentiel.
Quelle est la différence entre le RTO et le RPO ?
Le RTO est le délai dans lequel un système doit être rétabli. Le RPO est la quantité de données récentes que vous pouvez vous permettre de perdre. Un système peut devoir être rétabli en moins d’une journée, sans perdre plus d’une heure de données.
Avons-nous besoin d’un plan de reprise si tout est dans Microsoft 365 ?
Oui, même s’il sera plus simple. Vous devez quand même pouvoir vous remettre de données supprimées ou chiffrées, d’un compte d’administration compromis, de la perte d’appareils ou d’une panne Internet, et savoir qui décide et comment le personnel continue de travailler.
À quelle fréquence devrions-nous tenir un exercice sur table ?
Au moins une fois par année est un rythme raisonnable pour la plupart des petites et moyennes organisations, avec un exercice supplémentaire après tout changement important touchant les systèmes, les fournisseurs ou le personnel clé.
Services connexes
Produits et forfaits
Bâtissez un plan de reprise que vous pouvez tester
Nous pouvons animer une analyse des répercussions sur les activités, fixer des cibles de reprise réalistes, rédiger les guides d’exploitation de vos systèmes essentiels et tenir un exercice sur table avec votre équipe de direction.