Chiffrement des données sensibles : clé maîtresse, clé de l'organisation et clé de secours

## Objectif Protéger les données sensibles en cas de fuite de la base. Cléa est auto-hébergée : on ne vise pas le chiffrement de bout en bout. On vise un dump de base illisible sans une clé que l'hébergeur garde hors de la base. ## Décisions prises - Pas de chiffrement de bout en bout pour l'instant. - Une clé maîtresse choisie par l'hébergeur, jamais stockée en base. - Une clé de données par organisation, enfermée par la clé maîtresse. - Une clé de secours (paire de clés) pour retrouver les données si la clé maîtresse est perdue. - Toute donnée sensible des futurs modules (registre des traitements, AIPD, etc.) passe par ce mécanisme dès sa création. ## Fonctionnement prévu 1. **Clé maîtresse** : `APP_SECRET_KEY` ou un fichier indiqué par `APP_KEY_FILE` (secrets Docker). 2. **Clé de l'organisation** : 32 octets aléatoires par organisation, stockés en base chiffrés (AES-256-GCM) par la clé maîtresse. Elle chiffre les données. 3. **Clé de secours** : une paire de clés. La clé de l'organisation est aussi chiffrée avec la clé publique. La clé privée est affichée une seule fois au propriétaire, au setup, et n'est jamais stockée. ## À faire ### Backend - [x] Module de gestion des clés (chargement de la clé maîtresse, création et ouverture de la clé de l'organisation, cache) - [x] Clé de secours : génération au setup, chiffrement de la clé de l'organisation avec la clé publique - [x] Commande de récupération (clé maîtresse perdue) et commande de changement de clé maîtresse (rechiffre uniquement les clés des organisations) - [x] Support de `APP_KEY_FILE` - [x] Tests unitaires : chiffrement et déchiffrement, mauvaise clé, valeur modifiée, clé de secours, changement de clé - [x] Test de bout en bout sur une base jetable - [x] Supprimer l'ancien code de migration (chiffrement avec `APP_SECRET_KEY` seule), devenu inutile ### Frontend - [x] Page de configuration initiale : afficher la clé de secours une seule fois, avec bouton « Copier » et case « J'ai sauvegardé cette clé » obligatoire avant de continuer ### Documentation - [ ] `README/WIKI` : ce qui est chiffré et ce qui ne l'est pas, où garder les clés, comment les sauvegarder séparément de la base, que faire si on perd la clé maîtresse ou la clé de secours - [x] README : variable `APP_KEY_FILE` - [x] Sauvegardes chiffrées et vérifiables : traitées dans une autre issue ## Hors périmètre (pour plus tard) - Chiffrer les emails et noms d'utilisateur (empreinte avec clé pour garder la recherche et l'unicité ...)

Citizenfivefr commented

2026-10-11 23:24:28 +00:00

(Migrated from github.com)

Objectif

Protéger les données sensibles en cas de fuite de la base.

Cléa est auto-hébergée : on ne vise pas le chiffrement de bout en bout. On vise un dump de base illisible sans une clé que l'hébergeur garde hors de la base.

Décisions prises

Pas de chiffrement de bout en bout pour l'instant.
Une clé maîtresse choisie par l'hébergeur, jamais stockée en base.
Une clé de données par organisation, enfermée par la clé maîtresse.
Une clé de secours (paire de clés) pour retrouver les données si la clé maîtresse est perdue.
Toute donnée sensible des futurs modules (registre des traitements, AIPD, etc.) passe par ce mécanisme dès sa création.

Fonctionnement prévu

Clé maîtresse : APP_SECRET_KEY ou un fichier indiqué par APP_KEY_FILE (secrets Docker).
Clé de l'organisation : 32 octets aléatoires par organisation, stockés en base chiffrés (AES-256-GCM) par la clé maîtresse. Elle chiffre les données.
Clé de secours : une paire de clés. La clé de l'organisation est aussi chiffrée avec la clé publique. La clé privée est affichée une seule fois au propriétaire, au setup, et n'est jamais stockée.

À faire

Backend

Module de gestion des clés (chargement de la clé maîtresse, création et ouverture de la clé de l'organisation, cache)
Clé de secours : génération au setup, chiffrement de la clé de l'organisation avec la clé publique
Commande de récupération (clé maîtresse perdue) et commande de changement de clé maîtresse (rechiffre uniquement les clés des organisations)
Support de APP_KEY_FILE
Tests unitaires : chiffrement et déchiffrement, mauvaise clé, valeur modifiée, clé de secours, changement de clé
Test de bout en bout sur une base jetable
Supprimer l'ancien code de migration (chiffrement avec APP_SECRET_KEY seule), devenu inutile

Frontend

Page de configuration initiale : afficher la clé de secours une seule fois, avec bouton « Copier » et case « J'ai sauvegardé cette clé » obligatoire avant de continuer

Documentation

README/WIKI : ce qui est chiffré et ce qui ne l'est pas, où garder les clés, comment les sauvegarder séparément de la base, que faire si on perd la clé maîtresse ou la clé de secours
README : variable APP_KEY_FILE
Sauvegardes chiffrées et vérifiables : traitées dans une autre issue

Hors périmètre (pour plus tard)

Chiffrer les emails et noms d'utilisateur (empreinte avec clé pour garder la recherche et l'unicité ...)

Rows
Columns

Chiffrement des données sensibles : clé maîtresse, clé de l'organisation et clé de secours #13