📚 课程目录第4章权限分配与继承

角色继承与权限传递：别让权限像野草一样蔓延

权限分配这件事，很多团队一开始都觉得挺简单的。给张三配个“销售员”角色，给李四配个“销售经理”，搞定。但系统跑着跑着，就会发现不对劲——李四怎么突然有了财务模块的只读权限？王五明明只是个实习生，为什么能导出一整年的订单？

问题就出在角色继承上。我今天想跟你聊聊，角色之间的父传子、子传孙，到底该怎么管。

角色继承：很自然，但也很危险

我最早接触角色继承，是在一个OA系统的改造项目上。客户说你想想看，部门经理肯定拥有普通员工的所有权限，额外再加审批权限。这不就很自然的继承关系吗？

对，逻辑上没错。但在RBAC模型里，继承关系一旦建立，权限就开始“传染”了。我们来看一个典型的结构：

角色继承的关键特征：

子角色自动获得父角色的所有权限
权限是单向传递的，从父向子
继承链可以有多层，但深度越高风险越大
子角色可以额外增加自有权限，但通常无法移除父角色的权限

说白了，这就是一个树形结构。根节点是“基础员工”，下面长出“项目经理”、“技术主管”、“部门总监”。每一层都往上叠加权限。

我的经验：继承深度最好控制在3层以内。超过3层，你基本就搞不清楚某个底层角色到底拥有什么权限了。我曾经审计过一个系统，角色继承链整整拉了7层，最后查出来有个“试用期保洁员”角色，通过继承链，竟然拿到了系统管理员的部分权限。荒诞吧？

权限传递规则：不是你想的那样

很多人以为“继承 = 复制”，父角色有啥权限，子角色就照单全收。其实不是这么回事。

真正的权限传递，遵循三个核心规则：

传递不重算：子角色在运行时直接引用父角色的权限集合，而不是在分配时复制一份副本。这就意味着，如果你修改了父角色的权限，所有子角色都会自动生效。
传递不反向：父角色不会拥有子角色的权限。这一点最容易理解，但恰恰是很多设计翻车的地方——有人试图用继承来逆向实现“高级角色降级”，结果权限全乱套。
传递不交叉：两个不同的父角色继承分支，除非在某个中间角色处合并，否则彼此不共享权限。

这里有个常见的坑。我记得某次做审计时，发现开发团队在数据库里用外键自关联来实现角色继承：

-- 典型的关系数据库实现
CREATE TABLE roles (
    role_id INT PRIMARY KEY,
    role_name VARCHAR(100),
    parent_role_id INT NULL,
    FOREIGN KEY (parent_role_id) REFERENCES roles(role_id)
);

CREATE TABLE role_permissions (
    role_id INT,
    permission_key VARCHAR(200),
    is_granted BOOLEAN,
    PRIMARY KEY (role_id, permission_key)
);

表面看没问题，对吧？但实际跑起来，查询子角色权限时，开发团队写了个递归CTE：

WITH RECURSIVE role_hierarchy AS (
    SELECT role_id, parent_role_id, 0 AS level
    FROM roles WHERE role_id = :target_role_id
    UNION ALL
    SELECT r.role_id, r.parent_role_id, rh.level + 1
    FROM roles r
    INNER JOIN role_hierarchy rh ON r.role_id = rh.parent_role_id
)
SELECT DISTINCT rp.permission_key
FROM role_hierarchy rh
JOIN role_permissions rp ON rh.role_id = rp.role_id
WHERE rp.is_granted = TRUE;

你发现问题了吗？这个查询没有限制递归深度。如果有人在角色继承关系里不小心写了个循环引用——A继承B，B继承C，C又指向A——那么数据库会递归到爆栈为止。

注意：实现角色继承时，一定要加上递归深度上限，建议不超过10层。同时，每次修改角色继承关系时，都要做环形依赖检测。别问我为什么知道——我曾经在生产环境上亲手触发过ORA-00600错误，就是因为环形继承。

如何避免权限蔓延？我用四道防线

权限蔓延，说白了就是权限像野草一样，从一个角色长到另一个角色，最后长成一片大草原，谁也不知道边界在哪。怎么防？

我个人习惯用四道防线，挨个说说：

防线	具体做法	作用
第一道：继承锁	限制角色可继承的深度上限，例如≤3层	防止权限层层叠加，失去可控性
第二道：权限上限	每个角色设定最大权限数量，超出则告警	避免单个角色权限膨胀
第三道：继承审计	每周自动跑一次继承链变更审计，异常告警	发现未经审批的继承关系变更
第四道：权限快照	每次角色继承关系变更时，保存权限快照	回溯和对比权限变更轨迹

这里我想重点说说第一道防线——继承锁。怎么实现？很简单，在角色表里加个字段：

ALTER TABLE roles ADD COLUMN inherit_depth_limit INT DEFAULT 3;

然后在递归查询时，直接拿这个字段做硬上限。一旦某个角色设置了继承深度上限，所有父角色都不能超过这个数字向上追溯。

举个例子，假设“财务专员”角色的inherit_depth_limit = 2。那么它的父角色链最多只能往上追溯2层。如果“财务总监”在第三层，那么“财务专员”就不能直接继承“财务总监”的权限了。

你可能会问：这不是限制了灵活性吗？对，就是要限制。权限系统太灵活的结果，就是没有人能管住它。

审计视角：问题往往出在你意想不到的地方

作为审计专家，我在做权限边界审计时，会重点关注几个点——这些都是我踩过的坑：

检查继承链的起点和终点：每个继承链的根节点是谁？叶子节点是谁？中间有没有不该出现的跳跃？
检查是否存在“隐性权限”：有些系统把权限分成了“显式配置”和“继承获得”两种。审计时只看显式配置，很容易漏掉继承来的隐性权限。
检查继承权限是否遵循最小权限原则：子角色真的需要父角色的所有权限吗？还是只需要其中一部分？
检查权限传递的时效性：父角色权限变更后，子角色是立即生效还是延迟生效？如果延迟，延迟多久？

避坑指南：我曾经在一次审计中发现，某个系统的角色继承权限是异步同步的，延迟窗口长达15分钟。这就意味着，如果某个管理员的权限被撤销，他的子角色在15分钟内依然拥有这些权限。要是有人卡这个时间差搞点什么事，后果不堪设想。所以，不管用什么实现方式，权限收回必须是实时的，至少也是秒级的。

一张图搞懂角色继承与权限传递的核心流程

说了这么多，我觉得还是画张图更直观。下面这张SVG图，展示了一个标准的角色继承与权限传递流程，以及权限蔓延的阻断点：

这张图看得清楚吧？根角色“基础员工”可以派生出多个子角色。但我特意在“内部用户”这个分支上加了继承锁阻断——它下面的孙角色“受限用户”只有“内部用户”自身的新增权限，不再继承“基础员工”的全部了。这样一来，权限的边界就清晰了，不会无限制地蔓延下去。

嗯，说到这，我想起一个真实的案例。有个SaaS平台，客户公司有300多个角色，继承关系错综复杂。我们做审计时，发现其中一个叫“访客”的角色，通过长达7层的继承链，居然拿到了“订单导出”权限。这就是典型的权限蔓延——没有人能说清楚到底哪一层加了这个权限，也没有人敢去改。

所以我的建议很直白：继承关系越简单越好，能用扁平结构，就别用深度继承。你想想看，就算现在管理得了3层，等到业务扩张到50个角色的时候，你还管得住吗？