Defender for Cloud — Defender for SQL
Defender for SQL is the SQL-focused plan inside Microsoft Defender for Cloud (the Azure-native CNAPP). It adds two capabilities on top of any SQL surface — Azure SQL DB, Azure SQL Managed Instance, SQL Server on Azure VM, or Arc-enabled SQL Server:
- Vulnerability Assessment (VA) — periodic configuration scans against a Microsoft-curated baseline.
- Advanced Threat Protection (ATP) — runtime ML alerts for SQL injection, anomalous logins, brute force, and data exfiltration patterns.
🏢 Real-World DBA Note
Think of Defender for SQL as the Azure-native equivalent of Oracle Audit Vault & Database Firewall (AVDF) + Oracle DBSAT — VA gives you the configuration scan, ATP gives you the runtime detection. Both stream to Microsoft Sentinel if you want a SIEM.
What it covers
Defender for SQL — Coverage
Azure SQL Database & MI
Per-server plan. Enable on the logical server (DB) or instance (MI) — applies to all DBs.
SQL Server on Azure VM
Per-VM plan via the SQL IaaS Agent extension. No agent install on the SQL engine itself.
Arc-enabled SQL Server
Same plan extends to on-prem / multi-cloud SQL Servers connected via Azure Arc. Billed per SQL core. See: Arc-enabled SQL.
Sentinel & XDR integration
Alerts flow into Defender for Cloud → optionally forwarded to Sentinel for SIEM correlation and Defender XDR for incident grouping.
What Defender for SQL DOES vs DOES NOT do
✅ ✅ What Defender for SQL DOES
- Runs Vulnerability Assessment scans (schema + configuration) on a schedule
- Streams ATP detectors on the live query feed for injection, exfiltration, brute-force and anomalous access
- Maps findings to MITRE ATT&CK + secure score
- Forwards alerts to Defender for Cloud → Sentinel / XDR
- Works identically across Azure SQL DB / MI / SQL-on-VM / Arc-SQL
⚠️ ⚠️ What Defender for SQL DOES NOT do
- Does not scan column data values — use SQL Information Protection / Purview for sensitive-data discovery
- Does not auto-remediate findings — it gives the T-SQL / portal step to fix
- Does not replace Defender for Servers on the host VM
- Does not cover OSS engines (Postgres / MySQL) — those have separate Defender plans
- Does not bypass network controls — the host still needs the standard Arc / IaaS Agent connectivity
Architecture — how telemetry flows
From query to SOC alert
Telemetry source
Azure SQL: built-in (no agent)
SQL on VM: SQL IaaS Agent extension
Arc SQL: Connected Machine agent + Arc SQL extension
Defender for SQL service
VA scans on schedule (default weekly)
ATP detectors evaluate query stream
Findings stored per-resource
Defender for Cloud
Aggregates findings across resources
Maps to MITRE ATT&CK + secure score
Recommendations + alerts in portal
Downstream
Continuous export → Event Hub / Log Analytics
Sentinel Defender for Cloud connector
Logic App playbooks for auto-response
Vulnerability Assessment (VA) — deep dive
A scheduled scan against a Microsoft-curated rule set (~70 rules for Azure SQL DB, ~90 for SQL on VM/Arc). Findings map to severity (High / Medium / Low) and link to the exact T-SQL or portal step to remediate.
Rule families
| Family | Examples |
|---|---|
| Authentication & access | Disabled SQL logins, sysadmin sprawl, missing Entra-only auth, public endpoint exposure |
| Auditing & logging | Auditing not enabled, retention < 90 days, audit not capturing failed logins |
| Data protection | TDE off, missing customer-managed key (CMK), weak TLS, deprecated cipher suites |
| Surface area | xp_cmdshell enabled, contained DBs without authentication policy, CLR enabled, OLE Automation procedures enabled |
| Sensitive data | Unclassified PII columns, missing Dynamic Data Masking on sensitive columns |
| Permissions | Excessive permissions on built-in roles, public role with sensitive grants, db_owner sprawl |
Baseline workflow
VA's killer feature is the per-database baseline. The first scan flags everything; you then mark the findings you accept as "expected" and they become the baseline. Subsequent scans only flag drift from the baseline — keeping noise low for legacy systems.
🎯 Exam Focus
Common production gotcha: The baseline is stored per-database in the configured storage account. If you restore a database to a new server, the baseline does NOT travel with it — the first post-restore scan will look noisy until you re-baseline.
How to enable (Azure SQL Database)
# 1. Enable Defender for SQL at the subscription level
az security pricing create --name SqlServers --tier Standard
# 2. Configure VA storage on the logical server
az sql server vulnerability-assessment update \
--resource-group <rg> --server <server> \
--storage-container-path "https://<storage>.blob.core.windows.net/vulnerability-assessment" \
--recurring-scans-is-enabled true \
--recurring-scans-emails "dba@contoso.com" \
--recurring-scans-email-subscription-admins true
# 3. Trigger an on-demand scan for a specific database
az sql db threat-policy update \
--resource-group <rg> --server <server> --name <db> \
--state Enabled
How to enable (Arc-enabled SQL or SQL on VM)
# Per-resource plan toggle
az security pricing create --name SqlServerVirtualMachines --tier Standard
# After enabling, the Defender extension is auto-deployed to the host
# VA scans run automatically on the recurring schedule
Reading a VA report
Each finding has:
- Rule ID (e.g.,
VA1054— "Most Transparent Data Encryption (TDE) protectors should be encrypted with the customer-managed key") - Severity + Category
- Affected object (server / DB / table / column)
- Remediation T-SQL (literal script you can copy-paste)
- Approve as baseline button
Advanced Threat Protection (ATP) — alert catalog
ATP streams real-time SQL telemetry through ML detectors. Memorize the alert taxonomy — these are the alerts that show up in customer SOCs:
| Alert | Trigger | Typical action |
|---|---|---|
| SQL Injection | Pattern of injection attempts in queries | Block source IP, fix parameterization in app |
| Vulnerability to SQL Injection | App generates SQL errors revealing schema | Code review of the calling app, sanitize errors |
| Anomalous client login | Login from a new geography / unusual time / unusual app name | Verify with user, consider Conditional Access |
| Login from a principal user not seen in 60 days | Dormant account waking up | Reset credential, review access |
| Brute force | Failed-login burst from one or many sources | Block IP, enforce Entra-only auth, enable MFA |
| Potential data exfiltration | Large result sets to atypical destinations / volumes | Investigate session, rotate creds, lock down firewall |
| Suspicious SQL activity (harmful application) | Known scanner / SQLMap / nmap fingerprint | Block at firewall / WAF, alert SOC |
| Unusual export location | Bulk export of sensitive data to new storage account | Validate change, revert if unauthorized |
| Potential data injection (Linux/SQL on VM) | Suspicious file write detected by host telemetry | Combine with Defender for Servers alert for full chain |
🏢 Real-World DBA Note
ATP alerts land in Defender for Cloud → Security alerts. From there you can pivot directly to the Sentinel workbook if you have a SIEM, or fire a Logic App playbook (e.g., add IP to NSG, page on-call) without writing custom code. For multi-tenant SaaS apps, configure suppression rules to avoid alerting on tenant migration jobs that legitimately move bulk data.
Pricing model — know the shape
| Surface | Billing unit | Approx. list (verify in Azure Pricing) |
|---|---|---|
| Azure SQL Database / MI | Per logical server / per managed instance | ~$15/server/month |
| SQL on Azure VM | Per VM (regardless of instance count on the VM) | ~$15/VM/month |
| Arc-enabled SQL Server | Per SQL Server vCore | ~$15/vCore/month, capped per host |
Defender for SQL is separate from Defender for Servers — you can enable just one. For SQL on Azure VM you typically want both: Defender for Servers covers the OS + Defender XDR coverage; Defender for SQL covers the engine.
Free trial
First 30 days of Defender for SQL are free per subscription. Use this to run a one-shot VA scan + 30 days of ATP telemetry as a customer demo before they commit to the spend.
Decision matrix — which Defender plan(s) do I need?
| Workload | Defender for SQL? | Defender for Servers? | Why |
|---|---|---|---|
| Azure SQL DB / MI (PaaS) | ✅ | ❌ | OS is Microsoft-managed |
| SQL on Azure VM | ✅ | ✅ | You own the OS — both layers need protection |
| SQL on on-prem / AWS / GCP | ✅ (via Arc) | ✅ (via Arc) | Arc is the connector for both plans |
| Read replica / dev DB you don't care about | ❌ | ❌ | Cost — unprotected = accept the risk |
| Free Azure SQL DB tier | ❌ | ❌ | Plan minimum cost > the workload value |
| SQL DB in a multi-tenant SaaS | ✅ | depends | ATP is gold for catching injection in customer-facing tenants |
When not to use Defender for SQL
- Throwaway dev/test DBs with no production data. Use a CI-time scan with SQL Vulnerability Assessment instead.
- You already license a third-party DAM (Imperva / Guardium / IBM Security Guardium). Pick one to avoid duplicate alerting and license overlap.
- Free tier / hyperscale serverless paused workloads. Defender bills regardless of DB activity. Disable on long-paused DBs.
- Hyperscale named replicas used for read scale-out only. They inherit the parent's ATP coverage; the per-replica plan is redundant.
Sentinel integration — recommended pattern
- Enable continuous export in Defender for Cloud → send alerts + recommendations to a Log Analytics workspace.
- Connect that workspace to Microsoft Sentinel.
- Install the Microsoft Defender for Cloud Sentinel data connector.
- Use the built-in SQL Threat Intelligence workbook for triage.
- Author analytics rules:
- "Brute force followed by successful login from same IP within 5 min" → high severity incident
- "Anomalous client login + Potential data exfiltration on same DB within 1 hour" → critical, page on-call
// Sample Sentinel KQL: SQL alerts from Defender for SQL in last 24h, grouped by DB
SecurityAlert
| where ProductName == "Microsoft Defender for SQL"
| where TimeGenerated > ago(24h)
| extend ResourceId = tostring(parse_json(ExtendedProperties).ResourceId)
| summarize Alerts=count(), Severities=make_set(AlertSeverity) by ResourceId, AlertName
| order by Alerts desc
Operational best practices
- Enable at subscription scope with Azure Policy
[Preview]: Configure Microsoft Defender for SQL servers on machines planso new SQL VMs are auto-protected. - Tag exempt resources (
defender-exempt: true) and use Policy to skip them — keep an audit trail of intentional non-coverage. - Route alerts to a dedicated email distribution list plus the security team's ticketing system inbox; do NOT rely on a single DBA inbox.
- Quarterly re-baseline VA for production DBs after change-windows (schema migrations often add findings that should be accepted).
- Suppress noisy detectors for known automation (e.g., bulk-load service accounts that look like exfiltration) using Defender for Cloud suppression rules — keep the suppression scoped tight.
- Test alerts quarterly by running a benign red-team script (
sqlmap --batch --safe-url) from an isolated VM — confirms the pipeline is alive.
Limitations & gotchas
- VA scans schema and configuration, not data values. To find sensitive data inside columns use SQL Information Protection classification (separate, free feature).
- ATP does not see traffic that bypasses the SQL TDS protocol (e.g., direct file copies of
.mdf/.bakon a VM). Layer with Defender for Servers + Defender for Storage. - Hyperscale databases: VA is supported but some rules are skipped (page-server architecture). Confirm rule applicability per release.
- MI: Vulnerability Assessment requires a dedicated storage account in the same region as the MI subnet's VNet — plan storage placement during MI deploy.
- Arc + air-gapped (indirect mode): A subset of detectors is delayed by upload cadence. Plan for ~1 hour latency vs <5 min on direct mode.
Mapping to security frameworks
| Framework | What Defender for SQL contributes |
|---|---|
| DP-300 Domain 2 (Configure & monitor security infrastructure) | VA recurring scans + baseline drift, ATP runtime detection |
| CIS Microsoft Azure Foundations Benchmark | Sections 4.x (SQL DB) auto-evaluated by VA |
| PCI-DSS | Requirement 6.5 (vulnerability mgmt), 10.x (audit) |
| NIST 800-53 | SI-4 (system monitoring), RA-5 (vulnerability scanning) |
| MITRE ATT&CK | Initial Access (T1190), Credential Access (T1110), Exfiltration (TA0010) |
Flashcards
What two capabilities does Defender for SQL add on top of a SQL surface?
Click to reveal answer
(1) Vulnerability Assessment — periodic configuration scans against a baseline, and (2) Advanced Threat Protection — runtime ML alerts for SQL injection, anomalous logins, brute force, and data exfiltration.
1 / 5
Quiz
Defender for SQL Vulnerability Assessment scans report a finding that was already accepted as part of the system's intentional configuration. What is the recommended action?