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

Chapitre 1

1. Un secret est une donnée dont la seule connaissance confère un pouvoir d'action. Un login seul n'en est pas un : le connaître ne permet pas d'agir, c'est un identifiant fait pour circuler. Une adresse IP interne n'en est pas un : information utile à un attaquant, sans pouvoir en soi. Une clé publique n'en est pas un par définition ; c'est son intégrité qui compte, pas sa confidentialité.

2. Une image est un empilement de couches immuables, chaque instruction de build produisant une couche. Supprimer un fichier plus tard ajoute une couche qui le masque dans la vue finale, mais la couche antérieure reste dans l'image distribuée. Quiconque tire l'image peut examiner les couches et récupérer le fichier.

3. La réécriture n'atteint pas les copies existantes : clones, forks, miroirs et caches conservent l'ancien historique. La fenêtre d'exposition a déjà eu lieu, les dépôts étant scannés en continu. Et la révocation est la seule action dont l'effet est total et vérifiable, quand l'effacement est invérifiable par nature.

4. Chiffrer transforme « protéger la donnée » en « protéger la clé » : le problème subsiste, concentré sur un objet plus petit et plus puissant. Question de vérification : « et cette clé-là, où est-elle, qui y accède, qui la fait tourner ? » Sans réponse au-dessus, la solution a déplacé le problème.

5. Création : secret inventé par un humain, vu à la création, périmètre trop large. Distribution : transport et dépôts incontrôlés. Utilisation : pas de TLS, pas de trace, acteurs indistincts. Rotation : jamais faite faute d'inventaire, pas de recouvrement. Révocation : procédure inexistante ou jamais répétée. Destruction : copies oubliées dans les sauvegardes.

6. La rotation est planifiée et se prépare à froid ; la révocation est subie, immédiate, sous pression. La révocation est le vrai test parce qu'elle exige tout ce que le sprawl détruit : savoir où le secret est utilisé, pouvoir l'invalider côté cible, absorber la coupure.

7. La rotation manuelle exige inventaire, coordination, recouvrement et retour arrière. Son coût est certain, son bénéfice invisible, son échec spectaculaire : l'organisation rationnelle la repousse. Le cercle : pas de rotation, donc durée de vie longue, donc copies plus nombreuses, donc inventaire impossible, donc rotation plus risquée, donc report. L'issue est architecturale, pas disciplinaire.

8. Le consommateur doit s'authentifier pour obtenir ses secrets, donc présenter un premier secret, qui ne peut pas être dans le système qu'il ouvre. Traitements : le réduire à un par consommateur, le rendre éphémère et à usage limité, le livrer par un canal contrôlé, ou le supprimer en s'appuyant sur une identité de plateforme. Cette dernière stratégie ne distribue aucun secret.

Mise en pratique du chapitre 1. 1. La recherche naïve produit trois catégories. Les faux positifs occupent l'essentiel du volume et servent à calibrer les motifs. Les secrets périmés : leur présence dans l'historique reste une fuite, et la conclusion correcte est de considérer comme compromise toute valeur passée par là. Les secrets vivants appellent la même conclusion, en plus urgent. 2. L'environnement d'un service est lisible par root et, selon la configuration, par le propriétaire du processus. Questions à se poser : qui d'autre tourne sous cet utilisateur, quels outils capturent les environnements, que verrait un vidage mémoire. Une variable d'environnement est un transport lisible et persistant, pas une protection. 3. La feuille est réussie quand elle est incomplète et que vous savez pourquoi. Deux colonnes emportent la démonstration : le nombre de copies connues, dont la réponse honnête est « je ne sais pas », et le délai de révocation en urgence, qui se compte en heures ou en jours sans procédure écrite. Notez la date de dernière rotation : au-delà d'un an, le secret n'a plus de propriétaire réel.

Chapitre 2

1. Tout ce qui rend un secret plus confidentiel le rend moins disponible. Extrême disponibilité : le secret copié dans la configuration de chaque service, toujours là, indéfendable. Extrême confidentialité : la clé racine partagée entre cinq personnes, très défendue, et la récupération nocturne attend les humains.

