# Azure Cloud Architecture — Part 12: Security & Compliance > **Series:** Azure Cloud Architecture (12 of 16) > **Part 1:** `01-fundamentals-and-governance.md` — Fundamentals & Governance > **Part 2:** `02-identity-and-access.md` — Identity & Access > **Part 3:** `03-compute-vms-and-scale-sets.md` — Compute: Virtual Machines & Scale Sets > **Part 4:** `04-networking-foundations-vnets-ip-and-dns.md` — Networking Foundations: VNets, IP & DNS > **Part 5:** `05-networking-hybrid-connectivity.md` — Networking: Hybrid Connectivity > **Part 6:** `06-networking-application-delivery.md` — Networking: Application Delivery > **Part 7:** `07-networking-private-access-and-security.md` — Networking: Private Access & Security > **Part 8:** `08-storage-blob-files-and-disks.md` — Storage: Blob, Files & Disks > **Part 9:** `09-databases-and-data-services.md` — Databases & Data Services > **Part 10:** `10-containers-and-serverless.md` — Containers & Serverless > **Part 11:** `11-application-architecture-and-messaging.md` — Application Architecture & Messaging > **Part 12:** This file — Security & Compliance > **Part 13:** `13-monitoring-logging-and-observability.md` — Monitoring, Logging & Observability > **Part 14:** `14-business-continuity-backup-dr-and-migration.md` — Business Continuity: Backup, DR & Migration > **Part 15:** `15-cicd-and-iac.md` — CI/CD & Infrastructure as Code > **Part 16:** `16-multi-region-cost-optimization-and-cheatsheet.md` — Multi-Region, Cost Optimization & Cheat Sheet > **Questions:** `questions.md` ## Table of Contents 1. [Security and Compliance — Bringing the Series Together](#security-and-compliance--bringing-the-series-together) 2. [Key Vault — Secrets, Keys, and Certificates](#key-vault--secrets-keys-and-certificates) 3. [Key Vault Access Control — RBAC Is Now the Default](#key-vault-access-control--rbac-is-now-the-default) 4. [Managed HSM](#managed-hsm) 5. [Certificate Management and Auto-Rotation](#certificate-management-and-auto-rotation) 6. [Key Vault Networking and Soft Delete](#key-vault-networking-and-soft-delete) 7. [Microsoft Defender for Cloud — CSPM Plans](#microsoft-defender-for-cloud--cspm-plans) 8. [Defender for Cloud Workload Protection Plans](#defender-for-cloud-workload-protection-plans) 9. [Secure Score](#secure-score) 10. [Regulatory Compliance Dashboard](#regulatory-compliance-dashboard) 11. [Microsoft Sentinel — SIEM/SOAR Architecture](#microsoft-sentinel--siemsoar-architecture) 12. [Sentinel Data Connectors and Analytics Rules](#sentinel-data-connectors-and-analytics-rules) 13. [Sentinel Automation — Playbooks](#sentinel-automation--playbooks) 14. [Microsoft Purview — Data Governance and Classification](#microsoft-purview--data-governance-and-classification) 15. [Azure Policy Regulatory Compliance Initiatives](#azure-policy-regulatory-compliance-initiatives) 16. [A Full Worked Security Bootstrap for Meridian Freight](#a-full-worked-security-bootstrap-for-meridian-freight) 17. [Part 12 CLI Cheat Sheet](#part-12-cli-cheat-sheet) 18. [Common Mistakes and Interview Traps](#common-mistakes-and-interview-traps) 19. [Worked Practice Problems](#worked-practice-problems) 20. [Summary and What's Next](#summary-and-whats-next) ## Security and Compliance — Bringing the Series Together This chapter closes the loop on security topics deferred throughout the series: Key Vault (referenced since Part 2's managed identity examples), Defender for Cloud and Sentinel (previewed in Part 7), and the compliance tooling underneath Part 1's governance model. ```mermaid graph TD KeyVault["Key Vault —\nsecrets, keys, certificates"] --> Foundation["Security foundation\nfor every other service"] Defender["Defender for Cloud —\nposture + workload protection"] --> Foundation Sentinel["Microsoft Sentinel —\nSIEM/SOAR"] --> Foundation Purview["Microsoft Purview —\ndata governance"] --> Foundation ``` --- ## Key Vault — Secrets, Keys, and Certificates ```bash az keyvault create --name kv-meridian --resource-group rg-shipment-api-prod --sku standard az keyvault secret set --vault-name kv-meridian --name "rates-db-connection-string" --value "" ``` Key Vault holds three distinct object types: **secrets** (arbitrary strings — connection strings, API keys), **keys** (cryptographic keys used for encrypt/decrypt/sign operations, including the customer-managed keys Part 8 referenced for storage encryption), and **certificates** (TLS certificates, with built-in issuance/renewal workflows). --- ## Key Vault Access Control — RBAC Is Now the Default A genuinely important, current platform change worth stating explicitly: **as of API version 2026-02-01, Azure RBAC is the DEFAULT access control model for newly created key vaults** — the older **access policy** model (a Key Vault-specific permission system, separate from Azure RBAC) is no longer the default, though existing vaults keep their configured model until explicitly migrated. ```bash az keyvault create --name kv-meridian --resource-group rg-shipment-api-prod \ --enable-rbac-authorization true az role assignment create --assignee "" \ --role "Key Vault Secrets User" --scope "" ``` **Why this matters concretely, worth stating the underlying reasoning: RBAC-based access control means Key Vault permissions are managed through the exact same system (Part 2) governing every other Azure resource — one consistent place to audit "who can access what," rather than a Key-Vault-specific access policy system living in its own parallel world.** A vault still configured with the legacy access policy model is worth migrating deliberately — not urgently disruptive, but worth planning, since RBAC is now both the default and Microsoft's clearly stated direction. --- ## Managed HSM For the small subset of organizations with a genuine regulatory requirement for FIPS 140-2 Level 3 validated hardware key storage (rather than Key Vault's own multi-tenant HSM backing), **Managed HSM** provides a single-tenant, dedicated HSM pool. ```bash az keyvault create --hsm-name mhsm-meridian --resource-group rg-compliance \ --administrators "" --location eastus --retention-days 90 ``` **A genuinely important isolation detail worth stating precisely: Managed HSM's data plane (actual key operations) uses its OWN local RBAC system, entirely separate from the control plane's Azure RBAC** — granting someone Azure RBAC access to the Managed HSM resource itself does NOT grant them data plane access to actually use the keys, a deliberate design preventing privilege escalation through the control plane alone. This is a meaningfully different, stricter model than regular Key Vault's now-unified RBAC approach, worth knowing precisely rather than assuming the two Key Vault products behave identically. --- ## Certificate Management and Auto-Rotation ```bash az keyvault certificate create --vault-name kv-meridian --name shipment-api-tls \ --policy "$(az keyvault certificate get-default-policy)" ``` **Key Vault-managed certificates support automatic renewal** ahead of expiration, and integrate directly with services referencing them (Application Gateway, Front Door — Part 6) so a renewed certificate propagates without manual intervention — directly closing the same "certificate expired and nobody noticed" risk Part 6 already flagged for Front Door specifically, generalized here to every service that can reference a Key Vault certificate. --- ## Key Vault Networking and Soft Delete ```bash az keyvault update --name kv-meridian --resource-group rg-shipment-api-prod \ --default-action Deny az network private-endpoint create --name pe-keyvault-meridian --resource-group rg-shipment-api-prod \ --vnet-name vnet-shipment-api --subnet snet-private-endpoints \ --private-connection-resource-id "" --group-id vault ``` **The same Zero Trust, default-deny recommendation Part 7 made for storage accounts applies identically here — Key Vault should be reached via Private Link, not a public endpoint, for any production vault holding genuinely sensitive material.** Soft delete (enabled by default and non-optional since a 2020 platform change) and **purge protection** together prevent both an accidental deletion and a MALICIOUS permanent deletion — purge protection specifically blocks even an Owner from permanently purging a vault or its contents before the retention period elapses, worth enabling explicitly for any vault holding genuinely critical secrets or keys. ```bash az keyvault update --name kv-meridian --resource-group rg-shipment-api-prod --enable-purge-protection true ``` > **From the Trenches:** A disgruntled departing engineer with lingering `Owner` access to a subscription attempted to delete a Key Vault holding production database credentials as a final act before their access was revoked. Soft delete meant the vault entered a recoverable, deleted state rather than vanishing outright, and purge protection (already enabled per this chapter's recommendation) meant even a follow-up attempt to purge it permanently was blocked — the platform team recovered the vault fully within minutes once alerted, rather than facing what would otherwise have been a genuine, unrecoverable incident. --- ## Microsoft Defender for Cloud — CSPM Plans ```bash az security pricing create --name CloudPosture --tier Standard ``` | Plan | Cost | Capabilities | |---|---|---| | Foundational CSPM | Free | Basic security recommendations, Secure Score | | Defender CSPM (paid) | Paid | Attack path analysis (Part 7), AI security posture, risk prioritization, agentless scanning | **A genuinely important, current fact worth stating explicitly: starting October 27, 2026, NEW Azure subscriptions default to Foundational CSPM being OFF, requiring explicit opt-in** — a reversal of the previous always-on-by-default behavior, worth checking explicitly for any new subscription created after that date rather than assuming baseline posture visibility exists automatically. --- ## Defender for Cloud Workload Protection Plans ```bash az security pricing create --name VirtualMachines --tier Standard az security pricing create --name SqlServers --tier Standard ``` Beyond CSPM's posture assessment, **Defender for Cloud's workload protection plans** provide active threat detection for specific resource types — Defender for Servers, Defender for SQL, Defender for Storage, Defender for Containers — each a separately enabled, separately priced plan, worth enabling deliberately for the specific resource types Meridian Freight actually runs rather than assuming CSPM alone covers active threat detection too. --- ## Secure Score ```bash az security secure-scores list ``` **Secure Score** aggregates every applicable recommendation into a single percentage, weighted by each recommendation's actual security impact — worth treating as a genuinely useful trend metric to track over time (is posture improving or degrading release over release) rather than a one-time checklist to satisfy once and ignore. --- ## Regulatory Compliance Dashboard ```bash az security regulatory-compliance-standards list ``` Built directly on Azure Policy's regulatory compliance initiatives (Part 1), this dashboard maps every applicable policy assignment to specific controls in frameworks like PCI-DSS, ISO 27001, or SOC 2 — turning "are we compliant with framework X" from a manual audit exercise into a continuously updated, policy-driven view, directly extending Part 1's governance model into formal compliance reporting. --- ## Microsoft Sentinel — SIEM/SOAR Architecture ```bash az sentinel workspace create --resource-group rg-shipment-api-prod \ --workspace-name log-analytics-meridian ``` **Microsoft Sentinel** is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) platform, built on top of a Log Analytics workspace (Part 13) — it ingests security-relevant logs from every service this series has covered, correlates them for threat detection, and can automate a response. --- ## Sentinel Data Connectors and Analytics Rules ```bash az sentinel data-connector create --resource-group rg-shipment-api-prod \ --workspace-name log-analytics-meridian --data-connector-id "AzureActiveDirectory" az sentinel alert-rule create --resource-group rg-shipment-api-prod \ --workspace-name log-analytics-meridian --rule-id impossible-travel \ --display-name "Impossible travel detected" --severity High ``` **Analytics rules** run continuously against ingested data, generating an incident when a pattern matches — directly building on Part 2's Identity Protection risk signals and Part 7's NSG flow logs as real, concrete data sources a Sentinel analytics rule can correlate together, catching a coordinated attack pattern spanning identity AND network signals that neither signal alone would flag as clearly suspicious. --- ## Sentinel Automation — Playbooks ```bash az sentinel automation-rule create --resource-group rg-shipment-api-prod \ --workspace-name log-analytics-meridian --automation-rule-id auto-disable-compromised-account ``` A **playbook** (built on Logic Apps, Part 11) automates a response — disabling a compromised user account, isolating a VM's network access, or opening a ticket — triggered directly from an analytics rule's incident. A genuinely current 2026 capability worth mentioning: **natural-language playbook generation** lets an analyst describe a desired response in plain language and get a working, documented Python-based playbook generated directly, lowering the barrier to building custom automation beyond hand-authoring Logic Apps workflows from scratch. --- ## Microsoft Purview — Data Governance and Classification ```bash az purview account create --name purview-meridian --resource-group rg-shipment-api-prod ``` **Microsoft Purview** scans across Meridian Freight's data estate (Storage, SQL, Cosmos DB) to automatically discover and classify sensitive data (PII, financial data) — genuinely useful for answering "where does our sensitive data actually live" comprehensively, rather than relying on each team's own institutional knowledge of what their own systems contain. --- ## Azure Policy Regulatory Compliance Initiatives ```bash az policy assignment create --name "pci-dss-initiative" \ --policy-set-definition "" \ --scope "/subscriptions/" ``` Revisiting Part 1's Azure Policy discussion with compliance specifically in view: Microsoft provides **built-in regulatory compliance initiatives** — pre-built policy sets mapping directly to PCI-DSS, HIPAA, ISO 27001, and other frameworks — assignable at any scope, feeding directly into the Regulatory Compliance Dashboard covered earlier in this chapter. --- ## A Full Worked Security Bootstrap for Meridian Freight ```bash # 1. Key Vault with RBAC authorization (the current default) az keyvault create --name kv-meridian --resource-group rg-shipment-api-prod --enable-rbac-authorization true # 2. Enable Defender CSPM and relevant workload protection plans az security pricing create --name CloudPosture --tier Standard az security pricing create --name Containers --tier Standard # 3. Sentinel on the shared Log Analytics workspace az sentinel workspace create --resource-group rg-shipment-api-prod --workspace-name log-analytics-meridian # 4. Assign a regulatory compliance initiative matching Meridian Freight's obligations az policy assignment create --name "pci-dss-initiative" \ --policy-set-definition "" --scope "/subscriptions/" ``` --- ## Part 12 CLI Cheat Sheet | Area | Command | Purpose | |---|---|---| | Key Vault | `az keyvault create --enable-rbac-authorization` | Create a vault with RBAC access control | | Certificates | `az keyvault certificate create` | Create a Key Vault-managed, auto-renewing certificate | | Purge protection | `az keyvault update --enable-purge-protection true` | Block permanent deletion even by an Owner | | Managed HSM | `az keyvault create --hsm-name` | Create a single-tenant Managed HSM | | Defender | `az security pricing create` | Enable a CSPM or workload protection plan | | Secure Score | `az security secure-scores list` | Check current security posture score | | Compliance | `az security regulatory-compliance-standards list` | View compliance framework mapping | | Sentinel | `az sentinel workspace create` | Enable Sentinel on a Log Analytics workspace | | Sentinel | `az sentinel alert-rule create` | Create an analytics rule | | Purview | `az purview account create` | Create a data governance account | | Policy | `az policy assignment create --policy-set-definition` | Assign a regulatory compliance initiative | --- ## Common Mistakes and Interview Traps | Mistake | Why It's Wrong | Fix | |---|---|---| | Assuming Managed HSM control-plane RBAC access grants data-plane key access | The two planes use entirely separate authorization systems by design | Grant data-plane access explicitly via Managed HSM's own local RBAC | | Assuming Foundational CSPM is on by default for a new subscription created after October 2026 | The default changed — new subscriptions start with it OFF | Explicitly enable Foundational CSPM (or Defender CSPM) for any new subscription | | Manually managing and renewing TLS certificates outside Key Vault | Reintroduces the exact "expired certificate, nobody noticed" risk Key Vault-managed certificates solve | Use Key Vault-managed certificates with auto-renewal for any service that supports referencing them | | Treating Secure Score as a one-time checklist | Posture drifts over time as new resources and misconfigurations appear | Track Secure Score as an ongoing trend metric, not a one-time target | | Assuming an existing Key Vault automatically uses RBAC because it's now the platform default | Existing vaults keep their configured access model (often legacy access policies) until explicitly migrated | Check and deliberately migrate existing vaults to RBAC rather than assuming the new default applies retroactively | | Leaving purge protection disabled on a production vault | A malicious or mistaken Owner-level actor can permanently purge secrets/keys beyond recovery | Enable purge protection on any vault holding genuinely critical material | | Exposing a production Key Vault on a public endpoint | Contradicts this series' repeated Zero Trust, default-deny recommendation | Use Private Link for any vault holding sensitive production material | --- ## Worked Practice Problems **Problem 1:** A security engineer is granted the `Contributor` role (Azure RBAC) on a Managed HSM resource and expects this to let them read and use the keys stored inside it. They find they cannot perform any key operations at all. What's the cause? *Answer:* Managed HSM deliberately separates control-plane access (managing the HSM resource itself, governed by Azure RBAC) from data-plane access (actually using the keys for cryptographic operations, governed by the Managed HSM's own local RBAC system) — this is an intentional design choice preventing privilege escalation through the control plane alone. Being granted `Contributor` at the Azure RBAC level manages the HSM resource's existence and configuration but grants zero data-plane permission to use its keys; the engineer needs to be explicitly granted a data-plane role through Managed HSM's own local RBAC by one of the HSM's designated data-plane administrators. **Problem 2:** Meridian Freight creates a new Azure subscription in November 2026 and, weeks later, a security review finds no Secure Score data or baseline recommendations exist for it at all, despite the team assuming baseline security visibility is always on by default. What changed, and what should the team do? *Answer:* As of October 27, 2026, new Azure subscriptions default to Foundational CSPM being OFF, requiring explicit opt-in — a reversal of the previous default where baseline posture assessment was automatically enabled. The team needs to explicitly enable Foundational CSPM (or upgrade directly to paid Defender CSPM if the additional capabilities are needed) for this specific subscription; this is now a required setup step for any new subscription created after that date, not something to assume happens automatically the way it did for subscriptions created earlier. **Problem 3:** A departing engineer with residual `Owner` access attempts to delete Meridian Freight's production Key Vault out of malice before their access is revoked. The vault has soft delete enabled (the platform default) but purge protection was never explicitly enabled. What's the actual risk in this specific configuration, and what should have been different? *Answer:* Soft delete alone means the vault enters a recoverable deleted state rather than vanishing immediately — but WITHOUT purge protection, the same `Owner`-level actor (or anyone with sufficient permission) can issue a follow-up PURGE command that permanently, irrecoverably deletes the vault and everything in it, bypassing soft delete's recovery window entirely. This is exactly why purge protection needs to be enabled explicitly and separately from soft delete — it's the control that specifically prevents even a high-privilege actor from permanently destroying the vault, which soft delete alone does not guarantee. Meridian Freight's platform team should enable purge protection on every production vault as a standard, non-optional step in vault provisioning, not an afterthought considered only after a near-miss. --- ## Summary and What's Next - **Azure RBAC is now the default Key Vault access control model** (API version 2026-02-01+) — unifying vault permissions with the same system governing every other Azure resource, though existing vaults require deliberate migration. - **Managed HSM's data-plane access is entirely separate from control-plane Azure RBAC** — a deliberate isolation preventing privilege escalation, genuinely different from regular Key Vault's now-unified model. - **Foundational CSPM defaults to OFF for new subscriptions starting October 2026** — a real, actionable change from the previous always-on default. - **Sentinel correlates signals across every layer this series has covered** — identity risk (Part 2), network flow logs (Part 7), and more — catching coordinated attacks no single signal would flag alone. - **Key Vault-managed certificates with auto-renewal close the same "expired cert" risk** Part 6 flagged for Front Door specifically, generalized across every Key-Vault-integrated service. - **Purge protection, separate from soft delete, is what actually prevents permanent, malicious or accidental destruction** of a vault's contents — a required, not optional, step for production vaults. **Continue to Part 13** (`13-monitoring-logging-and-observability.md`) for Azure Monitor, Log Analytics, and Application Insights — the observability layer Sentinel and every other service in this series builds on.