Anhand von Triggern, die unabhängig vom Anwender alle Aktivitäten auf der Serverebene erfassen, soll ein eigenes Audit-System entwickelt werden. Damit wird eine Dokumentation gewährleistet, die belegt, wer wann, wo und mit welcher Zugriffsberechtigung auf interne Daten zugreift.
In Meetings mit Sarbanes-Oxley[1]-Auditoren geht es oft um die Sicherheit und Integrität von Unternehmensdaten sowie die Dokumentation, wer auf welche Daten Zugriff hat, wie Zugriffsberechtigungen erteilt werden und wie sichergestellt wird, dass sich niemand einschleicht, einloggt und etwas tut, was er nicht darf.
Es gibt einige kommerzielle Softwarelösungen zur Dokumentation der Sarbanes-Oxley-Compliance, aber man kann auch die im SQL Server 2005 integrierten Tools nutzen und ein eigenes Audit-System entwickeln. ZDNet zeigt dies anhand eines Beispiels.
Welche neuen Funktionen bietet Server 2005
Bevor es SQL Server 2005 gab, nutzten einige Unternehmen Trigger der Datenmanipulationssprache (DML), die anzeigten, wenn Daten in der Datenbank verändert wurden. Es konnte das Auditprotokoll aufgerufen werden und eine Liste aller INSERT-, UPDATE-, und DELETE-Einträge seit dem letzten Audit wurde angezeigt, einschließlich Uhrzeit und Datum wann der Eintrag vorgenommen wurde und durch welchen Mitarbeiter oder durch welches Programm.
DML-Trigger, bei denen es sich um spezielle, abgespeicherte Prozeduren handelt, die die Datenbank auslöst, haben sich als sehr nützlich erwiesen und ermöglichen es ein Prüfprotokoll über Änderungen von Daten zu erstellen. Ein Nachteil der DML-Trigger bestand jedoch darin, dass sie nur dann ausgelöst werden, wenn Daten verändert wurden. Ohne SQL Server 2005 gab es keine effiziente Möglichkeit, um strukturelle oder sicherheitsrelevante Änderungen des Datenbankservers aufzuspüren.
SQL Server 2005 unterstützt Datendefinitionssprache-Trigger (DDL). Diese Trigger können so eingerichtet werden, dass eine Auslösung erfolgt, wenn eine beliebige Anzahl von Ereignissen auf Server- oder Datenbankebene stattfindet. DDL-Trigger ermöglichen die Verfolgung kritischer Veränderungen in einem Datenbankumfeld - Änderungen, die gezielt erfolgen, durch Fehler oder böswillige Handlungen.
DDL-Trigger werden in zwei Bereichen ausgelöst: auf Datenbank- und auf Serverebene. Bei der Erstellung von Triggern ist es wichtig festzulegen, welche Ereignisse geprüft werden sollen und auf welcher Ebene das einzelne Ereignis stattfindet. In diesem Artikel befassen wir uns mit dem Schreiben eines Triggers, der Anmeldevorgänge erfassen soll. Diese erfolgen auf der Serverebene. DDL-Trigger verbessern die Möglichkeiten zur Überwachung einer Datenbank. Bei den Vorgängerversionen des SQL Server war es schwierig die Übersicht zu behalten, wenn neue Anmeldenamen eingerichtet wurden, eine neue Datenbank erstellt wurde oder neue Zugriffsberechtigungen für verschiedene Anwender vergeben wurden.
Mit SQL Server 2005 ist es relativ einfach solche sicherheitsrelevanten Veränderungen zu verfolgen. Um das zu verdeutlichen, soll nun ein Trigger erstellt werden, der alle Aktivitäten auf der Serverebene unabhängig vom Anwender erfasst. Hierfür verwendet man in diesem Fall das DDL-Triggerereignis DDL_LOGIN_EVENTS um das Auditprotokoll einzurichten. Dieses Triggerereignis erfasst alle Anmeldevorgänge auf dem Server, einschließlich der Ereignisse CREATE LOGIN, ALTER LOGIN und DELETE LOGIN.
Es sollen auch alle Veränderungen in einer Datenbank erfasst werden, auf die das DBA- und das Entwicklungsteam sehr eingeschränkten Zugriff haben. Die Einschränkung der Zugriffsmöglichkeit für das DBA-Team zur Änderung des Prüfprotokolls eines Servers oder einer Datenbank ist eine wesentliche Maßnahme um die Integrität des Prüfprotokolls zu gewährleisten.
In SQL Server 2005 erstellt man eine Datenbank für das Prüfprotokoll durch Ausführen des Befehls CREATE DATABASE DDLTriggerTest. Anschließend müssen die folgenden Felder definiert werden:
- IDCol SMALLINT IDENTITY(1,1) PRIMARY KEY,
- XMLEvent XML,
- DatabaseName VARCHAR(50),
- SystemUser VARCHAR(50),
- EntryDate DATETIME DEFAULT (GETDATE())
Man beachte, dass die Tabelle im XML-Format erstellt wird. Dies ist neu in SQL Server 2005. Wie die Bezeichnung schon andeutet, besteht die Funktion darin XML-Daten zu speichern.
Dieses Befehlsskript erstellt den Trigger, der festlegt, dass alle DDL-Anmeldevorgänge am Server erfasst werden. Alle durch die Auslösung des Triggers erstellten Informationsdaten werden in der zuvor angelegten DDLTriggerTest-Tabelle erfasst. Man beachte, dass für das Schreiben in die Tabelle drei Funktionen verwendet werden. In diesem Kontext erfasst die Funktion EVENTDATA alle Informationen der Anmeldevorgänge, da dies das Ereignis ist, welches mit der Funktion FOR DDL_LOGIN_EVENTS spezifiziert wurde. Die Funktion SYSTEM_USER gibt den Anmeldevorgang zurück, der den aktuellen Befehl ausgeführt hat und die Funktion DB_NAME() meldet den Namen der Datenbank zurück, in der der aktuelle Befehl ausgeführt wird. Da ein Anmeldevorgang auf Serverebene erfolgt, meldet das Prüfprotokoll, dass der Vorgang in der Master-Datenbank stattgefunden hat.
Um nun den neuen Trigger zu testen, muss ein Anmeldevorgang auf dem Server ausgelöst werden, damit dieser vom Trigger erfasst wird. Es ist am einfachsten einen neuen Anmeldevorgang beispielsweise durch die Befehlseingabe CREATE LOGIN TestLogin WITH PASSWORD = '123456xxYYbaz'. zu erstellen.
Ist dieser Befehl ausgeführt, sieht man im Meldungsfenster die Anzeige (1 Zeile(n) betroffen). Diese Meldung erfolgt aufgrund der integrierten Prüfroutine. Als der Befehl CREATE LOGIN ausgeführt wurde, wurde der DDL-Trigger ausgelöst und eine Meldung in die EventTableData-Tabelle in der DDLTriggerTest-Datenbank geschrieben.
Was steht nun in der XML?
Um zu überprüfen, ob die Meldung gespeichert wurde, kann eine SQL-Suchabfrage für die DDLTriggerTest-Tabelle durchgeführt werden. Für Anwender, die mit SQL Server 2000 vertraut sind, könnten die Daten in der XMLEvent-Spalte möglicherweise befremdlich aussehen. Im SQL Server Management Studio (SSMS) klickt man auf den Link in der XMLEvent-Spalte um sich die erstellten XML-Daten anzeigen zu lassen.
Im XMLEvent-Feld ist die EVENTDATA()-Funktion aus dem INSERT Befehl des Triggers eingetragen. In diesem Fall meldet die EVENTDATA()-Funktion XML-Daten, die sich auf den Anmeldevorgang beziehen, einschließlich Datum und Zeitpunkt des Anmeldevorgangs, Name des Servers, Anwender-ID und System-ID des Rechners.
Dies ist nur der Anfang
Der DDL_LOGIN_EVENT-Trigger ist nur einer von fünf Dutzend DDL-Ereignissen, die man überwachen kann um die Systemsicherheit zu dokumentieren. Andere DDL-Ereignisse, die für Sarbanes-Oxley-Audits von Interesse sind, sind die Erstellung oder Verwerfung anderer Datenbankobjekte, wie zum Beispiel Tabellen, Prozeduren, Trigger, Anzeigen, Funktionen und so weiter.
URLs in diesem Artikel:
[1] = http:/