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 命令注入租户上下文，并校验该变量是否已设置且合法。

标签： mysql app session 开发环境 red