Online Magazine

Wie integriere ich Oracle Unified Audit in SYSLOG?

Jede Datenbank braucht ein Sicherheitskonzept – und dieses muss überwacht werden. Bei Oracle Datenbanken gibt es dafür Oracle Unified Audit. Um das Audit von der Datenbank zu entkoppeln und so das Manipulationsrisiko zu verringern, integriert man es am besten in SYSLOG. Wie? Das zeige ich dir in diesem Hack.

von Stefan Oehrli

Wer regelmässig mit Datenbanken zu tun hat, weiss: Eine Datenbank braucht ein Sicherheitskonzept. Darin werden nicht nur die Daten klassifiziert (z. B. als «kritisch», wie Daten über Geschäftsprozesse), sondern auch festgelegt, wie sicher die Datenbank konfiguriert sein muss (Stichwort «hardening») und wer worauf Zugriff hat (Benutzer- und Rollenkonzept).

Um zu überprüfen, ob die getroffenen Sicherheitsmassnahmen greifen – ob etwa wirklich nur diejenigen User auf gewisse Daten zugreifen können, die das auch dürfen – muss das Sicherheitskonzept überwacht werden. Bei Oracle macht man das mithilfe des Datenbank-Audit, u. a. auch Oracle Unified Audit.

Oracle Unified Audit wurde mit Oracle 12c eingeführt und ist der künftige Standard für jegliches Datenbank-Audit. Es hat insbesondere 2 Vorteile: Erstens werden Audit Records neu nur noch an einem einzigen Ort gespeichert. Zweitens überwacht Oracle Unified Audit Manipulationsversuche am Audit, d. h., es zeichnet Änderungen an Audit-Einträgen, wie Löschungen, auf. Die Implementierung eines solchen Audit umfasst folgende Punkte:

Wahl resp. Konfiguration der Oracle-Audit-Methodik
Definition der Regel zur Überwachung mit Audit Policies
Housekeeping
Zentrale Auswertung und Integration der Audit-Daten, z. B. mit Hilfe der Integration in SYSLOG

Gerade der letzte Punkt ist wichtig: Die Integration der Audit Records in SYSLOG entkoppelt diese von der Datenbank, wodurch das Manipulationsrisiko verringert wird. Ausserdem kann man die Audit-Informationen so über mehrere Datenbanken hinweg sammeln und auswerten. Hinzu kommt, dass sich die Audit-Daten mithilfe von SYSLOG problemlos in Drittsysteme wie Kafka, Splunk oder Elastic Search integrieren lassen. Doch wie kannst du Oracle Unified Audit in SYSLOG integrieren? Schauen wir uns das zusammen an.

Noob Hack

Um Audit Event Records direkt an SYSLOG weiterzuleiten, stellt Oracle zwei Parameter zur Verfügung:

UNIFIED_AUDIT_SYSTEMLOG gibt an, ob Schlüsselfelder von Unified Audit Events an das SYSLOG geschickt werden. Dieser Parameter kann in einer Multitenant-Umgebung auch pro Pluggable Database (PDB) gesetzt werden.
UNIFIED_AUDIT_COMMON_SYSTEMLOG gibt an, ob Schlüsselfelder von Common Unified Audit Events an das SYSLOG geschickt werden. Dieser Parameter ist für Multitenant-Umgebungen und die global respektive common definierten Audit Policies.

In Abbildung 1 siehst du schematisch die Konfiguration von Oracle Unified Audit in einer Multitenant-Datenbank mit Common und Local User inklusive der Weiterleitung an SYSLOG. Für Single-Tenant-Datenbanken gilt analog die Konfiguration der Local User der blauen PDB02 in der Grafik:

_{Abbildung 1: Unified Audit in einer Multitenant-Datenbank.}

TIPP: Während in UNIFIED_AUDIT_TRAIL stets die kompletten Audit Records verfügbar sind, gibt es in SYSLOG lediglich reduzierte Informationen. Für eine direkte Überwachung oder Alarmierung reichen diese Informationen in der Regel aber aus. Details kann man im Anschluss an einen SYSLOG-Eintrag in der Datenbank abfragen, wenn man diese da noch nicht gelöscht hat.

Beginnen wir nun mit der eigentlichen SYSLOG-Konfigurierung und zwar in einer Multitenant-Datenbank. Im nachfolgenden Beispiel verwende ich RSYSLOG auf Oracle Enterprise Linux 7.

Als erstes müssen wir die entsprechenden SYSLOG Facilities definieren:

