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

Chapitre 20

1. Desceller : remettre la clé racine en mémoire, reconstruite du quorum ou déchiffrée par le gardien, ce qui permet de déchiffrer le keyring puis les données. Sceller : effacer cette clé de la mémoire. Ce qui ne bouge jamais est le stockage, chiffré avant, pendant et après. Seul l'état de la mémoire change.

2. Répondre sur le point de santé avec le code dédié, lire l'état de scellement sans authentification, et saisir des parts. Ces exceptions existent parce qu'il faut pouvoir diagnostiquer et rouvrir un serveur dont plus rien d'autre n'est lisible : les tokens eux-mêmes sont derrière la barrière.

3. Le nonce identifie la tentative en cours : les saisies d'un cycle ne valent pas pour un autre. La progression compte les parts valides déjà saisies, côté serveur. La réinitialisation est le bon geste dès qu'un doute existe : progression à zéro, nouveau nonce, recomptage propre. On ne devine jamais l'état d'une cérémonie.

4. Les cas : soupçon de compromission du processus ou de l'hôte, pour priver l'attaquant en mémoire de la clé racine ; menace physique ou juridique imminente, pour ne remettre qu'un coffre fermé. Le coût est l'arrêt immédiat de tout ce qui dépend de Vault, avec retour sous cérémonie. L'asymétrie : sceller est rapide et accessible à l'astreinte, desceller exige le quorum.

5. Le maître de cérémonie ouvre la session et détient le mot de passe à usage unique, les porteurs saisissent leurs parts, l'audit trace chaque étape. Le serveur ne produit qu'un token encodé : l'écran du quorum ne montre rien d'utilisable seul, et le mot de passe seul non plus. Le token ne naît qu'au décodage, dans les mains qui réunissent les deux. L'audit retient ouverture, saisies et complétion, sans oublier les tentatives annulées.

6. Parce qu'une procédure de crise jamais exécutée n'existe pas. L'exercice annuel vérifie les parts, les canaux, les rôles et le runbook à froid. Il se clôt comme au chapitre 8 : le token fait sa tâche, meurt par révocation, et le registre consigne motif, durée et révocation.

7. Chaque redémarrage exige le quorum : fenêtres calées sur les agendas des porteurs, correctifs urgents qui attendent, astreinte des porteurs devenue critique, disponibilité de la production suspendue à des humains. C'est un choix, le prix de « aucune machine seule ne peut ouvrir », qui se rediscute quand l'infrastructure mûrit.

8. Le scellement protège le vivant, la mémoire du processus et le service, en retirant la clé racine à un attaquant présent. La garde des parts protège le mort, toute copie du stockage où qu'elle soit. La confusion type est de croire qu'un scellement d'aujourd'hui protège un disque volé hier.

Mise en pratique du chapitre 20. 1. Déclencheurs : redémarrage planifié, crash, scellement d'urgence levé. Rôles : un maître de cérémonie qui conduit, vérifie et consigne, trois porteurs joignables issus de la rotation, un témoin si la cérémonie est sensible. Canal : pont d'appel nommé, saisies depuis les postes nominatifs, les parts ne se dictant pas et ne se collant pas dans une messagerie. Étapes : constat de l'état scellé et relevé du nonce, annonce du nonce aux porteurs, saisies une à une avec contrôle de progression, vérification du descellement puis du point de santé, relance des consommateurs, ligne de registre. Incidents probables : une part refusée, qui appelle une réinitialisation et un recomptage plutôt qu'un acharnement ; un porteur injoignable, que le quatrième de la rotation remplace, ce qui est la raison du dimensionnement. 2. Sceller : policy d'astreinte portant la capability de chemin protégé, avec plusieurs détenteurs. Desceller : les porteurs de parts, hors policy, le quorum étant le mécanisme. Ouvrir une cérémonie de régénération : le maître de cérémonie, la gouvernance étant procédurale puisque c'est le quorum qui autorise la suite. Le mot de passe à usage unique : le maître de cérémonie seul, jamais dans le même canal que le token encodé. 3. Ordre du jour : rappel de doctrine, cérémonie complète, usage à blanc limité à une consultation du token, révocation immédiate devant témoin, revue des enveloppes et des clés publiques des porteurs, mise à jour du runbook si un grain a accroché. Artefacts : attestation signée, ligne de registre, tickets de correction éventuels. Critères : token créé en moins de vingt minutes, révoqué en séance, aucune copie du mot de passe ni du token encodé hors des mains prévues. L'exercice prouve la capacité sans jamais laisser vivre le pouvoir.

Chapitre 21

