Auto-unseal et Recovery Keys : comprendre le scellement Vault

Vault protège vos secrets avec un mécanisme de scellement : même si un attaquant accède au stockage, les données restent chiffrées. Cette page vous aide à choisir et configurer la méthode de déscellement adaptée à votre contexte.

Ce que vous allez apprendre

• Pourquoi Vault utilise un mécanisme de scellement
• La différence fondamentale entre Shamir et auto-unseal
• Recovery keys vs unseal keys : quand les utiliser
• Les risques de chaque approche et comment les mitiger
• Ce qui relève de Community Edition vs Enterprise

Pourquoi Vault est “sealed” au démarrage ?

Le problème de sécurité résolu

Vault stocke des secrets sensibles (tokens, mots de passe, clés privées). Même chiffrées, ces données seraient vulnérables si quelqu’un pouvait :

• Voler le disque ou une sauvegarde
• Accéder au stockage Raft/Consul
• Compromettre le serveur Vault

Le scellement garantit que les données restent inutilisables sans une clé qui n’est jamais stockée sur le serveur.

Comment fonctionne le chiffrement Vault

La Root Key est au cœur du système. Elle n’est jamais stockée en clair. Vault doit la “reconstruire” à chaque démarrage.

Ce que le seal ne protège pas

Le scellement protège l’accès aux clés nécessaires pour déchiffrer les données au démarrage. Mais il ne remplace pas :

Protection	Assurée par
Contrôle d’accès aux secrets	Policies / ACL
Traçabilité des opérations	Audit logging
Sécurité du système hôte	Hardening OS
Protection réseau	Firewall, TLS, mTLS
Intégrité du stockage	Chiffrement disque, backups

Glissez pour voir

Une fois Vault déscellé et en service, les données sont accessibles aux utilisateurs authentifiés selon leurs policies. Le seal protège le démarrage, pas le runtime.

Les deux méthodes de scellement

Méthode 1 : Shamir’s Secret Sharing

Principe : la root key est divisée en N parts. Il faut K parts pour la reconstituer (seuil = threshold).

Exemple classique : 5 parts, seuil de 3

Root Key = Part1 + Part2 + Part3 + Part4 + Part5

Pour désceller :
- Admin A fournit Part1  ✓
- Admin B fournit Part3  ✓
- Admin C fournit Part5  ✓ → Vault déscellé

Avantages :

• Contrôle total : pas de dépendance externe
• Sécurité : aucun individu ne peut désceller seul
• Résilience : perte de N-K parts tolérée

Inconvénients :

• Manuel : intervention humaine à chaque redémarrage
• Coordination : réunir K personnes peut prendre du temps
• Pas automatisable : problématique pour les clusters auto-gérés

Shamir : le mode coffre-fort classique

C’est l’équivalent numérique d’un coffre nécessitant plusieurs clés détenues par différentes personnes. Sécurisé mais peu pratique pour l’automatisation.

Shamir en cluster : chaque nœud doit être déscellé

Avec un cluster Vault (plusieurs nœuds), le mécanisme de scellement est indépendant par nœud. Vault ne distribue pas l’état “partiellement unsealed” entre nœuds.

Concrètement :

• Si vous avez 3 nœuds et utilisez Shamir, vous devez fournir les unseal keys sur chaque nœud après un redémarrage complet
• Le leader et les standbys doivent tous être déscellés individuellement
• Cela multiplie la charge opérationnelle par le nombre de nœuds

C’est l’une des raisons principales pour lesquelles auto-unseal est préféré en production sur les clusters.

Méthode 2 : Auto-unseal

Principe : déléguer la protection de la root key à un service externe (KMS, HSM, Transit).

Comment ça marche :

Avantages :

• Automatique : pas d’intervention humaine au redémarrage
• Clusters auto-gérés : compatible Kubernetes, ASG
• Audit : les accès KMS sont loggés
• Rotation : possible sans downtime

Inconvénients :

• Dépendance externe : si le KMS est down, Vault ne peut pas démarrer
• Coût potentiel : utilisation KMS facturée
• Complexité : infrastructure supplémentaire à gérer

Le risque critique de dépendance

Avec auto-unseal, vous dépendez d’un service externe. Si AWS suspend votre compte, si le KMS est en panne, ou si vous perdez l’accès à la clé KMS, Vault est bloqué. Les recovery keys ne permettent pas de récupérer un cluster si le mécanisme de seal est définitivement perdu — même depuis les backups.

Recovery Keys vs Unseal Keys

La confusion courante

Beaucoup confondent unseal keys (Shamir) et recovery keys (auto-unseal). Ce sont des concepts différents avec des usages distincts.

