Zero Trust Architecture

Tags

Zero Trust Architecture

Zero Trust Architecture (ZTA) is a security model defined by NIST SP 800-207 that eliminates implicit trust based on network location — every access request is verified continuously against identity, device posture, and request context, regardless of whether the request originates inside or outside the network perimeter.

Core Idea

Traditional perimeter security grants implicit trust to anything inside the network boundary — once past the firewall, lateral movement is largely unrestricted. ZTA inverts this assumption: network location grants zero trust. Every request — from any origin — is treated as potentially hostile until verified. Access is granted only after continuous evaluation of three trust signals: who is requesting (identity), from what device (device posture), and for what purpose (workload context).

NIST SP 800-207 (2020) is the defining specification for ZTA. It establishes a reference architecture with four control planes and a central policy engine that all interact to produce access decisions.

When NOT to Use

  • Do not adopt ZTA as a big-bang migration of an existing perimeter network. ZTA is an architectural target, not a product you deploy in a sprint. Incremental adoption — starting with the identity plane — is the recommended approach.
  • Do not apply microsegmentation to non-networked, single-process batch jobs with no lateral movement exposure. The overhead of mutual authentication per process boundary is not justified.
  • Service-mesh mTLS (see Service-Mesh-Pattern) enforces the network plane of ZTA but does not cover the identity, device, or workload planes. Deploying a service mesh is not equivalent to adopting ZTA.
  • Do not treat ZTA as a compliance checkbox. ZTA requires ongoing maintenance of device inventories, identity stores, and policy definitions — a stale device inventory defeats the device plane entirely.

How It Works — NIST SP 800-207 Control Planes

NIST SP 800-207 defines a ZTA reference architecture with four control planes and a central policy engine:

Identity Plane

Every subject (user, service account, workload) has a verifiable identity. Authentication is continuous — not just at login. Tokens are short-lived (see JWT and OAuth2-OIDC-Flows). Identity is the primary trust signal. Multi-factor authentication is required for human subjects. Federated identity (OIDC) allows the IdP to remain the authoritative source of user identity across services without each service managing credentials independently.

Device Plane

Device posture is evaluated at access time. A valid user identity is insufficient if the device is unmanaged, missing patches, or showing anomalous behavior. Device attestation (TPM, MDM enrollment status, certificate binding) provides the device trust signal. The device plane answers: "Is this device in a state we trust?" — separately from whether the user on that device is authenticated.

Network Plane

Network location grants no trust. All traffic is encrypted (TLS 1.3 or mTLS). Microsegmentation enforces least-privilege connectivity — a workload can reach only the specific endpoints required by its function, not the entire network segment. East-west traffic (workload-to-workload) is inspected and controlled identically to north-south traffic (user-to-workload). This prevents lateral movement after an initial compromise.

Workload Plane

Workloads (containers, VMs, functions) have verifiable identities (SPIFFE SVIDs, cloud IAM roles). Workload identity drives secrets access policies (see Secrets-Management) and service-to-service authorization. The workload plane answers: "Is this service authorized to perform this operation?" — independently of any human user identity.

Policy Engine (PE) and Policy Administrator (PA)

The PE evaluates access requests against policy and the data store (identity records, device state, threat intelligence). The PA translates PE decisions into configuration for the policy enforcement points (PEP). PEPs are the inline enforcement components — API gateways, sidecar proxies, identity-aware proxies.

This separation is mandatory: collapsing PE and PEP produces an enforcement point that cannot be independently reasoned about. The PE is the decision-making brain; the PA is the configuration broker; the PEP is the traffic-inline enforcer. They have distinct failure modes and distinct audit trails.

sequenceDiagram
    participant Sub as Subject (User / Workload)
    participant PEP as Policy Enforcement Point
    participant PA as Policy Administrator
    participant PE as Policy Engine
    participant DS as Data Store (IdP, CMDB, Threat Intel)

    Sub->>PEP: Access request
    PEP->>PA: Forward request + context
    PA->>PE: Evaluate policy
    PE->>DS: Query identity, device posture, threat signals
    DS-->>PE: Trust signals
    PE-->>PA: ALLOW / DENY
    PA-->>PEP: Configure enforcement decision
    PEP-->>Sub: Grant or deny access

