Still in preview, you can send your Azure-based SQL Server Audit logs to the same Log Analytics workspace that is being used by Azure Sentinel.
In many other services, you would enable a Diagnostic Setting to send the logs to Azure Sentinel. But, Azure SQL Server is a bit different so it’s good to highlight.
- In your SQL Server instance, jump to the Auditing blade.
- Enable Azure SQL Auditing by toggling the switch.
- Select the Log Analytics workspace for which you want to send the log files (your Azure Sentinel workspace).
- Save it.
Also, note that there’s an option now that you can turn on logging for when Microsoft support persons are called on to help with service issues for your SQL Server instances.
Auditing data is stored in the AzureDiagnostics table in a SQLSecurityAuditEvents category:
AzureDiagnostics | where TimeGenerated > ago(24h) | where Category == "SQLSecurityAuditEvents"
All audit log fields can be researched here: https://docs.microsoft.com/en-us/azure/azure-sql/database/audit-log-format#subheading-1
Some ideas of things you want to look for:
- Audit trail
- Database activity
- Suspicious events
- Unusual activity
P.S. If you decide to enable this, it comes with a sort of gotcha – or at least a scary message. When you start shifting through Azure Sentinel blades you’ll be met with the following message periodically…
A Delete lock gets placed against the Resource Group for the Log Analytics Workspace when enabling the SQL Audit log flow. There’s no other indication that this is going to happen other than the nasty message that starts popping up.
You can jump into the Resource Group for the Log Analytics Workspace and delete the locks and the Audit logs still continue to flow just fine. Make sure to log out of the Azure portal and back in for the changes to take effect.