AWS, GCP, Azure cloud security: the 10 most common IAM mistakes

IAM: the front door to your cloud

Identity and Access Management is your cloud infrastructure's access control system. An IAM misconfiguration doesn't just create a flaw: it gives an attacker the keys to your entire environment. The most publicized cloud breaches (Capital One, Twitch, Microsoft) all involve IAM mistakes.

Mistake 1: static access keys in code

AWS access keys or GCP service account keys committed to source code. Bots scan GitHub in real time. A published key is exploited within 30 minutes on average.

Fix: use IAM roles for services, managed identities for virtual machines, and a secrets manager for cases where a key is necessary.

Mistake 2: admin permissions on application users

A backend service with AdministratorAccess on AWS or the Owner role on GCP. The application only needs to read/write to a DynamoDB table, but it has permissions to delete the entire account.

Fix: least privilege principle. Create policies that grant only the exact permissions needed.

Mistake 3: no MFA on root and admin accounts

The AWS root account without MFA is accessible with just an email and password. A successful phishing attack gives total access to the infrastructure.

Fix: hardware MFA (YubiKey) on all accounts with elevated privileges. No exceptions.

Mistake 4: assumable roles without conditions

An IAM role assumable by any service in the account, or worse, by any AWS account via an overly broad trust policy. "Principal": "*" in a trust policy is an open door.

Fix: specify exactly which principals can assume each role, with conditions on source IP or session tags.

Mistake 5: GCP service accounts with downloaded keys

Creating a JSON key for a GCP service account and distributing it to developers or storing it on a server. These keys never expire and are impossible to trace.

Fix: use Workload Identity Federation for access from outside GCP. For internal services, use the service account attached to the instance.

Mistake 6: public S3 / Cloud Storage buckets

Default settings have improved, but buckets remain publicly accessible through misconfiguration. Exposed data ranges from database backups to customer files.

Fix: block public access at the organization level with S3 Block Public Access or GCP Organization Policies.

Mistake 7: no credential rotation

Access keys created three years ago, service account passwords never changed. The longer a credential lives, the more likely it is to be compromised.

Fix: automatic rotation every 90 days maximum. Prefer temporary credentials (STS, Workload Identity).

Mistake 8: CloudTrail / Audit Logs disabled or incomplete

Without audit logs, it's impossible to detect a breach or perform post-incident forensics. Some SMBs disable logs to save on storage costs.

Fix: enable CloudTrail (AWS), Cloud Audit Logs (GCP), Activity Log (Azure) across all regions and services.

Mistake 9: wildcard policies

"Resource": "*" and "Action": "s3:*" in the same policy. The application has access to every S3 bucket in the account instead of just the one it needs.

Fix: specify exact resource ARNs. Use IAM Access Analyzer to identify excessive permissions.

Mistake 10: no separation between environments

Production, staging, and development in the same cloud account with the same credentials. A developer with staging access also has production access.

Fix: one account/project per environment. Use AWS Organizations or GCP Folders for governance.

Our approach

At CleanIssue, we systematically check IAM configuration during our cloud infrastructure audits. Request your audit call to identify your configuration mistakes.