AWS IAM Security Best Practices — Why Over-Permissive Access Is Your Biggest Cloud Risk

Source: Dev.to

TL;DR

I audited a Series A startup’s AWS account last year. Seven developers, all with AdministratorAccess. Three inactive accounts from people who’d left the company — still enabled, still with full permissions. Root account with no MFA. No API key rotation in 18 months. This is not unusual; it’s the norm. IAM misconfiguration is the number‑one cloud attack vector — and fixing it costs nothing but time. Here’s exactly what to fix.

Why IAM matters

AWS Identity and Access Management (IAM) is the system that controls who can do what in your AWS account. Every API call, every console login, every automated process that touches your cloud infrastructure goes through IAM.

If IAM is misconfigured, every other security control is undermined — an attacker with the right IAM credentials can:

• read your data,
• modify your infrastructure,
• delete your backups, and
• exfiltrate everything you’ve built.

According to the CrowdStrike 2025 Global Threat Report, cloud‑related breaches increased 75 % year‑over‑year in 2024, with credential‑based attacks and IAM misconfigurations consistently cited as the primary entry point. This isn’t a sophisticated attack class — it’s the exploitation of access controls that were never configured correctly in the first place.

Common problems I see

1. Everyone has AdministratorAccess
AdministratorAccess is the AWS equivalent of giving every employee a master key to every system, database, and configuration in the company. Developers need it to move fast in the early days, but the problem is it never gets removed. By the time a company reaches Series A, the entire engineering team typically still has full administrative rights they’ve never needed and shouldn’t have.

2. Inactive accounts from former employees remain enabled
   When someone leaves, their IAM user needs to be disabled and eventually deleted. This step is regularly skipped — either because off‑boarding checklists don’t include it, or because “we’ll do it next sprint.” Three months later, the account is forgotten but still active. A former employee — or an attacker who compromised their email and triggered a password reset — has full access to your production environment.

3. Root account used for day‑to‑day operations
   The AWS root account is the account you created when you first signed up. It cannot be restricted by IAM policies — it has absolute, unrestricted access to everything. It should never be used for day‑to‑day operations, and its access keys should never exist. Almost every startup audit I run finds the root account actively used, and often no MFA enabled on it.

4. Long‑lived access keys never rotated
   IAM access keys (the AKIA… key ID and secret) grant programmatic API access. Unlike passwords, they don’t expire by default. Keys created 18–24 months ago — possibly assigned to developers who’ve since left or to decommissioned applications — are still valid and represent exploitable credentials if they’ve been leaked anywhere.

5. Service accounts with admin permissions
   When a developer needs a service to access AWS — a deployment pipeline, a Lambda function, a third‑party integration — the quickest solution is an IAM user with broad permissions. The correct solution is an IAM role with the minimum permissions that specific service needs. Service accounts with AdministratorAccess are one compromised application away from full account takeover.

6. No IAM permission boundaries or Service Control Policies (SCPs)
   In multi‑developer accounts, there’s nothing preventing a developer with IAM permissions from escalating their own privileges — creating a new admin user, attaching an admin policy to themselves, or assuming a role with broader permissions. Permission boundaries and SCPs are the guardrails that prevent this, and they’re rarely configured in early‑stage accounts.

Principle: Least privilege

Least privilege means every identity — human or machine — has access only to what it needs to perform its function, and nothing more.

Examples for AWS IAM

Do not use s3:* on * or AdministratorAccess unless absolutely necessary.

Practical approach

1. Start with broader permissions
2. Enable AWS CloudTrail and IAM Access Analyzer
3. Use the data those tools generate to identify what each role actually uses
4. Scope permissions down to match reality

AWS’s IAM Access Advisor shows the last time each permission was used, making it straightforward to identify and remove unused permissions.

Step‑by‑step remediation checklist

Use IAM roles instead of … (the original text ended here; continue with your organization’s specific guidance)

Final note

Fixing IAM misconfigurations is free in terms of money; it only costs time and discipline. Implement the steps above, enforce least‑privilege policies, and you’ll dramatically reduce the most common cloud attack vector. 🚀

IAM Best Practices

• Use IAM roles instead of long‑lived access keys

  • IAM roles are assumed temporarily and issue short‑lived credentials automatically.
  • They have no static access keys that can be leaked or forgotten.
  • Any service running in AWS — EC2 instances, Lambda functions, ECS containers — should authenticate via an IAM role, not a long‑lived access key.

• Enforce MFA on all human IAM users

  • Attach an IAM policy that denies all actions unless MFA has been used in the current session.
  • This two‑minute implementation eliminates credential‑only compromise for human accounts.
  • AWS provides example MFA‑enforcement policies in their documentation.

• Never use the root account operationally

  • Create a dedicated admin IAM user for administrative tasks.
  • Enable MFA on that admin user.
  • Lock the root account credentials away and use them only for account‑level operations that strictly require root.

Typical Attack Chain

1. Obtain a valid credential

   • Leaked access key in a public GitHub repository.
   • SSRF vulnerability that hits the EC2 metadata endpoint and returns instance‑role credentials.
   • Phishing attack against a developer.

2. Enumerate permissions

   • Tools like Pacu (an open‑source AWS exploitation framework) automate this step: “what can this credential actually do?”

3. Privilege escalation

   • If the compromised credential has iam:CreateUser, iam:AttachUserPolicy, or iam:PassRole permissions, the attacker can:
     • Create a new admin user, or
     • Escalate to a higher‑privilege role.
   • From there the entire account is compromised – every service, data store, and secret.

This is not a theoretical scenario. It is documented in real breaches and in AWS’s own security guidance.

Helpful AWS‑Native and Open‑Source Tools

Run Prowler against your AWS account

pip install prowler
prowler aws --services iam

These steps and tools will help you harden IAM, detect misconfigurations, and reduce the risk of credential‑based attacks.