What is AWS IAM?

Definition

AWS Identity and Access Management (IAM) is the service that controls authentication and authorization for AWS. It governs who (or what) can perform which actions on which resources under which conditions within an AWS account.

IAM is the foundation of AWS security. Almost every AWS API call is authorized by IAM evaluation.

In simple terms:

IAM is AWS's policy engine: it answers "is this principal allowed to do this on this resource right now?" — millions of times per second.

---

Why AWS IAM Matters

• Every AWS API call is authorized by IAM.
• Compromise of high-privilege IAM credentials often equals account takeover.
• IAM misconfiguration is the #1 cause of AWS data breaches (per Verizon DBIR, multiple years).
• IAM scales across organizations, accounts, and services — and must be governed at scale.

---

Core Concepts

Principals

The "who" — entity making a request.

• Root user — the original account owner. Use sparingly.
• IAM Users — long-lived identities with credentials.
• IAM Roles — temporary identities that can be assumed.
• AWS Services — services calling other services (via service roles).
• Federated identities — from external IdPs (SAML, OIDC, IAM Identity Center).

Resources

The "what" — AWS objects: S3 buckets, EC2 instances, RDS databases, Lambda functions, etc.

Actions

The "do what" — API calls: s3:GetObject, ec2:RunInstances, iam:CreateRole, etc.

Policies

JSON documents that grant or deny permissions:

• Identity-based — attached to users, groups, roles.
• Resource-based — attached to resources (S3 bucket policies, KMS key policies).
• Permission boundaries — max permissions a principal can have.
• Service Control Policies (SCPs) — at AWS Organizations level.
• Session policies — passed during AssumeRole.

Conditions

Context that policies can use: source IP, MFA, time, tags, etc.

---

Key Identities

IAM Users

• Long-lived identities with credentials (password and/or access keys).
• Suited to small teams; strongly discouraged at scale in favor of federation/Identity Center.
• Can hold access keys for programmatic access.

IAM Roles

• Temporary identities assumed by principals (users, services, federated identities).
• No long-lived credentials.
• Use AssumeRole via STS to get temporary credentials.
• Foundation of secure cross-account, EC2, Lambda, federated, and CI/CD scenarios.

IAM Groups

• Containers for IAM Users to share policies.
• Cannot be principals themselves.

---

How an IAM Decision Works

1. Principal makes request to AWS service.
2. AWS evaluates all relevant policies:
   • SCPs (deny if disallowed).
   • Resource-based policies.
   • Identity-based policies.
   • Permission boundaries.
   • Session policies.
3. Explicit Deny anywhere → Deny.
4. Explicit Allow in identity-based AND no Deny → Allow.
5. No Allow → implicit Deny.

(Cross-account adds nuances; resource-based policies can grant cross-account access without identity-based.)

---

AWS IAM Identity Center (Successor to AWS SSO)

Modern multi-account access management:

• Centralized user store (or federated from external IdP).
• Permission Sets define roles deployable across accounts.
• SAML / OIDC SSO into accounts.
• MFA enforcement.
• Access reviews and reports.

Recommended for most multi-account organizations in place of standalone IAM Users.

---

Common Risks

• Overly broad policies (Action: *, Resource: *).
• IAM users with long-lived access keys never rotated.
• Trust policies allowing too-broad principals (e.g., trust * or large account lists).
• Privilege escalation via dangerous IAM permissions (iam:PassRole, iam:CreatePolicyVersion, etc.).
• Public S3 buckets via permissive bucket policies.
• Root user with no MFA or active access keys.
• Cross-account access with no external ID.
• Identity Center permission sets too broad.
• Federation misconfigurations (SAML token validation gaps).
• Service-linked role abuse.
• Lambda / EC2 roles with Administrator policy.

---

Real-World Examples

1. Capital One (2019)

A misconfigured WAF allowed SSRF that hit EC2 metadata service and stole the EC2 role's credentials. The role had s3:List* and s3:Get* on sensitive buckets. 100M+ records exfiltrated.

