Azure Security Domain

Azure Security is the set of controls, practices, and services that protect cloud resources against threats, enforce compliance, and maintain the confidentiality, integrity, and availability of data and systems. This domain page explains security as a cross-cutting architectural concern—not a collection of products—and focuses on Zero Trust principles, design decisions, threat protection, and the specific security demands of modern AI and agent systems. It is structured for reuse across multiple Azure certifications.

1. Overview

#

What Is Security in Cloud Architecture

#

In cloud architecture, security is the discipline of designing, implementing, and continuously verifying controls that prevent, detect, and respond to threats. It spans every layer of the stack: identity, networking, data, compute, and the application code itself. Security is not a feature bolted on after deployment; it is a foundational design principle that shapes system boundaries, access models, and operational processes.

Security as a Cross-Cutting Architectural Concern

#

Security intersects with every Azure domain:

• Identity: authentication, authorization, and privileged access management.
• Networking: micro-segmentation, firewalls, private endpoints, and DDoS protection.
• Storage & Databases: encryption at rest and in transit, key management, access control.
• Compute: workload protection, vulnerability scanning, host encryption.
• Integration: secure API exposure, message encryption, endpoint validation.
• AI & Agents: prompt injection defence, tool invocation boundaries, data isolation.

Because an attacker only needs one weak link, security must be architected holistically, with multiple overlapping layers of defense.

Why Zero Trust Replaces Traditional Perimeter Security

#

Traditional security assumed a trusted internal network. In the cloud, with globally distributed users, services, and workloads, the network perimeter is no longer sufficient. Zero Trust is the architectural model that:

• Verifies explicitly: authenticate and authorize every request based on all available data points (user identity, device health, location, anomaly signals).
• Uses least privileged access: grant just enough access, just in time.
• Assumes breach: segment resources, encrypt everywhere, monitor continuously.

In Azure, Zero Trust is implemented through Microsoft Entra ID, Conditional Access, RBAC, network micro-segmentation, and continuous monitoring. Identity becomes the primary security boundary, reinforced by network and data controls.

2. Core Security Pillars in Azure

#

Azure security can be organised into four interrelated pillars that align with the layers of a cloud workload.

Identity Security

#

Identity is the new perimeter. Core components:

• Microsoft Entra ID: the identity provider that authenticates users, devices, and services. It enforces Conditional Access policies that evaluate risk before granting access.
• Azure RBAC: authorizes management and data plane operations at granular scope (management group, subscription, resource).
• Privileged Identity Management (PIM): just-in-time privileged role activation with approval, time-bound, and audit trail.
• Multi-factor authentication (MFA): a fundamental control, enforced through Conditional Access, to prevent credential theft.

Network Security

#

Network controls create segmentation and restrict lateral movement:

• Azure Firewall: stateful firewall-as-a-service for east-west and north-south traffic inspection.
• Network Security Groups (NSGs): packet-level filters for subnets and NICs.
• Web Application Firewall (WAF): Layer 7 protection against OWASP Top 10 attacks, integrated with Application Gateway, Front Door, and CDN.
• Azure DDoS Protection: defends against volumetric and protocol attacks.

Data Security

#

Data must be protected at rest, in transit, and increasingly in use:

• Azure Key Vault: stores secrets, keys, and certificates; provides HSMs for key protection.
• Encryption: all Azure storage and databases automatically encrypt data at rest. Services support customer-managed keys for added control.
• Confidential Computing: protects data in use by executing sensitive workloads in hardware-based trusted execution environments (TEEs), preventing even the cloud operator from accessing data.

Workload Security

#

Protecting the compute that runs business logic and AI models:

• Microsoft Defender for Cloud: vulnerability management, security posture management, and workload protection for VMs, containers, and serverless.
• Azure Policy: enforces configuration standards (e.g., deny public IPs, require encryption) at scale.
• Just-in-time VM access: time-bound, audited access to management ports.

