Blog Name
  • Februar 2019
Freitag, 15.02.2019

Sensible Daten in Trace Files und Audit-Trails

Nicht erst seit Inkrafttreten der EU-Datenschutzgrundverordnung (EU-DSGVO) gibt es die Anforderung, sensible Daten aus den Oracle Trace Files und aus den Audit Trails zu entfernen. Im Konkreten handelt es sich dabei um sensible Daten, welche bei der Verwendung von sogenannten Bind-Variablen gegebenenfalls mit in Trace Files geschrieben werden. Das Gleiche gilt auch für den Oracle Audit-Trail.

Bind-Variablen

Bind-Variablen sind zur performanten Ausführung von SQL-Statements im Prinzip unerlässlich. Sie ermöglichen der Datenbank die wiederholte Verwendung eines SQL-Statements, welche sich nur durch die Eingabewerte (Variablen) unterscheiden. Die Nutzung von Bind-Variablen als Eingabewerte für SQL-Statements verhindert dabei das erneute Parsen des SQL-Statements und spart somit enorm viel Zeit bei der Ausführung syntaktisch gleicher SQL-Statements. Hinweise zum Thema Bind-Variablen finden Sie hier.

Das Problem

Wie so oft ist leider das was gut für die Performanz ist, ungünstig für das Thema Sicherheit. In diesem Fall handelt es sich um die Verwendung von Bind-Variablen. Sie tauchen als Klartext in den Trace Files und im Datenbank Audit-Trail auf. Kritisch wird es, wenn die Trace Files bei einem Problem nach Extern gesendet werden müssen, wie zum Beispiel zum Oracle Support. Ein weiteres Risiko entsteht bei hochsensiblen Datenbanken, bei denen vielleicht bereits Sicherheitsmaßnahmen implementiert wurden, um technisch privilegierten Benutzern wie z.B. Datenbankadministratoren keinen Einblick in die Daten zu ermöglichen. Hier wäre es also durchaus möglich, sensible Daten mittels Trace Files beziehungsweise Audit-Trails auszuspähen. Da hilft dann auch keine Verschlüsselung und kein Database Vault mehr.

Die Lösung: Transparent Sensitive Data Protection

Ob Bind-Variablen in Trace Files oder Audit-Trails sichtbar sind oder nicht, lässt sich steuern. Das Feature dazu heißt Transparent Sensitive Data Protection (TSDP) und wurde mit der Oracle Datenbank 12c eingeführt.

Transparent Sensitive Data Protection dient in erster Linie dazu, sensitive Tabellenspalten zu organisieren, um sie im Nachgang gebündelt verwalten zu können. Dabei werden alle sensitiven Tabellenspalten einer Datenbank unterschiedlichen Kategorien – sogenannten Sensitive Data Types – zugeordnet. Das Erstellen der Kategorien und das Zuordnen der sensitiven Tabellenspalten wird durch das PL/SQL-Package - DBMS_TSDP_MANAGE - durchgeführt. Bei der Suche nach sensitiven Tabellenspalten kann das Oracle Database Security Assessment Tool oder das Sensitive Data Discovery im Oracle Cloud Control (Lizenz erforderlich) helfen.

Nachdem alle sensiblen Tabellenspalten den Kategorien zugeordnet wurden, wird mittels des PL/SQL-Packages - DBMS_TSDP_PROTECT - die eigentliche Schutzmaßnahme entsprechend der Kategorien konfiguriert. Hier wird der Vorteil schnell sichtbar. Mit DBMS_TSDP_PROTECT lassen sich Datenbank-Sicherheits-Feature global auf Basis der Kategorien -Sensitive Data Types- steuern.

    Darunter fallen Oracle Datenbank Sicherheits-Feature wie:
  • Data Redaction
  • Virtual Private Database
  • Unified Auditing
  • Fine Grained Auditing
  • Column Encryption

Dazu werden über eine sogenannte TSDP-Policy die Eigenschaften des entsprechenden Sicherheits-Features konfiguriert. Hier exemplarisch am Beispiel einer TSDP-Policy für Data Redaction:

DECLARE

  redact_feature_options DBMS_TSDP_PROTECT.FEATURE_OPTIONS;
  policy_conditions DBMS_TSDP_PROTECT.POLICY_CONDITIONS;

BEGIN

  redact_feature_options ('expression')           := 'SYS_CONTEXT(''USERENV'',''SESSION_USER'')=''APPUSER''';
  redact_feature_options ('function_type')        := 'DBMS_REDACT.PARTIAL';
  redact_feature_options ('function_parameters')  := 'STR, VVVVVVVVV,VVVVVVVVV,*,1,6';
  
  policy_conditions(DBMS_TSDP_PROTECT.DATATYPE)   := 'VARCHAR2';

  DBMS_TSDP_PROTECT.ADD_POLICY ('PARTIAL_MASK_POLICY',  DBMS_TSDP_PROTECT.REDACT, redact_feature_options, policy_conditions);

