Chapitre 32. Threat modeling d'une architecture Vault

Objectifs pédagogiques

Distinguer la grille, qui est le livrable, de la méthode, qui est la façon d'y arriver. Adapter les six catégories de STRIDE au vocabulaire de Vault. Conduire un atelier en six temps. Énumérer par frontière plutôt que par composant. Coter sans fausse précision. Transformer chaque menace en contrôle, en signal ou en risque assumé. Maintenir le modèle vivant.

Prérequis

Chapitre 27 (la grille, dont ce chapitre est le mode d'emploi), chapitre 29 (la grille appliquée, matériau de l'atelier), chapitre 31 (les scénarios, qui fournissent l'épreuve de réalité).

Cours

32.1 La grille dit quoi produire, la méthode dit comment

Le chapitre 27 a donné six colonnes et le chapitre 29 les a remplies. Il manque l'essentiel du point de vue de l'ingénieur : comment on obtient ce résultat quand personne ne connaît déjà la réponse.

Une grille remplie par celui qui a conçu le système reflète surtout ce qu'il avait en tête en le concevant. Elle est utile, elle est incomplète, et son incomplétude porte toujours sur les mêmes zones : ce que l'auteur considère comme acquis.

La méthode corrige ce biais par trois propriétés. Elle est reproductible : deux équipes qui l'appliquent au même système arrivent à des inventaires proches. Elle est finie : elle dit quand s'arrêter, ce qui la distingue de la liste qu'on allonge jusqu'à la lassitude. Elle est transférable : elle s'applique au Vault d'Astrea comme à un système découvert le matin même, ce qui en fait la compétence la plus durable de la partie X.

Un mot sur le format, car il décide du résultat. Le threat modeling est un atelier, pas un document rédigé seul : quatre à six personnes, deux heures, un tableau, quelqu'un qui écrit. La composition compte autant que la méthode : l'architecte, un exploitant, quelqu'un qui a lu les journaux en incident, et, place la plus précieuse, une personne qui n'a pas construit le système et dont le rôle est de demander pourquoi.

32.2 STRIDE, traduit en questions Vault

STRIDE est un aide-mémoire de six catégories qui sert à ne pas oublier des familles entières de menaces. Sa valeur n'est pas théorique : c'est une liste de contrôle contre l'angle mort. Traduite au sujet, chaque catégorie devient une question qui se pose devant un flux précis.

Catégorie	Question	Où elle mène
Usurpation	qui peut se faire passer pour un autre ?	méthodes d'authentification, vérification TLS, identité des nœuds
Altération	qui peut modifier données ou messages ?	barrière, TLS, et surtout ce qui configure le système
Répudiation	qui peut agir sans qu'on le prouve ?	audit nominatif hors de portée de l'acteur, et ce que l'audit ne voit pas
Divulgation	qui peut lire ce qu'il ne devrait pas ?	secrets, mais aussi métadonnées, chemins, rythmes, volumes
Déni de service	qui peut empêcher le service ?	baux, disque d'audit, saturation de l'actif, quorum, gardien
Élévation	qui peut obtenir plus qu'accordé ?	les chemins de pouvoir accumulés depuis le chapitre 11

La catégorie de l'altération mérite un mot : la question la plus productive n'y porte pas sur les données mais sur ce qui configure le système, policies, rôles, unités de service, fichiers de configuration, images de machines. Et celle de la répudiation s'étend à ce que l'audit ne voit pas : une modification poussée par la gestion de configuration, un accès par la console d'hyperviseur.

32.3 L'atelier en six temps

Temps 1, cadrer. Ce qu'on modélise et ce qu'on ne modélise pas. Le périmètre s'écrit au tableau avant tout le reste, avec les hypothèses, qui sont exactement les exclusions du chapitre 5. Un périmètre non écrit produit un atelier qui dérive vers la sécurité de l'entreprise entière.

Temps 2, dessiner les flux. Zones, composants, échanges avec leur sens, puis les frontières de confiance tracées par-dessus. L'atelier redessine, parce que le dessin fait apparaître les flux que la matrice avait oubliés. Règle : tout flux dessiné doit correspondre à une ligne de la matrice, et réciproquement. Les écarts sont les premières trouvailles.

Temps 3, énumérer. Pour chaque frontière, on parcourt les six catégories sans filtrer. Une menace peu crédible notée coûte trente secondes ; une menace non dite coûte un incident.

Temps 4, coter. Plausibilité, impact, et, contribution du chapitre 31, une estimation du coût de la réponse.

Temps 5, décider. Chaque menace retenue sort sous l'une de trois formes : un contrôle, un signal, ou un risque résiduel signé. Aucune quatrième forme n'existe, et surtout pas « à surveiller », qui n'engage personne.

Temps 6, consigner. Le document sort dans la semaine : diagramme, tableau des menaces avec leur sort, actions avec propriétaire et date, risques signés. Ce qui n'a pas de propriétaire n'existe pas.

32.4 Énumérer par frontière, pas par composant

Le choix qui décide de la réussite de l'atelier est celui de l'unité d'énumération.

Par composant, la liste est infinie et redondante : chaque serveur ramène les mêmes menaces génériques et l'équipe s'épuise avant d'atteindre les cas intéressants.

Par frontière, la liste est finie par construction, cinq frontières fois six catégories faisant trente cases dont beaucoup se remplissent d'une ligne. Et elle concentre l'attention là où les incidents se produisent : au passage d'un niveau de confiance à un autre.

Deux frontières méritent une vigilance particulière parce qu'elles échappent au réflexe réseau. Celle où Vault est client, base de données, API cloud, fournisseur d'identité, où l'on oublie que la compromission de la cible se retourne contre Vault. Et la frontière humaine et hyperviseur, qui ne se dessine sur aucun schéma de réseau et concentre les scénarios les plus coûteux.

32.5 Coter sans se mentir

La tentation est de multiplier des notes pour obtenir un score. Un score à deux décimales calculé sur des estimations au doigt mouillé donne une fausse précision qui autorise ensuite des arbitrages qu'aucune donnée ne soutient.

La cotation utile est grossière et se défend : plausibilité en trois niveaux, attendu dans l'année, plausible, improbable sans changement de contexte ; impact en trois niveaux, gênant, sérieux, existentiel. Le couple suffit à trier.

La troisième colonne, celle que le chapitre 31 impose, est le coût de la réponse. Une compromission de nœud oblige à considérer le stockage comme exfiltré, donc à ouvrir un chantier de plusieurs jours. Une menace peu probable dont la réponse coûte une semaine mérite plus de prévention qu'une menace fréquente dont la réponse est une commande. C'est ce raisonnement, et non le score, qui produit les bonnes décisions.

Un garde-fou pour finir : une menace dont la réponse serait « on ne sait pas » n'est pas cotée, elle est escaladée. L'incertitude sur la réponse est le signal le plus fiable qu'un travail préparatoire manque.

32.6 Du modèle aux décisions

Un threat model qui ne change rien n'a rien produit, et cela se vérifie objectivement : à la sortie, on doit pouvoir citer au moins un contrôle ajouté, un signal branché ou un risque nouvellement écrit.

Le contrôle ferme la menace ou la borne : il a un propriétaire, une date, et une recette qui prouve qu'il fonctionne.

Le signal admet qu'on ne peut pas fermer la menace mais qu'on veut la voir arriver : il devient une alerte avec son seuil et son destinataire, et n'a de valeur que si quelqu'un sait quoi en faire, ce qui renvoie au runbook.

Le risque résiduel assume : nommé, chiffré si possible, accepté par quelqu'un qui a le droit de le faire, daté, muni d'un critère de révision.

La boucle avec la partie X se ferme ici : le chapitre 30 a fourni les contrôles, le chapitre 31 les scénarios qui les éprouvent, le chapitre 32 la méthode qui relie les deux.

32.7 Maintenir le modèle vivant

Un modèle de menaces se périme comme un dossier d'architecture. Cinq déclencheurs imposent une révision, même courte.

L'activation d'un moteur ou d'une méthode d'authentification, qui ouvre des chemins nouveaux. L'ajout d'un flux ou d'une zone. L'arrivée d'un acteur, prestataire, équipe, fournisseur. Un incident, chez soi ou ailleurs, un avis de sécurité se lisant avec le modèle ouvert. Un changement d'édition ou de version, qui déplace ce que le produit prend en charge.

Hors déclencheur, la révision complète est annuelle et se cale sur la revue anti-dérive du chapitre 29. Enfin, le modèle se relit après chaque exercice sur table : les quatre minutes mises à relier deux alertes sont une information sur le modèle autant que sur l'équipe.

Exemple : l'atelier de threat modeling

Deux heures, cinq personnes, dont l'architecte réseau, qui n'avait jamais travaillé sur Vault et qui pose les questions bêtes.

Le cadrage prend dix minutes : l'architecture cible du chapitre 29, hypothèses reprises du chapitre 5.

Le diagramme est redessiné au tableau plutôt que projeté, et la méthode paie tout de suite : un flux manquait à la matrice. Le serveur de gestion de configuration pousse les fichiers vers les nœuds, le gardien et le répartiteur, et fabrique aussi les machines de remplacement. Personne ne l'avait listé, parce qu'il fait partie du décor. Traité par les six catégories, il produit la trouvaille de la séance : qui contrôle ce serveur peut modifier la configuration des trois nœuds, donc changer la strophe de seal, donc rediriger le descellement. Une élévation de privilège qui contourne toutes les frontières du dessin.

Trois autres apports, plus modestes et tout aussi concrets. En répudiation : l'audit prouve qui a écrit une policy dans Vault, mais rien ne rapproche cette écriture du dépôt versionné où les policies sont censées naître, et un écart serait invisible. En divulgation : les journaux du répartiteur révèlent les rythmes d'activité de billing à qui les lit, et leur accès n'avait pas été restreint. En usurpation : la zone DNS interne, ancre du nom de service, était administrée par une équipe qui n'apparaissait dans aucune liste du dossier.

Les sorties. Deux contrôles : le compte de la gestion de configuration passe sous authentification nominative avec journalisation dédiée, et son droit d'écriture sur la configuration fait l'objet d'une alerte de modification ; les journaux du répartiteur rejoignent le régime d'accès des journaux d'audit. Un signal : une tâche quotidienne compare les policies actives au dépôt versionné, et toute divergence lève une alerte. Un risque résiduel nouveau, R6 : la gestion de configuration reste un chemin d'écriture privilégié vers les nœuds, accepté, mitigé par les deux contrôles, critère de révision fixé à la migration Kubernetes.

Et une ligne au registre que la directrice technique a fait relire à tout le monde : « Le trou trouvé aujourd'hui ne se voyait sur aucun de nos schémas parce qu'il était sur tous nos serveurs. »

Sécurité : la méthode a ses propres faiblesses

L'auto-évaluation converge vers ce qu'on sait déjà. L'équipe qui a construit le système partage ses angles morts. La place réservée à quelqu'un d'extérieur est le seul mécanisme qui corrige ce biais, et elle n'a rien d'une politesse. Le document produit, lui, se gouverne comme le dossier d'architecture (chapitre 29) : diagramme, menaces et risques résiduels forment un plan d'attaque prêt à l'emploi.

Un modèle non daté est un modèle faux. Sans date ni périmètre écrit, il sera lu dans deux ans comme s'il décrivait le système d'alors.

La méthode ne remplace pas les mesures. Le threat modeling énumère et priorise ; il ne prouve rien sur le comportement réel. Les exercices sur table, les recettes de flux et la supervision sont ce qui confronte le modèle au monde.

Erreurs fréquentes

Modéliser des composants au lieu de flux. La liste devient infinie et répétitive, et l'équipe s'arrête avant les cas intéressants (section 32.4).

Chercher un score plutôt qu'une décision. Des notes multipliées produisent une précision que les données ne portent pas (section 32.5).

Sortir de l'atelier avec « à surveiller ». La mention n'engage personne et ne produit rien (section 32.3).

Oublier les frontières non réseau. Les chemins les plus courts vers le coffre ne passent presque jamais par un port ouvert (section 32.4, Exemple).

Faire l'atelier entre concepteurs. Le résultat confirme l'intuition de départ et rate ce qui fait partie du décor (Sécurité).

Refaire le modèle de zéro à chaque révision. L'exercice devient trop coûteux, donc il n'a plus lieu. On révise par déclencheur, en version courte (section 32.7).

Modéliser sans périmètre écrit. L'atelier dérive et n'aboutit sur rien d'actionnable (section 32.3).

Mise en pratique : conduire l'exercice

Sur papier ; réponses commentées en fin de partie.

1. Préparez l'atelier de la future zone Kubernetes : périmètre et hypothèses, participants et rôles, flux à dessiner, et les trois questions que vous poserez en premier.
2. Appliquez les six catégories à la seule frontière où Vault est client de ses cibles, et donnez pour chacune une menace crédible et son sort.
3. Un prestataire vous remet un threat model de trente pages, avec des scores à deux décimales et aucun risque résiduel. Rédigez la note de relecture : ce que vous acceptez, ce que vous rejetez, et les trois questions qui décideront de sa valeur.

Questions de compréhension

1. Pourquoi une méthode est-elle nécessaire alors que la grille dit déjà quoi produire ?
2. Quelles sont les trois propriétés d'une méthode utile, et laquelle rend la compétence transférable ?
3. Traduisez les six catégories en questions Vault, avec un chapitre de rattachement pour chacune.
4. Décrivez les six temps de l'atelier et ce que produit chacun.
5. Pourquoi énumérer par frontière, et quelles deux frontières échappent au réflexe réseau ?
6. Comment coter sans fausse précision, et pourquoi le coût de la réponse entre-t-il dans la décision ?
7. Quelles sont les trois sorties possibles d'une menace retenue, et pourquoi « à surveiller » n'en est pas une ?
8. Citez les cinq déclencheurs de révision.
9. Quelles sont les faiblesses propres de la méthode, et quels mécanismes les corrigent ?

Synthèse

Le threat modeling est l'atelier qui produit la grille, et la méthode vaut plus que le tableau qu'elle remplit : reproductible, finie, transférable à un système qu'on découvre. Six catégories tiennent lieu de garde-fou contre l'angle mort et se posent frontière par frontière, ce qui rend l'énumération finie et la concentre là où les incidents naissent. La cotation reste grossière et honnête, augmentée du coût de la réponse. Chaque menace retenue sort sous l'une de trois formes seulement, avec un propriétaire et une date. L'atelier d'Astrea l'a démontré en deux heures : le chemin d'attaque le plus court passait par un serveur qui n'apparaissait sur aucun schéma parce qu'il était sur tous.