TP 9. Déléguer le descellement à un service de clés

Énoncé de travail pratique

Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable

Chapitre déclencheur : 22. Durée : 2 h.

Objectifs

Pratiquer la grammaire de l'Auto Unseal sans dépendre d'un fournisseur cloud réel : configuration d'un seal externe, initialisation produisant des recovery keys, migration dans les deux sens, et démonstration expérimentale de ce que les recovery keys ne font pas.

Prérequis

TP 8 terminé. Chapitre 22 lu.

Environnement

Deux variantes sont proposées, au choix. La variante A utilise un service de clés d'un fournisseur cloud, si vous disposez d'un compte de test : elle est la plus proche de la réalité et implique des identifiants réels. La variante B, recommandée et utilisée par la correction, emploie un émulateur local de service de clés fourni dans le laboratoire : elle produit exactement la même grammaire sans compte ni transfert de juridiction.

Étapes

1. Préparer le gardien. Démarrez l'émulateur et créez une clé dédiée à ce Vault. Notez sa politique d'accès : qui peut demander un déchiffrement avec cette clé.

2. Un serveur neuf. Sur un core-jetable, écrivez une configuration comportant la strophe de seal externe, sans jamais y inscrire d'identifiants d'accès : ceux-ci proviennent de l'environnement d'exécution.

3. Initialiser. Initialisez avec cinq recovery keys et un seuil de trois. Observez la sortie : il n'y a pas de parts de descellement. Vérifiez l'état du serveur : il est descellé sans que personne n'ait rien saisi.

4. Redémarrer. Redémarrez le service et constatez le descellement automatique. Mesurez la durée.

5. La démonstration principale. Arrêtez l'émulateur, puis redémarrez Vault. Constatez que le serveur reste scellé. Tentez alors de le desceller avec les recovery keys et constatez l'échec. Formulez la conclusion en une phrase : c'est l'énoncé le plus souvent mal compris de la partie VII.

6. Ce qu'elles font. Redémarrez l'émulateur, puis utilisez les recovery keys pour ce à quoi elles servent : ouvrez une cérémonie de régénération de token racine, complétez-la, puis révoquez le token obtenu.

7. Migrer vers Shamir. Configurez la désactivation du seal externe en le laissant joignable, redémarrez, et effectuez la migration avec le quorum des recovery keys. Constatez qu'elles deviennent les parts de descellement.

8. Migrer de nouveau. Refaites le chemin inverse, du quorum humain vers le gardien externe, et vérifiez par un redémarrage à blanc.

Résultats attendus

Un serveur descellé sans intervention, un échec de descellement par recovery keys constaté et compris, une cérémonie de régénération conduite avec ces mêmes clés, et deux migrations réussies dans les deux sens, chacune vérifiée par un redémarrage.

Erreurs possibles et diagnostic

Le serveur refuse de démarrer avec une erreur d'accès au gardien : les identifiants d'environnement sont absents ou l'émulateur n'écoute pas. La migration échoue en indiquant une incohérence de seal : l'indicateur de migration a été oublié sur les saisies. Le retour vers le quorum humain échoue : l'ancien gardien a été arrêté trop tôt, alors qu'il doit rester joignable pour déchiffrer une dernière fois. L'initialisation demande des parts alors que vous attendiez des recovery keys : la strophe de seal n'est pas prise en compte, vérifiez le chargement de la configuration.

Questions

1. Rédigez, en trois lignes, ce que vous répondriez à un exploitant qui affirme en pleine panne du gardien : « on va desceller avec les recovery keys ».
2. Comparez la matrice des pouvoirs avant et après la migration : qui peut redémarrer, qui peut autoriser l'exceptionnel, qui peut empêcher tout redémarrage.
3. Pourquoi la capacité de migration inverse est-elle une exigence d'architecture et pas une curiosité ?