Segmentation: make every connection earn its place

A hotel key should open your room, not every room and the maintenance office. A network needs similarly intentional boundaries, while still allowing the services people actually use.

Segmentation: Restricting communication between parts of a system according to their purpose and sensitivity.

Draw flows before rules

Start with a service: a public web tier needs to reach an application tier, which needs particular database operations. Write the initiator, destination, protocol, purpose, and owner for each required flow. Include management, monitoring, backups, and name resolution so the design remains usable.

A broad rule that allows every internal system to contact every other system makes a network label carry too much trust. Segment according to function and sensitivity, then document justified exceptions.

Reachability is only one gate

A firewall or network policy can limit which connections are possible. It does not inherently know whether a particular customer may read a particular invoice. The application still needs identity, authorization, and input handling.

Zero trust is an architecture approach that avoids granting implicit trust just because a request originates on an internal network. It is not a product you purchase or a promise that no trust exists. Decisions need relevant identity, device, resource, and context information.

Make the boundary observable

A useful boundary reduces the set of systems affected when one system fails or is compromised. Its value depends on actual enforcement, not a diagram of colored boxes. Shared administration and unrestricted exceptions may bridge otherwise separated areas.

Validate required and denied flows with approved synthetic checks in your own environment. Watch for unexpected denials and attempted cross-boundary communication. Review exceptions after migrations and retire rules when their services disappear.

Worked design review: the forgotten backup path

Assume a fictional booking service with Web, Application, Database, Backup, and Management components. The names identify roles; they do not establish trust. The supplied exercise records describe logical service connections, with supporting name resolution and return traffic already accounted for. No customer-data authorization test is included.

• S1, required flows: Web calls Application; Application reads and writes booking records in Database; Backup obtains the approved recovery dataset. The service owner requires all three workflows.
• S2, observed outcomes: Web-to-Application and Application-to-Database work. Web-to-Database is denied as intended. Backup-to-Database is also denied, so the required backup workflow fails.
• S3, management: One shared administrator can change traffic policy in every zone. No independent review or narrower administrative roles are documented.
• S4, exception proposal: “Allow internal maintenance” identifies a purpose, but has no named owner, bounded endpoints, or expiry condition. It has not been approved.

PredictThe diagram shows three well-separated service tiers. Is the proposed design ready because the direct Web-to-Database connection is denied?

No. That denial is useful evidence, but S2 also blocks a required recovery dependency. S3 describes authority that crosses all zones, and S4 is an incomplete proposal. A correct boundary must support justified work as well as restrict unjustified reach.

Build a correction with two kinds of verification

For S2, propose the precise Backup-to-Database flow required by S1, with its service identity, purpose and owner recorded. The implementation team must choose the actual protocol and enforcement mechanism; this packet does not supply them. “Backup” as a friendly name is not enough to trust an arbitrary requester.

The verification plan should establish that the intended backup workflow works and that the Web-to-Database denial remains. Confirm application permissions separately, because an allowed connection does not establish access to every booking. Include relevant failure behavior and the monitoring record that would reveal an unexpected policy change.

For S3, review who may alter policy, approve exceptions, and recover management access. Shared administration can be an explicit operating choice, but it must not be mistaken for independent boundaries. For S4, ask for narrow scope, an accountable owner and an end condition before approval.

Model deliverable: a flow matrix with “required,” “observed,” and “pending” columns, plus a separate management row. Keep the hotel-key analogy limited: network access opens a communication path; the application still decides what work the caller may perform.

EXPLORE THE CONCEPT

Which boundary is missing?

Explore a fictional three-tier service.

The web tier reaches only the application

This narrows network reachability. The application must still verify the caller and requested action.

Every tier shares one administrator

A shared management path can cross the segmentation boundary. Review privileged access alongside network rules.

A temporary broad rule never expires

The exception can become the real policy. Give exceptions owners and review dates.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

A good diagram includes both the intended connections and who can change the rules. Management paths are part of the architecture.