Logo Oracle Deutschland   DBA Community  -  Oktober 2013
Unified Auditing - Das neue Auditing in Oracle Database 12c
von Heinz-Wilhelm Fabry ORACLE Deutschland B.V. & Co.KG

In Datenbanken werden fast immer vor allem wichtige Informationen abgelegt. Der Zugriff darauf unterliegt in der Regel gesetzlichen oder betrieblichen Auflagen. Weil der Nachweis, dass diese Auflagen eingehalten werden, ausschliesslich über das Auditing möglich ist, ist eine Datenbank ohne Auditing eigentlich nicht vorstellbar.

Ein Artikel der DBA Community hat sich bereits vor einiger Zeit mit den Möglichkeiten und Varianten des Auditierens in der Datenbankversion Oracle Database 11g beschäftigt. Der Artikel beschreibt das Auditing vom Default Auditing, mit dem zum Beispiel das Starten und Stoppen der Datenbank dokumentiert wird, bis hin zum Fine Grained Auditing (FGA), das sehr zielgerichtet DML Operationen erfasst. Er geht auch auf die unterschiedlichen Speichermöglichkeiten für die Audit Daten ein, auf die sogenannten audit trails: Neben der Variante, den audit trail in unterschiedlichen Tabellen der Datenbank (SYS.AUD$, SYS.FGA_LOG$, DVSYS.AUDIT_TRAIL$) abzulegen, wird dabei auf Betriebssystemdateien in einem Oracle proprietären oder im XML Format zurückgegriffen sowie auf die SYSLOGs oder EVENT LOGs der Betriebssysteme.

Schaut man sich das alles an, kann man sicherlich feststellen, dass das Auditing über viele Jahre ständig an neue Anforderungen angepasst und erweitert wurde. Aber es ist damit auch nach und nach unübersichtlicher geworden. Das ist vor allem deshalb problematisch, weil das Ziel des Auditing nicht das unbegerenzte Sammeln von Informationen ist, sondern die Auswertung dieser Informationen. Darum wurden in der aktuellsten Datenbankversion, Oracle Database 12c, die unterschiedlichen audit trails zu einem einzigen audit trail zusammengeführt. Das Ergebnis wird als unified auditing bezeichnet.

Die dazu nötige vollständige Überarbeitung der Architektur des Auditing Verfahrens bietet gleichzeitig die Gelegenheit, weitere Verbesserungen zu implementieren. Das betrifft sowohl die Performance als auch die Öffnung des gesamten Auditierens zur Nutzung durch diverse weitere Oracle Werkzeuge wie SQL*Loader und RMAN. Die folgenden Abschnitte beschreiben, wie man das neue unified auditing einrichtet, wie man damit arbeitet und welche Vorteile es gegenüber dem 'alten' Auditing bietet.

Einrichten des unified auditing

Will man wissen, ob das unified auditing für eine Datenbank der Version Oracle Database 12c aktiviert ist, kann man die View V$OPTION danach abfragen:

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
Erscheint hier als Rückgabe nicht der Wert TRUE, sondern der Wert FALSE, so bedeutet das, dass das unified auditing NICHT aktiviert ist. Wie wird es eingeschaltet?

Weder bei der Installation der Software von Oracle Database 12c noch beim Aufbau einer Datenbank mit dem Database Configuration Assistant (dbca) noch bei bei der Verwendung des Befehls CREATE DATABASE kann angegeben werden, dass das unified auditing genutzt werden soll. Auch nach einem erfolgreichen Upgrade einer Datenbank hin zu Oracle Database 12c bleiben die zuvor gewählten Auditeinstellungen und die bisher gesammelten Audit Daten erhalten: Das unified auditing ist nur über ein erneutes Linken der Software zu aktivieren. Dies geschieht unter Linux nach dem Stoppen der Datenbank und des Listeners aus dem Verzeichnis $ORACLE_HOME/rdbms/lib heraus mit folgender Eingabe auf der Kommandozeile
make -f ins_rdbms.mk uniaud_on ioracle
Nach dem Starten der Datenbank befindet sich das RDBMS im sogenannten mixed mode auditing. Das bedeutet, dass die alten Audit Einstellungen zusätzlich gelten und Audit Daten im festgelegten Format und Umfang in die eingestellten audit trails geschrieben würden. Erst nach dem Löschen der Initialisierungsparameter (und Neustart der Datenbank) und / oder dem Ausschalten eventuell vorhandener FGA Policies ist das 'alte' Auditing ausgeschaltet. Die bereits gespeicherten alten Audit Daten stehen nach wie vor zur Verfügung und sollten bei Bedarf gesichert werden. Danach könnten sie in den Systemtabellen (SYS.AUD$, SYS.FGA_LOG$, DVSYS.AUDIT_TRAIL$) und / oder in den relevanten Betriebssystemdateien gelöscht werden.

