Discussion :

[vmonteco]

Bonjour,

Nous nous trouvons confrontés, avec un collègue, à une difficulté concernant la protection de données médicales dans une base de données.

Je suis en stage dans une start-up et nous devons faire un site manipulant des informations médicales.
Pour des raisons légales nous devons donc restreindre l'accès aux informations enregistrées en BDD à l'utilisateur concerné, même l'adminsys ne doit pas avoir accès à ces informations (donc pas de clé permettant le déchiffrement en BDD).

Sans vraiment connaître les outils ou techniques pouvant exister pour une telle problématique nous avons imaginé le système suivant :
À l'inscription, une clé publique et une privée propres à l'utilisateur sont générées (Avec le RSA par exemple). Seule la clé publique est conservée en base de données.
La clé privée est générée localement à chaque session par l'utilisateur à partir d'une information que nous ne connaissons pas (au hasard, le mot de passe passé dans une fonction de hachage par exemple).

Les données sont transférées chiffrées et sont déchiffrées localement (avec du javascript par exemple).
Les nouvelles données sont chiffrées avec la clé publique (ça peut être aussi un message privé pour un autre utilisateur par exemple) (localement ou côté serveur? Nous nous posons la question).

Le soucis est que si on veut laisser à l'utilisateur la possibilité de changer son mot de passe, il faut pouvoir déchiffrer l'intégralité des données, changer la clé publique et chiffrer à nouveau les données (le tout localement?!) avec la nouvelle clé publique.

Voici donc où nous en sommes.
Nous cherchons des idées, des pistes ou des conseils pour améliorer le système, des avis, qu'ils soient positifs ou négatifs, ou des alternatives que vous pourriez connaître.

Qu'en pensez-vous?

Merci d'avance!

[SQLpro]

Beaucoup de choses à dire et je n'ai hélas pas le temps, mais :
1) vous ne pouvez pas changer dynamiquement la clef par session
2) un hachage n'est pas une méthode de cryptage
3) certains SGBDR (MySQL, PostGreSQL... en particulier) ne protègent pas suffisamment les données cryptées notamment par un salage ou une génération de clef externe ce qui oblige à stocker les clefs dans des fichiers sur le serveur ou encore avoir des données cryptées qui ne résistent pas à l'analyse fréquentielle.

Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1...dans-les-sgbdr

Pour info, j'ai été consulté par une entreprise qui fait de la gestion de diabète en ligne....

A +

[vmonteco]

Bonjour, Merci pour votre réponse.

1) Je ne suis pas sûr d'avoir bien compris ce que vous dites, mais l'idée serait de télécharger l'ensemble des données chiffrées sur le poste du client, les déchiffrer avec la clé privée propre à la session (obtenue à chaque fois à partir du mot de passe, donc identique à chaque fois), avant de les chiffrer à nouveau avec la nouvelle clé publique, pour les renvoyer en BDD.
2) Je le sais parfaitement. Mais je ne souhaitais pas utiliser une fonction de hachage pour chiffrer les données, simplement pour générer la clé privée à chaque session (et la clé publique lors de sa création). Ensuite, "fonction de hachage" ne serait pas vraiment le terme juste, effectivement. Il s'agirait d'une fonction prenant une chaîne de caractères en paramètre (comme le mot de passe par exemple) et générant deux clés privée et publique pseudo-aléatoires, utilisables avec un certain système de chiffrement asymétrique.
3)Vous voulez dire que les outils proposés par ces SGBDR que vous citez ne sont pas assez sûrs? Ils font quoi? Ils s'occupent du chiffrement et conservent les clés? (C'est une vraie question, j'en ignore la réponse). Et si on chiffre ailleurs que le serveur. (que le serveur ne reçoit aucune donnée en clair, et que la BDD ne conserve que les clés publiques et hashs de mot de passe)?

Je vais regarder votre article. Merci encore!

EDIT :
Un étudiant de mon école m'a suggéré une idée que je trouve excellente :
Il s'agirait de chiffrer les données avec une clé obtenue aléatoirement.
Et de conserver cette clé en BDD mais chiffrée avec une autre clé "secondaire" provenant elle du mot de passe.
En cas de changement de mot de passe il suffirait de déchiffrer et de rechiffrer la clé "principale" avec la nouvelle clé "secondaire". (Au lieu de déchiffrer et de rechiffrer toute la base de données.).

Par contre un autre soucis auquel je n'avais pas pensé, c'est que si l'utilisateur perd son mot de passe, les données ne seront pas vraiment récupérables.

[SQLpro]

