🔐 IAM Fundamentals

Level: Foundation Solves: Thiết kế và quản lý identity & access management theo chuẩn enterprise security

🎯 Mục tiêu (Outcomes)

Sau khi áp dụng kiến thức trong trang này, bạn sẽ có khả năng:

Thiết kế IAM Strategy theo nguyên tắc least privilege cho tổ chức enterprise
Triển khai Role-Based Access thay thế hoàn toàn IAM Users cho human access
Xây dựng Cross-Account Access an toàn với ExternalId và MFA requirements
Áp dụng Permission Boundaries cho delegated administration
Cấu hình IAM Access Analyzer để phát hiện và remediate access risks
Thiết lập Access Auditing với CloudTrail và automated compliance checks

✅ Khi nào dùng

IAM Roles (Ưu tiên sử dụng)

Use Case	Tại sao dùng Role	Ví dụ
Human access	Temporary credentials, SSO integration	Developer assume role để deploy
EC2/Lambda/ECS	Instance profiles, automatic rotation	Lambda function access S3
Cross-account	No credential sharing, auditable	CI/CD từ account A deploy sang account B
Third-party integrations	ExternalId protection	SaaS vendor access logs

IAM Users (Hạn chế tối đa)

Use Case	Tại sao vẫn cần	Biện pháp bảo vệ
Programmatic access (legacy)	Một số tools chưa support AssumeRole	Access key rotation 90 ngày
Break glass accounts	Emergency access khi SSO down	Hardware MFA, sealed envelope
Service accounts (exceptional)	Services không support roles	Strict IP conditions, key rotation

❌ Khi nào KHÔNG dùng

Pattern	Vấn đề	Thay thế
IAM Users cho developers	Long-term credentials, khó revoke	SSO + AssumeRole
Shared IAM credentials	Không thể audit ai làm gì	Individual identities
Hardcoded access keys	Security breach chờ xảy ra	IAM Roles + Secrets Manager
Wildcard permissions	Blast radius vô hạn	Scoped policies với conditions
Root user cho daily operations	Ultimate privilege, không audit được	IAM Roles với MFA

⚠️ Cảnh báo từ Raizo

"Tôi đã forensic vụ breach của một công ty. Nguyên nhân? Developer commit AWS access key lên GitHub public repo. Key có AdministratorAccess. Hacker phát hiện trong 15 phút, spin lên 200 EC2 mining crypto. Bill $50,000 trong 2 ngày. Nếu dùng IAM Roles, chuyện này KHÔNG THỂ xảy ra."

Core Concepts

Principal Types

┌─────────────────────────────────────────────────────────────────┐
│                    IAM PRINCIPAL TYPES                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │  IAM User   │  │  IAM Role   │  │  Federated  │              │
│  │             │  │             │  │   Identity  │              │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘              │
│         │                │                │                     │
│         ▼                ▼                ▼                     │
│  • Long-term creds  • Temporary creds  • External IdP           │
│  • Access keys      • AssumeRole       • SAML/OIDC              │
│  • Console password • Trust policy     • SSO                    │
│                                                                 │
│  ⚠️ ENTERPRISE RECOMMENDATION:                                  │
│  • NO IAM Users for humans → Use SSO/Identity Center            │
│  • IAM Users ONLY for service accounts (with rotation)          │
│  • Prefer IAM Roles for everything                              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Policy Evaluation Logic

Least Privilege Implementation

Anti-Pattern: Overly Permissive

json

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

❌ Tại sao đây là anti-pattern?

Cho phép DELETE tất cả buckets
Cho phép PUBLIC access configuration
Không giới hạn resource scope
Không có conditions

Best Practice: Scoped Permissions

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadFromSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-data-bucket",
        "arn:aws:s3:::my-app-data-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/team": "data-engineering"
        },
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    }
  ]
}

Role Assumption Pattern

Cross-Account Access

┌─────────────────────────────────────────────────────────────────┐
│                 CROSS-ACCOUNT ROLE ASSUMPTION                   │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Account A (Source)              Account B (Target)             │
│  ┌─────────────────┐            ┌─────────────────┐             │
│  │                 │            │                 │             │
│  │  ┌───────────┐  │            │  ┌───────────┐  │             │
│  │  │ IAM Role  │  │  AssumeRole│  │ IAM Role  │  │             │
│  │  │ (Caller)  │──┼────────────┼─►│ (Target)  │  │             │
│  │  └───────────┘  │            │  └───────────┘  │             │
│  │                 │            │       │         │             │
│  │                 │            │       ▼         │             │
│  │                 │            │  ┌───────────┐  │             │
│  │                 │            │  │ Resources │  │             │
│  │                 │            │  └───────────┘  │             │
│  └─────────────────┘            └─────────────────┘             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Trust Policy (Target Role)

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CrossAccountCaller"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

