Easy-Vibe 云计算 IAM 实战：身份与访问管理的权限治理指南-平芜编程栈

Easy-Vibe 云计算 IAM 实战：身份与访问管理的权限治理指南

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

导读：本指南是 Easy-Vibe 课程中《7-基础设施与运维》附录的一部分（cloud-iam.md），系统讲解云上 IAM（Identity and Access Management，身份与访问管理）的核心概念与落地方法。文章以「如何在不把钥匙交给错误的人的前提下，方便地授予云访问权限」为主线，覆盖用户/组/角色/策略四类核心实体、AK/SK 密钥治理、MFA 多因素认证、跨账户 Role Assume，以及一套可照抄的 10 人团队权限架构实施方案。读完你将掌握 IAM 策略的 JSON 语法与优先级判定规则，并能独立为团队搭建最小权限、无长期密钥的云权限体系。

在深入之前，建议先补齐两个前置概念：Token 是什么可阅读大语言模型导论中的「Tokenization & Token」小节；Prompt 是什么可参考 Prompt 工程中 System / User / Assistant 的基本结构。

0. 引言：为什么一上云就容易「踩雷」

很多人第一次使用云服务时都有过类似的经历：

图省事把 AccessKey 直接写进代码并推送到 GitHub；
给所有员工都开了「管理员权限」，结果有人手滑删掉了生产数据库；
项目交接后，没人说得清还有谁持有离职员工的账号凭据；
听说过 MFA，但觉得「太麻烦」而从未启用。

直觉上我们会认为：「这些员工安全意识到位吗？」

但大多数情况下，问题并不在人，而在于缺少一套权限管理系统。

面对这些挑战，仅仅「小心一点」已经不够了。我们需要一套系统化的权限管理方法论——这正是IAM（Identity and Access Management）要解决的问题：Prompt 工程解决的是「如何把话说清楚」，而云权限管理解决的是「谁可以做什么」。

1. IAM/RAM 概览：从「门禁系统」讲起

1.1 类比：公司的智能门禁系统

假设公司搬进一栋新办公楼：

场景	没有 IAM	有 IAM
新员工入职	发一把能开所有门的万能钥匙	发一张只能开本部门区域的门禁卡
员工离职	钥匙丢了，没人知道在谁手里	在系统中立即注销其门禁卡——所有门都无法打开
外包人员	把钥匙借给他用几天	发放一张 3 天后自动过期的临时门禁卡
访客	前台发一把钥匙	发放一次性访客码，仅对会议室有效

IAM（身份与访问管理）就像这套「智能门禁系统」：

身份（Identity）：是谁？员工、外包、访客、应用程序；
访问（Access）：能开哪些门？允许执行哪些操作？
管理（Management）：钥匙如何发放、如何回收、如何留痕。

1.2 AWS IAM 与阿里云 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 实战案例：一家创业公司的权限进化史

阶段 1：创始团队（2-3 人）

问题：直接用 Root 账户登录控制台，因为「更方便」 风险：Root 账户拥有全部权限——一旦泄露，整个账户万劫不复

阶段 2：团队扩张（5-10 人）

改进：为每个人创建 IAM 用户，分配不同权限 新问题： - 运维工程师小王离职了——他的 AK/SK 还散落在哪些服务器上？ - 新来的前端需要 S3 只读权限，后端需要 RDS 权限——逐个手动配置太繁琐

阶段 3：标准化（10-30 人）

改进： 1. 按角色创建 IAM 用户组： - Developers（开发）：S3、EC2、RDS 读写 - DevOps（运维）：全权限，但必须使用 MFA - ReadOnly（只读）：可查看所有资源，不能修改 - QAs（测试）：测试环境资源访问 2. 使用 IAM 角色： - EC2 实例使用 Instance Profile，服务器上不再存放 AK/SK - 跨账户访问通过 Role Assume，不再共享 AK/SK - CI/CD 使用 OIDC Federation，不再存储长期凭据

阶段 4：多账户 / 企业级（30+ 人）

