Logo Oracle Deutschland   DBA Community  -  September 2012
Wer kennt Oracle Label Security?
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Oracle Label Security (OLS) ist eine Option der Enterprise Edition der Datenbank seit der Datenbankversion 9.0.1. Es handelt sich bei OLS um eine fertige Anwendung, die vollständig auf Oracle Virtual Private Database (VPD) aufgebaut ist.

Obwohl es sich also bei OLS um ein 'gestandenes' Oracle Produkt handelt, ist es vielen Kunden unbekannt. Oder vielleicht sollte man präziser sagen: Kaum ein Kunde redet über OLS. Das liegt sicherlich in erster Linie daran, dass Kunden, die sensibel für Security Fragen sind, sowieso nicht gerne Auskunft geben über die Massnahmen, die sie selbst ergriffen haben, sich zu schützen. Wenn man dann noch bedenkt, dass die Kunden, die OLS einsetzen, häufig aus Bereichen stammen, die für ihre Diskretion bekannt sind - Dienste, Polizei, Militär, Banken - hat man einen weiteren Grund dafür gefunden, warum so wenige über OLS reden.

Das ist allerdings bedauerlich, denn besonders in dieser Zeit steigenden Security Bewusstseins, verdient OLS auf jeden Fall mehr Aufmerksamkeit. Dieser Tipp möchte deshalb dazu beitragen, OLS bekannter zu machen. Dazu werden zunächst einige einführende Informationen zu OLS gegeben. Danach wird anhand eines kleinen Beispiels gezeigt, wie man mit OLS arbeitet. Ergänzend sei hier noch erwähnt, dass der Einsatz von OLS keinerlei Veränderungen an vorhandenen Anwendungen erfordert. In der Oracle Terminologie heisst das: OLS ist transparent für Anwender und Anwendungen.

Vorbemerkungen

SQL bietet über GRANTs die Möglichkeit, den Zugriff auf Tabellen zu kontrollieren. Allerdings greifen diese GRANTs nicht auf Zeilenebene, sondern immer nur auf der Ebene der gesamten Tabelle. Das wird mitunter auch als discretionary access control bezeichnet. Zum Beispiel bietet das Objekt Privileg SELECT immer die Möglichkeit, auf alle Zeilen einer Tabelle zuzugreifen. Will man nun den Zugriff nur auf bestimmte Zeilen erlauben, was mitunter auch als mandatory access control bezeichnet wird, hat man drei Möglichkeiten:
  1. Es werden Views definiert und der Zugriff auf die Daten wird über diese Views gesteuert. Wenn aber viele Tabellen und viele Benutzer mit unterschiedlichen Berechtigungen betroffen sind und / oder wenn die Zugriffsregeln komplex sind, wird das schnell unübersichtlich.
  2. Es wird eine eigene Zugriffssteuerung mit VPD programmiert. Hier kann man dann auch komplexe Regeln erstellen, die relativ leicht auf mehrere Tabellen anwendbar sind. Der Knackpunkt dabei ist das Programmieren. Wenn dazu die Expertise oder die Zeit fehlt, bietet Oracle eine vorgefertigte VPD Anwendung an, die komplett deklarativ, also recht einfach einzusetzen ist:
  3. Oracle Label Security

Wie funktioniert OLS?

OLS tritt nicht an die Stelle der bekannten GRANTS, sondern ergänzt sie. Das heisst, dass die GRANTs nach wie vor die erste Voraussetzung sind für jeden Zugriff auf eine Tabelle. Im Überblick funktioniert OLS folgendermassen:
Zusammenspiel der Komponenten
  1. Zunächst werden Labels definiert. Offizielle Labels sind zum Beispiel in der Bundesrepublik "streng geheim", "geheim", "Verschlusssache - vertraulich" und "Verschlusssache - nur für den Dienstgebrauch" oder in den USA "top secret", "secret", "confidential" und "restricted".
  2. Dann werden die definierten Labels einzelnen Tabellenzeilen zugewiesen. Dazu werden die Labels in einer separaten Spalte gespeichert. Die Spalte wird automatisch in jeder Tabelle angelegt, die für das Arbeiten mit OLS vorbereitet wird.
  3. Schliesslich erhalten auch die Benutzer Labels. Nach jedem Einloggen ist deren Labelinformation Teil ihres session context.
