【ぎょうれべるせきゅりてぃ】

行レベルセキュリティ(RLS) とは?

公開:
💡 同じテーブルを見ているのに、見える行が人によって違う——DBが自動で仕分けする
📌 このページのポイント
行レベルセキュリティ(RLS)のしくみ ordersテーブル user_id=1: 注文A ¥3,000 user_id=1: 注文B ¥1,500 user_id=2: 注文C ¥8,000 user_id=2: 注文D ¥500 ユーザー 1 (tenant_id=1) ユーザー 2 (tenant_id=2) POLICY: user_id = current_user_id() ← ユーザー1には 注文A・Bのみ表示 ← ユーザー2には 注文C・Dのみ表示 DBが自動的にフィルタリング
RLS:同じテーブルでもユーザーごとに見える行をDBが自動制限する
ひよこ ひよこ
行レベルセキュリティって、普通のアクセス制御と何が違うの?
ペンギン先生 ペンギン先生
普通のアクセス制御テーブル全体に「見ていいか・ダメか」を設定するんだけど、RLSはテーブルの中の「行ごと」に制御できるんだよ。同じテーブルでもユーザーAには自分の注文だけ、管理者には全部の注文が見える、みたいなことができる。
ひよこ ひよこ
アプリ側でWHEREを書けば同じことができるんじゃないの?
ペンギン先生 ペンギン先生
そうなんだけど、アプリ側だと書き忘れるリスクがある。RLSはDBレイヤーで強制するから、どんなクエリでも必ずフィルタが適用されるんだ。セキュリティの「最後の砦」として機能するよ。
ひよこ ひよこ
実際にどう設定するの?
ペンギン先生 ペンギン先生
PostgreSQLでは「ポリシー」を定義するよ。「tenant_id = current_setting('app.tenant_id')」みたいな条件を書いておくと、ユーザーが自分のテナントのデータしか見えなくなる。マルチテナントSaaSでとても便利な機能だね。
ひよこ ひよこ
パフォーマンスへの影響はあるの?
ペンギン先生 ペンギン先生
クエリにポリシーのWHERE条件が追加されるから、インデックスをうまく使えないと遅くなることがある。tenant_idなど絞り込みに使うカラムにはインデックスを張っておくのが定石だよ。
ひよこ ひよこ
Supabaseで使われているって聞いたけど関係あるの?
ペンギン先生 ペンギン先生
まさに!SupabasePostgreSQLのRLSをフル活用したBaaS(Backend as a Service)なんだ。認証情報をセッション変数に入れて、各テーブルのRLSポリシーで「自分のデータだけ」を制限する設計になっているよ。
ペンギン
まとめ:ざっくりこれだけ覚えればOK!
「行レベルセキュリティ(RLS)」って出てきたら「ユーザーごとに見える行をDBが自動制限する機能」と思えればだいたいOK!
📖 おまけ:英語の意味
「Row-Level Security」 = 行レベルセキュリティ
💬 Row(行)+Level(レベル)+Security(セキュリティ)。テーブルの行という細粒度でアクセス制御をかける仕組みだよ
← 用語集にもどる