PostgreSQL et le principe de "Privacy By Design"

Paris, le 19 mai 2022

La version 1.0 de l’extension PostgreSQL Anonymizer a été publiée il y a quelques jours. L’occasion de revenir sur le concept de “Privacy By Design“ qui est une des obligations du RGPD.

Quatre ans après la mise en route du RGPD, son application reste complexe pour de nombreuses entreprises et organisations. En particulier, la mise en oeuvre du principe “privacy by design” reste un casse-tête…

En effet, l’article 25 du RGPD impose la “Protection des données dès la conception” en précisant que la protection des droits et libertés des personnes physiques doit être mise en oeuvre « tant au moment de la détermination des moyens du traitement qu’au moment du traitement lui-même.»

Mais comment intégrer des règles de protection des données dès la conception d’une application ?

La majorité des outils d’anonymisation actuels fonctionnent à l’extérieur de la base de données, sur le principe des outils ETL (Extract-Transform-Load). Il en résulte que la responsabilité de la rédaction de la politique de sécurité est généralement confiée aux DBA de production. En clair, ces outils se focalisent sur la phase de traitement des données plutôt que sur la phase de détermination de ces traitements.

À l’inverse, l’extension PostgreSQL Anonymizer cherche à impliquer les développeurs et les architectes dès les phases préliminaires de conception. Grace à une syntaxe SQL appelées “SECURITY LABEL”, les règles de masquage sont déclarées directement à l’intérieur même de la base, au même titre qu’une contrainte d’intégrité ou d’un index.

Pour Thierry Aimé qui travaille au sein de bureau de l’architecture et des normes de la DGFIP, il s’agit d’un point important :

« PostgreSQL Anonymizer intègre, dès la conception de la base de données, le principe qu’en dehors de la production, les données sont anonymisées. Cela renforce les garanties du RGPD, sans nuire à la qualité des tests lors des montées de versions par exemple. »

En pratique, lorsque l’on ajoute une nouvelle colonne dans une table, on accompagne cette déclaration de règles et des restrictions qui seront garanties par la base (unicité, clé étrangère, etc.). Avec PostgreSQL Anonymizer, on peut désormais définir que cette colonne contient des données personnelles et écrire une règle de masquage pour décrire comment ces données seront transformées pendant le processus d’anonymisation.

Concrètement les règles de masquage seront accolées à la définition de la table :

CREATE TABLE player( 
  id SERIAL, 
  lastname TEXT, 
  birth DATE,
  points INT
);

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

SECURITY LABEL FOR anon ON COLUMN player.birth
  IS 'MASKED WITH VALUE NULL';

L’extension fournit un panel de techniques de masquage en fonction des besoins : randomisation, ajout de bruit, contrefaçon, destruction partielle, pseudonymisation, géneralisation, etc.

Il est également possible d’indiquer qu’une colonne est un identifiant indirect et le DBA de production pourra utiliser une fonction de K Anonymity pour vérifier qu’il n’est pas possible de singulariser un individu à l’intérieur de la table.

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

Chaque personne impliquée dans la création et la gestion d’une application est concernée par le RGPD. Dans cet esprit, l’extension PostgreSQL Anonymizer fournit une boîte à outils pour les développeurs et les administrateurs de données pour les aider à implémenter les règles de masquage le plus tôt possible, et ainsi respecter le principe de “Privacy by Design”.