Cet article décrira principalement la gestion des logs, le reste des données personnelles posant moins problèmes dans la mesure où des requetes SQL devraient suffire à extraire les données

De plus l'idée est de réaliser un outil le plus général possible, simple et adaptable pour n'importe quel système, ça évitera de s'arracher les cheveux lorsqu'un nouveau service demandera du traitement de données personnelles sans prévoir jusqu'au bout le RGPD, notamment la partie récupération de données. Cela permettra également de fournir à la communauté un outil pour le faire (ce que je n'ai pas trouvé au moment où je rédige ce paragraphe)

Vive MiNET, contribution swaggée ! (euh on se calme, faut réaliser l'outil avant hein)

Dans le cadre du RGPD, nous devons pouvoir permettre aux adhérents, et plus généralement aux utilisateurs de nos services de récupérer leurs données personnelles. C'est dejà le cas, mais ce n'est pas automatisé et c'est laborieux (se connecter sur les différentes machines, déchiffrer au besoin et récupérer que ce qui appartient à une personne donnée)

L'idée est d'essayer d'automatiser le processus, pour pouvoir in fine proposer une interface web, sur laquelle on peut récupérer nos données personnelles et supprimer ses données/son compte lorsque cela est possible. La suppression et/ou modification des données est effectivement un droit mais il ne peut pas s'appliquer à toutes les données, par exemple les données que nous conservont dans le cadre du respect de la loi : pouvoir identifier qui avait qu'elle adresse IP, à quel moment. Il y a aussi l'exemple de la passerelle Wifi qui rappelons le utilise une fonction de NAT, et donc identiquement, sauf que la phrase se transforme en : qui a visité quoi à quel moment.

D'autres données personnelles sont collectées pour différentes raisons : adresse mail pour le contact, logs d'authentification pour résoudre les problèmes de configuration des appareils, etc.

Il y a d'emblée deux solutions (qui peuvent éventuellement etre mixées) :

• centraliser les logs
• décentraliser, les logs restent sur les machines

Elles ont chacunes leurs avantages et inconvénients :

N'hésitez pas à compléter ce comparatif

Cependant, on sait déjà que pour certains services on devra aller chercher les données à un autre endroit (par exemple mattermost, ou encore adh, bref toutes les données personnelles qui ne sont pas des logs), cependant si on choisi de centraliser, alors ces données ne seront pas des logs (car il suffira de les envoyer au système de traitement), donc probablement des données dans une BDD, ou autre, pour savoir rien de mieux que de réaliser une liste des données personnelles que nous traitons (au sens du RGPD). Oui parce que tant qu'à faire prévoyons dès maintenant l'usage de l'appli web, pour récupérer non seulements des logs mais aussi tout le reste, provenant de n'importe quel service tant que c'est sur notre infra.

Dans le cas des données sur le traffic, on doit prévoir de chiffrer deux fois le meme log, avec deux clés différentes : la clé du Président et celle de l'adhérent à qui appartient la donnée personnelle (le log), pour pouvoir les déchiffrer si on nous les réclame (dans le cadre d'une enquete, P2P, etc)