Das neue Auditing konfigurieren

Das neue Auditing ist nicht abhängig von Initialisierungsparametern. Allerdings gibt es eine neue Abhängigkeit anderer Art, nämlich die Abhängigkeit entweder von dem Privileg AUDIT SYSTEM oder der Rolle AUDIT_ADMIN. Da die Eigentümer von Objekten, also zum Beispiel der bekannte Benutzer SCOTT, über dieses Privileg und / oder diese Rolle NICHT automatisch verfügen, können sie nicht selbst das Auditing für ihre Objekte festlegen oder ein- und ausschalten. Damit wird zum Beispiel verhindert, dass der Eigentümer der Tabellen einer Anwendung das Auditing für diese Tabellen durch ein Aus- und anschliessendes Einschalten zeitweilig umgehen kann, ohne dadurch Spuren zu hinterlassen.

Die Vorgehensweise ähnelt dem schon aus dem FGA bekannten Verfahren (das FGA muss übrigens nach wie vor verwendet werden, wenn man lediglich Zugriffe auf einzelne Spalten auditieren möchte): Man muss eine Policy zur Verfügung stellen. Es gibt einige mitgelieferte Policies, die verwendet werden könnten. Die wichtigste heisst ORA_SECURECONFIG. Sie ist mit dem Einrichten des unified auditing aktiviert und bildet die Audit Optionen ab, die auch in Oracle Database 11g standardmässig eingeschaltet sind. Sinnvollerweise sollte man sich eigene Policies anlegen, denn ORA_SECURECONFIG enthält zum Beispiel keinerlei Regeln für das Auditieren von Benutzerobjekten.

Die gesamte Verwaltung des Auditing kann über den Enterprise Manager Cloud Control stattfinden. Für diesen Artikel wird darauf nicht zurückgegriffen, sondern es wird zur Verdeutlichung dessen, was im Rahmen der graphischen Oberfläche im Hintergrund passiert, auf der Kommandozeile gearbeitet.

Das Anlegen einer Policy geschieht mit dem Befehl CREATE AUDIT POLICY.

CREATE AUDIT POLICY dbacommunity
PRIVILEGES          SELECT ANY TABLE
ACTIONS             CREATE USER,
                    ALTER USER
                    SELECT ON SCOTT.EMP
ROLES               RESOURCE
WHEN                'SYS_CONTEXT(''USERENV'', ''MODULE'') <> (''PERSVERW'')'
EVALUATE            PER STATEMENT
CONTAINER           = CURRENT;
Bevor die einzelnen Elemente kurz erläutert werden, soll der Hinweis nicht fehlen, dass Policies mit dem Befehl ALTER AUDIT POLICY geändert und mit dem Befehl DROP AUDIT POLICY wieder gelöscht werden können.

Zu den Elementen des Beispiels.
  • Eine Policy ist ein Datenbankobjekt und benötigt also einen Namen, hier DBACOMMUNITY.
  • Es folgt eine Auflistung der Systemprivilegien und Aktionen, die auditiert werden sollen.
  • Der Eintrag zum Parameter ROLES, hier RESOURCE, führt dazu, dass alle Privilegien, die im Rahmen der aktivierten Rolle RESOURCE genutzt werden, auditiert werden.
  • Der Parameter WHEN bietet die neue und ausgesprochen hilfreiche Möglichkeit festzulegen, unter welchen Bedingungen ein Audit Eintrag geschrieben wird. Die Bedingung darf maximal 4000 Zeichen lang sein. Ausserdem unterliegt sie einigen Restriktionen, die im Handbuch SQL Language Reference beschrieben sind.
    Im Beispiel wird davon ausgegangen, dass die Anwendung PERSVERW einen eigenen audit trail schreibt. Deshalb wird für diese Anwendung das Auditing ausgeschlossen. Datenbankseitig werden also nur dann Zugriffe erfasst, wenn die Anwendung umgangen wird.
  • Die EVALUATE Klausel legt fest, wann ein Audit Eintrag entsteht. Neben dem angegebenen PER STATEMENT stehen auch noch PER SESSION und PER INSTANCE zur Verfügung.
  • Schliesslich kann beim Einsatz in einer Container Datenbank (CDB) angegeben werden, ob die zu auditierenden Aktionen nur in der aktuellen Pluggable Database (PDB) erfasst werden sollen - das ist hier so angegeben - oder in allen PDBs einer CDB (CONTAINER = ALL). Für den Fall CONTAINER = ALL gelten einige besondere Regeln, auf die hier nicht näher eingegangen werden soll.
