多租户SaaS架构下的BI数据隔离与权限治理体系

引言

SaaS厂商在集成嵌入式BI时，最先被客户问到的三个问题永远是：我的数据会不会被其他租户看到？不同租户的指标定义能不能不一样？权限体系能不能跟我现有的角色系统打通？

这三个问题的本质是同一个命题：多租户架构下的数据隔离与权限治理。这不是一个可以"上线后补"的功能——如果在架构设计阶段没有处理好多租户隔离，后续的数据泄露风险和运维成本将是灾难性的。

衡石科技HENGSHI SENSE在服务200+ISV伙伴的过程中，构建了成熟的多租户BI架构体系。本文将从数据隔离、权限治理、租户管理三个维度，深度解析SaaS场景下BI平台的多租户技术实现。

一、多租户数据隔离的三层机制

1.1 数据隔离的核心原则

多租户数据隔离的设计遵循三个核心原则：

• 逻辑隔离：不同租户的数据在逻辑层面完全独立——数据集、指标定义、仪表盘配置均为租户私有

• 权限边界清晰：每个租户的数据访问范围由其租户管理员自主控制，不受平台管理员干预

• 性能不受影响：租户间的数据隔离不以牺牲查询性能为代价——100+租户并发查询时，每个租户的响应时间不受其他租户影响

1.2 数据集层面的隔离

每个租户拥有独立的数据集配置空间：

数据连接隔离

租户管理员在租户空间内创建和管理自己的数据连接——数据连接的认证信息、连接参数、网络配置均为租户私有，其他租户无法查看或访问。

对于SaaS厂商自建数据仓库的场景，数据连接的隔离机制确保了每个租户只能连接到自己的数据库schema或数据分区。

数据集定义隔离

每个租户的数据集定义独立管理——相同业务概念的数据集，在不同租户中可以有不同的字段映射、数据类型、计算口径。例如，"客户表"在租户A中可能包含10个字段，在租户B中可能包含15个字段，两者互不影响。

数据模型隔离

数据集之间的关联关系（Join/Union）也是租户私有的。同一组数据集，在不同租户中可以建立不同的关联模型——租户A可能需要"客户表 Join 订单表"的模型，租户B可能需要"客户表 Join 订单表 Join 产品表"的更复杂模型。

1.3 指标定义层面的隔离

指标定义隔离是多租户BI架构的核心特征——不同租户的同一业务概念可以有不同的计算口径：

原子指标隔离

每个租户的原子指标定义独立管理。例如，"销售额"在租户A中的原子指标定义为SUM(order_net_price)（净销售额），在租户B中的定义为SUM(order_gross_price)（毛销售额）——两个租户的"销售额"计算口径完全不同，但各自在自己的业务语境下都是正确的。

业务指标隔离

业务指标的维度条件、粒度声明、KPI目标等配置均为租户私有。租户A的"华东区月度销售额"和租户B的"华东区月度销售额"可以引用不同的原子指标、使用不同的维度值映射、采用不同的粒度定义。

语义标注隔离

每个租户的指标语义标注独立维护——别名、业务描述、使用场景标注等均为租户私有。这意味着同一指标在不同租户中可以有不同的自然语言别名，ChatBI的语义匹配结果是租户级别的。

1.4 仪表盘配置层面的隔离

仪表盘隔离

每个租户的仪表盘配置独立管理——布局、图表类型、过滤器、参数等均为租户私有。ISV可以为不同租户提供不同的仪表盘模板，租户管理员也可以在模板基础上进行个性化调整。

发布权限隔离

仪表盘的发布权限和分享权限由租户管理员自主配置——不同租户的发布策略可以完全不同，有的租户可能允许所有用户发布仪表盘，有的租户可能限制为仅管理员可发布。

二、权限治理体系

2.1 三级权限模型

HENGSHI SENSE的多租户权限体系采用三级模型：

第一级：平台级权限

平台管理员（通常为ISV的运维团队）管理平台的整体配置：

• 租户的创建、暂停、删除

• 全局资源配额的分配（计算资源、存储空间）

• 平台级别的安全策略配置（SSO协议、加密策略）

第二级：租户级权限

租户管理员管理本租户内的所有配置：

• 用户的创建、角色分配、权限配置

• 数据连接、数据集、指标、仪表盘的管理权限

• 发布权限和分享策略的配置

第三级：用户级权限

终端用户在自身权限范围内的操作权限：

• 数据访问权限：可以查看哪些数据集和指标

