Data perimeters and secure zones

Why this matters

Lesson twenty segmented the network. This lesson draws a boundary around the data, which is a different exercise with a different enforcement mechanism, and in a cloud estate it is the more useful of the two.

The reason is the threat lesson nineteen named: the movement that matters is frequently not into your network from outside but out of your accounts to somewhere else at the same provider. That traffic never crosses a network perimeter, because both ends are inside the provider's network. A network control cannot see it. What stops it is a boundary expressed in terms of which identities may access which resources, enforced by the platform's authorisation layer rather than by its network layer.

The second half of the lesson is the secure zone — an enclave for data whose classification justifies substantially stronger isolation. The examinable judgement there is scope: an enclave large enough to be convenient is an enclave too large to defend.

The lesson

A data perimeter as a boundary on identities and resources rather than on IP addresses

A data perimeter is a set of guardrails asserting three things continuously, and they are worth stating as three separate claims because they fail separately:

• Only trusted identities may access my resources. A resource policy that admits any principal — a wildcard, or an over-broad account condition — admits an attacker's principal at the same provider. Closing this means every resource policy naming the organisation as the boundary.
• My identities may only access trusted resources. This is the one people omit and it is the one that stops exfiltration. A compromised workload with legitimate credentials copying data to an attacker-controlled store at the same provider is using an allowed action on an unallowed destination.
• My identities and resources may only be reached over expected networks. Private endpoints and network conditions on identity policy, so a credential stolen from your estate cannot be used from outside it.

Those three together are qualitatively different from a firewall rule, because they are evaluated by the authorisation layer on every API call regardless of network path. A request from inside your own network to an attacker's storage account is denied by the second claim; a request from an attacker's laptop using your stolen key is denied by the third.

Two implementation notes scenarios probe. The perimeter is enforced at both ends — resource policies and identity policies — because each covers the other's gap, and estates that implement only resource policies have the exfiltration direction wide open. And the perimeter needs explicit exceptions for legitimate external interaction, which must be enumerated rather than handled by weakening the general rule: a named partner account, a specific public dataset, a specific integration.

The examinable contrast to carry: a network perimeter asks where the packet came from; a data perimeter asks who is asking and for what. In an estate where everything is an API call to a shared platform, only the second question has a reliable answer.

Building a zone: what enters, what leaves, what is logged, what is denied by default

A secure zone is a bounded environment with a deliberately small and enumerated interface. Building one is a design exercise with four questions, and answering all four is what distinguishes a zone from a subnet with a nice name.

What enters? Every ingress path, named: which identities, from which networks, through which mechanism, for what purpose. The default is deny, and each entry is an explicit, owned, reviewable exception. Administrative access is a separate question from application access and usually needs a stricter path — brokered through a bastion or privileged access workstation, with session recording.

What leaves? The direction most designs neglect, and the one that matters for confidentiality. Egress from a high-classification zone should be denied by default and permitted only to enumerated destinations. That includes the things that do not feel like data movement: software updates, telemetry, package downloads, DNS resolution. Each is a channel out, and each is a documented exception with a control.

What is logged? Everything crossing the boundary in either direction, plus all administrative activity inside, shipped outside the zone to a destination the zone's own administrators cannot alter. That separation is the point: logs held inside the zone are modifiable by anyone who compromises it.

What is denied by default? Stated explicitly, because a zone whose default is permit is a zone in name only. Default deny on ingress, egress, and east-west inside the zone.

Two further properties worth designing in. The zone should be rebuildable from code, so its configuration is reviewable and its drift detectable — the infrastructure-as-code advantage from lesson fourteen applied where it matters most. And the zone's controls should not depend on the general estate's controls, because a zone protected by the same identity provider, the same management tooling and the same administrators as everything else shares everything else's compromise.

Enclaves for regulated data, and keeping the enclave small enough to defend

An enclave is the strongest form of the zone, used where a classification or an obligation justifies substantially higher cost. Its defining constraint is scope, and scope is where enclaves fail.

The pressure is always toward growth. A system just outside needs the data, so it is brought inside. A team needs a tool, so the tool is installed. A reporting requirement needs an extract, so a pipeline is added. Each step is individually reasonable and each enlarges the thing you are defending, until the enclave contains a substantial fraction of the estate and carries enclave-level cost with general-estate-level assurance.

