Die Oracle Datenbank bietet je nach Anforderung verschiedene Möglichkeiten Daten zu anonymisieren. Dazu zählen:

• Virtual Private Database
• Data Redaction   
• Data Masking

Virtual Private Database (VPD)
Virtual Private Database ist ein Feature der Oracle Datenbank Enterprise Edition und seit Oracle 8i verfügbar. Es ermöglicht das Erstellen von Regeln, die den Datenbankzugriff auf Zeilen- und / oder Spaltenebene einschränken. VPD fügt den SQL Anweisungen, die auf eine Tabelle, View oder ein Synonym mit einer VPD Regel abgesetzt werden, eine dynamische WHERE-Klausel hinzu.

VPD kann verwendet werden, wenn die Standard-Objektberechtigungen und die zugehörigen Datenbankrollen nicht ausreichen, um die Sicherheitsanforderungen einer Anwendung zu erfüllen. VPD kann in Kombination mit der Applikations-Context Funktion genutzt werden, um anspruchsvolle Sicherheitsanforderungen auf Zeilen- und / oder Spaltenebene durchzusetzen. Ein einfaches Beispiel wäre, den VPD Zugriff auf Daten auf die Geschäftszeiten zu beschränken. Ein komplexeres Beispiel könnte den Applikations-Context über einen Logon Trigger ermitteln und so die Row-Level Security auf Tabellen Ebene erzwingen. Da die VPD Regeln direkt an die Tabellen geknüpft sind, können diese nicht umgangen werden, egal wie ein Benutzer auf die Tabellen zugreift (zum Beispiel über eine Applikation, SQL*Plus oder ein Web Interface). Wird auf eine sensible Spalte zugegriffen, schränkt Oracle VPD standardmäßig die Anzahl der zurückgegebenen Zeilen ein.

Beispiel: Der Account-Manager mit der ACCOUNT_MGR_ID=149 könnte alle Zeilen aus der Tabelle Kunden sehen, nicht aber CREDIT_LIMIT. Sobald die Spalte CREDIT_LIMIT abgefragt wird, werden nur die eigenen Kunden angezeigt:

Beim Column-Masking werden alle Zeilen angezeigt, die sensiblen Spalten werden jedoch mit NULL Werten maskiert.



Weitere Informationen zur Virtual Private Database im Community Tipp: Oracle Virtual Private Database

Oracle Data Redaction
Da es oftmals nicht ausreichend ist, Spalten nur mit NULL Werten zu redigieren, bietet Oracle mit dem Datenbank Release 12c Data Redaction an. Oracle Data Redaction ist Bestandteil der Oracle Advanced Security Option.

Oracle Data Redaction schützt vertrauliche Daten, die in Datenbankanwendungen angezeigt werden. Data Redaction ist hochtransparent für Anwendungsbenutzer, weil die ursprünglichen Datentypen und (optional) die Formatierung beibehalten werden. Es ist hochtransparent für die Datenbank, da die Daten im Buffer, Cache-und Storage gleich bleiben – sie werden erst verändert, wenn die SQL Abfrageergebnisse an den Benutzer zurückgegeben werden. Es kann definiert werden, welche Applikationsbenutzer redigierte Daten und welche Applikationsbenutzer Originaldaten sehen dürfen. Die Benutzerinformationen können über die SYS_CONTEXT Funktion in der Datenbank geprüft werden.

Im Gegensatz zu VPD, wo Spaltenwerte nur mit NULL redigiert werden können, bietet Data Redaction viele Möglichkeiten der Maskierung:

• Full Redaction
  Der komplette Inhalt der Spalte wird redigiert. Standardmäßig werden Number Datentypen mit 0, Zeichendatentypen mit Leerzeichen redigiert. Die Standards können mit der Prozedur DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES verändert werden. Siehe "Altering the Default Full Data Redaction Value"