Greift nun ein Benutzer auf Datensätze in einer für OLS vorbereiteten Tabelle zu, wird wie immer zunächst überprüft, ob dieser Benutzer überhaupt über die notwendigen Priviliegien verfügt, auf die Tabelle zuzugreifen. Ist das der Fall, wird über einen Abgleich des Benutzerlabels und des Zeilenlabels festgestellt, auf welche Sätze genau der Benutzer zugreifen darf.

Was ist ein Label?

Ein Label in OLS kann aus bis zu drei Teilen bestehen. Da ist zunächst das LEVEL (Ebene). Das Level ist obligatorisch, es hat jeweils einen frei zu vergebenden Lang- und Kurznamen sowie einen ebenfalls frei zu vergebenden numerischen Wert. Levels sind hierarchisch, das heißt, je höher das Level ist, desto höher ist der Wert. Während die Namen dem DBA bzw. Anwendungsentwickler das Arbeiten erleichtern, arbeitet die Datenbank selbst nur mit den numerischen Werten. Ein Benutzer hat Zugriff auf alle Sätze, deren Labelwerte kleiner oder gleich dem Wert sind, für die dieser Benutzer zugriffsberechtigt ist.

Ein Label KANN über sogenannte COMPARTMENTs (Abteilungen) verfügen. Compartments sind nicht hierarchisch, sondern differenzieren ein Level zusätzlich. So können in einer Tabelle zum Beispiel mehrere Datensätze existieren, die vom Level her alle GEHEIM sind, die aber unterschiedlichen Compartments zugeordnet sind. Ein Benutzer muss dann neben dem richtigen Level auch noch dem richtigen Compartment (der richtigen Abteilung) zugeordnet sein, um die entsprechenden Sätze bearbeiten zu können.

Zusammenspiel der Komponenten Schliesslich KANN einem Label auch noch eine sogenannte GROUP (Gruppe) zugewiesen werden. Gruppen sind wieder hierarchisch und fungieren als weiteres Differenzierungsmerkmal für den Zugriff.

Das Schaubild rechts zeigt an einem Beispiel, wie die Komponenten zusammenarbeiten, um den Zugriff auf mit Labels geschützte Datensätze zu steuern:

Das Level im Label des fiktiven Bundesministers besagt, dass dieser berechtigt ist, mit streng geheimen Daten zu arbeiten.

Das Compartment beschränkt diese Berechtigung auf die Abteilung Finanzen.

Da das Label des Bundesministers als Group DE (für Deutschland) enthält und der Bund in der Hierarchie über den Ländern steht, hat der Minister Zugriff auf die Daten aus den Bundesländern (hier NW, BY, MV).

Im Ergebnis hat der fiktive Minister also Zugriff auf alle Tabellenzeilen, deren Label rötlich markiert ist.

Beispiel vorbereiten

Soll das Beispiel nachgestellt werden, wird dazu eine Enterprise Edition der Datenbank benötigt, in der OLS installiert und konfiguriert ist. Bei einer völlig neuen Installation kann man dies mit dem Oracle Universal Installer über den Weg einer Advanced Installation und der Auswahl der Option im entsprechenden Dialog erreichen. Liegt bereits eine Installation der Datenbank vor, kann man durch eine Abfrage auf V$OPTION prüfen, ob OLS bereits installiert ist. Ist das nicht der Fall, fährt man die Datenbank und eventuell den Listener sowie das Database Control herunter. Da in allen Datenbanken seit der Version 11.2 alle Softwarekomponenten installiert sind, kann OLS vom Eigentümer der Oracle Software jetzt ganz einfach über folgende Eingabe auf der Kommandozeile in den Programmcode eingebunden werden:
chopt enable lbac
Anschliessend werden über den Database Configuration Assistant (dbca) die benötigten Datenbankobjekte erstellt.

