第四章 最小权限原则：理论、实施方法、常见误区
做IAM这么多年，我越来越觉得最小权限是安全防线的基石。你想想，权限给多了，就算其他防护做得再好，一个不慎就是全线崩溃。我见过太多案例——开发人员拥有生产环境删除权限，运维人员能访问客户数据库，服务账号可以调用不该碰的API。这些都不是攻击者多高明，而是我们自己把门开得太大了。
1. 理论：最小权限到底指什么？
说白了，就是主体只拥有完成本职工作所需的最小权限。多一分不要，少一分不能。这不是什么新鲜概念，从操作系统时代就有了。但在云和微服务架构下，它变得格外重要——因为权限粒度可以做到非常细。
我个人习惯把它拆成三个层面：
- 用户层面：普通员工不需要管理员角色，审计人员只读。
- 服务层面：微服务A只能访问自己的数据库，不能碰服务B的表。
- 数据层面：同一个表，某些人只能看部分字段（比如脱敏后的身份证号）。
我记得有一次帮一家电商公司做权限审计，发现他们的备份服务居然有S3的s3:DeleteObject权限。备份嘛，只需要读和写，根本不需要删。这就是典型的“多给了”。
2. 实施方法：落地才是硬道理
理论好讲，落地可不容易。我建议按照下面这几步走，每一步都有坑，我会一起说。
2.1 识别资源与权限边界
先搞清楚你的资产有哪些。API、数据库、存储桶、消息队列……然后画出一张权限地图。别指望一步到位，先从最核心的系统开始。
2.2 分析最小需求
对每个角色，问三个问题：
- 这个角色需要访问哪些资源？
- 需要哪种操作（读/写/执行/管理）？
- 在什么条件下可以访问（IP范围、时间、环境）？
我习惯让业务方和技术方坐在一起填一张表，避免只凭技术直觉。
2.3 定义策略 + 测试
写策略的时候，用白名单思想。拒绝所有，然后开放必需。下面是一个AWS IAM策略示例，只允许读取特定S3桶：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": ["arn:aws:s3:::my-prod-bucket", "arn:aws:s3:::my-prod-bucket/*"]
}
]
}注意，我没有给s3:PutObject或s3:DeleteObject。这就是最小权限的典型写法。
2.4 监控与定期审查
权限不是一成不变的。员工转岗、服务升级、业务调整，权限都需要跟着变。我建议每季度审计一次，用工具（比如AWS Access Analyzer、CloudSploit）检查“过度授权”的账号。
不同场景的策略对比
| 场景 | 建议策略 | 常见错误 |
|---|---|---|
| 开发人员访问生产库 | 只读权限，且通过堡垒机+操作审计 | 直接给Select/Update权限 |
| CI/CD部署服务 | 仅允许部署到特定环境，禁止删除 | 给FullAccess或Administrator |
| 外部合作伙伴API | 使用临时凭证+资源级别限制 | 创建长期密钥，未绑定资源 |
| 数据科学家分析用户数据 | 通过视图/脱敏层访问，不直接访问原始表 | 直接连接生产库的读写账号 |
3. 常见误区——我踩过的坑都在这儿
- 误区一：“先给最大权限，以后慢慢缩小”
我曾经在一家初创公司工作，技术总监说“先全开，出问题再收”。结果三个月后没人记得哪些权限是多余的，最后被安全审计抓了个典型。正确的做法：一开始就收紧，后面再根据需要放开。 - 误区二：最小权限=最小角色
不对。角色是逻辑分组，真正的最小权限是基于现场的策略。比如你不能因为“开发者”角色就无条件给所有开发一样权限——张三只负责前端，就不该有后端数据库的访问权。 - 误区三：只考虑人，不考虑服务
我见过一个案例：一个后台服务使用共享密钥连接数据库，密钥拥有所有权限。结果一个微服务被注入，攻击者直接删了整个数据库。服务间权限比人的权限更值得关注。 - 误区四：权限策略写一次就不管了
系统在变，权限策略也需要迭代。我建议把权限策略纳入CI/CD，每次修改都要走变更审批流程。
这张图展示了我推荐的最小权限落地流程。注意那个回环——定期审查发现问题后，需要回到“定义最小策略”重新调整，形成闭环。我曾经踩过的坑就是忽略了这个回环，以为部署后就不用管了，结果半年后权限早已偏离了设计目标。
最后再说一句：权限越小，风险越小。这不是让你捆住业务手脚，而是让你把门关好，钥匙只给该给的人。剩下的，靠审计、靠监控、靠自动化来保障。下一轮我们聊聊权限回收的话题——但那是后话了。