マルチテナント境界と RLS

定義

複数の顧客企業 (テナント) が同一インフラを共有しつつ、データの物理的隔離を DB 層で強制する設計。PostgreSQL Row Level Security (RLS) により Backend コードの不具合があってもクロステナント漏洩を防ぐ二重化アーキテクチャ。

現在の理解

ACL 3 ロール (§3.10)

ロール	権限範囲
`system_admin`	自社管理。全テナント横断の閲覧・操作
`tenant_admin`	顧客管理者。自テナント内の全操作 (CSV 投入・API Key 発行・利用状況閲覧・采配操作)
`tenant_agent`	コールセンター従事者。自分に割り当てられた通話の応対・履歴閲覧のみ

パート・アルバイトは tenant_agent 運用想定
必要に応じ細粒化したロール追加可能な設計

RLS の実装 (§6.2)

全テーブルで tenant_id 必須
ALTER TABLE ... ENABLE ROW LEVEL SECURITY
ポリシー例:

CREATE POLICY tenant_isolation ON sessions
    USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

CREATE POLICY system_admin_all ON sessions
    USING (current_setting('app.current_role') = 'system_admin');

Backend は DB 接続時に SET app.current_tenant_id = '...' / SET app.current_role = '...' を実行
Drizzle ORM の middleware で自動化

二重防御

DB 層: RLS で物理強制
API/UI 層: ロールチェックを重ねる

スケール前提

メインターゲット: 200-400 名規模コールセンター
複数テナント同時稼働、累計数千同時通話
初期は 1〜数社から段階的拡大

論点

Backend の current_tenant_id 設定ミス: RLS は発動するが接続設定ミスで「NULL テナント」状態になるエッジケース。middleware の失敗時挙動を明示すべき
system_admin の監査: 全テナント閲覧可能なので、操作は audit_logs で残すが誤操作リスク高
read replica との整合性: 本番移行時に read replica を使う (NFR-SC-7) が、RLS 設定の同期は自動か確認必要
テナント削除時のカスケード: GDPR / 個人情報保護法対応のデータ削除 API (NFR-CM-4) との整合