Security Baseline

Security in a landing zone is not a single service you switch on. It is a set of controls spread across identity, network, policy, monitoring, data protection, secrets, and incident readiness. The platform’s job is to provide a secure baseline that every workload inherits before workload-specific controls are added.

Purpose

This page defines the platform-level security baseline that workloads inherit. Application security, workload-specific data protection, and fine-grained runtime controls remain with the workload team — but the platform must provide the secure foundation underneath them.

Design Reasoning

The platform security baseline should focus on controls that are broadly reusable and enforceable:

• Defender for Cloud enabled across relevant subscriptions, with paid plans turned on deliberately.
• Microsoft Cloud Security Benchmark (MCSB) alignment — it is assigned automatically when Defender for Cloud is enabled and drives your secure score.
• Secure use of secrets and keys, with managed identities replacing stored secrets wherever possible.
• Network isolation — private endpoints and minimized public network access.
• Logging and detection, and a defined incident-response readiness posture.

Secure Score and the MCSB regulatory-compliance dashboard are operating tools, not dashboards to admire. Each control maps to recommendations with an owner; review them centrally and assign remediation to the platform or workload team that owns the resource.

Architecture Decision Record

Tradeoff: Disabling public network access and requiring private endpoints adds network plumbing for each data service. That plumbing is exactly what prevents the accidental public exposure that causes most data incidents.

Recommended Configuration

Example Implementation

A Key Vault provisioned to the baseline — RBAC authorization on, public network access off:

1
az keyvault create \
2
  --name kv-platform-prod-sec-001 \
3
  --resource-group rg-platform-security-prod-sec-001 \
4
  --location switzerlandnorth \
5
  --enable-rbac-authorization true \
6
  --public-network-access Disabled

Grant access by assigning a data-plane role (for example, Key Vault Secrets User) to a group or managed identity at the vault scope — never by adding an access policy.

Validation Steps

1
# Which Defender plans are enabled
2
az security pricing list
3

4
# Confirm the vault baseline (RBAC on, public access disabled)
5
az keyvault show --name kv-platform-prod-sec-001
6

7
# Review who has access at the vault scope
8
az role assignment list \
9
  --scope $(az keyvault show --name kv-platform-prod-sec-001 --query id -o tsv) \
10
  --output table
11

12
# Confirm workloads use managed identities rather than stored secrets
13
az identity list --output table

Common Mistakes

• Enabling Defender for Cloud without deciding which plans are required, and absorbing surprise cost.
• Treating Secure Score as a dashboard, not an operating process with owners.
• Continuing to use legacy Key Vault access policies in new designs.
• Storing secrets in pipelines, scripts, or application settings instead of using managed identities.
• Allowing public network access by default on data services.
• No owner for security findings, so recommendations are seen but never actioned.

References

• Connect your Azure subscriptions to Microsoft Defender for Cloud
• The Microsoft cloud security benchmark in Defender for Cloud
• Secure score in Microsoft Defender for Cloud
• Azure RBAC vs. Key Vault access policies
• Secure your Azure Key Vault
• Managed identities for Azure resources