Mit einer Variante des Befehls CREATE AUDIT POLICY unter Verwendung des Parameters ACTION COMPONENT ist das Auditing Verhalten der Komponenten Database Vault, Data Mining, Label Security, Real Application Security, SQL Loader (direct loads) und Data Pump zu steuern.
CREATE AUDIT POLICY dbacommunitydp
PRIVILEGES          SELECT ANY TABLE
ACTIONS             COMPONENT = DATAPUMP ALL
Hier wird beispielhaft festgelegt, dass für Data Pump Aktivitäten ein Audit Eintrag geschrieben wird, hier sowohl für den Export als auch für den Import. Mögliche Alternativen für den Wert ALL wären EXPORT oder IMPORT. Wer hier übrigens das Werkzeug Recovery Manager (RMAN) vermisst, sei darauf hingewiesen, dass RMAN sein Auditing Verhalten über seinen Aufruf quasi selbst steuert. Aber auch die Audit Daten des RMAN sind über den unified audit trail auszuwerten.

Nachdem mit dem Anlegen einer Policy festgelegt ist, was und unter welchen Bedingungen auditiert wird, muss das Auditing noch gestartet werden. Wie im 'alten' Auditing geschieht das mit dem Befehl AUDIT.
AUDIT POLICY dbacommunity
EXCEPT SYS
Auch hierzu eine kurze Erläuterung.
  • Das Auditieren kann mit der Klausel BY auch auf bestimmte Benutzer eingeschränkt werden. Es wird hier keine Einschränkung gemacht, deshalb gilt die Policy für alle Benutzer. Da SYS im unified auditing aber ein Benutzer wie jeder andere ist (es gibt für SYS KEINEN EIGENEN AUDIT TRAIL), wird für dieses Beispiel unterstellt, dass SYS absolut vertrauenswürdig ist und deshalb mit der Klausel EXECPT ausdrücklich vom Auditing durch die Policy DBACOMMUNITY ausgenommen wird.
  • Es gibt auch weiterhin die bekannte Klausel WHENEVER (NOT) SUCCESSFUL. Auf ihre Verwendung wird hier verzichtet. Das führt - ebenfalls wie gehabt - dazu, dass für beide Fälle ein Satz mit Audit Daten geschrieben wird.

audit trail auswerten und monitoren

Für das Auswerten des unified auditing müssen wie beim Konfigurieren bestimmte Voraussetzungen erfüllt sein - und diese gelten auch für die Eigentümer auditierter Objekte. Es muss entweder die Rolle AUDIT_ADMIN oder die Rolle AUDIT_VIEWER verliehen worden sein. Letztere erlaubt ausschliesslich das Lesen und wird typischerweise einem Auditor zur Verfügung gestellt.

Um die Möglichkeiten der Auswertung anzudeuten, soll an dieser Stelle nur der Verweis auf die Beschreibung der Spalten der View unified_audit_trail in der Oracle Database Reference stehen. SELECT Befehle sind damit leicht selbst zu schreiben. Ausserdem steht im Enterprise Manager Cloud Control für die Auswertung eine graphische Oberfläche zur Verfügung.

Die folgenden Views zum Monitoring des unified auditing geben Auskunft über alle Aspekte der Audit Konfiguration. Die Namen dieser Views sind sprechend, deshalb werden sie hier nicht weiter erläutert:

  • AUDIT_UNIFIED_POLICIES mit den Spalten
    policy_name, audit_condition, condition_eval_opt, audit_option, audit_option_type, object_schema, object_name, object_type, common
  • AUDIT_UNIFIED_CONTEXTS mit den Spalten
    namespace, attribute, user_name
  • AUDIT_UNIFIED_ENABLED_POLICIES mit den Spalten
    user_name, policy_name, enabled_opt, success, failure
  • AUDIT_UNIFIED_POLICY_COMMENTS mit den Spalten
    policy_name, comments

Pflege und Architektur des unified audit trail

Alle Manipulationen des audit trail erfolgen über das Package DBMS_AUDIT_MGMT. Dieses Package bietet die einzige Schnittstelle zur 'Pflege' des audit trail. Es ist nicht mehr möglich, den audit trail direkt mit SQL Befehlen zu bearbeiten. Jede Verwendung des Package wird auditiert. Das Package gehört dem Benutzer SYS und um es zu verwenden, muss entweder die Rolle SYSDBA oder die Rolle AUDIT_ADMIN verfügbar sein.

