脅威モデルと権限レビュー
security reviewでは、画面に見える機能ではなく、攻撃者が直接呼べるobject・identity・権限・データflowを列挙し、信頼境界ごとに壊します。
境界、transaction、並行制御、脅威、テスト、障害対応をFailure Firstで学ぶ。
先に学ぶ内容 — Prerequisite: 基礎 / 銀行システム学ぶこと — LEARNING GOALS
このページで学ぶこと
- Asset・Actor・Entry Pointの整理
- PostgreSQL権限の実効評価
- SECURITY DEFINERのreview方法
体験32 · THREAT MODELING（鍵束全体を調べる）
RLSが有効なら、他のDB権限は確認しなくても安全と言えるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の権限設定を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
RLS（Row Level Security）を有効にしておけば、他のDB権限は特に確認しなくても安全だと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
RLS以外に、schema権限やfunctionの実行権限もあることを思い出しましょう。
ヒント2を見る
ownerの強い権限は、RLSで制限できるでしょうか？
もっと詳しく：この問いで使う専門用語
- Effective privilegeは、roleが実際に到達・実行できる権限の合成結果です。
- Privilege escalationは、本来より強い権限を獲得・代理実行することです。
- Threat scenarioは、攻撃者・入口・操作・影響・防御を結んだ具体的な物語です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
脅威モデルは、守るasset・攻撃者・入口・trust boundaryを先に地図化します。
PostgreSQL securityはRLSだけでなく、schema・table・function・owner・default privilegeの合成結果です。
SECURITY DEFINERは強権限の代理実行なので、関数ごとにcaller・対象・名前解決・公開権限を確認します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Effective privilege
roleが実際に到達・実行できる権限の合成結果です。
個別GRANTだけ見てもowner・PUBLIC・継承を見落とします。
anon・authenticated・service_role・owner別にobject到達性を確認します。
Privilege escalation
本来より強い権限を獲得・代理実行することです。
金融操作や全顧客dataへ到達する危険があります。
definer RPC内の認可漏れやPUBLIC EXECUTEを攻撃経路として調べます。
Threat scenario
攻撃者・入口・操作・影響・防御を結んだ具体的な物語です。
抽象的な『securityを強化』をtest可能にします。
inactive adminが古いtokenでfreeze RPCを呼ぶscenarioを作ります。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
脅威モデルの順番
- 01守るassetを金額・個人情報・権限・証拠に分ける
- 02anon・顧客・inactive admin・service・ownerを列挙
- 03HTTP・RPC・table・function・storageを入口として列挙
- 04trust boundaryを跨ぐdata flowを書く
- 05なりすまし・改ざん・漏洩・二重処理を当てる
- 06予防・検知・復旧とtestへ変換
DB権限は重ね合わせて評価する
| 確認対象 | 危険な状態 | 確認方法 |
|---|---|---|
| Schema USAGE | private object名へ到達できる | role別schema privilege |
| Table privilege | RLS以前に直接DML可能、またはownerがbypass | GRANTとowner、FORCE RLS |
| Function EXECUTE | PUBLICの既定権限で強いRPCを呼べる | PUBLIC・anon・authenticated・service_role |
| SECURITY DEFINER owner | 強すぎるowner権限を代理実行 | function ownerと内部認可 |
| search_path | 攻撃者objectへ名前解決を誘導 | 固定pathとschema-qualified name |
| Default privilege | 将来objectが意図せず公開 | ALTER DEFAULT PRIVILEGES |
SECURITY DEFINER review checklist
- caller identityをDB内で取得し、引数のuser idを信用しない
- 対象recordのownership・role・active statusをlock後に確認
- search_pathを空または安全に固定し全objectをschema修飾
- dynamic SQLを避け、必要ならidentifierとvalueを安全に分離
- PUBLIC EXECUTEをrevokeし必要roleだけgrant
- 同じ操作の再送と並行実行を制御
- 成功・拒否・重要な失敗を監査可能にする
- 返す列とerrorに内部情報を含めない
攻撃演習
| 攻撃者 | 試すこと | 期待する防御 |
|---|---|---|
| anon | RPC名を推測して直接実行 | EXECUTE拒否または認証拒否 |
| 顧客A | 顧客Bのaccount idを指定 | DB内ownership検査で拒否 |
| inactive admin | 古いtokenで管理RPC実行 | 毎回active status確認 |
| 悪意ある入力 | 同名object・巨大値・未知field | 固定名前解決、validation、constraint |
| 内部service | 本来不要なtableへ直接write | 最小権限と専用RPC |
実際のMinibankでは
private schema、RLS、table privilege、SECURITY DEFINER RPC、actor separationを重ねています。『RLSがある』だけで判断せず、roleごとの到達経路を最後まで追います。
DB ownerやsuperuserは通常のapplication threat modelより強いため、運用上のcredential管理・職務分離・監査が別途必要です。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Effective privilegeの考え方を読んだところで、教材内の参照元で実際の権限設定を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずDB側の権限定義を見て、次に管理APIがどう認可を確認するかを見ます。RLS単体では防げないものを確かめましょう。
教材の参照元を確認する — Source Trail ↓RLS・GRANT・REVOKE・SECURITY DEFINER。PUBLIC EXECUTEの絞り込みを探します。
supabase/migrations/管理APIの認証・認可境界。
src/app/api/v1/admin/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜRLSが有効なだけでは安全と言い切れず、schema権限やSECURITY DEFINER関数のowner権限まで確認する必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Effective privilege」という言葉を使って書いてみましょう。
ヒント2を見る
なぜ複数の権限を重ねて評価する必要があるのか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Effective privilege、Privilege escalation、Threat scenarioの3つを使って、脅威モデルの考え方を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- RLSだけでは不十分だと説明できる
- 権限は複数の設定の合成結果だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1RLS enabledなら安全ですか？
いいえ。policy、table privilege、owner bypass、SECURITY DEFINER、function EXECUTEも確認します。
Q2search_path固定はなぜ必要ですか？
攻撃者が作った同名objectへ名前解決を誘導されないようにするためです。
Q3service_roleも通常顧客と同じ経路で使えますか？
強権限なので通常利用経路へ持ち込まず、用途・credential・到達objectを限定します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/RLS・GRANT・REVOKE・SECURITY DEFINER - 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/role別のprivilege regression - 現在の実装 — CURRENT IMPLEMENTATION
src/app/api/v1/admin/管理APIの認証・認可境界