OpenBao et secrets
Aucun secret n'est enregistré en clair dans le dépôt, ne se loge dans une réponse d'API ni dans un journal. La gestion des secrets suit deux paliers. Le premier est le socle, le second est le coffre du profil régulé. À la fin, vous saurez où vit chaque secret, quand OpenBao s'applique et ce qui reste à votre charge (initialisation du coffre, rotation).
Pourquoi OpenBao
Le coffre de secrets précédent était sous licence BSL, incompatible avec le plan de la plateforme, qui exige des licences permissives. Il a été retiré (décision DEC-34-008). Son remplaçant est OpenBao (MPL-2.0, Linux Foundation). Les variables de configuration portent le préfixe natif BAO_*. OpenBao est le coffre actuel du palier régulé.
Deux paliers
| Palier | Mécanisme | Quand |
|---|---|---|
| 1. Socle | sops + age : secrets chiffrés, versionnés, déchiffrés vers l'environnement au déploiement | toujours ; fonctionne sans serveur, y compris hors ligne |
| 2. Coffre à l'exécution | OpenBao : lecture des secrets au démarrage et à la demande | dès que BAO_ADDR est défini |
Quand OpenBao est configuré, chaque secret présent dans le coffre remplace la valeur issue de l'environnement. Un secret absent garde sa valeur d'environnement. Une erreur réelle du coffre (injoignable, authentification refusée) arrête le démarrage : un déploiement régulé ne doit pas démarrer en silence sur des valeurs périmées.
Si BAO_AUDIT_REQUIRED est vrai et qu'aucun journal d'audit n'est actif côté coffre, le démarrage est refusé. L'audit de lecture des secrets est une exigence NIS2 et DORA pour le profil régulé.
Le coffre
OpenBao est défini aux deux niveaux du dépôt : service du plan de la plateforme et unité Quadlet de production (stockage Raft persistant, TLS, journal d'audit déclaratif, conteneur sans privilège, publication sur l'interface locale seulement).
Le coffre ne s'amorce pas lui-même. Son initialisation, la répartition des clés de descellement et l'ensemencement suivent un guide d'exploitation exécuté par le titulaire. Cette cérémonie est une procédure humaine.
Secrets de base gérés par le recouvrement : clé de signature des jetons, mot de passe de la base, URL de connexion à la base, mot de passe SMTP, clé d'API de la base vectorielle, mot de passe de Valkey.
Secrets des clients et des connecteurs
- Les identifiants de services externes saisis par un client sont chiffrés au repos en AES-256-GCM. La valeur n'est jamais renvoyée : l'API ne retourne qu'une valeur masquée.
- Les secrets d'un connecteur sont résolus à la requête, par organisation, et n'existent en mémoire que le temps de l'appel. Il n'y a pas de cache de secrets à auditer.
- Pour le domaine de santé, la résolution passe par OpenBao.
Rotation
- Les secrets du coffre se renouvellent selon le guide d'exploitation. Pour la clé de chiffrement des données de santé au repos, une procédure sans interruption existe : l'ancienne clé reste disponible en lecture le temps du changement.
- Après une rotation, le serveur relit ses secrets au redémarrage.
- Un identifiant client se remplace par l'API des identifiants, par l'utilisateur concerné.
Bonnes pratiques
- Aucun secret dans le code source, les images, les journaux ni les réponses d'API.
- Des journaux caviardés pour les valeurs sensibles.
- Un secret par usage et par organisation.
- Activer l'audit de lecture du coffre en profil régulé.
- Ne jamais coller une valeur de secret dans un ticket, un message ou un document.
Lacunes assumées
- Le recouvrement par OpenBao concerne les six secrets de base listés plus haut. Il n'est pas un coffre pour tout.
- La clé maître des agents de sauvegarde est protégée par une enveloppe AES-256-GCM adossée à la racine des jetons. Sa migration vers sops + age ou OpenBao est tracée, pas finie.
- Le chiffrement applicatif des données de santé au repos est actif en production :
PHI_AT_REST_KEYdoit être fournie, sinon le démarrage est refusé. Il couvre les colonnes qui passent parphi_crypto; l'étendue sur toutes les données de santé n'est pas établie par le dépôt. Le chiffrement du disque reste documenté comme palier de fond.
Voir aussi
- Architecture de confiance zéro — classification des données et protections au repos, contrôle par contrôle
- Réponse aux incidents — révoquer et renouveler un secret compromis pendant le confinement
- Sécurité — clés de durcissement, chiffrement et contrôles au démarrage, fichier par fichier
- Variables d'environnement — variables du coffre et clés de durcissement lues par le backend
- Conformité NIS2 — exigences de cryptographie et d'audit du profil régulé