多租户SaaS最怕什么？不是功能少，而是不同客户的数据串了

多租户SaaS的价值，是让多家企业共享一套平台能力，同时保证每家企业只看到属于自己的数据。页面做得少一点通常只是产品问题，租户数据串了则可能直接变成安全事故。

tenant_id不是加一个字段就结束

常见设计会在业务数据中保存tenant_id，用来标记数据属于哪个企业。

但真正的隔离要求每一次查询、新增、修改和删除都带上正确租户上下文。如果某个接口忘了过滤tenant_id，就可能直接读取其他客户的数据。

权限校验应该尽量靠近数据层

只依赖前端隐藏按钮是不安全的。

后端接口必须重新验证当前用户属于哪个租户、拥有什么角色，并限制能够操作的数据范围。

对于适合的数据库，还可以在数据库层增加Row Level Security作为额外防线。

PostgreSQL RLS能做什么

PostgreSQL官方Row Security Policies允许针对SELECT、INSERT、UPDATE和DELETE定义行级规则。

启用RLS后，可以通过策略决定某个角色能够看到或修改哪些行。如果启用了Row Level Security却没有可用策略，普通访问会采用default-deny。

这类机制可以减少“某个业务查询忘写租户条件”造成的数据越权风险，但仍不能替代完整应用权限设计。

注意绕过RLS的高权限账号

PostgreSQL文档也特别说明，超级用户、具有BYPASSRLS权限的角色以及通常情况下的表Owner，可能绕过普通RLS策略。

所以生产业务程序不应该日常使用超级数据库账号，更不能因为已经配置RLS就认为所有访问天然安全。

缓存也是租户隔离的一部分

即使数据库查询正确，如果Redis Key、页面缓存或查询缓存没有包含tenant_id，也可能把A公司的结果返回给B公司。

缓存键设计必须与租户边界一致，缓存清理也要避免跨租户误删或污染。

文件和对象存储同样会串

合同、图片、Excel、导出文件和附件如果只靠一个可猜测URL访问，也可能越权。

文件访问应该绑定租户和业务权限，必要时使用短时签名URL，而不是把长期公开链接直接暴露出去。

超级管理员尤其危险

运营后台经常需要跨租户查看数据。

这种能力应单独授权、记录审计日志，并尽量采用“主动选择进入某租户”的操作模式，避免管理员在错误上下文修改另一家客户的数据。

怎么测试租户隔离

准备至少两个测试租户，用A账号尝试读取、修改、删除B租户的ID；测试列表、详情、导出、搜索、附件、缓存、批量接口和后台任务。

真正有效的安全测试不是确认正常流程能用，而是主动尝试跨边界访问。

资料依据

PostgreSQL官方文档《Row Security Policies》与《CREATE POLICY》说明了RLS的启用方式、默认拒绝行为、USING/WITH CHECK以及部分高权限角色的绕过行为。

结论

多租户SaaS的租户隔离应该贯穿身份、API、数据库、缓存、文件和运营后台。tenant_id只是起点，不是完整安全方案。