Discussion :

[c4lypso]

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.

[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.

[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...

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?

[Artemus24]

Salut à tous.

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.

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 ?

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.

@+

[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

[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.

[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?

[SQLpro]

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 +

[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.

@+