Anonymiser une base

Version imprimable

11/05/2015, 15h31
c4lypso

Anonymiser une base

Bonjour,

Il existe beaucoup (de plus en plus) d'application qui promette que toutes les données récoltées sont fait de manières anonyme... Je souhaiterai donc comprendre qu'est ce que ca veut dire anonyme d'un point de vue bdd.
Est-ce que juste les noms et prénom et autres identifiant physique sont hashé?
Est-ce qu'on ne pourra pas faire le lien entre les données prélevées, et l'id de la personne?

Je souhaite également savoir comment est-ce possible sachant que le client lui peut récupérer ses données et elles sont bien liée à son compte.

Typiquement ma base présentera les table suivant:
Users
user_id | email | password salt

User_profile
profile_id | user_id | name | forname | etc...

data
data_id | user_id | some data etc...

Comment peut-on donc anonymiser un tel shema (user_id est une clé externe de Users dans les tables User_profile et data)?

Je vous remercie de votre attention.
11/05/2015, 16h11
StringBuilder

Anonyme = aucune information à caractère personnelle n'est stockée.

Généralement, on procède de trois façons :

1/ On a deux bases. Une base de données nominative, dans laquelle on stock si oui ou non une personne est déjà présente dans la seconde. Et une seconde base, sans aucun lien avec la première, qui ne contient aucune donnée permettant de faire le rapprochement avec les données nominatives.

2/ On passe par un tiers qui se charge du boulot de la première base décrite ci-dessus. C'est le cas par exemple des identifiants publicitaires sur internet : d'un site à l'autre, une même personne a le même ID, mais à aucun moment le site n'est capable de retrouver le nom de la personne qu inavigue.

3/ On travaille sur des données cumulées : par exemple, au lieu de stocker dans une table de "réponses" une ligne par sondage, on se contente d'incrémenter une même ligne à chaque fois. C'est la bidouille la moins propre (analyses bien moins aisées), mais la plus simple.
11/05/2015, 17h38
c4lypso

Mouais, ca reste trop vague pour que je me fasse une idée... J'ai du mal a voir comment on peut récupérer certaines valeur si justement la 2ème base n'a aucun lien avec la 1ère...:weird::weird:

De facons générale, quel est le système cryptographique ou autre qui est utilisé pour que l'utilisateur et lui seul puisse récupérer ses données? Exemple.
Il s'inscrit,
ca remplit 2 tables 1 avec mail et mot de passe
et une seconde avec des infos, privée genre nom prénom adresse etc.. Lorsque l'utilisateur consulte son profil il doit pouvoir avoir accès à ses infos.... comment peuvent-elle donc être stockée de façon anonyme?
12/05/2015, 01h33
Artemus24

Salut à tous.

Citation:

Envoyé par C4lypso

Je souhaiterai donc comprendre qu'est ce que ca veut dire anonyme d'un point de vue bdd.

Anonyme ne veut rien dire du tout. Cela voudrait dire que l'on ne soit pas capable d'identifier la personne qui se cache derrière.
Mais cela veut dire aussi que la personne qui s'est incrite ne soit plus en mesure de s'identifier.
Une personne, ce n'est pas que son nom et son prénom. C'est aussi un pseudo, une adresse email, une adresse ip, des identifiants mais aussi des habitudes, voire même ce que l'on révèle lors des échanges dans des messages.
La géolocalisation est un moyen de connaitre son lieu de résidence.

Citation:

Envoyé par C4lypso

Comment peut-on donc anonymiser un tel shema

Je ne comprends même le sens de cette demande.

Par des recoupements, on peut toujours retrouver qui est qui. Mais à quoi cela peut te servir de rendre des informations complètements déconnectées de son utilisateur ?

Citation:

Envoyé par C4lypso

Lorsque l'utilisateur consulte son profil il doit pouvoir avoir accès à ses infos.... comment peuvent-elle donc être stockée de façon anonyme?

Ce n'est pas possible car il faut pouvoir faire le lien avec l'utilisateur.

Tu devrais plutôt te poser la question de se qui est pertinent dans les informations que tu désires stocker.
Ensuite, respecter les recommandations du CNIL sur ce qui est autorisé à faire ou pas.

@+
12/05/2015, 09h44
c4lypso

Ok, c'est bien ce qu'il me semblait. Mais donc du coup quand Google promet que les données récoltée sont anonyme, c'est pas vraiment anonyme vu que typiquement je peux obtenir en me loggant toute les infos des ieu que j'ai visité là par exemple: https://maps.google.com/locationhistory
12/05/2015, 11h26
StringBuilder

Vous confondez :
- Confidentialité et sécurité
- Anonymat de l'application
- Anonymat des données

Pour remprendre :

Confidentialité et sécurité
On met en place des notions de droits sur les éléments sécurables de la base de donnée (mot de passe sur les comptes utilisateurs, restriction des accès des utilisateurs, etc.) et on crypte les données sensibles (mot de passe avec un algo non réversible, données bancaires, etc.)

