Azure SQL databases whose server-level auditing is switched off
What does ZopNight detect here?
ZopNight flags an Azure SQL database when the discoverer-stamped audit_enabled flag reads exactly "false", meaning server-level auditing is off and no queries, logins, or changes are being logged. Rule RC-1331 rates this medium severity, abstains when the flag is absent, and the fix, server-level auditing, covers every database on the server at once.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1331 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | sql_auditing.go |
Where it applies
The forensic gap an auditor will find first
With auditing off, an Azure SQL database keeps no record of who queried it, who logged in, or what changed. When something goes wrong (a data leak, a dropped table, an access-review question), there is nothing to reconstruct from. Most compliance frameworks that touch databases (SOC 2, PCI DSS, HIPAA) expect database event logging, and “auditing: disabled” is one of the fastest findings an assessor can write up. The exposure is not that an attacker gets in more easily; the exposure is that nobody can prove what an attacker, or an insider, did once inside.
Detection is proved, not inferred
ZopNight does not guess from tags or naming. The Azure discoverer reads the live server
auditing settings through the ARM API and stamps the result into resource metadata as
audit_enabled. Rule RC-1331 fires only when that flag is exactly "false". When the flag
is absent, whether from an enrichment gap or a permission problem, the rule abstains rather than
speculating. An earlier version of this rule read a customer-controlled tag with a key no
producer ever wrote, so it could never fire; the current gate reads provider truth only.
Everything the detection needs is covered by the built-in Reader role.
One server setting, every database covered
Azure SQL auditing set at the server level is inherited by all databases on that server, which is why the discoverer captures the server-level state. Fixing it once at the server fixes current databases and every database created later. The class-level remediation is strictly better than enabling auditing database by database. You choose a destination (storage account, Log Analytics workspace, or Event Hub) and a retention period that matches your compliance requirements.
Check a server’s auditing policy yourself
az sql server audit-policy show \ --resource-group <rg> --name <server> \ --query "{state:state, storageEndpoint:storageEndpoint, retentionDays:retentionDays}"state: Disabled reproduces exactly what the rule saw.
What the finding costs
Nothing is saved by fixing this: the recommendation carries $0 and lives in the compliance category. Auditing itself has a cost consequence worth knowing up front: logs written to a storage account or Log Analytics accrue storage charges that scale with query volume and retention, so pick a retention window deliberately rather than defaulting to forever.