Article body
正文
一、多租户架构：从概念到工程落地
1.1 什么是多租户？为什么 BI PaaS 必须多租户？
多租户（Multi-Tenancy）是 SaaS/PaaS 架构的核心设计模式之一，指在单一软件实例中为多个租户（组织/企业/部门）提供服务，同时保证租户间的数据与逻辑隔离。对于 BI PaaS 场景，多租户的价值体现在：
| 维度 | 单租户模式 | 多租户模式 |
|---|---|---|
| 部署成本 | 每个组织独立实例，运维成本线性增长 | 共享基础设施，边际成本趋近于零 |
| 数据隔离 | 天然隔离 | 需要架构层面的隔离保障 |
| 版本管理 | 各实例版本碎片化 | 统一升级，功能一致性高 |
| 资源利用率 | 各实例负载不均 | 动态调度，资源利用率最优 |
HENGSHI SENSE 的多租户能力从 v5.1.2 正式引入租户创建功能开始，到 v6.2 已形成完整的租户生命周期管理链条。
1.2 HENGSHI SENSE 多租户架构总览
┌──────────────────────────────────────────────────────────────────┐
│ HENGSHI SENSE BI PaaS │
├──────────────────────────────────────────────────────────────────┤
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 租户 A │ │ 租户 B │ │ 租户 C │ ... │
│ │ (集团总部) │ │ (华东分公司)│ │ (外部客户) │ │
│ ├─────────────┤ ├─────────────┤ ├─────────────┤ │
│ │ 创作空间 A │ │ 创作空间 B │ │ 创作空间 C │ │
│ │ 用户组 A │ │ 用户组 B │ │ 用户组 C │ │
│ │ 数据源 A │ │ 数据源 B │ │ 数据源 C │ │
│ │ 应用 A │ │ 应用 B │ │ 应用 C │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
├─────────┴────────────────┴────────────────┴─────────────────────┤
│ 租户隔离层 (Tenant Isolation) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 数据隔离 │ 权限隔离 │ 认证隔离 │ 配置隔离 │ │
│ └────────────────────────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────────┤
│ 统一基础设施 (Shared Infrastructure) │
│ License 管理 │ SSO 认证中心 │ 安全策略 │ 审计日志 │
└──────────────────────────────────────────────────────────────────┘1.3 租户生命周期管理
1.3.1 租户创建与授权
从 v5.1.2 开始，平台支持在 PaaS 管理界面新建租户。每个租户拥有独立的创作空间和用户体系。v5.2.2 对 License 管理进行了关键优化——简化了租户授权流程，管理员无需逐个配置，可以通过 License 批量授权多个租户。
1.3.2 创作空间隔离
v6.1.1 引入了多租户隔离创作空间的增强能力，支持在分析能力嵌入模式下为不同租户提供独立的创作环境。同时支持隐藏”我的空间”并允许修改”团队空间”名称，使每个租户都可以定制符合自身组织习惯的空间命名。
1.3.3 组织架构管理
v6.0.5 对组织架构接口进行了增强，支持子节点移至根节点的操作，同时新增了批量接口支持。这使得企业在大规模组织架构调整（如部门拆分、合并）时，无需逐个手动操作。
1.3.4 License 加锁优化
在多租户高并发场景下，租户和用户的 License 校验可能产生锁竞争。v6.0.1 对租户/用户 License 的加锁逻辑进行了重构，采用细粒度锁策略替代全局锁，有效避免了死锁问题。
二、权限模型：从粗放到精细的三层权限体系
2.1 权限模型演进
HENGSHI SENSE 的权限模型经历了从简单角色控制到三维权限体系的演进。v6.1.0 是一个关键里程碑版本，实现了统一平台资源权限管理——将应用权限、数据权限和功能权限集中管控，形成了完整的权限治理框架。
2.2 三维权限体系详解
v6.1.0 的统一权限模型将权限分为三个正交维度：
| 权限维度 | 控制对象 | 示例 |
|---|---|---|
| 应用权限 | 仪表板、报告、应用模块 | 能否查看/编辑”销售分析”应用 |
| 数据权限 | 数据连接、数据表、字段级 | 能否访问”订单明细”表的”金额”字段 |
| 功能权限 | 系统功能入口 | 能否使用”数据导出”、“API 调用”功能 |
这种三维模型的优势在于：一个用户可能拥有查看某应用（应用权限）的资格，但不一定有访问该应用底层数据源（数据权限）的权限，也不一定有导出（功能权限）的权限。三者独立控制，灵活组合。
2.3 连接行权限与租户级授权
v5.1.2 引入了连接行权限支持授权给租户的能力，使数据行级安全（Row-Level Security, RLS）可以按租户维度进行配置。
2.4 维度去重模型与权限过滤器
v6.1.0 引入了维度去重模型在过滤器双向场景中的使用。在复杂的权限过滤场景中，当用户的多条权限规则可能产生交集或冲突时，维度去重模型确保过滤结果的一致性和正确性。
2.5 角色精简与权限配置简化
v6.1.5 将指标分析角色与数据查看角色合并，将原先分散在多个角色中的权限整合，减少了权限管理的复杂度。对于大型企业而言，角色数量过多往往意味着管理混乱和安全漏洞。角色合并是权限治理”做减法”的典型案例。
2.6 全局严格权限检查与黑名单机制
v5.2.8 引入了全局严格权限检查模式。在该模式下，所有数据访问请求都必须经过完整的权限校验链路，不依赖缓存或默认放行策略。配合数据继承审核机制，确保数据在层级传递过程中不出现权限越级。
v5.1.2 增加的用户组 ALL_USERS 黑名单功能，为平台管理员提供了一个快速通道——将特定用户加入 ALL_USERS 黑名单后，该用户将被禁止访问任何资源，无需逐个撤销权限。
三、认证体系：企业级 SSO 集成实践
3.1 为什么 BI PaaS 需要统一认证？
在多租户场景下，每个租户可能使用不同的身份认证系统——集团总部用 LDAP，分公司用钉钉，外部客户用自建 SSO。BI PaaS 需要与这些异构认证系统无缝对接，同时提供统一的会话管理和安全管控。
3.2 SSO 集成矩阵
| 认证方式 | 协议 | 引入版本 | 适用场景 |
|---|---|---|---|
| Authing.cn | SAML 2.0 | v5.1.10 | 国内企业统一身份管理 |
| Microsoft Teams | OAuth 2.0 | v5.4.10 | Microsoft 365 生态集成 |
| 租户定制域名 SSO | SAML/OIDC | v5.3.4 | 多租户独立认证域名 |
| 飞书 | OAuth 2.0 | v6.0.0 | 字节跳动生态企业 |
| 钉钉 | OAuth 2.0 | v6.0.0 | 阿里巴巴生态企业 |
| 企业微信 | OAuth 2.0 | v6.0.0 | 腾讯生态企业 |
| JWT 增强 | JWT | 多版本 | API 调用认证 |
3.3 统一 Access Token 管理
v6.0.0 是认证体系的重大升级版本——将飞书、钉钉、企业微信的 access token 统一纳入管理框架。此前，各平台的 token 刷新逻辑相互独立，导致代码冗余和维护困难。
3.4 租户定制域名 SSO
v5.3.4 支持为不同租户配置独立的 SSO 认证域名。这一功能在多租户嵌入场景中尤为关键——当 BI 能力以 iframe 方式嵌入到不同租户的系统中时，每个租户需要通过自己的域名完成 SSO 登录，而不会暴露其他租户的认证入口。
3.5 SSO 默认角色配置
v6.2 新增了 SSO 配置中指定用户默认角色的能力。当新用户首次通过 SSO 登录时，系统会自动为其分配预配置的默认角色，无需管理员手动干预。这在人员流动频繁的大型企业中极大降低了账号管理成本。
3.6 Authing.cn SAML 2.0 集成详解
Authing.cn 是国内领先的身份即服务（IDaaS）平台。v5.1.10 集成的 SAML 2.0 协议认证流程实现了与企业 IdP 的无缝对接。
四、安全特性：纵深防御体系
4.1 安全策略框架
HENGSHI SENSE 的安全策略遵循纵深防御（Defense in Depth）原则，从登录层、会话层、数据层到导出层提供多层保护：
┌─────────────────────────────────────────────────┐
│ 第一层：登录安全 │
│ - 登录失败锁定策略 │
│ - 多因素认证 (MFA) │
├─────────────────────────────────────────────────┤
│ 第二层：会话安全 │
│ - Active Cookie 活跃终端控制 │
│ - 会话超时管理 │
├─────────────────────────────────────────────────┤
│ 第三层：数据安全 │
│ - 行级权限 (RLS) │
│ - 水印防泄漏 │
│ - 敏感信息脱敏 │
├─────────────────────────────────────────────────┤
│ 第四层：传输与导出安全 │
│ - CORS 动态控制 │
│ - 导出水印 │
│ - WAF 兼容 │
└─────────────────────────────────────────────────┘4.2 登录安全策略
v5.3.10 引入的安全策略支持配置登录失败次数及禁止时长，有效防范暴力破解攻击。
4.3 Active Cookie 与终端控制
v5.1.12 引入的系统访问限制通过 active cookie 机制控制活跃终端数量。每个用户同时登录的设备数量受到限制，防止账号共享和异常会话。
4.4 水印与数据防泄漏
水印是数据防泄漏（DLP）的重要组成部分。HENGSHI SENSE 提供了多层水印保护：
- v5.3.7：导出文件支持全局自定义水印，对 PDF/Excel 导出文件添加水印
- v6.2：水印功能增强，支持按应用维度设置水印是否开启，并提供手机号中间四位隐藏功能
4.5 CORS 动态控制
v5.4.5 引入了 CORS header 动态生效机制，允许管理员在运行时调整跨域策略而无需重启服务。v6.0.6 进一步增加了 AI SDK 兼容项，确保 BI PaaS 的 API 可以被 AI 应用安全调用。
4.6 安全漏洞修复与 WAF 兼容
HENGSHI SENSE 在多个版本中持续修复安全漏洞，包括 XSS 防护、CSRF 令牌验证、SQL 注入防护等。v5.4.13 特别修复了 WAF（Web Application Firewall）误报导致的 404 问题。
五、数据隔离与 OEM 定制化
5.1 数据隔离机制
在多租户环境中，数据隔离是安全治理的底线。HENGSHI SENSE 通过以下机制实现数据隔离：
| 隔离层级 | 实现方式 | 版本 |
|---|---|---|
| 租户级隔离 | 租户 ID 作为数据分片键 | v5.1.2+ |
| 连接行权限 | 数据行级过滤规则 | v5.1.2+ |
| 空间隔离 | 独立创作空间 | v6.1.1+ |
| 应用隔离 | 模板市场 OEM 管理 | v6.1.2+ |
5.2 模板市场 OEM 管理
v6.1.2 引入的模板市场 OEM 管理能力，允许平台运营商为不同租户提供定制化的模板市场。每个租户看到的模板列表、模板品牌、模板预览图都可以独立配置，实现白标化交付。
5.3 看板发布与信息控制
v6.1.2 支持看板发布时的全局参数控制，允许管理员决定是否在看板发布页面上显示发布者信息。这一功能在匿名化展示或白标交付场景中非常实用。
5.4 多语言支持
国际化是企业级产品的基础能力。HENGSHI SENSE 构建了完整的多语言支持体系：
- v6.0.0：新增繁体中文支持
- v6.1.1：系统多语言包支持，允许租户加载自定义语言包
六、架构设计的关键决策与权衡
6.1 共享数据库 vs 数据库隔离
HENGSHI SENSE 选择了共享数据库方案，通过在查询层面注入租户过滤条件实现逻辑隔离。这一选择在性能和成本之间取得了最佳平衡，同时也对权限系统提出了更高的要求——所有 SQL 查询都必须经过租户过滤器的改写。
6.2 认证协议选型
| 协议 | 优势 | 劣势 | HENGSHI SENSE 使用场景 |
|---|---|---|---|
| SAML 2.0 | 企业标准，安全性高 | 配置复杂，XML 格式繁琐 | Authing.cn、企业 IdP |
| OAuth 2.0 | 流行度广，SDK 丰富 | 需要额外实现用户信息获取 | 飞书/钉钉/企微 |
| JWT | 无状态，适合 API | Token 不可撤销（需额外机制） | API 调用认证 |
6.3 安全与体验的平衡
安全策略越严格，用户体验往往越差。HENGSHI SENSE 在设计时注重二者的平衡：
- Active Cookie 限制终端数量，但支持管理员手动清除异常会话，而非直接锁定账号
- 登录失败锁定使用指数退避策略，而非一次性长时间锁定
- 水印按应用维度配置，而非全局强制开启
- 行权限在后台自动生效，用户无需感知
七、最佳实践总结
7.1 租户管理
- 按业务维度划分租户，而非按技术维度
- 合理配置 License 上限，为未来扩展预留空间
- 定期审计租户活跃度，回收闲置租户释放资源
7.2 权限管理
- 遵循最小权限原则，默认分配最低权限角色
- 利用三维权限模型，分别管控应用/数据/功能权限
- 定期审查角色配置，合并冗余角色
- 启用严格权限检查模式，确保无权限旁路
7.3 认证管理
- 优先选择企业已有 IdP，避免在 BI 平台内维护独立的用户密码体系
- 配置 SSO 默认角色，降低新用户入职成本
- 使用租户定制域名 SSO，在嵌入场景中提供统一的认证体验
7.4 安全运营
- 配置登录失败锁定策略，防范暴力破解
- 合理设置 Active Cookie 终端数量，平衡安全与便利
- 对敏感应用启用水印，数据脱敏与水印防泄漏双管齐下
- 动态管理 CORS 策略，按需开放 API 跨域访问
结语
多租户架构与安全治理不是一蹴而就的工程，而是在产品持续迭代中逐步完善的体系。HENGSHI SENSE 从 v5.1 到 v6.2 的演进历程清晰地展现了这一路径：从基础的租户创建，到统一权限模型，再到多维 SSO 集成和纵深安全防御，每一步都基于实际业务需求驱动。
对于正在构建或评估 BI PaaS 平台的企业而言，以下几点值得特别关注：
- 多租户不仅是功能，更是架构思维——需要在数据库设计、查询引擎、缓存层等各个技术栈层面贯彻租户隔离
- 权限模型要从”可用”进化到”好用”——三维权限体系、角色精简、默认角色配置都是在降低权限管理成本
- 安全不是单点方案，而是纵深体系——从登录到会话到数据到导出的全链路防护
- OEM 能力是 PaaS 商业化的基础——白标交付、定制域名、多语言支持决定了平台能否以 SaaS 模式规模化运营
本文基于 HENGSHI SENSE v5.1 至 v6.2 版本的公开技术文档与版本发布说明撰写。