Zero Trust Architecture: BeyondCorp, ZTNA, Microsegmentation & Continuous Verification - Cybersecurity Hub

← Back to Home Zero Trust Architecture: BeyondCorp, ZTNA, Microsegmentation & Continuous Verification Table of Contents Introduction: Beyond the Perimeter Google BeyondCorp: The Pioneer ZTNA Implementation Patterns Device Trust & Posture Continuous Verification Advanced Microsegmentation Service Mesh: Zero Trust at Workload Level Conclusion Introduction: Beyond the Perimeter Zero Trust, codified in NIST SP 800-207, is not a product—it's an architectural philosophy: never trust, always verify. No implicit trust based on network location. Every access decision is evaluated explicitly for identity, device, context, and risk. This guide goes deep into Zero Trust architectures from Google's pioneering BeyondCorp to modern ZTNA platforms, microsegmentation strategies, device trust implementations, and the operational practice of continuous verification. Google BeyondCorp: The Pioneer BeyondCorp is Google's implementation of Zero Trust, deployed internally since 2014 and documented in a series of papers. It replaced VPN with identity-based application access. Key BeyondCorp Principles No network-based trust: Inside/outside network distinction gone Identity + Device: Both must be verified, not just one Continuous: Trust level continuously re-evaluated Least privilege: Access scoped to application, not network Policy-driven: Centralized policy, distributed enforcement BeyondCorp Architecture # BeyondCorp Components: # 1. User Identity - federated SSO, MFA # 2. Device Inventory - Asset DB, MDM enrollment # 3. Device Trust - posture, compliance, certificates # 4. Trust Broker - central policy evaluation # 5. Access Proxy - enforces decisions # 6. Policy Engine - rules combining signals # Request flow: # 1. User authenticates to IdP # 2. Device certificate verified (managed device?) # 3. Device posture checked (compliant?) # 4. Trust broker evaluates: User + Device + App + Context # 5. Decision: Permit / Deny / Step-up # 6. Access proxy: routes if permitted, blocks if denied # 7. Session: continuously re-evaluated BeyondCorp Access Tiers # Trust levels drive access # # Trust Tier 1: Public services # - No auth required (marketing site) # - No device trust required # # Trust Tier 2: Basic corporate # - User authenticated # - Device: ANY (managed or BYO) # - MFA optional # # Trust Tier 3: Internal apps # - User authenticated + MFA # - Device: Managed, up-to-date # - Continuous verification # # Trust Tier 4: Sensitive # - User authenticated + MFA + approval # - Device: Managed, fully compliant # - Workload-restricted (e.g., specific subnet) # - Session recording for audit # # Trust Tier 5: Crown jewels (admin, prod) # - Tier 4 + JIT (just-in-time) elevation # - Device must be from known IP/device history # - Additional periodic re-auth # - Full session recording + alerting BeyondCorp Papers - Essential Reading BeyondCorp: A New Approach to Enterprise Security BeyondCorp: Design to Deployment at Google BeyondCorp: Real-World Access Management BeyondCorp: Maintaining Productivity in the Era of Mobile & Cloud Migrating to BeyondCorp: Maintaining Productivity ZTNA Implementation Patterns ZTNA vs. VPN Comparison Capability VPN ZTNA Access granularity Network segment Application/resources Trust model Implicit (network = trust) Explicit (per-request) Lateral movement Allowed (full network) Prevented (app isolation) Authentication Once at connect time Continuous during session Device posture Rarely checked Always evaluated Performance Tunneled traffic (overhead) Direct encrypted session Visibility Network flows App-level audit trail Remote user experience Clunky, reconnects Seamless, app-aware ZTNA Architecture Patterns 1. Client-Initiated (Agent-based) # Pattern: Agent on device -> ZTNA broker -> App connector # # Used by: Cloudflare Access (with Warp), Zscaler Private Access, Tailscale, Twingate # # Pros: # - Device posture can be deeply assessed # - Identity tied to specific device # - Works for non-web protocols (SSH, RDP, DB) # # Cons: # - Requires agent on user device (IT overhead) # - Deployment can be tricky for BYO # Example: Twingate architecture # 1. Remote network deployed (connectors in your VPC) # 2. Client installed on user device # 3. User authenticates via SSO (Okta, Azure, Google) # 4. Client connects to Twingate service # 5. Service routes to connectors based on policy # 6. Connector accesses internal resource # Resource access definition: resource "twingate_resource" "internal_app" { name = "internal-app" address = "10.0.1.100" remote_network_id = "rn-123456" access { security_policy_id = sp-prod_users } } 2. Service-Initiated (Agentless) # Pattern: Reverse proxy + OIDC/SAML; no agent on user device # # Used by: Cloudflare Access (browser), Pomerium, OAuth2-Proxy, Google IAP # # Pros: # - No agent deployment on user devices # - Works great for HTTP/HTTPS apps # - Easier BYO device support # # Cons: # - Limited to HTTP/HTTPS (no SSH/RDP/DB) # - Less device posture info (rely on IdP) # Example: Pomerium architecture (open source) # 1. Pomerium proxy in front of apps # 2. User accesses app.example.com (Pomerium FQDN) # 3. Redirected to IdP (Okta, Google, Azure) # 4. IdP issues session # 5. Pomerium validates JWT, evaluates policy # 6. Request proxied to internal app # 7. App receives authenticated headers (x-pomerium-claim-...) # Pomerium config example # services: # authenticate: # url: https://auth.example.com # proxy: # url: https://app.example.com # policy: # - from: https://grafana.example.com # to: http://grafana-internal:3000 # allowed_groups: ["devops@company.com"] # cors_allow_preflight: true 3. Browser Isolation # Pattern: User accesses via remote browser, no data on endpoint # # Used by: Cloudflare Browser Isolation, Menlo Security, Light Point # # Pros: # - Endpoint never touches corporate data # - No malware risk from web browsing # - Works on unmanaged devices # # Cons: # - Performance (rendered remotely, streamed) # - UX challenges (copy-paste, file transfer) # - Higher cost Policies for ZTNA # Example: Cloudflare Access policies # 1. Allow developers to staging { "name": "Developers to Staging", "decision": "allow", "email": ["developers@company.com"], "device_posture": ["device-os-windows-10-or-11", "edr-running"], "ip": ["10.0.0.0/8"] } # 2. Require approval for production { "name": "Prod requires approval", "decision": "bypass", // proceed to approval step "email": ["sres@company.com"], "require_approval": true, "approver": ["manager-on-call@company.com"] } # 3. Block high-risk users { "name": "Block risk", "decision": "deny", "user_risk_score": "high" } Device Trust & Posture Zero Trust requires knowing the device making each request, not just who is using it. Device Inventory & Identity # 1. Enroll devices in MDM/UEM # - Microsoft Intune / Endpoint Manager # - Jamf Pro (Mac) # - Workspace ONE (VMware) # - Google Android Management / Chrome Enterprise # # 2. Issue device certificates # - SCEP / NDES cert enrollment # - Or use platform-native (Apple Configurator, AD CS auto- enroll) # # 3. Inventory metadata: # - Serial number # - User assignee # - OS + version # - Encrypted? # - EDR running? # - Patch age? # - Compliance state # - Geolocation (where applicable) # - Last check-in Device Posture Signals Signal Source Sample Risk Decision OS version MDM Out of date -> require update Disk encryption MDM Not encrypted -> deny access to sensitive EDR running EDR API EDR off -> deny; investigate Screen lock MDM No screen lock -> deny Jailbreak/root MDM/EDR Rooted -> deny all access Patch age MDM > 30 days -> warn; > 60 -> deny Cert validity Pki/MDM Expired -> auto-rotate, deny during gap MDM enrollment MDM Unmanaged -> tier 2 only Avg risk score EDR High -> ask for MFA Continuous Device Posture # Device posture must be re-evaluated continuously # Example: Microsoft Intune + Conditional Access # Conditional Access: Block access if device not compliant { "conditions": { "devices": { "deviceFilter": { "mode": "include", "rule": "device.isCompliant -eq False" } } }, "grantControls": { "operator": "OR", "builtInControls": ["block"] } } # Flow: # 1. User logs in (every 1h for refresh token; every 8-24h for full re-auth) # 2. Conditional Access evaluates device compliance (from Intune) # 3. If compliant -> allow # 4. If non-compliant -> block, route to Intune remediation # 5. User remediates, admin re-checks # For real-time posture: # - Some ZTNA platforms poll posture every minute # - Some use webhooks from MDM/EDR # - Beware: true real-time is hard; posture often has minute-lag Continuous Verification Trust isn't a one-time check at login. It must be continuously re-evaluated throughout the session. Session Re-evaluation Signals # Signals monitored during session: # - User behavior (anomalous resource access?) # - Device posture change (compliance -> non-compliance) # - Network change (corporate wifi -> public wifi) # - Risk events (impossible travel, EDR alert) # - Time elapsed since last full auth # Response actions when risk changes: # - Re-auth (MFA challenge) # - Step-up (additional verification) # - Restrict (limit to read-only) # - Terminate (kill session immediately) Risk-Based Adaptive Access # Example risk scoring recipe: def evaluate_risk(request): score = 0 # Device posture if request.device.compliant: score += 0 else: score += 30 # Network risk if request.network.trusted: score += 0 else: score += 20 # Impossible travel if user.last_location != request.location: if travel_impossible(user.last_seen, request.time): score += 30 # Recent alerts on user if recent_alerts(request.user): score += 20 # Time of day if business_hours(request.time): score += 0 else: score += 10 # EDR risk if request.device.edr_risk_score > 70: score += 40 if score < 30: return "allow" elif score < 70: return "step_up_auth" else: return "deny" Advanced Microsegmentation This section explores implementation options and advanced strategies for microsegmentation, building on the network security article's introduction. Microsegmentation Implementation Paths Approach Where Pros Cons Host-based agents On each server Granular, identity-aware, OS signals Agent needed everywhere; cost Network-level (NSX-T) Hypervisor No agents on workloads VMware-centric Kubernetes native (Cilium, Calico, Istio) K8s Declarative, API-driven K8s only Service mesh (Istio, Linkerd) L7 Proxy Workload identity, mTLS, authz Overhead, complexity Cloud-native Cloud provider Easy in-cloud; security groups, VPC service controls Cloud only; multi-cloud hard Hybrid Multiple Best coverage Operational complexity Cilium / eBPF-Based Enforcement # Cilium uses eBPF - kernel-level enforcement, no agents in user space # CiliumNetworkPolicy for east-west traffic apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: order-to-payment namespace: production spec: endpointSelector: matchLabels: app: order-service egress: - toEndpoints: - matchLabels: app: payment-service toPorts: - ports: - port: "8080" protocol: TCP rules: http: - method: "POST" path: "/api/v1/charge" - toEndpoints: - matchLabels: k8s:io.kubernetes.pod.namespace: kube-system k8s-app: kube-dns toPorts: - ports: - port: "53" protocol: ANY # Deny all other egress (default deny) # Cilium defaults to deny when CiliumNetworkPolicy is in place Istio AuthorizationPolicy (Mesh-wide) # Apply mesh-wide: require mTLS + specific identities apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default-mtls namespace: istio-system spec: mtls: mode: STRICT # All mesh traffic must use mTLS --- # SPIFFE-based workload identities # Each pod gets SPIFFE ID: spiffe://cluster.local/ns/production/sa/payment apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: payment-service-authz namespace: production spec: selector: matchLabels: app: payment-service rules: - from: - source: principals: ["cluster.local/ns/production/sa/order-service"] to: - operation: methods: ["POST"] paths: ["/api/v1/charge", "/api/v1/refund"] - from: - source: principals: ["cluster.local/ns/monitoring/sa/prometheus"] to: - operation: methods: ["GET"] paths: ["/metrics", "/healthz"] Illumio / Guardicore (Host-based) # Host-based microsegmentation (bare-metal or VM) # Pros: works outside K8s; identity-driven # Cons: requires agent # Architecture: # - Agent on each server # - Central policy engine (controller) # - Real-time visibility of connections # - Enforcement: OS firewall + eBPF (Linux) or WFP (Windows) # Policy model: # 1. Map: agent discovers connections (monitor mode) # 2. Define: security team defines allowed flows # 3. Test: policy runs in "alert" mode (log only) # 4. Enforce: policy blocks violations # 5. Maintain: drift detection, policy updates # Example policy: # Environment: Production # Application: Payment # Role: API # Allow from [Production/Payment/Web] to [tcp:8080] (HTTPS) Service Mesh: Zero Trust at Workload Level Service Mesh Capabilities for Zero Trust Identity: SPIFFE-based workload identity (no IP-based trust) mTLS: All mesh traffic encrypted by default Authorization: L7 policy enforcement Observability: L7 traces, metrics, access logs Resilience: Retries, timeouts, circuit breaking Istio mTLS # PeerAuthentication - mTLS mode # Permissive (allows both plain and mTLS, for migration) apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: PERMISSIVE # STRICT (mTLS required) apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: production spec: mtls: mode: STRICT # DISABLE (no mTLS, e.g., for browser client) # Use only on specific ports Workload Identity (SPIFFE) # SPIRE - SPIFFE Runtime Environment # Issues X.509 SVIDs (SPIFFE Verifiable Identity Documents) to workloads # SVID format: # CN: spiffe://cluster.local/ns/production/sa/payment-service # Bundle trust: cluster.local CA # Workload registration # spire-server entry create \ # -spiffeID spiffe://cluster.local/ns/production/sa/payment-service \ # -parentID spiffe://cluster.local/k8s/workload-registrar \ # -selector k8s:ns:production \ # -selector k8s:sa:payment-service # Workload gets SVID, presents to peers # Peer validates against bundle, makes authz decision Service Mesh Comparison Mesh Stage mTLS Authz L