账号集成方案要能让实施人员照着执行，核心是围绕“身份来源—认证协议—账号映射—开通与回收—异常处理—验收”六个环节，逐项写清输入、动作、输出和责任人。编写顺序建议先盘点身份源与目标系统，再选定认证与同步方式，随后定义字段映射和唯一标识，最后补齐流程、异常回退与验收证据。本文聚焦身份认证与账号本身，访问授权策略和知识文档权限属于相邻主题，方案中注明边界即可。
要点总览（TL;DR）
- 账号集成方案按“身份来源—认证协议—账号映射—开通与回收—异常处理—验收”六段组织，每章写清输入、动作、输出和责任人，实施人员可直接照做。
- 编写前先完成身份源与目标系统盘点，记录字段来源、协议支持情况和账号现状问题，盘点结果决定方案范围与实施批次。
- 认证与同步方式按目标系统支持能力、账号生命周期需求、实时性要求选择，未确认的系统能力一律写成待验证项并注明验证责任人。
- 字段映射表覆盖登录名、唯一标识、姓名、部门、状态，唯一标识优先用工号并写明冲突处理规则；开通、变更、回收三类流程要有时效要求和交接物。
- 验收标准用登录成功率、账号回收完成率、映射准确率等可核对指标，交付前逐项核对检查清单，待验证项汇总成跟踪表附在方案末尾。
方案先写清哪几件事：核心结构与最小内容
一份可实施的账号集成方案，最小内容应覆盖七章：范围与目标、现状与身份源、认证与账号同步方式、字段映射、开通回收流程、异常与回退、验收与运维。每章都要回答“谁在什么条件下做什么、产出什么”，避免只写目标不写动作。下表给出骨架和每章的必答问题，可直接作为目录底稿。
| 章节 | 必答问题 | 输出物 | 责任人 |
|---|---|---|---|
| 范围与目标 | 接入哪些系统、覆盖哪些账号类型、本期不做什么 | 范围说明与边界清单 | 方案负责人 |
| 现状与身份源 | 身份数据从哪来、字段是否完整、目标系统现状如何 | 身份源与系统盘点表 | 身份源管理员、应用管理员 |
| 认证与同步方式 | 每个系统用哪种协议、依据是什么、哪些待验证 | 选型说明与待验证清单 | 集成负责人 |
| 字段映射 | 目标字段来自哪里、如何转换、为空怎么办 | 字段映射表 | 集成负责人、应用管理员 |
| 开通回收流程 | 谁触发、谁审批、谁执行、交接物是什么 | 流程说明与角色职责表 | 身份源管理员、应用管理员 |
| 异常与回退 | 出问题怎么发现、怎么止损、怎么恢复 | 异常处置与回退清单 | 运维负责人 |
| 验收与运维 | 用什么指标判定成功、上线后谁巡检 | 验收标准表与巡检计划 | 方案负责人、安全或审计角色 |
范围章节要明确写出本文覆盖身份认证与账号生命周期，访问授权策略、角色权限模型、知识文档的权限与共享另行成文。这样后续评审时，读者不会把授权设计混入账号集成方案，也便于把相邻文档作为引用对象。
第一步：盘点身份源、目标系统与账号现状
盘点的目的是让方案的范围和优先级有事实依据。输入是现有系统清单和账号管理记录，动作是逐系统访谈与核查，输出是一张可评审的盘点表。缺少这一步，后面的协议选择和字段映射容易建立在假设上。
身份源方面，逐一确认企业目录、HR系统、既有身份提供方各自能提供哪些字段，例如工号、登录名、部门、在职状态，以及数据更新频率和接口方式。目标系统方面，记录每个应用的当前账号创建方式（人工创建、脚本导入、已有联合登录）、是否支持标准协议、管理员是谁。账号现状方面，重点排查重复账号、离职未回收账号和共享账号：可按登录名与工号比对找重复，按在职名单与账号列表比对找遗留账号，共享账号则逐个确认使用人和必要性。
| 系统 | 账号来源 | 协议支持（已确认/待验证） | 账号现状问题 | 优先级 |
|---|---|---|---|---|
| 示例：HR系统 | 人事主数据 | 待验证 | 离职状态更新延迟 | 高（身份源） |
| 示例：协同办公应用 | 人工创建 | 待验证 | 存在重复账号 | 高 |
| 示例：内部业务系统 | 本地账号 | 待验证 | 共享账号若干 | 中 |
盘点结果直接决定方案边界：身份源字段完整、协议支持明确的系统排入第一期；依赖本地账号且短期无法改造的系统列为后续批次，并在方案中写明过渡期的账号管理方式。优先级建议按“账号数量、安全风险、改造难度”三项综合排序，排序理由写进方案，便于评审时解释取舍。
第二步：选定认证与账号同步方式并写明依据
方案中的方式选择要写成“某系统采用某方式，因为某依据，遗留某待验证项”，而不是笼统写“统一身份认证”。常见方式分两类：联合登录类包括SAML、OIDC，解决“用户如何证明身份”；账号同步与开通类包括LDAP或目录同步、SCIM等账号开通协议，解决“账号如何被创建、更新和停用”。两类方式可以组合使用，同一系统也可能既做联合登录又做账号开通。
选择依据主要有三条：目标系统实际支持的协议能力、账号生命周期管理需求（是否需要随入职离职自动开通回收）、实时性要求（离职后是否要求分钟级停用）。目标系统支持能力必须以对方管理员确认或文档为准，未确认的一律写成待验证项，并注明验证责任人和验证时间，不能按推断写成已支持。
方案中描述每种方式时，至少写清协议版本、端点地址、证书与密钥的生成方和保管方、交接方式与更换周期。证书和密钥的责任归属最容易在实施阶段扯皮，建议在方案里单独列一张交接表，写明由谁提供、由谁安装、到期前由谁提醒更换。
| 方式 | 适用系统 | 选择依据 | 待验证项 |
|---|---|---|---|
| SAML 联合登录 | 支持SAML的企业应用 | 无需改造应用账号体系，登录统一 | 协议版本、断言字段、证书更换流程 |
| OIDC 联合登录 | 支持OIDC的Web应用 | 适合现代Web应用，令牌可携带基础属性 | 回调地址、令牌有效期 |
| LDAP/目录同步 | 依赖目录服务的内部系统 | 复用既有目录，账号结构稳定 | 同步范围、过滤规则、冲突处理 |
| SCIM 账号开通 | 支持SCIM的应用 | 入职开通、离职停用可自动化 | 字段支持范围、停用行为 |
第三步：定义账号字段映射与唯一标识规则
字段映射解决“账号对不上、重复创建”的问题。方案中应给出一张映射表，逐字段写明目标字段、来源字段、转换规则、是否必填、为空时的处理。必填字段至少包括登录名、唯一标识、姓名、部门、状态；状态字段要能表达在职、停用等取值，并与回收流程对应。
| 目标字段 | 来源字段 | 转换规则 | 必填性 | 为空/异常处理 |
|---|---|---|---|---|
| 登录名 | HR系统工号或邮箱前缀 | 统一小写，去除特殊字符 | 必填 | 为空则挂起，由身份源管理员补录 |
| 唯一标识 | 工号 | 保持原值，不做转换 | 必填 | 冲突时以工号为准，人工核对 |
| 姓名 | HR系统姓名 | 直接映射 | 必填 | 为空时保留原值并告警 |
| 部门 | HR系统组织路径 | 按组织编码映射 | 必填 | 映射不到时归入待分配组 |
| 状态 | HR在职状态 | 在职→启用，离职→停用 | 必填 | 状态缺失按停用处理并通知 |
唯一标识的选取原则是稳定、不可复用、由权威系统产生，工号通常优于邮箱和姓名。方案要写明冲突处理规则：同一唯一标识对应多个账号时，保留主账号、停用其余账号并记录处理人；同一人出现多个唯一标识时，以HR主数据为准合并。映射表不是一次性文档，方案中要约定维护责任：目标系统字段变更、身份源结构调整时，由集成负责人更新映射表并通知应用管理员，变更记录附在方案附录中。
第四步：写清开通、变更与回收流程及角色分工
账号生命周期按入职开通、转岗变更、离职回收三类流程编写，每类流程写清触发条件、动作、状态和交接物。流程描述建议采用“触发—审批—执行—确认”四段式，每段标注责任角色，读者可以直接据此配置工单或排班。
- 入职开通：触发条件为HR入职记录生效；身份源管理员确认字段完整，应用管理员按映射表开通，交接物为开通结果记录。
- 转岗变更：触发条件为部门或岗位变更；由身份源管理员发起变更，应用管理员调整账号权限归属，交接物为变更前后对照记录。
- 离职回收：触发条件为离职状态生效；应用管理员在约定时效内停用账号，安全或审计角色抽查确认，交接物为回收确认记录。
角色分工建议在方案中单列一张职责表：身份源管理员负责主数据准确与及时推送，应用管理员负责目标系统账号的开通、变更与停用，安全或审计角色负责抽查回收结果和异常升级。回收时效要写成明确要求，例如离职生效后若干工作小时内完成停用，并写明超期未回收时的升级路径和处理人。申请、审批、开通结果、回收确认这些交接物需要留存可查，实际执行中常用工作项和审批流承载，例如在ONES中把开通与回收登记为工作项、走审批并保留状态记录，便于按人和时间追溯；具体工具按组织现有工具链确定。
第五步：异常处理、回退与验收怎么写
异常章节按“现象—发现方式—处置动作—责任人”逐条编写，覆盖认证失败、字段缺失、重复账号、同步中断、批量误操作五类常见场景。回退方案要提前写清可执行路径：保留本地账号登录作为联合登录故障时的临时入口、暂停同步避免错误数据扩散、恢复步骤与验证方法。回退不是失败预案的摆设，方案中要写明谁有权触发回退、触发后多久内完成恢复。
| 异常场景 | 发现方式 | 处置动作 | 责任人 |
|---|---|---|---|
| 认证失败 | 登录失败告警、用户报障 | 核查证书与端点，必要时启用本地登录 | 运维负责人 |
| 字段缺失 | 同步日志校验 | 挂起该条记录，通知身份源补录 | 身份源管理员 |
| 重复账号 | 定期比对报告 | 保留主账号，停用其余并记录 | 应用管理员 |
| 同步中断 | 任务监控告警 | 暂停同步，排查后从断点恢复 | 集成负责人 |
| 批量误操作 | 操作审计记录 | 按备份或操作日志回滚，评估影响范围 | 运维负责人、安全或审计角色 |
验收标准要可核对，建议至少包含：联合登录成功率、账号回收完成率、字段映射准确率、异常工单平均处理时长。每项指标写明统计口径、目标值和取证方式，例如回收完成率按“离职名单中已停用账号数÷离职名单总数”统计，证据为回收确认记录。上线后的运维责任与巡检周期也要写进方案：谁每周核对同步日志、谁每月抽查回收结果、巡检发现问题的升级路径。
示例：一份可直接套用的方案目录与填写片段
以下目录示例适用于中型企业首期接入若干核心系统的场景，可按实际系统数量增减章节。
- 范围与目标：本期接入系统清单、账号类型、边界说明
- 现状与身份源：身份源清单、目标系统盘点表、账号现状问题
- 认证与同步方式：逐系统选型说明、证书与密钥交接表、待验证清单
- 字段映射：映射表、唯一标识规则、冲突处理、维护责任
- 开通回收流程：三类流程说明、角色职责表、回收时效
- 异常与回退：异常处置清单、回退路径、触发权限
- 验收与运维：验收指标表、取证方式、巡检计划
- 附录：变更记录、待验证项跟踪表
字段映射章节的填写片段可写成：“目标系统A的登录名取自HR系统工号，统一转小写；唯一标识使用工号，冲突时保留主账号并停用其余账号，处理人记录在附录变更记录中。”流程章节的填写片段可写成：“离职状态生效后，应用管理员在4个工作小时内停用账号，安全或审计角色每周抽查10%的回收记录，超期未回收的升级至集成负责人。”这些片段体现了输入、动作、输出和责任人四要素，替换系统名称和时效即可迁移使用。示例中的时效和比例需按组织实际要求调整，协议支持情况以盘点结果为准。
完成检查：方案交付前的核对项
方案定稿前逐项核对下表，全部通过再提交评审。检查中发现的问题直接回写到对应章节，不留在评审会上口头补充。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 范围与系统清单 | 接入系统、账号类型、边界齐全，未确认能力均标注待验证项及验证人 | 方案负责人 |
| 认证与同步方式 | 每个系统有选型依据，协议版本、端点、证书责任到人 | 集成负责人 |
| 字段映射与唯一标识 | 必填字段齐全，冲突、为空、变更维护均有规则 | 集成负责人、应用管理员 |
| 开通回收流程 | 三类流程有触发条件、状态和交接物，回收时效与超期处理明确 | 身份源管理员、应用管理员 |
| 异常与回退 | 常见异常有处置动作和责任人，回退路径可执行 | 运维负责人 |
| 验收与运维 | 指标有口径、目标值和取证方式，巡检周期与责任人明确 | 方案负责人、安全或审计角色 |
核对完成后，把待验证项汇总成跟踪表附在方案末尾，注明验证责任人和截止时间。方案评审通过即进入实施，后续系统变更时同步更新映射表和盘点表，保持文档与实际情况一致。
常见问题
身份源字段不完整、部分系统短期无法改造时，方案怎么写才不影响实施？
把这类系统列入后续批次，并在方案中写明过渡期的账号管理方式，例如继续人工创建但纳入定期比对。身份源字段缺失的，在映射表中标注为空时的处理动作（挂起、补录、告警），并指定补录责任人。第一期只纳入字段完整、协议支持明确的系统，方案评审时用盘点表说明取舍理由，后续批次单列改造计划。
目标系统管理员说不清支持哪种协议，方案里应该怎么处理？
写成待验证项，不按推断填写。每条待验证项注明需要确认的内容（协议版本、断言字段、停用行为等）、验证责任人和截止时间，汇总成跟踪表附在方案末尾。验证完成后再回填选型说明，方案评审时把待验证项数量作为风险提示，避免实施阶段才发现协议不匹配。
离职回收的时效要求怎么定，超期了怎么处理？
时效按账号风险和系统敏感程度分档，例如核心业务系统要求离职生效后数小时内停用，一般系统可放宽到工作日级别，具体数值按组织实际要求确定。方案中同时写明超期未回收的升级路径：由安全或审计角色发现后通知应用管理员限期处理，仍超期的升级至集成负责人，处理记录留存备查。
方案上线后系统或组织架构发生变更，文档怎么保持可用？
在方案中约定维护责任：目标系统字段变更、身份源结构调整时，由集成负责人更新映射表和盘点表，变更记录写入附录。巡检环节同步核对文档与实际配置是否一致，发现偏差回写方案。把文档维护写进角色职责表，比事后补文档更可靠。
账号开通与回收的申请、审批记录用什么承载？
按组织现有工具链确定。常见做法是把开通、变更、回收登记为工作项并走审批流，保留状态和操作记录，便于按人、按时间追溯。例如在ONES中可用工作项与审批承载这类流转，具体配置以组织实际工具为准。方案中写明交接物名称和留存位置即可，不必绑定某一款工具。
