Die existierenden Objektprivilegien, die Anwendern das Lesen, Einfügen, Ändern und Löschen von Daten erlauben, zielen immer auf alle Zeilen einer Tabelle. Soll der Zugriff auf Zeilenebene gesteuert werden, weicht man entweder auf die Steuerung des Zugriffs über Anwendungen aus oder verwendet Views. Beides ist uneffektiv: Die Steuerung über Anwendungen, weil sie in jeder Anwendung separat programmiert werden muss und Änderungen in jeder Anwendung nachgezogen werden müssen. Die Steuerung über Views, weil bei großen Benutzergruppen oder vielen Views das ganze Berechtigungssystem schnell unüberschaubar wird.

Oracle bietet schon seit der Version Oracle8i eine Lösung für dieses Problem: Die Lösung ist unter den Namen Fine Grained Access Control (FGAC) oder auch Virtual Private Database (VPD) bekannt. Es handelt sich dabei um ein Feature der Enterprise Edition, dessen Nutzung in der Regel eine enge Zusammenarbeit von Datenbankadministratoren und Anwendungsentwicklern voraussetzt.

VPD implementiert die Kontrolle für den Zugriff auf einzelne Zeilen auf der Ebene der Tabelle: Mit dem Paket DBMS_RLS werden die Befehle INSERT, UPDATE, DELETE und SELECT, die auf eine mit VPD geschützte Tabelle zugreifen, um eine zusätzliche WHERE-Bedingung erweitert. Diese WHERE-Bedingung wird flexibel durch eine Funktion erstellt, die der Datenbankadministrator oder Anwendungsentwickler schreiben muß. Enthält das SELECT, UPDATE oder DELETE bereits eine WHERE-Bedingung, wird die von der Funktion erzeugte WHERE-Bedingung einfach mit AND angehängt. Die Verbindung zwischen Funktion und Tabelle wird als Policy bezeichnet, und die Funktion deshalb auch als Policy-Funktion.

Es ist möglich, identische oder auch unterschiedliche Policy-Funktionen für die Aktionen SELECT, INSERT, UPDATE und DELETE anzulegen. Sogar mehrere Policy-Funktionen für ein und dieselbe Aktion sind erlaubt. Und man kann auch Policy-Funktionen in Gruppen zusammenlegen (Oracle-Terminologie PARTITIONED FGAC): Die Ergebnisse der Funktionen werden einfach durch AND verbunden.

Die wahre Leistungsfähigkeit der VPD offenbart sich aber erst im Zusammenspiel mit Variablen, die als sogenannter Application Context im Arbeitsspeicher angelegt werden. Ein Application Context kann z. B. beim ersten Connect auf die Datenbank im Rahmen eines Logon-Triggers mit Werten aus der Betriebssystem- oder Anwendungsumgebung des Anwenders aber auch mit Informationen aus der Datenbank initialisiert werden. Durch den Zugriff auf den Application Context vermeiden Policy-Funktionen dann unnötige Mehrfachausführungen von Programmcode oder aufwendige SQL-Zugriffe.

Ein Application Context kann im Bereich des Arbeitsspeichers eines Anwenders angelegt werden. Er kann aber auch in einem Bereich angelegt werden, der für alle Benutzer verfügbar ist. Dann spricht man von sogenannten Global Application Contexts. Global Application Contexts unterstützen das Connection Pooling, Multitier-Anwendungen oder Anwendungen, die ihre eigene Authentifizierung vornehmen und selbst als Datenbankbenutzer agieren.

Anhand eines Beispiels soll die Verwendung von Policies und Application Contexts im Rahmen von VPD vorgestellt werden. Das Beispiel basiert auf den Tabellen EMPLOYEES, ORDERS und CUSTOMERS aus den Beispielschemas HR und OE. Beide Schemas sind im Lieferumfang der Datenbank enthalten und in der folgenden Graphik ausschnittweise dargestellt.


Zum Vergrößern auf das Bild klicken, zurück zum Artikel mit dem Back-Button des Browser

