Les prémices

Le principe de base des accès au données Oracle, s’appelle le ‘Discretionary Access Control’ ou DAC.
Il s’appuie sur des privilèges d’accès aux objets donnés aux utilisateurs concernés, grace ? la commande SQL ‘GRANT’.
Ainsi on donne ? Mr Clark le droit de consulter la table EMP de SCOTT, par la commande
GRANT SELECT ON scott.EMP TO clark’.
Ce controle d’accès ne gère pas de niveau plus fin que la table complète : soit CLARk ? a l’accès ? la totalité de la table ou ? aucune de ses lignes…
Ceci peut être affiné en utilisant des vues.
On peut limiter l’accès ? un niveau plus fin, par exemple autoriser CLARK ? ne lire que la ou les lignes qui le concerne, en créant une vue avec prédicat :

SQL> CREATE VIEW v_emp AS SELECT * FROM scott.emp
WHERE ename=user;
SQL> CONNECT clark/clark
SQL> SELECT * FROM scott.v_emp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
7782 CLARK MANAGER 7839 09-JUN-81 2450 10

Ceci peut néanmoins dans certains être contourné si Mr Clark iu d’autres utilisateurs accèdent directement ? la table sous jacente EMP.
La sécurité au niveau ligne (RLS) ou l’accès au niveau fin (Fine Grain Access Control ou FGAC)

sont une solution complètement ttransparente pour tous les users, ? ce type de besoin.
Faire du RLS (FGAC) nécessite
- 1 fonction predicat, qui limite les accès ? certaines lignes
Cette fonction, a 2 paramètres obligatoires (le proprietaire et le nom de l’objet filtré) et retourne

une chaine qui contient une expression booleenne.
- 1 strategie (policy) attachée ? la table qui met en oeuvre automatiquement cette fonction.
cette strategie, a un nom et doirt preciser l’objet filtré et la fonction utilisée.
Les stratégies sont gérées par un package prédéfini appelé DBMS_RLS. Le créateur de la startégie doit

donc avoir les droits d’EXECUTE sur ce package.
Pour la création on utilisera par exemple DBMS_RLS.ADD_POLICY(…)

Dans un Schmé sécurité (compte SEC) cela nous donne :

création de la fonction prédicat et de la stratégie

SQL> CONNECT sec/sec
SQL> CREATE OR REPLACE PACKAGE filtre_emp
AS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2;
END;

SQL> CREATE OR REPLACE PACKAGE BODY filtre_emp
IS
FUNCTION vue_emp (owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2
IS
predicat VARCHAR2(1000);
BEGIN
predicat := ‘ename=user’;
RETURN predicat;
END;
END;

– si nécessaire
execute DBMS_RLS.DROP_POLICY (’scott’, ‘emp’, ‘policy_emp’);
– et on crée donc…
execute DBMS_RLS.ADD_POLICY (’scott’,'emp’,'policy_emp’,’sec’,'filtre_emp.vue_emp’, ‘SELECT’);

Démontration du résultat de la stratégie mise en place

SQL> CONNECT clark/clark
SQL> SELECT COUNT(*) FROM scott.emp;
–> 1
SQL> CONNECT system/xxxx
SQL> SELECT COUNT(*) FROM scott.emp;
–> …
no row selected
car tout le monde est a priori sousmis ? la stratégie de sécurité !
y compris le DBA, et comme son nom d’utilisateur n’apparait pas dans la table EMP de SCOTT, le prédicat renvoie un résultat faux…et aucune ligne n’est affichée.

Nous verrons dans un prochain article comment créer une ébauche de VPD en associant ? cette stratégie un contexte utilisateur.