See Zero-Trust-Architecture-diagram for the zone topology showing how the four control planes surround the PE/PA core.

Microsegmentation

Microsegmentation divides the network into fine-grained segments with independent access control policies. Unlike VLANs (which segment at layer 2), microsegmentation operates at the workload or process level. Each workload has an explicit allowlist of inbound and outbound connections. East-west traffic (workload-to-workload) is inspected and controlled identically to north-south traffic (user-to-workload). This prevents lateral movement after an initial compromise.

Microsegmentation is enforced by the network plane PEPs — sidecar proxies (in a service mesh) or host-based firewalls with workload-aware rules. The rules are derived from policy: the PE decides which workloads may communicate; the PA pushes those rules to the PEPs.

Scope Boundaries

This note covers the ZTA model at the pattern level. SPIFFE/SPIRE configuration, service mesh deployment topology, and cloud-specific IAM policy syntax are implementation details outside this note's scope. For service mesh network plane enforcement, see Service-Mesh-Pattern. For secrets access controlled by workload identity, see Secrets-Management.

TypeScript Example

Skeletal identity-aware access check — a middleware function that validates a JWT identity claim and device context claim before forwarding a request, implementing the identity plane and device plane checks at the PEP layer:

import { jwtVerify } from 'jose';
 
interface ZeroTrustContext {
  identityToken: string;
  devicePosture: 'managed' | 'unmanaged' | 'unknown';
}
 
async function enforceZeroTrust(
  ctx: ZeroTrustContext,
  publicKey: CryptoKey
): Promise<boolean> {
  // Identity plane: verify JWT — signature before claims (see [[JWT]])
  const { payload } = await jwtVerify(ctx.identityToken, publicKey, {
    issuer: 'https://idp.example.com',
    audience: 'https://api.example.com',
  });
 
  // Device plane: reject unmanaged devices regardless of identity
  if (ctx.devicePosture === 'unmanaged') {
    return false;
  }
 
  // Workload plane: check required scope claim
  const scopes = (payload.scope as string ?? '').split(' ');
  return scopes.includes('resource:read');
}

Java Example

Spring Security 6.x method security expression checking both identity and a custom device-posture claim from the JWT — the @PreAuthorize SpEL expression enforces the identity plane (scope check) and device plane (device_posture claim) simultaneously at the PEP:

import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.security.core.annotation.AuthenticationPrincipal;
import org.springframework.security.oauth2.jwt.Jwt;
import org.springframework.stereotype.Service;
 
@Service
public class ResourceService {
 
    // Zero Trust: identity verified by Spring Security JWT decoder
    // Device plane claim checked via SpEL expression
    @PreAuthorize(
        "hasAuthority('SCOPE_resource:read') and " +
        "#jwt.claims['device_posture'] == 'managed'"
    )
    public Resource getResource(
        @AuthenticationPrincipal Jwt jwt,
        String resourceId
    ) {
        // PE granted access: proceed
        return resourceRepository.findById(resourceId).orElseThrow();
    }
}
  • Service-Mesh-Pattern — mTLS enforces the network plane of ZTA; service mesh is one PEP implementation
  • Secrets-Management — workload identity drives secrets access policies in the workload plane
  • OAuth2-OIDC-Flows — identity plane relies on OAuth2/OIDC for federated identity and short-lived tokens
  • JWT — short-lived JWT tokens are the primary credential in the identity plane
  • RBAC-ABAC — policy engine decisions are implemented as RBAC/ABAC authorization rules
  • API-Key-Authentication — API keys can serve as workload identity signals in the workload plane

(Leave as placeholder — backlinks added in Phase 40 sweep)

Linked mentions