💡 External ID

External ID ngăn chặn "confused deputy" attack. Luôn sử dụng khi cho phép third-party assume role vào account của bạn.

Permission Boundaries

Use Case: Delegated Administration

┌─────────────────────────────────────────────────────────────────┐
│              PERMISSION BOUNDARY CONCEPT                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │              Permission Boundary                         │    │
│  │  ┌───────────────────────────────────────────────────┐  │    │
│  │  │                                                   │  │    │
│  │  │    ┌─────────────────────────────────────┐        │  │    │
│  │  │    │      Identity Policy                │        │  │    │
│  │  │    │                                     │        │  │    │
│  │  │    │   ████████ EFFECTIVE ████████       │        │  │    │
│  │  │    │   ████████ PERMISSIONS ██████       │        │  │    │
│  │  │    │                                     │        │  │    │
│  │  │    └─────────────────────────────────────┘        │  │    │
│  │  │                                                   │  │    │
│  │  └───────────────────────────────────────────────────┘  │    │
│  │                                                         │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  Effective = Identity Policy ∩ Permission Boundary              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Permission Boundary Policy

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "cloudwatch:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:AttachUserPolicy",
        "iam:AttachRolePolicy",
        "iam:PutUserPolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::*:policy/DeveloperBoundary"
        }
      }
    }
  ]
}

IAM Access Analyzer

Finding Types

Finding Type	Description	Severity
External Access	Resource accessible from outside account	High
Cross-Account	Resource shared with another account	Medium
Public Access	Resource publicly accessible	Critical
Unused Access	Permissions not used in 90 days	Low

Automated Remediation

Auditing & Compliance

CloudTrail IAM Events

json

{
  "eventSource": "iam.amazonaws.com",
  "eventName": "AttachRolePolicy",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAEXAMPLE:admin-session",
    "arn": "arn:aws:sts::123456789012:assumed-role/AdminRole/admin-session"
  },
  "requestParameters": {
    "roleName": "ProductionRole",
    "policyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
  }
}

Key Events to Monitor

CreateUser, DeleteUser
CreateRole, DeleteRole
AttachUserPolicy, AttachRolePolicy
CreateAccessKey, DeleteAccessKey
UpdateAssumeRolePolicy
PutUserPermissionsBoundary

Best Practices Checklist

[ ] No IAM Users for human access (use SSO)
[ ] MFA required for all console access
[ ] Access keys rotated every 90 days
[ ] Permission boundaries for delegated admin
[ ] IAM Access Analyzer enabled
[ ] CloudTrail logging all IAM events
[ ] Regular access reviews (quarterly)
[ ] Unused credentials disabled after 90 days

⚖️ Trade-offs

Trade-off 1: Security vs Developer Experience

Khía cạnh	Strict IAM	Relaxed IAM
Security posture	Minimized blast radius	Larger attack surface
Developer velocity	Chậm hơn, cần request permissions	Nhanh hơn, ít friction
Operational overhead	Cao, cần process governance	Thấp
Audit readiness	Dễ dàng demonstrate compliance	Khó justify trong audits

Ngữ cảnh enterprise: Team Platform của một fintech phải balance giữa PCI-DSS compliance và developer productivity. Họ implement "tiered access":

Tier 1 (Production): Strict least-privilege, break-glass only
Tier 2 (Staging): Moderate permissions với approval workflow
Tier 3 (Dev/Sandbox): Broader permissions nhưng vẫn có boundaries

Trade-off 2: Centralized vs Decentralized IAM Management

Khía cạnh	Centralized (Platform team)	Decentralized (Each team)
Consistency	Uniform policies	Policy drift possible
Agility	Bottleneck tại platform team	Teams tự phục vụ
Expertise	Concentrated, deep	Distributed, varied
Governance	Easier to enforce	Harder to monitor

Khuyến nghị: Hybrid approach:

Centralized: Permission Boundaries, SCPs, core security policies
Decentralized: Teams tự tạo roles TRONG boundaries đã định

Trade-off 3: Fine-grained vs Coarse-grained Policies

Khía cạnh	Fine-grained	Coarse-grained
Policy size	Nhiều statements, complex	Ít statements, simple
Maintenance	Cần update thường xuyên	Ổn định hơn
Blast radius	Nhỏ nhất có thể	Lớn hơn
Debugging	Khó hơn khi access denied	Dễ troubleshoot

Ví dụ thực tế:

json

