Trust boundaries and threat model · Lesson 2

Define protect surfaces and access paths

7 min read

Lesson objectives

  • Derive a bounded protect surface and enforceable, testable access policies from a flow map.

A protect surface is a bounded set of valuable resources and operations whose access will be controlled; it is not a synonym for the entire enterprise environment. Select a workflow with clear impact and measurable legitimate and illegitimate requests. The surface could include a claims document API, its storage path and the service identities that serve it. Putting every corporate asset into the first migration makes it hard to distinguish effects of the new policy from old inventory defects. Reducing the surface to an API IP address may leave a background job or service account uncontrolled. Define the resource, operation, actor and permitted outcome, then link each to the flows inventoried in the preceding lesson.

Create an access matrix with a row for each use case rather than relying on broad role names. Columns are requester identity, device type or workload identity, resource, action, business purpose, contextual condition, decision, enforcement point and result log. For example, a claims analyst may read only a document for an assigned claim after recent strong authentication; an aggregation service reads selected fields of closed claims to produce statistics; a support account cannot read claim documents. The “assigned to” relationship must come from a trusted work system, not a client-supplied request field. State how fresh that attribute must be and how a decision changes when a claim moves to another analyst.

Separate decision and enforcement. A policy decision point evaluates attributes against policy; a policy enforcement point actually blocks or passes an operation on its execution path. A decision shown in a central console is ineffective if an old application route still reaches the object store directly. Enumerate all entry routes: public API, batch job, administration console, maintenance interface and backup. Register existing exceptions with an owner and expiry. Do not delete a break-glass account before testing recovery; make its use narrow, approved, logged and alerted. Specify what happens to each operation when the decision component is unavailable. Denying sensitive data reads is often a sound default, but a safety-critical shutdown may need a deliberately designed emergency route rather than an improvised broad allow.

Before enforcement, compare proposed decisions against a time-bounded sample of actual requests with appropriate privacy controls. Estimate how many legitimate requests would be denied, which teams are affected and whether the assignment attribute is available when needed. A monitor-only mode can reveal policy effects but does not protect the resource. Give that mode an end date and a measurable transition criterion. Suppose review assignments reach the document service ten minutes late. Blanket denial during that interval harms work; repair the attribute feed or provide a narrowly approved temporary route, rather than changing policy to broad access. The business owner judges edge cases, the security owner accepts the exception risk, and the service owner confirms that every path to the document crosses enforcement.

The matrix should distinguish conditional permit from deferred authorization. If an auditor requests a sample that has not yet been defined, the system should not interpret an “auditor” role as unrestricted access. It should require a task identifier and sample boundaries. Once the task exists, compare each requested resource with the actual sample. If the identity provider sends a role but no task identifier, the defect is in the attribute source or integration, not in policy wording. Document attribute refresh and revocation. A temporary entitlement that survives the task defeats the purpose of scoping it. Test expiry during an existing session, not only at the next login.

Policy impact analysis needs the right denominators. A higher “deny rate” after closing an old bypass may show improved coverage rather than degraded user experience. Measure the fraction of legitimate requests harmed in a labeled sample, time to resolve an exception, frequency of denial caused by stale attributes and number of routes with no decision log. Weigh those indicators against the severity of the blocked action; a low-impact administrative lookup is not equivalent to exporting millions of records. Where teams disagree, write an explicit choice among broad permit, immediate enforcement or staged enforcement while repairing attributes. The staged option can be defensible if it reduces risk without unmeasured disruption.

The decision record for this protect surface lists both included and deliberately deferred routes. Explain why an archive interface was deferred, set a date for covering it and assign a temporary compensating control. Otherwise “phase one” can become a permanent gap. Link each condition to test requests: one valid request, one invalid because of identity, one invalid because of resource and one invalid because of context. Do not rely solely on the user's screen; a direct route may be invisible there. Re-run affected path tests when services or roles change. A sound policy applied to an outdated access map cannot protect a newly introduced resource.

Lesson summary

Derive a bounded protect surface and enforceable, testable access policies from a flow map.