Microsoft Defender for SQL on machines should be enabled on workspaces

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

Flags Log Analytics workspaces that collect data from SQL Server instances running on virtual machines or Arc-enabled servers but do not have the Defender for SQL plan enabled at the workspace level. The recommendation exists because enabling the SQL Servers on machines plan on the subscription alone is not enough: each machine reports through a workspace, and that workspace must also carry the plan for threat detection to actually run on the instances behind it. It covers SQL Server hosted on Azure VMs and Arc-enabled SQL Servers. It does not cover Azure SQL Database, SQL Managed Instance or Synapse, which sit under the separate Defender for Azure SQL plan.

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

A workspace gap is a silent one. The subscription shows the plan as on, the bill reflects it, yet the SQL instances reporting to an unprotected workspace get no anomaly detection, no brute-force alerting and no vulnerability assessment. An attacker probing those databases, dumping tables or exploiting a known CVE triggers nothing, and the security team believes coverage exists because the plan looks enabled. For database servers, which usually hold the most sensitive data in the estate, that blind spot is where a breach goes unnoticed until exfiltration is complete. Closing it restores the detections you are already paying for.

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

1. Enable the SQL Servers on machines plan at the subscription level so the capability is licensed: az security pricing create -n SqlServerVirtualMachines --tier standard.
2. Enable Defender for SQL on each Log Analytics workspace the SQL machines report to. In Defender for Cloud, open the workspace under Environment settings and turn on the SQL Servers on machines plan, or migrate to the Azure Monitor Agent (AMA) auto-provisioning flow, which configures the workspace, data collection rules and extensions for you. The legacy Log Analytics agent path is being retired, so prefer AMA for new rollouts.
3. Standardise this in policy so new workspaces inherit it. Assign the built-in policy that deploys the configuration by looking it up at runtime rather than hardcoding its id: pid=$(az policy definition list --query "[?displayName=='Configure the Microsoft Defender for SQL Log Analytics workspace'].name" -o tsv); az policy assignment create --name defender-sql-workspace --policy "$pid" --scope /subscriptions/<sub-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