Chapitre 5. Le modèle de sécurité de Vault

Objectifs pédagogiques

Énoncer ce que le modèle place en périmètre et ce qu'il en exclut. Tracer les trois frontières de confiance. Raisonner sur les trois états des données. Caractériser cinq profils d'attaquants. Citer les hypothèses opérationnelles et ce que leur violation coûte.

Prérequis

Chapitre 4, dont ce chapitre reprend le schéma pour y tracer des lignes.

Cours

5.1 Ce qu'est un modèle de sécurité

Un modèle de sécurité est un contrat en trois listes : les menaces contre lesquelles le système protège, celles qu'il déclare hors périmètre, et les hypothèses sous lesquelles le contrat vaut. Les trois comptent également. La première seule serait une plaquette. La deuxième dit ce qui reste à votre charge. La troisième dit ce que vous devez garantir pour que le reste tienne.

Méthode applicable à tout produit de sécurité : chercher d'abord la section des exclusions. Si elle n'existe pas, se méfier. Si elle existe, la traiter comme le cahier des charges de ce qu'il faudra construire autour.

5.2 Le périmètre

Quatre familles de menaces, chacune adossée à un mécanisme du chapitre 4.

L'écoute et l'altération des échanges. TLS, terminé par le listener, couvre la confidentialité et l'intégrité du trafic. La garantie vaut à proportion de la configuration.

La lecture et l'altération du stockage. Un attaquant qui obtient les données au repos n'obtient que du chiffré, et ne peut pas modifier subrepticement : le chiffrement authentifié rejette l'altération. C'est la garantie la plus forte du modèle.

L'accès sans identité prouvée. Aucune opération significative sans token valide. L'authentification est un préalable mécanique, pas une politique.

L'accès au-delà des droits accordés. Le refus par défaut borne chaque identité à ce qui lui a été ouvert, uniformément, sans chemin de contournement. Que les bornes soient bien choisies reste votre travail : le modèle applique vos policies, il ne les écrit pas.

S'y ajoute une garantie transverse : tout ce qui précède est journalisé, avec le comportement bloquant du chapitre 4.

5.3 Les frontières de confiance

                 FRONTIERE 1 : client <-> serveur
                 protection : TLS + authentification + policies
                          |
   clients  ------------- | ----------------->  +------------------+
   (leur memoire et leurs |                     |  processus Vault |
    pratiques : HORS      |                     |  memoire : zone  |
    perimetre apres       |                     |  de confiance    |
    livraison)            |                     |  ULTIME          |
                          |                     +------------------+
                                                        |
                 FRONTIERE 2 : serveur <-> stockage     |
                 protection : la barriere               v
                                                +------------------+
                                                | disques, snapshots|
                                                | sauvegardes :    |
                                                | NON dignes de    |
                                                | confiance        |
                                                +------------------+

                 FRONTIERE 3 : le processus <-> son hote
                 protection : aucune, par construction.
                 L'hote est DANS la zone de confiance.

La frontière client-serveur est défendue en profondeur : TLS pour le transport, l'authentification pour l'identité, les policies pour les droits. De l'autre côté, le modèle s'arrête net : le secret livré relève du client.

La frontière serveur-stockage est défendue par la barrière, et elle est asymétrique. Confidentialité et intégrité la traversent protégées, la disponibilité non. Le stockage peut être hostile sans que rien ne fuie ; il ne peut pas être absent sans que tout s'arrête.

La troisième frontière n'existe pas. La mémoire du processus, seul endroit où vivent les clés et les données en clair, est protégée par les seuls mécanismes du système d'exploitation. La machine, son noyau et ses comptes privilégiés font partie de la zone de confiance ultime. Il ne peut pas y avoir de cryptographie entre Vault et son hôte : c'est cet hôte qui exécute les instructions de déchiffrement.

5.4 Les trois états des données

Au repos : chiffré par la barrière, intègre, illisible sans la hiérarchie de clés. L'état le mieux protégé. En transit : chiffré par TLS, à proportion de la configuration. En cours d'utilisation : en clair dans la mémoire, nécessairement, protégé par la seule intégrité de l'hôte.