Zu den erstellten Objekten gehört auch der Benutzer LBACSYS. Er ist Eigentümer aller Objekte von OLS. Der Account ist noch gesperrt und muss, weil damit gearbeitet werden soll, von einem DBA, etwa SYSTEM, entsperrt und mit einem gültigen Passwort versehen werden.
ALTER USER lbacsys ACCOUNT UNLOCK IDENTIFIED BY passwort
Weiterhin soll dieser Benutzer auch das OEM Database Control (OEM) nutzen können. Deshalb erteilt der DBA ihm das entsprechende Privileg.
GRANT select any dictionary TO lbacsys
Hier sei noch erwähnt, dass beim Erstellen der Datenbankobjekte von OLS die Tabelle AUD$ den Besitzer wechselt: Mit der erfolgreichen Konfiguration gehört sie nun SYSTEM.

Weil die Tabelle SCOTT.EMP in jeder Oracle Datenbankinstallation verfübar ist, soll das obige Beispiel ansatzweise anhand dieser Tabelle nachgestellt werden.

Als erstes wird EMP dazu zunächst für den Zugriff durch beliebige Benutzer freigegeben. Ausserdem werden einige Benutzer angelegt, die später belegen, wie OLS die Ergebnismengen in Abhängigkeit von diesen Benutzern bestimmt. Das zugehörige Skript ist hier zu finden.

In folgenden Schritten wird das Beispiel aufgebaut:
  1. Policy anlegen und mit einer Tabelle verbinden
  2. Labels anlegen
  3. Benutzern und Zeilen Labels zuweisen
  4. Testen

Policy anlegen und mit einer Tabelle verbinden

Alle weiteren Aktionen zum Anlegen des Beispiels führt LBACSYS aus. Das erste Objekt, das man benötigt, um mit OLS zu arbeiten, ist eine POLICY. Eine Policy ist eine Art Container für die in einem konkreten Fall benötigten OLS Objekte, die einer Tabelle oder auch mehreren Tabellen zugewiesen werden sollen. Das Anlegen einer Policy erfolgt mit dem Aufruf einer Prozedur
BEGIN
 SA_SYSDBA.CREATE_POLICY(
   POLICY_NAME     => 'communitypolicy', 
   COLUMN_NAME     => 'lspalte',
   DEFAULT_OPTIONS => 'read_control, write_control'
                                );
END;
/
oder im OEM unter dem Reiter SERVER Bereich SECURITY Punkt Oracle Label Security.

Zur Erläuterung: Selbstverständlich benötigt eine Policy einen Namen. Hier ist als Name COMMUNITYPOLICY angegeben. Weiter oben wurde bereits darauf hingewiesen, dass ein Zeilenlabel in einer speziell dafür angelegten Spalte gespeichert wird. Der Name dieser Spalte ist frei zu vergeben und wird hier mit LSPALTE angegeben. Die Policy soll angewendet werden sowohl beim Lesen der Daten, als auch beim Schreiben, also für die Aktionen INSERT, UPDATE und DELETE.

Nun wird diese Policy der Tabelle EMP zugewiesen. Auch diese Aktion ist über den OEM durchführbar. Dazu auf der bereits abgebildeten Bildschirmseite in der Auswahlliste den Punkt Anwenden auswählen und dann den Button Weiter klicken.
BEGIN
   SA_POLICY_ADMIN.APPLY_TABLE_POLICY(
     POLICY_NAME => 'communitypolicy', 
     SCHEMA_NAME => 'scott',
     TABLE_NAME  => 'emp'
                                     );
END;
/
Mit dem Aufruf der Prozedur wird die Tabelle EMP um die Spalte erweitert, in der später die Labels für die einzelnen Zeilen abgelegt werden. Sie heisst, wie beim CREATE POLICY angegeben LSPALTE.

Labels anlegen

