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

Chapitre 7

1. L'empreinte prouve que le fichier téléchargé est identique à celui que décrit la liste ; elle ne dit rien de l'auteur de la liste. La signature prouve que la liste émane bien de l'éditeur : un attaquant maître du canal peut servir binaire et liste assortis, pas les signer. Le maillon restant est l'obtention de la clé publique par un canal de confiance, premier acte qui ne se délègue pas.

2. Stockage en mémoire, donc rien à desceller. Démarrage descellé, l'inverse de « l'état sûr est l'état initial ». HTTP sans TLS, la première frontière abandonnée. S'y ajoute le root token affiché et souvent exporté. Usage légitime : explorer l'API, tester une syntaxe, reproduire un comportement, sans aucune donnée réelle ni réseau partagé.

3. Adopter Raft dès le mono-nœud évite toute migration de backend le jour du cluster : les futurs nœuds rejoindront le nœud existant, données en place. node_id fixe l'identité stable du nœud dans Raft ; un identifiant qui change fait apparaître un inconnu, donc on le choisit explicitement.

4. L'adresse d'écoute est celle où le processus accepte les connexions, une interface choisie et non toutes. api_addr est l'adresse annoncée aux clients, utilisée pour les redirections en haute disponibilité. cluster_addr est celle annoncée aux autres nœuds pour le trafic de cluster : seuls les membres ont à la joindre.

5. Avec le stockage intégré, la recommandation est le couple verrouillage mémoire désactivé et échange désactivé sur l'hôte. Première incohérence, verrouillage désactivé et échange conservé : la mémoire du processus, clés comprises, peut paginer hors de la protection de la barrière. Seconde incohérence, verrouillage actif avec Raft : recommandation non suivie, pathologies d'un processus à forte empreinte, pour une protection illusoire puisque les données Raft transitent de toute façon par le disque, chiffrées.

6. Trois exemples. LimitCORE=0 traduit l'hypothèse « la mémoire ne se retrouve pas sur disque » en interdisant les vidages. ProtectSystem=full réduit ce qu'un processus compromis peut faire de l'hôte, puisqu'il ne réécrit ni binaires ni configuration. NoNewPrivileges=yes interdit toute acquisition ultérieure de privilèges, figeant le moindre privilège dans le temps.

7. Les deux font disparaître l'erreur, par des chemins opposés. VAULT_CACERT fournit l'autorité avec laquelle réussir la vérification, donc le serveur est authentifié. VAULT_SKIP_VERIFY supprime la vérification : n'importe quel serveur est accepté, y compris celui d'un intercepteur, tokens et secrets offerts. Et l'habitude prise en laboratoire migre en production.

8. 501 signale un serveur non initialisé, dont la hiérarchie de clés n'existe pas encore. Les autres codes : 200 pour un serveur actif et descellé, 429 pour un standby, 503 pour un serveur scellé. Des codes supplémentaires existent pour la réplication Enterprise. Ces codes permettent à un répartiteur de router sans lire les corps de réponse.

Mise en pratique du chapitre 7. 1. Les six défauts, par gravité décroissante. a) tls_disable = true, critique : tokens et secrets en clair sur le réseau, première frontière abandonnée. b) Lancement en session root, critique : processus root sans confinement ni supervision. c) Échange actif et aucune doctrine mémoire, élevée : la configuration ne fixe rien et l'hôte pagine. d) Écoute sur toutes les interfaces, élevée : l'API offerte aux interfaces présentes et futures. e) api_addr en schéma http sur la boucle locale, moyenne : redirections fausses dès la haute disponibilité. f) node_id et cluster_addr absents, moyenne : identité Raft non maîtrisée. 2. Corrections dans le fichier : certificat et clé, adresse d'écoute d'interface, api_addr en https:// sur le nom de service, node_id et cluster_addr. Hors du fichier : unité systemd durcie sous utilisateur dédié, et échange désactivé avec table de montage neutralisée. La répartition compte autant que la liste : deux corrections sur six ne s'écrivent pas dans le fichier, et c'est pourquoi une revue de configuration seule ne suffit jamais. 3. Les deux défauts silencieux sont l'absence de node_id et de cluster_addr. Le mono-nœud fonctionne sans eux ; ils ne se manifestent qu'au premier ajout de pair. Les fixer coûte deux lignes aujourd'hui, les découvrir en partie VIII coûte une fenêtre de maintenance sur un cluster en service.

