Discussion :

[omzoway7]

Bonjour,
Je m'explique, j'ai un projet dont je dois utiliser une base de données (Wamp MySQL) et le projet concerne la gestion des patients dans une maison de santé (donc beaucoup de données sensibles et personnelles) , et il y'a 3 acteurs dans le projet qui pourront s'authentifier à une interface web et interagir avec la base de données (un patient qui ne peut que visualiser ses informations et les modifier, les assistants qui peuvent visualiser les infos des patients et les modifier également et les médecins-chefs qui ont les mêmes droits que ces derniers mais également visualiser l'historique et antécédent des patients).
Alors comme on doit prendre en compte l'aspect données privées je dois mettre en place une base de données avec architecture 3 tiers: un serveur qui permettra juste de stocker des données , un autre serveur qui traitera les requêtes pour avoir accès au serveur de données selon les droits et l'interface; en plus de mettre en place un dispositif pour anonymiser juste l'historique des patients.

Question: Comme c'est la première fois, tout conseil est à prendre sur comment je pourrais implémenter tout ça, et si j'utilise wamp comme le serveur des requêtes, comment je peux mettre en place le serveur des données, quel outil choisir? comment relier les 2 serveurs et des conseil pour la preservation des données.
Je vous remercie d'avance.

[ericd69]

salut,

wamp comme lamp implémentent toutes les parties (application et données)
mais si sur le principe tu peux les dispatcher sur différents serveur physique ou virtuels...

sinon il serait bon de te faire un api de procédures stockées pour encapsuler les requête et intégrer les mécanisme de contrôle d'accès.

tu peux en trouver un exemple ici.

l'autre avantage c'est la simplification des tes utilisateurs mysql:

• l'un est le super admin (root) auquel tu dois mettre un mot de passe pour verrouiller phpmyadmin et qui te servira à exécuter les scripts de mise en place de la bd et de l'api
• l'autre est un utilisateur à droits ultra limité (il n'a que grant execute sur le serveur) et peut ne pas avoir de mot de passe et qui servira à être appelé dans tes scripts php pour exécuter les procédures...

comme ça tu peux gérer finement les droits... le mécanisme que j'ai montré ici est simple et dédié à un environnement peu risqué... tu peux donner autan de droits que tu veux à chaque utilisateur applicatif (à ne pas confondre avec les utilisateurs mysql)

tu peux le compliquer en introduisant un mécanisme de seed dans la la génération des clé d'identification

après à voir un besoin de réplication...

[omzoway7]

bonsoir Eric,
tres sincerement je vous remercie beaucoup, beaucoup de votre réponde, ça m'avance sur plusieurs questions et c'est d'une grande aide. Bien sûr pour mon cas lidee est d'avoir 2 serveurs physiques reliés l'un à l'autre par des requetes sql ou si possible des triggers permettant de joindre le serveur de donnees en fonction des droits(root ou autres comme vous l'avez suggéré).Maintenant la principle question pour moi demeurre surtout comment mettre en place ces 2 serveurs et comment les relier, l'idée des Api est bien (en plus c'est ce que j'ai fait aujourdhui) mais si je peux utiliser 2 serveurs distints pourquoi pas alors??
je reste toujours à l'écoute durant ma phase d'étude pour toutes suggestions en vous remerciant tous d'avance .
Cordialement

salut,

wamp comme lamp implémentent toutes les parties (application et données)
mais si sur le principe tu peux les dispatcher sur différents serveur physique ou virtuels...

sinon il serait bon de te faire un api de procédures stockées pour encapsuler les requête et intégrer les mécanisme de contrôle d'accès.

tu peux en trouver un exemple ici.

l'autre avantage c'est la simplification des tes utilisateurs mysql:

• l'un est le super admin (root) auquel tu dois mettre un mot de passe pour verrouiller phpmyadmin et qui te servira à exécuter les scripts de mise en place de la bd et de l'api
• l'autre est un utilisateur à droits ultra limité (il n'a que grant execute sur le serveur) et peut ne pas avoir de mot de passe et qui servira à être appelé dans tes scripts php pour exécuter les procédures...

comme ça tu peux gérer finement les droits... le mécanisme que j'ai montré ici est simple et dédié à un environnement peu risqué... tu peux donner autan de droits que tu veux à chaque utilisateur applicatif (à ne pas confondre avec les utilisateurs mysql)

tu peux le compliquer en introduisant un mécanisme de seed dans la la génération des clé d'identification

après à voir un besoin de réplication...

[ericd69]

le seul avantage d'avoir 2 serveurs est de faire une réplication maitre esclave entre les 2 du serveur mysql ce qui permet de se munir d'une sécurité en cas de défaillance du serveur maitre.

