多租户系统数据隔离检查：用 RLS…

在构建或审查多租户应用时，通过 PostgreSQL 行级安全、应用层租户上下文、自动化隔离测试和定期审计来确保租户数据完全隔离。

适用场景

解决思路

1. 在 PostgreSQL 中为所有表启用行级安全：ALTER TABLE <table> ENABLE ROW LEVEL SECURITY。
2. 为每张表创建租户隔离策略：CREATE POLICY tenant_isolation_policy ON <table> USING (tenant_id = current_setting('app.tenant_id')::INTEGER)。
3. 强制对表所有者同样应用 RLS：ALTER TABLE <table> FORCE ROW LEVEL SECURITY。
4. 在应用层实现 TenantContext 类，通过 prisma.$executeRaw 执行 SET LOCAL app.tenant_id = <tenantId> 设置租户上下文。
5. 提供 withTenant 方法，在 prisma.$transaction 事务内设置租户上下文并执行回调，确保查询自动被 RLS 过滤。
6. 在 API 路由中从 req.user.tenantId 获取租户 ID，并通过 tenantContext.withTenant 包裹所有数据库查询。
7. 按清单核查数据库层：所有表含 tenant_id 列、tenant_id 非空、外键包含 tenant_id 检查、所有表启用 RLS、创建 RLS 策略、对所有者强制 RLS、复合索引包含 tenant_id。
8. 按清单核查应用层：每个请求设置租户上下文、从 JWT/session 验证租户 ID、无未带租户过滤的裸 SQL、所有查询包含 tenant_id（若无 RLS）、API 端点验证租户访问、文件上传限定租户、后台任务包含租户上下文。
9. 按清单核查测试：跨租户查询测试、RLS 绕过尝试测试、带租户绕过的 SQL 注入测试、自动化回归测试、定期安全审计。
10. 编写自动化隔离测试：创建两个测试租户及各自用户数据，设置租户上下文后查询，断言只能看到本租户数据、看不到其他租户数据。
11. 测试跨租户更新：设置租户 1 上下文后查询租户 2 用户应返回 null。
12. 测试跨租户删除：设置租户 1 上下文后删除租户 2 用户应影响 0 行，并验证该用户仍存在。
13. 测试事务回滚：在事务中创建用户后抛错，验证回滚后该用户不存在。
14. 编写 RLS 审计脚本：查询 pg_tables 获取所有 public 表（排除 _prisma_migrations），逐表检查是否含 tenant_id 列、是否启用 RLS、是否强制 RLS、是否存在策略，并输出 ✅/⚠️/❌ 状态。
15. 创建复合索引且 tenant_id 放在首位，如 CREATE INDEX idx_orders_tenant_user ON orders(tenant_id, user_id)，确保按租户过滤的查询走索引。
16. 实现 Prisma 中间件自动注入 tenant_id：对 findMany/findFirst 在 where 中注入 tenantId，对 create 在 data 中注入 tenantId，对 createMany 为数组每项注入 tenantId。
17. 编写安全回归测试：验证 SQL 注入输入（如 "1 OR 1=1 --"）被安全参数化后返回空结果，不会绕过租户。
18. 编写安全回归测试：验证 API 错误消息不泄露 tenant_id 或 tenantId 等租户信息。
19. 遵循最佳实践：始终使用 RLS 而非仅依赖应用逻辑、对表所有者强制 RLS、充分自动化测试跨租户访问、每月审计 RLS 配置、所有索引以 tenant_id 开头、验证用户属于该租户、记录跨租户访问尝试。
20. 按输出清单确认：所有表启用 RLS、创建 RLS 策略、租户上下文中间件、自动化安全测试、RLS 审计脚本、复合索引、跨租户访问防护测试、安全回归测试套件。

适用边界 · 注意事项

• 不使用 PostgreSQL 或所用数据库不支持行级安全（RLS）时，本技能的 RLS 部分不适用。
• 单租户应用或无需数据隔离的场景不适用。
• 未使用 Prisma 作为 ORM 时，Prisma 中间件与 TenantContext 示例需改写为对应数据访问层实现。