架构： - Master Account（主账户）：只做账单与组织管理，不部署资源 - Audit Account（审计账户）：集中收集所有账户的日志 - Dev Account（开发账户）：开发环境 - Staging Account（预发布账户）：测试环境 - Prod Account（生产账户）：生产环境，权限最严格 权限流转： - 开发者默认只对 Dev 账户有读写权限 - 需要变更生产环境时：提交工单，临时扮演 Prod 账户中的角色 - 所有 Assume 操作由 CloudTrail 记录，并定期审计

3. 角色与策略：权限管理的「灵魂」

3.1 角色的本质：信任 + 权限

一个 IAM 角色由两个核心部分组成：

信任策略（Trust Policy）：谁可以扮演这个角色？
权限策略（Permission Policy）：扮演角色之后可以做什么？

用一出戏剧来类比：

概念	类比	说明
角色（Role）	剧本里的「哈姆雷特」	定义了要演的是什么戏（权限集合）
信任策略（Trust Policy）	导演说「谁能演哈姆雷特」	可以是「本剧团的演员」（本账户用户）、「借来的别团演员」（跨账户）、「特邀嘉宾」（外部 IdP）
权限策略（Permission Policy）	剧本的内容	哈姆雷特能做什么：念台词、比剑、发疯（具体权限）
扮演角色（Assume Role）	演员登上舞台	小李被导演选为哈姆雷特，登上舞台后就拥有了剧本里定义的全部权限
临时凭据（Temporary Credentials）	演出许可	小李拿到一张「临时演出许可」，演出结束即失效

3.2 策略（Policy）：权限的「语法」

IAM 策略是一份 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	策略语法版本	"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 → 拒绝（默认拒绝原则）

实战案例：保护敏感数据

// 策略 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 依然生效（Root 账户除外）。

4. 访问密钥（AK/SK）：一把必须小心保管的钥匙

4.1 什么是 AK/SK

Access Keys（访问密钥）是云服务为程序化 API 调用提供的长期凭据，由两部分组成：

组成	名称	作用	类比
Access Key ID	访问密钥 ID	标识你是谁（类似用户名）	账号
Secret Access Key	秘密访问密钥	证明你是你（类似密码）	PIN 码

4.2 为什么 AK/SK 是「高危物品」

实战案例：一家创业公司的教训

小李是一家创业公司新来的后端开发。入职第一周，他需要调试一个文件上传功能：

# 小李的代码（严重的安全问题！） 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')

一周之后发生的事：

小李把代码推送到 GitHub（包括 AK/SK）；
GitHub 上的代码被爬虫扫描，AK/SK 被提取；
攻击者利用这些凭据创建了大量 EC2 实例挖矿；
月底账单：多出 12,000 美元；
审计时发现 AK/SK 泄露，小李被约谈……

这个案例教会我们什么？

错误做法	正确做法
在代码中硬编码 AK/SK	使用 IAM 角色，让程序自动获取临时凭据
把 AK/SK 提交进 Git 仓库	用`.gitignore`忽略配置文件，并使用密钥管理服务
长期不轮换同一套 AK/SK	定期轮换 AK/SK，优先用临时凭据替代长期凭据
给 AK/SK 过大的权限	遵循最小权限原则，只授予必要权限

4.3 AK/SK 安全使用指南

场景 1：本地开发

# 正确做法：用 AWS CLI 配置凭据，而不是写进代码 aws configure # 然后输入 Access Key ID 和 Secret Access Key # 它们会被保存在 ~/.aws/credentials 中，权限设为 600 # 代码中无需任何凭据 import boto3 s3 = boto3.client('s3') # 自动从 ~/.aws/credentials 读取

场景 2：服务器 / EC2

# 正确做法：使用 IAM Instance Profile # 1. 创建 IAM 角色，挂载所需权限（如 S3ReadOnly） # 2. 创建 Instance Profile 并关联该角色 # 3. 启动 EC2 时选择这个 Instance Profile # 代码中完全不需要凭据 import boto3 s3 = boto3.client('s3') # 自动从 EC2 元数据服务获取临时凭据 # 临时凭据会自动轮换，不用担心过期

