Logging und Auditing unter 10g R2 - database- · PDF file11/2007 Folie 2 von 42 ©Database Consult GmbH - Jachenau Logging und Auditing unter 10g R2 Database Consult GmbH • Gegründet

Logging und Auditing unter 10g R2

Dr. Günter UnbescheidDatabase Consult GmbH - Jachenau

11/2007 Folie 2 von 42 ©Database Consult GmbH - Jachenau

Logging und Auditing unter 10g R

2

Database Consult GmbH

• Gegründet 1996• Kompetenzen im Umfeld von ORACLE-basierten Systemen• Tätigkeitsbereiche

– Tuning, Installation, Konfiguration– Support, Troubleshooting, DBA-Aufgaben – Datenmodellierung und –design– Datenbankdesign, Systemanalysen– Programmierung: SQL,PL/SQL,Java, JSP, ADF UIX, BC4J– Schulungen– Expertise/Gutachten– www.database-consult.de

http://www.database-consult.de/



2

Featureprofil - Anforderungsprofil

05

10152025303540

R1 R2 R3 R4 R5

FPAP



2

Spannungsfeld Auditing

Gesetze

FeaturesAnforderungen



2

Rahmenbedingungen

Planung

KonfigurationAuswertung



2

Nur wer sein Ziel kennt,findet den Weg

Lao-Tse

Motto

Sicherheit ist kein automatischer Prozess, sondern eine zielgemässe und bewusste

Planung, Umsetzung und Kontrolle.

oder

Coole Features machen noch keinen Sommer!

Sicherheit ist kein automatischer Prozess, sondern eine zielgemässe und bewusste

Planung, Umsetzung und Kontrolle.

oder

Coole Features machen noch keinen Sommer!



2

Begriffe/Ziele

log (L) = aufzeichnen/protokollieren

audit (A) = prüfen/überprüfen

Ziel: Bedarfsgerechte Konfiguration und Auswertung von LA,

Bei Allem: AUDIT schützt nicht!

log (L) = aufzeichnen/protokollieren

audit (A) = prüfen/überprüfen

Ziel: Bedarfsgerechte Konfiguration und Auswertung von LA,

Bei Allem: AUDIT schützt nicht!



2

Prinzip Audit

Erlaubte Aktionen

Identifizierte BenutzerKontrolle der Ressourcen

Kein Schutz vor Missbrauch wenn identifizierte Benutzer erlaubte Aktionen regelwidrig verwenden!



2

Konzeption

• Geschäftsumfeld – gesetzliche Grundlagen• IT-Landschaft – Server, Netze, Firewalls• Applikationskontexte

– Typ: Client-Server, Web-Applikationen– Authentifizierung und Autorisierung– Individueller Schutzbedarf zur Sicherstellung von

Vertraulichkeit, Integrität und Verfügbarkeit

• Konzeptionelle Anforderungen an LA entwickeln– was – wann – wo

• LA individuell konfigurieren/implementieren• Regelmässige Auswertungen/Reports

– Routinen festlegen



2

Konzeption

• Erfassung der Applikationen und deren Architektur• Schutzbedarf applikations-spezifisch ermitteln

– Authentifizierung und Authentifizierungspfade– Authorisierungskonzepte (Gruppen und Rollen)– Schützenswerte Kontexte (

• Planung– Grundkonfiguration der Datenbank– Audit-Optionen ermitteln– Reporting und Analyseverfahren zur Audit-Auswertung– Verfahren zur Archivierung/Löschung

• Graphiken helfen bei der Übersicht/Planung• Audit ist keine Frage der Performance!



2

„Housekeeping“

• Auswertung– „real time“ zur spontanen Reaktion– mittlel- bzw. langfristige Analysen/Trends

• Löschen versus Archivieren– Zeitraster/Eventraster festlegen– Schutz von unauthorisiertem Löschen– Zusammenführen von disjunkten Audit Stores?



2

Applikations-Diagramm

DBa DBb

OID/LDAP

Application

A

A

A A

ApplicationContext



2

Authentifizierungsdiagramm

A

B

DB-User Global(s) Global(dn) Client-ID

A

B

A

B

A

BC

A

BC



2

Authentifizierungsdiagramm

A

B

DB-User Global(s) Global(dn) Client-ID

A

B

C

A

B

A

B

A

BC

A

B



2

Risiken Auditing

• Überlauf von Speicherbereichen bei ungenügendem „Housekeeping“

• Ignoranz gegenüber Attacken bei ungenügender Auswertung und Analyse

• Löschung relevanter Inhalte durch Hochprivilegierte (DBA-Group / Root)



2

Übersicht: Logging• Datenbank: Alert-Log

– zwanghaft– startup- und shutdown-Informationen– administive Logging create/drop tablespace u.v.a.– interne Fehler, non-default init.ora– keine Benutzer-Informationen (!)

• Oracle Net: Listener und Client/Database– zwanghaft – Namen und Verzeichnisse der log-Dateien bestimmbar– erfolgreiche und erfolglose Connect Requests, error stack

01-AUG-2006 13:04:57 * (CONNECT_DATA=(SERVICE_NAME=mr.dbc.de)(SERVER=DEDICATED)(CID=(PROGRAM=C:\Pr ogramme\KeepTool\KeepTool 7\Hora.exe)(HOST=DATTATREYA2)(USER=xxxx))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.45.98)(PORT=1635)) * establish * mr.dbc.de * 0