Dans le cas des données personnelles lambda (c'est pas le traffic quoi), on peut simplement chiffrer avec la clé de l'adhérent.

Pour que le chiffrement ait véritablement une utilité, vous conviendrez que l'on doit choisir une clé de chiffrement asymétrique, cela permettra de pouvoir laisser les gens administrer les machines, et pas juste le Président.

Certe on pert en perfomance, mais on gagne en sécurité, maintenabilité, et vous allez voir, normalement au niveau performance on a un peu de marge.

Bien sur aujourd'hui on utilise très rarement des algorithmes de chiffrement asymétrique pour faire du chiffrement, on les utilise plutot pour de l'authentification et ensuite on réalise un échange de clé symétrique. Cependant dans notre cas, nous n'avons pas trop le choix et RSA est dejà utilisé pour le chiffrement des mails, en fait c'est l'asynchrone qui nous oblige l'utilisation de l'asymétrique.

Il y a également ECIES comme algorithme de chiffrement asymétrique (à base de courbes elliptiques), mais je n'ai pas trouvé d'examples qui montre son utilisation.

En toute logique la clé du Président ne pose pas de problème (clé publique où il faut et la privée reste privée)

Et pour les adhérents ? Le mieux qu'on puisse faire c'est générer une clé privée à l'inscription, qui sera chiffrée avec comme passphrase le mot de passe de leur compte. Ainsi quand on prépare l'archive contenant toutes les données personnelles, on peut déchiffrer la clé en demandant le mot de passe, puis déchiffrer les données.

Mais alors on a un problème : l'adhérent peut oublier son mot de passe (et ça arrive TRÈS souvent). Dans ce cas, on ne peut plus déchiffrer les données, et on perd tous ses logs. Il y a une solution élégante à ce problème : on utilise le Partage de clé secrète de Shamir (SSS). On chiffre avec son mot de passe une clé symétrique intermédiaire, que l'on subdivise aussi en plusieurs secrets via SSS que l'on “distribue” aux membres du bureau. Cette clé sert de passphrase à sa clé privée RSA. Cela ouvre de nouvelles possibilités :

• si l'adhérent oublie son mot passe, il suffit d'avoir suffisamment de “morceaux” générés par SSS pour recouvrir la clé et on ne perd rien
• si l'adhérent refuse de coopérer dans le cadre d'une plainte par exemple, on peut procéder de même et retrouver la passphrase via une majorité de membres du bureau

Je vous laisse découvrir plus en détails les avantages de l'utilisation de ce protocole, notamment via la partie Propriétés de l'article Wikipédia.

On peut prévoir l'ajout de fonctionnalités sympa :

• déchiffrement dans le navigateur
• possibilité pour l'utilisateur de gérer lui meme le déchiffrement : il peut télécharger sa clé et déchiffrer le contenu de l'archive, bien sur il faudra fournir de la documentation pour le faire
• remplacement de la clé par l'utilisateur
• rotation des clés ?

En effet dans le cas des logs passerelle wifi ou encore proxy, clairement on se fiche de pouvoir les consulter, mais des logs d'authentification radius, c'est une autre histoire. C'est quand meme pratique de pouvoir dire : “il faut que tu retapes ton mot de passe, il n'est pas bon”, ou encore : “tu as oublié d'ajouter ton adresse MAC, c'est pour cela que ça ne fonctionne pas”.

Dans tous les cas, ce genre de logs peuvent etre chiffrés et gardés également en clair, ou alors chiffrés mais avec une clé disponible pour les applications qui utilisent ces logs (typiquement ADH) et empecher ainsi le fait de pouvoir avoir des données personnelles comme on veut.

Si on voulait aller plus loin il faudrait que l'on puisse faire du Searchable Encryption, ce qui est possible, mais c'est encore trop naissant et pas forcément au point actuellement. Je n'ai pas encore trouvé d'implémentation.

Une autre solution est de ne pas chiffrer betement tous les logs mais d'anonymiser les logs, on garde ainsi un oeil général (on peut anonymiser le numéro de port par exemple dans les logs du type Port UP, Port DOWN), qui permet encore de savoir si tout va bien, non plus à l'échelle d'un individu, mais par exemple d'un switch, ou d'un service, etc.

Pour gérer le cas de l'échelle d'un individu, le plus simple et le plus respectueux de la vie privée reste d'avoir un système qui permet à une personne de débloquer le chiffrement pour une certaine période, afin qu'un administrateur puisse regarder ce qui ne vas pas.

Sachant qu'il serait bien d'avoir un système qui permette de débloquer l'accès pour un administrateur qui est à distance (plus simple et s'étend au delà de MiNET), je vois donc bien les fonctionnalités suivantes pour ce genre de système :

• bouton sur l'interface client : Débloquer l'accès aux administrateurs aux logs de l'application X
• Sélection d'une période de débloquage possible
• On peut bloquer l'accès avant la fin de la période

Ci-dessous, ce qui avait été imaginé avant d'envisager l'utilisation du partage de clé secrète de Shamir :