Das Anlegen eines Labels erfolgt nun in zwei Schritten: Zunächst werden die Komponenten angelegt, aus denen ein Label bestehen kann. Mit Komponenten sind die vom Anwender benötigten Levels, Compartments und Groups gemeint. In diesem Fall sollen die Ebenen L, M und S heissen, die Compartments VERTRIEB, FORSCHUNG und VERWALTUNG. Auf die Definition von GROUPS wird verzichtet. Hier das Beispiel für das Anlegen des Levels MITTEL
BEGIN
   LBACSYS.SA_COMPONENTS.CREATE_LEVEL(
      POLICY_NAME => 'communitypolicy', 
      LEVEL_NUM   => 50,               -- zwischen 0 und 9999
      SHORT_NAME  => 'M',              -- maximal 30 Zeichen
      LONG_NAME   => 'mittel'          -- maximal 80 Zeichen
                                     );
END;
/
Hier sind die alle Prozeduraufrufe zu finden, mit denen die Levels und Compartments angelegt werden. Alternativ kann natürlich auch wieder im OEM gearbeitet werden. Dazu auf der bereits dargestellten Seite den Punkt Bearbeiten wählen und anschliessend unter dem Reiter Label-Komponenten die gewünschten Einträge vornehmen.

Wichtig ist bei der Definition des Levels die Angabe des Wertes LEVEL_NUM: Je höher die 'Geheimhaltungsstufe', die der Level bezeichnen soll, desto höher ist dieser Wert. So hat der Level GROSS im Beispiel den Wert 100, der Level KLEIN den Wert 25. Der SHORT_NAME wird in weiteren Prozeduren verwendet, der LONG_NAME hat nur erläuternden Charakter.

Aus den angelegten Komponenten werden nun die Label selbst definiert. Es müssen nicht alle denkbaren Kombinationen angelegt werden, sondern nur die wirklich benötigten. Hier der Prozeduraufruf zum Anlegen eines Labels.
BEGIN
   SA_LABEL_ADMIN.CREATE_LABEL(
     POLICY_NAME => 'communitypolicy', 
     LABEL_TAG   => 503,              -- muss zwischen 0 und 99999999 liegen
     LABEL_VALUE => 'M:ADM,RES,VB'
                               );
END;
/
Die Prozeduraufrufe zum Anlegen der Labels sind wieder vollständig hier zu finden, während die entsprechende Seite im OEM hier zu sehen ist. Bitte in der Auswahlliste den Punkt Daten-Labels wählen und auf Weiter klicken.

Der Wert für das LABEL_TAG - hier 503 - bestimmt den Sortierwert des Labels, der LABEL_VALUE zeigt, welcher Level und welche Compartments dem LABEL_TAG zugeordnet sind.

Benutzern und Zeilen Labels zuweisen

Das Zuweisen der Benutzerlabels erfolgt wieder über OLS spezifische Prozeduren. Levels und Compartments werden dabei in eigenen Schritten zugewiesen.
BEGIN
   SA_USER_ADMIN.SET_LEVELS(
      POLICY_NAME => 'communitypolicy',
      USER_NAME   => 'clark',
      MAX_LEVEL	=> 'm'     );
END;
/
BEGIN
   SA_USER_ADMIN.SET_COMPARTMENTS(
      POLICY_NAME => 'communitypolicy',
      USER_NAME   => 'clark',
      READ_COMPS  => 'adm,res,vb',
      WRITE_COMPS => 'adm,res,vb',
	);
END;
/
Hier die Prozeduraufrufe für alle angelegten Benutzer. Natürlich können auch diese Aufrufe über die graphische Benutzeroberfläche des OEM erfolgen. Dazu im gezeigten Bildschirm in der Auswahlliste den Punkt Autorisierung wählen und anschliessend Weiter klicken.

