做AI SaaS平台这两年我最大的体会就是权限体系这种东西看着不起眼真到了模型一多、用户一多、租户一多的时候它会变成整个系统里最容易出事故、也最难改的一块。之前我们平台刚起步时权限就两个角色管理员和普通用户菜单里藏一下按钮就完事了。后来接入的AI能力越来越重有的租户要调GPT-4o有的只需要轻量摘要还有人要按调用次数计费这时候才发现权限不是“谁能登录后台”的问题而是“谁能调用什么模型、能用多少额度、能看哪些数据”的立体问题。这篇文章就围绕如何用RBAC基于角色的访问控制实战落地一套AI SaaS平台的权限体系展开。我尽量讲清楚整个设计链路从数据表怎么建、权限点怎么命名、到模型调用怎么鉴权、配额怎么扣、审计日志怎么做再到实际开发中哪些坑最容易踩。适合正在做SaaS平台、AI应用后端、或者准备重构权限模块的团队参考也适合刚接触权限设计的后端工程师至少能帮你少走几条弯路。1. 为什么AI SaaS平台的权限体系不能只靠“登录 角色”1.1 传统后台权限和AI SaaS平台的差异传统的后台权限管理通常解决的是“谁能进入哪个页面、谁能点哪个按钮”的问题。用户登录后拿到一个角色角色关联一批菜单和操作权限后端接口再做一下拦截基本就完事了。这种模型在纯信息管理类系统里非常成熟也是RBAC最经典的应用场景。但放到AI SaaS平台上事情变复杂了因为你要控制的资源不只是页面和按钮还包括AI模型本身的调用、Token额度、并发数、数据隔离范围、甚至不同模型的不同版本。举个例子我们平台上有一个客户成功团队和一个开发者团队前者只能白屏操作调用摘要模型后者需要直接调API并且可以配置prompt模板。如果只按“管理员/普通用户”分要么开发者拿到过多权限要么客户成功团队什么都干不了。更麻烦的是AI模型调用是有成本的和合规要求的你不光要管“能不能调”还要管“能调几次”“能调哪个模型”“调完之后日志留没留下”这些已经不是传统RBAC能直接覆盖的范围了。所以说AI SaaS平台的权限体系本质上是在传统RBAC之上叠加了资源权限、配额权限、租户数据权限和审计要求。RBAC依然是最稳的底座但必须在底座上做扩展。1.2 RBAC模型怎么选从RBAC0到RBAC2再到RBACABAC很多同学知道RBAC但不一定清楚RBAC本身也分几个级别。做设计之前先把模型选对能省掉后面大量返工。RBAC0用户直接关联权限没有角色这层抽象。小项目能用但一旦权限一多用户和权限之间直接爆炸基本不推荐。RBAC1引入角色继承角色可以嵌套。比如“运营”继承“基础用户”的所有权限再额外加一些导出权限。这种模型很适合权限有天然层级关系的平台。RBAC2引入角色约束包括角色互斥用户不能同时拥有两个互斥角色、角色基数每个角色的人数上限、先决角色要拥有某角色必须先有另一个角色。这在金融、企业服务里很常见。RBAC3RBAC1RBAC2既支持继承又带约束能力最全但复杂度也最高。我实际做AI SaaS平台时建议主体用RBAC1加部分RBAC2的约束比如“模型管理员”和“财务管理员”做成互斥角色避免权限过度集中。至于那种需要根据上下文动态判断的场景比如“只允许在工作时间调用敏感模型”或者“同一个角色在不同租户下看到不同数据”纯RBAC处理不了我会额外引入ABAC策略来补充而不是把RBAC硬拗成万能模型。这里说一个很实用的判断标准如果权限判断的依据是“用户身份是什么”用RBAC如果依据是“请求时的环境、资源属性、上下文”用ABAC。AI SaaS平台里前者解决90%的问题后者解决最后那些动态规则。1.3 纯RBAC和ABAC结合的落地思路纯ABAC的问题在于规则太难维护。你让业务去写几十条策略表达式他们根本看不懂。但RBAC的好处是直观——给某个角色勾选权限点产品经理和业务都看得明白。所以我的落地思路是先把系统里所有可控制的动作抽象成权限点关联到角色上这部分全部走RBAC。在此基础上再留一个规则引擎扩展点专门承接“限时可用”“限资源可用”这类临时策略。比如某天要上线一个灰度模型只允许白名单租户调用我就在规则引擎里加一条“当租户ID在whiteList时允许访问model:invoke:new-model”而底层角色权限完全不用动。这样既保住了RBAC的简单性又不至于在动态需求面前束手无策。后面章节里的表结构设计也完全兼容这种“RBAC为主、ABAC为补充”的方案。2. 权限模型设计核心表结构与关键字段解析2.1 五张核心表的SQL设计权限系统的地基是表结构尤其要注意不要设计成“用户表里塞一个role字段”这种省事方案。后期你要查“哪些用户拥有某个权限”“某个角色都关联了什么权限”的时候一张冗余字段表会让你想骂人。我推荐至少五张表用户表、角色表、权限表、用户-角色关联表、角色-权限关联表。字段上不一定要完全照抄我的设计但以下这些核心点值得保留。CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0禁用, tenant_id BIGINT NOT NULL COMMENT 所属租户, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(64) NOT NULL UNIQUE COMMENT 角色编码如 MODEL_ADMIN, role_name VARCHAR(64) NOT NULL, parent_id BIGINT DEFAULT NULL COMMENT 父角色ID支持角色继承, status TINYINT NOT NULL DEFAULT 1, tenant_id BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, perm_code VARCHAR(128) NOT NULL UNIQUE COMMENT 权限点编码如 model:invoke:gpt-4o, perm_name VARCHAR(128) NOT NULL, category VARCHAR(64) DEFAULT NULL COMMENT 分组如 MODEL_ACCESS / QUOTA / AUDIT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, UNIQUE KEY uk_user_role (user_id, role_id) ); CREATE TABLE sys_role_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, UNIQUE KEY uk_role_perm (role_id, permission_id) );这里有一个重要细节所有业务表都加了tenant_id。原因很简单SaaS平台天然多租户如果权限表本身不按租户隔离后面做数据权限会非常痛苦。虽然sys_permission可以做成全局共享但角色和用户的关系必须绑定租户。比如A租户的“模型管理员”和B租户的“模型管理员”同名但数据完全不能互通。2.2 中间表为什么要存在而不是用户表直接带角色ID写单表快但你会立即撞上“一人多角色”这种需求。产品经理大概率会说“这个用户既是模型管理员又是审计员他的权限是两者叠加。”如果你在用户表里只放一个role_id这需求直接做不了。用中间表可以支持多对多多角色时权限取并集这个其实很简单但要注意权限叠加可能导致越权。比如一个角色有“导出用户数据”权限另一个角色刚好有“查看所有租户”的数据范围权限两者叠加就可能把全平台数据导出。遇到这种情况就要在RBAC2里加约束或者靠权限审批流程来控制后面我会在“常见问题”里展开讲。2.3 把权限点设计成“资源标识”统一命名与路由映射权限点编码是整个体系中容易被低估的设计。很多团队直接写“用户管理”“模型管理”这种中文命名短期能用但接口一多、模型一多维护起来就是灾难。我建议用三段式命名模块:动作:资源。模块通常对应系统域动作是动词资源是被操作的对象。例如model:invoke:gpt-4o 表示允许调用GPT-4o模型model:invoke:gpt-4o-mini 表示允许调用轻量模型quota:update:user 表示允许调整用户配额audit:view:log 表示允许查看审计日志prompt:write:template 表示允许编写提示词模板后端做校验时直接在接口代码里声明需要的权限点例如“调用模型接口需要model:invoke:gpt-4o”。前端拉取权限点列表后控制菜单显隐、按钮状态。这样前后端用同一套权限点编码理解成本低排查问题也方便。权限点不建议用数据库自增ID直接传给前端因为ID在不同环境可能不一致容易出现测试环境正常、生产环境错乱的灵异问题。用字符串编码做唯一标识天然可读、可迁移环境切换几乎没有成本。2.4 数据权限与租户隔离容易被忽略的维度角色权限解决的是“能不能操作”数据权限解决的是“能操作哪些数据”。在AI SaaS平台里这两个维度必须分开设计。举个例子两个租户都开通了某个模型服务如果接口鉴权只校验角色不校验租户ID用户用A租户的token调用接口传入的却是B租户的模型配置ID就可能读取到其他租户的数据。这种越权在AI应用里非常隐蔽。我通常这么处理先按RBAC判断“能不能做”再按数据权限过滤“能做哪些”。数据权限分三级就够了全部数据、本部门/本租户数据、仅本人数据。具体的隔离方式SaaS平台一般有三种选择隔离方式说明适合场景独立数据库每个租户一个库隔离最彻底大型客户、合规要求高独立Schema同库不同Schema中型SaaS共享表 tenant_id所有租户共用同一张表行级隔离中小型SaaS起步期我建议绝大多数AI SaaS平台起步阶段用“共享表 tenant_id”成本最低也最灵活。关键是要有一个全局的TenantContext比如基于ThreadLocal或请求上下文把当前租户ID塞进去然后所有的数据访问层都强制带上tenant_id条件不允许靠开发人员自觉。3. 结合AI能力扩展模型调用权限、配额与审计3.1 把AI模型当作受控资源模型网关设计AI SaaS平台和普通SaaS最不一样的地方就是底层API全是模型调用。模型不是免费资源也不是随便哪个角色都能碰所以要把模型当成一类“资源”来管理。我的做法是加一层模型网关所有模型调用统一走网关不在业务代码里直接拼OpenAI或者其他厂商的SDK调用。模型网关的核心职责有三个鉴权、配额校验、转发。所谓的“模型权限”本质上就是网关里的一组白名单配置判断当前用户所在的角色是否拥有目标模型的调用权限。{ model: gpt-4o, allowed_roles: [ROLE_MODEL_ADMIN, ROLE_ENTERPRISE_USER], allowed_plans: [enterprise, pro], rate_limit: { rpm: 60, tpm: 100000 }, quota_cost: 20 }上面这个配置的意思是只有模型管理员和企业用户角色能调用gpt-4o且套餐必须是enterprise或pro每分钟最多60次请求每次调用消耗20个credits。网关拿到请求后先解析用户角色再和配置比对不满足直接返回403满足就进入配额扣减流程。这个设计的优点很明显新增一个模型只需在网关里加配置不需要改一堆业务代码。比如平台接入了新的图像生成模型要开放给运营角色只需要在网关配置里把运营角色加进白名单再设置好配额成本前后端代码零改动。3.2 Credits配额设计权限不只是“能不能用”还要管“用多少”AI模型按调用量计费所以权限系统必须对接配额系统。很多团队一开始不做配额结果月底账单出来老板傻眼。配额本质上是一张“余额表”记录每个用户或角色在某个周期内可用多少次模型调用。Credits在AI产品里通常指计量配额。我的方案是用户账户表里存总credits余额模型配置表里存每次调用消耗多少credits每次调用前做余额预校验不足直接拒绝调用成功后异步扣费失败则返还这里有一个非常容易出问题的点并发扣费。用户连续点了几次“生成图片”如果业务代码是“先查余额再判断再扣减”并发请求可能同时通过校验导致余额变成负数。解决方式是用Redis的Lua脚本做原子扣减或者用数据库乐观锁。我习惯在网关里直接做预扣这样效率高一点-- 简单演示原子扣减 credits local current tonumber(redis.call(GET, KEYS[1]) or 0) local cost tonumber(ARGV[1]) if current cost then return -1 else redis.call(DECRBY, KEYS[1], cost) return current - cost end扣减完成后再去调模型API万一模型调用失败再执行“返还”逻辑给用户的credits加回去。这个“预扣-回调-返还”的流程比调用成功后再扣费可靠得多因为模型调用是网络IO超时、报错太常见了调用成功后再扣费很容易漏扣。3.3 审计与内容安全AI场景更容易出问题传统后台的审计日志记“谁删了什么数据”就够了AI SaaS平台的审计更复杂。你得知道谁在什么时间调用了哪个模型、传了什么输入、模型返回了什么摘要。一方面是为了排查滥用另一方面是为了满足合规要求。我的建议是至少维护一张审计表CREATE TABLE ai_audit_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, model_code VARCHAR(64) NOT NULL, action VARCHAR(32) NOT NULL COMMENT invoke / retry / fallback, prompt_hash VARCHAR(64) DEFAULT NULL COMMENT 输入内容哈希用于溯源, prompt_text TEXT DEFAULT NULL COMMENT 输入内容需要脱敏, output_text TEXT DEFAULT NULL COMMENT 输出内容摘要, cost_credits INT NOT NULL DEFAULT 0, status TINYINT NOT NULL COMMENT 0失败 1成功, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_time (user_id, created_at), KEY idx_tenant_time (tenant_id, created_at) );注意prompt_text和output_text必须脱敏不能直接原样存尤其是涉及用户隐私或企业机密的内容。实际操作里我会先跑一遍脱敏规则把手机号、邮箱、身份证号替换掉再落库。内容安全层面AI生成内容需要接入合规检测检测不通过要拦截返回。这个可以放在模型网关里做模型调用前先对输入做审查输出回来后对内容做审查两边都不放过。我们之前就踩过输出侧漏审的坑用户输入本身合规但模型生成的文案里带了违规内容好在有输出检测兜底否则问题就大了。4. 鉴权实现从登录态到权限校验的完整链路4.1 登录态与JWT权限信息放哪里权限设计得再好最终都要落到鉴权执行链路上。最常见的方案是用JWT做登录态用户在登录后拿到一个token后续请求带token访问。问题来了JWT里到底放不放权限信息我见过有人把用户所有权限点塞进JWT省得每次查库。但这样做有两个坑一是JWT是无状态的权限变更后旧的token依然有效导致权限更新不及时二是JWT体积膨胀每次请求都带着一大串权限列表浪费带宽。我的做法是JWT里只放用户ID、租户ID、角色编码列表这些轻量信息不放全量权限点。每次请求进来后用用户ID去缓存里拿权限点集合。权限变更时通过版本号机制让缓存失效这样既保证了实时性又不会把token撑得很大。// 伪代码JWT payload 示例 { sub: u_12345, tenant: tenant_678, roles: [ROLE_MODEL_ADMIN], perm_version: 12, exp: 1710000000 }perm_version是一个自增版本号每次该用户的角色或权限变更版本号加1缓存里的权限数据也跟着刷新。网关里只用判断JWT的perm_version和缓存里的版本是否一致不一致就重新加载权限不用重启服务。4.2 后端权限拦截基于注解加自定义校验器后端接口权限校验我推荐直接用Spring Security加方法级注解或者用AOP自定义一个权限注解。Spring Security生态成熟但自定义注解更轻量适合不想被框架绑得太死的团队。我通常定义一个RequirePermission的注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }然后在需要权限的接口上标注PostMapping(/v1/model/invoke) RequirePermission(model:invoke:gpt-4o) public Result invokeModel(RequestBody InvokeRequest request) { // 业务逻辑 }再写一个切面在方法执行前拦截校验当前用户是否拥有指定权限点Aspect Component public class PermissionAspect { Around(annotation(requirePermission)) public Object checkPermission(ProceedingJoinPoint joinPoint, RequirePermission requirePermission) throws Throwable { PermissionContext ctx PermissionContextHolder.get(); if (!ctx.hasPermission(requirePermission.value())) { throw new ForbiddenException(requirePermission.value()); } return joinPoint.proceed(); } }这样做的好处是权限判断和业务逻辑完全解耦代码里能看到每个接口明确的权限要求后面接新的AI模型也只需要标注对应的权限点。缺点也有如果一个接口有多个权限点注解只能写一个这时可以把注解改成支持字符串数组校验时满足任一即可或者改成必须全部满足看业务需要。4.3 前端按钮级权限控制与菜单动态化后端校验做完了前端如果不配合体验会很糟。用户看到一堆点不进去的菜单肯定会困惑。所以前端也要根据权限点动态控制界面元素。登录成功后后端返回当前用户拥有的权限点列表前端存起来。然后写一个v-permission指令控制按钮显隐// Vue 3 指令示例 app.directive(permission, { mounted(el, binding) { const required binding.value; const userPerms store.state.userPerms; if (!userPerms.includes(required)) { el.parentNode el.parentNode.removeChild(el); } } });模板里这样用el-button v-permissionmodel:invoke:gpt-4o调用GPT-4o/el-button菜单动态化同理后端返回菜单树的时候每个菜单项都绑定权限点编码前端渲染前先过滤一遍没有权限的菜单直接不渲染。这里强烈建议前后端权限点编码完全一致不要前端一套、后端一套否则排查起来要命。4.4 缓存权限Redis加速与一致性权限校验走数据库是能跑但高并发下数据库压力太大。我建议把用户权限点列表缓存到Redis里key类似perm:user:{userId}value是权限点集合的JSON数组。缓存之后要考虑失效问题。权限变更时除了更新数据库还要主动删除Redis缓存。由于JWT里有perm_version也可以约定每次请求带着版本号网关发现版本落后就主动刷新这样即使Redis被误删也能自动重建。不过缓存只是加速手段不能作为唯一数据源。高安全场景下写操作确认权限前最好回源数据库校验一次权限避免缓存数据被篡改导致越权。大多数平台没那么高要求Redis缓存就够了。5. 常见问题与排查技巧实录5.1 改了角色权限用户还是能访问旧功能这是最常遇到的问题十有八九是缓存或token导致的。JWT里塞了权限列表的token没过期之前权限当然不变Redis缓存没删的同样会读到旧权限。排查思路三步走第一步看JWT里有没有权限数据第二步看Redis缓存里有没有旧数据第三步看权限变更接口有没有主动删缓存。我见过一个团队的问题是权限变更接口改了数据库但缓存删除代码在一个新加的事务里事务回滚了缓存却被删了于是权限刷新和数据库状态不一致排查了整整一下午。所以缓存和数据库的操作顺序一定要设计好我的习惯是先更新数据库再删缓存缓存删除失败要做重试。5.2 并发扣费导致配额超扣上文提到的并发问题我再展开讲一个真实案例。我们上线初期某个客户用脚本并发调用了20次接口结果余额从1000被扣到负数虽然模型调用全成功了但对账就是不对。根因还是“先查余额再扣费”不是原子操作。用数据库乐观锁能修但性能差一点。我后来改用了Redis的Lua脚本把“检查余额、扣减、返回剩余”放在一个脚本里执行Redis保证脚本原子性彻底解决了并发问题。如果你们没有Redis也可以用数据库原子更新比如UPDATE account SET credits credits - 20 WHERE credits 20受影响的记录数为0就说明余额不足这个SQL本身是原子的。5.3 角色多、权限矩阵乱怎么治理正常来说权限点控制在100个以内角色控制在20个以内维护起来问题不大。一旦角色超过30个权限矩阵基本就会失控。我的建议是定期做角色收敛。把权限点高度重叠的角色合并用用户组而不是多角色来解决“一批人总是拥有相同角色”的需求。另外每次给角色加权限点时都要反问一句“这个权限真的需要放到角色上吗能不能用ABAC规则做临时开通”权限点不是越多越好每多一个权限点就多一分越权的可能。5.4 多租户数据越权访问全局拦截器兜底多租户SaaS最危险的场景就是A租户的用户传入B租户的资源ID接口如果没有做租户隔离数据就泄露了。光靠开发人员在SQL里写where tenant_id ?往往不够因为人都会忘。我建议做一个全局MyBatis拦截器或者在ORM层统一注入租户条件。比如MyBatis-Plus就有租户插件配置好tenant_id字段后所有自动拼接的SQL都会带上租户条件。这样即便开发者漏写了框架也会兜底。前提是你能接受所有表都有tenant_id字段这个设计需要前期规划好后期临时加非常痛苦。5.5 权限点编码错误排查还有一个细节权限点编码是字符串一旦写错比如前端要求model:invoke:gpt-4o后端接口标的是model:invoke:gpt4o用户就会莫名看到按钮被隐藏或者接口403。这种问题没有好办法只能靠规范。我建议权限点编码统一用常量类或枚举管理前后端从接口文档自动生成类型定义避免手敲出错。审核代码的时候重点看权限点字符串是否全部来自常量引用而不是随手写的字面量。如果让我重新把权限体系再做一遍我会把租户隔离和审计日志放到最高优先级因为这两个东西一旦上线后想补成本比角色模型大多了。RBAC的核心思路不复杂复杂的是把“谁能在什么条件下做什么事”这个一句话需求拆成用户、角色、权限点、数据范围、配额、审计这六个维度并且让它们各司其职又彼此协作。希望这篇实战记录能给你一些参考。 AI SaaS平台RBAC权限体系设计与实战落地指南
做AI SaaS平台这两年我最大的体会就是权限体系这种东西看着不起眼真到了模型一多、用户一多、租户一多的时候它会变成整个系统里最容易出事故、也最难改的一块。之前我们平台刚起步时权限就两个角色管理员和普通用户菜单里藏一下按钮就完事了。后来接入的AI能力越来越重有的租户要调GPT-4o有的只需要轻量摘要还有人要按调用次数计费这时候才发现权限不是“谁能登录后台”的问题而是“谁能调用什么模型、能用多少额度、能看哪些数据”的立体问题。这篇文章就围绕如何用RBAC基于角色的访问控制实战落地一套AI SaaS平台的权限体系展开。我尽量讲清楚整个设计链路从数据表怎么建、权限点怎么命名、到模型调用怎么鉴权、配额怎么扣、审计日志怎么做再到实际开发中哪些坑最容易踩。适合正在做SaaS平台、AI应用后端、或者准备重构权限模块的团队参考也适合刚接触权限设计的后端工程师至少能帮你少走几条弯路。1. 为什么AI SaaS平台的权限体系不能只靠“登录 角色”1.1 传统后台权限和AI SaaS平台的差异传统的后台权限管理通常解决的是“谁能进入哪个页面、谁能点哪个按钮”的问题。用户登录后拿到一个角色角色关联一批菜单和操作权限后端接口再做一下拦截基本就完事了。这种模型在纯信息管理类系统里非常成熟也是RBAC最经典的应用场景。但放到AI SaaS平台上事情变复杂了因为你要控制的资源不只是页面和按钮还包括AI模型本身的调用、Token额度、并发数、数据隔离范围、甚至不同模型的不同版本。举个例子我们平台上有一个客户成功团队和一个开发者团队前者只能白屏操作调用摘要模型后者需要直接调API并且可以配置prompt模板。如果只按“管理员/普通用户”分要么开发者拿到过多权限要么客户成功团队什么都干不了。更麻烦的是AI模型调用是有成本的和合规要求的你不光要管“能不能调”还要管“能调几次”“能调哪个模型”“调完之后日志留没留下”这些已经不是传统RBAC能直接覆盖的范围了。所以说AI SaaS平台的权限体系本质上是在传统RBAC之上叠加了资源权限、配额权限、租户数据权限和审计要求。RBAC依然是最稳的底座但必须在底座上做扩展。1.2 RBAC模型怎么选从RBAC0到RBAC2再到RBACABAC很多同学知道RBAC但不一定清楚RBAC本身也分几个级别。做设计之前先把模型选对能省掉后面大量返工。RBAC0用户直接关联权限没有角色这层抽象。小项目能用但一旦权限一多用户和权限之间直接爆炸基本不推荐。RBAC1引入角色继承角色可以嵌套。比如“运营”继承“基础用户”的所有权限再额外加一些导出权限。这种模型很适合权限有天然层级关系的平台。RBAC2引入角色约束包括角色互斥用户不能同时拥有两个互斥角色、角色基数每个角色的人数上限、先决角色要拥有某角色必须先有另一个角色。这在金融、企业服务里很常见。RBAC3RBAC1RBAC2既支持继承又带约束能力最全但复杂度也最高。我实际做AI SaaS平台时建议主体用RBAC1加部分RBAC2的约束比如“模型管理员”和“财务管理员”做成互斥角色避免权限过度集中。至于那种需要根据上下文动态判断的场景比如“只允许在工作时间调用敏感模型”或者“同一个角色在不同租户下看到不同数据”纯RBAC处理不了我会额外引入ABAC策略来补充而不是把RBAC硬拗成万能模型。这里说一个很实用的判断标准如果权限判断的依据是“用户身份是什么”用RBAC如果依据是“请求时的环境、资源属性、上下文”用ABAC。AI SaaS平台里前者解决90%的问题后者解决最后那些动态规则。1.3 纯RBAC和ABAC结合的落地思路纯ABAC的问题在于规则太难维护。你让业务去写几十条策略表达式他们根本看不懂。但RBAC的好处是直观——给某个角色勾选权限点产品经理和业务都看得明白。所以我的落地思路是先把系统里所有可控制的动作抽象成权限点关联到角色上这部分全部走RBAC。在此基础上再留一个规则引擎扩展点专门承接“限时可用”“限资源可用”这类临时策略。比如某天要上线一个灰度模型只允许白名单租户调用我就在规则引擎里加一条“当租户ID在whiteList时允许访问model:invoke:new-model”而底层角色权限完全不用动。这样既保住了RBAC的简单性又不至于在动态需求面前束手无策。后面章节里的表结构设计也完全兼容这种“RBAC为主、ABAC为补充”的方案。2. 权限模型设计核心表结构与关键字段解析2.1 五张核心表的SQL设计权限系统的地基是表结构尤其要注意不要设计成“用户表里塞一个role字段”这种省事方案。后期你要查“哪些用户拥有某个权限”“某个角色都关联了什么权限”的时候一张冗余字段表会让你想骂人。我推荐至少五张表用户表、角色表、权限表、用户-角色关联表、角色-权限关联表。字段上不一定要完全照抄我的设计但以下这些核心点值得保留。CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(128) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0禁用, tenant_id BIGINT NOT NULL COMMENT 所属租户, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sys_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_code VARCHAR(64) NOT NULL UNIQUE COMMENT 角色编码如 MODEL_ADMIN, role_name VARCHAR(64) NOT NULL, parent_id BIGINT DEFAULT NULL COMMENT 父角色ID支持角色继承, status TINYINT NOT NULL DEFAULT 1, tenant_id BIGINT NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, perm_code VARCHAR(128) NOT NULL UNIQUE COMMENT 权限点编码如 model:invoke:gpt-4o, perm_name VARCHAR(128) NOT NULL, category VARCHAR(64) DEFAULT NULL COMMENT 分组如 MODEL_ACCESS / QUOTA / AUDIT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE sys_user_role ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, role_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, UNIQUE KEY uk_user_role (user_id, role_id) ); CREATE TABLE sys_role_permission ( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_id BIGINT NOT NULL, permission_id BIGINT NOT NULL, UNIQUE KEY uk_role_perm (role_id, permission_id) );这里有一个重要细节所有业务表都加了tenant_id。原因很简单SaaS平台天然多租户如果权限表本身不按租户隔离后面做数据权限会非常痛苦。虽然sys_permission可以做成全局共享但角色和用户的关系必须绑定租户。比如A租户的“模型管理员”和B租户的“模型管理员”同名但数据完全不能互通。2.2 中间表为什么要存在而不是用户表直接带角色ID写单表快但你会立即撞上“一人多角色”这种需求。产品经理大概率会说“这个用户既是模型管理员又是审计员他的权限是两者叠加。”如果你在用户表里只放一个role_id这需求直接做不了。用中间表可以支持多对多多角色时权限取并集这个其实很简单但要注意权限叠加可能导致越权。比如一个角色有“导出用户数据”权限另一个角色刚好有“查看所有租户”的数据范围权限两者叠加就可能把全平台数据导出。遇到这种情况就要在RBAC2里加约束或者靠权限审批流程来控制后面我会在“常见问题”里展开讲。2.3 把权限点设计成“资源标识”统一命名与路由映射权限点编码是整个体系中容易被低估的设计。很多团队直接写“用户管理”“模型管理”这种中文命名短期能用但接口一多、模型一多维护起来就是灾难。我建议用三段式命名模块:动作:资源。模块通常对应系统域动作是动词资源是被操作的对象。例如model:invoke:gpt-4o 表示允许调用GPT-4o模型model:invoke:gpt-4o-mini 表示允许调用轻量模型quota:update:user 表示允许调整用户配额audit:view:log 表示允许查看审计日志prompt:write:template 表示允许编写提示词模板后端做校验时直接在接口代码里声明需要的权限点例如“调用模型接口需要model:invoke:gpt-4o”。前端拉取权限点列表后控制菜单显隐、按钮状态。这样前后端用同一套权限点编码理解成本低排查问题也方便。权限点不建议用数据库自增ID直接传给前端因为ID在不同环境可能不一致容易出现测试环境正常、生产环境错乱的灵异问题。用字符串编码做唯一标识天然可读、可迁移环境切换几乎没有成本。2.4 数据权限与租户隔离容易被忽略的维度角色权限解决的是“能不能操作”数据权限解决的是“能操作哪些数据”。在AI SaaS平台里这两个维度必须分开设计。举个例子两个租户都开通了某个模型服务如果接口鉴权只校验角色不校验租户ID用户用A租户的token调用接口传入的却是B租户的模型配置ID就可能读取到其他租户的数据。这种越权在AI应用里非常隐蔽。我通常这么处理先按RBAC判断“能不能做”再按数据权限过滤“能做哪些”。数据权限分三级就够了全部数据、本部门/本租户数据、仅本人数据。具体的隔离方式SaaS平台一般有三种选择隔离方式说明适合场景独立数据库每个租户一个库隔离最彻底大型客户、合规要求高独立Schema同库不同Schema中型SaaS共享表 tenant_id所有租户共用同一张表行级隔离中小型SaaS起步期我建议绝大多数AI SaaS平台起步阶段用“共享表 tenant_id”成本最低也最灵活。关键是要有一个全局的TenantContext比如基于ThreadLocal或请求上下文把当前租户ID塞进去然后所有的数据访问层都强制带上tenant_id条件不允许靠开发人员自觉。3. 结合AI能力扩展模型调用权限、配额与审计3.1 把AI模型当作受控资源模型网关设计AI SaaS平台和普通SaaS最不一样的地方就是底层API全是模型调用。模型不是免费资源也不是随便哪个角色都能碰所以要把模型当成一类“资源”来管理。我的做法是加一层模型网关所有模型调用统一走网关不在业务代码里直接拼OpenAI或者其他厂商的SDK调用。模型网关的核心职责有三个鉴权、配额校验、转发。所谓的“模型权限”本质上就是网关里的一组白名单配置判断当前用户所在的角色是否拥有目标模型的调用权限。{ model: gpt-4o, allowed_roles: [ROLE_MODEL_ADMIN, ROLE_ENTERPRISE_USER], allowed_plans: [enterprise, pro], rate_limit: { rpm: 60, tpm: 100000 }, quota_cost: 20 }上面这个配置的意思是只有模型管理员和企业用户角色能调用gpt-4o且套餐必须是enterprise或pro每分钟最多60次请求每次调用消耗20个credits。网关拿到请求后先解析用户角色再和配置比对不满足直接返回403满足就进入配额扣减流程。这个设计的优点很明显新增一个模型只需在网关里加配置不需要改一堆业务代码。比如平台接入了新的图像生成模型要开放给运营角色只需要在网关配置里把运营角色加进白名单再设置好配额成本前后端代码零改动。3.2 Credits配额设计权限不只是“能不能用”还要管“用多少”AI模型按调用量计费所以权限系统必须对接配额系统。很多团队一开始不做配额结果月底账单出来老板傻眼。配额本质上是一张“余额表”记录每个用户或角色在某个周期内可用多少次模型调用。Credits在AI产品里通常指计量配额。我的方案是用户账户表里存总credits余额模型配置表里存每次调用消耗多少credits每次调用前做余额预校验不足直接拒绝调用成功后异步扣费失败则返还这里有一个非常容易出问题的点并发扣费。用户连续点了几次“生成图片”如果业务代码是“先查余额再判断再扣减”并发请求可能同时通过校验导致余额变成负数。解决方式是用Redis的Lua脚本做原子扣减或者用数据库乐观锁。我习惯在网关里直接做预扣这样效率高一点-- 简单演示原子扣减 credits local current tonumber(redis.call(GET, KEYS[1]) or 0) local cost tonumber(ARGV[1]) if current cost then return -1 else redis.call(DECRBY, KEYS[1], cost) return current - cost end扣减完成后再去调模型API万一模型调用失败再执行“返还”逻辑给用户的credits加回去。这个“预扣-回调-返还”的流程比调用成功后再扣费可靠得多因为模型调用是网络IO超时、报错太常见了调用成功后再扣费很容易漏扣。3.3 审计与内容安全AI场景更容易出问题传统后台的审计日志记“谁删了什么数据”就够了AI SaaS平台的审计更复杂。你得知道谁在什么时间调用了哪个模型、传了什么输入、模型返回了什么摘要。一方面是为了排查滥用另一方面是为了满足合规要求。我的建议是至少维护一张审计表CREATE TABLE ai_audit_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, tenant_id BIGINT NOT NULL, model_code VARCHAR(64) NOT NULL, action VARCHAR(32) NOT NULL COMMENT invoke / retry / fallback, prompt_hash VARCHAR(64) DEFAULT NULL COMMENT 输入内容哈希用于溯源, prompt_text TEXT DEFAULT NULL COMMENT 输入内容需要脱敏, output_text TEXT DEFAULT NULL COMMENT 输出内容摘要, cost_credits INT NOT NULL DEFAULT 0, status TINYINT NOT NULL COMMENT 0失败 1成功, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_user_time (user_id, created_at), KEY idx_tenant_time (tenant_id, created_at) );注意prompt_text和output_text必须脱敏不能直接原样存尤其是涉及用户隐私或企业机密的内容。实际操作里我会先跑一遍脱敏规则把手机号、邮箱、身份证号替换掉再落库。内容安全层面AI生成内容需要接入合规检测检测不通过要拦截返回。这个可以放在模型网关里做模型调用前先对输入做审查输出回来后对内容做审查两边都不放过。我们之前就踩过输出侧漏审的坑用户输入本身合规但模型生成的文案里带了违规内容好在有输出检测兜底否则问题就大了。4. 鉴权实现从登录态到权限校验的完整链路4.1 登录态与JWT权限信息放哪里权限设计得再好最终都要落到鉴权执行链路上。最常见的方案是用JWT做登录态用户在登录后拿到一个token后续请求带token访问。问题来了JWT里到底放不放权限信息我见过有人把用户所有权限点塞进JWT省得每次查库。但这样做有两个坑一是JWT是无状态的权限变更后旧的token依然有效导致权限更新不及时二是JWT体积膨胀每次请求都带着一大串权限列表浪费带宽。我的做法是JWT里只放用户ID、租户ID、角色编码列表这些轻量信息不放全量权限点。每次请求进来后用用户ID去缓存里拿权限点集合。权限变更时通过版本号机制让缓存失效这样既保证了实时性又不会把token撑得很大。// 伪代码JWT payload 示例 { sub: u_12345, tenant: tenant_678, roles: [ROLE_MODEL_ADMIN], perm_version: 12, exp: 1710000000 }perm_version是一个自增版本号每次该用户的角色或权限变更版本号加1缓存里的权限数据也跟着刷新。网关里只用判断JWT的perm_version和缓存里的版本是否一致不一致就重新加载权限不用重启服务。4.2 后端权限拦截基于注解加自定义校验器后端接口权限校验我推荐直接用Spring Security加方法级注解或者用AOP自定义一个权限注解。Spring Security生态成熟但自定义注解更轻量适合不想被框架绑得太死的团队。我通常定义一个RequirePermission的注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }然后在需要权限的接口上标注PostMapping(/v1/model/invoke) RequirePermission(model:invoke:gpt-4o) public Result invokeModel(RequestBody InvokeRequest request) { // 业务逻辑 }再写一个切面在方法执行前拦截校验当前用户是否拥有指定权限点Aspect Component public class PermissionAspect { Around(annotation(requirePermission)) public Object checkPermission(ProceedingJoinPoint joinPoint, RequirePermission requirePermission) throws Throwable { PermissionContext ctx PermissionContextHolder.get(); if (!ctx.hasPermission(requirePermission.value())) { throw new ForbiddenException(requirePermission.value()); } return joinPoint.proceed(); } }这样做的好处是权限判断和业务逻辑完全解耦代码里能看到每个接口明确的权限要求后面接新的AI模型也只需要标注对应的权限点。缺点也有如果一个接口有多个权限点注解只能写一个这时可以把注解改成支持字符串数组校验时满足任一即可或者改成必须全部满足看业务需要。4.3 前端按钮级权限控制与菜单动态化后端校验做完了前端如果不配合体验会很糟。用户看到一堆点不进去的菜单肯定会困惑。所以前端也要根据权限点动态控制界面元素。登录成功后后端返回当前用户拥有的权限点列表前端存起来。然后写一个v-permission指令控制按钮显隐// Vue 3 指令示例 app.directive(permission, { mounted(el, binding) { const required binding.value; const userPerms store.state.userPerms; if (!userPerms.includes(required)) { el.parentNode el.parentNode.removeChild(el); } } });模板里这样用el-button v-permissionmodel:invoke:gpt-4o调用GPT-4o/el-button菜单动态化同理后端返回菜单树的时候每个菜单项都绑定权限点编码前端渲染前先过滤一遍没有权限的菜单直接不渲染。这里强烈建议前后端权限点编码完全一致不要前端一套、后端一套否则排查起来要命。4.4 缓存权限Redis加速与一致性权限校验走数据库是能跑但高并发下数据库压力太大。我建议把用户权限点列表缓存到Redis里key类似perm:user:{userId}value是权限点集合的JSON数组。缓存之后要考虑失效问题。权限变更时除了更新数据库还要主动删除Redis缓存。由于JWT里有perm_version也可以约定每次请求带着版本号网关发现版本落后就主动刷新这样即使Redis被误删也能自动重建。不过缓存只是加速手段不能作为唯一数据源。高安全场景下写操作确认权限前最好回源数据库校验一次权限避免缓存数据被篡改导致越权。大多数平台没那么高要求Redis缓存就够了。5. 常见问题与排查技巧实录5.1 改了角色权限用户还是能访问旧功能这是最常遇到的问题十有八九是缓存或token导致的。JWT里塞了权限列表的token没过期之前权限当然不变Redis缓存没删的同样会读到旧权限。排查思路三步走第一步看JWT里有没有权限数据第二步看Redis缓存里有没有旧数据第三步看权限变更接口有没有主动删缓存。我见过一个团队的问题是权限变更接口改了数据库但缓存删除代码在一个新加的事务里事务回滚了缓存却被删了于是权限刷新和数据库状态不一致排查了整整一下午。所以缓存和数据库的操作顺序一定要设计好我的习惯是先更新数据库再删缓存缓存删除失败要做重试。5.2 并发扣费导致配额超扣上文提到的并发问题我再展开讲一个真实案例。我们上线初期某个客户用脚本并发调用了20次接口结果余额从1000被扣到负数虽然模型调用全成功了但对账就是不对。根因还是“先查余额再扣费”不是原子操作。用数据库乐观锁能修但性能差一点。我后来改用了Redis的Lua脚本把“检查余额、扣减、返回剩余”放在一个脚本里执行Redis保证脚本原子性彻底解决了并发问题。如果你们没有Redis也可以用数据库原子更新比如UPDATE account SET credits credits - 20 WHERE credits 20受影响的记录数为0就说明余额不足这个SQL本身是原子的。5.3 角色多、权限矩阵乱怎么治理正常来说权限点控制在100个以内角色控制在20个以内维护起来问题不大。一旦角色超过30个权限矩阵基本就会失控。我的建议是定期做角色收敛。把权限点高度重叠的角色合并用用户组而不是多角色来解决“一批人总是拥有相同角色”的需求。另外每次给角色加权限点时都要反问一句“这个权限真的需要放到角色上吗能不能用ABAC规则做临时开通”权限点不是越多越好每多一个权限点就多一分越权的可能。5.4 多租户数据越权访问全局拦截器兜底多租户SaaS最危险的场景就是A租户的用户传入B租户的资源ID接口如果没有做租户隔离数据就泄露了。光靠开发人员在SQL里写where tenant_id ?往往不够因为人都会忘。我建议做一个全局MyBatis拦截器或者在ORM层统一注入租户条件。比如MyBatis-Plus就有租户插件配置好tenant_id字段后所有自动拼接的SQL都会带上租户条件。这样即便开发者漏写了框架也会兜底。前提是你能接受所有表都有tenant_id字段这个设计需要前期规划好后期临时加非常痛苦。5.5 权限点编码错误排查还有一个细节权限点编码是字符串一旦写错比如前端要求model:invoke:gpt-4o后端接口标的是model:invoke:gpt4o用户就会莫名看到按钮被隐藏或者接口403。这种问题没有好办法只能靠规范。我建议权限点编码统一用常量类或枚举管理前后端从接口文档自动生成类型定义避免手敲出错。审核代码的时候重点看权限点字符串是否全部来自常量引用而不是随手写的字面量。如果让我重新把权限体系再做一遍我会把租户隔离和审计日志放到最高优先级因为这两个东西一旦上线后想补成本比角色模型大多了。RBAC的核心思路不复杂复杂的是把“谁能在什么条件下做什么事”这个一句话需求拆成用户、角色、权限点、数据范围、配额、审计这六个维度并且让它们各司其职又彼此协作。希望这篇实战记录能给你一些参考。