AWS Authentication & Secure Access

Identity and Permissions Control

Authentication vs. Authorization

Understanding the fundamental distinction: proving who you are versus defining what actions you are permitted to perform.

Figure 1: Authentication (Who are you?) vs. Authorization (What can you do?).

1

Authentication (AuthN)

Verifies the identity of a user, application, or service requesting access:

Identity Verification: Confirms who is initiating the connection request.
Credentials Used: Usernames & passwords, Access Keys, Multi-Factor Authentication (MFA) tokens.
Example: Logging into the AWS Management Console with your email, password, and Google Authenticator MFA code.

2

Authorization (AuthZ)

Determines the permissions and actions an authenticated identity is allowed to perform:

Access Governance: Governs which resources can be interacted with.
Mechanism: Checked and enforced through IAM Policies (Allow, Read-Only, Explicit Deny).
Example: Allowing a user to download files from an S3 bucket, but blocking them from deleting objects.

The Bank Analogy

Authentication: You walk into a bank and show your government-issued ID card and signature to prove you are the account owner.
Authorization: Once verified, the bank clerk allows you to withdraw cash from your own checking account, but denies you access to another customer's safety deposit box.

💡

Exam Tips & Memory Tricks

Mnemonic: Authentication = Who? | Authorization = What?
Sequence: Authentication always happens before authorization. You must prove who you are before AWS evaluates your permissions.
Service: AWS Identity and Access Management (IAM) handles both authentication and authorization centrally in your cloud network.

Access Management Engine

AWS Identity & Access Management (IAM)

IAM securely manages access to AWS services, enforcing authentication constraints and granular authorization rules.

Figure 2: AWS IAM Components and Features.

Key Components of IAM

👤

IAM User

Represents a specific person or service account with long-term (permanent) credentials.

Console login or permanent API keys.

👥

IAM Group

A collection of IAM users. Permissions attached to the group are inherited by all its member users.

Example: Developers or Admins groups.

🎭

IAM Role

An identity offering short-term, temporary credentials. Used for resource/delegated access.

Assumed by services (EC2) or users.

📄

IAM Policy

A JSON document defining resource permissions. Can be attached to Users, Groups, or Roles.

Enforces Allow, Read, Deny structures.

MFA & Identity Federation

Multi-Factor Authentication (MFA): Adds an extra layer of protection by requiring a secondary verification code (software app or hardware device) alongside user password.
Federated Identity Management: Enables Single Sign-On (SSO). Users can sign in using existing enterprise directory credentials (e.g. Microsoft Active Directory, Okta) without duplicate logins.

IAM Core Features

Secure by Default: A newly created IAM user has zero access permissions by default. Access must be explicitly granted using IAM policies.
Granular Control: Enforces highly specific rules, such as allowing access to a single file in a bucket, or restricting access to specific time windows or IP addresses.

🧠

Mnemonic Trick: I A M

I — Identity Management (User, Group, Role)
A — Access Control (JSON Policies, Allow/Deny)
M — Minimum Permissions (Least Privilege Enforcement)

IAM Structure Definitions

IAM Terminology and Resource Classification

Establishing clear boundaries between IAM resources, entities, identities, and requesting principals.

Figure 3: Mapping of IAM Resources, Entities, Identities, and Principals.

📦

IAM Resource

Any configuration object created and stored within IAM service.

Includes: Users, Groups, Roles, Policies, Identity Providers.

🔐

IAM Entity

Objects managed by AWS to authenticate a request.

Includes: Users and Roles.

🆔

IAM Identity

Objects to which you can attach permission policies.

Includes: Users, Groups, and Roles.

👤

Principal

The person, application, or process making an AWS API request.

Includes: Root user, IAM User, IAM Role, Federated user.

💡

Exam Matrix Questions

Q: Which elements are considered IAM entities? ✅ Users and Roles (Group is not an entity as it cannot be used to authenticate).
Q: Which elements are IAM identities (can attach policies)? ✅ Users, Groups, and Roles.
Q: What is a Principal? ✅ The entity requesting a transaction.

Access Architecture

Using IAM to Control Access to AWS Resources

How Users, Groups, Roles, and Policies interface to dictate operational permissions in your AWS environment.

Figure 4: Diagram showcasing S3 Bucket access control via IAM policies.

IAM Component	Credential Type	Common Use Case	Best Practice Recommendation
IAM User	Permanent (Long-Term) passwords/access keys	Individual developers, administrative accounts, static application scripts	Avoid using for applications; enforce strict password policies and MFA.
IAM Group	None (inherits policies)	Assigning permissions to departments (Developers, Auditors, Finance)	Attach policies to groups rather than users. Manage group membership.
IAM Role	Temporary (Short-Term) credentials via STS	AWS Services (EC2/Lambda), cross-account operations, federated Single Sign-On	Prefer roles over long-term access keys for application permissions.
IAM Policy	JSON ruleset mapping Allow/Deny	Defining access boundaries for AWS buckets, resources, and databases	Build fine-grained custom policies enforcing Least Privilege.

API vs. Console Access

IAM Credentials for Authentication

Depending on how you interact with AWS (Console, Command Line Interface, or SDKs), different credentials are required.

