SaaS 多租户地区配置如何测试，避免设置串租户？ | 全球代理

串租户问题常出在缓存键或查询条件漏了租户维度，而不只是页面展示错误。地区配置的差异还会体现在套餐展示上，这类差异要单独判定，不能和租户串用混在一起。验证方法是准备两个合成租户，分别设不同的地区配置，再交叉访问页面、导出、搜索和 API，确认任何一条路径都拿不到对方的数据。通过标准要以产品的权限设计和地区策略为准，先写清 A 租户能看到什么、B 租户不能看到什么。验证时出口地区也是必须记录的变量，换了出口就要重新对照。

用两个合成租户验证地区配置隔离

至少建两个租户：A 租户设置地区一、语言一、套餐一；B 租户设置地区二、语言二、套餐二。差异要明显，否则串了也看不出来。若测试需覆盖多个地区，可先用代理 IP 产品页选定测试出口；租户隔离断言本身仍应针对 SaaS 权限与数据访问验证。

隔离断言写成可执行的句子：“用 A 的账号访问 B 的资源 ID，必须被拒绝，且响应不能泄漏该资源是否存在、内容是什么；具体返回 403、404 还是统一错误页，按产品的安全设计定，页面和 API 要一致”。判定要分对象：对明确属于 B 的详情资源，A 的访问必须符合产品约定的拒绝策略；对集合查询，返回 200 且只含 A 可见数据、或返回空集合，都可能是合法结果——空集合本身既不能证明越权，也不能证明查询漏了租户。是否越权看的是有没有读到、写到或推断出 B 的受保护信息，要结合授权中间件行为和查询日志核实，不能只凭响应体是空的就下结论。

检查配置和缓存键是否带租户维度

租户专属的地区配置必须按经过验证的租户上下文隔离：同一租户的不同地区可以分两级存，也可以各自独立存，但读写路径都要能拿到租户标识。“只按地区存”会让 A 改配置时 B 跟着变，这才是要测的失败模式，而不是必须采用某种表结构。独立库、独立缓存、行级过滤都是可行方案，测试断言只看结果：改 A 的配置，B 的配置和数据不受影响。

缓存同理。凡值或权限会随租户变化的响应，缓存键里必须带租户维度——页面缓存、接口缓存、CDN 缓存都属于这一类；各租户完全相同、无权限差异的公开数据可以用显式全局缓存，敏感响应也可以干脆禁用共享缓存。若多租户请求还共用代理连接池，应将并发、连接复用与租户隔离分开验证，可参考代理 IP 并发、QPS 和连接池规划。检查方法是在 A、B 之间交替请求同一路径，看返回是否跟着账号切换。

交叉访问页面和 API，确认跨租户访问被阻断

页面走一遍导航、列表、详情、设置页，重点是 URL 里带资源 ID 的详情页——把它换成另一个租户的 ID，看是否被拦住。

API 侧直接改请求里的租户字段或资源 ID。这一步比页面更容易暴露问题，因为很多系统的页面层做了校验，接口层没有。交叉验证全程固定一个出口地区；中途换代理 IP，串租户的判定就失去对照。地区配置本身要逐字段核对：租户、地区、语言、套餐各存一份，改一个租户不能牵动另一个。

覆盖导出、搜索和通知等旁路

主界面拦住了，不代表数据安全。导出任务、全局搜索、通知中心、Webhook、报表订阅，这些路径常常绕开统一的权限中间件。

检查导出文件和全局搜索是否带出他户数据

导出和搜索是最容易绕开权限中间件的两条批量取数路径。用 A 租户发起导出，看文件里是否出现 B 的行；A 搜索 B 的关键词，看是否命中对方数据。

检查通知和订阅是否带出其他租户数据

这三条路径由事件或订阅触发，不经过页面权限，日志往往也不在同一处。B 改配置后检查 A 收到的通知正文，顺带确认重试与去重不会把旧租户的数据带进来。

记录租户隔离的测试证据

证据要能回答三个问题：哪条路径、有没有租户维度、结果是否符合断言。只记“通过”没有价值，下一轮回归不知道该重测什么。

> 表格中的阈值、用例编号和结果如无测试记录支持，均应视为演示样例；实际验收标准以项目需求、历史基线或团队约定为准。

测试全程只用合成租户和合成数据，不碰真实客户记录。测试完成后清理合成租户，避免残留数据影响下一轮。

FAQ

合成租户能拿到生产验证吗？

不能。只限测试环境，生产侧用权限审计和日志核查替代。

跨租户返回 200 但数据为空，算通过吗？

不一定。空数据有三种可能：越权被安全过滤、查询本来就带租户但 A 没有数据、查询确实漏了租户。先看集合查询的语义和查询日志，再用详情资源直连 ID 验证；能读到 B 的受保护信息才算越权。

配置串了会报错吗？

不一定。常见表现是静默显示对方数据，优先查列表和导出。

测试完要清理哪些东西？

合成租户、导出文件、通知记录和缓存键，都要清干净。