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

Chapitre 14

1. Un moteur est un montage qui traduit les opérations d'API de ses sous-chemins en logique de service : stocker, chiffrer, signer, créer des comptes. S'appliquent uniformément la vue de stockage isolée, la gouvernance par policies ordinaires, et le cycle de requête avec son audit. Apprendre un moteur, c'est apprendre ses chemins.

2. La vue de stockage entière du montage : secrets, versions, configuration, et la révocation de ce qui en dépendait. Précautions : inventaire des dépendances, sauvegarde si besoin, décision écrite. C'est une destruction de domaine, pas un démontage réversible.

3. Parce que le montage est indisponible pendant l'opération et, surtout, parce que rien ne réécrit ce qui pointait l'ancien chemin. Policies, configurations clientes et scripts échouent à la seconde. L'opération ne déplace que le montage et ses données : la mise à jour de l'écosystème d'autorisation reste à votre charge.

4. Un objet de gestion attaché à un secret produit : identifiant, durée, caractère renouvelable. Il matérialise un prêt, le secret restant sous contrôle de Vault après sa remise. À l'échéance ou à la révocation, le gestionnaire d'expiration exécute la logique du moteur : supprimer le compte créé, invalider ce qui doit l'être.

5. Parce que lire une valeur KV remet une copie sans contrat de retour : le moteur conserve, il ne prête pas. C'est la définition du statique. Conséquence de conception : un secret statique lu est donné pour toujours, et c'est la limite que la partie VI dépasse.

6. Le système propose, avec 768 heures par défaut. Le montage encadre par son réglage. Le rôle ou la requête précise, en réduisant seulement. L'écrêtage est muet : demander au-delà du plafond ne produit pas d'erreur mais une durée tronquée, d'où la racine PKI « dix ans » servie pour trente-deux jours si le montage n'a pas été réglé.

7. Légitime en réponse à incident sur un domaine, par exemple une base compromise dont on coupe d'un geste tous les credentials. Coût assumé : tous les consommateurs légitimes tombent avec l'attaquant, d'où l'exercice à froid, périmètre et rétablissement chronométrés.

8. Un chiffrement supplémentaire des valeurs critiques d'un montage par le mécanisme de scellement lui-même, en plus de la barrière, en édition Enterprise. Le motif fréquent est d'inscrire ces données dans le périmètre d'un module certifié pour les chaînes de conformité.

9. Le réglage, des durées ou options différentes exigeant des montages distincts. Le rayon d'explosion, le montage étant l'unité de destruction et de révocation de masse. La lisibilité des droits, le premier segment disant le domaine. L'anti-modèle écarté est le montage par équipe ou par application, qui reconstitue l'étalement du chapitre 1 sans gain.

Mise en pratique du chapitre 14. 1. Confirmer l'absence de dépendances : recherche du chemin dans le dépôt de policies, dans les configurations clientes, et vérification d'activité récente dans l'audit. Annoncer la décommission. Exporter une copie si la rétention l'exige. Puis désactiver le montage, en le consignant comme une destruction, et vérifier la liste des montages ainsi que l'entrée d'audit. 2. Activer le montage avec une description explicite, puis régler les durées : plafond au maximum contractuel du fournisseur, défaut en dessous pour laisser une marge de renouvellement. Justification : le plafond de montage borne d'avance tout rôle futur. 3. Le plus dangereux est la désactivation du montage, destruction irréversible du domaine entier. Vient ensuite la révocation par préfixe, coupure immédiate mais ciblée et réparable, les consommateurs redemandant des credentials. Le moins spectaculaire et le plus durablement nocif est le relèvement du plafond à un an : aucun effet visible, mais tous les rôles futurs peuvent désormais créer des secrets longs. C'est une dégradation silencieuse de la politique de durées.

Chapitre 15

1. La configuration de montage fixe les défauts du domaine, rétention et exigence de check-and-set. Les métadonnées d'un secret y dérogent, dans les deux sens pour la rétention. Exception : l'exigence de check-and-set posée au montage s'impose partout, la dérogation locale ne pouvant pas l'assouplir, tandis que posée par secret elle ne durcit que ce secret.

2. Le propriétaire attaque le secret orphelin en donnant un interlocuteur avant tout geste. La criticité attaque la priorisation aveugle des revues. L'échéance de rotation attaque le secret éternel en donnant une date scannable. Hygiène : ces étiquettes sont visibles de tout détenteur du droit d'inventaire, donc jamais de valeur ni d'indice, et elles ne valent que tenues à jour.

