研发平台最小权限设置的核心，是把“人该做什么”转化为“角色能在哪些资源上执行哪些操作”，再通过申请、审批、复核和回收让授权持续收敛。落地时以角色清单、权限矩阵、授权流程和复核记录四类产物为主线，先收紧生产环境、密钥、权限变更等高风险资源，再逐步覆盖全平台。本文按资源与角色划分、权限矩阵设计、授权回收流程、职责分工、项目示例和落地检查依次展开。
要点总览（TL;DR）
- 最小权限设置从两张清单起步：资源清单标注负责人与敏感级别，角色清单按岗位和协作场景划分，并区分平台级与项目级角色。
- 权限矩阵以“角色×资源×操作”逐格取值，默认无权限；生产发布、密钥读取、权限变更三类高风险操作单独管控。
- 授权闭环由申请、审批、临时权限到期回收、定期复核、转岗离职与项目结束清理组成，每个环节都要有责任人和记录。
- 落地检查重点看矩阵覆盖度、高权限账号存量、临时权限存量、复核与回收记录完整性、变更可追溯性，按风险排序整改。
最小权限从哪里起步：先划清资源与角色
最小权限的起点是两张清单：一张列出需要管控的资源，一张列出使用这些资源的岗位角色。缺少资源清单，权限矩阵会失去边界；缺少角色清单，授权容易退化为按人名逐个配置，难以复核和交接。
纳入管控的资源类型
研发平台的资源可以按“代码与交付物—运行环境—平台配置”三层梳理。每类资源都要标注负责人、敏感级别和当前授权方式，作为后续权限矩阵的行来源。
| 资源类型 | 典型对象 | 敏感程度判断依据 |
|---|---|---|
| 项目与需求 | 项目空间、需求、迭代、缺陷 | 是否包含客户信息、商业计划 |
| 代码库 | 仓库、分支、合并请求 | 是否为核心系统、是否含密钥配置 |
| 流水线 | 构建任务、发布流水线、执行凭证 | 能否直接触达生产环境 |
| 制品库 | 镜像、依赖包、版本制品 | 是否被生产环境直接引用 |
| 测试与生产环境 | 测试集群、生产集群、数据库 | 影响范围与数据敏感度 |
| 配置与密钥 | 环境变量、访问密钥、证书 | 泄露后的直接损失 |
按岗位和场景划分角色
角色应来自稳定的工作职责，而非具体人员。常用做法是先列岗位，再补充跨岗位的协作场景，最后合并职责相近的角色，控制角色总数。一个可操作的划分示例如下：
- 项目负责人：管理项目成员、审批本项目内的权限申请、决定发布窗口。
- 开发人员：读写本项目代码库、触发测试环境流水线、查看构建日志。
- 测试人员：读取代码库、管理测试用例、在测试环境执行部署。
- 运维/发布人员：执行生产发布、读取部署所需密钥、管理环境配置。
- 平台管理员：维护平台级配置、账号与角色定义，不默认拥有业务数据访问权。
- 安全与审计人员：只读访问权限配置与操作记录，用于复核。
角色划分完成后，应检查是否存在“一人多角色靠叠加授权”的情况。叠加本身可以接受，但每个角色都要能独立说明其存在理由，否则应合并或删除。
区分平台级角色与项目级角色
平台级角色决定“能否进入平台、能否管理平台配置”，项目级角色决定“在某个项目内能做什么”。两者混用会带来两个问题：平台管理员被默认赋予全部项目的数据访问权；项目成员被授予平台配置权限后，影响范围超出项目边界。建议平台级角色只保留平台管理、安全审计等少数几类，业务操作一律放在项目级角色中授予。
本节完成标志：形成资源清单（含负责人和敏感级别）与角色清单（含角色定义和适用场景）初稿，并明确哪些角色属于平台级、哪些属于项目级。
权限矩阵怎么设计：把角色映射到操作
权限矩阵把角色清单和资源清单交叉展开，逐格填写允许的操作。它的作用是让授权从“凭印象开通”变成“按格子核对”，并为后续复核提供判断依据。
行列设计与操作粒度
推荐以“角色×资源”为行、以操作类别为列，也可以按“角色×资源×操作”逐条列出，便于逐项评审。操作类别通常分为四组：
- 读：查看、下载、检索。读权限也可能造成泄露，对密钥、生产配置等资源要单独收紧。
- 写：创建、修改、删除。删除类操作建议与普通修改分开授予。
- 执行：触发流水线、部署、运行脚本。执行权限要区分测试环境与生产环境。
- 审批与管理：审批发布、审批权限申请、管理成员与角色、修改权限配置。
粒度不宜过细到每个按钮，也不宜粗到“项目管理员”一揽子全开。判断标准是：该操作能否独立造成业务影响，能则单独成列。
默认最小授予与临时提权
矩阵的默认值应为“无权限”，新成员加入项目时按角色授予基线权限，超出基线的操作通过申请获得。临时提权要带三个要素：明确的操作范围、到期时间、申请理由。到期后系统或管理员执行回收，回收动作记入复核记录。对于高频且低风险的操作，可以评估后并入角色基线，避免审批流被琐事淹没。
高风险操作的单独管控
以下三类操作建议在矩阵中单独标注，不随普通角色批量授予：
| 高风险操作 | 管控方式 | 附加要求 |
|---|---|---|
| 生产环境发布 | 独立角色或临时授权 | 发布窗口、双人确认 |
| 密钥与证书读取 | 按需申请，限时有效 | 记录读取人与用途 |
| 权限变更与角色定义 | 仅平台管理员与安全负责人 | 变更留痕、事后复核 |
本节完成标志：矩阵覆盖全部资源类型与角色，每个格子有明确取值（允许/禁止/需申请），高风险操作已单独标注并写明附加条件，矩阵经过项目负责人和安全负责人共同评审。
授权与回收流程：申请、审批、复核、离场
权限矩阵解决“授什么”，流程解决“谁来授、何时收”。最小权限能否持续，取决于四个环节是否都有明确的触发条件、责任人和记录。
申请与审批
申请由需要使用权限的研发人员发起，内容包含资源、操作、用途和期望时长。审批人按资源归属确定：项目内资源由项目负责人审批，平台级配置由平台管理员审批，高风险操作增加安全负责人会签。审批人判断的依据是权限矩阵中该角色是否已有对应权限，已有则不应重复申请，没有则确认用途合理后授予。
临时权限的时限与回收
临时权限在申请时即写入到期时间，到期自动失效或由管理员在约定时间内回收。对于无法自动失效的平台，应建立到期提醒，由申请人或管理员在到期日执行回收并记录。临时权限延期需重新申请，避免一次申请长期占用。
定期复核
复核周期可按资源敏感度区分：生产环境、密钥、平台管理类权限建议每季度复核一次，普通项目权限可每半年一次。复核人由资源负责人担任，判断依据包括：该成员是否仍在相关项目、当前角色是否仍需要该权限、是否存在长期未使用的授权。复核结果分为保留、降级、回收三类，逐条记录。
转岗、离职与项目结束
这三类事件是权限残留的主要来源。建议把权限回收挂到人事与项目流程上：转岗时由原项目负责人确认回收项目级权限，新岗位按新角色重新授予；离职时由平台管理员核对账号与全部授权；项目结束时由项目负责人发起项目内权限清理，保留必要的归档只读权限。每类事件都要有回收完成的时间和执行人记录。
在工具层面，ONES 提供项目成员与角色的管理方式，权限申请与复核记录可以依托平台内的工作项或文档承载，使授权动作与项目协作在同一处留痕。具体角色粒度与审批配置以实际部署版本为准。
角色分工与交付物：谁负责哪一步
最小权限涉及安全、平台、项目和研发四类角色，职责不清时最容易出现“都以为对方在复核”。下表给出职责边界与对应交付物。
| 角色 | 主要职责 | 负责的交付物 | 更新时机 |
|---|---|---|---|
| 安全负责人 | 制定最小权限原则、评审高风险授权、抽查复核记录 | 权限管理规范、高风险操作清单 | 规范变更时、季度评审时 |
| 平台管理员 | 维护平台级角色与账号、执行平台级授权与回收 | 平台角色清单、账号与授权台账 | 人员入离场时、权限变更时 |
| 项目负责人 | 审批项目内申请、组织项目权限复核、项目结束时清理 | 项目权限矩阵、复核记录 | 成员变动时、复核周期到期时 |
| 研发人员 | 按需申请、说明用途、到期配合回收 | 权限申请单 | 每次申请时 |
协作接口有三处需要明确：项目负责人向平台管理员提交平台级授权需求；安全负责人对高风险授权拥有一票否决；复核发现异常时，由安全负责人发起整改，项目负责人执行。冲突处理原则可以简化为两条：安全要求与交付进度冲突时，先收紧权限再评估替代方案；审批人对申请有疑问时，默认不授予，待补充说明后再审。
本节完成标志：职责分工表经各方确认，每类交付物都有唯一责任人，交付物的更新时机写入流程说明。
示例：一个研发项目的权限设置过程
以下为演示情景，用于说明流程如何串起来，不代表任何真实项目。
项目范围与角色
某订单系统迭代项目，资源包括一个代码库、两条流水线（测试与生产）、一个制品库、测试与生产两套环境。参与角色为项目负责人1人、开发4人、测试2人、运维1人，平台管理员与安全负责人不直接参与项目日常操作。
权限矩阵取值
| 角色 | 代码库 | 测试流水线 | 生产流水线 | 生产环境配置 |
|---|---|---|---|---|
| 项目负责人 | 读写、合并 | 执行 | 审批 | 只读 |
| 开发 | 读写（本人分支） | 执行 | 无 | 无 |
| 测试 | 只读 | 执行 | 无 | 无 |
| 运维 | 只读 | 执行 | 执行 | 读写（需申请） |
一次临时提权记录
项目上线前，一名开发需要排查生产环境日志。申请内容为“生产环境日志只读权限，有效期3天，用途为定位线上异常”。项目负责人审批通过，安全负责人知会。第3天到期后权限自动失效，管理员在复核记录中登记回收时间与执行人。若排查未完成，需重新提交申请并说明进展。
项目结束后的清理
项目验收后，项目负责人发起权限清理：开发与测试的项目级权限全部回收，运维保留生产环境的日常运维角色，项目空间转为只读归档。平台管理员核对账号清单，确认无遗留的临时授权，清理结果记入项目结项记录。
完成检查：最小权限是否真正落地
检查的目的是发现“纸面矩阵”和“实际授权”之间的差距。建议每季度执行一次，逐项给出结论和整改责任人。
- 权限矩阵覆盖度：全部资源类型是否都有对应角色和操作取值；是否存在矩阵中未定义但实际已开通的权限。
- 角色冗余：是否存在职责重复的角色；是否存在仅有单人使用且长期无操作的角色，评估合并或删除。
- 高权限账号存量：平台管理员、生产发布、密钥读取类权限的持有人名单是否与岗位一致；数量是否随项目增加而失控。
- 临时权限存量：当前有效的临时授权是否都在有效期内；是否存在超期未回收的记录。
- 复核记录完整性：每个复核周期是否有记录；记录是否包含复核人、结论和处理动作。
- 回收记录：转岗、离职、项目结束三类事件的回收是否有时间和执行人；是否存在人员已离开但权限仍在的情况。
- 变更可追溯性：权限授予、变更、回收是否都能对应到申请单或审批记录；高风险操作的变更是否有额外确认。
检查中发现的问题按风险排序处理：生产环境与密钥类问题立即整改，普通项目权限问题纳入下一个复核周期。整改完成后更新权限矩阵和台账，使检查结果反过来修正矩阵取值，形成“设计—执行—核查—修正”的循环。
常见问题
研发平台最小权限设置应该先做资源清单还是角色清单？
两份清单可以并行起草，但建议先完成资源清单的初稿。资源清单确定了权限矩阵的边界，角色清单中的每个角色最终都要落到具体资源上才有意义。实际操作中，可以先按“代码与交付物—运行环境—平台配置”三层列出资源并标注负责人和敏感级别，再按岗位列出角色，最后把两者交叉检查：每个角色是否都有对应的资源范围，每类资源是否都有明确的负责角色。
临时权限到期后申请人仍在处理问题，应该延期还是重新申请？
建议重新申请，而不是直接延期。重新申请会强制申请人说明当前进展和仍需权限的理由，审批人据此判断是否可以缩小操作范围或缩短时长。如果确属同一任务延续，可以在申请中引用原申请单，减少重复填写。关键在于让每一次授权都有独立的到期时间和审批记录，避免一次申请长期占用高权限。
项目成员同时承担开发和运维职责时，角色怎么处理？
可以给同一人叠加多个角色，但每个角色要能独立说明存在理由，并且高风险操作仍按单独管控处理。例如该成员既有开发角色又有运维角色，生产发布权限不随运维角色自动获得，仍通过独立授权或临时提权取得。复核时要按角色分别检查：开发角色的权限是否仍与所在项目匹配，运维角色的生产权限是否仍在有效期内。
定期复核发现某成员长期未使用某项权限，应该直接回收吗？
先确认该权限是否属于其岗位的基线权限。属于基线的，可以保留但记录未使用情况，观察下一个周期；属于临时授权或超出基线的，建议回收，需要时再申请。对于生产环境和密钥类权限，即使属于基线，长期未使用也应评估是否仍需要，因为这类权限的持有面越窄，风险越可控。复核结论分为保留、降级、回收三类，逐条记录判断依据。
权限矩阵设计完成后，如何确认实际授权与矩阵一致？
需要把矩阵与实际授权台账做一次逐项比对，重点检查三类差异：矩阵中未定义但实际已开通的权限、矩阵允许但台账中缺失的授权、已回收但台账未更新的记录。比对可以由安全负责人抽查、项目负责人自查结合进行。发现差异后先判断是矩阵需要修正还是授权需要回收，再更新矩阵和台账，使两者保持一致。