Aspect	Unseal Keys (Shamir)	Recovery Keys (Auto-unseal)
Fonction principale	Désceller Vault	Opérations d’urgence
Utilisées au redémarrage	✅ Oui	❌ Non (c’est le KMS)
Peuvent générer un root token	✅ Oui	✅ Oui
Peuvent resceller Vault	✅ Oui	❌ Non
Permettent le rekey	✅ Oui (d’elles-mêmes)	✅ Oui (des recovery keys)
Critiques pour le fonctionnement	✅ Vitales	⚠️ Importantes mais secondaires

Glissez pour voir

Recovery Keys : pourquoi elles existent

Avec auto-unseal, Vault démarre automatiquement. Mais certaines opérations critiques nécessitent quand même une autorisation humaine :

Opération	Recovery Keys nécessaires
Générer un nouveau root token	✅
Effectuer un rekey (changer recovery keys)	✅
Migration de seal (KMS → autre KMS)	✅
Lecture des recovery keys initiales	❌ (une seule fois à l’init)

Glissez pour voir

Analogie

Unseal keys = clés de démarrage du coffre (nécessaires à chaque ouverture) Recovery keys = clés de secours (pour les opérations d’urgence uniquement)

Pourquoi les recovery keys ne déscellent pas

C’est une décision de sécurité intentionnelle. Les recovery keys ne peuvent pas déchiffrer la root key. Si un attaquant obtient les recovery keys, il ne peut pas :

1. Démarrer un Vault volé (besoin du KMS)
2. Accéder aux secrets sans le KMS
3. Contourner le KMS

Il peut seulement générer un root token sur un Vault déjà déscellé et accessible.

Limite critique des recovery keys

Les recovery keys servent à certaines opérations d’urgence, mais elles ne constituent pas un plan de reprise si le mécanisme d’auto-unseal est perdu. Si le KMS ou la clé KMS disparaît, le cluster ne peut pas être récupéré, même avec les recovery keys et les backups.

Méthodes d’auto-unseal disponibles

Cloud KMS (Community Edition)

Provider	Service KMS	Configuration Vault
AWS	AWS KMS	seal "awskms"
GCP	Cloud KMS	seal "gcpckms"
Azure	Azure Key Vault	seal "azurekeyvault"
Alibaba	Alibaba Cloud KMS	seal "alicloudkms"
OCI	Oracle Cloud KMS	seal "ocikms"

Glissez pour voir

Avantages :

• Intégration native avec le cloud
• Haute disponibilité gérée
• Audit trails inclus
• Disponible en Community Edition

Inconvénients :

• Dépendance au provider cloud
• Latence réseau
• Coûts d’utilisation

Transit (Vault-to-Vault)

Un cluster Vault peut désceller un autre cluster Vault.

Avantages :

• Pas de dépendance cloud
• Contrôle total
• Gratuit (Community Edition)

Inconvénients :

• Complexité : il faut un cluster Vault toujours disponible
• Dépendance circulaire possible
• Le cluster unsealer doit être scellé manuellement (Shamir)

HSM (Hardware Security Module) — Enterprise

