Auditing in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse is een relationeel warehouse op ondernemingsniveau op data lake-basis, met een architectuur die klaar is voor de toekomst, ingebouwde AI en nieuwe functies. Als u nieuw bent in gegevensopslag, begin dan met Fabric Data Warehouse. Bestaande dediceerde SQL-poolworkloads kunnen upgraden naar Fabric voor toegang tot nieuwe mogelijkheden in data science, realtime analyses en rapportage.

Azure Synapse Analytics auditing volgt databasegebeurtenissen en schrijft deze naar Azure Storage, een Azure Monitor Log Analytics workspace of Azure Event Hubs.

Controle helpt je om:

  • Een audittrail van geselecteerde gebeurtenissen bewaren.
  • Begrijp database-activiteiten en onderzoek afwijkingen of anomalieën.
  • Rapporteer activiteiten met behulp van zoekopdrachten, werkboeken en downstream monitoringtools.
  • Ondersteunt regelgeving en organisatorische compliance-eisen. Audit garandeert op zichzelf geen naleving.

Overview

U kunt SQL Database-controle gebruiken om het volgende te doen:

  • Behoud een audit trail van geselecteerde gebeurtenissen. U kunt categorieën van databaseacties definiëren die moeten worden gecontroleerd.
  • Rapport over databaseactiviteit. U kunt vooraf geconfigureerde rapporten en een dashboard gebruiken om snel aan de slag te gaan met activiteiten- en gebeurtenisrapportage.
  • Analyseer rapporten. U kunt verdachte gebeurtenissen, ongebruikelijke activiteiten en trends vinden.

Important

Controle is geoptimaliseerd voor de beschikbaarheid en prestaties van de SQL-pool. Tijdens periodes van zeer hoge activiteit of netwerkbelasting kunnen transacties verlopen zonder dat elk geselecteerd evenement wordt geregistreerd.

Voor omgevingen met veel databases waarop zware OLTP-workloads worden uitgevoerd, kan het gebruik van controle op serverniveau met standaardinstellingen leiden tot zeer grote controlevolumes op de logische server. Omdat alle gebeurtenissen van alle databases worden weggeschreven naar dezelfde auditmap, wordt het uitvoeren van query's op auditlogboeken voor één database traag en operationeel duur. Prestaties verbeteren en ruis verminderen:

  • Schakel over naar controle op databaseniveau. Elke database schrijft naar een eigen auditlogboekmap, waardoor het totale gescande volume wordt verminderd en sneller wordt opgehaald.
  • Controleer de auditconfiguratie. Bepaal of het vastleggen van alle batchgebeurtenissen nodig is of of als een aangepaste gefilterde configuratie kan voldoen aan uw beveiligings- en nalevingsvereisten.

Bescherm gevoelige informatie in auditlogboeken

Gecontroleerde statementtekst kan gevoelige waarden bevatten wanneer applicaties die waarden opnemen in dynamische SQL. Gebruik parameters voor datawaarden, vermijd het inbedden van geheimen of persoonlijke gegevens in querytekst, en beperk de toegang tot auditlogboeken tot gemachtigde gebruikers.

Rechten op de auditbestemming regelen de toegang buiten de SQL-engine. Pas least privilege toe op Azure Storage, Log Analytics en Event Hubs, en monitor de toegang tot die bronnen.

Limitations

  • U kunt de auditfuncties niet inschakelen voor een gepauzeerde toegewezen SQL-pool. Hervat de pool voordat je het policy inschakelt.
  • Door de gebruiker toegewezen beheerde identiteiten worden niet ondersteund voor auditing in Azure Synapse Analytics.
  • Een systeem-toegewezen beheerde identiteit wordt ondersteund voor een Azure Storage-bestemming wanneer het opslagaccount zich achter een virtueel netwerk of firewall bevindt. Beheerde identiteiten worden niet ondersteund voor Azure Synapse, tenzij het opslagaccount achter een virtueel netwerk of firewall zit.
  • Synapse SQL-pools ondersteunen alleen de standaard auditactiegroepen.
  • Controle wordt niet ondersteund voor databases met namen die het ? teken bevatten. Deze beperking geldt zowel voor auditing op serverniveau en databaseniveau, aangezien databases met ? in hun naam niet meer worden ondersteund op Azure.
  • Auditgegevens slaan tot 4.000 tekens op in de statement en data_sensitivity_information velden. Extra tekens worden afgekapt.