Chapitre 8

1. L'initialisation crée la première clé du keyring, la clé racine qui chiffre ce keyring, les cinq parts qui sont les seules voies de reconstitution de cette clé racine, et le token racine initial. Vault ne conserve ni la clé racine ni aucune part, et la sortie n'est jamais re-consultable : ce qui n'a pas été recueilli à cet instant est perdu.

2. Parce que Vault ne stocke rien de ce matériel : l'affichage est l'unique remise. Implications : écran maîtrisé, remise immédiate aux détenteurs, interdiction des copies, registre daté. En production, l'option de chiffrement des parts supprime le problème en ne montrant aucun clair.

3. La première chiffre chaque part avec la clé publique de son détenteur : chacun ne lit que la sienne, et l'opérateur ne voit aucune part en clair. La seconde applique le même traitement au token racine. Elles résolvent la fragilité centrale de la cérémonie, cette fenêtre où tout le matériel s'affiche ensemble sur un écran.

4. Non initialisé, puis scellé après l'initialisation, puis descellé une fois le quorum saisi ; et retour à scellé par scellement volontaire, redémarrage ou perte du processus. Tout arrêt ramène à l'état scellé parce que la clé racine n'existe qu'en mémoire, à dessein : rien sur le disque ne permet de s'en passer.

5. Le seuil élève la confidentialité, puisqu'il faut compromettre k détenteurs indépendants, et abaisse la disponibilité, puisque chaque descellement mobilise k humains joignables. Un seuil à deux rend l'astreinte facile et le double vol suffisant ; un seuil à quatre rend le vol très difficile et transforme chaque redémarrage nocturne en chaîne téléphonique.

6. Légitime en cas de compromission suspectée : figer le coffre le temps de comprendre, en assumant l'arrêt de tout ce qui en dépend. On le pratique en laboratoire pour en mesurer le coût réel, arrêt instantané et retour au prix du quorum, avant le jour où la décision se prendra sous pression.

7. Le root token sert au bootstrap, puis il meurt. Séquence : connexion root, activation de l'audit, écriture de la policy admin, activation d'userpass et création du compte nominatif, connexion avec ce compte et vérification effective de ses droits, révocation du root token. L'audit vient en premier parce que les gestes du bootstrap sont ceux qu'une investigation voudra relire ; la vérification précède la révocation parce qu'on ne détruit le pouvoir de secours qu'après avoir prouvé le pouvoir de relève.

8. Il se régénère sous quorum des détenteurs de parts, protégé en transit par un mot à usage unique. C'est supérieur à la conservation : aucune valeur permanente n'attend son voleur, et le pouvoir exceptionnel exige exactement le même concours de personnes que la clé racine, avec une trace d'audit de chaque régénération.

9. Les parts reconstituent la clé racine : elles descellent et ne confèrent aucun droit d'API. Le root token est un pouvoir d'API total sur un serveur déjà descellé, et ne descelle rien. Les recovery keys de l'Auto Unseal forment un quorum d'autorisation et, point d'ancrage à retenir, elles ne descellent pas.

Mise en pratique du chapitre 8. 1. L'ordre correct, avec la raison de chaque position. Vérifier le binaire : rien ne se construit sur un outil non prouvé. Démarrer le service : il faut un serveur qui écoute. Initialiser : l'acte de naissance, une seule fois. Desceller : rendre le serveur opérant. Se connecter avec le root token : seul pouvoir existant à cet instant. Activer l'audit : tout ce qui suit doit laisser trace. Créer la policy admin : le pouvoir borné avant le compte qui le portera. Créer le compte nominatif, s'y connecter et vérifier ses droits : prouver le relais. Révoquer le root token : clore la fenêtre sensible. 2. a) Serveur neuf jamais initialisé : initialiser, après avoir confirmé qu'aucune donnée n'est attendue sur ce nœud. b) Descellement en cours, deux parts acceptées : saisir une troisième part valide, ou réinitialiser la progression si la procédure est douteuse. c) L'état Vault est sain ; le refus est réseau : adresse d'écoute liée à une autre interface, pare-feu, ou adresse erronée côté client. On diagnostique depuis l'hôte, puis on remonte la chaîne. 3. Refus, en trois arguments. Une valeur éternelle et sans borne dans un coffre est la cible idéale du chapitre 1 : elle n'expire pas et n'est pas révocable par oubli. Un coffre d'équipe détruit l'imputabilité, « root a agi » ne désignant personne. Et c'est inutile, puisque la régénération fournit le même pouvoir à la demande, sous quorum et avec trace.

