3.3 角色与权限：给积木上锁

3.3 角色与权限：给积木上锁

本节摘要：NocoBase 的权限是一套三层锁：角色决定能进哪扇门（菜单与资源），行级范围决定进屋后能碰哪几件东西（数据行），字段权限决定能不能看保险柜（敏感列）。本节讲三层锁的机制与配置，给出一套最小权限的落地方案，以及「装了锁要试锁」的验证方法。

2.4 已经提前用过一次角色配置，这一节把背后的体系讲全。权限设计的出发点不是「防人」，是「让每个人在自己的车道上开车」——车道画清楚了，越道才是异常。

一、三层锁的机制

第一层是角色与资源：一个角色是一组授权的集合，授权对象包括菜单项、页面、数据表及其操作（新增、查看、编辑、删除、导入导出）。角色没勾的资源，界面上直接不可见——注意是不可见，不是禁用，这层锁装在门口。第二层是行级数据范围：同一张表，不同角色看到的行可以不同，范围本质是一段过滤条件，典型写法是「负责人等于当前用户」。第三层是字段权限：进入某行之后，哪些列可见、哪些列可编辑，逐字段勾选。三层从粗到细，配置成本也逐层上升，落地方案遵循「够用即停」。

图 3-2 权限三层锁与一份销售角色配置矩阵

二、最小权限的落地工序

最小权限原则的落地有一套固定工序，照做即可。第一步列角色清单，从业务职能出发而不是从人头出发——按人头发权限是权限失控的起点。第二步为每个角色写一句话职责，再从职责推导资源与操作：销售「管自己的客户」，推导出三张表的增改查加本人范围。第三步配置并试锁。第四步归档一份权限矩阵文档，新人入职、岗位轮换都按矩阵增删角色，而不是随手加授权。

权限矩阵归档模板（放进团队知识库，与平台配置同步维护）：
  角色：销售
    职责一句话：维护本人名下客户与跟进
    第一层：菜单〔我的客户〕；三张表 增/改/查；无删除
    第二层：customers 范围 = 负责人等于当前用户
    第三层：隐藏列〔预估金额〕
  变更记录：日期 / 变更人 / 变更内容 / 原因
​

三、接口层与特权的边界

浏览器里的三层锁之外，还有两处边界值得交底。其一是接口调用：区块与操作最终都走平台 API，行级与字段权限在接口层同样生效——试锁清单里那条「直连接口访问他人数据被拒」验证的正是这一点。需要系统对系统调用时，走 API 密钥并为密钥单独建角色，密钥的权限同样是三层结构，不要拿管理员密钥到处塞。其二是管理员角色：平台初始化角色拥有全量权限，日常运维也不该天天用它，给运维同事单独建运维角色、只授予需要的插件与设置权限，管理员的钥匙锁进保险柜。

与工作流的联动也要点一句：3.2 的人工节点受理人是按「汇报关系」变量解析的，这层解析不受第一层菜单权限影响——审批人可以看不到客户工作台，但待办中心照样能处理任务。权限与流程各管各的层，别用权限去实现流程该做的事。

⚠️ 常见坑：用第二层范围实现「部门隔离」时引用了人员表上的部门字段，后来有人把部门字段改成自由文本，过滤条件集体失灵。数据范围的过滤字段必须是强类型的（关系字段或单选），自由文本做不出可靠的锁。

💡 关键直觉：权限配置的正确性不靠感觉，靠「试锁」。每改一轮权限，换测试账号把主流程跑一遍——锁没试过的权限配置等于没上锁。

深入一格：给权限配置做一次机器比对

三层锁配久了，界面上的勾选状态谁也记不全。把权限配置当成数据来核对，思路与 6.3 的审计口径一致：定期导出角色的授权现状，与权限矩阵文档比对。操作路径是角色详情里的权限配置导出（或截图归档），比对重点按三层顺序走：

权限比对记录（每季度一轮，入合规账本）：
  角色：销售
  第一层核对：菜单〔客户工作台/我的客户〕与矩阵一致；删除操作仍未授权
  第二层核对：客户表范围条件仍为「负责人等于当前用户」，未被改动
  第三层核对：隐藏列〔预估金额〕仍隐藏；新增列默认不可见，符合最小授权
  漂移记录：无。发现漂移时：记录漂移项、定位变更人、恢复矩阵、复盘原因
​

比对的价值在于抓「权限漂移」：上线时干干净净的配置，半年后总会多出几处「当时为了赶工先放开」的口子。漂移不可怕，可怕的是无人知晓。每季度半小时的比对，把权限从「一次性配置」变成「持续校验的活账」，这正是审计方眼中最有说服力的那种机制——不是没出过错，而是出了错一定被发现。

角色矩阵的起点模板

权限设计最难的是从零画第一张矩阵。给一份通用起点模板，多数中后台应用都能在此骨架上添改：

角色矩阵起点（四类标准角色）：
  管理员   全部菜单与设置，不含日常业务操作
  业务主管 全部数据可看，核心表可增改，审批类操作
  业务专员 本人范围数据可增改查，敏感列不可见
  只读访客 汇总页面可看，全部写操作关闭
  增改原则：先砍后加——从「全关」起步按职责逐项开
​

模板之外再给一条定力建议：角色数量控制在个位数。每多一个角色，矩阵就多一行、试锁就多一轮、漂移面就大一寸。遇到「这个人需要 A 角色的三个权限加 B 角色的两个权限」时，先怀疑是职责定义不清，而不是急着造一个缝合角色——缝合角色是权限失控的起点，三个月后没人说得清它该能干什么。

临时授权的用工单管理

「先开个口子，回头再收」是权限漂移的第一大来源，解法是把临时授权当工单管。每一次临时开口，登记四样：给谁、开什么、为什么、到期日；到期日当天必须二选一——回收，或转正（转正意味着更新权限矩阵与职责说明）。工单可以是团队协作工具里的任务卡片，形式不限，关键在「有到期日、有人认领」这两颗钉子。

临时授权单（每单一卡）：
  申请人：____    角色：____    开放内容：____
  缘由工单号：____    到期日：____    回收人：____
  到期处理：已回收 / 已转正（矩阵已更新）
​

临时授权单与季度比对（本节前文的机器比对）是一对搭档：单据管「按期收」，比对管「有没有漏」。两张网一起收口，权限漂移基本无路可走。

装配要点回顾

• 三层锁：角色与资源锁门、行级范围锁行、字段权限锁列，从粗到细、够用即停；
• 按职能发角色：从职责推导授权，按人头加权限是失控的起点；
• 接口同权：API 与界面同一套三层锁，系统对接用独立密钥加独立角色；
• 矩阵归档：权限矩阵文档与平台配置同步维护，变更留痕；
• 试锁纪律：每轮权限变更都用测试账号实测四项，试过才算上锁；
• 下一步：3.4 把门开向外部——接入别的车间，让平台成为调度台。