13.1 Zero Trust Architecture in Cloud (NIST SP 800-207 Principles & Execution)

13.1 Zero Trust Architecture in Cloud (NIST SP 800-207 Principles & Execution)

Quick Answer: Zero Trust Architecture (ZTA) replaces the legacy, flawed "castle-and-moat" security model with an uncompromising security philosophy: "Never Trust, Always Verify", "Assume Breach", and "Verify Explicitly". In traditional perimeter security, once a subject gains access to an internal network or Virtual Private Cloud (VPC), all traffic within that network is implicitly trusted. In a Zero Trust cloud architecture, network locality grants zero implicit privilege. Under NIST SP 800-207, access decisions are separated into a Control Plane and a Data Plane. The Policy Decision Point (PDP)—comprising the Policy Engine (PE) (which determines access via enterprise policy and dynamic risk inputs) and the Policy Administrator (PA) (which issues commands and session credentials)—evaluates every single request against continuous contextual telemetry (identity, device posture, behavioral anomalies, resource sensitivity). The Policy Enforcement Point (PEP) sits inline to establish, monitor, and terminate the connection. In cloud networks, Zero Trust is realized through application-level microsegmentation, workload identity (SPIFFE/SPIRE), mutual TLS (mTLS), and Software-Defined Perimeters (SDP), completely eliminating flat, implicitly trusted VPCs.

For decades, enterprise security relied on network perimeter defense: firewalls, DMZs, and VPNs separated the "untrusted" external internet from the "trusted" internal corporate network. However, the rise of public cloud computing, multi-tenant IaaS/PaaS/SaaS architectures, ephemeral containerized workloads, and a distributed remote workforce has rendered physical and network-boundary perimeters obsolete.

In public cloud environments, workloads run on shared physical hardware, APIs are publicly addressable, and compromised credentials can allow an adversary to traverse an entire enterprise estate in minutes. According to Domain 12 of the Cloud Security Alliance (CSA) Security Guidance v5 and NIST Special Publication 800-207 (Zero Trust Architecture), cloud security must move away from perimeter-based trust and establish an identity-centric, continuously verified operational model.

---

The Core Tenets of Zero Trust (NIST SP 800-207 & CSA Guidance v5)

NIST SP 800-207 outlines seven fundamental tenets that define a true Zero Trust Architecture. Cloud security architects must design systems where each tenet is technically realized:

┌────────────────────────────────────────────────────────────────────────┐
│               THE 7 CORE TENETS OF NIST SP 800-207 ZTA                 │
├────────────────────────────────────────────────────────────────────────┤
│  1. ALL DATA SOURCES & COMPUTING SERVICES ARE CONSIDERED RESOURCES     │
│     Workloads, serverless functions, databases, and APIs are all assets│
├────────────────────────────────────────────────────────────────────────┤
│  2. ALL COMMUNICATION IS SECURED REGARDLESS OF NETWORK LOCATION        │
│     Traffic inside a VPC is untrusted; mTLS encryption is mandatory    │
├────────────────────────────────────────────────────────────────────────┤
│  3. ACCESS TO RESOURCES IS GRANTED ON A PER-SESSION BASIS               │
│     No perpetual trust; trust is ephemeral and transaction-specific    │
├────────────────────────────────────────────────────────────────────────┤
│  4. ACCESS IS DETERMINED BY DYNAMIC POLICY & CONTEXTUAL ATTRIBUTES     │
│     Identity + device health + behavior + data classification          │
├────────────────────────────────────────────────────────────────────────┤
│  5. ENTERPRISE MONITORS & MEASURES INTEGRITY OF ALL ASSETS             │
│     Continuous device posture assessment, patch status, and EDR state  │
├────────────────────────────────────────────────────────────────────────┤
│  6. RESOURCE AUTHENTICATION & AUTHORIZATION ARE DYNAMIC & CONTINUOUS   │
│     Re-evaluate risk continuously during active sessions               │
├────────────────────────────────────────────────────────────────────────┤
│  7. ENTERPRISE COLLECTS MAXIMUM TELEMETRY TO IMPROVE SECURITY POSTURE  │
│     Continuous log ingestion, ML behavioral baselining, and feedback   │
└────────────────────────────────────────────────────────────────────────┘

