Éléments de réponse aux questions de compréhension
Chapitre 30¶
1. Compte de service dédié sans shell : borne la compromission d'un autre service de la machine. Privilèges minimaux dans l'unité de service : enferme une exécution de code dans le processus. Vidages mémoire interdits : empêchent qu'un plantage dépose le keyring en clair sur disque. Échange désactivé : empêche que la mémoire non verrouillée soit paginée hors barrière. Surface logicielle réduite : ce qui n'est pas installé n'a pas de vulnérabilité et ne sert pas à un attaquant qui obtient un interpréteur.
2. Les deux traitent du même risque : qu'une copie de la mémoire du processus se retrouve sur un support persistant, hors barrière. Le vidage l'écrit en cas de plantage, la pagination l'écrit en fonctionnement normal. Ce sont les deux fuites qui contournent tout le chapitre 6 sans casser la moindre clé.
3. Le point de santé et l'état de scellement. Ils existent parce qu'il faut pouvoir sonder et diagnostiquer un serveur scellé, dont plus rien d'autre n'est accessible. Posture : ne pas les couper, mais les compter comme reconnaissance offerte et ne rien ajouter d'inutile à l'exposition.
4. Parce que monitor-01 concentre la cartographie des usages de tout le système. S'il pouvait ouvrir des sessions vers les nœuds, sa compromission deviendrait un chemin du composant le moins critique vers le plus critique. Les nœuds poussent, monitor-01 reçoit : sa compromission coûte la confidentialité des journaux, pas l'accès aux coffres.
5. Nominatif, sans aucun compte partagé. Court, l'accès étant un événement et non un état. Depuis un seul endroit, la machine qui figure à la matrice et qu'on durcit. Journalisé des deux côtés. La corrélation entre l'audit de Vault et les journaux système transforme un soupçon en certitude.
6. Parce que l'audit est bloquant : si aucun dispositif ne peut écrire, Vault cesse de répondre. Un dispositif unique dont le disque se remplit devient donc une panne de production causée par un contrôle de sécurité. Deux dispositifs indépendants font qu'une défaillance de l'un laisse l'autre écrire, et le second, distant, échappe à qui compromet la machine.
7. Horodatage, chemin, opération et issue, identité et policies, accessor du token, adresse source ; les valeurs sensibles apparaissant en empreinte salée. On retrouve une valeur en la recalculant par l'endpoint dédié, puis en cherchant l'empreinte dans le journal. On ne parle pas de déchiffrement parce qu'une empreinte n'est pas réversible : on compare des empreintes.
8. Qu'a fait cette identité ; qui a touché ce chemin ; qu'a fait ce token, par recalcul de son empreinte ; qu'est-ce qui a échoué. La dernière est la plus précieuse : une rafale de refus sur des chemins voisins est une reconnaissance en cours, donc le signal le plus précoce dont dispose la défense.
9. Parce qu'ils ont une valeur double : ils prouvent, donc leur intégrité et leur conservation engagent la capacité d'enquête et la conformité ; et ils révèlent, en donnant qui accède à quoi, à quel rythme et depuis où. Ils se protègent en accès, en intégrité et en rétention, comme les autres actifs.
Mise en pratique du chapitre 30. 1. Dix points, chacun avec sa menace et son constat. Utilisateur de service dédié : rebond depuis un autre service, vérifié par l'utilisateur du processus et l'absence de shell. Unité de service restrictive : exécution confinée, vérifiée par relecture des directives. Vidages interdits : keyring en clair, vérifié dans les limites du processus. Échange désactivé : pagination hors barrière, vérifié par l'état de l'échange. Consigne mémoire cohérente avec le stockage intégré, vérifiée par relecture de la configuration. Permissions des répertoires et des clés privées : lecture par un tiers local. Disques chiffrés : vol de disque. Horloge synchronisée : baux, certificats, élections et corrélation, avec l'écart mesuré. Surface logicielle réduite : outillage offert à l'attaquant, vérifiée par inventaire des paquets. Pare-feu conforme à la matrice : pivot depuis une zone voisine, vérifié par balayage depuis chaque zone, refus compris. Chacun entre dans la gestion de configuration, faute de quoi il se perd à la première reconstruction. 2. Deux dispositifs : un fichier sur un volume dédié, et une expédition vers le collecteur conservée en écriture seule. Rotation par renommage puis signal, jamais par copie et troncature, testée en laboratoire. Alertes : espace du volume à deux seuils, échec d'écriture d'un dispositif, écart de volume entre flux local et distant sur vingt-quatre heures. Rétention selon la conformité, avec chiffrement au repos et accès restreint. Recette : un événement de test doit apparaître dans les deux flux ; la coupure volontaire du collecteur ne doit pas arrêter Vault ; le remplissage volontaire du volume local doit produire l'alerte avant l'arrêt ; et un token de test recalculé doit se retrouver dans les deux flux. 3. Les quatre requêtes s'écrivent avec un filtre par identité et un tri chronologique ; un filtre par préfixe de chemin en affichant l'identité et l'issue ; un recalcul d'empreinte suivi d'une recherche sur le champ du token ; et un filtre sur les réponses en erreur, agrégé par identité, dont on attend une courbe plate et dont tout pic nominatif ouvre un ticket.
Chapitre 31¶
1. Hypothèse d'entrée, chronologie, signaux, décision, coût, reprise, enseignement. Le principe qui les traverse : on suppose l'attaquant présent, pas absent. L'exercice ne sert pas à démontrer que les contrôles tiennent, mais à voir ce que l'attaquant obtient quand ils tiennent.
2. Du plus étroit au plus large : révoquer un token par accessor, une session et un coût nul pour les autres ; révoquer une identité ou un rôle, toutes les sessions futures d'un demandeur ; révoquer par préfixe de baux, un domaine entier dont tous les consommateurs tombent ; révoquer le token de seal d'un nœud, sans effet sur le service ; sceller le cluster, arrêt total avec retour par cérémonie ou gardien.
3. La borne d'origine du token, qui a rendu le vol inexploitable hors de l'hôte compromis. Le moindre privilège des policies, qui a borné la lecture au périmètre de billing. Et les instructions de création du rôle de base, qui ne fabriquent que des comptes sans droit de structure. Trois décisions de deux lignes, prises longtemps avant l'incident.
4. Parce que les pleins pouvoirs sur un nœud descellé donnent accès au stockage, à la configuration donc au token de seal, et à la mémoire du processus où vit la clé racine. La conséquence mobilise le principe du chapitre 21 : le rekey ne périme pas les copies passées, donc il ne suffit pas de changer les gardes, il faut faire tourner les valeurs.
5. Parce que le mal est un fichier qui se trouve ailleurs : sceller, révoquer ou rekeyer ne reprend rien à qui détient déjà une copie. La réponse consiste à périmer la valeur de ce fichier, par rotation du keyring puis rotation effective des secrets contenus, et à traiter la cause d'exposition côté stockage de sauvegarde.
6. La défense n'est pas l'interdiction, puisque l'administrateur peut légitimement se donner des droits : c'est la détection immédiate et l'irréversibilité limitée. Trois mécanismes la portent : l'audit externalisé hors de sa portée, les policies versionnées qui rendent toute divergence visible, et le quorum exigé pour le pouvoir suprême.
7. Un appel de déchiffrement sur la clé d'enveloppe sans redémarrage de nœud correspondant. Le montage du chapitre 23 le rend possible parce que le gardien est sous notre toit, avec son propre audit : la corrélation entre ses journaux et les démarrages des nœuds est un contrôle qu'un gardien tiers ne permettrait qu'imparfaitement.
8. Parce que rien n'est volé ni détourné : un consommateur légitime demande des credentials en boucle, et chaque émission étant une écriture Raft engagée à la majorité, la latence monte et l'actif sature. Le contrôle permanent qui en sort est le quota de débit, par chemin ou par identité, doublé de la surveillance de la courbe des baux ; et pour une charge d'authentification, le token batch supprime l'écriture à la source.
9. Qui décide, avec les coupures préautorisées ; quand on coupe large ; ce qu'on dit et à qui ; ce qu'on préserve avant de reconstruire ; comment on revient, avec des critères explicites. Les trois artefacts : le runbook par scénario, l'annuaire d'astreinte incluant les porteurs de parts, et le journal de décision tenu en direct.
Mise en pratique du chapitre 31. 1. Hypothèse : le token volé porte la policy d'administration. Chronologie : l'attaquant ne lit pas directement les valeurs, mais il écrit une policy, l'attache à une entité qu'il crée, s'y connecte et lit tout ; il peut aussi désactiver un dispositif d'audit, activer un moteur ou détruire un montage. Signaux : les écritures sur les chemins de pouvoir, toutes de première catégorie, et la désactivation d'un dispositif qui laisse une trace dans l'autre. Décision : révoquer le token, suspendre l'identité porteuse, geler les changements de policies, exiger le quorum pour toute réparation. Coût : administration en mode dégradé pendant l'enquête, plus la revue complète des policies et entités sur la fenêtre. Reprise : comparaison avec le dépôt versionné, suppression de tout objet créé, rotation de tout secret dont la lecture est établie ou plausible. Comparaison : le rayon passe d'un périmètre applicatif borné à l'ensemble du système ; la détection ne repose plus sur des refus, puisque l'attaquant s'autorise au lieu d'être refusé, mais sur la surveillance des chemins de pouvoir ; et le coût de reprise passe de quelques minutes à un chantier de rotation générale. C'est l'argument le plus concret en faveur du raffinement de la policy d'administration. 2. Révocation d'un token par accessor : une session, astreinte. Révocation d'un secret_id ou d'un rôle : un demandeur, astreinte. Révocation d'un token de seal : aucune interruption, astreinte. Révocation par préfixe de baux : un domaine, astreinte pour les préfixes applicatifs, décideur pour un moteur entier. Retrait d'un droit dans une policy : proportionnel à sa largeur, décideur. Rotation du compte racine d'un moteur : irréversible, décideur, après vérification du compte de secours. Scellement d'un nœud : décideur. Scellement de vault-transit-01 : décideur, avec gel des redémarrages. Scellement du cluster : décideur, information immédiate de la direction. Rotation générale des secrets : direction. La fiche tient sur une page et se relit à chaque prise d'astreinte. 3. Injections : d'abord une alerte d'accès inhabituel au partage de sauvegarde ; un quart d'heure plus tard, la confirmation qu'une copie complète a été lue par un compte de prestataire ; enfin, l'information que ce compte servait aussi à d'autres clients. Durée : deux heures. Questions à trancher : que vaut la copie volée selon le seal en place et que manque-t-il à l'attaquant ; faut-il rotationner le keyring et cela suffit-il ; quels secrets doivent tourner réellement, dans quel ordre et qui les possède ; que dit-on au prestataire, aux clients, aux autorités. Critères de réussite : conclure en moins de trente minutes que la coupure Vault est inopérante, produire une liste ordonnée de rotations avec propriétaires, et identifier la mesure de fond. Les deux trous attendus : personne ne sait combien de copies de sauvegarde existent ni où, et aucun runbook de rotation générale n'existe côté applications.
Chapitre 32¶
1. Parce que la grille est un livrable, pas un procédé. Remplie par ceux qui ont conçu le système, elle reflète ce qu'ils avaient en tête et laisse dans l'ombre ce qu'ils considèrent comme acquis. La méthode corrige ce biais en imposant un ordre, des participants et un critère d'arrêt.
2. Reproductible, finie, transférable. C'est la troisième qui fait la compétence durable : elle s'applique à un système découvert le matin même, y compris hors de Vault.
3. Usurpation : qui peut se faire passer pour un autre, ce qui renvoie aux méthodes d'authentification et à la vérification TLS. Altération : qui peut modifier données, messages ou configuration. Répudiation : qui peut agir sans qu'on le prouve, ce qui renvoie à l'audit nominatif et externalisé. Divulgation : qui peut lire ce qu'il ne devrait pas, métadonnées comprises. Déni de service : qui peut empêcher le service. Élévation : qui peut obtenir plus qu'accordé, ce qui renvoie aux chemins de pouvoir.
4. Cadrer, avec périmètre et hypothèses écrits. Dessiner les flux et poser les frontières, les écarts avec la matrice étant les premières trouvailles. Énumérer par frontière sans filtrer. Coter, avec plausibilité, impact et coût de la réponse. Décider, en contrôle, signal ou risque signé. Consigner dans la semaine, avec propriétaires et dates.
5. Par composant, la liste est infinie et redondante, et l'équipe s'épuise avant les cas intéressants. Par frontière, elle est finie par construction et concentre l'attention là où les incidents naissent. Les deux frontières qui échappent au réflexe réseau sont celle où Vault est client de ses cibles, et la frontière humaine et hyperviseur.
6. Trois niveaux de plausibilité et trois d'impact, sans multiplication ni décimales : une fausse précision autoriserait des arbitrages que les données ne soutiennent pas. Le coût de la réponse entre dans la décision parce qu'une menace peu probable dont le traitement occupe une semaine mérite plus de prévention qu'une menace fréquente dont la réponse est une commande.
7. Un contrôle, avec propriétaire, date et recette. Un signal de supervision, avec seuil, destinataire et runbook associé. Ou un risque résiduel signé et daté avec son critère de révision. « À surveiller » n'engage personne, ne produit ni alerte ni décision, et sert surtout à clore la discussion sans conclure.
8. Activation d'un moteur ou d'une méthode d'authentification. Ajout d'un flux ou d'une zone. Arrivée d'un acteur. Incident, chez soi ou ailleurs, avis de sécurité compris. Changement d'édition ou de version. Hors déclencheur, révision complète annuelle, calée sur la revue anti-dérive.
9. Le biais de l'auto-évaluation, corrigé par une personne extérieure ou un avocat du diable mandaté. La sensibilité du document produit, qui est un plan d'attaque, corrigée par la gouvernance du dossier. L'obsolescence silencieuse, corrigée par la datation et les déclencheurs. Et l'absence de preuve empirique, corrigée par les exercices sur table, les recettes de flux et la supervision.
Mise en pratique du chapitre 32. 1. Périmètre : le cluster comme consommateur de Vault et comme cible du moteur de secrets Kubernetes. Hypothèses écrites : le plan de contrôle est administré par une équipe distincte, et l'API du cluster est de confiance pour la validation des jetons. Participants : l'architecte Vault, l'administrateur du cluster, un développeur, un exploitant, et une personne extérieure. Flux à dessiner : pods vers l'entrée Vault ; Vault vers l'API du cluster ; chaîne d'images et de manifestes ; gestion de configuration vers les nœuds. Trois premières questions : qu'est-ce qui distingue un pod légitime d'un pod hostile du même namespace, et que vérifie exactement le rôle ; qui peut créer un compte de service dans les namespaces autorisés ; que se passe-t-il si l'API du cluster est compromise, sachant que Vault lui fait confiance. 2. Usurpation : le fournisseur d'identité est usurpé ou son certificat expire et la vérification se relâche ; contrôle, ancre vérifiée et surveillance de l'échéance. Altération : un attaquant modifie les réponses de la base ; contrôle, vérification TLS complète, recette ajoutée aux revues. Répudiation : les actions du compte de moteur ne se distinguent pas de celles d'un administrateur humain ; signal, journalisation côté base et corrélation avec les émissions. Divulgation : le compte de moteur peut lire au-delà du schéma prévu ; contrôle, révision de ses privilèges. Déni de service : la base refuse les connexions et Vault ne peut plus créer de comptes ; risque résiduel, mitigé par le comportement des applications déjà servies. Élévation : qui écrit les rôles du moteur fait fabriquer des comptes aux privilèges de son choix ; contrôle, chemin réservé, alarmé et revu. 3. J'accepte le diagramme de flux et l'inventaire des actifs, sous réserve qu'ils correspondent à la matrice réelle et non à l'architecture sur plan. Je rejette la cotation à deux décimales, dont la précision n'est portée par aucune donnée, et je demande une échelle à trois niveaux assortie du coût de la réponse. Je rejette surtout l'absence de risques résiduels : un modèle sans sixième colonne n'a pas été mené à son terme. Trois questions décideront de sa valeur : qui a participé à l'atelier et quelqu'un d'extérieur y était-il ; combien de flux le dessin a-t-il fait apparaître qui ne figuraient pas dans notre documentation ; quelles décisions concrètes, avec propriétaire et date, en sortent, sachant qu'un modèle qui ne change rien n'a rien produit.