C2-08-IAM-身份与访问控制-本章目标与Authentication-与-Authorization与AWS-IAM与Root-User与IAM-User、Group、Role与Policy-权限到底写在哪里？
与Identity-based-与-Resource-based-Policy与Explicit-Deny-与权限评估与Least-Privilege与MFA与Access-Key-与临时凭证与AWS-STS与Federation-与-IAM-Identity-Center与Amazon-Cognito与AWS-Organizations-与-SCP与IAM-与-Organizations-的位置关系与GlobalShop-身份体系与高频对比与本章最后要形成的判断方式与与后续章节的关系
本篇是《C2-08-IAM-身份与访问控制》的第1个分篇，主要包含：本章目标、Authentication-与-Authorization、AWS-IAM、Root-User、IAM-User、Group、Role、Policy-权限到底写在哪里？
Identity-based-与-Resource-based-Policy、Explicit-Deny-与权限评估、Least-Privilege、MFA、Access-Key-与临时凭证、AWS-STS、Federation-与-IAM-Identity-Center、Amazon-Cognito、AWS-Organizations-与-SCP、IAM-与-Organizations-的位置关系、GlobalShop-身份体系、高频对比、本章最后要形成的判断方式、与后续章节的关系。
1-本章目标
安全的第一道问题不是“有没有防火墙”，而是 你是谁？
你如何证明你是谁？
你被允许做什么？
谁给了你这个权限？
应用访问 AWS 服务时用谁的身份？
多个 AWS Account 如何统一管理访问？
题库粗略曝光中 IAM 约 76 题，是整个 CLF-C02 最核心的服务之一。
2-Authentication-与-Authorization
Authentication = 身份验证 / 认证：证明“你是谁”。
Authorization = 授权：确定“你能做什么”。
Login + MFA
→ Authentication
Policy says s3:GetObject allowed
→ Authorization
这两个概念不能混。
3-★★★★★-AWS-IAM
正式名称： AWS Identity and Access Management，中文为： AWS 身份与访问管理。
3.1-为什么需要它
企业不能让所有员工和应用共享 root 密码，也不能把所有人都设置成管理员。
需要统一管理 AWS 身份、权限和策略。
3.2-它是什么
IAM 是 AWS 的身份与访问控制核心服务。
它管理 IAM User、Group、Role、Policy 等对象，并执行权限授权。
3.3-GlobalShop-场景
GlobalShop 的开发、运维、财务、安全团队拥有不同权限。
EC2/Lambda 也通过 Role 获取访问 S3、DynamoDB 等服务的权限。
3.4-常见组合
IAM User/Group/Role + Policy。
IAM Role + EC2/Lambda。
IAM + MFA。
跨账号 Role。
3.5-容易混淆
IAM 不等于 Cognito。
IAM 主要控制 AWS 资源访问。
Cognito 更偏应用终端用户身份。
3.6-题库通常怎么考
least privilege、user/group/role/policy、AWS resource permissions 几乎都属于 IAM。
4-★★★★★-Root-User
AWS Account 创建时有 Root User。
Root 权限极高，因此最佳实践是：
- 日常工作不要使用 Root。
- 为 Root 启用 MFA。
- 不要创建 Root Access Key。
- 只有必须使用 Root 的少数任务才使用它。
考试中看到“protect root account”，MFA 与避免日常使用 root 往往是核心。
5-IAM-User、Group、Role
5.1-IAM-User
表示某个长期身份，可能对应员工或技术用户。
可以有控制台凭证或 Access Key。
5.2-IAM-Group
把多个 IAM User 组织起来并统一附加权限策略。
Developers Group
├── Alice
├── Bob
└── Carol
5.3-★★★★★-IAM-Role
Role 与 User 最大直觉区别：
User
→ 长期身份
Role
→ 被某个可信主体 Assume
→ 获得临时凭证
应用访问 AWS 服务时，优先使用 Role，而不是把长期 Access Key 写进代码。
GlobalShop：
EC2 Product Service
│
│ Assume attached role
▼
IAM Role
│ s3:GetObject
▼
S3
6-★★★★★-Policy：权限到底写在哪里？
Policy = 策略。
IAM Policy 常以 JSON 表达权限，核心概念包括：
- Effect：Allow / Deny。
- Action：允许/拒绝什么 API。
- Resource：针对什么资源。
- Condition：在什么条件下。
教学示例：
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::globalshop-images/*"
}
CLF 不要求手写复杂 JSON，但要读懂：这是“允许读取某 S3 Object”的权限思想。
7-Identity-based-与-Resource-based-Policy
7.1-Identity-based-Policy
附加到 User / Group / Role，回答：
这个身份可以做什么？
7.2-Resource-based-Policy
附加到资源，例如 S3 Bucket Policy，回答：
谁可以对这个资源做什么？
8-Explicit-Deny-与权限评估
考试层面需要记住一个非常重要的安全原则：
Explicit Deny（显式拒绝）优先于 Allow。
但真实 IAM 权限评估还可能涉及 SCP、Permissions Boundary、Session Policy 等多层限制，因此不要把“看到一个 Allow 就一定能访问”当成完整规则。
9-★★★★★-Least-Privilege
Least Privilege = 最小权限原则。
需要读商品图片
→ 给 s3:GetObject
不需要删 Bucket
→ 不给 s3:DeleteBucket
不要为了方便直接授予 AdministratorAccess。
10-★★★★★-MFA
MFA = Multi-Factor Authentication = 多因素认证。
密码属于“你知道的东西”，MFA 再增加另一个因素，提高账号被盗后的防护能力。
Root 和高权限用户尤其应启用 MFA。
11-Access-Key-与临时凭证
Access Key 通常包括 Access Key ID 与 Secret Access Key，用于程序化访问。
危险做法：
const accessKey = "AKIA..."
const secret = "..."
写死在代码仓库、AMI、脚本里。
更好的 AWS 原生方式通常是：
Compute Service
→ IAM Role
→ Temporary Credentials
12-★★★★-AWS-STS
STS = Security Token Service = 安全令牌服务。
它与 AssumeRole、临时安全凭证紧密相关。
跨账号访问典型结构：
Account A User/Role
│
│ AssumeRole
▼
Account B Role
│
▼
Resource in Account B
13-★★★★-Federation-与-IAM-Identity-Center
企业通常已经有 Microsoft Entra ID、Okta、企业目录等身份系统，不希望每个员工再单独创建一个长期 IAM User。
Federation = 联合身份。
AWS IAM Identity Center 可用于集中管理员工对多个 AWS Account 和应用的访问，并结合外部身份源。
14-★★★-Amazon-Cognito
Cognito 的定位与 IAM 不同。
IAM
→ 管 AWS 资源访问身份
Cognito
→ App 的 Customer / End User 身份
GlobalShop 的消费者登录、注册、Social Login 等场景更接近 Cognito。
15-★★★★★-AWS-Organizations-与-SCP
Organizations 用来组织多个 AWS Account。
Organization
├── Management Account
├── Production OU
│ ├── Account A
│ └── Account B
└── Sandbox OU
└── Account C
SCP = Service Control Policy = 服务控制策略。
它是组织级权限边界工具之一。
最关键的理解：
SCP 不是给 IAM User “增加权限”的普通 IAM Policy。
它主要限制成员账号中身份可获得的最大权限范围。
16-IAM-与-Organizations-的位置关系
Organizations / SCP
→ Account / OU 治理边界
IAM
→ Account 内具体身份与权限
两者经常一起出现，但层级不同。
17-GlobalShop-身份体系
Employees
│
Identity Center / Federation
│
├── Dev Account
├── Prod Account
└── Security Account
Applications
EC2 / Lambda / ECS
│
▼
IAM Role
│
├── S3
├── DynamoDB
└── SQS
Customers
│
▼
Cognito
│
▼
GlobalShop App
18-高频对比
| 概念 | 核心定位 |
|---|---|
| IAM User | 长期 AWS 身份 |
| IAM Group | 用户集合与权限管理 |
| IAM Role | 可被 Assume 的临时权限身份 |
| Policy | 权限规则 |
| STS | 临时安全凭证 |
| MFA | 多因素认证 |
| Identity Center | Workforce 多账号集中访问 |
| Cognito | 应用终端用户身份 |
| Organizations | 多 AWS Account 组织治理 |
| SCP | Organizations 级权限边界 |
19-本章最后要形成的判断方式
不要把本章记成一串 AWS 产品名，而要形成下面的思考路径：
业务需求是什么？
↓
它属于哪一层问题？
↓
需要什么技术能力？
↓
哪些 AWS 服务提供这类能力？
↓
为什么某一个更贴合场景？
↓
其他相似服务为什么不合适？
真正稳定的考试能力不是“看到关键词就背答案”，而是能够从业务要求推导到技术能力，再从技术能力推导到 AWS 服务。
20-与后续章节的关系
C2 负责建立技术体系本身。
完整业务架构组合会在 C3 中继续展开。
719 道题的逐题选项解析放在 C4。
频率排名与强化学习放在 C5。
考前压缩复习放在 C6。
本篇概述
- 本篇梳理了本章目标相关的核心知识、适用场景与判断要点。
- 本篇梳理了Authentication-与-Authorization相关的核心知识、适用场景与判断要点。
- 本篇梳理了AWS-IAM相关的核心知识、适用场景与判断要点。
- 本篇梳理了Root-User相关的核心知识、适用场景与判断要点。
- 本篇梳理了IAM-User、Group、Role相关的核心知识、适用场景与判断要点。
- 本篇梳理了Policy-权限到底写在哪里？
相关的核心知识、适用场景与判断要点。
- 本篇梳理了Identity-based-与-Resource-based-Policy相关的核心知识、适用场景与判断要点。
- 本篇梳理了Explicit-Deny-与权限评估相关的核心知识、适用场景与判断要点。
- 本篇梳理了Least-Privilege相关的核心知识、适用场景与判断要点。
- 本篇梳理了MFA相关的核心知识、适用场景与判断要点。
- 本篇梳理了Access-Key-与临时凭证相关的核心知识、适用场景与判断要点。
- 本篇梳理了AWS-STS相关的核心知识、适用场景与判断要点。
- 本篇梳理了Federation-与-IAM-Identity-Center相关的核心知识、适用场景与判断要点。
- 本篇梳理了Amazon-Cognito相关的核心知识、适用场景与判断要点。
- 本篇梳理了AWS-Organizations-与-SCP相关的核心知识、适用场景与判断要点。
- 本篇梳理了IAM-与-Organizations-的位置关系相关的核心知识、适用场景与判断要点。
- 本篇梳理了GlobalShop-身份体系相关的核心知识、适用场景与判断要点。
- 本篇梳理了高频对比相关的核心知识、适用场景与判断要点。
- 本篇梳理了本章最后要形成的判断方式相关的核心知识、适用场景与判断要点。
- 本篇梳理了与后续章节的关系相关的核心知识、适用场景与判断要点。