sudo vi /etc/rsyslog.conf *.info;mail.none;authpriv.none;cron.none;local2.none;local4.none /var/log /messages
# Unified Audit Rules
local2.info /var/log/oracle_common_audit_records.log
local4.info /var/log/oracle_audit_records.log
Dann starten wir den RSYSLOG-Service neu ...

sudo systemctl restart rsyslog.service... und implementieren eine Verbindung als SYS zu CDB$ROOT. Wir ändern zudem UNIFIED_AUDIT_COMMON_SYSTEMLOG sowie UNIFIED_AUDIT_SYSTEMLOG in der PDB1:

CONNECT / AS SYSDBA
SHOW PARAMETER unified_audit_common_systemlog
ALTER SYSTEM SET unified_audit_common_systemlog='local2.info' SCOPE= SPFILE;
ALTER SESSION SET CONTAINER=PDB1;
ALTER SYSTEM SET unified_audit_systemlog='local4.info' SCOPE=SPFILE;
Nun starten wir die gesamte Container-Datenbank neu:

CONNECT / AS SYSDBA STARTUP FORCE; SHOW PARAMETER unified_audit ®TIPP: Bei einer Single-Tenant-Datenbank (Local User) umfasst die Konfiguration nur den Parameter UNIFIED_AUDIT_SYSTEMLOG.

Nachdem wir nun den Audit in SYSLOG integriert haben, kannst du deine Audit Policies sowie die Audit Events testen. Wie das geht, zeige ich dir im nachfolgenden Pro Hack.

Noch ein nützlicher Oracle-Hack:

Wie verwaltet man ein Datenbank-Namensverzeichnis mit möglichst wenig Aufwand?

Zum Beispiel indem man einen 389 Directory Server benutzt.

In diesem Artikel erfährst du, wie man einen solchen Server für eine Oracle-Datenbank installiert.

Pro Hack

Wie in Abbildung 1 gezeigt, macht die Unterscheidung von Common und Local User vor allem in Multitenant-Datenbanken Sinn. Hier hat man die Möglichkeit die beiden Typen von Benutzer zu unterscheiden und entsprechende Audit Events separat zu protokollieren. Im Folgenden testen wir zuerst Audit Policies und dann Audit Events – einmal über ein Login als Common User, dann über ein Login als Local User.

Fürs Testen der Audit Policies erstellen wir als Beispiel eine Common Audit Policy im Root Container der Multitenant-Datenbank ...

CONNECT / AS SYSDBA
CREATE AUDIT POLICY tvd_com_logon ACTIONS LOGON CONTAINER=ALL;
AUDIT POLICY tvd_com_logon;

In der Pluggable Datenbank PDB1 definieren wir eine weitere Policy:

CONNECT / AS SYSDBA
ALTER SESSION SET CONTAINER=pdb1;
CREATE AUDIT POLICY tvd_loc_logon ACTIONS LOGON;
AUDIT POLICY tvd_loc_logon;

Um zu kontrollieren, welche Audit Policies aktiviert sind, tun wir Folgendes:

SET LINESIZE WINDOW
COL policy_name FOR A14
COL entity_name FOR A20
SELECT * FROM audit_unified_enabled_policies;
POLICY_NAME ENABLED_OPTION ENTITY_NAME ENTITY_ SUC FAI
TVD_COM_LOGON BY USER ALL USERS USER YES YES
TVD_LOC_LOGON BY USER ALL USERS USER YES YES

Login als Common User

TIPP: Um für saubere Testbedingungen zu sorgen und besser zu sehen, was du für den Test im Audit einträgst, empfehle ich den UNIFIED_AUDIT_TRAIL im Root Container CDB$ROOT sowie in der Pluggable Datenbank PDB1 zu löschen, bevor du den Code zum Testen ausführst:

CONNECT / AS SYSDBA
BEGIN
dbms_audit_mgmt.clean_audit_trail( audit_trail_type => dbms_audit_mgmt.audit_trail_unified, use_last_arch_timestamp => FALSE);
END;
/
ALTER SESSION SET container=PDB1;
BEGIN
dbms_audit_mgmt.clean_audit_trail( audit_trail_type => dbms_audit_mgmt.audit_trail_unified, use_last_arch_timestamp => FALSE);
END;
/

Nun erstellen wir einen Audit Event in der PDB1:

CONNECT system@TCIS19C

Anschliessend können wir UNIFIED_AUDIT_TRAIL in der PDB1 abfragen.

TIPP: Wenn du die Abfrage standardmässig mit SQLPlus machst, kannst du zuerst den nachfolgenden Code-Block für eine schönere Darstellung kopieren:

