Revisjon for SQL-database i Fabric

Gjelder for:✅SQL-database i Microsoft Fabric

Revisjon av SQL-databaser i Fabric er en kritisk sikkerhets- og samsvarsfunksjon som gjør det mulig for organisasjoner å spore og loggføre databaseaktiviteter. Revisjon støtter etterlevelse, trusseldeteksjon og rettsmedisinske undersøkelser ved å hjelpe til med å besvare spørsmål som hvem som fikk tilgang til hvilke data, når og hvordan.

Hva er SQL-revisjon?

SQL-revisjon refererer til prosessen med å fange og lagre hendelser knyttet til databaseaktivitet. Disse hendelsene inkluderer datatilgang, skjemaendringer, tillatelsesendringer og autentiseringsforsøk.

I Fabric fungerer revisjon på databasenivå og støtter:

  • Samsvarsovervåking (for eksempel: HIPAA, SOX)
  • Sikkerhetsundersøkelser
  • Operasjonelle innsikter

Revisjonsmål

Revisjonslogger skrives til en skrivebeskyttet mappe i OneLake og kan forespørres ved hjelp av sys.fn_get_audit_file_v2 T-SQL-funksjonen eller OneLake Explorer.

For SQL-databaser i Fabric lagres revisjonslogger i OneLake: https://onelake.blob.fabric.microsoft.com/{workspace_id}/{artifact_id}/Audit/sqldbauditlogs/

Disse loggene er uforanderlige og tilgjengelige for brukere med passende tillatelser. Logger kan også lastes ned ved hjelp av OneLake Explorer eller Azure Storage Explorer.

Fakturering

For øyeblikket påløper det ingen ekstra kostnader å skrive revisjonslogger til Fabric OneLake, og lagring er inkludert som en del av kapasitetens OneLake-lagringsgrenser.

Alternativer for konfigurasjon

Som standard fanger Audit everything-alternativet opp alle hendelser, inkludert batch-fullføringer og vellykket og mislykket autentisering.

For å være mer selektiv, velg blant forhåndskonfigurerte revisjonsscenarier, for eksempel: Tillatelsesendringer og innloggingsforsøk, datalesing og -skriving, og/eller skjemaendringer.

Hvert forhåndskonfigurert scenario kartlegges til spesifikke revisjonsaksjonsgrupper (for eksempel SCHEMA_OBJECT_ACCESS_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP). Du kan også velge hvilke hendelser du vil revidere under Egendefinerte hendelser. Du kan velge individuelle aksjonsgrupper for å tilpasse revisjonen til dine behov. Dette alternativet er ideelt for organisasjoner med strenge interne sikkerhetspolicyer.

For å filtrere ut vanlige eller kjente tilgangsforespørsler kan du angi predikatuttrykk i Transact-SQL (T-SQL) for å filtrere ut revisjonshendelser basert på betingelser (for eksempel for å ekskludere SELECT-setninger): WHERE statement NOT LIKE '%select%'.

Tillatelser

For å administrere revisjon ved bruk av Fabric-workspace-roller (anbefalt), må du ha medlemskap i Fabric workspace Contributor-rollen eller høyere tillatelser.

For å administrere revisjon med SQL-tillatelser:

  • For å konfigurere databaserevisjonen må du ha tillatelse ENDRE ENHVER DATABASEREVISJON.
  • For å se revisjonslogger med T-SQL, må du ha tillatelsen VIEW DATABASE SECURITY AUDIT.

Oppbevaring

Som standard lagres revisjonsdata på ubestemt tid, med mindre du konfigurerer en tilpasset oppbevaringsperiode som automatisk sletter logger etter denne perioden.

Fabric lagrer for øyeblikket revisjonslogger i varens mappe i OneLake og begrenser dem til varelivssyklusen. Hvis du sletter elementet, sletter Fabric også revisjonsloggene sine. Hvis du krever oppbevaring uavhengig av produktets livssyklus, flytt revisjonsloggene til et annet lagringssted (for eksempel en annen Lakehouse- eller Azure Storage-konto) ved hjelp av verktøy som AzCopy eller SSDT.

Bevaring av innstillinger etter gjenoppretting

Etter en gjenopprettingsoperasjon beholdes revisjonsinnstillingene, men revisjon må aktiveres på nytt i Fabric SQL Database. I Fabric-portalen, åpne Manage SQL auditing, velg Save.

Konfigurer revisjon for SQL-databasen fra Fabric-portalen

