RLS 工作原理：行级别的安全门

RLS 工作原理：行级别的安全门

要写好 RLS，必须先彻底理解它「行」级别的工作方式。本节讲清 RLS 的核心概念：什么是行级安全、如何启用与禁用、策略如何被评估，以及一个常被忽略的关键前提——默认拒绝。

从「表级权限」到「行级权限」

传统数据库权限控制往往停留在「表」的粒度：某个角色能读某张表、能写某张表。但这种粒度对多租户应用远远不够——用户表里所有用户的数据混在一张表，你要让每个用户只能看到自己的行，「表级」权限就无能为力。

行级安全（RLS） 正是为解决这个问题而生：它让权限判定下沉到「每一行」，根据当前请求者的身份，逐行决定这条数据是否可见、可改。于是「用户只能看自己的订单」「员工只能改本部门的资料」这类需求，都能用 RLS 精准表达。

RLS 是表级开关

RLS 是针对每张表启用的开关。一张表可以选择：

• 未启用 RLS：该表对所有能连上数据库的角色完全开放，没有任何行级保护。
• 已启用 RLS：该表的访问受策略约束，无匹配策略的访问默认被拒绝。

极其重要：新建的表默认未启用 RLS。在 Supabase 中，未启用 RLS 的表若被客户端直接访问，等同于完全公开——这是最常见、也最危险的安全疏漏。每张承载真实数据的业务表，都应第一时间启用 RLS。

启用与禁用 RLS

启用 RLS 是一条简单的开关语句（针对某张表）。启用后，你可以为该表编写多条策略。禁用 RLS 同样是一条语句，但生产环境中几乎不应禁用已启用的 RLS——那等于拆掉守门人。

策略（Policy）：表达「谁能做什么」

启用 RLS 后，真正决定访问规则的是策略（policy）。一条策略本质上是：

• 针对某个命令（SELECT 查询、INSERT 插入、UPDATE 更新、DELETE 删除，或 ALL 全部）。
• 一段布尔表达式：对每一行，用当前用户的身份评估这个表达式；为真则允许，为假则拒绝。

例如「查询时，只允许读取 user_id 等于当前用户 id 的行」，就是一条针对 SELECT 的策略。

策略的评估方式

理解策略如何被联合评估，是写对 RLS 的关键：

• 一张表可以有多条策略，分别覆盖不同命令或不同角色。
• 针对同一命令的多条策略之间，通常是**「或」**关系——只要任意一条策略允许，就放行（默认 permissive 策略）。也存在「与」关系的 restrictive 策略用于收紧。
• 默认拒绝原则：如果某命令没有任何一条策略覆盖，或所有策略都不满足，访问被拒绝。

这条「默认拒绝」原则是 RLS 安全性的根基：宁可全拒，不可误放。

当前用户的身份从哪来

策略表达式需要知道「当前是谁」。PostgreSQL 在会话中维护着当前用户与角色信息，Supabase 则把 JWT 中的身份映射进来，提供一组函数供策略调用，例如：

• 获取当前用户的 id（UUID）。
• 判断当前是否已登录（是认证用户还是匿名）。
• 获取当前用户的角色。

策略通过这些函数拿到身份后，再与每一行的字段（如 user_id）比较，从而做出「这一行属于当前用户吗」的判断。具体函数名与用法见下一节。

绕过 RLS：服务级密钥

有一个重要例外：使用服务级密钥（service role key）的连接可以绕过 RLS。这个角色用于可信的后端环境（如边缘函数），需要直接操作所有数据时使用。

务必牢记：服务级密钥拥有绕过一切行级安全的特权，绝不能出现在前端代码或公开仓库中。前端只能使用受 RLS 保护的匿名密钥（anon key）配合用户令牌访问数据。

RLS 带来的架构变化

理解了 RLS，你就明白 Supabase 的架构为何如此独特：

• 传统架构：前端 → 自建后端（在代码里写鉴权）→ 数据库。
• Supabase 架构：前端（携带用户令牌）→ 直连数据库（RLS 在数据库层鉴权）。

RLS 让数据库本身承担了鉴权职责，前端因此可以安全直连，省去自建后端这一整层。这大幅简化了架构，也减少了鉴权逻辑在多处实现不一致的风险。

小结

RLS 是表级的行级安全开关，默认未启用需主动开启；启用后由策略逐行评估，遵循「默认拒绝」原则；当前用户身份来自 JWT；服务级密钥可绕过 RLS。掌握这些原理，下一节我们就能动手编写策略，把规则精确地表达出来。