巴别鸟 32 维权限系统实战

做过企业云盘权限系统的人都清楚，这玩意儿比表面复杂得多。私有化部署场景下，客户对权限颗粒度的要求远超"读/写/管理"三级。巴别鸟在 32 维权限模型上跑了 3 年，本文把设计思路、核心代码、踩坑实录全部展开，实操性拉满。

一个真实故事：从"研发能看设计稿"说起

泡泡玛特的业务有个有意思的场景：潮玩设计稿在上市前属于高度机密，但外包设计公司需要参与共创。怎么让外包在工作时间、从公司 IP 才能看，而且设计稿只能预览不能下载？

这个问题拆开来看，每句话都是一个权限约束：谁（外包公司）、能干什么（预览）、什么时候（工作时间）、从哪来（公司 IP）、不能干什么（下载）。传统的"角色+操作"二维模型根本兜不住。RBAC 只告诉你"用户 A 是角色 X，所以能操作 Y"，但它回答不了"什么时候、从哪来、用什么设备"这类上下文问题。

后来航天五院又提了一个更极端的：涉密版本只有管理员能删，研发部只能看，商务部可以下载。同一份文件，三组人看到的东西完全不同，而且还跟版本挂钩——历史版本权限跟当前版本独立。

这种多维约束叠加的场景，逼着我们去重新思考权限模型的设计哲学。

权限模型的根本问题：RBAC 解决不了的到底是什么

RBAC 跑得好好的，为什么还要搞 32 维？

核心矛盾在于：企业权限决策依赖的上下文，远不止"谁+做什么"。真实场景里，约束条件天然就是多维的：

• 主体：个人、部门、项目组、角色、外部协作人、服务账号、AI Agent
• 资源：文件、文件夹、项目空间、组织单元
• 动作：预览、下载、编辑、删除、分享、评论、版本管理、移动、权限委托
• 环境：时间窗口 × IP段 × 设备类型 × 网络环境

7 × 4 × 9 × 环境维度 =32 维权限空间。环境维度不是固定的 N，是动态枚举，所以叫"32 维"是口语说法，实际上是个开放空间。

把这个模型搭起来之后，之前那些"说不清道不明"的权限需求，突然就变得可以配置了。

数据库表设计：三张表把策略存清楚

先说表结构。踩过一个关键坑：别用布尔值存操作类型，用位掩码（bit mask）压缩。一条策略同时覆盖下载+编辑，位掩码一条记录搞定，查询效率完全不一样。

CREATETABLEpermission_policy(idBIGINTPRIMARYKEYAUTO_INCREMENT,policy_nameVARCHAR(128)NOTNULLCOMMENT'策略名称',resource_typeTINYINTNOTNULLCOMMENT'1=文件 2=文件夹 3=项目空间 4=组织单元',resource_idBIGINTNOTNULLCOMMENT'资源ID',actionSMALLINTNOTNULLCOMMENT'位掩码: 1=预览 2=下载 4=编辑 8=删除 16=分享 32=评论 64=版本管理 128=移动 256=权限委托',effectTINYINTNOTNULLDEFAULT1COMMENT'1=允许 0=拒绝',priorityINTNOTNULLDEFAULT0COMMENT'数字越大优先级越高',created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,INDEXidx_resource(resource_type,resource_id),INDEXidx_action(action))ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;CREATETABLEpolicy_subject(idBIGINTPRIMARYKEYAUTO_INCREMENT,policy_idBIGINTNOTNULL,subject_typeTINYINTNOTNULLCOMMENT'1=个人 2=部门 3=项目组 4=角色 5=外部协作人 6=服务账号 7=AI Agent',subject_idBIGINTNOTNULL,INDEXidx_policy(policy_id),INDEXidx_subject(subject_type,subject_id),FOREIGNKEY(policy_id)REFERENCESpermission_policy(id)ONDELETECASCADE)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;CREATETABLEpolicy_environment(idBIGINTPRIMARYKEYAUTO_INCREMENT,policy_idBIGINTNOTNULL,constraint_typeTINYINTNOTNULLCOMMENT'1=时间窗口 2=IP段 3=设备类型 4=网络环境',constraint_value JSONNOTNULLCOMMENT'如 {"start":"09:00","end":"18:00","timezone":"Asia/Shanghai"}',INDEXidx_policy_env(policy_id),FOREIGNKEY(policy_id)REFERENCESpermission_policy(id)ONDELETECASCADE)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4;

重点说一下action字段的位掩码设计：action=6（二进制 110）表示同时覆盖下载+编辑，一条记录顶过去两条 JOIN。MySQL 5.7 以上直接用action & 2 = 2判断是否包含某个操作，不用拆字段查。

权限判定核心代码

数据库只做存储和初步过滤，权限判定逻辑在应用层。以下是 Node.js 实现，实测可以直接用：

