多租户验收：九项控制、四张表与越权演练

客户要的不是三百字，是能查的证据。

一、三百字换来一句「请提供证据」

客户的安全问卷只有一页，最后一行问：「你们怎么保证我看不到别家的数据？」他写了三百字，从数据库行级隔离讲到对象存储前缀，自认为答得很完整。两天后对方回了一封很短的邮件：请提供证据。

他翻遍了自己的文档，发现能拿出来的只有一段架构描述和几张截图。没有越权测试报告，没有审计日志样例，也没有任何一个可以复现的检查脚本。也就是说，他的回答在逻辑上成立，在证据上为零。

安全问卷考的不是解释能力，而是举证能力。 一个能说清架构的团队，和一个能拿出证据的团队，中间隔着一整套可重复的检查流程。

这套流程的难点不在写测试，而在于把「我们做了什么」变成「你们可以随时来查什么」。前者是叙述，后者是控制项、证据和频率的组合。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

所以验收要解决的是同一个问题的两面：对内，它告诉你哪一块还没做完；对外，它让你在被问到时能直接指向一份材料，而不是重新组织语言。

本文把验收拆成九项控制、四张表和一个加权分数，目的是让「我们的多租户做得怎么样」这句话有一个可复算的答案。

二、九项控制与它们各自的证据

每一项控制都必须绑定一件可以拿出来的东西，否则它就只是口号。

九项里最容易变成空话的是第三项和第五项。 角色矩阵常常只写在文档里，从未和代码里的判断对齐；数据隔离常常只测了列表接口，漏掉了导出和批量操作。

三层校验的意思是同一个判断要在三个地方各做一次：路由层挡住不属于本组织的路径，服务层校验当前身份对该资源是否有动作权限，数据层在查询里强制带上租户条件。任何一层单独存在都不够，因为绕过的方式总在层与层之间。

数据隔离的证据不是「我们用了行级安全」，而是「我们尝试了 N 条跨租户访问，全部失败」。前者是设计，后者是结果，客户问的是结果。

席位一致的证据是一次对账：计费系统里的席位数，与成员表里处于激活状态的人数，差额必须能逐条解释。差额解释不了，就说明有人在白用或者有人在白付。

所有权冗余的证据是一段查询输出，列出 Owner 数量为 1 的组织。这段输出每个月都应该重跑，因为人员流动会让它变化。

越权演练是唯一一项既能对内发现问题、又能对外提供证据的控制，所以它值得单独占一个季度节奏。

三、四张表与四维加权

九项控制最终要落到四张可以交给别人看的表上，再由四个维度给出一个总分。

四张表的价值在于它们能互相印证。 租户清单表说某个组织有 5 个工作区，成员生命周期表就应该能解释这 5 个工作区各自的成员从哪来、为什么还在。

模型维度拿 4 分，是因为组织与工作区的两层结构清晰，但缺一个「工作区之间是否允许共享资源」的明确规则。

权限维度只有 3 分，是因为矩阵只覆盖了单条记录的读写，批量接口和导出接口仍靠服务层自觉。

隔离维度拿满 5 分，是因为跨租户测试全部失败，且失败是可复现的，不依赖某个人的记忆。

审计维度 4 分，是因为日志齐全但检索体验差，客户来查一次要人工翻半小时。

四个维度的权重不是平均分的变体，而是按「出错后多难补救」排的：权限和隔离各占 0.30，因为它们一出错就是数据泄露；模型占 0.25，因为它影响后续所有扩展；审计占 0.15，因为它是事后追责而不是事前阻断。

四、把分数算一遍

加权分数只有能复算才有意义。

综合得分 = 0.25×4 + 0.30×3 + 0.30×5 + 0.15×4
         = 1.00 + 0.90 + 1.50 + 0.60
         = 4.00
分级：≥4.5 稳；3.5–4.4 可用；<3.5 整改
本例：4.00 → 可用，短板在权限（3 分）
下季度只做一件事：27 条越权用例补齐批量接口 → 权限 4 分
新综合 = 0.25×4 + 0.30×4 + 0.30×5 + 0.15×4 = 4.30
演练成本：27 条整轮约 25 分钟（脚本化）
年度：4 个季度 × 25 分钟 = 100 分钟 ≈ 1.7 小时