3. La structure d'un secret, l'arbre de ses champs, toutes valeurs nulles, disponible depuis la version 1.10. Usage : l'outillage de conformité et d'inventaire, sous une policy qui n'a aucun droit sur les valeurs. Le contrôle sans l'exposition.

4. Les valeurs, l'existence avec les versions et les étiquettes, et la structure. Une revue de policies KV vérifie les trois : ce qu'accorde chacune, à qui, et si la structure n'a pas été distribuée par entraînement avec l'inventaire.

5. La méthode par défaut émet une requête PATCH : fusion côté serveur, capability unique, modifier un champ sans droit de lire les autres. Le repli lit, fusionne côté client et réécrit sous check-and-set : il exige lecture et écriture, donc l'appelant voit le secret entier. Règle : la méthode serveur quand la policy peut rester minimale, le repli quand les droits pleins existent de toute façon.

6. Parce que la conversion change les chemins réels de l'API. À cette seconde, toutes les policies écrites sur les chemins v1 cessent de correspondre, et tout client en API directe échoue. D'où le plan à l'envers : inventaire, réécriture des policies en trois familles, mise à jour des clients, fenêtre, conversion, tests avec refus attendus.

7. La taille, des valeurs de quelques kilooctets et pas de fichiers, la réplication et les snapshots en souffrant. Le débit d'audit, chaque lecture étant journalisée, d'où une lecture au rythme du token et non du trafic. La fraîcheur, faute de notification. Pour les tailles, l'objet vit ailleurs, chiffré, et Vault ne manipule que la clé.

8. Des politiques de rétention divergentes, la configuration étant par montage, et un cloisonnement de destruction permettant de décommissionner un domaine d'un geste. Le chacun chez soi ordinaire se fait par préfixes et policies, gratuitement. Un montage par équipe n'est pas un critère : il multiplie les vues à sauvegarder, régler et auditer sans gain.

Mise en pratique du chapitre 15. 1.

path "secret/metadata/*" {
  capabilities = ["list", "read"]
}
path "secret/subkeys/*" {
  capabilities = ["read"]
}

Rien sur les valeurs : les trois listes se produisent avec l'existence, les étiquettes et la structure. Zéro valeur lisible, c'est le critère du moindre privilège atteint. 2. Inventaire des trois policies et des deux applications, avec leurs chemins exacts. Réécriture des policies en version 2, publiées mais inertes tant que les chemins v1 servent, l'union des règles permettant de porter les deux formes pendant la transition. Mise à jour du code des deux applications, déployée derrière un commutateur. Fenêtre annoncée, conversion, bascule des applications. Tests finaux : lectures et écritures légitimes qui réussissent, énumération, et grille de refus, un token de test v1 pur devant échouer. Retrait des règles v1 après stabilisation. 3. Refus argumenté : KV réplique, snapshote et charge en mémoire chaque valeur. Deux cents mégaoctets par export dégraderaient stockage, sauvegardes et performances pour un gain de sécurité nul, la sensibilité ne se traitant pas par l'emplacement mais par le chiffrement. Les gros objets échappent en outre aux patterns du moteur. Contre-proposition : les exports restent dans le stockage de fichiers de l'équipe, chiffrés par enveloppe, une clé de données par export, l'enveloppe stockée en tête de fichier, la clé maîtresse dans Vault, et les droits découpés par acteur. KV ne conserve, au besoin, que des métadonnées d'inventaire.

Chapitre 16

1. Le renversement : les clés cessent d'être détenues par les applications, elles vivent dans Vault, et les applications détiennent un droit d'opération porté par leur token. Deux propriétés définissent le moteur : les clés ne sortent jamais, et les données ne restent jamais, Transit opérant puis oubliant.

2. Il transporte des octets arbitraires dans du JSON, à l'aller comme au retour, et ne protège rien. Deux bugs : l'oubli, qui produit des erreurs d'API ou un texte déchiffré illisible parce qu'encore encodé, et le doublage, silencieux jusqu'au jour où un autre consommateur ne décode qu'une fois.

3. Il indique la version de clé qui a chiffré. Le préfixe lie chaque chiffré à sa version, ce qui permet aux anciennes de rester déchiffrables pendant que les nouvelles chiffrent. C'est le keyring du chapitre 6 transposé au service.

4. Tourner, les nouveaux chiffrements passant à la version suivante. Re-chiffrer, chaque ancien chiffré étant réémis en dernière version. Couper, les vieilles versions ne déchiffrant plus. Dans cet ordre strict. Le re-chiffrement n'expose jamais le clair à l'appelant, d'où la propriété remarquable : un worker peut le porter sans le droit de déchiffrer et moderniser tout un parc sans en lire un octet.

