Microsoft Defender for SQL servers on machines should be enabled

What does the recommendation "Microsoft Defender for SQL servers on machines should be enabled" check?

Flags any subscription where the Defender for SQL servers on machines plan is not set to the Standard tier in Microsoft Defender for Cloud. This plan protects SQL Server installed inside Azure virtual machines and Arc-enabled SQL Server running on on-premises or other-cloud machines. It does NOT cover the platform Azure SQL Database, SQL Managed Instance or Synapse SQL pools, which are protected by the separate 'Defender for SQL on Azure SQL databases' plan. The control evaluates the subscription-level pricing tier only, so it does not by itself confirm that the SQL IaaS extension, Azure Monitor Agent and Defender extension have finished auto-provisioning onto each machine.

Why does "Microsoft Defender for SQL servers on machines should be enabled" matter?

SQL Server on a VM keeps your most valuable data, and a database engine reachable from a compromised host is a prime target for SQL injection, brute-force logins and bulk exfiltration. Without this plan there is no vulnerability assessment surfacing weak configuration and no behavioural alerting on anomalous queries, privilege changes or suspicious access patterns, so an intrusion can run for weeks before anyone notices. The business consequence is a data breach you learn about from a third party rather than from your own monitoring: regulatory exposure, breach notification, and lost customer trust. Enabling the plan gives you continuous threat detection and a remediation queue for the database tier you would otherwise have to staff and tool yourself.

How do I fix "Microsoft Defender for SQL servers on machines should be enabled"?

1. Enable the plan for the subscription with the Azure CLI: az security pricing create -n SqlServerVirtualMachines --tier Standard. This is the resource name Defender for Cloud uses for SQL servers on machines.
2. Confirm auto-provisioning of the SQL IaaS Agent extension, Azure Monitor Agent and the Microsoft Defender for SQL extension onto each SQL VM and Arc-enabled SQL Server, because the plan only alerts once those agents are reporting; for Arc machines this means onboarding them to Azure Arc first.
3. Assign the built-in policy to keep new subscriptions compliant rather than pasting a GUID: pid=$(az policy definition list --query "[?displayName=='Azure Defender for SQL servers on machines should be enabled'].name" -o tsv); az policy assignment create --name defender-sql-on-machines --policy "$pid" --scope /subscriptions/<subscription-id>

# Enable the three high-value Defender plans on the current subscription.
# Servers on Plan 2 (adds JIT access, FIM and vulnerability scanning).
az security pricing create --name VirtualMachines \
  --tier Standard --subplan P2

# Storage on the current per-account plan.
az security pricing create --name StorageAccounts --tier Standard

# Azure SQL Database servers (VA + Advanced Threat Protection).
az security pricing create --name SqlServers --tier Standard

# Verify what is now active on this subscription.
az security pricing list \
  --query "value[?pricingTier=='Standard'].name" -o tsv

# Ratchet it shut for the estate: assign the built-in DeployIfNotExists
# policies that turn each plan on for any subscription where it is missing.
# Servers (built-in 'Configure Azure Defender for servers to be enabled').
az policy assignment create \
  --name enable-defender-servers \
  --policy 8e86a5b6-b9bd-49d1-8e21-4bb8a0862222 \
  --scope "/providers/Microsoft.Management/managementGroups/contoso-root"

# Look up the matching Storage and SQL policies by display name rather than
# hard-coding a GUID, then assign each the same way at the same scope.
az policy definition list \
  --query "[?contains(displayName, 'Configure Microsoft Defender for Storage') || contains(displayName, 'Configure Azure Defender to be enabled on SQL servers')].{name:name, displayName:displayName}" \
  -o table