3. Azure Security Services Mapping

#

4. Security Architecture Model

#

Defense-in-Depth Strategy

#

Azure security relies on layered defenses so that a failure in one layer is contained by another:

• Physical security: datacenters with hardened access and protection.
• Identity & access: authentication, RBAC, PIM, MFA.
• Perimeter: DDoS, firewalls, gateways.
• Network: NSGs, VNet segmentation, private endpoints.
• Compute: OS hardening, endpoint protection, vulnerability scanning.
• Application: WAF, secure development practices, code scanning.
• Data: encryption, key management, data classification.

Each layer assumes the outer layers might be compromised; zero trust eliminates the concept of a trusted network.

Zero Trust Architecture Model

#

In a Zero Trust Azure deployment:

• Every call is authenticated and authorized (managed identity for services, user tokens for humans).
• Conditional Access gates every access attempt based on real-time risk.
• Network segmentation restricts east-west traffic via NSGs and Azure Firewall.
• Data is encrypted by default; access is granted per data object, not network segment.
• Continuous monitoring detects anomalies and triggers response actions.

Security Boundary Design

#

In cloud architecture, security boundaries are defined by:

• Management groups and subscriptions: policy and access control boundaries.
• Virtual Networks and subnets: network isolation boundaries.
• Resource groups and RBAC scopes: authorization boundaries for operations.
• Private Endpoints: service access boundaries, eliminating public exposure.

These boundaries create containment zones; an attacker who compromises one resource cannot automatically move laterally.

Segmentation and Isolation Strategies

#

• Hub-spoke VNet topology: a central hub hosts shared security services (firewall, gateway); spoke VNets isolate workloads.
• Application security groups (ASGs): group VMs by application role for fine-grained NSG rules.
• Container network policies: in AKS, enforce pod-to-pod isolation.
• Logical segmentation: separate subscriptions for production and non-production, with distinct identity tenants if required.

Threat Surface Reduction Techniques

#

• Minimise public IPs: use private endpoints and internal load balancers.
• Restrict outbound access: force-tunnel internet traffic through a firewall for inspection.
• Remove unnecessary privileges: use JIT, PIM, and just-enough-access.
• Harden images: use Azure Compute Gallery with pre-hardened OS images.
• Continuous posture management: Defender for Cloud to identify and remediate misconfigurations.

5. Security Design Decisions

#

When to Use Defender vs Sentinel

#

• Defender for Cloud: for security posture management (vulnerability assessments, compliance scoring) and workload protection (threat alerts for VMs, containers, databases). It is the first line of detection and prevention.
• Microsoft Sentinel: for centralised security information and event management (SIEM). Use when you need to aggregate logs from multiple sources, correlate complex attack patterns across hybrid/multi-cloud, and automate investigation and response with SOAR.

They are complementary: Defender feeds alerts to Sentinel, which provides extended analytics, hunting, and orchestration.

Network-Based Security vs Identity-Based Security

#

• Network-based security (NSGs, firewalls, WAFs) restricts traffic flows based on IP, port, and protocol. It is effective for perimeter and lateral movement control but becomes complex in dynamic, cloud-native environments.
• Identity-based security (Entra ID, RBAC, Conditional Access) ties access to a verifiable identity, independent of network location. It scales better for distributed, mobile-first, and multi-cloud scenarios.

Modern architectures lean on identity as the primary access control, reinforced by network segmentation. The principle: authenticate and authorise every connection, not just those at the perimeter.

Encryption Strategies

#

• At rest: enabled by default with Microsoft-managed keys. Use customer-managed keys (CMK) to retain control over key lifecycle and rotation, especially for regulated data.
• In transit: enforce TLS 1.2+; Azure policies can deny non-secure transfer. For ultra-sensitive data, consider application-layer encryption (Always Encrypted in SQL).
• In use: Confidential Computing protects data while in memory, enabling scenarios where data must be processed without exposure even to the infrastructure owner.

