多租户企业平台的租户隔离模式

一个 tenant_id 列是有用的，但它不是隔离策略。请求流经浏览器、API、服务、队列、缓存、对象存储、导出和支持工作流。每个边界都需要明确的租户身份以及关于什么可以跨越它的规则。

最安全的默认做法是从经过认证的成员关系和服务端路由中派生租户上下文——而非接受来自客户端的任意标识符。

共享表、独立模式和独立数据库提供不同的运维和隔离特性。正确的选择取决于规模、自定义需求、法规要求、噪声邻居风险、备份和恢复需求，以及运维能力。

混合模型很常见：大多数租户共享一个索引良好的模式，而选定的工作负载获得更强的物理隔离。应用程序应将该放置策略隐藏在稳定的仓储层或服务之后。

仅凭角色名称通常过于宽泛。授权应考虑组织、子账户、资源所有权、已启用的模块、请求的操作，有时还包括记录状态。

集中的策略辅助工具可以减少不一致性，但领域服务仍必须执行不变量。数据库行级安全可以在连接和上下文管理严格的情况下增加纵深防御。

每个任务都应携带不可变的租户和操作者上下文，在执行期间再次验证，并将输出写入租户范围内的位置。通用的缓存键、复用的临时目录和未限定范围的导出文件名可以绕过原本严格的 API 授权。

正向测试证明用户可以访问自己的数据。隔离测试证明标识符、过滤器、导出、Webhook、搜索和时序不能暴露其他租户的数据。

在集成测试中创建两个租户，系统性地尝试跨边界的读取和变更。包括工作进程、批量操作、管理工具和故障路径——而不仅仅是 HTTP 端点。