Une fois n’est pas coutume, nous n’allons pas parler ici d’un sujet purement technique, mais des impacts pour nos métiers de l’introduction d’une réglementation européenne majeure, la GDPR.

La GDPR ?

L’acronyme GDPR fait référence à l’ « EU General Data Protection Regulation »; c’est un règlement européen qui vise à protéger les données personnelles des citoyens et résidents de l’Union Européenne (508 millions de personnes … avant le Brexit).

Elle vise à améliorer la protection des données personnelles, dans un monde où les failles de sécurité exposant ces données défraient la chronique bien trop fréquemment (rappelons nous des brèches chez Yahoo, AOL, DropBox, LinkedIn, EBay, UPS, …), et mènent au développement des fraudes, vols d’identité et autres chantages…

C’est une évolution de la DPD (Data Protection Directive), qui date de 1995, quasiment la préhistoire à l’échelle d’Internet, et assurément bien loin des préoccupations qui sont les nôtres en 2017, à la lumière des incidents et risques rappelées précédemment.

Elle concerne les entreprises qui exploitent des données personnelles de citoyens ou résidents européens, que ces entreprises aient leurs activités basées en Europe… ou ailleurs dans le monde; le spectre des entreprises concernées est donc extrêmement large.

En cas de non respect de ce règlement, les entreprises risquent une amende pouvant aller jusqu’à 20 millions d’euros (ou 4% de leur chiffres d’affaires … sachant que le montant le plus élevé est retenu comme limite). Ça pique un peu plus qu’un radar qui vous attrape à 51 km/h en agglomération. De plus, le prononcé des sanctions sera rendu plus simple pour le régulateur que pour la directive précédente.

Et l’horloge tourne ! L’application est prévue dans un an (au 25 mai 2018). Autant dire que ça urge (et la recrudescence d’articles sur le sujet ces derniers temps le montre…).

Je ne vais pas ici donner toutes les implications que cela peut avoir pour les entreprises, car tous les départements sont touchés (des directions métiers au juridique, en passant par un nouveau rôle dans l’entreprise, le Data Protection Officier), je ne vise pas à être exhaustif sur le sujet, et certaines modalités d’application sont encore floues. On va se limiter à aborder en détail sur ce que cela change pour nous, architectes et développeurs (au sens large : applications, base de données, BI…).

OK, OK, mais en quoi cela me concerne-t-il ?

Un des articles de la GDPR demande que les entreprises qui traitent les données personnelles implémentent désormais la « data protection by design … and by default » : nous devons concevoir nos systèmes pour que les données puissent être protégées, et qu’elles le soient par défaut.

Les impact sur nos métiers sont nombreux, notamment à cause du mode de calcul de l’amende en cas de vol de données, qui tient compte des actions de prévention visant à réduire l’impact de ces vols de données (au plus nous aurons pris de mesures, plus faible sera l’amende).

La phase de conception, où nous intervenons, est donc essentielle; voici les approches qui doivent nous guider lors de la conception des architectures ou des modélisations de données de nos systèmes.

Minimisation des données personnelles

L’article 5 nous impose de minimiser les données personnelles que nous stockons : « personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ».

Il nous faut donc perdre les (mauvaises) habitudes que nous avons pu prendre en stockant un maximum de données, sur l’air de « ça pourra peut-être servir un jour », car on pouvait se reposer sur la tendance à la diminution du coût de stockage, et sur les possibilités offertes par les traitements big data.

Il faudra donc que l’on se pose les questions suivantes :

• quelles données sont réellement nécessaires ? Ai-je besoin de la date de naissance complète, de la simple année de naissance … ou simplement de savoir si la personne est majeure ? l’impact n’est pas le même en cas de vol de données ! On peut par exemple demander à l’utilisateur sa date de naissance complète pour s’assurer qu’il est majeur à l’accès au service, mais ne pas stocker la date en base de données !
• combien de temps dois-je stocker les données ? Certaines données perdent de leur utilité avec le temps. Si on collecte les coordonnées des participants à un jeu, ne devrait on pas supprimer leurs données personnelles au plus vite après le jeu ? GDPR impose de supprimer les données fonctionnellement inutiles.
• où sont stockées mes données ? Les données sont souvent répliquées dans de multiples systèmes, pour des raisons fonctionnelles (réutilisations) ou technique (disponibilité de la données par georéplication). Il faut s’assurer de minimiser la présence des données personnelles sur de multiples systèmes.
• comment sont utilisées les données ? est-ce que les données sont utilisées uniquement dans l’objectif affiché publiquement par notre service lorsque l’utilisateur les a renseigné ?

Pseudonymisation

GDPR nous incite à implémenter des technologies de pseudonymisation, qui consiste à traiter les données personnelles de manière à ce que celles-ci ne puissent être reliées à un individu que si elles sont complétées par une information additionnelle, qui n’est pas stockée en même temps que la donnée personnelle (ce qui réduit les risques d’exploitation en cas de vol de données).

Il s’agit ici d’un concept différent de celui, plus familier pour nous, d’anonymisation (qui est un processus non réversible qui ne permet pas de retrouver les associations avec les individus, alors qu’ici on souhaite être en mesure de retrouver cette association).

Comment s’y prendre pour implémenter la pseudonymisation ?

• Chiffrement : sans la clé de déchiffrement, je n’ai pas accès aux données personnelles.
• Hashage: je ne stocke pas directement la donnée mais le résultat d’une fonction de hashage, qui me permettra des comparaisons d’égalité ultérieurement (par exemple sur le numéro de sécurité sociale).
• Masquage : remplacer toute ou partie de la donnée pour la cacher (par exemple ne pas stocker les adresses email complètes….).
• Agrégation : on ne stocke pas la donnée pour chaque utilisateur, mais dans des agrégats (par exemple on ne stocke pas les ages de chaque personne mais uniquement les agrégats d’age moyen, min, max…)
• Références indirectes : stocker dans des sources de données différentes, et utiliser des références entre ces sources pour reconstituer la donnée complète. Ainsi, si une seule source de données est volée, l’exploitation en est plus compliquée !

 

Concluons…

En respectant ces bonnes pratiques, nous nous rendons capables de déployer des systèmes respectant la réglementation GDPR, même si bien d’autres interlocuteurs de l’entreprise devront aussi adapter leur travail.

Mais au delà de cette contrainte réglementaire, nous rendrons service à nos utilisateurs en respectant la valeur de leur données personnelles !