基线：等级保护要求
身份鉴别、访问控制、安全审计与入侵防范是等级保护的基本项，测评时会查策略、查记录，也查实际配置。只写制度不做配置，往往在这一项失分，而且整改时要动系统，比事前做贵得多，测评前先自查一遍。
最小必要与分级
数据安全与个人信息保护都要求按必要范围授权，权限应与数据级别匹配。给一个人开全库读权限，即便他从没看过，也已经不符合最小必要。检查时这一条最容易被直接指出，而整改往往要动业务流程。
特权与第三方
管理员、运维与外包账号是高风险面，需要审批、限时、录屏与双人复核。第三方接入应单独开号、限定范围与期限，不能共用内部账号，否则一旦出事连操作人是谁都查不出来，外包账号要有到期时间。
AI 新增的权限面
模型接口密钥、向量库、提示词模板、工具调用与 Agent 身份，都是传统权限体系没覆盖的新对象。它们常以服务账号形式存在，最容易长期不轮换、权限过大，也最容易在盘点时被漏掉，盘点时要单独列一节。
边界：控制不等于信任
访问控制能降低越权概率，但挡不住有权限的人恶意导出。需要与数据防泄漏、行为审计和离职管理配合，单靠权限配置无法解决内部风险。这条边界要提前讲清，否则权限治理会被当成万能方案。
适用与不适用
适合谁
- 要通过等级保护测评或客户安全审计的企业
- 正在做权限治理与账号清理的 IT 团队
- 上线了 Agent 与模型服务、需要补权限管理的公司
不适合谁
- 只有几名员工、系统完全离线的小团队
- 希望用一次权限梳理解决全部内部风险的组织
典型场景
某集团在等保测评前做自查，发现有十七个离职账号仍可登录，两个外包账号拥有数据库管理员权限。整改后账号与人事系统联动、特权操作走审批与录屏，测评时这两项从扣分项变成了加分说明，整改清单在会上逐条过。
可执行步骤
- 把合规要求拆成可检查项，逐条对应到具体系统、配置与责任人，抄送安全。
- 比对在职名单与账号清单，清理离职、调岗与长期未使用的账号，留档备查。
- 梳理特权与外包账号，改为审批后限时授权并记录操作，到期自动回收，回收记录留存。
- 为模型密钥、向量库与工具调用建立权限归属与轮换规则，并入整改清单。
- 把季度权限复核写进流程，指定复核人并保留签字记录，并纳入项目台账。
常见坑
- 制度写了最小权限，实际配置仍是全员可读，测评时被当场指出，整改又必须动系统，往往来不及，只能先扛着。
- 离职账号靠人工通知停用，只要漏掉一个，就是一个长期存在的后门，往往事后追查才发现，影响范围说不清。
- 外包共用内部账号，操作记录无法归到具体的人，出事时互相推诿，复盘时各方各说各话，补救往往来不及。
- 模型密钥写在脚本里长期不轮换，比员工账号更难被发现，泄露了可能很久都没人知道，追责时无从下手。
自检与验收清单
- 账号清单是否与在职名单定期比对并留记录，含差异
- 权限授予是否与数据级别和岗位职责匹配，有依据
- 特权与外包账号是否有审批、限时与录屏，按季更新
- 模型密钥是否有明确归属与定期轮换，含归属人
- 季度权限复核是否有复核人签字记录，有书面结论
常见问题
等保测评过了就合规了吗？
测评通过说明当时满足基线要求，但访问控制是持续过程。人员变动、系统上线与新业务接入都会改变权限现状，需要靠定期复核维持，不能一次通过就长期沿用，持续维护才算数。
服务账号怎么管？
给服务账号明确责任人、限定调用范围、定期轮换凭证，并禁止用于人工登录。没有责任人的服务账号最容易变成无人认领的高权限入口，盘点时也最容易被跳过，禁止人工登录。
第三方运维要开什么权限？
按任务开最小范围、设时限、走审批，并保留会话记录。能通过跳板机完成的，不要直接给数据库或主机权限；任务结束当天回收，不要留到下次再说，跳板机日志也要留存，需在项目内先讲清。