Anonymisation ou pseudonymisation en cas de fuite

Anonymisation ou pseudonymisation en cas de fuite

Une donnée pseudonymisée reste une donnée personnelle dès qu’un moyen raisonnable permet de relier le pseudonyme à une personne. Une donnée anonymisée ne doit plus permettre cette relation, y compris par recoupement avec d’autres jeux de données. Confondre les deux transforme une fuite limitée en incident complet, avec le vocabulaire rassurant des slides et les conséquences beaucoup moins décoratives.

Explication de la marmotte

Un dossier peut remplacer les noms par des numéros, sans pour autant faire disparaître les personnes concernées. Cacher l’étiquette d’une boîte ne change pas ce qu’elle contient. Le choix entre masquer une identité et la faire disparaître détermine ce qu’un voleur peut encore retrouver après avoir mis la main dessus.

→ Lire l’explication complète de la marmotte

Pseudonymisation : réduire l’exposition sans supprimer le lien

La pseudonymisation remplace un identifiant direct, tel qu’un nom, une adresse électronique ou un numéro client, par une valeur de substitution. Le lien subsiste : une table de correspondance, une clé cryptographique, un coffre de jetons ou un algorithme déterministe permet de retrouver l’identité initiale. Cette réversibilité, même indirecte, est le point qui compte.

Un identifiant chiffré est pseudonymisé, pas anonymisé. Une valeur obtenue avec une fonction à clé est pseudonymisée, pas anonymisée. Un jeton aléatoire stocké dans une base séparée est pseudonymisé, pas anonymisé. La séparation technique améliore fortement la résistance à une fuite locale, mais ne retire pas la donnée du périmètre de protection.

La pseudonymisation est le bon choix quand le système doit joindre des événements, réconcilier un historique, appliquer des droits, répondre à une demande d’effacement ou détecter une fraude. Le compromis central est net : on conserve l’utilité relationnelle de la donnée, mais on conserve aussi un risque de réidentification. Vouloir les deux bénéfices, analyse permanente et anonymat absolu, produit généralement une architecture de présentation commerciale. Le réel facture ensuite.

Un pseudonyme déterministe permet les jointures entre systèmes : la même entrée produit la même sortie. Cette propriété facilite l’analyse, mais révèle les répétitions et les corrélations. Un attaquant qui connaît l’adresse électronique d’une cible peut tester cette valeur contre un mécanisme de hachage non protégé. Un condensat SHA-256 (Secure Hash Algorithm 256 bits) d’une adresse électronique n’est donc pas une pseudonymisation robuste : l’espace d’entrée est trop petit et trop prévisible.

Pour un identifiant stable, utiliser un HMAC (Hash-based Message Authentication Code) avec une clé secrète dédiée et une séparation de domaine. HMAC(k, "crm:email:" || valeur_normalisee) ne doit jamais partager sa clé ni son préfixe avec HMAC(k, "support:email:" || valeur_normalisee). Sinon, les exports deviennent corrélables entre domaines fonctionnels, ce qui annule une part du cloisonnement recherché.

Le chiffrement fournit une réversibilité explicite. Une clé de chiffrement de données, ou DEK (Data Encryption Key), doit être protégée par une KEK (Key Encryption Key), c’est-à-dire une clé servant à chiffrer d’autres clés. Cette KEK doit résider dans un KMS (Key Management System) ou, pour les cas à fortes exigences, dans un HSM (Hardware Security Module). Le chiffrement applicatif sans contrôle d’accès à la clé est surtout une décoration binaire. Cela brille dans un audit de tableau blanc, moins dans un dump mémoire.

Anonymisation : démontrer l’absence de réidentification raisonnable

L’anonymisation ne consiste pas à retirer une colonne nom. Elle vise à empêcher l’identification d’une personne par le jeu publié seul ou par croisement avec des données accessibles de manière raisonnable. Cette condition inclut les données publiques, les fuites antérieures, les métadonnées, les informations géographiques et les connaissances métier ordinaires.

Les quasi-identifiants sont les attributs qui ne nomment pas directement une personne mais la distinguent dans une population : date de naissance, code postal, profession rare, date d’embauche, employeur ou séquence d’événements. Une ligne sans nom peut rester unique avec seulement trois ou quatre de ces champs. La rareté est une fuite d’identité déguisée en statistique.

Le masquage partiel échoue souvent. Remplacer une date de naissance par l’année, un code postal par le département et un salaire par une tranche peut diminuer le risque, sans le supprimer. Si un groupe contient une seule valeur sensible, connaître le groupe suffit à l’apprendre. La k-anonymité impose qu’au moins k lignes partagent les mêmes quasi-identifiants, mais elle ne protège ni contre l’homogénéité des valeurs sensibles ni contre les informations externes déjà connues.

