Module 2 · Azure Resource Hardening

Last updated: April 29, 2026

Beyond Entra ID, Azure has its own resource-management plane (ARM), data-plane services (Storage, SQL, Cosmos DB, Key Vault), networking, and compute. Securing an Azure subscription requires understanding the role-based access control model, the network options, and the data-plane-specific gotchas. This module covers the practical hardening checklist for Azure subscriptions.

The two access planes

• Management (ARM) plane: creating/modifying/deleting Azure resources. RBAC roles like Contributor, Owner, Reader
• Data plane: reading/writing data within resources. Storage Blob Data Reader, Key Vault Secrets User, etc. Per-resource granular roles

Common misconfiguration: granting Owner at subscription scope when narrow data-plane access would suffice. Owner = create/delete anything in the scope.

RBAC hierarchy

MANAGEMENT GROUP (e.g., "Contoso")
  └─ SUBSCRIPTION (e.g., "Production")
      └─ RESOURCE GROUP (e.g., "rg-app-prod")
          └─ RESOURCE (e.g., a specific storage account)

# Permissions inherit downward. Granting Reader at subscription = Reader on every
# RG and resource in it. Always grant at narrowest scope possible.

Built-in roles to know

• Owner — full control + can grant access to others. Equivalent to root
• Contributor — full control except access management. Common for engineering
• Reader — read-only at the management plane. Cannot read data within services
• User Access Administrator — manage RBAC. Combine with Contributor for effective Owner
• Specific data roles — Storage Blob Data Reader/Contributor, Key Vault Secrets User, SQL DB Contributor

Network security

Virtual Networks (VNets) and subnets

• Default-deny inbound from Internet via Network Security Groups (NSGs)
• Subnet-level NSGs for east-west segmentation
• Service Endpoints route traffic to PaaS services over Microsoft backbone (skip Internet)
• Private Endpoints — preferred over Service Endpoints; PaaS gets a private IP in your VNet

Public exposure controls

• Disable public network access on storage, SQL, Key Vault — use Private Endpoints
• Azure Firewall or third-party NVA at perimeter for hub-spoke architectures
• Just-in-Time VM access for management (RDP/SSH only opened on request)
• Bastion host instead of public RDP/SSH

Network monitoring

• NSG flow logs to Log Analytics — east-west visibility
• Azure Firewall logs centrally analyzed
• Network Watcher for connection troubleshooting

Storage account hardening

• Disable public blob access at account level
• Disable shared key access — use Entra ID auth + RBAC
• Disable storage account keys altogether or rotate frequently
• Customer-managed encryption keys (CMK) via Key Vault
• Soft delete + versioning for blobs
• Private Endpoint for VNet access only
• SAS tokens — short TTL, narrow scope, never long-lived in code

Azure Key Vault

• RBAC mode (preferred) over Access Policies (legacy)
• Soft delete + purge protection enabled
• Separate vaults per environment (no cross-env access)
• Audit logs to Log Analytics
• Network restrictions — Private Endpoint or specific IP allowlist
• HSM-backed keys for high-sensitivity workloads

Azure SQL hardening

• Entra ID authentication only; disable SQL auth where possible
• Transparent Data Encryption with CMK
• Always Encrypted for column-level encryption (sensitive PII)
• Defender for SQL — Advanced Threat Protection
• Auditing to a storage account or Log Analytics
• Private Endpoint; disable public network access
• IP firewall as backstop if public must be enabled

Azure Policy and Defender for Cloud

• Azure Policy — enforces configuration rules. Built-in initiatives for CIS, NIST, ISO baselines. Deny resources that don’t meet policy at deploy time
• Defender for Cloud — continuous posture management; secure score; threat detection. Free tier covers basic posture; paid tier adds runtime protection per workload type
• Azure Sentinel — SIEM/SOAR; ingest Azure activity, sign-ins, third-party

Cost controls as a security control

Compromised credentials often used for cryptomining — running expensive VM SKUs across regions. Mitigations:

• Azure Policy denying GPU SKUs and large VM sizes outside specific RGs
• Budget alerts at 50%, 80%, 100% of expected spend
• Cost anomaly detection — Defender for Cloud and standalone tools
• Geographic restriction — deny resources in regions you don’t operate in

Common Azure misconfigurations

• Storage account allowing anonymous blob access
• Public IP on a VM that has admin services exposed
• NSG rule allowing 0.0.0.0/0 to RDP/SSH
• Key Vault accessible from any network
• SQL Server with public access and SQL auth + weak passwords
• Default Azure Functions / Logic Apps with anonymous HTTP triggers
• Service principals with Contributor at subscription scope
• Soft delete disabled on resources holding important data
• Boot diagnostics with public storage account

The audit toolkit

• Azure CLI / PowerShell — scripted enumeration of resources, RBAC, configs
• Microsoft Defender for Cloud — continuous posture monitoring
• BloodHound Azure — graph attack path visualization
• Stormspotter (Microsoft) — Azure attack graph builder
• ROADtools — Azure AD attack toolkit (consider as research; legitimate for owned tenants)
• Prowler, ScoutSuite — multi-cloud auditors

Zero-trust architecture for Azure

1. Every workload uses Managed Identity — no long-lived secrets in apps
2. RBAC at narrowest scope; PIM for elevated
3. Network: default-deny; private endpoints; minimal public surface
4. Data: encrypted at rest with CMK; in transit always TLS 1.2+; column-level encryption for sensitive
5. Continuous: Defender for Cloud + Sentinel; alerts triaged within SLAs
6. Auditable: every administrative action logged with user attribution

Where this leads

Module 3 covers GCP security — different model than AWS or Azure, with hierarchical IAM and project-based isolation as core concepts.