Für das Beispiel werden die Tabellen modifiziert. Um eindeutige Nummernkreise für Angestellten- und Kundennummern (employee_id, customer_id) zu erhalten, werden die Kundennummern in ORDERS und CUSTOMERS mit 10 multipliziert. Dazu wird das Foreign Key Constraint auf ORDERS.CUSTOMER_ID zuvor mit DROP gelöscht. Ausserdem wird der Zugriff auf die Tabelle ORDERS für Verkäufer und Kunden freigegeben.

Aufgabenstellung

Die Auftragsdaten aus ORDERS sollen nur von den Verkäufern, die den Auftrag abgeschlossen haben, lesbar sein. Ausserdem sollen Kunden ihre eigenen Auftragsdaten lesen dürfen.

Der Lösungsweg sieht so aus, dass im Rahmen eines Logon-Triggers Variablen eines Application Context gefüllt werden, die dann im zweiten Schritt für die Policies gebraucht werden. Dabei wird davon ausgegangen, dass die Verkäufer sich mit ihrem Emailnamen einloggen. Dieser Emailname wird in der Tabelle EMPLOYEES in der Spalte EMAIL gelistet und besteht aus dem 1. Buchstaben des Vornamens und dem vollständigen Nachnamen. Analog sind die Kundenzugänge über Benutzernamen möglich, die ebenfalls nach diesem Muster aufgebaut sind.

Application Contexts und Logon-Trigger anlegen

Da das Anlegen der folgenden Objekte mehr als die üblichen Benutzerprivilegien erfordert, sollen die Objekte des Beispiels der Einfachheit halber von einem DBA angelegt werden, hier vom Benutzer SYSTEM.

Der Application Context wird mit folgendem Befehl angelegt

CREATE OR REPLACE CONTEXT initvpd USING initpack

CREATE OR REPLACE PACKAGE BODY initpack IS
  PROCEDURE benutzerdaten IS
    v_benutzer_id  number(6);
  BEGIN
    SELECT employee_id INTO v_benutzer_id 
    FROM hr.employees 
    WHERE email = SYS_CONTEXT('USERENV', 'SESSION_USER');
    DBMS_SESSION.SET_CONTEXT('initvpd', 'benutzer_id', v_benutzer_id);
  EXCEPTION
    WHEN NO_DATA_FOUND THEN 
    SELECT customer_id INTO v_benutzer_id 
    FROM oe.customers 
    WHERE upper(substr(cust_first_name,1,1)||cust_last_name) = SYS_CONTEXT('USERENV', 'SESSION_USER');
    DBMS_SESSION.SET_CONTEXT('initvpd', 'benutzer_id', v_benutzer_id);
-- Der Einfachheit halber
    WHEN OTHERS THEN null;
  END;
END;
/

CREATE OR REPLACE TRIGGER vpd_init_trig AFTER LOGON ON DATABASE
  BEGIN
    system.initpack.benutzerdaten;
  EXCEPTION
-- Auch vereinfacht, um das Nachstellen zu erleichtern: Loggen sich Benutzer
-- ein, die nicht in EMPLOYEES / CUSTOMERS gelistet sind (z.B. SYSTEM, SYS!),
-- scheitert der Trigger nicht und ein solcher Benutzer kann sich einloggen.
    WHEN NO_DATA_FOUND THEN null;
END;
/

CREATE OR REPLACE FUNCTION ord_policy (schemaname IN VARCHAR2, tabname IN VARCHAR2) 
  RETURN VARCHAR2 AS
    v_benutzer_id  NUMBER;
    bedingung      VARCHAR2(200);
  BEGIN
    SELECT sys_context('initvpd', 'benutzer_id') 
            INTO v_benutzer_id 
    FROM dual;
     IF v_benutzer_id IS NOT null THEN
       bedingung := 'orders.sales_rep_id = '|| v_benutzer_id ||' OR orders.customer_id = ' || v_benutzer_id ; 
-- Die letzte Vereinfachung damit z.B. SYSTEM noch abfragen kann   
     ELSE
       bedingung := '1=1';
     END IF;
  RETURN bedingung;
END ord_policy;
/

BEGIN
  DBMS_RLS.ADD_POLICY (object_schema   => 'oe',
                       object_name     => 'orders',
                       policy_function => 'ord_policy',
                       policy_name     => 'o_policy',
                       statement_types => 'select');
END;
/

Zurück zur Community-Seite