Zero Trust and Segmentation

The perimeter model — a hard firewall around a soft, trusted interior — assumes that being inside the network means you're allowed to be there. That assumption fails the instant one inside host is compromised, because the attacker now sits in the trusted zone and can reach everything the perimeter was protecting. A phished laptop, a vulnerable internal service, one stolen VPN credential, and the castle wall is behind the attacker, not in front of them.

Zero trust replaces "trust by location" with "verify every request and authenticate every workload." There is no trusted interior: a request from inside the data center is checked the same way as one from the public internet. Paired with segmentation and microsegmentation, which carve the network into small zones so a breach can't fan out, the goal is to shrink the blast radius — a compromise becomes one host's problem instead of the whole estate's.

The Perimeter's Failure

The weakness of the castle-and-moat model is the flat interior behind the wall. Once a network treats "inside" as trusted, it tends to leave internal traffic unrestricted — any host can reach any other on any port — because the perimeter was supposed to keep attackers out. The problem is what happens after the perimeter is breached, which it eventually is.

An attacker who lands on one machine then performs lateral movement: hopping host to host across the flat internal network, escalating privilege, reaching the database or the domain controller that was never meant to be exposed but was trivially reachable from inside. Most large breaches are not a single dramatic break-in; they are one foothold followed by weeks of quiet lateral movement that a flat network does nothing to stop.

Zero-Trust Principles

Zero trust rests on a short list of principles. Never trust based on network location — being on the corporate LAN or inside the VPN grants nothing. Authenticate identity on every request, for users and for workloads alike, so a service proves who it is before it talks to another service. Grant least privilege, so an identity can reach only what it specifically needs. And assume breach: design as though an attacker is already inside, because eventually one is.

The shift is from "where is this request coming from" to "who is making it and are they allowed." A request's source IP becomes nearly irrelevant; its verified identity and the policy attached to that identity decide everything. That is what makes a flat-network foothold far less useful — reaching a service is no longer the same as being allowed to use it.

Segmentation and Microsegmentation

Segmentation divides the network into zones — separate VLANs or subnets for production, staging, and corporate, with firewall rules controlling traffic between them. It limits lateral movement to within a zone, which is a large improvement over a single flat network but still leaves whole zones reachable once you're inside one.

Microsegmentation takes it to the workload: policy is enforced per host or per service, so even two machines on the same subnet talk only if a rule explicitly permits it. A web tier that has no business reaching the database directly simply can't, regardless of network adjacency. The cost is management — policy that granular has to be generated and maintained from workload identity and labels, not hand-written, or it becomes unmanageable fast.

# microsegmentation as identity-based policy, not IP rules:
# "the api service may talk to the db service on 5432, nothing else may"
from:     service:api
to:       service:db
ports:    5432/tcp
default:  deny          # every pair not named is denied

Identity-Aware Access

Identity-aware access is zero trust applied to user-facing services. Instead of "VPN in, then you're trusted," each request to an application is authorized at a proxy that checks the user's verified identity, device posture, and the policy for that specific app — Google's BeyondCorp is the canonical model, and IAP-style proxies are its product form. There is no network position to inherit trust from; an employee at a coffee shop and one at a desk go through the identical check.

For workloads, the equivalent mechanism is mTLS: two services each present a certificate and verify the other's identity before exchanging a byte, so a service's right to be called comes from its proven identity, not its IP. Identity-aware access for users and mTLS for services are the two halves of replacing network location with verified identity everywhere.