• 数据操作权限：可以执行哪些操作（查看、编辑、发布、分享）

• 维度访问权限：可以查看哪些维度的数据（如区域经理只能查看本区域数据）

2.2 字段级权限控制

字段级权限是多租户BI权限治理的精细化工具——它控制用户可以访问数据集中的哪些字段：

场景示例

在CRM SaaS场景中，"客户表"包含客户名称、联系方式、信用评级等字段。不同角色的字段访问权限可能不同：

• 销售代表：可以查看客户名称和联系方式，不能查看信用评级

• 区域经理：可以查看客户名称、联系方式和信用评级

• 财务人员：可以查看所有字段

技术实现

字段级权限在语义层定义——每个字段关联一个"可见角色列表"。Agent在推理过程中只能访问当前用户角色权限范围内的字段，超出权限的字段不会出现在查询的SELECT列表中。

这一机制确保了：即使Agent生成了包含所有字段的查询请求，权限层也会在执行前自动过滤掉超出权限的字段。

2.3 行级动态过滤

行级过滤控制用户可以访问数据集中的哪些数据行——这是多租户BI权限治理的核心机制：

场景示例

在零售SaaS场景中，"订单表"包含所有门店的订单数据。不同角色的行级访问权限可能不同：

• 门店店长：只能查看本门店的订单数据

• 区域经理：只能查看本区域所有门店的订单数据

• 总部管理层：可以查看所有门店的订单数据

技术实现

行级过滤在查询生成阶段自动注入——Agent生成的SQL查询在执行前，权限层自动追加WHERE条件。过滤条件基于用户的角色和业务属性动态计算：

-- 门店店长的查询自动追加： WHERE store_id = ${user.store_id} -- 区域经理的查询自动追加： WHERE region_id = ${user.region_id} -- 总部管理层的查询不追加过滤条件

行级过滤的关键设计是"动态计算"——过滤条件不是硬编码的规则，而是基于用户上下文实时计算的。当用户的角色或业务属性发生变化时，过滤条件自动更新，无需手动修改权限配置。

2.4 SSO与权限映射

多租户SaaS场景下，BI平台的身份认证需要与ISV业务系统的身份体系无缝对接：

SSO单点登录

支持OAuth 2.0、SAML 2.0等主流SSO协议。用户在ISV业务系统登录后，访问BI功能时无需再次登录——SSO协议自动完成身份认证和会话建立。

角色映射

ISV业务系统的角色体系通过映射规则同步至BI平台：

角色映射支持动态更新——当ISV业务系统的角色配置发生变化时，BI平台的角色映射自动同步，无需手动维护两套权限体系。

三、租户管理的运维体系

3.1 租户生命周期管理

租户创建

ISV通过API或管理界面创建新租户，配置租户的基础参数：

• 租户名称和标识

• 数据连接配置（或使用ISV预置的数据连接模板）

• 资源配额（计算并发数、存储空间上限）

• 权限策略模板

租户创建后，系统自动初始化租户的数据空间——数据集模板、指标模板、仪表盘模板自动加载，租户管理员可以基于模板快速配置本租户的分析环境。

租户暂停与恢复

当SaaS客户的订阅到期或暂停时，ISV可以暂停对应租户的BI访问权限——租户的数据和配置保留，但用户无法访问BI功能。当客户续费后，恢复租户的访问权限，数据和配置完全恢复。

租户删除

当客户正式终止合同时，ISV可以删除对应租户——租户的所有数据、配置、审计日志被永久清除。删除操作前系统会生成数据备份供ISV存档。

3.2 资源配额管理

多租户BI平台的核心运维挑战是资源管理——当200+租户共享同一平台时，如何确保资源分配的公平性：

计算资源配额

每个租户可配置独立的计算资源配额：

• 查询并发数：同时执行的查询请求上限

• 查询时间上限：单个查询的最大执行时间

• 内存使用上限：查询过程中可使用的最大内存

计算资源配额的目的是防止单一租户的高频查询影响其他租户的响应时间。当租户的查询请求超过配额时，系统自动排队或拒绝，确保其他租户的查询不受影响。

存储资源配额

每个租户的数据存储空间可配置上限：

• 数据集存储空间：数据集定义和物化数据的大小上限

• 审计日志存储空间：操作审计日志的保留时间和大小上限

• 仪表盘存储空间：仪表盘配置和缓存数据的大小上限

3.3 租户级性能监控

系统提供租户级的性能监控仪表盘，ISV运维团队可以实时查看：

• 每个租户的查询QPS（每秒查询数）

