RTO, RPO et MTTR : définir les objectifs de reprise

Sans objectifs de récupération précis et mesurables, il est impossible de concevoir des stratégies de sauvegarde adaptées, de choisir le niveau de site DR approprié ou d’évaluer si les investissements dans les technologies de récupération sont justifiés. Le RTO, le RPO et le MTTR traduisent les exigences métier de disponibilité en objectifs d’ingénierie précis. Ces mesures permettent aux équipes de sécurité et IT d’avoir avec les dirigeants des échanges fondés sur des éléments concrets concernant le coût du downtime par rapport à celui des investissements en DR, ce qui rend les analyses de rentabilité concrètes plutôt qu’abstraites.

L’objectif de délai de récupération (RTO) est le délai maximal acceptable entre le début d’une perturbation et le rétablissement du Service normal. Si un système de paiement Critical tombe en panne à 10:00 AM et que l’entreprise peut tolérer au maximum 2 Hours de downtime avant de subir une perte de revenus inacceptable ou de violer ses SLA, le RTO est de 2 Hours : le système doit être rétabli au plus tard à 12:00 PM. Le RTO détermine les choix concernant le niveau du site DR (site Hot pour un RTO de 15 Minutes contre site Cold pour un RTO de 48 Hours), la fréquence de réplication et l’automatisation du basculement.

L’objectif de point de récupération (RPO) est la perte de données maximale acceptable, mesurée dans le temps : quelle quantité de données peut être perdue en cas de catastrophe. Un RPO d’1 hour signifie que, lors de la restauration des systèmes, ceux-ci doivent contenir des données datant d’au plus 1 hour avant la catastrophe. Le RPO détermine la fréquence des sauvegardes : un RPO d’1 hour exige au moins des sauvegardes Hourly (ou une réplication continue). Un RPO de 4 Hours peut tolérer des intervalles de sauvegarde de 4 Hours. Le RPO concerne la récupération des données, tandis que le RTO concerne le rétablissement de la disponibilité du Service.

Le RTO et le RPO concernent des aspects différents de la récupération et doivent être définis indépendamment. Un système peut avoir un RPO strict (1 hour, ce qui signifie que les données sont répliquées fréquemment), mais un RTO souple (4 Hours, car le démarrage de l’environnement DR prend du temps, même si les données sont à jour). À l’inverse, un système peut avoir un RPO souple (24 Hours, une sauvegarde Nightly suffit) mais un RTO strict (basculement requis en 1 hour, ce qui nécessite qu’un environnement DR préprovisionné soit prêt à être activé). Ces deux mesures proviennent de l’analyse d’impact métier.

Le temps moyen de récupération (MTTR) est le temps moyen réellement nécessaire pour rétablir le Service après un incident : c’est la mesure opérationnelle des performances de récupération. Alors que le RTO est le downtime maximal tolérable (objectif/exigence), le MTTR correspond à la moyenne observée (performance réelle). Les organisations mesurent le MTTR pour l’ensemble des incidents au fil du temps et le comparent au RTO afin d’évaluer leur capacité de récupération. Un MTTR dépassant systématiquement le RTO indique que les capacités de DR sont insuffisantes et que des investissements dans l’automatisation, le personnel ou l’infrastructure sont nécessaires.

Le temps moyen entre les pannes (MTBF) mesure la fiabilité du système, c’est-à-dire le temps moyen pendant lequel un système fonctionne entre deux pannes. Un MTBF Higher indique une meilleure fiabilité. Le MTBF et le MTTR déterminent ensemble le pourcentage de disponibilité d’un système : Availability = MTBF / (MTBF + MTTR). Un système avec un MTBF de 2000 Hours et un MTTR de 2 Hours a une Availability de 2000/2002 = 99,9 %. Comprendre le MTBF aide à prévoir la probabilité des pannes et à planifier les fenêtres de maintenance en conséquence : le matériel dont le MTBF diminue approche de sa fin de vie et doit être remplacé de manière proactive.

