📚 AWS SECURITY ENGINEERING

IAM Misconfigurations & Hardening Strategies

Learn to identify and eliminate common IAM misconfigurations. Master the principles and tactical patterns that transform weak IAM into enterprise-grade security architecture.

⚠️ COMMON MISCONFIGURATIONS

Common IAM Misconfigurations

These patterns appear in 90% of organizations. Fixing them is the foundation of IAM hardening.

❌

1. Wildcard Permissions (iam:*, s3:*, *)

Policies that grant broad permissions using wildcards are the most dangerous misconfiguration.

❌ PROBLEM: Developer role with "iam:*" can create new admin roles and assume them. Full privilege escalation with a single compromised credential.

{ "Effect": "Allow", "Action": "iam:*", "Resource": "*" }

✓ SOLUTION: Replace wildcards with explicit actions. Developer only needs to assume their specific role.

                            { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource":
                            "arn:aws:iam::ACCOUNT:role/Developer" }
                        

🔓

2. Lack of MFA Enforcement

Not requiring MFA for sensitive operations leaves accounts vulnerable to credential theft.

❌ PROBLEM: IAM user with access keys (no MFA required) gets compromised. Attacker has instant full access—no second factor to block them.

                            // Vulnerable: No MFA condition { "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }
                        

✓ SOLUTION: Require MFA for all sensitive operations (console access, role assumption, credential management).

                            { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "*", "Condition": { "Bool":
                            {"aws:MultiFactorAuthPresent": "true"} } }
                        

🔗

3. Role Chaining Without Visibility

Allowing unlimited role chaining creates lateral movement paths that are difficult to audit and contain.

❌ PROBLEM: Lambda role can assume any cross-account role (wildcard in AssumeRole principal). Attacker uses Lambda to chain through 5+ roles to reach admin in another account.

{ "Effect": "Allow", "Principal": "*", "Action": "sts:AssumeRole" }

✓ SOLUTION: Explicit role chaining. Lambda can assume ONLY specific roles needed for its function.

                            { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT1:role/Lambda" }, "Action":
                            "sts:AssumeRole" }
                        

👥

4. Over-Permissioned Service Roles

Service roles (EC2, Lambda, ECS) with excessive permissions become targets for exploitation.

❌ PROBLEM: EC2 instance role has "s3:*" on all buckets. Attacker exploits EC2 vulnerability, gains role credentials, exfiltrates entire S3 data lake.

✓ SOLUTION: Least-privilege service roles. EC2 only gets explicit S3 buckets and actions it actually needs.

                            { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [
                            "arn:aws:s3:::app-bucket/logs/*" ] }
                        

🚪

5. Wildcard Trust Relationships

Role trust policies allowing any principal in an account (or any account) to assume the role.

❌ PROBLEM: Role trust allows "Principal": "*" or any AWS account. Malicious actor from outside your organization assumes your sensitive role.

{ "Effect": "Allow", "Principal": "*", "Action": "sts:AssumeRole" }

✓ SOLUTION: Explicit trust relationships. Only specific principals (users, services, cross-account roles) can assume sensitive roles.

                            { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/specific-user" },
                            "Action": "sts:AssumeRole" }
                        

⏰

6. No Session Duration Limits

Session tokens without expiration or duration limits allow indefinite access after compromise.

❌ PROBLEM: Service role with 12-hour session duration. Attacker obtains session token. Can operate for full 12 hours undetected.

✓ SOLUTION: Short session durations (1 hour max). Forces credential refresh and limits window of exposure.

                            // Set max session duration to 1 hour (3600 seconds) { "MaxSessionDuration": 3600 }
                        

🛡️ HARDENING PRINCIPLES

IAM Hardening Principles

Transform IAM from a security liability into an impenetrable access control system.

🎯

Principle 1: Least Privilege

Grant ONLY the minimum permissions needed for a principal to perform its function. Start with zero permissions. Add only explicit, required actions. Default to deny.

✂️

Principle 2: Policy Segmentation

Break permissions into focused policies by role, environment, and function. Separate read-only from write permissions. Separate management from operational access.

🔄

Principle 3: Regular Access Reviews

Audit permissions monthly. Remove unused roles and principals. Update policies as job functions change. Document justification for each permission.

⚙️ Least Privilege Architecture Pattern

