Oracle 12c - Das umfassende Handbuch

Kapitel 11

Sicherheit und Überwachung

284

11.3 Virtual Private Database (VPD)

Die Virtual Private Database ist eine feinmaschige Zugriffskontrolle, die in der

Datenbank implementiert ist. Sie ermöglicht eine Zugriffskontrolle auf Zeilen-

und Spaltenebene. Die VPD ist direkt im RDBMS implementiert und funktioniert

unabhängig vom Client-Programm, mit dem der Zugriff erfolgt. Ein klassischer

Anwendungsfall ist die Mandantenfähigkeit einer Applikation. Dabei speichern

verschiedene Mandanten ihre Datensätze in denselben Tabellen. VPD ermöglicht

eine klare Trennung, sodass jeder Mandant ausschließlich Zugriff auf die eigenen

Sätze hat.

Das Prinzip der VPD basiert auf der Möglichkeit, Policies zu Tabellen, Views oder

Synonymen zuzuordnen. Für die Auswertung der Policy-Funktion gibt es drei

Optionen:

쐽 Static Policy. Die Policy wird pro SQL-Anweisung einmalig ausgewertet.

쐽 Context-sensitive Policy. Die Policy wird nur ausgewertet, wenn sich der Applica-

tion Context in der Policy verändert.

쐽 Dynamic Policy. Die Policy wird jedes Mal ausgewertet, wenn die SQL-Anwei-

sung ausgeführt wird.

Abbildung 11.6 zeigt die Architektur der Virtual Private Database. Eine SQL-

Anweisung durchläuft die folgenden Schritte:

1. Der Client sendet eine SQL-Anweisung an die Datenbank.

2. Oracle prüft, ob eine Security Policy mit der Tabelle verknüpft ist. Ist dass der

Fall, wird die Policy-Funktion aufgerufen.

3. Die Policy-Funktion liefert ein Prädikat.

4. Oracle fügt das Prädikat zur WHERE-Klausel der SQL-Anweisung hinzu und

führt die modifizierte Anweisung aus.

5. Der Client bekommt das Resultset geliefert.

Vorsicht

Beachten Sie, dass die Wahl der Policy Auswirkung auf die Performance haben

kann. Die Dynamic Policy ist zwar sehr flexibel einsetzbar, hat jedoch den größ-

ten Einfluss auf die Performance.

11.3

Virtual Private Database (VPD)

285

Abb. 11.6: Die Architektur der Virtual Private Database

11.3.1 Application Context

Application Context ist ein unabhängiges Produkt. Es ist unter anderem nützlich

bei der Konfiguration einer VPD zur Verwendung in einer Policy-Funktion. Ein

Application Context ist ein aus Namen und Wert bestehendes Paar, das die Oracle-

Datenbank für jede Sitzung im Hauptspeicher behält. Eine Applikation kann den

Context benutzen, um Sitzungsinformationen über den Benutzer zu erlangen.

Stellen Sie sich den Application Context als eine Sammlung von globalen Variab-

len vor, zu vergleichen mit den Umgebungsvariablen des Betriebssystems, die

während einer Datenbanksitzung gehalten werden.

Oracle unterscheidet drei Kategorien für den Application Context:

쐽 Database Session-based Application Context. Dieser Context liest Daten, die in der

Benutzer-Session der Datenbank (UGA) gespeichert sind.

쐽 Global Application Context. Dieser Typ liest die Informationen aus der System

Global Area und ist für Applikationen geeignet, die ein Modell ohne Sessions

verwenden, also Applicationserver, die mit Connection Pooling arbeiten.

쐽 Client Session-based Application Context. Hier wird das Oracle Call Interface auf

dem Client verwendet, um die Sitzungsinformationen zu konfigurieren.

Mit der Funktion SYS_CONTEXT kann der Session Context abgefragt werden.

Neben dem benutzerdefinierten Context gibt es Standardvariablen, die von Oracle

für jede Session gesetzt werden. Eine solche ist die Variable SESSION_USER, die

den Benutzernamen enthält.

SQL> SELECT SYS_CONTEXT('USERENV','SESSION_USER') FROM dual;

SYS_CONTEXT('USERENV','SESSION_USER')

Kapitel 11

Sicherheit und Überwachung

286

Ein Context kann mithilfe der Prozedur SET_CONTEXT im Paket DBMS_SES-

SION gesetzt werden. Das folgende Beispiel zeigt, wie ein Context gesetzt werden

kann. Auf Basis der Tabelle hr.employees wird die Nummer der Abteilung als Con-

text in der Session des jeweiligen Benutzers gesetzt. Führen Sie die folgenden

Schritte aus, um den Context zu erstellen:

1. Erstellen Sie den Application Context. Der Context wird mit einer Prozedur ver-

bunden, die einem Namen den entsprechenden Wert zuordnet.

2. Die Prozedur ordnet dem Namen dept_number den entsprechenden Wert zu.

Die Nummer wird aus der Tabelle employees ermittelt.

3. Erstellen Sie einen Logon-Trigger, der die Prozedur zum Setzen des Application

Context aufruft.

-----------------------------------------------------------

SYS

SQL> CREATE CONTEXT mitp_ctx USING system.mitp_ctx_pkg;

Kontext wurde erstellt.

SQL> CREATE OR REPLACE PACKAGE system.mitp_ctx_pkg AS

2 PROCEDURE set_ctx;

3 END;

4 /

Package wurde erstellt.

SQL> CREATE OR REPLACE PACKAGE BODY system.mitp_ctx_pkg AS

2 PROCEDURE set_ctx IS

3 v_deptno NUMBER;

4 BEGIN

5 SELECT department_id INTO v_deptno FROM hr.employees

6 WHERE UPPER(last_name) =

UPPER(SYS_CONTEXT('USERENV','SESSION_USER'));

7 DBMS_SESSION.SET_CONTEXT('mitp_ctx','dept_number',v_deptno);

8 EXCEPTION

9 WHEN OTHERS THEN

10 DBMS_SESSION.SET_CONTEXT('mitp_ctx','dept_number',9999);

11 END;

12 END;

13 /

Package Body wurde erstellt.

SQL> CREATE OR REPLACE TRIGGER emp_context

2 AFTER LOGON ON DATABASE

3 BEGIN

4 system.mitp_ctx_pkg.set_ctx;

5 END;

6 /

Trigger wurde erstellt.