Auditing in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse är ett relationslager i företagsskala på en datasjögrund med en framtidsklar arkitektur, inbyggd AI och nya funktioner. Om du är nybörjare på datalager börjar du med Fabric Data Warehouse. Befintliga dedicerade SQL-poolarbetsbelastningar kan uppgraderas till Fabric för att få åtkomst till nya funktioner inom datavetenskap, realtidsanalys och rapportering.

Azure Synapse Analytics granskning spårar databashändelser och skriver dem till Azure Storage, ett Azure Monitor Log Analytics-arbetsområde eller Azure Event Hubs.

Granskning hjälper dig:

  • Upprätthåll en spårningslogg för valda händelser.
  • Förstå databasens aktivitet och undersök avvikelser eller anomalier.
  • Rapport om aktivitet med hjälp av frågor, arbetsböcker och verktyg för nedströms övervakning.
  • Stöd för regelefterlevnads- och organisationskrav. Granskning garanterar inte efterlevnad i sig.

Overview

Du kan använda SQL Database-granskning för att:

  • Behåll en spårningslogg med valda händelser. Du kan definiera kategorier av databasåtgärder som ska granskas.
  • Rapportera om databasaktivitet. Du kan använda förkonfigurerade rapporter och en instrumentpanel för att komma igång snabbt med aktivitets- och händelserapportering.
  • Analysera rapporter. Du hittar misstänkta händelser, ovanlig aktivitet och trender.

Important

Granskning är optimerad för tillgängligheten och prestandan hos SQL-poolen. Under perioder med mycket hög aktivitet eller nätverksbelastning kan transaktioner genomföras utan att varje vald händelse registreras.

För miljöer med många databaser som kör tunga OLTP-arbetsbelastningar kan användning av granskning på servernivå med standardinställningar leda till mycket stora granskningsvolymer på den logiska servern. Eftersom alla händelser från alla databaser skrivs till samma granskningsmapp blir det långsamt och driftsmässigt kostsamt att köra frågor mot granskningsloggar för en enskild databas. För att förbättra prestanda och minska bruset:

  • Växla till granskning på databasnivå. Varje databas skriver till sin egen granskningsloggmapp, vilket minskar den totala volymen som genomsöks och gör hämtningen snabbare.
  • Granska granskningskonfigurationen. Ta reda på om det är nödvändigt att samla in alla batch-slutförda händelser eller om en anpassad filtrerad konfiguration kan uppfylla dina säkerhets- och efterlevnadskrav.

Skydda känslig information i revisionsloggar

Granskad instruktionstext kan innehålla känsliga värden när applikationer sammanfogar dessa värden i dynamisk SQL. Använd parametrar för datavärden, undvik att bädda in hemligheter eller personuppgifter i frågetext, och begränsa åtkomst till revisionsloggar till auktoriserade användare.

Behörigheter på revisionsdestinationen kontrollerar åtkomst utanför SQL-motorn. Tillämpa least privilege på Azure Storage, Log Analytics och Event Hubs, och övervaka åtkomsten till dessa resurser.

Limitations

  • Du kan inte aktivera granskning på en pausad dedikerad SQL-pool. Återuppta poolen innan du aktiverar policyn.
  • Användartilldelade hanterade identiteter stöds inte för granskning i Azure Synapse Analytics.
  • En systemtilldelad hanterad identitet stöds för en Azure Storage-destination när lagringskontot är bakom ett virtuellt nätverk eller brandvägg. Managed IDENTITIES stöds inte för Azure Synapse om inte lagringskontot är bakom ett virtuellt nätverk eller brandvägg.
  • Synapse SQL-pooler stöder endast standardgrupperna för granskningsåtgärder.
  • Granskning stöds inte i databaser med namn som innehåller ? tecknet. Denna begränsning gäller både revision på servernivå och databasnivårevision, eftersom databaser med ? i deras namn inte längre stöds på Azure.
  • Granskningsposter lagrar upp till 4 000 tecken i fälten statement och data_sensitivity_information. Ytterligare tecken är avkortade.

