行级安全详解：写给非技术创始人

行级安全详解：RLS是一项数据库功能，它自动过滤每一次查询，让每位客户永远只能看到自己的数据——即使你的应用代码有bug。你只需在数据库里定义一次规则，它就无法被绕过。老实说，这就是我能睡得着觉的原因。

如果你在用AI构建SaaS，又不懂技术，RLS是唯一一个真正值得弄懂的安全概念。下面讲讲它是什么、为什么胜过所有替代方案，以及可以交给你的AI的检查清单。

行级安全详解：保安的比喻

想象你的数据库是一间档案室，每位客户的记录是里面的文件夹。没有RLS，档案室的门是敞开的，你依赖每一位员工——也就是应用代码的每一个部分——每一次都记得只取正确客户的文件夹。只要有一次疏忽，就会有人带着竞争对手的文件走出去。

RLS则在档案室里面安排了一名保安。保安核对每个提出请求者的身份，并且实打实地只交出属于其所在组织的文件夹。员工忘了正确提问也好，要求调取全部也好，都无所谓——保安会过滤返回的内容。每一次请求。自动执行。没有例外。

从技术上讲：不再由你的应用来过滤数据（“只显示这位客户的行”），而是把这条规则作为一项策略，在数据库内部定义一次。此后，每次查询在任何数据离开数据库之前就已被过滤。它内置于PostgreSQL，像Supabase这样的平台把它当作一等公民功能。

为什么只在应用代码里过滤是不够的

关于替代方案，有一个令人不舒服的事实。没有RLS，数据隔离就取决于某个人——或某个AI——记得在产品接触数据的每一个地方都加上“仅限此客户”。几百个地方。永远如此。每个新功能，每个快速修复，每次深夜改动。

人会忘。AI也会忘——在某个疲惫的周二让它做一个报表功能，它可能高高兴兴地把一切都查出来。现场的一个真实例子：一位开发者在报表接口里忘了按组织过滤。没有RLS的话，他们就把客户数据泄露给竞争对手了。有了RLS，数据库自动拦截了未授权的访问。直到代码评审才有人发现——因为什么坏事也没发生。

安全从业者把这叫作纵深防御：不要指望某一层是完美的。你的应用代码过滤数据（第一层），RLS在数据库层面强制执行（第二层）。如果第一层失效——bug、糟糕的提示词、AI幻觉——第二层依然守得住。当AI写了你大部分代码时，这一点加倍重要，因为AI生成的代码会以你难以察觉的方式出错，直到代价高昂。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

每张表都需要的四种权限

RLS策略有四种类型，对应用户对数据能做的每一件事。把它们看作保安会问的四个问题：

每张存放客户数据的表，这四种都要有。整个体系就是这样：每张表上的organization_id标签说明每一行归谁所有；这四条策略让数据库去强制执行。

我是怎么学会RLS的（向Claude学的）

老实说——我不是在安全课上学会RLS的，而是向Claude学的。刚开始用Supabase时，我问：“怎样确保用户只能看到自己组织的数据？”Claude讲解了RLS策略。我在每张表上都实现了它们。现在一切自动完成。

这正是写给非技术创始人的重点：你不需要手写这些策略。你只需理解这个概念——档案室里的保安，每张表四种权限——然后指示你的AI：“在每张表上启用行级安全，配置查看、创建、更新和删除的策略，并限定在用户所属的组织范围内。”AI生成策略；数据库永远强制执行。

我的平台FIKR Space有964张表。全部都用这种方式保护。没有例外。之所以能管得过来，只因为规则由数据库强制执行，而不是靠我的记忆——这也是我提倡在编写任何功能之前先设计数据库的同一个原因。

创始人的RLS检查清单

你不需要写一行SQL。你需要坚持五件事：

1. 每张客户数据表都启用RLS。直接问你的AI：“所有表都启用了行级安全吗？列出没有启用的。”
2. 每张表都有全部四种策略类型——查看、创建、修改、删除。只有查看策略的表，仍会通过写入操作泄露数据。
3. 策略按组织划定范围，与你的多租户设置保持一致。
4. 用两个账号测试。创建两个测试组织。以其中一个登录，尝试读取和编辑另一个的数据。只要有任何数据返回，就停下来修复，再上线。
5. 每新增一张表都重新检查。把“启用RLS并配置标准的四条策略”变成你的AI为其创建的每张表都要执行的常设规则——而不是你按每个功能去记着的事。

附带的好处是应用代码更简单：一旦数据库强制执行隔离，你的功能就不需要到处撒上按客户过滤的逻辑。默认安全，代码更少，你也不用再担心有人忘了的那一条查询。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

常见问题

行级安全通俗地说是什么？

这是你在数据库内部定义一次的规则，它自动过滤每一次查询，让每位用户只能看到属于自己组织的行。就像档案室里的保安：无论谁来问、怎么问，出来的永远只有正确的文件夹。

如果我的应用已经过滤了数据，还需要RLS吗？

需要。应用层过滤依赖每一段代码——无论是人写的还是AI写的——永远记得加上过滤条件。RLS是有人遗忘时的安全网：你应用里的bug不会再演变成数据泄露，因为数据库自己会拦下这次泄露。

不懂SQL也能设置RLS吗？

可以。先理解这个概念，然后指示你的AI：“在每张表上启用行级安全，配置查看、创建、更新和删除的策略，并限定在用户所属的组织范围内。”然后用两个测试账号互相尝试读取对方的数据来验证。策略由AI编写；检查清单由你负责。

RLS会拖慢我的产品吗？

只要表设置得当，就不会有明显影响——关键是在策略所检查的组织列上建立索引（把它写进给AI的常设指令里）。拥有数千张受保护表的平台就是按这种模式运行的；FIKR Space运行着964张。