4.00 落在「可用」而不是「稳」，这个结论比分数本身更重要。 它意味着现在可以接客户的安全问卷，但不能对外宣称「已经做到最好」。

把权限从 3 提到 4，综合分到 4.30，仍在「可用」区间，但离 4.5 只差 0.2。这 0.2 的差距恰恰说明：单点改进解决不了结构问题，要进「稳」还得把审计的检索体验一起补上。

只做一件事的选择也有依据。27 条越权用例覆盖的是批量接口、导出接口、跨工作区引用这三类最容易漏的路径，它们同时影响权限和隔离两个维度，性价比最高。

演练成本看起来很低，是因为脚本化了。27 条用例整轮约 25 分钟，四个季度合计 100 分钟，约 1.7 小时。这个量级任何团队都承担得起，真正难的是把它排进季度计划并坚持执行。

如果按人工点击估算，27 条至少要半天。所以「低成本」这个结论有个前提：用例必须是脚本，而不是一份需要人照着点的清单。

五、行动清单与复算验收

把九项控制、四张表和一次演练压成八条可执行的动作。

• 建立租户清单表，字段至少含组织、工作区、数据量、Owner 数
• 建立成员生命周期表，覆盖邀请到删除的五个状态
• 把角色权限矩阵与代码里的判断逐条对齐
• 为路由、服务、数据三层各写一条越权用例
• 跑一次跨租户测试，确认列表、导出、批量三类接口全部失败
• 导出一次审计日志检索结果，记录耗时
• 对账计费席位与活跃成员，逐条解释差额
• 每季度执行 27 条越权用例，把缺陷写进闭环清单

验收标准：能用九项控制与四张表完整回答一次客户安全问卷，且每个答案都能指向一份可复现的材料；做不到，说明验收还停留在叙述层面。

使用边界与实操验收

这套验收假设你已经有审计日志和至少一条自动化测试链路，两者都缺时先补基础设施。

加权分数是沟通工具，不是质量证明。 它能把「哪里弱」说清楚，但不能替代对具体接口的实际测试。

权重的设定带有主观性。如果你的产品处理的是支付或医疗数据，隔离的权重应该更高；如果是内部协作工具，模型的权重可以上调。权重变了，历史分数就不可比，需要在表里标注口径版本。

四张表也有维护成本。租户清单表每月要重跑，成员生命周期表要保证状态机没有旁路，角色权限矩阵每次改权限都要同步。任何一张表停止更新，整套验收就会退化成一次性的文档。

最后要提醒的是：客户真正在意的往往不是分数，而是「你能不能在被追问时立刻拿出一份东西」。分数是给自己的，材料才是给客户的。

关键参考与核验范围

核验日期：2026-10-25。以下链接用于核对 SLO、访问控制与日志管理的一般性原则，本文未逐条引用其内容。

• Google SRE Workbook — Implementing SLOs ：用于核对以指标和证据驱动验收的思路
• OWASP ASVS — V4 Access Control ：用于核对角色矩阵与越权测试的分级要求
• NIST SP 800-92: Guide to Computer Security Log Management ：用于核对审计日志的留存与检索要求

引用口径。 上文所有数字来自本系列的统一基线（120 个付费账户、344 个登录账号、24 个工作区），分数与分级阈值是本系列自定的演示口径，不代表任何行业标准。

核验范围。 已核对的是概念与术语，未核对任何具体产品的问卷模板与评分细则。

如何自行复核。 用自己的四张表跑一遍本文的加权公式，再随机挑三条越权用例实际执行，看结果是否与表里记录一致。

系列导航

• 上一篇：交接与合并：转所有权、并组织与最后一位管理员
• 下一篇：无，本系列共十篇到此结束
• 回到目录：一个人的多租户：组织、邀请、角色与数据隔离
• 相关阅读：运维验收：十项控制、四张表与月度巡检