For å begynne auditing for en Fabric SQL-database:

  1. Gå til og åpne SQL-databasen din i Fabric-portalen.
  2. Fra hovedmenyen, velg fanen Sikkerhet, og velg deretter Administrer SQL-revisjon. Skjermbilde fra Fabric-portalen, som viser Sikkerhetsfanen og knappen Administrer SQL-revisjon.
  3. Panelet Administrer SQL-revisjon åpnes.
  4. Velg knappen Save Events to SQL Audit Logs for å aktivere revisjon.
  5. Konfigurer hvilke hendelser som skal lagres i seksjonen Databasehendelser . Velg Revider alt (standard) for å fange opp alle hendelser.
  6. Eventuelt kan du konfigurere en oppbevaringspolicy under Retention.
  7. Eventuelt kan du konfigurere et predikatuttrykk av T-SQL-kommandoer som ignoreres i feltet Predicate Expression .
  8. Velg Lagre.

Overvåkingslogger for spørring

Revisjonslogger kan forespørres ved hjelp av T-SQL-funksjonene sys.fn_get_audit_file og sys.fn_get_audit_file_v2.

I skriptet nedenfor må du angi arbeidsområde-ID-en og database-ID-en. Begge kan finnes i URL-en fra Fabric-portalen. Eksempel: https://fabric.microsoft.com/groups/<fabric workspace id>/sqldatabases/<fabric sql database id>. Den første unike identifikatorstrengen i URL-en er Fabric workspace ID, og den andre unike identifikatorstrengen er SQL-database-ID.

  • Erstatt <fabric_workspace_id> med ID-en for Fabric-arbeidsområdet. Du kan finne ID-en til et arbeidsområde i URL-en, det er den unike strengen innenfor to / tegn etter /groups/ i nettleservinduet ditt.
  • Erstatt <fabric sql database id> med SQL-databasen i Strukturdatabase-ID. Du kan finne ID-en til databaseelementet i URL-en, det er den unike strengen innenfor to / tegn etter /sqldatabases/ i nettleservinduet ditt.

Eksempler:

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 );

Dette eksempelet henter revisjonslogger mellom 2025-11-17T08:40:40Z og 2025-11-17T09:10:40Z.

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')

For mer informasjon, se sys.fn_get_audit_file og sys.fn_get_audit_file_v2.

Administrer revisjon med REST API-et

Du kan også se og konfigurere SQL-databaserevisjonsinnstillinger programmatisk ved hjelp av Fabric REST API. REST API-et gjør det mulig å administrere revisjon konsekvent på tvers av alle databaser i et arbeidsområde ved hjelp av PowerShell-skript.

For mer informasjon, se Administrer SQL-databaserevisjon med REST API.

Beskytt sensitiv informasjon i revisjonslogger

Når du konstruerer dynamisk SQL ved å sette sammen inndataverdier direkte i SQL-setningen, blir disse verdiene en del av setningsteksten. Hvis du reviderer kontoutskriften, kan revisjonsloggen fange sensitiv informasjon som er inkludert i teksten til kontoutskriften.

For å redusere risikoen for å eksponere sensitiv informasjon, følg disse praksisene:

  • Unngå dynamisk SQL for operasjoner som inneholder sensitive verdier

    For sikkerhetssensitive administrative operasjoner, unngå å konstruere setninger ved å sette sammen sensitive verdier i dynamisk SQL. Der det er mulig, bruk native SQL-setninger eller andre metoder som forhindrer at sensitive verdier blir innebygd direkte i setningsteksten.

    Dynamiske SQL-setninger som er konstruert av brukertilgjengelige strenger gjør også applikasjonene dine sårbare for SQL-injeksjonsangrep. SQL-injeksjon er et angrep der ondsinnet kode settes inn i strenger som senere sendes til databasen for parsing og utførelse. Du må teste enhver prosedyre som konstruerer T-SQL for SQL-injeksjonssårbarheter, fordi databasemotoren utfører alle syntaktisk gyldige spørringer den mottar. Bruk parametere for dataverdier, og aldri sett sammen parameterverdier i spørringstekst. Korrekt parameteriserte verdier behandles som data i stedet for kjørbar SQL-syntaks.

  • Begrens tilgangen til revisjonslogger

    Begrens tilgangen til revisjonslogger til autoriserte brukere og administratorer. Inne i SQL databasemotor styrer SQL-tillatelser revisjonstilgang i SQL databasemotor, og kan variere avhengig av plattform og revisjonsomfang. Følg prinsippet om minste privilegium og gi kun de tillatelsene som kreves for å administrere eller gjennomgå revisjonsinformasjon. Det finnes separate servernivå- og databasenivå-revisjonstillatelsesmodeller, og Azure SQL Database skiller seg fra SQL Server ved tilgjengeligheten av servernivå-tillatelser. Å begrense tilgangen til revisjonsdata bidrar til å redusere risikoen for uautorisert utlevering når sensitiv informasjon er til stede i registrerte revisjonshendelser.

    Tilgang til revisjonslogger utenfor SQL databasemotor avhenger av tillatelser i den konfigurerte destinasjonen (som OneLake). Følg prinsippet om minste privilegium og gi kun de tillatelsene som kreves for å administrere eller gjennomgå revisjonsinformasjon.

Relatert innhold

  • Last updated on