制度：角色与规则
先按岗位梳理角色，再定义每个角色能访问的数据范围与操作类型，形成角色矩阵。矩阵要能被业务看懂，否则申请时仍然靠口头描述，授权就无法标准化，复核时也没有基准，矩阵要每年重审一次。
流程：申请到回收
申请、审批、授予、复核、回收五步要有工单与时限，审批人按数据级别确定。回收要写进离职与调岗流程并与人事系统联动，避免依赖提醒，毕竟提醒总会漏，而漏一次就是一个敞口，五个步骤都留工单。
技术：统一身份与默认拒绝
统一身份认证、多因素认证与单点登录是底座；权限默认拒绝，按角色开通。应用内角色与数据权限仍要单独实现，不能指望单点登录解决授权问题，它只解决「你是谁」，认证只是最外面那一层，需提前设计。
技术：特权与审计
特权账号纳入集中管理，提权走审批、限时、录屏；所有授权变更与敏感操作进审计日志，并设置异常告警。日志要能按人、按系统、按时间检索，否则出事时只能一条条翻，日志要集中存储并限权，评审时最容易被跳过。
顺序：先清存量再建机制
先把离职账号、长期未用账号与过大权限清一遍，再上新机制。带着历史包袱建设，往往把旧问题固化进新系统，后面要改就得停业务，代价比现在高得多。存量清理通常比选型更花时间，但绕不过去。
适用与不适用
适合谁
- 账号与权限分散在多系统的中型以上企业
- 需要给审计或客户提供权限证明的团队
- 正在做身份治理项目的 IT 与安全部门
不适合谁
- 用户规模很小、权限简单的团队，暂无必要
- 只想买一套工具、不愿梳理角色的组织
典型场景
某制造企业先用两个月清理存量：停用二百余个僵尸账号、收回三十多项超范围权限；再上线统一身份与角色矩阵，把审批搬进工单。第三个月开始季度复核，第一次复核就发现八个岗位的角色定义与实际职责不符，复核差异当场登记。
可执行步骤
- 按岗位梳理角色，输出角色、数据范围与操作类型的对应矩阵，并说明依据。
- 清理僵尸账号与超范围权限，先完成存量整改，并把每一步都逐条留痕存档
- 上线统一身份与多因素认证，优先打通核心业务系统，同步给部门负责人。
- 把申请、审批、授予、复核与回收搬进同一工单流程，写明办理时限，超时自动提醒。
- 特权账号集中管理，提权走审批、限时并全程录屏，由项目负责人在系统里确认。
- 建立季度复核机制，明确复核人、复核范围与签字要求，结果统一归档备查
常见坑
- 先买工具再梳理角色，工具上线后没人会用，权限配置照旧混乱，最后只能推倒重来，时间成本很高。
- 只做认证不做授权，登录虽然统一了，应用内的数据权限仍然各自为政，越权就这样留下来，审计时才发现。
- 复核走形式，签个字就算完成，超范围权限年年保留，等到要整改的时候无从谈起，上线时间被拖后。
- 回收流程没和人事系统联动，仍然靠人提醒，漏号的情况照旧发生，时间一久就没人当真，后续维护更吃力。
自检与验收清单
- 是否输出角色、数据范围与操作类型的矩阵，并每年重审
- 僵尸账号与超范围权限是否完成存量清理，有留档
- 是否统一身份并为主要系统启用多因素认证，含核心系统
- 特权提权是否走审批、限时并全程录屏，录屏可检索
- 季度复核是否明确复核人并留签字记录，有范围
常见问题
统一身份做完是不是就管住了？
统一身份解决「谁在登录」，解决不了「他能看什么」。应用内的角色与数据权限要单独设计，尤其是跨部门共享的系统，否则越权仍然存在，只是入口变得更整齐了，越权仍然存在。
角色矩阵谁来做？
业务部门定义职责与数据需求，安全团队定义规则与边界，信息技术部门负责落地。只由一方制定，往往与实际工作脱节，最后被业务绕开，矩阵也就成了摆设，三方缺一不可。
季度复核工作量太大怎么办？
按风险排序：先复核特权账号、财务与人事系统，以及近半年有变动的岗位。全量复核可以拉长到半年或一年，高频复核集中在高风险部分，效果比平均用力更好，不必一次全查。