4 Network Segmentation and Isolation

Why segment and isolate networks

Network segmentation divides an environment into smaller security zones and controls the traffic that crosses their boundaries. Isolation limits which systems can communicate, reducing paths an attacker could use if an account, workload, or device is compromised. Segmentation can also help contain mistakes and outages.

A network boundary does not make every system inside it trustworthy. A zero-trust design does not grant access solely because a system is on a particular network; it evaluates and authorizes access to each resource. Network boundaries remain useful when combined with identity-based controls and enforcement close to the resource.

Design security zones

Design security zones according to the sensitivity and purpose of their resources and the access those resources require—not simply their physical location or IP range. A common application environment might use these zones:

• Ingress zone: Public-facing load balancers or gateways.

• Application zone: Services that handle application requests.

• Data zone: Databases and other stores containing sensitive information.

• Management zone: Administrative tools and management interfaces, accessible only to authorized operators.

These are example boundaries, not a required layout. A cloud environment can implement zones using separate networks or subnets, routing controls, workload-level firewalls, or combinations of these. Further segmentation can isolate particularly sensitive workloads or separate environments such as production and development.

Set explicit traffic policies

For each zone boundary, specify the allowed source, destination, service or port, direction, and reason. Use a Deny by default approach: permit only documented, necessary flows. Broad rules such as “allow all traffic from the internal network” weaken containment and make unintended access harder to detect.

A simple policy might allow these flows:

• Internet to ingress gateway: HTTPS, to receive public requests.

• Ingress gateway to application service: the required application port, to forward approved requests.

• Application service to database: the required database port, to read or write application data.

• Management host to application and database systems: approved administrative protocols, for authorized operations.

Other flows are denied unless separately justified. The application service should not need direct inbound access from the internet, and the database should not be reachable from the public-facing zone. Restrict outbound traffic as well: workloads should contact only required services, such as approved APIs, DNS resolvers, or update repositories.

Control service-to-service access

Control service-to-service communication at multiple levels. Network rules can limit which workloads reach a destination, while application-aware controls can verify a caller’s service identity and authorize a specific operation. In cloud-native and multi-cloud systems, identity-based policies enforced by gateways or service-mesh proxies can provide finer-grained control than IP-address rules alone.

Use authenticated, encrypted connections where appropriate. Give individual services distinct identities and permissions instead of sharing credentials. A request should be allowed because the service is authenticated and authorized for the resource, not merely because the services share a subnet. Keep permissions narrow; for example, a reporting service might be allowed to read selected records without permission to modify them.

Choose enforcement points

Choose enforcement points that can control the intended boundary, using the controls available in the environment:

• Network or subnet controls regulate traffic crossing larger boundaries.

• Workload-level rules restrict connections to individual machines, containers, or services.

• Gateways and proxies can authenticate and authorize application requests.

• Host and application controls add protection if network rules are misconfigured or traffic does not cross the expected boundary.

Cloud controls can behave differently. For example, AWS security groups are stateful, while Network access control lists are stateless and therefore require explicit rules for return traffic. Understand a provider’s rule evaluation and enforcement scope before relying on a control.

Validate and maintain the design

Document approved flows, their owners, and their business purposes. Compare observed network traffic with the intended policy, then remove obsolete or overly broad rules. Where practical, log both permitted and denied connections, monitor for unexpected paths, and periodically test that boundaries work as intended.

Changes to an application, cloud route, or shared service can create new paths. Review segmentation policies on an ongoing basis as the environment changes.