如何设计一套多租户权限系统的数据模型

权限管理在复杂业务系统中最核心的任务，是解决"谁在什么条件下能对哪个资源的哪项操作生效"这一组交叉问题。一套可扩展、可审计、可动态调整的权限数据模型，直接决定系统在安全审查、多租户隔离和运维效率上的上限。本文以RBAC（基于角色的访问控制）为基线，结合数据权限与多租户隔离场景，给出经过一线架构验证的建模思路与关键代码实现。

权限模型选型决定系统复杂度上限

RBAC模型是绝大多数业务系统的最佳起点，ABAC（基于属性的访问控制）和ReBAC（基于关系的访问控制）仅在特定场景下具备替代优势。据Gartner《Access Management Technology Insight》报告数据显示，超过80%的企业级应用采用以RBAC为基线的权限架构，因为角色天然贴近组织架构，易于业务部门理解和审批。

三种模型的边界定义如下：

设计权限系统时不要一开始就追求ABAC，先把RBAC的用户、角色、权限点、资源类型四张基础表建扎实，再根据业务需要逐步引入属性策略。Google Zanzibar团队在论文《Zanzibar: Google's Consistent, Global Authorization System》中披露，其权限系统本质是一种ReBAC实现，但Google内部绝大多数服务仍优先使用角色层级来管理授权，只有文档、日历等强协作场景才启用关系图谱。

RBAC基础表结构的设计要点

RBAC核心数据模型由用户表、角色表、权限表、用户角色关联表和角色权限关联表五张表构成。权限点采用"资源:操作"的字符串编码方式，比整型ID更直观且无需二次查表。

一个可直接落地的基础建表语句如下：

CREATE TABLE `role` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `code` varchar(64) NOT NULL COMMENT '角色编码: admin/ops/viewer',
  `name` varchar(64) NOT NULL COMMENT '角色名称',
  `tenant_id` bigint NOT NULL COMMENT '租户ID，0表示系统级角色',
  `status` tinyint NOT NULL DEFAULT 1,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_tenant_code` (`tenant_id`,`code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `permission` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `resource` varchar(64) NOT NULL COMMENT '资源标识: order/user/report',
  `action` varchar(32) NOT NULL COMMENT '操作: create/read/update/delete/export',
  `scope` varchar(32) NOT NULL COMMENT '数据范围: all/dept/self',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_resource_action` (`resource`,`action`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

设计权限表时只有资源与操作还不够，必须同步纳入数据范围字段。同一个"查看订单"按钮，运营总监应该看到全公司订单，销售经理只能看到本部门订单，销售代表只能看到自己创建的订单。如果数据范围放在后端代码里硬编码，权限系统迟早会腐化成一堆if-else分支。

数据权限与菜单权限的分离存储策略

数据权限和菜单权限必须分表存储，这个结论来自大量线上安全事件复盘。很多系统把菜单权限和按钮权限全部塞进一张permission表，用type字段区分menu或button，查询时一次加载全部权限再按类型过滤。这种设计初期方便，后期却会让SQL复杂度和缓存命中率同时恶化——菜单权限变更频率低、参与数据量小，而数据权限随着组织架构调整频繁变动，两者生命周期完全不同。

推荐的做法是菜单权限沿用RBAC的"角色-权限点"映射，数据权限单独建一张数据规则表，用JSON字段存储SQL过滤条件。

CREATE TABLE `data_rule` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `role_id` bigint NOT NULL COMMENT '角色ID',
  `resource` varchar(64) NOT NULL COMMENT '资源标识',
  `condition_expr` json NOT NULL COMMENT '过滤条件: {"dept_id":8} 或 {"user_id":"current"}',
  `priority` int NOT NULL DEFAULT 0 COMMENT '规则优先级，数字小优先',
  PRIMARY KEY (`id`),
  KEY `idx_role_resource` (`role_id`,`resource`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

在一个订单管理系统中，数据规则的实际语义是：当请求"查询订单"接口时，系统先从用户角色找到对应数据规则，解析JSON条件表达式，拼接到SQL的WHERE子句中。使用JSON存储的好处是规则扩展时不需要改表结构，但代价是无法在数据库层做规则校验，因此必须配合严格的输入验证，防止注入恶意条件。

多租户隔离选型与共享权限表改造

多租户权限隔离存在三种实现路径，分别是独立数据库、共享数据库独立Schema和共享表加租户ID过滤。其中共享表加租户ID过滤是成本与隔离性平衡最好的方案，但要付出额外的SQL改写成本。

在共享表方案下，所有角色表、权限表都必须新增tenant_id字段。为避免每个查询都手动拼接租户条件，推荐在ORM层（如MyBatis、GORM）编写全局拦截器自动注入。以订单数据为例，拦截器会将"SELECT * FROM order_item"改写成"SELECT * FROM order_item WHERE tenant_id = 当前登录用户租户ID"。

租户ID注入必须使用参数绑定而不是字符串拼接，攻击者如果能在请求头伪造租户ID，拼接SQL会把整个租户的数据全部暴露。据Veracode《State of Software Security》报告统计，访问控制缺陷在Web应用漏洞中占比约14%，其中横向越权（租户A访问租户B数据）是最高发的子类。

角色继承与权限累加的边界控制

角色继承机制设计不当会造成权限爆炸，设计得当则能大大降低运维成本。部门经理角色继承部门员工角色，意味着经理自动获得员工的所有权限，同时额外拥有审批和导出权限。继承关系在RBAC模型中表示为角色之间的父子关联，但必须明确禁止多级循环继承。

CREATE TABLE `role_relation` (
  `parent_role_id` bigint NOT NULL,
  `child_role_id` bigint NOT NULL,
  `inherit_type` tinyint NOT NULL DEFAULT 1 COMMENT '1-完全继承 2-部分继承',
  PRIMARY KEY (`parent_role_id`,`child_role_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

