Der sichere Weg:
Einführung in das Unified Auditing

Ein Blick zurück

Bis einschließlich der Version Oracle 11g Release 2 gab es insgesamt vier verschiedene implementierte Auditing-Verfahren in der Datenbank:

• Mandatory Auditing
• Privileged Account Auditing (SYS- Auditing)
• Standard Auditing
• Fine Grained Auditing (FGA)

Diese Varianten wurden über Initialisierungsparameter, wie z. B. AUDIT_SYS_OPERATIONS oder AUDIT_TRAIL gesteuert. In Datenbanken, die in der Version 12c auf Unified Auditing umgestellt worden sind, haben diese Parameter keinen Effekt mehr.

Bei der Konfiguration erschwerten sehr viele Audit-Befehle die Übersichtlichkeit und Ausarbeitung eines wirkungsvollen Verfahrens. Wichtige Aktionen, wie die Anpassung der Audit-Konfiguration, RMAN und Data Pump waren zudem nicht in die Überwachung einbezogen.

Die Verteilung der Auditdaten auf unterschiedliche Speicher­orte (ADUMP Directory und Datenbank) machte eine einheitliche Lösung der Datenkontrolle zudem schwierig. Auf Dateisystemebene besteht ein Berechtigungs­konzept für die entsprechenden Verzeichnisse und parallel wird die Zugriffskontrolle auf die Audit Views in der Datenbank geregelt. Ein Analyst, der Auditing-Daten auswertet, benötigt demnach Zugriff auf beide Quellen.

Mixed Mode als Übergang zum Unified Auditing

Bei einer Migration auf Oracle 12c kommt es nicht zum Problem, dass das bestehende Auditing-Konzept nicht mehr wirksam ist. Unmittelbar nach dem Upgrade befindet sich die Datenbank in einem so genannten „Mixed Mode“. In diesem Zustand funktioniert das traditionelle Auditing (vor Oracle 12c) auch weiterhin. Die Audit-Einstellungen bleiben erhalten.

Nach der Migration sind die zwei neuen Policies ORA_SECURECONFIG und ORA_LOGON_FAILURES sofort aktiv. Die erste Policy überwacht wichtige CREATE-, ALTER-, DROP-Anweisungen und weitere Statements. Die zweite Policy protokolliert fehlerhafte Anmeldeversuche. Bei der Umstellung sollte daher beachtet werden, dass es zu einer redundanten Datenspeicherung kommen kann. Spezielle Unified-Auditing-Einstellungen, wie das RMAN Audit, funktionieren in diesem Modus noch nicht. Im Mixed Mode steht der Parameter Unified Auditing in der v$option auf FALSE (siehe Abbildung 1).

Unified Auditing

Das AUDSYS-Schema wurde in Oracle 12c neu implementiert. Dieser Datenbank-Account ist für eine Anmeldung gesperrt. Datensätze des Auditing, werden in diesem Schema in einer partitionierten Read-only-Tabelle geschrieben. Default-mäßig wird diese im Tablespace SYSAUX abgelegt.

Sollte die Datenbank nicht beschreibbar sein, werden die Events im Betriebssystem unter dem Verzeichnis $ORACLE_BASE/audit/$ORACLE_SID abgelegt. Die entstandenen Dateien können nachträglich in die Datenbank geladen werden.

Funktionsumfang

Das Auditing der Version 12c kann neben den Standard­aktivitäten die Aktionen folgender Oracle-Komponenten erfassen:

• Real Application Security (Spalten XS_*)
• Recovery Manager (Spalten RMAN_*)
• Data Pump (Spalten DP_*)
• Database Vault (Spalten DV_*)
• Label Security (Spalten OLS_*)
• FGA (Spalten FGA_*)
• SQL*Loader Direct Path

Alle überwachten Aktivitäten sind in einer einzigen zentralen View ersichtlich. In der UNIFIED_AUDIT_TRAIL sind für alle Events dedizierte Spalten selektierbar. Die Spaltennamen sind mit dem jeweiligen Präfix der Auf­listung identifizierbar. Diese zentrale Sicht löst die ent­sprechenden unzähligen Views wie SYS.AUD$, DBA_AUDIT_TRAIL, DBA_AUDIT_SESSION, DBA_FGA_AUDIT_TRAIL usw. ab.

Migration zu Unfied Auditing

Die Aktivierung des Unified Auditing funktioniert, wie in Abbildung 2 beschrieben, bei UNIX-Betriebssystemen über das Linken der Oracle Binaries [1]. Auf Windows muss eine DLL-Datei umbenannt werden. Die Datenbank muss bei dieser Aktion heruntergefahren sein. Der Parameter Unified Auditing (siehe Abbildung 1) steht nach der Aktua­lisierung jetzt auf TRUE. Die traditionelle Überwachung ist damit deaktiviert und deren Initialisierungsparameter
haben jetzt keinen Effekt mehr. Die alten Audit-Pfade sollten archiviert und bereinigt werden. Bei der Migration einer Multitenant-Datenbank werden CDB und alle angeschlossenen PDBs auf einmal umgestellt.

