Antyxsoft Cloud Blog

Segmenting a multi-tier application for auditors | Antyxsoft Cloud

Written by Antyxsoft Cloud | Sep 3, 2026, 8:13:21 PM

Segmentation is where security architecture and audit evidence meet, and the two want slightly different things. Security wants the smallest set of paths that lets the application work. An auditor wants to be shown that the boundary exists, that it is enforced by something other than good intentions, and that you would know if it were crossed.

A design that satisfies the second usually satisfies the first. The reverse is not reliably true — plenty of well-segmented networks fail an audit purely on evidence.

Separate by trust boundary, not by component

The instinct is to give every service its own subnet. That produces thirty subnets, a routing table nobody can review, and no clearer boundary than three subnets would have given.

Segment where the trust level actually changes. Anything reachable from the internet is one tier. Anything that processes requests but is never addressed directly from outside is a second. Anything holding data at rest is a third. If you handle regulated data — cardholder data, health records, personal data under a specific obligation — the systems in scope form their own tier, and the point of the exercise is to make that tier as small as you can defend.

Management is the fourth tier people forget. Monitoring collectors, backup proxies, CI runners and jump hosts reach into every other tier by design, which makes them the most privileged machines you own. They belong in their own subnet with their own rules, not scattered across the tiers they administer.

Deny by default, and mean it

The boundary is only real if the last rule in every ACL is deny all. Everything above it is an explicit, reviewable exception: source range, destination range, protocol, port, and a reason.

Two habits make the rule set defensible. Reference ranges rather than individual addresses, so replacing an instance does not require a rule change and nobody is tempted to widen a rule to make a deployment work. And control egress, not just ingress: the data tier having no route out is what turns a compromised database into a contained incident rather than an exfiltration. Auditors increasingly ask about outbound paths precisely because most teams have not thought about them.

Where the platform lets you apply policy at the network layer rather than per machine, use it. A rule set attached to the VPC governs every instance in it, including the one someone launches next Tuesday without reading the runbook — which is the difference between a control and a convention.

What to log, and for how long

Two log sources carry most of the evidentiary weight. Flow logs at the segment boundary show what actually crossed, which is the only way to prove that the design and the traffic agree. Administrative logs for network changes show who altered a rule and when — a segmentation design with no change history is a snapshot, not a control.

Ninety days of flow logs is a common baseline; a year is safer where the obligation is specific. Ship both to storage the network team cannot silently delete, and treat that separation of duties as part of the control rather than an afterthought.

Then actually look at them once a month. Every allowed rule should have matching traffic. A rule with no traffic in ninety days is either dead — remove it — or protecting something nobody knew was there.

The document that ends the conversation

Four artefacts, kept current, answer most segmentation questions before they are asked.

A network diagram showing tiers, their address ranges, and every permitted path between them, with the ports labelled. A rule table exported from the live configuration rather than hand-written, so it cannot drift from reality. A scope statement naming which systems are in the regulated tier and why the others are out. And a change log for the network policy itself.

Generate the rule table from the platform on the day you are asked. A hand-maintained copy is the artefact most likely to be wrong, and being caught with a stale one costs more credibility than a slightly awkward rule.

Verify the boundary, do not assert it

The strongest evidence is a test. From a machine in the application tier, try to reach a port in the data tier that policy forbids, and keep the output. From the public tier, try to reach the database directly. From outside, try to reach anything but the load balancer. Do it quarterly, and after any significant network change.

That test is also how you find the shortcut someone added during an incident and never removed — the single most common reason a segmentation design that was correct in March fails in October.

The short version

Segment at trust boundaries — public, application, data, management — and keep the regulated tier as small as you can defend. Deny by default in both directions, write rules against ranges, and apply policy at the network layer so new machines inherit it. Keep flow logs and network change logs somewhere the network team cannot erase, review allowed rules against real traffic monthly, and prove the boundary with a quarterly reachability test rather than a diagram.

Antyxsoft VPC gives you isolated networks, custom subnets and ACLs applied network-wide, with documented policy you can export — see how VPC works.