AWS Certified Security – Specialty: IAM, Access Control & Data Protection

Mastering AWS Identity and Access Management (IAM) is the cornerstone of cloud security. Whether you're preventing unauthorized access, enabling cross-account workflows, or protecting sensitive data at rest and in transit, nearly every AWS security decision flows through IAM concepts. This lesson covers the full spectrum — from policy structure and role trust relationships to encryption, temporary credentials, and centralized access management — giving you the depth needed to ace your Security Specialty exam.

---

IAM Fundamentals: Users, Groups, and Roles

IAM Users and Groups

IAM Users are individual identities with long-term credentials (passwords, access keys).

IAM Groups are collections of users that share the same permissions — attach a policy to a group and all members inherit it. This simplifies permission management at scale.

IAM Roles

Roles are the preferred identity mechanism for services and applications. Unlike users, roles have no long-term credentials — they issue temporary security tokens via AWS STS (Security Token Service).

Why roles over users for EC2?

No hardcoded credentials in code or config files

Credentials rotate automatically

Follows least privilege by scoping permissions to the task

// Example: EC2 Instance Profile Role Policy
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*"
  }]
}

Trust Relationships

Every role has a trust policy that defines *who can assume the role* (the principal). This is separate from the permissions policy.

// Trust policy allowing EC2 to assume the role
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

---

IAM Policy Structure

Every IAM policy is a JSON document with these key elements:

Conditions and Tags

Conditions make policies dynamic and precise. Use them to enforce least privilege:

// Allow S3 access only to buckets starting with 'dev-'
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::dev-*",
    "arn:aws:s3:::dev-*/*"
  ]
}

Tag-based conditions let you scope access to resources with specific tags:

"Condition": {
  "StringEquals": { "aws:ResourceTag/Environment": "dev" }
}

IP restrictions prevent access from outside approved networks:

"Condition": {
  "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}

aws:SourceArn is used in resource-based policies to restrict which service or resource can invoke an action — critical for preventing the *confused deputy* problem.

---

Policy Evaluation Logic

AWS evaluates policies in this order:

Explicit Deny — always wins, no exceptions

Explicit Allow — grants access

Implicit Deny — default if no allow exists

Service Control Policies (SCPs) in AWS Organizations act as guardrails. Even if an IAM policy allows an action, an SCP can block it organization-wide. SCPs do not grant permissions — they only restrict them.

---

Least Privilege Principle

Grant only the permissions needed to perform a specific task — nothing more. Practical strategies:

Start with AWS managed policies, then tighten with customer-managed policies

Use IAM Access Analyzer to identify unused permissions and external access

Regularly review with Security Auditing tools (CloudTrail, Access Advisor)

Use conditions to scope by resource name, tag, IP, or MFA status

---

Cross-Account Access

To grant access across AWS accounts securely:

Create a role in the target account with a trust policy allowing the source account's principal

Attach permissions to the role for the needed resources (e.g., S3 bucket)

The source account's user/role calls sts:AssumeRole to get temporary credentials

// Trust policy in Account B allowing Account A to assume the role
{
  "Principal": { "AWS": "arn:aws:iam::ACCOUNT-A-ID:root" },
  "Action": "sts:AssumeRole"
}

For S3 cross-account access, you can also use a bucket policy on the S3 resource itself — but combining both a role and a bucket policy is the most secure approach.

---

STS and Temporary Credentials

AWS Security Token Service (STS) issues short-lived credentials (Access Key ID, Secret Access Key, Session Token). These are used by:

EC2 instance profiles

Lambda execution roles

Cross-account role assumptions

Identity federation (SSO)

Temporary credentials expire automatically, reducing the blast radius of a credential leak.

---

IAM Identity Center and SSO

IAM Identity Center (formerly AWS SSO) provides centralized access management across multiple AWS accounts and applications. It integrates with external identity providers (Okta, Azure AD) and issues temporary credentials via SAML/OIDC. This eliminates the need for individual IAM users in every account.

---

MFA Enforcement

Require MFA for sensitive actions using conditions:

"Condition": {
  "Bool": { "aws:MultiFactorAuthPresent": "true" }
}

---

Data Protection: Encryption, SSL/TLS

S3, DynamoDB, and RDS

S3: Enable server-side encryption (SSE-S3, SSE-KMS) and versioning to protect against accidental deletion

DynamoDB: Encryption at rest is enabled by default using AWS-managed keys

RDS: Enable encryption at creation; enforce SSL/TLS connections using parameter groups and IAM policies with aws:SecureTransport

// Deny unencrypted S3 connections
"Condition": {
  "Bool": { "aws:SecureTransport": "false" }
}

---

IAM Troubleshooting

Common issues and fixes:

Use IAM Access Analyzer and CloudTrail logs to trace permission failures.

---

Key Takeaways

IAM Roles with STS temporary credentials are always preferred over long-term access keys for services like EC2 and Lambda — no hardcoded secrets, automatic rotation.

Policy evaluation follows a strict hierarchy: explicit Deny > explicit Allow > implicit Deny; SCPs layer on top as organizational guardrails.

Conditions (IP, MFA, tags, aws:SourceArn) are the primary tool for enforcing least privilege beyond simple Allow/Deny.

Cross-account access requires a properly configured trust relationship in the target account's role, and optionally a resource-based policy on services like S3.

IAM Identity Center centralizes SSO and access management across accounts, while IAM Access Analyzer continuously audits for over-permissive or externally accessible resources.