IAM 高级安全架构

章节概述

IAM（Identity and Access Management）是 AWS 安全体系的基石。在 SAA 级别，你只需要知道"IAM 可以管理用户和权限"就够了。但在 SAP 级别，IAM 变成了一个复杂的多层决策系统——你需要理解策略评估的完整逻辑链、跨账户访问的信任关系、联合身份认证的多种流程，以及如何在企业级多账户环境中实现统一的身份管理。

为什么 IAM 在 SAP 考试中这么重要？因为几乎每个 Domain 都涉及 IAM。Domain 1 的多账户安全需要 SCP + Permission Boundaries；Domain 2 的新架构设计需要精确的策略配置；Domain 3 的安全优化需要审计和分析工具；Domain 4 的迁移需要跨账户角色和联合身份。可以说，不理解 IAM 高级概念，SAP 考试寸步难行。

这一章我们会从策略评估逻辑开始，一层层往上搭建你的 IAM 知识体系。每个知识点都会告诉你"考试怎么考"和"生产环境怎么用"。

---

核心知识点

1. IAM 策略评估逻辑（Policy Evaluation Logic）

这是 SAP 考试中 IAM 相关题目的底层逻辑。不理解这个，你就只能靠猜。

概念

当一个 IAM 主体（用户、角色、服务）发起 API 请求时，AWS 会按照特定的顺序评估所有相关策略，最终决定 Allow 还是 Deny。

人话解释

想象你要进一栋大楼。保安（策略评估）会逐层检查：

1. 你在黑名单上吗？（Explicit Deny）→ 在的话直接赶走
2. 你的公司允许你来这栋楼吗？（SCP）→ 公司不允许的话赶走
3. 你的工卡能进这层楼吗？（Permission Boundary）→ 工卡权限不够的话赶走
4. 你自己有进这个房间的权限吗？（Identity-based Policy）→ 没有的话赶走
5. 这个房间允许你进来吗？（Resource-based Policy）→ 不允许的话赶走

完整评估顺序

请求发起
  │
  ├── 1. Explicit Deny 检查（显式拒绝）
  │     └── 任何策略中有 Deny → 直接拒绝，游戏结束
  │
  ├── 2. SCP 检查（Service Control Policy）
  │     └── Organizations 层面的限制 → 不在允许范围内则拒绝
  │
  ├── 3. Permission Boundary 检查（权限边界）
  │     └── 用户/角色的最大权限范围 → 不在范围内则拒绝
  │
  ├── 4. Session Policy 检查（会话策略）
  │     └── AssumeRole 时传入的限制 → 不在范围内则拒绝
  │
  ├── 5. Identity-based Policy 检查（基于身份的策略）
  │     └── 附加在用户/角色上的策略 → 必须有 Allow
  │
  ├── 6. Resource-based Policy 检查（基于资源的策略）
  │     └── 附加在资源上的策略（如 S3 Bucket Policy）
  │
  └── 最终结果：只有所有层都放行，请求才被允许

图解说明：

• 完整展示了 IAM 策略评估的先后顺序：Explicit Deny → SCP → Permission Boundary → Session Policy → Identity Policy → Resource Policy
• 核心原则：任何一层出现 Deny 就直接拒绝，所有层都放行才最终 Allow
• SAP 考试中策略评估题的解题关键就是按这个流程图逐层检查

考试考法

典型题目：一个用户有 IAM 策略允许 s3:*，但同时 SCP 只允许 ec2:*。该用户能访问 S3 吗？

答案：不能。SCP 限制了最大权限范围，即使 IAM 策略允许，SCP 不允许的操作也无法执行。

记忆口诀：Deny 优先，交集生效。最终权限 = Identity Policy ∩ Permission Boundary ∩ SCP ∩ Session Policy。

关键配置 — 跨账户访问的特殊规则

同账户访问：Identity-based Policy 或 Resource-based Policy 中任一允许即可（Union 并集）。

跨账户访问：Identity-based Policy 和 Resource-based Policy 都必须允许（Intersection 交集）。

同账户：权限 = Identity Policy ∪ Resource Policy（并集）
跨账户：权限 = Identity Policy ∩ Resource Policy（交集）

这个区别在 SAP 考试中经常出现，务必牢记。

---

2. 跨账户 AssumeRole 完整流程

概念