场景 3：CI/CD 流水线

# 正确做法：OIDC Federation（OpenID Connect） # 以 GitHub Actions 为例： # 1. 在 AWS 中创建信任 GitHub 的 OIDC Identity Provider # 2. 创建 IAM 角色，其信任策略允许指定 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 角色（无长期凭据）	EC2、Lambda、ECS、CI/CD	极低
高	使用 OIDC Federation	GitHub Actions、GitLab CI	低
中	使用密钥管理服务	本地开发、小团队	中
低	使用环境变量	快速原型、个人项目	高
极低	在代码中硬编码	任何场景都不推荐	极高

5. 多因素认证（MFA）：给账户再加一把「锁」

5.1 什么是 MFA

MFA（Multi-Factor Authentication，多因素认证），也称 2FA（双因素认证），是一种要求用户在登录时提供两种或以上不同认证因素的安全机制：

因素类型	是什么	示例
知识因素（你知道什么）	只有用户本人知道的信息	密码、PIN
持有因素（你拥有什么）	用户持有的物理设备	手机、硬件密钥
生物因素（你是什么）	用户的生物特征	指纹、人脸识别

5.2 为什么 MFA 如此重要

真实数据说明问题：

攻击方式	没有 MFA 的成功率	有 MFA 的成功率
密码猜测 / 暴力破解	高	极低（缺少第二因素）
窃取密码的钓鱼攻击	高	极低（钓鱼页面拿不到 MFA 验证码）
密码泄露（来自其他网站）	高	极低（缺少第二因素）

微软安全报告（2020）：MFA 可以拦截99.9%的自动化攻击。

5.3 MFA 实战：为 AWS Root 账户开启 MFA

步骤 1：登录 AWS 控制台

使用 Root 账户邮箱和密码登录；
点击右上角账户名，选择「Security Credentials」。

步骤 2：启用 MFA

找到「Multi-factor authentication (MFA)」区域；
点击「Assign MFA device」；
选择 MFA 设备类型（推荐「Authenticator app」）。

步骤 3：配置虚拟 MFA

在手机上安装 Google Authenticator 或 Microsoft Authenticator；
扫描二维码或手动输入密钥；
输入 App 中显示的 6 位验证码（需要连续输入两次，因为验证码每 30 秒刷新一次）。

完成！你的 Root 账户现在受 MFA 保护了。

6. 跨账户访问：如何安全地「登门做客」

6.1 为什么需要跨账户访问

随着公司规模增长，许多企业采用多账户架构来隔离不同环境：

账户类型	用途	权限要求
Master Account	组织管理、账单	几乎不使用
Security Audit	集中收集所有账户日志	对其他账户只读
Shared Services	共享资源（镜像仓库等）	其他账户只读
Development	开发环境	开发者全权限
Staging	测试 / 预发布环境	测试人员权限
Production	生产环境	严格受限，需审批

问题：Production 账户的 EC2 如何从 Shared Services 账户拉取镜像？

方案 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 镜像。

步骤 1：在 Shared Services 账户创建 IAM 角色

登录 Shared Services 账户的 AWS 控制台；
进入 IAM → Roles → Create role；
选择「Another AWS account」；
输入 Production 账户的 Account ID；
可选：开启「Require external ID」并输入一串随机字符串（提高安全性）；
挂载权限：AmazonEC2ContainerRegistryReadOnly；
命名角色：CrossAccountECRReadRole。

步骤 2：获取角色 ARN

创建完成后复制角色的 ARN：

arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole

步骤 3：配置 Production 账户的 EC2 实例

方法 A：使用 Instance Profile（推荐）

在 Production 账户创建 IAM 角色（供 EC2 使用）；
信任策略：信任 EC2 服务；
权限策略：允许扮演跨账户角色：

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

创建 Instance Profile 并关联此角色；
启动 EC2 时选择该 Instance Profile。

