Security Review Portfolio

AI & Azure Security Architecture · Public Edition

Azure Architecture, Deployment & Operational Security Review

A public methodology report showing how a live Azure footprint can be assessed through architecture mapping, safe read-only evidence, Zero Trust principles, operational telemetry and governed delivery.

Audience Security leaders, architects and operators Evidence Safe read-only Azure inspection Coverage Architecture, deployment and operations Companion AI/LLM and application review Formats Chaptered · single page for reading or print

Informed by OWASP LLM Top 10 OWASP Top 10 / ASVS NIST AI RMF (GenAI Profile) MITRE ATLAS / CWE Microsoft Zero Trust

Section 1

Executive Summary

Cloud-security conclusions should be tied to the environment that is actually deployed, not inferred solely from diagrams or infrastructure templates.

This review method starts by reconstructing the as-built Azure footprint and end-to-end data flow. It then examines identity, network boundaries, configuration, secrets, data services, containers, delivery controls, logging and alerting through safe evidence. The resulting architecture view connects each security principle to the service path it protects.

Assessment principle. Treat every cloud claim as a statement that needs a reproducible source, an evidence boundary and an explicit confidence level.

Section 2

Scope and Evidence Boundaries

The review covers the deployed application path from browser and API through configuration, object and queue storage, asynchronous processing and the operational data store. It considers the identities, network relationships and data movement that connect those components.

In the illustrative reference architecture these are Microsoft Entra ID, Azure Container Apps, Azure App Configuration, Azure Blob and Queue Storage, Azure Cosmos DB, Azure Key Vault, Azure Container Registry and Azure Monitor with Log Analytics.

The reviewed system (illustrative)

Click or tap a zone or checkpoint on the diagram to jump to the related illustrative security examples.

Component diagram of the illustrative reference platform: a browser single-page application and Microsoft Entra ID connect to an API, web app and asynchronous worker on Azure Container Apps; the worker calls Azure AI Document Intelligence and Azure OpenAI; data lives in Azure Blob and Queue Storage, Azure Cosmos DB, Azure App Configuration and Azure Key Vault; a planned Azure DevOps and Container Registry delivery path and an Azure Monitor and Log Analytics operations zone complete the picture.
The illustrative reference platform assessed across both reports. The architecture is fictional and representative: it names Azure services to anchor the review method and contains no client environment details. See also the document-processing flow and the trust-boundary view.

Review lenses per service

Azure service What the review examines Representative risks (Microsoft-documented)
Azure Container Apps Ingress exposure, workload identities, container hardening and runtime configuration Public endpoints without identity enforcement; over-privileged or shared identities; writable root filesystems
Azure Blob + Queue Storage Access model, network reach, lifecycle and deletion behavior Shared-key access left enabled; public network paths; orphaned documents outliving their records
Azure Cosmos DB Data-plane authentication, role scope and query surface Local authentication enabled alongside Microsoft Entra ID; broad data-plane roles; connection strings in configuration
Azure App Configuration Configuration scoping per identity and secret-reference hygiene One shared configuration scope for every workload; secrets stored as plain values instead of references
Azure Key Vault Access model, purge protection and reference patterns Broad get and list permissions; missing soft-delete or purge protection; secrets duplicated outside the vault
Azure Container Registry Admin account state, anonymous pull and image origins Enabled admin credentials; mutable tag-based deployment instead of digest pinning
Microsoft Entra ID User sign-in flows, workload identities and role assignments Long-lived client secrets where federation is available; least-privilege drift in role assignments
Azure Monitor + Log Analytics Diagnostic coverage, retention and alert ownership Missing data-plane logs; retention below investigation windows; alerts without an owned response path

Review lenses are generic and drawn from Microsoft security-baseline and Well-Architected guidance. Representative risks are typical finding categories for each service, not engagement findings.

Boundary. Read-only configuration evidence can establish observable control state and service relationships. It does not replace approved penetration testing, authenticated business-flow testing or long-term operational monitoring.

