Supabase RLS
Supabase の行レベルセキュリティを、正しく
RLS はアプリの実際の認可が宿る場所——SQL で、行の粒度で書きます。ここはそのハブ：いちばん大事な考え方、正しいパターン、そしてポリシーを書く・検証する・証跡化する無料ツール。必要なものから始めてください。
npx @aegiskit/cli scanリポジトリ全体をローカルでスキャン——インストール不要・どこにも通信しません。
9.2%の公開 Supabase アプリ（1,000 件中）が、認証はするが認可しない RLS を出荷（下限値）。
ここから
何をしたいですか？
正しいポリシーを書く
所有モデルを選ぶと、性能イディオムと WITH CHECK 付きの貼るだけ SQL を生成します。
ポリシー生成ツールを開く手元のポリシーを検証する
ポリシーを貼るだけで、行を呼び出し元に絞れているか即判定——100% ブラウザ内で。
RLS チェッカーを開くSOC 2 / ISO 27001 の証跡にする
所見を、監査人や問診票にそのまま渡せる統制証跡へマッピングします。
証跡マッピングを見るパターンを学ぶ
最初のポリシーから、マルチテナント分離・テスト・性能まで——深掘りガイド。
ガイドを見るレビューを受ける
アクセス制御の設計を端から端まで見てほしいなら、監査として引き受けます。
監査を依頼
いちばん大事な考え方
認証 ≠ 認可
RLS が有効なことと、RLS が正しいことは別です。セッションの存在だけを証明するポリシー（auth.role() = 'authenticated'、auth.uid() is not null）は、全ログインユーザーに全行を読ませます。認可は、行をその所有者に束縛します。
create policy "notes_read" on public.notes
for select to authenticated
using (auth.role() = 'authenticated');create policy "notes_read" on public.notes
for select to authenticated
using ((select auth.uid()) = user_id);「所有者スコープでない＝脆弱」ではありません——共有参照テーブルは全認証ユーザーが読めて正当。目的は煽りではなく意図の確認です。認可の正しさはいかなるツールも証明できません。正確に「指す」ことだけができます。
パターン
4 つの形でほぼすべてを覆える
ほとんどのテーブルはこの所有モデルのどれかに収まります。あなたの SQL を数秒で生成できます。
個人
各行は 1 人のユーザーのもの。本人だけが読み書きします。
マルチテナント
行はテナントに属し、ユーザーは所属テナントの行にアクセスします。
共有読取＋所有者書込
全ログインユーザーが読み、書けるのは所有者だけ。参照/共有データ向け。
ロック
クライアントからは一切アクセス不可——読み書きはサーバー経由のみ。
さらに深く
Supabase RLS ガイド
実践的で一次情報に基づく深掘り——このハブの spokes です。
入門：RLS を有効化し最初のポリシーを書く
GRANT と POLICY の層、USING / WITH CHECK、ロールモデル。
RLS が認証はするのに認可しないとき
実態調査が測定したパターンと、ケース別の直し方。
本番のマルチテナント設計パターン
メンバーシップ表、テナント分離、再利用できるヘルパ。
WITH CHECK 欠落による書き込みバイパス
書き込みに USING だけでは不十分な理由と、穴の開き方。
pgTAP で RLS をテストする
許可と拒否を CI で証明し、ポリシーの静かな退行を止める。
RLS 設定ミスの検出
5 つの危険パターンと、静的に捕まえる方法。
RLS のパフォーマンス最適化
(select auth.uid()) ラッパ、インデックス、EXPLAIN ANALYZE。
実態調査：公開 Supabase アプリ 1,000 件
9.2% の裏づけ——手法・誤検知・precision 1.0。
Supabase の RLS を、正しく
正しいポリシーを数秒で生成。あるいはアクセス制御の設計一式を端から端までレビューします。
FAQ
Supabase の行レベルセキュリティ（RLS）とは？
RLS は PostgreSQL の行単位アクセス制御です。Supabase では実際の認可境界になります——テーブルが API 公開されるため、各テーブルのポリシーが、呼び出し元がどの行を読み書きできるかを決めます。有効化し、行を呼び出し元に束縛するポリシーを足します。
RLS を有効化すれば安全ですか？
いいえ。RLS を有効化してポリシーが無い状態は全拒否（安全）ですが、ログイン済みかだけを確認するポリシー（auth.role() = 'authenticated'）は全ユーザーに全行を読ませます。正しいポリシーは行を所有者に絞ります（例：using ((select auth.uid()) = user_id)）。
正しい Supabase RLS ポリシーの書き方は？
各行を呼び出し元に束縛します。読み取りは USING ((select auth.uid()) = user_id)、書き込みには対の WITH CHECK を。無料のポリシー生成ツールが、個人・マルチテナント・共有読取・ロックの各テーブル向けに正確な SQL を出力します。
RLS が正しいかどう確認しますか？
無料のブラウザ内 RLS チェッカーにポリシーを貼れば行を絞れているか判定でき、npx @aegiskit/cli scan でリポジトリ全体を走査できます。どちらもコードを外部に送りません。データモデルに対する確定判断は、人間のレビュー・監査が適切です。
RLS は SOC 2 や ISO 27001 に役立ちますか？
行レベルのアクセス制御は、論理アクセス統制（SOC 2 CC6.1、ISO 27001 A.8.3）の技術証跡になります。Aegis は所見をそれらの統制へマッピングします——監査人向けの参考マッピングであり、認証ではありません。