Éléments de réponse aux questions de compréhension

Chapitre 36

1. Elle active la production de métriques internes et leur mise à disposition, soit par un point de collecte, soit par une expédition vers un agrégateur. Le mode engage le sens des flux : la collecte interrogative fait ouvrir une session du collecteur vers les nœuds, ce qui contredit l'invariant du chapitre 30 ; l'expédition ou l'agent local le préserve. Astrea retient l'agent local et consigne la contrepartie.

2. L'état du service, qui répond à « le nœud sert-il ». Le leadership, « qui mène et depuis quand ». Les latences de stockage, « le système souffre-t-il ». Les objets à cycle de vie, « qu'est-ce qui grossit ». Les échecs d'audit, « la traçabilité tient-elle ».

3. Parce que la valeur normale dépend du matériel, de la charge et de la taille du stockage : un seuil recopié d'une autre installation déclenche à tort ou jamais. On relève la référence sur un mois de fonctionnement sain, puis on alerte sur un écart durable.

4. Parce que l'audit est bloquant : si plus aucun dispositif ne peut écrire, Vault cesse de répondre. Un échec sur l'un des deux flux n'arrête rien, mais il consomme la marge qui sépare l'installation de l'arrêt complet.

5. Alerter sur le symptôme et diagnostiquer par la cause, pour ne pas réveiller sur des variations qui ne dégradent encore rien. Et séparer ce qui réveille de ce qui ouvre un ticket, avec les deux listes écrites au runbook. L'exception assumée concerne les alertes de prévention, échéance de certificat, espace disque ou snapshot manquant, dont l'intérêt est de précéder tout symptôme.

6. Aucun nœud actif ; un nœud descellé qui se scelle ; échec d'écriture d'un dispositif d'audit ; volume des journaux au-delà du seuil haut ; perte de quorum ; vault-transit-01 injoignable ; déchiffrement d'autounseal-core sans redémarrage correspondant. Celle de vault-transit-01 figure parmi les alertes de nuit parce qu'elle relève d'une catégorie que la supervision classique ignore : elle ne signale pas une panne de service mais la perte de la capacité à redémarrer, laquelle transforme le prochain incident bénin en immobilisation longue.

7. Le service répond-il ; qui mène et depuis quand ; le système souffre-t-il ; qu'est-ce qui grossit. La zone des échéances affiche le prochain certificat à renouveler, le dernier snapshot reçu, la dernière restauration d'épreuve et la prochaine vérification des porteurs : c'est-à-dire ce qui va bientôt surprendre.

8. Les refus, dont le volume et la répartition révèlent aussi bien une reconnaissance en cours qu'un déploiement mal configuré. Les écritures sur les chemins de pouvoir, confrontées au journal des changements attendus, pour détecter toute action hors procédure. Les accès aux secrets sensibles, avec attention aux horaires inhabituels. Ces trois-là parce qu'aucune ne déclenche de seuil : elles ne se voient que si quelqu'un regarde.

9. Quotidien de cinq minutes, hebdomadaire de vingt minutes, mensuel de deux heures, trimestriel d'une demi-journée, annuel pour les cérémonies et les exercices lourds. Leur valeur tient à ce qu'ils sont écrits, attribués et cochés, une exploitation fondée sur la vigilance individuelle s'interrompant avec les congés de la personne vigilante.

