Chapitre 20. Sceller, desceller, régénérer : la mécanique du seal

Objectifs pédagogiques

Décrire ce que le descellement fait, et ce que le scellement défait. Lire l'état du seal dans toutes ses dimensions et réinitialiser une saisie. Décider d'un scellement d'urgence. Conduire une cérémonie de régénération de token racine. Mesurer le coût opérationnel du descellement humain.

Prérequis

Chapitre 6 (la hiérarchie de clés, mise en mouvement ici), chapitre 8 (initialisation et premier descellement), chapitre 4 (les codes de santé).

Cours

20.1 Ce que desceller veut dire

Reprenons la hiérarchie du chapitre 6, car ce chapitre en est le mode d'emploi. Les données sont chiffrées par les clés du keyring, le keyring par la clé racine, la clé racine est protégée par le seal.

Desceller fait une seule chose : remettre la clé racine en mémoire. Avec Shamir, elle se reconstruit à partir du quorum de parts ; avec un seal automatique, elle se fait déchiffrer par le gardien externe. Une fois en mémoire, Vault déchiffre le keyring et la barrière s'ouvre : les données redeviennent lisibles pour le processus, et pour lui seul.

Sceller est l'exact inverse : effacer la clé racine de la mémoire. Le stockage n'a pas bougé, il était chiffré avant et l'est après, mais plus rien ne peut le lire. Le serveur redevient ce qu'un voleur de disque obtiendrait : un bloc opaque qui écoute.

D'où le comportement d'un Vault scellé, à connaître pour les astreintes. Il répond, le processus tournant et le port écoutant, mais refuse tout ce qui exigerait la barrière. Le point de santé rend son code dédié, que la sonde des répartiteurs verra. L'état de scellement se lit sans authentification, puisqu'il faut pouvoir diagnostiquer un serveur qu'on ne peut pas ouvrir. Et l'API de descellement accepte les parts. Tout le reste échoue, les tokens eux-mêmes étant dans la barrière. Scellé n'est pas éteint : c'est fermé à clé de l'intérieur.

20.2 Lire l'état

[Laboratoire]

vault status
# Seal Type       shamir
# Sealed          true
# Total Shares    5
# Threshold       3
# Unseal Progress 1/3
# Unseal Nonce    5f3a...

Chaque ligne a son usage. Le type dit qui garde la clé racine, et c'est la première vérification après toute migration de seal. La progression compte les parts valides saisies ; elle est portée par le serveur, pas par le terminal, de sorte que trois personnes peuvent saisir depuis trois postes. C'est même la bonne pratique : les parts ne se prêtent pas. Le nonce identifie cette tentative de descellement, change à chaque cycle, et empêche les mélanges entre cycles.

Quand une saisie déraille, la remise à zéro est un geste normal.

vault operator unseal -reset

La progression retombe, un nouveau nonce est émis, la cérémonie reprend proprement. Le réflexe s'installe tôt : face à un descellement qui ne monte pas, on ne devine pas, on réinitialise et on recompte.

Dernière précision, qui prendra son sens en partie VIII : l'état du seal est par nœud. Dans un cluster, chaque membre se descelle ; le mono-nœud masque encore cette dimension.

20.3 Sceller : l'arme d'urgence

[Production]. Commande dangereuse : arrêt de service immédiat

vault operator seal

L'effet est instantané : la clé racine est effacée, toute requête en vol échoue, et plus rien ne rouvrira sans quorum.

Deux familles de cas le justifient. Le soupçon de compromission du processus ou de l'hôte : si un attaquant est peut-être dans la mémoire, sceller le prive à la seconde de la clé racine et de tout ce qu'elle ouvre. C'est le geste qui transforme une compromission de serveur en vol de bloc chiffré. La menace physique ou juridique imminente : une saisie de machine, un accès physique non maîtrisé ; sceller avant, c'est ne remettre qu'un coffre fermé.

Le coût est celui du bouton : toute la production qui dépend de Vault s'arrête net, et le retour exige la cérémonie. D'où deux disciplines. L'autorisation : le chemin exige la capability sudo, et la policy qui la porte se distribue plus largement que le descellement. Il faut pouvoir fermer vite ; rouvrir exige le quorum, et l'asymétrie est voulue. La préparation : le scellement d'urgence figure au plan de réponse avec ses critères écrits à froid, parce que c'est une décision qu'on ne veut pas inventer à chaud.

