8. Plan détaillé des parties et des chapitres

Partie I. Introduction à la gestion des secrets

Cette partie établit le problème que Vault résout, les principes qui serviront de grille d'évaluation à tout le cours, puis situe l'outil, son périmètre exact et ses limites. Aucune installation avant la fin de cette partie : l'étudiant doit d'abord savoir pourquoi l'outil existe.

Chapitre 1. Pourquoi gérer les secrets ? Objectif : faire comprendre l'ampleur réelle du problème avant toute solution. Contenu. Définition rigoureuse d'un secret ; distinction entre secret, donnée sensible et donnée chiffrée : première des confusions classiques traitées par le cours. Typologie : mots de passe, clés d'API, tokens, clés privées et certificats, chaînes de connexion, clés de chiffrement. Inventaire méthodique des lieux de fuite : code source et historique Git ; variables d'environnement (visibilité via /proc, docker inspect, vidages mémoire) ; fichiers de configuration ; pipelines CI/CD (journaux, forks, artefacts) ; images et conteneurs (layers) ; Secrets Kubernetes (base64, etcd) ; journaux applicatifs ; sauvegardes ; systèmes de monitoring et APM. Le phénomène de secret sprawl et le cycle de vie d'un secret (création, distribution, utilisation, rotation, révocation, destruction). Conséquences d'une compromission : mouvement latéral, élévation, persistance ; incidents publics analysés à titre d'illustration (fuites de clés dans des dépôts, compromissions de chaînes CI). La rotation manuelle et ses échecs prévisibles. Limites des approches traditionnelles (fichiers chiffrés ad hoc, gestionnaires de mots de passe d'équipe, secrets partagés) et le problème de « la clé qui protège les clés » : première formulation du problème du secret zéro.

Chapitre 2. Principes fondamentaux de la gestion des secrets Objectif : donner le vocabulaire et les principes qui structurent tout le reste du cours. Contenu. Confidentialité, intégrité, disponibilité appliquées aux secrets, et le conflit spécifique entre disponibilité et confidentialité que tout gestionnaire de secrets doit arbitrer. Identité, authentification, autorisation : premier passage, formalisé au chapitre 10. Moindre privilège et besoin d'en connaître. Rotation et révocation comme propriétés de conception, non comme corvées d'exploitation. Traçabilité et audit. Séparation des responsabilités et cérémonies à quorum. Défense en profondeur. Zero Trust : l'accès fondé sur l'identité plutôt que sur la position réseau. La notion de racine de confiance (Root of Trust), présentée ici intuitivement et formalisée en partie VII. Les credentials éphémères : l'idée qui mène aux secrets dynamiques.

Chapitre 3. Présentation de HashiCorp Vault Objectif : situer l'outil, son périmètre exact et ses limites, avant toute technique. Contenu. Historique et repères datés, donnés avec prudence : projet open source lancé en 2015 ; éditions Community et Enterprise ; offre managée HCP Vault ; changement de licence (BSL) annoncé en 2023 et fork communautaire OpenBao ; rachat de HashiCorp par IBM finalisé en 2025. Objectifs de conception : API d'abord, « tout est chemin », sécurité par défaut. Grands cas d'usage : coffre central, credentials dynamiques, chiffrement comme service, PKI interne, identité machine. Survol de l'architecture et carte des termes (server, client, mount, path, secrets engine, auth method, policy, token, lease, seal, audit device). Ce que Vault est. Ce que Vault n'est pas : pas un HSM, pas un gestionnaire de mots de passe grand public, pas un IAM complet, pas une solution DLP, et surtout, Vault ne protège pas un secret après sa livraison au client, point capital pour tout le raisonnement de sécurité ultérieur. Positionnement face aux alternatives (AWS Secrets Manager et Parameter Store, Azure Key Vault, GCP Secret Manager, SOPS, sealed-secrets, Secrets Kubernetes natifs) et analyse honnête des cas où Vault est une solution disproportionnée.

Partie II. Fondamentaux techniques

Cette partie construit le modèle mental complet avant toute installation : comment Vault est architecturé, ce que son modèle de sécurité promet exactement, et comment son modèle cryptographique fonctionne. Le chapitre 6 est le prérequis direct de la partie VII.

Chapitre 4. Architecture générale de Vault Contenu. Le serveur Vault et son API HTTP ; la CLI et l'UI comme simples clients de cette API. Le cycle de vie complet d'une requête : listener, vérification du token, évaluation des policies, routage vers le moteur concerné, réponse, journalisation d'audit. La table des montages (mount table) et le principe « tout est chemin ». La barrière cryptographique (barrier) : la frontière entre le cœur de Vault et son stockage. Le stockage comme backend interchangeable et non digne de confiance. Le seal : rôle et position dans l'architecture. Auth methods et secrets engines comme plugins montés. Le magasin de tokens. L'expiration manager et les leases (première rencontre, formalisée au chapitre 18). Les audit devices. Le système de plugins. Le chapitre se conclut par le schéma d'ensemble des composants et de leurs relations, réutilisé ensuite dans tout le cours.