Remarks

  • Gebeurtenissen die zijn geïnitieerd door SQLDBControlPlaneFirstPartyApp in het activiteitenlogboek zijn een interne Azure functie van het Azure SQL Database besturingsvlak. Gebeurtenissen die zijn geïnitieerd door SQLDBControlPlaneFirstPartyApp maken deel uit van een interne synchronisatiebewerking tussen de SQL-engine en Azure Resource Manager. Deze gebeurtenissen zijn een normaal onderdeel van Azure SQL Database beheer en zijn vereist voor de juiste resourceweergave en -bewerking in Azure.
  • Premium-opslag met BlockBlobStorage- wordt ondersteund. Standard-opslag wordt ondersteund. Om auditlogs te schrijven naar een opslagaccount achter een virtueel netwerk of firewall, moet je echter een opslagaccount voor algemeen gebruik v2 gebruiken. Als je een account voor algemeen gebruik v1 of een Blob Storage-account gebruikt, upgrade dan naar een opslagaccount voor algemeen gebruik v2. Voor specifieke instructies, zie Schrijf auditlogboeken naar een opslagaccount achter een virtueel netwerk en firewall. Zie Typen opslagaccounts voor meer informatie.
  • Wanneer je SQL-auditing inschakelt en uitgaande netwerkbeperkingen configureert, moet je de volledig gekwalificeerde domeinnamen van je auditing-opslagaccount op de acceptatielijst plaatsen, zodat auditgebeurtenissen de bestemming kunnen bereiken. Als je het opslag-endpoint niet op de allowlist zet, wordt auditverkeer geblokkeerd, wat resulteert in verlies van auditgebeurtenissen. Nadat je de vereiste FQDN's voor opslagaccounts aan de toestemmingslijst hebt toegevoegd, moet je je auditconfiguratie opnieuw opslaan om de normale auditgebeurtenisstroom te hervatten.
  • hiërarchische naamruimte voor alle typen standard-opslagaccount en Premium-opslagaccount met BlockBlobStorage- wordt ondersteund.
  • Auditlogs worden geschreven naar Append Blobs in een Azure Blob Storage op je Azure-abonnement.
  • Auditlogboeken hebben de indeling .xel en kunnen worden geopend met SQL Server Management Studio (SSMS).
  • Als u een onveranderbaar logboekarchief wilt configureren voor controlegebeurtenissen op server- of databaseniveau, volgt u de instructies van Azure Storage. Wanneer u onveranderbare blobopslag configureert voor controle, moet u ervoor zorgen dat beveiligde toevoegschrijfbewerkingen zijn ingesteld op toevoeg-blobs of blok-blobs en toevoeg-blobs. De optie Geen wordt niet ondersteund. Voor bewaarbeleid op basis van tijd moet het retentie-interval van het opslagaccount korter zijn dan de retentie-instelling van SQL Auditing. Configuraties waarbij het opslagbeleid is ingesteld, maar SQL-auditingretentie is 0, worden niet ondersteund.
  • U kunt auditlogboeken schrijven naar een Azure Storage-account achter een virtueel netwerk of een firewall.
  • Voor details over het logboekformaat, hiërarchie van de opslagmap en naamgevingsconventies, zie auditlogindeling.
  • Wanneer u Microsoft Entra-authenticatie gebruikt, worden records van mislukte aanmeldingen niet weergegeven in het SQL-auditlogboek. Als u mislukte aanmeldingscontrolerecords wilt weergeven, moet u naar de Microsoft Entra-beheercentrum gaan, waarin de details van deze gebeurtenissen worden vastgelegd.
  • Nadat je je auditinstellingen hebt geconfigureerd, kun je de nieuwe dreigingsdetectiefunctie inschakelen en e-mailmeldingen configureren voor het ontvangen van beveiligingswaarschuwingen. Wanneer u bedreigingsdetectie gebruikt, ontvangt u proactieve waarschuwingen over afwijkende databaseactiviteiten die mogelijke beveiligingsrisico's kunnen aangeven. Zie SQL Advanced Threat Protection voor meer informatie.
  • Nadat een database met controle is ingeschakeld, is gekopieerd naar een andere logische server, ontvangt u mogelijk een e-mailbericht met de melding dat de controle is mislukt. Deze situatie is een bekend probleem en de auditing zou moeten werken zoals verwacht op de nieuw gekopieerde database.

Verwante onderwerpen

  • Laatst bijgewerkt om