Microsoft Azure Security Guide

Azure security failures usually come from the identity plane rather than the network: an over-permissive SAS token, a service principal with a forgotten secret, a role assignment at the wrong scope or a tenant nobody monitors. Azure ties every subscription to a Microsoft Entra tenant, so Azure security and Entra ID security cannot be separated. This guide covers the management group hierarchy and Cloud Adoption Framework landing zones, Azure Policy and initiatives, the difference between Entra roles and Azure RBAC, Privileged Identity Management, managed identities, Defender for Cloud and secure score, the Microsoft cloud security benchmark, logging, Key Vault, storage account security and network controls. It is written for cloud security engineers, platform teams and architects responsible for Azure estates of any size.

Key takeaways

• Two permission systems, one tenant. Entra roles manage the directory and Azure RBAC manages resources; a Global Administrator can cross the line by elevating access, so both must be governed together.
• Govern from management groups down. Policy and role assignments inherit through the hierarchy, so a well-designed landing zone sets guardrails once instead of per subscription.
• Prefer managed identities over secrets. They remove the credentials that attackers harvest from code and pipelines, but they are still non-human identities that need owners and least privilege.
• Turn off Shared Key where you can. Account keys and the SAS tokens signed with them are bearer credentials; Entra ID authorisation and user delegation SAS are safer and auditable.
• Measure against MCSB, then fix the risky things first. Defender for Cloud scores posture against the Microsoft cloud security benchmark; use risk factors and attack paths to decide what to remediate first.

Landing zones and the management group hierarchy

The Cloud Adoption Framework (CAF) defines an Azure landing zone as the architecture for a multi-subscription environment, split into platform landing zones (shared identity, management and connectivity services) and application landing zones for workloads. Management groups provide the structure. Microsoft documents the key limits: each directory has a single root management group ("Tenant root group", with the same ID as the Entra tenant), "A management group tree can support up to six levels of depth" excluding root and subscription level, and a directory can hold 10,000 management groups.

• Change the default management group: Microsoft states that "New subscriptions automatically default to the root management group when they're created." Point the default at a restricted group so a new subscription does not escape your guardrails.
• Deploy infrastructure as code: Azure Blueprints (Preview) "will be retired on January 31, 2027", with phased retirement from July 31, 2026; Microsoft recommends migrating to Deployment Stacks, with Template Specs as the other option.
• Resource locks: CanNotDelete or ReadOnly locks on hub networks, log workspaces and Key Vaults stop accidental or hasty deletion, but anyone with Owner can remove them, so they are a safety net, not an access control.

Azure Policy and initiatives

Azure Policy evaluates resources "without concern for who made the change", which makes it the complement to RBAC: RBAC decides who can act, Policy decides what is allowed to exist. Definitions are grouped into initiatives and assigned at management group, subscription or resource group scope. Effects include audit, auditIfNotExists, deny, modify, deployIfNotExists and denyAction, and Microsoft advises starting with audit or auditIfNotExists before enforcement.

• Baseline initiative: MCSB v2 is backed by "More than 420 Azure Policy built-in definitions" used by Azure Policy and Defender for Cloud to measure posture.
• High-value deny policies: "Storage accounts should prevent shared key access", storage accounts that allow anonymous blob access, public network access on PaaS services in Corp landing zones, and allowed locations.
• deployIfNotExists for logging: automatically configure diagnostic settings to the central Log Analytics workspace, so new resources are logged without a ticket.
• Exemptions: record them with an expiry date and owner rather than excluding scopes permanently.

Entra roles, Azure RBAC and PIM

Microsoft's summary is direct: "Azure roles control permissions to manage Azure resources, while Microsoft Entra roles control permissions to manage Microsoft Entra resources."

• Elevated access: Microsoft says to remove it "once you have made the changes you need to make at root scope". Elevation is logged in the Entra directory audit logs (Service: Azure RBAC (Elevated Access)) and the Azure Activity Log, and Microsoft Sentinel has an "Azure RBAC (Elevate Access)" analytics rule template. Alert on every occurrence.
• Classic administrators are gone: Microsoft states that classic administrator roles were fully retired as of May 2026, so all subscription access is now Azure RBAC; review the Owner assignments that replaced Co-Administrators.
• Contributor is not harmless: it cannot assign roles but can change almost everything else, including some data access paths. The Azure Key Vault Contributor escalation showed a "no data access" role reading secrets in vaults that still used access policies.
• Privileged Identity Management: PIM provides just-in-time, time-bound activation with approval, MFA, justification, notifications, access reviews and audit history for Entra roles, Azure resource roles and PIM for Groups. Make Owner, User Access Administrator and Global Administrator eligible rather than active. See the JIT Access Guide.
• Sign-in controls: require phishing-resistant MFA for Azure management through Conditional Access, and keep two excluded emergency accounts. See the Conditional Access Guide, the Break-Glass Account Guide and the Active Directory and Entra ID Hardening Guide.

Managed identities and other workload identities

