Cloud Security Architecture: Zero Trust, Identity and Network Segmentation

The Security Paradigm Shift: Perimeter to Zero Trust

On-premises security operated on a simple principle: everything inside the firewall is trusted, everything outside is not. The firewall was the perimeter. VPN extended the perimeter to remote users. As long as you were "inside," you could access resources with minimal additional verification.

Cloud invalidates this model. There's no "inside." The Azure SQL database is accessed over HTTPS from VMs in the same region, from on-premises servers through ExpressRoute, and from developer laptops through the internet — all through the same endpoint. The Kubernetes cluster runs workloads from 3 teams on shared nodes. The SaaS applications your employees use are entirely outside your infrastructure. The "perimeter" that on-premises security depended on simply doesn't exist in cloud architecture.

Zero Trust replaces the perimeter model with: "never trust, always verify." Every access request is authenticated, authorized, and encrypted — regardless of whether the request comes from inside the network or outside, from a trusted device or an unknown one, from a corporate office or a coffee shop. Identity — not network location — becomes the security perimeter.

The 5 Pillars of Cloud Zero Trust

Pillar 1: Identity as the New Perimeter

Identity is the foundation of Zero Trust — every other pillar depends on reliable identity verification. If the identity system is compromised, every downstream security control fails because the attacker has a "valid" identity.

Multi-Factor Authentication (MFA) — Non-Negotiable

Every identity — human and service — must authenticate with MFA. Password-only authentication is the #1 attack vector for cloud breaches. Microsoft reports that 99.9% of account compromise attacks are blocked by MFA. Deploy: MFA for all users (Authenticator app, not SMS), phishing-resistant MFA for administrators (FIDO2 keys, Windows Hello), and certificate-based authentication for service identities (managed identity, service principal with certificate — never shared secrets).

Conditional Access: Context-Aware Authorization

MFA alone is insufficient — context matters. Conditional Access policies evaluate: who is requesting access (user, role, group), what device (corporate-managed, BYOD, unknown), from where (corporate network, known location, anonymous VPN), to what resource (sensitive data, admin console, public content), and at what risk level (sign-in risk score from Azure AD Identity Protection). Based on these signals, the policy: allows access, requires additional verification (step-up MFA), limits access (read-only, no downloads), or blocks access entirely.

Example policies: "access to financial systems requires managed device + MFA + known location," "access to public SharePoint from any device with MFA," "admin console access requires phishing-resistant MFA + privileged identity management approval." These policies implement least-privilege access that adapts to context — more restrictive for sensitive resources, less restrictive for low-risk ones.

Privileged Identity Management (PIM)

Standing admin access — permanent Global Admin, permanent Subscription Owner — is the highest-risk identity pattern. PIM converts standing access to just-in-time: administrators request elevated access when needed, with justification, for a limited duration (1-8 hours), with approval workflow. After the duration expires, the elevation reverts automatically. PIM reduces the window of exposure from permanent (365 days/year) to transient (hours per month).

Pillar 2: Network Micro-Segmentation

Micro-segmentation divides the cloud network into isolated segments — each workload communicates only with the specific resources it needs, through explicitly allowed paths. A compromised web server can't pivot to the database server because network rules prevent the connection — even though both are "inside" the same cloud subscription.

Azure Network Architecture

VNet design: Separate VNets for production, development, and management. Each VNet is isolated by default — cross-VNet communication requires explicit peering with filtered NSG rules. Hub-and-spoke topology: a central hub VNet contains shared services (firewall, DNS, monitoring); spoke VNets contain workloads, peered to the hub for shared service access.

Network Security Groups (NSGs): Applied at the subnet and NIC level, NSGs filter traffic by source/destination IP, port, and protocol. Default: deny all inbound, allow all outbound. Explicit rules allow only required communications — the web tier accepts HTTPS (443) from the internet; the API tier accepts requests only from the web tier; the database tier accepts connections only from the API tier. Each layer is isolated from every other layer it doesn't need to communicate with.