2

Markierungen

• Individuelles Schreiben in Trace- und Alert-Dateien– Markierung relevanter Code-Kontexte

• Setzen von Zeitstempeln

BEGIN-- schreibt Zeitstempel in TRACE-Dateidbms_system.ksdddt;-- Einzug mit Doppelpunkten ("::::")dbms_system.ksdind(4);dbms_system.ksdwrt (1, 'Output written to trace file');dbms_system.ksdwrt (2, 'Output written to alert log');dbms_system.ksdwrt

(3, 'Output written to both trace file and alert log');END;

Werkzeuge



2

Übersicht Auditing

• „Mandatory“ Auditing– für sysdba und sysoper– einzelne aud-Dateien– Verzeichnis über

audit_file_dest

• SYS-Auditing– erweitertes Auditing für SYS,

SYSOPER und SYSDBA– erfolgreiche und fehlerhafte

Aktionen– audit_sys_operations=

true

– Neustart erforderlich

Audit file /u01/app/oracle/admin/xy/adump/ ora_7511.aud

Sun Nov 12 18:00:24 2006 ACTION : 'CONNECT‚ DATABASE USER: '/‚ PRIVILEGE : SYSDBA CLIENT USER: oracle CLIENT TERMINAL: pts/4 STATUS: 0

Sun Nov 12 18:00:26 2006 ACTION : 'ALTER DATABASE OPEN‚ DATABASE USER: '/‚ PRIVILEGE : SYSDBA CLIENT USER: oracle CLIENT TERMINAL: pts/4 STATUS: 0

Sun Nov 12 18:01:08 2006 ACTION : 'select name, value from v$parameter where name like '%audit%'‚



2

Übersicht Auditing

• „Application Auditing“– individuell programmiert, z.B. Journaling Tabellen, Status-

Tabellen, Nutzung von Triggern– flexibel, vielseiting und DB-unabhängig– ggf. umgehbar, wenn Applikation nicht genutzt wird.– ggf. per autonomous transaction

• Version Query und Transaction Query– „Flashback“ Features– können für Auditing eingesetzt werden– „Polling“ Prinzip – explizite Abfragen nötig– gebunden an undo_management und undo_retention



2

Übersicht Auditing

• DB-Auditing (Standard-Auditing)– Objekt-bezogen– Privilegien-Auditing– Statement – Gruppen von Statements– Content-Auditing (fine-grain auditing)

• Zusätzliche Filter– Benutzer– Erfolgreich/erfolglos/beides– Session/Statement



2

Alternative Nutzung

• Accounting durch– session_cpu– logoff_lread– logoff_pread

• Statistiken durch– timestamp Informationen– Username– Action



2

Grundkonfiguration audit_trail• nicht für FGA und SYS-Auditing• NONE – default = keine audit_trail• DB – in der Datenbank unter sys.aud$

– Nutzung diverser Views– einfache Generierung von Reports/Auswertungen

• OS – Betriebssystem– einfacher zu schützen vor Manipulationen durch DBAs– komplexere Auswertung/Filterung, nicht alle Daten geloggt!!

Sun Nov 12 19:39:54 2006 SESSIONID: "788" ENTRYID: "1" STATEMENT: "1" USERID: "MRX" USERHOST: "Ganga" TERMINAL: "pts/5" ACTION: "100" RETURNCODE: "0" COMMENT$TEXT: "Authenticated by: DATABASE" OS$USERID: "oracle" PRIV$USED: 5

Sun Nov 12 19:40:15 2006 SESSIONID: "788" ENTRYID: "1" ACTION: "101" RETURNCODE: "0" LOGOFF$PREAD: "2" LOGOFF$LREAD: "1163" LOGOFF$LWRITE: "0" LOGOFF$DEAD: "0" SESSIONCPU: "26"



2

Grundkonfiguration audit_trail

