|
Oracle Data Redaction
von Heinz-Wilhelm Fabry ORACLE Deutschland B.V. & Co.KG
Ende Juni 2013 wurde das neue Datenbank Release Oracle Database 12c
zum Download zur Verfügung gestellt. Ein besonderer
Artikel der DBA Community hat über die neuen Features informiert. Eines der
dort vorgestellten Features ist Oracle Data Redaction und Teil der Advanced
Security Option (ASO). Dieses Feature steht nun auch nach einem sogenannten
backport in der aktuellsten Version von ASO in Oracle Database 11g
Release 2 zur Verfügung. Dieses Release mit der Versionsnummer 11.2.0.4 ist seit
Ende August 2013 auf unterschiedlichen Plattformen verfügbar und wird vermutlich
das final release der Version 11.2 sein.
Der
aktuelle Artikel ist damit sowohl für diejenigen interessant, die sich über Oracle
Database 12c informieren möchten, als auch für jene, die noch mit Oracle
Database 11g arbeiten und ihre vorhandenen ASO Lizenzen nach einem Upgrade
auf 11.2.0.4 optimal nutzen möchten. Selbstverständlich wird Data Redaction hier
etwas ausführlicher betrachtet, als das in dem oben erwähnten Überblick möglich war.
Einführung
Jeder kennt Data Redaction aus eigener Erfahrung: Auf dem Kassenbeleg einer
Kreditkartenzahlung sind nicht alle Ziffern der Kreditkartennummer ausgedruckt,
sondern nur die letzten Ziffern dieser Nummer. Die übrigen Ziffern sind zum
Beispiel durch * unkenntlich gemacht. Bisher wird dieses unkenntlich Machen
in der Anwendung programmiert, und zwar in jeder einzelnen Anwendung, die auf die
Kreditkartennummer zugreift. Mit Oracle Data Redaction kann das unkenntlich Machen
nun direkt in der Tabelle bei den Daten hinterlegt werden und gilt damit für jeden
Zugriff, der zu einer Bildschirm- oder Druckausgabe führt. Die Kreditkartennummer
kann dennoch zum Beispiel in WHERE Bedingungen nach wie vor verwendet werden. Auf
Spalten, die mit Data Redaction unkenntlich gemacht werden, können auch nach wie
vor Berechnungen durchgeführt oder Indizes angelegt werden.
Mitunter wird nach dem Unterschied zwischen Data Masking, wie es zum Beispiel
mit dem Oracle Enterprise Manager Cloud Control Data Masking Pack angeboten wird,
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. Data Redaction verändert zwar ebenfalls Daten, aber
ausschliesslich die Ausgabe von Produktivdaten, die in Berichten oder
Anzeigemasken sichtbar werden. Die ursprünglichen 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 Redaction: Der Rahmen
Data Redaction wird über das Package DBMS_REDACT eingesetzt. Für das Package
muss also das Privileg EXECUTE vorliegen.
Es stehen vier unterschiedliche Möglichkeiten des Redigierens zur Verfügung. Alle
erhalten den Datentyp der Daten, auf die sie angewendet werden.
- FULL: Wird nichts anderes spezifiziert, so wird immer diese Möglichkeit
zum Redigieren verwendet. Dabei wird der gesamte Wert durch eine definierbare
Konstante ersetzt. Wird keine Konstante angegeben, werden Characterwerte durch
ein einzelnes Leerzeichen, Numberwerte durch eine 0 und Datumswerte durch den
Wert '1. Januar 2001' ersetzt. Diese Defaults können auf der Ebene der
Datenbank umgesetzt werden. Die neuen Defaultwerte werden allerdings erst nach
einem Neustart der Datenbank wirksam.
- PARTIAL: Ein Teil des Werts wird durch eine definierbare Zeichenkette ersetzt.
Weil der zu ersetzende Teil über eine Längenangabe (von ... bis) festgelegt
wird, sollte der zu redigierende Wert immer die gleiche Länge aufweisen. Liegt
diese Voraussetzung nicht vor, kann mit der Möglichkeit REGEXP (s.u.) gearbeitet
werden. Bei Characterwerten wird der für das Redigieren festgelegte Teil hier
durch einen festzulegenden Characterwert ersetzt und bei Zahlenwerten durch eine
Ziffer. Bei Datumswerten werden die einzelnen Komponenten (Tage, Monat, ...) durch
einen festzulegenden Tag, Monat, ... ersetzt.
- RANDOM: Der gesamte Wert wird durch einen Zufallswert ersetzt. Dabei werden
Characterwerte durch Strings in der 'Breite' der Datenbankspalte ersetzt,
Numberwerte durch eine Zahl, die in der Anzahl der Stellen identisch ist mit der
redigierten Zahl, und Datumswerte durch ein zufälliges Datum.
- REGEXP: Der Wert wird mit Hilfe einer Formatmaske (in Form eines regulären
Ausdrucks) durchsucht. Wird eine Zeichenkette gefunden, die der Formatmaske
entspricht, wird diese Zeichenkette durch einen definierbaren Wert ersetzt.
Bevor die Beispiele erläutert werden, noch einige wichtige Hinweise.
- Während viele Datentypen unterstützt werden, steht Data Redaction zur Zeit für
einige Datentypen NICHT zur Verfügung, zum Beispiel für Daten der Typen RAW, BLOB,
CLOB, XML Type und einige mehr.
- Bei geschachtelten Funktionen wird Data Redaction von innen nach aussen
angewendet, bei Inline Views umgekehrt von aussen nach innen.
- Objekte von SYS oder SYSTEM können nicht redigiert werden.
- Für die Benutzer SYS und SYSTEM werden die Policies zum Data Redaction NICHT
angewendet, denn beide verfügen über das System Privileg EXEMPT REDACTION POLICY.
SYSTEM kommt über das System Privileg EXP FULL DATABASE zu dieser Ausnahmeregelung,
denn EXEMPT REDACTION POLICY ist Teil dieses Export Privilegs. Das EXP FULL DATABASE
das Privileg benötigt, bedarf wohl keiner Erklärung.
- In den Ausführungsplänen ist die Veränderung der tatsächlichen Daten
nicht sichtbar.
Data Redaction: 3 Beispiele
Data Redaction wird im Enterprise Manager Cloud Control (siehe Abbildung) und im
SQL*Developer unterstützt.
Das ist zwar sehr komfortabel, fördert aber nicht das Verständnis. Deshalb zeigen
die Beispiele die Prozeduraufrufe, die ja letztendlich auch durch die graphischen
Oberflächen im Hintergrund erzeugt werden.
Das erste Beispiel zeigt, wie in der Tabelle SCOTT.EMP die Werte der Spalte
EMPNO mit der Funktion DBMS_REDACT.PARTIAL entsprechend den Angaben zum
Parameter FUNCTION_PARAMETER redigiert wird. Die Ziffer 9 ersetzt die
tatsächlichen Ziffern von der zweiten bis zur vierten Stelle. Der in
EXPRESSION verwendete Ausdruck veranlasst, dass das Redigieren für alle Benutzer
ausgeführt wird, ausser für den Benutzer 'KING'. Der Vergleich der beiden
Ausgaben zeigt, dass die Bedingung berücksichtigt wird. Will man das Redigieren
in jedem Fall ausführen, kann das durch die Expression '1 = 1' erreicht werden.
Das zweite Beispiel erweitert die bestehende Redaction Policy mithilfe der
Prozedur DBMS_REDACT.ALTER_POLICY. Das Verwenden von ALTER_POLICY ist nötig,
weil die bestehende Policy erhalten werden soll und mit einer Tabelle nur jeweils
eine einzige Redaction Policy verbunden werden kann. ALTER_POLICY kann ausser
zum Hinzufügen einer weiteren zu redigierenden Spalte dazu verwendet werden,
die Art des Redigierens oder die Parameter des Redigierens für eine Spalte zu
ändern, eine andere Bedingung für das Anwenden festzulegen oder das Redigieren
für eine Spalte auszuschalten.
Die Gehälter in der Spalte SAL werden, da als Funktionstyp FULL ohne weitere
Angaben vorgegeben ist, mit dem Wert 0 ausgegeben.
Im dritten und letzten Beispiel soll das Einstellungsdatum als Zufallswert ausgegeben
werden. Aus den oben genannten Gründen wird auch hier mit DBMS_REDACT.ALTER_POLICY
gearbeitet.
Wie nicht anders zu erwarten, sieht der Benutzer SCOTT für die Einstellungsdaten
zufällige Daten, während KING die korrekten Daten angezeigt erhält.
Weitere Informationen
Für das Monitoring des Data Redaction stehen einige Views zur Verfügung:
REDACTION_COLUMNS enthät Informationen zu den redigierten Spalten,
REDACTION_POLICIES Details zu den definierten Policies und
REDACTION_VALUES_FOR_TYPE_FULL die Werte, die bei einem vollständigen
Redigieren in den redigierten Spalten ausgegeben werden.
Die vollständigen Informationen zum Thema Data Redaction finden sich in den
entsprechenden Handbüchern und zwar in den Kapiteln der
Oracle Advanced Security Administrator Guides für die
Version 11
beziehungsweise für die
Version 12
sowie in den Kapiteln des Referenzhandbücher Oracle Database PL/SQL
Packages and Types Reference der
Version 11 oder der
Version 12. Die Unterschiede in der Funktionalität sind minimal und
beschränken sich auf den Umgang mit LOBs, wenn sie vollständig durch
Defaultwerte ersetzt werden.
Zurück zum Anfang des Artikels
Zurück zur Community-Seite
|