云账号与权限管理：IAM用户、角色、策略，多账号组织架构，安全最佳实践
聊到云上运维，我第一个想跟你聊的，就是账号和权限。
你想想看，云上的一切资源——服务器、数据库、存储桶——都归账号管。账号要是被黑了，那基本就是「裸奔」。我见过不少团队，一开始图省事，所有人共用一个根账号。结果呢？某天不小心删了个生产库，连谁干的都查不出来。嗯，这种坑，踩一次就够了。
IAM 核心三件套：用户、角色、策略
说白了，IAM 就是云上的「门禁系统」。它管三件事：你是谁（用户/角色）、你能进哪（策略）、你怎么进（认证）。
1. IAM 用户
每个开发者、每个服务，都应该有自己的 IAM 用户。我个人习惯，绝不给任何人共享密钥。哪怕是个临时实习生，也单独建个用户，用完就删。
- 长期凭证：Access Key ID + Secret Access Key。适合程序调用，但记得定期轮换。
- 临时凭证：通过 STS 获取，有效期几小时到几天。安全性更高，我推荐能用临时就别用长期。
我的习惯：给每个 IAM 用户都加上「必须使用 MFA」的条件。别嫌麻烦，多一步验证，安全提升一个量级。
2. IAM 角色
角色和用户最大的区别是：角色没有固定的密码或密钥。它是「被信任的实体」才能扮演的。比如，你的 EC2 实例要访问 S3，你不需要把密钥塞进代码里。给实例绑定一个角色就行。
我在项目中遇到过，有人把数据库密码写死在配置文件中，结果代码泄露，数据库被拖库。用角色，就没有这种烦恼。
// 示例：为 EC2 实例授予 S3 只读权限的角色信任策略
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}3. 策略（Policy）
策略就是权限的「说明书」。它用 JSON 格式写，告诉云服务「谁可以干什么」。我见过最经典的错误：策略写得太宽，给了「*」通配符。结果一个测试账号能删整个账号的资源。
避坑指南：我曾经接手过一个项目，安全组策略里写了 "Action": "*"，"Resource": "*"。这就是所谓的「超级管理员权限」。后来被安全扫描工具扫出来，紧急整改了一周。记住：最小权限原则，永远只给刚刚好的权限。
多账号组织架构
公司大了，一个账号根本不够用。开发、测试、生产混在一起，风险极高。我建议用多账号架构，把环境彻底隔离。
| 账号类型 | 用途 | 安全级别 |
|---|---|---|
| 管理账号（Root） | 组织管理、账单查看 | 最高，仅限 2-3 人操作 |
| 安全账号 | 集中日志、审计、告警 | 高，只读为主 |
| 开发账号 | 日常开发、测试 | 中，允许灵活操作 |
| 生产账号 | 线上服务、核心数据 | 极高，变更需审批 |
为什么这么分？说白了，就是「爆炸半径」的概念。开发账号被黑了，最多丢点测试数据。生产账号被黑了，那可能就是事故了。我习惯用 AWS Organizations 或阿里云的资源目录来统一管理，再配合 SCP（服务控制策略）做底线管控。
安全最佳实践
这部分我踩过的坑最多，直接给你总结几条铁律：
- 根账号只用来开账号。日常操作绝对不要用根账号。我见过有人用根账号登录控制台，还开了个浏览器自动保存密码……嗯，后来被社工了。
- 强制 MFA。所有人类用户，必须用 MFA。程序调用用临时凭证。没有例外。
- 定期审计权限。每季度跑一次 IAM 权限报告，看看有没有「僵尸用户」或「过度授权」。我习惯用 CloudTrail 或操作审计服务，记录所有 API 调用。
- 使用权限边界。给 IAM 用户或角色设置权限边界，防止他们给自己提权。比如，开发账号的角色，最多只能创建低权限的策略。
- 密钥轮换。Access Key 每 90 天换一次。自动化脚本跑，别手动换，容易漏。
一句话总结：云上安全，账号是门，权限是锁。门没锁好，再好的防火墙也没用。我每次做架构评审，第一件事就是看 IAM 策略。这步对了，后面才稳。
好了，这一章就聊到这儿。下一章我们聊聊网络架构——VPC、子网、安全组，怎么搭才又安全又省钱。到时候见。