完全继承模式下，经理的最终有效权限 = 自身权限 ∪ 员工的全部权限。部分继承则需要在关联表上增加refuse_permission_ids字段，显式排除某些敏感权限。实际落地中我倾向只做完全继承，因为部分继承的排查链路太长，一旦出现越权事件，安全团队需要同时检查角色表和关联表的排除逻辑，定位效率极低。

权限累加的语义必须唯一。同一用户拥有多个角色时，有效权限是各角色权限的并集，不允许出现"一个角色允许、另一个角色拒绝"的冲突场景。如果业务上确实需要拒绝某项权限，正确做法是设计独立的"角色禁用权限表"，在权限校验的最后一步剔除禁用项。这套方案的规则一致且易于解释，审计日志也可以清晰记录"用户X因角色Y获得权限Z"或"因角色禁用规则被拒绝"。

动态权限变更与缓存一致性的折中

权限变更必须做到分钟级生效，全量缓存并等待过期是最差的设计。业界通用的做法是权限数据放入Redis，变更时主动删除对应缓存键，下次请求再回源数据库加载。权限点表、角色表这类低频变更数据可以设置5到10分钟的短时缓存；用户权限集合属于高频查询数据，必须实现变更即清除。

func (s *PermissionService) ChangeUserRole(ctx context.Context, userID int64, roleIDs []int64) error {
    tx := s.db.Begin()
    if err := tx.Exec("DELETE FROM user_role WHERE user_id = ?", userID).Error; err != nil {
        tx.Rollback()
        return err
    }
    for _, roleID := range roleIDs {
        if err := tx.Exec("INSERT INTO user_role (user_id, role_id) VALUES (?, ?)", userID, roleID).Error; err != nil {
            tx.Rollback()
            return err
        }
    }
    if err := tx.Commit().Error; err != nil {
        return err
    }
    cacheKey := fmt.Sprintf("perm:user:%d", userID)
    return s.cache.Del(ctx, cacheKey).Err()
}

这里有两个必须注意的细节。其一，数据库事务提交成功后才允许删除缓存，否则先删缓存再回滚事务会造成脏数据。其二，权限缓存删除后需要让后续请求回源时加分布式锁，否则多个实例同时回源会引发缓存击穿。在高并发下建议引入singleflight机制，同一时刻只允许一个请求回源数据库。

权限相关的审计日志同样不能省。每次角色变更、权限点变更必须记录操作人、操作时间、目标对象和变更前后差异。腾讯安全团队在《企业安全建设指南》中给出的经验值是：权限审计日志至少保留180天，并且要支持按用户、按角色、按操作类型三个维度快速检索。

权限校验链路的性能优化实践

权限校验的常见性能瓶颈集中在数据库查询次数和缓存穿透。一个优化到位的权限校验链路，单次鉴权耗时应该控制在5毫秒以内，其中Redis查询占主要开销。

优化手段按照有效性排序如下：

1. 权限点全部加载到本地内存（如Go的sync.Map或Java的Caffeine），配合每30秒一次的后台刷新，把缓存命中的时间从毫秒级降到微秒级。
2. 用户权限集合按"用户ID+租户ID"作为缓存键，避免跨租户串数据。
3. 角色与权限的映射在写入时就完成展开，也就是用户缓存中直接存权限点ID集合，而不是存角色ID再实时关联查询。
4. 敏感接口（如导出、删除）绕过缓存强制校验数据库，缓解缓存异常带来的越权风险。

使用权限校验中间件将鉴权逻辑与业务代码解耦，是避免权限漏洞散落在各个业务模块中的有效手段。在Go Web框架中，每个需要权限保护的API只需标注资源与操作标识，中间件统一完成鉴权与审计，业务函数内部不再出现任何权限判断代码。

权限系统的建设没有银弹，但把RBAC基线、数据权限分离、多租户隔离、缓存一致性四条主线走稳，就能覆盖绝大多数业务场景的安全诉求。在技术选型时优先选择成熟建模，将复杂策略留在业务层演进，是权限管理落地中最值得坚持的工程判断。