Privilegien einschränken mit Database Vault
von Heinz-Wilhelm Fabry, ORACLE Deutschland GmbH

Benutzer mit der Rolle DBA und Benutzer, die sich aufgrund ihrer Betriebssystemprivilegien als Benutzer SYS bei einer Oracle-Datenbank anmelden können, haben seit jeher lesenden und schreibenden Zugriff auf den gesamten Datenbestand der Datenbank. Sie können auch die Strukturen der Datenbank und der darin abgelegten Objekte nahezu nach Belieben manipulieren. Inzwischen gewinnen allerdings Datenschutz und Datensicherheit immer mehr an Bedeutung, und unterschiedlichste Gesetze und Verordnungen verpflichten Unternehmen dazu, die 'Machtfülle' einzelner oder privilegierter Benutzer einzuschränken. Der Einsatz von Oracle Database Vault (DV), einer kostenpflichtigen Option der Enterprise Edition der Datenbank, kann dabei eine große Hilfe sein: Zum einen unterstützt DV Funktionstrennung und Aufgabenverteilung (separation of duties) - eine zentrale Komponente jeder Sicherheitsarchitektur. So können z.B das Verwalten von Benutzern, das Einrichten und Ändern von Datenbankstrukturen usw. mit den Mitteln von DV auf unterschiedliche Personen verteilt werden. Zum andern kann DV genauso wirksam das Prinzip des least privilege durchsetzen. Privilegien können mittels DV so verteilt und eingeschränkt werden, dass z.B. Datenbankadministratoren (DBAs) ausschließlich über die Privilegien verfügen, die sie für die Erfüllung der ihnen speziell zugewiesenen Aufgaben benötigen. Diese DBAs erhalten aber nicht mehr automatisch weitere oder gar alle Systemprivilegien.

Der folgende Beitrag versteht sich als erste Einführung in das Arbeiten mit DV.

Hintergrundinformationen

DV wurde mit Oracle 10g Release 2 eingeführt. Auf einigen Betriebssystemen ist auch nach Rückportierung eine Version für Datenbanken der Version 9.2.0.8 verfügbar. Diesem Community-Artikel liegt die Version 11.2.0.1 zugrunde. Die Funktionalität ist bis auf Feinheiten in allen Versionen identisch.

Die Installation benötigt ungefähr 300M zusätzlichen Plattenspeicher. Die Konfiguration - z.B. im Rahmen einer Neuinstallation der Datenbank - dauert nur wenige Minuten.

Die Objekte der Option werden in zwei eigens eingerichteten Tablespaces namens DVSYS und DVF abgelegt. Diese Tablespaces werden zugleich mit den Mitteln von DV gesichert. Außerdem modifiziert das Installationsskript die Rollen DBA, IMP_FULL_DATABASE, EXECUTE_CATALOG_ROLE und PUBLIC. Am bedeutsamsten sind dabei sicherlich die Veränderungen der Rolle DBA. Ihr werden aus Sicherheitsgründen folgende Privilegien genommen: BECOME USER, CREATE ANY JOB, CREATE EXTERNAL JOB, DEQUEUE ANY QUEUE, EXECUTE ANY CLASS, EXECUTE ANY PROGRAM, MANAGE SCHEDULER, MANAGE ANY QUEUE und SELECT ANY TRANSACTION. Das führt natürlich dazu, dass einige Routinearbeiten von DBAs, z.B. das Aufsetzen von Jobs oder das Arbeiten mit Data Pump, anders organisiert werden müssen - und können! - als in Datenbanken ohne DV. Diese Aspekte werden hier allerdings nicht behandelt, sondern sollen Teil eines weiterführenden Artikels werden.

Die Komponenten von DV sind sowohl über den Aufruf von Packages von der Kommandozeile oder aus Anwendungen heraus einzusetzen als auch über eine graphische, browser-basierte Schnittstelle, den Database Vault Administrator (dva). Diese graphische Schnittstelle ist auch über Enterprise Manager Database Control der Datenbank in der Version 11.2 erreichbar. Ausserdem ermöglichen dieses Database Control sowie die aktuellste Version des Grid Control ein Monitoring von DV-Umgebungen.

