Secrets, clés de chiffrement et coffre-fort IT

Cette page décrit, du point de vue de la sécurité, où vivent les secrets de la Navin Platform, qui peut les écrire, les lire ou les révéler, comment les clés tournent et ce que l'audit en garde. L'amorçage d'OpenBao et la liste des entrées des services tiers sont dans ../operations/secrets.md ; elles ne sont pas répétées ici.

English version: en/secrets-vault.md

Vue d'ensemble

Magasin	Contenu	Qui écrit	Qui lit en clair	Code
Secrets du tenant	Clés de fournisseurs, jetons d'outils et de connecteurs	tenant_admin, security_officer, developer (ses secrets)	Le serveur seulement, jamais l'API	eai.domains.secrets
Clés de chiffrement du tenant	DEK par clé et par version, emballées	tenant_admin, security_officer	Le serveur (chiffrement d'enveloppe)	eai.domains.privacy
Coffre-fort IT	Identifiants des services installés pour la plateforme	platform_admin	platform_admin, par révélation auditée	eai.domains.platform_manager.vault
Clés de la plateforme	Clé de la Context Authority, clé des sceaux d'audit, KEK des charges d'audit, clé de signature des bundles	L'opérateur, dans OpenBao ou le HSM	Jamais renvoyées	eai.domains.context, eai.domains.evidence, eai.crypto.kms

Secrets des tenants

• API en écriture seule : POST /v1/secrets (chemin et valeur), GET /v1/secrets (métadonnées : chemin, moteur, version, auteur, dates), DELETE /v1/secrets/{path}. La valeur n'est jamais renvoyée. Un developer ne remplace ni ne supprime que les secrets qu'il a écrits (403 sinon).
• Moteur : OpenBao KV v2 quand EAI_OPENBAO_URL est défini (montage EAI_OPENBAO_KV_MOUNT), sinon chiffrement local AES-GCM avec une clé par tenant dérivée par HKDF de la clé maîtresse (EAI_MASTER_KEY, ou générée une fois et gardée dans eai.platform_keys), le chemin étant la donnée associée. Une panne du moteur répond 502 secret_backend_error.
• Les autres domaines lisent un secret côté serveur (read_secret) ; les outils, MCP et connecteurs reçoivent une référence, jamais la valeur dans le prompt.
• Les références de la forme openbao:<chemin kv>#<champ> désignent une clé de la plateforme sans l'exposer (EAI_CONTEXT_SIGNING_KEY_REF, EAI_AUDIT_SEAL_SIGNING_KEY_REF, EAI_LITELLM_MASTER_KEY_REF).
• Identifiants de base de données dynamiques : eai.integrations.openbao.database_creds demande un identifiant temporaire au moteur de secrets base de données d'OpenBao, et revoke_lease le révoque aussitôt.

Clés de chiffrement (transit)

• POST /v1/encryption/keys crée une clé de tenant (nom, usage) ; GET /v1/encryption/keys les liste ; POST /v1/encryption/keys/{key_id}/rotate ajoute une version. Rôles d'écriture : tenant_admin, security_officer.
• Chaque version est une DEK aléatoire emballée (eai.encryption_key_versions) par OpenBao Transit (openbao-transit, montage EAI_OPENBAO_TRANSIT_MOUNT) ou par la clé locale du tenant. Le chiffré (eaienc1) nomme la clé et la version : les anciennes données restent lisibles après une rotation.
• POST /v1/encryption/encrypt et POST /v1/encryption/decrypt chiffrent et déchiffrent à la demande. Création, rotation, chiffrement et déchiffrement sont audités (encryption.key.create, encryption.key.rotate, encryption.encrypt, encryption.decrypt).
• EAI_KMS_PROVIDER choisit l'interface de clés de eai.crypto.kms : openbao (Transit), pkcs11 (HSM du client, avec EAI_KMS_PKCS11_MODULE, EAI_KMS_PKCS11_TOKEN_LABEL, EAI_KMS_PKCS11_PIN_FILE) ou none. Toute erreur du HSM lève kms_unavailable et l'appelant échoue fermé. Ce que le client doit fournir : identity-policy-plane.md.

Clés de la plateforme

Clé	Réglage	Exigence en production
Signature de la Context Authority (Ed25519 ou ECDSA P-256)	EAI_CONTEXT_SIGNING_KEY_REF	Référence OpenBao obligatoire ; EAI_CONTEXT_SIGNING_KEY en clair refusé
Sceaux d'audit (Ed25519)	EAI_AUDIT_SEAL_SIGNING_KEY_REF	Référence OpenBao obligatoire
KEK des charges d'audit	EAI_AUDIT_PAYLOAD_KEK	openbao-transit obligatoire
Signature des exports WORM	EAI_AUDIT_SIGNING, EAI_OPENBAO_AUDIT_SIGNING_KEY	Transit, jamais hmac
Signature des bundles OPA (RS256)	EAI_POLICY_BUNDLE_SIGNING_KEY_FILE, EAI_POLICY_BUNDLE_KEY_ID	Obligatoire avec EAI_OPA_DELIVERY=bundle

La garde de démarrage refuse chaque écart en production (configuration.md). Rotation de la clé de contexte : changer la référence retire l'ancienne clé, qui vérifie encore jusqu'à sa dernière signature plus EAI_CONTEXT_MAX_TTL_SECONDS ; POST /v1/context/keys/{kid}/revoke l'arrête tout de suite.

Coffre-fort IT du Control Plane

Le coffre-fort IT du Control Plane garde les identifiants des services installés pour la plateforme (PostgreSQL, Redis, Keycloak, OpenBao, OpenFGA, OPA, LiteLLM, Qdrant, NATS, Temporal, LiveKit, Opik, ClickHouse, S3, Platform Manager, compte d'installation du portail). Il n'a pas d'écran dans le portail : les administrateurs de la plateforme consultent et modifient les identifiants dans le coffre fort du Navin Manager, et les routes ci-dessous servent aux SDK. Table : eai.it_vault_entries (sql/postgres/V196).

Chiffrement

• Seul le nom du service est en clair (liste, unicité). URL, identifiant, mot de passe et clé d'API forment un seul document JSON scellé en AES-256-GCM, au format v1:<base64 nonce|chiffré>.
• Clé : 256 bits dérivés par HKDF-SHA256 de la clé maîtresse de la plateforme (info it-vault), dédiée au coffre-fort. Nonce aléatoire de 96 bits à chaque écriture. Donnée associée : l'identifiant de l'entrée, donc un document copié sur une autre ligne ne s'ouvre pas (500 it_vault_payload_invalid).
• Table de plateforme, sans donnée de tenant : RLS forcée, politique eai.is_platform().

danger

Changer la clé maîtresse (EAI_MASTER_KEY ou la clé de eai.platform_keys) rend illisibles toutes les entrées du coffre-fort et tous les secrets chiffrés localement. Exportez et ressaisissez les entrées avant tout changement, et sauvegardez la clé maîtresse avec la base.

Qui peut lire, révéler, modifier

Opération	Route	Audit
Lister	GET /v1/platform-manager/vault/entries	non (la liste ne porte ni mot de passe ni clé : has_password, has_api_key)
Lire une fiche	GET /v1/platform-manager/vault/entries/{entry_id}	non (mêmes champs masqués)
Créer	POST /v1/platform-manager/vault/entries	it_vault.create
Modifier	PATCH /v1/platform-manager/vault/entries/{entry_id}	it_vault.update
Supprimer	DELETE /v1/platform-manager/vault/entries/{entry_id}	it_vault.delete
Révéler mot de passe et clé	POST /v1/platform-manager/vault/entries/{entry_id}/reveal	it_vault.reveal
Importer les services installés	POST /v1/platform-manager/vault/import	it_vault.import

Toutes les routes sont réservées à platform_admin. L'audit garde le nom du service, jamais une valeur.

Rotation

Le coffre-fort ne fait pas tourner les identifiants des services : il les garde. Pour une rotation, changez le secret à sa source (OpenBao, puis External Secrets, selon ../operations/secrets.md), puis mettez l'entrée à jour par PATCH. L'import (au démarrage de l'API et par POST /v1/platform-manager/vault/import) n'ajoute que les services absents : une entrée modifiée par un administrateur n'est jamais écrasée, une entrée supprimée revient au prochain import.

Piste d'audit

Événement	Quand
api_key.create, api_key.rotate, api_key.revoke	Cycle de vie d'une clé d'API
encryption.key.create, encryption.key.rotate, encryption.encrypt, encryption.decrypt	Clés de chiffrement du tenant
it_vault.create, it_vault.update, it_vault.delete, it_vault.reveal, it_vault.import	Coffre-fort IT

Les actions secret.* et api_key.* font partie de la sélection par défaut envoyée au SIEM (EAI_SIEM_FORWARD_ACTIONS). Recherche : GET /v1/audit/events.

Procédures liées

• Clé d'API divulguée : runbooks.md.
• Rotation de clés dans OpenBao : runbooks.md.
• Durcissement : hardening.md.