Least privilege, defense in depth, and Zero Trust boundaries

Scoping access: resource, action, and time window

When avionics contractor Dax Mercer needs to upload calibration logs for thruster module bay-03 during Friday’s four-hour maintenance window at Meridian Space & Robotics (chronos.orbital), a lazy access model grants Dax permanent ReadWriteAdmin across the entire chronos-prod storage account. Six months later, if Dax’s laptop is compromised, the attacker inherits standing write access to every satellite’s flight tables.

Under the principle of Least Privilege, Staff Infrastructure Engineer Kael Cho scopes the grant across four explicit dimensions: Subject (dax.mercer@chronos.orbital), Resource (s3://chronos-telemetry/bay-03/calibration/*), Action (PutObject only, no DeleteObject or ListAllMyBuckets), and Time (a Just-In-Time grant that automatically expires at 20:00 UTC Friday). The role denies export.

Defense in depth: why independent layers matter

Defense in depth means placing multiple independent controls in the path of an attack so that if one mechanism fails (due to a code bug, misconfiguration, or stolen credential), the next layer still stops the adversary. Independence is the key word: checking the same password twice on two screens is repetition, not layering.

True layering combines different control classes across boundaries: a network firewall restricts which workload subnets can open a TCP socket, an identity-aware proxy verifies an mTLS workload certificate and a short-lived OIDC token, the application checks fine-grained object ownership, and the database encrypts columns with a key stored in a separate Hardware Security Module (HSM).

Two trust boundaries: Gateway, Internal Room, and Records Store

Examine how the interactive architecture model divides the system into distinct zones: the perimeter Gateway, the Internal Room where application workloads run, and the high-sensitivity Records Store holding mission telemetry. In a naive flat design, passing the Gateway puts a caller inside one giant Internal Room where the Records Store sits wide open.

In Meridian’s layered design, crossing the Gateway into the Internal Room is only the first boundary. A second, independent trust boundary guards the Records Store itself: even a process running inside the Internal Room must present a scoped service identity and pass a dedicated policy gate before reading or writing records. That way, an SSRF bug or compromised web worker in the Internal Room cannot dump the Records Store.

• VPN membership is not authorization to data.
• Workload identity (mTLS or SPIFFE) and resource-scoped authorization must still be verified at the Records Store gate.

Zero Trust is an architecture, not a SKU

As NIST SP 800-207 makes clear, Zero Trust Architecture (ZTA) is not a single box you buy from a vendor. It is the architectural commitment that network location alone (such as "the packet came from our office subnet") never grants trust. Every request is evaluated dynamically by a Policy Decision Point (PDP) and enforced by a Policy Enforcement Point (PEP) using identity, device health, and least-privilege resource policy.