Une anonymisation exploitable combine généralement plusieurs transformations : suppression des identifiants directs, généralisation des quasi-identifiants, agrégation, suppression des catégories rares, bruit statistique et limitation de précision temporelle ou géographique. Le bruit doit être calibré contre l’usage prévu. Ajouter un bruit fixe ou reproductible sans analyse de sensibilité ne protège rien de sérieux : cela dégrade les graphiques et laisse les attaques faire leur travail, un exploit assez coûteux pour mériter sa propre catégorie.

La confidentialité différentielle est une méthode formelle qui borne l’influence d’une personne sur une sortie statistique. Elle nécessite un budget de confidentialité, souvent noté epsilon, consommé à chaque publication ou requête. Sans registre central de ce budget, plusieurs extractions apparemment inoffensives se combinent. Le mécanisme mathématique reste alors correct, mais l’architecture l’a laissé mourir de faim dans un tableur.

Pour une publication externe, une recherche ouverte ou un partage sans finalité opérationnelle de réidentification, l’objectif doit être l’anonymisation mesurée et documentée. Pour une opération interne nécessitant un lien durable, retenir la pseudonymisation et traiter le jeu comme sensible. Il n’existe pas de zone grise magique entre les deux.

Attaques de réidentification et limites de protection

La première attaque est le recoupement. Un export contient l’âge, une commune, une date et un événement rare. Une source publique ou un autre export contient les mêmes attributs. La jointure reconstitue l’identité sans casser de chiffrement. Le contrôle consiste à mesurer l’unicité des quasi-identifiants après transformation, pas à admirer la disparition de la colonne email.

La deuxième attaque cible le référentiel de correspondance. Une base métier pseudonymisée et une table de jetons accessibles avec le même compte de service ne forment pas deux périmètres : elles forment une seule fuite en deux fichiers. Séparer les stockages, les comptes, les réseaux, les journaux d’accès et les équipes d’administration lorsque le niveau de risque le justifie.

La troisième attaque vise la clé de pseudonymisation. Une clé HMAC compromise permet de recalculer les pseudonymes de candidats connus. Une clé de chiffrement compromise permet de déchiffrer les valeurs protégées. La pseudonymisation ne protège donc pas contre un attaquant qui possède à la fois les données et le secret. Elle limite le rayon d’explosion quand ces éléments restent séparés.

La quatrième attaque exploite les sorties applicatives. Une API qui accepte une adresse électronique et retourne un pseudonyme devient un oracle de réidentification. Une API qui cherche un utilisateur par pseudonyme peut aussi révéler son existence par des différences de statut, de temps de réponse ou de volume. Appliquer une authentification forte, des autorisations minimales, des quotas et des réponses homogènes. Les principes d’architecture cyber restent plus efficaces qu’un badge « privacy by design » collé après coup.

Ni l’anonymisation ni la pseudonymisation ne garantissent la confidentialité des secrets, l’intégrité des enregistrements, la disponibilité du service ou la sécurité des postes administrateurs. Elles ne remplacent ni le contrôle d’accès, ni la segmentation réseau, ni la journalisation, ni la détection d’exfiltration. Elles réduisent une classe de dommages : l’identification directe après exposition d’un jeu de données.

HMAC de pseudonymisation reproductible

L’exemple suivant produit un pseudonyme déterministe pour une adresse électronique normalisée. Il requiert Python 3.8 ou supérieur et une clé aléatoire de 32 octets encodée en Base64. La clé ne doit pas provenir d’un fichier .env distribué avec l’application, ce cimetière à secrets où les permissions sont toujours « temporairement » larges.

#!/usr/bin/env python3
# Exécuter ainsi :
# export PSEUDO_HMAC_KEY_B64="$(openssl rand -base64 32)"
# python3 pseudonymiser.py "[email protected]"

import base64
import hashlib
import hmac
import os
import sys
import unicodedata

secret_b64 = os.environ["PSEUDO_HMAC_KEY_B64"]
secret = base64.b64decode(secret_b64, validate=True)

# Normaliser avant calcul : la règle doit être identique dans tous les producteurs.
email = unicodedata.normalize("NFKC", sys.argv[1]).strip().lower()

# Séparer les domaines pour interdire les jointures involontaires entre usages.
message = f"crm:email:v1:{email}".encode("utf-8")
token = hmac.new(secret, message, hashlib.sha256).hexdigest()

print(f"psn_v1_{token}")

Le préfixe de version est obligatoire si la clé ou la règle de normalisation change. Une rotation de clé HMAC modifie tous les pseudonymes. Sans période de double écriture, les jointures historiques cassent immédiatement. Avec période de double écriture, les deux valeurs deviennent corrélables et élargissent temporairement la surface d’exposition. Il faut choisir la durée, la documenter et la purger, pas laisser le mécanisme en « transition » jusqu’à la prochaine extinction du soleil.

Ne pas tronquer un HMAC sans calculer le risque de collision. Un identifiant de 64 bits devient insuffisant lorsque le volume et les jointures augmentent. Conserver au moins 128 bits, soit 32 caractères hexadécimaux, pour des corpus courants, puis vérifier l’absence de collision à l’ingestion. La gestion des collisions doit être déterministe, sinon la pseudonymisation crée des erreurs métier silencieuses.