1. Pour un seuil t, le secret est le terme constant d'un polynôme de degré t moins un, et chaque part est un point de la courbe. t points déterminent le polynôme, donc reconstruisent le secret. t moins un points laissent le terme constant indéterminé, toutes les valeurs restant équiprobables. La garantie est informationnelle : sous le seuil, il n'y a pas un problème difficile, il n'y a rien.

2. Parce qu'un point de courbe ne contient aucune fraction du terme constant, contrairement à un tronçon de mot de passe qui réduit l'espace de recherche. La reconstruction a lieu dans la mémoire du serveur, au descellement : les porteurs saisissent leurs points, le secret assemblé ne s'affiche jamais, et ils ne connaissent pas la clé racine.

3. t est le seuil de collusion : combien doivent s'entendre, ou être compromis ensemble, pour desceller ou lire une copie du stockage. n moins t est la tolérance aux pertes. Un seuil égal au nombre de parts met la tolérance à zéro : une enveloppe perdue, et le prochain redémarrage est impossible pour toujours, sans aucun recours.

4. Chaque part naît chiffrée pour la clé publique de son porteur : elle n'existe en clair ni dans le terminal, ni dans l'historique, ni sur le serveur. Les trois artefacts sont les parts distribuées par canaux nominatifs, l'attestation avec ses signatures, et la ligne de registre qui ouvre l'histoire du quorum.

5. Le rotate change les clés du keyring, qui chiffrent les données. Le rekey change la protection de la clé racine, donc la garde du verrou, et exige le quorum existant. Déclencheurs légitimes : départ d'un porteur, soupçon d'exposition, renouvellement périodique, changement de dimensionnement.

6. Le rekey ne périme pas les copies passées : toute copie antérieure reste protégée par la clé racine de son époque, que l'ancien quorum sait reconstruire. Conséquences : le départ d'un porteur interroge les sauvegardes contemporaines de ses parts ; le registre tient l'historique des époques ; et sauvegardes et matériel de scellement se séparent, leur réunion rouvrant le coffre de leur époque.

7. Chaque porteur prouve l'accès à sa part sans la révéler : enveloppe intacte au coffre, déchiffrement fonctionnel hors ligne, clé publique prête pour le prochain rekey. Sans le « sans la révéler », la vérification détruirait ce qu'elle vérifie. Et sans exécution réelle, elle ne prouve rien : c'est là qu'on découvre les cartes expirées et les phrases oubliées.

8. Parce que le seuil compte des personnes, pas des enveloppes. Trois porteurs du même service, du même site ou du même déplacement ramènent la collusion ou l'accident sous le seuil nominal. La composition fait partie du dimensionnement et se revoit comme une décision de gouvernance.

Mise en pratique du chapitre 21. 1. Startup de huit personnes : 3/2, trois porteurs aux rôles distincts, un tiers de confiance externe si possible. Un dimensionnement plus large mobiliserait plus de la moitié de l'effectif, et 2/2 serait un double point de défaillance. Banque à trois sites : 7/4, au moins deux porteurs par site pour qu'aucun site seul ne réunisse le quorum, tolérance de trois pertes, attestations intégrées au contrôle interne. Astrea : 5/3, collusion à trois hors d'un seul bureau, deux pertes absorbables, porteurs répartis entre technique, direction et conformité. 2. Champs : date et lieu ; type et motif ; paramètres avant et après ; identité des rôles, porteurs entrants et sortants compris ; empreintes des clés publiques utilisées, preuve que chaque part est née pour la bonne personne ; sort des anciennes parts ; références des lignes de registre et des sauvegardes d'époque examinées ; signatures de tous les présents. Chaque champ répond à une question d'audit future : qui pouvait ouvrir, depuis quand, sur quelle preuve. 3. Vendredi soir, évaluation : une part volée est inerte seule, donc pas d'ouverture possible et pas de panique, mais une part est réputée exposée. Décisions immédiates : geler toute cérémonie non indispensable, vérifier la joignabilité des autres porteurs. Week-end : préparation du rekey, nouvelle clé publique pour le porteur, convocation. Lundi : cérémonie, anciennes parts détruites devant témoin, attestation. Mardi : examen des sauvegardes d'époque, toute copie antérieure restant théoriquement ouvrable par l'ancienne génération dont un point court dans la nature ; pour chaque copie, destruction selon rétention ou consignation du risque résiduel, le voleur devant encore réunir deux autres anciennes parts et une copie du stockage. Communication au registre et à la RSSI, et la leçon pour le prochain exercice : la mallette n'était pas la doctrine de garde.

Chapitre 22

