Tuần 6 - Ngày 1: IAM Nâng cao

Mục tiêu học tập

• Hiểu Identity Federation (SAML, OIDC, Cognito)
• Nắm Permission Boundaries và STS
• Áp dụng IAM Access Analyzer
• Hiểu ABAC (Attribute-Based Access Control)

1. STS (Security Token Service)

Định nghĩa

STS = service phát hành temporary security credentials (Access Key + Secret + Session Token).

Use cases

• Assume Role (cross-account access)
• Identity federation (SAML, OIDC)
• Web identity (Cognito)
• MFA-protected operations

Key STS API operations

Token characteristics

• Lifetime: 15 minutes - 12 hours (default 1 hour)
• Cannot be revoked (until expiry)
• Auto-included AccessKey, SecretKey, SessionToken

2. Cross-Account Access

Pattern: Account A user assumes role in Account B

Setup

1. Account B: Create role with trust policy allowing Account A
2. Account A: User has permission sts:AssumeRole on Account B role ARN
3. User runs aws sts assume-role --role-arn arn:aws:iam::B:role/DataReaderRole
4. Get temp credentials
5. Use credentials to access Account B resources

Trust Policy example

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111111111111:root"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" }
    }
  }]
}

→ Account 111... có thể assume role, bắt buộc MFA.

ExternalID (security best practice)

• Khi share role với 3rd party (vendor), add ExternalID trong trust policy
• Vendor must provide ExternalID khi assume role
• Bảo vệ confused deputy problem (vendor bị social engineered)

3. Identity Federation

SAML 2.0

• Enterprise SSO: corporate AD, Okta, Azure AD
• IdP (Identity Provider) → STS → AWS Console/CLI

Flow

1. User → IdP (login với corporate creds)
2. IdP returns SAML assertion
3. App calls sts:AssumeRoleWithSAML
4. STS returns temp credentials
5. User accesses AWS

OIDC (OpenID Connect)

• Web identity providers: Google, Facebook, Apple, GitHub
• Mobile apps, web apps

AWS IAM Identity Center (formerly AWS SSO)

• Recommended modern solution
• SSO across AWS accounts + business apps
• Built-in IdP or integrate with AD, Okta, Azure AD
• Permission sets manage role mapping

Benefits

• Centralized user management
• Multi-account SSO with single login
• Replace per-account IAM users

4. Cognito (User Identity)

2 components

User Pool

• User directory (sign-up, sign-in, password reset)
• Built-in or federated (Google, Facebook, SAML)
• JWT tokens for app authentication

Identity Pool (formerly Federated Identities)

• Exchange identity provider token → AWS temp credentials (STS)
• Direct AWS access from mobile/web app
• 2 roles: authenticated, unauthenticated (guest)

Use case

• Mobile app users → S3 upload personal files
• Web app users → DynamoDB access scoped to user

Architecture

Mobile App → User Pool (sign in) → JWT token
            → Identity Pool (exchange token) → AWS temp credentials
            → DynamoDB / S3 / API Gateway

5. Permission Boundaries

Định nghĩa

Permission Boundary = MAX permissions an IAM entity can have, regardless of attached policies.

Đặc điểm

• Apply to IAM User or Role
• NOT a grant — just a ceiling
• Effective permission = Identity policy ∩ Permission boundary

Example

Identity Policy: allow s3:*, ec2:*, iam:*

Permission Boundary: allow s3:*, ec2:* (NO iam:*)

Effective: s3:* and ec2:* (iam:* blocked by boundary)

Use case

• Developers self-service IAM (tạo role mới for app)
• Boundary prevents tạo role with admin permissions
• Delegated administration

SCP vs Permission Boundary

SCP topic chính cho SAP-C02. SAA-C03 hiểu khái niệm cơ bản đủ.

6. AWS Organizations Brief

Định nghĩa

Organizations = multi-account management.

Components

• Management Account (Root): billing, organization-wide
• Organizational Unit (OU): group accounts
• Member Accounts: individual accounts

SCP (Service Control Policy)

• Whitelist hoặc Deny list IAM actions across accounts
• Apply ở OU/Account level
• Không grant permission — chỉ giới hạn max

SAA-C03 thường hỏi SCP basics. Chi tiết deep trong SAP-C02.

7. ABAC (Attribute-Based Access Control)

Định nghĩa

ABAC = grant permissions based on attributes (tags) thay vì specific resource ARNs.

So với RBAC (Role-Based)

• RBAC: separate role per resource set ("admin", "developer-app-A", "developer-app-B")
• ABAC: 1 policy, scale automatic with new resources/users

Example policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "ec2:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
      }
    }
  }]
}

→ User can access EC2 instances only if user's Department tag matches resource's Department tag.

Benefits

• Scale (new resources auto-covered by tags)
• Reduce # of policies/roles
• Easier compliance audit

8. IAM Access Analyzer

Định nghĩa

Tool analyze IAM policies, identify resources shared externally (public, cross-account, federated).

Findings

• S3 bucket accessible to all
• Lambda function exposed to other accounts
• KMS key shared with 3rd party
• IAM role assumable by external account

Features

