database-security

安全审计

专注于行级安全（RLS）执行、零信任数据库架构和取证审计跟踪的数据库安全审计工具。重点关注 Supabase、Postgres 和 Convex 数据层安全。对于一般应用安全（OWASP Top 10、身份验证模式、安全标头、输入验证），请改用 security 技能。

快速参考

需求	方法
RLS 执行	在每个 public 表上启用；为每种操作分别设置策略
RLS 性能	为 RLS 列建立索引；在子查询中使用 (select ...) 包装 auth.uid()
零信任数据库	微分段、身份传播、强制执行 TLS
在 RLS 中使用 Supabase 身份验证	使用 (select auth.uid()) 和 auth.jwt()；绝不使用 auth.role()
Convex 身份验证保护	在每个公开函数中调用 ctx.auth.getUserIdentity()
JIT 访问	设置有时限的授权，并在到期后自动失效
审计跟踪	使用数据库触发器和不可变的 audit_log 表
PGAudit	用于语句级和对象级 SQL 审计的扩展
服务角色安全	绝不在客户端代码中使用 service_role 密钥
视图和 RLS	使用 security_invoker = true（Postgres 15+）强制执行 RLS
架构分段	分开设置 public、private 和 audit 架构
数据库合规性	RLS + 审计日志 + 加密可满足多个框架的要求

审计流程

执行数据库安全审计时，请遵循以下顺序：

1. 攻击面映射：识别数据层的所有入口点（公开 API、内部控制面板、AI Agent、定时任务）
2. RLS 覆盖检查：查询 pg_tables，验证 public 架构中的每个表都已启用 RLS 且配置了适当的策略
3. 策略审查：检查逻辑绕过、缺少 WITH CHECK 子句、权限过于宽泛的 FOR ALL 策略
4. 服务角色审计：搜索客户端代码，检查是否暴露了 service_role 密钥；验证它只出现在服务器端代码中
5. 函数审计：检查已公开架构中的 security definer 函数，以及缺少身份验证保护的 Convex 函数
6. 访问模拟：以 anon 和 authenticated 角色执行查询，验证强制执行是否有效
7. 视图审计：验证视图使用 security_invoker = true，或不位于公开架构中
8. 审计跟踪验证：确认触发器或 PGAudit 会捕获所有与安全相关的操作
9. 合规性验证：将数据库控制措施与适用的法规框架进行对照

安全原则

原则	数据库应用
深度防御	RLS + 应用程序检查 + 架构分段
最小权限	为每个角色配置最小 GRANT；anon 几乎不授予任何访问权限
零信任	即使是内部请求，也要在数据库层验证身份
默认安全	创建时启用 RLS；没有策略时默认拒绝
安全失败	Postgres 的 RLS 默认拒绝；返回通用错误响应
假定已遭入侵	设计时假定攻击者持有有效的 JWT

反模式

反模式	风险
通过隐蔽性实现安全（仅使用 UUID）	攻击者通过 IDOR 枚举 ID
anon 角色对敏感表拥有 SELECT 权限	通过 Supabase API 泄露公开数据
RLS 列没有索引	生产环境性能下降（100 倍以上）
仅在前端检查权限	攻击者通过直接调用 API 绕过检查
长期保留管理员权限	一旦遭到入侵，影响范围过大
在客户端代码中使用 service_role 密钥	完全绕过所有 RLS 策略
使用 FOR ALL 策略，而非按操作分别设置策略	宽泛规则导致意外的写入权限
在 public schema 中使用 security definer 函数	函数可通过 API 调用，从而绕过 RLS
视图未设置 security_invoker	视图会在不提示的情况下绕过 RLS

常见错误

错误	正确做法
使用 auth.uid() = user_id，未将其包装在 (select ...) 中	使用 (select auth.uid()) = user_id，让 Postgres 通过 initPlan 缓存结果
使用 FOR ALL，而不是分别设置每种操作的策略	分别创建 SELECT、INSERT、UPDATE、DELETE 策略，以确保清晰和安全
让 anon 角色对敏感表保留 SELECT 权限	限制 anon 访问；敏感数据要求使用 authenticated 角色
仅依赖 UUID 进行访问控制	除唯一标识符外，还要强制执行 RLS 策略和显式的身份验证检查
RLS USING 子句所用列没有索引	为 RLS 策略表达式中引用的所有列添加 B-tree 索引
Convex 函数缺少 ctx.auth.getUserIdentity() 调用	每个公开查询和 mutation 都必须在访问数据前验证身份
在客户端代码中使用 service_role 密钥	客户端使用 anon 密钥；仅在服务端函数中使用 service_role
视图未设置 security_invoker，导致绕过 RLS	在 Postgres 15+ 中为视图设置 security_invoker = true
在公开 schema 中使用 security definer 函数	将 security definer 函数放在非公开 schema 中，并设置 search_path = ''
未对安全相关的数据库事件进行审计日志记录	使用触发器和 PGAudit 记录所有数据访问和修改

与安全技能的关系

application-security 技能涵盖通用应用安全内容：OWASP Top 10、身份验证模式、输入验证、安全标头和合规性概览。本 database-security 技能与之互补，重点关注数据库层面的安全问题：RLS 策略设计与性能、Supabase/Postgres 特定模式、Convex 身份验证防护、PGAudit 配置，以及数据库特定的合规实现（用于 GDPR 数据擦除的 SQL 函数、HIPAA PHI 审计触发器等）。

委派

• 通过访问模拟验证 RLS 强制执行情况：使用 Task agent 针对每个公开表运行匿名和经过身份验证的查询
• 审计 Convex 函数是否缺少身份验证防护：使用 Explore agent 扫描所有查询和 mutation 处理程序，查找 getUserIdentity 调用
• 设计零信任数据库架构：使用 Plan agent 梳理 schema、访问策略、JIT 授权和审计日志设计
• 生成数据库合规性证据：使用 Task agent 运行审计查询并生成合规报告

参考资料

• rls-performance.md —— RLS 策略性能、initPlan 缓存、稳定函数、独立策略、EXPLAIN 基准测试
• zero-trust-database.md —— 微分段、身份传播、连接安全、JIT 访问控制
• audit-logging.md —— 基于触发器的审计、PGAudit 扩展和日志类别、日志完整性、防篡改存储
• convex-security.md —— 身份验证、函数中的手动 RLS、细粒度函数、通过 JWT 声明进行基于角色的访问控制
• threat-modeling.md —— 将 STRIDE 应用于数据库访问、RLS 绕过途径、数据层信任边界
• application-security.md —— 服务角色管理、架构暴露、security definer 函数、视图和 RLS
• compliance-frameworks.md —— 数据库特定的 GDPR、HIPAA、SOC2、PCI-DSS 要求及 SQL 实现