Die Verwaltung der Aktionen, die überwacht werden, erfolgt jetzt nur noch über die sogenannten Audit Policies, die in der Datenbank hinterlegt werden. Der Prozess der Umstellung auf das neue Verfahren kann genutzt werden, um das bestehende Konzept zu analysieren und zu modernisieren.

Unified Auditing Architektur

Auditing in einer Datenbank hat immer den Nachteil, dass es die Performance negativ beeinflusst. Mit der neuen Architektur wird dieser Nachteil minimiert. Einträge werden in einem bestimmten Format abgespeichert und die Daten können in der SGA zwischengespeichert werden. Wir unterscheiden daher zwei Schreibverfahren der Audit-
Einträge:

• Queued Write Mode (Default)
• Immediate Write Mode

Im Default-Verfahren, dem Queued Write Mode, werden die Audit-Einträge zunächst in der SGA abgelegt und periodisch auf Platte geschrieben. Der Parameter UNIFIED_AUDIT_SGA_QUEUE_SIZE definiert die Größe in der SGA für die Audit-Einträge. Diese werden dann periodisch oder manuell (siehe Abbildung 3) in die Audit-Basistabelle geschrieben.

Bei dem Queued Write Mode kann es bei einem inkonsis­tenten Herunterfahren der Datenbank zu einem Datenverlust kommen. Die Daten können sich zu diesem Zeitpunkt noch in der SGA befinden. Zur Absicherung bietet sich der Immediate Write Mode an. Die Datensätze werden nicht zwischengespeichert, sondern sofort in die entsprechende Tabelle geschrieben. Der eingeschaltete Write-Modus kann über die View DBA_AUDIT_MGMT_CONFIG_PARAMS selektiert werden und,  wie in Abbildung 4 beschrieben, online geändert werden.

Konfiguration des Unified Auditing

Die Sammlung der Audit-Daten wird im Unified Auditing mit Policies realisiert. Diese Regeln können benutzerde­finiert sein oder es können bereits bestehende vordefinierte Standards (siehe Abbildung 5) verwendet werden. Policies sind Container,  um Aktionen, Privilegien, Objekte und Rollen in der Datenbank zu überwachen. Die Ausführung dieser Policies kann mit Bedingungen oder Ausnahmen verknüpft werden, wie es z. B. in Abbildung 6 zu sehen ist. Hier werden alle Einfüge- und Abfrageoperationen für bestimmte Tabellen protokolliert, wenn die Anmeldung über „sqlplus“ erfolgt ist.

Die erstellten Regeln werden mit den Befehlen AUDIT und NOAUDIT aktiviert bzw. deaktiviert. Sind sie eingeschaltet, werden die entsprechenden Events im Audit Trail erfasst. Die zweite Policy (AUDIT_DP_POLICY) überwacht alle Data Pump Jobs des User obr. Hinterlegte Konfigurationen einer Policy lassen sich über die View AUDIT_UNIFIED_POLICIES abfragen.

Auswertung des Audit Trail

Alle aufgelaufenen Audit-Datensätze können in der zentralen View UNIFIED_AUDIT_TRAIL selektiert werden (siehe Abbildung 7). Im Vergleich zum Auditing vor der Version 12c, muss man sich hier keine Gedanken machen, welche View oder welche Dateien für die Analyse herangezogen werden müssen. Bestimmte RMAN-Operationen werden ohne eine bereits bestehende Policy im Audit-Pfad protokolliert (siehe Abbildung 8). Die entsprechenden Spalten der vereinheitlichten View können dabei herange­zogen werden. Der Befehl DELETE ARCHIVELOG ALL; wird hingegen nicht aufgezeichnet.

Zugriffskontrolle auf Audit-Datensättze

Oracle hat mit der Einführung in die neue Version 12c viele Mechanismen eingebaut, bei der die Verantwortlichkeiten, je nach Zuständigkeit, verteilt werden können. Beim Auditing stellt der Datenbankadministrator nur den Tablespace für die Daten zur Verfügung und verschiebt die Basistabellen hinein. Die Verwaltung der Policies und die Analyse der Daten ist auf zwei neu geschaffene Rollen verteilt:

• AUDIT_ADMIN
• AUDIT_VIEWER

Die Admin-Rolle ist den Datenbankbenutzern vorbehalten, die sich um die Verwaltung, die Definition von Regeln und um das Housekeeping kümmern. Die Viewer-Rolle beinhaltet alle Rechte zur Auswertung der Audit-Daten. In der Praxis sollten diese zwei Rollen auf zwei verschiedene dedizierte Nutzer verteilt werden.

Housekeeping

Das Package DBMS_AUDIT_MGMT, welches mit der Version 11GR2 eingeführt worden ist, wurde um den Funktionsumfang des Unified Auditing erweitert. Zu den Funktionen des Paketes gehören unter anderem das manuelle Anstoßen des Schreibens im Queued Write Mode, das Verschieben der Audit-Tabellen und die Verwaltung alter Audit-Daten. Die Archivierung und Löschung alter Datensätze kann manuell aber auch in fest hinterlegten Datenbank-Jobs erfolgen.

