Discussion :

[Michel Rotta]

J'ai un pré-projet qui me pose un problème de faisabilité.

Dans ce projet, j'ai une table dont je dois garantir l'intégrité des données. Ces données constituent un journal d'incident dans le monde médical. Elle ne peuvent être modifiée, elle doivent avoir un numéro de chrono unique. Elle doivent avoir un horodatage. Si une donnée est modifiée, il faut indiquer l'ancienne comme modifiée (elle doit être conservée) et créer un enregistrement nouveau avec la donnée modifiée. L'idée est qu'en cas de problème sur un patient, il soit possible de retrouver tous ce qui a été fait et de pouvoir remonter l'historique des modifications sur une ligne du journal.

Idéalement, ce journal est tenu sur papier et lorsqu'une entrée est modifiée est est barrée d'un trait oblique, la laissant lisible. On ne peut surcharger, impossible de supprimer une entrée sans retirer toute une page, ce qui est physiquement visible.

Comment pouvoir reproduire ce comportement avec une base de données.

Dans les contraintes j'ai le fait de travailler sur plusieurs moteurs open source. Le plus souvent cela sera du MySql, mais il faut prendre en compte Postgree et SqLite. Le langage utilisé sera du PHP. Vu les contraintes de bases de données et mes connaissances en développement je passerais par une couche ORM doctrine (et un framework symfony mais je ne pense pas qu'il ait d'influence ici). Le serveur de base doit pouvoir tourner sur Windows ou Linux.

Le système doit pouvoir résister à toutes tentatives de modification, y compris de celles de l'administrateur du site, qui aura donc tous les droits, tant sur la base que sur les codes PHP.

Comment assurer, à postériori, que les données d'une table n'ont pas été modifiée. A noter que, si elle l'ont été, il n'est pas nécessaire de pouvoir récupérer l'original. Il faut juste pouvoir démontrer d'une manière certaine que ces données n'ont pas été modifiée.

Les modifications peuvent être, soit la suppression d'un enregistrement, soit (plus probable) la modification d'un enregistrement pour supprimer où rajouter une information, ou encore changer l'heure d'une information.

Pour l'instant, je ne pense pas que cela soit faisable compte tenu des contraintes.

Mon idée est de créer un hash, pour chaque ligne, mélangeant les données texte, timecode, id, id de l'utilisateur, de l'enregistrement et celle de l'enregistrement précédent. Sauf qu'il est simple de régénérer le hach d'un enregistrement, si l'on sait ce qu'il y a dedans (facile avec le php) et que l'on a accès à l’enregistrement précédent (facile avec root).

J'ai bien une solution passant par l'envoie du même hach à un partenaire de validation extérieur, il n'est alors plus modifiable, sauf à corrompre une personne chez le prestataire de validation, mais cela sort du cadre des préconisation.

Quelqu'un a-t-il une idée ?

[CinePhil]

Les SGBDR sérieux ont des journaux de transaction. Je ne les ai personnellement jamais utilisés ni même examinés mais il y a là une piste à mon avis à creuser.

[vmolines]

Créer des vues pour toutes les tables. Interdire la modification des tables par les droits utilisateurs de la BDD. Créer des triggers sur insert, update, delete des vues. Le code des triggers remplace un delete par un insert.

Vous aurez donc toutes les anciennes valeurs, impossible de modifier ou de supprimer, tout devient INSERT grace aux triggers. Sécurité garantie par la BDD.

[jmguiche]

