So aktivieren Sie das SQL Server Audit und überprüfen das Audit-Protokoll

Das Auditing von Microsoft SQL Server ist entscheidend, um Sicherheitsprobleme und Verstöße zu identifizieren. Darüber hinaus ist das Auditing von SQL Server eine Anforderung für die Einhaltung von Vorschriften wie PCI DSS und HIPAA.

Der erste Schritt besteht darin zu definieren, was überprüft werden soll. Zum Beispiel könnten Sie Benutzeranmeldungen, Serverkonfiguration, Schemaänderungen und die Überwachung von Datenänderungen auditieren. Als Nächstes müssen Sie auswählen, welche Sicherheitsüberwachungsfunktionen Sie verwenden möchten. Nützliche Funktionen umfassen Folgendes:

• C2-Auditing
• Gängige Compliance-Kriterien
• Login-Auditing
• SQL Server Auditing
• SQL Trace
• Erweiterte Ereignisse
• Change Data Capture
• DML, DDL und Anmeldeauslöser

Dieser Artikel richtet sich an Datenbankadministratoren (DBAs), die C2-Auditing, Common Compliance Criteria und SQL Server Auditing verwenden möchten. Wir werden keine Drittanbieter-Audit-Tools betrachten, obwohl diese besonders in größeren Umgebungen und regulierten Branchen sehr hilfreich sein können.

Aktivierung von C2-Auditing und Common Criteria Compliance

Wenn Sie derzeit Ihr SQL Server nicht überwachen, ist der einfachste Startpunkt, das C2-Auditing zu aktivieren. C2-Auditing ist ein international anerkannter Standard, der in SQL Server eingeschaltet werden kann. Es überwacht Ereignisse wie Benutzeranmeldungen, gespeicherte Prozeduren und das Erstellen und Entfernen von Objekten. Aber es ist alles oder nichts – Sie können nicht auswählen, was überwacht wird, und es kann eine Menge Daten erzeugen. Darüber hinaus befindet sich C2-Auditing im Wartungsmodus und wird wahrscheinlich in einer zukünftigen Version von SQL Server entfernt.

Common Criteria Compliance ist ein neuerer Standard, der das C2-Auditing ablöst. Er wurde von der Europäischen Union entwickelt und kann in den Enterprise- und Datacenter-Editionen von SQL Server 2008 R2 und später aktiviert werden. Es kann jedoch zu Leistungsproblemen führen, wenn Ihr Server nicht ausreichend ausgestattet ist, um mit dem zusätzlichen Overhead zurechtzukommen.

So aktivieren Sie die C2-Auditing in SQL Server 2017:

1. Öffnen Sie das SQL Server Management Studio.

2. Stellen Sie eine Verbindung zum Datenbank-Engine her, für die Sie die C2-Auditing aktivieren möchten. Stellen Sie im Dialogfeld 'Mit Server verbinden' sicher, dass Server type auf Database Engine gesetzt ist und klicken Sie dann auf Verbinden.

3. Im Objekt-Explorer-Bereich auf der linken Seite, klicken Sie mit der rechten Maustaste auf Ihre SQL Server-Instanz oben und wählen Sie Properties aus dem Menü.

4. Im Fenster Servereigenschaften klicken Sie auf Security unter Seite auswählen.

5. Auf der Sicherheitsseite können Sie die Überwachung von Anmeldungen konfigurieren. Standardmäßig werden nur fehlgeschlagene Anmeldungen aufgezeichnet. Alternativ können Sie nur erfolgreiche Anmeldungen oder sowohl fehlgeschlagene als auch erfolgreiche Anmeldungen überprüfen.

Abbildung 1. Konfiguration der Zugriffsüberwachung

6. Aktivieren Sie die Option C2-Audit-Protokollierung unter Optionen.

7. Wenn Sie das C2 Common Criteria Compliance-Auditing aktivieren möchten, aktivieren Sie die Option Enable Common Criteria compliance.

Common Criteria (CC) Compliance ist ein flexibler Standard, der mit verschiedenen Evaluation Assurance Levels (EALs) von 1 bis 7 umgesetzt werden kann. Höhere EALs erfordern einen anspruchsvolleren Verifizierungsprozess. Wenn Sie Enable Common Criteria compliance in SQL Server aktivieren, schalten Sie CC Compliance EAL1 frei. Es ist möglich, SQL Server manuell für EAL4+ zu konfigurieren.