Um die Performance des Auditing zu verbessern, werden die Daten des Auditing standardmässig nicht mehr synchron in die Datenbank geschrieben, sondern über eine Queue in der SGA asynchron. Die Größe der Queue ist mit 1 MB voreingestellt, kann aber auf bis zu 30 MB angepasst werden. Die Anpassung geschieht über den neuen statischen Initialisierungsparameter UNIFIED_AUDIT_SGA_QUEUE_SIZE.

Will man auch den Inhalt zum Beispiel einer größeren Queue auf jeden Fall bei einer Auswertung des audit trails mit betrachten, kann man mit der Prozedur FLUSH_UNIFIED_AUDIT_TRAIL aus dem Package DBMS_AUDIT_MGMT ein sofortiges Schreiben der Audit Daten aus der Queue in die Datenbank veranlassen.

Durch den Mechanismus des asynchronen Schreibens könnten bei einem Crash der Datenbank Audit Daten aus der Queue des Auditing verloren gehen. Muss das unter allen Umständen vermieden werden, gibt es die Möglichkeit, das bekannte synchrone Schreiben einzuschalten. Das geschieht ebenfalls über das Package DBMS_AUDIT_MANAGEMENT und zwar mit folgendem Aufruf.

BEGIN
 DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY(
  DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
  DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE, 
  DBMS_AUDIT_MGMT.AUDIT_TRAIL_IMMEDIATE_WRITE);
END;
Aus der Queue werden die Audit Daten in eine einzige Tabelle geschrieben, die dem Benutzer AUDSYS gehört. Die Tabelle wird beim Einrichten des unified auditing im Tablespace SYSAUX angelegt, kann jedoch mit dem Package DBMS_AUDIT_MGMT in ein anderes Tablespace verlegt werden.

Wie beim 'alten' Auditing muss auch im neuen Auditing gelegentlich 'aufgeräumt' werden: Nicht mehr online benötigte Inhalte werden ausgelagert und anschliessend gelöscht. Das Auslagern lässt sich beispielsweise über ein INSERT AS SELECT in eine Hilfstabelle und anschliessenden EXPORT erreichen. Für das Löschen steht wiederum - keine Überraschung an dieser Stelle - das Package DBMS_AUDIT_MGMT mit einer Prozedur, nämlich CLEAN_AUDIT_TRAIL, zur Verfügung. Dabei kann Bezug genommen werden auf einen Zeitstempel, der ebenfalls über das Package zu setzen ist. Will man das Löschen automatisieren kann das über einen Job erreicht werden, der über DBMS_AUDIT_MGMT aufgesetzt wird. Spezielle Views für das Package erlauben übrigens auch hier ein effizientes Arbeiten: DBA_AUDIT_MGMT_CLEAN_EVENTS, DBA_AUDIT_MGMT_CLEANUP_JOBS, DBA_AUDIT_MGMT_CONFIG_PARAMS und DBA_AUDIT_MGMT_LAST_ARCH_TS.

Mandatory Auditing

Einige Befehle werden grundsätzlich auditiert. Das sind alle Befehle, die das Auditing in irgendeiner Form manipulieren, alle Befehle, die die Konfiguration von Database Vault betreffen, und - wie bereits oben erwähnt - alle Aufrufe des Package DBMS_AUDIT_MGMT.

Der / Die aufmerksame Leser/in wird sich nun noch fragen, wie auditiert wird, wenn die Datenbank (noch) nicht verfügbar ist? Etwa, weil im Mount Stadium Änderungen an der Datenbank vorgenommen werden müssen. In einer solchen Situation MUSS natürlich in Dateien des Betriebssystems geschrieben werden. Diese Dateien werden im Verzeichnis $ORACLE_BASE/audit/$ORACLE_SID angelegt. Ihre Inhalte können, wenn die Datenbank wieder geöffnet zur Verfügung steht, mit der Prozedur LOAD_UNIFIED_AUDIT_FILES aus dem Package DBMS_AUDIT_MGMT in den unified audit trail geladen werden. Je nach Menge der dabei zu ladenden Daten sollte man diesen Vorgang für einen geeigneten Zeitpunkt planen, also sicherlich nicht für einen Zeitraum, in dem die Datenbank ohnehin vollständig ausgelastet ist.

Weitere Informationen

Das unfied auditing steht in allen Editionen von Oracle Database 12c zur Verfügung. Die vollständigen Informationen dazu finden sich in den in den entsprechenden Kapiteln des Oracle Database Security Guide. Das Package DBMS_AUDIT_MGMT ist umfangreich im Handbuch Oracle Database PL/SQL Packages and Types Reference beschrieben.

Zurück zum Anfang des Artikels

Zurück zur Community-Seite