从 RBAC 到 ABAC：一套权限模型怎么长出三个维度

权限这件事有个特点：它很少在设计阶段出问题，几乎总是在第三次扩展的时候崩掉。前两次你还能靠加字段、加分支扛过去，第三次你会发现每加一种资源，要改的地方是"已有实现数量 × 新资源数量"。

这篇讲清楚三件事：为什么角色不够、为什么必须拆成三条正交的轴、以及在一个已经在跑的系统上怎么换掉它而不出事故。

先承认 RBAC 解决了什么

RBAC 的核心贡献是把"人 → 权限"的 N×M 关系，拆成"人 → 角色 → 权限"的 N+M。这在权限是静态的、和数据无关的场景下非常好用：谁能进后台、谁能点删除按钮。

它的边界也很清楚——RBAC 回答不了任何一个跟"哪一条数据"有关的问题。"运维能查看设备"是角色能表达的；"运维只能查看他负责区域内的设备"不是。

三条正交的轴

把上面四行归并一下，落到工程上其实是三个不同的作用位置——它们发生在请求生命周期的不同时刻，必须是三套独立的机制。

数据范围这一轴的关键：下推

三条轴里，只有数据范围有个绕不开的工程难点：它必须变成 SQL 的一部分。

错误做法 —— 查完再过滤

public Page<Device> list(Query q) {
    Page<Device> page = deviceMapper.selectPage(q);   // 数据库返回 10 条
    page.setRecords(page.getRecords().stream()
        .filter(d -> scope.contains(d.getRegion()))    // 过滤掉 7 条
        .toList());
    return page;   // total 还是原来的总数 → 分页彻底错乱
}

正确做法 —— 条件下推

@DataScope(resource = "DEVICE", alias = "d")
public Page<Device> list(Query q) {
    return deviceMapper.selectPage(q);
}

// 拦截器在 SQL 到达数据库之前追加条件：
//   ... WHERE 1=1 AND d.region_id IN (?, ?, ?) 
// count 语句同样被改写，所以 total 是对的

范围表达式：不要发明 DSL

见过不少团队在这一步给自己挖坑：设计一套自研表达式语言来描述范围。三个月后没人能读懂线上存的那些串，也没有工具能校验它。

够用的模型比想象中简单——一条范围规则 = 资源类型 + 属性 + 操作符 + 值集合，多条之间做并集：

{
  "resource": "DEVICE",
  "rules": [
    { "attr": "regionId",  "op": "IN",     "values": ["CN-EAST", "CN-SOUTH"] },
    { "attr": "snPrefix",  "op": "PREFIX", "values": ["AL7"] },
    { "attr": "orgPath",   "op": "SUBTREE","values": ["/root/cn/east"] }
  ],
  "combine": "UNION"
}

四五个操作符能覆盖九成场景：IN、PREFIX、SUBTREE、ALL、NONE。覆盖不了的那一成，让它走代码，不要为了它把模型撑大。

换掉老实现：并行链路

真正的难题从来不是设计新模型，是在一个已经跑着的系统上换掉旧的。老系统里往往散着六七套硬编码判断，而且没有人能说清它们的优先级——因为那从来没被定义过。

可行的路线是：新建一条并行链路，先只判定不拦截。老链路一行不动。

几条踩过的经验

最后一句：权限系统的成功标准不是"拦住了多少非法请求"，是业务方接入一个新资源时，不需要来找你。做到这一点，模型就算对了。