Chapitre 31. Scénarios d'attaque et réponse à incident

Objectifs pédagogiques

Dérouler un scénario avec une méthode constante. Reconnaître les signaux de détection propres à Vault. Choisir la coupure proportionnée en connaissant le coût de chacune. Conduire les six scénarios de référence. Énoncer la doctrine de réponse et les cinq questions à trancher à froid. Préparer les artefacts d'incident.

Prérequis

Chapitre 30 (l'audit exploitable, sans lequel aucun scénario n'est détectable), chapitres 12 à 14 (l'arsenal de révocation), chapitres 20 et 23 (le scellement et le levier du gardien), chapitre 29 (la grille que les scénarios éprouvent).

Cours

31.1 La méthode

Un scénario n'est utile que déroulé selon une méthode constante : sept temps, toujours les mêmes, pour que la comparaison soit possible et que rien ne soit oublié sous la pression.

L'hypothèse d'entrée : ce que l'attaquant a obtenu au départ, énoncé sans complaisance. La chronologie : ce qu'il fait, dans l'ordre, avec ce que le système lui oppose. Les signaux : ce que l'installation aurait dû voir, et où. La décision : la coupure choisie, et pourquoi celle-là. Le coût : ce que la coupure casse de légitime, la question qu'on ne veut pas découvrir en la posant. La reprise : comment on revient à un état sain, et ce sur quoi on ne peut pas revenir. L'enseignement : ce qui change après coup.

Un principe traverse les sept : on suppose l'attaquant présent, pas absent. L'exercice ne consiste pas à démontrer que les contrôles tiennent, mais à voir ce qu'il obtient quand ils tiennent.

31.2 L'arsenal de coupure, avec son prix

La table des réponses possibles, du scalpel au disjoncteur. C'est elle qu'on consulte à chaud, et c'est pour cela qu'on l'écrit à froid.

Coupure	Commande	Portée	Coût
Révoquer un token	token revoke -accessor	une session	nul pour les autres
Révoquer une identité	destruction du secret_id, désactivation du rôle	toutes les sessions futures d'un demandeur	limité à ce demandeur
Révoquer par préfixe de baux	lease revoke -prefix	un domaine entier	tous les consommateurs du préfixe tombent
Retirer un droit	réécriture de la policy	une capacité, pour tous ses porteurs	proportionnel à la largeur de la policy
Tourner le compte racine d'un moteur	rotate-root	un identifiant privilégié fuité	irréversible ; exige le compte de secours
Révoquer le token de seal d'un nœud	token revoke sur vault-transit-01	son redémarrage descellé	nul sur le service
Sceller vault-transit-01	operator seal sur le gardien	toute capacité de redémarrage	le vivant continue
Sceller un nœud ou le cluster	operator seal	le service	arrêt total, retour par cérémonie ou gardien

La règle d'emploi est brève : la coupure la plus étroite qui traite la menace, et la plus large seulement quand on ignore l'étendue.

31.3 Scénario 1 : le token applicatif volé

Hypothèse : un attaquant obtient le token de billing sur l'hôte applicatif, par une vulnérabilité.

Chronologie : il l'essaie depuis sa machine et se heurte à la borne d'origine. Il pivote donc et l'utilise depuis l'hôte compromis ; cette fois cela marche, dans les limites des policies. Il lit les secrets de production et demande des credentials de base, qui ne savent que lire et écrire les tables de facturation. Il tente d'autres chemins : trois refus.

Signaux : la rafale de refus sur des chemins voisins, un volume de lectures anormal pour une instance, et un pic de baux sur le rôle.

Décision : révoquer le token par son accessor, détruire le secret_id et faire tourner le rôle, révoquer par préfixe les baux émis pendant la fenêtre.

Coût : les instances perdent leurs credentials et redemandent, quelques secondes. Le redéploiement du secret_id prend un cycle.

Reprise : traiter la vulnérabilité applicative, qui est la vraie cause, reconstruire l'hôte, réémettre.

Enseignement : ce qui a limité les dégâts n'est pas Vault en général, ce sont trois décisions précises, la borne d'origine, le moindre privilège de la policy, et le fait que le compte fabriqué ne savait pas modifier de structure.

31.4 Scénario 2 : l'hôte d'un nœud compromis

Hypothèse : un attaquant obtient les pleins pouvoirs sur un nœud standby.

Chronologie : il lit le stockage, chiffré et inutilisable seul. Il lit la configuration et y trouve le token de seal du nœud, risque assumé au chapitre 23. Avec lui, il peut faire déchiffrer des enveloppes par autounseal-core sur vault-transit-01, ce qui, combiné au stockage qu'il vient de copier, est la paire fatale : il peut reconstruire la clé racine hors ligne. Il lit aussi la mémoire du processus, où un standby descellé garde la clé racine.

Signaux : la connexion d'administration anormale, l'usage du token de seal hors d'un redémarrage, qui est l'alerte majeure du montage, et l'écart entre les journaux locaux et le collecteur si l'attaquant efface.

Décision : isoler la machine, révoquer son token de seal sur vault-transit-01, la retirer du cluster par remove-peer. Puis la décision lourde : considérer le stockage comme exfiltré, donc rekey des recovery keys, rotation du keyring, et rotation de tous les secrets que le stockage contenait. La copie volée reste déchiffrable par la clé racine de son époque, et le rekey ne périme pas les copies passées.

Coût : la rotation des secrets applicatifs est un chantier de plusieurs jours. C'est le coût réel d'une compromission de nœud, et il faut l'avoir chiffré avant.

Reprise : machine reconstruite, répertoire vide, nouveau token de seal, retour au cluster.

Enseignement : c'est le scénario qui justifie la séparation des domaines d'administration. Si le même compte administre les nœuds et le gardien, l'attaquant n'a même pas besoin de la configuration.

31.5 Scénario 3 : le snapshot exfiltré

Hypothèse : une sauvegarde est copiée depuis un partage mal protégé.

Chronologie : l'attaquant possède l'intégralité du coffre, chiffré. Il lui manque la clé racine de l'époque, donc l'accès au gardien ou le quorum de parts. Il attend et cherche à compléter la paire.

Signaux : l'accès anormal au partage, une copie hors fenêtre de sauvegarde, un volume sortant inhabituel.

Décision : la coupure Vault ne sert à rien, le mal étant un fichier ailleurs. La réponse est de périmer la valeur du fichier : rotation du keyring, puis rotation effective des secrets qu'il contient, et si le montage le permet, bascule vers une nouvelle clé d'enveloppe. Plus les mesures d'accès sur le partage.

Coût : celui des rotations, et le rappel utile que les sauvegardes se protègent comme le coffre.

Enseignement : c'est le scénario qui rend concrète la sixième colonne. Le risque résiduel des sauvegardes n'est pas théorique, et son contrôle est organisationnel autant que technique.

31.6 Scénario 4 : l'administrateur retourné

Hypothèse : un détenteur de la policy d'administration agit de mauvaise foi, ou son poste est compromis, ce qui revient au même du point de vue du système.

Chronologie : il ne peut pas lire les valeurs, le raffinement du chapitre 11 l'en empêche, mais il peut se donner le droit : écrire une policy, l'attacher à une entité, l'utiliser. L'escalade légitime, en trois requêtes. Il peut aussi désactiver un dispositif d'audit, tenter une régénération de token racine, qui exige le quorum et se bloque, ou détruire un montage.

Signaux : toute écriture sur les chemins de pouvoir est une alerte de première catégorie. La désactivation d'un dispositif d'audit laisse une trace dans l'autre, ce qui est une des raisons du double flux.

Décision : suspendre l'identité des deux côtés, révoquer ses tokens par accessor, geler les changements de policies, et exiger le quorum pour toute réparation.

Coût : l'administration passe en mode dégradé pendant l'enquête, avec deux paires d'yeux et des opérations ralenties.

Reprise : revue complète des policies et des entités créées ou modifiées sur la fenêtre, comparaison avec le dépôt versionné, rétablissement.

Enseignement : contre l'administrateur, la défense n'est pas l'interdiction mais la détection immédiate et l'irréversibilité limitée : audit externalisé, policies versionnées, quorum pour le pouvoir suprême.

31.7 Scénario 5 : vault-transit-01 compromis

Hypothèse : un attaquant obtient un accès de déchiffrement sur autounseal-core, par compromission de vault-transit-01 ou vol d'un token de seal.

Chronologie : seul, cet accès ne lit rien. Il lui faut un stockage, et il tente donc d'obtenir un snapshot ou un disque.

Signaux : des appels de déchiffrement sans redémarrage de nœud correspondant, la corrélation exacte mise en place au chapitre 23, et des connexions anormales sur vault-transit-01.

Décision : révoquer les trois tokens seal-vault-core-01/02/03, puisqu'on ignore lequel a fuité ; faire tourner autounseal-core par transit/keys/.../rotate, avec attention au plancher de déchiffrement ; et vérifier qu'aucune copie de stockage n'a bougé pendant la fenêtre.

Coût : les redémarrages sont gelés le temps de l'opération, mais le service vivant continue.

Enseignement : la valeur de la sobriété de vault-transit-01, où il n'y avait rien d'autre à voler, et de l'alerte de corrélation, seul signal précoce de ce scénario.

31.8 Scénario 6 : le déni de service par les baux

Hypothèse : pas de vol, une erreur ou un abus. Un consommateur demande des credentials en boucle.

Chronologie : le nombre de baux explose, chaque émission étant une écriture Raft engagée à la majorité. La latence monte, l'actif sature, des élections parasites apparaissent, et la base cible souffre aussi.

Signaux : la courbe des baux par moteur, la latence d'engagement, le compteur d'élections, la charge de la base.

Décision : identifier le demandeur par l'audit, couper au plus étroit en révoquant son identité plutôt que le préfixe entier, puis poser une limite. Les quotas de débit transforment la réponse d'urgence en contrôle permanent. Quand la charge vient des authentifications plutôt que des baux, le levier est différent et relève de la conception : les tokens batch ne sont pas persistés (chapitre 12), donc ne coûtent pas d'écriture Raft, au prix de la révocation unitaire.

Coût : le consommateur fautif s'arrête, les autres continuent.

Enseignement : la disponibilité s'attaque aussi par le bas, sans aucune compromission, et les contrôles préventifs de capacité valent des contrôles de sécurité.

31.9 La doctrine de réponse

Six scénarios, cinq questions à trancher à froid, et c'est la vraie sortie de ce chapitre.

Qui décide ? Une compromission suspectée exige une décision en minutes : le nom du décideur d'astreinte, son suppléant, et la liste des coupures préautorisées. Révoquer un token par son accessor, détruire un secret_id, révoquer un token de seal : préautorisé. operator seal sur le cluster : décision du décideur. Rotation générale des secrets : décision de direction.

Quand coupe-t-on large ? Le critère écrit d'Astrea : dès que l'étendue est inconnue et qu'un accès à la mémoire d'un nœud ou au gardien est plausible.

Que dit-on, à qui ? Les équipes applicatives pour l'impact, la direction pour les décisions lourdes, les tiers et autorités selon les obligations. Préparé, pas improvisé.

Que préserve-t-on ? Les preuves : copies des journaux avant toute reconstruction, horodatages, images mémoire si l'équipe sait les prendre. La reconstruction hâtive détruit l'enquête.

Comment revient-on ? Des critères de retour explicites, cause traitée, secrets tournés, contrôles vérifiés, et un débriefing sous quinzaine dont les actions entrent au registre.

Trois artefacts matérialisent la doctrine : le runbook par scénario, une page chacun ; l'annuaire d'astreinte, porteurs de parts compris ; et le journal de décision de l'incident, tenu en direct, parce que personne ne se souvient de l'ordre des choses le lendemain.

Exemple : l'exercice sur table

Astrea joue le scénario du nœud compromis en salle, deux heures, sans toucher à la production.

Les injections. Le maître d'exercice donne d'abord une alerte de connexion administrative inhabituelle, puis, dix minutes plus tard, l'alerte de corrélation de vault-transit-01. L'équipe met quatre minutes à faire le lien entre les deux, et le débriefing en fera son premier enseignement : l'alerte de corrélation doit remonter en priorité maximale, pas dans le flux général.

Les coupures préautorisées s'enchaînent correctement : isolement réseau, révocation du token de seal, retrait du cluster.

La question qui fait basculer l'exercice arrive ensuite : considère-t-on le stockage comme exfiltré ? Trente-cinq minutes de discussion, précisément parce que la réponse engage un chantier de plusieurs jours. Décision retenue et inscrite au critère de la doctrine : oui par défaut dès que les pleins pouvoirs ont été obtenus sur un nœud descellé, sauf preuve contraire tracée.

Deux découvertes de procédure. Personne ne savait qui pouvait autoriser une rotation générale des secrets applicatifs, ajouté à l'annuaire. Et le runbook de rotation du keyring n'existait pas, rédigé dans la quinzaine.

Le registre conclut par la phrase que l'équipe garde : « Nous avons trouvé nos trous en salle, pas à trois heures du matin, pour le prix de deux heures. »

Sécurité : ce que les scénarios ont révélé

Les contrôles qui ont le plus servi sont les plus petits. Une borne d'origine, une policy sans droit sur les valeurs, un compte de base sans droit de structure, un token de seal par nœud : trois scénarios se jouent sur des décisions de deux lignes prises douze chapitres plus tôt.

La détection précoce tient à deux signaux. La rafale de 403, reconnaissance en cours, et la corrélation entre les déchiffrements de vault-transit-01 et les redémarrages, paire fatale en formation. Ces deux-là méritent une priorité supérieure au reste.

Le coût de la réponse se chiffre avant. Une rotation générale n'est pas une commande, c'est un chantier. Savoir qu'elle prend des jours change la décision de coupure et l'appétit pour la prévention.

Ce qui n'est pas préautorisé sera improvisé. La liste des coupures que l'astreinte peut faire seule transforme trente minutes d'hésitation en trente secondes d'action.

Erreurs fréquentes

Sceller en premier réflexe. L'arrêt total pour un token volé : coût maximal, alors que la menace était traitable au scalpel (section 31.2).

Reconstruire avant de préserver. La machine réinstallée pour repartir vite emporte les preuves, et l'enquête ne saura jamais l'étendue, donc jamais si la rotation était nécessaire (section 31.9).

Croire qu'un rekey suffit après une exfiltration. Les copies passées restent ouvrables par leur époque : ce sont les valeurs qu'il faut faire tourner, pas seulement les gardes (sections 31.4, 31.5).

Oublier le compte de secours avant de tourner un compte racine. La réponse à un identifiant fuité devient un enfermement dehors (sections 31.2, 18.4).

Traiter la saturation par les baux comme un incident applicatif. C'est un déni de service du coffre, qui se prévient par des quotas et se surveille par des courbes (section 31.8).

Des exercices qui réussissent toujours. Un scénario joué pour être réussi ne trouve rien. Le maître d'exercice doit avoir le droit d'injecter l'ambiguïté et le silence (Exemple).

Mise en pratique : jouer, chiffrer, décider

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

1. Déroulez le scénario 1 en version pire cas : le token volé porte la policy d'administration. Reprenez les sept temps et comparez les coûts avec la version du cours.
2. Rédigez la fiche de décision de coupure : chaque coupure de l'arsenal avec sa portée, son coût, et son niveau d'autorisation.
3. Concevez un exercice sur table pour le scénario du snapshot exfiltré : injections, durée, questions à faire trancher, critères de réussite, et les deux trous que vous vous attendez à trouver.

Questions de compréhension

1. Énoncez les sept temps de la méthode et le principe qui les traverse.
2. Classez cinq coupures du plus étroit au plus large, avec le coût de chacune.
3. Dans le premier scénario, quelles décisions antérieures ont borné les dégâts, et à quels chapitres appartiennent-elles ?
4. Pourquoi la compromission d'un nœud impose-t-elle de considérer le stockage comme exfiltré, et quelle conséquence de la partie VII cela mobilise-t-il ?
5. Pourquoi une coupure Vault ne sert-elle à rien dans le scénario du snapshot, et que faut-il faire à la place ?
6. Contre l'administrateur retourné, quelle est la vraie défense, et quels trois mécanismes la portent ?
7. Quel est le seul signal précoce du scénario 5, et pourquoi le montage du chapitre 23 le rend-il possible ?
8. En quoi le dernier scénario est-il une attaque sans compromission, et quel contrôle permanent en sort ?
9. Citez les cinq questions de la doctrine et les trois artefacts qui la matérialisent.

Synthèse

Six scénarios déroulés selon une méthode constante, l'attaquant supposé présent plutôt qu'absent. Ils révèlent trois choses. Que les contrôles décisifs sont minuscules et anciens. Que la détection tient à deux signaux prioritaires, la rafale de refus et la corrélation gardien-redémarrages. Et que la réponse est une affaire de proportion, avec un arsenal ordonné dont chaque cran a un coût connu d'avance, la coupure large réservée à l'étendue inconnue. La doctrine transforme cela en capacité : cinq questions tranchées à froid et trois artefacts qui existent avant l'incident. Déclenche le TP 13 (énoncé en partie XV).