PostgreSQL行级安全策略

PostgreSQL的行级安全策略（Row-Level Security，简称RLS）并不是一个复杂到难以理解的概念，但很多开发者在使用时仍然会踩坑。最典型的问题就是：明明配置了策略，查询却突然不返回任何数据；或者应用层忘记设置参数，导致数据泄露。本质上，RLS是直接附加在数据库表上的一种过滤机制，它会在任何查询执行前自动追加WHERE条件，强制限定用户只能看到或修改特定的行。你不需要修改业务代码里的每一条SQL，只要策略定义得当，数据库层面就能帮你完成数据隔离。

要启用行级安全，首先需要在表上执行ALTER TABLE ... ENABLE ROW LEVEL SECURITY。这一步很多人会忽略，导致策略创建了但不生效。启用后，对于普通用户（非表所有者、非超级用户），PostgreSQL会默认执行一条“拒绝所有”的规则。也就是说，如果你只启用了RLS但没有创建任何策略，除了表所有者之外，其他用户连一行数据都查不到。这是一个安全优先的设计，但也经常让新手误以为是数据丢失了。

行级安全策略使用CREATE POLICY命令定义，基本结构包含三个关键部分：针对的操作（SELECT、INSERT、UPDATE、DELETE）、生效的角色以及最重要的USING表达式和WITH CHECK表达式。USING表达式决定哪些行对用户可见，作用于SELECT、UPDATE、DELETE操作；WITH CHECK表达式决定哪些行允许被插入或更新后保留在表中，作用于INSERT和UPDATE操作。如果你只定义了USING而没有定义WITH CHECK，那么对于需要写入检查的操作，PostgreSQL会用USING表达式同时作为检查条件。这种隐式行为在某些场景下会导致意料之外的结果，比如用户可能无法更新自己的记录，因为更新后的数据不满足USING条件。

-- 示例：为app_user角色创建策略，允许用户只查看和修改自己的数据
CREATE POLICY user_isolation_policy ON orders
    FOR ALL
    TO app_user
    USING (user_id = current_setting('app.current_user_id')::integer)
    WITH CHECK (user_id = current_setting('app.current_user_id')::integer);

上面的示例中出现了current_setting函数，这是RLS实现多租户数据隔离最常用的技巧。数据库本身不知道当前的应用用户是谁，你需要通过SET命令在会话级别设置一个自定义参数，比如app.current_user_id。应用在获取数据库连接后，立即执行SET app.current_user_id = '123'，这样策略中的表达式就能动态获取当前用户身份。这种方法的优势在于，即使多个应用用户共享同一个数据库连接池，只要每次从池中取出连接时重新设置参数，隔离性就不会被破坏。但要注意，如果应用忘记设置参数，current_setting会抛出异常，导致查询失败。更稳妥的做法是使用COALESCE或NULLIF提供默认值，或者设置一个不可能匹配任何真实用户的占位值，确保在未设置参数时查询返回空集而非报错。

SELECT操作只需要USING子句，它会在扫描表时过滤行。UPDATE操作需要同时考虑旧行和新行：USING决定哪些行可以被选中更新，WITH CHECK确保更新后的行仍然符合策略要求。DELETE只需要USING，因为删除操作不产生新行。INSERT操作比较特殊，它不需要USING（因为没有旧行可供检查），只需要WITH CHECK来验证新插入的行是否合法。如果你想让用户既能插入自己的记录，又能查看所有用户的部分公开信息，就需要创建两条策略，一条针对SELECT，一条针对INSERT，各自定义不同的表达式。多条策略之间是“或”的关系，只要有一条策略通过，操作就被允许。

-- SELECT策略：允许查看所有状态为public的记录，或者自己的记录
CREATE POLICY select_orders ON orders
    FOR SELECT
    TO app_user
    USING (status = 'public' OR user_id = current_setting('app.current_user_id')::integer);

-- INSERT策略：只允许插入自己的记录
CREATE POLICY insert_orders ON orders
    FOR INSERT
    TO app_user
    WITH CHECK (user_id = current_setting('app.current_user_id')::integer);