ce qui est utile est un serveur complet et l'autre étant donc la réplique du 1er. avoir un serveur pour l'application et l'autre pour le sgbd est inutile...

de plus, encore un autre avantage des procédures est de facilement mettre en place un système de log des actions

[omzoway7]

Merci Sir Eric, je note et je retiens personnellement votre dernier avis, je le proposerai la semaine prochaine reste à savoir si le (ou plutôt la) chef de projet sera d'accord.Encore merci =)

le seul avantage d'avoir 2 serveurs est de faire une réplication maitre esclave entre les 2 du serveur mysql ce qui permet de se munir d'une sécurité en cas de défaillance du serveur maitre.

ce qui est utile est un serveur complet et l'autre étant donc la réplique du 1er. avoir un serveur pour l'application et l'autre pour le sgbd est inutile...

de plus, encore un autre avantage des procédures est de facilement mettre en place un système de log des actions

[SQLpro]

Bonjour,

je vous déconseille fortement l'utilisation de MySQL dans le cadre d'application de santé ayant des données sensible, dont la nature impose aujourd'hui la traçabilité et le cryptage d'un point de vu légal !

MySQL est incapable d'implémenter correctement une sécurité quelconque viable à ce niveau. C'est une passoire que tous les auditeurs en matière de sécurité vous intimerons de changer et les instances actuelles ne sont pas tendre avec ceux qui enfreignent la Loi !

par exemple comment ferez vous pour tracer les accès aux informations médicales (SELECT, INSERT, UPDATE, DELETE ???), ainsi que l'histoire des connexions ;

Pour une application de santé aujourd'hui il faut réunir au moins quatre conditions :
1) que certains données nominatives ou pouvant conduire à la détermination de la personne soient cryptées (nom, prénom, date de naissance, n°, de sécu... mais aussi en fonction de la population de l'application cela peut être la nationalité, si par exemple le nombre de personnes recensé par la base est faible et qu'il n'y a qu'une personne d'une certaine nationalité !!!)
2) le stockage doit être crypté (fichiers de la base comme sauvegardes)
3) les clefs de cryptage ne doivent pas pouvoir être disponible sur le serveur (il faut donc les externalisées par des boîtiers de générations de clefs, appelés HSM : Hardware security module)
4) tracer les accès au système et les données manipulées en lecture comme en écriture pour tous les utilisateurs, y compris administrateurs...

Or peu de SGBDR assurent ces services là !!!
A ma connaissance seules Oracle et MS SQL Server permettent la mise en œuvre de ces technologies par le cryptage, l'authentification et la traçabilité (database audit).
En matière d'hébergement seul Orange en France possède l'agrément de santé pour héberger toute clientèle ayant des données sensibles (patients).
http://esante.gouv.fr/services/refer...ergeurs-agrees

Loi 2004-810 du 13 août 2004 relative à l’assurance maladie (DMP)
Textes complémentaires
• Décret 2006-6 du 4 janvier 2006 relatif à l’hébergement de données de santé à caractère personnel
• Décret 2007-960 du 15 mai 2007 relatif à la confidentialité des informations médicales conservées sur support informatique ou transmises par voie électronique
Code pénal
• Sanctions en cas d’atteinte à la vie à la vie privée (art 229-1), à l’atteinte au secret professionnel (art 226-13), au manquement à la loi Informatique et Libertés (art 226-1 à 226-6)

Conseil de la CNIL en matière de chiffrement :
http://www.cnil.fr/fileadmin/documen...ecurite-VD.pdf page 40 - item 17

Conseil du gouvernement en matière d'hébergement des données de santé :
http://esante.gouv.fr/services/refer...ebergement-faq

HSM : http://en.wikipedia.org/wiki/Hardware_security_module
Exemple US : http://www.futurex.com/hardware_security_modules.asp
Exemple Thales : http://www.thales-esecurity.com/prod...shield-connect

J'ai travaillé récemment sur deux missions de ce genre avec obligation de cryptage et les instances ne plaisante plus sur les logiciels bidon de santé fait par des bricoleurs !

Quelques exemples de gentillesses faite à des pro de la santé :
http://www.i-med.fr/spip.php?article452
http://www.i-med.fr/spip.php?article402

Un bon résumé des problématiques :
http://facmed.univ-rennes1.fr/wkf/st...rique_2011.pdf


A +

[ericd69]

je suis d'accord sur le principe mais attention les hsm ne sont pas une obligation, c'est juste un plus niveau traitement, vu que que rien ne t’empêche de faire une extension c/c++ dédiée au pire si les fonctions cryptologiques internes ne suffisent pas... ou que tu ne le fais pas coté langage appelant

