Data Redaction live

Oracle Data Redaction in einem produktiven Datenbanksystem Projektbericht Oracle Data Redaction in einem produktiven Datenbanksystem Tobias Bräutigam – Security, Netzwerk & Oracle Mike Schliephorst – Java EE & Oracle Entwicklung

Agenda Von der Vision zum Wirkbetrieb Typische Herausforderungen Überraschende Lösungen Implementierung von Data Redaction in einem Produktiv-System

Anforderungen Mandantenfähigkeit und Datenmaskierung für Nearshore- Nutzer Sensible Daten dürfen die Datenbank nicht verlassen Katalogisierung sensibler Daten Keine Änderung an bestehender Geschäftslogik und der Prozesse Buzzwort: Data Leakage Prevention

ANFORDERUNGEN - Zielsystem

Bestands-system Drei physikalische Oracle 12c EE Datenbankserver Microsoft ASP-Frontend mit IIS ˜ 900 Prozeduren ˜ 250 Datenbankpackages ˜ 500.000 PL/SQL LOC

Proof of Concept Beistellung der Test- und Entwicklungsumgebung Drei Oracle 12c EE Instanzen Mit Testdaten betankt Vollzugriff für Entwickler (System: root, DB: sysdba)

Proof of Concept System- und Code-Analyse Semantik der Schnittstellen? Katalog der sensiblen Kundendaten semantische Analyse Typanalyse Score-basiert Code-Analyse CRUD-Matrix (TOAD) Zirkelbezüge Bulk Operation wie INSERT AS SELECT Maskierte Daten in GROUP BY-Klausel Aggregate Functions Views Lösung für direkten SQL-Zugriff?

Proof of Concept Analyse der Webapplikation Seiteneffekte wie unbeabsichtigtes Schreiben maskierter Inhalte? Logische Konsistenz von Daten und Prozessen Werden maskierte Spalten als Schlüssel verwendet? Ist Pseudonymisierung statt Maskierung erforderlich? Performance: Ausführungspläne, Speicher, Latenzen

Proof Of ConcEpt Implementierung eines Use Cases Ein Anwendungsfall, wenige Frontend-Seiten Nur Lesezugriffe Funktionsfähiger Prototyp Präsentation des Lösungskonzeptes beim Kunden

Oracle Data Redaction Geeignet zur Anpassung von Applikationen ohne direkten DB-Zugriff für den Anwender Definition zu maskierender Daten über das Oracle Data Dictionary Oracle Advanced Security: ab 11gR2 EE Transparenz für Backup- und Export-Funktionen Ausführung im Datenbankkernel zur Laufzeit Änderung mit 12c evtl. nur auf 12c eingehen. Oracle Advanced Security beinhaltet Transparent Data Encryption zur verschlüsselten Ablage und Data Redaction zum Maskieren Sensitiver Daten.

Oracle Data Redaction Deklaration der Policies im Data Dictionary der DB Aktivierung der Policies z.B. durch Kontext, User Environment, Rollen Maskieren sensitiver Daten in Tables und Views Unterstützte Datentypen VARCHAR, CHAR, NUMBER, DATE, CLOB Spezielle Typen teilweise Default-Maskierung für Full Redaction anpassen Full 30.06.1975   01.01.2001 Partial 123-456-789 xxx-xxx-789 Regex gandalf@syntegris.de [hidden]@syntegris.de Random "geheim" "6zt5%a"

DEMO 1 – Create POLICY BEGIN DBMS_REDACT.ADD_POLICY ( object_schema => 'SCOTT', object_name => 'EMP', policy_name => 'HIDE_SAL', column_name => 'SAL', function_type => DBMS_REDACT.FULL, expression => '1=1', enable => TRUE ); END; /

DEMO 1 – iterative Inferenz CREATE OR REPLACE PROCEDURE inferenz IS buf VARCHAR(40); t CHAR; x NUMBER; i NUMBER; c NUMBER; BEGIN i := 0; c := 1; WHILE c<17 LOOP SELECT COUNT(*) INTO x FROM scott.redactiontest WHERE SUBSTR(cc,c,1)= TO_CHAR(i); IF x > 0 THEN c := c+1; buf := buf||TO_CHAR(i); i := 0; ELSE i := i+1; END IF ; END LOOP; dbms_output.put_line('CC: ' || buf); END; --Credits to David Lichfield Achten Sie auf den aktuellen Patchlevel!

SICHERHEIT Verständnis der Grundkonzepte Datenlecks durch Inferenz Geeignet für auf Oracle aufsetzende Applikationen Zusätzliche Maßnahmen bei anderen Szenarien Redaction Policies per default deaktiviert für die User SYS SYSTEM EXPORT Privileg: EXEMPT REDACTION POLICY - nicht für Attacken bon DB-Usern welche ad hoc queries ausführen - nicht für user mit sysdba rights - DDL statements to copy data wie create table as secect, insert as select keine Verwendung in group by klauseln ORA-00979 Adhoc-Database Queries may bypass redaction ORA-28081