• XML – wie OS nur in XML-Format– darstellbar und filterbar/analysierbar über XML-Standard-Tools– voluminös– DB-interne Sicht über v$xml_audit_trail und DBA_COMMON_AUDIT_TRAIL

– Integriert auch „mandatory auditing“ und SYS Audit Operationen• Typen „SYS XML Audit“, „Mandatory XML Audit“,

„Standard XML Audit“

• DB und XML extended– zusätzliches Protokoll von SQL, Bindevariablen SCN



2

Grundkonfiguration audit_trail

• Nutzen des SystemLogs– audit_trail = OS und audit_syslog_level=facility.priority setzen

– guter Schutz von DBA-Manipulationen– setzt Erfahrung mit SYSLOG voraus

• Generell beachten:– Record wird auch geschrieben, wenn rollback erfolgt.– modifiziertes SQL (VPN) wird in Originalform protokolliert.– Löschen von DB-Einträgen per Rolle

DELETE_CATALOG_ROLE



2

Statement Audit

AUDIT DROP TABLEBY SESSION;AUDIT TYPE -- GruppierungBY SESSION 7AUDIT SYSTEM AUDIT;

AUDIT DELETE FROM table BY GU BY ACCESS WHENEVER SUCCESSFUL /NOAUDIT TRUNCATE TABLEBY SCOTTWHENEVER NOT SUCCESSFUL/View DBA_STMT_AUDIT_OPTSView DBA_AUDIT_STATEMENT



2

Privilege Audit

AUDIT CREATE ANY CLUSTERBY BLABY ACCESSWHENEVER SUCCESSFUL/AUDIT ALL PRIVILEGESBY SESSION/View DBA_PRIV_AUDIT_OPTSView DBA_AUDIT_SESSION, DBA_AUDIT_TRAIL



2

Object Audit

AUDIT COMMENTON SCOTT.TBY SESSION/AUDIT INDEXON SCOTT.TBY SESSIONWHENEVER SUCCESSFUL/View DBA_OBJ_AUDIT_OPTSView DBA_AUDIT_OBJECT, DBA_AUDIT_TRAIL, DBA_COMMON_AUDIT_TRAIL



2

Default Audit

AUDIT GRANT ON DEFAULT/-- wirkt für zukünftige Objekte



2

User Identifizierung per audit_trail

• DB_USER – Datenbankuser• SESSIONID• GLOBAL_UID – Enterprise User• EXT_NAME – external Name (z.B. DN)• OS_USER• CLIENT_ID• COMMENT_TEXT – authentication

– database, network, proxy



2

Application Info

• client_info, module, action über DBMS_APPLICATION_INFO• client_id über DBMS_SESSION – „auditierbar“• Filtern teilweise möglich über

– v$session, – v$sqlarea, v$sql– dbms_monitor

BEGINDBMS_APPLICATION_INFO.SET_CLIENT_INFO( CLIENT_INFO => 'Test-Client');

DBMS_SESSION.SET_IDENTIFIER(CLIENT_ID => 'Test-ID');

END;



2

Fine Grain Auditing

• AUDITING abhängig von Inhalt (WHERE Bedingung)• ab 10g für alle DMLs• kein „not successful“ nur wenn Rows „getroffen“ werden• unabhängig von AUDIT_TRAIL – Einstellungen• Views DBA_FGA_AUDIT_TRAIL und

DBA_COMMON_AUDIT_TRAIL• API per Package DBMS_FGA• Typen:

– Bedingung: direkt oder per Function– Spalten-Auswahl (zusätzlich oder separat)– Event-Handler (Aktionen im Fall eines Falles)



2

Fine Grain Auditing

BEGINDBMS_FGA.ADD_POLICY (object_schema => ‘SCOTT’,object_name => ‘EMP‘,policy_name => ‘testpol‘,audit_condition => ‚schema.funct = 1‘,audit_column => ‚SAL‘-- handler_schema-- handler_module

);END;/



2

Oracle Flashback• Flashback Features

– FB query– FB Version Query: Abfragen, die „alte“ Daten und Metadaten

liefern– FB Transaction Query – Metadaten über Transaktionen einer

Zeitspanne– (FB Database, FB Table, FB Drop)

• FB arbeitet auf Basis der Undo Tablespace:– undo_management, undo_tablespace und undo_retention (Ausnahme FB Database)

– retention garantee Klausel der UTS– version query: grant flashback + select– Transaction Query: select any transaction und

supplemental logging eingeschaltet



2