1. La garde de la clé racine : au lieu d'être partagée en points, elle est chiffrée par une clé externe et rangée enveloppée ; au démarrage, le gardien la déchiffre. Ne changent pas la barrière, le keyring, les données ni les tokens. Le stockage volé reste un bloc chiffré, et seule la réponse à « qui fait renaître la clé racine » change.

2. Par la politique d'accès de la clé du gardien : quiconque peut faire exécuter un déchiffrement par cette clé peut faire renaître la clé racine. La formulation résume le modèle : le quorum n'a pas disparu, il est devenu une politique chez un tiers. Analyser l'Auto Unseal, c'est analyser cette politique.

3. Parce que le fichier de configuration hébergerait en clair le secret d'accès au gardien de tous les autres, soit le chapitre 1 recommencé au pire endroit. Le processus prend ses identités dans son environnement d'exécution. Une clé bien née est dédiée à ce Vault, avec une politique d'accès minimale et nominative, un délai de suppression et des verrous activés, et des alertes sur toute modification.

4. Elles ouvrent une cérémonie de régénération, se rekeyent elles-mêmes, et autorisent les migrations de seal. Elles ne descellent pas : la clé racine est gardée intégralement par le gardien. Si celui-ci est indisponible ou sa clé détruite, aucune réunion de recovery keys ne rouvre quoi que ce soit ; la réponse est la restauration du gardien ou la migration.

5. Le pouvoir de redémarrer, devenu mécanique et délégué au gardien, et le pouvoir d'autoriser l'exceptionnel, resté humain et porté par les recovery keys. Shamir confiait les deux aux mêmes parts ; l'Auto Unseal les sépare, et chacun se gouverne selon sa nature.

6. Le scellement ne tient plus que jusqu'au redémarrage : il coupe l'instant, il n'est plus un état stable. Le vrai levier est de suspendre la clé du gardien ou de retirer le droit de déchiffrer, hors de Vault. Au registre : qui peut tirer ce levier, par quel geste, en combien de temps, la nuit.

7. Aller : sauvegarde, strophe ajoutée, redémarrage, quorum des parts avec l'indicateur de migration ; la clé racine est ré-enveloppée et les parts deviennent recovery keys. Retour : directive de désactivation sur la strophe, l'ancien gardien restant joignable pour déchiffrer une dernière fois, redémarrage, quorum des recovery keys avec l'indicateur. Celui-ci marque chaque saisie comme contribution à la migration ; sans lui, rien ne migre.

8. L'édition Enterprise offre le seal adossé à un module matériel et, dans ses versions récentes, plusieurs seals en haute disponibilité. En édition Community, le gardien est unique et sa disponibilité se traite par l'architecture : gardien minimal, supervisé, sauvegardé, avec un ordre de reprise écrit.

Mise en pratique du chapitre 22. 1. Redémarrer descellé : sous Shamir, trois porteurs sur cinq ; sous seal externe, l'identité machine du serveur, et de fait quiconque contrôle cette identité ou la politique de la clé. Autoriser une régénération : le quorum des parts, puis celui des recovery keys, inchangé dans l'esprit. Empêcher tout redémarrage : sous Shamir, les porteurs en refusant de saisir ; sous seal externe, quiconque peut suspendre la clé ou retirer le droit de déchiffrer, c'est-à-dire l'astreinte et le fournisseur et un attaquant de la console d'administration. Détruire définitivement le stockage : perdre trop de parts, ou supprimer la clé, d'où délais et verrous ; dans les deux cas, la perte simultanée des sauvegardes reste requise. La ligne « fournisseur » de chaque case est exactement ce que la souveraineté d'Astrea refuse. 2. Aller : annonce de fenêtre, sauvegarde à froid consignée, contrôle de joignabilité et de droits sur le gardien, strophe déployée, redémarrage, cérémonie avec l'indicateur, vérification du type et de l'état, redémarrage à blanc dans la fenêtre, lignes de registre et notification des porteurs. Critères d'abandon : gardien injoignable, deux échecs de cérémonie inexpliqués, ou dérive de fenêtre ; retour à la configuration antérieure et re-planification. Retour : symétrique, avec l'ancien gardien joignable jusqu'à la fin. 3. Serveur en marche : aucun impact, la clé racine étant en mémoire et le gardien ne servant qu'au démarrage. Redémarrage planifié : à reporter, il aboutirait à un serveur scellé indéfiniment ; si le correctif est critique, accepter l'immobilisation en connaissance et préparer la communication. Cérémonie de régénération : maintenable, puisqu'elle repose sur les recovery keys et le serveur descellé. Décision générale : geler tout ce qui éteint le processus jusqu'au rétablissement, et consigner l'épisode pour le dossier de dépendance de redémarrage.

Chapitre 23