SICHERHEIT - Bug or Feature Problem: INSERT INTO table2 (col1, col2) SELECT col1, redact_col2 FROM table1; --> ORA-28081 Umgehung (Bug!): INSERT INTO table2(col1, SELECT redact_col2 FROM table1 t1a WHERE t1a.rowid = t1b.rowid) select col1 FROM table1 t1b; Lösung: Auslagerung von Code in Wrapper mit EXEMPT REDACTION POLICY und in neuem Schema BYPASS ORA-28081 tritt auch auf, wenn ein User, für den die Policy nicht gilt, ein INSERT AS SELECT auf redaktionierte Spalten absetzt http://www.oracle.com/technetwork/database/options/advanced-security/advanced-security-wp-12c-1896139.pdf https://docs.oracle.com/database/121/ASOAG/redaction_guidelines.htm#ASOAG10535 insert into table2 (col1, select redact_col2 from table1 t1a where t1a.rowid = t1b.rowid) select col1 from table1 t1b; Lösung implementierung eines BYPASS-Schemas mit Exempt Redactation Policy und Ausführung der "Insert As select" Statements für alle betroffenen Schemas

Sicherheit – Grenzen Kein Schreibschutz Bei komplexem Code nicht unmittelbar einsetzbar Z.B. dynamisches SQL aka EXECUTE IMMEDIATE() Als eigenständiges Sicherheitskonzept ungenügend Kein Schutz gegen fortgeschrittene Angriffe Privilege Escalation SQL Injection Brute Force

Lösung - Technologien Oracle Data Redaction Datenmaskierung Queries RLS Row Level Security Schreibzugriffe erkennen INSERT/UPDATE/DELETE Statements FGA Fine grained auditing Statements detailliert loggen Analyse, Debugging

Lösung - Row Level Security Problem: Komplexe Geschäftslogik in verketteten Stored Procedures kann unbeabsichtigtes Schreiben maskierter Werte auslösen. Lösung: RLS unterbindet Schreibzugriff auf redaktionierte Spalten selektiv Fängt fehlerhafte Validierung im Frontend ab Vermeidung vollständiger Codeanalyse

Lösung - KOMPONENTEN

LÖSUNG - Vorteile Datenmodell bleibt unverändert Trennung von Implementierung und Metadaten Zentrale Speicherung von SCD-Katalog, Berechtigungen, Redaktionstyp Einheitliche Pflege der Objekte für Frontend- und SQL- Zugriff Der User FACADE_ADMIN generiert Views, Synonyme, Grants, Redaction- und RLS- Policies

LÖSUNG - Fassadenarchitektur FACADE_ADMIN

LÖSUNG - Frontend Nearshore-User werden über ihre Windows-Gruppe identifiziert Für die Nearshore-AD-Gruppe wird ein eigener Connection Pool verwendet, dadurch sind die OO4O* Caches für Onsite- und Nearshore-Benutzer getrennt Separate technische Datenbank-User pro Pool Für das entsprechende Schema FACADE_WEB ist die Maskierung aktiv: … expression =>'SYS_CONTEXT (''USERENV'',''SESSION_USER'')= ''FACADE_WEB''‚ … *Oracle Objects for OLE

Flashback Sicherung der gesamten Datenbank in Sekunden mit CREATE RESTORE POINT GUARANTEE FLASHBACK DATABASE Delta der gesamten Datenbank mit der SELECT AS OF clause Überraschung: die Flashback Restore Points mit unserer Testdaten-Baseline überlebten ein Datenbank-Patchupdate nicht

FLASHBACK Beispiel SET serveroutput ON; DECLARE cnt pls_integer; rowcnt pls_integer; sqlstring VARCHAR2(2000); fails pls_integer :=0; BEGIN FOR TAB IN ( SELECT SYS.DBA_ALL_TABLES.TABLE_NAME AS TNAME, SYS.DBA_ALL_TABLES.OWNER AS TOWNER FROM SYS.DBA_ALL_TABLES WHERE OWNER IN 'HR‘‚ LOOP BEGIN sqlstring:='SELECT count(*) FROM '||TAB.TOWNER||'.'||TAB.TNAME; EXECUTE IMMEDIATE sqlstring INTO rowcnt; dbms_output.put_line('ROW COUNT: '||rowcnt||' Name: '|| TAB.TOWNER||'.'||TAB.TNAME); IF rowcnt<500000 THEN sqlstring := 'SELECT COUNT(*) FROM (SELECT * FROM ' ||TAB.TOWNER||'.'||TAB.TNAME|| ' MINUS SELECT * FROM ' ||TAB.TOWNER||'.'||TAB.TNAME|| ' AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL ''30'' MINUTE)))'; EXECUTE IMMEDIATE sqlstring INTO cnt; dbms_output.put_line('DIFFERENT LINES: '||cnt); dbms_output.put_line(''); END IF; EXCEPTION WHEN OTHERS THEN BEGIN insert into HR.TRACE_FLASH values (TAB.TOWNER||'.'||TAB.TNAME,rowcnt ); fails:=fails+1; END; END; END LOOP; COMMIT; dbms_output.put_line('FAILS: '||fails); END; -- Substracts(MINUS) current row set from past 30 minute flashback row set of each table. -- Counts remaining unique rows which are the modified ones. -- Fails on very large tables, system tables, tables without flashback records.

FAZIT Fachlichkeit radikal eingrenzen Testdaten frühzeitig einfordern Design lange flexibel halten Sicherheit durch komplementäre Testverfahren Entwicklungsumgebung beim Kunden nutzen Projektentscheidungen dokumentieren