In many cloud security reviews, Identity and Access Management (IAM) often turns out to be the weakest area. AWS provides powerful tools to control access, but its defaults are permissive and administrators often grant overly broad rights.
The result is predictable: accounts with far more privilege than needed, with API keys that never expire, and compliance risks that stand out during audits.
This article sets out how to design IAM in AWS with least privilege as the guiding principle.
1. Why AWS IAM Matters
-
Cloud is identity-driven: Whoever controls IAM controls the account.
-
Attack surface: Compromised keys or over-privileged users often lead directly to data exposure.
-
Compliance: Standards such as ISO27001, PCI DSS, and GDPR expect robust identity controls.
-
Business risk: In one case a developer had full admin rights to production and the ability to delete S3 buckets! That is unacceptable in any regulated environment which aims to be secure.
2. Principles of Least Privilege
-
Grant only the permissions required for a task.
-
Assign permissions to roles, not to individual users.
-
Regularly review policies and remove unused rights.
-
Enforce MFA for all human users.
IAM design should start from these principles and never from convenience.
3. Users, Groups, and Roles
AWS IAM supports three main identity types:
-
Users: Individual accounts for people. I recommend minimising these. Where possible, use federation (e.g. SSO with AD or IAM Identity Center).
-
Groups: Collections of users. Attach policies to groups, not directly to users.
-
Roles: Temporary credentials assumed by users or services. Roles are the preferred method for granting access.
Organisations that rely heavily on IAM users with permanent keys tend to end up with uncontrolled sprawl. Using roles is much more secure and auditable.
4. IAM Policies
Policies define what actions are permitted.
-
Avoid wildcards like
Action: "*"orResource: "*". These grant unlimited access. -
Write policies as narrowly as possible.
-
Use AWS-managed policies carefully. They are broad and often exceed what is needed.
Example of an overly permissive policy I often see:
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
A secure equivalent would scope to a single service and resource:
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::project-bucket/*"
}
5. Key Management
AWS IAM users can create access keys for API access. Misuse of keys is one of the top security issues.
Best practices:
-
Avoid static keys where possible — use roles instead.
-
Rotate keys regularly.
-
Delete unused keys.
-
Store keys securely, never in source code.
Beware of pushing hardcoded IAM keys out to a public GitHub repository. This immediately leads to compromise!
6. Multi-Factor Authentication (MFA)
MFA is mandatory for all IAM users with console access.
-
Enforce MFA using IAM policies.
-
Hardware MFA devices (YubiKey, etc.) are preferable to SMS.
-
AWS supports virtual MFA apps for lower-cost deployments.
I have seen instances where administrators had full rights but no MFA. No need to point out that this is a direct path to compromise!
7. IAM Roles for EC2 and Services
Instead of embedding keys into servers, assign IAM roles to EC2 instances or Lambda functions.
-
Roles provide temporary credentials rotated automatically by AWS.
-
This prevents key sprawl and simplifies audits.
-
For EC2, attach roles via instance profiles.
Example: an application server that needs access to a specific S3 bucket should have a role with only s3:GetObject on that bucket. Nothing more.
8. Monitoring and Logging
IAM events must be logged.
-
Enable CloudTrail in all regions.
-
Use GuardDuty to detect suspicious IAM activity.
-
Set up alarms for policy changes, new key creation, and failed logins.
CloudTrail logs may reveal a compromised IAM user creating new keys at unusual times. Without logging, the breach would have been missed.
9. Reviewing IAM Regularly
IAM should not be static. Reviews should occur at least quarterly:
-
Remove inactive users.
-
Disable unused keys.
-
Check policies for wildcards.
-
Confirm MFA is enabled for all users.
AWS provides IAM Access Analyzer to help identify overly permissive policies. I recommend running it routinely.
10. Compliance and Governance
Strong IAM practices map directly to compliance requirements.
-
GDPR expects data access to be restricted to what is necessary.
-
ISO27001 requires user access reviews.
-
PCI DSS demands MFA for administrators.
Being able to show evidence of IAM controls makes audits far easier.
Conclusion
IAM in AWS is both powerful and dangerous. Poorly designed IAM can undo every other security control. By minimising IAM users, enforcing MFA, using roles, writing narrow policies, and logging all activity, organisations can significantly reduce their cloud risk.
In my experience, most cloud compromises I see stem largely from weak IAM. Fixing IAM early on is one of the most effective steps in securing AWS systems.
Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.
With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.