开发者必读：系统最小权限实施指南

如果曾经因为懒得弄清楚服务账号具体需要什么权限，就直接给它 admin 权限，这篇文章就是写给你的。（没有指责的意思——我们都这么干过。）

最小权限说起来容易，在 deadline 压力下却极其容易被跳过。下面是关于如何在真实系统中真正实现最小权限的实际拆解，而不是仅仅在安全评审时嘴上说说。

从服务账号开始，而非人类账号

大多数团队把访问控制视为"哪个员工能看什么"的问题。实际上，服务账号和 API 密钥往往是更大的风险——它们长期存在、很少轮换，而且经常被过度授权，因为没人想在凌晨两点在生产环境里调试权限错误。

几个真正有效的习惯：

精细化令牌范围。 如果一个服务只读一张表，它就不应该拥有整个数据库的写权限。

定期轮换凭证，而不是"想起来的时候"。

记录每个特权凭证的使用情况。 如果你无法回答"这个密钥上周访问了什么"，那你就不是有可见性，你只是有希望。

基于角色的访问控制（RBAC）是规模化权限管理的标准模式，无需为每个用户手动管理。如果你在自己的技术栈中实现它，模式通常是这样的：

User -> assigned to -> Role -> grants -> Permissions

大多数团队陷入的陷阱是创建太多临时角色（"temp-access-jan-sprint"这类），然后永远不清理。要把角色当作一小套精心设计的、与实际工作职能绑定的集合，而不是例外情况的堆放地。

特权访问需要不同的 playbook

管理员账号和提升的服务角色应该比普通用户访问受到更严格的控制：

分离日常凭证和管理员凭证。 工程师的日常登录账号不应该是那个能修改生产基础设施的账号。

尽可能使用即时提升。 为特定任务请求临时特权访问，而不是永久持有。

任何特权操作都必须要求 MFA，没有任何例外，也没有什么"这只是内部的"借口。

这就是特权访问管理（PAM）的核心思想，值得将其作为基础设施的一级部分来对待，而不是在事件发生后才追加的事后考虑。

访问评审应该是 CI 任务，而不是季度末的恐慌

手动访问评审往往沦为橡皮图章——有人拿到 500 个权限的电子表格，然后全部批准，因为逐条阅读太耗时了。如果你能自动标记未使用的权限（90 天以上不活跃的账号、最近没有活动的角色），你的人工评审者就能专注于少数真正有风险的案例，而不是淹没在噪音里。

关于最小特权、RBAC、PAM 和治理如何在组织层面协同工作的更广泛框架，如果你在为自己的代码库之外设定策略，这份身份和访问管理指南是很好的参考。