1. All data sources and computing services are considered resources: An enterprise may comprise multiple classes of devices, cloud storage buckets, microservices, and serverless functions. A Zero Trust policy treats every discrete component as an individual protected resource.
2. All communication is secured regardless of network location: Network location alone does not imply trust. Traffic originating inside a cloud provider's Virtual Private Cloud (VPC) or private subnet must be secured to the exact same standard as traffic originating from an untrusted public Wi-Fi network. All communications must be encrypted and authenticated (typically via TLS 1.3 / mTLS).
3. Access to individual enterprise resources is granted on a per-session basis: Prior access to one resource does not grant access to another resource, nor does it guarantee future access to the same resource. Trust is evaluated on a per-transaction or per-session basis with strictly bounded lifetimes.
4. Access to resources is determined by dynamic policy: Access rules are not static IP allowlists or permanent group memberships. Access is computed dynamically using contextual attributes: client identity, role, requesting asset state, firmware/OS version, installed software, geolocation, time of day, and past behavioral baselines.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets: No asset is inherently trusted. The enterprise continuously inspects the patch level, configuration compliance, and vulnerability status of endpoints and workloads before and during resource access.
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed: This is a continuous cycle of obtaining credentials, verifying identities, evaluating policy, and inspecting telemetry. Modern architectures employ Multi-Factor Authentication (MFA), cryptographic workload tokens, and continuous assertion.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure, and communications: Continuous telemetry from identity providers (IdPs), endpoint detection and response (EDR) agents, VPC Flow Logs, and Cloud Security Posture Management (CSPM) feeds into policy engines to continually refine authorization decisions.

---

NIST SP 800-207 Logical Architecture: PDP vs. PEP

NIST SP 800-207 defines a clear separation of concerns between the Control Plane (where policy decisions are calculated) and the Data Plane (where application workloads communicate). This logical model forms the core of any compliant Zero Trust implementation:

┌────────────────────────────────────────────────────────────────────────┐
│                     NIST SP 800-207 LOGICAL MODEL                      │
├────────────────────────────────────────────────────────────────────────┤
│                             CONTROL PLANE                              │
│  ┌──────────────────────────────────────────────────────────────────┐  │
│  │                 POLICY DECISION POINT (PDP)                      │  │
│  │                                                                  │  │
│  │   ┌───────────────────────────┐   ┌──────────────────────────┐   │  │
│  │   │       POLICY ENGINE       │◄─►│   POLICY ADMINISTRATOR   │   │  │
│  │   │   (Evaluates Rule Logic   │   │ (Issues Session Tokens & │   │  │
│  │   │   & Grants/Denies Access) │   │ Commands the Inline PEP) │   │  │
│  │   └─────────────▲─────────────┘   └────────────┬─────────────┘   │  │
│  └─────────────────┼──────────────────────────────┼─────────────────┘  │
│                    │ Telemetry                    │ Control Commands   │
├────────────────────┼──────────────────────────────┼────────────────────┤
│                    │                              ▼                    │
│                 DATA PLANE              ┌──────────────────┐           │
│  ┌──────────┐                            │POLICY ENFORCEMENT│  ┌──────────┐│
│  │ SUBJECT  │═══════════════════════════►│    POINT (PEP)   │═►│ RESOURCE ││
│  │ (User or │   Untrusted Data Session   │  (Gatekeeper /   │  │(App, API,││
│  │ Workload)│                            │ Reverse Proxy)   │  │ DB, Data)││
│  └──────────┘                            └──────────────────┘  └──────────┘│
└────────────────────────────────────────────────────────────────────────┘

1. The Policy Decision Point (PDP)

The PDP is the brain of the Zero Trust Architecture. It resides strictly in the Control Plane and consists of two distinct sub-components:

• Policy Engine (PE): The PE is responsible for the ultimate decision to grant, deny, or revoke access to a resource. It applies enterprise security policy rules against contextual inputs. The PE does not communicate directly with the end user or data plane; it purely computes authorization decisions.
• Policy Administrator (PA): The PA is the operational executor of the PDP. Once the Policy Engine renders an access decision, the Policy Administrator establishes or shuts down the communication path. It generates dynamic, short-lived session credentials (e.g., signed JSON Web Tokens [JWT], ephemeral certificates, or Kerberos tickets) and commands the Policy Enforcement Point (PEP) to open or terminate the data plane connection.

