PostgreSQL et le principe de Privacy By Design

Bonjour

  • Damien Clochard

  • DBA PostgreSQL & Co-foundateur de Dalibo

  • Président de l’association PostgreSQLFr

  • Je ne suis pas juriste !

Mon chemin

  • RGPD : 3 an plus tard…

  • Pourquoi c’est difficile ?

  • Protéger les données dès la conception

  • PostgreSQL Anonymizer

RGPD

  • Droits Individuels

  • Principes

  • Impact

RGPD : les droits Individuels

  • droit à l’information (Art. 13 et Art. 14)
  • droit d’accès (Art. 15)
  • droit de rectification (Art. 16)
  • droit à la portabilité (Art 20)
  • droit d’opposition (Art. 21)
  • droit à l’oubli (Art. 17)
  • droit à la limitation du traitement (Art. 18)
  • droit de décision automatisée (Art. 22)

(sources: Individual Rights)

RGPD: Principes & Concepts

  • Licéité, loyauté, transparence
  • Sécurité
  • Minimisation des données
  • Privacy By Design
  • Data Protection By Design
  • Limitation du stockage
  • Précision
  • Limitation des finalités


(source: GDPR Principles)

Les montants explosent

(source: GDPR Enforcement Tracker)

La France est le mauvais élève

(source: GDPR Enforcement Tracker)

La France est le mauvais élève

(source: GDPR Enforcement Tracker)

Les principes RGPD sont aux coeurs des sanctions

(source: GDPR Enforcement Tracker)

Pourquoi c’est difficile ?


En général:

  • L’anonymisation est faite en bout de chaine

  • La surface d’attaque est trop grande

  • Les développeurs/éditeurs ne sont pas impliqués

  • Les outils d’anonymisation sont externes


Le RGPD a identifié le problème


Article 25

« […] le responsable du traitement met en œuvre, tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même, des mesures techniques et organisationnelles appropriées […] »


7 Bonnes Pratiques d’anonymisation

  • Embarquer les règles d’anonymisation
  • Privacy By Default
  • Qualifier les roles
  • Anonymiser dans la base
  • Suivre le cycle de vie des données
  • Echantillonner
  • Evaluer

Concrètement ?

PostgreSQL Anonymizer

Exemple

CREATE TABLE customer (
    id SERIAL PRIMARY KEY,
    firstname TEXT,
    lastname TEXT,
    phone TEXT,
    birth DATE,
);

Embarquer les règles d’anonymisation

SECURITY LABEL FOR anon ON COLUMN customer.lastname
IS 'MASKED WITH FUNCTION anon.fake_last_name()';

Privacy By Design

SECURITY LABEL FOR anon ON COLUMN customer.phone
IS 'MASKED WITH VALUE $$CONFIDENTIAL$$';

Qualifier les roles

SECURITY LABEL FOR anon ON COLUMN data_scientist
IS 'MASKED'

Anonymiser dans la base

Anonymiser dans la base

Anonymiser dans la base

Suivre le cycle de vie des données

ALTER TABLE customer ADD COLUMN postcode TEXT;

SECURITY LABEL FOR anon ON COLUMN customer.postcode
IS 'MASKED WITH VALUE NULL';

Echantillonner

SECURITY LABEL FOR anon ON TABLE customer
IS 'TABLESAMPLE BERNOULLI 33';

PS: cette fonction est en cours de développement :-)

Evaluer

SECURITY LABEL FOR anon ON COLUMN customer.birth 
IS 'INDIRECT IDENTIFIER';
SECURITY LABEL FOR anon ON COLUMN customer.postcode 
IS 'INDIRECT IDENTIFIER';
SELECT anon.k_anonymity('customer')
   k_anonymity
-----------------
 3

En résumé

  • Les sanctions du RGPD sont bien réelles

  • Les fuites de données sont le plus gros risque

  • Reduire la surface d’attaque

  • Anonymiser dès que possible

  • Anonymiser dans la base de données

Bataille pour la vie privée

  • Les développeurs doivent écrire les règles de masquage

  • C’est difficile mais PostgreSQL est un bon point de départ

  • La protection des données privées est un travail d’équipe

  • Les éditeurs doivent livrer les règles de base d’anonymisation

Aller plus loin

Comment Contribuer ?

  • Feedback et bugs !

  • Témoignages

  • Rejoindre le projet sur :

https://gitlab.com/dalibo/postgresql_anonymizer

Merci !

DGFIP

Biomerieux

Mes collègues

A bientôt !