Auditing in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse ist ein relationales Enterprise-Warehouse auf einem Data Lake-Fundament mit zukunftsfähiger Architektur, integrierter KI und neuen Features. Wenn Sie mit Data Warehouse noch nicht vertraut sind, beginnen Sie mit Fabric Data Warehouse. Vorhandene dedizierte SQL-Pool-Workloads können auf Fabric aktualisieren, um neue Funktionen in den Bereichen Data Science, Echtzeitanalyse und Berichterstellung zu nutzen.

Azure Synapse Analytics Auditing verfolgt Datenbankereignisse und schreibt sie in Azure Storage, einen Azure Monitor Log Analytics Arbeitsbereich oder Azure Event Hubs.

Die Überwachung hilft Ihnen bei:

  • Audit-Trail ausgewählter Ereignisse beibehalten.
  • Verstehen Sie Datenbankaktivitäten und untersuchen Sie Unstimmigkeiten oder Anomalien.
  • Berichte über Aktivitäten mithilfe von Abfragen, Arbeitsmappen und nachgelagerten Überwachungstools.
  • Unterstützen Sie regulatorische und organisatorische Compliance-Anforderungen. Prüfung garantiert allein keine Einhaltung der Vorschriften.

Overview

Sie können die SQL-Datenbanküberwachung für folgende Zwecke verwenden:

  • Beibehalten eines Überwachungspfads von ausgewählten Ereignissen. Sie können Kategorien für zu protokollierende Datenbankaktionen und -ereignisse konfigurieren.
  • Melden von Datenbankaktivitäten. Sie können vorkonfigurierte Berichte und ein Dashboard verwenden, um schnell mit der Berichterstattung über Aktivitäten und Ereignisse zu beginnen.
  • Analysieren von Berichten. Sie können nach verdächtigen Ereignissen, ungewöhnlichen Aktivitäten und Trends suchen.

Important

Das Auditing ist auf die Verfügbarkeit und Leistung des SQL-Pools optimiert. Während sehr hoher Aktivität oder Netzwerkbelastung können Transaktionen ablaufen, ohne dass jedes ausgewählte Ereignis aufgezeichnet wird.

Für Umgebungen mit vielen Datenbanken mit hohen OLTP-Workloads kann die Verwendung der Überwachung auf Serverebene mit Standardeinstellungen zu sehr großen Überwachungsvolumes auf dem logischen Server führen. Da alle Ereignisse aus allen Datenbanken in denselben Überwachungsordner geschrieben werden, wird das Abfragen von Überwachungsprotokollen für eine einzelne Datenbank langsam und betriebsintensiv. So verbessern Sie die Leistung und reduzieren Sie Rauschen:

  • Wechseln Sie zur Überwachung auf Datenbankebene. Jede Datenbank schreibt in ihren eigenen Audit-Log-Ordner, wodurch das gesamte gescannte Volumen reduziert und der Abruf schneller wird.
  • Überprüfen Sie die Überwachungskonfiguration. Ermitteln Sie, ob das Erfassen aller batchfertigen Ereignisse erforderlich ist oder ob eine benutzerdefinierte gefilterte Konfiguration Ihre Sicherheits- und Complianceanforderungen erfüllen kann.

Schützen Sie sensible Informationen in Auditprotokollen

Der Text überwachter Anweisungen kann sensible Werte enthalten, wenn Anwendungen diese Werte zu dynamischem SQL verketten. Verwenden Sie Parameter für Datenwerte, vermeiden Sie es, Geheimnisse oder personenbezogene Daten in den Abfragetext einzubetten, und beschränken Sie den Zugriff auf Audit-Logs auf autorisierte Benutzer.

Die Berechtigungen auf dem Audit-Ziel steuern den Zugriff außerhalb der SQL-Engine. Wenden Sie das Least Privilege auf Azure Storage, Log Analytics und Event Hubs an und überwachen Sie den Zugriff auf diese Ressourcen.

Einschränkungen

  • Sie können die Überwachung nicht für einen angehaltenen dedizierten SQL-Pool aktivieren. Nehmen Sie den Pool wieder auf, bevor Sie die Richtlinie aktivieren.
  • Benutzerzugewiesene verwaltete Identitäten werden für Audits in Azure Synapse Analytics nicht unterstützt.
  • Eine systemzugewiesene verwaltete Identität wird für ein Azure Storage-Ziel unterstützt, wenn sich das Speicherkonto hinter einem virtuellen Netzwerk oder einer Firewall befindet. Verwaltete Identitäten werden für Azure Synapse nicht unterstützt, es sei denn, das Speicherkonto befindet sich hinter einem virtuellen Netzwerk oder einer Firewall.
  • Synapse SQL-Pools unterstützen nur die Standard-Audit-Aktionsgruppen.
  • Die Überwachung wird für Datenbanken mit Namen, die das ? Zeichen enthalten, nicht unterstützt. Diese Einschränkung gilt sowohl für Audits auf Serverebene als auch auf Datenbankebene, da Datenbanken mit ? in ihren Namen auf Azure nicht mehr unterstützt werden.
  • Auditprotokolle speichern bis zu 4.000 Zeichen in den Feldern statement und data_sensitivity_information. Zusätzliche Zeichen werden abgeschnitten.

