Wir werden immer wieder danach gefragt wie Anonymisierung in der Datenbank funktioniert. Je nach Anforderung bietet die Oracle Datenbank dazu verschiedene Möglichkeiten wie Virtual Private Database, Label Security, Data Redaction und Data Masking. Was sind die Unterschiede? Welche Konzepte stecken dahinter?

Virtual Private Database (VPD)

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. Oracle bietet schon seit der Version Oracle8i eine weitere 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. 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. 

Label Security

Oracle Label Security (OLS) ist eine Option der Enterprise Edition der Datenbank. Was ist die Idee dahinter? Will man den Zugriff nur auf bestimmte Zeilen erlauben, hat man die Möglichkeit entweder Views anlegen, VPD zu programmieren oder einfach Label Security zu verwenden. Kurz beschrieben handelt es sich bei Oracle Label Security um eine fertige Anwendung, die auf Oracle Virtual Private Database aufgebaut ist. 

Wie funktioniert OLS? Zunächst werden Labels definiert. Offizielle Labels sind zum Beispiel “streng geheim”, “geheim”, “Verschlusssache – vertraulich” und “Verschlusssache – nur für den Dienstgebrauch”. Dann werden die definierten Labels einzelnen Tabellenzeilen zugewiesen und dabei in einer separaten Spalte gespeichert. Die Spalte wird automatisch in jeder Tabelle angelegt, die für das Arbeiten mit OLS vorbereitet wird.
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 Privilegien 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. 

Oracle Data Redaction

Seit dem Datenbank Release Oracle Database 12c gibt es im Rahmen der Advanced Security Option (ASO) das Feature Data Redaction, welches auch für 11.2.0.4 nachträglich verfügbar ist (Backport). Das Ziel ist dabei ein dynamisches Data Masking, also eine Unkenntlichmachung von Teilen der Ausgabe direkt beim Zugriff auf die Daten. Data Redaction wird über das Package DBMS_REDACT eingesetzt. Data Redaction verändert zwar ebenfalls Daten, aber ausschliesslich für die Ausgabe und damit der Darstellung von Produktivdaten, die in Berichten oder Anzeigemasken sichtbar werden. Die ursprünglichen, also gespeicherten, Daten bleiben dabei unverändert. Die mit Data Redaction bearbeiteten Daten können sogar nach wie vor für WHERE Bedingungen, in INSERTs, UPDATEs und DELETEs, für Berechnungen und für das Anlegen von Indizes verwendet werden.

Data Masking

Für Entwicklungs- und / oder Testumgebungen dürfen in der Regel keine Daten aus einer Produktionsumgebung verwendet werden. Mit dem Oracle Data Masking Pack können sensible Produktionsdaten irreversibel mit fiktiven Daten ersetzt werden. Kopien von Produktionsdatenbanken mit anonymisierten Daten können so einfach und schnell für Test- und Entwicklungsumgebungen bereitgestellt werden und/oder zusätzlich ein Subset der Daten erzeugt werden. Voraussetzung für Data Masking und Subsetting ist der Oracle Enterprise Manager. Desweiteren muss ein Application Data Model (ADM) oder Anwendungsdatenmodell vorhanden sein beziehungsweise erstellt werden. Im Anwendungsdatenmodell wird die Liste der Anwendungen, Tabellen und Beziehungen zwischen Tabellenspalten gespeichert, die entweder im Data Dictionary deklariert sind, aus Anwendungsmetadaten importiert oder vom Benutzer angegeben werden. Das Anwendungsdatenmodell verwaltet vertrauliche Datentypen und die zugehörigen Spalten. Data Masking setzt ein solches Anwendungsdatenmodell voraus. um eine konsistente Maskierung sensibler Spalten und aller abhängigen Spalten sicherzustellen.

Mitunter wird nach dem Unterschied zwischen Data Masking und Data Redaction, dem ASO Feature, gefragt. Diese Frage ist naheliegend, denn es geht in beiden Fällen um die Veränderung von Daten. Allerdings verändert Data Masking Daten permanent. Data Masking zielt darauf, in Entwicklungs- und Testumgebungen mit realistischen Daten arbeiten zu können, ohne diese mit dem gleichen Aufwand schützen zu müssen, der für die Originaldaten im Produktivsystem vorgeschrieben ist.

Links aus älteren Posts:

Handbucheinträge

OTN