Chapitre 23. Le Transit Seal : un Vault pour desceller un Vault

Objectifs pédagogiques¶

Expliquer le principe du Transit Seal et le motif de souveraineté. Résoudre la récursion et concevoir un descelleur minimal. Monter la chaîne complète : clé, policy, token de seal, configuration, migration. Analyser le modèle de sécurité du montage. Exploiter deux serveurs. Exécuter l'étape 3 du fil rouge.

Prérequis¶

Chapitre 22 (toute la grammaire se réutilise ici), chapitre 16 (Transit, dont le seal est un client), chapitre 7 (l'installation, dont transit-01 est une seconde, en plus petit).

Cours¶

23.1 Le principe, et le motif¶

Le Transit Seal remplace le service de clés externe par ce qu'Astrea sait déjà faire fonctionner : un moteur Transit, hébergé par un second Vault. La clé racine du core est enveloppée par une clé Transit qui vit sur vault-transit-01 ; au démarrage, le core présente l'enveloppe au moteur, qui la déchiffre. Même grammaire qu'au chapitre 22, gardien différent.

Et c'est tout le motif : le gardien est à nous, dans la juridiction, sur le matériel, sous l'audit et les policies d'Astrea. Le pouvoir de faire renaître la clé racine, et le levier d'urgence qui l'accompagne, ne quittent pas le périmètre.

Le coût est annoncé d'emblée : ce gardien, il faut désormais l'exploiter. C'est un serveur de plus, avec sa disponibilité, ses sauvegardes, sa sécurité. Ce chapitre en est le mode d'emploi.

23.2 La récursion, et sa réponse¶

L'objection vient immédiatement, et elle est saine : si transit-01 est un Vault, qui le descelle ? Un troisième Vault ? La régression s'arrête net par un choix d'architecture : le descelleur reste sous Shamir. Ce n'est pas un pis-aller mais un déplacement calculé du quorum humain vers l'endroit où il coûte le moins.

Comparons les deux vies. Le core redémarre souvent, pour des correctifs, des mises à jour, des incidents, et chaque redémarrage bloquait la production : le quorum y coûtait cher. Transit-01 est conçu pour ne presque jamais redémarrer : machine minimale, un seul montage, aucune charge applicative, mises à jour espacées et planifiées. Le quorum s'y mobilise quelques fois par an, à froid, en fenêtre choisie.

Et si le site entier s'éteint, l'ordre de reprise tient en une ligne de runbook : d'abord la cérémonie sur transit-01, puis le core redémarre seul. Le quorum humain n'a pas disparu du système, il a déménagé là où on ne le dérange presque jamais, et les recovery keys du core gardent leur rôle pour l'exceptionnel.

Dernier trait de conception : transit-01 ne porte aucun secret métier. Pas de KV, pas de PKI, rien que la clé d'enveloppe. Sa compromission n'ouvre pas le coffre d'Astrea, puisqu'il faudrait encore le stockage du core, et sa sobriété est sa surface.

23.3 Monter le descelleur¶

[Laboratoire]. Sur transit-01, installé selon le chapitre 7, initialisé sous Shamir 3/2, un quorum plus petit pour une machine plus rare, décision consignée, et amorcé selon le chapitre 8. Puis la spécialisation.

# Le moteur, et la cle d'enveloppe -- gouvernance ch.16 : defauts conserves
vault secrets enable transit
vault write -f transit/keys/autounseal-core

# La policy du seal : DEUX chemins, rien d'autre
vault policy write seal-core - <<'HCL'
path "transit/encrypt/autounseal-core" {
  capabilities = ["update"]
}
path "transit/decrypt/autounseal-core" {
  capabilities = ["update"]
}
HCL

# Le token que le core presentera : orphelin, periodique, a policy unique
vault token create -orphan -policy=seal-core -period=24h -display-name=seal-vault-core-01

Trois choix à défendre. La clé garde les défauts du chapitre 16 et y ajoute une consigne propre à son rôle : son plancher de déchiffrement ne se relève jamais. L'enveloppe courante de la clé racine du core doit rester déchiffrable ; relever le plancher au-dessus de la version qui l'a produite briquerait le redémarrage du core. Cette clé se sécurise par son contrôle d'accès, jamais par sa rotation.

La policy est l'épure du moindre privilège : deux chemins, une clé nommée. Le token du seal ne sait rien faire d'autre.

Le token est orphelin, donc il ne meurt pas avec un parent, et périodique : tant que le processus du core vit, le renouvellement l'entretient indéfiniment. S'il expire, après un arrêt prolongé du core, la réparation est simple et consignée au runbook : régénérer un token sur transit-01, le poser dans la configuration, redémarrer.

Le durcissement réseau clôt le montage : le port de transit-01 n'accepte que le core et le poste d'administration. Le pare-feu dit ce que la policy dit.

23.4 Brancher le core, et migrer¶

[Production]. Opération à fenêtre : redémarrage du core et cérémonie de migration

# /etc/vault.d/vault.hcl -- extrait
seal "transit" {
  address     = "https://transit.astrea.lab:8200"
  token       = "hvs.CAESIJ..."          # le token seal-core (fichier en 0600, root:vault)
  key_name    = "autounseal-core"
  mount_path  = "transit/"
  tls_ca_cert = "/etc/vault.d/tls/astrea-ca.pem"
}

Le fichier de configuration héberge désormais un secret, et l'arbitrage se consigne : ses permissions étaient déjà celles d'un fichier à clés, la policy du token ne sait que chiffrer et déchiffrer une enveloppe, et sa révocation est un geste d'une ligne sur transit-01. Le risque résiduel est accepté, daté, et la rotation du token inscrite au calendrier.

La vérification de l'autorité n'est pas un détail : le core vérifie l'identité du descelleur. Un Transit Seal qui accepterait n'importe quel certificat accepterait n'importe quel gardien.

Puis la migration, à la grammaire du chapitre 22, sauvegarde à froid faite et consignée. Le core redémarre, détecte la migration à faire, et le quorum de Shamir saisit une dernière fois dans ce rôle.

vault operator unseal -migrate     # x3, chaque porteur depuis son poste
vault status
# Seal Type          transit
# Recovery Seal Type shamir
# Sealed             false

Les cinq parts deviennent les recovery keys du core : mêmes enveloppes, nouveau rôle, ligne de registre pour que les porteurs le sachent. Ils n'ouvriront plus les matins, ils autoriseront l'exceptionnel.

La recette de sortie ne se discute pas. Un redémarrage à blanc dans la fenêtre : arrêt, démarrage, serveur descellé sans qu'aucun humain n'ait rien saisi. Puis un second contrôle : couper transit-01, redémarrer le core, constater qu'il reste scellé, rallumer transit-01, constater le descellement au redémarrage suivant. On ne croit pas un montage de seal : on le voit échouer et réussir aux bons endroits.

23.5 Exploiter à deux¶

Le montage vit ensuite selon quatre habitudes.

La supervision double. Les deux points de santé sur monitor-01, avec une alerte spécifique : transit-01 injoignable n'affecte pas le core en marche, mais transforme le prochain redémarrage en immobilisation. C'est une alerte de capacité à redémarrer, une catégorie que la supervision classique ne connaît pas et qu'il faut créer.

Les sauvegardes séparées. Transit-01 a les siennes, petites mais vitales : la perte simultanée du serveur et de sa sauvegarde rendrait l'enveloppe du core indéchiffrable. Ses parts ont leur propre registre et leurs propres coffres, distincts de ceux du core.

Les mises à jour en quinconce. Jamais les deux serveurs dans la même fenêtre. Transit-01 se met à jour pendant que le core tourne, sans impact ; le core se met à jour pendant que transit-01 est stable. C'est l'ordre inverse d'une reprise générale, et les deux se consignent côte à côte dans le même runbook.

Le test trimestriel. Le redémarrage à blanc du core, qui prouve que l'étape 3 tient toujours.

Exemple : l'étape 3, exécutée¶

Fenêtre de deux heures en soirée, annoncée. La séquence consignée.

Préparation. Sauvegarde à froid du core : arrêt propre, copie du répertoire de données, empreinte calculée, coffre. Vérification de transit-01, installé la semaine précédente : Shamir 3/2, clé, policy et token en place, pare-feu recetté.

Migration. Strophe de seal déployée sur le core, redémarrage, cérémonie avec trois porteurs. Quatre minutes. Le type de seal bascule, le serveur est descellé.

Recette en trois actes. Redémarrage à blanc, sans aucune saisie. Test d'échec : transit-01 coupé, le core redémarre scellé, comme il doit. Retour nominal.

Clôture. Lignes de registre : les parts deviennent recovery keys, les porteurs sont notifiés de leur nouveau rôle. Le levier d'urgence est documenté, sceller transit-01 ou révoquer le token gelant tout redémarrage du core. Prochain test trimestriel daté.

La dernière ligne répond à la directrice technique, quatre mois après le redémarrage à l'aube : « Un crash de nuit se résout désormais tout seul en moins d'une minute. Le quorum humain n'a pas disparu : il a déménagé sur transit-01 et dans les recovery keys, aux heures ouvrées. »

Architecture : le montage du fil rouge à l'étape 3¶

  zone d'administration (10.10.10.0/24)          zone Vault (10.10.20.0/24)
  +---------------------------------+            +--------------------------------+
  |  vault-transit-01 (.11)         |            |  vault-core-01 (.11)           |
  |  transit.astrea.lab:8200        |            |  vault.astrea.lab:8200         |
  |  Shamir 3/2 (quorum a froid)    |  unseal    |  seal "transit"                |
  |  transit/keys/autounseal-core   | <--------- |  (token seal-core, CA verifie) |
  |  policy seal-core (2 chemins)   |  encrypt/  |  recovery keys 5/3 (ex-parts)  |
  |  aucun secret metier            |  decrypt   |  toute la charge metier        |
  +---------------------------------+            +--------------------------------+
  pare-feu : 8200 de transit-01 ouvert a vault-core-01 et admin-01 uniquement
  ordre de reprise generale : 1) ceremonie transit-01   2) core seul