END;

Nachdem die TSDP-Policy erstellt wurde, muss sie nur noch einer Kategorie zugeordnet und aktiviert werden. Die hierüber eingestellte Schutzmaßnahme gilt dann für alle Tabellenspalten einer Kategorie. Bei der Verwendung anderer Datenbank Sicherheits-Feature variieren die einzustellenden Feature-Options entsprechend. Schlussendlich werden die Kategorien mittels der Methode ASSOCIATE_POLICY aus dem DBMS_TSDP_PROTECT Package der TSDP-Policy zugeordnet.

BEGIN 
dbms_tsdp_protect.associate_policy(policy_name => 'PARTIAL_MASK_POLICY ', sensitive_type => 'EMAIL');
END;

Es existiert allerdings eine Standard TSDP-Policy mit dem Namen REDACT_AUDIT. Diese Policy ist immer vorhanden und kann nicht entfernt werden. Lediglich das Aktivieren beziehungsweise das Deaktivieren ist möglich. Sie dient zur Maskierung von Bind-Variablen in Trace Files und Audit-Trails. Dabei werden die Werte der Bind-Variablen durch einen Asterisk (*) ausgetauscht.

Beispiel: Maskierung von Bind-Variablen

Im folgenden Beispiel wird die genaue Vorgehensweise erläutert.

Ausgangssituation ist die Kenntnis darüber, in welchen Tabellenspalten sensitive Daten enthalten sind. Der Sensitive Data Discovery-Report des Database Security Assessment Tools liefert hierfür alle notwendigen Informationen. Weiterführende Hinweise dazu hier.

Der Report zeigt, dass die Tabelle EMPLOYEES im Schema HCMDATA gespeichert ist und neben vielen anderen sensitiven Daten, auch eine Spalte mit E-Mail-Adressen beinhaltet.

Aber bevor wir mit den Schutzmaßnahmen beginnen, schauen wir uns das eigentliche Problem genauer an.

Dafür melden wir uns mit einem Datenbankbenutzer an, der Select-Rechte auf die Tabelle HCMDATA.EMOPLYEES besitzt. Damit wir hier ein Session-Tracing forcieren können, verwenden wir den Benutzer SYSTEM.

Das Select-Statement, welches wir verwenden, nutzt in der Bedingung eine Bind-Variable. Diese muss vorab deklariert und gesetzt werden.

var email varchar2(40)
exec :email := 'WTAYLOR@ORACLE.COM';

PL/SQL procedure successfully completed.

Jetzt aktivieren wir das Session-Tracing mittels des DBMS_MONITOR Packages. Dabei schalten wir die Erfassung der Bind-Variablen im Trace File explizit ein.

exec dbms_monitor.session_trace_enable(waits => FALSE, binds => TRUE); 

PL/SQL procedure successfully completed.

Nun führen wir das eigentliche Select-Statement aus.

SELECT EMAIL FROM HCMDATA.EMPLOYEES WHERE EMAIL=:email;

EMAIL
-------------------------
WTAYLOR@ORACLE.COM

Um zu sehen welches Trace File erstellt wurde, führen wir folgendes Statement aus.

SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';

VALUE
--------------------------------------------------------------------------------------------------------------------------------------------------------------
/u01/oracle/db/diag/rdbms/cdb1/cdb1/trace/cdb1_ora_2477.trc

Nun schauen wir nach, welche Informationen dort gespeichert sind. Das muss auf dem Datenbank-Server durchgeführt werden.