SET LINESIZE 160 PAGESIZE 200
COL event_timestamp FOR A20
COL dbusername FOR A10
COL os_username FOR A10
COL action_name FOR A20
COL return_code FOR 999999
COL object_name FOR A20
COL unified_audit_policies FOR A30

SELECT
to_char(event_timestamp,'dd.mm.yyyy hh24:mi:ss') event_timestamp,
sessionid,
dbusername,
os_username,
action_name,
return_code,
object_name,
unified_audit_policies
FROM unified_audit_trail
ORDER BY event_timestamp;
EVENT_TIMESTAMP SESSIONID DBUSERNAME ACTION_NAME OBJECT_NAME UNIFIED_AUDIT_POLICIES
01.09.2022 07:05:01 4036001073 SYS EXECUTE DBMS_AUDIT_MGMT
01.09.2022 07:05:26 1521526562 SYSTEM LOGON TVD_COM_LOGON
01.09.2022 07:05:40 1430860507 SYS LOGOFF BY CLEANUP

Um die SYSLOG-Datei zu kontrollieren, führen wir folgende Schritte aus:

host sudo grep -i 1521526562 /var/log/oracle_common_audit_records.log
Apr 1 07:05:26 localhost journal: Oracle Unified Audit[10178]: LENGTH: '204'
TYPE:"4" DBID:"1612911514" SESID:"1521526562" CLIENTID:"" ENTRYID:"1”
STMTID:"1" DBUSER:"SYSTEM" CURUSER:"SYSTEM" ACTION:"100" RETCODE:"0"
SCHEMA:"" OBJNAME:"" PDB_GUID:"86B637B62FDF7A65E053F706E80A27CA"

Login als Local User

Um den Login als Local User zu testen, erstellen wir einen Audit Event in der PDB1 und loggen uns als Benutzer SCOTT ein:

CONNECT scott/tiger@pdb1.trivadislabs.com

Dann fragen wir UNIFIED_AUDIT_TRAIL in der PDB1 ab:

SELECT
to_char(event_timestamp,'dd.mm.yyyy hh24:mi:ss') event_timestamp,
sessionid,
dbusername,
os_username,
action_name,
return_code,
object_name,
unified_audit_policies
FROM unified_audit_trail
ORDER BY event_timestamp;
EVENT_TIMESTAMP SESSIONID DBUSERNAME ACTION_NAME OBJECT_NAME UNIFIED_AUDIT_POLICIES
01.09.2022 07:19:16 3934031462 SYS EXECUTE DBMS_AUDIT_MGMT TVD_LOC_LOGON
01.09.2022 07:19:45 2440243087 SYSTEM LOGON TVD_LOC_LOGON, TVD_COM_LOGON
01.09.2022 07:21:08 2448415323 SCOTT LOGON TVD_LOC_LOGONZum Schluss kontollieren wir die SYSLOG-Datei erneut:

host sudo grep -c -i 2448415323 /var/log/oracle_common_audit_records.log 0
host sudo grep -i 2448415323 /var/log/oracle_audit_records.log
Apr 1 07:21:08 localhost journal: Oracle Unified Audit[11705]: LENGTH: '201'
TYPE:"4" DBID:"817014372" SESID:"2448415323" CLIENTID:"" ENTRYID:"1" STMTID:"1"
DBUSER:"SCOTT" CURUSER:"SCOTT" ACTION:"100" RETCODE:"0" SCHEMA:"" OBJNAME:""
PDB_GUID:"B8E3D716A96C1507E0530100007F363B"

Fazit

Geschafft! In diesem Hack haben wir zusammen einen Oracle Unified Audit in SYSLOG integriert und sowohl Audit Policies als auch Audit Events für Common und Local User erstellt respektive getestet.
Die Integration in SYSLOG bringt insbesondere folgende Vorteile:

Wir haben die Audit-Daten von der Datenbank entkoppelt, und sie stehen uns nun in reduzierter Form in SYSLOG zur Verfügung. Die vollumfänglichen Audit-Daten sind immer noch im Unified Audit drin und stehen da für umfassende Auswertungen via SQL zur Verfügung.
Von SYSLOG aus können wir die Audit-Daten ganz einfach an Drittsysteme wie Kafka, Elastic Search oder Splunk weiterleiten. Damit Kafka oder Elastic Search die Daten direkt aus der Datenbanken lesen könnten, müsste ich mithilfe von JDBC direkt auf die Datenbank zugreifen und die entsprechende Abfrage selber entwicklen. Bei Splunk müsste man ebenfalls selbst den Zugriff via JDBC Implementieren oder den Splunk Agent für Oracle kaufen. SYSLOG hingegen kann ich relativ einfach und ohne zusätzliche Lizenzkosten nutzen.