Die oben erwähnten Prinzipien der Aufgabenverteilung und Funktionstrennung sowie des least privilege finden auch in der Implementierung des Vault selbst Anwendung. Dabei sind zwei Rollen, die bei der Installation des Vault vergeben werden, von zentraler Bedeutung. Da ist zunächst die Rolle DV_OWNER. Sie berechtigt ausschließlich dazu, die Strukturen des Vault zu administrieren. Die Rolle verfügt darüber hinaus über keinerlei Privilegien zum Zugriff auf Benutzerobjekte oder zur Vergabe von Objekt- oder Systemprivilegien. Die zweite wichtige Rolle heißt DV_ACCTMGR. Nur wer diese Rolle bekommen hat, kann Benutzer anlegen und die Passwörter anderer Benutzer ändern. Und auch für diese Rolle gilt: Sie verfügt über keinerlei weitere Privilegien zum Zugriff auf Benutzerobjekte oder zur Vergabe von Objekt- oder Systemprivilegien. In der Praxis führt dieses Konstrukt dazu, dass 'normale' DBAs und die Personen mit den Rollen DV_OWNER und DV_ACCTMGR zur Administration einer mit DV gesicherten Datenbank zusammenarbeiten müssen und sich dadurch auch ständig gegenseitig kontrollieren.

Die folgende Abbildung zeigt den Eingangsbildschirm des dva. Alle Komponenten von DV sind von hier aus erreichbar.

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

Die Installation von DV allein reicht nicht aus, um eine Datenbank sicherer zu machen. Vielmehr erhält der Kunde damit Werkzeuge an die Hand, die er für seine speziellen Sicherheitsanforderungen nutzen kann. Für diese Einführung in die Möglichkeiten von DV soll auf die drei wichtigsten dieser Werkzeuge etwas näher eingegangen werden: auf Realms, Rule Sets und Command Rules. Diese Werkzeuge werden hier beispielhaft dazu verwendet

  • privilegierten Benutzern den Zugriff auf die Tabelle EMP des Benutzers SCOTT zu entziehen und
  • dem Benutzer SCOTT das Recht zu entziehen, Sätze in 'seiner' Tabelle EMP zu löschen

Tabellen durch Realms schützen

Aus dem folgenden Bild wird deutlich, dass der Benutzer SYSTEM problemlos die Tabelle EMP des Benutzers SCOTT lesen kann:

Benutzer SYSTEM selektiert Sätze aus SCOTT.EMP
Zum Vergrößern auf das Bild klicken, zurück zum Artikel mit dem Back-Button des Browser

Soll die Tabelle vor dem Zugriff durch privilegierte Benutzer, z.B. SYSTEM, geschützt werden, ist das am einfachsten durch ein Realm zu erreichen. Realms sind logische Konstrukte, denen Schema-Objekte, z.B. Tabellen und Packages, zugeordnet werden können.

Nur die Person mit der Rolle DV_OWNER kann ein Realm anlegen. Dazu wählt sie im dva (s.o.) den Menupunkt Realms, dann dort das Untermenu CREATE. Das Realm wird angelegt, indem ein Name vergeben wird, hier EmpRealm. Über PULL DOWN Menus werden die zu schützenden Objekte ausgewählt. Das Ergebnis sieht man in der folgenden Abbildung.

Anlegen eines Realms mit EMP als zu schützendes Objekt
Zum Vergrößern auf das Bild klicken, zurück zum Artikel mit dem Back-Button des Browser

Wie die folgende Abbildung zeigt, kann SYSTEM unmittelbar nachdem die Tabelle EMP in ein Realm eingestellt wurde - also ohne erneutes Logon und ohne Neustart der Datenbank - nicht mehr auf die Tabelle zugreifen. Dies gilt auch für alle anderen Benutzer einschließlich des Benutzers SYS, die versuchen, mit ANY Privilegien auf die Tabelle zuzugreifen. Ein ANY Privileg verkehrt sich hier also sozusagen in sein Gegenteil und wird zum Ausschlußkriterium für den Zugriff auf Daten.

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

