SaaS 租户隔离：客户接入前测试什么

SaaS 租户隔离意味着客户只能访问其组织有权使用的记录和操作。界面中的租户选择器并不够。当请求、后台任务、缓存和文件下载进入底层系统时，边界仍需有效。

使用不同组织、普通用户角色及刻意跨越边界的尝试测试租户隔离。依据相同访问规则核实读取、写入、文件、缓存响应和后台工作。在接入具有敏感或商业重要记录的客户前，要求来自实际执行控制的后端边界的证据。

设想一个客户门户，各组织查看自己的采购订单。列表页面看似正确，但下载导出却包含其他组织的行。即使登录和普通页面路径按预期工作，这仍是隔离失败。

本指南帮助负责人界定验证和修复范围。它不主张某种数据库布局保证安全，也不主张检查表能替代完整应用评估。

选择存储前定义 SaaS 租户隔离

明确产品中租户的含义。可能是客户组织、法律实体或工作空间。记录用户如何加入、退出和切换租户，以及哪些支持角色可以跨租户操作。规则模糊会使测试模糊。

OWASP 多租户安全指南 描述跨数据库、缓存、存储和计算边界的隔离，也区分客户端提供的租户选择器与服务器核实的授权。评估产品实际请求路径时应使用这一区分。

明确数据归属。共享产品目录可能有意供多个客户查看，而订单备注归租户所有。测试需要知道区别，以识别泄露，同时不把刻意共享信息归为缺陷。

映射管理例外。如果支持员工能查看客户记录，说明谁授予访问、范围如何限定及使用如何记录。强大的支持路径应作为有意提供的能力测试，而不是隐藏在普通租户模型之外。

沿请求追踪租户上下文

从已认证用户开始，核实当前成员资格或服务授权。沿所选租户进入业务逻辑及数据访问。检查更改请求头、路由值或请求体，不能替换成另一组织的授权。

看似随机的标识符能让猜测更难，但不构成权限。OWASP 授权指南 建议检查每次请求的访问权。应使用从另一租户合法获得的标识符测试，而不是依赖测试者能否猜中。

对搜索、导出和其他 API 重复这一推理。首个详情页面正确，不能证明批量报告、移动端端点或旧兼容路径执行相同边界。

依据实际控制比较数据库方法

独立数据库、模式和共享表带来不同运维权衡。任何方式都不能免除凭据、角色、查询和管理路径验证。方案应明确边界在哪里执行，以及应用代码漏掉过滤条件时会发生什么。

不要把迁移到独立数据库当作每项缺陷的默认修复。有限授权错误可能适合针对性修复。同样，如果导出、任务和支持工具仍无限制访问，在一个控制器中加过滤条件并不够。

测试生产请求实际使用的角色

PostgreSQL 行安全文档 解释重要例外，包括特权角色和表所有权。产品依赖行策略时，使用实际受限请求角色验证。以数据库管理员执行的测试，不代表普通应用的边界。

将部署和迁移账户纳入清单。它们可能合法需要更广访问，但不应成为客户请求的日常身份。记录运行时如何取得预定授权，以及部署后如何检查该安排。

检查缓存、文件和派生输出

检查缓存键和缓存结果范围。不能仅因两次请求共享便利的路径或过滤器，就让某组织创建的缓存条目变成另一组织的答案。先由第一租户填充缓存，再测试第二租户。

文件需要自己的验收证据。核实上传归属、预览访问、下载和生成报告。页面可能正确拒绝访问，但附件 URL 仍可通过无关路径访问。在约定测试范围中纳入旧链接和此前发出的链接。

检查搜索索引、推荐和分析导出等派生数据。确认系统检索时而非仅插入时执行租户限制。即使源记录端点受保护，信息也可能通过摘要跨越边界。

使用归不同组织所有的受控测试数据。每组包含足够可辨识内容，以识别混杂，而无需将真实客户文档复制进评估。这样更容易诊断异常缓存命中或混合导出。

测试后台任务和成员资格变化

后台工作应通过队列将已验证租户上下文传递至操作。检查任务延迟、重试或由另一工作节点接收时会发生什么。Web 请求中有效的租户范围，不能证明后续任务保留它。

测试成员资格变化。按约定政策，从组织移除的用户不应通过缓存会话、保存导出或待执行操作继续保留普通访问。定义撤销前已接受工作的预定行为。

支持人员身份模拟和租户删除也值得刻意覆盖。说明操作员如何退出高权限会话，以及如何处理残留文件、任务和引用。正确删除政策取决于产品保留义务；评估应验证已选政策，而不是编造政策。

当前团队无法解释这些路径时，我们的软件项目接管指南 很相关。恢复部署、数据访问及运维文档的管理权，可能是让边界可维护的一部分。

明确有用的验证报告

要求发现展示行为者、租户、操作和观察到的影响。纳入相关请求和目标证据，并适当控制敏感值。只有“访问控制”标签而没有可重现路径的发现，很难修复和复测。

OWASP ASVS 可支持更广泛的应用安全要求。将租户专属验收矩阵与该工作一起保留，让审核者能看到测试了哪些组织、角色和资源类型。

区分确认缺陷与未测试路径。如果评估者无法检查私有存储服务或管理导出，要明确说明。诚实的范围限制，比没有依据地断言全部租户数据隔离更有用。

修复后，重复原故障案例和邻近合法案例。阻止全部下载的修复可能阻止泄露，却破坏产品。验收既需要拒绝未授权访问，也需要获准客户工作继续。

为产品实际边界编制预算

按资源类型、角色和操作路径界定评估，而不是只按页面数。如果外部文件、缓存、后台任务和支持访问能暴露租户数据，就应纳入。小门户的边界可能比界面所示更广。

要求 GBP 方案，并区分评估与修复。避免仅凭登录测试或自动扫描就接受通用保证。有价值的交付，是关于客户将依赖的访问边界的证据。

我们的应用安全服务 为这一范围提供起点。向我们提供产品租户模型和接入决策 ，讨论验证、针对性修复，以及开通下一客户账户前所需的证据。

常见问题

什么是 SaaS 租户隔离？ 它是对客户组织数据及允许操作的强制分离。边界需要跨应用请求、存储、缓存、文件和后台工作有效，包括产品定义的管理例外。

独立数据库保证隔离吗？ 不保证。凭据、路由、支持工具、导出和备份仍可能跨边界。独立数据库可作为设计的一部分，但实际访问路径需要测试。

随机记录标识符足够吗？ 不够。它能减少简单枚举，却不是权限检查。使用另一受控租户的真实标识符测试访问，并确认服务器拒绝。

除了拒绝，也应测试获准访问吗？ 应该。拒绝每项请求的修复可能掩盖产品损坏。确认普通用户保留预定操作，同时跨租户尝试被拒绝。

为什么缓存需要独立测试？ 它可能不重复原始数据访问路径就返回数据。由一个租户填充缓存，再在另一租户检查结果。确认缓存范围保留预定授权，而不是仅共享便利的键。

支持访问应如何工作？ 定义谁可以取得访问、范围、持续时间及动作记录方式。测试进入、使用和退出高权限上下文。设计应使例外明确且可审查。

使用行级安全怎么办？ 用应用实际请求角色测试，并纳入绕过普通控制器的操作。特权数据库角色和其他访问路径可能行为不同。行策略是需要验证的控制，而不是省略评估的理由。

供应商报价前应收到什么？ 租户和角色、资源类型、外部存储及后台操作的描述。明确可用于测试的环境和受控账户，以及评估必须支持的决策。