Cloud IAM and Shared Responsibility

Shared responsibility is a control map

A provider commonly operates underlying facilities and parts of a managed service. The customer still owns decisions about identities, data, configurations, integrations, permissions, monitoring, and use of the service. A managed service can narrow operational work without transferring every security responsibility. Record the specific service model, contract boundary, and control owner instead of relying on a general cloud statement.

Responsibility assignment

Control area	Questions to assign
Identity federation	Which identity provider, tenant, issuer, and owner governs human access and recovery?
Workload access	Which service principal or managed identity is used, what resource scope exists, and who approves changes?
Platform operation	Which provider-managed component applies, and which customer configuration, data, or network decision remains?
Monitoring and review	Where are privileged events retained, who reviews them, and what happens when a log route fails?

Cloud access review

Inventory human identities, workload identities, service principals, API credentials, third-party access, and dormant emergency accounts.
Review role inheritance, organization-level policy, resource-level permissions, and whether group membership or role chaining creates unexpected reach.
Use least privilege with a clear task, scope, duration, owner, and review date. Broad roles should have a documented exception or reduction plan.
Make temporary credentials time-bound and log their use. Break-glass access should be separately protected, monitored, tested, and not used as a routine path.
Revoke or re-scope access during role changes, service retirement, vendor offboarding, and incident response; retain evidence of the review.

Cross-account trust checklist

State the source account, target account, identity type, allowed action, resource condition, and intended data flow.
Confirm the target resource owner accepts the trust deliberately and can audit its use.
Check external IDs, conditions, session duration, permission boundaries, and organization controls where the platform supports them.
Test normal and denied paths using approved accounts. A successful permitted action does not demonstrate that all other permissions are constrained.
Review logs for assumption, elevation, and emergency access events, then set a scheduled revalidation date.

Fictional access example

A deployment service in a build account receives a cross-account role to update a production workload. The first design grants broad administration because deployment occasionally changes networking. During review, the team splits the role, requires a controlled approval for the rare network action, uses a workload identity for routine deployment, and routes role-assumption logs to the security account. The managed build service remains part of the solution; it does not remove the customer responsibility to bound the permission.

Common misunderstandings

Common errors are treating an authenticated identity as authorized for every resource, assuming a provider's managed service automatically configures customer policy, or leaving partner access after a project ends. Another is assuming an access review proves no misuse occurred. Reviews create evidence about a bounded time and scope; investigation requires relevant logs and context.

Privileged-role checklist

For each privileged role, retain the business purpose, approving owner, permitted resources, duration, authentication requirements, monitoring source, and review date. Review delegation and role chaining as carefully as direct assignment. An emergency path needs a documented trigger, named custodians, tested recovery process, and post-use review. When a third party needs access, define the service boundary and offboarding event before granting it. These records support an access decision; they do not replace current configuration or activity evidence.