SQL多租户隔离设计方案_SQL共享模式权限配置

多租户SQL数据库隔离核心是数据可见性控制与操作权限边界划定，需在数据库层落实：通过tenant_id字段+行级安全策略（RLS）实现物理隔离，按租户分角色并遵循最小权限原则，连接池强绑定租户上下文，定期审计与脱敏测试保障安全。

多租户场景下，SQL数据库的隔离核心在于“数据可见性控制”和“操作权限边界划定”，不能只靠应用层过滤，必须在数据库层落实。共享模式（Shared Database, Shared Schema）成本低、运维简单，但权限配置稍有疏忽就容易越权访问。

租户标识字段 + 行级安全策略（RLS）

在每张业务表中增加 tenant_id 字段（非空、索引），作为租户隔离的物理锚点。启用数据库原生行级安全（如 PostgreSQL 的 RLS、SQL Server 的 Row-Level Security、MySQL 8.0+ 可用视图+DEFINER 模拟），为每个租户角色绑定策略，自动注入 WHERE tenant_id = current_tenant_id() 条件。

• PostgreSQL 示例：创建策略 CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.tenant_id'));
• 确保应用连接时通过 SET app.tenant_id = 't123'; 显式声明当前租户上下文
• 禁用超级用户直连生产库，避免绕过 RLS

按租户分角色 + 最小权限原则

不复用 public 角色或 db_owner 权限。为每个租户创建独立数据库角色（如 role_tenant_a），仅授予其所属租户数据的 SELECT/INSERT/UPDATE/DELETE 权限，且限制在带 tenant_id 过滤的视图或表上。

• 禁止跨租户 GRANT（如 GRANT SELECT ON orders TO role_tenant_b;）
• 敏感操作（如 DROP TABLE、TRUNCATE、EXECUTE PROCEDURE）一律拒绝，除非经审批开通临时会话级权限
• 使用视图封装逻辑：如 CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = current_tenant_id();，再对视图授权

连接池与会话变量强绑定

租户身份不能依赖应用传参拼接 SQL（易 SQL 注入），也不能靠应用内存缓存租户 ID。必须由连接池（如 PgBouncer、HikariCP 配合拦截器）在建连后立即执行 SET 命令注入租户上下文，并校验该变量是否已设置且合法。

• 数据库侧可加检查函数：如 PostgreSQL 中定义 current_tenant_id()，内部校验 current_setting('app.tenant_id', true) 是否存在且匹配白名单
• 连接归还池前自动执行 RESET app.tenant_id，防止连接复用导致上下文污染
• 审计日志中记录每次查询的 session_user + app.tenant_id，便于追溯越权行为

定期权限巡检与租户数据脱敏测试

自动化脚本每月扫描：哪些角色拥有跨 tenant_id 的显式权限？是否存在未启用 RLS 的核心表？是否有视图未加 tenant_id 过滤？同时模拟租户 A 的账号，尝试访问租户 B 的接口或直连查询，验证是否返回空结果或报错。

• 用 SQL 快速检测： SELECT table_name FROM information_schema.role_table_grants WHERE grantee = 'role_tenant_a' AND table_name IN ('orders','users');
• 测试用例应覆盖 JOIN 场景（如订单+用户表联查），确认关联字段也受 tenant_id 约束
• 开发环境启用 log_statement = 'all' 并过滤含 tenant_id 的执行计划，确认无全表扫描漏过滤

基本上就这些。共享模式不是妥协，而是把隔离逻辑从代码里“请进数据库”，靠机制而不是靠人盯。关键在 tenant_id 全链路贯穿、RLS 默认开启、权限按租户原子化分配——不复杂但容易忽略细节。