Überwachung der SQL-Datenbank in Fabric

Gilt für:✅SQL-Datenbank in Microsoft Fabric

Die Überwachung für SQL-Datenbanken in Fabric ist ein wichtiges Sicherheits- und Compliancefeature, mit dem Organisationen Datenbankaktivitäten nachverfolgen und protokollieren können. Die Überwachung unterstützt Compliance-, Bedrohungserkennungs- und forensische Untersuchungen, indem Sie Fragen beantworten, z. B. wer auf welche Daten zugegriffen hat, wann und wie.

Was ist SQL-Überwachung?

Die SQL-Überwachung bezieht sich auf den Prozess der Erfassung und Speicherung von Ereignissen im Zusammenhang mit Datenbankaktivitäten. Zu diesen Ereignissen gehören Datenzugriff, Schemaänderungen, Berechtigungsänderungen und Authentifizierungsversuche.

In Fabric funktioniert die Überwachung auf Datenbankebene und unterstützt Folgendes:

  • Complianceüberwachung (z. B. HIPAA, SOX)
  • Sicherheitsuntersuchungen
  • Operative Einblicke

Überwachungsziel

Überwachungsprotokolle werden in einen schreibgeschützten Ordner in OneLake geschrieben und können mit der sys.fn_get_audit_file_v2 T-SQL-Funktion oder dem OneLake-Explorer abgefragt werden.

Für die SQL-Datenbank in Fabric werden Überwachungsprotokolle in OneLake gespeichert: https://onelake.blob.fabric.microsoft.com/{workspace_id}/{artifact_id}/Audit/sqldbauditlogs/

Diese Protokolle sind unveränderlich und für Benutzer mit entsprechenden Berechtigungen zugänglich. Protokolle können auch mithilfe des OneLake-Explorers oder des Azure Storage-Explorers heruntergeladen werden.

Abrechnung

Derzeit entstehen beim Schreiben von Überwachungsprotokollen in Fabric OneLake keine zusätzlichen Gebühren, und der Speicher ist Bestandteil der OneLake-Speichergrenzwerte für Kapazitäten.

Konfigurationsoptionen

Standardmäßig erfasst die Option "Alles überwachen " alle Ereignisse, einschließlich Batchvervollständigungen und erfolgreicher und fehlgeschlagener Authentifizierung.

Um selektiver zu sein, wählen Sie aus vorkonfigurierten Überwachungsszenarien aus, z. B.: Berechtigungsänderungen und Anmeldeversuche, Datenlese- und Schreibvorgänge und/oder Schemaänderungen.

Jedes vorkonfigurierte Szenario ist bestimmten Überwachungsaktionsgruppen zugeordnet (z. B. SCHEMA_OBJECT_ACCESS_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP). Sie können auch auswählen, welche Ereignisse unter "Benutzerdefinierte Ereignisse" überwacht werden sollen. Sie können einzelne Aktionsgruppen auswählen, um die Überwachung an Ihre Anforderungen anzupassen. Diese Option eignet sich ideal für Organisationen mit strengen internen Sicherheitsrichtlinien.

Um allgemeine oder bekannte Zugriffsabfragen herauszufiltern, können Sie Prädikatausdrücke in Transact-SQL (T-SQL) bereitstellen, um Überwachungsereignisse basierend auf Bedingungen zu filtern (z. B. zum Ausschließen von SELECT-Anweisungen): WHERE statement NOT LIKE '%select%'.

Erlaubnisse

Um die Überwachung mithilfe von Fabric-Arbeitsbereichsrollen zu verwalten (empfohlen), müssen Sie über eine Mitgliedschaft in der Rolle " Fabric-Arbeitsbereichsmitwirkender" oder höheren Berechtigungen verfügen.

So verwalten Sie die Überwachung mit SQL-Berechtigungen:

  • Zum Konfigurieren der Datenbanküberwachung benötigen Sie die Berechtigung ALTER ANY DATABASE AUDIT.
  • Um Überwachungsprotokolle mit T-SQL anzuzeigen, müssen Sie über die BERECHTIGUNG "VIEW DATABASE SECURITY AUDIT" verfügen.