Die Aktivierung der CC-Compliance ändert das Verhalten von SQL Server. Beispielsweise haben auf Tabellenebene erteilte DENY-Berechtigungen Vorrang vor auf Spaltenebene erteilten GRANTs, und sowohl erfolgreiche als auch fehlgeschlagene Anmeldungen werden überwacht. Zusätzlich wird der Residual Information Protection (RIP) aktiviert, der Speicherzuweisungen mit einem Muster aus Bits überschreibt, bevor sie von einer neuen Ressource genutzt werden.

8. Klicken Sie auf OK.

9. Basierend auf den ausgewählten Optionen, könnte es sein, dass Sie aufgefordert werden, SQL Server neu zu starten. Wenn Sie diese Nachricht erhalten, klicken Sie auf OK im Warnungsdialog. Wenn Sie die C2 Common Criteria Compliance aktiviert haben, starten Sie den Server neu. Andernfalls klicken Sie erneut mit der rechten Maustaste auf Ihre SQL Server-Instanz im Objekt-Explorer und wählen Sie Restart aus dem Menü. Im Warnungsdialog klicken Sie auf Yes um zu bestätigen, dass Sie SQL Server neu starten möchten.

Aktivierung von SQL Server Audit

Das Auditing von SQL Server kann anstelle von C2-Auditing aktiviert werden; Sie können auch wählen, beides zu aktivieren. SQL Server Audit-Objekte können konfiguriert werden, um Ereignisse auf Serverebene oder auf Ebene der SQL Server-Datenbank zu sammeln.

Server-Audit-Objekt erstellen

Erstellen wir ein serverweites SQL Server-Audit-Objekt:

1. Im Objekt-Explorer-Bereich auf der linken Seite erweitern Sie Security.

2. Klicken Sie mit der rechten Maustaste auf Audits und wählen Sie Neue Überwachung… aus dem Menü. Dadurch wird ein neues SQL Server Audit-Objekt für die Serverebenen-Überwachung erstellt.

3. Im Fenster Audit erstellen, geben Sie den Audit-Einstellungen einen Namen im Feld Audit name

4. Legen Sie fest, was passieren soll, wenn das SQL Server Auditing fehlschlägt, indem Sie die Option On Audit Log Failure verwenden. Sie können Continue wählen oder entscheiden, den Server herunterzufahren oder die überwachten Datenbankoperationen zu stoppen. Wenn Sie Fail operation auswählen, werden Datenbankoperationen, die nicht überwacht werden, weiterhin funktionieren.

Abbildung 2. Erstellen eines serverweiten SQL Server-Auditobjekts

5. Im Dropdown-Menü „Audit destination“ können Sie wählen, ob Sie die SQL-Audit-Trail in eine Datei schreiben oder Audit-Ereignisse im Windows-Sicherheitsprotokoll oder Anwendungsereignisprotokoll protokollieren möchten. Wenn Sie sich für eine Datei entscheiden, müssen Sie einen Pfad für die Datei angeben.

Beachten Sie, dass SQL Server die Berechtigung benötigt, wenn Sie in das Windows-Sicherheitsereignisprotokoll schreiben möchten. Wählen Sie der Einfachheit halber das Anwendungsereignisprotokoll aus. Zusätzlich können Sie einen Filter als Teil des Audit-Objekts einbeziehen, um eine engere Ergebnismenge zu erhalten; Filter müssen in Transact-SQL (T-SQL) geschrieben werden.

6. Klicken Sie auf OK.

7. Sie finden nun die neue Überwachungskonfiguration im Objekt-Explorer unter Audits. Klicken Sie mit der rechten Maustaste auf die neue Überwachungskonfiguration und wählen Sie Enable Audit aus dem Menü.

8. Klicken Sie auf Close im Dialogfeld Audit aktivieren.

Datenbank-Audit-Objekt erstellen

Um ein SQL Server Audit-Objekt für die Datenbankebene zu erstellen, ist der Prozess etwas anders und Sie müssen zuerst mindestens ein Audit-Objekt auf Serverebene erstellen.

1. Erweitern Sie Databases im Objekt-Explorer und erweitern Sie die Datenbank, für die Sie die Überwachung konfigurieren möchten.

2. Erweitern Sie den Ordner Security, klicken Sie mit der rechten Maustaste auf Database Audit Specifications und wählen Sie New Database Audit Specification… aus dem Menü.

Abbildung 3. Erstellen einer Server-Audit-Spezifikation für die Datenbankebene-Auditing

3. Im Eigenschaften-Fenster unter Aktionen verwenden Sie die Dropdown-Menüs, um einen oder mehrere Überwachungsaktionstypen zu konfigurieren, indem Sie die Anweisungen auswählen, die Sie überwachen möchten (wie DELETE oder INSERT), die Objektklasse, auf die die Aktion angewendet wird, und so weiter.

