Cloud Shared Responsibility Does Not Configure IAM

“The provider handles the infrastructure, so IAM is mostly their problem.”

Let me stop you before somebody turns a responsibility matrix into a permission set.

Shared responsibility does not configure your IAM.

Your provider can operate the physical datacentre, the physical network, the physical hosts and the managed service infrastructure correctly.

You can still give a human, a workload, a vendor or a resource policy far more access than you intended.

Both statements can be true at once.

That is the entire point of a boundary.

Shared responsibility says who owns which work.

IAM says which principals may do which things to which resources, and when that answer has to change.

One is an allocation.

The other is a set of decisions.

An allocation written in a vendor PDF does not wake up in the night and trim your role policy.

Nobody would say “the building manager maintains the lifts, so your tenant doesn’t need keys for its own office.”

Put the office in a cloud region and suddenly it sounds like an architecture position.

NIST SP 800-145, published in September 2011, gives you your service-model vocabulary.

IaaS, PaaS, SaaS.

It does not assign tenant entitlements.

Your providers do that, in their own shared-responsibility documents.

That distinction matters because service names move and defaults change.

The durable question does not: who selected this principal’s privileges?

1. “But the Provider Secures the Infrastructure.”

Yes.

Under Azure’s published responsibility matrix, physical hosts, the physical network and the physical datacentre are Microsoft’s responsibility from IaaS onward.

IaaS does not mean you own everything above bare metal.

That particular misunderstanding has had a long and surprisingly healthy life.

But the same matrix keeps customer data, configurations and settings, identities and users in your column, at IaaS, PaaS and SaaS alike.

The infrastructure boundary moves.

Those decisions don’t.

NIST’s definitions explain why.

Under IaaS, you control operating systems, storage and deployed applications, with possibly limited control of select networking components such as host firewalls.

Under PaaS, you control deployed applications and possibly application-hosting configuration.

Under SaaS, control usually narrows to limited user-specific configuration settings.

That is a narrowing of infrastructure control.

It is not a transfer of knowledge about your legitimate access.

A provider cannot infer whether your deployment workload needs to read one object, every object, a different account’s object, or none of them.

It can give you your policy language and the enforcement.

It cannot supply your business judgment without becoming an extremely expensive and extremely confused member of every customer’s access-review committee.

2. “But the Managed Service Has a Secure Default.”

Good.

Secure defaults reduce the number of ways you can get into trouble.

They don’t complete every control that remains configurable.

AWS made S3 Block Public Access automatically enabled, and ACLs disabled by default, for newly created buckets in every region on 27 April 2023.

That is an important platform-side improvement against a pattern of public-storage exposure.

It is also not a policy review of every principal you later allow through an identity policy, a bucket policy or a cross-account grant.

And it is not the explanation for every cloud breach with the word “storage” in it.

Capital One’s 2019 exposure was not a public S3 bucket.

It involved credentials for an EC2 instance role.

Collapse those into “the cloud storage default failed” and you have filed a specific control gap under a more comforting, unrelated noun.

The right question is always at the layer of your control.

Block Public Access controls a public-access failure mode.

A workload role constrains the actions a workload credential can take.

A resource policy decides which principals may reach that resource.

MFA protects an authentication event.

None of them performs the others’ job, and arriving in the same cloud console does not change that.

3. “But the Provider Audits the Control Plane.”

Provider auditing can establish that the platform’s control plane operates as documented.

It can’t determine whether your grant was legitimate.

The shared-responsibility model has no external body that accepts or rejects your configuration before it becomes dangerous.

Each provider publishes and revises its own allocation.

The meaningful enforcement is often after a failure, when a regulator asks whose column contained the failed control.

On 6 August 2020 the Office of the Comptroller of the Currency penalized Capital One over the 2019 breach, citing inadequate risk-assessment processes before its public-cloud migration.

The documented consequence followed your tenant’s risk-management and configuration responsibility.

Not a claim that AWS operated the physical infrastructure incorrectly.

That is not a criticism of cloud auditing.

It is a statement of scope.

An audit record can show that somebody created, changed or used a grant.

It doesn’t transform “somebody granted this” into “this principal should have it.”

A spelling checker can flag a sentence.

It cannot decide whether your policy exception was a terrible idea.