Bezogen auf Tabellen hat der Realmschutz folgende Auswirkungen
  1. Nur der Eigentümer und alle Benutzer, die über explizite GRANTS dazu ermächtigt wurden, können weiterhin DML-Operationen ausführen. Dies ist ausserordentlich bedeutsam, denn es impliziert: Anwendungen, die mit den Daten arbeiten, müssen NICHT geändert werden, selbst wenn Objekte erst nachträglich über Realms geschützt werden - vorausgesetzt die Anwendungen arbeiten nicht mit DBA Privilegien auf den Daten.
  2. Niemand kann DDL-Operationen ausführen, es sei denn, er / sie hat die entsprechenden Privilegien über explizite GRANTs erhalten UND ist durch den Anwender mit der Rolle DV_OWNER in dem Realm als sogenannter PARTICIPANT gekennzeichnet worden. Dies erfolgt im dva durch einfaches Anklicken eines Radio-Button.
  3. Niemand kann Privilegien mit dem Befehl GRANT auf die Tabelle vergeben, es sei denn, er / sie hat die entsprechenden Privilegien, z.B. ein SELECT WITH GRANT OPTION, UND ist durch den Anwender mit der Rolle DV_OWNER in dem Realm als sogenannter OWNER gekennzeichnet worden. Dies erfolgt im dva durch einfaches Anklicken eines Radio-Button. Die Kennzeichnung OWNER beinhaltet die Authorisierung PARTICIPANT.
Wie man sieht, ist über diese Rechtestruktur sichergestellt, dass die Person mit der Rolle DV_OWNER keinen Zugriff auf eine realmgeschützte Tabelle erlangen kann. Denn selbst wenn die Person sich als PARTICIPANT oder OWNER in dem entsprechenden Realm einträgt, würden ihr nach wie vor die expliziten GRANTs für den Zugriff auf die Tabelle fehlen.

SQL Befehle kontrollieren

Ein weiteres Feature, die sogenannten Regelgruppen (rule sets) und ihre besondere Ausprägung, die Befehlsregeln (command rules, bieten eine flexible Erweiterung des Schutz von Daten vor privilegierten Benutzern. So können etwa SQL Befehle unter das Vier-Augen-Prinzip gestellt werden oder an beliebige andere programmierbare Voraussetzungen. Das soll wiederum an einem Beispiel verdeutlicht werden.

Wie bei den Auswirkungen, die der Realmschutz auf eine Tabelle hat, kann der Eigentümer einer Tabelle diese Tabelle grundsätzlich mit DML Befehlen bearbeiten. Das ist aber in DV ganz einfach durch eine Befehlsregel zu unterbinden: Im dva verknüpft der Benutzer mit der Rolle DV_OWNER unter Command Rules den SQL Befehl DELETE im Hinblick auf die Tabelle EMP mit dem Rule Set Disabled und schaltet dadurch den Befehl im Kontext der Tabelle EMP aus. Die Abbildung zeigt den entsprechenden Bildschirm.

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

Schaut man sich unter dem Menüpunkt Rule Set die Regelgruppe Disabled an, so findet man, dass diese Regelgruppe aus nur einer Regel besteht, nämlich aus der Regel 1=0. Diese Regel wird für jedes DELETE ausgewertet, ergibt natürlich immer den Wert FALSE und verhindert jetzt zuverlässig das Löschen von Daten in der Tabelle EMP.

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

Natürlich können Regeln selbst geschrieben und auch komplexer sein, aber für dieses Beispiel genügt diese im Lieferumfang von DV enthaltene Regelgruppe. Dass ein DELETE auch durch SCOTT nicht mehr möglich ist, belegt die folgende Abbildung. SCOTT kann zwar nach wie vor lesen, aber keine Sätze mehr löschen.

SCOTT kann lesen, aber nicht löschen
Zum Vergrößern auf das Bild klicken, zurück zum Artikel mit dem Back-Button des Browser

Im übrigen kann mit Regeln auch der Zugriff auf andere Komponenten von DV gesteuert werden - beispielsweise der Zugriff auf Realms.

Weitere Möglichkeiten

Zum Arbeiten mit DV kann auf Umgebungsvariablen (Factors) und eigene Rollen (Secure Application Roles) zurückgegriffen werden. Beide Komponenten sind in anderer Form in der Datenbank bereits bekannt - die Faktoren z.B. im Umfeld von Virtual Private Database (VPD) als application contexts. Der Unterschied liegt darin, dass die Umgebungsvariablen und Rollen von DV durch keinen DBA oder den Benutzer SYS zu manipulieren sind, sondern ausschließlich durch die speziellen Mechanismen von DV. Schließlich bietet DV die Möglichkeit der Integration mit Label Security sowie eine erkleckliche Anzahl von Berichten zum Monitoring des DV sowie security-relevanter Einstellungen der Datenbank.

Zurück zur Community-Seite