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 folgenden Funktion ausgelesen werden:
FUNCTION SYS_CONTEXT ('USERENV', attribute) RETURN VARCHAR2;
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:
PRESIDENT: Sieht alle Mitarbeiter und kann diese ändern
MANAGER: Sieht nur alle Mitarbeiter seiner Abteilung und kann nur die Mitarbeiter seiner Abteilung ändern
ANALYST: Sieht nur seine eigenen Daten und kann nur diese ändern
- Besitzt der User keinen der oben genannten Jobs, so erhält er keine Daten zum lesen, bzw. ändern
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:
- show_context: Mit dieser Prozedur kann der Attributwert des Attributs ‚JOB' in der derzeitigen Session ermittelt werden. Nützlich beim Erstellen und Debuggen.
- set_context: Mit dieser Prozedur wird der Attributwert des Attributs ‚JOB' in der derzeitigen Session gesetzt. Der Aufruf erfolgt in dem noch zu erstellenden LOGON Trigger.
- job_predicate: Diese Funktion generiert anhand vom Attributwert (ma_list) des Attributs 'JOB' im eigens erstellten Kontext 'emp_restriction' das Prädikat (den String der WHERE Klausel) welche an das SELECT- bzw. DML Statement angehängt wird
- ANALYST: Hier wird mit Hilfe vordefinierten Attributs ‚userenv' der derzeitige Sessionuser ermittelt, sodass folgende WHERE Klausel z.B. bei Scott generiert wird:
WHERE ENAME = 'SCOTT'
- PRESIDENT: Hier wird keine WHERE Klausel generiert, da der President alle Mitarbeiter anschauen und manipulieren darf. Alternativ kann auch 1=1 angegeben werden.
MANAGER: Hier wird die WHERE Klausel mit der Abteilungsnummer eingeschränkt, in welcher der jeweilige Manager arbeitet. Z.B. BLAKE:
WHERE DEPTNO = 30
- Alle anderen Jobs bekommen den Zugriff gesperrt mit der WHERE Klausel:
WHERE 1=2
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;
/
object_schema: Schema in dem sich das Objekt (z.B.Tabelle/View) befindet, auf dem die Sicherheitsrichtlinie angewendet werden soll
object_name: Objekt, auf dem die Sicherheitsrichtlinie angewendet werden soll
policy_name: Name der Sicherheitsrichtlinie
function_schema: Schema in dem sich die Funktion befindet, mit dem die Sicherheitsrichtlinie angewendet werden soll
policy_function: Packagefunktion mit der Sicherheitsrichtlinie ausgeführt wird
statement_types: Statements, bei denen die Policy Funktion greift. Möglich: SELECT, INSERT, UPDATE, DELETE oder Kombinationen davon
update_check: TRUE/FALSE. TRUE: Überprüfung der Policy nach INSERT oder UPDATE Statement mit den neuen Werten
- enable: Policy ist sofort aktiv, wenn sie erstellt wird
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.
Test mit folgendem Benutzern:
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 über alle erstellte Kontexte und Policies erhält man über die Data Dictionary Views
SELECT * FROM dba_context;
SELECT * FROM dba_policies;
Für SYS gelten die Policies nicht, er kann die Tabelle uneingeschränkt sehen
Es können unabhängige Filter auf ein Objekt für SELECT, INSERT, UPDATE, INDEX und DELETE gesetzt werden
Bei mehreren Filtern auf ein Objekt werden die Filterbedingungen mit AND verknüpft
Das Recht EXEMPT ACCESS POLICY erlaubt die Policy zu umgehen
- DIRECT PATH Export umgeht auch Policies
Löschen, ein- und ausschalten der Policy ist mit folgenden Prozeduren möglich:
Löschen:
DBMS_RLS.drop_policy(object_schema, object_name, policy_name);
Ein-, ausschalten:
DBMS_RLS.enable_policy(object_schema, object_name, policy_name, TRUE/FALSE);
object_chemsa: Schema in dem sich das Objekt (z.B.Tabelle/View) befindet, auf dem die Sicherheitsrichtlinie angewendet werden soll
object_name: Objekt, auf dem die Sicherheitsrichtlinie angewendet werden soll
policy_name: Name der Sicherheitsrichtlinie
- TRUE/FALSE: Einschalten/Ausschalten der Policy