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

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.
Durch das Hinterlegen von Prüffunktionen werden Prüfprotokolle (sogenannte Audit Records) erzeugt. Diese werden am einfachsten ins Syslog des Betriebssystems importiert und an externe Auswertetools weitergegeben, welche dann die Daten nach bestimmten Auswertemustern durchsuchen.
In dieser Artikelserie werde ich die Einrichtung des Audits Schritt für Schritt erklären und dabei auf die wichtigsten Problemstellen eingehen. Im ersten Teil konzentrieren wir uns zunächst auf die Instanz, im zweiten Teil dann auf eine Datenbank.

Schritt 1: Ein Puffer im Hauptspeicher sorgt für mehr Performance

Alle Prüfprotokolle werden in Dateien zwischengespeichert, bevor diese an das Syslog (oder alternative Ziele) übergeben werden. Das Standardverhalten ist dabei eine synchrone Speicherung, analog zum Transaktionsprotokoll, da auch bei einem Systemabsturz keine Daten verloren gehen dürfen.

Um einen negativen Einfluss des Audits auf die Performance zu verhindern, kann jedoch ein Puffer im Hauptspeicher eingerichtet werden, der bei hoher Last einige Prüfprotokolle zwischenspeichern kann.

Der Instanzparameter hat die Bezeichnung AUDIT_BUF_SZ. Der Wert wird in Datenbankseiten angegeben, die bei Db2 jeweils 4 Kilobyte groß sind. Zur Konfiguration eines 8 Megabyte großen Puffers wird also der folgende Befehl verwendet:

db2 update dbm cfg using audit_buf_sz 2048

Hierbei ist zu beachten, dass es nun bei einem Absturz der Db2-Instanz zu einem Verlust von Prüfprotokollen kommen kann, da durch das "buffern" die Informationen eben nicht mehr synchron geschrieben werden.

Schritt 2: Konfiguration der benötigten Verzeichnisse

Für die Aktivierung der Audit-Funktionalität werden zwei Verzeichnisse benötigt: Eines für die aktuell geschriebenen Prüfprotokolle, ein weiteres für die bereits versendeten Prüfprotokolle (als lokales Archiv).

Auf diese Verzeichnisse dürfen unbedingt nur berechtigte Personen zugreifen. Die Zugriffsrechte sollten auf 770 gesetzt werden, zudem sollte eine eigene Audit Gruppe angelegt werden.

Mit dem untenstehenden Kommando konfiguriere ich den Datenpfad, den ich bereits zuvor angelegt und berechtigt habe:

db2audit configure datapath ~/audit/

Als nächstes wird der Archivpfad konfiguriert:

db2audit configure archivepath ~/audit/arch

Schritt 3: Konfiguration der Übertragung an das Syslog

Um das Importieren der Audit Records in regelmäßigen Abständen durchzuführen, wird ein ausführbares Skript benötigt, welches über einen Scheduler angestoßen wird.

Das Skript hat die folgenden Aufgaben:
• Die Audit-Dateien regelmäßig zu archivieren, also abzuhängen vom Audit-Datenstrom
• Die archivierten Dateien ins Systemlog zu importieren
• Erfolgreich übertragene Dateien zu löschen
• Nicht erfolgreich übertragene Dateien in ein separates Verzeichnis zu verschieben

Das Skript sollte so aufgebaut sein, dass die vorhandenen Datenbanken in einer Instanz automatisch erkannt werden.

Bei einem Importzyklus müssen die Audit-Daten sicher importiert sein, bevor der nächste Import startet. Wenn zu viele Audit-Prüffunktionen eingerichtet wurden, können die Prüfprotokolle schnell groß werden und der Import kann viel Zeit in Anspruch nehmen.

Sollte es zu Störungen beim Übertragen der Audit-Daten kommen, weil etwa das Syslog ein Problem hat, ist es sinnvoll, ein Unterverzeichnis auf der Platte einzurichten und die zurückgewiesenen Audit-Dateien dort abzulegen. Diese können dann zu einem späteren Zeitpunkt nachträglich importiert werden. Es gilt: Keine Audit-Daten dürfen verloren gehen!

Es sei hier der Vollständigkeit halber noch angemerkt, dass es außer dem Import ins Syslog noch weitere Möglichkeiten gibt, die Audit-Daten bereitzustellen. Eine Möglichkeit ist, die Audit-Daten in ein verschlüsseltes Verzeichnis zu legen und von einem nachgelagerten Auswertungstool abholen zu lassen. Dies ist praktikabel, wenn man große Datenmengen hat.

Man sollte aber beachten, dass auf diese Laufwerke nur ein begrenzter Benutzerkreis Zugriff haben darf, damit die Audit-Daten nicht manipuliert oder gelöscht werden können. Die IT-Sicherheitsvorschriften des Kunden sind hier zu beachten.

Schritt 4: Konfiguration der zu sammelnden Informationen

Um die Menge der zu sammelnden Information zu konfigurieren, gibt es drei Optionen: scope, status und errortype. Die möglichen Einstellungen werden im Folgenden aufgelistet und erläutert.

Die Option scope gibt an, in welchen Situationen gesammelt werden soll:
• all: In allen Situationen.
• audit: Wenn die Prüfprotokolle (Audit Records) verändert werden oder auf die Prüfprotokolle zugegriffen wird.
• checking: Während der Autorisierungsprüfung von Versuchen, auf die Db2 Instanz zuzugreifen.
• context: Generiert Datensätze, um den Vorgangskontext anzuzeigen.
• objmaint: Beim Erstellen oder Löschen von Datenbankobjekten.
• secmaint: Wenn die sysadm_group, sysctrl_group oder sysmaint_group beim Datenbankmanager verändert wird.
• sysadmin: Bei Operationen die SYSADM, SYSMAINT oder SYSCTRL Berechtigungen benötigen.
• validate: Wenn Berechtigungen hinzugefügt oder entfernt werden.

Die Option status gibt an, ob bei Erfolg oder bei Fehlschlag gesammelt werden soll:
• 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 soll:
• audit: Alle Fehler, also auch Audit-Fehler und alle negativen SQLCODES.
• normal: nur negativen SQLCODES.

Weitere Informationen kann man diesem Link zur Dokumentation entnehmen.

Ein Beispielbefehl, der in diesem Fall den größten Umfang der Datensammlung konfiguriert, sieht damit so aus:

db2audit configure scope all status both errortype audit

 Schritt 5: Das Audit starten und prüfen

Damit die Db2-Instanz die konfigurierten Werte übernimmt, muss sie neu gestartet werden:

db2stop
db2start

Der Befehl zum Start des Audits ist kurz und nicht überraschend:

db2audit start

Um jederzeit den Status und die aktuellen Einstellungen des Audits anzeigen zu lassen, kann dieser Befehl verwendet werden:

db2audit describe

Fazit

Mit nur wenigen Schritten kann das Audit für eine Instanz eingerichtet werden. Wichtig ist es, im Vorfeld die für das Unternehmen passende Konfiguration zu ermitteln.

Im zweiten Teil wird dieses Audit dann um eine Überwachung innerhalb der Datenbanken erweitert.