Différences

Ci-dessous, les différences entre deux révisions de la page.

--- wiki:divers:gestion_log_rgpd [2018/07/05 15:26]
varens [Et l'utilisation des logs alors ?]
+++ wiki:divers:gestion_log_rgpd [2020/06/27 18:16] (Version actuelle)
@@ Ligne 25: / Ligne 25: @@
 ^fonction\infrastructure^centralisée^décentralisée^
-|possibilité de démarrer une machine générant des logs sans dépendance (supplémentaire)|<color #ed1c24>✘</color>|<color #22b14c>✔</color>|
+^possibilité de démarrer une machine générant des logs sans dépendance (supplémentaire)|<color #ed1c24>✘</color>|<color #22b14c>✔</color>|
-|récupération des informations facile |<color #22b14c>✔</color>|<color #ed1c24>✘</color>|
+^récupération des informations facile |<color #22b14c>✔</color>|<color #ed1c24>✘</color>|
-|perte de logs quasi-impossible|<color #ed1c24>✘</color> il y a des problématiques d'envoi de logs|<color #22b14c>✔</color>|
+^perte de logs quasi-impossible|<color #ed1c24>✘</color> il y a des problématiques d'envoi de logs|<color #22b14c>✔</color>|
-|chiffrement|<color #22b14c>✔</color>|<color #22b14c>✔</color>|
+^chiffrement|<color #22b14c>✔</color>|<color #22b14c>✔</color>|
-|connexion à une BDD pour les clés de chiffrement|une seule|chaque machine|
+^connexion à une BDD pour les clés de chiffrement|une seule|chaque machine|
-|redondance|disque de(s) machine(s) + infrastructure de stockage choisie|disque de machine|
+^redondance|disque de(s) machine(s) + infrastructure de stockage choisie|disque de machine|
-|stockage|n'importe quelle solution|limité (on ne va pas installer un SGBD sur chaque machine), fichier texte simple|
+^stockage|n'importe quelle solution|limité (on ne va pas installer un SGBD sur chaque machine), fichier texte simple|
 N'hésitez pas à compléter ce comparatif
-Cependant, on sait dejà 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 ce 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.
+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.
 === Quel chiffrement ? ===
@@ Ligne 48: / Ligne 48: @@
-Pour que le chiffrement ai 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.
+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 (l'asynchrone oblige).
+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'example qui montre son utilisation.
+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.
@@ Ligne 62: / Ligne 62: @@
 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 [[https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir|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  [[https://fr.wikipedia.org/wiki/Partage_de_cl%C3%A9_secr%C3%A8te_de_Shamir#Propri%C3%A9t%C3%A9s|Propriétés]] de l'article Wikipédia.
 On peut prévoir l'ajout de fonctionnalités sympa :
@@ Ligne 71: / Ligne 77: @@
 === Et l'utilisation des logs alors ? ===
-En effet dans le cas des logs passerelle wifi ou encore proxy, clairement on s'en 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".
+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, pour 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.
+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 au point actuellement.
+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 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.
+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.
@@ Ligne 88: / Ligne 94: @@
   * On peut bloquer l'accès avant la fin de la période
-En pratique comment ça fonctionne derrière ? Allons y par étape, en essayant d'imaginer qu'on a les fonctionnalités
+Ci-dessous, ce qui avait été imaginé avant d'envisager l'utilisation du partage de clé secrète de Shamir :
+<wrap lo>
+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 [[https://wiki.minet.net/wiki/divers/gestion_log_rgpd#quel_chiffrement|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.
+</wrap>
+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.
+===== Les choix =====
+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 8-) ).
+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 :
+{{:wiki:divers:log_rgpd.png?600|}}
+<WRAP center round info 95%>
+Autant tout le chiffrement RSA est implémenté très proprement dans des librairies auditées et très utilisées, autant je ne crois pas avoir trouvé d'implémentation "connue" du partage de clé privée de Shamir. Cela veut dire qu'il faut soit "roll our own crypto" (pourquoi pas, mais c'est risqué), soit utiliser des projets existants et les auditer nous-même (c'est sans doute déjà mieux).
+Update: il y a quand même [[http://point-at-infinity.org/ssss/|ssss]] qui a l'air bien sérieux
+ --- //[[frazew@minet.net|François Horta]] 2019/02/21 06:38//
+</WRAP>
+<WRAP center round info 95%>
+J'ai écris cette proposition (qui est incomplète) sans avoir fait de tests, rien du tout, c'est pour l'instant juste une réflexion, il y aura donc peut etre des choix qui seront remis en question au moment des tests, on pourra d'ailleurs faire des tests en dev comme en prod où on combinera pendant un certain temps l'ancien et le nouveau modèle, histoire de vérifier que tout fonctionne bien (d'ailleurs pour les logs de traffics, sensibles donc, on pourra garder la solution de stockage en local en plus, indéfiniment, au sens de la solution, pas des données :-) , il y aura cependant peut-etre des écarts avec l'autre solution : des choses en plus en local) --- //[[varens@minet.net|Romain Cherré]] 2018/07/05 16:33//
+</WRAP>

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page