复核要有固定周期
季度复核是最低要求：导出全量授权，按岗位与在职状态比对，由部门负责人逐条确认。为什么必须由业务确认？因为只有业务知道某人是否还需要这份权限，安全团队只能判断形式合规，判不了业务必要性。
离职转岗靠联动
人事系统的状态变更应自动触发权限冻结或调整，而不是等安全团队月度导出。怎么落地？先在入离调转四个节点上打通，明确同步延迟上限；延迟超限的场景要有人工兜底，否则会出现已离职仍可登录的窗口。
孤儿账号定期清
长期无人使用的账号既占授权额度也藏风险。做法是按最近登录时间分级：超过设定周期未登录的先停用、再通知、最后清理，每一步留记录。边界是服务账号与集成账号不能按人号规则处理，要单独建册管理。
告警要能收敛
审计告警初期往往噪声过大，运维两周后就整体关掉。怎么优化？先把高频误报规则降级为统计，只对敏感数据导出、批量授权变更、非工作时间登录保留实时告警，并每月回看命中与漏报，避免误判。
适用与不适用
适合谁
- 已完成权限系统上线、需要长期运营的企业
- 有季度或年度审计要求的集团与子公司
- 安全团队人员有限、需要明确运营节奏的团队
不适合谁
- 尚未完成身份源统一、也没有接口的项目
- 没有人事系统接口、无法做状态联动的组织
典型场景
某集团上线权限平台半年后，安全团队发现复核流于形式。调整后改为部门负责人线上确认、超时未确认默认收回；离职冻结从事后导出改成接口触发，孤儿账号按九十天未登录先行停用。三个月后复核工时下降，遗留授权明显减少。
可执行步骤
- 定下复核周期与确认人，超时未确认的授权一律默认收回
- 打通入职、离职、调动、转岗四个节点，设定同步延迟上限
- 按未登录时长分级处理孤儿账号，服务类账号单独建册管理
- 收敛告警规则，只对高风险场景保留实时告警，并定期回看
常见坑
- 复核交给安全团队独自完成，业务未参与，确认流于签字，遗留授权年年重复出现，整改无从下手。
- 只做月度导出比对，离职当天到下次比对之间仍可登录，形成可被利用的时间窗口。
- 告警规则只加不减，噪声淹没真实风险，运维最终整体关闭告警，等于没有监控，风险重新裸露。
自检与验收清单
- 复核是否有固定周期与超时默认收回规则
- 入离调转是否有接口联动与延迟上限
- 孤儿账号与服务类账号是否分开处理
- 告警规则是否每季度回看命中与漏报
常见问题
复核一定要部门负责人确认吗？
建议如此。安全团队能判断授权是否符合规则，判断不了业务是否仍需要。由负责人确认并留痕，既提高准确性，也在出现问题时明确了责任主体，避免事后在安全与业务之间互相推诿。
没有人力做季度复核怎么办？
先缩小复核范围：只复核高权限角色与敏感数据访问，普通角色改为半年一次。宁可缩小范围做扎实，也不要全量走形式；形式化复核在审计时反而会成为管理缺陷的证据。
服务账号怎么管？
单独建册，登记用途、责任人、关联系统与失效条件，禁止用于人工登录。服务账号不参与人员离职联动，但要有到期复核机制，长期无人认领的应停用后清理，避免成为长期潜伏的入口。