Mise en pratique du chapitre 36. 1. Aucun nœud actif : le cluster ne sert plus ; geste immédiat, vérifier le quorum depuis un nœud joignable et appliquer le runbook de perte de quorum. Nœud descellé repassé à zéro : le nœud a redémarré ou été scellé ; vérifier s'il s'agit d'une maintenance déclarée, sinon suspecter le gardien ou une action manuelle et consulter l'audit. Échec d'écriture d'un dispositif d'audit : la traçabilité a consommé sa marge ; vérifier l'espace du volume et la joignabilité du collecteur, restaurer la capacité d'écriture avant toute autre chose. Volume des journaux au seuil haut : arrêt de production imminent ; libérer de l'espace selon la procédure de rotation, sans jamais tronquer un fichier ouvert. vault-transit-01 injoignable : perte de la capacité à redémarrer ; interdire toute opération impliquant un redémarrage du core et le rétablir. Déchiffrement sans redémarrage : compromission possible de la paire fatale ; appliquer le runbook correspondant, révocation des tokens de seal comprise. Chacune renvoie à sa page de runbook et nomme son destinataire. 2. Zone de l'état : trois pastilles de santé, trois états de seal, l'état du gardien ; question, le service répond-il. Zone du leadership : nom de l'actif, durée depuis la dernière élection, compteur sur trente jours ; question, qui mène et est-ce stable. Zone de la charge : requêtes par seconde, latences de requête et de stockage avec la référence en pointillé ; question, souffre-t-on. Zone des volumes : baux, tokens, taille du stockage, volume d'audit sur trente jours ; question, qu'est-ce qui grossit. Zone des échéances : prochain certificat, dernier snapshot, dernière restauration d'épreuve, prochaine vérification des porteurs ; question, qu'est-ce qui va nous surprendre. 3. Établir d'abord que l'écart est réel et localisé, en comparant les trois nœuds sur la même fenêtre : une dérive commune oriente vers la charge, une dérive isolée vers la machine. Hypothèse matérielle : contrôler l'état du disque, ses propres métriques et le voisinage sur l'hyperviseur, qui explique une bonne part des ralentissements isolés. Hypothèse de volume : vérifier la taille du stockage et le nombre de baux, une base qui grossit ralentissant les écritures. Hypothèse de configuration : comparer les paramètres du nœud aux deux autres après la dernière intervention de la gestion de configuration. Décision : si la cause est matérielle, planifier le remplacement par la procédure ordinaire, sans urgence puisque le service n'est pas dégradé ; si elle est volumétrique, traiter la cause et non le symptôme ; si rien n'explique l'écart, retirer le nœud du cluster avant qu'il ne devienne l'actif, ce qui transformerait une dérive discrète en dégradation générale.

Chapitre 37

1. Les notes de version, les avis de sécurité et les canaux d'écosystème. Les quatre filtres : la version installée est-elle dans la plage visée ; l'édition est-elle concernée ; la fonctionnalité en cause est-elle activée chez nous, ce qui suppose un inventaire des montages à jour ; les conditions d'exploitation sont-elles réunies dans notre architecture, en particulier le niveau d'accès requis.

2. Parce qu'une décision non écrite est réputée n'avoir jamais été prise : six mois plus tard, personne ne sait si l'avis a été analysé et écarté ou simplement manqué. La trace protège l'organisation en audit, et elle protège l'équipe contre le refus de reconsidérer un avis lorsque le contexte change : un moteur non monté hier peut l'être demain.

3. Rester dans la plage supportée ; ne pas installer une version le jour de sa parution, sauf faille exploitée ; ne pas dépasser deux versions mineures de retard ; traiter les correctifs selon gravité et exploitabilité réelles. Dans les notes, chercher les changements de format de stockage, les dépréciations et suppressions, les changements de comportement par défaut, et les étapes obligatoires entre certaines versions.

4. Les migrations de format internes : une fois montées, les données ne sont plus comprises par la version précédente, donc la rétrogradation par simple retour de binaire échoue. Le plan de retour repose alors sur la restauration d'un snapshot antérieur sur une installation à l'ancienne version, procédure lourde qui justifie la sauvegarde préalable et le choix de la fenêtre.

5. Parce que l'un doit rester stable pendant que l'autre bouge : les mettre à jour ensemble expose à perdre simultanément le service et la capacité de le redémarrer.

6. Par exemple : keyring, annuel ; recovery keys, sur départ ou soupçon et revue annuelle ; tokens de seal, trimestriel ; certificats des nœuds, automatique à sept jours de l'échéance ; clé Transit applicative, trimestriel avec rewrap puis plancher ; comptes racines des moteurs, semestriel et sur soupçon. Le piège de la clé de sauvegarde : les snapshots déjà produits restent chiffrés par l'ancienne clé, dont la partie privée doit être conservée jusqu'à la fin de la rétention.

7. Parce que l'enveloppe de la clé racine a été produite par une version donnée de la clé d'enveloppe : relever le plancher au-dessus rendrait l'enveloppe indéchiffrable, et le prochain redémarrage échouerait définitivement. La sécurité de cette clé passe par son contrôle d'accès, pas par sa rotation.

