Logo Oracle Deutschland   DBA Community  -  September 2013
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.
  1. 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.
  2. Bei geschachtelten Funktionen wird Data Redaction von innen nach aussen angewendet, bei Inline Views umgekehrt von aussen nach innen.
  3. Objekte von SYS oder SYSTEM können nicht redigiert werden.
  4. 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.
  5. 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.

Unverschlüsselte Abfrage

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.

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'empno',
policy_name         => 'empno_redact',
function_type       =>  DBMS_REDACT.PARTIAL,
function_parameters => '9,2,4',
expression          => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'')<>''KING''');
END;
/

-- Als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB          MGR HIREDATE         SAL       COMM     DEPTNO
------ ---------- --------- ------ --------- ---------- ---------- ----------
  7999 KING       PRESIDENT        17-NOV-81       5000                    10
  7999 TURNER     SALESMAN    7698 08-SEP-81       1500          0         30
  7999 ADAMS      CLERK       7788 12-JAN-83       1100                    20
  7999 JAMES      CLERK       7698 03-DEC-81        950                    30
  7999 FORD       ANALYST     7566 03-DEC-81       3000                    20
  7999 MILLER     CLERK       7782 23-JAN-82       1300                    10

-- Als Benutzer KING (ist nicht automatisch angelegt)

SQL> SELECT * FROM scott.emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0     30
  7876 ADAMS      CLERK           7788 23-MAY-87       1100                20
  7900 JAMES      CLERK           7698 03-DEC-81        950                30
  7902 FORD       ANALYST         7566 03-DEC-81       3000                20
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10
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.
BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'sal',
policy_name         => 'empno_redact',
action              =>  DBMS_REDACT.ADD_COLUMN,
function_type       =>  DBMS_REDACT.FULL);
END;
/

-- Wieder als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7999 KING       PRESIDENT            17-NOV-81          0                10                       
  7999 TURNER     SALESMAN        7698 08-SEP-81          0          0     30
  7999 ADAMS      CLERK           7788 23-MAY-87          0                20
  7999 JAMES      CLERK           7698 03-DEC-81          0                30
  7999 FORD       ANALYST         7566 03-DEC-81          0                20
  7999 MILLER     CLERK           7782 23-JAN-82          0                10
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.
BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema       => 'scott',
object_name         => 'emp',
column_name         => 'hiredate',
policy_name         => 'empno_redact',
action              =>  DBMS_REDACT.ADD_COLUMN,
function_type       =>  DBMS_REDACT.RANDOM);
END;
/

-- Als Benutzer SCOTT

SQL> SELECT * FROM emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7999 KING       PRESIDENT            11-MAY-25          0                10
  7999 TURNER     SALESMAN        7698 14-DEC-11          0          0     30
  7999 ADAMS      CLERK           7788 17-APR-25          0                20
  7999 JAMES      CLERK           7698 14-DEC-83          0                30
  7999 FORD       ANALYST         7566 24-SEP-69          0                20
  7999 MILLER     CLERK           7782 09-AUG-12          0                10

-- Zur Kontrolle wieder als Benutzer KING

SQL> SELECT * FROM scott.emp WHERE empno > 7800;

 EMPNO ENAME      JOB              MGR HIREDATE         SAL       COMM DEPTNO
------ ---------- --------- ---------- --------- ---------- ---------- ------
  7839 KING       PRESIDENT            17-NOV-81       5000                10
  7844 TURNER     SALESMAN        7698 08-SEP-81       1500          0     30
  7876 ADAMS      CLERK           7788 23-MAY-87       1100                20
  7900 JAMES      CLERK           7698 03-DEC-81        950                30
  7902 FORD       ANALYST         7566 03-DEC-81       3000                20
  7934 MILLER     CLERK           7782 23-JAN-82       1300                10
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