权限模型设计基础：从理论到落地
权限模型这东西，说白了就是「谁可以看什么」的一套规则。我刚开始做BI的时候，觉得权限嘛，不就是给个开关，能看不能看就完了？后来被业务部门追着改权限改了三个月，才明白——权限模型设计不好，后面全是坑。
今天咱们就把这块掰开揉碎了讲。核心就四个东西：RBAC模型、用户与组织架构、数据维度与权限标签、继承与覆盖规则。嗯，一个一个来。
1. RBAC：用户-角色-权限模型
RBAC（Role-Based Access Control）是目前最主流的权限模型。它的核心思想很简单：用户不直接关联权限，而是通过角色来间接获得权限。
举个例子你就明白了：
- 用户「张三」属于「销售经理」这个角色
- 「销售经理」这个角色拥有「查看华北区销售数据」的权限
- 那张三自然就能看华北区的数据了
为什么要绕这么一圈？直接给张三授权不行吗？
我在项目中遇到过这种情况：公司有500个销售，如果每个人单独授权，哪天组织架构调整，你得改500次。但如果你只维护「销售经理」「销售主管」「销售代表」这三个角色，改一次角色权限，所有关联用户自动生效。你想想看，这效率差了多少？
RBAC 三要素关系：
- 用户（User）：系统操作的主体，可以是人也可以是服务账号
- 角色（Role）：权限的集合，代表一类职责或岗位
- 权限（Permission）：对某个资源的具体操作能力，比如「查看报表A」「编辑报表B」
这里有个关键点：角色是权限的容器，用户是角色的容器。一个用户可以有多个角色，一个角色也可以有多个用户。这就是多对多的关系。
我的经验：角色命名要规范。别用「角色1」「角色2」这种名字，三个月后你自己都忘了是干嘛的。我一般用「业务域_岗位_级别」的格式，比如「销售_经理_高级」。
2. 用户与组织架构的关联
光有RBAC还不够。现实中的企业是有组织架构的——部门、团队、汇报关系。权限模型必须能映射这种结构。
常见的做法是：把组织架构作为权限分配的依据。比如：
- 用户属于「华北销售部」
- 「华北销售部」关联了「华北区销售数据」的权限
- 那这个用户自动获得华北区数据的查看权限
这样做的好处是：组织架构变了，权限自动跟着变。员工从华北调到华东，权限自动切换，不用人工干预。
我曾经帮一家零售企业做权限设计，他们每个月都有人员调动。如果用传统方式，IT部门得专门安排一个人天天改权限。后来我们改成基于组织架构的权限模型，IT部门直接解放了。
注意：组织架构不是一成不变的。设计时要考虑：
- 组织架构变更时，权限如何平滑迁移？
- 临时借调、兼职等情况怎么处理？
- 离职员工的权限如何自动回收？
3. 数据维度与权限标签设计
行级权限的核心，就是在数据行级别做过滤。那怎么告诉系统「哪些行你能看，哪些不能」？答案就是——权限标签。
权限标签，说白了就是给数据行打上「属性标记」。比如：
| 数据维度 | 权限标签示例 | 说明 |
|---|---|---|
| 区域 | region = '华北' | 按地理区域划分 |
| 部门 | dept = '销售部' | 按组织归属划分 |
| 产品线 | product_line = 'A系列' | 按业务线划分 |
| 数据等级 | data_level = '机密' | 按安全等级划分 |
设计权限标签时，我建议遵循几个原则：
- 标签粒度要适中：太粗了控制不住，太细了维护成本高
- 标签值要稳定：别今天叫「华北」，明天叫「North China」
- 标签要有业务含义：别用「A001」「B002」这种代号
举个例子。假设销售数据表里有「区域」字段，值有「华北」「华东」「华南」。那权限标签就是：
-- 用户张三的权限标签
region IN ('华北', '华东')
-- 查询时自动拼接
SELECT * FROM sales_data
WHERE region IN ('华北', '华东') -- 这行是权限系统自动加的
你看，用户根本感觉不到权限的存在，但数据已经被过滤了。
4. 权限继承与覆盖规则
这是最容易出问题的地方。我见过太多因为继承和覆盖规则没理清楚，导致权限混乱的案例。
权限继承：子节点自动获得父节点的权限。比如：
- 「销售部」有查看「销售数据」的权限
- 「销售一部」继承了「销售部」的权限
- 那「销售一部」的人也能看「销售数据」
权限覆盖：子节点可以修改或拒绝继承来的权限。比如：
- 「销售部」有查看「销售数据」的权限
- 但「销售二部」因为业务特殊，被禁止查看「高端产品线」的数据
- 这就是覆盖——在继承的基础上做了限制
继承与覆盖的核心规则：
- 默认继承：子节点自动获得父节点的所有权限
- 显式拒绝优先：如果子节点明确拒绝了某个权限，以拒绝为准
- 显式授权优先：如果子节点明确授予了某个权限，以授予为准
- 就近原则：离用户最近的权限定义优先级最高
我曾经遇到过一个坑：某公司给「华东区」授权了查看「华东数据」的权限，但「华东区」下面的「上海团队」又单独授权了查看「全国数据」的权限。结果上海团队的人能看到全国数据，但华东区其他团队看不到。业务部门投诉说「权限不一致」。后来我们加了规则：子节点的权限不能超过父节点的范围，除非显式授权。这才解决了问题。
避坑指南：
- 继承层级不要太深，超过3层就容易混乱
- 覆盖规则要文档化，别靠口头传
- 每次权限变更都要做回归测试，防止覆盖失效
整体架构图
下面这张图把上面讲的四个部分串起来了。你可以看到用户、角色、组织架构、权限标签、继承规则之间的关系。
嗯，到这里权限模型的基础就讲完了。这四个部分——RBAC、组织架构、权限标签、继承覆盖——是行级权限的四大支柱。后面咱们讲具体实现的时候，你会发现所有方案都是围绕这四个东西展开的。