权限矩阵用一张二维表回答“谁对什么能做什么”：角色承载权限，资源是被访问对象，操作是可执行动作，三者组合成一条可判定的授权规则。本文说明三要素的含义、矩阵的行列排布与单元格取值，并厘清它与角色权限模型、访问控制列表和属性策略的关系，最后用研发平台场景示范填写与常见误区。
要点总览（TL;DR）
- 权限矩阵的一条授权规则由角色、资源、操作三者组合而成：角色代表职责，资源是被访问对象，操作是可执行动作。
- 矩阵通常以角色为行、以“资源＋操作”为列，单元格统一取值为允许、拒绝或条件允许，空白含义需在表头约定。
- 权限矩阵与角色权限模型（RBAC）是同一套授权逻辑的两个层面：RBAC 负责分配，矩阵负责表达与评审，不替代运行时授权引擎。
- 与 ACL 相比，矩阵便于批量核对角色间的重叠与缺失；与 ABAC 相比，矩阵更适合表达静态规则，动态条件判断仍交给策略引擎。
- 常见误区包括角色写成人名、操作用“管理”等模糊词、资源粒度过粗、条件权限未标注，以及矩阵与系统配置长期不一致。
权限矩阵由哪三个要素构成
权限矩阵的基本单位是一条授权规则，而一条完整的授权规则必须同时说清三件事：谁、对什么、做什么。这三件事分别对应角色、资源和操作。缺少任何一项，规则都无法判定，评审时也无从核对。
角色：权限的承载主体
角色代表一类职责，而不是某个具体的人。例如“后端开发工程师”“测试负责人”“项目管理员”，描述的是岗位承担的职责范围。把权限授予角色，再把人员关联到角色，人员变动时只需调整关联关系，权限规则本身保持稳定。角色写成具体人名，矩阵就会随人员流动频繁失效，也失去了批量核对的意义。
资源：被访问的对象
资源是权限作用的对象，需要按层级和粒度拆分。研发平台中常见的资源包括代码仓库、需求工作项、流水线、测试用例、发布单、环境配置等。同一类资源往往还有层级，例如代码仓库可以细分到仓库、分支、目录；工作项可以细分到项目、工作项类型、单个条目。资源粒度决定矩阵的精细程度：粒度太粗，无法区分敏感与普通对象；粒度太细，列数膨胀，评审成本上升。
操作：对资源可执行的动作
操作用明确的动词表达，指向资源上的具体行为，例如查看、创建、编辑、删除、执行、审批、导出。操作应当可观察、可判定，“管理”这类笼统词无法说明到底允许了哪些动作，容易在评审时被误读为全部权限。必要时可以把一组高频操作打包成操作集，但打包后仍应能展开到具体动作。
三者组合成一条授权规则
把三者串起来，就得到一条可判定的规则，例如：“后端开发工程师”对“代码仓库的合并请求”可以“审批”。这条规则包含主体、对象、动作和结论，评审人可以逐项确认是否符合职责设计。矩阵中的每个单元格，本质上就是一条或一组这样的规则。
角色、资源、操作在矩阵里怎么排布
矩阵的排布方式决定了它是否易读、易核对。常见做法是把角色放在行，把资源与操作的组合放在列，单元格填写授权结论。这样一行读下来是一个角色的全部权限，一列读下来是一个资源操作被哪些角色持有，两个方向都便于发现异常。
行列结构与单元格取值
列标题通常写成“资源＋操作”的形式，例如“代码仓库·查看”“代码仓库·合并”“流水线·执行”。单元格取值建议统一为三类：允许、拒绝、条件允许。允许表示该角色可以直接执行；拒绝表示明确不授予，用于覆盖继承或默认开放的情况；条件允许表示在满足附加条件时才生效。空白单元格含义模糊，容易被理解为“未定义”或“默认允许”，应尽量避免，或在表头明确约定空白的含义。
资源粒度与操作粒度对列数的影响
列的数量由资源粒度和操作粒度共同决定。资源拆得越细、操作列得越多，矩阵越精确，但列数增长很快。实践中可以分层处理：先按资源大类建主矩阵，再对敏感资源单独建细粒度子矩阵。操作方面，把低频且风险相近的动作合并为操作集，把高风险动作单独成列，既控制列数，又保留关键判断点。
条件字段如何附加
条件允许需要在矩阵之外补充条件说明，常见条件包括数据范围（本人、本团队、全公司）、环境（开发、测试、生产）、数据级别（公开、内部、机密）、时间窗口等。条件字段可以放在单元格内以简短标注呈现，并在矩阵下方用统一的条件表解释每个标注的含义。条件与结论必须相邻呈现，避免读者只看到“允许”而忽略适用范围。
| 要素 | 在矩阵中的位置 | 表达要求 | 常见问题 |
|---|---|---|---|
| 角色 | 行 | 按职责命名，可继承 | 写成具体人名 |
| 资源 | 列（与操作组合） | 按层级和粒度拆分 | 粒度过粗，无法区分敏感对象 |
| 操作 | 列（与资源组合） | 用明确动词 | 用“管理”等模糊词 |
| 结论 | 单元格 | 允许／拒绝／条件允许 | 空白含义不明 |
权限矩阵与角色权限模型是什么关系
权限矩阵和角色权限模型（RBAC）描述的是同一套授权逻辑的两个层面，二者互补而非互斥。RBAC 是授权机制：先定义角色，给角色分配权限，再把用户关联到角色。权限矩阵是这套分配结果的可视化表达，把“角色—资源—操作”的对应关系摊开成表，供人阅读、评审和核对。
矩阵用于核对重叠与缺失
角色数量增多后，仅靠逐条查看权限配置很难发现两个角色是否授予了相同的高风险操作，也很难发现某个必要操作是否无人持有。矩阵按行按列对照，可以快速定位重叠授权和权限缺口。这类核对属于治理动作，产出的是评审结论和调整建议。
角色继承与矩阵展开
RBAC 中常有角色继承，例如“测试负责人”继承“测试工程师”的基础权限。矩阵表达继承关系时有两种方式：一种是把继承来的权限展开到子角色行中，读者看到的是最终有效权限；另一种是只列角色自身直接授予的权限，另用说明标注继承来源。前者便于判断实际效果，后者便于追溯授权来源，可以按评审目的选择，但同一张矩阵内应保持一致。
矩阵承担表达与评审，不替代授权引擎
矩阵是文档层面的表达工具，运行时的权限判定仍由系统的授权引擎完成。矩阵的价值在于让规则可读、可讨论、可留痕；它本身不执行拦截。因此矩阵需要与系统配置保持同步，否则评审结论会偏离实际行为。
在研发平台中，角色权限的评审往往涉及多个团队共同确认。ONES 提供成员与权限管理能力，支持按角色组织成员并配置相应权限；团队可以把矩阵作为评审底稿，在确认角色职责和资源范围后，再到系统中完成配置，并在人员或项目调整时对照矩阵复核。具体可配置的角色类型与资源层级以实际产品界面为准。
和访问控制列表、属性策略的区别
权限矩阵、访问控制列表（ACL）和基于属性的访问控制（ABAC）都在回答“谁能对什么做什么”，但组织方式和适用场景不同。理解差异有助于判断在什么环节用矩阵表达、在什么环节交给策略引擎判定。
ACL 以资源为主体逐条列权限
ACL 通常挂在资源上，逐条列出哪些主体对该资源拥有哪些权限。它贴近资源的实际存储位置，适合对象数量有限、授权关系简单的场景。矩阵以角色为行，把同类资源的授权集中呈现，更适合批量核对多个角色在多个资源上的权限分布。两者可以并存：ACL 是系统内的存储形式，矩阵是从中归纳出的评审视图。
ABAC 按属性动态判定
ABAC 依据主体属性、资源属性、环境属性等条件在运行时动态计算是否放行，例如“仅允许项目成员在工作时间访问生产环境配置”。它能表达细粒度和上下文相关的规则，但规则分散在策略中，不易一眼看全。矩阵更适合表达相对静态的角色授权，条件字段可以承载部分属性判断，复杂动态规则仍应交给策略引擎。
混合使用时的分工
实际系统常混合使用多种机制：静态的角色授权用矩阵表达和评审，动态的上下文判断由策略引擎执行，资源级的例外授权用 ACL 记录。矩阵在其中扮演评审底稿的角色，汇总各机制的授权意图，帮助确认整体是否符合最小权限原则。矩阵不承担运行时判定，策略变更后应及时回写矩阵，保持两者一致。
| 对比项 | 权限矩阵 | 访问控制列表（ACL） | 属性策略（ABAC） |
|---|---|---|---|
| 组织方式 | 角色为行，资源操作为列 | 以资源为主体逐条列权限 | 按属性条件编写策略 |
| 主要用途 | 表达与评审授权规则 | 记录资源上的具体授权 | 运行时动态判定 |
| 优势 | 批量核对重叠与缺失 | 贴近资源，直观具体 | 支持细粒度和上下文条件 |
| 局限 | 不执行运行时拦截 | 角色多时难以整体审阅 | 规则分散，不易一眼看全 |
一个具体例子与常见表达误区
下面以研发平台的三类典型资源为例，示范矩阵如何填写。示例为演示情景，角色和操作按常见职责设计，实际使用时需结合团队分工调整。
填写示例
| 角色 | 代码仓库·查看 | 代码仓库·合并 | 需求工作项·编辑 | 需求工作项·关闭 | 流水线·执行 | 流水线·编辑配置 |
|---|---|---|---|---|---|---|
| 后端开发工程师 | 允许 | 条件允许（需代码评审通过） | 允许 | 拒绝 | 允许 | 拒绝 |
| 测试工程师 | 允许 | 拒绝 | 允许 | 拒绝 | 允许 | 拒绝 |
| 项目管理员 | 允许 | 允许 | 允许 | 允许 | 允许 | 条件允许（限本项目流水线） |
这张表读起来很直接：后端开发工程师可以查看代码仓库、在评审通过后合并代码、编辑需求工作项、执行流水线，但不能关闭需求或修改流水线配置；项目管理员在本项目范围内拥有较完整的权限。条件允许的单元格都附带了范围说明，评审时可以逐格确认。
常见表达误区
- 角色写成具体人名。人名会随组织调整失效，也无法体现职责设计，应改为岗位或职责名称。
- 操作写成模糊的“管理”。这类词无法判定具体动作，评审时容易被理解为全部权限，应拆成查看、编辑、删除、审批等明确动词。
- 资源粒度过粗。只写“代码仓库”而不区分仓库、分支、合并请求，无法表达敏感操作的边界，应按实际访问对象拆分层级。
- 条件权限未标注。单元格只写“允许”而省略范围、环境或数据级别，评审人会按全量权限理解，导致误判。
- 矩阵与系统配置不一致。矩阵更新后未同步到系统，或系统调整后未回写矩阵，都会让评审结论失真。
矩阵与系统配置的核对方法
核对可以按固定节奏进行：先导出系统中各角色的实际权限，与矩阵逐格比对，标记差异项；再判断差异是配置遗漏还是矩阵过期，分别修正；最后记录本次核对的范围和结论，作为下一轮评审的基线。人员或项目结构发生较大调整时，应提前触发一次核对，避免权限随人员流动悄然扩散。
常见问题
角色继承关系在矩阵里应该展开还是只列直接权限？
两种做法各有用途，关键是同一张矩阵内保持一致。把继承来的权限展开到子角色行，读者看到的是最终有效权限，适合判断实际效果；只列角色自身直接授予的权限，另用说明标注继承来源，适合追溯授权来源。如果评审目标是确认“这个角色到底能做什么”，建议展开；如果目标是排查“某条权限是谁授予的”，建议保留直接授权并标注继承链。
条件允许的单元格，条件说明放在哪里比较合适？
常见做法是在单元格内用简短标注（如“需评审通过”“限本项目”），并在矩阵下方用统一的条件表解释每个标注的含义。条件与结论要相邻呈现，避免读者只看到“允许”而忽略适用范围。条件类型较多时，可以给每类条件分配固定编号，单元格只写编号，条件表集中说明，减少单元格文字量。
矩阵和系统里的实际权限配置不一致时，先改哪一边？
先判断差异的性质再决定方向。如果系统配置遗漏了矩阵中已评审通过的规则，应修正系统配置；如果矩阵未反映系统中已经生效的调整，应更新矩阵。核对时可以按固定节奏导出系统实际权限与矩阵逐格比对，标记差异项并记录处理结论，作为下一轮评审的基线。人员或项目结构发生较大调整时，提前触发一次核对。
团队规模不大，还需要维护完整的权限矩阵吗？
矩阵的价值在于把授权规则摊开供人核对，团队规模小、角色少时，维护成本也相应较低，可以只保留核心资源和敏感操作的列。随着角色数量增加、资源层级变细，矩阵的核对作用会更明显。是否维护完整矩阵取决于授权复杂度和评审要求，没有统一标准；关键是矩阵与系统配置保持同步，避免评审结论失真。
矩阵里的操作粒度应该拆到多细？
判断标准是操作能否被独立判定和独立评审。查看、创建、编辑、删除、执行、审批、导出这类动词通常需要分开，因为风险和职责不同；低频且风险相近的动作可以合并为操作集，但操作集应能展开到具体动作。高风险动作建议单独成列，保留关键判断点，避免被合并后淹没在操作集里。
