Chiffrement des données
Chiffrement AES-256-GCM des secrets et des sauvegardes, par enveloppe (DEK + KEK).
Toutes les données sensibles que Revault stocke sont chiffrées au repos en AES-256-GCM, avec une architecture à enveloppe (deux niveaux de clés) et une clé propre à chaque client.
Ce qui est chiffré
| Donnée | Emplacement | Clé |
|---|---|---|
| Token API Okta | Configuration du tenant | DEK du client |
| Clés S3 (access / secret) | Configuration du tenant | DEK du client |
Fichiers de sauvegarde (chaque *.json) | Local ou S3 | DEK du client |
| Mots de passe Revault | Comptes utilisateurs | hachage scrypt (voir Authentification) |
Algorithme
| Paramètre | Valeur |
|---|---|
| Algorithme | AES-256-GCM (chiffrement authentifié) |
| Taille de clé | 256 bits |
| IV / nonce | 96 bits, aléatoire par opération |
| Tag d'authentification | 128 bits |
Le format des données chiffrées est versionné (enc:v1:…) pour permettre des
évolutions futures sans casser l'existant.
Chiffrement par enveloppe (DEK + KEK)
Revault utilise deux niveaux de clés :
DEK — clé de données, par client
Chaque client possède sa propre Data Encryption Key (256 bits). C'est elle qui chiffre directement les tokens, clés S3 et fichiers de sauvegarde. Elle est provisionnée à la volée au premier besoin et mise en cache mémoire quelques minutes.
KEK — clé maîtresse, côté plateforme
La DEK n'est jamais stockée en clair : elle est elle-même chiffrée (« wrappée ») par une Key Encryption Key maîtresse, détenue par la plateforme. Seule la version chiffrée de la DEK est en base.
Conséquence d'isolation : compromettre les données d'un client nécessiterait sa DEK ; chaque client est cryptographiquement séparé des autres.
Chiffrement des sauvegardes
Après l'écriture d'une sauvegarde, chaque fichier *.json est chiffré en
place avec la DEK du client, et un marqueur _encrypted est posé sur le
dossier. Cela vaut pour le stockage local comme S3 :
- en local, les fichiers sur le serveur sont chiffrés ;
- en S3, les fichiers sont chiffrés avant l'envoi — ils arrivent déjà chiffrés dans votre bucket.
Revault ne dépend pas du chiffrement côté bucket (SSE-S3 / SSE-KMS) : la donnée est déjà protégée par Revault. Vous pouvez ajouter SSE par-dessus si votre politique l'exige.
Au moment d'une lecture (exploration, comparaison, restauration), les fichiers sont déchiffrés dans un espace temporaire puis supprimés immédiatement après usage. Rien n'est conservé en clair.
Rotation des clés
- Rotation de la KEK : la plateforme peut introduire une nouvelle KEK et
re-wrapper toutes les DEK des clients dessous. Les données chiffrées par
les DEK ne changent pas (elles restent lisibles), seule l'enveloppe est
renouvelée. Opération idempotente et tracée dans le
journal d'audit (
kek.rotated). - Rotation d'une DEK : possible pour un client, après re-chiffrement de ses payloads.
Bonnes pratiques d'exploitation
- La clé maîtresse (KEK) doit être fournie au déploiement et gérée comme un secret critique (idéalement un coffre / KMS en production). Sa perte rend les données chiffrées irrécupérables.
- Le facteur de coût du hachage des mots de passe utilisateurs doit être relevé pour la production (voir Authentification).