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

Posté par (page perso) . Licence CC by-sa
Tags :
17
16
mai
2018

Sommaire

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.

  • # Prescription

    Posté par . Évalué à 2 (+1/-0).

    En droit, la prescription est en règle générale de 5 ans. Mais il y a des exceptions.

    Pour plus de détails voir également ici : https://www.service-public.fr/professionnels-entreprises/vosdroits/F10029

    La durée de stockage peut varier. Ensuite il peut y avoir un contentieux avec un client. Contentieux qui peut durer longtemps et qui engendrera très vraisemblablement un traitement, nécessitant une conservation et un stockage au delà de la durée de prescription.

    Dans le cas du litige, il faudra alors peut être prévoir une base "à part" distincte voire "déconnectée" de la base qui sert au quotidien pour rendre le service.

    Bon cela étant… je ne suis pas du tout informaticien ;-)

  • # Performance

    Posté par (page perso) . Évalué à 2 (+1/-0).

    Donc pour accéder à une donnée de l'utilisateur il y a 3 niveaux de déchiffrement à appliquer. Est-ce que ça ne va pas créer des problèmes de performance ?

    • [^] # Re: Performance

      Posté par (page perso) . Évalué à 2 (+1/-0).

      C'est une crainte que j'ai aussi (comme dit dans le conclusion), et qui va nécessiter de réaliser des benchs.

      Si cela pose problème, il faudra explorer d'autres solutions. L'avantage de la solution présentée ici c'est la compartimentation des utilisateurs ET des applications.

      J'ai choisi d'utiliser asyncio pour permettre au serveur de mieux paralléliser, mais je n'ai aucun chiffre pour assurer mes dires.

      Je vise à avoir d'abord un PoC qui soit testable avant de passer à l'étape d'optimisation.

    • [^] # Re: Performance

      Posté par . Évalué à 6 (+6/-0).

      Surtout que le RGPD n'impose nullement le chiffrement des données, c'est surtout un argument utilisé par les vendeurs de solutions de chiffrement : "Chiffrez, vous serez sauf !" (comprendre : "Achetez ma solution !").

      Voir ce billet pour plus de détails : https://www.comptoirsecu.fr/blog/2018-01-28-rpgd-le-chiffrement-ne-vous-absoudra-pas/

      Après sur le principe ce n'est pas une mauvaise chose, mais c'est très compliqué et une architecture de chiffrement à plusieurs étages c'est super pour garantir que même le plus superadmin n'aura jamais accès au données (seul ceux qui doivent le peuvent). Mais ça reste à réserver à des données vraiment critiques, car ça peux vite devenir un enfer quand il s'agit de donner des accès ensuite à certaines personnes.

      De ce que je comprend du RGPD, c'est surtout les grands principes et donc les bonnes pratiques qu'il faut suivre. Vous ne serez pas poursuivi si une liste d'utilisateur avec les emails n'est pas chiffré dans une DB, si les accès au serveurs sont limités, et que la sécurité de l'infrastructure est ok, et que si en cas de vol de données vous suivez les consignes du règlement.

  • # outil schémas

    Posté par . Évalué à 2 (+0/-0).

    En lisant la page du repo, je me demandais avec quoi est fait le schéma de la solution ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.