Sécurité : le modèle du montage¶

La paire fatale est la copie du stockage du core réunie à un accès à la clé d'enveloppe. Chacune seule est un bloc inerte ; réunies, elles déroulent toute la hiérarchie. La défense est la séparation : machines, zones réseau, et autant que possible domaines d'administration distincts. L'hyperviseur ou l'administrateur unique qui tient les deux serveurs est la paire réunie, et le dossier d'architecture le dit expressément.

Le levier d'urgence a une adresse. Sceller transit-01, ou révoquer le token de seal : tout redémarrage du core devient impossible. C'est le levier du chapitre 22, rapatrié. Il figure au plan de réponse avec ses détenteurs et son coût : le core en marche n'est pas affecté, le core arrêté ne revient plus sans décision.

Le token de seal est un secret de configuration assumé. Policy de deux chemins, permissions strictes, rotation calendaire, révocation d'une ligne. Le risque est petit, borné, écrit : le contraire du mot de passe du chapitre 1 n'est pas l'absence de secret, c'est le secret gouverné.

Transit-01 se durcit par soustraction. Pas d'autres montages, pas d'autres clients, pas d'autres administrateurs que nécessaire. Son audit part vers monitor-01 comme celui du core, et un appel de déchiffrement sans redémarrage du core en face est l'alerte majeure du montage.

