AWS re/Start Lab · Seguridad

Introduction to AWS Identity and Access Management (IAM)

This lab explores the core concepts of AWS IAM. Discover how to create and enforce account-wide password policies, organize resources utilizing user groups and policies, and enforce least-privilege permissions through practical testing.

Lab Summary

Configured an IAM password policy, analyzed managed and inline JSON policies, attached users to logical User Groups, and systematically tested positive/negative authorizations.

Hardening Authentication

Upgraded the account password posture by enacting stricter policies requiring lengthier and more complex strings to hinder brute-force attacks.

Role-Based Testing

Authenticated as three separate users representing distinct roles (S3 Support, EC2 Support, and EC2 Admin) to validate that each identity was explicitly denied capabilities beyond their provisioned scope.

Step-by-Step Walkthrough

Detailed documentation of creating security policies and testing IAM roles.

01

Create an account password policy

  • Accessed Account settings in the IAM dashboard to review the default authentication security constraints.
  • Redefined the minimum password length to 10 characters and required alphanumeric characters and symbols to increase complexity.
Modified password policies
IAM Dashboard: Saving the updated account-level password policies
02

Explore users, groups, and policies

  • Reviewed the pre-created users (user-1, user-2, user-3). Verified none of them possessed direct attached permissions.
  • Inspected the pre-created user groups (S3-Support, EC2-Support, EC2-Admin).
  • Examined the core IAM JSON policies driving the privileges for each group:

EC2-Support

Managed: AmazonEC2ReadOnlyAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:GetSecurityGroupsForVpc"
      ],
      "Resource": "*"
    },
    ...
  ]
}

S3-Support

Managed: AmazonS3ReadOnlyAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*",
        ...
      ],
      "Resource": "*"
    }
  ]
}

EC2-Admin

Customer Inline Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": ["*"],
      "Effect": "Allow"
    }
  ]
}
03

Add users to user groups

  • Assigned user-1 to the S3-Support group.
  • Assigned user-2 to the EC2-Support group.
  • Assigned user-3 to the EC2-Admin group.
  • Verified all three groups possessed exactly one assigned user.
Users assigned to groups
IAM Dashboard: Confirming group assignments for the new hires
04

Sign in and test user permissions

  • Signed in as user-1 (S3-Support). Verified successful read access to an S3 bucket but received an API error when attempting to fetch the EC2 Instances list, demonstrating the restrictive policy effectively blocking access outside S3.
User 1 accessing S3 successfully
user-1: Allowed S3 read actions
User 1 failing to access EC2
user-1: Denied EC2 access via API error message
  • Signed in as user-2 (EC2-Support). Verified ability to view the EC2 instance list. Attempted to execute Stop instance and correctly received an "unauthorized operation" failure message since the role only holds read-only privileges.
User 2 failing to stop EC2
user-2: Implicit Deny triggers an error when issuing modifying actions on EC2
  • Signed in as user-3 (EC2-Admin). Was successfully able to execute the Stop instance action due to the inline policy containing the explicitly defined ec2:StopInstances action array map.
User 3 successfully stopping EC2
user-3: Functionality verified per the assigned EC2-Admin capabilities

Key Learnings

What Was Actually Learned

✓
How to strictly enforce an Account Password Policy across all identities within an organization.
✓
Differences between heavily reusable Managed Policies and single-use Customer Inline Policies.
✓
How the default architecture of IAM revolves around an Implicit Deny, requiring explicit allows via an Effect block.
✓
How to validate permissions by actually assuming the roles to emulate and troubleshoot endpoint behaviors.

Technical Conclusion

This lab underscored the importance of applying the Principle of Least Privilege in cloud environments. It highlighted a scalable approach by applying permissions directly to logical groups rather than individuals natively avoiding convoluted, contradictory, or abandoned direct permission mappings.

Understanding how to read JSON-structured policies, with their Effect, Action, and Resource blocks, is an instrumental skill for debugging API failures shown actively through simulated user testing in this lab exercise.