研发平台权限治理要解决的问题，是把”谁能对什么对象做什么动作”写成可执行的角色与策略，再落到账号、项目、代码库、流水线、环境等对象上，并配套申请、审批、复核和回收机制。本文按”先建模、再落地、明分工、看示例、做检查”的顺序，给出一套可以直接照着推进的设计方法与实施清单。
要点总览（TL;DR）
- 研发平台权限治理的核心是把“谁能对什么对象做什么动作”写成角色与策略，覆盖组织、项目、代码库、流水线、环境、密钥等对象。
- 落地按五步推进：盘点账号与敏感对象、定义角色与权限矩阵、配置分级授权、设置申请审批流程、灰度上线并回收旧权限。
- 职责要固定到人：平台管理员管配置与账号，安全/合规负责人定标准并组织复核，项目负责人管项目内授权，IT/运维管环境与密钥。
- 用检查清单验收：账号与人员一致、高权限账号有任命记录、审批记录完整、离职回收及时、敏感环境与密钥访问可追溯。
- 复核频率与敏感等级挂钩，密钥和生产环境按季度或更短周期复核，普通项目权限按半年复核，问题进入整改闭环。
先定权限模型：对象、角色与动作怎么拆
权限设计的第一步是把结构搭对。研发平台的权限可以拆成三层：对象是”被管的东西”，角色是”人的集合”，动作是”允许做的事”。三层交叉形成权限矩阵，后续所有配置、审批、复核都围绕这张矩阵展开。先有矩阵再上系统，能避免权限在配置过程中越加越乱。
需要管控的对象类型
研发平台中常见的受控对象可以按层级归类，不同层级的敏感程度和管理方式差异明显：
| 对象层级 | 典型对象 | 敏感程度 | 管控要点 |
|---|---|---|---|
| 组织层 | 组织、成员账号、团队 | 高 | 账号生命周期、组织级管理员任命 |
| 项目层 | 项目、项目成员、项目设置 | 中高 | 项目负责人授权、成员进出 |
| 代码层 | 代码库、分支、合并请求 | 高 | 读写权限、分支保护、合并审批 |
| 交付层 | 流水线、构建任务、制品库 | 高 | 执行权限、制品发布与下载 |
| 运行层 | 测试环境、预发与生产环境 | 极高 | 访问审批、操作留痕 |
| 凭证层 | 密钥、令牌、证书 | 极高 | 最小可见、定期轮换、访问审计 |
盘点对象时，建议同时标注敏感等级。敏感等级决定后续审批层级和复核频率，是权限矩阵之外的第二条管理线索。
角色分层
角色按职责范围分层，避免把平台级权力下放到项目级，也避免项目成员被授予跨项目权限：
- 平台管理员：管理组织、账号、全局策略和集成配置，人数应严格控制。
- 组织/项目管理员：在授权范围内管理成员、项目和项目级设置，不触碰平台级配置。
- 开发者：在所属项目中读写代码、执行流水线、提交变更，权限边界止于项目。
- 只读角色：用于查看代码、流水线状态和报表，适合跨团队协作、评审和管理层查看。
- 外部协作角色：面向供应商、外包或合作方，权限范围窄、有效期短，默认不带审批和授权能力。
角色数量不宜过多。每增加一个角色，就多一组需要维护和复核的授权关系。常见做法是先按上述五类建立基础角色，确有特殊岗位时再派生细分角色。
动作粒度
动作按风险从低到高排列：查看、编辑、执行、审批、授权、删除。设计时把握两条原则：
- 最小权限：默认只给完成当前工作所需的最低动作。例如只读角色不配编辑，开发者不配授权。
- 职责分离：提交变更的人与审批合并的人分开，申请授权的人与批准授权的人分开，执行生产环境操作的人与审批该操作的人分开。职责分离不要求每个团队都设专职审批岗，但至少在敏感对象上保留两人以上的制衡。
把对象、角色、动作三者填入下表，就得到权限矩阵的初稿框架：
| 对象 | 平台管理员 | 项目管理员 | 开发者 | 只读 | 外部协作 |
|---|---|---|---|---|---|
| 项目设置 | 授权 | 编辑 | 查看 | 查看 | 无 |
| 代码库 | 授权 | 编辑 | 编辑 | 查看 | 查看/按需编辑 |
| 流水线 | 授权 | 编辑 | 执行 | 查看 | 无 |
| 测试环境 | 授权 | 审批 | 执行 | 查看 | 按需申请 |
| 密钥 | 授权 | 无 | 无 | 无 | 无 |
矩阵中的每一格都要能回答”为什么给这个角色这个动作”。答不上来的格子，通常就是可以收回的权限。
权限落地的操作步骤：从盘点 to 上线
模型确定后，按五个步骤推进落地。每一步都明确输入、动作、输出和完成标志，便于排期和验收。
第一步：盘点现有账号、项目与敏感对象
输入：现有平台账号清单、项目清单、代码库与环境清单。动作：核对账号与在职人员是否一致，标记长期未登录账号、共享账号和权限明显过大的账号；给项目、代码库、环境标注敏感等级；记录当前各对象的授权情况。输出：账号与对象盘点表、异常账号清单。完成标志：每个账号都能对应到具体人员，每个敏感对象都有等级标注，异常项有明确处理人。
第二步：定义角色清单与权限矩阵
输入：第一步的盘点表、岗位职责说明。动作：按 S1 的分层确定角色清单，逐格填写权限矩阵，对每个高敏感动作标注是否需要审批。输出：权限矩阵初稿、角色说明文档。完成标志：矩阵覆盖全部受控对象，每个角色有明确的适用人群，高敏感动作全部标注审批要求。
第三步：配置分级授权
输入：权限矩阵、平台现有权限模型。动作：按组织、项目、代码库、流水线、环境逐级配置。组织层控制成员进出和全局策略；项目层控制成员角色；代码库配置读写与分支保护；流水线配置执行与触发权限；环境配置访问审批。配置时优先使用平台内置的角色模板，减少逐人授权。输出：配置完成记录、配置与矩阵的对照表。完成标志：抽查若干项目，实际权限与矩阵一致；不存在矩阵之外的个人直授权限。
第四步：设置申请与审批流程
输入：高敏感动作清单、审批人名单。动作：为临时权限、跨项目权限、生产环境访问、密钥访问设置申请入口，明确审批人、审批时限和权限有效期。审批通过后由系统自动授予并记录到期时间。输出：申请审批流程说明、审批记录模板。完成标志：所有高敏感动作都有可用的申请路径，审批记录可查询，临时权限带到期时间。
第五步：灰度上线与回收旧权限
输入：新权限矩阵、旧权限清单。动作：先选一到两个项目试点，观察一周内的权限申请量、审批耗时和阻塞问题，修正矩阵后全量推广；同步回收旧权限，对无法立即回收的权限登记例外并设定回收期限。输出：试点报告、旧权限回收清单、例外登记表。完成标志：试点项目无重大阻塞，旧权限回收完成率可统计，例外项均有责任人和期限。
在配置与复核环节，ONES 的项目成员管理与工作项权限设置可以承接上述分级授权思路：项目内按成员角色分配操作范围，权限变更随项目成员调整同步生效，便于把矩阵落到具体项目和成员上。具体能力以实际使用版本为准。
角色与交付物：谁负责哪一段
权限治理容易失败的地方，是设计做完却没人持续维护。把职责和交付物固定下来，机制才能运转。
| 角色 | 主要职责 | 在流程中的动作 | 关键交付物 |
|---|---|---|---|
| 平台管理员 | 平台级配置与账号管理 | 配置角色与策略、执行账号开通与回收、维护审批流 | 权限矩阵、配置记录、账号台账 |
| 安全/合规负责人 | 定义敏感等级与复核标准 | 审核矩阵、抽查高权限账号、组织定期复核 | 复核报告、例外审批意见 |
| 项目负责人 | 项目内权限的日常管理 | 审批项目内权限申请、确认成员角色、发起回收 | 项目成员清单、审批记录 |
| 研发成员 | 按需申请、合规使用 | 提交权限申请、到期前确认是否续期 | 申请单、使用记录 |
| IT/运维 | 环境与凭证的技术管控 | 配置环境访问策略、轮换密钥、执行离职账号回收 | 环境访问清单、密钥轮换记录、回收清单 |
四类交付物贯穿整个机制：权限矩阵是设计依据，审批记录是执行证据，复核报告是有效性证明，回收清单是闭环凭证。建议为每类交付物指定唯一保管人，避免多头维护导致版本不一致。
示例：一个项目组的权限配置过程
以下为演示情景，用于说明配置思路，不代表任何真实项目。
情景设定：某研发团队新立项一个业务系统，成员包括 1 名项目负责人、5 名开发、1 名测试，另有 2 名外部供应商参与前端开发，项目需要独立的代码库、一条持续集成流水线和一套测试环境。
配置过程：
- 平台管理员创建项目，将项目负责人设为项目管理员，授予项目设置编辑权。
- 5 名开发加入项目，授予代码库读写、流水线执行、测试环境访问权限；测试人员授予代码库只读、流水线执行、测试环境访问权限。
- 代码库主分支开启保护，合并需项目负责人审批，落实提交与审批分离。
- 流水线配置为开发可执行、项目负责人可编辑，生产发布流水线仅平台管理员可触发。
- 2 名外部供应商授予代码库指定目录的读写权限和测试环境访问权限，有效期设为项目周期，到期自动失效；不授予流水线编辑和项目设置权限。
验证动作：配置完成后，项目负责人用只读账号抽查代码库和流水线页面，确认看不到编辑入口；平台管理员导出项目成员权限清单，与矩阵逐项比对；检查外部人员权限的到期时间是否正确写入；模拟一次合并请求，确认审批环节生效。验证通过后，将该项目作为模板复制到后续同类项目。
完成检查：权限治理是否到位
上线前和定期复核时，按以下清单逐项核对。每项给出可观察的通过标准，避免停留在”已检查”的口头结论。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 账号与人员一致性 | 导出账号清单与人事名单比对 | 无无法对应人员的账号，共享账号已登记并说明用途 |
| 高权限账号数量 | 统计平台管理员与项目管理员人数 | 平台管理员人数在约定上限内，每个高权限账号有任命记录 |
| 审批记录完整性 | 抽查近三个月的高敏感权限授予 | 每次授予都能找到对应审批记录，审批人与申请人不同 |
| 离职与转岗回收时效 | 抽取离职、转岗人员，核对权限回收时间 | 回收在约定时限内完成，超时项有原因说明 |
| 敏感环境与密钥访问 | 导出环境访问名单与密钥使用记录 | 访问人均在授权名单内，密钥按周期轮换，无长期未使用的授权 |
| 权限变更留痕 | 查看权限变更日志 | 授予、变更、回收均有记录，可追溯到操作人和时间 |
| 定期复核机制 | 检查复核计划与最近一次复核报告 | 复核按周期执行，发现的问题有整改记录和关闭时间 |
建议把复核频率与对象敏感等级挂钩：密钥和生产环境按季度或更短周期复核，普通项目权限按半年复核。复核发现的问题进入整改清单，整改完成后由安全/合规负责人确认关闭，形成”设计—执行—复核—整改”的完整闭环。
常见问题
研发平台权限矩阵做完之后，怎么保证配置和矩阵一致？
矩阵是设计文档，配置是系统里的实际状态，两者容易在人员变动和临时授权中脱节。可行的做法是保留一条对照机制：每次配置完成后导出实际权限清单，与矩阵逐项比对；抽查时选只读账号登录，确认看不到编辑入口；把矩阵之外的个人直授权限列为异常项，要求补审批或收回。矩阵本身也要有版本和变更记录，调整角色或动作时同步更新，避免用旧矩阵核对新配置。
小团队也需要平台管理员、安全负责人、项目负责人这样分开吗？
角色分层的目的是让高敏感动作有人复核，人数少时可以合并岗位，但不宜合并到同一个人身上。例如平台管理员与安全/合规负责人由同一人兼任时，高权限账号的任命和复核就缺少制衡，可以改为由技术负责人或上级管理者承担复核。项目负责人审批项目内权限、研发成员提交申请这两类动作，即使团队只有几个人也建议保留，因为它们是审批记录和回收清单的来源。岗位合并后要在职责表里写明兼任关系和替代复核人。
外部供应商或外包人员的权限怎么管才不失控？
外部协作权限的关键是范围窄、期限短、可追溯。授予时限定到具体代码库目录或具体环境，不授予流水线编辑、项目设置和授权类动作；有效期与合同或项目周期对齐，到期自动失效，需要延期时重新走申请。外部人员离场时，回收动作要和项目成员移除同步执行，并核对代码库、环境、制品库等处的残留授权。建议单独维护外部人员权限清单，复核频率高于内部成员。
灰度上线阶段旧权限回收遇到业务阻塞怎么办？
旧权限回收遇到阻塞时，不要直接放弃回收，而是转为登记例外：记录权限内容、持有人、阻塞原因、替代方案、责任人和回收期限，由安全/合规负责人确认。例外项要进入复核清单，到期前确认是否已具备回收条件。同时分析阻塞原因，如果是矩阵设计过紧，就调整矩阵并重新试点；如果是流程缺失，就补充申请路径。试点阶段收集的申请量、审批耗时和阻塞问题，正是修正矩阵的依据，建议在推广前完成一轮调整。
权限复核发现问题后，怎么确认整改真的完成了？
复核报告只说明发现了什么，整改闭环还需要关闭证据。建议为每个问题指定责任人和整改期限，整改完成后由安全/合规负责人核对实际权限状态，确认与矩阵一致后在整改清单中记录关闭时间和确认人。对于反复出现的问题，例如离职回收超时，要回到流程层面找原因，调整账号回收的触发点和时限，而不是每次复核都重复登记。复核报告与整改清单一起归档，作为下一轮复核的输入。
