Auditing für Oracle-Datenbanken nach der Härtung
Das Thema Sicherheit ist in aller Munde, nicht nur im IT-Umfeld. Bei Datenbanken geht es dann aber oftmals um das passende Berechtigungskonzept. Dort hört die Arbeit aber nicht auf, die Einhaltung des Konzepts und die zweckkonforme Anwendung der vergebenen Rechte müssen auch kontrolliert werden. Genau darum dreht es sich beim Auditing. Ich werde das Thema hier speziell für Oracle-Datenbanken näher beleuchten. Die Grundideen sind aber sicherlich übertragbar.
Im Grunde geht es beim sicheren Betrieb von Datenbanken (und auch anderen Systemen) um zwei Dinge: Berechtigungen verwalten und Berechtigungen überwachen.
Beim Verwalten der Berechtigungen dreht sich alles um das Einschränken der Möglichkeiten. Es wird also festgelegt, wer etwas tun darf und was er tun darf. Dabei wird meist das "Principle of Least Privilege" zur Anwendung gebracht, man vergibt also so wenig Berechtigungen wie möglich, aber so viele und so umfangreich wie nötig. So kann möglicher Schaden schon im Vorfeld abgewendet werden, wenn die Datenbankbenutzer überhaupt nicht über die nötigen Rechte verfügen, um Schaden anzurichten.
Das Überwachen der Berechtigungen hingegen befasst sich dann praktisch mit den Auswirkungen der vergebenen Rechte. Es geht darum, wer, wann, was gemacht hat. So kann man jederzeit nachvollziehen, welche Benutzer ihre erhaltenen Berechtigungen für welche Aktivitäten benutzt haben oder versucht haben zu benutzen. Auf diese Weise können Angriffe möglicherweise schon im Vorfeld erkannt werden, beispielsweise durch fehlgeschlagene Logins, oder man kann zumindest im Nachgang nachvollziehen, wie und durch wen der Angriff genau erfolgt ist. Genau das ist die Aufgabe des Auditings um das es hier gehen soll.
Abb. 1 zeigt die Rollenverteilung im Datenbankumfeld. Es gibt zwei nebenläufige Rollen: eine, die das Regelwerk vorgibt, also sowohl für das Rechtekonzept als auch für die entsprechenden Überwachungsregeln verantwortlich zeichnet, und eine, die die anfallenden Daten der Überwachung auswertet. Darüber hinaus gibt es eine ganze Reihe von administrativen Rollen, die für den Betrieb erforderlich und damit für die Umsetzung des Regelwerks verantwortlich sind.
Auditing-Methoden
Oracle-Datenbanken bringen aus der Historie verschiedene Arten von Auditing mit. In der Welt vor Version 12.1 gab es das klassische Auditing, Fine Grained Auditing und SYS Auditing um nur einige zu nennen. Die gesammelten Auditinformationen wurden an verschiedenen Stellen abgelegt. Daher wurden all diese verschiedenen sogenannten Audit-Trails wieder in ein einziges Audit-Trail zusammengeführt. Diese Art von Auditing nennt Oracle nun "Unified Auditing". Das altherkömmliche Auditing ist aus Kompatibilitätsgründen immer noch vorhanden, ist aber mit der Version 21 abgekündigt [1] und wird somit in zukünftigen Versionen nicht mehr unterstützt werden. Dementsprechend wird diese Altlast hier außen vorgelassen.
Das Unified Auditing hat gegenüber dem herkömmlichen Auditing noch weitere Verbesserungen erfahren. So werden die Audit-Daten nun in einem separaten Schema abgelegt, das besonders geschützt ist. Der SYS-Benutzer kann somit die Daten nicht mehr direkt verändern. Die Auditierung wird nun über Policies gesteuert, die dann entsprechend verschiedenen Datenbankbenutzern zugeordnet werden können, ähnlich dem Rollenkonzept für Berechtigungen. Außerdem ist es nun möglich, nur unter bestimmten Bedingungen Audit-Daten zu generieren und bestimmte Komponenten zu auditieren. Darauf wird später noch eingegangen.
Vorbereitungen
Nach der Installation der Oracle-Datenbank-Software arbeitet diese zuerst einmal im Mixed-Mode, d. h. sowohl altherkömmliches als auch das Unified Auditing sind aktiv. Wenn nun das Unified Auditing verwendet werden soll, um Aktivitäten zu protokollieren, dann empfiehlt es sich, ausschließlich das Unified Auditing zuzulassen. Dazu sind folgende Schritte notwendig:
- Ggf. laufende Datenbanken stoppen,
- in das lib-Verzeichnis wechseln,
- Datenbank-Software mit reinem Unified Auditing neu linken und
- gestoppte Datenbanken wieder starten.
Das sieht dann beispielsweise so aus wie in Listing 1:
Listing 1: Aktivierung des reinen Unified Auditing
export ORACLE_HOME=<Pfad zur Oracl Installation>
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracleDatenbankseitig sind ebenfalls einige Vorbereitungen zu treffen. Es ist zu empfehlen, die Audit-Daten in einem eigenen Tablespace abzulegen, der natürlich anzulegen ist. Das Audit muss dann auf diesen Tablespace umgelenkt werden. Außerdem sind noch folgende weitere Schritte notwendig oder empfehlenswert:
- Herkömmliches Auditing deaktivieren,
- standardmäßige Unified Audit Policies deaktivieren (Warum das sinnvoll ist, erklärt sich im Folgenden),
- Audit-Management initialisieren und
- Audit Trail leeren, um einen konsistenten Start zu erhalten.
Die ganze Verwaltung der Audit Trails erfolgt über das Package DBMS_AUDIT_MGMT, die eben erläuterten Schritte werden also entsprechend Listing 2 durchgeführt.
Listing 2: Vorbereiten der Datenbank
-- herkömmliches Audit deaktivieren
NOAUDIT ALL;
-- Standard Unified Audit Policies dektivieren
NOAUDIT POLICY ORA_SECURECONFIG;
NOAUDIT POLICY ORA_LOGON_FAILURES;
BEGIN
-- Audit Management initialiseren
DBMS_AUDIT_MGMT.INIT_CLEANUP(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
default_cleanup_interval => 24
);
-- Audit Trail leeren
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
use_last_arch_timestamp => FALSE
);
-- Neuen Tablespace festlegen
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
audit_trail_location_value => 'AUDSYS'
);
END;
/Damit sind alle notwendigen Vorbereitungen getroffen, um das eigene Audit-Konzept umzusetzen. Die vorgenommenen Einstellungen finden sich u. a. in der View DBA_AUDIT_MGMT_CONFIG_PARAMS wieder.
Audit-Konzept erstellen
Um ein sinnvolles Audit-Konzept zu erarbeiten, stelle man sich zunächst die Frage, was alles potenziell Schaden anrichten kann. Für die Oracle-Datenbank kommen da einige allgemeine Dinge in Frage:
- Alle Aktivitäten als Benutzer SYS.
- Änderungen am System (ALTER DATABASE, ALTER SYSTEM).
- Änderungen an Benutzern/Rollen (CREATE, ALTER, DROP USER, ROLE).
- Änderungen an Berechtigungen (GRANT, REVOKE).
- Änderungen am Auditing (AUDIT, NOAUDIT).
- Anmeldungen an der Datenbank.
- Änderungen an Wallets für Verschlüsselung (ADMINISTER KEY MANAGEMENT).
- Alle ANY-Privilegien.
Dabei ist es bei allen aufgezählten Aktivitäten egal, durch wen sie durchgeführt wurden. Auch das ist ein Kriterium bei der Erstellung des Konzepts. Zusätzlich müssen noch applikationsspezifische Aktivitäten beleuchtet werden, wie z. B.
- Änderungen an sensitiven oder kritischen Objekten und
- Zugriffe und/oder Änderungen an sensitiven Inhalten.
Aus diesen ermittelten Rahmenbedingungen ergibt sich dann das finale Audit-Konzept und daraus wiederum die passende Definition der Audit-Policies sowie deren Aktivierung und Zuweisung zu Datenbankbenutzern. Im Grunde besteht die Umsetzung des Audit-Konzepts in der Datenbank aus zwei Schritten pro Regel. Zuerst wird die Audit-Policy erstellt. Dabei wird festgelegt, welche Aktivitäten auditiert werden sollen. Im zweiten Schritt wird diese Policy dann entsprechenden Datenbankbenutzern zugewiesen und damit aktiviert. Listing 3 zeigt die Erstellung und Aktivierung der ersten sieben allgemeinen Regeln.
Listing 3: Erstellen und Aktivieren der allgemeinen Audit-Policies
-- Regel 1: Alles, was SYS tut
create audit policy AP_SYS_OPERATIONS
actions
all;
audit policy AP_SYS_OPERATIONS by SYS;
-- Regel 2: Änderungen am System
create audit policy AP_SYSTEM_MGMT
actions
create spfile,
alter system,
alter database;
audit policy AP_SYSTEM_MGMT;
-- Regel 3: Änderungen an Benutzern / Rollencreate audit policy AP_USER_ROLE_MGMT
actions
create user, alter user, drop user,
create role, alter role, drop role, set role;
audit policy AP_USER_ROLE_MGMT;
-- Regel 4: Änderungen an Berechtigungen
create audit policy AP_PRIVILEGE_MGMT
actions
grant,
revoke;
audit policy AP_PRIVILEGE_MGMT;
-- Regel 5: Änderungen am Audit
create audit policy AP_AUDIT_MGMT
actions
audit, noaudit,
create audit policy,
alter audit policy,
drop audit policy;
audit policy AP_AUDIT_MGMT;
-- Regel 6: An- und Abmeldungen an der Datenbank
create audit policy AP_LOGON_LOGOFF
actions
logon,
logoff;
audit policy AP_LOGON_LOGOFF;
-- Regel 7: Änderungen an Wallets
create audit policy AP_WALLET_MGMT
actions
administer key management;
audit policy AP_WALLET_MGMT;Interessant wird es nun beim Erstellen der Policy zur Überwachung aller ANY-Privilegien. Davon gibt es eine ganze Menge und es variiert auch von Version zu Version. Die Lösung ist aber einfach. Statt eines statischen Statements zur Erstellung der Policy wird dieses einfach dynamisch mit allen in der aktuellen Datenbank zulässigen ANY-Privilegien erzeugt, s. Listing 4.
Listing 4: Erstellen und Aktivieren der Audit-Policy für ANY-Privilegien
declare
do_create boolean := true;
do_sql varchar2(1000);
begin
for privs in (select name from system_privilege_map where name like '% ANY %') loop
if do_create then
do_sql := 'create audit policy AP_ANY_PRIVS privileges ' || privs.name;
do_create := false;
else
do_sql := 'alter audit policy AP_ANY_PRIVS add privileges ' || privs.name;
end if;
begin
execute immediate do_sql;
exception
when others then
dbms_output.put_line('skipping privilege "' || privs.name || '" due to: ' || SQLERRM);
end;
end loop;
end;
/
Für die applikationsspezifischen Audit-Einstellungen können hier keine konkreten Aussagen getroffen werden. Ein paar Beispiele sollen aber eine Idee über die generellen Möglichkeiten liefern. In Listing 5 wird eine Policy erstellt, die Zugriffe auf eine spezielle Tabelle überwacht und eine Bedingung enthält, so dass nur dann auditiert wird, wenn der angemeldete Datenbankclient eine "JDBC-Thin"-Connection verwendet.
Listing 5: Beispiel einer applikationsspezifischen Audit-Policy
-- Lesezugriffe auf EMPLOYEES Tabelle auditieren
create audit policy AP_ACCESS_APP
actions
select on HR.EMPLOYEES;
-- zusätzlich auch DML auf der Tabelle überwachen
alter audit policy AP_ACCESS_APP
add actions
insert, update, delete on HR.EMPLOYEES;
-- Nur auditieren, wenn es eine JDBC-Thin Connection ist
alter audit policy AP_ACCESS_APP
condition
'SYS_CONTEXT(''USERENV'', ''CLIENT_IDENTIFIER'') = ''jdbc-thin'''
evaluate per session;
-- Policy für alle Benutzer aktivieren
audit policy AP_ACCESS_APP;Auswerten der Audit-Daten
Nun sammelt man Audit-Daten aus einem bestimmten Grund: Man will daraus Informationen gewinnen. Wie also wertet man die gesammelten Audit-Daten aus? Im Grunde gibt es dafür mit dem Unified Auditing nur eine einzige Stelle der Wahrheit, die View UNIFIED_AUDIT_TRAIL. Aber aufgepasst, mit der Einführung des Unified Auditing in der Version 12.1 hat Oracle die Audit-Informationen als XML in einem LOB abgelegt. Bei entsprechend großen Datenmengen können Abfragen gegen diese View mehrere Minuten dauern. Oracle beschreibt das Problem in My Oracle Support[2]. Daher wurde mit Version 12.2 die Speicherung in ein relationales Modell überführt. Datenbanken, die ab Version 12.2 neu angelegt werden, erhalten sofort diese Art der Speicherung. Datenbanken, die mit 12.1 angelegt und dann lediglich per Upgrade auf höhere Versionen gebracht wurden, behalten die alte Art der Speicherung bei. Es ist daher erforderlich, die Daten manuell in eine relationale Speicherung zu überführen. Dieser Prozess ist ebenfalls in My Oracle Support[3] beschrieben.
Für die eigentliche Auswertung der Audit-Daten bilden die persönlichen SQL-Kenntnisse sowie die eigene Kreativität die Grenzen. Es ist schwierig, allgemeine Vorschläge zur Auswertung zu machen, denn oft entsteht der eigentliche Bedarf erst nach einem konkreten Problemfall oder ergibt sich implizit aus den definierten Regeln. Das generelle Vorgehen soll durch zwei einfache Beispiele erläutert werden. Beispiel 1 in Abb. 2 zeigt offenbar einen Versuch, sich als Benutzer SYSTEM Zugang zur Datenbank zu verschaffen. Das mündet zuerst in einem ORA-1017, also "Benutzer oder Passwort falsch" und führt dann nach 10 fehlgeschlagenen Versuchen zur Sperrung des Accounts, ersichtlich aus dem ORA-28000. Das zweite Beispiel zeigt, wie ein Benutzer seine ANY-Privilegien ausnutzt, um zuerst an Tabellennamen eines anderen Schemas zu gelangen und anschließend dort Dateninhalte zu verändern.
Mehr soll an dieser Stelle nicht erläutert werden, denn die möglichen Auswertungen verschiedener Szenarien sind enorm umfangreich.
Housekeeping
Zu guter Letzt soll es noch um das Housekeeping gehen. Es kann vorkommen, dass doch Dateien im Betriebssystem abgelegt werden, anstatt direkt in der Datenbank. Das passiert immer dann, wenn die Daten nicht in die Datenbank geschrieben werden können, also z. B. wenn diese nicht zum Schreiben geöffnet ist oder schlicht der Tablespace, in dem die Audit-Daten abgelegt werden sollen, voll ist. Dieser Mechanismus verhindert, dass Audit-Daten verloren gehen, weil sie nicht geschrieben werden können. Die Dateien werden als Spillover-Files bezeichnet und im Verzeichnis $ORACLE_BASE/audit/$ORACLE_SID abgelegt. Ist die Datenbank zu einem späteren Zeitpunkt wieder beschreibbar, dann lassen sie diese Spillover-Files mit der Prozedur DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES in die Datenbank laden. Dabei können entweder alle Informationen oder nur die einer bestimmten Pluggable Database geladen werden.
Nachdem nun jede Menge Daten in der Datenbank angekommen sind, müssen diese auch irgendwann wieder daraus verschwinden. Auch dafür bringt das Package DBMS_AUDIT_MGMT Funktionen mit. Um die Audit-Daten wieder loszuwerden, gibt es zwei Möglichkeiten. Entweder man löscht alle Audit-Daten, die es gibt oder man behält alle Audit-Daten bis zu einem bestimmten Zeitpunkt und löscht alles, was älter ist. Letztere Möglichkeit ist gedacht, um Audit-Daten in ein externes System zu archivieren und erst danach aus der Datenbank zu löschen. Diese Methode ist auch ohne ein externes System zur Langzeitarchivierung zu empfehlen, da so zumindest ein definiertes Zeitfenster an Audit-Daten immer verfügbar ist.
Um das zu verwirklichen, braucht es nur zwei Aufrufe des DBMS_AUDIT_MGMT-Packages. Einer setzt den Zeitstempel der letzten Archivierung, der andere führt das Löschen durch, wie in Listing 6 gezeigt. Dieses Codeschnipsel kann dann per Datenbank-Scheduler regelmäßig ausgeführt werden.
Listing 6: Purging des Unified Audit Trails
BEGIN
-- Lesezugriffe auf EMPLOYEES Tabelle auditieren
DBMS_AUDIT_MGMT.SET_LAST_ARCHIVE_TIMESTAMP(
AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED,
LAST_ARCHIVE_TIME => SYSTIMESTAMP - <Zeitfenster in Tagen>
);
-- Audit Trail leeren
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
use_last_arch_timestamp => TRUE
);
END;Initial muss das Purging einmal initialisiert werden, das wurde bereits bei den Vorbereitungen der Datenbank erledigt. Da die Löschprozedur auf dem Droppen von Tabellenpartitionen basiert, kann es mit dem Standardintervall der Partitionierung von einem Monat eine ganze Weile dauern, bis wirklich Daten gelöscht und wieder Platz freigegeben wird. Daher empfiehlt es sich, das Intervall auf ein kürzeres Intervall wie einen Tag oder zumindest eine Woche zu setzen. Wie das gemacht wird, zeigt Listing 7. Das neue Intervall wirkt aber erst dann, wenn der aktuelle Monat vorbei ist und eine neue Partition angelegt werden muss. Es sollte also direkt bei der Vorbereitung der Datenbank ein praktikables Intervall gewählt werden.
Listing 7: Anpassen des Partitionierungsintervalls
BEGIN
DBMS_AUDIT_MGMT.ALTER_PARTITION_INTERVAL(
interval_number => 1,
interval_frequency => 'DAY'
);
END;Oracle bietet auch die Möglichkeit, direkt über das Package einen Purge-Job zu erstellen. Dann existieren aber zwei Datenbank-Jobs für das Purging, einer zum Setzen des Zeitstempels und einer zum eigentlichen Löschen, was die Sache nicht unbedingt übersichtlicher macht.
Zusammenfassung
Auditing ist ein weites Feld im Dunstkreis der Sicherheitsfeatures welches hin und wieder vernachlässigt wird. Im Artikel wurde gezeigt, was eine Oracle-Datenbank für Möglichkeiten dafür bietet und wie man diese zum Einsatz bringt. Außerdem finden sich einige Anregungen, wie ein erstes Basiskonzept zum Auditing aussehen kann und wie man dieses dann umsetzt.
- Oracle – Database 21c Upgrade Guide: Deprecation of Traditional Auditing
- Oracle – Performance Issues While Monitoring the Unified Audit Trail of an Oracle12c Database (Doc ID 2063340.1)
- Oracle – How To Transfer Unified Audit Records To An Internal Relational Table (Doc ID 2212196.1)