FB QuerySELECT * FROM employees AS OF TIMESTAMPTO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')WHERE last_name = 'Unbescheid'/INSERT INTO employees(SELECT * FROM employees AS OF TIMESTAMPTO_TIMESTAMP('2004-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS')WHERE last_name = 'Unbescheid');-- Timestamp to SCN-Mapping mit 3 Sek. GranularitätINSERT INTO employees(SELECT * FROM employees AS OFTIMESTAMP (SYSTIMESTAMP - INTERVAL '60' MINUTE))-- SYSTIMESTAMP refers to the time zone of the database host environmentMINUS SELECT * FROM employees);



2

FB QuerySELECT ora_rowscn, last_name, salaryFROM employeesWHERE employee_id = 7788;-- normal upper bound, exakter für ROWDEPENDENCIES

-- Package DBMS_FLASHBACK-- DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER-- DBMS_FLASHBACK.ENABLE_AT_TIME or-- DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER-- DBMS_FLASHBACK.DISABLE-- function SCN_TO_TIMESTAMPUPDATE employeesSET salary = salary + 100WHERE employee_id = 7788AND ora_rowscn = 202553/



2

Oracle Flashback Version Query

• Versionen von Rows in einer gegebenen Zeitspanne• Ergebnis mit distinktiven Versionen von Rows• Pseudospalten verfügbar

SELECT versions_startscn, versions_starttime,versions_endscn, versions_endtime,versions_xid, versions_operation,name, salaryFROM employeesVERSIONS BETWEEN TIMESTAMPTO_TIMESTAMP('2003-07-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS')AND TO_TIMESTAMP('2003-07-18 17:00:00', 'YYYY-MM-DD HH24:MI:SS')WHERE name = 'JOE';



2

Flashback Transaction Query

• View falshback_transaction_query• XIDs, SCNs, User und Undo SQL für zurückliegende Transaktionen

SELECT xid, operation, start_scn,commit_scn, logon_user, undo_sqlFROM flashback_transaction_queryWHERE xid = HEXTORAW('000200030000002D')/SELECT xid, logon_user FROM flashback_transaction_queryWHERE xid IN (SELECT versions_xid FROM employees VERSIONS BETWEEN TIMESTAMPTO_TIMESTAMP('2003-07-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS') ANDTO_TIMESTAMP('2003-07-18 17:00:00', 'YYYY-MM-DD HH24:MI:SS'));



2

Audit Vault

• IST-Stand:– Audit-Informationen liegen verteilt: in zugehörigen DBs bzw.

Filesystemen– kein vollständiger Schutz vor Manipulationen (Oracle-User,

Root-User)– unterschiedliche Formate: Tabellen, XML, Textdateien

• Audit Vault – DWH für Audit-Daten– Produkt ist Beta seit Ende 05 – erwartet in Kürze (1.Q 2007)– zentrales Audit Repository für Konsolidierung und Management

von Quellsystemen– Entlastung von Produktivsystemen– zentrales Management und Auswertung (Reports, Alerts)– „gehärtete“ Konfiguration



2

Audit Vault

Quelle: Oracle



2

Audit Vault

• Quellsysteme möglicherweise von 9iR2 bis 10g• Aufzeichnungsformat basiert auf Distributed Audit

Service (XDAS)– Basisformat mit abgeleiteten Formaten je nach Audit-Kategorie

• Unterschiedliche Source-Typen– Datenbank, Application Server ...

• Policies regeln Audit-Optionen– Abgleich mit IST auf Quellsystemen („policy violation“)– „Deployment“ auf Quellsysteme

• Prozesse– Audit Loader, Data Processor, Alert Agent, Data Archiver



2

Audit Vault

• Datensammlung aus DB– Audit-Daten– Redo Logs

• Software Developement Kit für Datensammlung• Separation of Duties - Rollenmodell

– Auditor, Audit Admin, Audit Archiver, Audit Vault Super User – exklusiv innerhalb einer Session

– DBA-Schutz des Schemas (Database Vault) – Schemazugriff nur über Rollen – Rollenadministration durch AV Super User

– Zugriff nur per SSL möglich – sichere Datenübermittlung

• Integrierte Alerts



2

Audit Vault

• Daten partitioniert nach Sourcen und Zeit• AV Warehouse für historische Partitionen• Workflow: von aktuell über Komprimierung ins DWH• Reporting

– voreingestellte Analysen– Erstellung eigener Auswertung– Automatische Report-Generierung– BI-Integration



2

Danke für‘s Zuhören

Documents

Logging und Auditing unter 10g R2 - database- · PDF file11/2007 Folie 2 von 42 ©Database Consult GmbH - Jachenau Logging und Auditing unter 10g R2 Database Consult GmbH • Gegründet