Anonymat de l'application
C'est l'exemple que j'ai donné. Une application de vote, par exemple, se doit d'être anonyme. Il est strictement interdit de savoir qui a voté pour qui. En revanche il faut être en mesure de savoir qui a voté ou non. On passe alors par deux applications, une qui permet d'identifier qui a voté ou non, et une autre qui ne stocke que les votes, sans lien avec le votant. Les applications de publicité, de sondage et autres sont généralement "anonymes", car cela évite de devoir faire une déclaration à la CNIL.

Anonymat des données
C'est l'exemple d'une base de données de test ou démo. On récupère une base de données "réelle", avec de vraies valeurs, des vrais noms, etc. Sauf que pour des raisons de confidentialité, on modifie ces données nominatives et valuées de façon à ce que les données gardent leur sens (volumétrie, répartition, etc.) mais qu'on ne soit plus capable de dire qui est qui. Par exemple "Monsieur Dupont" devient "Monsieur X", et sa facture de 895,54 € devient 834,47 €. Données sensiblement identiques, mais ne permettant, d'aucune sorte, de retrouver les données réelles en faisant des recoupements avec d'autres données.
12/05/2015, 12h56
c4lypso

Merci de ces précisions!

Ce que je cherche c'est donc bien évidement la confidentialité, hachage du mot de passe avec sel ainsi que les autres données sensible, cela est fait.
Pour ce qui est de l'anonymat, j'aurai bien aimé qu'il existe un moyen du genre "seul l'utilisateur identifié peut accéder a ses données" c'est à dire que sans son mot de passe, ou clé, il est alors impossible de savoir quelle données lui appartiennent dans la table.
Pour être sûre d'être claire encore une fois dans l'autre sens ^^: Depuis la table "données" sensible, on voit tout normalement sauf que il est impossible de savoir quelle ligne correspond a quel utilisateur, en revanche, depuis la table utilisateur, et ayant obtenu le mot de passe, alors il est possible d'obtenir les données...

J'imagine donc une sorte de chiffrement de la foreign key grâce au mot de passe de l'utilisateur... Une tel chose est elle faisable?
13/05/2015, 10h11
SQLpro

Citation:

Envoyé par c4lypso

Merci de ces précisions!

Ce que je cherche c'est donc bien évidement la confidentialité, hachage du mot de passe avec sel ainsi que les autres données sensible, cela est fait.
Pour ce qui est de l'anonymat, j'aurai bien aimé qu'il existe un moyen du genre "seul l'utilisateur identifié peut accéder a ses données" c'est à dire que sans son mot de passe, ou clé, il est alors impossible de savoir quelle données lui appartiennent dans la table.
Pour être sûre d'être claire encore une fois dans l'autre sens ^^: Depuis la table "données" sensible, on voit tout normalement sauf que il est impossible de savoir quelle ligne correspond a quel utilisateur, en revanche, depuis la table utilisateur, et ayant obtenu le mot de passe, alors il est possible d'obtenir les données...

J'imagine donc une sorte de chiffrement de la foreign key grâce au mot de passe de l'utilisateur... Une tel chose est elle faisable?

Pour information les procédés de chiffrement de MySQL comme de PostGreSQL ne sont pas du tout fiable, car il n'y a pas de salage des données chiffrées et que par conséquent cela ne résiste pas aux attaques par analyse fréquentielle.
J'ai démontré la chose en comparant PostGreSQL (qui est bien plus avancé en la matière que ce pseudo SGBDR qui est mySQLmerde) dans ce papier : http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr

A +
13/05/2015, 11h46
c4lypso

Merci pour cet article très intéressant.
Je pense donc faire moi-même (en utilisant des protocole existant donc) de la cryptographie sur certaines valeur d'identification, et du hache avec sel sur les clé.
Users
user_id | email | Sha512(password+salt) | salt

Pour toutes autres tables, reliant les informations a l'utilisateur user_id, un hache serait calculer:

user_id_hash = sha512(password+user_id+salt)
Ou salt et user_id sont des éléments unique créer lors de l'inscription, password est donc le mot de passe utilisateur (passé via tls)
Pour toutes infos, comme nom prénom, et autres, les valeurs serait chiffrée avec un algorithme de cryptage:

Crypto(password + msg)
Ou msg est le message à crypter (nom, prénom etc...) L'utilisateur peut alors récupérer ces informations à l'aide de son mot de passe
User_profile
user_id_hash | encrypted_name | encrypted_forname ....

OTHERS
user_id_hash | clear_data |

