Controles uitvoeren voor Azure SQL Database en Azure Synapse Analytics

Van toepassing op: Azure SQL DatabaseAzure Synapse Analytics

Controle voor Azure SQL Database en Azure Synapse Analytics houdt databasegebeurtenissen bij en schrijft deze naar een auditlogboek in uw Azure-opslagaccount, Log Analytics-werkruimte of Event Hubs.

De controlefunctie biedt ook deze mogelijkheden:

• Naleving van wet- en regelgeving, inzicht in activiteiten in de database en in de afwijkingen en discrepanties die kunnen wijzen op problemen voor het bedrijf of vermoedelijke schendingen van de beveiliging.

• Mogelijk maken en faciliteren van nalevingsstandaarden, hoewel dit geen garantie biedt voor naleving. Zie het Vertrouwenscentrum van Microsoft Azure voor meer informatie, waar u de meest recente lijst met SQL Database-nalevingscertificeringen kunt vinden.

Overzicht

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

• Een audittrail van geselecteerde gebeurtenissen behouden . U kunt categorieën van database-acties definiëren die moeten worden gecontroleerd.
• Rapporteren over databaseactiviteit. U kunt vooraf geconfigureerde rapporten en een dashboard gebruiken om snel aan de slag te gaan met de rapportage van activiteiten en gebeurtenissen.
• Rapporten analyseren . U kunt verdachte gebeurtenissen, ongebruikelijke activiteit en trends vinden.

Beperkingen voor controle

• Het inschakelen van controle voor een onderbroken Azure Synapse SQL-pool wordt niet ondersteund. Als u controle wilt inschakelen, hervat u de Synapse SQL-pool.
• Het inschakelen van controle met behulp van door de gebruiker toegewezen beheerde identiteit (UAMI) wordt niet ondersteund in Azure Synapse.
• Controle voor Azure Synapse SQL-pools ondersteunt alleen standaardactiegroepen voor controle.
• Wanneer u controle configureert voor een logische server in Azure of Azure SQL Database met de logboekbestemming als opslagaccount, moet de verificatiemodus overeenkomen met de configuratie voor dat opslagaccount. Als u opslagtoegangssleutels als verificatietype gebruikt, moet het doelopslagaccount zijn ingeschakeld met toegang tot de opslagaccountsleutels. Als het opslagaccount is geconfigureerd voor alleen verificatie met Microsoft Entra-id (voorheen Azure Active Directory), kan controle worden geconfigureerd voor het gebruik van beheerde identiteiten voor verificatie.

Opmerkingen

• Premium-opslag met BlockBlobStorage wordt ondersteund. Standard-opslag wordt ondersteund. Voor controle om te schrijven naar een opslagaccount achter een VNet of firewall, moet u echter een v2-opslagaccount voor algemeen gebruik hebben. Als u een v1- of Blob Storage-account voor algemeen gebruik hebt, voert u een upgrade uit naar een v2-opslagaccount voor algemeen gebruik. Zie audit schrijven naar een opslagaccount achter VNet en firewall voor specifieke instructies. Zie Typen opslagaccounts voor meer informatie.
• Hiërarchische naamruimte voor alle typen Standard-opslagaccount en Premium-opslagaccount met BlockBlobStorage wordt ondersteund.
• Auditlogboeken worden geschreven naar toevoeg-blobs in een Azure Blob Storage in uw 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 de controlegebeurtenissen op server- of databaseniveau, volgt u de instructies van Azure Storage. Zorg ervoor dat u aanvullende toevoeggegevens toestaan hebt geselecteerd wanneer u de onveranderbare blobopslag configureert.
• U kunt auditlogboeken schrijven naar een Azure Storage-account achter een VNet of firewall.
• Voor meer informatie over de logboekindeling, de hiërarchie van de opslagmap en naamconventies raadpleegt u de naslaginformatie over de blob-auditlogboekindeling.
• Controle op alleen-lezen replica's wordt automatisch ingeschakeld. Zie de indeling van het auditlogboek van SQL Database voor meer informatie over de hiërarchie van de opslagmappen, naamconventies en logboekindeling.
• Wanneer u Microsoft Entra-verificatie gebruikt, worden mislukte aanmeldingsrecords niet weergegeven in het SQL-auditlogboek. Als u mislukte aanmeldingscontrolerecords wilt weergeven, moet u het Microsoft Entra-beheercentrum bezoeken, waarin de details van deze gebeurtenissen worden vastgelegd.
• Aanmeldingen worden door de gateway doorgestuurd naar het specifieke exemplaar waarin de database zich bevindt. Met Microsoft Entra-aanmeldingen worden de referenties geverifieerd voordat deze gebruiker wordt gebruikt om zich aan te melden bij de aangevraagde database. In het geval van een storing wordt de aangevraagde database nooit geopend, dus wordt er geen controle uitgevoerd. Met SQL-aanmeldingen worden de referenties gecontroleerd op de aangevraagde gegevens, dus in dit geval kunnen ze worden gecontroleerd. Geslaagde aanmeldingen, die uiteraard de database bereiken, worden in beide gevallen gecontroleerd.
• Nadat u uw controle-instellingen hebt geconfigureerd, kunt u de nieuwe functie voor detectie van bedreigingen inschakelen en e-mailberichten configureren om beveiligingswaarschuwingen te ontvangen. Wanneer u bedreigingsdetectie gebruikt, ontvangt u proactieve waarschuwingen over afwijkende databaseactiviteiten die kunnen wijzen op mogelijke beveiligingsrisico's. Zie Aan de slag met detectie van bedreigingen 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. Dit is een bekend probleem en controle moet werken zoals verwacht in de zojuist gekopieerde database.

Volgende stappen

Zie ook

• Aflevering met gegevens beschikbaar gesteld wat er nieuw is in Azure SQL Auditing
• Controle voor SQL Managed Instance
• Controle voor SQL Server