Rotation, sauvegarde et supervision des secrets

Une clé de pseudonymisation doit être créée dans un gestionnaire de secrets avec contrôle d’accès nominatif, journalisation des lectures et export interdit lorsque la plateforme le permet. La clé applicative ne doit être accessible qu’au composant qui calcule les pseudonymes. Un service d’analyse qui ne fait que consommer des jetons n’a aucune raison de la lire.

Pour un chiffrement réversible, versionner les clés avec chaque donnée chiffrée. Conserver les anciennes clés tant que des données chiffrées avec elles existent, puis détruire la version après rétention et validation des sauvegardes. Une sauvegarde contenant des données chiffrées sans les clés nécessaires est une archive décorative. Une sauvegarde contenant les clés au même endroit que les données est une fuite différée.

Superviser les lectures de clés, les échecs de déchiffrement, les appels inhabituels de pseudonymisation et les exports de masse. Les journaux ne doivent jamais contenir l’entrée brute, la clé, ni le jeton de session utilisé pour les obtenir. Pour les mécanismes de journalisation et de rétention, consulter les pratiques d’observabilité et architecture.

Tester la restauration complète : données, métadonnées de version, politiques d’accès, clés historiques et procédures de rotation. La reprise après incident échoue fréquemment sur l’autorisation manquante du compte de restauration, pas sur l’algorithme. La cryptographie a bon dos, mais elle ne crée pas les droits d’accès absents.

🐝 Ce qui arrive si on s’en passe

Sans cette distinction posée avant traitement, un jeu déclaré anonyme sort silencieusement du périmètre protégé : il n’est plus inventorié, ses exports ne sont plus journalisés, sa durée de conservation n’est plus fixée et aucune analyse d’impact ne le couvre. La qualification d’un incident devient alors impossible à trancher dans les délais utiles, faute de savoir si les enregistrements exposés restent rattachables à des personnes. Une publication effectuée sous cette étiquette ne se reprend pas : les copies diffusées échappent à toute purge et à tout retrait, même lorsqu’une mesure d’unicité menée après coup révèle des lignes distinguables. Sans versionnage ni traçabilité des transformations appliquées, il n’existe plus de moyen de prouver le niveau de protection réellement obtenu, ni de reconstituer quels destinataires ont reçu quelle variante.

🦫 Explication de la marmotte 🍫

La pseudonymisation remplace une information qui désigne directement une personne par une autre valeur. Cette nouvelle valeur peut être reliée à la personne d’origine si l’on possède une table de correspondance ou une clé secrète. Elle permet donc de suivre la même personne dans plusieurs enregistrements sans afficher son nom à chaque fois. Si un fichier fuit sans la clé ni la table, l’attaquant a plus de mal à retrouver les personnes. Si ces éléments fuient aussi, la protection tombe.

L’anonymisation va plus loin. Elle modifie ou retire des informations pour empêcher de retrouver une personne, même en comparant le fichier avec d’autres sources. Retirer les noms ne suffit pas : une date précise, un lieu, un métier rare et un événement particulier peuvent désigner une seule personne. Il faut donc regrouper, arrondir, supprimer certaines lignes ou modifier les résultats statistiques.

Le choix dépend du besoin. Si le système doit retrouver une personne, corriger son dossier ou relier son historique, il faut conserver un lien et protéger fortement les secrets. Si les données servent seulement à publier des chiffres ou à faire de la recherche, il faut supprimer ce lien et vérifier que les croisements restent impossibles. Dans les deux cas, il faut limiter les accès, surveiller les exportations, sauvegarder les clés séparément et tester leur restauration.

À lire aussi

• Comment minimiser les données collectéesLa minimisation des données réduit la surface d’attaque en limitant la collecte, la conservation et la diffusion des informations personnelles.
• Pseudonymisation par LLM, fuite de contexte et réidentificationPourquoi une pseudonymisation confiée à un LLM laisse fuiter le contexte qui permet de réidentifier les personnes, et quelle architecture limite cette fuite.
• Masquage dynamique pour tests et développementMettre en place un masquage dynamique de données pour conserver des jeux exploitables en test et développement sans distribuer les valeurs sensibles.
• Qualité des données et erreurs silencieusesLa qualité des données devient un sujet de sécurité quand une erreur silencieuse modifie une décision, un droit ou une exposition sans déclencher d’alerte.

Pages voisines

La citent

• Comment minimiser les données collectées
• Classifier les données avant de les protéger
• Masquage dynamique pour tests et développement
• AI Act : gouvernance des données d'entraînement (article 10)
• AIPD RGPD article 35 : méthode, critères et impact sur l'architecture
• Comment éviter la mémorisation dans un LLM interne
• Pseudonymisation par LLM, fuite de contexte et réidentification

Anonymisation ou pseudonymisation en cas de fuite

Elle cite

• Anonymisation ou pseudonymisation des données
• Confidentialité différentielle pour télémétrie produit
• Déployer Vault ou OpenBao pour supprimer les secrets en clair