Every application, pipeline and automation account that touches Azure is a non-human identity, and they usually outnumber people. Managed identities are the strongest option: "You don't need to manage credentials. Credentials aren't even accessible to you."

• Least privilege still applies: a managed identity with Contributor on a subscription is as dangerous as a leaked key once code on that resource is compromised. Assign data-plane roles (Storage Blob Data Reader, Key Vault Secrets User) at the narrowest scope.
• Watch for credentials added to applications: attackers persist by adding secrets or certificates to existing service principals. The Microsoft Midnight Blizzard breach began in a forgotten test tenant and used an OAuth application to reach executive mailboxes. See the SaaS and OAuth App Governance Guide.
• Owners and inventory: each identity needs a named owner and a review date. See the Cloud Workload Identity Guide, the Service Account Security Guide and the NHI Ownership Guide.

Defender for Cloud, secure score and the MCSB

Defender for Cloud is Microsoft's CNAPP. Foundational CSPM is free and covers policy, recommendations and multicloud connectors for AWS and GCP. The paid Defender CSPM plan adds attack path analysis, cloud security explorer, governance rules and regulatory compliance. Workload protection plans include Defender for Servers, Storage (which covers malware, sensitive data leakage and "Shared Access Signature (SAS) token misuse"), Databases, Containers, Key Vault, Resource Manager, App Service, APIs and AI Services.

Secure score comes in two models that Microsoft says are "completely different models with different calculations and values". The classic score in the Azure portal is a percentage based only on built-in MCSB recommendations, recalculated every eight hours, and a control only improves when all its recommendations are fixed. The Cloud Secure Score in the Defender portal runs from 0 to 100 and weights recommendations by asset risk factors such as internet exposure and data sensitivity, plus asset criticality. Report one model consistently.

The Microsoft cloud security benchmark (MCSB, which replaced the Azure Security Benchmark) v2 is in preview and "supersedes" v1. It has 12 domains: Network Security (NS), Identity Management (IM), Privileged Access (PA), Data Protection (DP), Asset Management (AM), Logging and Threat Detection (LT), Incident Response (IR), Posture and Vulnerability Management (PV), Endpoint Security (ES), Backup and Recovery (BR), DevOps Security (DS) and the new Artificial Intelligence Security (AI) domain. Its controls map to NIST SP 800-53 Rev. 5, PCI DSS v4, CIS Controls v8.1, NIST CSF 2.0, ISO 27001:2022 and SOC 2, but Microsoft cautions that a mapping "doesn't necessarily translate to the full compliance" of the external control. For CIS, the current CIS Microsoft Azure Foundations Benchmark is v6.0.0, with separate CIS benchmarks for Azure Compute, Database and Storage services. See the CNAPP Guide.

Logging and monitoring

• Activity Log: the Azure Monitor platform log for control-plane operations, kept for 90 days. Export it with a diagnostic setting to a Log Analytics workspace (and Event Hubs or storage for archive) at management group or subscription scope.
• Resource logs: data-plane events such as reading a Key Vault secret "aren't collected by default and require configuration with a diagnostic setting". Use a deployIfNotExists policy so every Key Vault, storage account and SQL server sends them.
• Entra ID logs: sign-in logs (including service principal and managed identity sign-ins) and audit logs show credential misuse that the Activity Log never sees.
• Storage telemetry: StorageBlobLogs with AuthenticationType of AccountKey, SAS or Anonymous shows who still relies on keys or public access.
• Network: NSG flow logs retire on 30 September 2027 and can no longer be created; use virtual network flow logs.
• SIEM: Microsoft Sentinel or another SIEM correlates these sources. Do not rely on the provider alone: the Microsoft Storm-0558 key breach showed why customers need their own audit logs and retention. See the Log Management and Retention Guide.

Key Vault and storage account security

Key Vault

• Use Azure RBAC: Microsoft says not to use legacy access policies because they "have known security vulnerabilities and lack support for Privileged Identity Management (PIM)".
• Soft delete and purge protection: soft delete keeps deleted objects for 7 to 90 days; purge protection stops even an administrator destroying them early.
• Network: disable public network access and use private endpoints, or at least the Key Vault firewall.
• Blast radius: "Use one Key Vault per application, region, and environment". See the Secrets Management Guide.

Storage accounts

The Microsoft SAS token exposure is the textbook case: one over-permissive link exposed 38TB of internal data. Microsoft's own procedure for removing Shared Key is to measure usage first (Metrics Explorer, Transactions filtered by Authentication = Account Key and SAS), migrate those clients to Entra ID, assign the built-in policy in audit mode, then switch it to deny. Expect HTTP 403 for any client you missed, and note that Azure Files without RBAC and Cloud Shell file shares break when Shared Key is disabled. For anonymous access, set AllowBlobPublicAccess to false; the $web static website container stays public regardless.

Network security