4. “But the Workload Role Only Exists in One Project.”

A workload role is still an identity.

Its effective reach is the permissions attached to it, the resources those permissions name, and the resource-side policies that accept it.

Its address in your organization chart isn’t an access boundary.

Capital One is the painful, dated example.

On 22 and 23 March 2019, an internet-facing WAF running on an EC2 instance was misconfigured.

An SSRF path reached the EC2 Instance Metadata Service at 169.254.169.254, which returns temporary credentials associated with the instance’s IAM role.

The role carried enough access to list and read broad storage locations.

The attacker didn’t receive a mysterious cloud-superuser token.

The metadata service returned your workload’s own temporary credentials, and those credentials could do what the role allowed.

That was enough to turn one misconfigured request path into a breach affecting roughly 100 million people in the United States and 6 million in Canada.

At the time, IMDSv1 accepted a plain GET with no session boundary.

AWS shipped IMDSv2 on 19 November 2019 with an initial PUT and a token with a hop-limited TTL.

Defence in depth against the passthrough-proxy shape of SSRF.

Useful platform hardening.

It still leaves the role policy to you.

Temporary credentials are not narrow credentials by nature. They are credentials carrying the permissions somebody attached to the role.

Replace static keys with workload identity.

Then make your workload identity boringly, aggressively narrow.

Otherwise your credential rotation is immaculate and your authorization is a bonfire.

5. “But the Account Has MFA Enabled.”

MFA is an authentication control.

It establishes that a claimant completed an accepted sign-in ceremony.

It doesn’t decide whether that identity may assume an administrative role.

Read a storage object.

Write a resource policy.

Delegate access to another account.

This should not be controversial.

An SSO assertion tells a relying party who the person is.

The relying party, or an entitlement layer in front of it, still decides what that person may do once recognized.

Cloud administration isn’t special enough to escape the distinction.

RBAC, standardized as ANSI/INCITS 359 and revised in 2012, assigns permissions to roles and identities to roles.

ABAC, defined in NIST SP 800-162 and updated in August 2019, evaluates subject, object, requested operation and sometimes environment attributes against policy.

Most enterprises layer RBAC for coarse baseline access with ABAC or a policy layer for finer conditions.

Neither model turns MFA into least privilege.

NIST defines least privilege as restricting users or processes to the minimum access necessary for assigned tasks.

A broad role is still broad after an excellent MFA ceremony.

RBAC and ABAC will enforce that excess with admirable consistency.

Nobody would say “the employee used a badge reader, so the employee can now rewrite the payroll system.”

Add a cloud identity provider and somehow the badge reader becomes an authorization engine.

It doesn’t.

It is still a badge reader with better APIs.

6. “But Access Reviews Are an Enterprise Process.”

Correct.

Cloud IAM is also an enterprise process.

The permissions live in cloud services.

The reasons for granting, changing and removing them live in your organization that owns those services.

Pretend that lifecycle work sits outside cloud security and an old role becomes an immortal cloud credential with excellent uptime.

Joiner-Mover-Leaver rules connect HR events to entitlement change.

A joiner receives birthright access on a verified hire-date trigger, and requests anything beyond that baseline.

A mover requires a simultaneous grant for the new role and revocation of old access that no longer applies.

A leaver’s access has to be revoked on or before the last working day, across connected systems, not merely in your identity provider.

The grant-and-revoke distinction matters because the two operations don’t fail symmetrically.

Missing access announces itself.

Unnecessary access is quiet.

That is why a person can carry the permissions of several former jobs long after the job titles changed.

And why “we update access when people move” usually means “we add more access when people move.”

Microsoft Entra access reviews support weekly, monthly, quarterly and annual recurrence, and can recommend denial when a user has not signed into your tenant in the preceding 30 days.

That recommendation is behavioural evidence.

It is not a verdict on whether access remains legitimate.

A principal can be inactive and still need a rare emergency entitlement.

A principal can be active and still have a role that is much too broad.

Review the grant.

Not merely the last click.

7. “But Least Privilege Is Impossible to Maintain in Cloud.”

It is difficult to maintain.

That isn’t the same sentence.

Least privilege is a policy goal.

It isn’t a button that RBAC, ABAC, an IAM suite or a managed cloud service presses on your behalf.