En pratique comment ça fonctionne derrière ? Allons y en essayant d'imaginer qu'on a les fonctionnalités pour la gestion des clés décrites dans la partie chiffrement. Le déchiffrement dans le navigateur, et meme pire le remplacement de la clé de chiffrement nous empeche de chiffrer puisqu'on ne pourra pas déchiffrer à moins de demander à chaque fois à l'utilisateur, ce qui est très pénible. Je vois alors deux possibilités : * On continue de chiffrer et on utilise du Asymmetric Searchable Encryption (ASE), mais il faudra alors peut etre d'autres clés et dans tout les cas l'ASE demanderait à l'utilisateur de “chiffrer” les mots que l'on va chercher dans ses logs (et encore une fois, c'est peut etre encore un peu trop neuf, quand ce sera utilisé par des entreprises on pourra éventuellement y réfléchir, ou y réfléchir en tant qu'amélioration, mais sur toute la solution, concentrons nous sur quelque chose de fonctionnel, tant pis si il y aura beaucoup de choses à adapter, cependant c'est une piste très interessante) * On ne chiffre pas ses logs temporairement, ou plutot on stocke temporairement en plus de la version chiffrée un version non chiffrée, que l'on peut récupérer soit dans l'application métier, soit dans l'application de gestion des logs, bref de la façon dont on souhaite. En ce cas la fin de la période arrete le stockage en non chiffré pour la personne et supprime les logs stockés en clair.

Grâce au partage de clé secrète de Shamir, on peut demander à l'adhérent de fournir à un administrateur l'accès à ses logs (il déchiffre la clé grâce à sa passphrase). S'il n'accepte pas, ou si on ne veut pas toujours avoir à demander à l'adhérent, on peut utiliser les pièces distribuées aux membres du bureau pour reformer la clé. On peut par ailleurs imaginer que certains membres puissent avoir plus de pièces que les autres, afin de pouvoir reformer la clé seuls, ou avec moins de membres. Tout ceci est, bien sûr à définir.

Maintenant qu'on a exposé les différentes solutions, il va falloir commencer à faire des choix.

Reprenons dans l'ordre : on choisi la manière centralisée, car elle simplifie grandement le CRUD et chiffrement asymétrique avec RSA (symètrique n'a pas vraiment d'effet et RSA est assez utilisé)

Bon il va falloir décider de comment on fait notre jolie moulinette à logs, sachant qu'il va falloir au mieux répondre aux deux inconvénients de la solution, à savoir :

• perte de logs possible dans certains cas (la gravité dépend du type de log)
• et on ne peut pas démarrer les services (dans une certaine mesure vous allez voir) dont on veut absolument stocker les logs sans que l'infra de centralisation de logs soit prete

Y'a tout de meme des choses assez simples que l'on va décider maintenant. On choisit syslog et plus précisément rsyslog pour envoyer les logs à notre service de gestion de logs (On va essayer de mettre ça en HA tant qu'à faire : secure, and highly available by design : oh lala ).

Rsyslog car c'est déjà sur nos machines, on l'utilise déjà et sur les switchs c'est le meme protocole, donc on part là-dessus.

Pour ce qui est de les recevoir ? On utilise déjà logstash et elasticsearch pour stocker, et après vérification logstash à les plugins qu'il faut pour ce que l'on veut faire, donc partons sur ça.

Pour l'interface web, j'avoue ne pas vraiment savoir, on a pas forcément besoin d'un gros truc, certains sites web faits maison tournent dejà avec python, mais peut-etre que juste un Symfony permettrait de ne pas se casser la tete. Après en terme de code, il y a pas grand chose, en gros pour l'export c'est une requete SQL (qui dépend de la personne) par service, et si on fait bien notre stockage, une requete HTTP sur le cluster elasticsearch pour les logs. Et il faudra faire un peu de gestion de clés, donc je propose python pour la simplicité et parce que c'est populaire et qu'on est censé en faire en classes préparatoires, donc c'est censé etre maintenable (modulo la lisibilité et propreté du code bien sur)

Bon je crois que c'est le temps des schémas pour que tout le monde comprenne :