Step 1: Define the Job Function
Document EXACTLY what the principal needs to do. Example: "Lambda function that reads from S3 bucket X and writes CloudWatch logs."

Step 2: Map to AWS Actions
Convert functional requirements to specific IAM actions. Example: s3:GetObject, logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents.

Step 3: Restrict to Resources
Limit actions to ONLY the required resources. Example: Allow s3:GetObject only on "arn:aws:s3:::app-bucket/inputs/*", NOT on all buckets.

Step 4: Add Conditions (When Applicable)
Time-based restrictions, IP restrictions, MFA requirements, encryption requirements. Example: "Deny S3 DeleteObject unless encrypted with customer-managed keys."

Policy Segmentation Strategy

Policy Type	Purpose	Attachment
Identity-Based Policies	Define what a principal (user/role) can do	Attached to users, groups, roles
Resource-Based Policies	Define who can access a resource (S3 bucket, SQS queue, etc.)	Attached to resources
Permission Boundaries	Set max permissions ceiling for a role	Attached to roles as safety guardrail
Session Policies	Further restrict permissions during role assumption	Applied when assuming role temporarily
SCPs (Service Control Policies)	Organizational-level permission boundaries	Applied to AWS accounts in organization

📋 Access Review Checklist (Monthly)

✓ List all active IAM users and roles
✓ Verify last access date for each principal (CloudTrail)
✓ Identify unused roles/users (no activity in 30 days)
✓ Review all policies with wildcard permissions (*)
✓ Verify MFA is enforced for console access
✓ Audit cross-account role trust relationships
✓ Check for unused access keys (rotate or delete)
✓ Validate service role permissions match documented job functions
✓ Test that Deny policies are working as intended
✓ Document findings and remediation plan

🏗️ ARCHITECTURE PATTERNS

Secure Architecture Patterns

Industry-proven patterns for deploying IAM at scale without sacrificing security.

🌍 Pattern 1: Multi-Account Security Model

Organize AWS accounts by function (logging, security, development, production, data). This creates natural boundaries that prevent lateral movement.

                        Architecture:

                        [Root Org] → [Security Account] → [Logging + Monitoring]

                                                        →
                        [Dev Account]

                                                        →
                        [Prod Account] (restricted cross-account access)

                                                        →
                        [Data Account] (no internet access)
                    

Benefits:

✓ Blast radius containment: Compromise in dev doesn't affect prod
✓ Clear trust boundaries: Cross-account roles explicitly define allowed access
✓ Audit-friendly: Logging centralized in security account
✓ Scalable: Add new workloads in new accounts without changing core security

👥 Pattern 2: Role-Based Security Planning

Create a matrix of roles your organization needs. Define permissions for each role ONCE, then assign users/services to roles. Simplifies management and reduces errors.

Role Matrix Example:

Role	Purpose	Key Permissions
DevOps-Pipeline	CI/CD automation	EC2:Describe, CodeDeploy:, S3 artifacts
App-Service	Application runtime	RDS:DescribeDB*, S3:GetObject, Secrets:GetSecretValue
Security-Audit	Read-only compliance auditing	:Describe, :Get, :List (no write/delete)
Admin-Break-Glass	Emergency-only full access	* (but requires MFA + approval log)

Benefits:

✓ Consistency: All devops engineers get same permissions
✓ Simplicity: Developers think in roles, not individual actions
✓ Compliance: Audit role definitions (not 100 individual policies)
✓ Agility: Add new user to role, instant right permissions

🔐 Pattern 3: Privileged Access Workstations (PAW)

For sensitive operations (admin tasks, production changes), use dedicated, hardened workstations with strong MFA and audit logging.

Implementation:

✓ PAW is separate from daily work computer (no email, browsing)
✓ Requires hardware MFA (U2F/FIDO2, not SMS)
✓ All actions logged to centralized SIEM
✓ Access to PAW role itself requires MFA
✓ Network isolation: PAW can only reach AWS, not internet

📚 RESOURCES

External Learning References

Deepen your understanding of IAM hardening with official AWS whitepapers and architecture guides:

🎓

Verified Certificate Notice

Complete all 3 modules of this AWS Security Engineering course to unlock your
Verified Cyber Security Certificate from
MONEY MITRA NETWORK ACADEMY

📌 Unique Certificate ID • 🔐 QR Code Verification • 📜 Digital Credentials

✓ Module 2 Complete — Ready for Module 3