1. La clé racine du core est enveloppée par une clé Transit hébergée sur un second Vault ; au démarrage, le core fait déchiffrer l'enveloppe. C'est la grammaire de l'Auto Unseal, gardien remplacé. La souveraineté est satisfaite parce que le gardien est dans la juridiction, sur le matériel, sous l'audit et les policies d'Astrea.

2. Le descelleur reste sous Shamir : le quorum ne disparaît pas, il déménage sur une machine conçue pour ne presque jamais redémarrer. Le gain : le core, qui redémarre souvent, n'exige plus personne, tandis que le descelleur mobilise sa cérémonie quelques fois l'an, à froid. Après une coupure générale : cérémonie sur le descelleur d'abord, puis le core seul.

3. La clé garde les défauts du chapitre 16, non exportable et non supprimable. La policy tient en deux chemins sur la seule clé, de sorte que la fuite du token de seal est bornée. Le token est orphelin, donc il ne meurt pas avec un parent, et périodique, donc le processus vivant l'entretient indéfiniment ; sa mort par arrêt prolongé a une réparation d'une ligne au runbook.

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

5. Que le serveur qui répond est bien le descelleur, certificat validé contre l'autorité attendue. Sans cette vérification, un interposé pourrait se présenter comme gardien. Le core doit authentifier le descelleur comme les clients authentifient le core.

6. Acte un, redémarrage à blanc : le cas nominal fonctionne, sans aucune saisie. Acte deux, test d'échec, descelleur coupé : le core redémarre scellé, ce qui prouve que le seal est bien celui qu'on croit et qu'il n'existe pas de chemin caché. Acte trois, retour nominal : le montage se rétablit seul.

7. La copie du stockage du core réunie à un accès de déchiffrement à la clé d'enveloppe. Séparations exigées : machines et zones réseau distinctes, sauvegardes et coffres distincts, et, le point que les dossiers oublient, des domaines d'administration distincts. L'hyperviseur ou l'administrateur unique des deux serveurs est la paire réunie en une personne.

8. Sur le descelleur : le sceller, ou révoquer le token de seal. Cela gèle tout redémarrage du core et laisse intact le core en marche, dont la clé racine est en mémoire. Au plan de réponse : détenteurs, geste exact, délai, et le coût explicite, un core arrêté ne revenant plus sans décision de lever le gel.

9. La supervision double avec une catégorie neuve, l'alerte de capacité à redémarrer. Les sauvegardes séparées, chacune avec ses parts et ses coffres. Les mises à jour en quinconce, jamais les deux serveurs dans la même fenêtre. Et le test trimestriel de redémarrage à blanc, preuve périodique que l'étape 3 tient.

Mise en pratique du chapitre 23. 1. Runbook de reprise générale : vérifier alimentation et réseau de la zone d'administration ; démarrer le descelleur et constater qu'il est scellé ; conduire sa cérémonie et vérifier son point de santé ; démarrer le core et constater le descellement automatique ; relancer les consommateurs selon leur ordre propre ; consigner. Les deux pièges d'ordre : démarrer le core en premier, où il reste scellé pendant que l'équipe diagnostique une panne inexistante, ce qui justifie que le descelleur figure en gras à l'étape deux ; et relancer les consommateurs avant le core descellé, ce qui produit une cascade d'échecs applicatifs brouillant le tableau. 2. Réparation : sur le descelleur, générer un nouveau token orphelin et périodique portant la policy de seal ; reporter la valeur dans la strophe du core, fichier en permissions strictes, différence relue à deux ; démarrer le core et constater le descellement ; révoquer l'ancien token par son accessor s'il subsiste ; consigner. Mesure de calendrier : inscrire la rotation du token à l'exploitation, par exemple à chaque test trimestriel, ce qui fait deux vérifications en une, et mentionner explicitement la régénération dans le runbook d'arrêt prolongé. 3. Paires suffisantes et séparations : stockage du core plus clé d'enveloppe, séparés par zones, machines et administrations distinctes. Stockage du core plus quorum des recovery keys : non, les recovery keys ne descellant ni ne déchiffrant rien, elles n'entrent dans aucune paire suffisante, et c'est la bonne réponse à l'auditeur. Sauvegarde du core plus clé d'enveloppe : même paire que la première, d'où des sauvegardes dans un troisième lieu. Stockage du descelleur plus son quorum : cela ouvre le descelleur, donc la clé d'enveloppe, et combiné à une copie du core, c'est la chaîne complète, d'où des parts et des sauvegardes sous garde propre. Conclusion pour l'auditeur : aucune machine, aucune personne, aucun lieu ne réunit à lui seul une paire suffisante, et le registre nomme, pour chaque élément, sa garde et sa séparation.