AssumeRole 是 AWS 中实现跨账户访问的核心机制。账户 A 的用户可以"扮演"（Assume）账户 B 中的一个角色，从而获得临时凭证来访问账户 B 的资源。

人话解释

就像一个公司的员工拿着介绍信去另一个公司临时办公。介绍信上写了"这个人可以来"（Trust Policy），但他能干什么取决于对方公司给他的临时工卡（Permission Policy）。

完整流程

账户 A（请求方）                    账户 B（资源方）
  │                                    │
  │  1. 用户调用 sts:AssumeRole        │
  │  ──────────────────────────────>   │
  │     传入 RoleArn + ExternalId      │
  │                                    │
  │  2. STS 检查 Trust Policy          │
  │     (IAM Role 的信任策略)           │
  │  <──────────────────────────────   │
  │     ✓ 账户 A 被信任                │
  │     ✓ ExternalId 匹配              │
  │                                    │
  │  3. STS 返回临时凭证               │
  │  <──────────────────────────────   │
  │     AccessKeyId                    │
  │     SecretAccessKey                │
  │     SessionToken                   │
  │     Expiration                     │
  │                                    │
  │  4. 用户使用临时凭证访问资源        │
  │  ──────────────────────────────>   │
  │     权限由 Role 的 Policy 决定      │

三个关键策略

1. Trust Policy（信任策略）— 在目标角色上

决定"谁可以 Assume 这个角色"：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-id-12345"
        }
      }
    }
  ]
}

2. Permission Policy（权限策略）— 在目标角色上

