Aurabase Logo
aurabasedocs
docs›Services›Vault

Vault

Chiffrement au niveau champ pour les données sensibles d'Aurabase. AES-256-GCM avec clé dérivée par enregistrement (HKDF-SHA256), ou backend HashiCorp Vault transit en production — la même primitive protège les secrets de vos Edge Functions et les secrets internes de la plateforme.

6 min de lecture·Niveau intermédiaire·Révisé le 15 août 2026
#
Vue d’ensemble

Un service de chiffrement, pas un produit séparé

« Vault » n'est pas un service HTTP à part sur le gateway : c'est EncryptionService, une bibliothèque de chiffrement au niveau champ partagée (libs/aura-crypto) que plusieurs services appellent pour protéger des données sensibles avant écriture en base — secrets MFA, jetons fournisseurs OAuth, chaînes de connexion projet, et les secrets de vos Edge Functions.

Ce que vous manipulez concrètement, en tant que développeur, ce sont les secrets par fonction : des paires clé/valeur définies via la CLI ou l'API REST, injectées comme variables d'environnement dans le worker qui exécute votre fonction.

Info
Le nom « Vault » fait aussi référence au produit d'infrastructure HashiCorp Vault, déployé en production comme backend optionnel de ce service (gestion de la clé de chiffrement racine, rotation, credentials Postgres à durée de vie limitée). Les deux sens coexistent : la primitive applicative documentée ici, et l'outil d'infrastructure qui peut la soutenir.
#
Modèle mental

Deux backends, un seul format de lecture

À l'écriture, le service choisit un backend : Vault transit si configuré (préféré — la clé de chiffrement racine ne quitte jamais Vault), sinon un repli AES-256-GCM local avec une clé dérivée par enregistrement via HKDF-SHA256. À la lecture, le format du texte chiffré indique quel backend l'a produit — aucune migration forcée n'est nécessaire pour basculer de l'un à l'autre.

format du texte chiffré
TEXT
vault:v1:AbCdEf...     # backend transit — déchiffré via Vault (KEK jamais exposée)
{"key_id":"v1",         # backend AES-256-GCM local (repli / dev)
 "nonce":"…","data":"…"}
sk_live_51J2x...       # valeur historique non chiffrée (avant activation du chiffrement)
Astuce
Le contexte de dérivation (côté fonctions) est project_id:function_name — le même secret chiffré deux fois pour deux fonctions produit deux textes chiffrés différents, et supprimer/renommer la fonction rend l'ancien texte chiffré illisible par construction.
#
Primitives

Ce que le service fournit

AES-256-GCM
Clé de 32 octets dérivée par enregistrement via HKDF-SHA256 (contexte = project_id:function_name). Nonce 96 bits par écriture.
§ chiffrement local
Backend Vault transit
En production, la KEK ne quitte jamais Vault : chiffrement/déchiffrement délégués à transit/encrypt|decrypt, ciphertext versionné vault:vN:....
§ backend prod
Migration sans coupure
Le déchiffrement détecte le format stocké (vault: → transit, {...} → AES local, texte brut → historique non chiffré) : bascule de backend sans ré-écriture forcée.
§ dual-read
Portée par fonction
Les secrets applicatifs documentés ici sont scopés à une fonction (project_id + nom), injectés au worker Deno via Deno.env.get('CLE').
§ scope
CLI dédiée
aura secrets list/set/unset --function <nom>. Les valeurs ne sont jamais ré-affichées en clair par list.
§ cli
Réutilisé par la plateforme
Le même service de chiffrement protège aussi, côté serveur, les secrets MFA, jetons OAuth et chaînes de connexion (db_url_encrypted, anon_key_encrypted).
§ plateforme
#
Exemples

Trois façons d’écrire, une façon de lire

functions/echo.tsTYPESCRIPT
// Une fois écrit (CLI ou REST), le secret est injecté comme variable
// d'environnement du worker qui exécute la fonction.
Deno.serve(async (req) => {
  const cle = Deno.env.get('STRIPE_SECRET_KEY')
  // ...
})
Astuce
La CLI (aura secrets) et l'endpoint REST dédié (/env) manipulent les mêmes données — les secrets d'une fonction — mais pas nécessairement par le même chemin d'écriture. Voir le point d'attention ci-dessous.
#
Point d’attention

Le chiffrement dépend du chemin d’écriture emprunté

aura-functions expose deux façons de modifier les variables d'environnement d'une fonction : l'endpoint dédié PUT /v1/functions/:projectId/:nom/env (qui chiffre systématiquement via EncryptionService avant écriture), et l'endpoint générique PATCH /v1/functions/:projectId/:nom utilisé pour mettre à jour l'ensemble d'une fonction — code, runtime, env_vars inclus — sans passer par ce chiffrement.

La CLI aura secrets passe par le chemin générique
Vérifié dans aura-cli/src/commands/secrets.rs : aura secrets set/list/unset lisent et écrivent via PATCH /v1/functions/:projectId/:nom, pas via /env. Les valeurs y sont donc stockées telles quelles, sans passer par le chiffrement AES-256-GCM décrit plus haut. Pour un secret réellement chiffré au repos, appelez directement l'endpoint /env.
Chiffrement conditionné à la configuration serveur
Même via /env, le chiffrement dépend de la variable serveur FN_ENV_ENCRYPTION_KEY. Absente ou invalide, aura-functions le signale au démarrage et stocke les valeurs en clair — un comportement dégradé assumé pour le développement local, à proscrire en production.
Dernière mise à jour · 15 août 2026