Microsoft organizes this guidance into two frameworks that work together: the Cloud Adoption Framework (CAF) Secure methodology for the strategic/governance layer, and the Well-Architected Framework (WAF) Security pillar for workload-level architecture decisions. The CAF Secure methodology applies Microsoft security best practices at each stage of the cloud adoption journey, built on Zero Trust principles. The WAF Security pillar exists to protect the workload from attacks by maintaining confidentiality and data integrity.

1. Identity and access

• Zero Trust as the foundation — adopt Zero Trust guidance to drive a security-first mindset rather than assuming a trusted network perimeter.
• Entra ID over static keys — use Microsoft Entra ID for authentication instead of API keys, since it provides centralized identity management and advanced security features that static keys lack. This mirrors the Valet Key / Managed Identity pattern in the diagram you shared earlier.
• Least-privilege RBAC, Conditional Access, and Privileged Identity Management for anything with elevated rights.

2. Network and workload isolation

• Multi-layer segmentation — the Gatekeeper → Bulkhead → Valet Key pattern you diagrammed is a textbook implementation of this: perimeter (WAF/Front Door) → network isolation (VNet/subnet) → scoped credentialed access (Key Vault/Managed Identity).
• Sentinel connectors for virtual network flow logs to improve threat visibility was added as recent Azure Virtual Network guidance.
• Private Link/Private Endpoint to keep PaaS traffic off the public internet, as shown in your diagram’s “10.x.x.x” hop.

3. Data protection

• Encryption at rest and in transit by default; Azure SQL Database offers options like transparent data encryption, and organizations typically standardize on tools like Microsoft Purview Information Protection for sensitive data in transit such as email.
• Secrets, keys, and certificates centralized in Key Vault — never embedded in app config, matching the credential-governance approach we used for the Kong gateway.

4. Infrastructure as Code and deployment safety

• Colocate IaC assets with application code and apply the same safe deployment practices used for software, using deployment stacks to manage Azure resources as a single cohesive unit.
• Policy-as-code (Azure Policy) to enforce baselines automatically rather than relying on manual review.

5. Continuous posture management

• Automate validation through policy, infrastructure as code, continuous compliance scanning, and secure score tracking in Microsoft Defender for Cloud.
• Document security baselines aligned with CIS, NIST, or the Microsoft Cloud Security Benchmark (MCSB), and continuously measure workloads against those baselines.
• Recent WAF updates added recommendations for security exercises, including tabletop simulations and red-teaming — worth building into an ongoing program, not a one-time audit.

6. Monitoring and incident response

• Use a robust monitoring solution to automatically enroll all resources in the cloud estate, with alerting configured to notify the right teams when incidents occur, preferring Azure-native tooling where possible.
• Track secure score controls in Defender for Cloud to quantify gaps, paired with risk-based metrics like exposure of high-privilege identities or unencrypted sensitive stores.

7. AI-specific controls (relevant given our Kong AI Gateway work)

• Apply Azure security baselines to all AI resources, since they provide standardized controls addressing common vulnerabilities across AI platforms.
• Enable Microsoft Defender for Cloud’s AI threat protection to monitor for prompt injection attacks and model manipulation — the Azure-native counterpart to Kong’s AI Prompt Guard / Semantic Prompt Guard plugins.
• Require Microsoft Entra ID authentication for AI model endpoints rather than API keys, applying this to Foundry, Azure OpenAI, and Foundry Tools specifically.

Sustaining it

• Security spans strategy, planning, readiness, adoption, governance, and operations — a gap in any one phase weakens the overall posture, so treat it as continuous rather than a point-in-time project.
• Security is not static: look for patterns indicating misuse or anomalies, and conduct regular reviews of access logs, security policies, and incident response plans.

Each pattern now has its concrete control checklist attached, plus a cross-cutting band at the bottom for Defender for Cloud, Policy-as-code, and safe IaC deployment, which apply across every layer rather than just the data tier.

MCSB Mapping (quick reference)

The Microsoft Cloud Security Benchmark groups controls into domains that line up cleanly with the three patterns:

Pattern	MCSB Domain(s)	Key controls
Gatekeeper	Network Security (NS), Endpoint Security	NS-1 (establish network boundaries), NS-6 (WAF deployment), NS-8 (DDoS protection)
Bulkhead	Network Security, Identity Management	NS-1/NS-2 (segmentation, private connectivity), IM-1 (centralize identity)
Valet Key	Privileged Access (PA), Data Protection (DP)	PA-7 (least privilege/JIT), DP-7/DP-8 (key/secret management via Key Vault)
Cross-cutting	Logging & Threat Detection (LT), Posture & Vulnerability Management (PV)	LT-1 (enable threat detection), PV-2 (automate posture tracking via Defender secure score)

Each domain has numbered sub-controls in the published MCSB documentation (currently v1 on Microsoft Learn) .