权限最小化是精准授权而非盲目削减，需通过摸清家底、分级收敛、验证闭环和固化机制四步实现可识别、可收敛、可验证的治理。
权限最小化不是“砍权限”，而是让每个用户、服务或进程只拿到它真正需要的那一小块钥匙——不多不少，不早不晚。治理清洗的关键在于“可识别、可收敛、可验证”，而不是一次性清零再重配。
一、先摸清家底：自动化发现所有现存权限
盲目清理等于埋雷。必须先获取全量、实时、带上下文的权限快照：
- 扫描操作系统层：用getfacl（Linux）或icacls（Windows）导出关键目录/服务的ACL清单，重点覆盖
/etc、/var/log、C:\Windows\System32、注册表敏感键等 - 抓取服务账户权限：检查
systemd服务文件中的User=、SupplementaryGroups=字段；Windows中用Get-Service | Get-CimInstance -ClassName Win32_Service查服务运行身份 - 提取平台级权限配置：Tsuru用
tsuru role-list --json、ModelArts查策略绑定关系、OpenClaw导出Skill执行上下文权限声明 - 记录隐式权限：如SSH配置中的
AllowUsers/DenyUsers、PAM模块启用状态（pam_wheel.so是否生效）、sudoers中通配符规则
二、按角色与生命周期分级收敛
权限不是越少越好，而是要匹配“谁在什么阶段做什么”：
- 区分三类主体：人类操作员（运维/开发）、自动化服务（Agent/Job）、系统组件（sshd/nginx/kubelet），各自建立独立权限基线
- 绑定生命周期：临时账号（如外包接入）设7天自动过期；项目制服务账号随CI/CD流水线创建/销毁；长期服务账号禁止交互式登录，仅限API调用
-
拒绝“继承式授权”：禁用Linux中
root组全员赋权、Windows中Administrators组泛化使用；改用明确命名的最小权限组，例如log-reader、db-backup-operator
三、清洗动作必须带验证闭环
每一条删除或降权操作，都需附带“能否继续完成核心任务”的验证证据：
- 对用户账号：执行
sudo -lU username确认sudo能力范围，再模拟其常用命令（如git push、docker ps）是否仍成功 - 对服务账户：在非生产环境启动该服务，观察日志中是否有
Permission denied、Operation not permitted报错，特别关注文件锁、sysctl读写、procfs访问 - 对平台角色：用对应账号调用一次典型API（如Tsuru的
tsuru app-list、ModelArts的list-train-jobs），捕获HTTP 403并比对预期权限项 - 留白不删：若某权限用途不明，先加注释标记（如
# used by legacy backup script, last seen 2026-03-12），而非直接移除
四、固化机制防止反弹
清洗不是终点，是常态运营的起点：
- 把权限基线写进IaC：Ansible Playbook中用
file:模块固化ACL，Terraform中定义Tsuru Role绑定，GitOps仓库里保存所有AllowUsers白名单 - 加入CI流水线卡点：新服务部署前，自动校验其声明的最小权限是否超出组织策略（如禁止申请
sudo ALL、禁止请求SeDebugPrivilege） - 设置月度自动巡检：用脚本比对当前ACL与基线差异，对新增项触发审批工单；对连续90天未使用的权限组自动归档
- 审计日志必含权限上下文：所有
chmod、chown、tsuru role-update操作，必须记录操作人、目标资源、变更前后权限值
