Oracle 12c - Das umfassende Handbuch

19.5

Oracle Data Redaction

465

19.5 Oracle Data Redaction

Datenbanken mit sensiblen Daten unterliegen einer Kontrolle, welcher Benutzer

welche Daten sehen darf oder auch nicht. Häufig gibt es mehrere Sicherheitsstu-

fen, was die Kontrolle erschwert und bisher häufig über die Applikation realisiert

wurde. Neben den produktiven Datenbanken werden häufig auch Testdatenban-

ken gepflegt, um zum Beispiel Performance-Tests und fachliche Abnahmen

durchzuführen. Dazu ist es meistens notwendig, mit dem produktiven Datenbe-

stand zu arbeiten. Eine Option, um die Sicherheit der Daten zu wahren, ist die

Anonymisierung. Für viele solcher oder ähnlicher Anforderungen gibt es nun eine

intelligente Lösung.

Oracle Data Redaction ist ein neues Feature in Oracle 12c. Daten können für gerin-

ger privilegierte Benutzer maskiert werden. Die Maskierung erfolgt in Echtzeit,

wenn die Daten selektiert werden. Damit muss keine aufwendige Zugriffskont-

rolle programmiert oder Daten anonymisiert werden. Data Redaction unterstützt

folgende Modi:

쐽 Full Data Redaction: Der gesamte Inhalt einer Spalte wird maskiert.

쐽 Partial Data Redaction: Es werden Teile des Datenfeldes maskiert.

쐽 Random Data Redaction: Es werden Zufallsdaten generiert und angezeigt.

쐽 Regular Expression: Verwendung von regulären Ausdrücken für die Maskie-

rung. Kann nur für Spalten vom Zeichentyp verwendet werden.

Die Implementierung ist relativ einfach:

쐽 Erstellen Sie eine Redaction Policy für eine Tabelle unter Verwendung des Pa-

ketes »DBMS_REDACT«.

쐽 Geben Sie der Policy eine Redaction Function mit.

Ob der tatsächliche Wert angezeigt wird oder die maskierte Ausgabe einer Spalte

erfolgt, ist abhängig von der vorgegebenen Policy. Die Maskierung erfolgt am

Ende der Ausgabe des Result Set an den Benutzer.

Im Beispiel in Listing 19.8 soll die Spalte »salary« für alle Benutzer maskiert wer-

den. Dies wird durch den Parameter »expression« festgelegt. Der Wert »1=1« ist

immer gültig, und somit erfolgt keine Einschränkung auf Benutzerebene.

Hinweis

Data Redaction ist Teil der Advanced Security-Option und muss somit zusätzlich

lizenziert werden.

Kapitel 19

Erweiterte Sicherheitsthemen

466

Ein voller Datenbankexport wird häufig aus Sicherheitsgründen durchgeführt.

Deshalb ist der Standard an dieser Stelle sinnvoll. Beachten Sie, dass die Aus-

nahme nicht automatisch greift. Führt der Benutzer »hr« einen Export seines eige-

nen Schemas durch, dann werden maskierte Daten exportiert und auch wieder

importiert.

Die Maskierung gilt im Beispiel auch für den Besitzer des Schemas. Obwohl er

alle Rechte an der Tabelle hat, kann er die wahren Inhalte der Spalte »salary« nicht

sehen.

Hinweis

Benutzer, die das Privileg »EXEMPT REDACTION POLICY« besitzen, sind

nicht von der Maskierung betroffen. Sie sehen stets die echten Werte. Dieses Pri-

vileg ist standardmäßig der Rolle »EXP_FULL_DATABASE« zugewiesen. Diese

wiederum ist Teil der Rolle »DBA«.

SQL> BEGIN

2 DBMS_REDACT.ADD_POLICY(object_schema=>'HR',

3 object_name=>'EMPLOYEES', column_name=>'SALARY',

4 policy_name=>'mask_salary',function_type=>DBMS_REDACT.FULL,

5 expression=>'1=1');

6 END;

7 /

PL/SQL-Prozedur erfolgreich abgeschlossen.

Listing 19.8: Eine Redaction Policy anlegen

Tipp

Data Redaction ist eine gute Möglichkeit, um Anonymisierung auf einem siche-

ren Weg durchzuführen. Erhält der exportierende Benutzer keine Ausnahme,

dann werden die Daten bereits maskiert in das Dumpfile geschrieben, und es

gibt keine Sicherheitslücke auf dem Weg zur Testdatenbank.

SQL> SELECT first_name,last_name,salary

2 FROM employees;

FIRST_NAME LAST_NAME SALARY

-------------------- ------------------------- ----------

Steven King 0

Neena Kochhar 0

Lex De Haan 0

. . .

Listing 19.9: Ausgabe mit Full Data Redaction auf der Spalte salary

19.5

Oracle Data Redaction

467

Was passiert, wenn die Spalte »salary« in der WHERE-Klausel verwendet wird?

Wie Sie wissen, erfolgt die Maskierung im letzten Schritt der Datenübergabe an

den Benutzer. Die Verarbeitung der SQL-Anweisung erfolgt vorher und berück-

sichtigt die Redaction Policy natürlich nicht, wie im Beispiel in Listing 19.10 zu

sehen ist.

Ist das nun eine Sicherheitslücke? Schließlich erhält der Benutzer den Wert auf

diese Art und Weise auf Umwegen.

Die Möglichkeit, eine Redaction Policy zu definieren, ist ein mächtiges Recht. Der

Benutzer hat schließlich die Möglichkeit, anderen Benutzern die Sicht auf Daten

zu entziehen. Es gehört deshalb besonders geschützt. Allerdings gibt es dafür kein

spezielles Privileg. Jeder, der das EXECUTE-Recht auf das Paket »DBMS_RE-

DACT« besitzt, darf eine solche Policy festlegen. Das sind standardmäßig nur

wenige.

SQL> SELECT first_name,last_name,salary

2 FROM employees WHERE salary = 3000;

FIRST_NAME LAST_NAME SALARY

-------------------- ------------------------- ----------

Kevin Feeney 0

Anthony Cabrio 0

Listing 19.10: Einfluss der Redaction Policy auf die WHERE-Klausel

Hinweis

Oracle Data Redaction ist keine umfassende Sicherheitslösung. Neben dem im

Beispiel gezeigten Vorgehen haben insbesondere privilegierte Benutzer die Mög-

lichkeit, die Maskierungen zu umgehen. Für Daten, die umfassend geschützt

werden müssen, ist eine Kombination mit weiteren, von Oracle angebotenen

Sicherheitsfeatures erforderlich. Dazu gehören unter anderem die Verschlüsse-

lung von Daten und »Oracle Data Vault«.

SQL> SELECT grantee FROM dba_tab_privs WHERE table_name = 'DBMS_REDACT';

GRANTEE

----------------------------------------------------------------------

IMP_FULL_DATABASE

EXECUTE_CATALOG_ROLE

SQL> SELECT grantee FROM dba_role_privs

2 WHERE granted_role IN ('EXECUTE_CATALOG_ROLE','IMP_FULL_DATABASE');

GRANTEE

-------------------------------------------------------------------------------

SYS

DBA

Listing 19.11: Benutzer mit Zugriff auf das Paket DBMS_REDACT