Discussion :

[valzon]

Bonjour,
je souhaite intégrer les checksum dans postgreSQL pour sécuriser, tracer et éviter la modification des données dans postgresql. En fait je veux éviter la modification des valeurs des champs. Quelqu'un a t'il une idée ? comment pourrais-je résoudre ce souci ?

Merci !

[punkoff]

Bonjour,

Je ne comprend pas bien la relation entre interdire un user de faire des updates / delete / insert (gestion de droit) et un checksum.

Pouriez-vous développer ?

[SQLpro]

Il me semble que PG propose quelques fonctions de hachage :
https://postgresql.developpez.com/do...tion/francais/

A +

[valzon]

Salut punkoff,
en fait je veux empêcher les modifications des données à partir de PostgreSQL. On m'a conseillé les checksum pour cela. Je demande si quelqu'un peut me donner une autre solution car j'ai fouillé comment je peux résoudre cela avec les checksum mais en vain. Je n'ai rien trouvé. Sqlpro je ne veux pas crypter les données mais pouvoir empêcher, voir tracer toutes modifications des données.

[Camaie]

juste une question comme cela qui va surement rejoindre ce que voulait dire punkoff, mais quels sont les utilisateurs qui peuvent modifier les données ?

je demande cela car si vous avez un utilisateur X (par exemple user_update) qui est autorisé à modifier ce qu'il veut et un utilisateur Y (par exemple user_read_only) vous dissocier les rôles de chacun et n'êtes obligé que de gérer la diffusion des informations de l'utilisateur X.

Sinon, de mémoire, vous pouvez configurer postgresql pour qu'il log toutes les requêtes de modification via l'option "log_statement" dans le fichier postgressql.conf ( plus d'info : http://www.postgresql.org/docs/9.1/i...G-LOGGING-WHAT rubrique log_statement)

Sinon dernière solution très coûteuse en temps pour la mettre en place, ce sont les RULES qui permettent de rien faire pour un ordre donné (p.e. : create or replace rule rien_faire on update to table_a_proteger do instead nothing ) car il est nécessaire de créer autant de rules que de table à verrouiller et de supprimer/recréer les régles à chque fois que l'on veux faire une modification de contenu.

[estofilo]

en fait je veux empêcher les modifications des données à partir de PostgreSQL. On m'a conseillé les checksum pour cela.

Un checksum en soi ça n'empêche rien, ça permet juste de savoir après coup qu'il y a eu modification. Et autant pour des fichiers c'est assez simple à mettre en oeuvre, autant ce n'est pas le cas dans une base de données structurée.

Pour accorder aux utilisateurs le droit ou non de modifier les données, en SQL on utilise la commande GRANT.

Et pour tracer les mises à jour dans des tables, on utilise plutôt la méthode des triggers qui voient passer toutes les mises à jour et peuvent les consigner dans d'autres tables.

[kain_tn]

Bonjour,

Comme l'a dit Camaie, je pense que ce que tu cherches est le système de RULES de PostgreSQL.

http://www.postgresql.org/docs/9.1/i...ive/rules.html

Il s'agit en fait d'une ré-écriture automatique de requête. En principe ça doit être plus performant que les triggers ça t'évite surtout d'avoir à écrire de nouvelles fonctions.

C'est le même mécanisme qui est utilisé pour implémenter les vues sous PostgreSQL.

[valzon]

bonjour et merci à vous. Je pense que le système de RULE dans PostgreSQL pourra m'être utile comme suggéré par kain_tn. Mais est ce qu'il ne sera pas contournable? that is the question. En fait je veux empêcher toutes modifications et suppressions dans la table des logs de mon application. J'ai remarqué qu'il est possible de se connecter à la base de données et de supprimer les logs voir même modifier. Je souhaite mettre en œuvre une politique de sécurité rigoureuse pour pallier à cette situation.

[vmolines]

Le mécanisme de droits standard de Postgre vous permet de faire ça.

Créez un rôle pour vos utilisateurs en lui interdisant les modifications et suppressions sur la table en question (CREATE ROLE, GRANT ROLE, GRANT, REVOKE).

[valzon]

Merci vmolines pour ton feedback. Le problème est au dessus des droits car tu vois bien qu'il y a un rôle qui te permet de créer des rôles ?!

[Camaie]

il y aura toujours un rôle de superadmin dans une base sinon c'est la cata pour gérer les droits, et de plus, il y aura forcément un utilisateur qui pourra écrire dans la table de logs ne serait-ce pour la peupler régulièrement.

Au final, seule une gestion rigoureuse des droits d'utilisateur et de diffusion des infos peut venir à bout de votre problème : verrouiller une table contre toute modification veux dire aussi que personne ne peux y écrire ce qui est antinomique avec le rôle d'une table de logs

[vmolines]

Merci vmolines pour ton feedback. Le problème est au dessus des droits car tu vois bien qu'il y a un rôle qui te permet de créer des rôles ?!

Mais le role superadmin ne doit pas être utilisé par les utilisateurs finaux justement... Vous ne donnez à vos utilisateurs ou applications clientes qu'un login qui ne permet que les opérations que vous (superadmin) autorisez.

Evidemment tout système de sécurité est contournable. Si un utilisateur vole votre mot de passe superadmin ou détruit votre serveur , il peut supprimer les données .

il y aura toujours un rôle de superadmin dans une base sinon c'est la cata pour gérer les droits, et de plus, il y aura forcément un utilisateur qui pourra écrire dans la table de logs ne serait-ce pour la peupler régulièrement.

Au final, seule une gestion rigoureuse des droits d'utilisateur et de diffusion des infos peut venir à bout de votre problème : verrouiller une table contre toute modification veux dire aussi que personne ne peux y écrire ce qui est antinomique avec le rôle d'une table de logs

Si j'ai bien compris son besoin, il souhaite que la table soit en INSERT only comme vous le dites pour peupler le log. Aucun droit d'altérer des logs (DELETE, UPDATE). Les droits proposent cette restriction, je ne vois pas en quoi ce n'est pas approprié.

[estofilo]

J'ai remarqué qu'il est possible de se connecter à la base de données et de supprimer les logs voir même modifier. Je souhaite mettre en œuvre une politique de sécurité rigoureuse pour pallier à cette situation.

Et bien il faut inverser le problème. Il ne faut pas se demander comment interdire de "modifier les données", ce qui est trop vague pour être utile, il faut se demander pour chaque compte utilisateur ou rôle ce qu'il est censé avoir le droit de faire avec la base et n'autoriser que ça.

[Camaie]

Si j'ai bien compris son besoin, il souhaite que la table soit en INSERT only comme vous le dites pour peupler le log. Aucun droit d'altérer des logs (DELETE, UPDATE). Les droits proposent cette restriction, je ne vois pas en quoi ce n'est pas approprié.

En fait que je pinaille un peu sur les mots pour la définition de "modification", mais bon ce n'est qu'un détail.

Au final, on est d'accord sur le fait, qu'il y a au moins 2 utilisateurs (sans compter le superadmin) :
-celui qui écrit dans la table de logs (potentiellement le superadmin mais vraiment pas conseillé)
- et celui qui lit les données sans pouvoir les altérer.

[SQLpro]

...Sqlpro je ne veux pas crypter les données mais pouvoir empêcher, voir tracer toutes modifications des données.

PostGreSQL présente comme cryptographique des fonctions de hachage qui n'en sont pas...

A +