La hiérarchie des risques s'en déduit. Voler le stockage rapporte du chiffré. Intercepter le réseau rapporte du chiffré. Lire la mémoire du processus rapporte tout. C'est pourquoi l'attaquant rationnel vise l'hôte.

5.5 Les cinq exclusions explicites

C'est la section la plus importante du chapitre : chaque exclusion se traduit en travail d'architecte.

Le contrôle de l'hôte et l'analyse de la mémoire. Un attaquant disposant de root, ou de toute capacité d'inspecter la mémoire, en extrait les clés de la barrière. Aucune configuration ne prévient cela. Traduction, sur trois plans. Prévention : un hôte dédié à Vault et à rien d'autre, durci, à jour, avec un accès humain réduit ; la liste des personnes pouvant devenir root est la liste des personnes pouvant lire tous les secrets, et elle doit être courte et assumée. Détection : l'audit expédié hors de l'hôte en continu, pour qu'une compromission laisse des traces que l'attaquant ne peut effacer. Limitation : les durées courtes, qui font vieillir vite la récolte d'un instant.

Le client après livraison. Mémoire, journaux et pratiques du consommateur sont hors périmètre. Traduction : chapitre 40 pour l'intégration, durées courtes, et Transit pour ne pas livrer les clés du tout.

L'administrateur légitime aux pleins pouvoirs. Le modèle protège des accès non autorisés, pas de l'usage des pouvoirs accordés. Traduction : le pouvoir suprême se gouverne. Token root révoqué après usage et régénéré sous quorum, droits d'administration découpés, séparation des responsabilités appliquée aux opérateurs, audit hors de leur atteinte.

Les systèmes d'identité amont. Quand Vault fédère un annuaire, un fournisseur OIDC ou l'API d'un cluster, il fait confiance à leurs assertions : un annuaire compromis fabrique des identités que Vault honorera. Traduction : la chaîne de confiance s'étend à ces systèmes, et le choix d'une méthode d'authentification est un choix de tiers.

La disponibilité, seule. Le modèle garantit confidentialité et intégrité. La disponibilité relève de l'architecture que vous construisez. Traduction : les parties VIII et XI sont la moitié du contrat que le modèle vous laisse.

Cinq exclusions : hôte, client, administrateur, amont, disponibilité. Aucune n'est une faiblesse du produit ; chacune est une frontière honnête entre ce qu'un logiciel garantit et ce qui appartient à l'architecture.

5.6 Les cinq profils d'attaquants

Pour chacun, trois questions : que voit-il, que peut-il faire, qu'est-ce qui l'arrête.

L'attaquant réseau externe, sans credential. Il voit l'existence du service, son certificat, les chemins non authentifiés. Il peut tenter l'API à l'aveugle, chercher une vulnérabilité du serveur, saturer. L'arrêtent TLS, l'authentification obligatoire, la segmentation qui réduit qui peut essayer, les quotas, et la mise à jour du serveur. Profil le moins dangereux, à une réserve près : une vulnérabilité logicielle le transforme d'un coup en profil suivant.

L'attaquant en position d'interception. Il voit des flux TLS, c'est-à-dire rien, si TLS est bien configuré des deux côtés. Il peut tenter sa chance sur la configuration : un client qui ne vérifie pas le certificat, un tls_disable de laboratoire oublié, une autorité de confiance trop large. Ce profil mesure la distance entre « nous avons TLS » et « TLS est vérifié partout ».

Le client compromis. Il obtient très précisément ce que les policies du token accordent. C'est ici que se récolte le moindre privilège semé au chapitre 2 : un token billing-kv volé lit les secrets de billing, incident réel, périmètre borné, rotation ciblée. L'arrêtent la portée des policies, décidée avant le vol, les durées de vie, les restrictions d'origine, la détection dans l'audit et la révocation préparée à froid. C'est le profil le plus fréquent, et le plus travaillé par ce cours.

L'interne malveillant. Techniquement identique au précédent ; la différence est temporelle et sociale. Il a le temps, la légitimité apparente et la connaissance du système ; il peut demander des élargissements plausibles et choisir son moment. L'arrêtent le moindre privilège tenu dans la durée, la séparation des responsabilités sur les opérations terminales, et un audit nominatif hors de sa portée. Si l'interne malveillant est l'administrateur aux pleins pouvoirs, on retombe sur l'exclusion précédente : la réponse est la gouvernance, pas un mécanisme.