Key Management Strategies

#

• Azure Key Vault: suitable for most workloads; HSMs backed, but Microsoft retains control plane access.
• Managed HSM: dedicated FIPS 140-2 Level 3 HSM; no Microsoft access to keys. Required for the highest security and compliance (e.g., PCI DSS, certain government standards).

Key rotation should be automated via event-driven functions or Key Vault’s built-in rotation policies (for certain services).

Centralised vs Decentralised Security Governance

#

• Centralised: a security team defines policies, monitors, and responds from a central platform (e.g., Azure Policy at management group, Sentinel across all subscriptions). Ensures consistency.
• Decentralised: individual application teams manage some security controls within guardrails. Improves agility and accountability.

A hybrid model is typical: centralised policy enforcement and monitoring, with decentralised implementation within allowed boundaries. Azure Policy and initiative assignments at management group scope enforce the central baseline.

6. Security in Enterprise Architecture

#

Multi-Tier Applications

#

• Web tier: Internet-facing Application Gateway with WAF, terminating TLS and routing to internal web servers. Web servers run with least-privilege managed identities.
• Business tier: API services in a private subnet, only reachable from the web tier. They use managed identities to access databases.
• Data tier: Databases and storage accounts accessible only via private endpoints; no public access. Encryption at rest with CMK.

Microservices Architectures

#

Microservices increase the number of assets to protect. Security patterns:

• Service identity: each microservice has its own managed identity; no shared keys.
• API gateway: APIM or Application Gateway enforces authentication, rate limiting, and threat protection before traffic reaches services.
• Network policies: in AKS, network policies restrict pod communication to only required dependencies.
• Mutual TLS (mTLS): service mesh (e.g., Istio) can enforce mTLS between services without code changes.

Hybrid Cloud Systems

#

On-premises resources and cloud resources must share security controls:

• Entra ID Connect extends on-premises identities to the cloud; hybrid join enforces Conditional Access.
• Private connectivity (ExpressRoute/VPN) ensures traffic does not traverse the public internet.
• Azure Arc extends Azure Policy and Defender for Cloud to on-premises servers and Kubernetes clusters, enabling centralised governance.

Multi-Region Deployments

#

Security posture must be consistent across regions:

• Global identity: same Entra ID tenant applies globally.
• Network security: replicate hub-spoke topology with Azure Firewall per region.
• Data residency: ensure data at rest stays within chosen geographies; use geo-replication only to compliant regions.
• Failover security: DR region must have identical security controls; failover procedures must include security validation.

Enterprise Compliance Requirements

#

Azure Policy and Defender for Cloud provide continuous compliance monitoring against standards like ISO 27001, SOC 2, HIPAA, and PCI DSS. Custom policies can enforce corporate requirements. Compliance dashboards provide real-time status, and non-compliance can trigger automatic remediation.

7. Security for AI & Agent Systems

#

Modern AI introduces new attack vectors that require explicit architectural mitigations.

Prompt Injection Risks

#

Attackers craft inputs that manipulate an LLM to ignore instructions, reveal system prompts, or execute malicious tool calls. Mitigations:

• Input filtering: sanitise user input before it reaches the LLM; use Azure AI Content Safety.
• System prompt hardening: separate immutable system prompts from user input. Use prompt engineering to instruct the model to ignore instructions from user data.
• Tool parameter validation: the orchestrator validates and sanitises tool arguments before execution, regardless of what the LLM requested.

Tool Misuse in Agent Systems

#

Agents can invoke tools (APIs, functions) with parameters generated by an LLM. Risk: a prompt-injected agent may call a tool to delete data or exfiltrate information. Defenses:

• Least privilege tools: each tool runs under a scoped identity with only the permissions needed for its specific function. A “read” tool cannot write.
• User context propagation: when an agent acts on behalf of a user, the tool invocation must carry the user’s delegated identity (on-behalf-of token). The backend service can then enforce user-level authorization.
• Human-in-the-loop: for high-risk actions (e.g., financial transactions, data deletion), require explicit user confirmation via an approval workflow before the tool executes.