Remarks

  • Ereignisse, die von SQLDBControlPlaneFirstPartyApp im Aktivitätsprotokoll initiiert werden, sind eine interne Azure Funktion der Azure SQL-Datenbank Steuerebene. Von SQLDBControlPlaneFirstPartyApp initiierte Ereignisse sind Teil eines internen Synchronisierungsvorgangs zwischen dem SQL-Modul und Azure Resource Manager. Diese Ereignisse sind ein normaler Bestandteil der Azure SQL-Datenbank-Verwaltung und sind für die korrekte Ressourcendarstellung und -operation in Azure erforderlich.
  • Storage Premium mit BlockBlobStorage wird unterstützt. Standardspeicher wird unterstützt. Um jedoch Audit-Logs auf ein Speicherkonto hinter einem virtuellen Netzwerk oder einer Firewall zu schreiben, müssen Sie ein Allzweck-v2-Speicherkonto verwenden. Wenn Sie ein Allzweck-v1- oder Blob Storage-Konto verwenden, führen Sie ein Upgrade auf ein Allzweck-v2-Speicherkonto durch. Für spezifische Anweisungen siehe Schreibe Audit-Logs zu einem Speicherkonto hinter einem virtuellen Netzwerk und einer Firewall. Weitere Informationen finden Sie unter Speicherkontentypen.
  • Wenn Sie SQL-Auditing aktivieren und ausgehende Netzwerkbeschränkungen konfigurieren, müssen Sie die vollständig qualifizierten Domänennamen Ihres Audit-Speicherkontos in die Allowlist aufnehmen, um sicherzustellen, dass Audit-Events das Ziel erreichen können. Wenn Sie den Speicher-Endpunkt nicht zur Zulassungsliste hinzufügen, wird der Audit-Datenverkehr blockiert, was zum Verlust von Audit-Ereignissen führt. Nachdem Sie die erforderlichen FQDNs des Speicherkontos zur Erlaubnisliste hinzugefügt haben, müssen Sie Ihre Audit-Konfiguration neu speichern, um den normalen Fluss der Auditereignisse wieder aufzunehmen.
  • Hierarchischer Namespace für alle Typen von Standardspeicherkonto und Storage Premium-Konto mit BlockBlobStorage wird unterstützt.
  • Audit-Logs werden in Append Blobs in einem Azure Blob Storage auf Ihrem Azure-Abonnement geschrieben.
  • Überwachungsprotokolle sind im .xel-Format und können mit SQL Server Management Studio (SSMS) geöffnet werden.
  • Um einen unveränderlichen Protokollspeicher für die Überwachungsereignisse auf Server- oder Datenbankebene zu konfigurieren, folgen Sie den instructions, die von Azure Storage bereitgestellt werden. Wenn Sie unveränderlichen Blob-Storage für Auditing konfigurieren, stellen Sie sicher, dass Zulassen von geschützen Append-Writes entweder auf Blobs anhängen oder Blockieren und Blobs anhängen festgelegt ist. Die Option "Keine" wird nicht unterstützt. Bei zeitbasierten Aufbewahrungsrichtlinien muss das Aufbewahrungsintervall des Speicherkontos kürzer sein als die Aufbewahrungseinstellung für die SQL-Überwachung. Konfigurationen, bei denen die Storage-Richtlinie festgelegt ist, die Aufbewahrung für SQL Auditing jedoch 0 ist, werden nicht unterstützt.
  • Sie können Überwachungsprotokolle in ein Azure Storage Konto hinter einem virtuellen Netzwerk oder einer Firewall schreiben.
  • Details zum Logformat, der Hierarchie des Speicherordners und den Namenskonventionen finden Sie unter Audit-Log-Format.
  • Wenn Sie Microsoft Entra Authentifizierung verwenden, werden fehlgeschlagene Anmeldedatensätze im SQL-Überwachungsprotokoll nicht angezeigt. Um fehlgeschlagene Anmeldeüberwachungsdatensätze anzuzeigen, müssen Sie das Microsoft Entra Admin Center besuchen, das die Details zu diesen Ereignissen protokolliert.
  • Nachdem Sie Ihre Audit-Einstellungen konfiguriert haben, können Sie die neue Bedrohungserkennungsfunktion aktivieren und E-Mail-Benachrichtigungen für den Empfang von Sicherheitswarnungen konfigurieren. Mit der Bedrohungserkennung können Sie proaktive Warnungen bei anomalen Datenbankaktivitäten erhalten, die auf mögliche Sicherheitsbedrohungen hinweisen können. Weitere Informationen finden Sie unter SQL Erweiterter Schutz vor Bedrohungen.
  • Nachdem eine Datenbank mit aktivierter Überwachung auf einen anderen logischen Server kopiert wurde, erhalten Sie möglicherweise eine E-Mail mit der Information, dass ein Fehler bei der Überwachung aufgetreten ist. Dieser Umstand ist ein bekanntes Problem, und die Auditierung sollte auf der neu kopierten Datenbank wie erwartet funktionieren.

Verwandte Inhalte

  • Zuletzt aktualisiert um