Le downtime maximal tolérable (MTD) est la durée absolument maximale pendant laquelle un système peut être indisponible avant que l’entreprise ne subisse un préjudice irréversible : perte de clients, sanctions réglementaires ou incapacité à respecter ses obligations contractuelles. Le MTD est toujours supérieur ou égal au RTO. La relation est la suivante : le MTD est la limite métier ; le RTO est l’objectif IT. Si un contrat autorise une violation du SLA pendant 4 Hours avant l’application de sanctions, le MTD peut être de 4 Hours. L’équipe IT conçoit alors un RTO de 1 à 2 Hours afin de conserver une marge de sécurité avant d’atteindre le MTD.

Les accords de niveau de Service (SLAs) définissent les engagements contractuels envers les clients qui déterminent directement les exigences de RTO et de RPO. Un SLA de fournisseur Cloud garantissant une Uptime de 99,95 % autorise environ 4,4 Hours de downtime par an. Une violation du SLA déclenche des crédits de Service ou des droits de résiliation du contrat. Les SLA internes entre l’IT et les unités métier fonctionnent de la même manière. Le RTO et le RPO doivent être conçus de façon à maintenir le downtime réel dans les limites des engagements du SLA, et le MTTR doit être mesuré et communiqué pour démontrer la conformité.

Les choix technologiques sont directement déterminés par les exigences de RTO et de RPO. Un RTO de 15 Minutes avec un RPO nul exige une mise en cluster actif-actif avec une réplication Synchronous : aucune perte de données et basculement automatique. Un RTO de 4 Hours avec un RPO d’1 hour peut utiliser l’expédition des journaux ou une réplication asynchrone vers un système Warm en attente. Un RTO de 24 Hours avec un RPO de 24 Hours peut utiliser des sauvegardes Daily vers un stockage Cold. Concevoir une résilience supérieure aux besoins gaspille le budget ; concevoir une résilience inférieure crée un risque métier inacceptable lors des incidents.

Les objectifs de reprise ne sont valides que s’ils sont régulièrement validés par des tests. Les organisations doivent effectuer des tests de reprise qui mesurent le MTTR réel et vérifient le point de reprise réel des données (de quand datent les données lors de leur restauration ?). Si un test révèle que le MTTR est systématiquement de 3 heures alors que le RTO est d’une heure, cet écart doit être corrigé — soit en améliorant l’infrastructure de DR (automatisation, préprovisionnement), soit en révisant les attentes de l’entreprise au moyen d’un BIA mis à jour. La fréquence des tests doit être adaptée à la criticité : les systèmes CRITICAL chaque trimestre, les autres chaque année.

Les rapports sur le RTO, le RPO et le MTTR doivent être communiqués aux parties prenantes de l’entreprise dans des termes qu’elles comprennent. Au lieu de dire : « notre MTTR pour les systèmes de niveau 1 est de 47 minutes », dites : « lorsque nos systèmes les plus critiques tombent en panne, nous rétablissons le service en moins d’une heure en moyenne — dans la fenêtre de 2 heures autorisée par nos contrats ». Des rapports réguliers renforcent la confiance des parties prenantes et favorisent une compréhension commune du niveau de résilience de l’organisation. La présentation, dans des tableaux de bord, de l’évolution du MTTR au fil du temps démontre les progrès du programme et justifie les budgets consacrés aux investissements de DR.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que le RTO correspond à la durée maximale pendant laquelle un service peut être indisponible et détermine les exigences de rapidité du basculement, que le RPO correspond à la perte de données maximale acceptable et détermine la fréquence des sauvegardes et de la réplication, et que le MTTR correspond à la durée moyenne réelle de reprise mesurée, comparée au RTO pour évaluer l’efficacité du programme de DR. Nous allons maintenant étudier les stratégies de sauvegarde — la règle 3-2-1 et les sauvegardes immuables que les rançongiciels ne peuvent pas détruire.