Introduction
Identity and Access Management (IAM) controls who can access cloud resources and what they are allowed to do once they have access. It is one of the most critical security layers in the cloud because nearly every breach involves either a compromised identity or an overly permissive grant of access.
Cricket analogy: A stadium's accreditation desk decides who gets a pass and which areas that pass unlocks, just as IAM controls who can access cloud resources and what they're allowed to do, with most security breaches tracing back to a stolen pass or an overly broad one.
Explanation
Authentication and authorization are related but distinct concepts. Authentication answers 'who are you?' — it verifies identity, typically through a username and password combined with multi-factor authentication (MFA), or through federated identity from a trusted provider. Authorization answers 'what can you do?' — once identity is confirmed, authorization determines which actions on which resources are permitted. A user can be successfully authenticated (proven to be who they claim) yet still be denied an action because authorization rules do not grant it.
Cricket analogy: Checking a player's accreditation badge at the gate confirms who they are, that's authentication, while the badge's color determining whether they can enter the dressing room or just the stands is authorization.
The principle of least privilege states that an identity — whether a human user, application, or service — should be granted only the minimum permissions necessary to perform its intended task, and nothing more. This limits the blast radius if credentials are ever compromised. In practice, least privilege is implemented through role-based access control (RBAC): permissions are grouped into roles, and identities are assigned only the roles they need, rather than being granted broad or administrative access by default.
Cricket analogy: Giving a net bowler access only to the practice nets they need, not the entire team dressing room, mirrors least privilege, and grouping players into roles like 'fast bowler' or 'wicketkeeper' with matching access mirrors role-based access control.
Example
{
"Version": "2026-01-01",
"Statement": [
{
"Effect": "Allow",
"Action": ["storage:ReadObject"],
"Resource": "arn:cloud:storage:::reports-bucket/*",
"Condition": {
"StringEquals": { "aws:PrincipalTag/team": "analytics" }
}
}
]
}Analysis
The example policy above grants only read access to a single bucket, scoped further by a condition tied to the identity's team tag. This is least privilege in action: it does not grant write, delete, or administrative permissions, and it does not apply broadly across all storage resources. A common security failure is granting wildcard permissions like 'Action: *' on 'Resource: *' for convenience during development and never tightening them afterward — this collapses the distinction between authentication and authorization by making every authenticated identity effectively all-powerful.
Cricket analogy: Giving a scorer read-only access to just their own team's scoresheet, tied to a condition like their assigned match, is least privilege in action, while handing every accredited person a master key to every dressing room 'for convenience' collapses the whole access control system.
Key Takeaways
- Authentication verifies who you are; authorization determines what you can do.
- Least privilege means granting only the minimum permissions needed for a task.
- Role-based access control (RBAC) is the common mechanism for applying least privilege at scale.
- Overly broad wildcard permissions are a frequent and dangerous misconfiguration.
Practice what you learned
1. Which question does authentication answer?
2. Which question does authorization answer?
3. What does the principle of least privilege recommend?
4. In the example IAM policy JSON, what access is granted?
Was this page helpful?
You May Also Like
Cloud Security Fundamentals
Learn the core principles of securing cloud environments, including the shared responsibility model and defense-in-depth.
The Shared Responsibility Model
Understand which security responsibilities belong to the cloud provider versus the customer, and how that split shifts across IaaS, PaaS, and SaaS.
Encryption in the Cloud
Learn how encryption at rest, encryption in transit, and key management protect cloud data.
Compliance and Governance
Get a conceptual overview of common compliance frameworks like SOC 2, GDPR, and HIPAA in the cloud.