Vertrauen ist gut, Kontrolle ist besser: Audit von Db2 LUW Datenbanksystemen – Schritt für Schritt erklärt

Teil 2: Audit der Datenbank

Wie andere Datenbanksysteme auch, stellt Db2 eine Audit Komponente (IBM bezeichnet sie als Audit Facility) bereit, die zum Erkennen von unerwarteten und unbekannten Zugriffen auf die Db2 Instanzen und Datenbanken dient. Im ersten Teil wurde die Einrichtung für die Instanz Schritt für Schritt beschrieben. Im zweiten Teil geht es um die Datenbank an sich.

Beim Auditieren einer Datenbank werden mit Hilfe von definierten Prüfrichtlinien (sogenannten Policies), Prüfprotokolle (Audit Records) generiert und diese dann in Dateien abgelegt.

Mit den "Policies" definiere ich, was ich auditieren möchte. Die Ergebnisse dieser Abfragen werden dann für jede Datenbank in separate Records geschrieben, ähnlich wie bei der Db2 Instanz. Es werden dazu, die innerhalb der Instanz definierten Verzeichnispfade verwendet, beispielsweise:

Audit Data Path: "/auditdata"
Audit Archive Path: "/auditarchive"

Eine Unterscheidung der Audit Dateien von Datenbanken und Instanz ist anhand der Dateinamen möglich, wie im folgenden Beispiel unten erklärt wird. Bei den Datenbanken wird genauso vorgegangen, wie bei der Instanz: Das Abhängen der Datenströme entspricht der Archivierung und dem Versand der Dateien.

Das Versenden erfolgt dann mithilfe einer Sendedatei, wie im Teil 1 (Schritt 3) ausführlich beschrieben wurde. Dabei sollten alle Dateien als ein Packet zur Auswerteeinheit übertragen werden.
Dateinamen der aktiven Dateien:

• db2audit.db.DBNAME1.log.0

• db2audit.db.DBNAME2.log.0
  

• db2audit.db.INSTANZNAME.log.0

Dateinamen der archivierten Dateien:

• db2audit.db.DBNAME1.log.0.timestamp

• db2audit.db.DBNAME2.log.0.timestamp

• db2audit.db.INSTANZNAME.log.0.timestamp

Schritt 1: Was kann auditiert werden? 

Wie oben erwähnt, kann der Sicherheitsadministrator (secadm) mithilfe von Prüfrichtlinien (Policies) die Prüffunktionen so konfigurieren, dass entweder alles oder nur diejenigen Daten, Objekten und Zugriffe erfasst werden, die zur Erfüllung der Auditanforderung benötigt werden.

Folgende Optionen sind möglich:

• Gesamte Datenbank: Alle Ergeignisse, die auf der Datenbank auftreten und prüfbar sind werden entsprechend der Policy protokolliert.

• Tabellen: Alle DML- und XQUERY-Zugriffe werden protokolliert.

• Trusted Context: Alle prüfbaren Ergebnisse, die in Verbindung mit einem gesicherten Kontext auftreten, werden entsprechend der Prüfrichtlinie geprüft.

• Berechtigungen von Benutzer, Gruppen und Rollen: Alle prüfbaren Ergebnisse, die von Benutzern, Gruppen und Rollen eingeleitet werden, werden geprüft.

• Berechtigungen SECADM, DBADM, SQLADM, WLMADM, ACCESCTRL, DATAACCES, SYSADM, SYSCTRL, SYSMAINT, SYSMON: Alle prüfbaren Ergebnisse werden protokolliert.
  

Schritt 2: Definition der Prüfrichtlinien für die Datenbanken

Die Option "categories" gibt an, aus welchen Kategorien gesammelt werden soll:

• all: Alle Kategorien

• audit: Wenn die Auditeinstellungen verändert werden oder auf das Audit Log zugegriffen wird.

• checking: Berechtigungsprüfung bei Versuchen, Datenbankobjekten aufzurufen oder zu bearbeiten.

• context: Generiert Datensätze, wenn Datenbankoperationen ausgeführt werden.

• execute: Generiert Datensätze zum Anzeigen der SQL- Anweisung. Hier gibt es zwei Möglichkeiten: Es kann nur das SQL Statement auditiert werden, was die Default Einstellung ist oder die SQL-Anweisung und zusätzlich die Ausgegebenen Datensätze.

• obmaint: Generiert Datensätze, wenn Datenbankobjekte erstellt oder gelöscht werden.

• secmaint: Erstellt Datensätze, wenn Operationen, Objektberechtigungen oder das Recht DBADM erteilt oder entzogen werden.

• sysadm: Wenn Operationen SYSADM-, SYSCTRL- oder SECMAINT-Rechte erfordern.

