Cloud identity is settled at the shared responsibility boundary: the provider operates the authentication and authorisation machinery, while the organisation answers for who is granted access and who approved it. This article works through that boundary, the policy types behind it, and the roles that have to be separated for an access review to mean anything.
Quick Overview
What you’ll learn:
- What a cloud provider structurally cannot know about access to your data
- Why most over-permission arrives through inheritance rather than decision
- How identity-based and resource-based policies answer different questions
- Which roles must be held by different people for separation of duties to hold
Who this article is for:
- Cloud administrators and anyone who grants entitlements
- Leads of teams building services on public cloud
- People accountable for access audits and compliance evidence
Reading time: 7 minutes
What the Provider Cannot Know
The shared responsibility model on aws.amazon.com separates security of the cloud from security in the cloud: the provider answers for the infrastructure the service runs on, the customer for the service’s configuration, the data and the management of identity and access. The boundary is sharper than it is usually understood to be — and the customer side is where incidents concentrate.
A blunt test settles most arguments about it: if the setting is changeable in the console, it is yours. The provider cannot know whether a service account should read that bucket, because the answer comes from a business purpose rather than from the service architecture. Nor can it know that someone who left last month still holds access — only your joiner-mover-leaver process knows that.
The organisational conclusion follows: moving to cloud does not reduce identity work, it relocates it from device configuration to a grant-and-revoke process. A team that has not built that process before migrating will build it after the first audit.
Where Over-Permission Comes From
The IAM overview on cloud.google.com describes access as roles granted to principals on resources arranged in a hierarchy, with grants inherited downward. That inheritance, not explicit generosity, is where excess entitlement usually originates: a role granted at a parent level to unblock a project quietly applies to everything created underneath it afterwards.
The second distinction concerns where a policy lives. An identity-based policy is attached to a user, group or service account and states what that principal may do. A resource-based policy is attached to the resource and states who may work with it — including principals outside your organisation. The first answers “what is this person allowed to do”; the second answers “who can reach this bucket”, and the second is the question an auditor asks.
Least privilege enters here as a process, not a setting. The Entra role guidance on learn.microsoft.com puts it in named steps: assign the least privileged role that completes the task, activate privileged roles just in time through Privileged Identity Management rather than permanently, keep the number of standing global administrator assignments small, and require multifactor authentication for administrator accounts. Each of those is checkable with a directory query, which makes each usable as review criteria.
Separating Grant, Approve and Review
Separation of duties is the whole content of this section. Where the same person grants an entitlement and approves the grant, the access review is a formality — and formalities pass green for years.
The split that works names its functions. The resource owner decides who needs access and for what purpose, because the data is theirs. The identity administrator performs the grant and keeps the directory consistent, without deciding scope. The approver sits on the business side and attests to purpose rather than technique. The data protection officer enters wherever personal data is in scope and settles the lawful basis. Teams running services add an on-call engineer whose access is elevated for the duration of an incident — and that elevation needs a shorter expiry than any standing assignment.
Service accounts deserve separate attention because they have no owner by nature. A service account without a named responsible person survives every review, since nobody will confirm it is no longer needed. Its register entry has to name the owner, the system that consumes it, and the condition under which it can be switched off.
Authentication Assurance Comes First
Policies settle authorisation — what an already authenticated principal may do. If authentication can be bypassed, authorisation is decoration, which is why this step belongs before the previous ones even though projects tend to append it at the end.
The guidelines on csrc.nist.gov under SP 800-63B-4 set the standard side of this: they define authentication assurance levels, classify authenticators by type, and state requirements for multifactor authentication and for authenticator lifecycle management. For a team the standard turns into something concrete: the choice of factor is a question of the assurance level a given access path needs, not a question of convenience.
The zero trust architecture document on csrc.nist.gov extends the same logic to the network: access to a resource is granted on a per-session basis, on the evidence of identity and device posture, instead of by location inside a perimeter. Read together, the practical message is that identity has become the control plane, so its own assurance cannot be the weakest link in the chain.
What no policy repairs: access granted outside the process, an access key committed to a repository, and an account shared by a team. The last is the worst of the three, because it destroys accountability end to end — the log names an account rather than a person, so after an incident nobody can establish who acted.
Read Also
- Identity and access management: how to manage user permissions effectively — the grant and revoke process inside an organisation
- Zero trust architecture: security without a trusted network — the model in which identity replaces the network boundary
- Security considerations for low-code applications — the same entitlements seen from an application built outside IT
Build Your Skills
This topic is covered by Identity and Access Management (IAM) and Zero Trust Security — SASE, microsegmentation and identity management. The first works through the access management process and its tooling; the second shows identity taking over as the security boundary. Talk to us about matching the scope to your environment’s architecture.
Frequently Asked Questions (FAQ)
Is the cloud provider accountable for who I gave data access to?
No. The shared responsibility model assigns infrastructure security to the provider and service configuration, data and access management to the customer. The grant, its scope and the moment of revocation sit with the customer — including when the entitlement arrived through inheritance in the resource hierarchy rather than by an explicit decision.
How do we apply least privilege without blocking the team?
By starting with privileged entitlements rather than with everything. Convert standing administrative assignments into just-in-time elevation first, then work down to ordinary entitlements on the basis of observed usage. The reverse order — tightening everything at once — produces a wave of tickets and ends with the whole change being rolled back.
What should we do with service accounts nobody remembers?
Assign each an owner and a switch-off condition, and for those without an owner remove privileged entitlements first rather than deleting the account. Deleting an account used by an undocumented integration is an outage; stripping it back to what it demonstrably uses is a test that exposes the integration without stopping the service.
Does an access review have to be periodic?
A periodic review is the audit minimum, but on its own it describes a state from weeks ago. Useful reviews are event-driven: a role change, a leaver, a new resource holding personal data, a project closing. The calendar is a safety net for the events your process failed to catch.