Einfach mit dem VI nach value="WTAYLOR@ORACLE.COM" suchen (Beispiel: /value=\"WTAYLOR).

vi /u01/oracle/db/diag/rdbms/cdb1/cdb1/trace/cdb1_ora_2477.trc

--------------
PARSING IN CURSOR #139714235942448 len=54 dep=0 uid=121 oct=3 lid=121 tim=40539217914 hv=286018727 ad='789b5bf8' sqlid='40kxbac8hsm57'
select email from hcmdata.employees where email=:email
END OF STMT
PARSE #139714235942448:c=0,e=221,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=40539217913
BINDS #139714235942448:

 Bind#0
  oacdty=01 mxl=128(120) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1000000 frm=01 csi=873 siz=128 off=0
  kxsbbbfp=7f11c1574c40  bln=128  avl=18  flg=05
  value="WTAYLOR@ORACLE.COM"
--------------

Wie zu vermuten war, ist der Wert der Bind-Variable im Klartext zu finden. Wurde für diese Tabelle zuvor ein Unified Auditing auf SELECT Statements eingeschaltet, findet sich die Bind-Variablen ebenfalls im Audit-Trail.

set linesize window
col OBJECT_NAME format a15
col OBJECT_SCHEMA format a15
col SQL_BINDS format a30
col EVENT_TIMESTAMP format a30
col SQL_TEXT format a60

select EVENT_TIMESTAMP,OBJECT_NAME,OBJECT_SCHEMA,SQL_BINDS,SQL_TEXT from unified_audit_trail where OBJECT_SCHEMA='HCMDATA' Order by EVENT_TIMESTAMP;

EVENT_TIMESTAMP 	       OBJECT_NAME     OBJECT_SCHEMA   SQL_BINDS		      SQL_TEXT
------------------------------ --------------- --------------- ------------------------------ ------------------------------------------------------------
11-FEB-19 02.53.49.668017 PM   EMPLOYEES       HCMDATA		#1(18):WTAYLOR@ORACLE.COM     select email from hcmdata.employees where email=:email

Nun beginnen wir mit der Einrichtung der Schutzmaßnahme. Zunächst wird eine Sensitive-Data-Type Kategorie für die E-Mail-Adresse erstellt. Dies wird mittels der Prozedur ADD_SENSITIVE_TYPE des DBMS_TSDP_MANAGE Packages durchgeführt.

Der Datenbankbenutzer, der die jetzt folgenden Aktivitäten ausführt, muss Execute-Rechte auf die Packages DBMS_TSDP_MANAGE und DBMS_TSDP_PROTECT haben. Bei Verwendung anderer Datenbank-Sicherheits-Feature mit TSDP werden gegebenenfalls Execute-Rechte auf die Packages DBMS_REDACT für Data Redaction und DBMS_RLS für Virtual Private Database benötigt.

BEGIN
 DBMS_TSDP_MANAGE.ADD_SENSITIVE_TYPE (
  sensitive_type  => 'Email_Adresses',
  user_comment    => 'Kategorie fuer E-Mail Adressen');
END;
/

Als nächstes weisen wir die Tabellenspalte HCMDATA.EMPLOYEES.EMAIL der gerade erstellten Kategorie zu.

BEGIN
 DBMS_TSDP_MANAGE.ADD_SENSITIVE_COLUMN(
 schema_name        => 'HCMDATA',
 table_name         => 'EMPLOYEES',
 column_name        => 'EMAIL',
 sensitive_type     => 'Email_Adresses',
 user_comment       => 'GDPR Relevant Data: Email-Adress');
END;
/

Mit den Views DBA_SENSITIVE_DATA und DBA_SENSITIVE_COLUMN_TYPES lässt sich überprüfen, ob auch alles funktioniert hat.

col SENSITIVE_TYPE format a35
col POLICY_NAME format a25
col SCHEMA_NAME format a25
col TABLE_NAME format a25
col NAME format a35
col COLUMN_NAME format a25
col USER_COMMENT format a100
set linesize window

select NAME,USER_COMMENT from DBA_SENSITIVE_COLUMN_TYPES;

NAME				    USER_COMMENT
----------------------------------- ----------------------------------------------------------------------------------------------------
Email_Adresses			    Kategorie fuer E-Mail Adressen

select SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, SENSITIVE_TYPE from DBA_SENSITIVE_DATA;

SCHEMA_NAME		  TABLE_NAME		    COLUMN_NAME 	      SENSITIVE_TYPE
------------------------- ------------------------- ------------------------- -----------------------------------
HCMDATA 		  EMPLOYEES		    EMAIL		      Email_Adresses

Wie bereits erwähnt, werden alle angelegten Kategorien - Sensitive Data Types – automatisch der Standard TSDP-Policy REDACT_AUDIT zugeordnet. Hierfür sind keine Benutzeraktionen notwendig. Dies lässt sich durch Abfrage der View DBA_TSDP_POLICY_TYPE überprüfen.

select POLICY_NAME, SENSITIVE_TYPE  from DBA_TSDP_POLICY_TYPE;

POLICY_NAME		  SENSITIVE_TYPE
------------------------- -----------------------------------
REDACT_AUDIT		  Email_Adresses

Damit jetzt alle Tabellenspalten, bei Verwendung von Bind-Variablen, der Kategorie Email_Adresses in den Trace Files und in den Audit Trails maskiert werden, muss nur noch die Schutzmaßnahme mittels des Packages DBMS_TSDP_PROTECT aktiviert werden.

BEGIN
 DBMS_TSDP_PROTECT.ENABLE_PROTECTION_TYPE (
  sensitive_type  => 'Email_Adresses' );
END;
/

Damit wäre diese Schutzmaßnahme aktiviert und wir können überprüfen, ob sie funktioniert. Dazu gehen wir wie bereits bei der eben durchgeführten Überprüfung vor. Um zu verhindern, dass wir in dasselbe Trace File wie eben schreiben, melden wir uns einmal von der Datenbank ab, und wieder an. Danach führen wir die Schritte durch.

var email varchar2(40)
exec :email := 'WTAYLOR@ORACLE.COM';

PL/SQL procedure successfully completed.

Jetzt aktivieren wir das Session-Tracing mittels des DBMS_MONITOR Packages. Dabei schalten wir die Erfassung der Bind-Variablen im Trace-File explizit ein.

exec dbms_monitor.session_trace_enable(waits => FALSE, binds => TRUE); 

PL/SQL procedure successfully completed.

Nun führen wir das eigentliche Select-Statement aus.

SELECT EMAIL FROM HCMDATA.EMPLOYEES WHERE EMAIL=:email;

EMAIL
-------------------------
WTAYLOR@ORACLE.COM

Um zu sehen welches Trace-File erstellt wurde, führen wir folgendes Statement aus.

SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';

VALUE
--------------------------------------------------------------------------------
/u01/oracle/db/diag/rdbms/cdb1/cdb1/trace/cdb1_ora_10909.trc

Nun schauen wir wieder nach, ob die Sicherheitsmaßnahme gegriffen hat. Jetzt sollte keine Bind-Variable mit dem Wert ="WTAYLOR@ORACLE.COM" mehr zu finden sein. Das muss auf dem Datenbank-Server durchgeführt werden. Einfach mit dem VI nach value="WTAYLOR@ORACLE.COM" suchen (Beispiel: /value=\"WTAYLOR ). Oder eine Positiv-Suche mit value=* (Beispiel /value=\*).

vi /u01/oracle/db/diag/rdbms/cdb1/cdb1/trace/cdb1_ora_10909.trc

--------------
PARSING IN CURSOR #139714235942448 len=54 dep=0 uid=121 oct=3 lid=121 tim=40531698835 hv=286018727 ad='789b5bf8' sqlid='40kxbac8hsm57'
select email from hcmdata.employees where email=:email
END OF STMT
PARSE #139714235942448:c=236,e=236,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=40531698834
BINDS #139714235942448:

 Bind#0
  oacdty=01 mxl=128(120) mxlc=00 mal=00 scl=00 pre=00
  oacflg=03 fl2=1000000 frm=01 csi=873 siz=128 off=0
  kxsbbbfp=7f11c1574c40  bln=128  avl=18  flg=05
  value=*
--------------

Falls das Auditing eingeschaltet war, sind die Bind-Variablen für die entsprechenden Tabellenspalten auch hier maskiert (2. Eintrag).

set linesize window
col OBJECT_NAME format a15
col OBJECT_SCHEMA format a15
col SQL_BINDS format a30
col EVENT_TIMESTAMP format a30
col SQL_TEXT format a60

select EVENT_TIMESTAMP,OBJECT_NAME,OBJECT_SCHEMA,SQL_BINDS,SQL_TEXT from unified_audit_trail where OBJECT_SCHEMA='HCMDATA' Order by EVENT_TIMESTAMP;

EVENT_TIMESTAMP 	       OBJECT_NAME     OBJECT_SCHEMA   SQL_BINDS		      SQL_TEXT
------------------------------ --------------- --------------- ------------------------------ ------------------------------------------------------------
11-FEB-19 02.53.49.668017 PM   EMPLOYEES       HCMDATA		#1(18):WTAYLOR@ORACLE.COM     select email from hcmdata.employees where email=:email
11-FEB-19 02.56.01.250842 PM   EMPLOYEES       HCMDATA		#1(1):* 		      select email from hcmdata.employees where email=:email

Fazit

Transparent Sensitive Data Protection ist ein einfach einzusetzendes Datenbank Sicherheits-Feature. Neben der Maskierung von sensiblen Daten in Trace Files und Audit Trails, unterstützt es bei der zentralen Umsetzung von Sicherheitsmaßnahmen wie zum Beispiel bei Unified Auditing, Daten-Zugriffsmanagement und Data Redaction. Alles was für den korrekten Einsatz notwendig ist, ist das Wissen darüber, in welchen Tabellen sensible Daten gespeichert sind. Hierbei kann der Sensitive Data Discovery-Report des Database Security Assessment Tools helfen.

Lizenzhinweis

Transparent Sensitive Data Protection ist ein Feature der Oracle Database Enterprise Edition.

 
Verfügbarkeit und Download

Weitere Informationen

 

Zurück zur Community-Seite
 

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services