Private Endpoints: Azure PaaS services (SQL Database, Storage, Key Vault) are accessed through private endpoints on VNet — removing the public internet from the data path entirely. The SQL Database doesn't have a public IP; it's accessible only through the VNet's private endpoint. This eliminates the entire class of attacks that target public-facing PaaS endpoints.

Pillar 3: Data Protection — Encryption, Classification, DLP

Encryption everywhere: Data at rest encrypted with AES-256 (Azure Storage Encryption, TDE for SQL). Data in transit encrypted with TLS 1.2+ (enforced, not optional). Keys managed in Azure Key Vault (not hardcoded in applications, not stored in config files, not shared via email). Customer-managed keys (CMK) for organizations requiring key control — the encryption key lives in your Key Vault, not Microsoft's.

Data classification with Microsoft Purview: Automatically scan and classify data across the estate — identifying PII (SSN, credit cards, health records), financial data, intellectual property, and regulated content. Classification labels drive policy: "confidential" data triggers DLP rules preventing external sharing, "restricted" data triggers access reviews, "public" data flows freely. Classification is the foundation of data governance in cloud — you can't protect what you can't identify.

Data Loss Prevention (DLP): Policies that prevent sensitive data from leaving the organization through unauthorized channels — email attachments, cloud storage sharing, copy-paste to external applications. Microsoft 365 DLP covers: Exchange Online (email), SharePoint/OneDrive (documents), Teams (messages), and endpoint DLP (desktop actions). Cloud DLP extends to Azure resources — preventing classified data from being exported to unapproved storage or shared with unapproved identities.

Pillar 4: Workload Security — Containers, VMs, Serverless

Every compute workload — VM, container, serverless function — is a potential attack surface. Workload security hardens each compute type against its specific threat model.

VM security: OS patching (Azure Update Management for automated patching), endpoint protection (Defender for Servers for malware detection and response), just-in-time VM access (RDP/SSH ports closed by default, opened only on request for limited duration), and disk encryption (Azure Disk Encryption with Key Vault-managed keys).

Container security: Image scanning (Defender for Containers scans images in ACR for vulnerabilities before deployment), runtime protection (monitors running containers for anomalous behavior — privilege escalation, unexpected network connections, file system modifications), admission control (Kubernetes admission controllers enforce: no privileged containers, no root users, required resource limits, approved image registries only), and network policies (Kubernetes NetworkPolicy restricts pod-to-pod communication to explicitly allowed paths).

Serverless security: Azure Functions and Logic Apps have a smaller attack surface (no OS to manage) but require: input validation (functions accept external triggers — validate all input), identity-based access (managed identity for all resource access, never connection strings), and dependency scanning (function dependencies may include vulnerable packages).

Pillar 5: Continuous Monitoring and Threat Detection

Microsoft Sentinel: Cloud-native SIEM (Security Information and Event Management) that aggregates security signals from all Azure resources, Microsoft 365, on-premises systems, and third-party security tools. Sentinel uses AI/ML to detect threats that rule-based systems miss — unusual sign-in patterns, lateral movement between resources, data exfiltration indicators, and insider threat behavior. Automated playbooks (SOAR — Security Orchestration, Automation, and Response) respond to detected threats without waiting for human analysis: isolate a compromised VM, disable a compromised account, block a malicious IP.

Microsoft Defender for Cloud: Cloud Security Posture Management (CSPM) continuously assesses Azure resource configuration against security benchmarks (CIS, Azure Security Benchmark, PCI-DSS). Secure Score quantifies the organization's security posture (0-100). Recommendations prioritize the configuration changes that improve security most — "enable MFA for all admins" might add 10 points; "enable NSG flow logs" adds 2 points. The prioritized recommendation list focuses security investment on the highest-impact improvements.

Azure Zero Trust Implementation

Zero Trust Maturity Assessment

Where is your organization on the Zero Trust maturity curve?

Go Deeper

Continue building your understanding with these related resources from our consulting practice.