après ici la principale question c'est que tout ça c'est le rôle de la chef de projet et pas d'un stagiaire d'y réfléchir...et de proposer une architecture adaptée...

ne serait-ce que par ce que le matériel et le logiciel ont un coup pas négligeable sur ce genre de projet... et ça dépend aussi de l'accès que tu donnes aux données: médecins seuls ou autres (institutions plus ou moins grosses, particuliers)...

car les dossiers médicaux chez les médecins généralistes ou autres spécialistes n'utilisent souvent que très peu voir pas de cryptologie hors échanges lié à la gestion de parcours de santé...

ce genre de truc reste de toute façon de la responsabilité seule de la chef de projet... après elle verra ce qu'elle risque à faire se renseigner par un stagiaire à sa place sur ce qu'impose la réglementation (chose qui n'était pas la question originale)... moi je pars du principe que si elle a fait le choix des technologies, c'est qu'elle a fait son boulot d'audit de l’état de l'art et donc des contraintes réglementaires...

de même, que tu aurais pu faire la réflexion sur wamp...

par contre, si tu passes par un api de procédures stockées tu peux justement tracer facilement ce que tu veux puisque tu peux inclure ce que tu veux comme logique de traçabilité, avec bien moins de contraintes que de pauvres triggers after...

[omzoway7]

Bonjour à vous messieurs et merci pour vos réponses.
Juste je précise que ce projet est réalisé dans le cadre des études en licence pro informatique distribuée, je suis bien d'accord qu'avec oracle comme BD la structure serait plus sécurisée et solide, cependant comme c'est un projet à titre expérimental on ne dispose pas des coûts pour...mais tout ce que vous avez dit est vrai et on en a discuté et je vous en remercie,et pour la gestion des clés aussi je réfléchis bien à leur stockage de manière à être sécurisé. concernant l'api de procedures stockees, Eric est ce que dans l'exemple joint dans les messages précédents il y'a un dispositif de traçabilité des logs?
Merci

[ericd69]

je pense que tu nous rassure tous les deux mais je pensais bien que sur ce genre de truc un étudiant qui se renseigne sur un domaine lié au role de chef de projet (et pas du dev) ça devait certainement être un projet d'étude...

non pas dans l'exemple que je donnais... mais c'est facile à mettre en place et ça reste valable quelque soit le sgbd...
vu que tu as juste à rajouter une table de log ou tu enregistres l'identifiant de celui qui fait l'action, l'identification de l'action (table où tu as le nom les droits histoire de compacter plus), la date et l'heure et un commentaire qui peut servir à mettre des informations spécifiques par exemple

pour les système de cryptage en dur (ou logiciel) en pratique ils n'ont pas forcément à être intégré au sgbd mais plus au niveau applicatif...

de plus seule la partie identité de la personne (nom, nni, adresse, etc) doit être cryptée... ce qui n'oblige pas à décrypter pour rechercher, ça peut être fait purement au niveau applicatif pour la restitution... une sécurité qui évite que les administrateurs ait un accès réel aux données

tu peux utiliser AES ou des (3-DES) qui existe en natif dans mysql pour t'entrainer ça ira très bien...
mais si tu utilises AES pour faire les fonctions php compatible avec celle de l'implémentation du padding du seed de mysql lis ça...

ce qui n'empêche en rien un cryptage ssl à tous les niveaux d'échange... mais ça n'est que du tunneling pour la transmission ça ne joue pas sur ce qui est échangé...

[omzoway7]

ceci répond de façon définitive je crois à tous les résidus de questions que je me posais encore mille merci.

[ericd69]

pense aussi au partitionnement pour les tables à forte capacité genre les log, les actes médicaux, etc...
d'autan plus que mysql le supporte, ça accélèrera nombre de requête de recherche/insertion/suppression en pénalisant parfois certaines autres...
surtout que tu peux explicitement distribuer tes partitions sur des unités de disques différentes...

et n'oublie jamais que le sgbd n'est qu'un outil de classement/recherche, c'est pour ça que le cryptage/décryptage des données utilisées dedans n'est pas un soucis lié au sgbd mais plus à l'application métier
hormis quand tu veux faire une recherche nominative ou sur le nni... mais tu peux le contourner...

tu encryptes la donnée recherchée et rechercher sa forme cryptée comme un code est symétrique c'est donc une bijection...
la encore l'administrateur du sgbd n'a pas à être en mesure de lire les donner en clair pour ce genre d'application metier...

après aucun cryptage n'est infaillible quelque soit la méthode si on y met les moyens et le temps... de plus en france le cryptage fort est réglementé quand à sa complexité...