Skip to main content

Anonymisation

Pseudonymiser ou anonymiser les colonnes contenant de la donnee personnelle. Six strategies, deux workflows, FK consistency garantie pour cinq d'entre elles.

Quand l'utiliser​

  • Refresh staging depuis prod : transformer emails, noms, telephones.
  • Generer un export RGPD-safe pour partage avec un partenaire.
  • Couvrir l'Article 32 RGPD (pseudonymisation comme mesure technique).

Deux workflows distincts​

  1. In-place : modifie les donnees dans la connexion ciblee. UPDATE en SQL natif quand possible, fallback Python sinon. Audit trail complet.
  2. Export anonymise : ne touche pas la source. Genere un dump (CSV, JSON, SQL) deja anonymise. Compatible avec Bridge.

Les six strategies​

StrategieEffetFK-safe ?Idempotent ?
hashSHA256(value + salt)OuiOui
redactremplace par *** ou NULLNon sur FK columnOui
fakeFaker (nom, email, addr)Oui (avec salt)Non
generalizetronque (date -> mois, ZIP -> 3 chars)OuiOui
shufflepermutation au sein de la colonneNon sur FKNon
encryptchiffre symetriqueNon (non deterministe)Non

Workflow rapide​

  1. Anonymisation -> Nouvelle config.
  2. Pour chaque colonne sensible : choisir une strategie. Auralith suggere selon le domain_classifier_service (detecte email, name, phone).
  3. Dry-run : preview de 10 lignes avant / apres.
  4. Choisir le workflow (in-place ou export).
  5. Approval requis sur env prod (policy par defaut).
  6. Executer. Suivre dans la barre de jobs.

Concepts cles​

  • AnonymizationConfig : sauvegardee, reutilisable.
  • Strategy : une par colonne. Plusieurs strategies par config.
  • Salt : commun a une config pour garantir la coherence (un meme email hash toujours pareil dans une config donnee).
  • FK consistency : si users.id est hash, alors orders.user_id doit etre hash avec le meme salt. Auralith le verifie au dry-run.

Pieges courants​

  • encrypt non deterministe : un meme plaintext donne deux ciphertexts differents. Inutilisable sur une FK. Utilisez hash pour la FK et encrypt pour les colonnes non-jointe.
  • redact sur FK column : remplace toutes les valeurs par la meme constante -> les jointures explosent en produit cartesien. Auralith bloque.
  • shuffle casse la coherence relationnelle : le user_id 42 peut atterrir sur la ligne d'un autre. A reserver aux colonnes non-FK et non-PK.
  • Charge memoire fake : tourne en Python, batch limite a 5000 lignes. Pour des tables > 1M lignes, prevoir plusieurs heures.
info

La pseudonymisation au sens RGPD Art 32 = hash ou encrypt reversible avec cle separee. La vraie anonymisation (irreversible) = redact + generalize + shuffle combines. Voir Art 32 pseudonymisation.

API​

# Creer une config
curl -X POST https://app.auralith.io/api/v1/projects/{pid}/anonymize/configs \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"name":"prod-to-staging","rules":[{"table":"users","column":"email","strategy":"hash"}]}'

# Executer
curl -X POST https://app.auralith.io/api/v1/anonymize/configs/{id}/run \
  -d '{"connection_id":"...","mode":"in_place"}'

Voir aussi​