Section 3

Methodology

  1. Inventory the footprint. Identify services, workloads, identities, data stores and delivery surfaces in scope.
  2. Trace the data flow. Follow client information from ingress through processing, storage and retrieval.
  3. Map trust boundaries. Record which component can read, transform, route or act on information.
  4. Collect safe evidence. Use read-only cloud queries and preserve the observed result and evidence limit.
  5. Challenge conclusions. Use the Threat Tribunal multi-model harness to propose, challenge and arbitrate observations.
  6. Apply human review. Assess confidence, operational relevance and remediation priority before creating delivery work.

Section 4

Control Domains and Examples at a Glance

Each control domain has its own page with worked, explicitly fictional severity examples. The table lists every example for quick scanning.

Severity Illustrative example (fictional) Control domain
Critical Sensitive Operations Lack a Default-Deny Identity Boundary Architecture and Trust Boundaries
High Privileged Service Follows an Untrusted Callback Destination Architecture and Trust Boundaries
Medium Public Discovery Surface Reveals Unnecessary Operations Architecture and Trust Boundaries
Critical One Workload Identity Can Traverse Multiple Trust Zones Identity, Least Privilege and Network Exposure
High Frontend Workload Can Read Backend-Only Configuration Identity, Least Privilege and Network Exposure
Medium Supporting Services Retain Unnecessary Public Network Paths Identity, Least Privilege and Network Exposure
Critical Long-Lived Cloud Credentials Exist in Source or Build History Secrets, Configuration and Data Protection
High Secrets Are Stored as Shared Application Configuration Secrets, Configuration and Data Protection
Medium Record Deletion Can Leave Associated Objects Behind Secrets, Configuration and Data Protection
Low Unused Configuration Points to a Retired Service Destination Secrets, Configuration and Data Protection
Critical Unverified Build Inputs Can Produce an Untrusted Release Container, Infrastructure and Delivery Controls
High Manual Deployment Path Bypasses Security and Approval Gates Container, Infrastructure and Delivery Controls
Medium Container Workloads Use an Unrestricted Default Runtime Identity Container, Infrastructure and Delivery Controls
Low Competing Package Inputs Make Builds Non-Deterministic Container, Infrastructure and Delivery Controls
Critical Privileged Changes and Sensitive Access Produce No Actionable Signal Directed Logging, Monitoring and Response
High Security Logs Are Not Centralized or Retained for Investigation Directed Logging, Monitoring and Response
Medium Alerts Exist Without an Owner or Tested Response Path Directed Logging, Monitoring and Response

Section 5

Relationship to the Application Review

The Azure review assesses running configuration, service relationships and observable operational controls using safe, read-only evidence. The application review assesses source code, infrastructure as code, dependencies and delivery artifacts. Areas of overlap are intentionally compared. Agreement between the two evidence streams strengthens confidence, while differences reflect their distinct scopes and evidence boundaries.

Read the companion AI/LLM and application security review.

Section 6

Public Edition and Disclosure

This purpose-built public edition is intended for external sharing. It contains no client names, tenant or subscription identifiers, resource names, internal URLs, work-item references, source paths, commit identifiers, screenshots, sample data, credentials, or combinations of details that could reconstruct a specific finding.

The severity-labelled material in Sections 4 through 8 consists only of newly authored fictional examples. It does not report, summarize or imply any engagement finding or actual severity rating.

Cross-reference links point only to newly authored demonstration evidence in Section 9. They are not client source links, Azure resource links or engagement tool output.

Section 7

Limitations

This report explains the assessment scope, methodology, control domains and generalized security lessons. It does not reproduce client-specific findings, actual severity ratings, evidence, remediation status or current production configuration. Severity labels shown in Sections 4 through 8 apply only to newly authored fictional examples and do not describe the reviewed environment. It is not a penetration-test report, certification, assurance opinion or statement that any example weakness was present. Inclusion of a topic means it was assessed, not that a finding existed.

Section 8

Public References