Aller au contenu principal

Article 32 — Pseudonymisation

L'article 32 du RGPD impose des mesures techniques appropriees pour proteger les donnees personnelles. La pseudonymisation est citee explicitement comme exemple.

Quand l'utiliser​

  • Vous voulez documenter dans votre DPIA / registre des traitements quelle technique vous appliquez.
  • Audit interne ou externe (CNIL, certification ISO 27701).
  • Reduire le risque d'un breach : un dump pseudonymise n'est plus une donnee personnelle directe.

Workflow rapide​

  1. Identifier les colonnes PII : Anonymisation -> Suggestions auto (le domain_classifier_service propose une liste).
  2. Choisir la strategie selon le besoin :
    • hash (SHA256 + salt) si vous devez garder la jointure FK.
    • encrypt (cle separee) si vous voulez pouvoir restituer dans des cas legitimes (admin avec cle).
  3. Appliquer in-place (sur la DB cible) ou au passage du Bridge.
  4. Documenter la AnonymizationConfig dans votre registre des traitements.

Pseudonymisation vs anonymisation​

Pseudonymisation (Art 4 §5)Anonymisation
DefinitionIdentifiant remplace, reversible avec info supplementairePlus aucune possibilite de re-identifier
ReglementationReste donnee personnelle, RGPD appliqueHors scope RGPD
Outils Auralithhash (avec salt protege), encrypt (avec cle separee)redact + generalize + shuffle combines
RisqueCompromission du salt / cle = re-identificationFaible si bien fait

Concepts cles​

  • Salt protege : doit etre stocke separement. Auralith le gere par config, vous pouvez le rotater (impact : plus aucun mapping reverse-able).
  • Cle d'encryption : pour encrypt, gardez la cle dans un secret manager (voir Secret providers).
  • Re-identification combinee : meme pseudonymise, un dataset reste re-identifiable via croisement (date naissance + ZIP + genre = 87 % unique aux USA, etude Sweeney 2000). Generalize avant pseudonymise les quasi-IDs.

Pieges courants​

  • Salt en clair dans la base : si l'attaquant a la base, il a le salt. Stocker le salt dans un secret manager pour vraie protection.
  • hash sur petit espace : hash sur un genre (M/F) = trivial a inverser (deux hashes possibles). Ne pas hash des colonnes a faible entropie.
  • Confondre avec column masking : column masking masque a la lecture, les donnees source restent en clair. Pseudonymisation modifie les donnees stockees.

Voir aussi​