sydepsystem design atlas

Zero-Trust Access

Verify every request explicitly; nothing is trusted by network location alone.

AdvancedSecurityPlatform
ClientClientIdentity ProviderSecurity & IdentityPolicy-enforcing GatewayNetworkingAuthorization ServiceSecurity & IdentityServiceCompute

Every request is authenticated and authorized at each hop -- via strong identity, short-lived certificates and policy checks -- regardless of whether it originates inside or outside the network perimeter.

When to use it

  • Perimeter-only security has proven insufficient (lateral movement risk, remote/hybrid access)
  • Compliance requires explicit authorization and audit at every service boundary

Trade-offs

  • Every hop now needs identity issuance, verification and policy evaluation, adding latency and complexity
  • Requires strong identity and certificate infrastructure to be reliable, or everything breaks at once

Components used

Mobile AppIdentity ProviderAPI GatewayAuthorization ServiceManaged App Service

How it works

  • Every request is authenticated and authorised regardless of origin. Being inside the network grants nothing.
  • A policy enforcement point checks identity, device posture and context before proxying to the resource.
  • Access is least-privilege and short-lived, so a stolen credential has limited scope and a short useful life.

Used in the wild

  • Remote workforces where the VPN perimeter no longer corresponds to anything meaningful.
  • Contractor and third-party access scoped to individual applications rather than the network.
  • Regulated environments needing per-request audit trails.

Good to know

  • Forrester's John Kindervag coined the term in 2010; Google's BeyondCorp, built after the 2009 Aurora breach, is the best-known large-scale implementation.
  • The classic castle-and-moat model fails because once an attacker is inside, lateral movement is unrestricted. Most large breaches are a small initial foothold plus unimpeded lateral movement.