Als DBA ist man verantwortlich für viele alltägliche Dinge, die die Stabilität und die Sicherheit der zu betreuenden Microsoft SQL Server betreffen. Nicht alles hat man sofort im Fokus und manchmal kommt es vor, dass Dinge bereits passiert sind und der DBA mit den Auswirkungen der Änderungen konfrontiert wird. Wird z. B. der Eigentümer einer Datenbank geändert, kann es passieren, dass die Anwendung nicht mehr läuft. Diese Art der Programmierung sehe ich sehr häufig und dann stellt sich die Frage, wer hat diese Anpassungen vorgenommen. Standardmäßig speichert Microsoft SQL Server diese Informationen nicht; aber es gibt eine Lösung, die jeder DBA mit wenig Aufwand implementieren kann – ÜBERWACHUNGEN. Dieser Artikel beschreibt an Hand eines konkreten Problems die Funktionsweise der ÜBERWACHUNGS-Komponente in Microsoft SQL Server.
Inhaltsverzeichnis
SQL Server Audit
Unter einem AUDIT versteht man die Überwachung einer Instanz von Microsoft SQL Server oder einer einzelnen Datenbank. Sie umfasst die Nachverfolgung und Protokollierung von Ereignissen, die während des Betriebs von Microsoft SQL Server auftreten. Überwachte Ereignisse können in die Ereignisprotokolle oder Überwachungsdateien geschrieben werden. Unterschiedliche Überwachungsebenen für Microsoft SQL Server garantieren eine lückenlose Protokollierung, die von gesetzlichen oder standardspezifischen Anforderungen für die Installation abhängig sind. Für Server können Überwachungsaktionsgruppen instanzweise aufgezeichnet werden. Für Datenbanken können Überwachungsaktionsgruppen oder Überwachungsaktionen pro Datenbank aktiviert werden. Alle Editionen ab SQL Server 2016 SP1 unterstützen Überwachungen auf Datenbankebene. Zuvor war die Überwachung auf Datenbankebene der Enterprise, Developer und Evaluation Edition vorbehalten.
Eine AUDIT-Implementierung besteht aus zwei Komponenten. Je nach Anwendungsfall unterscheidet man zwischen Server-Audits (zu finden in [Security] –> [Audits] auf Serverebene) oder Datenbank-Audits (zu finden in [Security] –> [Database Audit Specifications] auf Datenbankebene).
Überwachung
Jedes Audit benötigt als Grundlage für die Speicherung von Ereignissen eine Überwachung, die die generelle Konfiguration der Überwachung (Speicherort, Dateigröße, …) beinhaltet.
Sobald eine Überwachung konfiguriert wurde, kann diese Überwachung dazu verwendet werden, Überwachungsspezifikationen zu verwalten und die Informationen in der konfigurierten Datei oder im WINDOWS Ereignisprotokoll ist zu empfehlen, da es nicht manipuliert werden werden. Dateien können leicht von einem DBA gelöscht oder manipuliert werden.
Das Konto, unter dem der SQL Server -Dienst ausgeführt wird, muss über die Berechtigung zum Generieren von Sicherheitsüberwachungen verfügen, um in das Windows-Sicherheitsprotokoll schreiben zu können. Hierzu muss dem SQL Server-Dienstkonto die Vollberechtigung zum Zugriff auf die Registrierungsstruktur HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security vergeben werden!
Weitere Informationen zu AUDITS finden sich hier:
- https://docs.microsoft.com/de-de/sql/relational-databases/security/auditing/sql-server-audit-database-engine
- https://docs.microsoft.com/de-de/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions
- https://docs.microsoft.com/de-de/sql/relational-databases/security/auditing/sql-server-audit-records
Problemstellung
Die Änderung des Eigentümers einer Datenbank kann weitreichende Folgen haben. Wenn eine Applikation (siehe Sharepoint) den Eigentümer überprüft und voraussetzt, dass z. B. ein Applikationskonto der Eigentümer sein muss, wird die Anwendung entweder überhaupt nicht oder fehlerhaft gestartet. Die Änderung des Eigentümers einer Datenbank wird nicht von Microsoft SQL Server protokolliert; ein AUDIT wäre somit ein ideales Einsatzgebiet für diese Anforderungen.
Erstellen einer Überwachung
Um ein AUDIT zu implementieren, muss zunächst ein Überwachungsobjekt implementiert werden. Das kann entweder über die GUI erfolgen oder aber mit Hilfe von T-SQL automatisiert werden.
USE [master] GO CREATE SERVER AUDIT [Monitor_DatabaseOwnerChange] TO FILE ( FILEPATH = N'F:\TraceFiles' ,MAXSIZE = 128 MB ,MAX_FILES = 1 ,RESERVE_DISK_SPACE = OFF ) WITH ( QUEUE_DELAY = 1000 ,ON_FAILURE = CONTINUE ); GO ALTER SERVER AUDIT [Monitor_DatabaseOwnerChange] WITH (STATE = ON); GO
Das obige Skript erstellt eine Überwachung mit dem Namen “Monitor_DatabaseOwnerChange”. Alle entdeckten Vorfälle werden in einer Datei abgespeichert, die in F:\TraceFiles abgespeichert wird. Der Name der Datei wird von Microsoft SQL Server selbst verwaltet! Hat die Datei die maximale Größe von 128 MB erreicht, wird sie überschrieben. Microsoft SQL Server speichert die Überwachung zunächst im RAM, die Änderungen werden aber alle 1000ms in die Datei geschrieben. Im Falle eines Fehlers soll die Überwachung aber nicht gestoppt werden sondern weiterhin versuchen, die Aufzeichnungen durchzuführen.
Erstellen einer Überwachungsspezifikation
Sobald die Überwachung erstellt wurde, kann die Überwachungsspezifikation erstellt werden. Microsoft SQL Server stellt verschiedene Audit-Aktionsgruppen zur Verfügung, um die Überwachung granular zu gestalten. Die Überwachung kann auf Serverebene und Datenbankebene erfolgen. Eine Übersicht der möglichen Überwachungsgruppen findet man hier: https://docs.microsoft.com/de-de/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions. Die möglichen Aktionen sind vielfältig und – aus meiner Sicht – teilweise recht unübersichtlich. Liest man sich durch den Dschungel der Möglichkeiten, findet man die Aktionsgruppe “DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP”. In der Hilfe zu Microsoft SQL Server heißt es zu dieser Gruppe:
“Das Ereignis wird ausgelöst, wenn der Besitzer für Objekte im Datenbankbereich geändert wird. Das Ereignis wird für eine Objektbesitzänderung in einer beliebigen Datenbank auf dem Server ausgelöst.”
Die Überwachungsspezifikation kann – wie bereits weiter oben beschrieben, mit Hilfe der GUI erstellt werden. In T-SQL ist es deutlich schneller und einfacher zu realisieren:
CREATE SERVER AUDIT SPECIFICATION [DatabaseOwnerChange] FOR SERVER AUDIT [Monitor_DatabaseOwnerChange] ADD ( DATABASE_OWNERSHIP_CHANGE_GROUP ) WITH (STATE = ON); GO
Überprüfung der implementierten Überwachung
Nachdem die Überwachung implementiert wurde, wird es Zeit, die Funktionalität zu überprüfen. Dazu ändere ich für eine Testdatenbank den Eigentümer.
ALTER AUTHORIZATION ON DATABASE::CustomerOrders TO [NB-LENOVO-I\Uwe]; GO
Auswertung mit SQL Server Management Studio
Mit Hilfe von SQL Server Management Studio lassen sich Protokolleinträge leicht anzeigen und auswerten. Hierzu wird einfach mit der rechten Maustaste auf die zuvor implementierte Überwachung geklickt und der Befehl [View Audit Logs] zeigt in einem Dialog die gesammelten Einträge chronologisch geordnet an.
Das Problem der Benutzeroberfläche besteht jedoch darin, dass immer ALLE Datensätze angezeigt werden. Sie können zwar gefiltert werden, dennoch sind es immer mehrere Schritte, die benötigt werden, um die Informationen auszuwerten. Eine “eigene” Verwendung der Ergebnisse ist aus der GUI heraus nicht möglich.
Auswertung mit DMF
Wer die Arbeit mit der GUI scheut, dem steht eine Systemfunktion zur Verfügung, mit der es möglich ist, die Protokolldatei ebenfalls auszulesen. Mit Hilfe von sys.fn_get_audit_file besteht die Möglichkeit der Ausgabe mit Hilfe von T-SQL. Die Funktion kann natürlich auch verwendet werden, um das Ergebnis z. B. in den Reporting Services oder anderer Clientsoftware zu verwenden. Die Berechtigungen für die Verwendung der Funktion sind jedoch sehr hoch gesteckt – es wird die Berechtigung CONTROL SERVER benötigt.
SELECT event_time, session_id, server_principal_name, target_server_principal_name, database_name, statement FROM sys.fn_get_audit_file ( 'F:\TraceFiles\Monitor_DatabaseOwnerChange_*.sqlaudit', DEFAULT, DEFAULT ) WHERE action_id = 'TO' ORDER BY event_time DESC;
Das obige Listing gibt alle Überwachungen aus, bei denen der Eigentümer einer Datenbank geändert wurde. Neben der Information über den Zeitpunkt wird die Session, in der der Befehl abgesetzt wurde sowie folgende Informationen ausgegeben:
- Anmeldename des ausführenden Kontos (server_principal_name)
- Neuer Eigentümer der Datenbank (target_server_principal_name)
- Betroffene Datenbank (database_name)
- Ausgeführtes Statement (statement)
Zusammenfassung
Überwachungen sind ein unerlässliches Mittel, wenn es um Sicherheitsstrategien für Microsoft SQL Server geht. In einer Zeit, in der Daten eine immer wichtigere Rolle im täglichen Geschäft spielen, sollte der Schutz dieses Guts nicht zu “lax” behandelt werden. Microsoft SQL Server. Mit Hilfe von sehr granularen Überwachungsmöglichkeiten zeigt Microsoft SQL Server einmal mehr, dass Sicherheit sehr ernst genommen wird.
Vielen Dank fürs Lesen!