4. Wenn Sie fertig sind, klicken Sie auf OK und aktivieren Sie dann das Überwachungsobjekt, indem Sie es mit der rechten Maustaste anklicken und Enable Database Audit Specification auswählen.

Anzeigen von SQL Server Audit Logs

C2 Audit SQL Server-Auditprotokolle werden im Standarddatenverzeichnis der SQL Server-Instanz gespeichert. Jede Protokolldatei kann maximal 200 Megabyte groß sein. Eine neue Datei wird automatisch erstellt, wenn das Limit erreicht ist.

Eine native Lösung, die empfohlen wird, um SQL Server-Auditprotokolle anzusehen, heißt Log File Viewer. Um sie zu verwenden, gehen Sie wie folgt vor:

1. In SQL Server Management Studio, im Objekt-Explorer-Bereich, erweitern Sie Security und

2. Klicken Sie mit der rechten Maustaste auf das zu überprüfende Audit-Objekt und wählen Sie View Audit Logs aus dem Menü.

3. Im Log File Viewer werden die Protokolle auf der rechten Seite angezeigt. Unabhängig davon, ob die Protokolle in eine Datei oder in das Windows-Ereignisprotokoll geschrieben werden, der Log File Viewer zeigt die Protokolle an.

4. Oben im Log File Viewer können Sie auf Filter klicken, um anzupassen, welche Protokolleinträge angezeigt werden. SQL Server-Dateiprotokolle werden im .sqlaudit-Format gespeichert und sind nicht lesbar, daher ermöglicht Ihnen der Log File Explorer, auf Export zu klicken, um Protokolle in einem kommagetrennten .log-Dateiformat zu speichern.

Abbildung 4. Überprüfung des SQL Server-Audit-Protokollierung im Log File Viewer

FAQ

Wie kann man überprüfen, ob das SQL Server Audit aktiviert ist?

Um zu überprüfen, ob das SQL Server Audit aktiviert ist, fragen Sie die dynamische Managementansicht sys.dm_server_audit_status ab oder überprüfen Sie den Sicherheitsordner im SQL Server Management Studio (SSMS). In SSMS erweitern Sie Sicherheit > Audits, um alle konfigurierten Audits und ihren aktuellen Status zu sehen – aktivierte Audits werden mit einem grünen Symbol angezeigt, während deaktivierte ein rotes Symbol haben. Sie können auch diese Abfrage ausführen, um den Audit-Status programmgesteuert zu überprüfen:

      SELECT name, is_state_enabled FROM sys.server_audits
      

Denken Sie daran, dass sowohl die Serverüberwachung als auch die Datenbanküberwachungsspezifikation aktiviert sein müssen, um eine vollständige Überwachungsabdeckung zu gewährleisten. Data Security beginnt mit Identity und erfordert umfassende Einblicke darin, wer auf welche Daten zugreift. SQL Server Audit bietet diese Grundlage, wenn es richtig konfiguriert und überprüft wird.

Warum wird meine SQL Server-Auditdatei so groß?

Übermäßiges Wachstum von Überwachungsdateien tritt typischerweise auf, wenn zu viele Ereignisse überwacht werden oder keine angemessenen Dateiverwaltungseinstellungen konfiguriert sind. Die häufigsten Ursachen sind die Aktivierung ALLER Überwachungsaktionsgruppen, das Überwachen von SELECT-Anweisungen auf stark frequentierten Tabellen oder das Einstellen von unbegrenztem Dateiwachstum ohne Rotation. Um das Wachstum zu kontrollieren, konzentrieren Sie sich darauf, nur die Ereignisse zu überwachen, die Sie tatsächlich für die Compliance benötigen – typischerweise LOGIN_CHANGE_PASSWORD_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, und spezifische DML-Operationen auf sensiblen Tabellen. Konfigurieren Sie maximale Dateigrößenlimits und aktivieren Sie die Dateirotation mit den Optionen MAXSIZE und MAX_ROLLOVER_FILES. Für Umgebungen mit hohem Volumen sollten Sie in Betracht ziehen, das Ziel APPLICATION_LOG anstelle von FILE zu verwenden, oder implementieren Sie eine Überwachungsfilterung mit WHERE-Klauseln, um unnötige Ereigniserfassungen zu reduzieren. Intelligente Überwachung bedeutet, das Wesentliche zu verfolgen, ohne in Datenrauschen zu ertrinken.

Wie behebt man das Problem, dass die SQL Server-Überwachung nicht startet?

