安全访问
CloudBase PostgreSQL 的安全访问需要同时处理身份、权限、网络和密钥管理。前端访问应以 RLS 为核心，服务端访问应以最小权限账号和受控 API 为核心。
访问边界
| 访问来源 | 推荐方式 | 安全重点 |
|---|---|---|
| 小程序 / Web 前端 | SDK 或 HTTP API | 必须配置 RLS，避免越权访问 |
| 云函数 / 云托管 | PostgreSQL 协议直连或服务端 SDK | 使用环境变量保存密钥，限制数据库账号权限 |
| 管理人员 | DMC 或控制台 | 使用独立账号，避免共享管理员密码 |
| 第三方系统 | HTTP API 或后端转发 | 使用短期令牌、签名或后端鉴权 |
前端访问与 RLS
前端请求来自不可信环境，不能把表名、筛选条件或客户端参数当作权限依据。应在数据库表上开启 RLS，并通过 auth.uid() 识别当前用户。
alter table public.todos enable row level security;
create policy "Users can read own todos"
on public.todos
for select
to authenticated
using (user_id = (select auth.uid()));
完整策略示例请参考 基础权限。
服务端访问
服务端适合处理管理员任务、复杂业务规则、跨用户聚合和批处理。服务端可以使用数据库账号直连，但不应把该账号暴露给客户端。
建议为服务端创建独立数据库账号，并只授予所需 schema、表和函数权限。
grant usage on schema public to app_server;
grant select, insert, update on public.orders to app_server;
grant usage, select on all sequences in schema public to app_server;
密钥管理
- 数据库密码、AccessToken、私钥等敏感信息应保存在环境变量或密钥管理系统中。
- 不要将
.env、连接串或控制台截图提交到代码仓库。 - 不同环境使用不同账号和密码，例如开发、预发、生产分别配置。
- 定期轮换高权限账号密码，离职或权限变更后及时回收账号。
SQL 注入防护
服务端执行 SQL 时必须使用参数化查询，不要拼接用户输入。
await pool.query(
"select id, title from public.todos where user_id = $1 and done = $2",
[userId, false]
);
表名、列名等 SQL 标识符无法通过普通参数占位符传入。如果确实需要动态表名，应使用白名单映射。
最小权限原则
生产环境中建议将管理员操作和业务读写拆分为不同账号。业务账号只保留必要权限，避免误删表、修改结构或读取敏感表。
如果业务需要对外开放管理操作，应通过云函数或云托管封装，并在服务端完成身份校验、参数校验和审计日志。
上线检查
- 前端可访问的表已开启 RLS。
- 所有策略都覆盖
select、insert、update、delete的预期行为。 - 服务端连接信息只存在于受控环境变量中。
- 数据库账号权限已按最小权限收敛。
- 重要写操作有日志、备份或回滚方案。