Zero Trust Architecture
Never trust, always verify: zero trust principles, microsegmentation, service identity, mutual TLS, and implementing zero trust incrementally.
The Problem with Perimeter Security
Traditional security was built on the castle-and-moat model: build a strong perimeter (firewall, VPN), and trust everything inside. This model has catastrophically failed in the modern threat landscape. Attackers increasingly compromise users through phishing and social engineering, gaining legitimate credentials to enter the 'castle.' Once inside, the flat internal network gives them free lateral movement to reach crown jewel systems. The 2020 SolarWinds breach and 2021 Colonial Pipeline ransomware attack both exploited this model's weakness.
Zero Trust Architecture (ZTA) — popularized by John Kindervag at Forrester Research in 2010 and adopted by Google (BeyondCorp), Microsoft, and mandated by the US government (Executive Order 14028) — replaces the perimeter model with a philosophy: 'Never trust, always verify.' Network location grants no implicit trust. Every request, from any location, must be authenticated, authorized, and validated.
Google BeyondCorp: Zero Trust in Production
Google's BeyondCorp program, rolled out between 2011 and 2017, moved all Google employee access to the public internet with per-request identity verification. Employees use no VPN — their Chromebook's device certificate and Google account are verified on every request. This is the most famous real-world Zero Trust implementation at scale.
The Three Pillars of Zero Trust
- Verify Explicitly: Authenticate and authorize every request using all available signals: user identity (strong MFA), device health (is the device managed and compliant?), location (is the IP suspicious?), and time (is this an unusual access time for this user?).
- Use Least Privilege Access: Grant just enough access for just long enough. Use JIT (Just-In-Time) access for privileged operations. Prefer scoped credentials over wildcard permissions. Expire access automatically.
- Assume Breach: Architect as if the attacker is already inside. Segment the network. Encrypt all traffic, including east-west (internal service-to-service). Log everything. Detect anomalies. Limit blast radius.
Microsegmentation
Microsegmentation is the Zero Trust answer to flat internal networks. Instead of all services being able to talk to all other services (because 'they're all internal'), you define explicit, fine-grained network policies: the `orders-service` can make requests to the `inventory-service` and the `orders-db`, but not to the `payments-db` or `auth-service`. Policies are enforced at the workload level, not the network perimeter level.
Microsegmentation is implemented via network policies (Kubernetes NetworkPolicy, AWS Security Groups, GCP VPC Firewall Rules) and/or a service mesh (Istio, Linkerd, Consul Connect) that enforces mTLS-based identity policies at the sidecar proxy layer. The service mesh approach is particularly powerful because it doesn't depend on network topology — it works even when services run on the same host.
Service Identity: SPIFFE and SPIRE
In a Zero Trust model, services need cryptographic identities that are unforgeable and automatically rotated. SPIFFE (Secure Production Identity Framework For Everyone) is a CNCF standard that defines a URI-based workload identity format: `spiffe://trust-domain/namespace/workload-name`. SPIRE is the reference implementation that issues short-lived X.509 SVIDs (SPIFFE Verifiable Identity Documents) to each workload based on platform attestation (Kubernetes service account, cloud IAM role, etc.).
Zero Trust for User Access: BeyondCorp-Style
Implementing Zero Trust Incrementally
Zero Trust is a journey, not a product you buy. You cannot migrate a mature organization to Zero Trust overnight. Implement incrementally based on risk:
- Inventory: Catalog all users, devices, services, and data. You cannot protect what you cannot see.
- Strong Identity: Deploy SSO, enforce MFA for all users, especially admins. This alone eliminates the majority of breach risk.
- Device Trust: Enroll devices in MDM (Intune, Jamf). Verify device compliance on each access request.
- Least Privilege: Audit and reduce over-permissioned service accounts. Implement JIT access for privileged operations (e.g., AWS IAM Roles Anywhere, HashiCorp Boundary).
- Network Segmentation: Implement security groups and network policies to limit lateral movement. Start with the most sensitive services.
- mTLS for Internal Services: Deploy a service mesh. Encrypt and authenticate all east-west traffic.
- Continuous Monitoring: Deploy a SIEM. Alert on anomalous access patterns. Assume breach and actively hunt for lateral movement.
| Maturity Level | Controls | Example Tools |
|---|---|---|
| Level 1: Traditional | VPN, firewall perimeter, password auth | Cisco VPN, on-prem AD |
| Level 2: Basic ZT | SSO + MFA, basic IAM policies | Okta, AWS IAM, Google Workspace |
| Level 3: Advanced ZT | Device trust, network segmentation, SIEM | Intune, AWS Security Hub, Splunk |
| Level 4: Optimal ZT | mTLS everywhere, continuous validation, JIT access | Istio, SPIRE, HashiCorp Boundary |
Zero Trust Is an Architecture, Not a Product
Vendors market 'Zero Trust' products, but Zero Trust is a philosophy and architectural approach. No single product implements Zero Trust. A complete ZTA requires controls across identity (IdP), devices (MDM/EDR), network (microsegmentation/service mesh), applications (per-request authz), and data (classification/DLP). Evaluate vendors by which pillar they address, not by the marketing label.
Interview Tip
If Zero Trust comes up in a system design interview, structure your answer around the three pillars: verify explicitly, use least privilege, assume breach. Describe how mTLS (via a service mesh like Istio) provides service identity and encrypts internal traffic. Explain microsegmentation for limiting blast radius. Mention that Zero Trust replaces the VPN model — devices on any network get the same level of scrutiny. This demonstrates architectural thinking beyond just 'use HTTPS.'