方法 B：在 EC2 用户数据中动态 Assume Role

#!/bin/bash # 安装 AWS CLI yum install -y aws-cli # 扮演跨账户角色 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

步骤 4：测试跨账户访问

在 Production 账户的 EC2 上执行：

# 测试能否完成 Role Assume 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 权限架构。以下是推荐的实施步骤：

第一阶段：Root 账户保护（第 1 天）

目标：保护 Root 账户——最重要的账户 1. 为 Root 账户开启 MFA（强制） - 推荐硬件 MFA（YubiKey）或 Google Authenticator 2. 创建 IAM 管理员账户 - 用户名：admin（或你的名字） - 权限：AdministratorAccess（后期再收敛） - 开启 MFA 3. 删除 Root 账户的 Access Key（如果创建过） - Root 账户永远不应拥有 AK/SK 4. 配置 Root 账户使用告警 - CloudWatch + SNS：Root 账户登录时发送邮件/SMS 通知

第二阶段：团队权限分组（第 1 周）

目标：把团队成员分组，批量管理权限 1. 分析团队角色： - 后端开发（2 人） - 前端开发（1 人） - 移动端开发（1 人） - 产品经理（1 人） - 设计师（1 人） - 创始人/管理员（3 人） 2. 创建 IAM 用户组： Group: Developers ├── 成员：所有开发者（后端、前端、移动端） ├── 权限： │ ├── EC2：启动、停止、查看（但不能删除他人的实例） │ ├── S3：开发环境桶的读写 │ ├── RDS：只读（不能改动生产数据库） │ └── CloudWatch：查看日志 └── 限制：仅限 ap-northeast-1 区域 Group: ProductTeam ├── 成员：产品经理、设计师 ├── 权限： │ ├── S3：只读（查看数据文件） │ ├── CloudWatch Dashboard：查看监控图表 │ └── Cost Explorer：查看账单（不能修改） └── 限制：仅只读，不能改动任何资源 Group: Administrators ├── 成员：创始人、技术负责人 ├── 权限：AdministratorAccess └── 要求：操作必须使用 MFA 3. 为每个人创建 IAM 用户，并加入对应用户组 - 不直接给个人授权，始终通过用户组管理 - 开启 MFA（强制）

第三阶段：应用层优化（第 2-4 周）

目标：让应用安全地访问 AWS 资源 1. EC2 实例使用 Instance Profile - 服务器上不再配置 AK/SK - 创建 IAM 角色并挂载所需权限（如 S3 读写） - 创建 Instance Profile 并关联角色 - 启动 EC2 时选择该 Instance Profile - 应用代码直接用 boto3，无需配置凭据 2. 如果必须使用 AK/SK（第三方集成） - 用 AWS Secrets Manager 保存 AK/SK - 应用启动时从 Secrets Manager 读取 - 配置定期轮换（90 天） - 监控 AK/SK 的使用情况 3. 为所有 API 调用配置 CloudTrail - 创建独立的 S3 桶存放日志 - 开启日志文件校验（防篡改） - 对关键事件发送 SNS 通知（如 Root 账户使用、策略变更）

第四阶段：安全加固（持续进行）

目标：建立持续的安全监控与改进 1. 启用 AWS Config - 监控资源配置变更 - 合规性检查（如安全组是否对 0.0.0.0/0 开放） 2. 启用 IAM Access Analyzer - 持续分析资源策略 - 识别外部访问（如 S3 桶是否公开） 3. 定期检查 IAM 配置 - 每月排查未使用的 IAM 用户和角色 - 检查 Access Key 使用情况 - 核实用户组成员是否合理 4. 建立安全事件响应流程 - AK/SK 泄露时：立即删除、轮换、审计影响范围 - 发现异常 API 调用时：立即调查、收敛权限

8. 常见误区与规避策略

8.1 十大 IAM 反模式