5. Obtenir le couple, clé claire et clé enveloppée. Chiffrer localement le volume avec la claire. Jeter la claire. Stocker l'enveloppée avec les données. Propriétés : les données ne transitent pas par Vault, la clé maîtresse ne sort jamais, une clé par objet borne la compromission, et la rotation ne re-chiffre que des enveloppes de quelques kilooctets.

6. La dérivation crée une clé effective par contexte à partir d'une clé nommée : l'isolement cryptographique par client ou dossier sans multiplier les objets, au prix d'un contexte à gérer. Le convergent, qui l'exige, rend le chiffrement déterministe pour permettre l'égalité et l'index, et sacrifie l'indistinguabilité : un observateur voit les doublons et corrèle. Règle : une clé dédiée à l'index, décision écrite, jamais la clé générale.

7. Parce que la partie publique d'une clé asymétrique se lit dans la configuration de la clé : les vérificateurs n'ont besoin d'aucun secret, seul le droit de signer se garde. Le cas du fil rouge, signature des artefacts par la CI et vérification avant installation, adresse le risque de chaîne d'approvisionnement du chapitre 1.

8. L'export interdit par défaut : une clé exportée a quitté le périmètre et perdu la non-exfiltrabilité qui justifiait Transit. Il ne se justifie que par une interopérabilité contrainte, en exception datée, et la sauvegarde de clés relève du même régime. La suppression interdite par défaut : supprimer une clé tue toutes les données qu'elle protège, et le garde-fou impose deux gestes explicites, donc deux réflexions.

9. Il déplace la confidentialité vers la disponibilité : les données sont illisibles quand Vault ne répond pas. C'est l'argument concret de la haute disponibilité et un paramètre de conception applicative. Les sauvegardes de Vault font exception par circularité : les chiffrer avec Transit exigerait Vault pour restaurer Vault.

Mise en pratique du chapitre 16. 1. Vérifier l'état de la clé, version courante et plancher. Temps 1, tourner, puis contrôler qu'un chiffrement neuf sort bien en version suivante. Temps 2, le job de re-chiffrement parcourt le parc avec un compteur d'avancement et une vérification finale : plus aucun préfixe ancien dans les données. Critère du temps 3 : ce compte à zéro, et la période de rétention des sauvegardes applicatives examinée, une restauration ramenant des chiffrés anciens ; soit on attend, soit on sait qu'une restauration exigera de rebaisser temporairement le plancher, décision écrite. Temps 3, monter le plancher, tester qu'un vieux chiffré échoue, consigner. 2.

# application billing
path "transit/encrypt/billing-data" { capabilities = ["update"] }
path "transit/decrypt/billing-data" { capabilities = ["update"] }

# worker de migration
path "transit/rewrap/billing-data"  { capabilities = ["update"] }

# verificateur de livraisons
path "transit/verify/release-signing" { capabilities = ["update"] }

Les opérations Transit sont des écritures sur leurs chemins, d'où la capability unique. Aucun profil n'approche les chemins de gouvernance des clés ni l'export. 3.

# s'authentifier (AppRole role "backup" -- droits: datakey + rien d'autre)
TOKEN  = login(role_id, secret_id_wrappe)              # secret: token, memoire seule
DEK, DEK_WRAP = vault transit/datakey/plaintext/billing-data   # DEK claire: memoire
archive = tar(donnees)
chiffre = aes_gcm(archive, DEK)                        # chiffrement LOCAL
ecrire(fichier, en_tete=DEK_WRAP + chiffre)            # seule l'enveloppe est persistee
effacer(DEK) ; revoquer(TOKEN)                         # rien ne survit au script
# restauration (autre role, droit decrypt seul):
# DEK = vault transit/decrypt/billing-data(DEK_WRAP) ; dechiffrer localement ; effacer

Où chaque secret vit : la clé maîtresse, dans Vault, jamais sortie ; la clé de données claire, en mémoire du script, le temps du chiffrement ; l'enveloppe, sur disque, inoffensive seule ; le token, en mémoire, révoqué en sortie.

Chapitre 17

1. Il porte une clé privée qui authentifie, une durée de validité, un besoin de renouvellement et une révocation : l'inventaire complet du chapitre 1. Le wildcard violait tout à la fois : un secret unique partagé par neuf services, quasi éternel, sans inventaire de ses copies, à révocation improbable.

2. La racine est l'ancre de confiance : installée partout, longue, elle ne signe que l'intermédiaire, et la changer coûte un redéploiement de parc. L'intermédiaire fait l'émission quotidienne : exposée, donc moyenne et sacrifiable, puisque compromise, la racine la révoque et en signe une autre sans que les clients aient rien à toucher. L'objet le plus exposé n'est pas le plus précieux.

