存储策略与访问控制：用 RLS 机制守护文件

存储策略与访问控制：用 RLS 机制守护文件

文件同样需要权限控制——「用户只能下载自己的文件」「付费内容只有付费用户能看」。本节讲解 Storage 如何复用第 5 章的 RLS 机制，实现细粒度的文件访问控制。

存储策略：RLS 的延伸

Storage 的访问控制并不另起炉灶，而是复用 RLS 的理念：存储桶本身关联一组「存储策略」（storage policies），它们与数据表的行级安全策略本质相同——都是基于当前用户身份的布尔表达式，决定某次操作是否放行。

关键概念对应：

正因为机制一致，你在第 5 章学到的策略设计经验可直接迁移到 Storage。

路径即归属：存储策略的关键

存储策略的核心技巧是把归属编码进路径。例如约定所有用户文件都放在以用户 id 开头的路径下：

users/{用户id}/avatar.png
users/{用户id}/documents/report.pdf
​

这样，策略就能基于「路径前缀」判断归属：「只允许操作以 users/{当前用户id}/ 开头的对象」。这与数据表中「只允许操作 user_id 等于当前用户的行」是同构的。

常见存储策略模式

借鉴第 5 章的数据表模式，存储也有几种典型策略：

模式一：私有，仅本人可访问

• 上传：路径必须以当前用户 id 开头。
• 下载/列出：只能访问以当前用户 id 开头的对象。

适合用户私人文档、个人上传内容。

模式二：公开桶，所有人可读

• 桶设为公开，读取无需策略。
• 上传仍受策略约束（如仅认证用户可上传）。

适合网站公开图片、头像等。

模式三：私有桶 + 签名 URL 分享

• 默认私有，所有者可访问。
• 需要分享时，由有权限的人生成短期签名 URL。

适合付费内容、临时协作用文件。

模式四：基于角色

• 管理员可访问全部对象。
• 普通用户只能访问自己的。

思路与第 5 章 RBAC 一致，在策略中加角色判断。

上传策略与 WITH CHECK 等价物

和数据表的 INSERT 策略类似，存储的上传策略也要防止冒名——否则用户 A 可以上传到 users/B/ 路径下，冒充 B。因此上传策略应强制：新对象的路径前缀必须匹配当前用户 id。

这与数据表中「INSERT 的 WITH CHECK 要求 user_id = 当前用户」是同一思想：写入时的归属必须由服务端强制，不能信任客户端传的路径。

元数据辅助复杂策略

当归属无法仅靠路径表达时（如「协作者也能访问某文档的附件」），可以借助数据库表：

• 在数据库中维护一张「文件元信息表」，记录路径、所有者、协作者等。
• 存储策略中用子查询查这张表，判断当前用户是否有权。

这样存储策略能与业务数据表联动，表达任意复杂的权限规则——例如「该文件所属的项目，当前用户是否是成员」。

私有桶的访问流程

私有桶里一次下载的完整流程：

授权集中在生成签名 URL 时完成一次，下载本身高效。

存储安全清单

把存储安全浓缩为一份清单：

• 默认用私有桶，公开桶仅用于真正公开内容。
• 每个桶都配置了上传与下载策略。
• 路径编码归属（如 users/{id}/...），策略据此判断。
• 上传策略强制路径前缀匹配当前用户，防止冒名。
• 大文件 / 敏感文件用签名 URL，有效期尽量短。
• 文件类型与大小在桶配置层面约束。
• 上线前用不同身份测试上传/下载权限边界。

配额与滥用防护

除了权限，还要防范滥用：

• 限制单文件大小与允许类型。
• 限制单个用户的上传频率，防刷。
• 监控存储总量与带宽消耗，避免成本失控。
• 对公开桶尤其要监控，防止被当作免费图床盗用带宽。

小结

存储策略复用 RLS 机制，基于 JWT 与路径实现细粒度文件权限；路径编码归属、上传强制前缀匹配、复杂规则借助元数据表，是与数据表 RLS 同构的安全模型。把它用足，文件访问就能像数据访问一样安全可控。

至此，第 7 章完成了对文件存储的全面讲解。第 8 章将进入边缘函数，学习如何用 Serverless 代码承载更复杂的后端逻辑。