2. The Policy Enforcement Point (PEP)

The PEP resides in the Data Plane. It acts as the inline gatekeeper that directly intercepts, inspects, and enables, monitors, or severs the connection between a subject (client, user, or microservice) and an enterprise resource. The PEP enforces the instructions issued by the Policy Administrator. Examples of cloud PEPs include API Gateways, Service Mesh Ingress/Sidecar Proxies (Envoy), Software-Defined Perimeter (SDP) Gateways, and Cloud Access Security Brokers (CASBs).

3. Continuous External Telemetry Feeds

The Policy Engine cannot operate in a vacuum. Under NIST SP 800-207, the PDP continuously ingests data from external sources:

• Continuous Diagnostics and Mitigation (CDM): Ingests endpoint patch status, vulnerability scans, and OS configurations.
• Threat Intelligence: Ingests external Indicators of Compromise (IoCs), malicious IP feeds, and zero-day threat feeds.
• Data Access Policies: Defines attributes, data classification levels (e.g., Confidential, Restricted), and regulatory restrictions (GDPR, HIPAA, PCI DSS).
• Public Key Infrastructure (PKI): Issues and validates X.509 cryptographic certificates for subjects, workloads, and resources.
• Identity Management (IdP): Verifies user credentials, group memberships, and MFA state.
• Security Information and Event Management (SIEM) & UEBA: Analyzes historical activity logs, access trends, and behavioral anomalies.

---

Continuous Contextual Risk Evaluation

In a legacy model, authentication occurs once at login (the "front door"), granting a session that remains trusted for hours. In Zero Trust, authentication and authorization are continuous and contextual.

Contextual Attributes Evaluated by the PDP:

1. Cryptographic Identity Assurance: Strong, phishing-resistant Multi-Factor Authentication (FIDO2/WebAuthn, hardware security keys). For workloads: cryptographically signed identity documents (SPIFFE IDs).
2. Device State & Compliance Posture: Is the device managed by enterprise Mobile Device Management (MDM)? Is the operating system fully patched? Is full-disk encryption active? Is the endpoint detection and response (EDR) agent healthy and reporting no active infections? Is Secure Boot verified via hardware Trusted Platform Module (TPM)?
3. Environmental & Network Telemetry: What is the IP reputation? Is the request originating from a known Tor exit node or commercial VPN? Does the geographic location represent an "impossible travel" anomaly (e.g., logging in from New York, then from Tokyo 20 minutes later)?
4. Behavioral Telemetry (UEBA): Is the user attempting to access resources outside their typical working hours? Is the user downloading 10,000 database records when their historical average is 15?
5. Data Sensitivity: Does the requested resource contain sensitive personal data (PII), cardholder data (PCI), or unreleased financial earnings? Higher sensitivity demands stricter contextual thresholds (e.g., requiring step-up authentication or denying access from non-corporate-managed devices).

---

Zero Trust in Cloud Networks: Microsegmentation & SDP

Traditional cloud deployments placed workloads into public and private subnets inside a Virtual Private Cloud (VPC), relying on basic network access control lists (NACLs) and Security Groups. However, inside a VPC, traditional architectures permitted open east-west traffic between instances. If an attacker compromised a single internet-facing web server, they could pivot laterally across the flat network to internal database clusters.

Zero Trust eliminates this implicit east-west trust through four architectural pillars:

1. Application-Level Microsegmentation

Microsegmentation divides the cloud data center into logical security segments down to individual workload and container boundaries. Unlike network segmentation based on IP subnets (Layer 3/4), modern cloud microsegmentation operates at Layer 7 using software-defined policies. Security policies are bound to application metadata, cryptographic labels, and workload identities, completely independent of IP addressing schemes. Even if two virtual machines share the same private subnet, microsegmentation prevents them from communicating unless an explicit Layer 7 allow rule exists.

2. Workload Identity & Mutual TLS (mTLS)

Zero Trust extends identity beyond human users to encompass services, containers, and serverless functions. Workload identity frameworks—specifically the SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (SPIFFE Runtime Environment) open-source standards—issue cryptographically verifiable identity documents (SVIDs - SPIFFE Verifiable Identity Documents) in the form of short-lived X.509 certificates or JWT tokens.