• External access findings: detect unintended sharing
• Unused access findings: detect unused IAM roles/permissions (cost + security)
• Policy validation: validate IAM policy syntax + best practices
• Policy generation: generate least-privilege policy from CloudTrail events

Use case

• Continuous security audit
• Reduce attack surface
• Compliance (PCI, HIPAA)

9. IAM Roles Anywhere

Định nghĩa

IAM Roles Anywhere = on-prem servers (or other clouds) assume AWS IAM Roles using X.509 certificates (no long-term AWS keys).

Workflow

1. Trust anchor: AWS Private CA hoặc external CA
2. On-prem server has X.509 cert signed by trust anchor
3. Server uses CreateSession API with cert → temp credentials
4. Use temp creds to access AWS

Use case

• Hybrid workload (on-prem → AWS)
• CI/CD systems (Jenkins on-prem → AWS deploy)
• Replace stored access keys (security best practice)

10. IAM Best Practices (Top 15)

1. Lock root user (MFA, no daily use)
2. MFA cho admin users
3. Use IAM Roles (not access keys) cho EC2, Lambda, ECS
4. Apply least privilege
5. Use AWS Identity Center for multi-account SSO
6. Rotate access keys every 90 days
7. Don't share credentials
8. Audit with CloudTrail + Access Analyzer
9. Permission boundaries for delegated admin
10. Tag resources + use ABAC
11. Federated identity instead of IAM users
12. Strong password policy
13. Enable IAM Roles Anywhere for hybrid
14. Use Service Control Policies (Organizations)
15. Regular review and cleanup unused users/roles

11. Common Patterns

Pattern 1: Cross-account access cho CI/CD

CI account → Assume role in target account → Deploy resources

Pattern 2: Multi-account SSO via Identity Center

User → Identity Center login → Permission Set chosen → Auto-assume role in chosen account

Pattern 3: Mobile app + Cognito

User signup → User Pool → Identity Pool → AWS temp creds → API Gateway / DynamoDB

Pattern 4: Federated workload (on-prem CI)

Jenkins on-prem → X.509 cert → IAM Roles Anywhere → AWS deploy

Câu hỏi ôn tập

1. STS token lifetime range là bao nhiêu?

   Xem đáp án

   15 phút đến 12 giờ cho AssumeRole (mặc định 1 giờ). Cho AssumeRoleWithWebIdentity và AssumeRoleWithSAML: tối đa 1 giờ. Federated user sessions có thể đến 36 giờ. Role session duration tối đa cấu hình trong role settings (max 12 giờ). Token ngắn hơn = security tốt hơn; token dài hơn = ít calls đến STS hơn.

2. Permission Boundary có grant permission không?

   Xem đáp án

   Không — Permission Boundary chỉ giới hạn permission tối đa (ceiling), không tự grant permission. Identity vẫn cần identity-based policy riêng để có quyền thực sự. Ví dụ: Boundary cho phép S3+EC2, identity policy cho phép S3+DynamoDB → effective permission chỉ là S3 (intersection). Dùng Boundary để delegate IAM administration: cho phép team tạo roles nhưng không vượt quá scope đã định.

3. Khi share IAM role với 3rd party vendor, dùng tính năng gì để bảo vệ?

   Xem đáp án

   External ID trong trust policy (Confused Deputy protection). Khi vendor assume role phải cung cấp External ID secret — ngăn attacker lừa vendor access account của bạn bằng cách sử dụng vendor's AWS credentials. External ID là secret chỉ bạn và vendor biết, include trong sts:ExternalId condition. Best practice cho tất cả cross-account third-party integrations.

4. ABAC khác RBAC ở điểm gì?

   Xem đáp án

   RBAC (Role-Based): access dựa trên roles (IAM Roles/Groups) — tạo nhiều roles cho nhiều resource combinations, phức tạp khi scale. ABAC (Attribute-Based): access dựa trên tags của cả identity lẫn resource — một policy có thể cover nhiều resources: "Condition": {"StringEquals": {"aws:ResourceTag/Project": "${aws:PrincipalTag/Project"}}. Phù hợp cho large-scale multi-team environments — ít policies hơn, dễ quản lý hơn.

5. IAM Access Analyzer giúp phát hiện gì?

   Xem đáp án

   Access Analyzer phân tích resource-based policies (S3, SQS, KMS, Lambda, IAM roles) để tìm external access — resources được chia sẻ với principals bên ngoài account/Organization. Highlight unintended public access (S3 bucket public, role assume-able từ internet). Cũng có External Access findings cho cross-account access và Unused Access findings (over-permissive policies). Chạy continuously — alert khi phát hiện mới.

Bài tập thực hành

• Tạo cross-account role: Account A user assume role trong Account B
• Setup IAM Identity Center (free), assign Permission Set
• Tạo Permission Boundary giới hạn user chỉ tạo IAM role với boundary attached
• Test ABAC: user với tag Department=eng access EC2 tag Department=eng
• Enable IAM Access Analyzer, review findings

Tài liệu tham khảo chính thức

• IAM User Guide
• STS
• Permission Boundaries
• ABAC
• IAM Access Analyzer
• IAM Identity Center

---

Tiếp theo: KMS và Secrets Manager