Chapitre 5. Le modèle de sécurité de Vault Contenu. Le modèle de menace documenté par HashiCorp : ce contre quoi Vault protège, ce contre quoi il ne protège pas. Les frontières de confiance : client-serveur (TLS), serveur-stockage (barrière), et le processus serveur avec sa mémoire comme zone de confiance ultime. Conséquence assumée du modèle : un attaquant root sur l'hôte Vault est hors modèle ; analyse détaillée de ce que cela implique pour la conception (durcissement de l'hôte, minimisation des accès, détection). Données au repos, en transit, en cours d'utilisation. Première présentation de la hiérarchie des clés (clé de chiffrement, clé racine, mécanisme de scellement), approfondie en partie VII. Profils d'attaquants étudiés un à un : externe, interne, client compromis, hôte compromis, réseau compromis ; pour chacun : ce qu'il voit, ce qu'il peut faire, ce qui l'arrête. Hypothèses opérationnelles du modèle : verrouillage mémoire (mlock) et interdiction du swap, horloge fiable, système d'exploitation durci.

Chapitre 6. Cryptographie appliquée à Vault Contenu. Rappels ciblés, limités à ce dont le cours a besoin : chiffrement symétrique (AES-GCM, rôle du nonce et de l'authentification du chiffrement) ; chiffrement asymétrique (RSA, ECDSA, Ed25519) ; hachage (SHA-2) ; HMAC ; signatures ; dérivation de clés. Chiffrement par enveloppe et key wrapping : pourquoi on chiffre des clés avec des clés. Application à Vault : la barrière et son keyring (chiffrement AES-256-GCM du stockage) ; les trois niveaux à ne plus jamais confondre ; clé de chiffrement, clé racine, clé(s) de scellement. Rotation cryptographique : différence entre operator rotate (nouvelle clé de chiffrement dans le keyring) et operator rekey (redistribution des parts de la clé racine), l'une des confusions les plus fréquentes chez les opérateurs. Usage de HMAC dans les journaux d'audit. Place de TLS dans l'ensemble.

Partie III. Installation et premiers déploiements

Premier contact avec l'outil, mais un contact propre : installation durcie dès le premier jour, compréhension exacte de l'initialisation et de l'unseal, premiers secrets manipulés en connaissance de cause.

Chapitre 7. Installation Contenu. Installation sur Linux par dépôt officiel et par binaire, avec vérification des sommes de contrôle et des signatures. Exécution en conteneur. Le mode -dev : à quoi il sert, pourquoi il est strictement interdit hors laboratoire [Laboratoire]. Le fichier de configuration HCL : listener, storage "raft" mono-nœud, api_addr, cluster_addr, ui. Service systemd durci : utilisateur dédié, capacités réduites, ProtectSystem, NoNewPrivileges. mlock et la capacité IPC_LOCK ; la question du swap. Permissions des fichiers et des répertoires. Ouverture réseau : 8200 (API) et 8201 (cluster). TLS dès le départ : certificat auto-signé de laboratoire, et énoncé du problème d'amorçage du certificat, résolu proprement au chapitre 28. Déclenche le TP 1.

Chapitre 8. Premier démarrage : initialisation, seal et unseal Contenu. Ce que fait exactement vault operator init : génération de la clé racine, découpage en parts par Shamir (nombre de parts et seuil), création de la clé de chiffrement, écriture initiale dans le stockage, émission du root token. Lecture détaillée de vault status. L'état sealed : ce qui est possible et ce qui ne l'est pas. L'unseal pas à pas : reconstruction de la clé racine en mémoire, déchiffrement du keyring. La nature exacte du root token, pourquoi et quand le révoquer. L'option PGP pour la remise des parts. Le scellement volontaire (vault operator seal) comme réflexe d'urgence : première rencontre, développée au chapitre 31. Bonnes pratiques de conservation des parts, détaillées au chapitre 21. Déclenche le TP 2.

Chapitre 9. Premiers secrets : le moteur KV Contenu. KV v1 et KV v2 : versionnage, métadonnées, et les chemins internes data/ et metadata/ ; préparation du piège de policies traité au chapitre 11. Création, lecture, mise à jour, suppression. Versions : restauration, soft delete, undelete, destroy, suppression des métadonnées. Check-and-set (cas) et écritures concurrentes. Ce que la CLI masque par rapport à l'API. Ce que KV doit contenir, et ce qu'il ne doit pas contenir. Déclenche le TP 3.

Partie IV. Authentification et autorisation

Le contrôle d'accès est le cœur de Vault. Cette partie construit la chaîne complète : une identité prouve qui elle est (chapitre 10), reçoit des droits (chapitre 11) matérialisés par un token (chapitre 12), le tout unifié par la couche Identity (chapitre 13).

Chapitre 10. Authentification Contenu. Définitions rigoureuses et distinctions : identité, authentification, autorisation, session, token. Le flux de login : l'échange de preuves contre un token. Les montages d'authentification et les chemins auth/. Étude méthodique des méthodes : pour chacune : fonctionnement, architecture, cas d'utilisation, avantages, inconvénients, risques, recommandations : - Token : la méthode primitive sous-jacente à toutes les autres ; - Userpass : laboratoire et dépannage, limites assumées ; - AppRole, traité en profondeur : role_id et secret_id, TTL et num_uses du secret_id, contraintes CIDR, modes de livraison push et pull, le problème du secret zéro et ses réponses (orchestrateur de confiance, response wrapping ; mécanisme détaillé au chapitre 12) ; - LDAP : annuaire d'entreprise ; - OIDC : les humains, le SSO ; - JWT : les machines et la fédération, dont la CI ; - Kubernetes : TokenReview, comptes de service, audiences ; - méthodes cloud (AWS IAM et EC2, Azure, GCP) : l'identité de plateforme comme solution structurelle au secret zéro. Le chapitre couvre également Login MFA (TOTP et intégrations tierces) disponible en Community (Note de version : 1.10+). OIDC est illustré par une démonstration guidée [Démonstration] avec un fournisseur d'identité de laboratoire (Keycloak), hors TP notés. Grille de choix finale : quelle méthode pour quel type de client, et pourquoi.

Chapitre 11. Policies et autorisation Contenu. Le modèle ACL : tout est refusé par défaut. Syntaxe HCL, chemins, capabilities (create, read, update, delete, list, patch, sudo, deny). Les motifs * et +. Les policies default et root. Attachement des policies : par méthode d'authentification, par rôle, par identité. Policies templatisées (paramètres d'identité). Le piège KV v2 : écrire des policies sur secret/data/ et secret/metadata/. sudo et les chemins système. deny et sa priorité absolue. Erreurs de conception classiques : wildcards trop larges, confusion entre list et read, sudo par confort, policies fourre-tout, absence de revue. Méthode de conception en moindre privilège à partir des besoins réels de l'application. Outils de vérification : vault policy fmt, vault token capabilities. Au-delà des ACL, le chapitre situe les policies Sentinel (EGP/RGP) et les control groups (Enterprise) : ce qu'ils ajoutent, et pourquoi savoir qu'ils existent éclaire les limites du modèle ACL. Déclenche le TP 4.

