Hinweis: In der Standard Edition können Policies nicht erstellt werden!
Oracle bietet ab Version 8i die Möglichkeit, aufgrund von bestimmten Sessionkriterien den Zugriff auf bestimmte Daten einzuschränken (Application Context). Dadurch können viele statische Views eingespart werden. Für die Einschränkung des Datenzugriffs benötigt man das DBMS_RLS Package.
Dieses Package implementiert das Feature "Virtual Private Database", das auch unter den Begriffen "Fine Grained Access Control" und "Row Level Security" bekannt ist. Es ist in der Enterprise und Personal Edition verfügbar, nicht aber in der Standard Edition.
Das DBMS_RLS Package ermöglicht die Verknüpfung von Tabellen oder Views mit Funktionen, die in Abhängigkeit von bestimmten Faktoren (Attribute und deren Attributwerte) nur die Sicht oder die Möglichkeit von Datenänderungen auf Teile des Objekts freigibt. Die Einschränkung wird erzielt, indem die Funktion eine dynamische WHERE Klausel (Prädikat) an den abgesetzten Select- oder DML-Befehl anhängt.
Die Verknüpfung zwischen der Funktion und der entsprechenden Tabelle erfolgt über eine Policy. Die Einschränkungen auf eine Tabelle können auch mit mehreren Policies gesteuert werden, wobei die einzelnen einschränkenden Bedingungen in der WHERE Klausel mit AND verbunden werden.
In der Datenbank gibt es einen Standardkontext 'USERENV' aus dem vordefinierte Kontextattribute der derzeitigen Session wie Benutzer, Session_id, Hostname, Servername usw. ermittelt werden können. Diese Attributwerte können zwar ausgelesen, jedoch nicht geändert werden. Die jeweiligen Attributwerte können mit der Funktion
FUNCTION SYS_CONTEXT ('USERENV', attribute)RETURN VARCHAR2;
ausgelesen werden.
Werden darüber hinaus eigene Attribute benötigt, muss ein eigener Kontext erstellt werden.
Im folgenden Beispiel soll das einschränkende Prädikat anhand des Attributs ‚JOB' im eigenen Kontext ‚emp_restriction' festgelegt werden.
Anhand des Jobs soll in der Tabelle emp der Zugriff wie folgt gesteuert werden:
Der Kontext soll im Schema von Scott erstellt werden.
Hierzu müssen ihm die erforderlichen Rollen und Rechte erteilt werden:
Anmeldung als SYS AS SYSDBA
GRANT CREATE ANY CONTEXT TO SCOTT;
GRANT EXECUTE on DBMS_RLS TO SCOTT;
GRANT CREATE PUBLIC SYNONYM TO SCOTT;
Nachdem Scott nun die benötigten Rechte besitzt, sollen alle Mitarbeiter Zugriff auf die Tabelle emp mit Hilfe eines Synonyms erhalten:
CREATE PUBLIC SYNONYM emp FOR scott.emp;
GRANT ALL ON scott.emp TO PUBLIC;
Zunächst wird das Kontextobjekt erstellt:
CREATE CONTEXT emp_restriction USING scott.s_pkg;
Der Kontext verweist auf das Package, welches die Funktionen der Sicherheitsrichtlinien beinhaltet. Das Package braucht noch nicht erstellt zu sein.
Danach wird das Package mit den benötigten Funktionen erstellt.
CREATE OR REPLACE PACKAGE scott.s_pkg
AS
c_context CONSTANT VARCHAR2(30):= 'emp_restriction';
c_job_attr CONSTANT VARCHAR2 (3):= 'JOB';
v_deptno NUMBER (3);
v_job VARCHAR (20);
PROCEDURE set_context;
PROCEDURE show_context;
FUNCTION job_predicate (p_schema_in IN VARCHAR2, p_name_in IN VARCHAR2)
RETURN VARCHAR2;
END S_Pkg;
/
CREATE OR REPLACE PACKAGE BODY scott.s_pkg
AS
PROCEDURE show_context
IS
BEGIN
DBMS_OUTPUT.PUT_LINE('typ = '||SYS_CONTEXT (c_context, c_job_attr));
END;
PROCEDURE set_context
IS
BEGIN
DBMS_SESSION.SET_CONTEXT(c_context, c_job_attr, v_job);
END;
FUNCTION job_predicate (p_schema_in IN VARCHAR2, p_name_in IN VARCHAR2)
RETURN VARCHAR2
IS
ma_list VARCHAR2(100):= SYS_CONTEXT (c_context, c_job_attr);
retval VARCHAR2(4000);
BEGIN
CASE ma_list
WHEN 'ANALYST'
THEN
retval := 'ENAME = SYS_CONTEXT (''userenv'',''SESSION_USER'')';
WHEN 'PRESIDENT'
THEN
retval := '';
WHEN 'MANAGER'
THEN
retval := 'DEPTNO = ' || v_deptno;
ELSE
retval := '1=2';
END CASE;
RETURN retval;
END;
END S_Pkg;
/
Im Package befinden sich 2 Prozeduren und eine Funktion:
Die Funktion, welche die Einschränkungen festlegt, benötigt immer 2 VARCHAR2 Parameter, auch wenn diese Parameter in der eigentlichen Funktion nicht benötigt werden. Diese Funktion wird in der Policy mit der Tabelle EMP verknüpft.
Zunächst jedoch der Zugriff auf das Package für alle User mit Hilfe des Synonyms:
GRANT EXECUTE ON scott.s_pkg TO PUBLIC;
CREATE PUBLIC SYNONYM s_pkg FOR scott.s_pkg;
Da das Package mit DEFINER RIGHTS erstellt wurde, benötigen die Anwender keine weiteren Rechte oder Rollen um die Prozeduren des Packages S_Pkg aufzurufen.
Jetzt kann die Policy erstellt werden, welche die einzuschränkende Tabelle mit der Einschränkfunktion verknüpft:
BEGIN
DBMS_RLS.ADD_POLICY(object_schema=>'scott',
object_name=>'emp',
policy_name=>'PLC_EMP',
function_schema=>'SCOTT',
policy_function=>'s_pkg.job_predicate',
statement_types=>'SELECT,INSERT,UPDATE,DELETE',
update_check => FALSE,
enable => TRUE );
END;
/
Wobei:
Der sessionabhängige Attributwert des Attributs ‚JOB' wird in LOGON Trigger im SYS Schema festgelegt.
CREATE OR REPLACE TRIGGER set_privacy_after_log_on
AFTER LOGON ON DATABASE
DECLARE
BEGIN
SELECT job, deptno
INTO s_pkg.v_job, s_pkg.v_deptno
FROM emp
WHERE ename = SYS_CONTEXT ('userenv', 'SESSION_USER');
s_pkg.set_context;
EXCEPTION
WHEN OTHERS THEN
NULL;
END set_privacy_after_log_on;
/
In dem Trigger wird ein letzter "freier" Zugriff auf die Tabelle emp ermöglicht, um die Information des Jobs und der Abteilung des Users zu ermitteln. Danach wird der Attributwert gesetzt. Ab dem jetzigen Zeitpunkt hat jeder User in Abhängigkeit von seinem Job nur noch Einblick und Manipulationsmöglichkeiten auf "seine" Daten. Dies ist völlig unabhängig von dem Medium, mit dem sich der Anwender auf die Datenbank anmeldet.
CREATE USER king IDENTIFIED BY king;
CREATE USER blake IDENTIFIED BY blake;
CREATE USER allen IDENTIFIED BY allen;
GRANT CONNECT,RESOURCE TO king;
GRANT CONNECT,RESOURCE TO blake;
GRANT CONNECT,RESOURCE TO allen;
Informationen über erstellte Kontexte und Policies im eigenen Schema erhält man über die Data Dictionary Views
SELECT * FROM all_context;
SELECT * FROM all_policies;
Informationen alle erstellte Kontexte und Policies erhält man über die Data Dictionary Views
SELECT * FROM dba_context;
SELECT * FROM dba_policies;
Hinweise:
Löschen, ein- und ausschalten der Policy ist mit folgenden Prozeduren möglich:
DBMS_RLS.drop_policy(object_schema, object_name, policy_name);
DBMS_RLS.enable_policy(object_schema, object_name, policy_name, TRUE/FALSE);
Wobei:
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.