SQL-granskningsloggar i Fabric Data Warehouse

Gäller för:✅ SQL-analysslutpunkt och lager i Microsoft Fabric

Granskning i Fabric Data Warehouse ger förbättrade säkerhets- och efterlevnadsfunktioner genom att spåra och registrera databashändelser.

Genom att använda SQL-revisionsloggar kan du övervaka databasaktiviteter, upptäcka potentiella säkerhetshot och uppfylla efterlevnadskrav genom att upprätthålla en revisionsspår av viktiga åtgärder, såsom:

• Autentiseringsförsök och ändringar i åtkomstkontroll
• Åtgärder för dataåtkomst och ändring
• Schemaändringar och administrativa aktiviteter
• Behörighetsändringar och säkerhetskonfigurationer

Kom igång genom att läsa stegen i Konfigurera SQL-granskningsloggar i Fabric Data Warehouse.

Förvaring

SQL-granskningsloggar krypteras i vila och lagras i OneLake.

För Fabric Data Warehouse skrivs granskningsloggar till .XEL filer som lagras i mappen för lagergranskning i OneLake.

Användare med följande roller kan komma åt granskningsmappen:

• Arbetsyteadministratörer
• Arbetsyta Medlemmar
• Bidragsgivare arbetsyta
• Arbetsytevisare med läsbehörighet för alla

Dessa användare kan:

• Bläddra i mappen Granskning
• Visa granskningsfilerna .XEL som genereras av SQL-granskning
• Kopiera filerna för offlineanalys
• Öppna filerna med verktyg som SQL Server Management Studio (SSMS)

Du kan också köra en fråga mot granskningsloggar med T-SQL via sys.fn_get_audit_file_v2.

Se Hur du konfigurerar SQL-granskningsloggar i Fabric Data Warehouse för instruktioner.

Prestanda

Funktionen SQL audit logs är optimerad för databasens tillgänglighet och prestanda. Under perioder med mycket hög aktivitet eller hög nätverksbelastning kan granskningsfunktionen tillåta transaktioner att fortsätta utan att registrera alla händelser som markerats för granskning.

Behörigheter

Användarna måste ha behörigheten Granskningsfrågor (Granskning) för att kunna konfigurera och köra frågor mot granskningsloggar.

• Som standard har arbetsyteadministratörer behörigheten "Audit queries" till alla objekt i arbetsytan.
• Administratörer kan ge behörigheter för revisionsfrågor på objekt till andra användare via delningsmenyn.

Workspace-administratörer kan ge behörigheter för granskningsfrågor till ett objekt genom att använda alternativet delad meny i Fabric-portalen. För att verifiera om en användare har behörighet för Granskningsfrågor, kontrollera inställningarna för Hantera behörigheter.

1. I ditt lagerobjekt väljer du knappen Dela .

   Eller i Fabricportalen, i din arbetsyta. ... Välj snabbmenyn för ditt lagerobjekt och välj Hantera behörigheter.

2. I panelen Grant people access , ge behörigheter till en användare.

   

Sök igenom revisionsloggar med T-SQL-behörigheter

Ge användare behörighet VIEW DATABASE SECURITY AUDIT så att de kan söka i revisionsloggar genom att använda T-SQL-behörigheter, även om de inte har administrativa roller i arbetsområdet.

När du ger följande behörighet kan en användare fråga revisionsloggar med funktionen sys.fn_get_audit_file_v2 :

GRANT VIEW DATABASE SECURITY AUDIT TO [user];

Granskningsåtgärdsgrupper och åtgärder på databasnivå

För att göra konfigurationen av granskningsloggar mer tillgänglig använder Fabric-portalen egna namn för att hjälpa icke-SQL-administratörer och andra användare att enkelt förstå insamlade Fabric Data Warehouse-händelser.

Nätverket mappar dessa vänliga namn till de underliggande SQL Audit-åtgärdsgrupperna. Använd följande tabell som referens.

Granskningsåtgärder på databasnivå