L’auto-unseal via HSM (PKCS#11) est une fonctionnalité Vault Enterprise.

Type	Exemples	Notes
HSM cloud	AWS CloudHSM, GCP Cloud HSM	Coût élevé
HSM on-premise	Thales Luna, nCipher	Matériel dédié

Glissez pour voir

Avantages :

• Sécurité maximale (clé ne quitte jamais le HSM)
• Compliance FIPS 140-2 Level 3+

Inconvénients :

• Enterprise uniquement
• Coût très élevé
• Complexité opérationnelle

Résumé CE vs Enterprise

Community Edition : Shamir + auto-unseal via KMS cloud majeurs + Transit Enterprise : tout CE + HSM (PKCS#11) + Seal HA + Seal Wrap

Seal HA — Enterprise

Vault Enterprise 1.16+ introduit Seal HA : la possibilité de configurer plusieurs mécanismes d’auto-unseal pour la résilience.

• Au moins deux seals auto-unseal configurés
• Shamir n’est pas supporté dans ce mode
• Si un KMS est indisponible, l’autre prend le relais

Seal HA réduit le risque de dépendance à un seul service, mais c’est une fonctionnalité Enterprise uniquement.

Quand choisir Shamir vs auto-unseal

Pour la plupart des déploiements de production, HashiCorp pousse vers auto-unseal car il réduit fortement la complexité opérationnelle par rapport à Shamir.

Critère	Shamir	Auto-unseal
Redémarrage automatique	❌	✅
Scaling horizontal	Difficile	✅
Kubernetes-ready	❌	✅
Disaster Recovery	Lent (coordination)	✅ Rapide
Dépendance externe	❌	✅
Sécurité	Élevée	Élevée (différente)

Glissez pour voir

Quand garder Shamir

Shamir reste approprié dans certains cas :

Situation	Pourquoi Shamir
Lab / Développement	Pas besoin d’auto-restart
Politique “zero cloud”	Pas de KMS disponible
Compliance extrême	Aucune dépendance externe tolérée
Environnement air-gapped	Pas de connectivité KMS possible
Budget très restreint	Pas de coût KMS
Cluster unsealer Transit	Le “unsealer” doit être Shamir

Glissez pour voir

Le compromis Transit

Si vous ne voulez pas dépendre d’un cloud KMS mais souhaitez l’auto-unseal, Transit est une bonne alternative. Un petit cluster Vault “unsealer” (Shamir) peut désceller votre cluster principal automatiquement.

Risques et mitigations

Risque 1 : Perte d’accès au KMS

Scénario : Votre clé KMS est supprimée, votre compte cloud suspendu, ou le KMS est down pendant longtemps.

Impact : Vault ne peut pas démarrer. Vos secrets sont inaccessibles, même depuis les backups.

Mitigations :

1. Backups réguliers du stockage Raft (les données restent récupérables si vous retrouvez l’accès KMS)

2. Procédure de migration documentée vers un autre seal/KMS

3. Gouvernance forte sur la clé KMS : protection contre suppression accidentelle, politique de retention, accès restreint

4. Seal HA (Enterprise) : plusieurs seals configurés pour la résilience

En Community Edition

Seal HA n’est pas disponible en CE. Misez plutôt sur la gouvernance du KMS, les sauvegardes, la documentation de migration et les contrôles forts autour de la clé de seal.

Risque 2 : Compromission du KMS

Scénario : Un attaquant obtient accès au KMS.

Impact : Il peut déchiffrer la root key stockée. S’il a aussi accès au stockage Vault, il peut potentiellement déchiffrer les secrets.

Mitigations :

• Accès KMS restreint : IAM strict, least privilege
• Audit logging : surveiller tous les accès à la clé KMS
• Rotation KMS régulière : limiter la fenêtre d’exploitation
• Seal Wrap (Enterprise) : chiffrement additionnel par HSM au runtime

Impact runtime en Enterprise

En Community Edition, l’impact de la disponibilité du KMS se voit surtout au redémarrage. En Enterprise avec Seal Wrap activé, certaines opérations utilisent le mécanisme de seal au runtime — la dépendance est plus forte.

Risque 3 : Perte des recovery keys

Scénario : Les recovery keys sont perdues ou inaccessibles.

Impact : Impossible de générer un nouveau root token si nécessaire. Le Vault fonctionne mais certaines opérations d’urgence sont bloquées.

Mitigations :

• Stockage sécurisé : coffre-fort physique, password manager enterprise
• Plusieurs copies : réparties entre N personnes (threshold K pour rekey)
• Test régulier : vérifier que les recovery keys sont accessibles
• Documentation : procédure claire de qui détient quoi

Mise en place : exemples de configuration

Ne stockez pas les credentials en clair

Les exemples ci-dessous montrent la structure de configuration. En production, n’écrivez jamais vos credentials KMS/HSM/token en clair dans vault.hcl. Utilisez :

• Les identités natives du cloud (IAM roles, instance profiles, workload identity)
• Les variables d’environnement avec env://VAR_NAME
• Les fichiers protégés avec file:///path/to/secret

AWS KMS

seal "awskms" {
  region     = "eu-west-1"
  kms_key_id = "alias/vault-unseal-key"

  # Préférer IAM role attaché à l'instance
  # plutôt que access_key/secret_key en dur
}

IAM Policy minimum :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "arn:aws:kms:eu-west-1:123456789:key/your-key-id"
    }
  ]
}

Recommandation : utilisez un IAM role attaché à l’instance EC2 ou un service account Kubernetes avec IRSA plutôt que des credentials statiques.

GCP Cloud KMS

seal "gcpckms" {
  project     = "my-project"
  region      = "europe-west1"
  key_ring    = "vault-keyring"
  crypto_key  = "vault-unseal-key"

  # Préférer Workload Identity ou service account
  # plutôt que credentials JSON en dur
}

Service Account roles :

• roles/cloudkms.cryptoKeyEncrypterDecrypter

Recommandation : utilisez Workload Identity sur GKE ou le service account attaché à la VM plutôt qu’un fichier JSON de credentials.

Transit

seal "transit" {
  address         = "https://vault-unsealer.corp.local:8200"
  disable_renewal = "false"

  # Mount path du secret engine transit
  mount_path      = "transit/"

  # Nom de la clé
  key_name        = "unseal-key"

  # Token via variable d'environnement
  # Définir VAULT_TOKEN dans l'environnement systemd
}

Prérequis sur le cluster unsealer :

# Activer le secrets engine Transit
vault secrets enable transit

# Créer la clé de déscellement
vault write -f transit/keys/unseal-key