Data Leakage in LLM Applications

#

LLMs can memorise and potentially regurgitate training data or information from RAG retrieval. Mitigations:

• Data isolation: deploy Azure OpenAI models in your own subscription, with access restricted via private endpoints and VNet.
• RAG access control: identity-aware retrieval ensures the LLM only sees documents the current user is authorised to see. Azure AI Search security filters based on user groups.
• Output monitoring: log and audit completions for sensitive content; use Azure AI Content Safety to filter responses.

Secure Azure OpenAI Deployment Patterns

#

• Network isolation: access Azure OpenAI only through a Private Endpoint within a VNet. No public access.
• Identity auth: use managed identity to authenticate from application to Azure OpenAI, not API keys.
• Abuse monitoring: Azure OpenAI detects and blocks abusive prompts; integrate with Defender for Cloud.
• Content filtering: apply content filters for violence, hate, sexual content, and self-harm; adjust thresholds based on use case.

RAG Security and Data Isolation

#

The retrieval pipeline introduces its own security considerations:

• Index permissions: the search index must apply row-level security or document-level ACLs so that users can only retrieve documents they are permitted to see.
• Ingestion security: the ingestion process must validate that uploaded documents are tagged with the correct access labels.
• Embedding generation: embedding calls should go through a private endpoint and not expose the embedding model’s usage externally.

Agent Identity and Permission Boundaries

#

For agent systems (GH-600 focus), the security architecture must:

• Assign each agent a workload identity (managed identity) with minimal privileges.
• Segment tool execution into separate containers or functions with distinct identities.
• Enforce that tool calls cannot exceed the agent’s (and user’s) authorised scope. Use OBO flows for user-delegated permissions; the backend services receive the user’s token and authorise accordingly.
• Log every tool invocation with correlation ID, agent identity, and outcome for full auditability.

8. Detection, Monitoring & Incident Response

#

Azure Monitor Security Signals

#

Azure Monitor collects logs and metrics from all Azure services. Security-relevant signals include:

• Activity Log: all management plane operations.
• Resource logs: data plane operations (e.g., blob access, Key Vault secret reads).
• Microsoft Entra ID logs: sign-in attempts, audit logs, risky sign-ins.
• NSG flow logs: network traffic patterns.

These are sent to Log Analytics and queried by Sentinel.

Sentinel Detection Rules and Analytics

#

Microsoft Sentinel uses built-in and custom analytics rules to detect threats:

• Scheduled rules: run queries on a cadence to detect anomalies (impossible travel, privilege escalation).
• Fusion rules: correlate low-fidelity alerts from multiple sources into high-confidence incidents using machine learning.
• Behavioural analytics: UEBA uses machine learning to baseline user and entity behaviour and flag deviations.

Automated Response (SOAR)

#

Sentinel playbooks (built on Azure Logic Apps) automate incident response:

• Isolate a compromised VM by modifying NSG rules.
• Disable a compromised user in Entra ID.
• Send notifications to security teams with incident details.
• Enrich incidents with threat intelligence data.

Automation reduces mean time to respond (MTTR) and ensures consistent handling.

Security Logging Strategy

#

A comprehensive logging strategy includes:

• Centralisation: all logs to Log Analytics workspace(s), with appropriate retention.
• Immutable logs: critical security logs should be stored in immutable storage for forensic integrity.
• Log levels: ensure data plane diagnostics are enabled for all security-sensitive services (Key Vault, storage, databases).
• Long-term archiving: for compliance, archive logs to Azure Storage with lifecycle policies.

Threat Intelligence Integration

#

Sentinel integrates with threat intelligence feeds (Microsoft Threat Intelligence, third-party, custom STIX/TAXII). Threat indicators can be used in analytics rules to detect known malicious IPs, domains, or file hashes.