Figure 5: Console Credentials (Password) vs. Programmatic Credentials (Access Keys).

1. Console Authentication

Logging into the AWS web interface:

Credentials: Account ID/Alias + Username + Password.
Security: Always require MFA (Multi-Factor Authentication).
Usage: Manual configuration, resource monitoring, and console testing.

2. Programmatic Authentication (CLI/SDK/API)

Accessing AWS via terminal or application code:

Credentials: Access Key ID + Secret Access Key.
Access Key ID: public identifier (like a username).
Secret Access Key: private credential (like a password).
Limitation: You cannot log in to the CLI or run API scripts using console password.

Credential Mapping Cheat-Sheet

AWS Interaction Method	Access Type	Required Credentials
AWS Management Console	User Interface / Web	Username + Password (+ MFA recommended)
AWS Command Line Interface (CLI)	Programmatic Access	Access Key ID + Secret Access Key
AWS Software Development Kit (SDK) / API	Programmatic Access	Access Key ID + Secret Access Key

Security Controls

AWS IAM Best Practices

Key architectural regulations recommended by AWS to secure identities, protect programmatic access, and lock down account boundaries.

Figure 6: AWS Identity and Access Management Best Practices.

🛡️

1. Least Privilege

Grant only the absolute minimum permissions required to perform daily work functions.

🔐

2. Enforce MFA

Activate MFA for all administrative users and highly privileged accounts (e.g. root user).

🎭

3. Use Temporary Credentials

Prefer IAM Roles over static programmatic access keys inside virtual machines or application code.

🔄

4. Rotate Access Keys

Regularly rotate program access keys and revoke any unused keys to minimize compromise risks.

🏢

5. Centralize Accounts

Use AWS Organizations to centrally manage multiple billing, security, and access accounts.

🕵️

6. Audit API Calls

Enable AWS CloudTrail to log, monitor, and audit all security configuration and API requests.

Protecting the AWS Root User

Unrestricted Access: The root account is created with your email address and has full, un-lockable control over everything.
Daily Operations: Do NOT use the root user for everyday tasks. Lock it away.
Root Security: Enable strong MFA, select a complex unique password, and keep credentials secure.

Best Practices for Root Account

Create Administrative IAM Accounts: Use AWS IAM Identity Center to define a daily administrative user with limited but powerful permissions.
Monitor with CloudTrail: Set alerts to notify security teams immediately if the root credentials are used to authenticate.
Restricted Use Cases: Only log in as root for billing modifications, closing the account, or overriding S3 bucket lock policies.

Steps to Securely Initialize an Admin Account

Figure 7: 5-Step Process to set up an administrative user and secure the root account.

1

Root Setup & MFA

Sign in as the root user. Immediately set up Multi-Factor Authentication (MFA) to guard the login interface.

2

Create Admin User

Configure a separate admin user (using IAM Identity Center or IAM). Attach Administrator access policy and enable MFA.

3

Root Sign-Out

Sign out of the root user account to ensure you do not use it for daily configuration work.

4

Sign in as Admin

Authenticate with the new administrator credentials for all future resource configuration tasks.

5

Initialize IAM User Directory

Create individual IAM users for each engineer or process. Attach specific JSON policies to groups to guarantee Principle of Least Privilege.

Policy Attachment Practices

Attaching IAM Policies & Permissions Inheritance

Simplifying cloud identity governance by using IAM groups to manage policies collectively, rather than patching users individually.

Figure 8: Best practice of attaching policies to IAM groups instead of individual users.

Group Policy Inheritance (Best Practice)

Group policy configurations are highly recommended:

Process: Create groups based on jobs (e.g. Sales, DevOps, Accounting). Attach the policies directly to the group.
Inheritance: Users added to the group automatically inherit all attached policy permissions.
Management: Revoking or adding access is handled centrally by editing the group policy once.

Direct User Policies (Exception Case)

Attaching policies directly to a user is supported but should be minimized:

Purpose: Granting custom, unique permissions to a single user without editing the group.
Example: A developer in the "Developers" group needs temporary write access to an S3 archive bucket for a debugging task.

Temporary Access Delegation

IAM Roles: Safe Access Delegation

Using roles to authorize AWS resources, applications, and cross-account users with temporary credentials instead of permanent keys.

Figure 9: IAM Roles delegating temporary security credentials.

IAM Roles Characteristics

Temporary Credentials: Delivers short-term security keys that automatically expire.
No permanent passwords: Does not store long-term passwords or access keys on EC2.
Assumed by: AWS services (EC2/Lambda), federated users, and cross-account identities.

Instance Profiles

How EC2 instances assume IAM Roles:

Definition: A container for an IAM Role.
Process: Associate the IAM role with an Instance Profile, and attach that profile to the EC2 instance.
Security: Allows EC2 apps to query S3 buckets safely without embedding hardcoded access keys in code files.

IAM Role Delegation Scenarios

Scenario 1: IAM User accessing EC2 App

An IAM user in your AWS account requires temporary permission to access an application running on an EC2 instance. By assuming an Instance Access Role, AWS yields temporary credentials to execute the transaction.

Authentication &Secure Access