System Design Cases
Zero Trust Architecture
Zero Trust Architecture concept page. "Never trust, always verify." BeyondCorp-style identity-aware proxy with device posture + MFA, microsegmentation via service mesh (sidecar PEP + SPIFFE mTLS), and contrast vs legacy VPN castle-and-moat. 3 scenarios: BeyondCorp access flow, microsegment allow/deny, Colonial Pipeline–style breach blocked by ZT. ADR on adoption strategy (BeyondCorp vs Cloudflare Access vs Tailscale vs Zscaler).
Zero trust architecture: per-resource policy and continuous evidence
Zero trust removes implicit trust based on network location or ownership. Subjects, devices, and workloads obtain resource-specific access through policy decision and enforcement points using current identity, posture, and threat evidence.
Security invariants
- ZT-C1: Zero trust grants no implicit trust based solely on physical or network location, ownership, or affiliation.
- ZT-C2: Access is resource-specific and mediated by a policy decision point and policy enforcement point before the session reaches the resource.
- ZT-C3: Policy uses current identity, device or workload posture, resource, action, environment, and threat evidence.
- ZT-C4: Cloud-native zero trust uses application and service identities plus application-level enforcement, not only IP segmentation.
- ZT-C5: Grants are least-privilege, resource and action scoped, and time bounded rather than broad network admission.
- ZT-C6: A required policy dependency outage fails closed or follows an explicit narrow continuity policy; it never silently creates implicit trust.
Trust-boundary map
| Component | Responsibility |
|---|---|
user | User |
device | Device and Client |
identity-provider | Identity Evidence |
policy-enforcement | Policy Enforcement Point |
policy-decision | Policy Engine and Administrator |
posture-service | Device and Workload Posture |
telemetry | Telemetry and Threat Signals |
resource | Protected Enterprise Resource |
workload | Calling Service Workload |
service-enforcement | Service Policy Enforcement |
data | Resource Data |
Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.
Executable scenarios
per-resource-decision — Evaluate every resource request
Access is granted to a specific resource and action after identity, device, policy, and risk evidence are evaluated at the enforcement point.
network-location-is-not-trust — Network location does not grant access
Being on a corporate subnet or VPN supplies context but never bypasses authentication and resource authorization.
posture-change — Respond to a posture change
Device or workload state is dynamic evidence. A newly noncompliant device loses or narrows subsequent access without treating the prior session as permanent trust.
service-to-service — Apply zero trust to workloads
A service identity reaches another service through an application-level enforcement point; network reachability alone grants no method permission.
least-privilege-session — Limit authority and duration
A grant is scoped to the minimum resource, action, and duration; it does not become broad lateral network access.
policy-service-outage — Policy outage fails closed
The enforcement point does not interpret an unavailable policy decision as allow; explicitly designed low-risk continuity policies remain narrow and auditable.
continuous-reevaluation — Reevaluate on new threat evidence
Telemetry does not magically inspect every packet, but material risk changes can trigger a new decision, session restriction, or reauthentication.
Operational and failure rules
- Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
- Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
- Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
- Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.