身份源必须唯一
员工账号散落在办公系统、人事表与各业务系统时，权限无法收敛到同一个人。开工前要确认人事系统能否作为权威源，并写明入离调转怎么同步、延迟容忍多少；否则每次复核都得人工比对，越查越乱。
接口决定自动化上限
账号开通与回收能否自动执行，取决于业务系统是否开放接口、是否支持批量操作。只能手工点选的系统要单独排期，不能默认进入首批范围；没有接口时怎么做？只能事后核验，做不到事前拦截与自动封禁。
日志口径先统一
各系统日志字段差异很大，用户名、操作对象、结果码各写一套。怎么让平台拼出完整链路？先定最小审计事件规范，再让试点系统按规范输出，否则上线后仍缺关键一步，追责时说不清谁在何时做了什么。
分级与组织是前提
角色设计来自岗位职责，可见范围来自数据分级。这两份依据没有书面化时，权限模型只能凭经验拍，评审时无法解释某人为何能看某类数据；技术能实现，但边界在于谁能看什么，必须由业务与安全共同确认。
适用与不适用
适合谁
- 账号分散在多个业务系统、需要统一收口的企业
- 要通过等保测评或客户安全评审的项目
- 准备把数据开放给 AI 助手、需先划定可见范围的团队
不适合谁
- 系统不超过两个、账号由一人维护的小团队
- 跳过身份源梳理、直接要求上平台的项目
典型场景
某集团信息中心要给内部 AI 助手开放工单与合同数据。安全负责人先清点系统：人事系统可作身份源，六个系统有账号接口，三个老系统只能导出日志。团队据此把首批范围缩到四个系统，老系统改走事后审计，并在评审会上说明缺口与补救时间。
可执行步骤
- 清点全部含账号的系统，标注身份源、接口能力与日志格式
- 确认人事或目录服务为唯一权威源，约定同步频率与延迟上限
- 起草最小审计事件规范，选两个系统试跑字段映射并修正差异
- 整理部门、岗位与数据级别三张表，作为角色设计的依据
常见坑
- 把权限项目当软件采购，没先统一身份源，上线后仍要人工比对账号，复核成本不降反升，半年后项目被搁置。
- 默认所有系统都能对接，排期时才发现老系统无接口，首批范围反复调整，业务方对进度失去信任。
- 日志字段不做规范，平台只能存原始文本，出事后仍要逐台翻记录，审计报告拿不出完整链路。
自检与验收清单
- 是否指定唯一权威身份源与同步方式
- 每个系统是否标注接口能力与日志格式
- 最小审计事件字段是否书面确认并冻结
- 部门、岗位、数据级别三张表是否齐备
常见问题
没有统一身份源，能不能先上审计？
可以，但要把边界说清：此时审计只能事后核验，无法实时拦截与自动回收。建议同步启动身份源整合，把审计当过渡，并在方案里写明过渡期补偿措施，例如月度人工核对与离职清单双签。
审计日志要存多久？
取决于行业监管要求与客户合同约定，常见做法是按事件类型分级设置留存期，敏感操作留得更久。具体年限以客户法务与监管口径为准，我方按确认后的期限配置存储与归档。
老系统没有接口怎么纳入？
两条路：导出日志做离线审计，接受时效延迟；或把该系统的账号开通收口到统一入口，由人工执行但全程留痕。两条都要在方案里写明覆盖缺口，避免验收时被理解为全部系统已纳入。