Zero Trust & Access Governance

What Zero Trust Actually Means

The traditional security model trusts everything inside the corporate network. If you can reach the VPN, you can reach internal services. Zero trust flips this: nothing is trusted by default, regardless of where the request originates. Every request must carry proof of identity, and access decisions are made per-request based on identity, device posture, and context.

Google published the BeyondCorp papers in 2014 describing how they eliminated their corporate VPN entirely. Every internal service authenticates requests individually. An engineer's laptop on coffee shop WiFi gets the same access as one plugged into the office network, because the network does not determine trust. Identity does.

This is not a product you buy. It is an architecture pattern you adopt incrementally. Start with your most sensitive services, add identity-aware access controls, and expand from there.

Access Control Models

Choosing the right access control model depends on how complex your permission requirements are.

RBAC (Role-Based Access Control) - Users are assigned roles, roles have permissions. Simple to understand, easy to audit. Works well when you have a small, stable set of roles. Breaks down when you hit role explosion: "engineer-team-alpha-readonly-staging" multiplied across dozens of teams and environments. If your role list exceeds 100 entries, RBAC is getting unwieldy.

ABAC (Attribute-Based Access Control) - Access decisions based on attributes of the user, the resource, the action, and the environment. "Allow if user.department == resource.department AND user.clearance >= resource.classification AND time.hour is between 9 and 17." Extremely flexible, but policies are hard to write, hard to test, and hard to debug when access is denied unexpectedly.

ReBAC (Relationship-Based Access Control) - Access decisions based on relationships between entities. "User X can edit Document Y because X is a member of Team Z, and Team Z owns Folder W, which contains Document Y." This is the Google Zanzibar model, implemented by open-source projects like SpiceDB and Ory Keto. It handles hierarchical and shared permission models cleanly. The learning curve is steeper than RBAC, but the model scales better for products with complex sharing semantics (think Google Docs, Notion, or Figma).

Most organizations start with RBAC, hit the complexity wall, and either move to ABAC for infrastructure access or ReBAC for product-level permissions. You do not need to pick one model for everything.

Least Privilege Engineering

Least privilege is the principle that every identity (human or machine) should have only the permissions it needs, for only as long as it needs them.

Just-in-time (JIT) access - Instead of granting permanent admin access, engineers request elevated permissions when they need them. The request goes through an approval workflow (or auto-approves for low-risk requests), grants access for a fixed window (1 hour, 4 hours, 1 day), and revokes automatically. Tools like Teleport, ConductorOne, and Opal handle this.

Break-glass procedures - For genuine emergencies where the approval workflow is too slow. A pre-authorized mechanism grants immediate elevated access but triggers high-priority alerts and requires a post-incident review. The point is not to block emergency access, but to make sure it is visible and auditable.

Credential rotation - All credentials should have expiration dates. Database passwords, API keys, service account tokens: none of them should last forever. Short-lived credentials (hours, not months) dramatically reduce the blast radius of credential theft.

Access reviews - Quarterly reviews where managers verify that their team members still need the access they have. Automate the data collection: pull IAM roles, database grants, and SaaS app permissions into a review dashboard. The reviewer's job is to confirm or revoke, not to manually inventory.

Identity-Aware Proxies

An identity-aware proxy sits in front of your applications and authenticates every request before it reaches the application. The application never sees unauthenticated traffic.

Google IAP - Built into GCP. Protects App Engine, GKE, and Compute Engine applications. Authenticates via Google identity, injects verified identity headers into requests. Free if you are already on GCP.

Cloudflare Access - Works with any origin, not just Cloudflare-hosted apps. Supports multiple identity providers. Can protect internal dashboards, admin tools, and APIs without a VPN.

Pomerium - Open-source identity-aware proxy. Self-hosted, works with any identity provider. Good choice if you want to avoid vendor lock-in or need to run it in your own infrastructure.

The pattern is the same for all of them: external users authenticate via SSO, the proxy verifies the token, and the request is forwarded with identity context. Internal services trust the proxy's identity headers instead of managing their own authentication. This eliminates an entire class of auth bugs in individual applications.

Service-to-Service Authentication

Humans are not the only identities in your system. Services call other services, and those calls need authentication too.

mTLS (mutual TLS) - Both the client and server present certificates during the TLS handshake. Each service proves its identity cryptographically. Service meshes like Istio and Linkerd handle mTLS transparently. Your application code does not change; the sidecar proxy handles certificate exchange.

SPIFFE/SPIRE - SPIFFE (Secure Production Identity Framework for Everyone) defines a standard for workload identity. SPIRE is the reference implementation. Every workload gets a short-lived X.509 certificate (SVID) that identifies it. Certificates rotate automatically, typically every hour. No static secrets, no manual key management.

The key benefit is eliminating shared secrets. Instead of Service A calling Service B with an API key stored in environment variables (which gets copied to config files, logged accidentally, and never rotated), Service A presents a cryptographic identity that is verified in real time and expires within hours.

Access Review Automation

Access reviews are a requirement for SOC 2, ISO 27001, and most enterprise security programs. Manual reviews are tedious and error-prone. Automate the pipeline:

1. Collect - Pull access data from IAM providers (Okta, Azure AD, Google Workspace), cloud providers (AWS IAM, GCP IAM), databases (PostgreSQL roles, MongoDB users), and SaaS applications (via SCIM or API).
2. Correlate - Match access grants to the employee directory. Flag accounts that do not map to a current employee (orphaned accounts), accounts with access that does not match their role, and accounts that have not been used in 90+ days.
3. Review - Present flagged items to the appropriate reviewer (manager, system owner). Make it easy: a dashboard with approve/revoke buttons, not a spreadsheet.
4. Enforce - Revocations should take effect immediately, not wait for someone to log into the IAM console. Integrate with your identity provider's SCIM provisioning or write direct API calls.
5. Evidence - Store the review records with timestamps, reviewer identity, and decisions made. This is your audit evidence for SOC 2 and ISO 27001.