Un contresens à éviter : sceller protège la mémoire et le service vivant. Cela ne protège pas rétroactivement une copie du stockage déjà exfiltrée, qui est protégée par la garde des parts, objet du chapitre 21.

20.4 Régénérer le pouvoir, sous quorum

La doctrine du chapitre 8 a tué le token racine après l'amorçage, et laissé une question : le jour où il en faut un, comment le recréer sans qu'aucune personne seule ne le puisse ? La réponse est une cérémonie, outillée pour que le pouvoir ne s'assemble qu'au dernier moment.

[Laboratoire]

# 1. Le maitre de ceremonie ouvre la session
vault operator generate-root -init
# -> Nonce  : 2f9c...
# -> OTP    : 59SGRzNYWkPqdb...   (il garde l'OTP, et seulement lui)

# 2. Chaque porteur, depuis SON poste, saisit SA part (nonce affiche)
vault operator generate-root
# ... au quorum atteint :
# -> Encoded Token : HDzKGdXm1xEuVM...

# 3. Le maitre de ceremonie decode -- c'est la que le token nait
vault operator generate-root -decode="HDzKGdXm1xEuVM..." -otp="59SGRzNYWkPqdb..."
# -> hvs.xxxxxxxx   (token root)

La pièce maîtresse est le mot de passe à usage unique. Le serveur ne produit jamais le token racine en clair : il produit un token encodé avec ce mot émis à l'ouverture. Celui qui voit l'écran du quorum n'a rien, celui qui n'a que le mot de passe n'a rien. Il faut les deux, et ils sont nés dans des mains différentes.

Le nonce lie toutes les saisies à cette cérémonie, une annulation est possible à tout moment, et chaque étape est une ligne d'audit : la recréation du pouvoir suprême est l'événement le plus tracé du système.

La doctrine se referme comme au chapitre 8 : le token créé fait sa réparation, sous surveillance, puis meurt, et le registre consigne cérémonie, motif, durée de vie, révocation. Deux notes pour la suite : sous seal automatique, la même cérémonie fonctionne avec les recovery keys, et c'est même leur premier usage. Et la cérémonie se répète à blanc une fois par an, parce qu'une procédure de crise qui n'a jamais tourné n'existe pas.

20.5 Le coût humain, regardé en face

Avec Shamir, chaque démarrage du processus exige le quorum : le correctif noyau, la mise à jour, le crash, la coupure électrique. Trois personnes, leurs parts, un canal sûr, à l'heure où l'événement survient.

Les conséquences s'enchaînent. Les fenêtres de maintenance se planifient autour des agendas des porteurs. Les correctifs urgents attendent. L'astreinte de nuit d'un porteur devient un rôle critique de l'entreprise. Et la disponibilité de Vault, dont la partie VI a fait la dépendance de démarrage de toute la production, se retrouve suspendue à la joignabilité de trois humains.

Ce n'est pas un défaut de Vault : c'est le prix, assumé, du choix « aucune machine seule ne peut ouvrir le coffre ». Mais c'est un prix qui se rediscute quand l'infrastructure mûrit, et les deux derniers chapitres de cette partie offrent chacun une manière de le payer autrement.

Exemple : un redémarrage planifié

Correctif noyau critique sur vault-core-01, redémarrage à l'aube pour précéder l'ouverture du service de facturation. La cérémonie mobilise trois cadres.

Le maître de cérémonie vérifie d'abord l'état : scellé au redémarrage, comme attendu. La première part est saisie depuis le poste de sa porteuse, par son tunnel nominatif. La deuxième échoue deux fois : enveloppe correcte, faute de frappe. Réinitialisation, on recompte. Au troisième essai, trois parts valides, le serveur passe descellé, la sonde repasse au vert et les instances applicatives redémarrent.