Lesson: EC2 instance roles must be tightly scoped; IMDSv2 enforced; least privilege strictly applied.

2. Imperva (2019)

Compromised AWS API key (no MFA) accessed an internal database via misconfigured IAM permissions.

Lesson: Long-lived keys + over-broad permissions = inevitable breach.

3. CodeSpaces (2014)

Attacker obtained AWS console credentials, deleted the entire infrastructure. Company shut down within days.

Lesson: MFA, separated admin accounts, immutable backups.

4. Multiple S3 Public Bucket Incidents

Companies including Verizon, Accenture, and many more have leaked terabytes of data via S3 buckets misconfigured to public read.

Lesson: Block Public Access at account level; default-deny mindset.

---

AWS IAM Best Practices (Highlights)

1. Use IAM Identity Center + federated identities; minimize standalone IAM Users.
2. No long-lived access keys where avoidable; use roles and STS.
3. MFA enforced for all human identities, especially root.
4. Lock down root — secure MFA token in safe, no daily use, no access keys.
5. Least privilege policies; periodic reviews via Access Analyzer.
6. Permission boundaries to cap delegated admin authority.
7. SCPs at the Organizations level to enforce guardrails.
8. Tag-based access where appropriate.
9. Roles for services (EC2, Lambda) with narrowest permissions.
10. Cross-account access via roles + external ID + SCP enforcement.
11. Block Public Access for S3 at account level.
12. CloudTrail for all accounts; centralized; immutable.
13. Enable IAM Access Analyzer for unintended public/cross-account access.
14. Detect dangerous patterns: new policy with *:*, new IAM user, key creation, role assumption from unusual sources.
15. Continuous attack-path analysis.

---

AWS IAM Quick Checklist

• Identity Center used for human access?
• Root user MFA + token in safe + no daily use + no keys?
• Long-lived access keys minimized and rotated?
• MFA required for IAM users (where they exist)?
• Least-privilege policies; regular Access Analyzer reviews?
• SCPs enforce account-level guardrails?
• Permission boundaries for delegated admin?
• IAM Access Analyzer enabled?
• CloudTrail enabled, centralized, immutable?
• S3 Block Public Access on?
• Detections for IAM dangerous events in SIEM?
• Continuous IAM attack-path analysis?

---

How Forestall Helps

Forestall analyzes AWS IAM across every account in your Organization:

• Effective permissions for every principal.
• Privilege escalation paths.
• Cross-account trust risks.
• Public exposure via resource policies.
• Federation and Identity Center mappings.
• Paths from low-privilege → admin equivalent.

---

Frequently Asked Questions

Should I still use IAM Users?

For most cases, no. Use Identity Center + federated identities. Limited IAM Users for break-glass and specific automation.

What's the difference between an IAM Role and a service role?

A service role is an IAM Role assumed by an AWS service (EC2, Lambda, etc.). Same mechanism; specific use case.

Is IAM the same as Access Management in AWS?

IAM is the service. Access management is the discipline; IAM is its primary tool, complemented by SCPs, resource policies, KMS, etc.

How does AWS IAM compare to Entra ID?

AWS IAM is account-centric, JSON policy–based, fine-grained per service. Entra ID is directory-centric, role-and-app-based. Different models, similar goals.

What is : and why is it bad?

A policy with Action: *, Resource: * grants every action on every resource — effectively account-administrator. Avoid except for explicit, justified, audited cases.

---

Conclusion

AWS IAM is the heart of AWS security. Its model is powerful and granular — and easy to misuse. Adopt Identity Center, eliminate long-lived keys, enforce MFA, write least-privilege policies, layer SCPs and permission boundaries, monitor with CloudTrail and IAM Access Analyzer, and continuously analyze the privilege graph. Done well, IAM becomes the strong cloud authorization plane it's designed to be — instead of the silent path attackers take to your data.