Article body
正文
Data Agent可以替用户查询数据、创建资源和触发动作，它继承了BI平台的全部安全问题，还增加了自动执行风险。多租户SaaS若只在聊天入口校验一次身份，后续工具调用很容易越过数据边界。
每次调用都携带租户与用户身份
Agent执行查询、读取指标或创建看板时，后端必须重新校验租户、用户和资源权限。系统不能把模型生成的SQL直接交给数据库，也不能相信前端传来的租户ID。查询服务应从受信身份上下文注入租户过滤和行级权限。
共享数据库可以降低运维成本，但要求所有读取路径都经过统一过滤器。独立数据库提供更强物理隔离，却增加升级、连接和跨租户运营成本。平台可以按客户等级组合两种模式，安全合同必须写清楚数据放在哪里、谁能访问、如何迁移。
三层权限覆盖应用、数据与功能
应用权限决定用户能进入哪个空间或门户，数据权限限制可见行与字段，功能权限控制能否建模、导出、发布或调用Agent工具。三层权限需要在同一决策点汇合。用户可以查看一个看板，不代表他可以导出明细；他可以问数，也不代表Agent可以替他修改指标定义。
敏感动作应使用最小权限工具。创建资源、扩大共享范围、跨系统写入和批量导出需要审批或二次确认。管理员还要设置全局禁用、黑名单和紧急回收通道，人员离职时可以立刻终止会话与Token。
SSO解决身份一致性
企业通常已经使用SAML、OAuth或OIDC身份系统。BI PaaS应复用企业IdP，并把组织、角色和租户映射到平台权限。嵌入场景还要处理宿主应用与BI组件之间的Token交换，避免用户重复登录。
会话安全包括过期、撤销、终端数量和异常登录检测。Agent的长任务不能依赖无限期Token，执行器需要在每个关键步骤检查授权状态。权限变化后，正在运行的任务也应停止或重新确认。
审计记录回答六个问题
完整日志要说明谁在什么租户、以什么目标、调用了哪个工具、读取或修改了什么、得到什么结果、是否经过审批。模型提示词和中间推理可以按合规要求裁剪，但工具参数、权限决策与资源变化必须可追踪。
安全团队还要定期回放高风险任务，检查越权尝试、重复执行和异常导出。Data Agent进入生产环境之前，先让它在只读范围运行，再逐步开放写工具。权限与审计成熟后，自动化范围才有扩展基础。
工程细节与实施补充
一、多租户架构：从概念到工程落地
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 租户生命周期管理
在HENGSHI SENSE中，租户的管理贯穿创建、授权、运营到回收的全生命周期。
1.3.1 租户创建与授权
从v5.1.2开始，平台支持在PaaS管理界面新建租户。每个租户拥有独立的创作空间和用户体系。v5.2.2对License管理进行了关键优化：简化了租户授权流程，管理员无需逐个配置，可以通过License批量授权多个租户，大幅降低了运营成本。
# 租户 License 配置示例
license:
type: paas
tenant_limit: 50 # 最大租户数量
tenants:
- id: tenant_hq
name: "集团总部"
user_limit: 500
features: ["advanced_analytics", "data_export", "api_access"]
expires_at: "2026-12-31"
- id: tenant_east
name: "华东分公司"
user_limit: 200
features: ["basic_analytics", "data_export"]
expires_at: "2026-06-30"1.3.2 创作空间隔离
v6.1.1引入了多租户隔离创作空间的增强能力，支持在分析能力嵌入模式下为不同租户提供独立的创作环境。同时支持隐藏“我的空间”并允许修改“团队空间”名称，使每个租户都可以定制符合自身组织习惯的空间命名。
租户创作空间配置流程：
1. 创建租户
└── 2. 配置空间策略
├── 隐藏"我的空间" (v6.1.1+)
├── 自定义"团队空间"名称 (v6.1.1+)
└── 3. 分配空间权限
├── 管理员：完全控制
├── 分析师：编辑/发布
└── 查看者：只读访问1.3.3 组织架构管理
v6.0.5对组织架构接口进行了增强，支持子节点移至根节点的操作，同时新增了批量接口支持。这使得企业在大规模组织架构调整（如部门拆分、合并）时，无需逐个手动操作。
// 组织架构批量操作示例
POST /api/organization/batch
{
"operations": [
{
"action": "move_to_root",
"node_id": "dept_1024",
"tenant_id": "tenant_east"
},
{
"action": "update",
"node_id": "dept_2048",
"name": "新业务线",
"parent_id": "dept_1024"
}
]
}1.3.4 License 加锁优化
在多租户高并发场景下，租户和用户的License校验可能产生锁竞争。v6.0.1对租户/用户License的加锁逻辑进行了重构，采用细粒度锁策略替代全局锁，有效避免了死锁问题。
重构前（全局锁）：
acquire(global_license_lock)
→ 校验租户 License
→ 校验用户 License
release(global_license_lock)
⚠️ 高并发下死锁风险
重构后（细粒度锁）：
acquire(tenant_license_lock[tenant_id]) # 租户级锁
→ 校验租户 License
release(tenant_license_lock[tenant_id])
acquire(user_license_lock[user_id]) # 用户级锁
→ 校验用户 License
release(user_license_lock[user_id])
✅ 锁粒度细化，死锁风险消除二、权限模型：从粗放到精细的三层权限体系
2.1 权限模型演进
HENGSHI SENSE的权限模型经历了从简单角色控制到三维权限体系的演进。v6.1.0是一个关键里程碑版本，实现了统一平台资源权限管理：将应用权限、数据权限和功能权限集中管控，形成了完整的权限治理框架。
权限模型演进时间线：
v5.1.x ─── 基础角色权限 + 连接行权限
│
v5.2.8 ─── 全局严格权限检查 + 数据继承审核
│
v6.1.0 ─── 统一资源权限管理（应用/数据/功能三维）
│
v6.1.5 ─── 角色合并优化（指标分析角色与数据查看角色合并）2.2 三维权限体系详解
v6.1.0的统一权限模型将权限分为三个正交维度：
这种三维模型的优势在于：一个用户可能拥有查看某应用（应用权限）的资格，但不一定有访问该应用底层数据源（数据权限）的权限，也不一定有导出（功能权限）的权限。三者独立控制，灵活组合。
2.3 连接行权限与租户级授权
v5.1.2引入了连接行权限支持授权给租户的能力，使数据行级安全（Row-Level Security，RLS）可以按租户维度进行配置。
-- 行权限配置示例：不同租户看到不同数据范围
-- 假设 sales_table 包含字段 region, amount, product
-- 租户 A（华东）只能看到华东区域数据
-- 配置方式（API）
PUT /api/permissions/row-level
{
"connection_id": "conn_sales",
"table": "sales_table",
"tenant_id": "tenant_east",
"rule": {
"type": "filter",
"expression": "region = '华东'"
}
}2.4 维度去重模型与权限过滤器
v6.1.0引入了维度去重模型在过滤器双向场景中的使用。在复杂的权限过滤场景中，当用户的多条权限规则可能产生交集或冲突时，维度去重模型确保过滤结果的一致性和正确性。
权限过滤器双向场景示例：
用户 U 同时拥有：
规则1：部门 = "销售部" → 可看销售额、客户数
规则2：角色 = "区域经理" → 可看区域汇总数据
维度去重模型处理：
┌─────────────────────────────────────────┐
│ 数据查询请求 │
│ SELECT region, SUM(amount) FROM sales │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 权限过滤器引擎 │
│ ├─ 正向：过滤数据 → 应用维度去重 │
│ └─ 反向：过滤指标 → 应用维度去重 │
└──────────────┬──────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 输出：去重后的安全数据集 │
└─────────────────────────────────────────┘三、认证体系：企业级 SSO 集成实践
3.1 为什么 BI PaaS 需要统一认证？
在多租户场景下，每个租户可能使用不同的身份认证系统：集团总部用LDAP，分公司用钉钉，外部客户用自建SSO。BI PaaS需要与这些异构认证系统无缝对接，同时提供统一的会话管理和安全管控。
3.2 SSO 集成矩阵
HENGSHI SENSE从v5.1到v6.2累计支持了多种企业级SSO协议：
3.3 统一 Access Token 管理
v6.0.0是认证体系的重大升级版本：将飞书、钉钉、企业微信的access token统一纳入管理框架。此前，各平台的token刷新逻辑相互独立，导致代码冗余和维护困难。统一管理框架的架构如下：
┌──────────────────────────────────────────────────────────┐
│ SSO 统一认证网关 (v6.0.0+) │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 飞书 │ │ 钉钉 │ │ 企业微信 │ │
│ │ OAuth │ │ OAuth │ │ OAuth │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 统一 Token 管理器 │ │
│ │ ┌─────────────┐ ┌─────────────────────────┐ │ │
│ │ │ Token 存储 │ │ Token 自动刷新引擎 │ │ │
│ │ │ (Redis) │ │ - 定时检查过期 │ │ │
│ │ │ │ │ - 异步刷新 │ │ │
│ │ │ │ │ - 刷新失败重试 │ │ │
│ │ └─────────────┘ └─────────────────────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 会话管理 (Session Manager) │ │
│ │ - 统一会话创建 │ │
│ │ - 跨平台会话映射 │ │
│ │ - 会话过期与续期 │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘3.4 租户定制域名 SSO
v5.3.4支持为不同租户配置独立的SSO认证域名。这一功能在多租户嵌入场景中尤为关键：当BI能力以iframe方式嵌入到不同租户的系统中时，每个租户需要通过自己的域名完成SSO登录，而不会暴露其他租户的认证入口。
# Nginx 配置示例：租户定制域名
server {
listen 443 ssl;
server_name bi.tenant-a.com; # 租户 A 的专属域名
location / {
proxy_pass http://hengshi-sense:8080;
proxy_set_header Host $host;
proxy_set_header X-Tenant-Id tenant_a;
proxy_set_header X-SSO-Domain bi.tenant-a.com;
}
}
server {
listen 443 ssl;
server_name bi.tenant-b.com; # 租户 B 的专属域名
location / {
proxy_pass http://hengshi-sense:8080;
proxy_set_header Host $host;
proxy_set_header X-Tenant-Id tenant_b;
proxy_set_header X-SSO-Domain bi.tenant-b.com;
}
}3.5 SSO 默认角色配置
v6.2新增了SSO配置中指定用户默认角色的能力。当新用户首次通过SSO登录时，系统会自动为其分配预配置的默认角色，无需管理员手动干预。这在人员流动频繁的大型企业中极大降低了账号管理成本。
# SSO 默认角色配置示例
sso:
provider: authing
config:
saml_endpoint: "https://xxx.authing.cn/saml"
default_role: "analyst" # SSO 登录用户默认角色 (v6.2+)
default_tenant: "tenant_hq" # 默认归属租户
auto_create_user: true # 自动创建用户
role_mapping: # 可选：按属性映射角色
- attribute: "department"
value: "IT"
role: "admin"
- attribute: "department"
value: "Sales"
role: "analyst"3.6 Authing.cn SAML 2.0 集成详解
Authing.cn是国内领先的身份即服务（IDaaS）平台。v5.1.10集成的SAML 2.0协议认证流程如下：
SAML 2.0 认证流程：
用户 HENGSHI SENSE Authing IdP
│ │ │
│── 1. 访问BI页面 ──────→ │ │
│ │ │
│── 2. 重定向到IdP ─────────────────────────────────→ │
│ (SAML AuthnRequest) │
│ │ │
│ │ 3. 用户在Authing登录 │
│──────────────────────────────────────────────────→ │
│ │ │
│ │ 4. 返回SAML Response │
│←────────────────────────────────────────────────── │
│ (SAML Assertion) │
│ │ │
│── 5. 提交断言 ────────→ │ │
│ │ │
│ │ 6. 验证断言，创建会话 │
│←── 7. 返回BI页面 ───────│ │
│ (已认证) │四、架构设计的关键决策与权衡
4.1 共享数据库 vs 数据库隔离
方案对比：
┌──────────────────────────────────────────────────────┐
│ 方案A：共享数据库（HENGSHI SENSE 采用） │
│ ┌──────────────────────────────────────────────┐ │
│ │ PostgreSQL / ClickHouse │ │
│ │ ┌─────────┬─────────┬─────────┐ │ │
│ │ │ 租户A │ 租户B │ 租户C │ │ │
│ │ │ 数据 │ 数据 │ 数据 │ │ │
│ │ └─────────┴─────────┴─────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ 优势：成本低、运维简单、资源利用率高 │
│ 挑战：需要严格的行级隔离和权限控制 │
├──────────────────────────────────────────────────────┤
│ 方案B：每租户独立数据库 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 租户A DB │ │ 租户B DB │ │ 租户C DB │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ 优势：天然隔离、安全等级最高 │
│ 挑战：成本高、运维复杂、跨租户查询困难 │
└──────────────────────────────────────────────────────┘HENGSHI SENSE选择了共享数据库方案，通过在查询层面注入租户过滤条件实现逻辑隔离。这一选择在性能和成本之间取得了最佳平衡，同时也对权限系统提出了更高的要求：所有SQL查询都必须经过租户过滤器的改写。
4.2 认证协议选型
4.3 安全与体验的平衡
安全策略越严格，用户体验往往越差。HENGSHI SENSE在设计时注重二者的平衡：
- Active Cookie限制终端数量，但支持管理员手动清除异常会话，而非直接锁定账号
- 登录失败锁定使用指数退避策略，而非一次性长时间锁定
- 水印按应用维度配置，而非全局强制开启
- 行权限在后台自动生效，用户无需感知
五、最佳实践总结
基于HENGSHI SENSE多版本迭代积累的工程经验，以下是企业级BI PaaS多租户安全治理的最佳实践。
5.1 租户管理
- 按业务维度划分租户，而非按技术维度。例如按“华东分公司”“华北分公司”划分，而非按“前端组”“后端组”划分
- 合理配置License上限，为未来扩展预留空间
- 定期审计租户活跃度，回收闲置租户释放资源
5.2 权限管理
- 遵循最小权限原则，默认分配最低权限角色
- 利用三维权限模型，分别管控应用/数据/功能权限
- 定期审查角色配置，合并冗余角色（参考v6.1.5的角色合并实践）
- 启用严格权限检查模式（v5.2.8+），确保无权限旁路
5.3 认证管理
- 优先选择企业已有IdP，避免在BI平台内维护独立的用户密码体系
- 配置SSO默认角色（v6.2+），降低新用户入职成本
- 使用租户定制域名SSO，在嵌入场景中提供统一的认证体验
5.4 安全运营
- 配置登录失败锁定策略，防范暴力破解
- 合理设置Active Cookie终端数量，平衡安全与便利
- 对敏感应用启用水印，数据脱敏与水印防泄漏双管齐下
- 动态管理CORS策略，按需开放API跨域访问
资料与核验说明
内部资料用于梳理衡石能力与工程方法；竞品和版本信息按2026年8月26日可访问的官方页面复核。产品功能会受版本、地区、授权和部署模式影响，正式采购与发布前应再做一次现场确认。
延伸阅读：HENGSHI SENSE产品与技术白皮书。