Most cloud breaches you read about share a sentence: "the attacker obtained credentials with broader permissions than necessary and used them to reach data they should not have been able to reach." Identity and Access Management is the discipline of making sure that sentence cannot be written about your environment.
This page covers three things: the access-control models you'll see in real cloud IAM systems (RBAC, ABAC, PBAC), least privilege as an operational discipline rather than a slogan, and how NIST SP 800-207 zero trust translates from a paper into the IAM features you actually configure.
Three ways to grant access
Cloud providers use a mix of three access-control models. Each one is good at a specific thing and noisy at others. Knowing which model you're using helps explain why a policy reads the way it does.
Role-Based Access Control
Permissions are attached to roles. Users are assigned roles. Move someone between roles and their permissions shift accordingly. The dominant model in most IAM systems by far.
Attribute-Based Access Control
Permissions are decided dynamically by comparing attributes on the user, the resource, and the request context. You don't grant access to a specific resource; you grant access to "resources where attribute X matches attribute Y."
Department tag matches the user's Department attribute.Policy-Based Access Control
An expressive policy language evaluates a request against rules that can consider arbitrary conditions: identity, resource, time, location, device posture, prior actions. The most flexible model and the one underlying modern zero-trust systems.
In practice you'll use all three at once. RBAC is the spine: people belong to a team, the team has a role, the role grants the base permissions. ABAC fills in scaling problems: instead of writing N policies for N projects, you tag resources and let one ABAC rule cover all of them. PBAC adds context: who, where, when, on what device.
Least privilege, in practice
"Least privilege" is the principle that any identity (user, service, role) should have only the permissions it needs to do its job, and no more. Quoted in every policy document, applied poorly in most production environments. The reason is operational, not philosophical: granting permissions unblocks work today, and revoking them might break something tomorrow.
Three operational habits make least privilege real:
- Start from zero. New roles get no permissions; add what you find you need. This sounds obvious and almost no one does it — the temptation is to copy an existing similar role and edit it down. Don't.
- Periodic access reviews. Every role's permissions should be reviewed quarterly. Cloud providers publish tools to surface unused permissions: AWS IAM Access Analyzer (Last Accessed), GCP IAM Recommender, Azure Entra Permissions Management.
- Just-In-Time elevation over standing access. Engineers don't need admin permissions all day; they need them for the 30 minutes when something is broken. Tools (Entra PIM, AWS IAM Identity Center session policies, Vault) make JIT operationally cheap.
Role assumption — how cloud identities chain
In the cloud, "I am alice" usually isn't the end of the identity story. Alice assumes a role — she presents her identity, the IAM system mints a short-lived set of credentials scoped to the role, and the work happens under those credentials. The role's permissions, not alice's, are what the request gets evaluated against.
Zero trust, applied
NIST SP 800-207 defines zero trust as a set of principles, not a product. The document is 50 pages; the part that matters for cloud IAM fits in a paragraph: no implicit trust is granted based on network location or asset ownership; every access decision is made explicitly, with all available context.
In the cloud, that translates to concrete features:
Identity is the policy boundary
Not network range, not VPN connection, not "is the request from inside the VPC." Every access decision starts with who is asking, verified by the IdP every time.
Verify explicitly, every request
No session is "trusted" because it was authenticated five minutes ago. Conditional Access re-evaluates on each sensitive action. Continuous authentication, not point-in-time.
Least privilege at the role
The permissions the role grants are the minimum required, not the maximum convenient. JIT elevation when more is needed.
Short-lived credentials
STS tokens, federated sessions, SSH certificates with minute-scale lifetimes. Standing long-lived keys are a code smell in 2026.
Assume breach — segment blast radius
Design as if one identity will eventually be compromised. The permission boundary it can reach — not its happy-path use — is what matters in incident response.
Continuous monitoring of identity
GuardDuty, Defender for Identity, Chronicle, Detection on impossible travel, unusual API calls, new region usage, principal expansion.
In a cloud where every workload is reachable over a network you don't control, identity is the new perimeter. The access-control models you'll use are some mix of RBAC, ABAC, and PBAC; the discipline that ties them together is least privilege; the architectural posture that pulls it into focus is zero trust.
When you read a cloud breach report and ask "what would have stopped this?", the answer is almost always one of three things: a tighter role, a shorter-lived credential, or a conditional access rule. Master those three and you've covered the majority of cloud identity work.
References
Formatted in APA 7. Alphabetized by first author's last name.
- Amazon Web Services. (n.d.). What is ABAC for AWS? AWS Identity and Access Management documentation. https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html
- Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., & Scarfone, K. (2014). Guide to attribute based access control (ABAC) definition and considerations (NIST Special Publication No. 800-162). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-162
- Microsoft. (n.d.). Conditional access overview. Microsoft Entra ID documentation. https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
- Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication No. 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207
- Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-based access control models. Computer, 29(2), 38–47. https://doi.org/10.1109/2.485845