• NSGs: rules use priorities 100 to 4096 (lower wins, first match stops) with service tags and application security groups instead of IP lists. Default rules (AllowVNetInBound, AllowAzureLoadBalancerInBound, DenyAllInbound and their outbound equivalents, including AllowInternetOutBound) cannot be removed, only overridden, so add an explicit outbound deny where egress must be controlled.
• Private Link: private endpoints give PaaS services a private IP in your virtual network; pair them with private DNS zones and disable public network access on the service.
• Azure Firewall: central egress filtering and inspection in the connectivity hub, with user-defined routes forcing spoke traffic through it. See the Firewall Management Guide.
• Administrative access: Azure Bastion for RDP and SSH without public IPs on virtual machines.
• Edge: Azure DDoS Protection and a web application firewall for Online landing zones. See the Network Segmentation Guide.

Implementation roadmap

1. Discover (weeks 1 to 3): list subscriptions, management groups, Owner and User Access Administrator assignments, Global Administrators, service principals with secrets, and storage accounts allowing Shared Key or anonymous access. Enable free Foundational CSPM everywhere.
2. Logging (weeks 2 to 6): Activity Log and Entra logs to a central workspace, and deployIfNotExists policies for resource logs. This changes nothing for workloads, so do it first.
3. Identity (weeks 4 to 10): move privileged roles into PIM as eligible, enforce Conditional Access for Azure management, remove standing elevated access, and convert service principals with secrets to managed identities or federated credentials.
4. Hierarchy and policy (weeks 6 to 14): build the management group structure, change the default management group, and assign policies in audit mode. Review compliance results for two to four weeks, then switch selected policies to deny one landing zone at a time. Roll back by changing the assignment effect back to audit.
5. Data and network (weeks 10 to 20): Key Vault RBAC, purge protection and private endpoints; disable Shared Key and anonymous access after usage reaches zero; Bastion and Azure Firewall in the hub. Pilot in non-production subscriptions.
6. Operate: enable Defender plans by risk, review secure score monthly, and rehearse leaked secret and compromised identity playbooks. See the Leaked Credential Response Playbook.

Decision guidance

• System-assigned or user-assigned identity: system-assigned for a single resource with its own permissions; user-assigned when several resources need identical access or are frequently rebuilt.
• Private endpoints or service endpoints: private endpoints remove the public path entirely and work from on-premises; service endpoints are simpler but keep the service's public endpoint, so prefer private endpoints for sensitive data.
• Foundational or Defender CSPM: small estates can start free; buy Defender CSPM when attack path analysis and risk-based prioritisation would save more analyst time than it costs.
• Small organisations: a short hierarchy (platform, production, non-production, sandbox), PIM for a handful of admins, MCSB in audit mode and Shared Key disabled on new accounts gives most of the benefit.
• Large or regulated organisations: the full CAF hierarchy, policy as code with exemption tracking, Defender plans across workloads, and CIS Azure Foundations checks for auditors.

Detection and measurement

• Standing privilege: number of active (not eligible) Owner, User Access Administrator and Global Administrator assignments.
• Secrets in use: count of service principals with client secrets, and the share expiring beyond 12 months.
• Shared Key exposure: percentage of storage accounts with AllowSharedKeyAccess false.
• Posture: secure score and MCSB compliance per landing zone, one model reported consistently.
• Logging coverage: share of subscriptions and Key Vaults with diagnostic settings to the central workspace.

Common failure patterns

• Account SAS shared as a link: long-lived, broad and unrevocable without rotating the key, as the Microsoft SAS token exposure showed.
• Forgotten tenants and test environments: weaker MFA and monitoring outside production, the entry point in the Midnight Blizzard breach.
• Elevated access left on: a Global Administrator keeps User Access Administrator at root scope long after the task.
• Key Vault on legacy access policies: Contributor-level users can grant themselves data access.
• Hybrid sync accounts over-privileged: the Storm-0501 hybrid cloud attacks used stolen Entra Connect Sync credentials to reach Azure.

Framework mapping

Practitioner checklist

• Build a CAF-style management group hierarchy and change the default management group for new subscriptions.
• Assign MCSB and targeted deny policies, starting in audit mode.
• Make all privileged Entra and Azure roles PIM-eligible and alert on elevate access.
• Replace service principal secrets with managed identities or federated credentials.
• Export the Activity Log, Entra logs and resource logs to a central workspace via policy.
• Move Key Vaults to Azure RBAC with purge protection and private endpoints.
• Disable Shared Key and anonymous blob access once usage is zero.
• Block inbound RDP and SSH from the internet; use Bastion and private endpoints.
• Track standing privilege, secrets count, Shared Key exposure and secure score monthly.

Standards and references

• Microsoft: Microsoft cloud security benchmark overview
• Microsoft: Azure roles, Microsoft Entra roles, and classic subscription administrator roles
• Microsoft: What are managed identities for Azure resources?
• Microsoft: What are Azure management groups?
• Microsoft: Secure score in Defender for Cloud
• Microsoft: Prevent Shared Key authorization for an Azure Storage account
• Microsoft: Secure your Azure Key Vault
• CIS: Microsoft Azure Benchmarks

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · Active Directory and Entra ID Hardening Guide · Secrets Management Guide · Service Account Security Guide