Day 06 – IAM for Beginners – The Ultimate Guide to AWS Security

Welcome to Day 6 of your AWS 30-Day Roadmap.

In the last five days, we have built servers (EC2), stored files (S3), and toured the dashboard. It has been exciting. But today, we need to have a serious conversation.

The Cloud is powerful, but it is also dangerous. If you leave the keys to your house under the doormat, you will get robbed. If you leave your AWS keys exposed, you will wake up to a $50,000 bill because hackers used your account to mine Bitcoin.

Today, we learn how to lock the door.

IAM (Identity and Access Management) is the gatekeeper of AWS. It is the service that answers two simple questions:

1. Authentication: Who are you?
2. Authorization: What are you allowed to do?

In this ultimate guide, we will move beyond the basics. We will dissect the “Four Pillars” of IAM, learn to read the JSON code that controls the internet, and set up Multi-Factor Authentication (MFA) to make your account bulletproof.

The Metaphor (The Nightclub)

To understand IAM, forget about computers for a second. Imagine a high-end Nightclub.

1. The Bouncer (IAM): Standing at the door. He checks IDs and lists.
2. The Patron (User): A specific person (You, your developer, your boss). They have an ID badge.
3. The VIP List (Group): A list of people. If you are on the “VIP List,” you get into the VIP lounge. If you are on the “Staff List,” you get into the kitchen.
4. The Wristband (Role): A temporary pass. Maybe you are a regular patron, but the DJ hands you a “Backstage Wristband.” For the next hour, you can go backstage. When you take it off, you lose that access.
5. The House Rules (Policy): A sign on the wall. “No shirt, no shoes, no service.” Or “VIPs can drink free, Regulars must pay.”

In AWS, these are the 4 Pillars of IAM: Users, Groups, Roles, and Policies.

The Root User vs. IAM User (The Owner vs. The Employee)

We mentioned this on Day 3, but it bears repeating because it is the #1 security risk.

The Root User

• Who is it? The email address used to create the AWS account.
• Power: Infinite. It can delete the account, change billing, and access everything.
• Restriction: You cannot restrict the Root User. You cannot write a policy that says “Root User cannot delete S3 buckets.”
• Best Practice: Create the account, create an IAM Admin User, enable MFA on Root, and then lock the Root password in a physical safe. Never use it again unless absolutely necessary.

The IAM User

• Who is it? A sub-account created by you.
• Power: Zero by default. An IAM user starts with no permissions. They cannot even view the dashboard until you allow it.
• Best Practice: Create a unique IAM User for every physical person in your company. Never share passwords.

The 4 Pillars Deep Dive

Let’s break down the technical definitions.

1. IAM Users (The People)

An entity that represents a person or service.

• Credentials: Users can have a Password (for the Console) and Access Keys (for the Command Line/Code).
• Note: A User can belong to multiple Groups.

2. IAM Groups (The Teams)

A collection of users.

• Why use them? Efficiency. Instead of attaching the “Admin Policy” to Bob, Alice, and Charlie individually, you create an “Admins” Group, attach the policy to the Group, and add the users to it.
• Rule: If you remove Bob from the group, he instantly loses those permissions.

3. IAM Policies (The Rules)

A document that defines permissions. This is the logic engine of AWS.

• Managed Policies: Pre-written by AWS (e.g., AdministratorAccess, AmazonS3ReadOnlyAccess). Great for beginners.
• Customer Managed Policies: Written by you. (e.g., “Allow access to only this specific bucket”).

4. IAM Roles (The Hats)

This is the most confusing concept for beginners.

• A User has long-term credentials (password).
• A Role has no password. It relies on temporary security tokens.
• Who uses Roles?
  1. AWS Services: An EC2 server needs a Role to upload files to S3.
  2. External Users: A corporate user logging in via Single Sign-On (SSO).
  3. Cross-Account Access: Someone from Account A needing to do something in Account B.
• Analogy: Putting on a firefighter’s uniform. While you wear it, you have the authority to break down doors. When you take it off, you are just a civilian again.

Reading the Matrix (JSON Policies Explained)

IAM Policies are written in JSON (JavaScript Object Notation). You don’t need to be a coder to read them. They follow a simple grammar:

The Structure:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-secret-bucket"
    }
  ]
}

The Translation:

1. Effect: Do we “Allow” or “Deny”? (Usually Allow).
2. Action: What is the verb? (Here, s3:ListBucket means “Look inside the bucket”).
3. Resource: What is the object? (Here, it is specifically my-secret-bucket).

The “Power of Deny”: If a user has one policy that says “Allow S3” and another policy that says “Deny S3”, the Deny wins. Always. This is called an Explicit Deny.

The Principle of Least Privilege (POLP)

This is the Golden Rule of Security.

“Grant only the permissions required to perform the task, and nothing more.”

• Bad Practice: Giving your developer AdministratorAccess because you are too lazy to figure out what they need.
• Good Practice: Giving your developer AmazonEC2FullAccess and AmazonS3ReadOnlyAccess because that is all they need to do their job.
• Why? If that developer’s laptop gets hacked, the hacker can only touch EC2 and S3. They cannot delete your billing info or databases.

Hands-On Lab (Securing Your Account)

Let’s make your account safe. We will enable MFA and create a daily driver user.

Step 1: Activate MFA on Root (Do this NOW)

1. Log in as Root.
2. Click your account name (top right) -> Security Credentials.
3. Find Multi-factor authentication (MFA).
4. Click Assign MFA device.
5. Name it RootMFA.
6. Select Authenticator app (Free).
7. Download “Google Authenticator” or “Authy” on your phone.
8. Scan the QR code.
9. Enter the two codes displayed on your phone.
10. Done: Your account is now 99% harder to hack.

Step 2: Create an Admin Group

1. Go to the IAM Dashboard.
2. Click User groups -> Create group.
3. Name: AdminGroup.
4. Scroll to Attach permissions policies.
5. Search for AdministratorAccess. Check the box.
6. Click Create group.

Step 3: Create Your IAM User

1. Click Users -> Create user.
2. Username: cloud-admin (or your name).
3. Check Provide user access to the AWS Management Console.
4. Select I want to create an IAM user.
5. Set a Custom Password. Uncheck “Users must create a new password” (since it’s for you).
6. Click Next.

Step 4: Add User to Group

1. Select Add user to group.
2. Check the box next to AdminGroup.
3. Click Next -> Create user.
4. Download the .csv file containing your login link and credentials.

Step 5: The Test

1. Log out of the Root account.
2. Use the login link from the .csv file.
3. Log in as cloud-admin.
4. Success: You are now using AWS safely!

IAM Credential Report (The Audit)

How do you know if your employees are using secure passwords? Or if they have MFA enabled?

You run the Credential Report.

1. Go to IAM Dashboard -> Credential report (left menu).
2. Click Download Report.
3. It gives you a CSV file listing every user, when they last logged in, if they have MFA, and if they have rotated their keys recently.
4. Audit this monthly.

Conclusion & Summary

You have now secured the perimeter. You understand that IAM is not just about creating users, but about defining the logic of access.

Key Takeaways:

1. MFA Everything: Root user and all IAM users should have MFA.
2. No Root: Stop using the root account today.
3. Groups are Good: Manage permissions via Groups, not individual Users.
4. Least Privilege: Start with zero access and add only what is needed.

Tomorrow, on Day 7, we return to infrastructure. We will look at Amazon EBS (Elastic Block Store) and EFS (Elastic File System). We will learn how to attach hard drives to servers and how to create shared network drives.

Stay secure.