研发平台统一身份认证的规划，核心顺序是先把身份源和账号唯一标识定下来，再设计“人员—账号—角色—资源范围”的映射结构，随后按组织、项目、环境三层划清授权边界，最后用试点账号验证登录、映射和越权拦截。本文按这一顺序给出可填写的映射表结构、边界分层清单和上线检查项，适合负责研发平台身份集成的管理员或架构师参照执行。
要点总览（TL;DR）
- 账号映射从身份源和唯一标识入手：先确定主身份源，再以工号为主键、域账号为登录名，并写明外部协作者、服务账号和离职复用账号的处理规则。
- 映射表按“人员—账号—角色—资源范围”四层拆分，一条记录对应一个角色与一个资源范围，一人多项目用多行表达，便于按人员聚合和按资源反查。
- 授权边界按组织、项目、环境三层划分，冲突时范围更小的授权优先、安全级别更严的限制优先，无法判断时由安全负责人裁定并留痕。
- 上线前用覆盖各类角色的试点账号验证登录与映射一致性，做越权拦截测试，模拟离职与转岗回收，并保存配置快照以便回退。
先定身份源与账号唯一标识
账号映射反复返工，多数源于起步阶段身份源和唯一标识没有定死。规划的第一步是确认研发平台从哪一类身份源取数，并选定一个在人员全生命周期内保持稳定的标识字段。
身份源类型与适用条件
常见身份源有三类，选择时看企业现有基础设施和研发平台的接入条件：
| 身份源类型 | 适用条件 | 规划要点 |
|---|---|---|
| 企业目录（如LDAP、AD） | 企业已有统一目录，人员入离职在目录中维护 | 确认目录属性中可用于映射的字段，明确同步频率与失败处理 |
| 单点登录（SSO） | 已有统一认证门户，希望研发平台复用登录态 | 确认协议类型、属性传递内容，以及登出后的会话处理 |
| 本地账号 | 外部协作者、临时人员，或尚未接入统一认证的系统 | 限定使用范围，单独规定创建、审批与回收流程 |
三类身份源可以并存，但需要明确主身份源。主身份源承载正式员工账号，本地账号作为补充，避免同一人员存在两套可登录凭证。
唯一标识的取舍
唯一标识决定映射表能否长期稳定。工号、邮箱、域账号各有适用条件：
- 工号：稳定性最好，不随姓名、部门变化，适合作为主键；前提是工号在目录中完整且唯一。
- 邮箱：便于识别和沟通，但存在别名、更换域名的情况，适合作为辅助字段。
- 域账号：与登录体系直接对应，适合作为登录名；需要确认离职后是否会被回收复用。
建议以工号作为人员主键，域账号作为登录名，邮箱作为联系字段，三者同时记录在映射表中。这样即使登录名调整，人员与账号的对应关系仍可追溯。
特殊账号的处理规则
外部协作者、服务账号和离职复用账号是最容易出问题的三类对象，需要在规划阶段写明规则：
- 外部协作者：使用本地账号或独立身份源，设置明确的有效期，到期自动停用，并指定内部对接人作为责任人。
- 服务账号：与自然人账号分开管理，登记用途、所属系统和责任人，禁止用于人工登录，权限按最小范围授予。
- 离职复用账号：规定离职后账号立即停用、标识不可复用；如工号被重新启用，必须新建账号记录，不复用历史授权。
完成以上三项决策后，形成一张身份源与唯一标识决策表，记录身份源类型、主键字段、登录名字段、特殊账号规则和责任人，作为后续映射设计的输入。
账号映射表怎么设计：四层字段与对应关系
映射表的作用是把“谁、用哪个账号、以什么角色、访问哪些资源”这四件事固定成一条可查询的记录。建议采用“人员—账号—角色—资源范围”四层结构，每层保留独立字段，避免把角色和资源混写在一个字段里。
字段清单与必填项
| 层级 | 字段 | 是否必填 | 说明 |
|---|---|---|---|
| 人员 | 人员标识（工号） | 必填 | 映射主键，全表唯一 |
| 人员 | 姓名、所属部门 | 必填 | 用于核对与展示 |
| 人员 | 人员类型 | 必填 | 正式员工、外部协作者、服务账号 |
| 账号 | 登录名（域账号） | 必填 | 与身份源一致 |
| 账号 | 身份源 | 必填 | 目录、SSO或本地 |
| 账号 | 账号状态 | 必填 | 启用、停用、待回收 |
| 角色 | 角色名称 | 必填 | 如项目管理员、开发成员、只读成员 |
| 资源范围 | 资源类型与范围 | 必填 | 组织、项目或环境，写明具体对象 |
| 公共 | 生效时间、失效时间 | 必填 | 临时授权必须有失效时间 |
| 公共 | 维护责任人 | 必填 | 对该条记录负责的人 |
一对多与多对一的表达
实际组织中，一人参与多个项目、一个岗位由多人承担都很常见。映射表按“一条记录对应一个角色与一个资源范围”的方式拆分，用多行表达一对多：同一人员标识出现多行，每行对应不同项目或不同角色。多对一则表现为同一角色、同一资源范围下有多条人员记录。这样拆分后，权限核对时可以按人员聚合查看，也可以按资源反查成员，不需要在单元格里堆叠多个值。
维护责任人与更新时点
映射数据必须有明确的维护人。人员与账号字段由身份管理员维护，角色与资源范围字段由项目管理员维护，安全负责人负责抽查。更新时点至少覆盖四类事件：人员入职、转岗、离职，以及项目成员调整。每次变更保留变更前后记录和操作人，便于后续复核。
在映射维护环节，ONES 的成员管理与项目角色设置可以作为承载方式：人员与账号信息在成员层面维护，角色与项目范围在项目成员配置中体现，变更记录随工作项和操作日志留存，便于身份管理员与项目管理员按同一份数据核对。
授权边界怎么划：组织、项目与环境三层范围
授权边界回答的是“这个账号最多能看到和操作到哪里”。建议按组织、项目、环境三层划分，每层管一类范围，层与层之间用优先级规则处理冲突。
组织边界
组织边界管部门、团队与跨团队可见性。规划时明确：本部门成员默认可见的范围，跨团队协作时通过什么方式开放（如加入对方项目、申请临时可见），以及哪些信息默认不跨团队展示。组织边界的审批人通常是部门负责人或团队负责人。
项目边界
项目边界区分项目成员、只读成员与写入成员。成员可提交和修改工作项，只读成员可查看进度与文档但不能改动，写入范围较大的角色需要项目管理员审批。跨项目访问按项目逐个授权，不设“全公司项目默认可读”。
环境边界
环境边界区分生产、预发、测试环境的访问差异。测试环境可对项目成员开放，预发环境限定到发布相关角色，生产环境只授予运维和值班角色，并保留操作记录。环境边界的审批人应为安全负责人或运维负责人。
边界冲突的优先级
当多层授权同时命中一个账号时，按两条规则处理：范围更小的授权优先于范围更大的授权；安全级别更严的限制优先于更宽松的授权。例如组织层允许访问某项目，但环境层限制生产环境，则以环境层限制为准。冲突无法按规则判断时，提交安全负责人裁定并记录结论。
| 边界层级 | 管辖内容 | 典型审批人 |
|---|---|---|
| 组织 | 部门、团队、跨团队可见性 | 部门或团队负责人 |
| 项目 | 项目成员、只读与写入区分 | 项目管理员 |
| 环境 | 生产、预发、测试访问差异 | 安全或运维负责人 |
角色与交付物分工
规划能否落地，取决于每个环节是否有人负责、有产物可查。以下四类角色覆盖映射建立、变更和回收的全过程。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 身份管理员 | 确认身份源，维护人员与账号字段，执行入职开通与离职回收 | 身份源决策表、账号清单、回收记录 |
| 项目管理员 | 维护项目成员与角色，提交资源范围变更 | 项目成员清单、角色变更申请 |
| 安全负责人 | 审定边界规则，审批高权限与环境访问，组织越权测试 | 边界分层清单、审批记录、测试结论 |
| 普通成员 | 按需提交权限申请，配合验证登录与访问结果 | 权限申请单、验证反馈 |
映射建立阶段，身份管理员提供人员与账号数据，项目管理员补充角色与资源范围，安全负责人确认边界规则后发布基线版本。变更阶段，任何角色调整都走申请与审批，审批记录与映射记录关联保存。回收阶段，身份管理员在收到离职或转岗通知后执行停用，项目管理员确认项目内授权已清除，安全负责人抽查回收结果。交接时以映射表当前版本和变更记录作为交接依据，避免口头传递。
示例：一个研发团队的映射与边界配置
以下为演示情景，用于说明配置过程，不代表真实企业案例。某研发团队共12人，包含1名团队负责人、2名项目管理员、8名开发成员和1名测试成员，另有2名外部协作者参与联调。身份源为企业目录，正式员工以工号为主键、域账号为登录名；外部协作者使用本地账号，有效期三个月。
映射表填写示例
| 人员标识 | 登录名 | 人员类型 | 角色 | 资源范围 | 失效时间 | 维护责任人 |
|---|---|---|---|---|---|---|
| E1021 | zhang.san | 正式员工 | 项目管理员 | 项目A | 长期 | 项目管理员甲 |
| E1021 | zhang.san | 正式员工 | 只读成员 | 项目B | 长期 | 项目管理员乙 |
| E1045 | li.si | 正式员工 | 开发成员 | 项目A、测试环境 | 长期 | 项目管理员甲 |
| X2003 | ext.wang | 外部协作者 | 只读成员 | 项目A | 三个月后 | 对接人张三 |
授权边界配置与预期结果
组织层：团队内成员默认可查看团队公开信息，跨团队访问需加入对方项目。项目层：项目A的开发成员可提交和修改工作项，外部协作者仅可查看。环境层：测试环境对项目A成员开放，预发环境仅项目管理员可访问，生产环境不对该团队开放。
按此配置，张三是项目A管理员、项目B只读成员，登录后可管理项目A的工作项，在项目B只能查看；李四可访问项目A和测试环境，尝试进入预发环境应被拒绝；外部协作者王五只能查看项目A内容，且三个月后账号自动失效。
上线前完成检查与验证
配置完成后，用试点账号逐项验证，确认登录、映射、越权拦截和账号回收都符合预期，再扩大到全量人员。
试点账号验证
选取覆盖各类角色的试点账号，包括项目管理员、普通成员、只读成员和外部协作者，逐一登录，核对登录后可见的项目、角色和资源范围与映射表记录一致。记录每个账号的实际结果，与预期结果逐条比对。
越权访问拦截测试
用低权限账号尝试访问未授权项目、预发或生产环境，确认系统拒绝并给出明确提示。测试项至少包括：只读成员尝试修改工作项、普通成员尝试进入预发环境、外部协作者尝试查看未授权项目。
离职与转岗账号回收验证
模拟一名成员离职，确认账号在约定时限内停用，项目内授权同步清除，历史操作记录仍可追溯。模拟一次转岗，确认原项目权限按规则收回，新项目权限按申请开通。
配置变更复核与回退准备
上线前保存当前配置基线，记录变更内容、操作人和时间。每次批量调整前先导出配置快照，出现异常时可按快照回退。复核由安全负责人执行，确认检查项全部通过并签字后，再开放全量登录。
| 检查项 | 验证方法 | 通过标准 |
|---|---|---|
| 登录与映射一致 | 试点账号逐一登录比对 | 可见范围与映射表记录一致 |
| 越权拦截 | 低权限账号访问未授权资源 | 访问被拒绝并有提示 |
| 离职回收 | 模拟离职流程 | 账号停用、授权清除、记录留存 |
| 转岗调整 | 模拟转岗流程 | 原权限收回、新权限按审批开通 |
| 变更可回退 | 核对配置快照与回退步骤 | 快照完整、回退步骤可执行 |
检查完成后，将验证记录与映射表、边界清单一并归档，作为后续审计和交接的依据。
常见问题
企业同时存在企业目录、单点登录和本地账号，映射表应该以哪个为准？
可以并存，但需要指定一个主身份源。主身份源承载正式员工账号，本地账号只用于外部协作者、临时人员或尚未接入统一认证的系统。映射表中每条账号记录都要标注身份源字段，核对时以主身份源的人员数据为准，本地账号单独规定创建、审批与回收流程，避免同一人员出现两套可登录凭证。
员工转岗后，原项目权限应该立即收回还是保留一段时间？
按映射表的规则处理：转岗属于必须触发更新的四类事件之一，原项目授权按规则收回，新项目权限按申请开通，两者分开走流程。如果业务上确需保留一段时间的只读访问，应在映射表中单独记录临时授权，写明失效时间和审批人，到期自动失效，不把临时保留写成默认做法。
组织层允许访问、环境层限制访问时，实际以哪条为准？
以环境层的限制为准。冲突处理遵循两条规则：范围更小的授权优先于范围更大的授权，安全级别更严的限制优先于更宽松的授权。组织层开放的是可见范围，环境层管的是具体环境的操作准入，生产、预发这类高敏感环境应单独收紧。规则无法判断的冲突，提交安全负责人裁定并记录结论，后续同类情形按已有结论执行。
外部协作者的账号到期后，项目里的历史记录会一起消失吗？
账号停用与历史记录留存是两件事。外部协作者账号到期后应停用登录并清除其授权，但其在项目内提交的工作项、评论等操作记录仍应保留，用于追溯。规划时在映射表中为外部协作者写明有效期和内部对接人，回收时由对接人确认授权已清除、记录仍可查。
试点验证通过后，全量开放前还需要做哪些准备？
试点验证覆盖登录、映射一致性、越权拦截和账号回收后，全量开放前还需完成三件事：保存当前配置基线并导出快照，确认回退步骤可执行；由安全负责人复核检查记录并签字；明确上线后映射数据的日常维护人和变更审批路径。批量导入或批量调整前再次导出快照，出现异常时按快照回退。