constACTIONS={PREVIEW:1,// 000000001DOWNLOAD:2,// 000000010EDIT:4,// 000000100DELETE:8,// 000001000SHARE:16,// 000010000COMMENT:32,// 000100000VERSION:64,// 001000000MOVE:128,// 010000000DELEGATE:256// 100000000};asyncfunctioncheckPermission(userId,resourceType,resourceId,actionBit,context={}){// 收集用户所有主体身份constidentities=awaitresolveUserIdentities(userId);// identities: [{type:1, id:10086}, {type:2, id:301}, {type:4, id:5}]// 查询所有匹配的策略constpolicies=awaitqueryMatchingPolicies(identities,resourceType,resourceId,actionBit);if(policies.length===0)return{allowed:false,reason:'NO_POLICY'};// 按优先级排序，逐条检查环境约束policies.sort((a,b)=>b.priority-a.priority);for(constpolicyofpolicies){constenvOk=awaitevaluateEnvironmentConstraints(policy.id,context);if(!envOk)continue;return{allowed:policy.effect===1,reason:policy.effect===1?'GRANTED':'DENIED',policyId:policy.id};}return{allowed:false,reason:'NO_ENV_MATCH'};}asyncfunctionevaluateEnvironmentConstraints(policyId,context){constconstraints=awaitdb.query('SELECT * FROM policy_environment WHERE policy_id = ?',[policyId]);if(constraints.length===0)returntrue;for(constcofconstraints){constval=JSON.parse(c.constraint_value);switch(c.constraint_type){case1:{constnow=timeInZone(val.timezone||'Asia/Shanghai');if(now<val.start||now>val.end)returnfalse;break;}case2:if(!ipInRange(context.clientIp,val.cidr))returnfalse;break;case3:if(!val.allowedDevices.includes(context.deviceType))returnfalse;break;case4:if(val.requireSecure&&!context.isTls)returnfalse;break;}}returntrue;}

策略继承也很关键：子资源默认继承父级策略，只有例外才单独配置。用以下命令可以查看当前策略总数：

mysql-h127.0.0.1-uroot-p-Dbabelloop\-e"SELECT resource_type, COUNT(*) as cnt \ FROM permission_policy GROUP BY resource_type \ ORDER BY cnt DESC;"

三个真实坑点

坑 1：策略爆炸问题

7 × 4 × 9 看起来组合很多，但实际根本不需要那么多策略。靠权限继承，子资源默认继承父级策略，只有例外情况才单独配置。绝大部分企业 200-800 条策略就够用。泡泡玛特跑 3 年，策略从 150 条增长到 400 条，权限判定平均响应 < 5ms。

坑 2：环境约束性能

每次权限判定都要查policy_environment表，高并发下成了性能瓶颈。解决方案：热点策略的环境约束缓存到 Redis，TTL 60 秒。

# Redis key 设计perm:env:{policy_id}->JSON(constraints)# 查询顺序: Redis → MySQL# 命中率实测: 92%（无环境约束的策略返回空标记，不穿透 DB）

中建南洋在海外工程场景下，跨部门文件协同有大量临时时间窗口约束，Redis 缓存把这块的 DB 压力降了 90%。

坑 3：智巢 AI Agent 的权限边界

智巢 AI（DeepSeek 私有化 RAG）是巴别鸟的协同智能模块，AI 作为第 7 类主体，权限判定有特殊处理：

• AI 只能访问被明确授权的知识库范围
• AI 生成的文件自动继承创建者的权限
• AI 读取文件时，环境约束中的"设备类型"替换为"Agent 版本号"

-- 智巢 AI 专用只读策略INSERTINTOpermission_policy(policy_name,resource_type,resource_id,action,effect,priority)VALUES('智巢AI只读知识库',3,5001,1,1,100);-- action=1 仅允许预览，下载和编辑均拒绝INSERTINTOpolicy_subject(policy_id,subject_type,subject_id)VALUES(LAST_INSERT_ID(),7,200);-- subject_type=7 = AI Agent

航天五院踩过一个更极端的坑：VPN 用户来源 IP 不稳定，纯 IP 判断导致内网用户被误判。后来改为 IP + 设备指纹双重校验才解决。

权限变更怎么同步到审计

权限系统不仅是访问控制，还要支撑版本协同场景下的权限联动。审计日志同步写入是关键：

# 查看某文件的权限策略列表mysql-h127.0.0.1-uroot-p-Dbabelloop\-e"SELECT pp.policy_name, pp.action, pp.effect, pp.priority, \ ps.subject_type, pe.constraint_type \ FROM permission_policy pp \ JOIN policy_subject ps ON pp.id = ps.policy_id \ LEFT JOIN policy_environment pe ON pp.id = pe.policy_id \ WHERE pp.resource_type = 1 AND pp.resource_id = ? \ ORDER BY pp.priority DESC;"

每次策略变更通过消息队列同步到审计系统，审计日志与策略版本保持一致，支持回滚查证。

32 维权限 vs 传统 RBAC：实际场景对比

总结

32 维权限模型的核心是把环境约束纳入决策链路，位掩码+优先级排序+缓存保证性能。实操中最大两个坑是策略爆炸和环境约束性能，用继承和 Redis 缓存可以有效规避。这套方案在泡泡玛特、中建南洋、航天五院均稳定运行 3 年以上，策略数量分别约为 400、550、800 条，场景各有侧重。