• validate: Wenn Benutzer authentifiziert werden oder wenn Sicherheitsdaten abgerufen werden.

Die Option "status" gibt an, ob bei Erfolg oder bei Fehlschlag Audit-Daten gesammelt werden sollen:

• both: Es wird bei Erfolg und Fehlschlag gesammelt.

• none: Es wird in keinem Fall gesammelt. Das kann bei Tests sinnvoll sein.

• failure: Es wird nur bei Fehlschlag gesammelt.

• success: Es wird nur bei Erfolg gesammelt.

Die Option "errortype" gibt an, bei welchen Fehlercodes gesammelt werden sollen:

• audit: Alle Fehler, also auch audit Fehler und alle negativen SQLCODES.

• normal: nur negativen SQLCODES.

Hier die allgemeine Syntax zur Definition einer Prüfrichtlinie:

create audit policy <Name> categories <all> status <both> error type <audit>

Schritt 3: Policies in der Datenbank erstellen und nutzen

Mit der Audit Policy definiere ich, was auf Datenbankebene auditiert werden soll. Mit dem Befehl "audit..." starte ich die Datenbank Auditierung, wie die folgenden zwei Beispielen beschreiben:

Beispiel 1: Es sollen alle Aktionen auditiert werden, die durch Personen mit der Berechtigung SYSADM, SECADM oder DBADM vorgenommen werden. Um dies zu realisieren, benötigt man die beiden Kategorien "Sysadm" und "Execute" zum Loggen der SQL-Anweisungen. Es sollen erfolgreiche und fehlerhafte Operationen auditiert werden (Status "both"). Die Policy bekommt den Namen "admins".

Der Sicherheitsadministrator SECADM ordnet im Anschluss dann die Prüfrichtlinie "audit …." den Berechtigungen SYSADM, DBADM, SECADM zu.

create audit policy admins categories execute status both, sysadmin status both error type audit
commit
audit sysadm, dbadm, secadm using policy admins
commit
 

Beispiel 2: Es sollen alle erfolgreichen und fehlerhaften Zugriffe auf die Datenbank mitgeloggt werden. Hier benötigt man die Kategorie "context" und "validate". Die Policy bekommt die Bezeichnung "login_logout". Die Rolle "role_users" muss vorher angelegt werden und den jeweiligen Benutzern und Gruppen zugewiesen werden.

create audit policy login_logout categories context status both, validate status both, checking status both error type audit
commit
audit role_users using policy login_logout
commit
 

Schritt 4: Audit stoppen und Policy entfernen

Wie beim Aufsetzen des Audits, kann ich auch das Audit ganz oder teilweise beenden. Es reicht dabei nicht, ein "db2audit stop" abzusetzen, sondern ich muss auf den Datenbanken die Policys entfernen. Mit "remove policy" wird die Prüfrichtlinie aus dem angegebenen Objekt entfernt. Ab diesem Moment findet die Protokollierung nicht mehr statt. Die Zuordnung wird aus dem Systemkatalog entfernt. Anschließend kann man die "Policy" löschen ("droppen").

Beispiel 1: Anhand des ersten Beispiels aus dem vorigen Abschnitt, wird hier das Entfernen der Audit Policy dargestellt.

audit sysadm remove policy
audit dbadm remove policy
audit secadm remove policy
drop audit policy admins
 

Schritt 5: Audit überprüfen und überwachen

Um die Definition der Policies auf Datenbankebene zu überprüfen, stehen im Systemkatalog der Db2 Datenbank die Tabellen "auditpolicies" und "audituse" im Schema "syscat" zur Verfügung. Die Tabellen haben die folgenden Spaltendefinitionen:

Schritt 6: Audit überprüfen und überwachen

Zum Abschluss noch ein Tipp: Sollten wider Erwarten die Auditrecords zu groß werden, so dass es Probleme beim Übertragen der Daten gibt, dann bietet der Support von IBM verschiedene, auf die Auditierung zugeschnittene Umgebungsvariable an, um die Dateigrößen in Grenzen zu halten. Im konkreten Fall aus der Praxis bei einem Kunden, hat die Kategorie "context db2hmon" zu viele Daten geschrieben, die zur Auswertung nicht benötigt wurden. Aus diesem Grund wurde die Ausgabe des db2hmon durch die Umgebungsvariable begrenzt:

db2set DB2_LIMIT_AUDIT_APPS=DB2HMON

Fazit 

Die Db2 Audit Facility ist sehr umfangreich und mächtig. Sie bietet die Möglichkeit, sowohl auf Instanz- wie auch auf Datenbankebene unabhängig zu auditieren. Durch Anlegen von Prüffunktionen, kann das Audit auf die speziellen Erfordernisse angepasst werden. Die Prüfprotokolle sind eindeutig strukturiert, was die Arbeit und das Monitoring angenehm macht.