Vérrouiller des lignes en modifications à long terme ?

[floxone]

Bonjour,

J'ai une petite question un peu particulière : je souhaite vérrouiller en modification certaines lignes d'une table, est-ce possible.

Pour m'expliquer, j'ai une table 'contacts'. Je souhaite interdire la modification de certaines lignes de cette table à mes collègues et que l'on puisse dévérrouiller ces lignes sur demande.

Je ne peut pas mettre ces données dans une autre table et je ne peut pas placer un nouveau champ "flag".

Un trigger me semble être la seule approche. Sauf que mes données de contact sont éclatées sur plusieures tables : donc un peu compliquer à mettre en place.

Je ne suis pas sûr que le système de row-level lock puisse rester sur du long terme.

Avez-vous une idée sur la question ?

Merci d'avance,

Floxone.

[LeoAnderson]

Le trigger avec une variable de package pour le flag semble la solution la plus simple.
Attention à ne pas engendrer de blocages permanents avec ce système...

par contre, il suffit de verrouiller par trigger la table maitre, le jeu des transactions fera alors le reste

[Michel SALAIS]

Est il possible de créer une vue sur la table qui ne sélectionnerait pas les lignes en question?

[floxone]

Bonjour,

Envoyé par LeoAnderson

Le trigger avec une variable de package pour le flag semble la solution la plus simple.
Attention à ne pas engendrer de blocages permanents avec ce système...

par contre, il suffit de verrouiller par trigger la table maitre, le jeu des transactions fera alors le reste

En effet, pour le moment, je n'ai trouvé que 2 solutions :
- placer un trigger mais qui risque d'être un peu gourmand et gros.
- déporter ces données vers d'autres tables.

Mais je cherche une solution plus robuste et plus simple à mettre en oeuvre.

Envoyé par Michel SALAIS

Est il possible de créer une vue sur la table qui ne sélectionnerait pas les lignes en question?

Cette solution ne serait bonne que pour les select. Le but étant de vérrouiller les n-uplets concernées pour les opérations de mise à jour. Et par la suite, je pense qu'avec cette solution, rien n'empêchera d'attaquer directement la table. De plus le besoin et plutôt inverse : voir toutes les données mais ne pouvoir modifier qu'une partie.

Merci encore de votre aide.

[Michel SALAIS]

Envoyé par floxone

Bonjour,

Cette solution ne serait bonne que pour les select. Le but étant de vérrouiller les n-uplets concernées pour les opérations de mise à jour. Et par la suite, je pense qu'avec cette solution, rien n'empêchera d'attaquer directement la table. De plus le besoin et plutôt inverse : voir toutes les données mais ne pouvoir modifier qu'une partie.

Merci encore de votre aide.

Non! Elle est valable pour les mises à jour aussi à condition de donner les droits sur la vue et aucun droit sur la table. Alors même s'il tentent d'attaquer la table, ils ne pourront pas.

[orafrance]

et le VPD ne permet-il pas de faire ça ? Je sais qu'il peut faire ce que propose Michel (sélection... sélective ) mais peut-être peut-il aussi gérer les autorisations en écriture

Edit : apparemment c'est bien possible : http://download.oracle.com/docs/cd/B...i.htm#i1006882

[floxone]

Envoyé par orafrance

et le VPD ne permet-il pas de faire ça ? Je sais qu'il peut faire ce que propose Michel (sélection... sélective ) mais peut-être peut-il aussi gérer les autorisations en écriture

Edit : apparemment c'est bien possible : http://download.oracle.com/docs/cd/B...i.htm#i1006882

Effectivement, j'avais trouvé cela :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
Les Bases de données privées virtuelles (Virtual Private DATABASE ou VPD)
Les VPDs sont un nouveau moyen (disponible à partir de Oracle 9i et amélioré en Oracle 10g) de renforcer la sécurité d'une base de données Oracle.
La politique de sécurité peut être définie via une interface graphique : Oracle Policy Manager
 
Caractéristiques principales :
 
affinent la granularité du contrôle d'accès aux données, 
sont centralisées au niveau de la base, 
à ne définir qu'une fois quelque soit l'applicatif client, et transparentes pour l'application 
peuvent concerner des vues, des tables, des colonnes (Oracle 10g) ou des synonymes 
fournit un package de chiffrement DBMS_CRYPTO (Oracle 10g) 
 les vues paramétrées étaient jusqu'à présent présent le seul moyen d'obtenir une granularité d'accès inférieure à la TABLE.
Les sécurités mises au niveau applicatifs sont d'une part à réécrire pour chaque applicatif et sont aisément contournables lorsque l'ON fait un accès direct aux données avec un autre programme client.
 
Principes de fonctionnement
modification dynamique de requête 
Les VPDs utilisent la modification dynamique de requête .
Tout ordre commençant par ou incluant 'SELECT' , est filtré, des conditions différentes (clauses WHERE ou fonction booleene personnalisée par exemple ) sont appliquées en fonction de l'utilisateur qui fait la demande.
 
contextes applicatifs 
Les VPDs s'appuient sur des informationsn contexctuelles personnalisées pour déterminer le niveau d'accès autorisé et appliquer la politique de sécurité du groupe d'utilisateurs concerné
 
Pour des raisons évidentes de sécurité, si aucun contexte n'est spécifié, un utilisateur ne pourra pas accéder à des données globales non filtrées. Dans ce cas, par défaut, Oracle applique TOUTES les politiques de sécurités existantes, sur TOUTES les applications. Ainsi aucun contournement n'est possible.
 
contextes applicatifs simples
Un contexte applicatif est UNIQUE au niveau de la base, et il peut en exister autant que d'application.
Il existe des contexte applicatifs simples, qui permettent d'identifier finement l'utilisateur connecté en fonction de paramètres choisis. Par exemple le contexte peut déterminer le niveau hirarchique de l'utilisateur dans la société, son appartenance à tel ou tel groupe, ou service, son origine géographique, etc. 
L'application montrant dès lors les données autorisées relatives à ce contexte précis 
contextes applicatifs globaux
Dans certains cas de figure, pour éviter des consommations de ressources excessives, améliorer les performances ou pour simplifier la gestion des utilisateurs Oracle, il n'y a pas une connexion et un process dédié à chaque utilisateur accédant au données.
C'est le cas notamment lorsque qu'ON a un utilisateur applicatif générique pour tous les utilisateurs réels, ou lorsque qu'on utilise le 'connection pooling'. Ceci est fréquent dans les architectures 3 tiers, mettant en jeu un serveur web applicatif.

Mais je pensais que les VPD ne concernées que les sélections. Je vais regarder cela de plus près.

Merci bien de votre aide.

[Michel SALAIS]

Envoyé par orafrance

et le VPD ne permet-il pas de faire ça ? Je sais qu'il peut faire ce que propose Michel (sélection... sélective ) mais peut-être peut-il aussi gérer les autorisations en écriture

Edit : apparemment c'est bien possible : http://download.oracle.com/docs/cd/B...i.htm#i1006882

Oui bien sûr mais VPD nécessite l'édition Entreprise.

[floxone]

Envoyé par Michel SALAIS

Oui bien sûr mais VPD nécessite l'édition Entreprise.

Bonjour,

Ce n'est pas un problème puisque je dispose de la 10g Entreprise. Je cherche dans ce sens.

Merci de votre aide.