Zero Trust Network Architecture

• Tue, Jul 23, 2024
• 6-minute read

Most zero-trust programs deliver an identity-aware HTTP proxy in front of web services and call the rest of the work done. The deck is clean. The vocabulary is right. Database, message queue, internal RPC, and service-to-service traffic look the same as before the program started, and the audit narrative leaves that part unspoken.

The principle is sound. The implementations vary wildly in how much of the principle they preserve. Most projects branded as zero trust deliver something more modest, and the discipline of naming what was delivered is what separates the program that matures into real architecture from the one that stays a marketing artifact.

Figure 1. The principle and the four shapes most projects deliver. Each is useful. None of them, alone, is zero trust. The honest map shows the delivered work and the gap to the principle, not a relabeling of the delivered work.

The four properties

Zero trust has four properties, and a program either preserves them or doesn’t. Network location confers no implicit trust: the IP address inside the corporate VPN doesn’t grant access to anything by itself, and being inside the network is not authorization. Every access decision is authenticated at the identity level and logged in a form that supports real audit, not one that satisfies an auditor for a quarter.

The unit of policy is the identity-resource pair, not the network segment. “User X can access resource Y” replaces “anything in this subnet can talk to anything in that subnet,” and that granularity is what makes the rest of the model work. The fourth property is the one most programs stop short of: verification is continuous, not just at session start. A token issued at login that grants access for eight hours is a perimeter assumption with extra steps. The model assumes session compromise is possible and re-evaluates trust as sessions continue.

What programs usually deliver

Four shapes show up most often. All are useful in their own right. None of them is zero trust on its own:

The pattern I see most often is a textbook version of all four at once. The HTTP proxy is real. The perimeter improves. SSO gets consolidated. VPN gets retired. The interior is unchanged. The audit narrative is zero trust. The gap is the work nobody scoped.

The architectural decisions

Identity provider as the single source of truth. Most organizations have three: the SSO provider, the cloud IAM, and the directory. Reconciling them is years of work. The team that says “we have one IdP” usually means “we standardized our SSO,” and the cloud IAM and directory are still managing identities the SSO doesn’t see. The slow divergence of identity sources is a kind of access debt, and zero-trust programs that don’t address it inherit it.

Policy enforcement points: where they live, who owns them, how they coordinate. The HTTP proxy is one PEP. Cloud IAM is another. The database authentication layer is a third. The service mesh, if you have one, is a fourth. A program without a coherent answer for how policy flows across these ends up with conflicting decisions and no precedence rule:

Figure 2. One identity provider, four enforcement points, each covering a different traffic type. The HTTP proxy is typically the only PEP most programs implement. The others require separate answers.

The non-HTTP problem. Databases, message queues, internal RPC, service-to-service traffic, batch jobs. Each requires its own answer. “We did mTLS” is a partial answer to one slice: mTLS handles authentication between services. It doesn’t handle authorization, and it doesn’t handle the policy lifecycle. Here’s what the authorization layer looks like once mTLS establishes identity:

# Service-to-service: mTLS proves identity; this policy checks permission
package service_authz

default allow = false

allow {
    input.source.service_account != ""
    data.service_permissions[input.source.service_account][input.destination.service]
    time.now_ns() < input.credentials.expiry_ns
}

The break-glass model. How legitimate emergencies bypass policy without bypassing audit. Most programs handle this badly. If there’s no clean audited path for emergencies, incident response will create one informally. The informal path is the one that compromises the audit story later.

The compliance dimension

Zero trust as an audit narrative versus zero trust as an operating model. The audit version is easier to produce and easier to defend in a single quarter. The first time an auditor asks “show me the policy decisions for service-to-service traffic on Tuesday at 3pm,” the difference becomes visible.

NIST 800-207 and similar frameworks allow a wide range of implementations to claim conformance. An organization can satisfy the framework with a strong identity-aware proxy and an aspirational roadmap for the rest. The framework doesn’t catch this. This is one of the places compliance can substitute for security thinking without anyone in the room noticing.

I don’t have a clean answer for how to close the gap between the compliance timeline and the operational timeline inside a single budget cycle. The honest version is that it usually takes a leadership transition or an incident to bring them back into alignment.

The honest path

Incremental zero trust as a multi-year program, not a project. Measured in fewer trust assumptions, not more product purchases. The useful metric is “what trust assumption did we eliminate this quarter.” A program that can’t name one bought tools and didn’t change architecture.

A SaaS company I worked with, one handling sensitive customer data that had just come through a compliance audit surfacing gaps in their interior access model, scoped a multi-year program and prioritized admin access and customer data paths in year one. Service-to-service mTLS went to later years. The scoping was honest. The audit narrative was modest in year one and stronger in year three. That’s the shape of a program that survives.

Audit your program against the four properties at the start of this piece. If three of them aren’t true for your environment, the program is a marketing artifact. The work to make them true is years of effort, not a vendor procurement. The teams that name that timeline up front are the ones whose programs survive the third leadership transition. The teams that don’t are the ones whose programs become the case study somebody else writes.

Related Posts

• Infrastructure security architecture patterns
• The security posture question most organizations ask too late
• When compliance becomes a substitute for security thinking
• IAM sprawl is access debt
• The architectural decisions hidden in a Dockerfile