Map cloud access control to the service layer that actually makes the decision

Bottom line: “cloud access” is rarely one control. A request may cross provider administration, tenant identity, platform policy, application roles, resource permissions, data filtering, network boundaries, and support channels. Map the layer that makes each decision before assigning or reviewing access.

Source fact: what NIST covers

NIST SP 800-210 presents cloud access-control characteristics and general guidance for infrastructure, platform, and software service models. NIST notes that the models expose different types of components and access. It describes them as hierarchical in the sense that guidance for lower-level functional components can remain relevant when those components appear within higher-level models, while each service model retains its own access-control focus.

This supports an important operating distinction: the provider’s controls and the customer’s controls can both matter, but they do not necessarily make the same decision or produce the same evidence.

What the source does not establish

The publication does not certify a cloud service or prescribe exact product roles. It does not prove that a provider role, tenant group, application role, and data permission align. A least-privilege name is not evidence of least-privilege behavior.

The source also does not establish contractual responsibility, licensing, feature availability, or log retention for a particular service. Those facts must come from current service documentation and the customer’s agreement and configuration.

Applicability questions

• Which service model and functional components are in scope for this resource?
• At which layer is authentication performed, and at which layers is authorization re-evaluated?
• Which provider, tenant, application, data, automation, and support identities can affect the resource?
• Where is policy configured, who can change it, and which logs show the resulting decision?
• Can an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission?

DSE recommendation: create an access-decision map

The following steps are DSE recommendations based on the cited source.

1. For each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source.
2. Separate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts.
3. Inventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture.
4. Test effective access with representative accounts at each role and boundary. Include denied operations, cross-tenant or cross-project paths, and direct API access where supported.
5. Protect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events.
6. Re-run the map after service architecture, identity integration, subscription, or application behavior changes.

Verification and evidence

Retain the architecture and decision map, official responsibility documentation, exported role and policy configuration, effective-access tests, denied-event logs, privileged-change records, exception register, and review sign-off. Evidence should identify the tenant, subscription or project, region where relevant, resource, and test identity.

Official references

• NIST SP 800-210 — General Access Control Guidance for Cloud Systems — National Institute of Standards and Technology; finalized July 31, 2020