How to Audit AWS IAM Permissions: Step-by-Step Guide
From listing roles to identifying over-privileged accounts: a practical walkthrough.
TL;DRBlog Key takeaways
• How to Audit AWS IAM Permissions: Step-by-Step Guide: A step-by-step guide to auditing AWS IAM roles, finding wildcard permissions, and producing least-privilege recommendations.
• Devopsify provides a tenant-scoped control plane with governed execution and audit.
• AI assistance is read-only and proposal-based; humans approve.
• Try the pattern in demo mode with zero credentials.
Devopsify is a tenant-scoped infrastructure control plane that unifies multi-cloud inventory, topology, governed provisioning, delivery operations, audit, and AI-assisted investigation under one declarative graph. From listing roles to identifying over-privileged accounts: a practical walkthrough. This post examines the practical steps, trade-offs, and operational signals that make the pattern reviewable and auditable, from inventory discovery to policy evaluation and deployment waves.
Why IAM audits matter
AWS IAM is the first line of defense for cloud security. Over-privileged roles create attack surfaces, stale credentials become liability, and wildcard permissions (`*:*`) are the most common root cause of security incidents. Regular IAM audits catch these issues before they're exploited. This guide walks through a systematic approach to auditing IAM roles, identifying risks, and producing actionable recommendations.
Step 1: Inventory all IAM entities
Start by enumerating all IAM roles, users, and groups in your account. Use `aws iam list-roles --query 'Roles[?RoleName!=`AWSServiceRoleFor*`]' --output json` to get all user-created roles, excluding service-linked roles. For users, run `aws iam list-users --query 'Users[?UserName!=`root`]'`. Document each entity's creation date, last accessed timestamp (via IAM Access Advisor), and attached policies.
Step 2: Identify wildcard permissions
Wildcard permissions (`Action: '*'` or `Resource: '*'`) are the highest-risk patterns. Run `aws iam get-role-policy --role-name <name> --policy-name inline` for each role's inline policies, and `aws iam list-attached-role-policies --role-name <name>` for managed policies. Look for statements where Action or Resource is `*`. Flag any that grant access to sensitive services like `iam:*`, `organizations:*`, or `ec2:*` without scoping to specific resources.
aws iam list-roles ──▶ enumerate all roles │ ├──▶ aws iam list-attached-role-policies ──▶ check managed policies │ ├──▶ aws iam get-role-policy ──▶ check inline policies │ └──▶ flag wildcard actions/resources ──▶ prioritize remediation
Step 3: Check for unused permissions
IAM Access Advisor shows which services each role has actually used in the past 90 days. Run `aws iam get-access-last-used --access-last-used-detailed-information` for each role. Roles with permissions but no usage history for 90+ days are candidates for permission reduction. Cross-reference with CloudTrail logs to verify whether the role was ever assumed during that period.
Audit checklist
- List all roles and their attached policies
- Flag wildcard Action or Resource statements
- Check IAM Access Advisor for unused permissions
- Verify MFA requirements on privileged roles
- Review cross-account trust policies
- Document findings and remediation priorities
| Aspect | Without Devopsify | With Devopsify |
|---|---|---|
| Inventory | Siloed consoles | ✓ Unified graph |
| Policy | Manual review | ✓ Pre-apply gate |
| Audit | Screenshots | ✓ Per-change trail |
How does this pattern fit your operating model?
- Connect read-first via SDK adapters or on-prem agents.
- Discover drift and topology on schedule.
- Govern attach policy and approvals.
- Operate propose with AI, approve as human, execute with audit.
Common Questions
How does Devopsify ensure the pattern is auditable?
Every proposed change carries its inventory snapshot, policy result, required approvals, and execution result as one traceable record: no gaps, no screenshots.
Can I try this without credentials?
Yes. Demo mode uses labeled mock data. Walk the same inventory, policy, and AI investigation flows with zero cloud credentials.
Does AI execute changes?
No. AI investigates and proposes; humans approve and policy gates enforce. Execution is platform-only and fully audited.
References
Cover photo via Openverse under a Creative Commons license. Illustrative imagery only.
This is a pattern, not a promise.
Every story here is an illustrative implementation pattern. To verify one against your own estate, start in demo mode (zero credentials) or request guided access.
Approvals and audit for a regulated payments estate
A payments platform needed regulated changes to be provable, not just recorded. Here is how policy gates, approvals, and a signed audit trail replaced screenshots as the evidence of record.
Read the story
Firefly vs Devopsify: Which Cloud Asset Management Tool?
A side-by-side comparison of Firefly and Devopsify for cloud asset management, covering discovery depth, policy gating, and audit trail.
Read the story
Spacelift vs Devopsify: IaC Governance Showdown
Comparing Spacelift's plan governance with Devopsify's broader control plane that spans inventory, policy, and delivery.
Read the story