# 权限、租户能力与数据范围职责边界说明 > 适用范围：`leaudit-platform` 当前 `RBAC + 租户主数据 + 多租户业务挂载` 体系 > 更新日期：2026-05-21 > 文档定位：专门解决“角色权限配置”和“租户管理里的功能开关/承载能力”看起来重复的问题，明确三者各自负责什么、不负责什么。 --- ## 1. 先看结论 当前系统里确实存在“语义重叠感”，但不应该把这三类配置看成同一层： 1. `角色权限` - 控制“人能不能操作” 2. `租户功能开关` - 控制“某租户是否开放某类业务能力” 3. `租户业务承载能力` - 控制“某租户能不能作为某类业务的数据归属方/挂载方” 4. `数据范围` - 控制“当前人最终能看到哪些租户、哪些数据” 如果只看页面字段，不看后端职责边界，就会误以为“租户页和角色权限页都在管入口模块、文档上传、知识库”。 这正是当前用户感知混乱的根因。 --- ## 2. 三层控制分别管什么 ## 2.1 角色权限：管人 角色权限回答的问题是： - 这个用户能不能进入某页面 - 这个用户能不能新建、编辑、删除、发布、导出 - 这个用户能不能调用某个接口 典型例子： - `entry_module:create` - `entry_module:update` - `documents:upload:create` - `rag:dataset:manage` - `rbac:tenants:update` 结论： - 角色权限只决定“用户有没有操作资格” - 不决定“数据应该挂在哪个租户下” - 也不决定“某个租户是否承载某类业务” --- ## 2.2 租户功能开关：管租户是否开放业务能力 租户功能开关回答的问题是： - 这个租户是否启用了入口模块能力 - 这个租户是否启用了文档上传能力 - 这个租户是否启用了知识库能力 当前主字段： - `sys_tenant_feature_flags.feature_key` - 前端对应 `feature_keys` 当前真实语义应理解为： - “该租户是否开放该业务能力” - 更偏向租户产品能力配置，不是用户授权配置 结论： - 功能开关不授予用户权限 - 它只决定“租户是否开放某业务” --- ## 2.3 租户业务承载能力：管数据能不能落到该租户 租户承载能力回答的问题是： - 新建入口模块时，这个租户能不能被选为适用租户 - 新建文档、模板、知识库时，这个租户能不能作为归属租户 当前主字段： - `can_host_entry_module` - `can_host_documents` - `can_host_rag` - `can_host_templates` 这类字段和 `feature_keys` 很像，但不是一回事： - `feature_keys` 更偏“租户是否开放该业务” - `can_host_*` 更偏“租户能否被选为该业务的数据挂载对象” 结论： - 承载能力不等于操作权限 - 也不完全等于功能开关 - 它主要服务于“业务归属”和“数据落点”控制 --- ## 2.4 数据范围：管最终可见边界 数据范围回答的问题是： - 这个用户最终能看到哪些租户的数据 - 这个用户能看全部、部门、自身、公共、关系型资源中的哪些部分 它最终会把下面几件事合并起来： 1. 用户身份 2. 角色权限 3. 用户归属租户 4. 目标资源归属租户 5. 模块策略 结论： - 数据范围是最终访问边界 - 它不是租户主数据页里的布尔开关 - 也不是角色权限页里的单个 permission 就能表达清楚的 ## 2.5 三层控制的防护性区别 这三层不是“配置位置不同的同一件事”，而是三道不同的防护闸： 1. `租户功能开关` - 属于业务准入防护 - 防的是“该租户根本不该开放这类业务，却仍被看见或被使用” 2. `角色权限` - 属于操作授权防护 - 防的是“租户虽然开放了该业务，但不是任何人都能新增、编辑、删除、发布” 3. `数据范围` - 属于数据边界防护 - 防的是“有权限的人在操作时串看、串改到不属于自己范围的数据” 可以直接这样理解： - `租户功能开关 = 模块级总闸` - `角色权限 = 人的操作闸` - `数据范围 = 数据行级边界闸` 任意一层缺失，风险都不同： 1. 只有功能开关，没有角色权限 - 结果：租户开了功能后，可能任何角色都能乱用 2. 只有角色权限，没有功能开关 - 结果：本不该承载该业务的租户，仍可能被误开放入口或误创建数据 3. 只有前两层，没有数据范围 - 结果：拥有权限的用户仍可能看到其他租户数据，形成越权或串租户泄漏 所以最终判断某个操作是否允许，不能只看一层，而应按下面顺序串起来判断： 1. 目标租户是否开放该业务 2. 当前用户是否具备该业务动作权限 3. 当前用户的数据范围是否允许访问该目标租户或目标资源 --- ## 3. 为什么当前会让人觉得重复 当前用户会觉得重复，原因不是理解错了，而是系统现状确实还没完全收口： 1. 前端租户页把： - `启用租户` - `公共租户` - `功能开关` - `承载能力` 混在同一个表单区域里 2. 业务名称上和角色权限页高度重合 3. 部分下游模块还没有把 `can_host_*` 做成强执行链路 4. `feature_keys` 已经有使用点，但并不是所有模块都用同一模式接入 因此现在最准确的判断不是“完全重复”，而是： - 设计上应该分层 - 落地上还处于过渡态 - 页面表达还不够清楚 补一句更贴近当前现状的话： - 当前系统已经有三层模型雏形 - 但还没有在所有模块做到“租户能力先拦、权限再拦、数据范围最后收口”的稳定统一执行顺序 --- ## 4. 当前代码里的真实分工 ## 4.1 已经落到真实用途的部分 当前已经能确认的真实用途： 1. `feature_keys` - 已被入口模块租户选择器消费 - `home.entry_module` 已有真实用途 2. `leaudit_entry_module_tenants` - 已作为入口模块适用租户关系表使用 3. 用户当前上下文 - 已开始统一输出 `tenant_code / tenant_name` 4. 首页入口模块 - 已按用户租户 + 模块租户关系过滤 ## 4.2 仍未完全闭环的部分 以下部分仍需继续补强： 1. `can_host_documents` 2. `can_host_rag` 3. `can_host_templates` 4. `feature_keys` 的统一消费规范 结论： - 现在租户页里的部分字段已经不是摆设 - 但也还没有做到所有字段都形成“写入即生效”的全链路闭环 --- ## 5. 最终建议的收口规则 ## 5.1 角色权限页只做“人”的授权 角色权限页只保留： - 页面访问权限 - 菜单权限 - 按钮权限 - 接口动作权限 - 数据范围策略 不要在角色权限页里表达： - 某租户是否开放业务 - 某租户是否能承载业务数据 ## 5.2 租户管理页只做“租户侧能力配置” 租户管理页应拆成 3 组： 1. 基础状态 - `启用租户` - `公共租户` 2. 功能开关 - 某租户是否开放某业务能力 3. 业务承载能力 - 某租户能否作为某业务的数据归属方 并且页面必须明确提示： - 这里不授予用户操作权限 - 用户是否能操作，仍由角色权限决定 ## 5.3 数据范围执行器单独收口 数据范围不要继续分散在各业务模块里各写一套： - 应把用户权限 - 用户租户 - 资源租户 - 公共数据策略 - 关系型特例 统一并入执行器。 --- ## 6. 推荐页面文案 ### 功能开关 说明： - 决定该租户是否开放某类业务能力 - 不直接授予用户页面或按钮操作权限 ### 业务承载能力 说明： - 决定该租户能否作为该类业务的数据归属租户 - 会影响新建/编辑时该租户是否可被选中 ### 角色权限 说明： - 控制当前用户能不能访问页面、调用接口、执行动作 - 与租户侧能力配置是两层控制 --- ## 7. 后续工程动作建议 优先级建议： 1. 前端租户页分组与文案改清楚 2. 为 `can_host_documents / can_host_rag / can_host_templates` 补下游强校验 3. 梳理 `feature_keys` 的统一消费规范 4. 统一把“租户是否可选”沉到服务层，不让前端自己猜 5. 最后再把数据范围执行器接到更多业务域 --- ## 8. 一句话原则 后续所有实现都应遵守下面这个原则： - `角色权限` 决定“谁能操作” - `租户功能开关` 决定“租户开不开这类业务” - `租户承载能力` 决定“数据能不能挂到这个租户” - `数据范围` 决定“最终能看到哪些数据” 只要这四层不再混写，后面的权限和多租户改造就不会继续失控。