• Partial Redaction
  Teile von Spalteninhalten werden redigiert. Zum Beispiel können alle Zeichen bis auf die letzten 4 Zeichen einer Kreditkartennummer mit Sternchen (*) redigiert werden.
• Regular Expressions
  Reguläre Ausdrücke können sowohl in Full- als auch in Partial Redaction verwendet werden. Daten können basierend auf einem Suchmuster redigiert werden. So können zum Beispiel reguläre Ausdrücke verwendet werden, um bestimmte Telefonnummern oder Email-Adressen zu redigieren.
  Weitere Informationen zum Thema siehe Using Regular Expressions in Database Applications"
• Random Redaction
  Die angezeigten Daten werden bei jedem Zugriff zufällig generiert.
• No Redaction
  No redaction dient zum Testen von internen Operationen der Redaction Regeln, ohne Auswirkung auf die Ergebnisse der Abfragen auf die Tabellen für die Redaction Regeln erstellt wurden.

Für das Erstellen von Redaction Regeln ist das Execute Recht für das DBMS_REDACT PL/SQL Package erforderlich.
Redaction Regeln können mittels Kommandozeile mit DBMS_REDACT.ADD_POLICY und DBMS_REDACT.ALTER_POLICY erstellt und verändert werden. Enterprise Manager 12c Cloud Control bietet hierfür eine graphische Oberfläche an.

Beispiel:
Für die Tabelle HR_REDACT.SAMPLE_EMAILS soll mit Oracle Enterprise Manager 12c Cloud Control eine Redaction Regel erstellt werden, die alle Email Adressen in der Spalte MAIL VARCHAR2(4000) mit „nobody“ redigiert:

Die Redaction Policy soll nur gelten, wenn der User SCOTT auf die Tabelle HR_REDACT.SAMPLE_EMAILS zugreift.

Der angegebene reguläre Ausdruck sucht nach Email Adressen und ersetzt diese mit „nobody“.

Mit Show SQL sieht man das SQL Statement:


Die Redaction Regel wurde erstellt:

Mit dem Tool SQL*Developer wird der Inhalt der Spalte MAIL angezeigt:

2. wenn der User SCOTT diese selektiert

Data Redaction funktioniert auch für Spalten mit dem Datentyp VARCHAR2(32k), der mit dem Oracle Datenbank Release 12c (MAX_STRING_SIZE=EXTENDED) unterstützt wird.

Folgende Data Dictionary Views geben Auskunft über Data Redaction Regeln:

• REDACTION_COLUMNS
• REDACTION_POLICIES
• REDACTION_VALUES_FOR_TYPE_FULL

Die User SYS und SYSTEM besitzen das EXEMPT REDACTION POLICY Privileg und können damit alle Data Redaction Regeln umgehen. Sie können die Originaldaten aller Tabellen und Views sehen, für die Data Redation Regeln definiert wurden.

Oracle Data Redaction Regeln gelten für alle Zieltabellen oder -views und alle Views, die auf diesem Ziel erstellt werden. Wenn Sie eine View Kette (das heisst, eine View basierend auf einer anderen View) erstellen, dann gilt die Data Redaktion Regel auch in dieser View Kette. Siehe hierzu How Oracle Data Redaction Policies Affect Tables and Views

Der Schwerpunkt von Data Redaction liegt im Redigieren von Daten in Produktionsumgebungen. Data Redaction kann aber auch in Kombination mit Oracle Enterprise Manager Data Masking and Subsetting Pack für den Schutz sensibler Daten in Test- und Entwicklungsumgebungen verwendet werden.

Oracle Data Masking and Subsetting
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.

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 und hat somit Informationen über Abhängigkeiten von Spalten. Dies stellt eine konsistente Maskierung der sensiblen Spalten und aller abhängigen Spalten sicher.

Data Masking bietet eine Vielzahl an Maskierungformaten an. Dazu zählen