It needs roles scoped to defined resource-and-action pairs, conditions where context matters, and a lifecycle that removes what is no longer required.

For ordinary privileged work, use just-in-time access.

An eligible administrator requests elevation for a specific task, receives it for a bounded window through approval, and loses it immediately afterwards.

Microsoft Entra Privileged Identity Management implements that model.

It narrows the time a valid privileged account can be exploited, without claiming your administrator never needs privilege.

Break-glass accounts answer a different problem.

They exist when ordinary approval channels fail, so they deliberately bypass the normal gate.

Their governing control is detection: every use logged, every use reviewed afterwards.

Calling a permanent administrator role “break glass” doesn’t make it an emergency control.

It makes a standing grant with a dramatic label.

Difficulty is not an excuse to leave the default role broad forever.

It is a reason to use boundaries or their equivalents, narrow resource and action scope, document exceptions, and revisit them.

Nobody accepts “patching is impossible to maintain” as a reason to stop patching.

IAM deserves the same refusal to confuse ongoing work with optional work.

8. No, This Does Not Mean Providers Contribute Nothing.

They contribute a great deal.

The physical isolation and infrastructure operation in your provider column matter.

IMDSv2’s session-oriented design matters.

AWS’s 2023 S3 public-access defaults matter.

Azure’s distinction between customer and provider responsibilities matters.

GCP’s alternative framing, “shared fate”.

Matters too, because it adds provider-supplied defaults and tooling to a task-allocation model rather than pretending allocation alone guarantees correct execution.

Those features make secure choices easier, reduce particular failure modes, and can limit the damage from a mistake.

Use them.

But a provider-supplied default cannot identify the legitimate privileges of your principal.

A managed identity feature can issue a workload credential.

It cannot know that your deployment service should be allowed to modify every storage policy.

A resource-policy editor can reject invalid syntax.

It cannot know whether a vendor still requires the cross-account grant somebody created years ago.

Provider controls constrain the platform. Your IAM expresses your intent.

The first improves the safety of the second.

It does not write it.

9. What You Should Actually Do.

Start with an identity inventory. Human administrators.

Workload identities.

Service accounts.

Vendor and partner principals.

Emergency accounts.

And the resource policies that name any of them.

A cloud account inventory without a principal inventory is a building plan without a list of keys.

Require federation and MFA for human administrators, then separate sign-in assurance from authorization.

Define roles, resources and permitted actions after the user signs in. Map broad directory groups to bounded RBAC roles.

Use ABAC or a policy layer where the decision depends on subject, object, operation or environment.

Apply permission boundaries, or the platform equivalent, so a role cannot quietly exceed its intended ceiling.

Replace static workload keys with workload identity and temporary credentials. Then scope each role to the actions and resources it actually needs.

Review identity policies and resource policies together, especially where a cross-account grant lets an external principal reach a resource.

A role can be carefully designed on one side while the resource policy defeats the boundary on the other.

Make JML events real cloud events. Provision only birthright access at hire.

At a move, remove old entitlements as deliberately as you grant new ones.

At departure, disable the identity-provider account and explicitly remove local, VPN and non-federated access.

The average number of deployed applications per Okta customer passed 100 in 2025, up 9 percent year over year.

That is why your offboarding runbook needs a list.

Review grants on a declared cadence. Identify dormant assignments.

Record an owner and a purpose for every exception.

Use JIT elevation for routine administrative work.

Keep break-glass access separate, and review its use afterwards.

None of this is glamorous.

It is also the actual configuration work that the phrase “shared responsibility” is frequently used to avoid naming.

10. The Model Is Not Complicated.

Your provider secures the cloud infrastructure it operates.

You secure your data, configurations, identities, users, and the access relationships among them.

IaaS, PaaS, SaaS, serverless defaults and product names alter how much infrastructure you directly manage.

They do not give your provider the missing context needed to choose your legitimate privileges.

Shared responsibility is an allocation of work. IAM is your implementation of access intent.

Use provider defaults, managed identity features, isolation, audit capabilities and infrastructure hardening.

Then do the untransferable part.

Decide which principal needs which action on which resource.

Set your boundary.

Review the grant.

Remove it when the reason ends.

Otherwise “your provider secures the cloud” becomes an elegant way of saying nobody configured the permissions.