AWS IAM Security Best Practices

AWS IAM is one of the most powerful — and most easily misused — services in AWS. This article consolidates the best practices most consistently associated with secure AWS environments, drawing on AWS official guidance, the AWS Security Reference Architecture, the CIS AWS Benchmark, and patterns observed in real incident response.

---

1. Identity Plane

Use IAM Identity Center for Human Access

• Federate from your corporate IdP (Entra ID, Okta, Google).
• Map groups to Permission Sets per account.
• MFA enforced at IdP and Identity Center.
• No standalone IAM Users for engineers.

Use Roles for Workloads

• EC2 → Instance Profiles.
• Lambda → Execution Roles.
• ECS / EKS → Task Roles / IRSA.
• CI/CD → OIDC federation (GitHub Actions, GitLab).

Eliminate Long-Lived Access Keys

• Replace with STS-issued temporary credentials wherever possible.
• For remaining keys: rotate ≤ 90 days; monitor for leaks.

Lock Down the Root Account

• Hardware MFA (FIDO2).
• Strong unique password.
• No active access keys.
• Recovery email and phone controlled and monitored.
• Don't use root for daily operations.
• Alert on any root sign-in.

---

2. Authentication

Enforce MFA Everywhere

• Identity Center MFA enforced.
• IAM users with MFA condition on sensitive actions.
• Hardware FIDO2 for admins; TOTP at minimum elsewhere.

Use Strong Conditions

• aws:MultiFactorAuthPresent
• aws:SourceIp for restricted networks
• aws:PrincipalOrgID for cross-account inside org
• aws:SourceArn / aws:SourceAccount for service trust

Federation Done Right

• SAML / OIDC trust scoped tightly (specific repos / branches / environments for OIDC).
• External ID for vendor trust.
• No Principal: "*".

---

3. Authorization

Least Privilege

• Explicit Allow on specific actions and ARNs.
• Avoid *:* and broad service wildcards.
• Use IAM Access Analyzer for unused-permission findings and policy generation.
• Right-size based on observed CloudTrail usage.

Permission Boundaries

• For delegated IAM administration.
• Required on principal creation (iam:PermissionsBoundary condition).
• Boundary denies its own removal.

Service Control Policies (SCPs)

• Baseline guardrails: deny root, deny public S3, region restriction, deny disabling CloudTrail/GuardDuty/Security Hub, deny IMDSv1.
• Per-OU scoping (sandbox vs prod).
• Version-controlled.

Resource Control Policies

• Where available, enforce resource-side restrictions across the org.

Tag-Based Access Control

• Where appropriate, use ABAC for self-service environments.

---

4. Privileged Access

Minimize Standing Admins

• Few persistent administrator-equivalent identities.
• Use just-in-time access (Identity Center session policies, custom approval workflows).

Privileged Tasks via Break-Glass

• Specific high-privilege roles assumable only with MFA + approval + monitoring.

Tier IAM Roles

• Tier 0 (cross-cutting privileged): tightly governed, monitored, low session duration.
• Tier 1 (workload admins): boundaries + SCPs.
• Tier 2 (read / power users): broader but capped.

---

5. Cross-Account and Multi-Account

Multi-Account Architecture

• Workload, security, log, sandbox accounts separated.
• Use AWS Control Tower or equivalent for account factory + baseline.

Cross-Account Access

• IAM roles with tight trust.
• aws:PrincipalOrgID for org-internal.
• External ID for third parties.
• Tag with vendor / purpose.
• Decommission on offboarding.

Centralized Logging

• CloudTrail, VPC Flow Logs, Config to dedicated logging account.
• Immutable bucket; long retention; WORM if required.

Centralized Security

• Security account with audit roles in members.
• GuardDuty, Security Hub, Macie aggregation.
• Forestall connected at organization level.

---

6. Detection and Response

CloudTrail Everywhere

• Multi-region trail.
• Management + data events for sensitive resources.
• Centralized + immutable.

GuardDuty / Security Hub / Macie

• Enabled across accounts.
• Findings centralized and triaged.

Identity-Specific Detections

• New IAM user creation.
• New AdministratorAccess assignment.
• Trust policy change.
• Access key creation / leak.
• Console login from unusual IP.
• Unusual AssumeRole patterns.
• Root sign-in.

Incident Response Playbooks

• Compromised IAM user / role / key.
• Rogue admin.
• S3 public exposure.
• Tabletop exercises.

---

7. Governance

Inventory

• All accounts known and owned.
• All IAM principals tagged with owner / purpose.
• All Permission Sets documented.

Lifecycle

• Joiner / mover / leaver workflows update IAM access.
• Quarterly cleanup of inactive identities.

Reviews

• Quarterly access reviews for privileged roles and Permission Sets.
• Annual review of broader access and trust relationships.

Policy as Code

• IAM policies, SCPs, boundaries in Git.
• Peer review on changes.
• Automated validation (cfn-policy-validator, Access Analyzer policy validation).

---

8. Recovery

Break-Glass Procedure

• Documented process for using root or emergency admin.
• Hardware MFA stored in safe with chain of custody.
• Tested periodically.

Backup of IAM Configuration

• Some elements (Identity Center config, SCPs) tracked in IaC for restore.
• Policy versions retained.

---

9. Continuous Improvement

Track Metrics

• Number of standing admins.
• Number of long-lived keys > 90 days.
• Open IAM Access Analyzer findings.
• Public S3 buckets.
• MFA adoption.
• Quarterly trend.

Use a Posture Tool

• Forestall (or equivalent) for continuous attack-path analysis and prioritized remediation.

Quarterly Identity Review

• Top risks reported to leadership.
• Remediation tracked.

---

Quick Best-Practice Summary

• Identity Center for humans.
• Roles + STS + federation for everything else.
• MFA everywhere, hardware where it matters.
• Least privilege; Access Analyzer-driven.
• Permission Boundaries for delegated admin.
• SCPs for org guardrails.
• Centralized CloudTrail and security tooling.
• Identity-focused detection in SIEM.
• Quarterly reviews and metrics.

---

How Forestall Helps

Forestall translates these best practices into continuous, prioritized work:

• Posture scoring against best practices.
• Attack-path analysis to admin and data.
• Risk-ranked findings with remediation guidance.
• Trend tracking for your identity security KPIs.

---

Conclusion

AWS IAM security is a discipline, not a feature. Implement these best practices in tiers — start with the highest-impact (Identity Center, MFA, root lockdown, eliminate *:*, baseline SCPs, CloudTrail centralization) and expand outward. Measure quarterly. With these in place, AWS becomes one of the most defensible identity environments you operate.