Chapitre 12. Tokens Contenu. Anatomie d'un token. Types service et batch (préfixes hvs. et hvb.) : comparaison complète ; persistance, renouvellement, coût, limites. Les accessors et leurs usages : révoquer et auditer sans détenir le token. TTL, max TTL, tokens périodiques pour les services long-vivants, renouvellement. Hiérarchie parent-enfant et révocation en cascade. Tokens orphelins : usages légitimes et dangers. Token roles. Restrictions CIDR. Cubbyhole et response wrapping : la livraison sûre d'un secret à usage unique ; mécanisme complet, wrapping token, unwrap, détection d'interception. Première approche de la lutte contre le token sprawl, complétée au chapitre 30. Déclenche le TP 5.

Chapitre 13. Identity : entités, alias et groupes Contenu. Pourquoi une couche d'identité au-dessus des méthodes d'authentification. Entités et alias : unifier un même acteur authentifié par plusieurs méthodes. Groupes internes et externes (mappage LDAP et OIDC). Policies portées par l'identité. Identity tokens (Vault comme fournisseur OIDC) en survol. Effets concrets sur l'audit et sur le moindre privilège. Pièges : création implicite d'entités, fusion d'alias, groupes externes non synchronisés. La partie se conclut par le TP 6 (AppRole de bout en bout, avec livraison du secret_id par response wrapping).

Partie V. Secrets Engines : fondations

Cette partie enseigne d'abord ce que tous les moteurs ont en commun, puis les trois moteurs fondateurs : KV, Transit et PKI. Transit est enseigné ici, avant la partie VII, parce qu'il est indispensable à la compréhension du Transit Seal (chapitre 23).

Chapitre 14. Anatomie d'un Secrets Engine Contenu. Montage, démontage, déplacement d'un moteur ; la table des montages et l'isolement par chemin. Tuning : default_lease_ttl, max_lease_ttl. Structure des réponses : data, lease_id, renewable. Les leases formalisés (le chapitre 18 en fera le cœur des secrets dynamiques). Options et versions de moteurs. Panorama des moteurs disponibles et critères de choix. Ce qu'un moteur écrit derrière la barrière, et ce que cela implique pour la sauvegarde. Mention du seal wrap (Enterprise) : un chiffrement supplémentaire par le mécanisme de scellement pour les données les plus sensibles d'un montage.

Chapitre 15. KV approfondi Contenu. Organisation des chemins (par application, par environnement) et conventions de nommage Astrea. Métadonnées personnalisées, delete_version_after, cas_required. Migration v1 vers v2. Sauvegarde et restauration de secrets KV. Limites et anti-patterns : secrets géants en JSON, KV utilisé là où un moteur dynamique s'impose, versionnage confondu avec une sauvegarde.