... l'idée serait de télécharger l'ensemble des données chiffrées sur le poste du client, les déchiffrer avec la clé privée propre à la session (obtenue à chaque fois à partir du mot de passe, donc identique à chaque fois), avant de les chiffrer à nouveau avec la nouvelle clé publique, pour les renvoyer en BDD.

Totalement irréaliste et pour 3 raisons...
1) le coût/le temps : chiffrer coute très cher en traitement et donc votre utilisateur aura largement le temps d'aller pisser, faire causette et boire son café... De plus si le PC plante pendant cette phase vous devez tout recommencer
2) la très mauvaise sécurité : le principal trou de sécurité dans un SI vient TOUJOURS de l'intérieur... Soit c'est l'utilisateur (il a été viré, mais à copié la base sur une clef...) ou bien il a été négligeant (allant aux toilette il a oublié de ferme son poste...)
3) la concurrence : une base de données est faite pour être utilisé en concurrence c'est à dire par de nombreux utilisateurs. Comment résoudrez vous les conflits de mise à jour si 2 utilisateurs ont modifié la même info chacun de leur côté ?

2) Je le sais parfaitement. Mais je ne souhaitais pas utiliser une fonction de hachage pour chiffrer les données, simplement pour générer la clé privée à chaque session (et la clé publique lors de sa création).

Les clefs publiques et privées étant liées, chaque fois que vous faites cela vous devez recrypter toutes les informations. Comme chaque utilisateur aura une clef différente c'est totalement impossible !

3)Vous voulez dire que les outils proposés par ces SGBDR que vous citez ne sont pas assez sûrs? Ils font quoi? Ils s'occupent du chiffrement et conservent les clés? (C'est une vraie question, j'en ignore la réponse). Et si on chiffre ailleurs que le serveur. (que le serveur ne reçoit aucune donnée en clair, et que la BDD ne conserve que les clés publiques et hashs de mot de passe)?

Peu de SGBDR svant correctement faire ce boulot. Parmis ceux là il y a IBM DB2, Oracle et SQL Server. Le reste c'est mauvais (PostGreSQL) à catastrophique (MySQL). Quand à chiffrer déchiffrer en dehos de la base c'est pire encore.

Enfin certains SGBDR (oracle, SQL Server) proposent le "Transparent Data Encryption". Le stockage est entièrement crypté, donc le vol des fichiers de la base comme des sauvegardes ne sert à rien. En revanche les informations sont en clair en mémoire. C'est le meilleur des deux mondes : protection efficace et performances optimale. Car ne l'oubliez pas en cas de cryptage des données, les performances sont particulièrement mauvaise !

Je vais regarder votre article. Merci encore!

EDIT :
Un étudiant de mon école m'a suggéré une idée que je trouve excellente :
Il s'agirait de chiffrer les données avec une clé obtenue aléatoirement.

Totalement débile pour les mêmes raisopns qu'évoquées ci avant...

Et de conserver cette clé en BDD mais chiffrée avec une autre clé "secondaire" provenant elle du mot de passe.
En cas de changement de mot de passe il suffirait de déchiffrer et de rechiffrer la clé "principale" avec la nouvelle clé "secondaire". (Au lieu de déchiffrer et de rechiffrer toute la base de données.).

Par contre un autre soucis auquel je n'avais pas pensé, c'est que si l'utilisateur perd son mot de passe, les données ne seront pas vraiment récupérables.

TOUJOURS....

Bref, commencez par étudier à fond les mécanismes de cryptage car vous faites totalement fausse route. Étudiez aussi ce qu'il y a dans chaque SGBDR et en particulier chez les "grands"....
Exemples :
Chiffrement SQL Server
Chiffrement transparent des données (TDE)
SQL Server et clés de chiffrement de base de données
Chiffrement des connexions à SQL Server

A +


A +

[vmonteco]