• Array List
• Encrypt
• Fixed Number
• Fixed String
• Post-Processing Function
• Random Dates
• Random Decimal numbers
• Random Strings
• Regular Expression
• Shuffle
• Substitute
• SQL Expression
• User Defined Function

Eine komplette Liste und ausführliche Beschreibung der Maskierungsformate kann hier nachgelesen werden: Providing a Masking Format to Define a Column
Eine Auflistung der unterstützen Datentypen finden Sie hier: Supported Data Types

Oracle liefert out-of-the-box folgende vordefinierte Maskierungsformate aus:

• Credit Card Numbers
• United States Social Security Numbers
• ISBN Numbers
• UPC Numbers
• Canadian Social Insurance Numbers
• North American Phone Numbers
• UK National Insurance Numbers
• Auto Mask

Im nachfolgenden Beispiel soll die Tabelle MAILS für eine Testumgebung anonymisiert werden. Hierzu soll die Spalte MAIL mit einem regulären Ausdruck analog zum Beispiel für Data Redaction anonymisiert werden.

Die Originaldaten der Spalte MAIL für den Datensatz mit der EMPLOYEE_ID=100 sehen wie folgt aus:

Im ersten Schritt wurde ein Application Data Model erstellt. Hier wurden alle Spalten der Tabelle MAILS als „Sensitive Columns“ deklariert. Nur diese können später beim Data Masking anonymisiert werden. In diesem Beispiel gibt es keine Abhängigkeiten zu anderen Tabellen.

Als nächstes wird die Data Masking Definition erstellt:

Nun werden die zu maskierenden Spalten hinzugefügt und die Maskierungsformate festgelegt:

Für die Spalte LAST_NAME wird das Maskierungsformat „Shuffle“ verwendet. Dies bewirkt, dass alle Werte der Spalte erhalten bleiben, jedoch untereinander vertauscht werden: 

Auf dem nächsten Bild ist das Maskierungsformat Shuffle für die Spalte LAST_NAME ausgewählt. Mit Grouping Columns könnte zum Beispiel ein Shuffle von LAST_NAME innerhalb einer Abteilung durchgeführt werden. Ist hier nichts angegeben, wird das Shuffle über die komplette Tabelle durchgeführt. Sample zeigt das Ergebnis der Maskierung für die Spalte einer beliebigen Zeile an.

Im nächsten Schritt definieren wir das Maskierungsformat für die Spalte MAIL:

Der reguläre Ausdruck [a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+ sucht nach Email Adressen in der Spalte MAIL und ersetzt diese mit „nobody“.

Nun wird das Skript für die Maskierung der Daten generiert:

Beim Generieren des Skriptes muss angeben werden, ob ein „In-Place Masking“ oder „At-Source Masking“ gemacht werden soll. Beim In-Place Masking wird die angegebene Datenbank (normalerweise Kopie der Produktion) maskiert, indem sensible Daten In-Place durch maskierte Daten ersetzt werden. At-Source Masking exportiert maskierte Daten aus der angegebenen Quelldatenbank (normalerweise Produktion) mit Oracle Data Pump. Die Daten werden jedoch erst beim Export maskiert, so dass die Daten in der Produktionsdatenbank unverändert bleiben.

Nun muss das generierte Skript nur noch ausgeführt werden:

Beim In-Place Masking muss bestätigt werden, dass es sich nicht um eine Produktionsdatenbank handelt.

Nach erfolgreicher Maskierung sieht der Inhalt der Tabelle wie folgt aus:

Die Spalte LAST_NAME wurde sozusagen durcheinander gewürfelt. Die Email Adressen in der Spalte MAIL wurden durch „nobody“ ersetzt. Wie man hier sehr schön erkennen kann, ist ein Rückschluss auf den Nachnamen durch die EMAIL möglich. Beim Masking von sensiblen Daten muss also darauf geachtet werden, dass solche Rückschlüsse nicht mehr möglich sind.

Zurück zur Community-Seite