The disciplines that hold the line:

• Define scope by data, not by team or system. The enclave contains the regulated data and the minimum processing required. A system that merely uses results belongs outside, receiving aggregated or tokenised output.
• Push transformation to the boundary. Tokenisation, masking and aggregation at the edge mean downstream systems never need to be inside — which is the same scope-reduction logic that lesson eleven applied to the payment standard, and it is the single most effective technique here.
• Enumerate and review the population. Everything inside is listed, owned and justified, and reviewed on a cycle. Growth without review is how the boundary dissolves.
• Make entry costly and exit easy. If adding a system to the enclave requires a documented justification and an approval, and removing one does not, the population trends downward instead of upward.

The examinable framing: a smaller enclave with stronger controls beats a larger one with the same budget, because assurance is per-system and cost is roughly linear in population. A scenario describing an enclave that has grown to include most of the estate is describing a failure of scope discipline, and the remedy is transformation at the boundary rather than more controls inside.

Cross-zone data movement: brokered transfer, one-way paths and approval

Data must sometimes leave a zone, and the transfer mechanism is where the boundary is either upheld or quietly bypassed.

Mechanisms, in increasing strength:

• Direct network connectivity with policy. The transfer is an ordinary connection subject to the zone's egress rules. Simplest, and the weakest, because anything that can open the connection can move arbitrary data.
• Brokered transfer. A service in the boundary mediates: it receives from one side, inspects, classifies, applies policy, and delivers to the other. Nothing on either side has direct connectivity. This is where content inspection, classification checks and volume limits are applied, and it is the mechanism most scenarios expect.
• One-way transfer. Data can move in one direction only, enforced by a mechanism with no reverse channel. Appropriate where the classification justifies it — logs and telemetry leaving a high-assurance zone is the natural fit, since a one-way path cannot be used to reach back in.
• Approved manual transfer. Human authorisation per transfer, with a record of what, when and by whom. Slow, and the right answer where volume is low and consequence is high.

Design points that recur. Transfer is a control point, not just a pipe — it is where classification is checked, volume anomalies are detected, and the record for audit is created. Both directions need separate consideration; inbound transfer carries the risk of introducing untrusted content and code into the zone, which is the supply-chain path into an otherwise isolated environment. And every transfer is logged with its content classification, because the aggregate of transfers is the real answer to what has left the zone.

The failure scenario to recognise: a zone with excellent ingress control, a brokered transfer path used for the designed flow, and a second route — a backup, an analytics pipeline, a monitoring agent's outbound channel — that moves data out without passing the broker. The boundary is the weakest path out of it, and the paths nobody designed are the ones not being inspected.

Proving a perimeter holds, rather than asserting it in a diagram

The closing discipline of the objective, and it is the one that separates a perimeter from a drawing of one.

A boundary described in a document, implemented in policy, and never tested is an assertion. It can be wrong from the day it is built — a policy that does not do what its author believed — or it can become wrong through drift, and neither condition announces itself. The estate looks the same either way.

What proving it looks like:

• Test the denies. Attempt the actions the perimeter is supposed to prevent — write to an external account, reach the resource from an unexpected network, assume a role from outside the organisation — from inside, deliberately, and confirm each is refused. A control that has never been observed refusing anything has never been observed working. This is precisely the canary discipline this library applies to every check it writes, and the reasoning is identical: a green result from an instrument nobody proved can go red is not evidence.
• Enumerate from the platform, not from the design. List every resource policy, every trust relationship, every egress route by API and compare against the intended model. The difference is the finding, and it will exist.
• Test continuously, because a boundary is a property of a configuration that changes daily. A quarterly penetration test proves the perimeter held on one day.
• Alert on boundary changes specifically — a new trust relationship, a widened resource policy, a new egress route — routed to the owner rather than into a report.

And record the result as evidence with an age, for lesson nineteen's reason: a perimeter proven six months ago is a historical fact, not a current control. The pairing to carry out of domain 2 is that a boundary needs both an enforcement mechanism and a continuous demonstration that the mechanism is doing what it was built to do — and of the two, estates reliably build the first and reliably skip the second.