3. 权限边界定义：粒度、范围与划分原则
权限边界这事儿，说白了就是回答三个问题：你能碰什么？能碰多大一块？碰到什么程度算越界？我在不少审计项目里见过，系统权限模型看着挺全，但一查边界全是糊的。
3.1 权限粒度的三个层次
粒度就是权限的最小操作单元。我习惯把粒度分成三层，这样好落地。
| 层级 | 典型举例 | 我常用的判断标准 |
|---|---|---|
| 粗粒度 | 角色 = 管理员 / 审计员 | 角色数量少（≤5），权限范围大，适合静态环境 |
| 中粒度 | 角色 + 资源类型 | 可区分“读密钥”和“写密钥”，但不对具体密钥ID做限制 |
| 细粒度 | 角色 + 资源实例 + 属性条件 | 比如：只能读属于自己部门的密钥，且有效期小于30天 |
选哪种粒度，取决于你的密钥管理系统的规模。如果你的组织只有几百个密钥，粗粒度问题不大。如果上百万密钥还粗放管理，那出事儿是迟早的。我在一家金融客户那见过——他们用了粗粒度角色，一个运维能看到所有客户的支付密钥。你想想看，这多危险。
我的小技巧： 先按中粒度起步，等审计发现越权事件后，再针对具体资源类型下钻到细粒度。一次性上细粒度，管理成本会压垮你。
3.2 权限范围：不仅是“有/没有”
很多新手认为权限只有“允许”和“拒绝”。但范围还要包括三个维度。
- 资源范围：能访问哪些密钥？全部？指定分类？特定标签？
- 操作范围：read、write、delete、export、rotate？这些操作得拆开算。
- 约束范围：时间窗口？来源IP？是否需要审批？是否可委派？
我记得有一次审计，对方声称“密钥管理员只能读密钥”。我拿他们的审计日志一看，发现read操作居然包含了密钥材料的明文导出。这就是操作范围没拆细。所以我在做审计时，一定会要求他们把每个操作对应的实际底层API列出来。
注意：很多系统把"list keys"和"read key material"混在一个read权限里。这是大坑。密钥管理里，list和read必须分开。
3.3 边界划分原则：四个铁律
我经手过十几个密钥权限模型的设计和审计，总结出四条原则。你可以直接用它们来卡自己系统的边界。
- 最小够用原则：每个角色只分配其完成工作所必需的权限。比如审计员只需要read，不需要write。我曾经见过一个生产环境，审计员居然有删除密钥的权限，说是"调试时图方便"——后来真误删了一批生产密钥。
- 职责分离原则：密钥创建、使用、审计这三件事必须由不同角色完成。记住，一个人不能既当运动员又当裁判。特别在密钥管理里，创建密钥和审批密钥必须是不同的人。
- 权限不可叠加越界原则：多个角色的权限合并后，不能产生原角色都不具备的越权操作。比如角色A有read权限，角色B有write权限，用户同时拥有A和B后，不能自动获得delete权限。这条很多RBAC实现都忽略了。
- 边界显性化原则：所有边界规则必须写进策略文档，并且能被自动检查。口头约定等于没有边界。
3.4 实际案例：一个密钥轮换权限的边界
拿一个最常见的操作“轮换密钥”来拆解。你可能会想，不就是把旧密钥换成新密钥吗？但它的边界其实很复杂。
# 一个典型的密钥轮换权限定义（JSON）
{
"effect": "Allow",
"actions": ["kms:ScheduleKeyRotation", "kms:CreateKey", "kms:DeleteKey"],
"resources": ["arn:kms:us-east-1:123456789012:key/*"],
"conditions": {
"ip_address": {"SourceIp": "10.0.0.0/8"},
"bool": {"kms:CallerPermissionBoundary": "true"}
}
}上面这个策略，看起来允许了轮换，但你仔细看——它包含了kms:DeleteKey。为什么要给轮换操作分配删除权限？这明显违反了最小够用原则。正确的做法是只给ScheduleKeyRotation和CreateKey（如果需要自动生成新密钥版本），删除应该单独由另一个角色执行。
经验之谈： 我在审计中常发现，运维为了方便，把“轮换”权限包成了“密钥全生命周期”权限。每次我都要求他们拆成最小操作单元。刚开始他们嫌麻烦，但后来有一次一个误操作删了生产密钥，所有人都闭嘴了。
3.5 边界划分的审计检查清单
每次我去客户现场做审计，都会拿着这个清单过一遍。你也可以直接用。
- ☐ 角色的每个权限是否都有明确的业务理由？（没有理由的权限全部移除）
- ☐ 密钥创建、使用、审计是否由不同角色执行？是否存在重叠？
- ☐ 同一个用户的多个角色合并后，是否出现了任何单一角色都没有的权限？
- ☐ 所有权限策略是否以文档形式存管，并且版本受控？
- ☐ 每个权限的操作范围是否精确到API级别？有没有模糊的"admin"或"full_access"？
- ☐ 资源范围是否限制了密钥的标签、区域或归属部门？
- ☐ 约束条件（IP、时间、审批）是否实际生效？有没有被绕过的方式？
我见过一个团队把审计检查清单贴在墙上，但半年没更新策略文档。你会发现最脆弱的边界不是技术，是人。