Onze minutes, hors fenêtre, trois cadres mobilisés à l'aube. La ligne de registre se clôt sur la question de la directrice technique : « Et si c'était un crash un 15 août à trois heures du matin ? » Décision consignée : étudier la délégation du descellement, souveraineté comprise. Les chapitres 22 et 23 sont la réponse à cette ligne.

Sécurité : les pouvoirs du seal

Fermer et ouvrir sont deux pouvoirs asymétriques, et c'est voulu. Sceller doit être rapide et accessible à l'astreinte ; desceller exige le quorum. Inverser l'asymétrie inverserait le modèle de sécurité.

La cérémonie de régénération sépare trois rôles. Les porteurs détiennent les parts, le maître de cérémonie le mot de passe à usage unique, l'audit la trace. La collusion nécessaire pour un token racine clandestin est celle du quorum plus le mot de passe, et toute tentative, même annulée, se lit dans le journal.

L'état de scellement parle sans authentification. Type de seal, progression, version : une reconnaissance mineure offerte à qui atteint le port. Acceptable parce que nécessaire au diagnostic, à connaître parce que visible.

Le scellement protège le vivant, la garde des parts protège le mort. Mémoire compromise, on scelle ; stockage copié, c'est le quorum qui tient.

Erreurs fréquentes

Laisser le token encodé et son mot de passe dans le même canal. Collés dans le même ticket, le token racine est reconstituable par quiconque le lit. Les deux moitiés ne voyagent ni ne se rangent ensemble (section 20.4).

Une régénération sans révocation derrière. La réparation faite, le token traîne : le chapitre 8 à l'envers. La cérémonie inclut sa propre fin (section 20.4).

S'acharner sur une progression bloquée. Une part erronée dans le cycle, et l'on ressaisit en boucle. Réinitialiser, nouveau nonce, recompter (section 20.2).

Sceller pour tester en production. Le test coupe la production réelle et exige une cérémonie pour revenir. Le geste se répète en laboratoire (section 20.3).

Croire qu'un scellement rattrape une exfiltration. Le stockage copié hier est protégé par les parts d'hier, pas par le scellement d'aujourd'hui (sections 20.3, 21.4).

Mise en pratique : trois procédures à écrire

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

1. Rédigez le runbook de descellement d'astreinte : déclencheurs, rôles, canal, étapes, critères de succès, et les deux incidents de séance les plus probables avec leur traitement.
2. Établissez la matrice des pouvoirs du seal : qui peut sceller, qui peut desceller, qui ouvre une cérémonie de régénération, qui détient le mot de passe à usage unique, avec le mécanisme qui porte chaque pouvoir.
3. Concevez l'exercice annuel de régénération à blanc : ordre du jour, artefacts produits, critères de réussite, et ce que l'exercice doit prouver sans créer de risque.

Questions de compréhension

1. Définissez desceller et sceller en termes de hiérarchie de clés, et dites ce qui ne bouge jamais.
2. Que peut-on encore faire sur un Vault scellé, et pourquoi ces exceptions existent-elles ?
3. À quoi servent le nonce et la progression, et quand la réinitialisation est-elle le bon geste ?
4. Donnez les deux familles de cas du scellement d'urgence, son coût, et l'asymétrie voulue des autorisations.
5. Déroulez la cérémonie de régénération : les trois rôles, le mécanisme du mot de passe à usage unique, ce que l'audit en retient.
6. Pourquoi la cérémonie se répète-t-elle à blanc, et comment se clôt-elle en doctrine ?
7. Énumérez ce que le descellement humain coûte à l'exploitation, et pourquoi ce coût est un choix.
8. Que protège le scellement, que protège la garde des parts, et quelle erreur naît de leur confusion ?

Synthèse

Desceller remet la clé racine en mémoire, sceller l'en efface ; le stockage, lui, reste chiffré en toutes circonstances. Un Vault scellé répond mais n'ouvre rien ; son état se lit sans authentification, sa progression se compte par nœud et se réinitialise proprement. Le scellement est une arme à deux cas, au coût d'un arrêt total, avec des autorisations asymétriques à dessein. La régénération de token racine recrée le pouvoir suprême sans jamais le confier à une personne seule, et se répète à blanc chaque année. Reste l'arithmétique : trois humains à chaque redémarrage, et une production suspendue à leur joignabilité.