Chapitre 22. L'Auto Unseal : déléguer la garde à un service de clés
Objectifs pédagogiques¶
Expliquer ce que l'Auto Unseal délègue exactement. Configurer un seal externe et initialiser sous ce régime. Définir le rôle des recovery keys et énoncer ce qu'elles ne font pas. Analyser le déplacement du bouton d'urgence. Conduire une migration de seal dans les deux sens. Situer les seals matériels de l'édition Enterprise.
Prérequis¶
Chapitre 20 (la mécanique, dont l'Auto Unseal ne change qu'un maillon), chapitre 21 (le quorum, dont il déplace la charge), chapitre 5 (les frontières de confiance, qui gagnent un acteur externe).
Cours¶
22.1 Ce qui est délégué, et ce qui ne l'est pas¶
L'Auto Unseal ne remplace qu'un maillon de la hiérarchie, mais le maillon décisif : la garde de la clé racine. Au lieu d'être partagée en points de Shamir, la clé racine est chiffrée par une clé externe, celle d'un service de clés géré, et rangée ainsi enveloppée dans le stockage. Au démarrage, Vault présente l'enveloppe au service, qui la déchiffre : la clé racine revient en mémoire sans aucun humain.
Tout le reste est inchangé. La barrière, le keyring, les données, les tokens : un attaquant qui copie le stockage fait toujours face au même bloc chiffré.
Ce qui a changé est la réponse à une seule question : qui peut faire renaître la clé racine ? Hier, trois humains sur cinq. Désormais, quiconque peut faire exécuter une opération de déchiffrement par cette clé, c'est-à-dire la politique d'accès du service, ses identités, ses rôles de machines, ses administrateurs. Le quorum n'a pas disparu, il a été remplacé par une politique d'accès chez un tiers. Toute l'analyse de ce chapitre découle de cette phrase.
22.2 Configuration et initialisation¶
La délégation tient dans une strophe. [Démonstration]
# /etc/vault.d/vault.hcl -- extrait
seal "awskms" {
region = "eu-west-3"
kms_key_id = "arn:aws:kms:eu-west-3:111122223333:key/9f3a..."
}
Deux disciplines dès ces quatre lignes. Les identifiants d'accès ne s'écrivent pas dans le fichier : le processus les trouve dans son environnement d'exécution, selon les mécanismes natifs du fournisseur. Un secret d'accès en clair dans la configuration recréerait le chapitre 1 dans le fichier le plus sensible du serveur. Et la clé est dédiée : une clé pour ce Vault, sa politique d'accès réduite au rôle de la machine et aux administrateurs de crise, jamais la clé générale du compte.
L'initialisation change alors de visage.
vault operator init -recovery-shares=5 -recovery-threshold=3 \
-recovery-pgp-keys="nadia.asc,karim.asc,lea.asc,marc.asc,sofia.asc"
# ...
vault status
# Seal Type awskms
# Recovery Seal Type shamir
# Sealed false
Pas de parts de descellement : le serveur démarre descellé, et l'initialisation produit à la place des recovery keys, cinq parts au seuil de trois, chiffrées comme au chapitre 21. Leur rôle est si souvent mal compris qu'il mérite sa propre section.
22.3 Les recovery keys : ce qu'elles font, ce qu'elles ne font pas¶
Les recovery keys ne descellent pas. C'est l'énoncé le plus contre-intuitif de la partie. Elles ne sont pas des parts de la clé racine, celle-ci étant gardée intégralement par le service externe. Si ce service est indisponible ou la clé détruite, aucune réunion de recovery keys ne rouvrira le serveur.
Ce qu'elles sont : le quorum d'autorisation des opérations sensibles, celles qui, sous Shamir, exigeaient les parts. Trois usages. Ouvrir une cérémonie de régénération de token racine, la mécanique du chapitre 20 étant identique. Rekeyer les recovery keys elles-mêmes au départ d'un porteur, la cérémonie du chapitre 21 à l'identique. Et autoriser une migration de seal.
Autrement dit, l'Auto Unseal sépare deux pouvoirs que Shamir confondait : le pouvoir de redémarrer, désormais mécanique, et le pouvoir d'autoriser l'exceptionnel, toujours humain. La conséquence de gouvernance est directe : les recovery keys se traitent avec toute la discipline du chapitre 21, car le jour où elles servent est précisément un jour de crise.
22.4 Le bouton d'urgence a déménagé¶
Trois propriétés opérationnelles changent, et chacune se prépare.
Le scellement ne tient plus que jusqu'au redémarrage. La commande efface bien la clé racine de la mémoire, mais un attaquant capable de redémarrer le service obtient un descellement automatique. Le scellement d'urgence reste utile, il coupe l'instant, mais il n'est plus un état stable.
Le vrai levier est chez le fournisseur : suspendre la clé, ou retirer à l'identité de la machine le droit de déchiffrer. Voilà ce qui garantit désormais qu'aucun redémarrage ne rouvrira. C'est un chemin de pouvoir hors de Vault, à inscrire au registre avec ses détenteurs, sa procédure et son délai de nuit, et au plan de réponse.
La disponibilité du gardien entre dans la vôtre. Le serveur en marche n'en dépend pas au fil de l'eau, mais tout redémarrage en dépend : une panne de région pendant une fenêtre de maintenance transforme un redémarrage de routine en immobilisation. Et la destruction de la clé est la perte totale et définitive du stockage : les protections du fournisseur, délai de suppression obligatoire et verrouillage de politique, se configurent le premier jour. L'alerte sur toute planification de suppression est la plus importante du montage.
22.5 Migrer un seal¶
Le seal se change dans les deux sens, et c'est ce qui rend la compétence précieuse : elle est aussi la porte de sortie.
[Production]. Opération à fenêtre : redémarrage et cérémonie requis
Le sens aller, de Shamir vers le service externe : sauvegarde préalable du stockage, consignée ; ajout de la strophe à la configuration ; redémarrage, Vault détectant qu'il est initialisé sous Shamir et attendant. Puis chaque porteur saisit sa part avec l'indicateur de migration.
Au quorum, Vault ré-enveloppe la clé racine sous la clé externe, et les parts deviennent les recovery keys : mêmes valeurs, nouveau rôle, ligne de registre obligatoire pour que personne ne l'ignore. Vérifications de sortie : le type et l'état de scellement, puis un redémarrage à blanc dans la fenêtre. Le premier descellement sans humains se constate, il ne se suppose pas.
Le sens retour existe et se répète en laboratoire. La strophe reçoit une directive de désactivation, l'ancien gardien devant rester joignable puisque c'est lui qui déchiffre une dernière fois. Redémarrage, puis le quorum des recovery keys saisit avec l'indicateur de migration : elles deviennent les nouvelles parts de descellement.
Ce chemin de retour est une assurance stratégique contre une panne durable du fournisseur, un changement de conditions ou une exigence nouvelle de souveraineté. La migration entre deux gardiens automatiques suit la même grammaire : l'ancien désactivé mais joignable, le nouveau actif, le quorum de recovery keys avec l'indicateur.
22.6 Enterprise : matériel et haute disponibilité de seal¶
Deux mentions complètent la carte. L'édition Enterprise sait adosser le seal à un module matériel certifié, sur site : la réponse historique des environnements réglementés, avec les exigences d'exploitation d'un tel module. Et ses versions récentes savent configurer plusieurs seals en haute disponibilité, la panne d'un gardien n'empêchant plus le descellement. En édition Community, le gardien est unique, et sa disponibilité se traite par l'architecture.
Exemple : pourquoi Astrea dit non, et apprend quand même¶
La note d'arbitrage, versée au dossier.
L'Auto Unseal résout exactement le problème du redémarrage à l'aube. Mais la contrainte de souveraineté du chapitre 1 le disqualifie : la clé qui fait renaître la clé racine vivrait chez un fournisseur hors juridiction, soumise à son droit, à ses injonctions et à ses pannes. Le pouvoir de redémarrage de tout le système, et le levier d'urgence qui va avec, sortirait du périmètre que l'entreprise s'est engagée à maîtriser.
Décision : non au service externe, oui à la mécanique. Car la configuration, l'initialisation en recovery keys et la migration sont les mêmes gestes que ceux du Transit Seal, qui respecte la souveraineté. Le TP 9 fait donc pratiquer l'Auto Unseal sur un service de clés local de laboratoire : l'équipe y apprend, sans compte cloud ni transfert de juridiction, tout ce que le chapitre 23 réutilisera. La note se clôt sur une phrase du registre : « Nous refusons le gardien, pas la grammaire. »
Sécurité : le modèle de menace déplacé¶
La politique d'accès à la clé est le nouveau quorum. Qui peut faire déchiffrer par cette clé peut faire renaître la clé racine. Elle se rédige comme une policy du chapitre 11, nominative, minimale, revue, et ses évolutions s'alertent. L'administrateur du fournisseur entre dans le modèle de menace de Vault.
Deux journaux à croiser. Chaque descellement laisse une trace côté fournisseur et côté Vault. Leur rapprochement détecte l'anomalie : un déchiffrement sans redémarrage légitime correspondant est une alerte majeure, quelqu'un déchiffrant l'enveloppe ailleurs.
Les recovery keys restent une institution humaine. Ni la facilité du redémarrage automatique ni la rareté de leurs usages ne dispensent de la discipline du chapitre 21. C'est même l'inverse : elles ne servent que les jours où tout le reste a échoué.
La porte de sortie se répète. La migration retour se joue en laboratoire tant qu'elle est un exercice. Le jour où elle devient une nécessité, elle doit être un runbook éprouvé, pas une découverte.
Erreurs fréquentes¶
Des identifiants d'accès en clair dans la configuration. Le fichier le plus sensible du serveur hébergerait un secret d'accès au gardien de tous les autres. Les identités ambiantes du fournisseur existent pour cela (section 22.2).
Croire que les recovery keys descellent. Le jour d'une panne du gardien, réunir le quorum n'ouvrira rien, et l'avoir cru retarde la vraie réponse (section 22.3).
Traiter le scellement comme un état stable. Un redémarrage rouvre : le scellement d'urgence se double du levier fournisseur (section 22.4).
Une clé partagée ou supprimable sans délai. Une erreur d'administration devient la perte totale du stockage. Clé dédiée, protections maximales, alerte sur toute planification de suppression (sections 22.2, 22.4).
Migrer sans l'ancien gardien joignable. Le sens retour exige qu'il déchiffre une dernière fois ; le désactiver trop tôt bloque la migration au pire moment (section 22.5).
Oublier l'indicateur de migration. Les saisies échouent ou ne migrent rien, et la confusion s'installe en pleine fenêtre. Il figure dans le runbook, sur chaque commande de chaque porteur (section 22.5).
Mise en pratique : l'analyse avant le geste¶
Sur papier ; réponses commentées en fin de partie.
- Établissez la matrice avant et après : pour chaque pouvoir, redémarrer descellé, autoriser une régénération, empêcher tout redémarrage, détruire définitivement le stockage, qui le détient sous Shamir et qui le détiendrait sous seal externe.
- Rédigez le runbook complet de la migration aller et retour pour un mono-nœud : préparation, commandes, vérifications, critères d'abandon, lignes de registre.
- Le fournisseur annonce une panne de sa région, durée inconnue. Analysez l'impact sur le serveur en marche, sur un redémarrage planifié dans deux heures, et sur une cérémonie de régénération prévue le jour même.
Questions de compréhension¶
- Quel maillon exact l'Auto Unseal remplace-t-il, et que ne change-t-il pas ?
- Par quoi le quorum humain est-il remplacé, et pourquoi cette formulation résume-t-elle le modèle de menace ?
- Pourquoi les identifiants du gardien ne s'écrivent-ils pas dans la configuration, et à quoi ressemble une clé bien née ?
- Énoncez ce que les recovery keys font, leurs trois usages, et ce qu'elles ne font pas, avec la conséquence en cas de panne du gardien.
- Quels deux pouvoirs l'Auto Unseal sépare-t-il, que Shamir confondait ?
- Décrivez le déménagement du bouton d'urgence : ce que devient le scellement, où est le vrai levier, ce que cela ajoute au registre.
- Déroulez les deux migrations : rôle de l'indicateur, devenir des parts, exigence sur l'ancien gardien.
- Que propose l'édition Enterprise en matière de seal, et comment l'édition Community traite-t-elle la disponibilité du gardien ?
Synthèse¶
L'Auto Unseal délègue un seul maillon, la garde de la clé racine, à une clé externe : le redémarrage cesse d'exiger des humains, et le quorum est remplacé par la politique d'accès du gardien. L'initialisation produit des recovery keys qui ne descellent pas : elles autorisent l'exceptionnel et se gouvernent avec toute la cérémonie du chapitre 21. Le bouton d'urgence déménage, la disponibilité du gardien entre dans la vôtre, sa destruction serait la perte totale, et la migration dans les deux sens est la compétence qui rend la délégation réversible. Astrea refuse le gardien étranger au nom de la souveraineté et garde la grammaire. Déclenche le TP 9 (énoncé en partie XV).