Excessive permissions by default: the easy path that becomes costly
A common practice in many organizations is assigning roles or policies with overly broad permissions to “save time” or “avoid blocking deliveries.” The classic AdministratorAccess, or even custom policies that end with wildcards like "Action": "*", become the rule rather than the exception.
This often begins as a temporary measure—during an incident or a migration—and remains in place due to a lack of subsequent review. The result is an unnecessary attack surface. We’ve seen cases where a developer with broad IAM permissions was able to create persistent users undetected, merely because no control prevented it.
- Full service access without justification: granting a team EC2 permissions with
*instead of limiting to start/stop/reboot if they don’t need to create or modify instances. - Reusing policies from other accounts: copying policies from a sandbox to production without reviewing the context leads to dangerous outcomes, like enabling write access to sensitive buckets.
The anti-pattern here is assuming that documenting the correct usage of permissions is enough to avoid misuse. It’s not. In security, what is not explicitly forbidden is allowed.
Poorly segmented policies due to lack of a clear role model
Another common mistake arises from not establishing a clear model of roles, groups, and their relationships. We often find dozens (even hundreds) of policies with similar names, duplicated permissions, and no traceability of who uses what.
This complicates both maintenance and audits. We’ve worked with companies where simply removing a permission required weeks of functional review due to fear of breaking some invisible integration.
- Poor segmentation: bundling permissions from multiple domains (e.g., S3, Lambda, and RDS) into a single policy makes it harder to enforce the principle of least privilege.
- Misused IAM groups: granting permissions through groups without periodically reviewing their members ends up creating “Frankenstein groups” with accumulated privileges no one dares to touch.
We suggest working with a task-based model, not a team-based one. The “backend team” is not the same as “users who need to deploy Lambda functions.”
Lack of rotation and control over persistent credentials
In many companies, IAM users with persistent access keys remain active for years without rotation or usage tracking. We’ve seen organizations where offboarded developers still had active keys connected to old pipelines that no one dares to dismantle.
AWS IAM does not enforce an expiration or key rotation policy by default. It’s up to the security team to establish limits and automation to enforce this practice.
- Access keys without rotation: active keys for over 90 days without a documented purpose or review pose a high risk.
- Keys in code: another recurring issue in CI/CD is embedding keys in scripts or repositories, which worsens the impact in case of exfiltration.
An effective policy combines automated notifications, continuous auditing via CloudTrail, and periodic recertification by each key’s owner.
Ignoring the use of IAM Access Analyzer or CloudTrail as control tools
IAM offers powerful tools to mitigate human error, such as IAM Access Analyzer and CloudTrail logs. Nonetheless, many companies still have them disabled or without real monitoring. It’s not uncommon to hear: “we didn’t even know Access Analyzer existed.”
These tools help detect when a policy unintentionally grants public or cross-account access. They also help understand how permissions are actually being used, which is essential input for safely reducing privileges.
A typical case we encounter is the exposure of S3 buckets or Lambda functions to other accounts due to resource policy errors. Access Analyzer would have raised an alert in minutes, but no one had configured it.
Not using these functionalities is like operating a production environment blindly: functionally, everything might seem fine, but from a security standpoint, it’s a huge blind spot.
Recommendations for corporate environments
The IAM management errors in AWS we’ve described are not hypothetical: we see them repeatedly in companies with complex structures, large teams, and business pressures. The common denominator is the lack of proactive governance over the permission lifecycle.
We propose the following as priority action lines:
- Systematically review and reduce wildcard
*policies. - Adopt an explicit model of roles and tasks, with defined ownership per permission.
- Audit and enforce key rotation, with automated alert mechanisms.
- Enable and monitor tools like IAM Access Analyzer and CloudTrail in all accounts.
Maturity in IAM is not achieved just by good configuration, but through good operations: monitoring, reviewing, revoking, and above all, having real access control at all times.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.