集团或 SaaS 平台把分析能力提供给多个企业客户时，需要同时回答两个问题：不同租户能否在各自空间分析，平台分享的数据又会被哪些人看到。衡石的多租户能力从租户空间、资源分享和权限配置三个层面处理这一边界；安全结果取决于具体授权和验证，不能只看“已开启多租户”。

1 先划清平台与租户的责任

衡石产品手册将多租户描述为一个平台方服务多个企业客户的模式。启用该功能需相应授权；平台方创建并管理租户，租户管理员维护本租户的用户和分析空间。租户之间空间独立，平台方可以向租户分享连接、数据包和应用，分享方向是平台到租户。

平台把数据包或应用授权给“租户”，不代表租户内所有普通用户立即可见。租户管理员还需按角色和业务需要做二次授权。规划交付时，先列清平台管理员、租户管理员、租户分析者和只读用户各自需要访问的资源，再配置分享与授权，比笼统地说“租户隔离”更可执行。

以平台方把销售分析提供给不同供应商为例，平台先确定各供应商所在租户，向租户分享需要的数据包和应用，并配置对应的数据范围；供应商的租户管理员再决定采购、销售或管理人员各能看哪些内容。平台方不应借“统一运营”直接代替租户管理员管理其内部用户，租户自己的分析成果也不会因平台分享而自动回流。

资源所在空间也会影响能否分享。产品手册区分团队空间、公共空间与个人空间：并非任意个人创作的应用都可以直接分享给租户。实施前先确认资源是否已放在可分享位置，再核对租户侧收到的资源和后续授权。

2 数据边界由多层权限共同决定

用户能否看到数据，要同时检查身份和租户归属、数据连接权限、应用资源权限、应用的数据权限模式，以及数据集的行列权限。应用可以按应用作者、数据集作者或使用者等模式决定数据的使用身份；在适用模式下，管理员还能为数据集设置行权限和列权限。行权限限制记录范围，列权限限制字段可见性。

表 1 多租户分析的分层核对点

控制面	配置或管理对象	验收时的问题
租户空间	平台方与租户管理员	用户是否进入正确租户
资源分享	连接、数据包、应用	平台授权后谁还需二次授权
应用与数据权限	访问角色、数据权限模式	能否看到应用，使用谁的数据
行列权限	数据集规则	记录和字段范围是否正确
派生与公开入口	下游数据集、公开链接	身份裁剪是否仍有依据

行列权限需要具体到数据集与用户。比如两个区域负责人共用一张销售应用，行规则分别限定各自区域，列规则再隐藏不应展示的成本字段。手册说明，同一用户同一数据集的多条行规则之间取并集，行权限与列权限共同作用时取交集。配置时应通过实际账号预览结果，避免把“多条规则”误解成自动取最严格的交集。

权限来源也值得核对：用户可能通过个人授权、用户组、组织架构或系统角色获得访问权。只撤销一条授权后仍能看到应用，不一定是权限失效，也可能是另一条授权路径仍在生效。管理员可以在权限管理中按用户或租户查询资源授权及其来源。

这些规则有明确边界。产品手册指出，数据集上的行权限不会自动传递到由它关联生成的下游数据集；若下游仍需限制访问，应单独检查和配置。使用者模式依赖当前登录用户身份，因此不能把需要这种身份裁剪的应用直接改成公开链接。权限设计需要验证每一种实际访问路径，包括应用查看、派生数据集与导出。

一个容易遗漏的场景是“复制或派生以后还安全么”。A、B 两个数据集上的行规则不会因为创建了关联数据集 C，就自动变成 C 的规则；需要把 C 作为新的访问面检查。公开链接同样不能简单复用登录态下的验证结果：一旦访问者无需登录，依赖“使用者”身份裁剪数据的模式便失去前提。上线前应把这些路径列入权限评审。

3 认证集成不能替代资源授权

企业可按现有身份系统选择适配的登录与认证方式，但成功登录只证明身份被识别，不等于获得了连接、应用或数据包的访问权。嵌入式分析尤其要核对外部用户与衡石用户、租户的映射，以及登录后落在哪个租户空间。具体协议和配置应以目标版本手册及实施方案为准，避免把某个客户的 SSO 配置写成所有环境的默认架构。

4 用越权场景检验配置

验收时至少准备平台方、两个租户及租户内不同角色的测试账号。分别核对平台分享到租户后的可见范围、租户管理员的二次授权、同一数据集的行列过滤、派生数据集、公开链接与导出结果。每项测试都记录“应可见”和“应不可见”的具体资源，发生差异时回到权限来源与数据权限模式排查。

测试矩阵可以从同一份销售数据出发：平台管理员应看到配置范围，租户 A 的用户只能看到 A 获授权的数据，租户 B 的用户只能看到 B 的数据；同租户的不同角色再验证成本列、明细行和导出权限。除页面截图外，还应核对导出文件与派生数据集，因为只验证仪表盘画面不足以覆盖全部访问路径。

把越权检查写成可复用的验收用例，比只记录“页面正常”更容易复测。以下是测试记录格式示意，不是衡石权限配置文件。

case: 租户 A 的只读用户访问销售分析
identity: 租户 A / 只读用户
resource: 销售应用
expected_visible: 租户 A 已授权数据
expected_hidden: 租户 B 数据、受列权限限制的字段
paths: 页面、导出、派生数据集

发生越权疑虑时，先固定复现条件：账号、租户、应用、数据集、数据权限模式、行列规则和访问方式。随后检查权限来源与实际查询结果，必要时暂停有争议的分享或公开入口，再修订配置并复测。把“看不到”和“看到了不该看的”都作为可重复的用例，权限边界才会随业务扩张保持清楚。

场景案例：教育 SaaS 的跨学校课程分析

一家教育 SaaS 平台向学校 A 和学校 B 提供同一套课程运营看板。平台方分别向两个租户分享应用与所需数据包，各校租户管理员再为教务人员和管理人员授权。平台分享完成后，仍要检查每位使用者进入的租户、能够打开的应用以及实际可见的数据范围。

例如教务人员只需查看本校负责年级的课程记录，管理人员查看本校汇总；若有不应展示的字段，再按数据集配置列权限。设计时还要确认应用采用的数据权限模式。若看板引用了派生数据集，应把派生数据集作为新的访问面单独检查，不能假设上游行权限会自动传递。

验收使用两校及校内不同角色的测试账号，对同一看板分别检查页面、导出和派生数据集：学校 A 的账号不应看到学校 B 的记录，受限角色不应看到超出授权的年级或字段。记录每个账号的预期与实际结果，发现差异时回查分享、二次授权和权限来源。

衡石的多租户能力提供了独立空间和分层授权机制。真正可靠的数据边界，需要把租户分享、应用权限与数据权限作为同一套配置来设计，并在每条用户路径上验证。