决定"Assume 之后能干什么"：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::target-bucket/*"
    }
  ]
}

3. 源账户的 IAM Policy — 在请求用户上

决定"用户是否被允许调用 AssumeRole"：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/CrossAccountRole"
    }
  ]
}

External ID 的作用（防止"困惑代理"攻击）

问题场景：你委托第三方公司 A 管理你的 AWS 资源。A 知道你的 Role ARN。如果恶意用户 B 也是 A 的客户，B 可能诱导 A 用他们的权限来访问你的资源。

解决方案：在 Trust Policy 中要求 External ID。只有提供正确 ExternalId 的请求才被接受。External ID 是你和第三方之间的"暗号"。

考试考法

题目经常这样出：

• "第三方需要访问你的 S3 存储桶" → AssumeRole + External ID
• "跨账户访问被拒绝" → 检查两边的策略是否都有 Allow
• "临时凭证过期" → STS 默认 1 小时，最长 12 小时

---

3. SAML 2.0 联合身份认证

概念

SAML 2.0（Security Assertion Markup Language）是一种企业级的联合身份认证标准。它允许企业用户使用公司内部的身份系统（如 Active Directory）直接登录 AWS，不需要在 AWS 中创建单独的 IAM 用户。

人话解释

你公司用 AD（Active Directory）管理员工账号。有了 SAML 联合身份，员工不需要再记一套 AWS 的用户名密码——用公司账号就能直接登录 AWS Console 或使用 AWS CLI。

认证流程

用户 → 公司 IdP (ADFS) → AWS STS → AWS 资源

详细步骤：
1. 用户访问公司的 IdP 登录页面（如 ADFS Portal）
2. IdP 验证用户身份（AD 用户名/密码）
3. IdP 生成 SAML Assertion（包含用户身份和角色映射）
4. 用户带着 SAML Assertion 调用 STS:AssumeRoleWithSAML
5. STS 验证 SAML Assertion 的签名和内容
6. STS 返回临时凭证（AccessKey + SecretKey + SessionToken）
7. 用户使用临时凭证访问 AWS 资源

考试考法

• "企业用户使用现有的 Active Directory 登录 AWS" → SAML 2.0 Federation
• "不想在 AWS 中创建 IAM 用户" → Federation（SAML / OIDC / Identity Center）
• "员工需要访问 AWS Console" → SAML 2.0 + Console URL with STS

---

4. OIDC / Web Identity Federation

概念

Web Identity Federation 允许应用（特别是移动应用和 Web 应用）的用户使用第三方身份提供商（如 Google、Facebook、Amazon）登录后获得 AWS 临时凭证。

人话解释

你的手机 App 用户用 Google 账号登录后，App 需要直接上传照片到 S3。Web Identity Federation 就是让 Google 的登录令牌换成 AWS 的临时凭证。

两种实现方式

方式 1：使用 Cognito（AWS 推荐）

用户 → Google/Facebook 登录 → 获得 Token
  → 发送 Token 到 Cognito Identity Pool
  → Cognito 验证 Token
  → Cognito 调用 STS 获取临时凭证
  → 返回 AWS 临时凭证给用户
  → 用户直接访问 S3/DynamoDB

方式 2：不使用 Cognito（旧方式，不推荐）

用户 → Google/Facebook 登录 → 获得 Token
  → 直接调用 STS:AssumeRoleWithWebIdentity
  → STS 返回临时凭证
  → 用户访问 AWS 资源

Cognito 与 ALB 集成

图解说明：

• ALB（Application Load Balancer）原生支持 Cognito User Pool 作为认证层
• 用户请求 → ALB 自动重定向到 Cognito 登录页 → 认证成功后 ALB 转发请求到后端
• 无需在应用代码中实现认证逻辑，ALB 自动处理 Token 验证
• 适用于 Web 应用需要统一认证入口的场景

Cognito 与 API Gateway 集成

图解说明：

• Cognito User Pool 可以作为 API Gateway 的 Authorizer（授权器）
• 客户端先通过 Cognito 登录获取 JWT Token，然后在 API 请求中携带 Token
• API Gateway 自动验证 Token 的有效性，无需后端代码参与认证
• 这是 Serverless 架构中最常用的 API 认证模式

考试考法

• "移动应用用户需要上传文件到 S3" → Cognito Identity Pool
• "Web 应用用户用 Google 登录后访问 DynamoDB" → Cognito Identity Pool
• 选项中 Cognito 和 AssumeRoleWithWebIdentity 同时出现 → 选 Cognito

---

5. IAM Identity Center（原 AWS SSO）

概念

IAM Identity Center 是 AWS 的统一登录服务。它允许用户通过一次登录（Single Sign-On）访问多个 AWS 账户和业务应用。

人话解释

一个企业有 50 个 AWS 账户。没有 Identity Center，每个员工要记 50 套用户名密码。有了 Identity Center，登录一次就能在所有账户之间切换。就像你公司的一张门卡，能刷开所有办公室的门。

图解说明：

• 展示了企业多账户环境中 IAM Identity Center 的统一身份管理架构
• 一个身份来源（AD/Okta/内置）通过 Identity Center 连接多个 AWS 账户
• Permission Sets 定义了不同用户组在不同账户中的权限
• 这是 SAP 考试中"多账户 + 统一登录"场景的标准答案架构

核心组件

IAM Identity Center 架构：

身份来源（任选其一）：
├── 内置身份存储（直接在 Identity Center 中管理用户）
├── Active Directory（通过 AD Connector 或 Managed AD）
└── 外部 IdP（Okta, OneLogin, Azure AD 等，通过 SAML 2.0）

权限管理：
├── Permission Set（权限集）= 一组 IAM 策略
├── 关联到用户/组 + AWS 账户
└── 自动在目标账户中创建 IAM Role

用户体验：
├── 统一登录门户（一个 URL）
├── 看到所有可访问的账户和应用
└── 一键切换账户，不需要重新登录

关键特性

• 支持 ABAC（Attribute-Based Access Control）：根据用户属性（部门、职级、地区）动态分配权限
• 多账户管理：与 AWS Organizations 深度集成，可以按 OU 分配权限
• 应用集成：支持 Salesforce, Box, Microsoft 365 等 SAML 2.0 应用

考试考法

• "多个 AWS 账户 + 统一登录" → IAM Identity Center
• "与现有 Active Directory 集成 + SSO" → IAM Identity Center + AD Connector/Managed AD
• "简化多账户权限管理" → IAM Identity Center + Permission Sets

---

6. Cognito 用户池 vs 身份池

概念

Amazon Cognito 提供两个核心服务：User Pool（用户池）和 Identity Pool（身份池）。它们解决的是不同的问题。

图解说明：

• 展示了 Cognito Identity Pool 如何将外部身份（Google、Facebook、SAML、User Pool）转换为 AWS 临时凭证
• 用户先通过 IdP 认证获得 Token，再通过 Identity Pool 换取 AWS 临时凭证
• Identity Pool 支持认证用户和未认证（Guest）用户两种访问模式
• 这是移动/Web 应用访问 AWS 资源（S3、DynamoDB）的推荐架构

人话解释

• User Pool（用户池）：管理"你是谁"——注册、登录、密码找回、MFA。相当于一个用户数据库 + 认证系统。登录后发给你一个 JWT Token。
• Identity Pool（身份池）：管理"你能访问什么 AWS 资源"——把各种来源的 Token 换成 AWS 临时凭证。相当于一个"Token 兑换机"。

什么时候用哪个

场景 1：你的 App 需要自建用户注册/登录系统
  → 用 User Pool

场景 2：你的 App 用户登录后需要直接访问 S3/DynamoDB
  → 用 Identity Pool（把 User Pool 的 JWT 换成 AWS 临时凭证）

场景 3：你的 App 需要完整的认证 + 授权
  → User Pool + Identity Pool 一起用

场景 4：你的 App 只需要用 Google/Facebook 登录
  → 可以直接用 Identity Pool（不需要 User Pool）

场景 5：你的 API 需要认证（通过 API Gateway）
  → User Pool 作为 API Gateway 的 Authorizer

关键配置

User Pool 核心功能：

• 用户注册/登录/密码重置
• MFA（多因素认证）
• 社交登录（Google, Facebook, Apple）
• 自定义认证流程（Lambda Triggers）
• 输出 JWT Token（ID Token, Access Token, Refresh Token）

Identity Pool 核心功能：

• 接受多种来源的 Token（User Pool, Google, Facebook, SAML, OIDC）
• 通过 STS 换成 AWS 临时凭证
• 支持未认证（Guest）访问
• 精细化 IAM 策略（用 Policy Variable 实现行级安全）

---

7. Directory Services（目录服务）

概念

AWS Directory Services 提供三种目录服务选项，让企业在 AWS 中使用 Microsoft Active Directory 功能。

三种选项对比

AWS Managed Microsoft AD（完全托管的 AD）：
├── 在 AWS 中运行完整的 Microsoft AD
├── 支持与本地 AD 建立 Trust Relationship
├── 支持 MFA
├── 适用场景：需要完整 AD 功能 + 混合云

AD Connector（AD 代理/转发器）：
├── 不存储任何目录数据
├── 所有请求转发到本地 AD
├── 依赖 VPN/Direct Connect 连接
├── 适用场景：不想在 AWS 复制目录数据

Simple AD（简化版 AD）：
├── 基于 Samba 4，功能有限
├── 不支持 MFA、不支持 Trust
├── 500-5000 用户
├── 适用场景：小规模、不需要与本地 AD 集成

考试考法

• "在 AWS 中运行需要 AD 的 Windows 应用" → Managed Microsoft AD
• "使用现有本地 AD 认证 AWS 资源，不想复制数据" → AD Connector
• "小规模，只需要基本目录功能，不需要连本地" → Simple AD
• "混合云环境，本地 AD + AWS AD 互信" → Managed Microsoft AD + Trust Relationship

---

8. Permission Boundaries（权限边界）

概念

Permission Boundary 是附加在 IAM 用户或角色上的一个策略，定义了该用户/角色能拥有的最大权限范围。它本身不授予任何权限，只是画了一个"天花板"。

人话解释

老板给你一张公司信用卡（IAM Policy 赋予你权限），但设置了每月上限 5000 元（Permission Boundary）。即使你的报销额度是 10000 元（IAM Policy 允许），你实际能花的也只有 5000 元。

核心公式

有效权限 = Identity-based Policy ∩ Permission Boundary

示例：
Identity Policy 允许: s3:*, ec2:*, iam:*
Permission Boundary 允许: s3:*, ec2:*

有效权限 = s3:*, ec2:*（iam:* 被 Boundary 截断）

关键使用场景：委托管理

场景：你是管理员，想让开发者自己创建 IAM 角色，
      但不希望他们创建权限过大的角色。

解决方案：
1. 给开发者 iam:CreateRole 权限
2. 要求创建角色时必须附加 Permission Boundary
3. Permission Boundary 限制了新角色的最大权限

IAM Policy 条件：
{
  "Effect": "Allow",
  "Action": "iam:CreateRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary"
    }
  }
}

考试考法

• "允许开发者创建角色但限制权限范围" → Permission Boundary
• "防止权限提升（Privilege Escalation）" → Permission Boundary
• "IAM 策略允许但操作被拒绝" → 检查 Permission Boundary

---

9. 策略条件键（Condition Keys）

概念

策略条件键允许你在 IAM 策略中添加额外的限制条件，根据请求的上下文信息决定是否允许操作。

高频条件键速查

aws:SourceIp
  └── 限制请求来源 IP
  └── 常用于：只允许公司 IP 访问

aws:PrincipalOrgID
  └── 限制请求必须来自同一 Organization
  └── 常用于：S3 Bucket Policy 限制组织内访问

aws:RequestedRegion
  └── 限制操作只能在指定区域执行
  └── 常用于：SCP 中限制区域
  └── 注意：IAM 等全局服务始终在 us-east-1

aws:MultiFactorAuthPresent
  └── 要求 MFA 认证
  └── 常用于：敏感操作（删除、停止实例）

aws:PrincipalTag/TagKey
  └── 基于主体标签的条件
  └── 常用于：ABAC 场景

aws:SecureTransport
  └── 要求 HTTPS 连接
  └── 常用于：S3 Bucket Policy 强制加密传输

aws:CalledVia
  └── 识别中间服务调用
  └── 支持：CloudFormation, Athena, DynamoDB, KMS

aws:SourceVpc / aws:SourceVpce
  └── 限制请求必须来自指定 VPC 或 VPC Endpoint
  └── 常用于：私有网络访问控制

考试实战示例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonOrgAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "o-abc123def4"
        }
      }
    }
  ]
}

这个策略的含义：拒绝所有不属于组织 o-abc123def4 的主体访问 S3 桶。这是企业环境中非常常见的安全策略。

---

深度对比表

对比项	SAML 2.0 Federation	Web Identity (OIDC)	IAM Identity Center	Cognito User Pool	一句话记忆
典型场景	企业员工登录 AWS	移动/Web 应用用户	多账户统一登录	App 用户注册/登录	用哪个看场景
身份来源	企业 IdP (ADFS)	Google/Facebook	AD/Okta/内置	自建用户库	用户从哪来
STS API	AssumeRoleWithSAML	AssumeRoleWithWebIdentity	自动 AssumeRole	不直接调用 STS	STS 是桥梁
输出	AWS 临时凭证	AWS 临时凭证	AWS 临时凭证	JWT Token	注意 Cognito 输出 JWT
管理开销	需要配置 IdP	需要配置 IdP	AWS 全托管	AWS 全托管	托管的更省心
适用规模	企业级	消费级应用	企业级多账户	消费级应用	企业选 IC，App 选 Cognito

对比项	Managed Microsoft AD	AD Connector	Simple AD	一句话记忆
本质	完整 AD 在 AWS 运行	代理/转发器	简化版 AD	完整 vs 代理 vs 简化
数据存储	AWS 上	本地 AD	AWS 上	Connector 不存数据
Trust	支持	不支持	不支持	只有 Managed AD 支持 Trust
MFA	支持	支持	不支持	Simple AD 最弱
网络依赖	可独立运行	必须有 VPN/DX	可独立运行	Connector 断网就废了
用户规模	大型企业	任意	500-5000	Simple AD 小规模
RDS SQL Server	支持	不支持	不支持	需要 RDS 集成选 Managed AD

---

关键词→答案速配

题目关键词	第一反应	备注
"企业 AD" + "登录 AWS Console"	SAML 2.0 + ADFS	或 IAM Identity Center
"多个 AWS 账户" + "单点登录"	IAM Identity Center	企业级首选
"移动应用" + "S3/DynamoDB 访问"	Cognito Identity Pool	不是 User Pool
"用户注册/登录" + "MFA"	Cognito User Pool	应用级用户管理
"第三方公司访问你的资源"	AssumeRole + External ID	防止困惑代理攻击
"限制只能从公司 IP 访问"	aws:SourceIp 条件键	在 IAM 或 SCP 中
"限制只能在特定区域操作"	aws:RequestedRegion	注意全局服务例外
"开发者自己创建 IAM 角色"	Permission Boundary	防止权限提升
"Windows 应用需要 AD"	Managed Microsoft AD	完整 AD 功能
"不想在 AWS 复制目录数据"	AD Connector	需要 VPN/DX
"临时凭证被泄露"	撤销临时凭证（Revoke）	DateLessThan 条件
"API Gateway 认证"	Cognito User Pool Authorizer	或 Lambda Authorizer
"组织内所有账户共享 S3"	aws:PrincipalOrgID	条件键限制

---

高频场景题拆解

场景 1：企业身份集成选型

题目：一家公司有 5000 名员工，使用本地 Active Directory 管理身份。他们有 30 个 AWS 账户。需求是：员工用公司账号登录即可访问对应的 AWS 账户，不需要创建 IAM 用户。应该使用什么方案？

选项分析：

• A. 在每个账户中创建 IAM 用户 → 5000 x 30 = 15 万用户，疯了 → 排除
• B. SAML 2.0 Federation + 每个账户配置角色 → 可行但管理复杂
• C. IAM Identity Center + AD Connector/Managed AD → 最优解
• D. Cognito User Pool → 这是给应用用户的，不是企业员工 → 排除

答案：C。IAM Identity Center 专为多账户 SSO 设计，与 Organizations 深度集成。

场景 2：Permission Boundary 实战

题目：安全团队希望允许开发者在开发账户中创建 IAM 角色，但要确保开发者创建的角色权限不能超过预定义的范围（例如不能有 IAM 管理权限）。如何实现？

答案：

1. 创建一个 Permission Boundary 策略，排除 IAM 管理操作
2. 在给开发者的 IAM 策略中，允许 iam:CreateRole，但条件要求必须附加该 Boundary
3. 这样开发者创建的任何角色都被 Boundary "封顶"

场景 3：临时凭证泄露应急

题目：安全团队发现一个 IAM 角色的临时凭证可能已被泄露。该角色被多个 EC2 实例使用。如何在不影响正常服务的情况下撤销已泄露的凭证？

答案：在 IAM 角色上附加一个内联策略，使用 aws:TokenIssueTime 条件键拒绝所有在指定时间之前发放的凭证：

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "DateLessThan": {
      "aws:TokenIssueTime": "2026-02-22T12:00:00Z"
    }
  }
}

之后 EC2 实例会自动获取新的临时凭证（通过 Instance Metadata Service），新凭证的发放时间在截止时间之后，所以不受影响。

场景 4：Cognito 架构选型

题目：一个移动应用需要：(1) 用户用邮箱注册和登录 (2) 支持 Google 社交登录 (3) 登录后上传照片到 S3 (4) 每个用户只能访问自己的 S3 前缀。应该如何设计？

答案：

1. Cognito User Pool — 处理用户注册、邮箱登录、Google 社交登录
2. Cognito Identity Pool — 把 User Pool 的 JWT Token 换成 AWS 临时凭证
3. IAM 策略使用 Policy Variable — ${cognito-identity.amazonaws.com:sub} 限制 S3 前缀

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::photo-bucket/${cognito-identity.amazonaws.com:sub}/*"
}

场景 5：跨账户访问被拒绝排错

题目：账户 A 的用户尝试 AssumeRole 到账户 B 的角色，但收到 AccessDenied 错误。Trust Policy 和 Permission Policy 都已正确配置。可能的原因是什么？

排查清单：

1. 账户 A 的用户是否有 sts:AssumeRole 权限？
2. 是否有 SCP 阻止了 sts:AssumeRole？
3. 是否要求 External ID 但没有提供？
4. 是否要求 MFA 但没有通过 MFA 认证？
5. Role 的 Trust Policy 中 Principal 是否写错（注意 :root vs 具体用户 ARN）？

---

常见错误与陷阱

陷阱 1：混淆 User Pool 和 Identity Pool

• User Pool = 认证（Authentication）→ 输出 JWT Token
• Identity Pool = 授权（Authorization）→ 输出 AWS 临时凭证
• 两者经常一起用，但解决的是不同问题

陷阱 2：忘记跨账户的"双重允许"规则

跨账户访问需要两边都 Allow。只配了一边的策略是不够的。唯一的例外是某些资源策略（如 S3 Bucket Policy）在资源策略单独 Allow 时也可以生效。

陷阱 3：SCP 不影响 Management Account

SCP 可以限制所有 Member Account，但不影响 Management Account。这是考试常考的陷阱。Management Account 即使附加了 SCP，也不受限制。

陷阱 4：Permission Boundary 不授权

Permission Boundary 只设置上限，本身不给任何权限。你还需要 Identity-based Policy 来实际授权。Boundary 没有 Allow 的操作，即使 Policy 允许也做不了。

陷阱 5：aws:SourceIp 在 VPC 内不适用

当请求来自 VPC 内部（通过 VPC Endpoint），应该使用 aws:SourceVpc 或 aws:SourceVpce，而不是 aws:SourceIp。aws:SourceIp 只适用于公网 IP。

---

命令/配置速查

STS 常用命令

# AssumeRole 获取临时凭证
aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/CrossAccountRole \
  --role-session-name my-session \
  --external-id unique-id-12345

# 获取当前身份信息
aws sts get-caller-identity

# 获取带 MFA 的 Session Token
aws sts get-session-token \
  --serial-number arn:aws:iam::111111111111:mfa/user \
  --token-code 123456

# 使用临时凭证
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

IAM 策略调试

# 模拟策略评估
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111111111111:user/dev \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/test.txt

# 查看用户的所有策略
aws iam list-attached-user-policies --user-name dev
aws iam list-user-policies --user-name dev

# 查看角色的信任策略
aws iam get-role --role-name CrossAccountRole

# 生成凭证报告
aws iam generate-credential-report
aws iam get-credential-report

# 查看 Access Advisor（服务访问记录）
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::111111111111:user/dev

IAM 审计与分析工具

以下三个工具在 SAP 考试中经常出现，它们解决不同的安全审计问题。

图解说明：

• IAM Access Analyzer 自动识别资源（S3、IAM Role、KMS 等）是否被组织外部的主体访问
• 每个"Finding"（发现）都标识了外部访问的来源和被访问的资源
• 支持 Organization 级别部署，一次性分析所有成员账户
• SAP 考试关键词："发现外部访问""识别公开共享的资源" → Access Analyzer

图解说明：

• Access Advisor 展示了每个 IAM 用户/角色最后一次访问各 AWS 服务的时间
• 用于识别未使用的权限，实现最小权限原则（Least Privilege）
• 如果某个服务 180 天未被访问，建议移除该服务的权限
• SAP 考试关键词："缩减权限""最小权限""识别未使用的权限" → Access Advisor

图解说明：

• Credentials Report 是账户级别的 CSV 报告，列出所有 IAM 用户的凭证状态
• 包含：密码最后使用时间、Access Key 轮换状态、MFA 是否启用等
• 用于安全审计：识别长期未使用的账号、未启用 MFA 的用户、过期的 Access Key
• SAP 考试关键词："审计所有用户凭证""检查 MFA 启用状态" → Credentials Report

EC2 Instance Profile

图解说明：

• Instance Profile 是将 IAM Role 附加到 EC2 实例的"容器"
• EC2 通过 Instance Metadata Service (IMDS) 自动获取临时凭证，无需硬编码 Access Key
• 一个 Instance Profile 只能关联一个 IAM Role，但一个 Role 可以被多个 Instance Profile 使用
• SAP 考试关键词："EC2 访问 S3/DynamoDB""不使用 Access Key" → Instance Profile + IAM Role

Permission Boundary 设置

# 创建 Permission Boundary 策略
aws iam create-policy \
  --policy-name DevBoundary \
  --policy-document file://boundary.json

# 给用户设置 Permission Boundary
aws iam put-user-permissions-boundary \
  --user-name dev \
  --permissions-boundary arn:aws:iam::111111111111:policy/DevBoundary

# 给角色设置 Permission Boundary
aws iam put-role-permissions-boundary \
  --role-name DevRole \
  --permissions-boundary arn:aws:iam::111111111111:policy/DevBoundary

# 查看 Boundary
aws iam get-user --user-name dev
# 输出中的 PermissionsBoundary 字段

Cognito 关键操作

# 创建 User Pool
aws cognito-idp create-user-pool \
  --pool-name MyAppUsers \
  --auto-verified-attributes email

# 创建 Identity Pool
aws cognito-identity create-identity-pool \
  --identity-pool-name MyAppIdentities \
  --allow-unauthenticated-identities

# 获取临时凭证（通过 Identity Pool）
aws cognito-identity get-id \
  --identity-pool-id us-east-1:xxx \
  --logins cognito-idp.us-east-1.amazonaws.com/us-east-1_xxx=<JWT_TOKEN>