はじめに

認可ミスは重大な情報漏えいにつながります。
特に「組織ごとにデータを分ける」SaaSでは、1件の漏れでも大きな問題です。
その対策として強力なのがRLS（Row Level Security）です。

RLSとは

行ごとに、誰がアクセスできるかをDB側で制御する仕組みです。

アプリ側で WHERE organization_id = ... を書き忘れても、
RLSがあればDBがアクセスをブロックできます。

初心者向けの一般的な例

例1: ECサイトの注文履歴（自分の注文だけ見える）

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY order_owner_policy ON orders
USING (user_id = current_setting('app.user_id', true)::uuid);

これで SELECT * FROM orders を実行しても、ログイン中ユーザー本人の注文だけ返るようになります。

例2: SNSの下書き投稿（本人の下書きだけ見える）

ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY draft_owner_policy ON posts
USING (
  status = 'published'
  OR author_id = current_setting('app.user_id', true)::uuid
);

この場合、公開投稿は全員が見られますが、下書きは投稿者本人だけが見られます。

よくある誤解

• RLSがあれば全部安全
  → 管理者権限やバイパス設定の扱いを誤ると漏えいする
• RLSは性能に無関係
  → ポリシー条件列にインデックスがないと遅くなる

ベストプラクティス

1. RLSを有効化し、方針をテーブル間で統一する
2. ポリシー条件列（例: tenant_id, user_id, author_id）にインデックスを貼る
3. アプリ側の権限チェックも併用する（多層防御）
4. 監査ログを残す（誰が何にアクセスしたか）

パフォーマンスとスケーラビリティの注意

• データ量が増えると、ポリシー評価コストが効いてくる
• 複雑すぎるポリシーはクエリプランを悪化させやすい

ポリシーはシンプル + インデックス前提が安全です。

まとめ

RLSは、認可の最終防衛ラインです。
アプリ実装ミスを補う意味でも、マルチテナントでは導入価値が高いです。

学習リソース

• PostgreSQL Row Security Policies
  https://www.postgresql.org/docs/current/ddl-rowsecurity.html
• PostgreSQL CREATE POLICY
  https://www.postgresql.org/docs/current/sql-createpolicy.html