Retention

Standardmäßig werden Überwachungsdaten unbegrenzt aufbewahrt, es sei denn, Sie konfigurieren einen benutzerdefinierten Aufbewahrungszeitraum, um Protokolle nach dieser Dauer automatisch zu löschen.

Fabric speichert derzeit Prüfprotokolle im Ordner des Elements in OneLake und grenzt sie an den Lebenszyklus des Elements an. Wenn Sie das Element löschen, löscht Fabric auch die Überwachungsprotokolle. Wenn Sie die Aufbewahrung unabhängig vom Lebenszyklus des Elements benötigen, verschieben Sie Überwachungsprotokolle an einen separaten Speicherort (z. B. ein anderes Lakehouse- oder ein Azure Storage-Konto), indem Sie Tools wie AzCopy oder SSDT verwenden.

Aufbewahrung von Einstellungen nach der Wiederherstellung

Nach einem Wiederherstellungsvorgang werden Überwachungseinstellungen beibehalten, die Überwachung muss jedoch in Fabric SQL-Datenbank erneut aktiviert werden. Öffnen Sie im Fabric-Portal Manage SQL-Überwachung, wählen Sie Speichern aus.

Konfigurieren der Überwachung für SQL-Datenbank über das Fabric-Portal

So beginnen Sie mit der Überwachung einer Fabric SQL-Datenbank:

  1. Navigieren Sie zu Ihrer SQL-Datenbank im Fabric-Portal, und öffnen Sie sie.
  2. Wählen Sie im Hauptmenü die Registerkarte "Sicherheit " und dann " SQL-Überwachung verwalten" aus. Screenshot des Fabric-Portals mit der Registerkarte
  3. Der Bereich "SQL-Überwachung verwalten " wird geöffnet.
  4. Wählen Sie die Schaltfläche "Ereignisse in SQL-Überwachungsprotokolle speichern " aus, um die Überwachung zu aktivieren.
  5. Konfigurieren Sie, welche Ereignisse im Abschnitt "Datenbankereignisse " erfasst werden sollen. Wählen Sie "Alles überwachen" (Standard) aus, um alle Ereignisse zu erfassen.
  6. Konfigurieren Sie optional eine Aufbewahrungsrichtlinie unter "Aufbewahrung".
  7. Konfigurieren Sie optional einen Prädikatausdruck von T-SQL-Befehlen, die im Prädikatausdruckfeld ignoriert werden sollen.
  8. Wählen Sie Speichern aus.

Abfrageüberwachungsprotokolle

Überwachungsprotokolle können mithilfe der T-SQL-Funktionen sys.fn_get_audit_file und sys.fn_get_audit_file_v2 abgefragt werden.

Im folgenden Skript müssen Sie die Arbeitsbereichs-ID und datenbank-ID angeben. Beide sind in der URL des Fabric-Portals zu finden. Beispiel: https://fabric.microsoft.com/groups/<fabric workspace id>/sqldatabases/<fabric sql database id>. Die erste eindeutige Identifikator-Zeichenkette in der URL ist die Fabric-Arbeitsbereich-ID, und die zweite eindeutige Identifikator-Zeichenkette ist die SQL-Datenbank-ID.

  • Ersetzen Sie <fabric_workspace_id> durch Ihre Fabric-Arbeitsbereichs-ID. Sie können die ID eines Arbeitsbereichs in der URL finden; sie ist die eindeutige Zeichenfolge zwischen zwei / Zeichen nach /groups/ in Ihrem Browserfenster.
  • Ersetzen Sie <fabric sql database id> durch Ihre SQL-Datenbank in der Fabric-Datenbank-ID. Sie können die ID des Datenbankelements in der URL finden; es ist die eindeutige Zeichenfolge zwischen zwei / Zeichen, die nach /sqldatabases/ in Ihrem Browserfenster steht.

Beispiel:

SELECT * FROM sys.fn_get_audit_file_v2(
  'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
  DEFAULT, DEFAULT, DEFAULT, DEFAULT );