Erreurs fréquentes¶

Faire du descelleur un deuxième coffre par commodité. Un montage KV pour l'équipe infra, et le gardien devient un coffre métier sans en avoir l'architecture, en réunissant chez lui ce que le montage devait séparer (sections 23.2, 23.5).

Relever le plancher de déchiffrement de la clé d'enveloppe. L'hygiène du chapitre 16 appliquée à contre-emploi : l'enveloppe courante devient indéchiffrable, et le prochain redémarrage du core est le dernier (section 23.3).

Oublier l'ordre de reprise générale. Après la coupure électrique, on redémarre le core en premier, il reste scellé, et l'on cherche la panne. Transit-01 d'abord (section 23.2).

Un token de seal à policy large. Le core détiendrait alors un pouvoir sur transit-01 qu'il n'a aucune raison d'avoir. Deux chemins, une clé (section 23.3).

Ne pas vérifier le certificat du descelleur. Sans contrôle de l'autorité, un interposé peut se faire passer pour le gardien (section 23.4).

Recetter seulement le cas nominal. Le redémarrage à blanc réussi ne prouve que la moitié. Il faut aussi voir le core rester scellé quand transit-01 manque (section 23.4).

Mise en pratique : le montage sous contrainte¶

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

Rédigez le runbook de reprise après coupure électrique générale du site : ordre, cérémonies, vérifications, et les deux pièges d'ordre qui coûtent une heure chacun.
Le token de seal a expiré pendant un arrêt prolongé du core. Écrivez la procédure de réparation complète, et la mesure de calendrier qui aurait évité l'incident.
L'auditeur demande ce qu'il faut voler, au minimum, pour lire les secrets d'Astrea. Répondez en listant les paires suffisantes et la séparation qui protège chacune.

Questions de compréhension¶

Énoncez le principe du Transit Seal et le motif pour lequel il satisfait la contrainte de souveraineté.
Comment la récursion se résout-elle, et pourquoi ce déplacement du quorum est-il un gain net ?
Justifiez les trois choix du montage côté descelleur : gouvernance de la clé, policy de deux chemins, token orphelin périodique.
Pourquoi le plancher de déchiffrement de la clé d'enveloppe ne se relève-t-il jamais ?
Que vérifie la référence à l'autorité dans la strophe, et que risquerait un montage qui l'omettrait ?
Décrivez la recette de sortie en trois actes, et ce que prouve chacun.
Quelle est la paire fatale du montage, et quelles séparations le dossier doit-il exiger ?
Où est le levier d'urgence, que gèle-t-il, et que laisse-t-il intact ?
Donnez les quatre habitudes d'exploitation à deux serveurs, et la catégorie d'alerte nouvelle à créer.

Synthèse¶

Le Transit Seal rapatrie la grammaire du chapitre 22 sous le toit d'Astrea : la clé racine du core est enveloppée par une clé Transit d'un second Vault minimal, sans secret métier, avec une policy de deux chemins, un token orphelin périodique et un TLS vérifié. La récursion se résout en déplaçant le quorum humain là où il ne sert que quelques fois l'an, pendant que les parts historiques du core deviennent ses recovery keys. Le modèle de sécurité se ramène à une paire à séparer, un levier d'urgence à adresse connue, et une clé qui se gouverne par l'accès et jamais par le plancher. L'exploitation à deux remplace la cérémonie de l'aube par un redémarrage automatique. L'étape 3 du fil rouge est faite. Déclenche le TP 10 (énoncé en partie XV).