Die Zuweisung von Labels an Tabellenzeilen erfolgt über ein einfaches UPDATE der Labelspalte unter der Verwendung der Funktion CHAR_TO_LABEL, also zum Beispiel
UPDATE scott.emp
SET lspalte = CHAR_TO_LABEL('communitypolicy', 'M:ADM')
WHERE job = 'MANAGER' and deptno = 10
/
Da das Zuweisen und Ändern von Labels nur mit besonderen Privilegien verbunden ist, auf die hier nicht eingegangen werden soll, lassen wir den Benutzer SYS die UPDATEs durchführen. Alle UPDATES für das Beispiel im Tipp finden sich hier.

Testen

Damit sind alle Vorkehrungen für diese minimale Beispielstellung getroffen. Nun sollen die Auswirkungen der getroffenen Einstellungen getestet werden. Dazu wird das folgende SELECT immmer wieder mit unterschiedlichen Benutzern ausgeführt. Um etwas besser nachvollziehen zu können, welche Labeleinstellungen gerade wirksam sind, wird neben den Kurzbezeichnungen der Labelspalte noch der numerischen Wert des Labels sowie der aktuelle Userlabelwert des Sessionbenutzers angezeigt. Nicht alle Ergebnisse werden im Bild dargestellt.
SELECT ename, job, deptno, lspalte,
       sa_utl.numeric_label('communitypolicy') labelnummer, sa_session.label('communitypolicy') sessionlabel
FROM   scott.emp
ORDER BY deptno, lspalte desc
Führt man das SELECT als Benutzer KING aus, erhält man alle 14 Sätze angezeigt. Das Ergebnis ist korrekt, denn für KING wurde (siehe oben) das Systemprivileg EXEMPT ACCESS POLICY vergeben. Das heisst, dass keine Policy auf ihn angewendet wird. Erkennbar ist das auch an den fehlenden Einträgen in den Spalten LABELNUMMER und SESSIONLABEL. KING selektiert Auch LBACSYS und SYS verfügen übrigens standardmäßig über dieses Privileg. Sollen die Daten auch gegen diese privilegierten Benutzer geschützt werden, ist das mit der Option Database Vault möglich, die ja bereits einmal Gegenstand eines Tipps war.

Führt man das Statement als Manager CLARK aus, der als eine Art Stellvertreter KINGs aufgesetzt ist, werden alle Sätze mit Ausnahme des Satzes von KING angezeigt, also 13 Sätze. Das Label von KINGs Satz hat den Level 1000 und liegt damit über dem Level von CLARK (503). Ausserdem ist in den letzten beiden Spalten zu erkennen, welche Labeleinstellungen aktiv sind.

Der Manager JONES dagegen sieht nur alle Daten aus seiner Abteilung, während SCOTT, der in dieser Abteilung arbeitet, wiederum nur die Daten seiner Kollegen mit Ausnahme der Daten seines Vorgesetzten JONES sieht.

Hinweis und weitere Informationen

Dieser Tipp will nur eine allereinfachste Einführung in OLS bieten. Deshalb fehlt auch die Darstellung weitergehender Möglichkeiten, etwa wie man ein Default Level für das Einloggen festlegt, wie der Labeleintrag beim Einfügen neuer Sätze behandelt wird oder welche Änderungsmöglichkeiten für ein vorhandenes Label erlaubt werden können, wie Benutzerlabel im Oracle Internet Directory gespeichert werden können und vieles mehr. Das heisst auch, dass die Lektüre des Handbuchs unbedingt nötig ist, wenn man nach diesem Tipp meint, dass OLS eine interessante Ergänzung bereits bestehender eigener Sicherheitsmassnahmen sein könnte.

Natürlich gibt es für OLS auch eine eigene Seite auf OTN, auf der weitere Informationen zu finden sind für denjenigen, der / die sich weiter mit der Option beschäftigen möchten. Und auch auf MOS finden sich viele nützliche Informationen, von der Installation in Note 171155.1 "How to Install / Deinstall Oracle Label Security" bis hin zur Note 230980.1 "Oracle Label Security - Concepts (Policies and Labels) and Examples".


Zurück zur Community-Seite