Security Baseline
A security baseline is the set of non-negotiable controls every workload inherits before any workload-specific hardening — identity as the perimeter, least privilege, encryption, secrets in a vault, a defended network edge, and continuous posture assessment. It is the floor, assembled once into the landing zone, so no individual team has to remember to build it.
This chapter has argued each piece in isolation; the baseline is them combined into a default. On Azure, the order is deliberate: identity first (most breaches are identity failures), then least privilege, then the data and network controls. A baseline applied uniformly through policy is far stronger than security left to each team's discretion.
Identity as Perimeter
Identity is the primary control. The baseline requires MFA on every account, phishing-resistant methods for privileged ones, Conditional Access gating sign-in on device and risk, and managed identities for workloads so no credentials are stored. Getting identity right does more than any network control, because identity is what attackers actually target.
Least Privilege and RBAC
Access follows least privilege: RBAC roles scoped to the narrowest resource and granted only as needed, with just-in-time elevation through Privileged Identity Management instead of standing admin rights. Standing high-privilege access is a permanent target; time-bound elevation shrinks the window an attacker can exploit.
Encryption and Secrets
Data is encrypted at rest (on by default) and in transit, with customer-managed keys where compliance requires control of the key lifecycle. Application secrets live in Key Vault and are fetched at runtime via managed identity — never in code, config, or pipelines. A leaked repository should expose nothing usable.
Network Defense and Posture
The network baseline applies least-privilege NSGs, keeps PaaS on private endpoints, fronts public web apps with a WAF, and protects exposed endpoints with DDoS Protection. Above it all, Defender for Cloud assesses posture and Azure Policy enforces the baseline so drift is caught and prevented. Posture management turns the baseline from a one-time setup into an enforced, monitored state.
- Leaving the baseline to each team's discretion instead of enforcing it uniformly through policy in the landing zone.
- Investing in network controls while leaving identity weak — no MFA, standing admin roles — when identity is what attackers target.
- Granting broad, standing privileges instead of least-privilege RBAC with just-in-time elevation.
- Storing secrets in code or config rather than Key Vault fetched via managed identity.
- Exposing PaaS services and management ports publicly instead of using private endpoints and a defended edge.
- Setting the baseline once and never measuring drift with Defender for Cloud or enforcing it with Policy.
- Put identity first: MFA everywhere, phishing-resistant methods for admins, Conditional Access, managed identities for workloads.
- Enforce least privilege with scoped RBAC and just-in-time elevation via Privileged Identity Management.
- Encrypt at rest and in transit, use customer-managed keys where required, and keep secrets in Key Vault.
- Apply least-privilege NSGs, private endpoints, a WAF on public apps, and DDoS Protection on exposed endpoints.
- Assess posture continuously with Defender for Cloud and enforce the baseline with Azure Policy.
- Bake the baseline into the landing zone so every workload inherits it by default.
Knowledge Check
Why does a security baseline put identity first?
- Identity is the primary perimeter — most breaches are identity failures, so MFA and least privilege matter most
- Identity controls are the cheapest of all the baseline controls to implement
- Network controls such as NSGs and private endpoints are unavailable on Azure
- Encryption at rest depends on identity being fully configured first, so identity has to come before it in the baseline
How should application secrets be handled in the baseline?
- Stored in Key Vault and fetched at runtime via managed identity — never in code, config, or pipelines
- Stored as encrypted environment variables in the application's own configuration and read in at startup
- Embedded directly in the container image at build time for convenience
- Rotated manually once a year by an operator on a fixed schedule
What turns a security baseline from a one-time setup into an enforced state?
- Continuous posture assessment with Defender for Cloud and enforcement with Azure Policy
- A quarterly manual audit run by the security team
- Documenting the required controls thoroughly in a team wiki
- Assigning each individual team to implement all of the controls at their own discretion
You got correct