Zero Trust and Defense in Depth

BeyondCorp, the death of the perimeter, and how SREs implement defense in depth.

Overview

From "trust the network" to Zero Trust

Zero Trust is the security model that replaced "trust the network." It originated as Google's BeyondCorp (2014) and is now the mainstream approach.

> [!IMPORTANT] Zero Trust means every request is authenticated and authorized on its own merits. Being "inside" grants nothing.

Why the perimeter model failed

Inside the corporate network = trusted, outside = untrusted — A network compromise via phishing or a stolen laptop gives full implicit trust
Firewall at the perimeter — Multi-cloud, SaaS and BYOD make "inside" meaningless
VPN to "get inside" — Trusted insiders abuse privileges
Lateral movement is the dominant attack pattern, and the perimeter does not stop it

Zero Trust principles

These are the common framing of NIST SP 800-207.

1. Verify explicitly — Every request authenticated and authorized
2. Least-privilege access — Just-in-time, just-enough access
3. Assume breach — Design for adversaries already inside

BeyondCorp, Google's implementation

Device identity — Every laptop and phone has a hardware-rooted certificate
User identity — SSO with strong MFA
Access tiers — Services tagged by sensitivity; only a matching device and user tier gets in
No VPN — Anyone can reach the proxy from anywhere; the proxy denies by policy

The components

1. Strong identity for users and devices — Phishing-resistant MFA, FIDO2 or hardware keys preferred; device certificates issued at provisioning and renewed regularly
2. Identity-aware proxy — In front of every service; authenticates user and device on every request; Google Cloud IAP, AWS Verified Access, Cloudflare Access
3. Microsegmentation — Each service trusts only its specific callers, not "all internal"; Istio or Linkerd enforce it with mTLS and policy
4. Continuous verification — Trust re-evaluated per request, not just at session start; behavioral anomalies trigger re-auth

Defense in depth

Zero Trust is one layer. Defense in depth is the broader principle: several independent layers, each catching different attacks and each assuming the previous one might fail.

An attacker through the firewall meets application auth; through that, data encryption; even with data in hand, audit and detection.

The SRE's role

Service mesh — mTLS and policy
Identity-aware proxies — IAP, AWS Verified Access configuration
Audit logging — Design
Rate limiting — Implementation
Network policies — Kubernetes NetworkPolicy, security groups

Pragmatic rules and common mistakes

Default deny: traffic only when explicitly allowed — Network segmentation as the only layer, when cloud workloads cross networks easily
Encrypt by default: TLS everywhere, mTLS between services — Long-lived service credentials, which are perimeter trust for service-to-service
Audit everything, immutably — Audit logs stored in the system being audited, where attackers can delete them
Rate-limit per user, IP and endpoint
MFA for all human access; cert-based auth for service accounts — VPN-only auth, since VPN credentials get compromised
Verify devices, not just users — User identity alone is insufficient

> [!TIP] BSRS frames it as one design pattern: Zero Trust plus defense in depth plus least privilege plus blast radius reduction. SREs internalize it even when "security" is not their title.

Key concepts

Zero Trust: Verify explicitly; least privilege; assume breach. NIST SP 800-207. Replaces perimeter security.
BeyondCorp: Google's 2014 implementation. Device certs + SSO + identity-aware proxy + no VPN.
Identity-aware proxy: Sits in front of every service; authenticates user + device per request. IAP, Verified Access, Cloudflare Access.
Microsegmentation: Each service trusts only specific callers, not "internal." mTLS + service mesh policy.
Defense in depth: Multiple independent layers; each catches different attacks. Network + app + data + identity + detection.
Default deny: Services reject traffic unless explicitly allowed. Inverts the "default allow within network" of perimeter.

When to use it

Designing access for new services — Zero Trust by default
Migrating from VPN-based access — BeyondCorp pattern
Cross-cloud / SaaS environments — perimeter doesn't exist; Zero Trust is mandatory
Reviewing existing systems — where are perimeter assumptions still in place?

Interview questions

Walk me through implementing Zero Trust for an internal service.
How does service mesh fit into Zero Trust?
What's "least privilege" in practice for cloud IAM?