权限模型

ABAC

基于属性的访问控制,是相对较新的模型,通过属性组合来判断权限。这些属性可以来自:

  • 用户属性:部门、职级、工龄、地域
  • 资源属性:类型、创建者、敏感度、标签
  • 环境属性:时间、地点、设备类型

举个例子:"华东区的销售经理在工作时间可以查看本区域高价值客户的信息"。这条规则涉及了用户的地域属性、角色属性,资源的地域属性、价值属性,以及时间这个环境属性。

ABAC 的优势是灵活性极高,可以实现非常精细的权限控制。

缺点是实现复杂,性能开销大,权限规则难以理解和调试。

只适合医疗、金融等强监管行业等需要这么复杂的权限控制。

RBAC

基于角色的访问控制,是目前最主流的权限模型,核心思想是引入「角色」这个中间层。用户不直接拥有权限,而是通过角色来获得权限。

角色:

  • 销售员:可以查看和编辑自己的客户、订单
  • 销售主管:可以查看和编辑本部门所有客户、订单,可以查看销售报表
  • 财务人员:可以查看所有订单,可以开具发票,可以查看财务报表

新员工入职,只需要给他分配对应角色就行了。角色的权限变了,所有该角色的用户权限自动更新。

-- 用户表
CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    username VARCHAR(50) NOT NULL,
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 角色表
CREATE TABLE roles (
    id BIGINT PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    role_name VARCHAR(50) NOT NULL,
    parent_id BIGINT, -- 用于角色继承
    -- 其他字段...
    INDEX idx_tenant (tenant_id)
);

-- 权限表
CREATE TABLE permissions (
    id BIGINT PRIMARY KEY,
    permission_code VARCHAR(100) NOT NULL, -- 如 'customer.view'
    permission_name VARCHAR(100) NOT NULL,
    module VARCHAR(50), -- 所属模块
    -- 其他字段...
    UNIQUE KEY uk_code (permission_code)
);

-- 用户-角色关联表
CREATE TABLE user_roles (
    user_id BIGINT NOT NULL,
    role_id BIGINT NOT NULL,
    PRIMARY KEY (user_id, role_id)
);

-- 角色-权限关联表
CREATE TABLE role_permissions (
    role_id BIGINT NOT NULL,
    permission_id BIGINT NOT NULL,
    PRIMARY KEY (role_id, permission_id)
);

-- 数据权限规则表
CREATE TABLE data_permissions (
    id BIGINT PRIMARY KEY,
    role_id BIGINT NOT NULL,
    resource_type VARCHAR(50), -- 如 'customer', 'order'
    rule_type VARCHAR(50), -- 如 'self', 'department', 'all'
    rule_value TEXT, -- 具体规则,可以是 JSON
    INDEX idx_role (role_id)
);

RBAC0(基本模型)

最简单的实现,用户-角色-权限三层结构。

RBAC1(角色分层模型)

角色可以继承。

比如「销售主管」自动继承「销售员」的所有权限,再加上管理权限。这样可以减少重复配置。

RBAC2(角色限制模型)

增加了约束条件。

比如「角色互斥」(一个用户不能既是采购员又是审批员),「角色数量限制」(一个用户最多只能有 3 个角色)等。

RBAC3(统一模型)

集成了 RBAC1 和 RBAC2 的所有特性,最完整但也最复杂。

ACL

访问控制列表,是最直观的权限模型,直接定义「用户-资源-权限」的对应关系。

  • 张三可以编辑文档 A
  • 李四可以查看文件夹 B
  • 王五可以删除报表 C

优点是简单直接,实现容易。早期的文件系统、简单的内容管理系统多用这种模型。

缺点也很明显:用户一多就没法管理了。假设你有 1000 个用户,100 个资源,每个资源有 5 种操作权限,理论上你需要维护 50 万条权限记录。更要命的是,新员工入职你得一个个配置权限,员工离职你得一个个回收权限,运维成本极高。

所以 ACL 一般只适合用户量少、权限关系简单的场景。

最后更新于 2025年7月1日