Chapitre 16. Transit : le chiffrement comme service Contenu. Le concept Encryption as a Service : l'application ne détient plus de clé. Types de clés et opérations : encrypt, decrypt, rewrap, sign, verify, hmac, datakey. Format des ciphertexts (vault:v<n>:...). Versions de clés, rotation, min_decryption_version, rewrap de masse. datakey et chiffrement d'enveloppe côté application pour les gros volumes. Chiffrement convergent et clés dérivées : usages et dangers. Exportabilité des clés, et pourquoi la refuser par défaut. Cas d'usage Astrea : chiffrement des données de facturation. Performance et disponibilité : ce qui se passe exactement quand Transit est injoignable. Le chapitre se conclut sur la question qui prépare la partie VII : pourquoi un Vault portant des clés Transit devient une racine de confiance pour tous ses clients.

Chapitre 17. PKI : Vault comme autorité de certification Contenu. Rappels X.509 : autorité, chaîne, CSR, SAN, durées de vie, révocation (CRL, OCSP). Modèles d'architecture : racine hors ligne avec intermédiaire dans Vault (recommandé), racine dans Vault (assumé et analysé). Mise en place fil rouge : pki-root/ et pki-int/, rôles d'émission, contraintes (domaines autorisés, SAN, TTL courts). Émission, renouvellement, révocation, distribution des CRL. Rotation d'autorité et multi-issuer (Note de version : 1.11+). Opérations tidy et maintenance. ACME (Note de version : 1.14+) pour l'automatisation. La philosophie des certificats à courte durée de vie plutôt que la dépendance à la révocation. Risques : compromission de clé d'autorité, TTL excessifs, rôles trop permissifs. Comparaison PKI interne et PKI publique. Déclenche le TP 7.

Partie VI. Secrets dynamiques

Le concept qui justifie Vault au-delà du simple coffre : des credentials qui n'existent pas avant la demande et cessent d'exister après usage.

Chapitre 18. Le modèle des secrets dynamiques Contenu. Définition rigoureuse ; différences avec un secret statique : existence, unicité, durée, révocabilité, imputabilité. Cycle de vie d'un lease : émission, renouvellement, expiration, révocation. L'expiration manager. Révocation en cascade : du token vers ses leases. Dimensionnement des TTL : l'arbitrage entre sécurité et charge. Modes de défaillance : backend injoignable au moment de révoquer, files de révocation, credentials orphelins. Effet sur l'investigation : un credential par instance, et ce que cela change pour l'analyse forensique. Ce que l'application doit savoir faire (renouveler, se reconnecter), préparé pour le chapitre 40.

Chapitre 19. Moteurs dynamiques : Database, Cloud, SSH et autres Chapitre volumineux par construction (la numérotation des chapitres 20 à 26 étant fixée, il ne peut pas être scindé) : il est structuré en six sous-chapitres numérotés, chacun suivant le gabarit complet ; fonctionnement, architecture, cas d'utilisation, configuration, exemple, sécurité, rotation, révocation, limites. Contenu. - 19.1 Database avec PostgreSQL (fil rouge) : configuration de connexion, rotation du credential racine (rotate-root et ses précautions ; l'opération est irréversible pour l'opérateur), rôles dynamiques (creation_statements, revocation_statements), rôles statiques (rotation de comptes existants) et différence de philosophie entre les deux ; - 19.2 AWS : iam_user, assumed_role, federation_token ; critères de choix et conséquences ; - 19.3 Azure et GCP : traitement structuré ; - 19.4 SSH : OTP et signature de certificats SSH (recommandée), signature de clés d'hôtes ; - 19.5 RabbitMQ ; - 19.6 Kubernetes (comptes de service dynamiques ; Note de version : 1.11+). Déclenche le TP 8.

Partie VII. Scellement et cryptographie avancée

Le cœur cryptographique du cours, et sa question centrale : qui garde les clés du gardien. C'est ici que se joue la notion de Root of Trust et l'essentiel des scénarios de perte définitive.

Chapitre 20. Seal et Unseal en profondeur Contenu. Reprise formelle de la hiérarchie complète : mécanisme de scellement → clé racine → keyring et clé de chiffrement → données. Ce que « sealed » signifie exactement : état du processus, endpoints accessibles, comportement des clients. Ce que l'unseal reconstruit, et où : en mémoire uniquement. Initialisation et unseal : deux opérations à ne pas confondre. Sceller volontairement : quand, comment, avec quelles conséquences. Les opérations de rotation : operator rotate (clé de chiffrement), operator rekey (parts de la clé racine ou clés de récupération), operator generate-root (recréer un root token sous quorum). Principes de la migration de seal, dont les procédures sont détaillées aux chapitres 22 et 35.

Chapitre 21. Shamir Secret Sharing Contenu. Le principe mathématique rendu accessible : polynômes et interpolation, pourquoi k-1 parts n'apprennent strictement rien. Choix raisonné des paramètres n et k. La réalité opérationnelle : cérémonie de génération, désignation des détenteurs, remise chiffrée par PGP, stockage physique (coffres, enveloppes scellées), registre des détenteurs. Le rekey : quand et comment redistribuer. Risques opérationnels : perte de parts, départ de détenteurs, collusion, indisponibilité humaine lors d'un incident nocturne ; la limite qui motive l'Auto Unseal. Ce que Shamir protège, et ce qu'il ne protège pas.

