Azure SQL databases on a logical server with auditing switched off
What does ZopNight detect here?
ZopNight flags an Azure SQL database when auditing is off on its logical server, the setting every database on that server inherits. Without it, no record of logins, queries or permission changes reaches a storage account, Log Analytics workspace or Event Hubs. Severity is medium and no saving is claimed, since enabling auditing adds log cost.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1331 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | server auditing disabled |
| Source | ZopNight |
| Permissions used | Microsoft.Sql/servers/databases/read · Microsoft.Sql/servers/auditingSettings/read |
Where it applies
No audit, no record of who touched the data
Auditing for Azure SQL Database tracks database events and writes them to an audit log in an Azure storage account, a Log Analytics workspace or Event Hubs. It is how you answer, after the fact, which login ran a destructive query, who granted a permission, or whether a leaked credential was used.
Most compliance frameworks expect this trail. With auditing off, the events are never captured and cannot be reconstructed later.
Checking auditing on a server
az sql server audit-policy show --resource-group my-rg --name my-serverLook at state and at which destinations are enabled: blob storage, Log Analytics or Event
Hubs. A Disabled state means no server-level audit is being written.
Server-level auditing is what ZopNight reads
ZopNight evaluates each database but reads the auditing state of the logical server it lives on, which all of that server’s databases inherit. It fires when Azure reports that state as off. There is no metric or window; the check repeats on every scan.
When the rule stays quiet
If ZopNight could not read the server’s auditing state, it raises nothing for the server’s databases. Tags on the database or server are not consulted. Because the rule looks at the server policy, a database with its own database-level audit policy can still be flagged while server auditing is off; that is the main case to dismiss with a note.
Compliance exposure, and a logging bill if you fix it
This finding claims no saving. Enabling auditing adds destination costs: storage for append-blob
.xel files, Log Analytics ingestion, or Event Hubs throughput. Microsoft warns that server-level
auditing with default settings on busy OLTP servers can produce very large audit volumes, so
plan retention and filtering.
Turning server auditing on
- Choose the destination. Log Analytics is easiest to query; storage is cheapest to retain.
- Enable it, for example to a workspace:
az sql server audit-policy update --resource-group my-rg --name my-server \ --state Enabled --lats Enabled \ --lawri /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<ws>- For storage targets, use
--bsts Enabled --storage-account mystorageand set a retention period that matches your compliance requirement. - Limit who can read audit logs in the destination; Microsoft recommends least privilege there as well.
- Run a query and confirm events appear.