Je suis d'accord avec quelques remarques, mais pour le reste je ne me suis peut-être pas expliqué assez clairement (je ne suis pas tout à fait d'accord), je vais apporter quelques précisions pour dissiper un éventuel malentendu.
À l'inscription d'un utilisateur, un couple de clés publique et privée est créé (Appelons-les clés A-publique et A-privée), elles sont propres à l'utilisateur (Donc pas de couple de clés unique pour l'intégralité de la BDD).
La clé A-publique est enregistrée en clair dans la BDD à côté des données de l'utilisateur et sert à chiffrer les données de cet utilisateur. La clé A-privée sert à les déchiffrer et est également enregistrée en BDD, mais pas en clair.
Elle est en effet chiffrée avec une seconde clé (clé B) qui provient du mot de passe.
Cette clé B ne transite jamais par le serveur, elle reste en local, côté client, et est retrouvée à l'aide du mot de passe lors de la connexion.
Par contre il n'a jamais été question d'envoyer l'intégralité de la BDD sur la machine cliente pour le déchiffrement/chiffrement/changement de mot de passe, tout au plus j'ai évoqué la possibilité d'envoyer les données relatives à l'utilisateur, mais comme je l'explique plus bas je n'estime plus cela envisageable, nous sommes donc à priori d'accord là-dessus.
L'accès est bien entendu restreint, pas moyen de copier l'intégralité de la BDD. Et le risque que vous évoquez (que quelqu'un utilise sa session dans son dos) ne concerne que le dit utilisateur, et c'est un soucis qui se trouve aussi par exemple pour les boites mail par exemple.

Donc :
-Si l'utilisateur veut consulter des données, il reçoit la clé A-privée chiffrée et les données demandées, chiffrées également.
Il peut ainsi, avec la clé B (obtenue à partir du mot de passe au log-in), déchiffrer la clé A-privée, puis déchiffrer les données, le tout localement.
(Attention, il ne s'agit pas forcément de déchiffrer toutes les données, cela peut aussi être une sélection assez légère parmi les données enregistrées, qui ne surchargera pas forcément le navigateur).
-Si l'utilisateur veut ajouter des données, il lui suffit d'utiliser la clé A-publique (Cela peut être aussi un message privé à un autre utilisateur, donc dans ce cas c'est la clé publique de cet utilisateur qui est utilisée).
-Si l'utilisateur veut changer de mot de passe, il lui suffit de convertir la clé A-privée, i-e :la recevoir du serveur, la déchiffrer avec l'ancienne clé B, la chiffrer à nouveau avec la nouvelle clé B avant de l'uploader avec le nouvel hash de mot de passe. Il ne s'agirait donc plus de télécharger->convertir->uploader l'intégralité des données de l'utilisateur, mais une simple clé (Cela me semble accessible pour la grande majorité des machines ).

Pour ce qui est des conflits de mise à jour cela devrait être négligeable pour ce que l'on veut faire, Ce pourrait être à la limite avec un cas tordu, je peux très bien ne pas avoir pensé à un tel cas, mais à priori je ne vois pas.

Je vous remercie à nouveau pour ces liens, c'est toujours bon à prendre et si ça se trouve je trouverai quelque-chose de mieux.
Mais ce que je propose me semble viable, ou en tout cas je ne vous suis pas sur ce que vous invoquez comme explication pour dire le contraire. :/
Maintenez-vous toujours cela après les précisions que j'ai essayées d'apporter? Si c'est le cas je ne vous comprends peut-être tout simplement pas. :/

[SQLpro]

Encore une fois vous faites fausse route. Vous ne pouvez pas avoir une clef différente pour chaque utilisateur pour chiffrer/déchiffrer les mêmes données, que ce soit une clef symétrique (clef unique de cryptage décryptage) ou qu'elle soit asymétrique (clef de cryptage publique et clef de décryptage privée).

Dans une base de données il n'y a pas de données appartenant à un utilisateur, mais des données communes à tous...
Sinon il serait impossible de mettre la moindre contrainte (celf pimaire, étrangère, unicité, validation....).

Visiblement vous ne maîtrisez aucun des sujets :

• vous ne comprenez rien des bases de données
• vous ne savez pas comment fonctionne le cryptage

Commencez par apprendre !!!

[alassanediakite]

Bonjour

...
Pour des raisons légales nous devons donc restreindre l'accès aux informations enregistrées en BDD à l'utilisateur concerné, même l'adminsys ne doit pas avoir accès à ces informations (donc pas de clé permettant le déchiffrement en BDD).

Il me semble que d'après Microsoft

"Un système n'est sécurisé que si son administrateur est digne de confiance"

D'ailleurs "trop de sécurité tue la sécurité".
Pour ma part, le chiffrement évite un accès aux données à partir du système de fichier (une copie de la base (ou sauvegarde) qu'on charge sur un autre serveur. Pour l'accès à partir du SGBD on utilise la sécurité par utilisateur et mot de passe.

Dans une base de données il n'y a pas de données appartenant à un utilisateur, mais des données communes à tous...
Sinon il serait impossible de mettre la moindre contrainte (celf pimaire, étrangère, unicité, validation....).

Quel mot convient à la place de "appartenir" si (Je ne vous l'apprends pas): dans une école, on permettra à chaque prof d'enregistrer ses notes d'évaluations, tout le monde peut les voir mais chaque prof doit être seul à pouvoir modifier ce qu'il a entré.
@+

[vmonteco]

Vous ne pouvez pas avoir une clef différente pour chaque utilisateur pour chiffrer/déchiffrer les mêmes données.

Quand vous dites "les même données", vous parlez de l'intégralité de la BDD?
Je parle des données relatives à un individu (donc une entrée dans une table par exemple).
Je ne compte pas chiffrer les données qu'entrerait un utilisateur avec sa clé, pour essayer de les déchiffrer avec la clé d'un autre utilisateur si c'est ce que vous voulez dire.

Dans une base de données il n'y a pas de données appartenant à un utilisateur, mais des données communes à tous...

Les entrées peuvent tout de même être associées à un utilisateur. Après oui, les données se retrouvent toutes dans la même base de donnée et éventuellement toutes dans la même table, mais en quoi cela implique-t-il l'impossibilité d'un chiffrage individuel pour certaines informations de chaque entrée?

Sinon il serait impossible de mettre la moindre contrainte (celf pimaire, étrangère, unicité, validation....).

Ce problème intervient selon vous même si on laisse lisibles les données nécessaires au système pour fonctionner? (aussi bien les clés primaires que les mails utilisés comme identifiants et hash de mot de passe (pas les mots de passe tout court bien sûr) je veux dire).
Il me semble tout de même possible d'identifier et de manipuler les différentes entrées pour peu qu'on laisse en clair certaines informations sans pour autant compromettre l'identité de l'utilisateur.

"Un système n'est sécurisé que si son administrateur est digne de confiance"

Je vois ce que vous voulez dire, mais la CNIL impose -sauf erreur de ma part- certaines règles, et vu que les données médicales sont particulièrement sensibles. Nous aimerions garantir dans la mesure du possible une confidentialité maximale. :/
Et on ne peut pas vraiment dire à la CNIL "Ne vous en faites pas, toutes les données soumises au secret médical sont en clair, mais l'accès est restreint et notre adminsys est digne de confiante". :/

Ensuite oui, on peut trouver des protections plus "softs" sans pour autant laisser en clair, mais ce que j'ai évoqué est une piste que j'aimerais explorer. :/

[aieeeuuuuu]

Bonjour,

Je rajouterai deux choses :

1/ absolument personne, hormis l'utilisateur lui-même ne devra accéder aux données (médecins, statistique anonymes,...) ?

2/ comment ferez vous si un utilisateur oublie son mot de passe ? Ses données deviendront de fait irrécupérables.

[vmonteco]

Bonjour,

Je rajouterai deux choses :

1/ absolument personne, hormis l'utilisateur lui-même ne devra accéder aux données (médecins, statistique anonymes,...) ?

Pour certaines données, oui.

2/ comment ferez vous si un utilisateur oublie son mot de passe ? Ses données deviendront de fait irrécupérables.

C'est exact.
Nous étudions l'idée de la génération d'une clé de secours pour l'utilisateur, à imprimer et à conserver, éventuellement avec certaines restrictions/sécurités, mais nous en débattons encore.
Mais même dans ce cas il existerait tout de même un risque pour que les données soient totalement irrécupérables, effectivement. Mais c'est aussi un peu le principe des protections que nous souhaitons mettre en place.

[punkoff]

bonjour,


Partez du principe que l'utilisateur perdra toujours sont mot de passe voir sont identifiant de connexion.

Cela arrivera, et si vous lui répondez "désolé vous n'auriez pas du perdre votre mot de passe" vous avez de grandes chance de perdre un client

[vmonteco]

bonjour,


Partez du principe que l'utilisateur perdra toujours sont mot de passe voir sont identifiant de connexion.

Cela arrivera, et si vous lui répondez "désolé vous n'auriez pas du perdre votre mot de passe" vous avez de grandes chance de perdre un client

Ce n'est pas faux, effectivement.
Il faudrait donc soit :
-se pencher vers un autre moyen de protection des données.
-trouver un moyen pour que l'utilisateur puisse regénérer/retrouver une clé pour débloquer ses informations, sans que ce soit nous qui la lui fournissions à partir de notre BDD (i-e sans que nous puissions, en tant que sysadmin, la trouver par nous même).

Il y aussi cette éventuelle solution avec une clé se secours donnée de manière préventive.
Ou peut-être, comme on m'avait également suggéré, à partir de réponses à des questions de sécurité? Ça pourrait presque être une information contenue dans les données chiffrées comme son nom et son prénom : Nous n'en aurions pas connaissance (l'entourage par contre...).
En tout cas, au boulot, nous allons y réfléchir.