The State of Cloud IAM
After reviewing hundreds of AWS environments as a Cloud IAM Engineer, I've compiled the most dangerous IAM misconfigurations that I encounter repeatedly. These aren't theoretical risks — I've exploited every one of these in authorized penetration tests.
1. Wildcard Resource Permissions
The most common and dangerous pattern is using "Resource": "*" in IAM policies. This grants the specified actions across ALL resources in the account, not just the intended ones. I've seen S3 full access policies meant for a single bucket that inadvertently exposed every bucket in the account.
2. Overly Permissive AssumeRole Trust Policies
Role trust policies that allow sts:AssumeRole from overly broad principals create lateral movement opportunities. A compromised low-privilege role can escalate to high-privilege roles if the trust relationships aren't properly scoped.
3. IAM Users with Long-lived Access Keys
Static access keys that never rotate are ticking time bombs. I've found access keys in source code, environment variables, and CI/CD configurations that were over 2 years old and still active.
4. Missing Permission Boundaries
Without permission boundaries, any principal that can create IAM roles can create roles with more permissions than they have themselves. This is a well-known privilege escalation path that's trivial to exploit.
Defensive Recommendations
Implement SCPs at the organization level, use permission boundaries for all delegated administration, rotate credentials automatically, and adopt ABAC where possible to reduce policy complexity.