Unified Auditing - Das neue Auditing in Oracle Database 12c
von Heinz-Wilhelm Fabry ORACLE Deutschland B.V. & Co.KG
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:
Erscheint hier als Rückgabe nicht der Wert TRUE, sondern der Wert FALSE, so
bedeutet das nicht, dass das unified auditing nicht aktiviert ist. Es
bedeutet vielmehr, dass das unified auditing nicht als
Standardauditingverfahren eingerichtet ist und dass beide Verfahren, das
klassische und auch das neue, nebeneinander aktiv sind. Das wird auch als
mixed mode auditing bezeichnet. In diesem gemischten Modus gelten die
neuen Audit Einstellungen zusätzlich, und Audit Daten werden im
festgelegten Format und Umfang zusätzlich in den neuen unified audit trail
geschrieben. Vom Umfang her entspricht das dem, was eine Datenbank der Version 11
mit der Standardeinstellung AUDIT_TRAIL=DB sammelt.
Diese auf den ersten Blick vielleicht merkwürdig erscheinende Vorgehensweise
soll den Wechsel zum neuen Verfahren erleichtern. Man kann so zum
Beispiel eine Teilmenge aller zu auditierenden Aktionen einer Anwendung mit dem neuen
Verfahren testweise auditieren und erst später das gesamte Auditing mit dem
neuen Verfahren abwickeln - oder sich auch dagegen entscheiden, die Neuerung
einzusetzen.
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
ausschliesslich 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 als alleiniges Verfahren 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
Erst nach dem Neustart der Datenbank ist das 'alte' Auditing ausgeschaltet. Die
Initialisierungsparameter, die das alte Auditing steuern, werden nicht mehr
berücksichtigt. Die bereits gespeicherten alten Audit Daten stehen aber 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.
Ein Besonderheiten sei separat erwähnt: Auch wenn das neue Auditing als alleiniges
Verfahren eingeschaltet ist, können noch Befehle des alten Verfahrens OHNE
FEHLERMELDUNG eingesetzt werden - zum Beispiel AUDIT ALL ON emp. OBWOHL die
Meldung AUDIT SUCCEEDED angezeigt wird, werden die alten Befehle NICHT umgesetzt.
Sie sind nach dem Linken völlig wirkungslos.
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.
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.
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.
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.
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
|