Discussion :

[Ceubex]

Bonjour,

Je suis sur la conception d'un système assez sécurisé et il faut vérifier que la base de données reste intègre et inchangée durant une période. Du coup ce que je fais c'est journaliser régulièrement le hash de la base. Pour cela j'avais pensé à sortir toutes les tables, puis à venir prendre tout leur contenu (SELECT *), ensuite concaténer les chaines de caractères et hasher le tout en MD5.
Mais c'est assez lourd. A votre avis y a-t-il une manière de faire ça un peu optimisée ?

[punkoff]

bonjour,

reste intègre et inchangée

Avec une politique de droit assez restrictive vous ne devriez pas avoir de problème pour mettre en place ceci.

Si vous interdisez les opérations de type DML vos données ne bougeront pas.


De plus, selon votre SGBD, vous pouvez aussi activée un audit assez "large" afin de tracer toute modification de donnée.
(ou une version avec trigger si pas d'audit possible)


Sinon concernant le truc MD5, ca ne garantira en rien que vos données n'ont pas bougées.

En effet deux valeurs sources peuvent avoir un hash md5 identique.

[Ceubex]

Ca fait partie des obligations de la réglementation. On doit faire comme ça. Donc je n'ai pas le choix, je suis obligé de produire ces hash ! Même si c'est pas le meilleur truc à faire

[aieeeuuuuu]

Bonjour,

Le MD5 de la concaténation du MD5 de toutes les colonne de toutes les tables ????? ouchhh !

Avec une politique de droit assez restrictive vous ne devriez pas avoir de problème pour mettre en place ceci.

Ou simplement mettre la base en lecture seule.

Sinon concernant le truc MD5, ça ne garantira en rien que vos données n'ont pas bougées.

Bah dans un sens si : avec une telle requête, toutes les tables vont être verrouillées, donc les modifications ne seront plus possibles, et au bout de quelques heures, quand le serveur aura pris feu, le modifications ne seront plus possible non plus

Plus sérieusement, j'aurai aussi dit l'inverse : des MD5 différents ne signifiera pas forcément qu'il y a eu de modifications, mais peut être que l'ordre de récupération des select aura changé, à moins de mettre des ORDER BY de partout sur une requête qui sera déjà monstrueuse !

[aieeeuuuuu]

On doit faire comme ça.

Alors il serait utile de connaitre vos contraintes exactes afin de trouver la meilleure implémentation possible.

[Ceubex]

Oui je mets des ORDER BY.

On pourrait débattre de l'intérêt de mettre en lecture seul. Le problème c'est que si un petit malin vient, enlève la lecture seul, modifie et la remet, eh ben euh....

De toute manière c'est comme ça, je le répète, c'est imposé de faire comme ça, donc la seule question qui se pose à moi c'est comment le faire le plus efficacement possible

[Ceubex]

Ma contrainte c'est de journaliser régulièrement une empreinte de l'ensemble de la base à partir d'un hash de ses données.

[aieeeuuuuu]

Vu que votre base ne sera pas modifiée, vous pouvez déjà soit créer soit des vues indexées (ou ajouter une colonne calculée persistante à chaque table) faisant le calcul du MD5 de la ligne. ça sera toujours ça de gagné à chaque calcul global.

Quel est votre SGBD ?
et pour information, quelle est la taille de votre BDD, le nombre de tables, de colonnes et de lignes ?


sinon, avez-vous envisagé (si ça répond à vos contraintes) de faire un hash du fichier de données (d'autres problématiques se poseraient alors, mais seraient je pense plus simples) ?

[Ceubex]

Eh bien en fait c'est là que ça devient drole
La base doit être "scéllée" mais avec des exceptions. Il y a donc certains champs et parfois certaines valeurs qui ne doivent pas être vérifier en intégrité.
De plus, j'aimerais bien précalculer les hash dans un champ mais l'ennui c'est que si qq1 modifie le champ, le hash lui ne sera pas modifier. Ainsi la ligne ne sera plus intègre mais le semblera pourtant.

[orion99]

C'est de la foutaise de dire "c'est imposé et j'ai pas le choix" moi quand mon supérieur me demande une absurdité sans nom je lui explique, s'il est pas d'accord j’écris un rapport que je communique là ou sa fait mal...

Faire un hash de ta db n'a pas de sens... tu dis "si quelqu'un vient déverrouillé ma db faire les modif et la reverrou" sa signifie qu'il a le droit de le faire (ou alors le problème se situe justement à ce niveau) donc tu pourra jamais l'empêcher de foutre le bordel s'il en a envie... ce n'est donc pas la bonne solution.

[Ceubex]

Désolé d'avoir des idées fixes mais ça n'est pas une idiotie de parton mais une idiotie de la loi
C'est encore plus fort !

Les différents systèmes de traitement doivent faire l'objet d'un scellement, c'est à dire d'un procédé permettant de déceler toute modification du système

Quand on demande aux responsables administratifs ce que ça veut dire, ils le disent clairement, ça veut dire ça.
Alors il est vrai qu'il est toujours possible d'aller toquer au Parlement pour faire entendre son point de vue mais moi ça ne m'amuserait pas trop. Je préfère uriner dans des violons.

[orion99]

Um... qu'appelle tu responsable administratif ? les fonctionnaires ou ceux qui sont dans ta boite ? si ce sont les fonctionnaires qui disent qu'il faut un hash... effectivement, sa va être dur de faire autrement... bien que dans mon cas, j'ai aussi eu a adapter mes logiciels aux lois et lorsque j'étais face à une aberration je leur signalait et on était parvenu à un compromis.

[Ceubex]

Ce sont des fonctionnaires de la CNIL. Malheureusement ceux-là n'ont pas trop la culture du compromis

[ram-0000]

et un hash MD5 du tar gzip de l'export de la base ?

Ainsi, tu peux le revérifier quand tu veux (et même de manière automatisée par cron) et cela sera certainement moins lourd qu'un hash du résultat de toutes tes requêtes.

[Ceubex]

Merci, ouf enfin une réponse

[aieeeuuuuu]

De plus, j'aimerais bien précalculer les hash dans un champ mais l'ennui c'est que si qq1 modifie le champ, le hash lui ne sera pas modifier. Ainsi la ligne ne sera plus intègre mais le semblera pourtant.

Si c'est une colonne calculée, ou une colonne dans une vue, la modification d'une des autres colonnes entrainera bien la modification du hash, de façon automatique et transparente dans la transaction.

Cela dit, dans votre texte, je ne vois nulle part la mention de hash...

[SQLpro]

Désolé d'avoir des idées fixes mais ça n'est pas une idiotie de parton mais une idiotie de la loi
C'est encore plus fort !

Quand on demande aux responsables administratifs ce que ça veut dire, ils le disent clairement, ça veut dire ça.
Alors il est vrai qu'il est toujours possible d'aller toquer au Parlement pour faire entendre son point de vue mais moi ça ne m'amuserait pas trop. Je préfère uriner dans des violons.

Permettez moi de vous dire que je connais assez bien les Lois en matière de données, applications et bases de données, et je n'ai pas connaissance d'une seule Loi Française ou d'un pays de langue française imposant de calculer un hash de la totalité des données.
Donc, donnez-nous les références de cette Loi, car je suis plus que très sceptique !

A +

[Ceubex]

Va ici et tu auras tout un tas de trucs dans le genre http://www.cnil.fr/documentation/del...commandations/
Par contre ils n'imposent pas le hash dans la loi. La loi dit qu'il faut sceller la base et quand on demande à la CNIL elle dit qu'il faut faire comme ça

[SQLpro]

Va ici et tu auras tout un tas de trucs dans le genre http://www.cnil.fr/documentation/del...commandations/
Par contre ils n'imposent pas le hash dans la loi. La loi dit qu'il faut sceller la base et quand on demande à la CNIL elle dit qu'il faut faire comme ça

Vous me balancez un lien et vous ne dites même pas dans quelle catégorie vous êtes alors qu'il existe plus de 50 entrée différente dans le liste....
De plus iil s'agit de recommandations, rien à voir avec une Loi ! Vous êtes dans le mensonge...
C'est du grand n'importe quoi !

A +

[aieeeuuuuu]

On pourrait débattre de l'intérêt de mettre en lecture seul. Le problème c'est que si un petit malin vient, enlève la lecture seul, modifie et la remet, eh ben euh....

Et si le même malin modifie la base, recalcule son hash et remplace le hash "sauvegardé en référence" par le nouveau hash ???

Si vous partez du principe que n'importe qui peut faire n'importe quoi sur vos serveurs, alors votre problème n'a pas de solution...