2. L'identité est ce que l'acteur est, l'authentification l'acte de le prouver, l'autorisation la décision de ce qu'il peut faire. Le secret partagé fusionne les identités au niveau de la preuve : dix acteurs, une trace. Le compte unique tout-puissant fusionne en plus authentification et autorisation.

3. Parce qu'une identité peut avoir plusieurs moyens de preuve, et que les moyens changent sans que la fonction change. Bénéfice : la même application garde les mêmes droits et la même trace qu'elle s'authentifie par AppRole ou par Kubernetes, et l'on révoque un moyen de preuve sans reconstruire les droits.

4. Une compromission est une chaîne : chaque privilège du maillon compromis est offert au suivant. Un token limité à secret/billing/prod borne le vol à ce périmètre et permet une rotation ciblée ; le même token avec des droits larges transforme le même vol initial en accès général.

5. Attachée à des identités individuelles ; horodatée avec opération, chemin, origine et résultat ; protégée en intégrité et expédiée hors du système observé ; exempte des valeurs secrètes ; effectivement interrogeable. Un journal qui manque l'une de ces propriétés fait de « tout considérer comme volé » la seule conclusion honnête.

6. Le quorum protège l'usage d'un pouvoir terminal contre la malveillance d'une personne seule, la compromission partielle et l'erreur individuelle sur un geste irréversible. Le prix est la disponibilité : l'opération attend k humains joignables, ce qui se paie dans les récupérations d'urgence.

7. Aucun accès n'est accordé sur la foi de la position réseau ; chaque accès est authentifié, autorisé et tracé sur une identité vérifiable. La segmentation demeure comme couche de défense en profondeur, mais cesse d'être un mécanisme d'autorisation.

8. La racine de confiance est l'élément terminal de la chaîne des clés : rien au-dessus ne la protège, sa sécurité se décide et tout en hérite. Sa perte est aussi grave que son vol parce qu'elle est irréparable par construction : le vol compromet les données, la perte les détruit.

9. Trois problèmes traités : le sprawl, puisqu'une copie exfiltrée expire d'elle-même ; la rotation, qui devient le mode normal ; l'imputabilité, un credential par instance produisant des acteurs distincts. Deux coûts : la criticité de disponibilité de l'infrastructure d'émission, et l'adaptation des consommateurs comme des systèmes cibles.

Mise en pratique du chapitre 2. 1. a) Théâtre pour l'essentiel : la robustesse du mot de passe ne répare ni la fusion d'identités ni l'imputabilité nulle du compte partagé (2.2, 2.5). b) Théâtre : le chiffrement dont la clé vit dans le flux protégé ne résiste pas au scénario qu'il prétend couvrir (2.9). c) Moindre privilège et identité (2.2, 2.3), mesure de fond. d) Credentials éphémères (2.10) et rotation comme propriété (2.4). e) Séparation des responsabilités (2.6), pertinent à condition que la procédure soit répétée. f) Filet utile mais dernier de sa couche (2.7) ; devient théâtre si l'on s'y fie comme protection principale. g) Défense en profondeur légitime (2.7) parce qu'elle s'ajoute à l'authentification au lieu de s'y substituer. h) Traçabilité complète (2.5), protégée en intégrité, conservée et lue. 2. À partir du cas f) : le masquage est du théâtre parce qu'il ne connaît que les valeurs déclarées et n'empêche ni la copie par le job, ni la présence dans les artefacts. La mesure de fond est de ne plus livrer de secret durable au pipeline, en lui donnant des credentials éphémères obtenus contre son identité (2.10 et 2.2). 3. Les trois mesures qui se renforcent sont c), d) et h). L'identité rend l'action attribuable, les credentials éphémères bornent la fenêtre d'usage, la conservation avec revue rend l'attribution exploitable. Sans identité, la trace n'accuse personne ; sans durées courtes, l'identité prouvée reste exposée des mois ; sans revue, l'anomalie dort dans un fichier.