L'attaquant maître de l'hôte. Il voit tout : la mémoire, donc les clés, donc l'intégralité des données. Rien ne l'arrête dans le modèle. La compromission root de l'hôte est une compromission totale du Vault. Ce qui reste est de l'encadrement : prévenir, détecter par un audit déjà parti ailleurs, borner dans le temps. Le chapitre 31 déroule ce scénario jusqu'à la question qui fâche : que faut-il faire tourner après, et la réponse est « tout ce que ce Vault a jamais su ».

Un sixième profil traverse les autres : le voleur de données au repos. Il est le seul contre lequel la garantie est presque absolue, à une condition qui occupe toute la partie VII : que le mécanisme de scellement n'ait pas été emporté dans le même sac. Un snapshot volé avec de quoi reconstituer la clé racine n'est plus du chiffré, c'est un Vault portable. La règle qui en découle, jamais les sauvegardes et le matériel de scellement dans le même domaine de compromission, sera récoltée aux chapitres 21, 23 et 33.

5.7 Les hypothèses opérationnelles

Chacune, violée, fait tomber un pan du modèle.

Un système d'exploitation sain, à jour, durci. Chaque vulnérabilité locale est une vulnérabilité de Vault. L'hypothèse emporte mises à jour, surface minimale, comptes réduits et confinement (chapitre 30).

Une mémoire qui ne se retrouve pas sur disque. Si le système pagine la mémoire ou l'écrit dans un vidage de crash, le clair atterrit au repos, hors de la barrière. Deux mesures : interdiction des vidages mémoire, et traitement de l'espace d'échange. Précision documentée qui surprend : Vault sait verrouiller sa mémoire contre la pagination, mais avec le stockage intégré, la recommandation officielle est de désactiver ce verrouillage et de désactiver l'échange au niveau de l'hôte, les données Raft transitant de toute façon par le disque et le verrouillage total d'un processus à forte empreinte créant ses propres pathologies. Règle pour le fil rouge : stockage intégré, donc pas d'échange sur l'hôte et disable_mlock assumé.

Une horloge juste. Baux, durées de tokens, validité des certificats, fenêtres des assertions : le temps est partout un paramètre de sécurité.

TLS réellement vérifié, des deux côtés. L'hypothèse silencieuse de la frontière 1. Toute la valeur du profil « interception » se joue là.

Des humains et des procédures à la hauteur des pouvoirs terminaux. Détenteurs de fragments joignables et exercés, registre tenu, gestes répétés à froid. C'est une hypothèse sur l'organisation, pas sur le logiciel.

Exemple : le premier serveur d'Astrea, passé au modèle

Le futur vault-core-01, tel qu'il sortira de la partie III : un nœud unique, stockage Raft local, scellement Shamir, billing pour seul client.

Actifs : les secrets de billing, la hiérarchie de clés en mémoire, les cinq fragments remis à cinq personnes, le journal d'audit.

Frontières : billing vers serveur, protégée par TLS, AppRole et la policy billing-kv ; serveur vers disque, protégée par la barrière ; processus vers hôte, non protégée, ce qui fait de la liste des root de la machine la vraie liste d'accès aux secrets.

Exclusions applicables : l'hôte, qui impose une machine dédiée et un audit déporté dès le premier jour ; l'administrateur, qui impose la doctrine du token root du chapitre 8 ; la disponibilité, qui reste entière puisqu'un nœud unique ne tolère aucune panne.

Risques résiduels à ce stade : nœud unique sans reprise éprouvée ; audit local uniquement ; fragments détenus sans cérémonie formalisée. Les trois sont datés et traités respectivement aux parties VIII, X et VII.

Sécurité : gouverner ce que le modèle ne couvre pas

Une exclusion documentée n'est pas un risque traité. L'organisation reste responsable d'encadrer chaque zone par d'autres moyens : liste courte des administrateurs, séparation des domaines, journalisation des accès physiques et des consoles de virtualisation. La raison de cette exigence tient en une observation : un attaquant prend le chemin le moins cher, et c'est presque toujours l'exclusion plutôt que la frontière défendue. Un modèle de menaces qui n'inventorie que les frontières techniques rate donc l'essentiel.

