Inventory assets and data flows as trust boundaries

A cloud zero-trust architecture starts by naming the resource to protect and the operation performed on it, not by drawing a network perimeter. NIST SP 800-207 says network location or ownership alone does not confer implicit trust; resources such as services, workflows and accounts are the design focus. An inventory of servers and addresses is therefore insufficient. Define the unit of protection precisely: a payroll export endpoint, a beneficiary table, an encryption key or a deployment approval path. Specify who requests which action on that resource, for what business purpose, and which decision must be tested before a session is established. The label “sensitive data” by itself identifies neither a policy enforcement point nor the consequence of a denial.

Build an inventory with stable columns: resource identifier, resource type, business owner, operating owner, data classification, environment, cloud account or project, ingress and egress interfaces, dependencies, and identity mechanism. Distinguish a logical asset from its physical copies. Request records may exist in an operational database, an analytics replica and a backup, each with different routes, privileges and retention. A single provider console cannot prove completeness: federated identities, third-party services and exports outside the account may be missing. Record when and how each asset was last observed; label an uncertain resource rather than quietly omitting it. The useful completion test is whether a critical business operation can be traced from requester to data and output, not how many rows appear in the inventory.

Draw a flow with at least six nodes: actor, entry point, decision service, enforcement point, application service and data store. Include each connection's identity, direction, protocol and logical operation, not just a port number. A trust boundary is where authority, responsibility or assurance changes. It may lie between a user and an API, between two services on the same network, or between accounts at the same provider. Do not equate a subnet boundary with a trust boundary. Allowing an employee to view a report does not automatically authorize the reporting service to extract every table. The workload's identity and privilege require a separate decision, consistent with the application and service identity emphasis of NIST SP 800-207A.

Test the map with a contrary case. If an attacker steals the nightly job token, can that token read individual documents or only the aggregate export? If the answer cannot be derived from a policy and observed configuration, the map remains a hypothesis. Ask for service request logs, identity and permission settings, network route configuration, and ownership evidence for the third-party integration. Compare those records with the map and label each link confirmed, assumed or unknown. An interview-derived inventory is different from a route verified in operation. The diagram itself grants no authorization to run penetration tests and proves no policy is working. Exercise allow and deny requests only in an authorized test environment without copying real personal records into it.

Make the inventory auditable by recording a source of truth and a possible falsification test for each row. An object store row might come from the provider resource inventory, while effective access requires reviewing bucket policy, service role and an unauthorized identity's test request. Inherited permissions or temporary exceptions are common. A role's name is not proof of its scope. Record the rule identifier or relevant configuration in an internal evidence register, its review date and the owner who will close the exception. If resource records conflict with an interview, preserve the discrepancy rather than accepting the interview as decisive. The map becomes a collection of hypotheses that can be tested and corrected.

Prioritize flow mapping by operation impact, reachability and blast radius, not service count. Reading one document, exporting a million records and changing the access policy have different consequences and need different verification even if they share an interface. For each path, state the expected maximum scope and request volume, then test the behavior at the limit. Does enforcement deny the excess request, hold it for approval or fail to act? What happens to legitimate service when the decision component is unavailable? Do not prescribe “fail closed” as an absolute before assessing safety and operational consequences. Where a break-glass route is necessary, make it narrowly scoped, time bound, approved, logged and revocable.

The migration team can use the flow map as a contract among owners. The business owner signs off on the operation's purpose and minimum necessary data. The identity owner confirms the source and freshness of attributes. The service owner confirms where a decision can be enforced, while the monitoring team identifies evidence that will appear for permits and denials. If an owner cannot identify an attribute source or enforcement point, delaying broader access is a defensible decision. The lesson output is not an attractive network picture: it is a register of resources, flows and boundaries, each linked to an expected test request and an observable result. Keep unresolved assumptions in a decision log with an owner and review date; a diagram that hides unknowns is more dangerous than one that labels them.