In diesem Beispiel werden Prüfprotokolle zwischen 2025-11-17T08:40:40Z und 2025-11-17T09:10:40Z abgerufen.

SELECT *
FROM sys.fn_get_audit_file_v2(
    'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
    DEFAULT,
    DEFAULT,
    '2025-11-17T08:40:40Z',
    '2025-11-17T09:10:40Z')

Weitere Informationen finden Sie unter sys.fn_get_audit_file und sys.fn_get_audit_file_v2.

Verwalten der Überwachung mit der REST-API

Sie können die SQL-Datenbanküberwachungseinstellungen auch programmgesteuert mithilfe der Fabric-REST-API anzeigen und konfigurieren. Mit der REST-API können Sie die Überwachung in allen Datenbanken in einem Arbeitsbereich mithilfe von PowerShell-Skripts konsistent verwalten.

Weitere Informationen finden Sie unter Verwalten der SQL-Datenbanküberwachung mit der REST-API.

Schützen Sie sensible Informationen in Auditprotokollen

Wenn du dynamisches SQL konstruierst, indem du Eingabewerte direkt in die SQL-Anweisung verkettest, werden diese Werte Teil des Anweisungstextes. Wenn Sie die Rechnung prüfen, könnte das Prüfungsprotokoll sensible Informationen im Text der Stellungnahme aufnehmen.

Um das Risiko der Offenlegung sensibler Informationen zu verringern, befolgen Sie folgende Maßnahmen:

  • Vermeiden Sie dynamisches SQL bei Operationen, die sensible Werte enthalten

    Für sicherheitsrelevante administrative Operationen sollten Sie vermeiden, Anweisungen zu konstruieren, indem sensible Werte in dynamisches SQL verkeindet werden. Wenn möglich, verwenden Sie native SQL-Anweisungen oder andere Ansätze, die verhindern, dass sensible Werte direkt in den Anweisungen eingebettet werden.

    Dynamische SQL-Anweisungen, die aus benutzerzugänglichen Strings zusammengesetzt sind, machen Ihre Anwendungen ebenfalls anfällig für SQL-Injection-Angriffe. SQL-Injection ist ein Angriff, bei dem bösartiger Code in Strings eingefügt wird, die später zur Parsing und Ausführung an die Datenbank weitergegeben werden. Sie müssen jedes Verfahren testen, das T-SQL für SQL-Injektionslücken erstellt, da die Datenbank-Engine alle syntaktisch gültigen Anfragen ausführt, die sie erhält. Verwenden Sie Parameter für Datenwerte und fügen Sie niemals Parameterwerte in den Anfragetext ein. Korrekt parametrisierte Werte werden als Daten und nicht als ausführbare SQL-Syntax behandelt.

  • Den Zugriff auf Audit-Logs einschränken

    Beschränken Sie den Zugriff auf Audit-Logs auf autorisierte Benutzer und Administratoren. Innerhalb der SQL Datenbank-Engine regeln SQL-Berechtigungen den Auditzugriff innerhalb der SQL Datenbank-Engine und können je nach Plattform und Prüfungsumfang variieren. Folgen Sie dem Prinzip der geringsten Privilegien und gewähren Sie nur die Berechtigungen, die zur Verwaltung oder Überprüfung von Auditinformationen erforderlich sind. Es gibt separate Audit-Rechtsprechungsmodelle auf Serverebene und Datenbankebene, und Azure SQL-Datenbank unterscheidet sich von SQL Server durch die Verfügbarkeit von Serverberechtigungen. Die Einschränkung des Zugriffs auf Auditdaten hilft, das Risiko unbefugter Offenlegung zu verringern, wenn sensible Informationen in aufgezeichneten Audit-Events vorhanden sind.

    Der Zugriff auf Audit-Logs außerhalb der SQL Datenbank-Engine hängt von den Berechtigungen im konfigurierten Ziel (wie OneLake) ab. Folgen Sie dem Prinzip der geringsten Privilegien und gewähren Sie nur die Berechtigungen, die zur Verwaltung oder Überprüfung von Auditinformationen erforderlich sind.

Verwandte Inhalte

  • Last updated on