• Services authenticate each other using Mutual TLS (mTLS): both client and server validate each other's cryptographic certificates during the TLS handshake.
• All traffic in transit within the cloud VPC is fully encrypted, preventing packet sniffing by compromised adjacent nodes or rogue network taps.
• Communication is governed by service mesh proxies (e.g., Envoy in an Istio service mesh) acting as distributed Policy Enforcement Points.

3. Software-Defined Perimeter (SDP)

The Software-Defined Perimeter (SDP), developed by the Cloud Security Alliance, operationalizes Zero Trust for network access. SDP follows a "Need-to-Know" model and enforces the concept of a "Dark Cloud":

• Initiating Host (IH): The client requesting access.
• Accepting Host (AH): The gateway protecting enterprise applications.
• SDP Controller: The central orchestrator (part of the PDP) that authenticates the IH, assesses device posture, and configures the AH.
• Single-Packet Authorization (SPA): The Accepting Host operates with all inbound firewall ports closed (drop-all). It is completely invisible to port scanners on the public internet. To initiate a connection, the IH sends a cryptographically signed Single-Packet Authorization packet to the AH. Only upon cryptographic verification does the AH dynamically open a temporary firewall pinhole specifically for the client's IP address and identity.
• Application-Specific Tunneling: The SDP client never connects to the general network; it connects strictly to the authorized application, eliminating network-level IP discoverability and lateral movement.

---

Real-World Implementation Scenario: Zero Trust in a Hybrid Multi-Cloud Architecture

A global fintech enterprise operates customer-facing microservices on AWS EKS, a legacy core banking ledger in an on-premises data center, and analytics workloads on Google Cloud Platform (GCP). In their legacy setup, corporate users connected via a centralized VPN concentrator, granting broad IP reachability across the entire private subnet range.

The enterprise transitions to a Zero Trust Architecture:

1. Identity & Context: The organization deploys an identity provider integrated with FIDO2 WebAuthn security keys and an endpoint management agent. Device health (disk encryption, OS patch version, CrowdStrike EDR status) is evaluated before access is considered.
2. Network Decoupling via SDP: The corporate VPN concentrators are decommissioned. In their place, an SDP controller and cloud-native gateways (PEPs) are deployed. Remote developers connect to internal code repositories and cloud bastions via mutual TLS tunnels. The bastions present zero listening ports to the public internet, relying on Single-Packet Authorization.
3. Cloud Microsegmentation with Service Mesh: Within AWS EKS and GCP GKE clusters, Istio service meshes are configured with strict mTLS. Every pod receives an ephemeral SPIFFE ID certificate rotated every hour. The payment processing service rejects all incoming connections unless the caller presents a valid X.509 certificate verifying identity as the authenticated checkout service.
4. Dynamic Revocation in Action: During an active session, a developer's workstation triggers a high-severity EDR alert (unauthorized process injection detected). The EDR platform sends an instant webhook event to the Policy Engine. The Policy Administrator commands the PEP to sever the developer's active mTLS sessions within two seconds, quarantining the asset before any intellectual property can be exfiltrated.

---

Common Exam Pitfalls & Anti-Patterns

[!WARNING] Exam Trap: Confusing Network Segmentation with Zero Trust. On the CCSK exam, questions often describe an organization dividing a VPC into subnets using CIDR blocks and standard Security Groups and ask if this constitutes Zero Trust. It does not. Traditional IP-based subnetting relies on network topology and implicit trust within segments. Zero Trust requires continuous identity verification, least-privilege per-session authorization, and device posture checks, independent of network location.

[!IMPORTANT] Exam Distinction: Policy Engine (PE) vs. Policy Administrator (PA) vs. PEP. Remember the NIST SP 800-207 logical demarcations:

• Policy Engine (PE): Makes the decision to grant or deny access.
• Policy Administrator (PA): Issues session credentials and directs the PEP to open/close the connection.
• PE + PA = Policy Decision Point (PDP): Operates strictly in the Control Plane.
• Policy Enforcement Point (PEP): Operates inline in the Data Plane to enforce the decision.

[!TIP] Zero Trust Philosophy: Remember the core mantra: "Never Trust, Always Verify" and "Assume Breach". Any answer choice that suggests trusting an entity because it resides within an internal enterprise network or private cloud VPC is automatically incorrect.