Design Network Segmentation Around Real Traffic

Putting web servers and databases in different subnets makes a diagram tidier. It reduces risk only when the traffic policy between them enforces a useful boundary. Start with one question: what should a compromised frontend still be unable to reach?

Describe a flow precisely

For each necessary connection, record the initiating workload, destination, protocol, port and purpose. A web service may need its database on a specific port. It probably does not need unrestricted access to every database, hypervisor console and backup repository. Include DNS, time synchronization, monitoring and deployment traffic; otherwise a broad emergency exception often follows the first outage.

Observe normal traffic over a representative period, including scheduled jobs. Observation suggests candidates for an allow list. It does not prove every observed connection is authorized.

Test both sides of the rule

In staging, allow the frontend to reach its own database endpoint. Verify the normal transaction succeeds. Then verify that the same workload cannot reach a management endpoint or another tenant's database. Test with the workload identity and actual route, not from an administrator's laptop. Check IPv6, alternate interfaces and egress paths where applicable.

A firewall rule controls reachability. Database authentication and application authorization still decide what an allowed connection can do. A trusted subnet should not become a substitute for either.

Roll out without losing the recovery path

Stage rules in small groups. Keep a separately tested management path, record the policy version and define how to revert it. Review denied traffic around deployment and backup windows. The objective is a smaller, explainable set of reachable services that still supports the work people depend on.

Further reading

NIST SP 800-207: Zero Trust Architecture

Related guide: How to Verify an Access Control Fix in Staging.