Oracle 12c Unified Auditing – Teil 1

Mit Oracle 12c wird alles Besser! Und dazu gehören auch die neuen Auditing Möglichkeiten, die unter dem Begriff „Unified Auditing“ zusammengefasst werden.  Zunächst einmal bedeutet „Unified Auditing“ nichts anderes, als das die bisherigen Funktionen, Standard Auditing und Fine Grained Auditing zusammengefasst werden. Das bedeutet zunächst einmal, dass wir es jetzt mit drei (!) unterschiedlichen Methoden zu tun haben, denn die „alten“ sind immer noch vorhanden, auch wenn, entgegen den Aussagen einer Dokumente, diese standardmäßig ausgeschaltet sind. Auch der Behauptung, dass die gleichen Befehle wie in Oracle 11g protokolliert werden, kann ich nur bedingt zustimmen. So wird z.B. nur ein Failed Logon überwacht, nicht aber ein Successful Logon – aber dazu gleich mehr.

Es gibt gegenüber den bisherigen Auditing Funktionen einige wesentliche Verbesserungen. Dazu gehört z.B. dass die Auditrecords nicht mehr direkt in Tabellen geschrieben werden, sondern zunächst nur in der SGA existieren. Wem das zu unsicher ist, der kann dieses Verfahren natürlich überschreiben und dann wird, wie bei jeder normalen Tabelle, die Auditinformation direkt in die Tabelle geschrieben. Und das ist schon die zweite Änderung: mit Version 12c wird für die Auditinformationen eine partitionierte Tabelle im Schema AUDSYS verwendet. Diese Tabelle, mit einem kryptischen Namen „CLI_SWP…“ liegt standardmäßig im SYSAUX und sollte natürlich in einen separaten Tablespace, z.B. AUDITTS, verschoben werden.

Unified Auditing aktivieren

In einigen Blogs und auch in der Oracle Dokumentation wird erwähnt, dass man die Datenbank auf Unified Auditing umstellen kann, d.h. auf die „alten“ Funktionen verzichtet. Dafür muss der Oracle Kernel neu gelinkt werden. Ich würde damit erst einmal warten, da das Unified Auditing derzeit noch nicht den kompletten Umfang des bisherigen Fine Grained Auditing beherrscht (siehe Oracle 12c Database Security Guide: „If you want to audit specific columns or use event handlers, use fine-grained auditing.“)

Die folgende Abfrage könnte den Eindruck vermitteln, dass Unified Auditing nicht aktiv ist, dieser Eindruck ist falsch. Das „FALSE“ besagt lediglich, dass Unified Auditing nicht ausschließlich verwendet wird sondern zusätzlich auch noch das „alte“ Auditing benutzt werden kann.

SELECT parameter, value
  FROM v$option
 WHERE parameter = 'Unified Auditing';

PARAMETER            VALUE
-------------------- --------------------
Unified Auditing     FALSE

Die nächste Verbesserung betrifft ganz generell die Verwaltung von Unified Auditing. Bisher war es erforderlich, eine Initialisierung vorzunehmen, wenn man z.B. die Auditingtabelle verschieben wollte oder Datensätze mit „Purge“ löschen wollte (siehe hierzu auch den Blog: Verwaltung von Auditing Informationen). Das ist mit dem Unified Auditing nicht mehr erforderlich bzw. möglich. Daher können Sie den folgenden Befehl und die Fehlermeldung einfach ignorieren.

BEGIN
   dbms_audit_mgmt.init_cleanup(
      audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
      default_cleanup_interval => 24);
END;
/ 
BEGIN
   ERROR at line 1:
   ORA-46250: Invalid value for argument 'AUDIT_TRAIL_TYPE'
   ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 177
   ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 605
   ORA-06512: at line 2

Hinweis:

Es gibt einige Dokumente, die besagen, dass der Parameter audit_trail für Unified Auditing keine televanz hat. Das ist falsch! Wenn der Parameter nicht auf „DB“ steht, werden keine Unified Auditing Informationen geschrieben und einige Befehle in diesem Kontext funktionieren nicht:

execute DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
   ERROR at line 1:
   ORA-46276: DBMS_AUDIT_MGMT operation on unified audit trail failed
   ORA-55906: Secure file log [id: 0 name: ORA$AUDIT_NEXTGEN_LOG] does not exist
   ORA-06512: at "SYS.DBMS_AUDIT_MGMT", line 1746
   ORA-06512: at line 1

Daher sollten Sie den Parameter auf jeden Fall auf „DB“ stellen, um Unified Auditing zu nutzen.

Verschieben der Tabelle

Das Verschieben der Tabelle geht ganz einfach:

CREATE TABLESPACE auditts
   DATAFILE SIZE 1000M AUTOEXTEND ON NEXT 100M MAXSIZE 2000M;
   
BEGIN
   dbms_audit_mgmt.set_audit_trail_location(
   audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
   audit_trail_location_value => 'AUDITTS');
END;
/

Löschen von Audit Informationen

Das Verfahren für das Löschen von Auditinformationen ist identisch mit dem bereits aus früheren Versionen bekannten (siehe Blog: Verwaltung von Auditing Informationen). D.h. zunächst einmal werden die Audit Records, die gelöscht werden können, markiert (SET_LAST_ARCHIVE_TIMESTAMP) und anschließend kann entweder ein Purge Job ausgeführt werden oder aber die Datensätze mit einer Clean Prozedur direkt gelöscht werden.

Leider gibt es hier einen unschönen Bug, für den es aber bereits einen Patch gibt: Patch 18743542: 12C UNIFIED AUDIT TRAIL, CANNOT DELETE LAST_ARCHIVE_TIME.

Hier noch einmal das Vorgehen für das Löschen von Audit Records (die Initialisierung entfällt, wie bereits erwähnt):

BEGIN
   dbms_audit_mgmt.set_last_archive_timestamp(
      audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
	  last_archive_time => to_date('13.01.2015 13:22:00','DD.MM.YYYY HH24:MI:SS'));
END;
/

SELECT last_archive_ts 
  FROM dba_audit_mgmt_last_arch_ts;

LAST_ARCHIVE_TS                     
-----------------------------------
13-JAN-15 01.22.00.000000 PM +00:00

BEGIN
   dbms_audit_mgmt.clean_audit_trail(
      audit_trail_type => dbms_audit_mgmt.audit_trail_unified,
	  use_last_arch_timestamp => TRUE);
END;

In dem Beispiel wird nicht der Purge Job aufgerufen, sondern das Löschen direkt ausgeführt. Allerdings scheint es so, als ob zunächst nichts passiert…  Warten wir’s ab!

Im zweiten Teil kümmern wir uns um das eigentliche Auditing.