Mesures techniques et organisationnelles de TokenVeil (art. 32 RGPD)
Annexe au dossier de conformité. Décrit les mesures de sécurité implémentées dans le produit. À joindre au registre des traitements et, le cas échéant, à l’AIPD du client.
1. Chiffrement
Section intitulée « 1. Chiffrement »| Élément | Mesure |
|---|---|
| Mapping de pseudonymisation (jeton ↔ valeur réelle) | Chiffré au repos (Fernet : AES-128-CBC + HMAC-SHA256). Ne quitte jamais le process. |
| Identifiants de comptes IA liés par utilisateur | Chiffrés au repos (Fernet), permissions fichier 0600. |
| Mot de passe du compte de service LDAP | Chiffré au repos (Fernet) dans la base de configuration. |
| Transport | TLS requis (terminaison au reverse proxy en amont ; cookie de session en Secure + HSTS activés dans ce mode). |
2. Authentification et gestion des accès
Section intitulée « 2. Authentification et gestion des accès »- Comptes locaux : mots de passe hachés en PBKDF2-HMAC-SHA256, 600 000 itérations (recommandation OWASP), sel aléatoire de 128 bits par compte.
- LDAP / Active Directory : bind + search ; le mot de passe utilisateur ne transite jamais en clair et n’est jamais stocké. Filtres LDAP échappés (anti-injection).
- Sessions : jeton aléatoire de 256 bits ; seul son hachage SHA-256 est persisté (une fuite de la table des sessions ne permet pas de rejouer une session). Cookie
HttpOnly,SameSite=Lax,Secure(en TLS). - Rôles : séparation utilisateur / administrateur ; les routes d’administration exigent le rôle admin.
- Multi-tenant (option LDAP) : quotas de sièges par groupe.
3. Résistance aux abus
Section intitulée « 3. Résistance aux abus »- Anti-force brute : verrouillage temporaire après N échecs par compte ET par adresse IP (ce dernier contre le password-spraying, où un même mot de passe est essayé sur de nombreux comptes).
- Limitation de débit applicative : fenêtre glissante par utilisateur / clé API / IP, plafonds distincts selon la sensibilité de la route (authentification, appels IA, reste). Fail-open (une panne du limiteur ne bloque jamais un accès légitime).
- Clés API (intégrations / extension IDE) : hachées en SHA-256 (jamais stockées en clair), expiration configurable, quota d’appels journalier, révocation immédiate.
4. Durcissement applicatif et infrastructure
Section intitulée « 4. Durcissement applicatif et infrastructure »- En-têtes de sécurité HTTP sur chaque réponse : Content-Security-Policy stricte (aucune origine tierce autorisée),
X-Frame-Options: DENY(anti-clickjacking),X-Content-Type-Options: nosniff,Referrer-Policy,Permissions-Policy, HSTS derrière TLS. - Zéro dépendance externe au chargement : toutes les ressources front (JavaScript, polices) sont servies localement. Le produit fonctionne en environnement isolé (air-gapped) et n’expose aucune surface d’attaque supply-chain via CDN tiers.
- Conteneur non-root : exécution sous un utilisateur dédié (uid non privilégié).
- Isolation des données : chaque utilisateur ne peut accéder qu’à ses propres conversations et travaux (contrôle d’accès systématique ; réponses
404génériques pour ne pas révéler l’existence de ressources d’autrui).
5. Journalisation et auditabilité
Section intitulée « 5. Journalisation et auditabilité »- Journal d’audit d’anonymisation : pour chaque message, enregistre la catégorie et le nombre de données pseudonymisées, jamais la valeur réelle. Permet de prouver au RSSI/DPO que la pseudonymisation a eu lieu, sans recréer de risque de fuite dans le journal.
- Traçabilité des licences : vérification périodique signée, sans donnée personnelle.
6. Assurance qualité du moteur de pseudonymisation
Section intitulée « 6. Assurance qualité du moteur de pseudonymisation »- Jeu de test annoté (non-régression) : chaque catégorie de donnée sensible est vérifiée à chaque évolution.
- Fuzzing aléatoire : génération de milliers de lignes à graine aléatoire, mesure du taux de fuite sur échantillon jamais vu à l’avance.
- Intégration continue : la barrière CI bloque toute modification qui réintroduirait une fuite (seuil : 0 %).
- Résultat courant : 0 % de fuite mesuré (recall), taux de sur-pseudonymisation < 0,1 %.
7. Réversibilité et effacement
Section intitulée « 7. Réversibilité et effacement »- La pseudonymisation est réversible uniquement côté client, via le mapping chiffré local.
- La suppression d’une conversation détruit son mapping : les jetons deviennent définitivement non réversibles (support du droit à l’effacement, art. 17).
Les mesures ci-dessus décrivent les capacités du produit à sa version courante. Leur mise en œuvre effective (TLS, sauvegardes, gestion des accès administrateur, durées de conservation) relève de la responsabilité de l’organisation qui déploie TokenVeil.