Chapitre 22. Auto Unseal : KMS et HSM Contenu. Le principe : la clé racine, chiffrée, est protégée par une clé externe qui ne quitte jamais son service. Fournisseurs : AWS KMS, Azure Key Vault, GCP Cloud KMS, OCI ; configuration type détaillée sur AWS KMS. Le HSM : rôle général, et le seal PKCS#11 (Enterprise). Le flux exact au démarrage. Les clés de récupération (recovery keys) : ce qu'elles permettent (rekey, generate-root) et surtout ce qu'elles ne permettent pas ; desceller. Le déplacement de la confiance : le fournisseur de KMS entre dans la racine de confiance ; analyse complète (qui a accès à la clé, journalisation côté fournisseur, juridiction, souveraineté). Pannes : KMS indisponible (cluster en marche contre cluster qui redémarre) ; clé KMS supprimée ou désactivée ; scénario catastrophe et garde-fous. Migrations Shamir vers Auto Unseal et retour (-migrate). Coûts et dépendances. Déclenche le TP 9 (dont la variante hors cloud sur émulateur KMS local, décrite en section 11).

Chapitre 23. Transit Seal Chapitre le plus développé de la partie, avec schémas ASCII pas à pas. Contenu. L'architecture à deux étages : un Vault Transit dédié (l'unsealer) et le Vault Core (les données). Pourquoi cette architecture existe : l'Auto Unseal sans dépendance à un fournisseur cloud. La relation de confiance analysée composant par composant : le montage transit/ dédié et la clé autounseal-core ; la policy minimale (encrypt et decrypt sur cette seule clé) ; le token détenu par le Core ; choix du type, renouvellement, stockage dans la configuration, avec une analyse honnête de ce point sensible ; TLS entre Core et Transit. Configuration commentée du bloc seal "transit". Le problème d'amorçage : qui descelle l'unsealer ; la récursion s'arrête sur Shamir ou sur un KMS, et les deux choix sont analysés. Le flux complet au redémarrage du Core, schématisé étape par étape. La matrice de défaillance, cas par cas : Transit indisponible (Core en marche ; Core qui redémarre) ; Transit compromis (ce que l'attaquant obtient, ce qui lui manque encore) ; Core compromis ; compromission simultanée ; perte définitive du Transit et de ses sauvegardes ; démonstration que les données du Core deviennent indéchiffrables, et pourquoi les recovery keys du Core ne sauvent pas de ce scénario. Stratégies de sauvegarde du Transit : snapshots, protection de ses propres parts, éventuel second nœud. Procédures de restauration croisées, détaillées en partie XI. Comparaison finale argumentée Shamir / KMS / HSM / Transit : racine de confiance, dépendances, souveraineté, disponibilité, coût opérationnel, scénarios de perte. Déclenche le TP 10.

Partie VIII. Stockage et haute disponibilité

Comment les données sont stockées et répliquées, et comment le service survit aux pannes.

Chapitre 24. Le stockage de Vault Contenu. La séparation entre stockage logique et stockage physique. Tout passe par la barrière : le backend ne voit que du chiffré ; conséquences exactes : la confidentialité est assurée par la barrière, mais ni l'intégrité de service ni la disponibilité ne le sont. Panorama historique des backends (Consul, systèmes de fichiers, bases, services cloud) et pourquoi Integrated Storage est devenu le choix par défaut recommandé. Ce qui est réellement stocké : table des montages, tokens, leases, données des moteurs, configuration. Exigences de performance (latence disque) et de capacité.

Chapitre 25. Integrated Storage et Raft Contenu. Le problème du consensus distribué. Raft pas à pas : mandats, élection du leader, réplication du journal, index de commit, quorum (majorité stricte). Snapshots Raft et compaction du journal : à distinguer des snapshots de sauvegarde déclenchés par l'administrateur : même mécanisme, usage différent (la distinction est reprise au chapitre 33). Application à Vault : bootstrap du cluster, raft join, liste des pairs, port cluster 8201, autopilot (nettoyage des nœuds morts, seuils de stabilité ; les fonctions avancées d'autopilot sont Enterprise). Dimensionnement : trois ou cinq nœuds, nombre impair, tolérance de panne. Observation : raft list-peers, autopilot state.

Chapitre 26. Haute disponibilité Contenu. Le modèle actif/standby : un seul nœud actif traite les requêtes ; redirection et forwarding des standbys. Élection et bascule : le déroulé d'un failover et le comportement attendu des clients (retry). sys/health et ses codes (200, 429, 501, 503, et les codes propres à la réplication Enterprise) au service des health checks du load balancer. Perte d'un follower contre perte du leader. Perte du quorum : symptômes, et principe de la récupération par peers.json (procédure complète au chapitre 35). Partitions réseau et prévention du split brain par Raft. Stepdown volontaire et fenêtres de maintenance. Déclenche le TP 11, réalisé dans un environnement de laboratoire jetable scellé par Shamir : pour constater que chaque nœud Raft doit être descellé individuellement, et observer la perte de quorum ; le cluster définitif du fil rouge, scellé par Transit, est assemblé au TP 12.

