最小权限是流程而不是配置项
最小权限原则听起来像一句口号，落到工程上其实是一套可检验的动作：明确每个身份需要完成哪些任务、把这些任务需要的权限列出来、按任务授予、定期回收不再需要的部分。它之所以难落地，是因为授权容易、回收困难，权限只会随项目推进不断累加。可执行的做法是让权限跟着角色与生命周期走，而不是跟着人走，并把回收变成有触发条件的固定动作。
基本信息
| 适用对象 | 服务器账号、服务账号、云资源与数据访问授权 |
|---|---|
| 落地抓手 | 角色定义、授权清单、定期复核、离职与项目结束回收 |
| 常见阻力 | 紧急授权长期不回收，临时权限变成事实上的默认权限 |
| 衡量方式 | 超额权限的账号数量、未复盘的授权条目数量 |
| 配套要求 | 访问行为需要留痕，否则无从判断某项权限是否真的被用到 |
落地五步
- 梳理任务清单：按角色列出实际要执行的操作，而不是按工具列出权限
- 定义最小角色：把同类任务合并成少数几个角色，避免每人一套规则
- 按角色授权：新成员加入时只挂角色，不单独追加权限
- 建立回收触发条件：人员变动、项目结束、工具下线都应触发权限复核
- 用行为数据校准：长期未被使用的授权应被清理，而不是默认保留
可检验的检查项
可检验的检查项
id opsuser # 身份与所属组是否与角色一致
sudo -l -U opsuser # 提权范围是否超出任务需要
find /srv -perm -o+w -type d | head -20 # 找出对所有人可写的目录
ssh-keygen -l -f ~/.ssh/authorized_keys # 核对授权密钥数量与指纹
last -n 20 # 最近登录记录，用于核对实际使用者
awk -F: '$3>=1000 {print $1}' /etc/passwd # 列出普通账号，逐一确认必要性常见超额授权
| 表现 | 根因 | 修正方向 |
|---|---|---|
| 服务账号可登录终端 | 创建时图方便给了完整 shell | 改为不可登录或限定来源 |
| 共享账号多人使用 | 省去逐人授权的工作量 | 拆分身份并保留审计粒度 |
| 临时授权未回收 | 事后无人负责复核 | 设定到期时间与复核责任 |
| 目录对所有人可写 | 应急放行后忘记收回 | 收回写权限并改按组授权 |
| 权限远超当前任务 | 按历史需求累积 | 按角色重授权并清理多余项 |
最小权限不是越小越好：权限过紧会导致大量临时加权限的操作，反而使授权临时化、无记录。判断标准是「稳定覆盖常态任务、偶发任务走有审批的临时授权」，而不是无限逼近零权限。
复核需要数据支撑。把提权日志与访问记录按账号聚合，长时间没有任何使用记录的授权项就是最优先的清理对象；没有数据的复核只能靠猜。