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 +