Wenn das SQL Server Audit nicht startet, liegt das Problem normalerweise bei Dateiberechtigungen, Pfadzugänglichkeit oder Konflikten in der Konfiguration. Zuerst sollten Sie überprüfen, ob das SQL Server Dienstkonto Schreibberechtigungen für das Verzeichnis der Audit-Datei hat – dies ist die häufigste Ursache für Startfehler. Überprüfen Sie das SQL Server Fehlerprotokoll auf spezifische Fehlermeldungen, die in der Regel klare Anweisungen zum Problem geben. Stellen Sie sicher, dass das Zielverzeichnis existiert und vom SQL Server-Instanz aus zugänglich ist, besonders in Clusterumgebungen, wo gemeinsam genutzte Speicherpfade auf allen Knoten gültig sein müssen. Wenn das Windows-Anwendungsprotokoll als Ziel verwendet wird, überprüfen Sie, ob das Dienstkonto entsprechende Schreibberechtigungen für das Ereignisprotokoll hat. Konfigurationsfehler wie doppelte Audit-Namen oder ungültige Dateipfade verhindern ebenfalls den Start. Der Schlüssel liegt in der methodischen Fehlersuche: Überprüfen Sie zuerst die Berechtigungen, dann die Pfade, dann die Konfigurationssyntax. Netwrix vereinfacht diese Komplexität, indem es eine zentralisierte Audit-Verwaltung bietet, die diese häufigen Fallstricke beseitigt.

Welche Auswirkungen hat das Auditing auf die Leistung von SQL Server?

Das Auditing von SQL Server hat bei korrekter Konfiguration eine minimale Leistungsbeeinträchtigung, typischerweise einen Mehraufwand von 2-5% in den meisten Umgebungen. Die tatsächliche Auswirkung hängt von drei Schlüsselfaktoren ab: welche Ereignisse Sie überwachen, wie häufig diese auftreten und die Leistung Ihres Speichersubsystems. Das Überwachen von Operationen mit hoher Frequenz wie SELECT-Anweisungen auf stark frequentierten OLTP-Systemen erzeugt mehr Overhead als die Konzentration auf sicherheitsrelevante Ereignisse wie Anmeldungen, Berechtigungsänderungen und DML-Operationen auf sensiblen Tabellen. Asynchrone Audit-Ziele (die Standardeinstellung) bieten eine bessere Leistung als synchrone Optionen, allerdings mit leicht verzögerter Ereignisaufzeichnung. Um die Auswirkungen zu minimieren, verwenden Sie Audit-Filterung mit WHERE-Klauseln, vermeiden Sie das Überwachen unnötiger Systemoperationen und stellen Sie sicher, dass Ihr Audit-Dateispeicher über ausreichende I/O-Kapazität verfügt. Extended Events haben im Allgemeinen eine geringere Überlastung als SQL Server Audit bei Szenarien mit hohem Volumen, aber SQL Server Audit bietet überlegene Compliance-Funktionen und eine einfachere Verwaltung. Ein intelligentes Audit-Design konzentriert sich auf den Sicherheitswert anstelle von umfassendem Logging – Sie möchten eine Sichtbarkeit, die schützt, ohne die Leistung zu lähmen.

SQL Server-Audit vs. SQL Trace: Welches sollte ich verwenden?

SQL Server Audit ist die moderne Wahl für neue Implementierungen, während SQL Trace als veraltet gilt und für neue Projekte vermieden werden sollte. SQL Server Audit bietet im Vergleich zur veralteten SQL Trace-Funktionalität eine bessere Sicherheit, Leistung und Verwaltungsfähigkeit. Im Gegensatz zu SQL Trace können SQL Server Audit-Ereignisse nicht von Benutzern (einschließlich Sysadmins) modifiziert oder gelöscht werden, was die Integrität der Überwachung für Compliance-Anforderungen sicherstellt. Das Überwachungsframework bietet asynchrone Verarbeitung für eine bessere Leistung, integrierte Filterfunktionen und eine Integration mit dem Windows-Sicherheitsereignisprotokoll. SQL Trace erfordert manuelle Codierung mit gespeicherten Prozeduren und wurde zur Entfernung in zukünftigen SQL Server-Versionen markiert. Extended Events ist der empfohlene Ersatz für die diagnostischen Fähigkeiten von SQL Trace, während SQL Server Audit die Überwachung von Sicherheit und Compliance übernimmt. Wenn Sie derzeit SQL Trace für die Sicherheitsüberwachung verwenden, migrieren Sie sofort zu SQL Server Audit – es bietet die manipulationssichere Überwachungsspur, die echte Datensicherheit erfordert. Netwrix-Lösungen bauen auf diesen nativen Überwachungsfähigkeiten auf, um eine zentralisierte Sichtbarkeit über Ihre gesamte Datenumgebung zu bieten.