Le périmètre évolue avec la configuration. Désactiver TLS, exclure des champs du masquage d'audit ou exposer un point non authentifié déplace la limite sans qu'aucune alerte ne se déclenche. Les décisions de configuration sont des décisions de modèle.

Ce que le modèle promet doit être vérifiable. Une interception qui échoue, un stockage volé illisible, une requête sans identité refusée, une écriture d'audit impossible qui arrête le service : les travaux pratiques les font constater plutôt que croire.

Erreurs fréquentes

Lire le modèle comme une plaquette. Ne retenir que le chiffrement et l'audit en sautant les exclusions, c'est déployer en croyant couvert ce qui est à votre charge.

Traiter la compromission de l'hôte comme un cas d'école. « Si l'attaquant est root, tout est perdu de toute façon » sert à clore le sujet ; le modèle dit l'inverse. C'est parce que tout est perdu que l'hôte mérite le traitement le plus strict.

Confondre « le stockage est chiffré » et « les sauvegardes sont réglées ». Le snapshot est du chiffré, et sa valeur dépend entièrement de la garde du matériel de scellement.

Oublier que la confiance s'importe. Fédérer un annuaire, c'est étendre son périmètre d'analyse à cet annuaire.

Compter sur Vault pour la disponibilité. Elle est explicitement hors périmètre du modèle et relève de l'architecture.

Laisser mlock et l'échange dans un état non décidé. Les deux réglages vont par paire, et leur incohérence écrit potentiellement des clés sur disque.

Mise en pratique : classer, borner, décider

Sans machine. Réponses commentées en fin de partie.

1. Classez chacun des six événements suivants : en périmètre du modèle, avec le mécanisme qui l'arrête, ou hors périmètre, avec la mesure d'encadrement applicable.

a) Un snapshot du stockage exfiltré par un prestataire de sauvegarde. b) Une lecture de la mémoire du processus via un accès root obtenu par une vulnérabilité noyau. c) Un token applicatif rejoué depuis un poste inconnu. d) L'annuaire d'entreprise compromis, produisant des authentifications valides. e) Un opérateur réseau qui capture le trafic entre billing et Vault. f) L'administrateur Vault qui consulte des secrets RH par curiosité.

1. Pour le profil « client compromis », listez les cinq contrôles qui bornent son action et indiquez pour chacun le chapitre qui le construit.
2. « Notre stockage est chiffré, donc un accès root sur l'hôte n'est pas si grave. » Réfutez cette affirmation en trois phrases, en vous appuyant sur les trois états des données.
3. Un collègue propose de ranger les sauvegardes du stockage dans le même coffre que les fragments de Shamir, « pour tout retrouver au même endroit ». Rédigez votre refus argumenté.

Questions de compréhension

1. Quelles sont les trois listes d'un modèle de sécurité, et pourquoi les exclusions sont-elles un cahier des charges ?
2. Citez les quatre familles de menaces en périmètre, chacune avec son mécanisme.
3. Tracez les trois frontières, avec leur protection, et la particularité de la troisième.
4. Associez chaque état des données à sa protection, et déduisez la cible rationnelle d'un attaquant.
5. Énumérez les cinq exclusions et, pour chacune, le chapitre qui y répond.
6. Déroulez le profil « client compromis » et expliquez pourquoi il est le plus travaillé du cours.
7. Pourquoi la compromission root de l'hôte est-elle une compromission totale, et que reste-t-il à faire ?
8. Citez les hypothèses opérationnelles et, pour deux d'entre elles, ce que leur violation coûte.
9. Que devient le voleur de données au repos si le matériel de scellement est emporté avec la copie ?

Synthèse

Le modèle est un contrat en trois listes. En périmètre : écoute et altération des échanges, lecture et altération du stockage, accès sans identité, accès hors droits, le tout journalisé sous peine d'arrêt. Hors périmètre, cinq exclusions qui forment le cahier des charges : l'hôte et la mémoire, le client après livraison, l'administrateur aux pleins pouvoirs, les systèmes d'identité amont, la disponibilité. Trois frontières structurent l'ensemble, dont la troisième n'existe pas. Cinq profils d'attaquants situent les contrôles, et cinq hypothèses opérationnelles conditionnent le tout.