Security zones and trust boundaries in system design

Zones and boundaries

A security zone collects systems that share a trust level, data sensitivity and set of rules. A trust boundary is any point where data or control passes between zones of different trust. Boundaries are where you place controls, and they are also where threat modelling looks hardest (see threat modelling with STRIDE).

A classic three-tier web application uses the zones above: the internet is untrusted, web servers or reverse proxies sit in a DMZ (demilitarised zone), application servers sit behind them, and databases sit deepest. A separate management zone holds jump hosts, monitoring and backup systems, because compromise there gives control over everything.

Controlling traffic between zones

• Default deny: allow only the specific flows the design needs, documented in a flow matrix.
• Adjacent tiers only: the DMZ may talk to the application tier, but not straight to the database.
• Direction matters: allow connections to start from the more trusted side where possible.
• Inspect at the boundary: firewalls, WAFs, API gateways and proxies enforce and log decisions (see firewall types).
• Admin paths: administration only from the management zone, through a bastion with MFA.

Zones in the cloud and in microservices

The same idea applies in cloud networks using separate VPCs or VNets, subnets, security groups and network security groups. Many organisations put production, development and shared services in separate accounts or subscriptions, which is a strong boundary for identity as well as network. See cloud networking.

Inside a microservice platform, zones shrink to individual workloads. Microsegmentation applies policy to each workload, for example with Kubernetes network policies or a service mesh that only lets the checkout service call payments. This controls east-west traffic, which perimeter firewalls never see (see zero trust segmentation).

Design tips and mistakes

1. Classify data first; zone boundaries should follow data sensitivity.
2. Keep the number of zones manageable; too many becomes unmaintainable.
3. Review firewall rules regularly and remove "any any" exceptions.
4. Remember non-network boundaries: identity, tenant, process and hardware boundaries also separate trust.
5. Log all boundary decisions centrally so you can spot lateral movement.

Tip: a flat network where every server can reach every other is the attacker's favourite. Even a few well-placed zones dramatically limit how far ransomware can spread.