In Datenbanken werden 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';

make -f ins_rdbms.mk uniaud_on ioracle

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 unified auditing grundsätzlich aktiviert (siehe auch mixed mode auditing oben) und bildet - wie oben erwähnt - die Audit Optionen ab, die auch in Oracle Database 11g standardmässig mit der Einstellung AUDIT_TRAIL=DB 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;

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

CREATE AUDIT POLICY dbacommunitydp
PRIVILEGES          SELECT ANY TABLE
ACTIONS             COMPONENT = DATAPUMP ALL

AUDIT POLICY dbacommunity
EXCEPT SYS

• 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;

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