Pseudonymisation RGPD : checklist logiciel métier

Pseudonymiser vos données ne les sort pas du RGPD. Avant de valider un logiciel métier, je vérifie 4 points : séparer les informations qui permettent de retrouver l’identité, limiter les accès, contrôler les copies et garder les preuves des vérifications.

Voici les contrôles que je retiens :

• Cadrer le besoin : données utiles, finalités, base légale, durées de conservation et droits des personnes.
• Choisir la méthode : pseudonymiser pour permettre une attribution contrôlée, anonymiser si elle n’est plus nécessaire. Chiffrer ne remplace pas la séparation des accès.
• Protéger les correspondances : isoler leur stockage, gérer les clés et réserver la réidentification aux comptes habilités.
• Vérifier tous les usages : accès, journaux, tests, exports et sauvegardes, avec des données synthétiques en priorité pour les tests.
• Documenter la décision : responsables, résultats des tests, corrections et accord avant lancement.

Mon critère : <u>aucune validation sans preuves de contrôle</u>. Masquer les noms ne suffit pas : je vérifie aussi les possibilités de retrouver une personne en croisant les données.

Pseudonymisation vs Anonymisation : Tout savoir sur leur rôle dans le RGPD

Séparer les identifiants des informations d’attribution

Dans le logiciel, la pseudonymisation repose sur une séparation entre l’identifiant, la table de correspondance et les droits d’accès.^[7][8] Placer la correspondance dans une seconde table ne suffit pas si les mêmes comptes peuvent y accéder.

Remplacer les identifiants et isoler la table de correspondance

Remplacer les identifiants directs inutiles au traitement courant par des jetons générés aléatoirement. Documenter leur unicité, leur format, leur durée de vie et leur finalité.

Isoler la table de correspondance dans un composant distinct, avec des permissions dédiées. Seuls les comptes habilités doivent pouvoir retrouver l’identité : le compte applicatif courant ne doit pas pouvoir lire cette table. Cette séparation n’est utile que si l’accès reste strictement limité.

Lorsque le besoin métier le permet, réduire la précision des quasi-identifiants, comme le site, une fonction rare ou une date exacte, pour limiter le risque de réidentification. Un hachage seul ne garantit pas la pseudonymisation.^[4]

Protéger les clés et les informations d’attribution

Distinguer la table de correspondance de la clé cryptographique : chiffrer la table ne remplace pas sa séparation. Documenter le cycle de vie des clés et des jetons, de leur génération à leur destruction, en incluant leur récupération et leur renouvellement si nécessaire.

Protéger les correspondances au repos et en transit selon le risque. Séparer les comptes d’administration et interdire les comptes communs.

Vérifier les URL, les noms de fichiers, les exports, les erreurs et les journaux pour éviter qu’ils réintroduisent des identifiants. Séparer les stockages si le risque l’exige, sans confondre stockage distinct et contrôle d’accès.

Responsable : responsable technique.
Preuves attendues : schéma d’architecture, matrice des permissions et tests montrant qu’un utilisateur, un développeur ou un compte de test non habilité ne peut pas retrouver l’identité.^[3][4]
Fréquence de revue : avant la mise en production, puis après chaque changement d’architecture, d’hébergement ou de gestion des rôles.

Une fois la correspondance isolée, limiter les personnes et les comptes qui peuvent y accéder, puis tracer chaque consultation.

Contrôler les accès et sécuriser les journaux d’audit

Une fois la correspondance isolée, limitez les personnes autorisées à réidentifier et tracez chaque action sensible. Le but : empêcher toute réidentification sans autorisation.

Définir les droits par rôle et par environnement

Appliquez le refus par défaut dans l’application, les API, les bases de données et l’hébergement. Pour chaque rôle, définissez séparément les droits de lecture, d’écriture, d’export et de réidentification. Consulter un dossier ne doit pas donner le droit de l’exporter. Testez aussi les refus d’accès par appel direct à l’API.

Séparez les habilitations de production, de développement et de test. Chaque accès ponctuel à la production doit être nominatif, approuvé, limité dans le temps et tracé. Exigez une authentification forte, avec MFA pour les accès privilégiés. Recensez les comptes techniques en précisant leur responsable, leur finalité et leurs permissions, puis retirez les droits obsolètes.

Journaliser les actions sans exposer de données personnelles

Tracez les consultations selon le risque, ainsi que les réidentifications, les exports massifs, les changements d’habilitation, les échecs d’authentification et les accès administratifs. Les journaux doivent permettre d’attribuer chaque action sensible et de démontrer la maîtrise du dispositif, sans exposer de données identifiantes.

Pour chaque événement, enregistrez le compte ou l’identifiant pseudonymisé, l’horodatage, l’action, la référence technique de la ressource, l’environnement et le résultat. Distinguez les journaux de l’application, des bases de données et de l’infrastructure pour pouvoir recouper les événements. N’y copiez ni données identifiantes, ni correspondances, ni secrets d’authentification.

Centralisez les traces importantes dans un stockage séparé, à accès restreint et protégé contre toute modification ou suppression sans autorisation. Documentez leur durée de conservation. La CNIL recommande 6 à 12 mois, selon le contexte, puis une purge automatisée.^[9][10][11]

Désignez la personne chargée de traiter les alertes liées aux réidentifications inhabituelles, aux exports massifs et aux échecs répétés. Fixez un délai de traitement et une procédure d’escalade.

Responsables : propriétaire de l’application et responsable sécurité.
Preuves attendues : matrice des rôles validée, échantillons de journaux et comptes rendus de revue des accès, avec les corrections effectuées.
Fréquence : à chaque arrivée, départ ou changement de poste, périodiquement selon le risque et après un incident.

Ne validez pas si les actions sensibles ne peuvent pas être attribuées ou si des droits privilégiés ne sont plus justifiés.

Contrôler les données personnelles dans les environnements de test

Les copies de test sont une source fréquente de fuites. Traitez-les comme un environnement à part entière, avec leurs propres contrôles.

Préparer des jeux de test limités et isolés

Privilégiez les données synthétiques. Elles doivent reproduire les formats, les relations, les règles métier et les cas limites utiles aux tests fonctionnels, d’intégration et de démonstration, sans reprendre de personnes réelles^[15].

Si des données de production restent indispensables, documentez le besoin, les champs retenus, les garanties de sécurité et de confidentialité, les destinataires autorisés, la durée de conservation et les modalités de suppression^[4][13][14]. Même pseudonymisé, un jeu de test reste soumis au RGPD^[17].