Fazit

Das Auditing präsentiert sich ab der Version 12c bedeutend verbessert. Es erfüllt viele Anforderungen und vereinfacht die Realisierung. Im Hinblick auf die Performance wird durch den Queued Write Mode eine Steigerung erzielt. Die einfache Entwicklung und Umsetzung eines Konzeptes setzt hier neue Maßstäbe. Man braucht nicht mehr viele einzelne Audit Statements, sondern kann gruppiert einzelne Regeln in Policies bündeln. Hervorzuheben ist, dass mit der Migration das bestehende Konzept analysiert und neue Definitionen erstellt werden. Weiterhin ist die Analyse der Daten mit einer zentralen View bedeutend einfacher geworden. Vorbei ist das Zusammensuchen der Information aus verschiedenen Speicherorten. Das Oracle Audit ist in die richtigen Bahnen gelenkt worden und gerade im Punkt Benutzerfreundlichkeit in neue Dimensionen vorge­drungen.

Ole Breimann
()

Glossar

CDB
Die Container Database ist die zentrale Datenbank in einer Multitenant-
Architektur in der Oracle Version 12c. In diese können die Plugable-Datenbanken eingeklinkt werden können.

DLL-Dateien
Dynamic Link Library Windows Dateien werden über die Betriebssystemfunk­tionalität bereitgestellt.

FGA
Das Fine Grained Auditing ist eine Erweiterung des klassischen Auditing,
um nur zu protokollieren, wenn gewisse Inhalte betroffen sind.

PDB
Die Pluggable Database ist eine für Anwendungen genutzte Datenbank, die
unter Verwendung der Multitenant-Architektur betrieben wird.

Abbildungen:

SQL> SELECT * FROM v$option
2 WHERE parameter = 'Unified Auditing';
PARAMETER VALUE CON_ID
------------------------------ ---------- ----------
Unified Auditing FALSE 0 

$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk uniaud_on ioracle

BEGIN
DBMS_AUDIT_MGMT.FLUSH_UNIFIED_AUDIT_TRAIL;
END;
/

SQL> BEGIN
2 dbms_audit_mgmt.set_audit_trail_property(
3 dbms_audit_mgmt.audit_trail_unified,
4 dbms_audit_mgmt.audit_trail_write_mode,
5 dbms_audit_mgmt.audit_trail_immediate_write);
6 END;
7 /
PL/SQL-Prozedur erfolgreich abgeschlossen.
SQL> SELECT * FROM dba_audit_mgmt_config_params
2 WHERE parameter_name = 'AUDIT WRITE MODE';
PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
---------------- -------------------- --------------------
AUDIT WRITE MODE IMMEDIATE WRITE MODE UNIFIED AUDIT TRAIL

--Anlegen der AUDIT POLICY
SQL> CREATE AUDIT POLICY obr_obj_policy
2 ACTIONS SELECT ON OBR.ABTEILUNG,
3 INSERT ON OBR.ABTEILUNG
4 WHEN 'INSTR(UPPER(SYS_CONTEXT(''USERENV'', ''CLIENT_PROGRAM_
NAME'')),
5 ''SQLPLUS'') > 0'
6 EVALUATE PER STATEMENT;
Audit-Policy erstellt.
--Erstellen einer Policy für Datapump Jobs
SQL> CREATE AUDIT POLICY audit_dp_policy
2 ACTIONS COMPONENT=DATAPUMP ALL;
Audit-Policy erstellt.
--Aktivieren der Policies
SQL> AUDIT POLICY obr_obj_policy EXCEPT obr;
AUDIT wurde erfolgreich ausgefuhrt.
SQL> AUDIT POLICY audit_dp_policy by obr;
AUDIT wurde erfolgreich ausgefuhrt.
--Überprüfen der aktiven AUDIT POLICY
SQL> SELECT *
2 FROM audit_unified_enabled_policies
3 WHERE policy_name in ('OBR_OBJ_POLICY','AUDIT_DP_POLICY');
USER_NAME POLICY_NAME ENABLED_ SUC FAI
---------- -------------------- -------- --- ---
OBR OBR_OBJ_POLICY EXCEPT YES YES
OBR AUDIT_DP_POLICY BY YES YES

1 SELECT dbusername "User",action_name "Aktion",object_schema
"Schema",object_name "Name",sql_text, unified_audit_policies
"Audit Policy"
2 FROM unified_audit_trail
3* WHERE unified_audit_policies='OBR_OBJ_POLICY'
User Aktion Schema Name SQL_TEXT Audit Policy
---- ------ ------ --------- ----------------------- -------------
USER1 SELECT OBR ABTEILUNG select * from obr.abteilung OBR_OBJ_POLICY

rman_device_type, event_timestamp
2 FROM unified_audit_trail
3 WHERE action_name='RMAN ACTION'
4 ORDER BY event_timestamp;
DBUSERNAME RMAN_OPERATIO RMAN_OBJECT_TYPE RMAN_
--------------- ------------- -------------------- -----
SYS Backup DB Incr None
SYS List SP File None
SYS Backup DB Incr Disk