Anmärkningar

  • Händelser som initieras av SQLDBControlPlaneFirstPartyApp i aktivitetsloggen är en intern Azure funktion i kontrollplanet Azure SQL Database. Händelser som initieras av SQLDBControlPlaneFirstPartyApp ingår i en intern synkroniseringsåtgärd mellan SQL-motorn och Azure Resource Manager. Dessa händelser är en normal del av Azure SQL Database hantering och krävs för korrekt resursrepresentation och åtgärd i Azure.
  • Premium-lagring med BlockBlobStorage stöds. Standardlagring stöds. För att skriva revisionsloggar till ett lagringskonto bakom ett virtuellt nätverk eller en brandvägg måste du dock använda ett allmänt lagringskonto v2. Om du använder ett konto för generell användning v1 eller ett Blob Storage-konto, uppgraderar du till ett lagringskonto för generell användning v2. För specifika instruktioner, se Skriv revisionsloggar till ett lagringskonto bakom ett virtuellt nätverk och brandvägg. Mer information finns i Typer av lagringskonton.
  • När du aktiverar SQL-granskning och konfigurerar begränsningar för utgående nätverk måste du lägga till de fullt kvalificerade domännamnen för ditt granskningslagringskonto i tillåtelselistan för att säkerställa att granskningshändelser når destinationen. Om du inte tillåtslistar lagringsändpunkten blockeras revisionstrafiken, vilket leder till förlust av revisionshändelser. Efter att ha lagt till de nödvändiga FQDN:erna för lagringskontot i tillåtslistan måste du spara din granskningskonfiguration igen för att återuppta det normala granskningshändelseflödet.
  • Hierarkisk namnrymd för alla typer av standardlagringskonto och premiumlagringskonto med BlockBlobStorage stöds.
  • Auditloggar skrivs till Append Blobs i en Azure Blob Storage på din Azure-prenumeration.
  • Granskningsloggarna är i .xel-format och kan öppnas med SQL Server Management Studio (SSMS).
  • Om du vill konfigurera ett oföränderligt loggarkiv för granskningshändelser på server- eller databasnivå följer du de instruktioner som tillhandahålls av Azure Storage. När du konfigurerar oföränderlig bloblagring för granskning kontrollerar du att Tillåt skyddade tilläggsskrivningar är inställt på antingen Tilläggsblobar eller Blockera och lägg till blobar. Alternativet Ingen stöds inte. För tidsbaserade kvarhållningsprinciper måste lagringskontots kvarhållningsintervall vara kortare än kvarhållningsinställningen för SQL-granskning. Konfigurationer där lagringsprincipen har angetts, men kvarhållningen för SQL-revisionen är 0, stöds inte.
  • Du kan skriva granskningsloggar till ett Azure Storage-konto bakom ett virtuellt nätverk eller en brandvägg.
  • För detaljer om loggformatet, hierarkin i lagringsmappen och namngivningskonventioner, se revisionsloggformat.
  • När du använder Microsoft Entra-autentisering visas misslyckade inloggningsposter inte i SQL-granskningsloggen. Om du vill visa misslyckade inloggningsgranskningsposter måste du besöka Administrationscenter för Microsoft Entra, som loggar information om dessa händelser.
  • Efter att du konfigurerat dina inställningar för granskning kan du slå på den nya hotdetekteringsfunktionen och konfigurera e-post för att ta emot säkerhetsvarningar. När du använder hotidentifiering får du proaktiva aviseringar om avvikande databasaktiviteter som kan tyda på potentiella säkerhetshot. Mer information finns i SQL Advanced Threat Protection.
  • När en databas med granskning aktiverat har kopierats till en annan logisk serverkan du få ett e-postmeddelande om att granskningen misslyckades. Detta tillstånd är ett känt problem och auditering bör fungera som förväntat på den nykopierade databasen.

Relaterat innehåll

  • Uppdaterades senast