RGPD : Un guide pratique pour les développeurs

Pour la fonctionnalité « Oubliez-moi », vous devez avoir une procédure qui prend en paramètre un identifiant utilisateur et efface toutes ses données personnelles (dans le cas d'une collecte sur la base d'un consentement ou basée sur l'intérêt légitime du responsable des données personnelles (voir plus bas) et non pas en raison de l’exécution d'un contrat ou d’obligation légale).

Il est utile pour les tests d'intégration d'avoir cette fonctionnalité(pour un nettoyage après test), mais cela peut être difficile à implémenter selon le modèle de données. Dans un modèle de données ordinaire, supprimer un enregistrement peut être facile, mais certaines clés étrangères peuvent être enfreintes. Cela signifie que vous avez deux options :

• vous assurer que vous autorisez les clés étrangères pouvant être à NULL (par exemple, une commande a généralement une référence à son auteur, mais quand l'utilisateur demande la suppression de ses données, vous pouvez donner la valeur NULL au userID) ;
• ou vous assurer de la destruction de toutes les données relatives (par exemple en cascade).

Ceci peut ne pas être souhaitable, exemple : si les commandes sont utilisées pour tracer les quantités disponibles, ou à des fins comptables.

C'est un peu plus compliqué pour l’approvisionnement d’événements, ou dans des cas extrêmes, ceux incluant un genre de blockchain/de hash de structure/chaîne de données inviolable. Avec l'approvisionnement d’événements, vous devriez pouvoir retirer un événement passé et régénérer des instantanés intermédiaires. Pour les structures de type blockchain, faites attention à ce que vous y stockez, et évitez d'y mettre des données personnelles d'utilisateurs. Il y a l'option d'utiliser une fonction de hashage caméléon, mais c'est sous-optimal. Vous devez globalement constamment penser à comment supprimer les données personnelles. Et « Notre modèle de données ne le permet pas » n'est pas une excuse. Et à propos des sauvegardes ? Idéalement, vous devez garder une table séparée pour les identifiants des utilisateurs oubliés, donc à chaque restauration d'une sauvegarde, vous réoubliez les utilisateurs oubliés. Cela signifie que la table devrait être dans une base de données séparée ou avoir un processus de sauvegarde/restauration séparé.

Supprimer les données de votre système c'est une chose, mais vous êtes aussi obligé d'informer tous les tiers à qui vous avez poussé les données. Donc, si vous avez envoyé des données personnelles à des services externes tels que Salesforce, Hubspot, Twitter, ou tout autre fournisseur de service cloud, vous devrez appeler une API de leur cru permettant la suppression de données personnelles. Si vous êtes un tel fournisseur, votre point final « oubliez-moi » devra être apparent. Appeler l'API tierce pour supprimer des données n'est pas tout, quoique. Vous devez également vous assurer que l'information n'apparaisse pas dans des résultats de recherche. Maintenant, c'est délicat, car Google n'a pas d'API de suppression, seulement un processus manuel. Heureusement, c'est seulement pour les pages de profils publics navigables et accessibles par Google (et d'autres moteurs de recherches, bien entendu), mais vous avez toujours à prendre des mesures. Idéalement, vous devriez faire retourner une erreur HTTP 404 sur la page de données personnelles pour qu'elle puisse être supprimée.

Article 19 de la RGPD.

Dans votre panneau d'administration, où il y a une liste d'utilisateurs, il devrait y avoir un bouton « restreindre le traitement ». La page réglages utilisateur devrait également l'avoir. Lors de son clic (après lecture de l'information appropriée), il devrait marquer le profil comme restreint. Cela signifie qu'il ne devrait plus être visible par l'équipe du backoffice, ou publiquement. Vous pouvez implémenter ceci avec un simple drapeau « restreint » dans la table « utilisateurs » et un peu de clauses « si » ici et là.

Article 18 de la RGPD.

Il devrait y avoir un autre bouton « export des données ». Lors de son clic, l'utilisateur devrait recevoir toutes les données que vous possédez sur lui. Ce que sont exactement ces données dépend du cas de figure. Habituellement, il s'agit d’au moins les données que vous supprimez avec la fonctionnalité « oubliez-moi », mais peut inclure des données additionnelles (ex. les commandes faites par l'utilisateur ne devraient pas être détruites, mais incluses dans le dump). La structure du dump n'est pas strictement définie, mais ma recommandation serait de réutiliser les définitions de schema.org. Autant que possible, soit JSON ou XML. Si les données sont suffisamment simples, un simple export CSV/Excel devrait être suffisant.

Quelquefois, l'export de données peut prendre du temps, le bouton peut donc déclencher un processus en tâche de fond, qui pourra ensuite notifier l'utilisateur par mail quand ses données seront prêtes (Twitter par exemple le fait déjà, vous pouvez demander tous vos tweets et les obtenir après un moment). Vous ne devez pas forcément implémenter un export manuel, bien que ce serait plus pratique. Il est suffisant d'avoir un processus en place permettant aux utilisateurs de demander l'accès à leurs données, qui peut être un processus manuel de requête sur la base de données.

Article 20 de la RGPD.

Cela semble une règle évidente, mais elle n'est pas toujours suivie. Les utilisateurs doivent pouvoir modifier toutes les données les concernant, incluant les données que vous avez collectées depuis d'autres sources (par exemple en utilisant un login avec Facebook vous devriez avoir récupéré leur nom et adresse). Règle générale, tous les champs dans votre table « utilisateurs » devraient être éditables via l'interface graphique. Techniquement, une rectification peut être faite via un processus de support manuel, mais ceci revient normalement plus cher pour une entreprise que de simplement avoir le formulaire pour le faire. Cependant, il y a un autre scénario, quand vous avez obtenu les données d'autres sources (c’est-à-dire les utilisateurs ne vous ont pas fourni directement le détail de leurs informations directement). Dans ce cas, ils devraient quand même y avoir une page où ils peuvent en quelque sorte s'identifier (via une adresse mail et/ou une confirmation par SMS) et obtenir l'accès à leurs données.

Article 16 de la RGPD.

« J'accepte les termes et conditions » ne sera plus suffisant pour prétendre que l'utilisateur a donné son consentement au traitement de ses données. Donc, pour chaque activité particulière de traitement, il devrait y avoir une case à cocher séparée sur l'écran d'enregistrement (ou le profil utilisateur). Vous devrez garder ces cases à cocher dans des colonnes séparées de la base de données, et laisser l'utilisateur retirer son consentement (en décochant ces cases depuis son profil, voir le point précédent). Idéalement, ces cases à cocher devraient provenir directement de l'activité de traitement de l'enregistrement (si vous en gardez un).

Notez que ces cases à cocher ne devront pas être présélectionnées, ceci ne comptant pas comme un « consentement ». Une autre chose importante ici concerne le machine learning/l'intelligence artificielle. Si vous allez utiliser les données des utilisateurs pour entraîner vos modèles ML, vous devrez également obtenir le consentement pour cela (sauf à des fins scientifiques, lesquelles ont un traitement spécifique). Notez ici le traitement appelé « intérêt légitime ». C'est à l'équipe juridique de décider ce qui est d'un intérêt légitime, mais le marketing direct est inclus dans cette catégorie, comme tout traitement de bon sens relatif à l'activité commerciale. Si par exemple vous collectez des adresses d'expédition, c'est évidemment légitime. Toutes les activités de traitement ne nécessitent pas de cases à cocher de consentement.

Article 7 de la RGPD.

Si le consentement qu'ont donné les utilisateurs n'était pas clair (exemple : simple accord aux termes et conditions), vous devrez le réobtenir. Préférez donc une fonctionnalité de mass-mailing pour demander aux utilisateurs d'aller dans leur page de profil et vérifier toutes les cases à cocher pour les traitements sur leurs données personnelles.

Ceci est similaire au bouton « export », mis à part que les données devraient être visibles dans une interface graphique régulière plutôt que dans un format JSON/XML. Je ne dirai pas que c'est obligatoire, et vous pouvez le laisser comme une fonctionnalité « souhaitable ». Par exemple, Google Map vous montre votre historique de position, tous les endroits où vous avez été. C'est une bonne implémentation du droit d'accès (bien que Google soit loin d'être parfait quand la vie privée est concernée).

Ce n'est pas tout à propos du droit d'accès. Vous devez laisser les utilisateurs non enregistrés savoir si vous avez des données les concernant, mais ce serait plus un processus manuel. Le minimum idéal serait d'avoir une fonctionnalité « vérification par mail », ou vous contrôleriez si vous avez des données concernant une adresse mail particulière. Vous devez dire à l'utilisateur de quelle façon vous traitez ses données. Vous pouvez simplement imprimer tous les enregistrements dans votre registre de traitement des données pour lequel l'utilisateur a consenti.

Article 15 de la RGPD.

Vous devrez demander l'âge des utilisateurs, et si l'utilisateur est un enfant (moins de seize ans), vous devrez demander la permission des parents. Il n'y a pas de moyen clair à ce sujet, ma suggestion est d'introduire un flux, où l'enfant devra spécifier le mail d'un parent, qui pourra donc confirmer.

Évidemment, les enfants pourront tricher sur leur date de naissance, ou fournir une fausse adresse mail parentale, mais vous aurez fait votre travail conformément à la législation (c'est un des vœux pieux de la réglementation).

Article 8 de la RGPD.

Si vous avez collecté les données pour un usage spécifique (ex. livrer un produit), vous devez les supprimer/les anonymiser aussitôt que possible. Beaucoup de sites d'e-commerce offrent une option « acheter sans inscription », dans quel cas, le consentement n'est valable que pour la commande particulière. Vous devrez donc avoir une tâche programmée pour anonymiser périodiquement les données (supprimer les noms et adresses), mais seulement après la réunion de certaines conditions, exemple : confirmation de livraison du produit. Vous pouvez avoir un champ dans la base pour stocker la date limite à partir de laquelle les données devront être supprimées, et cette date limite peut être étendue en cas de problème de livraison.

Article 5 de la DPDR.

Les cookies sont un sujet de réglementation différent (une directive qui deviendra bientôt une réglementation). Cependant, la RGPD va encore changer les choses étant donné que les cookies traceurs sont concernés. J'ai décrit mon opinion sur les cookies traceurs dans un post séparé.

Cela signifie que la communication entre votre couche applicative et votre base de données (ou votre queue de message, ou tout composant que vous avez) devrait se faire à travers TLS. Les certificats pourraient être autosignés (et éventuellement épinglés), ou vous pourriez avoir une autorité de certification interne.

Différentes bases de données ont des configurations différentes. Certaines bases de données ont besoin de dialoguer entre plusieurs nœuds, qui devraient aussi être configurés pour utiliser du chiffrement.

Cela dépend encore de la base de données (certaines offrent un chiffrement au niveau des tables), mais peut aussi être au niveau machine. Ex. en utilisant LUKS. La clé privée peut être stockée dans votre infrastructure, ou dans un service cloud comme AWS KMS.

Un peu évident.

Le cas d'utilisation le plus évident est quand vous voulez utiliser des données en production pour des serveurs de tests/mises en scène. Vous devrez changer les données personnelles en « pseudonymes », de façon à ce que les gens ne puissent pas être identifiés. Quand vous poussez des données à des fins d'apprentissage automatique (à des tiers ou non), vous pouvez aussi le faire.

Techniquement, cela pourrait signifier que votre objet utilisateur peut avoir une méthode « pseudonymise » qui applique un hash+sel/bcrypt/PBKDF2 pour les données pouvant être utilisées pour identifier une personne. La pseudonymisation peut être réversible ou non, dépendant de l'usage (la définition dans la régulation implique la réversibilité basée sur une information secrète, mais pas en cas de données de test/mises en scène). Certaines bases de données ont de telles fonctionnalités intégrées, ex. : Oracle.

C'est une chose très large, et peut simplement signifier « avoir un système d'authentification pour modifier les données ». Mais vous pouvez faire plus, même aussi simple qu'un checksum, ou une solution plus compliquée (comme celle sur laquelle je travaille). Cela dépend des enjeux, de la façon dont les données sont accédées, d'un système particulier, etc. Le checksum peut être de la forme d'un hash de toutes les données d'un enregistrement de la base, qui devra être mis à jour à chaque fois que l'enregistrement est modifié via l'application. Ce n'est pas une garantie forte, mais c'est au moins quelque chose.

L'article 30 stipule que vous devriez garder un enregistrement de tous les types d'activités où vous utilisez des données personnelles. Cela sonne comme de la bureaucratie, mais peut être utile. Vous serez capable de lier certains aspects de votre application avec ce registre (ex. les cases à cocher de consentement, ou votre trace d'enregistrement d'audit).

Mettre en place un simple registre ne devrait pas prendre beaucoup de temps, mais les besoins de l'entreprise pour cela viennent de quiconque est responsable de la conformité RGPD. Mais vous pouvez aussi les informer que l'avoir dans un fichier Excel ne le rendra pas facile pour vous en tant que développeur (imaginez avoir à fouiller dans le fichier Excel, pour pouvoir le parser et implémenter une fonctionnalité). Un tel registre pourrait être un microservice/une petite application déployée séparément dans votre infrastructure.

Chaque opération de lecture d'un enregistrement de données personnelles devrait être loguée, pour que vous sachiez qui y a accédé et pour quel usage. Cela ne découle pas directement de la réglementation, mais c'est implicite concernant les responsabilités.

Qu'en est-il des résultats de recherche (ou listes) contenant des données personnelles sur plusieurs sujets ? Mon pressentiment que simplement loguer « utilisateur X a fait une recherche sur le critère Y » devrait suffire. Mais n'affichez pas trop de données personnelles dans les listes, par exemple voir comment Facebook vous fait passer par des cercles pour obtenir l'anniversaire d'une personne.

Il y a d'autres articles sur le règlement qui laissent entendre que garder un log d'audit est une meilleure pratique (pour protéger l'intégrité des données aussi bien que s'assurer qu'elles n'ont pas été accédées sans une raison valable).

Vous ne devriez pas autoriser les API anonymes à accéder aux données personnelles. Je dirais que vous devez demander le nom de l'entreprise et le nom du contact pour chaque utilisateur de l'API lors de l'inscription, et les ajouter au registre de traitement des données.

Ceci est supposé être l'esprit de la réglementation. Si vous voulez exposer une nouvelle API à un nouveau type de clients, ou voulez utiliser les données pour de l'apprentissage automatique, ou décidez d'ajouter des publicités à votre site basé sur le comportement des utilisateurs, ou encore vendre votre base de données à un tiers, réfléchissez à deux fois. J'imaginerais un bouton pour envoyer des notifications par mails aux utilisateurs pour leur demander la permission (ou si vous utilisez un répertoire tiers, il vous fournira probablement une API). Donc, lors de l'ajout d'une nouvelle activité de traitement (et l'ajout à votre registre), envoi d'un mail en masse à tous les utilisateurs desquels vous souhaiteriez le consentement. Notez ici que cette autorisation peut être ajoutée dynamiquement.

Article 6 de la RGPD.

Se débarrasser des données personnelles depuis des fichiers de log (spécialement si elles sont fournies par un service tiers) peut être fastidieux ou même impossible. Loguez donc juste les identifiants si nécessaire, et assurez-vous que les anciens fichiers de log sont nettoyés, juste au cas où.

Il est toujours tentant de placer autant de champs que le designer le souhaite, mais sauf si vous avez absolument besoin des données pour fournir votre service, vous ne devriez pas les collecter. Vous devrez probablement toujours collecter les noms, mais à moins de livrer quelque chose, une adresse personnelle ou un numéro de téléphone est inutile.

Vous êtes responsable s'il y a une fuite de données chez un tiers (c’est-à-dire le tiers effectuant le traitement) à qui vous avez envoyé des données personnelles. Donc avant d'envoyer des données à un autre service via une API, assurez-vous d'au moins un niveau de protection basique. Si ce n'est pas le cas, signalez-le à la direction.

Les informations standards de sécurité et même les standards de données personnelles sont un bon point de départ et représenteront probablement 70 % des éléments requis par la réglementation, mais ne sont pas suffisants. La plupart des choses listées ci-dessus ne sont couvertes par aucun de ces standards.