{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/cloud-access-control-service-layer-map/", "item": { "id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "slug": "cloud-access-control-service-layer-map", "url": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map.md", "json": "https://update.dsesecurity.com/api/v1/posts/cloud-access-control-service-layer-map/" }, "title": "Map cloud access control to the service layer that actually makes the decision", "summary": "IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-25T21:34:06+00:00", "modified_at": "2026-08-26T13:27:47+00:00", "reviewed_on": "2026-08-25", "reading_minutes": 3, "word_count": 486, "potentially_affected": "Organizations using infrastructure, platform, or software cloud services, especially where provider, tenant, application, and data-layer authorization overlap.", "dse_recommendation": "Create an access-decision map across provider and customer layers, define owners and authoritative policy for each decision, and test effective access with representative identities rather than relying on role names alone.", "primary_source": { "name": "NIST SP 800-210 — General Access Control Guidance for Cloud Systems", "url": "https://csrc.nist.gov/pubs/sp/800/210/final", "published_on": "2020-07-31", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what NIST covers

\n

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.

\n

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.

\n

What the source does not establish

\n

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.

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: create an access-decision map

\n

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

\n
    \n
  1. For each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source.
    2. \n
  2. Separate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts.
    3. \n
  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. \n
  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. \n
  5. Protect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events.
    6. \n
  6. Re-run the map after service architecture, identity integration, subscription, or application behavior changes.
    7. \n
\n

Verification and evidence

\n

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.

\n

Official references

\n", "content_text": "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.\nSource fact: what NIST covers\nNIST 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.\nThis 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.\nWhat the source does not establish\nThe 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.\nThe 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.\nApplicability questions\n\nWhich service model and functional components are in scope for this resource?\nAt which layer is authentication performed, and at which layers is authorization re-evaluated?\nWhich provider, tenant, application, data, automation, and support identities can affect the resource?\nWhere is policy configured, who can change it, and which logs show the resulting decision?\nCan an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission?\n\nDSE recommendation: create an access-decision map\nThe following steps are DSE recommendations based on the cited source.\n\nFor each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source.\nSeparate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts.\nInventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture.\nTest 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.\nProtect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events.\nRe-run the map after service architecture, identity integration, subscription, or application behavior changes.\n\nVerification and evidence\nRetain 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.\nOfficial references\n\nNIST SP 800-210 — General Access Control Guidance for Cloud Systems — National Institute of Standards and Technology; finalized July 31, 2020", "content_markdown": "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.\n\n## Source fact: what NIST covers\n\n[NIST SP 800-210](https://csrc.nist.gov/pubs/sp/800/210/final) 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.\n\nThis 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.\n\n## What the source does not establish\n\nThe 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.\n\nThe 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.\n\n## Applicability questions\n\n- Which service model and functional components are in scope for this resource?\n\n- At which layer is authentication performed, and at which layers is authorization re-evaluated?\n\n- Which provider, tenant, application, data, automation, and support identities can affect the resource?\n\n- Where is policy configured, who can change it, and which logs show the resulting decision?\n\n- Can an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission?\n\n## DSE recommendation: create an access-decision map\n\nThe following steps are DSE recommendations based on the cited source.\n\n- For each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source.\n\n- Separate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts.\n\n- Inventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture.\n\n- 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.\n\n- Protect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events.\n\n- Re-run the map after service architecture, identity integration, subscription, or application behavior changes.\n\n## Verification and evidence\n\nRetain 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.\n\n## Official references\n\n- [NIST SP 800-210 — General Access Control Guidance for Cloud Systems](https://csrc.nist.gov/pubs/sp/800/210/final) — National Institute of Standards and Technology; finalized July 31, 2020" }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "url": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-25" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Map cloud access control to the service layer that actually makes the decision", "item": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/#article", "identifier": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "url": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/", "headline": "Map cloud access control to the service layer that actually makes the decision", "description": "IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service…", "abstract": "IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it.", "articleBody": "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.\nSource fact: what NIST covers\nNIST 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.\nThis 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.\nWhat the source does not establish\nThe 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.\nThe 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.\nApplicability questions\n\nWhich service model and functional components are in scope for this resource?\nAt which layer is authentication performed, and at which layers is authorization re-evaluated?\nWhich provider, tenant, application, data, automation, and support identities can affect the resource?\nWhere is policy configured, who can change it, and which logs show the resulting decision?\nCan an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission?\n\nDSE recommendation: create an access-decision map\nThe following steps are DSE recommendations based on the cited source.\n\nFor each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source.\nSeparate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts.\nInventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture.\nTest 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.\nProtect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events.\nRe-run the map after service architecture, identity integration, subscription, or application behavior changes.\n\nVerification and evidence\nRetain 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.\nOfficial references\n\nNIST SP 800-210 — General Access Control Guidance for Cloud Systems — National Institute of Standards and Technology; finalized July 31, 2020", "datePublished": "2026-08-25T21:34:06+00:00", "dateModified": "2026-08-26T13:27:47+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Map cloud access control to the service layer that actually makes the decision" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Guide", "Important priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 486, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "NIST SP 800-210 — General Access Control Guidance for Cloud Systems", "url": "https://csrc.nist.gov/pubs/sp/800/210/final", "datePublished": "2020-07-31" } } ] } }