Discussion :

[gmonseu]

Bonjour à tous,

Est-il possible à l'aide d'Oracle d'intercepter toutes les requêtes (SELECT + DML) envoyées au serveur de base de données ? Si oui, est-il possible de les annuler et/ou les modifier (pour des questions de sécurité).

J'ai déjà pas mal regardé à VPD, Fine-grained auditing, etc. mais je ne trouve pas exactement ce que je cherche...

Merci d'avance,

Gaëtan.

[Loyd1974]

Dans quel but ?
Si c'est juste pour empêcher certaine table d'être lues ou bien d'être mises à jour, le GRANT suffit largement

[gmonseu]

Dans quel but ?
Si c'est juste pour empêcher certaine table d'être lues ou bien d'être mises à jour, le GRANT suffit largement

Non en fait je dois pouvoir appliquer une sécurité au niveau de certaines colonnes qui ne peuvent être modifiées que par certains utilisateurs...

Et comme je n'ai pas accès au code source de ces écrans je dois passer par une sécurité à plus bas niveau type Oracle.

Des idées ?

[LBO72]

Et si tu utilses un trigger sur ton schèma ?
Ton trigger testera l'OsUser et la requête lancée...quelque chose comme ça...

LBO72.

[gmonseu]

Bonjour,

Oui mais dans les triggers (before insert, before update et before delete) : comment par exemple annuler/modifier la requête au cas où l'utilisateur OSUser n'a pas les droits suffisants ?

[Loyd1974]

Par le biais d'un trigger, tu peux faire un RAISE d'une erreur que tu auras défini si le user n'est pas correct.

Personnellement, je ne conseillerai pas de mettre ce genre de contrôle du côté de la base de données, mais plutôt du côté de la couche métier de ton appli.

Sinon, une autre solution serait de passer par des vues et suivant l'utilisateur ton application accède à une vue ou une autre.

Par exemple, tu peux avoir une table X et faire une vue X_small et une autre X_All, sur la vue X_small, tu n'affiches que les champs dont l'utilisateur a accès ou bien, tu les affiches tous et au moment de l'update ou de l'insert, tu gères les champs qui sont accessible par le biais de la vue.
Cela te permet de ne pas avoir de trigger qui viendrai gêner des traitements en masse comme un batch car celui-ci accèderai directement à la table et non aux vues qui seront dédiés seulement au transactionnel

Mais, il doit y avoir milles autres solutions

[pifor]

Personnellement, je ne conseillerai pas de mettre ce genre de contrôle du côté de la base de données, mais plutôt du côté de la couche métier de ton appli.

Si on code une couche de sécurité sur les données, il est préférable de la coder dans la base pour que tout accès SQL soit pris en compte: par l'application mais aussi par tout autre outil susceptible de se connecter à la base comme SQL*Plus, TOAD, Excel, etc...

[orafrance]

j'vois pas pourquoi le VPD ne peut pas t'aider

[Loyd1974]

Si on code une couche de sécurité sur les données, il est préférable de la coder dans la base pour que tout accès SQL soit pris en compte: par l'application mais aussi par tout autre outil susceptible de se connecter à la base comme SQL*Plus, TOAD, Excel, etc...

Oui, tu as raison, en fait, pour moi, le problème était au niveau des utilisateurs eux-mêmes. Donc, j'avais plus dans la tête le mot "habilitation" que "sécurité", ce qui n'est pas exactement la même problématique, même si le résultat final peut apparaitre similaire, l'une est vraiment sure à 100%, l'autre est plus souple.