11. Travaux pratiques. liste complète
Quinze TP de difficulté croissante. Chacun est rédigé selon le gabarit imposé : objectifs ; prérequis ; environnement ; architecture ; étapes à conduire ; résultats attendus ; erreurs possibles et diagnostic ; questions. Les commandes se construisent depuis le chapitre déclencheur, et les corrections font l'objet d'un livret séparé, à produire. Les TP sont numérotés dans leur ordre d'exécution (1 → 15) ; la colonne « fiche » donne la correspondance avec la numérotation de la fiche de mission, dont les quinze TP sont repris un pour un : seule l'ordre d'étiquetage change, la PKI (chapitre 17) étant enseignée avant les moteurs dynamiques (chapitre 19), et le scellement (partie VII) avant le cluster (partie VIII).
| TP | Titre | Après | Fiche | Contenu et objectif | Durée |
|---|---|---|---|---|---|
| 1 | Installation propre | ch. 7 | TP 1 | binaire vérifié, configuration HCL, systemd durci, TLS auto-signé de laboratoire | 1,5 h |
| 2 | Initialisation, seal et unseal | ch. 8 | TP 2 | init 5 parts / seuil 3, lecture de status, unseal, seal volontaire, création d'un admin puis révocation du root token initial |
1,5 h |
| 3 | KV v2 | ch. 9 | TP 3 | versions, soft delete, undelete, destroy, check-and-set | 1 h |
| 4 | Policies | ch. 11 | TP 4 | écrire billing-kv en moindre privilège, piège data/-metadata/, preuve par token capabilities |
2 h |
| 5 | Tokens | ch. 12 | TP 5 | TTL, renouvellement, hiérarchie et révocation en cascade, accessors, response wrapping | 1,5 h |
| 6 | AppRole de bout en bout | ch. 13 | TP 6 | rôle billing, contraintes CIDR et TTL de secret_id, livraison du secret_id par wrapping, login applicatif scripté |
2 h |
| 7 | PKI | ch. 17 | TP 8 | pki-root + pki-int, rôle astrea-services, émission et révocation, CRL, rotation d'intermédiaire |
2,5 h |
| 8 | Secrets dynamiques PostgreSQL | ch. 19 | TP 7 | connexion pg-billing, rôle billing-app, émission, renouvellement, révocation, observation côté base |
2 h |
| 9 | Auto Unseal KMS | ch. 22 | TP 10 | variante A : KMS cloud (compte d'essai) ; variante B [Laboratoire] : émulateur KMS local (type LocalStack, via le paramètre endpoint du seal awskms), limites de représentativité signalées ; migration Shamir → Auto Unseal et retour |
2 h |
| 10 | Transit Seal | ch. 23 | TP 11 | déploiement de vault-transit-01, clé autounseal-core, policy seal-core, token dédié, bascule du Core, tests de redémarrage, coupure du Transit et observation |
3 h |
| 11 | Cluster Raft trois nœuds | ch. 26 | TP 9 | laboratoire jetable en scellement Shamir : bootstrap, join, list-peers, unseal nœud par nœud, arrêt du leader et observation du failover, perte du quorum constatée |
2,5 h |
| 12 | Architecture multi-nœuds complète | ch. 29 | TP 12 | assemblage fil rouge définitif : lb-vault-01 (HAProxy), cluster trois nœuds scellé par Transit, health checks, vérification des flux | 3 h |
| 13 | Incident de sécurité | ch. 31 | TP 15 | un token applicatif fuité est utilisé (scénario fourni) : chasse dans l'audit, identification, révocation, rotation, rapport d'incident | 3 h |
| 14 | Sauvegarde et restauration | ch. 33 | TP 13 | snapshot, restauration sur le cluster d'origine, restauration sur un cluster neuf avec le seal d'origine | 2 h |
| 15 | Disaster Recovery | ch. 35 | TP 14 | perte du quorum et récupération par peers.json ; perte totale du cluster et reconstruction depuis snapshot ; liste de contrôle post-restauration |
3 h |
Total pratique : 33 heures, ouverture d'environnement comprise (32,5 h de TP et environ 0,5 h de prise en main). L'environnement (l'ensemble tient en conteneurs sur une machine d'environ 8 Go de RAM), les fichiers fournis (HCL, compose, scripts) et leur correspondance avec la nomenclature Astrea sont décrits en ouverture de la partie XV, qui propose aussi un TP optionnel hors barème (Kubernetes, adossé au chapitre 38).