#	反模式	为什么不好	正确做法
1	用 Root 账户做日常操作	Root 拥有全部权限，一旦泄露损失无法控制	创建 IAM 管理员账户，Root 仅在必要时使用
2	给所有人 AdministratorAccess	违反最小权限原则，放大误操作与内鬼风险	按角色分组，只授必要权限
3	在代码中硬编码 AK/SK	可能经 GitHub 泄露，且难以轮换	使用 IAM 角色、环境变量或密钥管理服务
4	长期不轮换 AK/SK	凭据泄露后风险窗口期过长	制定 90 天轮换策略，更好的是改用临时凭据
5	忽略 MFA	密码泄露后账户立刻失守	为所有 IAM 用户开启 MFA，高权限用户尤其必要
6	不用 CloudTrail	无法审计谁做了什么，出事后无法溯源	开启 CloudTrail，日志存放到独立审计账户
7	IAM 策略写得过于宽松	例如`Resource: ""`、`Action: ""`，攻击面过大	明确写出资源 ARN 和具体 Action
8	离职员工 IAM 用户不清理	僵尸账户会成为后门	建立离职流程，立即停用并删除 IAM 用户
9	不用 IAM Access Analyzer	无法发现过于宽松的资源策略（如公开的 S3 桶）	启用 IAM Access Analyzer，定期检查外部访问
10	不在测试环境验证策略	直接应用到生产可能导致服务中断	用 IAM Policy Simulator 测试，先在测试环境验证

9. 术语表

英文术语	中文翻译	说明
IAM（Identity and Access Management）	身份与访问管理	管理用户身份与访问权限的云服务
RAM（Resource Access Management）	资源访问管理	阿里云 IAM 服务的名称
Root Account	Root 账户	注册时创建的拥有最高权限的归属账户
IAM User	IAM 用户 / 子账户	由 Root 创建、日常使用的子身份
IAM Role	IAM 角色	没有长期凭据的临时权限实例，必须「扮演」
IAM Policy	IAM 策略	以 JSON 格式定义的权限规则
ARN	Amazon 资源名	全局唯一的资源标识符
AK/SK	访问密钥 / 秘密密钥	程序化访问云 API 的凭据
STS	Security Token Service	提供临时安全凭据的服务
MFA	多因素认证	需要两个及以上因素的认证方式
SSO	单点登录	一次登录即可访问多个系统的认证方式
ExternalId	外部 ID	用于防止混淆代理人攻击的安全标识
CloudTrail	云审计服务	记录云账户中所有 API 调用与操作

总结：云访问管理的三大核心原则

云访问管理不是一劳永逸的动作，而是必须随着团队规模与业务需求不断演进：

起步阶段（1-10 人）：
- 保护 Root 账户（MFA + 不用于日常操作）；
- 创建 IAM 管理员账户；
- 基础分组（Developers、Admins）。
成长阶段（10-50 人）：
- 精细化的权限分组（前端、后端、运维、产品等）；
- 用 IAM 角色替代 AK/SK；
- 开启 CloudTrail 审计；
- 定期做权限检查。
成熟阶段（50+ 人 / 多账户）：
- 多账户架构（Dev、Staging、Prod 分离）；
- 集中式日志审计账户；
- 自动化权限检查与告警；
- 完善的权限申请与审批流程。

记住三条核心原则：

最小权限原则：只授予必要权限，不给 AdministratorAccess；
不用长期凭据：优先使用 IAM 角色与临时凭据，杜绝 AK/SK 泄露；
开启 MFA：尤其是 Root 账户与高权限账户——这是性价比最高的安全措施。

本指南对应的完整原文见 docs/de-de/appendix/7-infrastructure-and-operations/cloud-iam.md，其他语言版本可在 docs 目录的zh-cn、en、ja-jp等子目录中找到。本文属于 Easy-Vibe 课程的基础设施与运维附录，建议结合课程主线的部署与运维相关内容学习；需要确认文中涉及的 STS、CloudTrail 等服务的完整定义，可对照上文第 9 节术语表逐一查阅。

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Easy-Vibe 云计算 IAM 实战：身份与访问管理的权限治理指南