2 Network Segmentation
Learn how to design network zones around purpose and risk, enforce narrow traffic boundaries, and test whether segmentation supports necessary work while limiting unnecessary access.
What accomplishes
divides an environment into zones and controls traffic between them. It limits which systems can communicate, helping contain a compromised device and reduce an attacker’s opportunities for .
Segmentation supports security, but it does not replace authentication, patching, endpoint protection, or monitoring. Network location is one policy signal, not proof that a user or device is trustworthy; access to resources should be authorized explicitly.
Design zones around purpose and risk
Group systems by similar purpose and security requirements, rather than merely by building or department. Begin by listing important systems, users, data, and the communications they need.
Typical zones include:
User zone: employee workstations and managed mobile devices.
Application zone: web and application servers.
Data zone: databases and other sensitive data stores.
: public-facing services that must accept connections from outside.
Management zone: administrative workstations and interfaces used to manage infrastructure.
Guest zone: untrusted visitor devices isolated from internal resources.
High-impact systems, such as backups or industrial control equipment, may need a more restrictive zone of their own.
Plan and enforce boundaries
Assign each zone a distinct or another clearly enforceable boundary. In a small network, an organization might reserve separate private address ranges for users, applications, data, management, and a . The exact addresses matter less than documenting each range, its purpose, its owner, and its routing and enforcement points.
A alone is not a security boundary: if a router freely forwards traffic between subnets, systems may still communicate. Enforce boundaries with network firewalls, router access-control lists, host firewalls, cloud security controls, or suitable combinations. can apply policy to individual workloads or services for more precise controls.
Write narrow traffic policies
For every required flow, specify its source, destination, service or protocol, direction, and business reason. Permit only necessary traffic and deny other inter-zone traffic by default. Avoid broad rules such as “users can reach all servers” or “all internal networks can communicate.” Review and remove rules that are no longer needed.
Illustrative rules include:
Internet → web service: allow HTTPS for public website access.
web service → application service: allow the required application port because the website depends on the application tier.
Application service → database: allow the required database port because the application reads and writes data.
User zone → database: deny any service because users access data through the application.
Guest zone → internal zones: deny any service because guest devices do not need internal access.
Management workstation → managed devices: allow approved administrative services for authorized administration.
These are illustrative rules, not universal port recommendations. Verify actual application dependencies before deployment. Restrict outbound traffic where practical, too, because unrestricted egress can let compromised systems communicate with external services. Log and monitor important boundary traffic, especially unexpected connections to sensitive zones.
Design and test a small network
For a company with a public website, an internal application, a customer database, employee laptops, guest Wi-Fi, and administrator workstations, a design and test process is:
Assign each asset group to a zone and .
List the communications the website and application actually require.
Write allow rules for those flows, plus necessary management access.
Deny guest access to internal zones and employee-laptop access directly to the database.
Identify where traffic will be enforced and logged.
Test both permitted and prohibited flows, including whether one compromised user device can freely reach other zones.
A sound design allows required business functions while making unnecessary paths fail. If a rule is hard to justify, investigate whether it is needed before allowing it.
Review the design principles
Design zones around function and risk, assign clear boundaries, and enforce those boundaries with traffic controls. Use narrow, documented allow rules and between zones. Test intended paths and monitor traffic so segmentation limits exposure and without disrupting necessary work.