Diagnostic logs in Azure Data Lake Store should be enabled

What does the recommendation "Diagnostic logs in Azure Data Lake Store should be enabled" check?

Flags any Azure Data Lake Store Gen1 account (Microsoft.DataLakeStore/accounts) that has no diagnostic setting routing its resource logs to a destination, so the 'Audit' and 'Requests' log categories are not being captured. The control verifies only that at least one diagnostic setting exists and exports those categories to a Log Analytics workspace, an event hub or a storage account. It does not check the retention period, whether anyone reviews the logs, or whether the destination itself is secured. It also does not cover Data Lake Analytics or Data Lake Storage Gen2 (an ADLS Gen2 account is a hierarchical-namespace storage account and is logged through the Storage diagnostic categories instead), which are separate recommendations.

Why does "Diagnostic logs in Azure Data Lake Store should be enabled" matter?

Data Lake Store Gen1 holds large volumes of analytics and often sensitive source data, yet without a diagnostic setting the account keeps no durable record of who read, wrote or deleted files. When an account is compromised or data goes missing, you have no activity trail to reconstruct what happened, which file paths were touched, or which identity was responsible, so an incident investigation stalls before it starts. The gap also undermines audit and breach-notification duties: you cannot prove the scope of an exposure you cannot see. Exporting the Audit and Requests categories to a workspace gives you the queryable history needed to detect anomalous access and to answer the forensic questions that follow a security event.

How do I fix "Diagnostic logs in Azure Data Lake Store should be enabled"?

1. Create a diagnostic setting on the account, sending the resource logs to a Log Analytics workspace: az monitor diagnostic-settings create --name dls-logs --resource <data-lake-store-resource-id> --workspace <workspace-resource-id> --logs '[{"category":"Audit","enabled":true},{"category":"Requests","enabled":true}]'.
2. Confirm the setting took effect with az monitor diagnostic-settings list --resource <data-lake-store-resource-id>, then run a Kusto query against the workspace to verify Audit events are arriving before you rely on them.
3. Enforce the baseline at scale by assigning the built-in policy by its exact display name so you never have to capture future accounts by hand: pid=$(az policy definition list --query "[?displayName=='Resource logs in Azure Data Lake Store should be enabled'].name" -o tsv); az policy assignment create --name dls-diag-logs --policy "$pid" --scope <subscription-or-management-group-id>.

# 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"