# Créer une policy dédiée
vault policy write autounseal - <<EOF
path "transit/encrypt/unseal-key" {
  capabilities = ["update"]
}
path "transit/decrypt/unseal-key" {
  capabilities = ["update"]
}
EOF

# Créer un token orphelin avec cette policy
vault token create -orphan -policy="autounseal" -period=24h

Wrapping token pour la sécurité

Pour transférer le token au cluster auto-unsealed de façon sécurisée, utilisez un wrapping token à durée de vie courte plutôt qu’un token en clair :

vault token create -orphan -policy="autounseal" -period=24h -wrap-ttl=1h

Unwrap côté cluster cible lors du premier démarrage.

Azure Key Vault

seal "azurekeyvault" {
  tenant_id      = "your-tenant-id"
  vault_name     = "vault-unseal-kv"
  key_name       = "unseal-key"

  # Préférer Managed Identity plutôt que client_id/client_secret
  # use_managed_identity = true (si supporté par la plateforme)
}

RBAC minimum :

• Key Vault Crypto Officer sur la clé

Recommandation : utilisez une Managed Identity attachée à la VM ou au pod AKS plutôt que des credentials applicatifs.

Migration de seal

Il est possible de migrer d’un type de seal à un autre.

Migration = downtime potentiel

La migration de seal nécessite un redémarrage de Vault. L’ancien et le nouveau mécanisme de seal doivent être disponibles pendant la migration. Avec Integrated Storage (Raft), respectez la logique de quorum et la séquence standby/leader. Suivez la documentation officielle pour l’enchaînement exact selon votre version et configuration.

De Shamir vers auto-unseal

1. Ajouter le nouveau seal dans vault.hcl (en plus de Shamir implicite) :

   seal "awskms" {
     region     = "eu-west-1"
     kms_key_id = "alias/vault-unseal-key"
   }

2. Redémarrer Vault : le serveur détecte une migration en attente

3. Exécuter la migration avec le flag -migrate :

   vault operator unseal -migrate

4. Fournir les unseal keys Shamir existantes (threshold requis)

5. Vault génère des recovery keys pour le nouveau seal

6. Sécuriser les recovery keys et supprimer l’ancienne logique Shamir

D’un KMS vers un autre

1. Ajouter le nouveau seal dans vault.hcl en plus de l’ancien :

   seal "awskms" { ... }  # ancien — garder temporairement
   seal "gcpckms" { ... } # nouveau

2. Redémarrer Vault : migration détectée

3. Exécuter la migration :

   vault operator unseal -migrate

4. Fournir les recovery keys existantes (threshold requis)

5. Une fois la migration réussie, supprimer l’ancien seal de la config

6. Redémarrer pour valider la configuration finale

Checklist de sécurité

Pour Shamir

• Nombre de parts adapté (5 recommandé pour la plupart des cas)
• Threshold adapté (3 pour 5 parts)
• Chiffrement PGP des unseal keys à l’initialisation
• Chaque part stockée séparément (personnes/lieux différents)
• Procédure de déscellement documentée
• Drills périodiques pour vérifier la capacité à reconstituer le quorum
• Personnes détentrices identifiées et joignables
• Gestion du cycle de vie des détenteurs (départ, rotation)

Pour auto-unseal

• Clé KMS dédiée (pas partagée avec d’autres services)
• Accès KMS au minimum (least privilege)
• Pas de credentials en clair dans vault.hcl (identité cloud ou env://)
• Audit logging activé sur le KMS
• Protection contre suppression accidentelle de la clé KMS
• Recovery keys générées avec chiffrement PGP
• Recovery keys sécurisées et testées
• Procédure de migration documentée
• Plan B si KMS indisponible (même temporairement)
• SLA du KMS vérifié et acceptable

À retenir

1. Shamir = contrôle total, auto-unseal = automatisation — les deux ont une sécurité élevée, mais des trade-offs différents
2. Recovery keys ≠ unseal keys : elles ne déscellent pas Vault et ne permettent pas de récupérer un cluster si le mécanisme de seal est perdu
3. Pour la plupart des déploiements, auto-unseal offre une meilleure expérience opérationnelle que Shamir
4. Dépendance KMS : risque critique à évaluer et mitiger — perte du KMS = perte du cluster, même avec backups
5. Transit : bonne alternative sans dépendance cloud (mais avec un cluster unsealer à maintenir)
6. HSM et Seal HA : fonctionnalités Enterprise pour les besoins avancés
7. Ne stockez jamais les credentials seal en clair : utilisez les identités cloud natives ou les références indirectes

Prochaines étapes

Installation Vault Configurer le seal lors de l'installation

Vault vs OpenBao Comparer les options de scellement

Éditions CE vs Enterprise HSM et Seal Wrap Enterprise

Page pivot Vault Retour à la vue d'ensemble

×

📖 Voir la documentation →