3. Parce que la durée servie est bornée par le plafond du montage, laissé à 768 heures par défaut : la génération dix ans aboutit à un certificat de trente-deux jours. En silence, parce que le dépassement s'écrête sans erreur. D'où le réflexe : régler, relire, générer.

4. Le mode interne garantit que la clé privée est générée dans le montage et jamais renvoyée, donc non exportable par construction ; seul le certificat public sort. Les URL s'inscrivent dans chaque certificat émis : instables, elles cassent la validation des chaînes et la récupération des révocations, et en changer impose de réémettre. D'où le nom de service pérenne dès le premier jour.

5. Les domaines autorisés et les sous-domaines bornent l'émission au domaine interne. L'interdiction du domaine nu écarte un nom qu'aucun service ne porte. L'interdiction du wildcard est le contrôle structurel du constat 5. L'autorisation des SAN d'adresses sert le parc. Le type et la taille de clé imposent la cryptographie plutôt que de la laisser au demandeur. Les durées fixent la politique du rôle, sous celle du montage.

6. La génération produit la clé côté Vault et la renvoie une fois : simple et outillable, mais la clé transite par la réponse. La demande de signature laisse le demandeur générer sa clé et n'envoyer qu'une demande publique : la clé n'existe jamais hors du service. Dans les deux cas, Vault ne stocke que le certificat. Règle : la demande de signature dès que le demandeur sait la produire.

7. La liste de révocation ne protège que les clients qui la téléchargent et la respectent. OCSP ne protège que ceux qui interrogent, et l'échec souple fait accepter quand le répondeur ne répond pas. Révoquer, c'est publier une information que le monde est libre d'ignorer. Conclusion : la révocation se pratique pour les clients rigoureux et la conformité, mais ne porte pas le modèle. La vraie défense est la durée courte.

8. L'entretien purge du stockage les certificats expirés au-delà d'une marge. Il est nécessaire parce que le moteur conserve chaque feuille émise, ce qui permet révocation et inventaire, et que les durées courtes en accumulent des milliers. Le renoncement au stockage sert les très hauts volumes et sacrifie la révocation et l'inventaire des feuilles : arbitrage explicite, cohérent seulement avec des durées très courtes.

9. Le multi-issuer, depuis la version 1.11, fait coexister plusieurs émetteurs dans un montage, ce qui permet la rotation des autorités sans interruption, l'ancienne servant sa liste jusqu'à extinction de ses feuilles. ACME, depuis la version 1.14, fait parler au montage le protocole standard, les clients de l'écosystème obtenant et renouvelant sans rien connaître de Vault. Le déplacement de confiance : la preuve devient la maîtrise du nom, donc la rigueur du DNS interne entre dans le modèle de menace.

Mise en pratique du chapitre 17. 1. Un rôle client se distingue par les usages et les noms : usage serveur désactivé et usage client activé, noms bornés au sous-domaine des sondes ou à une liste fermée, wildcard et domaine nu interdits comme toujours, SAN d'adresses refusés puisqu'une sonde s'authentifie par son nom, même cryptographie imposée, durées courtes assorties au cycle des sondes. La différence de fond avec le rôle de service tient à ce que le certificat prouve, une identité cliente, et non à ce qu'il sert, un point d'accès TLS. Son consommateur naturel sera la méthode cert du chapitre 10. 2. Générer la nouvelle intermédiaire dans le même montage, faire signer sa demande par la racine, installer le certificat signé. Les deux émetteurs coexistent, l'ancien restant par défaut. Vérifier la chaîne du nouveau, puis basculer l'émetteur par défaut. Les émissions passent sur la nouvelle autorité sans toucher aux rôles ni aux clients, la racine inchangée couvrant les deux. Laisser l'ancienne intermédiaire en service de liste de révocation jusqu'à expiration naturelle de sa dernière feuille, soit soixante-douze heures de traîne. Puis retirer l'ancien émetteur et consigner. Zéro interruption, zéro redéploiement de confiance. 3. Dans l'ordre. La chaîne servie incomplète : le service présente sa feuille sans l'intermédiaire ; diagnostic par inspection de la connexion TLS et vérification que le déploiement concatène bien la feuille et la chaîne reçue à l'émission. Ensuite la racine absente du magasin de confiance du client qui se plaint ; diagnostic par validation manuelle avec le certificat racine explicite : si elle passe, c'est le magasin du client. Enfin le mauvais émetteur, une feuille signée par une intermédiaire retirée ou un montage de test ; diagnostic par lecture de l'émetteur et du numéro de série, confrontés à l'inventaire d'émission, l'audit sachant qui a émis quoi.