员工维护多套账号，调岗离职后的权限回收依赖人工通知，敏感操作记录分散在各应用中。
员工需要维护多套账号，应用各自实现登录和权限功能。人员调岗或离职后，权限回收依赖人工通知，关键操作日志分散在不同系统。
项目周期分两批实施约 14 周
协作角色人力、信息安全、应用负责人、运维与内控团队
交付范围身份模型设计、认证中心研发、存量系统适配、灰度切换与运营支持
DELIVERY CONSTRAINTS
落地时必须同时处理的约束
- 存量系统横跨多种技术栈与年代
- 认证改造不能影响正常业务访问
- 旧系统缺少标准协议和可用接口
核心问题
存量系统技术栈差异大；角色定义不统一；部分旧系统缺少标准接口；认证改造不能影响日常业务。
不是功能清单，而是一组关键决策
建设统一身份目录和认证中心，制定应用接入规范；通过 OAuth2、网关适配和代理方式分批接入，并统一权限审批和审计查询。
统一身份，不强行重写应用
标准系统采用 OAuth2 接入，旧系统通过网关或代理适配，控制改造成本与上线风险。
权限跟随组织变化
把入职、调岗、离职事件与权限申请回收流程关联，减少人工通知遗漏。
审计记录集中查询
统一采集登录与敏感操作事件，建立按人员、应用和时间追踪的证据链。
核心建设范围Node.js / OAuth2 / API Gateway / Kubernetes
- 组织与身份目录
- 单点登录
- 角色及数据权限
- 应用接入管理
- 权限申请与审批
- 操作审计与风险查询
从调研到试运行的交付记录
每个阶段都有可评审的产出，并在进入下一阶段前完成关键口径确认。
- 01第 1–3 周
身份梳理
身份源、组织模型、角色与应用接入分级
- 02第 4–7 周
中心建设
身份目录、认证中心、接入规范与审计模型
- 03第 8–12 周
分批接入
标准应用接入、旧系统适配、权限流程
- 04第 13–14 周
灰度切换
账号映射、并行验证、应急回退与交接
项目结果，以验收与试运行口径呈现
以下数据已做匿名化处理，反映的是特定项目范围和阶段，不作为对其他项目的效果承诺。
首期接入系统
分两批完成切换
统一员工身份
替代多账号登录入口
敏感操作审计
按人、应用、时间查询
已交付成果交付物覆盖产品、研发、迁移与运维交接
- 身份与权限模型
- 认证中心及管理后台
- 应用接入 SDK 与规范
- 存量系统适配组件
- 审计查询平台
- 切换与应急回退方案