Éléments de réponse aux questions de compréhension
Chapitre 33¶
1. L'intégralité de l'état du cluster à un instant : montages, secrets, identités, policies, baux, table des tokens, configuration du seal. Il est produit par le nœud actif, à chaud, à partir de l'état engagé du journal, et il sort chiffré par la barrière. Ce n'est pas un export lisible mais le coffre entier.
2. Un snapshot ne s'ouvre qu'avec le matériel de scellement de son époque : les parts d'alors, ou l'accès à la clé d'enveloppe d'alors. Le forçage contourne des contrôles de cohérence, notamment la correspondance du type de seal ; il ne contourne aucune protection cryptographique, et sans le matériel d'origine le serveur restauré ne descellera pas.
3. Parce que le fichier ne vaut rien sans son gardien : il faut sauvegarder les snapshots du core et de quoi reconstituer le matériel de scellement, c'est-à-dire la sauvegarde du gardien, sa clé d'enveloppe et ses parts. Une stratégie qui ne couvre que la première moitié produit des fichiers que personne ne pourra ouvrir.
4. Le snapshot donne une image cohérente de l'état engagé, sans interruption. La copie du répertoire de données à chaud produit une image potentiellement incohérente, puisque le serveur écrit pendant la copie. La copie à froid, après arrêt propre, reste valide et cohérente, au prix de l'indisponibilité.
5. Le test de santé garantit qu'un seul nœud produit, et qu'il produit là où l'état est cohérent. Le chiffrement en flux évite qu'une version en clair du coffre touche le disque, même quelques secondes. Le dépôt en écriture seule empêche qu'un nœud compromis relise l'historique des sauvegardes ou l'efface.
6. Parce que restaurer Vault exigerait alors Vault, le cercle interdit annoncé au chapitre 16. La protection passe par trois moyens autonomes cumulés : chiffrement par une clé dédiée dont la partie privée vit hors ligne en double détention, séparation stricte d'avec le matériel de scellement, et contrôle d'accès au dépôt avec journalisation.
7. Garder plus longtemps augmente la profondeur de reprise et le nombre de copies complètes du coffre à garder, chacune ouvrable par le matériel de son époque. La rétention est donc simultanément une décision de disponibilité et une décision de sécurité, ce qui impose de tenir un inventaire par époque et de le relire à chaque rekey.
8. Superficiel et quotidien : présence du fichier, taille plausible, empreinte, arrivée au dépôt et hors site. Cryptographique et hebdomadaire : le fichier se déchiffre, éventuellement par le contrôle d'une clé de test pour éviter de sortir la clé maîtresse. Fonctionnel et mensuel : restauration réelle avec le matériel de l'époque. Seul le troisième prouve quelque chose, et il fournit la durée dont le chapitre 34 a besoin.
9. Parce qu'une chaîne de sauvegarde qui cesse de produire ne génère aucune erreur : elle ne fait rien, silencieusement. Les contrôles sur les fichiers présents n'ont alors plus rien à examiner, et le défaut se découvre le jour de la restauration.
Mise en pratique du chapitre 33. 1. La policy se réduit à une règle, la lecture du chemin de snapshot. Ce qu'on n'ajoute pas, et pourquoi : aucun droit de restauration, car produire une sauvegarde et écraser l'état sont deux pouvoirs sans rapport ; aucun listage des montages, le processus n'ayant pas à connaître le contenu ; aucun accès au point de santé, l'appel étant non authentifié ; aucun droit sur les baux ni sur l'audit, malgré la tentation d'ajouter des vérifications au même script, car un rôle sert une fonction. Le rôle associé est borné en origine au réseau des trois nœuds, avec des identifiants renouvelés. 2. Le chiffrement de volume protège contre le vol du support physique et rien d'autre : un attaquant qui obtient un accès au système du dépôt lit les snapshots en clair, puisque le volume est monté et déchiffré. Le chiffrement applicatif protège contre ce même attaquant, contre la compromission du dépôt, contre l'indiscrétion du prestataire hors site et contre l'erreur de copie vers un emplacement moins protégé. Il laisse ouverte la destruction des fichiers, que le pare-feu et le dépôt en écriture seule couvrent, et il ajoute une dépendance à la clé privée, qui devient un point de défaillance si sa garde est mal organisée, d'où la double détention et la vérification hebdomadaire. Les deux dispositifs sont complémentaires et non substituables : on garde le chiffrement de volume, on ajoute le chiffrement applicatif, et l'on documente que le second couvre la menace réellement redoutée, la lecture par quelqu'un qui a un accès légitime à la machine. 3. Colonnes : identifiant du snapshot ; tranche de rétention ; emplacements connus ; empreinte ; génération de parts et version de clé d'enveloppe en vigueur à la prise ; date de destruction prévue ; date de destruction attestée. Sources : le script d'automatisation pour les six premières, le registre des cérémonies pour la génération de parts, la procédure de destruction pour la dernière. Mise à jour automatique à chaque prise, revue humaine à chaque rekey. Question d'audit à laquelle il répond en moins d'une minute : cette part qui vient d'être compromise ouvre quelles sauvegardes, et où sont-elles ?
Chapitre 34¶
1. Le RPO est la perte de données acceptable depuis le dernier point de reprise ; le RTO est la durée d'indisponibilité acceptable, du sinistre au service rendu. Ils sont arrêtés par la direction, qui assume les conséquences d'une interruption, l'équipe se bornant à chiffrer ce que chaque niveau coûte. Ils se mesurent parce qu'un RTO annoncé sans restauration chronométrée est une intention.
2. Parce que les procédures et les moyens diffèrent : la perte d'un nœud est absorbée par la relève, celle du cluster exige une restauration, celle du site ajoute l'acheminement et la coordination. Un couple unique de chiffres est nécessairement faux pour au moins un scénario, et il induit en erreur ceux qui s'y fient.
3. Le matériel de scellement, sans lequel aucun snapshot n'est exploitable. La clé de sauvegarde hors ligne et sa procédure d'accès. Le DNS, sans lequel plus de résolution ni de validation de certificats. La PKI et un certificat d'amorçage, sans quoi le serveur reconstruit ne peut pas servir en TLS. L'horloge, sans laquelle baux, certificats et consensus se comportent de façon incompréhensible. La gestion de configuration, sans laquelle la reconstruction est manuelle. Et les secrets d'amorçage.
4. L'architecture absorbe seule la perte d'un disque ou d'un nœud. La perte du quorum impose un choix sous pression entre attendre le retour des machines et forcer la configuration avec une perte non chiffrable. La perte conjointe du matériel de scellement et de sa sauvegarde n'a pas de reprise.
5. Des secrets créés ou modifiés qui reviennent à leur valeur ancienne, désaccordée des cibles. Des identités et des policies disparues. Des baux absents côté Vault alors que les comptes existent côté cible, donc des orphelins non gouvernés. Des tokens perdus, obligeant les applications à se réauthentifier. Conséquence : la reprise ne s'achève pas à la restauration mais au réaccord du monde.
6. La réplication de reprise maintient un secondaire à jour, inactif, promu en cas de sinistre. La réplication de performance maintient des secondaires qui servent les lectures localement. Ni l'une ni l'autre ne remplace les snapshots, puisqu'elles répliquent fidèlement les erreurs logiques, et toutes deux étendent la frontière de confiance à des clusters qui détiennent les mêmes données.
7. Écrit hors ligne, nominatif, exercé. La troisième échoue le plus souvent : les plans sont rédigés, parfois relus, rarement joués, et ce sont les procédures humaines que l'exercice révèle défaillantes.
8. Parce que les protections sont partielles pendant la reconstruction : audit pas encore branché ou destination injoignable, pare-feu à peine appliqué, certificats provisoires, comptes d'amorçage actifs. On la referme en plaçant les contrôles dans un ordre défini par la procédure, et en vérifiant à l'exercice qu'aucun n'a été contourné.
Mise en pratique du chapitre 34. 1. Dépendances dans l'ordre : parts du gardien avec leurs suppléants ; sauvegarde du gardien ; clé de sauvegarde hors ligne ; dernier snapshot vérifié et sa copie hors site ; matériel de calcul et réseau du site de secours ; DNS ; certificat d'amorçage ; gestion de configuration. Rôles : un directeur d'incident pour les décisions et la communication, un opérateur pour les procédures, un porteur de parts, un détenteur de clé, un responsable applicatif. Étapes majeures : réunir le matériel, monter le gardien, monter un cluster vide, restaurer, ramener à trois voix, remettre l'entrée en service, dérouler la liste de réaccord, rouvrir aux applications. Les trois points où le chronomètre dérape : l'accès aux coffres, qui dépend de personnes et non de machines ; l'obtention du matériel, si aucun contrat ne le garantit ; et la remise en service de l'entrée, où DNS et certificats font intervenir des équipes tierces. 2. Deux heures sont atteignables pour le scénario du cluster sur site intact, c'est déjà l'engagement pris et il est mesuré. Pour le site perdu, deux heures supposeraient trois conditions qu'un budget nul ne permet pas : du matériel préprovisionné et à jour sur un second site, une copie du matériel de scellement immédiatement disponible là-bas, et une équipe capable d'intervenir sans déplacement. Ce qui est possible sans budget : réduire les quarante minutes d'accès aux coffres en désignant des suppléants et en rapprochant un support du site de secours, et préparer à l'avance les configurations et les images, ce qui ramène l'estimation à quatre ou cinq heures. Les deux options chiffrées : un site de secours passif avec matériel dormant et copie du gardien, qui rapproche des deux heures pour un coût de matériel et d'exploitation ; ou l'édition Enterprise avec réplication de reprise, qui ramène le RTO à une promotion mais suppose un second cluster protégé au même niveau. Le choix appartient à la direction, avec la mention que l'objectif n'a de sens que si la base et les applications s'engagent au même niveau. 3. Côté Vault : les baux vivants et leur volume comparé à la normale ; les policies confrontées au dépôt versionné ; les entités et rôles créés dans la dernière heure avant le sinistre ; les dispositifs d'audit et leur capacité effective à écrire ; les certificats émis dans la fenêtre, absents du stockage. Côté cibles : les comptes dynamiques sans bail correspondant, à inventorier puis supprimer ; les credentials révoqués avant le sinistre et ressuscités par la restauration, dont la validité se teste ; les rotations postérieures au snapshot, en particulier celles des comptes racines de moteurs, à retraiter avec le compte de secours ; les mots de passe statiques tournés dans la fenêtre.
Chapitre 35¶
1. Parce que chaque nœud détient une copie complète du coffre : le nouveau venu reçoit l'état par réplication depuis les survivants. Le snapshot ne sert que lorsque plus aucun nœud ne porte l'état, ou lorsqu'on veut revenir à un état antérieur.
2. La question est de savoir si les machines perdues reviendront. Si elles sont récupérables, on attend et l'on répare, parce que le quorum revient sans perte et qu'aucune manœuvre irréversible n'est engagée. Forcer prématurément coûte les écritures non répliquées et interdit le retour des anciens nœuds avec leur journal.
3. Plus aucun leader ne doit exister. Les nœuds concernés doivent être arrêtés pendant l'écriture du fichier. Les machines écartées ne doivent jamais revenir avec leur ancien journal, sous peine de divergence. Et l'on accepte la perte des écritures engagées par l'ancien leader mais non reçues par le survivant, dont personne ne peut dire le contenu. Une copie du répertoire prise avant la manœuvre est obligatoire.
4. Prendre un snapshot de l'état courant avant de l'écraser, puisque rien ne garantit que l'état restauré sera jugé préférable. Annoncer la coupure, car les tokens et les baux disparaissent du point de vue des clients. Vérifier l'identité du fichier, empreinte et horodatage, pour ne pas transformer un incident en sinistre.
5. Réunir le matériel de scellement, la clé de sauvegarde et le fichier vérifié ; monter un cluster vide avec le même gardien ; l'initialiser ; restaurer en forçant ; ramener à trois voix ; remettre l'entrée en service ; dérouler la liste de réaccord. On initialise un cluster qu'on va écraser parce que la restauration exige un serveur descellé et fonctionnel pour la recevoir, et les clés produites deviennent caduques, le snapshot apportant son propre keyring et ses propres recovery keys.
6. Il contourne les contrôles de cohérence entre le snapshot et le cluster cible, notamment le type de seal. Il ne contourne pas la cryptographie : le keyring reste protégé par la clé racine de son époque. L'erreur ne se manifeste donc pas à la restauration, qui réussit, mais au descellement, qui échoue, et à ce stade il n'y a plus de recours.
7. Côté Vault : type de seal et état descellé, trois votants, montages et policies conformes au dépôt, dispositifs d'audit capables d'écrire, volume de baux. Côté cibles : comptes dynamiques sans bail correspondant, credentials ressuscités dont la validité se teste, rotations postérieures au snapshot. Côté clients : réauthentification des applications, certificats émis après la prise et absents du stockage, à réémettre.
8. Parce que la rotation est appliquée côté cible et annulée côté Vault : les deux mondes détiennent des valeurs différentes, et Vault ne connaît plus la bonne. Le cas du compte racine de moteur est le pire, l'opération étant irréversible pour l'opérateur : le compte de secours hors Vault redevient la seule porte d'entrée.
9. Le chronomètre découpé par phase, qui alimente le RTO et désigne la phase réellement lente. Le journal de décision tenu en direct, qui permet de reconstituer les choix après coup. La liste des écarts, qui alimente la correction des procédures. Un exercice qui ne produit aucune correction n'a probablement pas été joué sincèrement.
Mise en pratique du chapitre 35. 1. Informations cherchées en premier : l'hyperviseur redémarre-t-il, avec quelle estimation, et les répertoires de données des deux nœuds sont-ils intacts ; le nœud survivant est-il bien seul et sans leader ; quelle est la fenêtre acceptable annoncée aux applications. Arbre de décision : si les machines reviennent dans un délai inférieur au temps qu'exigerait la manœuvre forcée plus sa vérification, attendre ; le service en lecture reste rendu par les credentials déjà émis, et seuls les démarrages échouent. Si le délai est inconnu au-delà de la fenêtre acceptable, ou si un disque est perdu, basculer sur la reconfiguration forcée après avoir copié le répertoire du survivant, en veillant à ce que les deux autres machines soient et restent éteintes, puis reconstruire deux nœuds neufs. Le point de bascule s'écrit à froid dans le runbook, sous forme de durée, et non pas sous pression. 2. Étapes numérotées, avec rôle, durée attendue et critère de sortie. Déclencher le plan et ouvrir le journal, directeur d'incident, cinq minutes, plan diffusé. Mobiliser porteurs et détenteurs, trente minutes, personnes en route. Obtenir le matériel du site de secours, responsable infrastructure, une heure, machines démarrées. Monter le gardien depuis sa sauvegarde et le desceller en cérémonie, quarante minutes, serveur descellé. Déchiffrer et vérifier le snapshot, vingt minutes, empreinte conforme. Monter un cluster vide sous le même seal et l'initialiser, trente minutes, trois nœuds descellés. Restaurer en forçant, quinze minutes, descellement automatique constaté. Rétablir DNS, répartiteur et sondes, responsable réseau, trente minutes, motif de santé nominal. Dérouler la liste de réaccord, une heure, liste close. Rouvrir aux applications et clore, quinze minutes, service nominal. Total cohérent avec les six heures engagées, avec la marge concentrée sur la mobilisation et le matériel. 3. Le tableau reprend les vérifications de la section 35.5 en leur associant une commande. Côté Vault : l'état, l'annuaire des pairs, la liste détaillée des montages, la liste des policies puis comparaison avec le dépôt, la liste des méthodes d'authentification, la liste des dispositifs d'audit complétée d'un événement de test à retrouver dans les deux flux, et le listage des baux pour le volume. Côté cibles : la requête d'inventaire des rôles fabriqués confrontée aux baux, un test de connexion avec un credential réputé révoqué, la relecture des dates de dernière rotation des comptes gérés. Côté clients : l'observation des réauthentifications dans l'audit, l'inventaire des certificats en service comparé au stockage de la PKI, et la confirmation applicative que le service tourne sous des credentials fraîchement émis.