Journal Secure User Data : Reprenons le contrôle de nos données

Sommaire

• Présentation du projet
  • Parlons des données
  • Parlons stockage
  • Parlons accès
  • Conclusion

Lorsque l'on développe une application qui nécessite un compte utilisateur, on demande à cet utilisateur des informations à propos de lui afin de créer son compte et lui offrir les services de notre application.

Le minimum requis c'est le nom d'utilisateur et un mot de passe. Mais si on veut vérifier que le compte que l'on créé est bien relié à un être humain, on va demander une adresse e-mail pour envoyer un lien d'activation du compte.

Selon les applications, plus ou moins d'informations personnelles vont être demandés :

• nom/prénom
• âge
• adresse
• …

Jusqu'à maintenant, on n'avait d'autres choix que de faire confiance au fournisseur pour stocker nos données de manière sécurisée. De plus, si le service nous est vraiment nécessaire, on n'a d'autres choix que d'accepter les CGU parfois douteuses de ce fournisseur.

Comment sont stockées ces données ? Comment savoir ce que le fournisseur possède sur moi ? Comment savoir ce qu'il en fait ? Via des CGU et mentions légales écrites dans la langue juridique ?

Mi ça me va pas, je m'y perd. Et avec les récents événements qui ont envoyé Mr. Zuckerberg devant le congrès américain, nos peurs se confirment. Et les gouvernements ouvrent les yeux et font passer des lois pour nous assurer ces garanties.

Coucou la RGPD !