Je pense qu'il faut commencer par suivre un cours sgbd, ou s'entourer de qqun de compétent.
Ensuite, il faut embaucher un dba de confiance, car il est impossible d'empecher tout le monde, y compris les DBA, et il en faut, de modifier des données.Il y a je crois des fonctionnalités d'Oracle qui peuvent même brider les DBA, mais je ne les ai jamais vu tourner et ca ne doit pas être simple... ni bon marchés. Sous SQLServer (l'autre SGBD sérieux), je ne sais pas.



Par contre, il est possible (trivial avec un sgbd digne de ce nom) de faire une application qui journalise toute les modifs faites sur une table (par trigger en effet si on souhaite être le plus sur possible). Seul les DBA auront la possibilité de "tricher".

Mais si la contrainte est de passer par le plus petit dénominateur commun que sont Mysql, Postgress, sqllite, vous n'avez plus qu'a programmer ça en php et oublier vos rêves de sécurité. J'en soupçonne même, dans cette liste, de ne pas connaitre la notion de transaction , du coup pas de journalisation sure possible.

Quand au hash de validation exterieur, il reviendra plus cher que de travailler avec des outils adaptés... Et cela me semble hyper complexe et assez peu résistant aux pannes.

Autre piste : ecrire sur un support "write once read many".

[Michel Rotta]

Je pense qu'il faut commencer par suivre un cours sgbd, ou s'entourer de qqun de compétent.

C'est gentil, mais j'ai commencé à jouer avec les sgbd il n'y a que 25 ans... Retourner à l'école serait amusant, mais peu productif, je le crains.

Le problème de l'application est qu'elle doit être installée dans des petites structures, en local. Qu'il est impossible de garantir l'intégrité et l’inaccessibilité de la machine. Et encore moins l'incorruptibilité de l'administrateur db qui pourrait être personnellement impliqué.

Les sgbd ne sont pas choisi pas moi mais font partie du cahier des charges.

L'externalisation était une idée, mais ne répond pas à ce même cahier des charges.

L'écriture sur un support write on read many est effectivement une solution que j'ai envisagée et qui me semble une des plus solide. Ceci me confirme dans cette direction.

Si non, j'ai aussi une possibilité de passer par des clefs publiques et privée. Chaque utilisateur ayant alors sa clef USB avec sa clef privée sur la clef USB. Les données de l'enregistrement sont éditée sur le poste de travail et codée en local, avec la clef privée de l'utilisateur en javascript. Par sécurité, on y introduit le codage de l'enregistrement précédant. Ainsi pour modifier un enregistrement, il faut deux clef, la sienne et celle de l'utilisateur qui a entré une ligne juste avant. Ce qui réduit un peu les probabilité de faisabilité. Mais les risques de pression sont fort et que faire si l'enregistrement précédent est du même utilisateur, ce qui est plausible sur de petites structures.

Sauf à trouver une solution miracle, le support write one read multi est ce qu'il y a de mieux.

[vmolines]

Que pensez vous de ma proposition ?

Pour la compléter et finir de répondre à votre problématique, je ne donnerais justement aucun droit étendu aux personnes sur site ce qui garantit que la BD tourne comme vous l'avez défini ou qu'elle ne tourne pas.

[Michel Rotta]

En tant que prestataire, je ne peux refuser les droits d'administration à la société, ne serais-ce pour des raisons de sauvegarde et de restauration.

De plus, je ne suis pas sur que SqLite (même si je ne pense pas avoir jamais à l'utiliser) soit capable de gérer les vue.

Et je ne peux garantir dans cette configuration l'intégrité des données.

En fait, vu la demande, je ne pense pas que cela soit réalisable. Du moins, pas avec du PHP comme langage. Il y aurait peut-être des possibilités en réécrivant un driver, une sorte de surcouche pdo, qui s'occuperait du codage, mais cela dépasse mes compétences (il faut savoir où s'arrêter), et le projet ne serait plus rentable si je dois faire appel à un prestataire supplémentaire pour re-développer les couches d'accès aux données sur windows et linux.

En fait, en postant j'avais déjà comme sentiment qu'il n'y avait pas de solution logiciel et ceci me confirme mon sentiment. La plus viable est la solution matériel. Il faudra intégrer l'écriture sur le disque dans la transaction pour s'assurer que l'écriture à bien eu lieu.

J'ai lu un projet concomitant à la loi hadopi. Il prévoie "d'obliger" toutes les personnes qui veulent être protéger d'installer un logiciel d'espionnage sur leur PC pour pouvoir fournir des preuves de leur innocence (lol,il faut démontrer son innocence, un contournement du CPP où c'est à l'accusation de démontrer la culpabilité). Dans ce projet, le prestataire doit conserver le log sur le poste de l'utilisateur en garantissant qu'il ne puisse être modifier par l'utilisateur, si non, ce ne peux plus être une preuve. Je me disais qu'il y avait peut-être, derrière cette normalisation, l’existence de procédé de stockage et de cryptographie récents qui pourrait être utilisé pour mon application. Mais vu les contraintes de langage, je n'y crois pas trop.

Pourtant, la meilleur sécurité qui puisse exister est celle où tu montres en détail le système de sécurité et qu'il est impossible de cracker (hors une clef secrète bien sur).

[vmolines]

Je ne suis pas un expert en administration mais il est peut être possible de sauvegarder/restaurer sans avoir les pleins droits sur la base.

Mais apparemment vous ne voulez pas utiliser les mécanismes offerts par le SGBD.

[Michel Rotta]

Je ne suis pas suffisamment convaincu par la sécurité offerte pour pouvoir garantir l'intégrité des données...

[jmguiche]

Créer des vues pour toutes les tables. Interdire la modification des tables par les droits utilisateurs de la BDD. Créer des triggers sur insert, update, delete des vues. Le code des triggers remplace un delete par un insert.

Vous aurez donc toutes les anciennes valeurs, impossible de modifier ou de supprimer, tout devient INSERT grace aux triggers. Sécurité garantie par la BDD.

Cela ne protege pas contre un DBA malveillant.
Mais rien ne protege contre un dba malveillant !

Sauf ... Ci dessous.

[jmguiche]

En tant que prestataire, je ne peux refuser les droits d'administration à la société, ne serais-ce pour des raisons de sauvegarde et de restauration.

De plus, je ne suis pas sur que SqLite (même si je ne pense pas avoir jamais à l'utiliser) soit capable de gérer les vue.

Et je ne peux garantir dans cette configuration l'intégrité des données.

En fait, vu la demande, je ne pense pas que cela soit réalisable. Du moins, pas avec du PHP comme langage. Il y aurait peut-être des possibilités en réécrivant un driver, une sorte de surcouche pdo, qui s'occuperait du codage, mais cela dépasse mes compétences (il faut savoir où s'arrêter), et le projet ne serait plus rentable si je dois faire appel à un prestataire supplémentaire pour re-développer les couches d'accès aux données sur windows et linux.

En fait, en postant j'avais déjà comme sentiment qu'il n'y avait pas de solution logiciel et ceci me confirme mon sentiment. La plus viable est la solution matériel. Il faudra intégrer l'écriture sur le disque dans la transaction pour s'assurer que l'écriture à bien eu lieu.

J'ai lu un projet concomitant à la loi hadopi. Il prévoie "d'obliger" toutes les personnes qui veulent être protéger d'installer un logiciel d'espionnage sur leur PC pour pouvoir fournir des preuves de leur innocence (lol,il faut démontrer son innocence, un contournement du CPP où c'est à l'accusation de démontrer la culpabilité). Dans ce projet, le prestataire doit conserver le log sur le poste de l'utilisateur en garantissant qu'il ne puisse être modifier par l'utilisateur, si non, ce ne peux plus être une preuve. Je me disais qu'il y avait peut-être, derrière cette normalisation, l’existence de procédé de stockage et de cryptographie récents qui pourrait être utilisé pour mon application. Mais vu les contraintes de langage, je n'y crois pas trop.

Pourtant, la meilleur sécurité qui puisse exister est celle où tu montres en détail le système de sécurité et qu'il est impossible de cracker (hors une clef secrète bien sur).

Il y a une solution logiciel.

http://www.oracle.com/fr/technologie...ity/index.html

Mais pas avec sqlite ou mysql !

[Michel Rotta]

Solution très intéressante.

Et avec l'avantage de déporter la charge de la preuve sur Oracle et plus sur mes épaules...

Mais par contre, cela vas faire un trou énorme dans le budget. Un trou que dis-je, une faille, un gouffre !

Je vais voir ça la semaine prochaine, ça correspond, presque, au cahier des charge, sauf niveau coût. Après, on ne peux pas tout avoir.

[SQLpro]

Je viens de terminer la modélisation d'un ERP dans le domaine de la santé (hospitalisation) dans lequel nous avons mis en place dans le modèle de données et par des mécanismes direct dans la bases de données de la traçabilité à tous les niveaux :

• insertion
• update (avec conservation de toutes les valeurs intermédiaires
• delete
• lecture (SELECT)
• connexion
• dynamique de saisie par tranche de 30 secondes

Je veux bien vous faire part de mon expérience, mais à cette heure là j'ai sommeil et je vais être en clientèle demain.

Envoyez moi un message par mail et je vous donnerais quelques pistes !

Déjà au niveau sécurité tout ce qui existe sur Oracle existe sur SQL Server (gestion des privilèges, audit divers, cryptage...) en 10 à 25 fois moins cher !
Je dirais même que SQL Server est plus avancé en matière de sécurité que ne l'est Oracle !
http://www.pcinpact.com/actu/news/32...litchfield.htm
http://www.databasesecurity.com/dbsec/comparison.pdf

A +

[Michel Rotta]

Je jette un oeil sur les liens et reviens.