# 云身份与权限管理
> **学习指南**：提示词工程解决的是"怎么把话说清楚"，云账号权限管理解决的是"谁能做什么事"。本章节会围绕一个问题展开：**在云端世界里，如何既能方便地授权，又不把钥匙交给不该给的人？**
在开始之前，建议你先补两块"基础砖"：
- **Token 是什么**：可以先阅读 [大语言模型入门](../8-artificial-intelligence/llm-principles.md) 的「分词 & Token」部分。
- **Prompt 是什么**：如果你还不熟悉 System / User / Assistant 的基本结构，可以先看 [提示词工程](../8-artificial-intelligence/prompt-engineering/)。
---
## 0. 引言：为什么刚上云就"踩雷"了？
很多人刚开始使用云服务时都会遇到类似的情况：
- 为了省事，直接把 AccessKey 写在代码里提交到 GitHub；
- 给所有员工都开了"管理员权限"，结果有人误删了生产数据库；
- 项目交接后，不知道谁手里还有旧员工的账号密码；
- 听说要开 MFA，但觉得"麻烦"就一直拖着没开。
直觉上，我们会以为是：**"这些员工安全意识不够"**。
但大多数时候，问题并不在于人，而在于**没有建立正确的权限管理体系**。
面对这些挑战，单纯依靠"小心点操作"已经行不通了。我们需要一套系统的权限管理方法论，这正是**IAM（Identity and Access Management，身份与访问管理）**试图解决的问题。
---
## 1. 什么是 IAM/RAM？从"门禁系统"说起
### 1.1 类比：公司的智能门禁
想象一下，你们公司搬到了一栋新写字楼：
| 场景 | 没有 IAM 的做法 | 有 IAM 的做法 |
| :--------- | :----------------------------- | :------------------------------------------- |
| 新员工入职 | 给他一把能开所有门的万能钥匙 | 给他一张门禁卡，只能刷他办公区域的门 |
| 员工离职 | 钥匙丢了就丢了，也不知道谁拿着 | 立即在系统里注销他的门禁卡，所有门都打不开了 |
| 外包人员 | 把钥匙借给他几天 | 发临时门禁卡，设置3天后自动失效 |
| 访客 | 前台配一把钥匙给他 | 发一次性访客码，只能进会议室 |
**IAM（Identity and Access Management，身份与访问管理）**，就像是这套"智能门禁系统"：
- **身份（Identity）**：谁？员工、外包、访客、应用程序
- **访问（Access）**：能进哪些门？能做什么操作？
- **管理（Management）**：怎么发钥匙、怎么收钥匙、怎么查记录
### 1.2 AWS IAM vs 阿里云 RAM
不同的云厂商都有自己的 IAM 实现：
| 云厂商 | 服务名称 | 核心概念 |
| :--------- | :----------------------------------- | :------------------------ |
| **AWS** | IAM (Identity and Access Management) | User、Group、Role、Policy |
| **阿里云** | RAM (Resource Access Management) | 用户、用户组、角色、策略 |
| **腾讯云** | CAM (Cloud Access Management) | 用户、用户组、角色、策略 |
| **华为云** | IAM | 用户、用户组、委托、策略 |
| **Azure** | Azure AD + RBAC | User、Group、Role、RBAC |
虽然名字不同，但**核心概念都是相通的**：
- **用户（User）**：代表一个具体的人或应用程序
- **用户组（Group）**：批量管理一批用户的权限
- **角色（Role）**：定义一组权限，可以被"扮演"
- **策略（Policy）**：具体的权限规则（允许/拒绝做什么）
---
## 2. 用户、组、角色：到底该用哪个？
### 2.1 三种"身份"的区别
用一个办公室的场景来类比：
| 概念 | 类比 | 适用场景 | 特点 |
| :------------------ | :----------------------------- | :------------------- | :--------------------------------- |
| **用户（User）** | 正式员工，有自己的工位和门禁卡 | 长期、稳定的团队成员 | 有永久凭证（密码、AK/SK） |
| **用户组（Group）** | 部门，如"技术部"、"销售部" | 批量管理权限 | 不能登录，只是权限容器 |
| **角色（Role）** | 临时访客证、外包临时卡 | 临时授权、跨账号访问 | 没有永久凭证，靠"扮演"获取临时凭证 |
### 2.2 真实案例：一个创业公司的权限演进
**阶段一：创始团队（2-3人）**
```
问题：直接用根账号（Root Account）登录控制台，因为"省事"
风险：根账号拥有所有权限，一旦泄露整个账号就废了
```
**阶段二：团队扩张（5-10人）**
```
改进：给每个人创建 IAM User，分配不同权限
问题：
- 运维小王离职了，他的 AK/SK 散落在哪些服务器上？
- 新来的前端需要 S3 只读权限，后端需要 RDS 权限，手动一个个配太麻烦
```
**阶段三：规范化（10-30人）**
```
改进：
1. 按角色创建 IAM Group：
- Developers（开发）：S3、EC2、RDS 读写
- DevOps（运维）：全权限，但需要 MFA
- ReadOnly（只读）：查看所有资源，不能修改
- QAs（测试）：测试环境资源访问
2. 使用 IAM Role：
- EC2 实例使用 Instance Profile，不再在服务器上放 AK/SK
- 跨账号访问用 Role Assume，不用共享 AK/SK
- CI/CD 用 OIDC Federation，不用存储长期凭证
```
**阶段四：多账号/企业级（30人+）**
```
架构：
- Master Account（主账号）：只用来管理账单和组织结构，不放任何资源
- Audit Account（审计账号）：收集所有账号的日志
- Dev Account（开发账号）：开发环境
- Staging Account（预发布账号）：测试环境
- Prod Account（生产账号）：线上环境，权限最严格
权限流转：
- 开发人员默认只有 Dev 账号的只读权限
- 需要修改生产环境时，提工单申请 Assume 到 Prod 的临时 Role
- 所有 Assume 操作都被 CloudTrail 记录，定期审计
```
---
## 3. 角色与策略：权限管理的"灵魂"
### 3.1 角色的本质：信任 + 权限
IAM Role 有两个核心组成部分：
1. **信任策略（Trust Policy）**：谁可以扮演这个角色？
2. **权限策略（Permission Policy）**：扮演成功后能做什么？
用一个话剧表演的类比：
| 概念 | 类比 | 说明 |
| :-------------------- | :--------------------- | :----------------------------------------------------------------------------------------- |
| **Role（角色）** | 剧本里的"哈姆雷特" | 定义了要演什么戏（权限） |
| **Trust Policy** | 导演说"谁能演哈姆雷特" | 可能是"本剧团的演员"（本账号用户）、"隔壁剧团借来的演员"（跨账号）、"特邀嘉宾"（外部 IdP） |
| **Permission Policy** | 剧本内容 | 哈姆雷特能做什么：说台词、决斗、发疯（具体权限） |
| **Assume Role** | 演员上台表演 | 小李被导演选中演哈姆雷特，上台后他就拥有了剧本里定义的所有权限 |
| **临时凭证** | 演出证 | 小李拿到一个"临时演出证"，演出结束后就失效了 |
### 3.2 策略（Policy）：权限的"语法"
IAM Policy 是一个 JSON 文档，定义了"谁能对什么资源做什么操作"。
**一个完整的 Policy 示例**：
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadWrite",
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::my-app-bucket/*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "ap-northeast-1"
},
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
},
{
"Sid": "DenySensitiveData",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::my-app-bucket/sensitive/*"
}
]
}
```
**关键字段解释**：
| 字段 | 含义 | 示例 |
| :------------ | :--------------------------------- | :----------------------- |
| **Version** | Policy 语法版本 | "2012-10-17" |
| **Statement** | 权限声明数组，可包含多个规则 | [...] |
| **Sid** | 声明 ID，可选，用于标识这条规则 | "AllowS3ReadWrite" |
| **Effect** | 效果：Allow（允许）或 Deny（拒绝） | "Allow" |
| **Action** | 允许/拒绝的操作，支持通配符 | "s3:GetObject", "s3:\*" |
| **Resource** | 作用的资源，用 ARN 标识 | "arn:aws:s3:::bucket/\*" |
| **Condition** | 可选，满足特定条件时才生效 | 区域限制、MFA 要求等 |
### 3.3 权限的优先级：Deny > Allow > 默认拒绝
IAM 的权限评估逻辑可以用一句话总结：**显式 Deny 永远赢，没有 Allow 就是拒绝**。
评估流程如下：
```
1. 先看有没有 Deny 策略
├─ 有 Deny → 拒绝（不管有没有 Allow）
└─ 没有 Deny → 继续看
2. 再看有没有 Allow 策略
├─ 有 Allow → 允许
└─ 没有 Allow → 拒绝（默认拒绝原则）
```
**实战案例：保护敏感数据**
```json
// 策略1：给开发者的普通权限
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "arn:aws:s3:::company-data/*"
}
// 策略2：保护敏感目录（即使开发者有 s3:* 也不能访问）
{
"Effect": "Deny",
"Action": ["s3:*"],
"Resource": "arn:aws:s3:::company-data/sensitive/*"
}
```
**关键点**：
- 开发者虽然有 `s3:*` 的 Allow 权限
- 但敏感目录有显式的 Deny 规则
- Deny 优先级更高，所以开发者无法访问敏感数据
- 即使开发者是管理员，这个 Deny 也有效（除非是根账号）
---
## 4. 访问密钥（AK/SK）：一把需要谨慎保管的"钥匙"
### 4.1 AK/SK 是什么？
Access Key（访问密钥）是云服务提供的一种长期凭证，用于程序化的 API 调用。它由两部分组成：
| 组成部分 | 名称 | 作用 | 类比 |
| :-------------------- | :----------- | :------------------------- | :--------- |
| **Access Key ID** | 访问密钥 ID | 标识你是谁（类似于用户名） | 银行卡号 |
| **Secret Access Key** | 秘密访问密钥 | 证明你是你（类似于密码） | 银行卡密码 |
### 4.2 为什么 AK/SK 是"高危物品"？
**真实案例：某创业公司的教训**
小李是一家创业公司的新晋后端工程师。入职第一周，他的任务是调试一个文件上传功能。
```python
# 小李写的代码（有严重安全问题！）
import boto3
# 为了方便调试，直接把 AK/SK 写在代码里
s3 = boto3.client(
's3',
aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
region_name='ap-northeast-1'
)
def upload_file(file_path, bucket_name, object_name):
s3.upload_file(file_path, bucket_name, object_name)
print(f"文件已上传到 s3://{bucket_name}/{object_name}")
# 测试上传
upload_file('./test.jpg', 'my-company-bucket', 'uploads/test.jpg')
```
**一周后发生的事情**：
1. 小李提交代码到 GitHub（包括 AK/SK）
2. GitHub 上的代码被爬虫扫描到，AK/SK 被提取
3. 攻击者使用这些凭证，在公司账号里创建了大量 EC2 实例挖矿
4. 月底收到账单：额外消费 12,000 美元
5. 审计发现 AK/SK 泄露，小李被约谈...
**这个案例告诉我们什么？**
| 错误做法 | 正确做法 |
| :-------------------------- | :----------------------------------------------- |
| 把 AK/SK 硬编码在代码中 | 使用 IAM Role，让程序自动获取临时凭证 |
| 把 AK/SK 提交到 Git 仓库 | 使用 `.gitignore` 忽略配置文件，使用密钥管理服务 |
| 长期使用同一个 AK/SK 不轮换 | 定期轮换 AK/SK，使用临时凭证替代长期凭证 |
| 给 AK/SK 分配过大权限 | 遵循最小权限原则，只授予必要的权限 |
### 4.3 AK/SK 的安全使用指南
**场景一：本地开发**
```bash
# 正确做法：使用 AWS CLI 配置凭证，不写在代码里
aws configure
# 然后根据提示输入 Access Key ID 和 Secret Access Key
# 这些信息会被保存在 ~/.aws/credentials，权限设置为 600
# 代码中不需要任何凭证配置
import boto3
s3 = boto3.client('s3') # 自动从 ~/.aws/credentials 读取
```
**场景二：服务器/EC2**
```python
# 正确做法：使用 IAM Instance Profile
# 1. 创建一个 IAM Role，附加需要的权限（如 S3ReadOnly）
# 2. 创建一个 Instance Profile，关联这个 Role
# 3. 启动 EC2 时，选择这个 Instance Profile
# 代码中完全不需要凭证
import boto3
s3 = boto3.client('s3') # 自动从 EC2 元数据服务获取临时凭证
# 临时凭证会自动轮换，无需担心过期
```
**场景三：CI/CD 流水线**
```yaml
# 正确做法：使用 OIDC Federation（OpenID Connect）
# 以 GitHub Actions 为例：
# 1. 在 AWS 创建 OIDC Identity Provider，信任 GitHub
# 2. 创建一个 IAM Role，信任策略允许 GitHub 的特定仓库扮演
# 3. 在 GitHub Actions 中配置
name: Deploy
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # 关键：允许请求 OIDC token
contents: read
steps:
- uses: actions/checkout@v3
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
aws-region: ap-northeast-1
# 注意：这里没有 Access Key！完全使用临时凭证
- name: Deploy
run: aws s3 sync ./build s3://my-bucket/
```
**总结：AK/SK 使用的安全层级**
| 安全等级 | 做法 | 适用场景 | 风险等级 |
| :------- | :-------------------------- | :------------------------ | :------- |
| 最高 | 使用 IAM Role（无长期凭证） | EC2、Lambda、ECS、CI/CD | 极低 |
| 高 | 使用 OIDC Federation | GitHub Actions、GitLab CI | 低 |
| 中 | 使用密钥管理服务 | 本地开发、小团队 | 中 |
| 低 | 使用环境变量 | 快速原型、个人项目 | 高 |
| 极低 | 硬编码在代码中 | 任何场景都不推荐 | 极高 |
---
## 5. 多因素认证（MFA）：给你的账号加把"锁"
### 5.1 什么是 MFA？
MFA（Multi-Factor Authentication，多因素认证），也叫 2FA（Two-Factor Authentication，双因素认证），是一种安全机制，要求用户在登录时提供**两种或以上**不同类型的认证因素：
| 因素类型 | 是什么 | 例子 |
| :------------------------- | :----------------- | :------------- |
| **知识因素**（你知道什么） | 只有用户知道的信息 | 密码、PIN 码 |
| **持有因素**（你有什么） | 用户拥有的物理设备 | 手机、硬件密钥 |
| **生物因素**（你是什么） | 用户的生物特征 | 指纹、面部识别 |
### 5.2 为什么 MFA 这么重要？
**真实数据告诉你答案**：
| 攻击方式 | 没有 MFA 时的成功率 | 有 MFA 时的成功率 |
| :----------------------- | :------------------ | :------------------------------ |
| 密码猜测/暴力破解 | 很高 | 极低（还需要第二因素） |
| 钓鱼攻击获取密码 | 很高 | 极低（钓鱼页面无法获取 MFA 码） |
| 密码泄露（其他网站泄露） | 很高 | 极低（不知道第二因素） |
**微软安全报告（2020）**：启用 MFA 可以阻止 **99.9%** 的自动化攻击。
### 5.3 MFA 实战：为 AWS 根账号开启 MFA
**步骤一：登录 AWS 控制台**
1. 使用根账号邮箱和密码登录
2. 在右上角点击你的账号名，选择 "Security Credentials"
**步骤二：启用 MFA**
1. 找到 "Multi-factor authentication (MFA)" 区域
2. 点击 "Assign MFA device"
3. 选择 MFA 设备类型（推荐"Authenticator app"）
**步骤三：配置虚拟 MFA**
1. 在手机上安装 Google Authenticator 或 Microsoft Authenticator
2. 扫描二维码或手动输入密钥
3. 输入 App 上显示的 6 位验证码（连续输入两个，因为验证码每 30 秒刷新）
**完成！** 你的根账号现在有了 MFA 保护。
---
## 6. 跨账号访问：如何安全地"串门"？
### 6.1 为什么需要跨账号访问？
随着业务增长，很多公司会使用**多账号架构**来隔离不同环境：
| 账号类型 | 用途 | 权限要求 |
| :------------------ | :--------------------- | :----------------- |
| **Master Account** | 组织管理、账单结算 | 几乎不使用 |
| **Security Audit** | 集中收集所有账号的日志 | 只读访问其他账号 |
| **Shared Services** | 共享资源（镜像仓库等） | 其他账号只读访问 |
| **Development** | 开发环境 | 开发者完全权限 |
| **Staging** | 测试/预发布环境 | 测试人员权限 |
| **Production** | 生产环境 | 严格限制，需要审批 |
**问题：Shared Services 账号里的镜像，怎么让 Production 账号的 EC2 拉取？**
- 方案 A：把 AK/SK 写在 Production 的用户数据里 （危险！AK/SK 泄露风险）
- 方案 B：使用跨账号 Role Assume （推荐！临时凭证，自动轮换）
### 6.2 跨账号 Role Assume 的原理
```
账号 A（Production） 账号 B（Shared Services）
| |
| 1. 请求 Assume Role |
| "我想扮演账号 B 的 ECRReadRole" |
|------------------------------------------>|
| |
| 2. 检查信任策略 |
| "账号 A 可以扮演我吗？" |
| |
| 3. 返回临时凭证 |
| AccessKeyId, SecretKey, SessionToken |
|<------------------------------------------|
| |
| 4. 使用临时凭证访问 ECR |
| docker pull 账号B.dkr.ecr... |
```
**关键点**：
- 临时凭证有效期默认 1 小时，最长可配置 12 小时
- 不需要在代码里存储任何长期凭证
- 信任策略可以限制谁可以扮演这个角色（如指定账号、指定外部 ID）
### 6.3 实战：配置跨账号 ECR 访问
**场景**：Production 账号的 EC2 需要拉取 Shared Services 账号的 Docker 镜像。
**步骤一：在 Shared Services 账号创建 IAM Role**
1. 登录 Shared Services 账号的 AWS 控制台
2. 进入 IAM -> Roles -> Create role
3. 选择"Another AWS account"
4. 输入 Production 账号的 Account ID
5. 可选：勾选"Require external ID"并输入一个随机字符串（增加安全性）
6. 附加权限：AmazonEC2ContainerRegistryReadOnly
7. 给 Role 命名：CrossAccountECRReadRole
**步骤二：获取 Role ARN**
创建完成后，复制 Role 的 ARN：
```
arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole
```
**步骤三：在 Production 账号配置 EC2 实例**
方式 A：使用 Instance Profile（推荐）
1. 在 Production 账号创建 IAM Role（EC2 用）
2. 信任策略：信任 EC2 服务
3. 权限策略：允许 Assume 跨账号 Role
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole"
}
]
}
```
4. 创建 Instance Profile，关联这个 Role
5. 启动 EC2 时，选择这个 Instance Profile
方式 B：在 EC2 用户数据里动态 Assume Role
```bash
#!/bin/bash
# 安装 AWS CLI
yum install -y aws-cli
# Assume 跨账号 Role
CREDS=$(aws sts assume-role \
--role-arn arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole \
--role-session-name EC2PullSession)
# 提取临时凭证
export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r '.Credentials.SessionToken')
# 登录 ECR
aws ecr get-login-password --region ap-northeast-1 | \
docker login --username AWS --password-stdin SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com
# 拉取镜像
docker pull SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
```
**步骤四：测试跨账号访问**
在 Production 的 EC2 上执行：
```bash
# 测试能否 Assume Role
aws sts get-caller-identity
# 应该显示：arn:aws:sts::PRODUCTION_ACCOUNT_ID:assumed-role/CrossAccountECRReadRole/EC2PullSession
# 测试能否列出 Shared Services 的 ECR 仓库
aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID
```
**完成！** 现在 Production 的 EC2 可以安全地拉取 Shared Services 的镜像，而无需共享任何长期凭证。
---
## 7. 实战：构建安全的权限体系
### 7.1 从零开始搭建权限架构
假设你是一个 10 人创业公司的技术负责人，需要从零设计 AWS 权限架构。以下是推荐的实施步骤：
**阶段一：根账号保护（第 1 天）**
```
目标：保护根账号，这是最重要的账号
1. 启用根账号 MFA（必须）
- 推荐硬件 MFA（YubiKey），或者 Google Authenticator
2. 创建 IAM 管理员账号
- 用户名：admin（或你的名字）
- 权限：AdministratorAccess（但后续会收紧）
- 启用 MFA
3. 删除根账号的 Access Key（如果创建了的话）
- 根账号永远不应该有 AK/SK
4. 配置根账号使用告警
- 使用 CloudWatch + SNS，一旦根账号登录就发邮件/短信
```
**阶段二：团队权限分组（第 1 周）**
```
目标：给团队成员分组，批量管理权限
1. 分析团队角色：
- 后端开发（2人）
- 前端开发（1人）
- 移动端开发（1人）
- 产品经理（1人）
- 设计师（1人）
- 创始人/管理员（3人）
2. 创建 IAM Groups：
Group: Developers
├── 成员：所有开发（后端、前端、移动端）
├── 权限：
│ ├── EC2: 启动、停止、查看（但不能删除别人的实例）
│ ├── S3: 读写开发环境的 bucket
│ ├── RDS: 只读权限（不能修改生产数据库）
│ └── CloudWatch: 查看日志
└── 限制：只能操作 ap-northeast-1 区域
Group: ProductTeam
├── 成员：产品经理、设计师
├── 权限：
│ ├── S3: 只读（查看数据文件）
│ ├── CloudWatch Dashboard: 查看监控图表
│ └── Cost Explorer: 查看账单（但不能修改）
└── 限制：只读权限，不能修改任何资源
Group: Administrators
├── 成员：创始人、技术负责人
├── 权限：AdministratorAccess
└── 要求：必须使用 MFA 才能操作
3. 给每个人创建 IAM User，加入对应的 Group
- 不要给个人直接附加权限，一律通过 Group 管理
- 启用 MFA（强制要求）
```
**阶段三：应用层权限优化（第 2-4 周）**
```
目标：让应用程序安全地访问 AWS 资源
1. EC2 实例使用 Instance Profile
- 不再在服务器上配置 AK/SK
- 创建 IAM Role，附加需要的权限（如 S3 读写）
- 创建 Instance Profile，关联这个 Role
- 启动 EC2 时选择这个 Instance Profile
- 应用代码中直接使用 boto3，无需配置凭证
2. 如果必须使用 AK/SK（第三方集成）
- 使用 AWS Secrets Manager 存储 AK/SK
- 应用启动时从 Secrets Manager 读取
- 设置定期轮换（90天）
- 监控 AK/SK 的使用情况
3. 配置 CloudTrail 记录所有 API 调用
- 创建单独的 S3 bucket 存储日志
- 设置日志文件校验（防止篡改）
- 配置 SNS 通知关键事件（如根账号使用、策略变更）
```
**阶段四：安全加固（持续）**
```
目标：建立持续的安全监控和改进机制
1. 启用 AWS Config
- 监控资源配置变更
- 检查合规性（如安全组是否开放了 0.0.0.0/0）
2. 启用 IAM Access Analyzer
- 持续分析资源策略
- 识别外部访问（如 S3 bucket 是否公开）
3. 定期审查 IAM 配置
- 每月检查一次未使用的 IAM User、Role
- 检查 Access Key 的使用情况
- 验证 Group 成员是否合理
4. 建立安全事件响应流程
- 如果发现 AK/SK 泄露：立即删除、轮换、审计影响范围
- 如果发现异常 API 调用：立即调查、限制权限
```
---
## 8. 常见误区与避坑指南
### 8.1 十大 IAM 反模式
| # | 反模式 | 为什么不好 | 正确做法 |
| :-- | :--------------------------- | :--------------------------------------------- | :----------------------------------------------- |
| 1 | 使用根账号进行日常操作 | 根账号拥有所有权限，一旦泄露无法限制损害 | 创建 IAM 管理员账号，根账号仅在必要时使用 |
| 2 | 给所有人 AdministratorAccess | 违反最小权限原则，增加误操作和内部威胁风险 | 按角色分组，只授予必要的权限 |
| 3 | 在代码中硬编码 AK/SK | AK/SK 容易通过 GitHub 泄露，且难以轮换 | 使用 IAM Role、环境变量或密钥管理服务 |
| 4 | 长期不轮换 AK/SK | 增加凭证泄露后的风险敞口时间 | 设置 90 天轮换策略，或更好的——使用临时凭证 |
| 5 | 忽略 MFA | 密码泄露后账号直接沦陷 | 为所有 IAM 用户启用 MFA，尤其是高权限用户 |
| 6 | 不使用 CloudTrail | 无法审计谁做了什么操作，出事后无法溯源 | 启用 CloudTrail，并将日志存储到独立的审计账号 |
| 7 | IAM Policy 过于宽松 | 如 `Resource: "*"`、`Action: "*"`，增加攻击面 | 明确指定资源 ARN 和具体 Action |
| 8 | 不清理离职员工的 IAM User | 僵尸账号可能成为后门 | 建立离职流程，立即禁用并删除 IAM User |
| 9 | 不使用 IAM Access Analyzer | 无法发现过度宽松的资源策略（如公开 S3 bucket） | 启用 IAM Access Analyzer，定期检查外部访问 |
| 10 | 不在测试环境验证 Policy | 直接在生产环境应用 Policy，可能导致服务中断 | 使用 IAM Policy Simulator 测试，先在测试环境验证 |
---
## 9. 名词对照表
| 英文术语 | 中文对照 | 解释 |
| :--------------------------------------- | :-------------- | :----------------------------------------- |
| **IAM (Identity and Access Management)** | 身份与访问管理 | 云服务中管理用户身份和访问权限的服务 |
| **RAM (Resource Access Management)** | 资源访问管理 | 阿里云的 IAM 服务名称 |
| **Root Account** | 根账号 | 注册云账号时创建的拥有者账号，拥有最高权限 |
| **IAM User** | IAM 用户/子账号 | 由根账号创建的子身份，用于日常操作 |
| **IAM Role** | IAM 角色 | 临时性权限载体，无长期凭证，需要被"扮演" |
| **IAM Policy** | IAM 策略 | JSON 格式的权限规则定义 |
| **ARN** | 亚马逊资源名称 | 全局唯一的资源标识符 |
| **AK/SK** | 访问密钥/密钥 | 程序访问云 API 的凭证 |
| **STS** | 安全令牌服务 | 提供临时安全凭证的服务 |
| **MFA** | 多因素认证 | 需要两个或以上因素的认证方式 |
| **SSO** | 单点登录 | 用户一次登录即可访问多个系统的认证方式 |
| **ExternalId** | 外部 ID | 用于防止困惑代理攻击的安全标识符 |
| **CloudTrail** | 云审计服务 | 记录云账号中所有 API 调用和操作的日志服务 |
---
## 总结：云账号权限管理的核心原则
云账号权限管理不是一蹴而就的，而是需要根据团队规模和业务需求持续演进：
1. **起步阶段**（1-10 人）：
- 保护根账号（MFA + 不用根账号日常操作）
- 创建 IAM 管理员账号
- 基本的分组（Developers、Admins）
2. **成长阶段**（10-50 人）：
- 细化的权限分组（前后端、运维、产品等）
- 使用 IAM Role 替代 AK/SK
- 启用 CloudTrail 审计
- 定期权限审查
3. **成熟阶段**（50 人以上 / 多账号）：
- 多账号架构（Dev、Staging、Prod 分离）
- 集中式日志审计账号
- 自动化权限审查和告警
- 完善的权限申请和审批流程
**核心原则记住三句话**：
1. **最小权限原则**：只给必要的权限，不要给 AdministratorAccess
2. **不用长期凭证**：优先使用 IAM Role 和临时凭证，避免 AK/SK 泄露
3. **启用 MFA**：特别是根账号和高权限账号，这是最有效的安全措施
---
> **延伸阅读**：
>
> - [AWS IAM 官方文档](https://docs.aws.amazon.com/iam/)
> - [阿里云 RAM 官方文档](https://www.aliyun.com/product/ram)
> - [AWS IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)