En tant qu'utilisateur, je suis d'accord sur l'intention. En tant qu'éditeur de logiciel, cela rajoute pas mal de taf pour y être conforme, et les sanctions sont sévères (4% du CA annuel avec un minimum à 20 millions d'€).

On entre dans une période où chaque entreprise, association, … vont fournir de nombreux efforts dans le but d'être conforme. Il serait bon de mutualiser ces efforts.

Comment ? Commençons déjà par fournir une base de travail et essayer de fédérer la communauté autour de cette base pour la rendre applicable !

Présentation du projet

J'ai donc commencé à implémenter ma propre solution pour rendre les applications que ma société développe conforme. Il me semble important de préciser un point important :

Je ne suis ni un expert en sécurité, ni un expert en droit, mon approche est naïve, et je vise à m'entourer des personnes compétentes qui pourront la valider ou m'aider à l'améliorer.

Voilà, ça c'est dit.

Maintenant, commençons par ce que j'ai compris de cette nouvelle loi :

• les données utilisateurs doivent être sauvegardées de manière sécurisée (chiffrée)
• on ne peut utiliser ces données sans l'aval de ce dernier
• à tout moment, l'utilisateur peut révoquer les droits qu'il nous a accordé
• à tout moment, il peut demander un export de l'ensemble des données qu'on a sur lui
• à tout moment, il peut demander la suppression de ces données
• nous sommes soumis à une transparence totale avec nos utilisateurs

NB: N'étant pas un expert en droit, il se peut que j'ai loupé des choses.

Parlons des données

J'ai identifié 3 catégories de données au sein d'une application :

• les données utilisateurs identifiables : nom, prénom, adresse, …
• les données utilisateurs personnelles : messages privés, sessions, …
• les données métiers : statistiques anonymes, tags, catégories, configuration, …

Les données identifiables permettent donc d'identifier un individu réel.
Les données personnelles sont les données qu'un utilisateur produit au sein du service et qui sont liées à ce dernier par son identifiant unique.
Les données métiers sont des données que l'application produit et qui ne sont pas liées à un quelconque utilisateur.

Seule les données identifiables nécessitent d'être chiffrée. Les autres sont par nature pseudonymisée puisqu'elles sont liées à un utilisateur par son identifiant au sein de l'application.

Parlons stockage

Les données identifiables doivent être chiffrées, on va donc générer une clé de chiffrement par utilisateur, qui chiffrera ses données. Cette clé est donc associée à son identifiant.

Cet ensemble de clé, on doit le stocker, et pas en clair tant qu'à faire. Un utilisateur appartenant à une application, on va générer une clé de chiffrement par application. Elle servira a chiffrer les clés utilisateurs en base de données.

Bon maintenant, il faut stocker les clés applications, qui seront associées à un identifiant unique d'application. Elles sont chiffrées à l'aide d'une clé de chiffrement qui réside dans l'environnement (en mémoire donc). Un peu comme le SECRET d'une application web (coucou Django/FLask) qui sert à chiffrer les sessions/cookies.

On a donc :

• un service cryptography qui permet de :
  • générer des clés
  • chiffrer/déchiffrer des données à l'aide d'une clé
• un service app_key_store qui permet de :
  • créer des clés de chiffrement applications associées à un identifiant unique (qui est donc retourné)
  • supprimer une clé d'application à l'aide de son identifiant
• un service user_key_store qui permet de :
  • créer une clé de chiffrement utilisateur associée à un identifiant unique
  • supprimer cet utilisateur
• un service identifiable_data_store qui permet de :
  • créer un profil utilisateur (cela va demander automatiquement la création de l'identifiant et de la clé, et chiffrer les données)
  • récupérer un profil utilisateur (cela va automatiquement récupérer les différentes clés nécessaire au déchiffrement)
  • mettre à jour un profil utilisateur (pareil, tout auto)
  • supprimer un profil utilisateur (pareil, tout auto)
• un service owned_data_store qui permet de :
  • stocker/gérer des données typées associées à un utilisateur

Comme vous le voyez ci-dessus, j'ai choisi de répondre au problème avec une infrastructure en microservice.

On a donc un moyen d'interagir avec les données utilisateurs tout en les gardant en sécurité.

NB: il est nécessaire de confronter ma solution au monde réel, je le rappelle, je ne suis pas un expert en sécurité.

Parlons accès

Au sein de notre application, nous allons avoir différents algorithmes/scripts/programmes qui vont utiliser ces données. L'utilisateur doit pouvoir donner son aval pour chacun de ces ASP (algo, script, programme, jeu de mot pourri).

On a donc besoin de :

• un service data_processing qui permet de :
  • enregistrer un ASP avec les données qu'il va vouloir manipuler (identifiable, owned:<data type>)
  • déclencher l'exécution d'un ASP
  • traquer l'exécution des ASP
• un service authorization_firewall qui permet de :
  • créer des accès aux données (si l'utilisateur autorise un ASP, cela créé un identifiant d'accès)
  • récupérer les données via les accès (va interroger les services identifiable_data_store et/ou owned_data_store en fonction d'un identifiant d'accès)
  • supprimer un accès

On va donc désormais être en mesure de protéger comment les données sont manipulées.

Le service data_processing va donc parler avec le service authorization_firewall pour accéder aux données qu'il va vouloir manipuler. Si un utilisateur n'a pas donné son aval, ses données vont simplement ne pas être transmises à l'ASP.

Imaginons que l'on veuille générer la statistique : nombre de message moyen par utilisateur.

Si un utilisateur ne donne pas son aval pour calculer le nombre de message qu'il a publié, alors ce nombre ne sera pas pris en compte dans la statistique.

Conclusion

Ma solution possède les inconvénients suivants :

• je n'ai pas parlé des backups, si un utilisateur souhaite supprimer ses données, cela invalide les backups
• si un utilisateur retire son aval sur des ASP, les backups sont également invalidés
• quid de la performance ?
• les jointures vont faire mal…

Le début du projet est disponible sur Github. Pure Python 3, avec AsyncIO et sous licence Apache.

Tout est encore brouillon, sujet à être modifié radicalement. Il va évoluer au fur et à mesure que je gagne en compétence sur le sujet et/ou que des personnes compétentes et motivés viennent en renfort.

Pourquoi cet article alors ? Pour faire savoir que je travaille sur le sujet, et que je suis motivé à mutualiser mes efforts avec d'autres pour obtenir une solution facile d'utilisation, facile à intégrer, totalement conforme aux lois et surtout éthique.