Diagnostic logs in Service Bus should be enabled

What does the recommendation "Diagnostic logs in Service Bus should be enabled" check?

Flags any Service Bus namespace (Microsoft.ServiceBus/namespaces) that has no diagnostic setting routing its resource logs to a Log Analytics workspace, storage account or event hub. It is an audit-only check: it confirms a destination exists, not that every log category is switched on, and it does not validate retention, the workspace's access controls or whether anyone actually reviews the logs. It also does not cover platform metrics or the subscription-level activity log, which are collected separately.

Why does "Diagnostic logs in Service Bus should be enabled" matter?

Service Bus operational logs are the record of who created, updated or deleted queues, topics and shared access policies, and the runtime audit logs show which identity authenticated and from where. Without a diagnostic setting these events are never persisted, so when a messaging entity is tampered with or a SAS key is abused you have no trail to reconstruct what happened. Because Service Bus often carries orders, payments and other business events between services, an unlogged compromise can ripple through downstream systems unnoticed. After an incident that gap stalls the investigation, undermines breach-notification timelines and can leave you unable to demonstrate to auditors that access to a business-critical message bus was monitored.

How do I fix "Diagnostic logs in Service Bus should be enabled"?

1. Create a Log Analytics workspace (or reuse a central one) to receive the logs, then add a diagnostic setting on the namespace: az monitor diagnostic-settings create --name sb-logs --resource <namespace-resource-id> --workspace <workspace-resource-id> --logs '[{"category":"OperationalLogs","enabled":true},{"category":"VNetAndIPFilteringLogs","enabled":true},{"category":"RuntimeAuditLogs","enabled":true}]'. RuntimeAuditLogs is emitted only by premium-tier namespaces.
2. Enforce this everywhere by assigning the audit policy by its exact display name rather than a hardcoded GUID: pid=$(az policy definition list --query "[?displayName=='Resource logs in Service Bus should be enabled'].name" -o tsv); az policy assignment create --name sb-diag-logs --policy "$pid" --scope /subscriptions/<sub-id>. To make new namespaces self-remediate, pair it with the 'Deploy Diagnostic Settings for Service Bus to Log Analytics workspace' deployIfNotExists policy and a remediation task.
3. Bake the setting into your infrastructure as code so it cannot be forgotten: in Bicep declare a Microsoft.Insights/diagnosticSettings resource scoped to the namespace, set its workspaceId and list the log categories with enabled set to true.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"