// Fine-grained (khuyến nghị cho production)
{
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::bucket/prefix/${aws:PrincipalTag/team}/*"
}

// Coarse-grained (chỉ cho dev/sandbox)
{
  "Action": ["s3:*"],
  "Resource": "arn:aws:s3:::dev-*"
}

🚨 Failure Modes

Failure Mode 1: Privilege Escalation qua iam:PassRole

🔥 Incident Pattern

Developer có quyền iam:PassRole và lambda:CreateFunction. Họ tạo Lambda function với AdminRole attached, execute code với full admin privileges trong account.

Cách phát hiện	Cách phòng tránh
CloudTrail monitor `iam:PassRole` events	Restrict PassRole to specific roles với conditions
Detect Lambda/EC2 với high-privilege roles	SCP deny PassRole cho admin roles
Access Analyzer unused permissions	Regular review roles có thể bị passed

Policy để prevent:

json

{
  "Sid": "RestrictPassRole",
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::*:role/Lambda-*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

Failure Mode 2: Stale Credentials và Unused Permissions

┌─────────────────────────────────────────────────────────────────┐
│                 CREDENTIAL LIFECYCLE PROBLEM                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Day 1:              Day 90:             Day 365:               │
│  ┌────────────┐      ┌────────────┐      ┌────────────┐         │
│  │ Key created│  →   │ Still active│  →  │ COMPROMISED│         │
│  │ for project│      │ project done│     │ attacker   │         │
│  │ XYZ        │      │ key unused  │     │ uses key   │         │
│  └────────────┘      └────────────┘      └────────────┘         │
│                                                                 │
│  Root cause: Không có lifecycle management                      │
└─────────────────────────────────────────────────────────────────┘

Cách phát hiện	Cách phòng tránh
IAM Credential Report	Automated key rotation policy
Access Analyzer unused access findings	90-day inactive credential disable
CloudTrail last used analysis	Automated cleanup Lambda

Failure Mode 3: Policy Conflicts và Unexpected Denies

Cách phát hiện	Cách phòng tránh
Developer reports "Access Denied" unexpectedly	Document policy interaction matrix
IAM Policy Simulator testing	Test policies trước khi deploy
CloudTrail với `errorCode: AccessDenied`	Alert on unusual deny patterns

Debug workflow:

bash

# Sử dụng Policy Simulator
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/MyRole \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/my-key

🔐 Security Baseline

IAM Configuration Requirements

Requirement	Implementation	Verification
No human IAM Users	SSO/Identity Center mandatory	Config Rule: `iam-user-no-policies-check`
MFA everywhere	SSO MFA + AssumeRole MFA	Credential Report + CloudTrail
Password policy	14+ chars, complexity, 90-day rotation	`iam-password-policy` Config Rule
Access key rotation	90-day maximum	Custom Lambda + Credential Report
Root user lockdown	No access keys, MFA enabled	`root-account-mfa-enabled`

Keys/Secrets Management

┌─────────────────────────────────────────────────────────────────┐
│               IAM CREDENTIAL HIERARCHY                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Level 1 - Root (NEVER USE):                                    │
│  └── Root credentials → Sealed envelope, vault, hardware MFA    │
│                                                                 │
│  Level 2 - Admin (Rare use):                                    │
│  └── Break-glass IAM User → Hardware MFA, 2-person rule         │
│                                                                 │
│  Level 3 - Operations (Daily use):                              │
│  └── SSO → Permission Sets → AssumeRole per account             │
│                                                                 │
│  Level 4 - Applications:                                        │
│  └── IAM Roles → Instance Profiles, Task Roles                  │
│  └── Service Accounts → If needed, Secrets Manager rotation     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Data Access Patterns

Principal Type	Allowed Data Access	Restrictions
Developers (SSO)	Dev/Staging data only	No production PII
CI/CD Roles	Deploy artifacts, configs	No data plane access
Application Roles	Specific resources per service	Least privilege, tagged resources
Audit Roles	Read-only, logs only	No data plane, cross-account aggregate

📊 Ops Readiness

Metrics cần Monitoring

Metric	Nguồn	Alert Threshold
IAM Users với console access	IAM API	> 0 (ngoại trừ break-glass)
Access keys > 90 ngày	Credential Report	> 0
Roles với AdminPolicy	IAM API	Spike pattern
AssumeRole failures	CloudTrail	> 10/hour per principal
Access Analyzer findings	Access Analyzer	Critical/High > 0
Unused permissions	Access Analyzer	Review weekly

Alerting Configuration

json

{
  "EventPattern": {
    "source": ["aws.iam"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventSource": ["iam.amazonaws.com"],
      "eventName": [
        "CreateUser",
        "CreateAccessKey",
        "AttachUserPolicy",
        "AttachRolePolicy",
        "PutRolePolicy",
        "UpdateAssumeRolePolicy"
      ]
    }
  }
}

Runbook Entry Points

Tình huống	Runbook
Access key leaked	`runbook/credential-compromise.md`
Privilege escalation detected	`runbook/privilege-escalation-response.md`
Access Analyzer high finding	`runbook/access-analyzer-remediation.md`
Role permission change in prod	`runbook/iam-change-review.md`
Break-glass activation	`runbook/break-glass-procedure.md`
Quarterly access review	`runbook/access-review-process.md`

✅ Design Review Checklist

Kiến trúc IAM

[ ] Không có IAM Users cho human access (chỉ SSO)
[ ] Mọi Role có Permission Boundary attached
[ ] Cross-account access dùng ExternalId
[ ] Trust policies không có Principal: "*"

Security Controls

[ ] MFA enforced cho tất cả console access
[ ] Password policy meets compliance requirements
[ ] Access keys có rotation schedule
[ ] Root user locked down, MFA hardware

Monitoring & Audit

[ ] IAM Access Analyzer enabled
[ ] CloudTrail logging IAM events
[ ] Alerts cho high-risk IAM operations
[ ] Quarterly access reviews scheduled

Governance

[ ] IAM policy naming convention
[ ] Role tagging strategy
[ ] Policy review process documented
[ ] Least privilege documentation per role

📎 Liên kết

📎 GCP IAM Model - So sánh với GCP's IAM approach
📎 Account & Landing Zone - IAM trong multi-account context
📎 Security Posture - IAM như một phần của security strategy
📎 Terraform Security - Quản lý IAM qua IaC
📎 Key & Secrets Management - Secrets rotation patterns

🔐 IAM Fundamentals ​

🎯 Mục tiêu (Outcomes) ​

✅ Khi nào dùng ​

IAM Roles (Ưu tiên sử dụng) ​

IAM Users (Hạn chế tối đa) ​

❌ Khi nào KHÔNG dùng ​

Core Concepts ​

Principal Types ​

Policy Evaluation Logic ​

Least Privilege Implementation ​

Anti-Pattern: Overly Permissive ​

Best Practice: Scoped Permissions ​

Role Assumption Pattern ​

Cross-Account Access ​

Trust Policy (Target Role) ​

Permission Boundaries ​

Use Case: Delegated Administration ​

Permission Boundary Policy ​

IAM Access Analyzer ​

Finding Types ​

Automated Remediation ​

Auditing & Compliance ​

CloudTrail IAM Events ​

Key Events to Monitor ​

Best Practices Checklist ​

⚖️ Trade-offs ​

Trade-off 1: Security vs Developer Experience ​

Trade-off 2: Centralized vs Decentralized IAM Management ​

Trade-off 3: Fine-grained vs Coarse-grained Policies ​

🚨 Failure Modes ​

Failure Mode 1: Privilege Escalation qua iam:PassRole ​

Failure Mode 2: Stale Credentials và Unused Permissions ​

Failure Mode 3: Policy Conflicts và Unexpected Denies ​

🔐 Security Baseline ​

IAM Configuration Requirements ​

Keys/Secrets Management ​

Data Access Patterns ​

📊 Ops Readiness ​

Metrics cần Monitoring ​

Alerting Configuration ​

Runbook Entry Points ​

✅ Design Review Checklist ​

Kiến trúc IAM ​

Security Controls ​

Monitoring & Audit ​

Governance ​

📎 Liên kết ​

🔐 IAM Fundamentals

🎯 Mục tiêu (Outcomes)

✅ Khi nào dùng

IAM Roles (Ưu tiên sử dụng)

IAM Users (Hạn chế tối đa)

❌ Khi nào KHÔNG dùng

Core Concepts

Principal Types

Policy Evaluation Logic

Least Privilege Implementation

Anti-Pattern: Overly Permissive

Best Practice: Scoped Permissions

Role Assumption Pattern

Cross-Account Access

Trust Policy (Target Role)

Permission Boundaries

Use Case: Delegated Administration

Permission Boundary Policy

IAM Access Analyzer

Finding Types

Automated Remediation

Auditing & Compliance

CloudTrail IAM Events

Key Events to Monitor

Best Practices Checklist

⚖️ Trade-offs

Trade-off 1: Security vs Developer Experience

Trade-off 2: Centralized vs Decentralized IAM Management

Trade-off 3: Fine-grained vs Coarse-grained Policies

🚨 Failure Modes

Failure Mode 1: Privilege Escalation qua iam:PassRole

Failure Mode 2: Stale Credentials và Unused Permissions

Failure Mode 3: Policy Conflicts và Unexpected Denies

🔐 Security Baseline

IAM Configuration Requirements

Keys/Secrets Management

Data Access Patterns

📊 Ops Readiness

Metrics cần Monitoring

Alerting Configuration

Runbook Entry Points

✅ Design Review Checklist

Kiến trúc IAM

Security Controls

Monitoring & Audit

Governance

📎 Liên kết