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.


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

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.

Zurück zur Community-Seite