• 每个租户的平均查询响应时间

• 每个租户的资源使用率（计算、存储）

• 每个租户的查询失败率和失败原因

基于监控数据，ISV可以及时发现性能瓶颈——如某租户的查询响应时间持续偏高，可能需要扩容该租户的资源配额或优化其数据模型。

四、多租户架构的安全合规

4.1 数据加密

传输加密

所有数据传输采用TLS 1.2+加密，确保数据在网络传输过程中不被窃取。租户的数据连接认证信息在传输过程中同样加密。

存储加密

租户的敏感数据（如数据连接密码、API密钥）在存储时采用AES-256加密。即使数据库被直接访问，攻击者也无法获取明文凭证。

4.2 审计合规

每个租户的操作审计日志独立存储，包含：

• 用户操作日志：每次查询、分析、发布操作的完整记录

• 管理操作日志：每次权限变更、配置修改的管理记录

• 数据访问日志：每次数据读取和写入的详细记录

审计日志支持按时间、用户、操作类型等多维度检索，满足金融、医疗等强监管行业的合规审查要求。

4.3 数据主权保障

对于有数据本地化要求的客户（如政务、军工行业），HENGSHI SENSE支持私有化部署——每个租户的数据完全存储在客户自有的服务器上，不经过任何云端中转。这一部署模式确保了数据的物理隔离和主权保障。

五、典型多租户架构场景

5.1 CRM SaaS的多租户BI

场景描述：CRM SaaS厂商为每个企业客户提供独立的CRM实例，每个实例需要嵌入数据分析功能。

衡石方案：

• 每个企业客户对应一个BI租户

• 租户的数据连接指向该客户的CRM数据库schema

• ISV预置标准仪表盘模板和指标模板，新租户创建时自动加载

• 租户管理员可基于模板进行个性化调整

实施效果：新客户接入BI功能的周期从2周降至2天——租户创建、模板加载、数据连接配置在1天内完成，第2天即可上线标准分析功能。

5.2 零售连锁的多层级BI

场景描述：零售连锁企业拥有总部-区域-门店三级管理架构，不同层级的用户需要不同粒度的数据分析。

衡石方案：

• 单一租户内的三级权限模型：总部管理层（全量数据）、区域经理（本区域数据）、门店店长（本门店数据）

• 行级动态过滤：基于用户的组织层级自动过滤数据范围

• 仪表盘分级配置：总部看板（全国汇总）、区域看板（区域对比）、门店看板（单店运营）

实施效果：三级管理架构下的数据权限完全自动化——用户无需手动选择数据范围，系统根据用户角色自动过滤。

六、多租户架构的实施建议

6.1 隔离策略的选择

建议SaaS厂商根据客户规模和行业要求选择合适的隔离策略——不追求"最高隔离"，而追求"够用且可控"。

6.2 权限体系的先行设计

在BI功能上线前，先完成权限体系的设计和测试：

• 梳理ISV业务系统的角色体系，设计角色映射规则

• 配置核心场景的行级过滤规则，验证过滤效果

• 测试字段级权限的覆盖范围，确保敏感字段的访问控制有效

权限体系的先行设计可以避免"上线后发现权限漏洞"的被动局面——在多租户场景中，权限漏洞的影响范围是全租户的，修复成本远高于事前设计。

6.3 监控体系的同步建设

多租户BI平台的监控体系应与功能同步上线，重点监控：

• 租户间的数据隔离有效性——是否有跨租户数据泄露的异常

• 租户级的性能指标——是否有租户的性能异常下降

• 资源使用率的均衡性——是否有租户的资源使用率过高影响其他租户

结语

多租户BI架构的核心挑战不是技术实现，而是安全边界的设计——在"灵活共享"与"严格隔离"之间找到平衡点。

衡石科技的三层数据隔离机制、三级权限模型、租户级资源管理体系，为SaaS厂商提供了一套成熟的多租户BI架构方案。这套方案的核心设计理念是：让ISV专注于业务逻辑，让衡石负责技术底座——ISV不需要投入大量研发资源自建多租户BI基础设施，只需要通过API配置和模板设计，即可为每个租户提供独立、安全、高性能的数据分析体验。

当SaaS客户问"我的数据会不会被其他租户看到"时，答案不是一个模糊的"不会"，而是一套完整的隔离机制——从数据连接到数据集、从指标定义到仪表盘配置、从字段级权限到行级过滤，每一个层面都有明确的隔离规则和技术保障。这才是多租户BI架构真正赢得客户信任的方式。