场景一：离职与调岗
账号未停用、权限未回收，前员工仍能访问系统，是最常见也最难解释的问题。处置是把账号状态与人事流程联动，离职当天自动禁用，调岗时先回收再按新岗位重授，避免权限只增不减，联动要在系统里做，不要靠通知。
场景二：共享账号
共用管理员账号、共用无线口令、共用测试账号，会让操作无法归因。处置是一人一号、强制多因素认证，对确需共享的设备改用个人凭证加集中管理，而不是把口令写在便签上贴在机柜门后，共享账号要定期清理。
场景三：对象越权
接口只校验登录不校验归属，改一个编号就能读别人的数据。处置是服务端强制做对象级鉴权与租户过滤，并在测试中加入越权用例，而不是只在前端隐藏入口，那种做法挡不住任何人，越权用例要进回归。
场景四：特权运维
运维通道长期开放、提权无需审批、操作无录屏，一旦账号失守就是全线失守。处置是堡垒机集中接入、临时提权、双人复核与会话留存，重点是把「长期在线」改成「按需开通」，特权操作要有审批单号，上线后再补很被动。
场景五：密钥与令牌
密钥硬编码在代码、令牌长期有效、离职后仍在用，是自动化系统里的常见漏洞。处置是密钥托管、短期令牌、定期轮换与仓库扫描，并给每个服务单独凭证，避免一处泄露全线可用，轮换要尽量自动化。
适用与不适用
适合谁
- 发生过账号或权限问题的企业，愿意整改
- 系统数量多、账号分散在各部门的组织
- 需要给外包与第三方开权限的团队
不适合谁
- 单机离线、无多用户体系的场景，无账号体系
- 尚未建立账号清单的组织，先做盘点
典型场景
某互联网公司在一次红队演练中被发现：用离职员工的旧账号登录后台，再通过修改订单编号读到了其他商户的结算信息。整改包括人事联动停用、对象级鉴权改造与越权测试入回归，演练复测时两条路径都被阻断，演练报告同步给了业务负责人。
可执行步骤
- 拉出全量账号清单，与人事在职与调岗数据做一次逐条比对，明确跟进人。
- 把离职停用改为系统联动触发，取消依赖人工通知的环节，并标注责任人。
- 为关键接口补对象级鉴权与租户过滤，并加自动化越权用例，由主管确认。
- 特权操作改为审批后限时授权，全程录屏并留存会话记录，由安全团队复核。
- 密钥统一托管，每个服务单独凭证，按周期自动轮换，在系统里留操作记录。
常见坑
- 离职流程只发邮件通知信息技术部门，没人确认是否真的执行，账号就一直活着，谁也不知道它还在。
- 前端隐藏了按钮就以为做了权限控制，直接调接口照样能读到数据，常规测试也测不出来，往往来不及补救。
- 运维图方便长期开着提权通道，日志也没人看，等于把门长期虚掩着无人看守，旧问题被固化下来。
- 测试与生产共用一套密钥，测试环境泄露就等于生产环境泄露，一处失守等于全线失守，问题会一直藏着。
自检与验收清单
- 账号清单是否与人事在职数据逐条比对过，有差异
- 离职停用是否由系统联动触发而非人工，非人工
- 关键接口是否有对象级鉴权与租户过滤，含越权
- 特权操作是否限时授权并留存会话录屏，有录屏
- 密钥是否按服务隔离并定期自动轮换，轮换有记录
常见问题
员工离职当天停号会不会影响交接？
可以先做权限降级再停用：把账号转为只读、收回敏感权限，交接完成后再停用。关键是时间点与责任人明确，而不是把停用留成待办事项，最后没人认领，交接期要缩短，建议写进制度。
内部系统也要做对象级鉴权吗？
要。内部人员同样可能误操作或越权查看，尤其是人事、财务与客服系统。对象级鉴权能防止改编号读他人数据，成本通常低于事后追责与补救，测试要覆盖所有常见入口，建议提前对齐。
外包人员怎么管？
单独开户、限定系统与数据范围、设到期时间，并要求通过堡垒机操作。任务结束当天回收，保留操作记录；不要给外包配内部通用账号，那等于放弃了归因能力，到期当天必须回收。