Data Redaction live. Data Redaction live Oracle Data Redaction in einem produktiven Datenbanksystem Projektbericht Oracle Data Redaction in einem produktiven.

Präsentation zum Thema: "Data Redaction live. Data Redaction live Oracle Data Redaction in einem produktiven Datenbanksystem Projektbericht Oracle Data Redaction in einem produktiven."—  Präsentation transkript:

1

2 Data Redaction live

3 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

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

5 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

6 ANFORDERUNGEN - Zielsystem

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

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

9 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?

10 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

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

12 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.

13 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   Partial xxx-xxx-789 Regex Random "geheim" "6zt5%a"

14 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; /

15 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!

16 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

17 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 tritt auch auf, wenn ein User, für den die Policy nicht gilt, ein INSERT AS SELECT auf redaktionierte Spalten absetzt 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

18 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

19 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

20 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

21 Lösung - KOMPONENTEN

22 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

23 LÖSUNG - Fassadenarchitektur
FACADE_ADMIN

24 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

25 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

26 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< 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.

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

28