Coté "entreprise", le but donc étant de pouvoir faire des études statistiques sur certaines valeur sans pouvoir identifier la personne le user_id_hash est donc utilisé pour déterminer les infos de la même personne. La personne peut elle obtenir toutes ses infos, grâce a son mot de passe, le user_id_hash peut être recalculer et les valeur d'identification déchiffrées.
Est-ce que cela a du sens? Ou je pars complètement faux?

Merci encore pour vos réponses
13/05/2015, 14h41
SQLpro

Ce sont surtout les temps de traitement et particulièrement ceux de cryptage/décryptage qui vont être long.
Mieux vaudrait utiliser un SGBDR qui sait faire cela nativement, comme SQL Server. Si votre volume n'est pas trop important, vous pouvez opter pour la version Express gratuite qui permet des bases de 10 Go, à concurrence de 32760 bases sur la même instance (donc 320 To...)

A +
13/05/2015, 16h06
Artemus24

Salut à tous.

Dans un premier temps, je pense qu'il faut séparer les données confidentielles de celles qui ne le sont pas.
Une base de données contenant par exemple des noms, des adresses, enfin, tout ce qui est autorisé de faire selon la CNIL.
Cette base de donnée ne doit pas être accessible par tout le monde.
Soit par le propriétaire de ses informations, ce qui nécessite alors de conserver un accès sécurisé.
Soit par l'administrateur de du site. Mais là, il s'agit d'avoir confiance en cette personne.

Ensuite, pour identifier ces données, vous utilisez un code qui sera incapable de faire la relation entre ces données confidentielles et celle qui seront accessible par tout le monde.
Un simple numéro peut faire l'affaire, mais pas du genre "DUP7506" pour désigner M. Dupond résidant dans le 75 et dans l'arrondissement 06 de Paris.

Ensuite, Un problème est soulevé, celui de la sécurité qui a été mis en place pour garantir la totale confidentialité des accès à cette base de données.
exemple : les numéros des cartes bancaires !

Actuellement, même s'il existe des protocoles de chiffrements, ils ne sont pas du tout fiable. Et certains le sont encore moins que d'autres.
Le problème du transfert des données confidentielles entre deux points n'a rien à voir avec celle du stockage de ces mêmes données dans la base.

Le problème de la sécurité est celle aussi de la viabilité des données. Plus une donnée à une durée de vie courte, mieux c'est !
Le mieux alors est de rendre ces données inaccesibles par quiconque.

La question soulevé par SQLPRO est fort intéressante, celle du choix du SGBDR.
Hormis les questions de performances (qui ne sont pas à négliger), il faut aussi connaitre ce qui se fait en chiffrement.
Je ne suis pas certain que tout ce qui est proposé soit incassable. Mais la question est surtout en combien de temps.
Mettre le même protocole de chiffrement, c'est aussi idiot que de laisser le même mot de passe pour un compte.

Ce que vous pouvez mettre en place, c'est vérifier qui accéder aux comptes et d'identifier le ou les bonnes adresses IP.
Il y a juste un petit problème à cela, tout le monde n'a pas une adresse ip fixe.

@+
13/05/2015, 17h10
c4lypso

Merci encore a tous pour vos réponse.

La solution avec les adresse IP est a proscrire ici car cette base se trouve derrière une application smartphone. Il est donc impossible, d'avoir une IP fixe.

Le temps de traitement est effectivement important, est nous n'avons pas encore considéré cet aspect. Le fait est que l'enregistrement des données ne requiert pas de traitement rapide... donc pas de problème. Pour ce qui est des étude statistique, les requêtes se feront sans déchiffrage, ce qui donc ne change pas parrapport à une base normale.
Le seul point ou le temps de traitement pourrait être clé, est lorsque l'utilisateur fait des requêtes sur ses infos... Mais cela ne devrai pas arrivé non plus trop régulièrement

Quoiqu'il en soit, je pense partir sur la solution, que j'ai expliqué plus haut, de toute façon on attend pas des masses d'utilisateur au début, on changera par la suite si besoin

Citation:

Envoyé par c4lypso

Users
user_id | email | Sha512(password+salt) | salt

Pour toutes autres tables, reliant les informations a l'utilisateur user_id, un hache serait calculer:

user_id_hash = sha512(password+user_id+salt)
Ou salt et user_id sont des éléments unique créer lors de l'inscription, password est donc le mot de passe utilisateur (passé via tls)
Pour toutes infos, comme nom prénom, et autres, les valeurs serait chiffrée avec un algorithme de cryptage:

Crypto(password + msg)
Ou msg est le message à crypter (nom, prénom etc...) L'utilisateur peut alors récupérer ces informations à l'aide de son mot de passe
User_profile
user_id_hash | encrypted_name | encrypted_forname ....

OTHERS
user_id_hash | clear_data |

Je marque le sujet en résolu, Merci a tous pour vos réponses. Si vous avez encore des informations importantes sur une autre implémentation ou sur pourquoi il ne faut pas faire ce que j'ai l'intention de faire, j'attends vos message!

Merci!