Chapitre 34. Stratégie de reprise
Objectifs pédagogiques¶
Définir RPO et RTO, les mesurer plutôt que les estimer, et les faire arbitrer par qui doit le faire. Cartographier les dépendances de la reprise. Analyser chaque scénario de perte avec son impact, sa procédure et son coût. Distinguer ce qui relève de la redondance, de la sauvegarde et de l'acceptation. Situer les réplications de l'édition Enterprise. Rédiger un plan de reprise et le maintenir exerçable.
Prérequis¶
Chapitre 33 (la matière première et sa durée mesurée), chapitre 26 (ce que le cluster absorbe seul), chapitre 29 (les risques résiduels, dont celui du site unique), chapitre 23 (l'ordre de reprise générale).
Cours¶
34.1 Les deux chiffres, et qui les donne¶
Toute stratégie de reprise se construit sur deux engagements chiffrés. Le RPO fixe la perte de données acceptable, exprimée en temps : un RPO d'une heure signifie qu'un sinistre peut coûter jusqu'à une heure d'écritures, secrets créés, rotations effectuées, identités modifiées. Le RTO fixe la durée d'indisponibilité acceptable, du sinistre au service rendu.
Trois précisions évitent les malentendus qui ruinent ces engagements. Ils ne se déduisent pas de la technique : ce sont des décisions métier, prises par qui assume les conséquences d'une interruption, l'équipe d'infrastructure se contentant de dire ce que chaque niveau coûte. Ils se mesurent ensuite : un RTO annoncé sans restauration chronométrée est un vœu, et le chapitre 33 vient de fournir le chiffre réel. Ils sont enfin différenciés par scénario : perdre un nœud et perdre le site n'appellent ni la même procédure ni la même promesse.
Ceux d'Astrea, arrêtés en comité.
| Scénario | RPO | RTO | Fondement |
|---|---|---|---|
| Perte d'un nœud | nul | nul | relève mesurée à neuf secondes |
| Perte du cluster, site intact | une heure | deux heures | cadence des snapshots, restauration chronométrée |
| Perte du site | une heure | six heures | acheminement du matériel, de la clé et des parts |
Ce dernier chiffre a fait l'objet du seul vrai débat : la direction voulait quatre heures, l'équipe a montré la mesure et le fait qu'aucun site de secours n'existe. Six heures ont été retenues, avec leur critère de révision, et le risque résiduel correspondant a été mis à jour.
34.2 Ce dont dépend la reprise¶
Le jour du sinistre, on ne restaure pas Vault : on reconstitue une chaîne. Voici les dépendances dans l'ordre où elles manquent, et chacune a coûté une heure à quelqu'un, quelque part.
Le matériel de scellement vient en tête, parce que sans lui le snapshot ne vaut rien : vault-transit-01 rétabli ou reconstruit, donc sa propre sauvegarde et ses parts de Shamir 3/2, avec deux porteurs joignables.
La clé de sauvegarde, hors ligne, en double détention, avec sa procédure d'accès au coffre : quarante minutes mesurées.
Le DNS, qui porte le nom de service : sans lui, les certificats ne valident plus et aucun client ne trouve le service. L'équipe qui l'administre doit figurer au plan.
La PKI, puisque les certificats des nœuds sont émis par Vault lui-même. Reconstruire exige un certificat serveur, donc un mécanisme d'amorçage qui ne dépende pas du Vault qu'on restaure : un certificat de secours à durée longue conservé avec la clé de sauvegarde, ou une émission depuis le Vault restauré avant remise en service, ce qui suppose de savoir dans quel ordre faire les choses.
Le temps, dont dépendent les baux, les certificats et Raft : une machine de secours à l'horloge fausse produit des symptômes incompréhensibles.
Le répartiteur et sa configuration, reconstruits par la gestion de configuration, laquelle devient elle-même une dépendance.
Les secrets d'amorçage, enfin : le token de seal des nœuds, l'identifiant du rôle de sauvegarde, les accès au dépôt.
La question qui teste un plan de reprise se formule en une ligne : où est écrit ce qu'il faut, et où est ce qui n'est écrit nulle part ? Un plan est complet quand chaque dépendance porte un nom, un lieu et un détenteur.
34.3 La matrice des scénarios¶
| Perte | Ce qui tombe | Ce qu'on fait | Ce que ça coûte |
|---|---|---|---|
| Un disque | une voix, service intact | retirer le pair, reconstruire, rejoindre | tolérance consommée, un disque à détruire |
| Un nœud | idem, avec bascule si c'était l'actif | identique | neuf secondes, absorbé par l'architecture |
| Le quorum | plus d'écritures ni de logins | réparer si les machines reviennent, forcer sinon | interruption réelle, choix sous pression |
| Le cluster | tout, site intact | reconstruire et restaurer le dernier snapshot | une heure d'écritures perdues, deux heures d'arrêt |
| Le site | tout, y compris le reste du SI | matériel de secours, acheminement, reconstruction | six heures annoncées, coordination large |
| Le matériel de scellement | la lisibilité de tous les snapshots | rien | aucune reprise possible |
Le dernier scénario est celui que les plans oublient : vault-transit-01 détruit et sa sauvegarde perdue, ou les parts insuffisantes après plusieurs départs. Les snapshots deviennent illisibles et aucune procédure ne les sauve. C'est le seul cas sans reprise, ce qui en fait le plus important à prévenir : sauvegarde propre du gardien, parts dispersées, vérification annuelle des porteurs.
Le scénario du site mérite aussi un mot : Vault n'y est plus un problème isolé mais une pièce d'un plan de continuité plus large, et son RTO n'a de sens que rapporté à celui des applications qu'il sert.
34.4 Ce que le RPO coûte vraiment¶
Un RPO d'une heure paraît anodin jusqu'à ce qu'on énumère ce qu'une heure d'écritures contient.
Des secrets créés ou modifiés : une rotation effectuée après la prise du snapshot revient à l'ancienne valeur, celle que la cible ne connaît plus. Des identités et des policies : l'entité créée pour la nouvelle collègue disparaît, son accès aussi. Des baux : ceux émis dans l'heure n'existent plus côté Vault alors que les comptes existent toujours côté cible, orphelins que rien ne révoquera. Des tokens : tout ce qui s'est authentifié depuis le snapshot doit recommencer, ce que les applications bien écrites font seules.
L'enseignement dépasse le chiffre : après une restauration, le monde et Vault ne sont plus d'accord, et la reprise n'est terminée qu'une fois cet écart traité. Le chapitre 35 en fait une étape de procédure. C'est aussi l'argument qui justifie une cadence plus courte là où les écritures sont fréquentes : le RPO ne se choisit pas par confort d'exploitation, mais par la quantité de désaccord qu'on accepte de réparer à la main.
34.5 Enterprise : la réplication¶
L'édition Enterprise propose deux réplications qu'il faut situer sans les confondre. La réplication de reprise maintient un cluster secondaire à jour, en attente : il ne sert aucune requête et se promeut en cas de sinistre, ce qui ramène le RPO à quelques instants et le RTO à la durée d'une promotion. La réplication de performance maintient des clusters secondaires qui servent localement les lectures, pour rapprocher le service des consommateurs éloignés ; son objet premier n'est pas la reprise.
Deux mises en garde accompagnent ces capacités. Elles ne dispensent pas des snapshots : une réplication propage fidèlement une erreur logique, quand un snapshot permet de revenir en arrière. Et elles déplacent la frontière de confiance : un cluster secondaire détient les mêmes données, donc mérite les mêmes protections, ce que les projets sous-estiment régulièrement.
34.6 Le plan, et son exercice¶
Un plan de reprise se juge à trois qualités.
Il est écrit hors ligne : un plan stocké uniquement dans le système d'information qu'il doit relever ne servira pas. Astrea en garde une copie papier au coffre et une copie chez le prestataire hors site.
Il est nominatif : chaque étape a un rôle, chaque rôle a un titulaire et un suppléant joignables, porteurs de parts compris.
Il est exercé : la restauration mensuelle en éprouve la moitié technique, et un exercice annuel de bout en bout, sur le scénario du site, en éprouve la moitié humaine. Celle où l'on découvre que la clé de sauvegarde est dans un coffre dont le code est connu d'une personne en congé.
Exemple : la réunion de cadrage¶
Une heure, la directrice technique, la RSSI, le responsable applicatif et deux ingénieurs. Le tableau présenté tient en trois lignes de RPO et RTO par scénario, chacune assortie de son coût annuel.
Pourquoi six heures et non quatre. La directrice technique demande pourquoi le RTO du site dépasse celui exigé pour l'application. La réponse tient en deux mesures et une question : la restauration chronométrée a pris une heure cinquante-cinq dans des conditions idéales, sur du matériel disponible ; le scénario du site ajoute l'acheminement, le matériel et la coordination ; et surtout, si l'application doit revenir en quatre heures, la question n'est pas Vault seul mais la base, le réseau et les applications, dont aucun plan n'affiche encore de chiffre. Décision : six heures pour Vault, et un chantier de continuité plus large ouvert. C'est exactement le résultat qu'une bonne réunion de reprise doit produire.
Le coût du RPO découvert. Le responsable applicatif comprend qu'une heure de perte signifie des comptes orphelins et des credentials à réémettre. Il demande si la cadence peut passer au quart d'heure. Le calcul est fait en séance : quatre fois plus de snapshots, donc quatre fois plus de copies du coffre à garder, à inventorier, à détruire. L'arbitrage retenu est un compromis : cadence horaire en régime normal, cadence courte activable pendant les fenêtres de changement importantes. Une décision qui n'aurait pas émergé sans que le chapitre 33 ait rendu visible le coût de la rétention.
Le scénario sans reprise. La RSSI pose la question, et l'équipe confirme : la perte simultanée de vault-transit-01 et de sa sauvegarde rend l'ensemble des snapshots inexploitables. Trois mesures en sortent : une seconde copie de la sauvegarde de transit-01 dans un troisième lieu, la vérification annuelle des porteurs avancée, et l'inscription de ce scénario en tête du plan, avec la mention que sa prévention passe avant toute optimisation du RTO.
Sécurité : la reprise vue par l'attaquant¶
Un plan de reprise est une carte des dépendances critiques. Il nomme les coffres, les détenteurs, les procédures d'accès et les lieux. Sa diffusion se restreint et sa version détaillée reste hors ligne.
La reprise est une fenêtre de vulnérabilité. Pendant la restauration, les protections sont partielles : audit pas encore branché, pare-feu de la machine neuve à peine appliqué, certificats provisoires. La procédure du chapitre 35 place les contrôles dans un ordre qui réduit cette fenêtre.
Un secondaire vaut un primaire. Le cluster de reprise détient les mêmes secrets ; ses protections et sa surveillance sont celles d'une production, pas d'une machine de secours.
Le désaccord d'après restauration s'exploite. Des comptes orphelins subsistent sur les cibles, des credentials restaurés fonctionnent encore alors que Vault les ignore. La liste de contrôle de fin de reprise ferme des accès qui ne sont plus gouvernés : elle relève de la sécurité, pas du ménage.
Erreurs fréquentes¶
Annoncer un RTO jamais mesuré. Sans restauration chronométrée, le chiffre est une intention, et l'écart se découvre le jour où il coûte le plus cher (section 34.1).
Un seul couple de chiffres pour tous les scénarios. Un plan indifférencié ment sur l'un des deux cas (section 34.1).
Oublier les dépendances non-Vault. DNS, horloge, certificats d'amorçage, gestion de configuration, équipes tierces : ce sont elles qui allongent les reprises réelles (section 34.2).
Négliger le scénario du matériel de scellement. C'est le seul sans issue, et pourtant le moins souvent écrit (section 34.3).
Traiter le RPO comme un simple réglage. Une heure de perte, ce sont des rotations annulées, des identités disparues, des baux désaccordés du monde réel (section 34.4).
Prendre la réplication pour une sauvegarde. Elle réplique aussi les erreurs logiques (section 34.5).
Garder le plan uniquement en ligne. Le document qui doit relever le système d'information ne peut pas dépendre de lui (section 34.6).
Mise en pratique : chiffrer, cartographier, arbitrer¶
Sur papier ; réponses commentées en fin de partie.
- Rédigez la fiche de reprise du scénario de perte du site : dépendances dans l'ordre, rôles et titulaires, étapes majeures, chiffres engagés, et les trois points où le chronomètre risque de déraper.
- La direction demande un RTO de deux heures sur ce scénario, sans budget supplémentaire. Rédigez la réponse argumentée : ce qui est possible, ce qui ne l'est pas, et les deux options chiffrées que vous mettez sur la table.
- Établissez la liste de contrôle du désaccord entre Vault et le monde, à exécuter après une restauration, en distinguant ce qui se vérifie côté Vault et côté cibles.
Questions de compréhension¶
- Définissez RPO et RTO, dites qui les arrête et pourquoi ils se mesurent au lieu de s'estimer.
- Pourquoi les chiffres se différencient-ils par scénario ?
- Énumérez au moins six dépendances de la reprise et dites, pour chacune, ce qu'elle bloque si elle manque.
- Parcourez la matrice et indiquez lequel des scénarios l'architecture absorbe seule, lequel exige un choix sous pression, et lequel n'a pas de reprise.
- Que contient concrètement une heure d'écritures perdues, et quelle conséquence en tirer pour la procédure ?
- Distinguez les deux réplications, et dites ce que ni l'une ni l'autre ne remplace.
- Quelles sont les trois qualités d'un plan de reprise, et laquelle échoue le plus souvent ?
- Pourquoi la reprise est-elle une fenêtre de vulnérabilité, et comment la refermer ?
Synthèse¶
Une stratégie de reprise commence par deux chiffres que la direction arrête et que l'équipe mesure, différenciés par scénario. Elle continue par la cartographie de ce dont la reprise dépend, matériel de scellement, clé hors ligne, DNS, certificats d'amorçage, horloge, gestion de configuration, équipes tierces : le jour venu, on ne restaure pas un serveur, on reconstitue une chaîne. La matrice distingue ce que l'architecture absorbe seule, ce qui impose un choix sous pression, et l'unique scénario sans issue, la perte conjointe du gardien et de sa sauvegarde, dont la prévention prime sur toute optimisation. Le RPO se paie en désaccords entre Vault et le monde, qui se réparent à la main et se listent d'avance. La réplication de l'édition Enterprise raccourcit tout cela sans dispenser des snapshots. Le plan, enfin, vaut par trois qualités : hors ligne, nominatif, exercé.