9. Reliability & Compliance

#

Regulatory Compliance

#

Azure provides compliance offerings mapped to global, regional, and industry standards. Architecture must leverage:

• Defender for Cloud regulatory compliance dashboard: continuously assesses environment against controls.
• Azure Policy built-in initiatives for standards (e.g., HIPAA HITRUST, PCI DSS).
• Data residency and sovereignty: choose regions and replication settings that meet legal requirements.

Audit Logging and Traceability

#

All management plane operations and many data plane operations are logged. Use Azure Policy to enforce diagnostic settings on all resources. Retain logs in immutable storage for the required period. Integrate with Purview for data classification and lineage tracking.

Policy-Driven Security Enforcement

#

Azure Policy is the enforcement engine for security baselines:

• Deny effect: prevents non-compliant resources from being created (e.g., deny public IP on storage accounts).
• DeployIfNotExists: automatically deploys missing security configurations (e.g., install Defender agent).
• Audit: tracks non-compliance without blocking.

Policies are assigned at management group or subscription scope and inherited, ensuring consistent enforcement.

Continuous Compliance Monitoring

#

Defender for Cloud and Azure Policy continuously evaluate resources. Workbooks and dashboards visualise compliance drift. Alerts can trigger when a resource falls out of compliance, enabling rapid remediation.

10. Certification Mapping

#

11. Real-World Architecture Example

#

Scenario: A secure, multi-tenant SaaS platform with an AI co-pilot for financial analysis.

Zero Trust implementation:

• Identity: all users authenticate via Microsoft Entra ID with Conditional Access (MFA, compliant device). Administrators use PIM for just-in-time access. All services (App Service, Functions, AKS) use managed identities.
• Network: hub-spoke topology. Hub VNet contains Azure Firewall and VPN gateway. Production and development are separate spoke VNets, peered only to the hub. Azure Firewall inspects all traffic between spokes and to the internet.
  • Azure OpenAI and Azure AI Search are accessed via Private Endpoints in the AI services subnet.
  • Storage accounts and databases have public access disabled, accessible only through Private Endpoints.
• Data protection: all data at rest encrypted with CMK stored in Managed HSM. Key rotation automated via Functions. Application-layer encryption for sensitive fields (Always Encrypted in SQL).
• Workload protection: Defender for Cloud enabled for all subscriptions, with continuous vulnerability assessment. Defender for Containers protects the AKS cluster.
• SIEM/SOAR: Microsoft Sentinel ingests logs from all services. An analytics rule detects when an agent’s tool call fails excessively, triggering a playbook that isolates the agent’s container and alerts the security team.

AI agent security:

• The AI co-pilot agent runs on Container Apps within the AI subnet, using a user-assigned managed identity.
• Its tool catalog includes a “query_financial_data” function (read-only, scoped to the user’s portfolio) and a “create_report” function (generates a document, but requires explicit user approval via a Logic Apps workflow).
• The agent’s managed identity has no direct permissions to databases; instead, it obtains an on-behalf-of token from the user’s session, and the backend API authorizes based on the user’s RBAC roles.
• Prompt injection defences: user input is sanitised; tool parameters are validated against allowed schemas before invocation; the agent’s system prompt is immutable.
• All tool calls, prompts, and completions are logged to Application Insights and Sentinel, with correlation IDs. Anomaly detection monitors for unusual tool invocation patterns.
• RAG access: Azure AI Search index has document-level security filters based on user tenant ID and role. The retrieval step uses the user’s identity to filter documents, preventing cross-tenant data leakage.

Compliance: Azure Policy enforces that all resources are in approved regions, TLS 1.2+, and CMK. Defender for Cloud continuously monitors against PCI DSS controls because financial data is processed. Audit logs are immutable.

This architecture demonstrates how security is woven through identity, network, data, and AI, with Zero Trust as the guiding principle—every access verified, every threat monitored, and every AI action bounded by strict permissions.