🔐 AWS IAM: Identity, Access Management, and Security Best Practices

AWS Identity and Access Management (IAM) is one of the most important services in AWS, as it governs who can access resources and what actions they can perform. Misconfiguration can lead to serious vulnerabilities such as unauthorized access to S3 buckets or EC2 instances.

This blog post covers IAM fundamentals, types of users, policies, roles, groups, patterns, and best practices for securing your AWS environment.

👤 IAM Users and Credentials

Users represent individuals or applications that interact with AWS services. They can access AWS via:

• AWS Console (using passwords)
• SDK or CLI (using access keys)

Types of Credentials:

• Password: For console logins
• Access Keys: Programmatic access (Access Key ID + Secret Access Key)

📄 IAM Policies

Policies are JSON documents that define what actions are allowed or denied. They attach to IAM users, groups, or roles.

Types of Policies:

• Identity Policies: Attached to IAM users, groups, or roles.
• Resource Policies: Attached directly to AWS resources (e.g., S3, SNS).

🧰 Identity Policies

Inline Policies

• Applied directly to a specific user or role
• Not reusable; suitable for one off permissions

Managed Policies

• Standalone IAM resources
• Reusable and scalable
• Automatically update permissions across multiple users

Policy Document Structure

1{
2"Version": "2012-10-17",
3"Statement": [
4  {
5    "Effect": "Allow",
6    "Action": "ec2:RunInstances",
7    "Resource": "arn:aws:ec2:*:057285111279:instance/*"
8  }
9]
10}

🧱 Policy Components

• Effect: Either Allow or Deny
• Action: Service and method (e.g., s3:GetObject, ec2:RunInstances)
• Resource: ARN specifying the resources affected

📌 Resource Policies

Attached directly to services (e.g., S3, Lambda). Define who (principal) can access the resource and what actions they can take.

Example

1{
2"Effect": "Allow",
3"Principal": {"AWS": ["arn:aws:iam::account-id:user/username"]},
4"Action": "s3:*",
5"Resource": ["arn:aws:s3:::mybucket", "arn:aws:s3:::mybucket/*"]
6}

👥 IAM Groups

Groups are collections of users that share the same policies.

• Simplify permission management for large teams
• Policies attached to groups are inherited by all members

🛡️ IAM Roles

Roles grant temporary access to AWS services and do not require passwords or access keys. They are assumed by

• AWS services (e.g., EC2, Lambda)
• Other AWS accounts
• Federated users (e.g., using SAML, web identity)

Role Requirements:

• Attached policies (managed or inline)
• Trust relationships (who can assume the role)

🔁 IAM Patterns

AWS Managed Policies

• Predefined by AWS
• Easy to use but may grant broad permissions

Custom Role Patterns

• Split roles for better control (e.g., Master vs Manager roles)
• Prevent privilege escalation by separating duties

🏢 Managing Multiple Accounts

Use AWS Organizations to manage multiple accounts under a single hierarchy.

• Designate a management account
• Use Service Control Policies (SCPs) to enforce guardrails
• Deny unwanted actions across child accounts

🧠 Threat Modeling and Best Practices

Threat Modeling

• Build architecture diagrams
• List IAM entities
• Simulate attack vectors (spoofing, privilege escalation, etc.)

IAM Best Practices

• Enable MFA
• Use strong password policies
• Rotate access keys regularly
• Implement least privilege
• Prefer Session Manager over SSH

🔐 Password Policy Options

⚖️ Least Privilege Access Challenges

• Hard to predict necessary permissions
• Time consuming to write precise policies
• Requires ongoing monitoring and tuning

📌 Conclusion

AWS IAM is central to securing your cloud infrastructure. By combining users, roles, policies, and best practices, you can enforce strict access controls, meet compliance requirements, and reduce your attack surface.