Row Level Security(RLS)

Row Level Securityとは

Row Level Security(RLS、行レベルセキュリティ)は、データベースエンジン自身が「どの行を読み書きできるか」を、問い合わせを行うユーザーの身元に応じて判定する仕組みです。[[PostgreSQL]] などが標準搭載しています。

従来はアプリのコード側(サーバー層)で「このユーザーは自分のデータしか見れない」といったチェックを書いていました。RLSはこのチェックをDB自体に埋め込む点が特徴です。アプリのコードにバグがあっても、DB側のポリシーが最後の砦として機能します。

ポリシーの考え方

テーブルでRLSを有効にすると、明示的にポリシーを作らない限り全アクセスが拒否される(デフォルト拒否)のが基本です。その上でSELECT・INSERT・UPDATE・DELETEごとに条件を書きます。

-- 自分の行だけ読める
create policy "select_own_rows" on notes
  for select using (auth.uid() = owner_id);

「読み取りは全員OK、書き込みは本人のみ」のように操作ごとに別条件を持たせることもできます。

最小権限の原則との関係

RLSは [[最小権限の原則]] をデータベース層で具体化した仕組みといえます。「必要な行にだけアクセスできる」状態をアプリのコードではなくDBのポリシーとして強制することで、権限管理の抜け漏れを構造的に防ぎます。

使いどころ

• [[BaaS(Backend as a Service)]] のようにクライアントが直接DBへアクセスする構成では、RLSがほぼ唯一の防御ラインになるため必須
• マルチテナントSaaSで、テナント間のデータ漏洩を防ぐ

注意点

• ポリシーの条件ミスは「見えるはずのないデータが見えてしまう/更新できてしまう」という静かな形で表面化するため、テストで検証する
• 管理用の特権キー(サービスロールキー)は、テーブル所有者やスーパーユーザーと同じくRLSをバイパスする([[データベースのユーザーと権限管理]])ため、クライアントに絶対に埋め込んではならない

関連技術とのつながり

• [[BaaS(Backend as a Service)]] — RLSが安全性を担保する土台
• [[認証と認可]] — 「誰がアクセスしているか」を判定する前提
• [[最小権限の原則]] — RLSはこの原則をDB層で実装したもの
• [[PostgreSQL]] — RLSを標準搭載する代表的なRDBMS

Q: Row Level Securityの説明として正しいのはどれ?
- [ ] アプリのサーバーコードでのみ実装できるアクセス制御
- [x] データベースエンジン自身が行単位でアクセス可否を判定する仕組み
- [ ] HTTPレスポンスをキャッシュする仕組み
解説: RLSはDBエンジンが問い合わせユーザーの身元に応じて行単位のアクセス可否を判定する仕組みです。

Q: RLSを有効にしたテーブルで、ポリシーを何も作らなかった場合どうなる?
- [x] 全アクセスが拒否される(デフォルト拒否)
- [ ] 全アクセスが許可される
- [ ] SELECTのみ許可される
解説: RLSはデフォルト拒否が基本で、明示的にポリシーを作らない限りアクセスできません。

Q: RLSが特に重要になる構成はどれ?
- [x] クライアントが直接DBへアクセスするBaaS構成
- [ ] サーバーが全アクセスを仲介しクライアントは一切DBに触れない構成
- [ ] DBを使わない静的サイト
解説: クライアントが直接DBへアクセスするBaaS構成では、RLSがほぼ唯一の防御ラインになります。