SLO and Error Budget Service  ·  View 19 of 21  ·  Assurance

Security Trust Zones

Five zones, and a deliberate asymmetry between reading and changing.

Editable source SVG draw.io All views
Internet — untrusted Engineer Release gate Replayed verdict Perimeter Front Door TLS, WAF API Management quota, throttle Entra ID verification workload federation Read zone — broad access Verdict API Budget query API tenant-scoped Budget projection Privilege zone — four named grants Role check author ǀ approve ǀ grant ǀ read Privileged API Separation of duties author ≠ approver Key Vault HSM signing key, non-exportable Evidence zone — no update path Window snapshots WORM Audit ledger tamper-evident HTTPS workload token verify authenticated claims authorise second approver prior value valid_until rejects Security — Trust Zones and What Crosses Them Person or role External / third party Risk / gap Interface / broker Security / platform Data store Decision point synchronous failure / alternate Five zones, and the asymmetry is the point: reading a verdict is deliberately easy, and the two privileges that can make a breached objective appear met — approving an exclusion and granting an override — sit behind separation of duties and an append-only record. A verdict carries a validity period precisely because a signed document is otherwise replayable forever. The verdict API's read of the projection is drawn in view 08. v 1.0 · owner Reliability Architecture · date 2026-10

Decisions

  • Reading a verdict is deliberately easy and organisation-wide. The two privileges that can make a breached objective appear met sit behind separation of duties and an append-only record (ADR-11).
  • The verdict carries a validity period because a signed document is otherwise replayable forever — the replayed-verdict risk in the untrusted zone is rejected on valid_until, not on signature (ADR-12).
  • The signing key is non-exportable in a managed HSM. The platform can be compromised without the ability to mint a verdict that survives verification elsewhere.

Assumptions

  • Four independently assignable privileges: author a definition, approve an exclusion, grant an override, read budget state — assumed as the minimum viable split.
  • A second approver is required for an exclusion beyond 60 minutes — assumed threshold.
  • SLI aggregates carry no personal data, enforced by rejecting definitions whose label dimensions would introduce user identifiers.

Risks

  • Two colluding approvers defeat the entire exclusion control. Nothing in this architecture detects collusion; the override register and exclusion-minutes metric make it visible after the fact, which is the accepted residual.
  • The query API is tenant-scoped on a shared aggregate store, so authorisation is a per-request decision on every read. A scoping bug leaks another team's unpublished attainment.
◀  SLO Lifecycle All views Identity and Privilege Flow  ▶
Solution Architecture v1.0 · Microsoft Azure · Reliability Architecture · 2026-10 · 21 views · 17 architecture decision records19-security-trust-zones