Chapitre 3

1. Pour l'administrateur : tout geste manuel est scriptable à l'identique, et il n'existe pas d'opération réservée à un outil graphique. Pour l'attaquant : la surface est l'API, toute l'API, ce qui la rend énumérable, filtrable et journalisable en un point unique.

2. Toute ressource et toute opération est adressée par un chemin. Conséquence : l'autorisation s'exprime dans une grammaire unique, des capacités sur des chemins, qui couvre uniformément tout le système et rend le moindre privilège exprimable partout avec le même outil.

3. Refus par défaut : un token sans policy ne peut rien, on écrit ce qu'on accorde. Démarrage scellé : le serveur ne déchiffre pas ses données sans opération explicite, l'état sûr est l'état initial. Chiffrement non optionnel du stockage et TLS attendu : la protection n'est pas une option à activer.

4. Mount : installation d'un composant sur un chemin. Secrets engine : composant gérant une famille de secrets. Auth method : composant qui vérifie des preuves et délivre des tokens. Policy : capacités sur des chemins. Token : matérialisation d'une authentification réussie. Lease : bail d'un secret ou d'un token. Seal : mécanisme protégeant la clé racine. Barrière : couche chiffrant tout ce qui part au stockage. Audit device : destination du journal des requêtes.

5. Parce qu'il fixe la frontière de responsabilité : au-delà de la livraison, le secret vit dans la mémoire et les pratiques du client. Conséquences : la sécurisation des consommateurs fait partie du projet ; les durées courtes sont la mitigation réaliste ; le chiffrement comme service est la parade ultime, puisqu'il ne livre pas la clé.

6. Gestionnaire cloud meilleur : organisation entièrement dans un cloud, secrets statiques, pas de PKI interne ni de dynamique multi-systèmes, pas de capacité d'exploitation à dédier. Vault meilleur : hétérogénéité, credentials dynamiques sur systèmes variés, PKI et chiffrement de service, exigence de choisir soi-même la racine de confiance. Critère : Vault se justifie quand la valeur de ses capacités différenciantes excède durablement le coût de l'exploiter sérieusement.

7. Elle fait du serveur l'actif le plus critique de l'infrastructure, en gravité comme en disponibilité. Elle justifie donc l'ordre du cursus : modèle de sécurité et frontières, scellement, haute disponibilité, durcissement et réponse à incident, reprise après sinistre. Et elle impose un corollaire : un Vault mal exploité est plus dangereux qu'une absence de Vault.

8. Petite équipe avec quelques dizaines de secrets statiques sur un seul cloud : gestionnaire du cloud plus coffre humain. Secrets exclusivement humains : gestionnaire de mots de passe d'équipe. Cluster Kubernetes unique sans PKI ni dynamique : secrets natifs, éventuellement complétés du gestionnaire du cloud.

Mise en pratique du chapitre 3. 1. Le gestionnaire de secrets du fournisseur cloud, complété d'un gestionnaire de mots de passe d'équipe pour les accès humains. Le secret zéro est résolu par l'IAM de la plateforme, il n'y a pas d'infrastructure à exploiter, et aucune capacité différenciante de Vault n'est requise. Critère de bascule à écrire d'avance : arrivée d'un second fournisseur, besoin de PKI interne ou de credentials dynamiques. 2. Vault, sans hésitation : hétérogénéité multi-cloud et sur site, PKI interne pour du TLS mutuel, credentials dynamiques, et surtout contrainte de localisation des clés qui impose de choisir soi-même la racine de confiance. C'est le profil où les capacités différenciantes justifient le coût d'exploitation. 3. Les secrets natifs du cluster suffisent au besoin décrit, complétés du gestionnaire du cloud pour ce qui vient de lui. Introduire Vault ajouterait un service critique sans traiter de problème existant. Le critère de révision : apparition d'un second cluster, d'une exigence de mTLS interne ou de credentials de bases dynamiques.