Partie IX. Architecture de production

La synthèse d'architecture : transformer les briques des parties précédentes en une architecture de production, en justifiant chaque évolution par un risque ou un besoin nommé.

Chapitre 27. Construire l'architecture de production Contenu. Reprise du fil rouge depuis le mono-nœud. Chaque étape est déclenchée par une question explicite : que se passe-t-il si ce serveur meurt (→ cluster Raft) ; qui descelle à trois heures du matin (→ Auto Unseal) ; un KMS cloud est-il acceptable dans ce contexte (→ Transit Seal) ; comment les clients trouvent-ils le nœud actif (→ load balancer et DNS). L'arbre de décision du scellement. Les environnements (production, préproduction, laboratoire) et leur séparation stricte ; la notion de namespaces (Enterprise) est présentée ici comme alternative de cloisonnement au sein d'un même cluster, avec ses limites. Ce qu'on ne fait pas : cluster étiré sans réflexion sur la latence, nœud unique « temporaire » qui devient permanent, mutualisation d'un Vault de production avec des usages de test.

Chapitre 28. Réseau, TLS et exposition du service Contenu. TLS de bout en bout : certificats des listeners, émission par la PKI interne (résolution propre du problème d'amorçage posé au chapitre 7) et rotation. mTLS : où il s'applique et ce qu'il coûte. Le load balancer : passthrough TCP (recommandé) contre terminaison TLS ; analyse des conséquences (visibilité du trafic, réémission, en-têtes). Health checks sur sys/health. Le répartiteur lui-même comme point de défaillance : redondance par paire active/passive (VRRP ou équivalent) en production ; le LB unique du laboratoire est un compromis assumé et documenté. DNS et nommage (vault.astrea.lab). Segmentation et pare-feu : qui a le droit de joindre 8200 ; qui a le droit de joindre 8201 ; réponse stricte : les membres du cluster uniquement. Accès d'administration par bastion. api_addr et cluster_addr corrects : erreurs classiques et leurs symptômes. Non-exposition à Internet, et gestion des exceptions si elles existent.

Chapitre 29. Architecture de référence Astrea Contenu. L'assemblage final : applications, load balancer, cluster Core de trois nœuds (Raft), Vault Transit unsealer avec son propre scellement, PKI, supervision, collecte d'audit, travaux de sauvegarde. Schéma complet et flux numérotés : login applicatif, lecture de secret, unseal au redémarrage, snapshot. Analyse de sécurité formelle de l'architecture selon la grille utilisée dans tout le reste du cours : Assets, Threats, Trust Boundaries, Attack Surface, Security Controls, Residual Risks. Ce que cette architecture ne couvre pas encore : le multi-site (partie XI), le durcissement fin (partie X), la redondance du répartiteur (LB unique assumé comme compromis de laboratoire, traité au chapitre 28 et au cas 4). Déclenche le TP 12.

Partie X. Sécurité avancée

Adopter le point de vue de l'attaquant, puis celui du défenseur outillé.

Chapitre 30. Durcissement Contenu. Durcissement système : unité systemd restrictive, mlock et swap, core dumps, permissions, SELinux et AppArmor dans leurs principes. Durcissement du service : versions et suites TLS, désactivation de l'UI si elle n'est pas nécessaire, quotas et rate limiting contre l'épuisement de ressources, taille maximale des requêtes, paramètres de listener. Gouvernance du root token : révocation après installation, régénération sous quorum (generate-root) documentée et testée à froid. Audit : au moins deux devices, et le comportement bloquant si aucun device ne répond ; Vault cesse de répondre plutôt que d'agir sans trace ; conséquences opérationnelles à connaître avant l'incident. Lutte contre le token sprawl : TTL par défaut stricts, token roles, revues d'accessors. Le secret zéro : comparaison des stratégies (identité de plateforme, orchestrateur de confiance, response wrapping) selon l'environnement. Gestion des plugins. Le chapitre produit la check-list de durcissement Astrea, alignée sur le guide officiel de production hardening.

Chapitre 31. Scénarios d'attaque, détection et réponse Contenu. Scénarios développés de bout en bout : contexte, chemin d'attaque, traces produites, détection, containment, éradication, retour d'expérience : - vol d'un token applicatif : rayon d'action, révocation par accessor, rotation des secrets exposés ; - exfiltration d'un secret_id AppRole par un runner CI compromis ; - interne disposant d'une policy trop large ; - compromission root de l'hôte Vault : ce qui tombe, ce qui reste protégé, pourquoi c'est hors modèle, et comment on s'en approche malgré tout (détection, minimisation) ; - vol du stockage ou d'un snapshot : analyse de ce qui manque encore à l'attaquant selon le type de seal ; - tentative sur les détenteurs de parts Shamir ; - déni de service par explosion de leases. Lecture des journaux d'audit : structure, HMAC des champs sensibles, corrélation, requêtes de chasse typiques ; intégration SIEM. Gestes de réponse : seal d'urgence, revoke-prefix, arbitrage rotate contre rekey selon ce qui est suspecté compromis. Plan de communication. Déclenche le TP 13.

Chapitre 32. Threat modeling d'une architecture Vault Contenu. Une méthode praticable, inspirée de STRIDE et adaptée au sujet : identifier les assets, tracer les flux, poser les frontières de confiance, énumérer les menaces, choisir les contrôles, accepter et documenter les risques résiduels. Application complète à l'architecture de référence Astrea : le tableau du chapitre 29 est déroulé et justifié ligne à ligne. Exercice : modéliser une variante (Vault dans Kubernetes, ou mono-site sans Transit) et défendre ses choix. Limites de l'exercice et pièges : un modèle n'est jamais terminé, et l'exhaustivité apparente est un faux confort.

Partie XI. Disaster Recovery

La question qui décide de la survie du service : peut-on tout perdre et revenir. La partie est construite en trois temps : sauvegarder, décider, exécuter.

Chapitre 33. Sauvegardes et snapshots Contenu. Le snapshot Raft : contenu exact ; l'intégralité de l'état, chiffré par la barrière ; création (vault operator raft snapshot save) ; automatisation en Community Edition par planification et API (les snapshots automatiques intégrés sont Enterprise). La conséquence capitale, énoncée et démontrée : un snapshot sans le seal correspondant (ou sans ses clés) est indéchiffrable ; la sauvegarde des données et la sauvegarde de la capacité de déchiffrement sont deux problèmes distincts, à traiter séparément. Ce qu'il faut sauvegarder d'autre : configuration, infrastructure as code, matériel de la PKI, snapshots du Vault Transit, registre des détenteurs de parts. Stockage des sauvegardes : chiffrées malgré tout, hors du domaine de panne. Tests de restauration réguliers : une sauvegarde non testée n'existe pas. Déclenche le TP 14.

Chapitre 34. Stratégie de Disaster Recovery Contenu. RPO et RTO : définitions, mesure, engagements réalistes. Cartographie des dépendances au moment du désastre : DNS, load balancer, KMS ou Transit, synchronisation du temps, secrets d'amorçage. La matrice des scénarios, chacun avec son analyse : perte d'un nœud, d'un disque, du quorum, du cluster, du site ; perte du seal (KMS ou Transit) ; perte des clés (parts Shamir, recovery keys) ; sauvegardes corrompues ; reconstruction après compromission ; cas particulier : on ne restaure pas un état compromis, on reconstruit la confiance. Options de réplication : réplications DR et performance (Enterprise) présentées conceptuellement ; stratégies Community à base de snapshots et de cluster de secours. Exercices de crise (game days) et critères de déclenchement. Gouvernance : qui décide, qui exécute, qui communique.

Chapitre 35. Procédures de restauration et de récupération Contenu. Procédures pas à pas, chacune testée en TP : remplacer un nœud perdu ; récupérer un quorum perdu par peers.json ; conditions, risques, vérifications ; restaurer un snapshot sur le cluster d'origine ; reconstruire un cluster neuf depuis un snapshot ; exigence du seal d'origine, usage et dangers de la restauration forcée ; migrer de seal en situation de récupération ; récupérer après perte du Transit ; avec sauvegarde du Transit, puis sans : constat de perte et plan de reconstruction du service. Liste de contrôle post-restauration : état des leases et des tokens, validité des credentials dynamiques émis avant l'incident, cohérence de l'audit, rotations préventives. Modèle de rapport d'incident. Déclenche le TP 15.

Partie XII. Exploitation

Le quotidien qui fait durer le service : mesurer, entretenir, mettre à jour.

Chapitre 36. Supervision et audit en exploitation Contenu. Télémétrie et exposition Prometheus. Les métriques qui comptent, avec leurs seuils : état du seal, identité du leader et fréquence des bascules, latences Raft (commit, apply), volumétrie et croissance des leases et des tokens, latence des requêtes, échecs d'audit, taille du stockage. sys/health pour les load balancers et la supervision. Journal opérationnel et journal d'audit : deux rôles distincts. Audit devices (file, syslog, socket), rotation des fichiers d'audit, acheminement vers le SIEM. Le catalogue d'alertes Astrea, chaque alerte étant justifiée par le scénario qu'elle détecte. Tableaux de bord types.

Chapitre 37. Maintenance, mises à jour et cycle de vie Contenu. Stratégie de mise à jour d'un cluster Raft : snapshot préalable, standbys d'abord, stepdown, leader en dernier ; lecture des notes de version et fenêtres de compatibilité. Le calendrier des rotations : clé de chiffrement (rotate), parts et recovery keys (rekey), certificats TLS, credentials racine des moteurs (rotate-root), secret_ids, revue du root token. Capacity planning : croissance des leases, opérations tidy (tokens, PKI), volumétrie des snapshots. Gestion des montages dans la durée (dépréciation, déplacement). Intégration au processus d'incident : astreinte, niveaux de gravité. Documentation vivante et runbooks.

Partie XIII. Intégrations

Vault ne vit pas seul : le connecter proprement aux plateformes, aux chaînes de livraison et aux applications.

Chapitre 38. Kubernetes et conteneurs Contenu. La méthode d'authentification Kubernetes en détail : TokenReview, audiences, liaison compte de service et namespace. Consommer des secrets dans les pods : Agent Injector (sidecar), CSI Secrets Store, Vault Secrets Operator (synchronisation vers des Secrets Kubernetes) ; comparaison honnête des trois approches : fraîcheur des secrets, surface d'attaque, expérience développeur, et la conséquence exacte de la copie dans etcd. Vault installé dans Kubernetes ou à l'extérieur : analyse de frontière de confiance. Docker et Compose : patrons d'injection et erreurs classiques (secrets dans les variables d'environnement du conteneur). Transit pour le chiffrement applicatif dans Kubernetes. Fil rouge : l'application billing migrée sur k8s-astrea. Le chapitre intègre une mise en pratique guidée sur un cluster local (kind ou minikube) ; un TP optionnel hors barème, adossé à ce chapitre, est proposé en partie XV.

Chapitre 39. Infrastructure as Code et CI/CD Contenu. Gérer la configuration de Vault avec Terraform (provider vault) : apports, et le problème sérieux de l'état Terraform qui contient des secrets ; analyse et mitigations. Ansible et les lookups Vault. La CI sans secret statique : GitHub Actions par OIDC (méthode JWT, sujets, audiences), GitLab CI (id_tokens), Jenkins (approches possibles et leurs limites). Prévention des fuites dans les journaux de pipeline. Credentials éphémères pour les déploiements. Fil rouge : la chaîne de déploiement de billing obtient ses accès par identité, plus jamais par secret partagé.

Chapitre 40. Intégration applicative Contenu. Consommer Vault depuis le code : API directe et bibliothèques (hvac pour Python, Spring Vault, client Go officiel, node-vault). Qui s'authentifie et comment : l'application elle-même, ou la délégation à Vault Agent. Vault Agent en profondeur : auto-auth, sinks, templates, cache ; le patron recommandé pour découpler l'application de Vault (Note de version : depuis 1.14, l'outil est scindé en Vault Agent et Vault Proxy ; le cours précise leurs rôles respectifs). Modes de consommation comparés : variables au démarrage, fichiers templatés avec rechargement, appels directs. Gérer la rotation sans coupure : signaux, pools de connexions. Modes de défaillance : Vault indisponible au démarrage de l'application ou en cours de vie ; décisions de conception, fail closed ou fail open selon la nature du secret. Anti-patterns : cache sauvage de credentials, TTL ignorés, journaux bavards.

Partie XIV. Études de cas

Six cas complets pour transférer les acquis vers des contextes réels. Chaque cas suit la même grille : contexte ; contraintes ; risques ; architecture proposée ; choix techniques argumentés ; alternatives écartées et pourquoi ; compromis assumés ; stratégie de récupération. Chaque cas se conclut par des questions de discussion. La liste et le périmètre de chaque cas sont donnés en section 12.

Partie XV. Travaux pratiques

Le parcours pratique complet : quinze TP de difficulté croissante, chacun rédigé selon le gabarit imposé (objectifs, prérequis, environnement, architecture, étapes à conduire, résultats attendus, erreurs possibles et diagnostic, questions). Les commandes ne figurent pas dans les énoncés : chaque TP est déclenché par un chapitre qui les contient, et l'exercice consiste à les mobiliser. Les corrections font l'objet d'un livret séparé, à produire. La liste, le positionnement dans la progression et les durées sont donnés en section 11. La partie s'ouvre sur la description de l'environnement de TP (machines ou conteneurs, dimensionnement, fichiers à produire) et sa correspondance avec la nomenclature Astrea. Elle propose en outre un TP optionnel hors barème (Kubernetes : authentification et Agent Injector sur un cluster kind, adossé au chapitre 38) pour les publics qui disposent de l'environnement.

Partie XVI. Évaluation finale

Contenu. Banque de QCM organisée par partie, avec corrigés commentés. Questions ouvertes de compréhension. Exercices techniques : écriture de policies et correction d'un existant fautif, cycles de vie de tokens, lecture de journaux d'audit. Exercices d'architecture : concevoir sous contraintes, critiquer et corriger une architecture donnée. Scénarios d'incident et de compromission sur table. La grille d'auto-évaluation reprenant l'intégralité des questions de la fiche de mission, avec renvoi vers les chapitres. L'examen final complet : sujet, barème, correction détaillée (structure en section 13).

Annexes

• Annexe A. Glossaire : termes du cours, avec équivalences français-anglais (le cours conserve les termes techniques anglais consacrés lorsqu'ils sont d'usage : seal, lease, mount, etc.).
• Annexe B. Bibliographie et ressources officielles : documentation Vault (docs, API, tutoriels), guide officiel de durcissement, architectures de référence, notes de version, et textes fondateurs (article de Shamir, 1979 ; papier Raft).
• Annexe C. Mémento : commandes CLI et chemins d'API utilisés dans le cours, classés par thème. Seul document autorisé à l'examen final.