Deshalb möchte ich an dieser Stelle versuchen, ein wenig Licht in den Tunnel zu bringen.
Das Standard Auditing wurde von Oracle mit dem Release 7 eingeführt, also vor immerhin ca.30 Jahren.
Nach vielen Erweiterungen wurde Unified Auditing mit dem Oracle Release 12R1 (ab 2013) zusätzlich eingeführt. Ziel war es, ein einheitliches Ziel (Audit Trail) für alle Audits in der Datenbank bereitzustellen, weil eine Auswertung der Audit-Daten bei bis zu fünf unterschiedlichen Zielen vor Oracle 12c schwierig war.
Zwei Audit-Möglichkeiten
Damit eine weiche Migration gut möglich ist, sind seit Oracle 12c beide Audit-Möglichkeiten als „Mixed Mode Auditing“ in der Datenbank verfügbar. Auf der einen Seite die „alte“ Methode, genannt das „Traditional Auditing“, und auf der anderen Seite die neue Methode – das „Unified Auditing“.
Das Unified Auditing wird automatisch nach der Installation gestartet. Dabei sind sind zwei Policies sofort aktiv:
SQL> SELECT POLICY_NAME
FROM AUDIT_UNIFIED_ENABLED_POLICIES;
POLICY_NAME
------------------------------------
ORA_SECURECONFIG
ORA_LOGON_FAILURES
Mit folgender Abfrage kann man sehen, welche Aktionen standardmäßig mit der Policy "ORA_SECURECONFIG" in der Datenbank auditiert werden:
SQL> SELECT POLICY_NAME, AUDIT_OPTION
FROM AUDIT_UNIFIED_POLICIES
WHERE policy_name = 'ORA_SECURECONFIG' order by 2;
Es werden 49 Audit-Aktionen aufgelistet, d.h. auch ohne weitere Konfiguration werden von der Datenbank ausgewählte Zugriffe aufgezeichnet.
Weiterhin können mit dem Unified Auditing auditiert werden (Auswahl):
- Audit-Einträge (einschließlich SYS-Audit-Einträge) von Audit Policies und AUDIT-Einstellungen
- Fine-grained Audit-Einträge von dem DBMS_FGA PL/SQL Package
- Oracle-Recovery-Manager-Audit-Einträge
- Oracle-Database-Vault-Audit-Einträge
- Oracle-Application-Context-Einträge
- Oracle Data Pump
- Oracle SQL*Loader
Bei genauer Betrachtung befinden sich keine Einträge mehr in dieser Tabelle AUD$.
Diese Tabelle ist ein Ziel des „Traditional Auditing“, was weiterhin noch genutzt werden kann.
SQL> SELECT COUNT(*) from AUD$
COUNT(*)
-------------
0
Aber in der folgenden View (Tabelle : AUD$UNIFIED) sind bereits viele Einträge, die von den zwei bereits genannten aktivierten Policies initiiert wurden:
SQL> SELECT COUNT(*)
FROM UNIFIED_AUDIT_TRAIL;
COUNT(*)
--------------
17377 – (Beispiel nach 4 Tagen)
Wie kann das sein? Denn nach der Installation erhält man folgende Ausgabe:
SQL> SELECT PARAMETER, VALUE
FROM V$OPTION
WHERE PARAMETER='Unified Auditing';
PARAMETER VALUE
----------------------------------------------------------------
Unified Auditing FALSE
Diese Ausgabe bedeutet, das Unified Auditing im Mixed Mode teilweise aktiviert ist.
Um Unified Auditing vollständig freizuschalten, muss es im Kernel eingebunden werden, da es standardmäßig nicht integriert ist.
Schritte zur Aktivierung des Unified Auditing als (Standard-) Auditing
Mit folgenden Schritten wird Unified Auditing als einziges (Standard-) Auditing aktiviert (Beispiel LINUX):
1. alle Listener im ORACLE_HOME stoppen
2. alle Datenbanken im ORACLE_HOME stoppen
3. aktivieren als ORACLE_HOME Owner
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle
ORACLE_HOME=$ORACLE_HOME
4. alle Listener im ORACLE_HOME starten
5. alle Datenbanken im ORACLE_HOME starten
Jetzt hat sich "Value" auf "TRUE" geändert.
SQL> SELECT PARAMETER, VALUE
FROM V$OPTION
WHERE PARAMETER='Unified Auditing';
PARAMETER VALUE
-----------------------------------
Unified Auditing TRUE
Im Unified Auditing werden alle Einträge in die Tabelle AUDSYS.AUD$UNIFIED geschrieben, die sich nach der Installation im SYSAUX Tablespace befindet.
Da diese Tabelle täglich wächst, gibt es verschiedene Möglichkeiten, die Tabelle zu pflegen, ohne Audit-Einträge zu verlieren.
- Mit dem Package DBMS_AUDIT_MGMT kann die Tabelle in ein anderes Tablespace verschoben werden. Aber Achtung, SYSAUX ist intern komprimiert.
- Nachdem wichtige Datensätze gesichert wurden, können diese mit Hilfe des DBMS_AUDIT_MGMT gelöscht werden. D.h. nach der Sicherung der Datensätze wird ein Timestamp angelegt, bis zu welchen Zeitpunkt die Daten gelöscht werden.
Mit einem PURGE_JOB kann die Löschaktion auch automatisiert werden, so dass die Größe des Tablespaces überschaubar bleibt.
Cornelia Heyde
stv. DOAG Themenverantwortliche Monitoring und Sicherheit
-----
Bild von Vitor Dutra Kaosnoff auf Pixabay
