🎯 学习目标
- 掌握 IAM 用户、组和角色的使用
- 理解 IAM 策略的编写和评估
- 实施 AWS 安全最佳实践
📌 核心知识点
学习目标
完成本章学习后，你将能够：
- 理解 IAM 的核心概念，清楚 Users、Groups、Roles、Policies 之间的关系
- 读懂并编写 IAM Policy JSON 文档
- 掌握权限评估流程，能判断"到底有没有权限"
- 理解 STS 临时凭证、跨账户访问、Permission Boundaries 的工作机制
- 掌握 Organizations、SCP、Control Tower 的多账户治理体系
学习建议：本章按"门禁系统"来理解整个 IAM 体系。
Users / Groups / Roles= 先搞清楚"谁要进门"Policies= 再定义"谁能做什么"STS / MFA= 给进门的人发"临时通行证"和"双重验证"Organizations / SCP= 集团总部统一管理所有子公司的门禁规则
本章知识地图：
┌──────────────┐
│ IAM 门禁 │
└──────┬───────┘
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ 谁要进门 │ │ 能做什么 │ │ 怎么管大楼 │
│ (身份) │ │ (权限) │ │ (治理) │
└────┬─────┘ └────┬─────┘ └──────┬───────┘
│ │ │
Users / Groups Policies Organizations
Roles / STS Boundaries SCP
MFA / Federation Evaluation Control Tower
1. IAM 是什么
1.1 通俗理解
把 AWS 想成一栋超大的办公大楼。IAM (Identity and Access Management) 就是这栋大楼的 门禁系统：
- 门禁卡 = 你的 AWS 账户凭证（用户名密码、Access Key）
- 权限级别 = 有的人能进所有楼层，有的人只能进自己的办公室
- 访客通行证 = 临时凭证（STS），用完就失效
- 安保日志 = CloudTrail，记录谁在什么时候刷了什么卡
1.2 一句话解释
IAM 是 AWS 的集中式访问控制中心，决定"谁"能对"哪些资源"做"什么操作"。
1.3 为什么第一个学 IAM？
你可能会想："我想学 EC2、S3 这些好玩的东西，为什么要先学门禁？"
原因很简单：没有 IAM，你什么都做不了。
- 创建 EC2？需要
ec2:RunInstances权限 - 上传文件到 S3？需要
s3:PutObject权限 - 查看账单？需要
aws-portal:ViewBilling权限
IAM 是所有 AWS 服务的"前置条件"。学好 IAM，后面的章节你会轻松很多。
1.4 核心功能
- Share access at various levels of permission - 多级权限共享
- Identity federation - 身份联合（支持 Facebook、Google、Active Directory 等外部认证）
- MFA (Multi-Factor Authentication) - 多因素认证
- Custom password rotation policy - 自定义密码轮换策略
- PCI DSS compliant - 符合支付卡行业数据安全标准（通过政府强制的信用卡安全法规）
2. IAM 四大实体
- 图中展示了 IAM 的四种核心概念。注意看图标含义：User（人形图标）= 具体的人；Group（人群图标）= 一组人；Role（安全帽图标）= 可以被"穿戴"的身份，通常给服务用；Policy（清单图标）= 权限规则。
- 关键观察：Policy 的框画在外面，说明 Policy 本身不是身份（Identity），而是"附加"到身份上的规则。就像门禁规则不是人，而是贴在门上的告示。
- 看图顺序建议：
User（个人）→ Group（分组管理）→ Role（服务身份）→ Policy（权限规则附加到前三者上）。 - 考试怎么考：题目可能会问"以下哪个不是 IAM Identity？" — 答案是 Policy。
2.1 用"公司人员管理"来理解
想象你是一家科技公司的 IT 主管，要管理办公大楼的门禁：
| IAM 概念 | 公司类比 | 说明 |
|---|---|---|
| User | 每位员工的工牌 | 小明、小红各有一张工牌 |
| Group | 部门 | "开发部"、"财务部"，入职时分到对应部门就自动有该部门权限 |
| Role | 临时安全帽 | 外包人员来了，戴上"运维安全帽"就临时拥有运维权限 |
| Policy | 门禁规则表 | "开发部可进3楼实验室，不可进4楼财务室" |
2.2 Users (用户)
任何个人终端用户，如 employee, system architect, CTO 等。
- 共享账号 = 出了事不知道谁干的（无审计追踪）
- 独立用户 = CloudTrail 能精确记录"谁在什么时候做了什么"
User 认证方式:
| 认证类型 | 用途 | 说明 |
|---|---|---|
| Console Password | AWS Console 登录 | 可设置密码策略 |
| Access Keys | CLI / SDK | Access Key ID + Secret Access Key |
| SSH Keys | CodeCommit | Git over SSH |
| Server Certificates | HTTPS | SSL/TLS 证书 |
2.3 Groups (组)
具有共享权限的用户集合，如 system administrators, HR employees, finance teams。
通俗理解： Group 就是公司里的"部门"。你不需要逐个给每位开发人员配权限，只要把他们拉进"开发部"这个 Group，所有人就自动继承开发部的权限。
- 组内用户 继承 组的所有权限
- 一个用户可以属于多个组（就像一个人可以同时属于"开发部"和"项目A组"）
- ⚠️ 注意: Groups 不能嵌套！You cannot create subgroups.
- Groups 只能包含 Users，不能包含其他 Groups 或 Roles
🧠 最易混淆：很多人以为 Group 可以嵌套（像文件夹一样），但 IAM Group 是扁平的，不支持子组。
2.4 Roles (角色)
需要权限执行任务的 AWS 服务或外部实体。
通俗理解： Role 就像一顶"安全帽"。EC2 实例本身没有权限，但"戴上"一个 Role（安全帽），就临时拥有了这个 Role 定义的权限。用完可以摘下来。
常见使用场景：
- AWS Lambda needing write permissions to S3
- A fleet of EC2 instances needing read permissions from RDS MySQL
- Cross-account access from another AWS account
- Users from corporate directory using Identity Federation
Role 核心概念:
| 概念 | 说明 | 类比 |
|---|---|---|
| Trust Policy | 定义谁可以 assume 这个 role | "谁有资格戴这顶安全帽" |
| Permission Policy | 定义 role 拥有的权限 | "戴上安全帽后能干什么" |
| Role Session | assume role 后的临时会话 | "安全帽的使用时段" |
🧠 最易混淆：User 是"永久身份"，Role 是"临时身份"。不要给 EC2 用 Access Key（永久），应该给它 Role（临时、自动轮换）。
2.5 Policies (策略)
授予或限制访问的规则集合，用 JSON 编写。
通俗理解： Policy 就是贴在门上的"规则清单"。上面写着"允许进入3楼实验室"或者"禁止进入4楼财务室"。
Policy 类型:
| 类型 | 描述 | 示例 | 类比 |
|---|---|---|---|
| AWS Managed | AWS 预定义策略 | AmazonS3ReadOnlyAccess | 物业统一制定的标准规则 |
| Customer Managed | 用户自定义策略 | 可复用，可版本控制 | 公司自己制定的特殊规则 |
| Inline | 直接嵌入到 User/Group/Role | 1:1 关系，不可复用 | 写在某人工牌背面的特殊权限 |
⚠️ 重要: IAM Policies 不是 IAM Identity，而是附加到 IAM Identities 上的。就像"规则"不是"人"，而是贴在人身上的。
3. IAM Policy 怎么写
3.1 场景引入
假设你是 IT 主管，公司来了一位实习生小王。你的需求是：
- 小王只能 查看 S3 里的照片存储桶
- 小王 不能 删除任何文件
- 只在 悉尼区域 生效
怎么用 IAM Policy 表达这个需求？看下面这段 JSON：
3.2 Policy JSON 结构
{
"Version": "2012-10-17",
"Id": "S3-Account-Permissions",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "ap-southeast-2"
}
}
}
]
}
3.3 逐字段带读
我们逐行拆解这段 JSON，像读合同一样：
| 字段 | 值 | 含义 | 类比 |
|---|---|---|---|
| Version | "2012-10-17" | Policy 语言版本（固定值，别改） | 合同模板版本号 |
| Id | "S3-Account-Permissions" | 给这个 Policy 起个名字（可选） | 合同编号 |
| Statement | [...] | 一条或多条权限声明 | 合同条款列表 |
| Sid | "AllowS3ListRead" | 这条声明的 ID（可选） | 第一条条款的编号 |
| Effect | "Allow" | 允许还是拒绝 | "允许进入" |
| Principal | "arn:aws:iam::..." | 谁被允许（Resource-based policy 才需要） | "持此工牌的人" |
| Action | ["s3:GetObject", ...] | 允许做什么操作 | "可以看文件、列清单" |
| Resource | ["arn:aws:s3:::my-bucket/*"] | 对哪些资源生效 | "仅限照片存储桶" |
| Condition | {"StringEquals": ...} | 在什么条件下生效 | "仅限悉尼办公时间" |
3.4 Policy 元素详解
| 元素 | 必需 | 描述 |
|---|---|---|
| Version | ✅ | 策略语言版本，始终用 "2012-10-17" |
| Id | ❌ | 策略标识符 |
| Statement | ✅ | 一个或多个权限声明 |
| Sid | ❌ | Statement ID，语句标识符 |
| Effect | ✅ | Allow 或 Deny |
| Principal | 🔸 | 谁被允许/拒绝（Resource-based policy 需要） |
| Action | ✅ | 允许/拒绝的操作列表 |
| Resource | ✅ | 操作应用的资源 ARN |
| Condition | ❌ | 策略生效的条件 |
3.5 Policy Variables (策略变量)
场景： 公司有 100 个员工，每人在 S3 有自己的文件夹。你不可能写 100 个 Policy。这时候用变量：
{
"Resource": "arn:aws:s3:::mybucket/${aws:username}/*"
}
${aws:username} 会自动替换成当前登录用户的名字。小王访问时变成 mybucket/xiaowang/*，小红访问时变成 mybucket/xiaohong/*。
常用变量：
${aws:username}- IAM 用户名${aws:userid}- 用户唯一 ID${aws:PrincipalTag/department}- Principal 的标签值
4. 核心要点
4.1 Global Service
- IAM is a global AWS service, not limited by regions
- Any user, group, role or policy is accessible globally
- 但某些资源可以通过 Condition 限制到特定 region
为什么是全局的？ 因为"人"是全局的。你不会因为切到悉尼区域就变成另一个人。IAM 管的是"身份"，身份当然是全球通用的。
4.2 Root Account
- 注册 AWS 时使用的账户拥有完全 admin access
- 建议使用公司官方邮箱创建 root account
- ⚠️ 绝对不要 在日常工作中使用 root account
- ⚠️ 绝对不要 创建 root account 的 access keys
- ✅ 必须 为 root account 启用 MFA
为什么不用 Root？ Root 拥有"上帝权限"，一旦泄露，攻击者可以删掉你所有数据、创建天价资源。日常操作用权限受限的 IAM User，就像公司老板不会把万能钥匙挂在脖子上到处走。
4.3 New Users
- New users have no permissions when first created（最小权限原则）
- 创建用户时会生成 Access Key ID 和 Secret Access Key ID
- Access Keys 只能下载 一次，丢失需重新生成
- Access Keys 用于 CLI 和 SDK，不能 用于控制台登录
为什么默认没权限？ 这叫 最小权限原则（Least Privilege）。想象新员工入职第一天，门禁卡是空白的，需要 IT 主管逐个开通权限。这比"默认全开、出事再关"安全得多。
4.4 Identity Federation (身份联合)
如果公司有内部 SSO (Single Sign On)，可以复用现有身份：
| 联合类型 | 使用场景 | 协议 |
|---|---|---|
| SAML 2.0 | 企业 AD/LDAP 集成 | SAML |
| Custom Identity Broker | 不支持 SAML 的系统 | STS API |
| Web Identity Federation | 移动/Web 应用 | OIDC |
| AWS SSO | 多账户 SSO | SAML/OIDC |
| Cognito | 外部用户 (Google/Facebook) | OIDC |
为什么需要联合身份？ 你的公司有 5000 名员工用 Active Directory 登录电脑。难道要在 AWS 再创建 5000 个 IAM User？联合身份让他们用同一套账号密码登录 AWS，省去重复管理。
4.5 IAM Roles 灵活性
- 可在 EC2 实例创建前或后分配
- 可随时更改权限，立即生效
- 通过 AWS Console 或 CLI 操作
- Instance Profile 是将 Role 附加到 EC2 的容器
4.6 Tags for Access Control (ABAC)
使用 tags 标记资源和 principals，然后通过 IAM policy 控制访问：
{
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
}
}
}
这叫做 Attribute-Based Access Control (ABAC)。
通俗理解： 不再按"你是谁"来给权限，而是按"你的标签"来给权限。比如：标签是 Environment=Production 的人只能访问标签也是 Environment=Production 的资源。像停车场按"员工车贴颜色"决定能停哪个区。
5. 权限判断流程
5.1 通俗理解：安检多道关卡
想象你要进入一栋高安全级别的大楼，需要过多道安检：
- 黑名单检查（Explicit Deny）→ 名字在黑名单上？直接拒绝，不管你有什么通行证
- 集团总部规定（SCP）→ 总部说这栋楼禁止进入？你也进不了
- 大楼邀请函（Resource-based Policy）→ 大楼管理员单独邀请你？可以进
- 权限上限（Permission Boundary）→ 你的权限等级够吗？
- 临时通行证限制（Session Policy）→ 你的临时证件允许进这里吗？
- 个人门禁卡（Identity-based Policy）→ 你的卡能刷开这扇门吗？
- 默认拒绝（Default Deny）→ 以上都没有明确允许？那就是不能进
5.2 权限优先级
| 优先级 | 名称 | 描述 |
|---|---|---|
| 1️⃣ | Explicit Deny | 明确拒绝，不可覆盖 |
| 2️⃣ | Organization SCP | Organizations Service Control Policy |
| 3️⃣ | Resource-based Policy | 资源策略的 Allow |
| 4️⃣ | Permission Boundary | 权限边界限制 |
| 5️⃣ | Session Policy | AssumeRole 时的限制 |
| 6️⃣ | Identity-based Policy | 附加到 User/Group/Role 的策略 |
| 7️⃣ | Default Deny | 如果没有明确允许，默认拒绝 |
5.3 权限评估流程图
Request（请求来了）
│
▼
Explicit Deny? ──Yes──▶ ❌ DENY（黑名单直接拒绝）
│ No
▼
SCP Allow? ──No──▶ ❌ DENY（总部不允许）
│ Yes
▼
Resource Policy Allow? ──Yes──▶ ✅ ALLOW (same account)
│ No
▼
Permission Boundary Allow? ──No──▶ ❌ DENY（超出权限上限）
│ Yes
▼
Session Policy Allow? ──No──▶ ❌ DENY (if present)
│ Yes
▼
Identity Policy Allow? ──No──▶ ❌ DENY（门禁卡没权限）
│ Yes
▼
✅ ALLOW（全部通过，放行！）
🧠 考试口诀："Deny 永远赢" — 只要有一个 Explicit Deny，不管其他 Policy 怎么 Allow，最终结果一定是 Deny。这是 IAM 权限评估的第一定律。
5.4 考试怎么考
典型题目： 一个 IAM User 的 Identity Policy 允许 s3:*，但 SCP 只允许 s3:GetObject。这个 User 能删除 S3 对象吗？
解题思路： 有效权限 = Identity Policy ∩ SCP。s3:DeleteObject 在 Identity Policy 中被允许，但不在 SCP 允许范围内 → 不能删除。
6. STS 临时凭证
6.1 通俗理解：酒店房卡
AWS STS (Security Token Service) 提供的临时凭证，就像酒店房卡：
- 入住时发放（AssumeRole 时获取）
- 有效期有限（15分钟 ~ 12小时，不是永久的）
- 只能开指定的门（权限由 Role 的 Policy 决定）
- 退房后自动失效（过期后不能再用）
对比 IAM User 的 Access Key，那就像你家的钥匙——永远有效，丢了就危险了。
6.2 AssumeRole
为 IAM 用户或 AWS 服务获取临时凭证：
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/MyRole \
--role-session-name MySession
返回：
- AccessKeyId - 临时 Access Key
- SecretAccessKey - 临时 Secret Key
- SessionToken - 必须随请求发送
- Expiration - 过期时间（15分钟 ~ 12小时）
为什么用 AssumeRole 而不是直接给 Access Key？ 因为临时凭证会自动过期。即使泄露，攻击者也只有很短的窗口期。而 Access Key 一旦泄露，在你发现之前可能已经被滥用数周。
6.3 AssumeRoleWithSAML
用于 SAML 2.0 身份联合：
- 企业 AD 用户登录 AWS Console
- 无需创建 IAM 用户
6.4 AssumeRoleWithWebIdentity
用于 Web Identity Federation：
- 移动应用用户通过 Google/Facebook 登录
- 推荐使用 Cognito 替代直接调用
6.5 GetSessionToken
用于 MFA 保护的 API 调用：
aws sts get-session-token \
--serial-number arn:aws:iam::123456789012:mfa/user \
--token-code 123456
6.6 跨账户访问 (Cross-Account Access)
为什么需要跨账户访问？ 大公司通常有多个 AWS 账户（开发、测试、生产）。开发者在"开发账户"工作，但偶尔需要查看"生产账户"的日志。跨账户访问让这成为可能。
方式一：Resource-based Policy
在资源上设置信任其他账户：
{
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
}
}
支持的服务：S3, SNS, SQS, Lambda, KMS 等。
方式二：AssumeRole
- 在目标账户创建 Role，Trust Policy 信任源账户
- 源账户用户 assume 目标账户的 role
- 获取临时凭证访问资源
示例 Trust Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
🧠 考试选择题思路： 小规模跨账户 → Resource-based Policy。大规模多账户 → AssumeRole。需要额外安全保障 → 要求 MFA 才能 AssumeRole。
7. Permission Boundaries (权限边界)
7.1 通俗理解：给孩子的零花钱上限
想象你给孩子一张银行卡，但设了 每月 500 元上限。即使孩子知道卡里有 10 万元，每月也只能花 500 元。
Permission Boundary 就是这个"上限"：
- Identity Policy = 孩子想买什么（允许的操作）
- Permission Boundary = 爸妈设的上限（最大允许范围）
- 实际权限 = 两者的 交集
有效权限 = Identity Policy ∩ Permission Boundary
即使 Identity Policy 授予 * 权限，Permission Boundary 也会限制实际权限。
7.2 使用场景
- 允许开发者创建 IAM 角色，但限制他们能授予的权限
- 防止 privilege escalation（权限提升攻击）
为什么需要它？ 假设你允许开发者创建 Lambda 函数的 Role。如果没有 Boundary，开发者可以给这个 Role AdministratorAccess，然后通过 Lambda 获得管理员权限——这就是"权限提升"。有了 Boundary，即使开发者想授予 *，实际权限也不会超出边界。
7.3 示例
设置 Permission Boundary 只允许 S3 和 CloudWatch：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*"
],
"Resource": "*"
}
]
}
8. MFA (Multi-Factor Authentication)
8.1 通俗理解：银行 U 盾
你去银行转账，只输密码不够，还需要插 U 盾或输入手机验证码。MFA 就是 AWS 版的"U 盾"：
- 第一因素 = 你知道的东西（密码）
- 第二因素 = 你拥有的东西（手机 App、硬件设备）
即使密码被盗，没有第二因素也登录不了。
8.2 MFA 设备类型
| 类型 | 示例 | 适用场景 |
|---|---|---|
| Virtual MFA | Google Authenticator, Authy | 最常用，手机 App 生成 6 位数 |
| Hardware MFA | Gemalto token | 高安全性要求的企业 |
| U2F Security Key | YubiKey | 物理密钥，插 USB 验证 |
| Hardware MFA for Root | 专用设备 | Root 账户专用 |
8.3 MFA 强制策略
强制用户使用 MFA 才能执行操作：
{
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
8.4 MFA Delete for S3
启用 MFA Delete 后，删除对象版本需要 MFA 认证：
- 防止意外删除
- 只有 bucket owner (root account) 可以启用/禁用
- 只能通过 CLI 启用，不能通过 Console
🧠 考试考法： "如何防止 S3 对象被意外或恶意删除？" → 启用 Versioning + MFA Delete。
9. 安全工具箱
IAM 不只是"设权限"，还提供了一整套安全监控工具。把它想成门禁系统的"监控中心"：
9.1 IAM Access Advisor (User Level)
什么时候用： 你想知道某个用户的权限是不是给多了。
- 显示授予用户的 service permissions
- 显示 last accessed time（最后一次使用该权限的时间）
- 用于实施最小权限原则 — 如果一个权限 90 天没用过，大概率可以移除
9.2 IAM Credentials Report (Account Level)
什么时候用： 安全审计，检查整个账户的凭证健康状况。
- 列出所有账户用户及其 credentials 状态
- 包含：密码、Access Keys、MFA 状态
- 用于 安全审计 和 合规检查
- 每 4 小时可生成一次
9.3 IAM Access Analyzer
什么时候用： 检查是否有资源被意外公开。
- 分析资源策略，识别 外部访问
- 发现意外公开或跨账户共享的资源
- 支持：S3, IAM Roles, KMS, Lambda, SQS
9.4 AWS CloudTrail
什么时候用： 出了安全事件，需要"回看监控录像"。
- 左侧红色图标是 CloudTrail 服务。它捕获两类事件：Management Events（管理操作，如创建 EC2、修改 IAM 策略）和 Data Events（数据操作，如 S3 GetObject、Lambda Invoke）。
- 日志可发送到两个目的地：CloudWatch Logs（实时告警，像安保人员盯着监控屏幕）和 S3（长期存储归档，像监控录像存硬盘）。
- 底部说明 Trail 可配置为 One Region（单区域）或 All Regions（全区域）。
- 右侧提示 IAM、STS 等 Global Services 的事件默认记录在 us-east-1。
- 考试怎么考："谁在凌晨3点删了这个 S3 bucket？" → 查 CloudTrail 日志。
CloudTrail 核心功能：
- 记录所有 IAM API 调用
- 用于安全分析、合规审计、故障排查
9.5 CloudWatch Logs
- 日志有三层结构：各种 Logging Sources（EC2、Lambda、CloudTrail 等）产生日志 → 进入 Log Group（日志容器，按应用/服务分组）→ 每个 Group 内有多个 Log Stream（日志流，按实例/时间区分）→ 流中是一条条 Log Events（具体日志条目）。
- 右侧是监控链：从日志中提取 Metric Filter（如"ERROR 出现次数"）→ 生成 Metric（指标）→ 触发 Alarm（告警，如"ERROR 超过 10 次就发邮件"）。
- 考试怎么考："如何在 IAM 策略被修改时立即收到通知？" → CloudTrail 日志 → CloudWatch Logs → Metric Filter → Alarm → SNS 通知。
10. Organizations & SCP
10.1 通俗理解：集团管子公司
想象你是一家集团公司（AWS Organizations）的总部。集团下面有好几家子公司（Member Accounts）：
- 总部（Management Account）= 统一支付所有子公司的账单，制定集团统一规章
- 子公司（Member Accounts）= 各自独立运营，但必须遵守总部规定
- 事业部（OU - Organizational Units）= 按业务线分组，如"生产事业部"、"研发事业部"
10.2 AWS Organizations
- 顶部带皇冠的图标 = Management Account（总部），它是整个组织的"老大"，负责支付所有账单、管理组织结构。
- 下方的图标 = Member Accounts（子公司），它们是独立的 AWS 账户，加入组织后受总部管理。
- 左下方 On-premises 图标 = 本地办公室/数据中心也能通过 VPN/Direct Connect 接入组织网络。
- 看图顺序：总部 → 事业部分组 → 各子公司账户 → 本地互联。
核心功能：
- Consolidated Billing — 合并账单，获得批量折扣（用得越多越便宜）
- OU (Organizational Units) — 组织单元，按部门/环境分组
- Management Account — 主管理账户，支付所有账单
- Member Accounts — 成员账户，可通过 Role 访问
10.3 Service Control Policies (SCP)
- 这张图展示了 SCP 的 继承关系。顶部是 Management Account，下面是两个 OU：OU:Production 和 OU:Development，每个 OU 下面有各自的 Member Accounts。
- SCP（清单图标）附加在 OU 上，就像集团总部的规章制度贴在各事业部的门口。
- 关键概念：SCP 是 向下继承 的。附加在 OU 上的 SCP，会自动应用到该 OU 下的所有账户。
- ⚠️ Management Account 不受 SCP 限制！总部自己不受自己制定的规则约束。
SCP 核心规则：
- 只在 Organizations 中可用
- 不授予权限，只 限制 权限（SCP 是"天花板"，不是"地板"）
- 影响账户中所有用户和角色（包括 root）
- 不影响 service-linked roles
10.4 SCP 的"韦恩图"理解
- 这张图是理解 SCP 最关键的图。两个圆圈形成交集：
- 左圆 = Identity Policy（IAM 策略允许的权限）
- 右圆 = SCP（组织策略允许的权限范围）
- 交集（重叠部分） = 实际有效权限
- 左圆溢出部分 = Identity Policy 允许，但 SCP 不允许 → 无效！ 就像员工有进入实验室的工牌，但集团规定该楼层关闭 → 进不了
- 右圆溢出部分 = SCP 允许，但 Identity Policy 没给 → 也无效！ 就像集团允许进实验室，但员工的工牌上没有这个权限 → 也进不了
- 考试口诀：有效权限 = Identity Policy ∩ SCP，两边都得允许才行。
10.5 SCP 示例
禁止关闭 CloudTrail（防止子账户毁灭证据）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail"
],
"Resource": "*"
}
]
}
为什么需要这条 SCP？ 如果子账户的管理员做了坏事，第一反应可能是关闭 CloudTrail 来"毁灭证据"。有了这条 SCP，即使子账户的 Root 用户也无法关闭日志记录。
10.6 SCP 继承
Root
├── SCP: FullAWSAccess
│
├── OU: Production
│ ├── SCP: DenyS3Delete
│ └── Account: Prod-App
│ └── 有效权限 = FullAWSAccess ∩ DenyS3Delete
│
└── OU: Development
└── Account: Dev-App
└── 有效权限 = FullAWSAccess
解读： Production OU 下的账户不能删除 S3 对象（多了一道限制），而 Development OU 下的账户没有额外限制。这很合理——生产环境要更严格。
11. Control Tower
11.1 通俗理解
如果说 Organizations 是"集团架构图"，那 Control Tower 就是"集团管理手册 + 自动化流程"。它帮你：
- 自动创建符合规范的新账户（不用手动配置几十项设置）
- 自动应用安全基线（不用担心新账户"裸奔"）
- 持续监控合规状态（不用人工检查）
11.2 核心组件
- 顶部是 Management Account（集团总部），通过 Control Tower 管理一切。
- 中间是 Account Factory（账户工厂）：像生产线一样，按模板批量创建新账户。每个新账户自动配好安全基线、日志、网络。
- 左下 Audit Account（审计账户）：集团审计部门的专用账户，所有安全事件汇总到这里。
- 右下 Log Archive Account（日志归档账户）：所有账户的 CloudTrail/Config 日志统一归档到这里，防篡改。
- 两侧的 Guardrails（护栏）：附加在组织上的治理规则，分为 Preventive（预防型，基于 SCP，直接禁止危险操作）和 Detective（侦测型，基于 Config Rules，发现违规后报警）。
- 考试怎么考："如何快速建立一个安全合规的多账户环境？" → Control Tower。
核心功能：
- Landing Zone — 自动创建安全的多账户架构
- Guardrails — 预定义的治理规则（Preventive + Detective）
- Account Factory — 自动化创建符合规范的新账户
- Dashboard — 集中查看合规状态
🧠 和 Organizations 的关系： Control Tower 是 建立在 Organizations 之上 的。Organizations 提供多账户的"骨架"，Control Tower 提供自动化的"管理流程"。你可以只用 Organizations 不用 Control Tower，但用 Control Tower 一定会用到 Organizations。
12. 最佳实践
账户安全
- ✅ Lock away root user access keys — 不为 root 创建 access keys
- 为什么：Root 的 access key 一旦泄露，等于给了攻击者"上帝模式"
- ✅ Enable MFA for root — 必须为 root 启用 MFA
- 为什么：即使密码被盗，没有 MFA 设备也登不进来
- ✅ Create individual IAM users — 每人独立用户，不共享凭证
- 为什么：共享账号无法审计"谁做了什么"
- ✅ Use groups — 通过组管理权限，不直接给用户附加策略
- 为什么：100 个开发者逐个改权限 vs 改一次 Group 权限，效率差 100 倍
权限管理
- ✅ Grant least privilege — 最小权限原则，只给需要的权限
- 为什么：权限越多，被滥用的风险越大
- ✅ Use roles for EC2 — EC2 应用使用 IAM Role，不用 access keys
- 为什么：Role 临时凭证自动轮换，access key 永久有效一旦泄露就危险
- ✅ Use roles for cross-account — 跨账户使用 AssumeRole
- 为什么：临时凭证比永久凭证安全
- ✅ Use Permission Boundaries — 限制开发者创建的角色权限
- 为什么：防止权限提升攻击
凭证管理
- ✅ Rotate credentials — 定期轮换密码和 access keys
- 为什么：长期不变的凭证更容易被破解
- ✅ Remove unused credentials — 删除不使用的凭证
- 为什么：不用的凭证 = 不设防的后门
- ✅ Use temporary credentials — 优先使用 STS 临时凭证
- 为什么：自动过期，即使泄露损害也有限
监控审计
- ✅ Enable CloudTrail — 记录所有 API 调用
- 为什么：没有日志 = 出事了无法追查
- ✅ Use Access Analyzer — 发现意外的外部访问
- 为什么：你可能不知道哪个 S3 bucket 被设成了公开
- ✅ Review Credentials Report — 定期审查凭证报告
- 为什么：发现"僵尸账号"和过期凭证
- ✅ Use IAM Access Advisor — 移除未使用的权限
- 为什么：90 天没用过的权限，大概率不需要
13. 考试重点
高频考点
💡 IAM 基础
- IAM is global, not regional
- Root account should be secured with MFA
- Users have no permissions by default
- Access Keys 用于 CLI/SDK，不能用于 Console
- Policies 用 JSON 编写
💡 Roles vs Users
- 优先使用 Roles 而不是在 EC2 中嵌入 access keys
- EC2 通过 Instance Profile 获取 Role
- Role credentials 自动轮换
💡 跨账户访问
- 小规模：使用 Resource-based policy
- 大规模：使用 AssumeRole
- 可要求 MFA 才能 AssumeRole
💡 STS 临时凭证
- 默认有效期 1 小时
- 最长可达 12 小时
- 包含 AccessKeyId, SecretAccessKey, SessionToken
💡 权限评估
- Explicit Deny 永远优先
- 没有明确允许 = Implicit Deny
- SCP 限制整个账户（Organizations）
典型场景题
场景 1: 开发者需要访问 S3，但你想限制他们只能访问自己的文件夹
解题思路: 一个 Policy 管 100 个用户？不可能写 100 个。用 Policy Variables ${aws:username} 动态匹配。
答案: 使用 Policy Variables ${aws:username}
场景 2: 企业用户想用 Active Directory 登录 AWS Console 解题思路: 关键词"Active Directory" + "AWS Console" = 企业 SSO 场景。AD 支持 SAML 2.0。 答案: SAML 2.0 Federation + AssumeRoleWithSAML
场景 3: 移动应用用户需要上传文件到 S3 解题思路: 移动用户 = 外部用户，不应该创建 IAM User。需要联合身份。AWS 推荐用 Cognito。 答案: Cognito Identity Pool + Web Identity Federation
场景 4: 防止 IAM 管理员给自己授予过多权限 解题思路: 关键词"防止权限提升" = Permission Boundaries。给管理员画一个权限天花板。 答案: Permission Boundaries
场景 5: 子账户不能关闭 CloudTrail 解题思路: "子账户" = Organizations 环境。"不能做某事" = 需要 Deny。跨账户统一限制 = SCP。 答案: Organization SCP + Deny cloudtrail:StopLogging