---
title: "多租户与 RLS：如何设计客户数据边界"
slug: "multi-tenancy-rls-data-boundaries"
language: "zh-cn"
tags: ["멀티테넌시","rls","보안","데이터","플랫폼 운영"]
created: "2026-09-30T00:00:00.000Z"
published: "2026-10-08T10:15:09.802Z"
updated: "2026-10-08T10:15:09.802Z"
sample: false
---

# 多租户与 RLS：如何设计客户数据边界

## 多租户不是界面区分，而是数据契约

在订阅式服务中，多个客户组织会使用同一个应用程序和数据库。仅仅在界面上显示组织名称，并不能实现隔离。必须确认每次查询和更改属于哪个租户的请求，并确保无权访问的行在数据库层面也无法被访问。

SAG 将表示组织的租户与用户角色分别处理。用户登录后，服务器会检查会话和成员关系，并验证请求的资源是否属于该租户。服务器不会直接信任浏览器发送的组织标识符。

## 为什么要同时设置服务器端权限和 RLS

服务器端权限检查能够清晰、明确地表达业务规则。RLS（行级安全）则会在数据库中再次设置边界，即使查询出错，也能避免暴露其他组织的行。两层防护结合使用，可以降低一方的疏漏直接导致客户数据泄露的可能性。

核心原则如下：

- 对需要区分租户的表，设置明确的租户标识符。
- 对读取和写入应用相同的所有权验证。
- 区分平台管理员与客户运营人员的权限。
- 在审计日志中记录谁更改了哪些资源。
- 不要将 API 密钥、密码等机密值存储在普通运营记录中。

## 区分共享数据与客户专属数据

有些对象（例如竞争对手域名）可由多个客户共同观测；而客户问题、改进建议和审批记录等数据则应按组织进行保护。无条件复制前一类数据会增加运营成本，轻率共享后一类数据则会引发安全问题。SAG 会先定义数据的所有权和公开范围，再决定存储结构。

## 需要验证的故障场景

仅确认正常查询能够通过还不够。还需要确认：输入其他租户的 ID 时是否会返回 404 或权限错误；低权限用户是否无法调用更改 API；尝试用旧版本覆盖数据时是否能够检测到冲突。数据边界不是写在文档中的承诺，而是必须通过可重复测试证明的运营条件。

## 还要检查 RLS 所适用的执行角色

即使设置了 RLS 策略，表所有者或 BYPASSRLS 角色也可能绕过这些策略。SAG 的服务器端成员关系和租户条件检查会独立于此继续执行。必须同时检查数据库连接角色和策略的应用情况，才能判断隔离范围。


## 主题相关技术参考

- [PostgreSQL 行安全策略](https://www.postgresql.org/docs/current/ddl-rowsecurity.html)


## 如何继续了解这项技术

了解租户权限、任务重试、缓存和审批历史。

- [设计可靠的客户空间](/ko/blog?tag=%ED%94%8C%EB%9E%AB%ED%8F%BC%20%EC%9A%B4%EC%98%81)
- [功能指南 FAQ](/zh-cn/faq)