Chapitre 9

1. Trois différences : les versions conservées à chaque écriture, la suppression douce réversible distincte de la destruction, et les métadonnées avec la rétention configurable et le check-and-set. La raison de fond : la rotation comme propriété de conception exige recouvrement, retour arrière et historique, c'est-à-dire des versions.

2. Le premier niveau est l'enveloppe standard de toute réponse de Vault, le second le conteneur des paires du secret. À côté, le bloc de métadonnées porte la version servie et ses dates, donc de quoi savoir quelle valeur on a lue, ce qui est la moitié d'une rotation propre.

3. Le premier porte les valeurs : lecture, écriture, accès à une version. Le second porte l'existence et la gestion : liste et état des versions, rétention, métadonnées personnalisées, effacement complet, et c'est lui que l'énumération parcourt. Conséquence : les policies s'écrivent sur ces deux chemins réels, jamais sur le chemin logique, qui ne correspond à aucune requête.

4. Suppression douce : la version est marquée, la lecture ne la sert plus, la restauration répare. Retrait ordinaire, réversible. Destruction : les données sont effacées, les métadonnées d'existence demeurent. Irréversible, pour les valeurs compromises. Effacement des métadonnées : tout disparaît, versions, historique, existence. Irréversible et total, pour la décommission d'un chemin.

5. Deux écrivains concurrents, et le second écrase en silence ce que le premier vient de poser. Avec le check-and-set, l'écriture est conditionnée à la version que l'on croit courante et échoue explicitement si elle a bougé ; le refoulé relit et décide. La valeur zéro signifie « n'écris que si le secret n'existe pas » : la création stricte.

6. Le retour arrière republie une ancienne version comme nouvelle version courante. L'historique reste honnête puisque le retour est lui-même une version datée ; la valeur n'est jamais ressaisie à la main, donc jamais réexposée par un canal de saisie ; et la version fautive reste identifiable pour une destruction ciblée ensuite.

7. L'application d'abord, parce que le consommateur d'un préfixe est une application : une règle de policy par application, le moindre privilège en une ligne. L'environnement ensuite, parce que la séparation production contre préproduction doit être découpable par préfixe : un rôle de préproduction ne peut alors même pas exprimer un chemin de production.

8. On change la valeur à la source : nouveau mot de passe posé côté base. On écrit cette nouvelle valeur dans Vault. On bascule l'application. L'ancienne valeur, celle de l'historique Git, cesse de fonctionner. La migrer aurait rangé une valeur compromise dans un meilleur coffre : le pouvoir volé serait resté volé.

9. KV ne renouvelle rien : ni rotation, ni bail, ni credential à la demande. C'est le statique par construction, où chaque valeur vit jusqu'à remplacement explicite. La réponse est la partie VI et son modèle dynamique, et pour PostgreSQL le moteur Database, où le secret n'existe qu'à la demande et expire seul.

Mise en pratique du chapitre 9. 1. vault kv put secret/billing/preprod/db username=billing password=- puis saisie de la valeur, ce qui ne laisse rien dans l'historique. Vérifications par une lecture complète, puis par une lecture du seul champ password. 2. Relire pour connaître la version courante dans le bloc de métadonnées, puis écrire conditionné avec -cas=<version>. Rendre la précaution obligatoire par vault kv metadata put -cas-required=true sur le chemin. 3. vault kv destroy -versions=1 rend la version 1 définitivement illisible tout en conservant la version courante et l'historique d'existence. Si le chemin entier devait disparaître, il faudrait, après s'être assuré que rien n'en dépend, effacer les métadonnées, en traitant l'opération pour ce qu'elle est : totale et sans retour.