8. Au trimestre, revue KV, revue anti-dérive, exercice sur table, rotation des tokens de seal. À l'année, vérification des porteurs et cérémonie à blanc, exercice de reprise complet, révision du modèle de menaces, relecture du dossier, revue du tableau des rotations. Une revue qui a eu lieu laisse des lignes de registre et, en cas d'écart, des tickets avec propriétaire et date.

9. Un objet : suppression selon le cycle de son moteur, révocation des dépendances, retrait du dépôt ; piège, la policy orpheline réutilisée par facilité. Un moteur ou une méthode : inventaire des dépendances, révocation des baux, désactivation qui détruit la vue de stockage, mise à jour de la matrice ; piège, la désactivation d'une méthode révoque les tokens qu'elle avait émis. Un cluster : le sujet est le sort des copies, décidé élément par élément entre garde et destruction attestée ; piège, croire que l'extinction des machines clôt l'affaire, alors que les secrets encore en usage doivent être migrés ou tournés.

Mise en pratique du chapitre 37. 1. Informations à collecter : identifiant de l'avis, versions affectées et version corrigée, éditions concernées, composant en cause, vecteur et prérequis d'exploitation, existence d'un contournement. Filtres et sources : la version par l'état du serveur et l'inventaire du parc ; l'édition par la licence ; la fonctionnalité par la liste des montages et des méthodes, jamais de mémoire ; les conditions par la matrice de flux et les policies réellement accordées. Trois niveaux de réponse : fenêtre d'urgence sous vingt-quatre heures si la vulnérabilité est exploitable dans notre configuration avec un privilège que nous accordons réellement, ou si un contournement dégraderait le service ; fenêtre planifiée sous deux semaines si l'exploitation exige des conditions que notre architecture rend improbables ; intégration au cycle normal si le composant n'est pas monté ou l'édition non concernée, la ligne de registre précisant alors ce qui rendrait l'avis pertinent. 2. Une répartition possible. Premier trimestre : revue trimestrielle et rotation des tokens de seal, puis rotation de la clé Transit avec rewrap et plancher, puis rotation semestrielle des comptes racines après vérification des comptes de secours, avec l'exercice sur table. Deuxième trimestre : revue trimestrielle et tokens de seal, vérification annuelle des porteurs et cérémonie à blanc mobilisant les cinq porteurs, puis rotation annuelle du keyring, opération courte et sans quorum. Troisième trimestre : revue trimestrielle et tokens de seal, exercice de reprise complet placé en période creuse avec porteurs et détenteurs de la clé, puis rotation semestrielle des comptes racines et rotation annuelle de la clé de sauvegarde, l'ancienne partie privée étant conservée. Quatrième trimestre : revue trimestrielle, tokens de seal, révision du modèle de menaces, relecture du dossier et du tableau des rotations, rotation trimestrielle de la clé Transit, puis gel des changements en fin d'année. Les cérémonies exigeant plusieurs personnes sont placées hors des périodes de congés, et deux opérations mobilisant les mêmes détenteurs ne tombent jamais le même mois. 3. Plan de décommissionnement. Inventorier les consommateurs et les secrets encore en usage, par montage, avec leur propriétaire. Décider pour chacun entre migration et rotation avec abandon, en sachant qu'un secret non tourné reste connu de l'ancien système. Migrer par vagues, en gardant Vault en service, chaque vague se terminant par la vérification qu'aucune lecture n'arrive plus sur le montage concerné, l'audit fournissant la preuve. Désactiver les montages vidés, révoquer les baux, retirer les méthodes d'authentification. Prendre un snapshot final, marqué comme tel, et arrêter le service. Traiter les copies selon l'inventaire par époque, snapshots du dépôt et hors site, disques des nœuds, sauvegarde et disque du gardien, parts, recovery keys, clé de sauvegarde, chacun soit sous garde conditionnée, soit détruit de façon attestée. Mettre à jour la matrice, le dossier et le modèle de menaces, puis clore au registre. Les deux points qui exigent une décision de direction : la durée de conservation du snapshot final et des parts nécessaires à son exploitation, qui engage une obligation de garde parfois longue ; et le sort des secrets non migrés mais encore valides chez leurs cibles, dont la rotation représente un chantier applicatif que quelqu'un doit financer.