Förutom åtgärdsgrupper kan du konfigurera enskilda granskningsåtgärder för att logga specifika databashändelser:

Minska revisionsbrus med predikatfiltrering

För att filtrera vilka händelser som fångas, använd det valfria predikatuttrycksfiltret .

Använd predikatfiltrering för att minska brus från förväntad, repetitiv aktivitet, såsom automationsidentiteter, tjänsteprinciper eller schemalagda jobb, utan att behöva inaktivera de åtgärdsgrupper som din organisation behöver för efterlevnad eller utredning.

• Endast när en händelse matchar det konfigurerade predikatet genereras SQL-revisionslogghändelsen för den åtgärden.
  • Filtreringen sker innan händelsen skrivs, så uteslutna händelser är inte tillgängliga senare för retrospektiv granskning. Behandla predikatundantag som ett medvetet revisionspolicybeslut och granska det konfigurerade predikatet periodiskt när ägande, behörigheter och riskprofiler förändras.
• Predicat-filtrering utvärderar endast händelser som redan är konfigurerade att fångas av en aktiverad revisionsaktionsgrupp eller åtgärd.
  • Om den underliggande handlingsgruppen inte är aktiverad genereras ingen händelse för predikatet att utvärdera, och filtret har ingen effekt. Till exempel, för att filtrera SELECT satser med ett predikat på statement fältet måste du först aktivera handlingsgruppen Batch Was Completed (BATCH_COMPLETED_GROUP) åtgärdsgruppen.

Du kan konfigurera ett predikatuttryck genom att använda Fabric-portalen eller REST API:et. För steg, se Konfigurera ett predikatuttryck.

Predikatuttryckssyntax

Predikatuttryck använder samma syntax som satsen <predicate_expression> i CREATE SERVER AUDIT (Transact-SQL), utan WHERE nyckelordet:

<predicate_expression> ::=
    { [ NOT ] <predicate_factor>
    [ { AND | OR } [ NOT ] { <predicate_factor> } ] [ ,... n ] }

<predicate_factor> ::=
    event_field_name { = | <> | != | > | >= | < | <= | LIKE }
    { number | 'string' }

• event_field_name motsvarar en kolumn som returneras av sys.fn_get_audit_file (Transact-SQL). Du kan använda alla dokumenterade kolumner, förutom file_name, audit_file_offset, och event_time.
• action_id och class_type är strängar, men du kan bara jämföra dem med numeriska värden i ett predikat.
• Strängjämförelser utför inte implicit typkonvertering.
• Den maximala uttryckslängden är 3 000 tecken.
• En tom sträng betyder att inget predikat tillämpas.

Till exempel, för att utesluta aktivitet som genereras av en känd tjänsteprincip eller automationsidentitet, filtrera på server_principal_name. För att utesluta upprepade SELECT påståenden, filtrera på fältet statement : NOT statement LIKE 'SELECT %'.

Begränsningar

• Standardarbetsytan stöder inte SQL-granskningsloggar.
• SQL-granskningsloggar stöds inte för ögonblicksbilder av lager.

Begränsningar för SQL-analysslutpunkter

Följande begränsningar gäller vid granskning av SQL-analysslutpunkter:

• DML-åtgärder registreras inte. Granskningen registrerar inte åtgärder som INSERT, UPDATE, DELETEoch MERGE eftersom datamanipulering för Lakehouse-tabeller sker via Lakehouse-körningen i stället för via SQL-analysslutpunkten.
• Direkt åtkomst till granskningsmappen stöds inte för närvarande. Användare kan inte bläddra eller ladda ned de underliggande .XEL granskningsfilerna från lakehouse-granskningsmappen.

Du kan fortfarande fråga revisionshändelser för SQL-analysendpoints genom att använda T-SQL-funktionen sys.fn_get_audit_file_v2.

Nästa steg

Relaterat innehåll

• Säkerhet för datalagerhantering i Microsoft Fabric
• Säkerhet i Microsoft Fabric