どんな場面で検討するか
PostgreSQLの関係データに、認証・ファイル保存・アプリ用APIを組み合わせ、利用者ごとに行の閲覧権限を分けるWebアプリを作る場合。
組織で使う条件
RLSを有効にし、公開キーでも他者の行へアクセスできないことを継続確認する。 DBバックアップにはStorage APIのファイル本体が含まれないため、ファイルを別途保全する。
採用前に試すこと
- 架空ユーザーA/Bと申請100件、添付10件を作り、本人の申請だけが見えるRLSを設定する。
- Aの公開クライアントでBの行/添付を読込・更新しようとし、サーバー処理と権限を比較する。
- DBと添付を別々に保全して隔離環境へ復元し、件数・添付SHA256・所有者を照合する。
合格と判断する条件
- A/Bの所有者識別と件数が正しい。
- AがBのデータを取得/改変できず、秘密鍵がブラウザへ配信されない。
- DBと添付の両方が復元でき、見積にcompute・保存・転送が含まれる。
見落としたくない点
- 全ユーザーを管理者相当のキーで処理する設計や、RLSの否定テストを行えない場合は採用前に見直す。 DBのみ必要なら単独のマネージドPostgreSQLと運用/費用を比較する。
- 全ユーザーを管理者相当のキーで処理する設計や、RLSの否定テストを行えない場合は採用前に見直す。
- DBのみ必要なら単独のマネージドPostgreSQLと運用/費用を比較する。
根拠となる資料
Securing your data | Supabase Docs