RLS的本质是自动追加WHERE条件，因此它的性能直接取决于这些条件能否高效利用索引。如果你的USING表达式中使用了函数调用或者类型转换，比如对current_setting的返回值做了::integer转换，PostgreSQL可能无法有效利用user_id列上的索引。这是因为查询规划器看到的不是常量，而是一个运行时才能确定的值。在大多数情况下，规划器会将这个表达式当作一个稳定的函数处理，生成的执行计划仍然可以使用索引，但前提是统计信息足够准确且表足够大。对于小表，顺序扫描可能比索引扫描更快，RLS带来的额外过滤条件几乎不会造成性能问题。真正需要警惕的是在USING表达式中使用子查询或者访问其他表，这会导致每一行过滤都触发额外的查询，性能会急剧下降。如果确实需要跨表权限判断，应该考虑使用会话级临时表或者物化视图来预先计算权限集合。

这是RLS设计中一个容易被忽视但至关重要的特性：表所有者和超级用户默认不受行级安全策略的限制。这意味着即使你精心设计了策略，数据库管理员或者拥有表所有权限的账号仍然能看到所有数据。在多租户SaaS系统中，如果你的应用使用了拥有表所有权的数据库用户进行连接，那么RLS形同虚设。正确的做法是创建专门的、没有超级权限且不拥有目标表的数据库角色，让应用以这些受限角色连接数据库。表的实际所有者只用于执行DDL变更，与应用运行时的访问完全分离。如果你确实需要让表所有者也被RLS约束，可以在表上执行ALTER TABLE ... FORCE ROW LEVEL SECURITY，这样连所有者也会被策略限制。

行级安全策略是在表级别定义的，但它与列级权限、表级权限共同构成了PostgreSQL的完整权限体系。一个用户能否访问某张表，首先取决于是否被授予了表级SELECT权限。如果没有表级权限，即使RLS策略允许，查询也会被直接拒绝。反过来，如果用户有表级权限但没有匹配的RLS策略，查询会返回空集而不是报错。这种层级关系意味着你需要同时管理好GRANT和CREATE POLICY两套机制。在实际项目中，建议将表级权限授予一个组角色，然后将具体的用户角色加入这个组，再通过RLS策略对不同用户角色进行行级隔离。这样权限结构清晰，审计也方便。

当查询结果不符合预期时，首先要确认当前会话的角色和参数设置。执行SELECT current_user, current_setting('app.current_user_id', true)可以快速检查。然后使用EXPLAIN ANALYZE查看查询计划，注意输出中的Filter部分，它会显示RLS策略附加的具体条件。如果Filter中的表达式与你预期的不一致，说明策略定义有误或者有多条策略在同时起作用。PostgreSQL在pg_policies视图中提供了所有策略的定义信息，可以直接查询这个视图来审查当前数据库中的策略配置。另一个常见问题是策略的生效角色设置为了PUBLIC，但当前用户并不属于你预期的角色范围。记住，PUBLIC代表所有角色，包括未来创建的角色。

-- 查看当前数据库中的所有RLS策略
SELECT schemaname, tablename, policyname, permissive, roles, cmd, qual, with_check
FROM pg_policies
ORDER BY schemaname, tablename;

在真实业务中，数据隔离往往不是简单的“用户只能看自己的数据”。你可能需要处理上下级关系，比如部门经理可以查看下属的订单；或者需要处理共享数据，比如一个项目组的成员都能看到项目相关的所有记录。对于上下级关系，可以在USING表达式中使用递归CTE或者预先在应用层计算好下属ID列表，通过数组参数传递进来。对于共享数据，通常需要引入一张关联表来存储资源与用户的关系，然后在策略中使用EXISTS子查询。但正如前面提到的，EXISTS子查询会带来性能开销，一个折中方案是使用PostgreSQL的数组操作符，在会话参数中设置一个包含所有可访问资源ID的数组，策略表达式中使用user_id = ANY(current_setting(...)::int[])来判断。这种方式将复杂的关联查询转化为了数组包含判断，索引利用效率更高。

-- 使用数组参数实现共享数据访问
-- 应用层设置：SET app.accessible_project_ids = '{100,200,300}';
CREATE POLICY project_access ON projects
    FOR SELECT
    TO app_user
    USING (project_id = ANY(current_setting('app.accessible_project_ids')::int[]));

行级安全策略是PostgreSQL提供的一项成熟且强大的功能，它把数据访问控制的粒度从表级细化到了行级，让数据库真正承担起数据隔离的核心职责。合理使用RLS可以大幅减少应用层的权限判断代码，降低因代码漏洞导致的数据泄露风险。但它的正确实施需要你对SQL权限体系、查询规划器行为以及应用架构有整体的把握。一旦配置得当，它就会像一道沉默的闸门，精确地控制着每一行数据的流向。