脅威モデリング：STRIDEを非エンジニアが回す

第8章で描いたデータフロー図には、まだ「誰が、何を、どうやって狙うか」が書かれていません。それを体系的に書き足す作業が脅威モデリング（threat modeling）です。専門家は4つの問いとSTRIDEという6分類を使います。この章では、その道具を経理の不正・事故に置き換えて理解し、自分の図に当てはめて上位3つの脅威を決めるところまでやります。

脅威モデリングとは：4つの問い

脅威モデリングは、作る前、あるいは公開する前に、「何が起こりうるか」を順序立てて洗い出す作業です。この分野で最も広く使われている枠組みが、Adam Shostack氏（2014年の著書「Threat Modeling: Designing for Security」で知られる）がまとめた4つの問いです。原文はきわめて短く、次の通りです。

1. What are we working on?（何を作っているのか）
2. What can go wrong?（何が間違いうるのか）
3. What are we going to do about it?（それに対して何をするのか）
4. Did we do a good job?（十分だったか）

OWASPのThreat Modeling Cheat Sheetも、この4つの問いを出発点にしています（4つ目は「Did we do a good enough job?」という表現で引用されています）。注目すべきは、技術の言葉が一つも入っていないことです。経理の内部統制の整備も、同じ順番で進みます。業務フローを描き、リスクを洗い出し、統制を置き、運用評価で確かめる。第8章で描いた全体図は、1つ目の問いの答えでした。この章は2つ目と3つ目、そして次章以降が4つ目に当たります。

STRIDE：6種類の「間違い方」

「何が間違いうるのか」を白紙から考えると、思いついたものしか出てきません。STRIDEは、脅威を6種類に分け、「この矢印に、この6種類のうちどれが起こりうるか」と機械的に問うための分類です。頭文字をつなげたものがSTRIDEです。OWASPのCheat Sheetは、各脅威が「どの性質を壊すか」を次のように整理しています。経理の例を右側に添えました。

第10章で扱った「認証」と「認可」の区別が、ここではSとEの区別として現れます。第1章の論文で最多だった「アクセス制御の不備」（339件、28.58%）は、STRIDEで言えばIとEの組み合わせです。「認証の不備」（176件）はS、「暗号化の不備」（112件）は主にIとTに関わります。応用編で学んだ分類が、ここでは「起きうること」の側から見直されます。

データフロー図の矢印に、STRIDEを当てる

手順は単純です。第8章の図で、信頼境界をまたぐ矢印を1本選びます。その矢印について、S・T・R・I・D・Eの6つを順に「この矢印で、これは起こりうるか」と問います。起こりうるなら一言で書き、起こりえないなら「該当なし」と書きます。これを矢印の本数だけ繰り返します。

図を見ると、ブラウザからサーバーへ入る矢印に脅威が集中しています。第8章で「境界をまたいで入ってくる矢印が点検箇所」と言った理由がここにあります。一方、R（否認）は矢印ではなく、サーバーの「記録」の有無に付きます。ASVS 5.0のV16（セキュリティログとエラー処理）がL2以上に置かれているのは、Rへの対策が「第一線の防御」というより「あとで説明責任を果たすための備え」だからです。

ミニ銀行で、「振込」の矢印にSTRIDEを当てた例を示します。

• S：他人のセッションで振込が送られうるか。対策はセッションの扱い（ASVS 7.2、7.4）。
• T：送信中に金額や振込先が書き換えられうるか。対策はTLS（12.2.1）と、サーバー側での金額・残高の再検証（2.2.2）。
• R：誰が、いつ、いくら振り込んだかが残らないか。対策はサーバー側での操作記録（V16）。
• I：応答に、他人の口座情報が混ざらないか。対策は必要な項目だけを返す（15.3.1）。
• D：同じ振込を大量に送りつけられて止まらないか。対策は回数制限（6.1.1の文書化と実装）。
• E：一般利用者が他人の口座から振り込めるか。対策はサーバー側の所有者確認（8.2.2、8.3.1）。

攻撃ツリー：目標から手段へ

STRIDEが「矢印から脅威へ」の道具だとすると、攻撃ツリー（attack tree）は「攻撃者の目標から手段へ」と逆向きにたどる道具です。根に「攻撃者が達成したいこと」を置き、枝に「それを達成する手段」を並べ、葉まで分解します。経理の不正リスク評価で「横領」を根に置き、「架空仕入」「小口現金の抜き取り」「振込先の差し替え」と手段を枝分かれさせるのと同じ発想です。

ミニ銀行で「他人の残高を見る」を根にした木を、概念の段階だけで描くと次のようになります。葉は「〜できてしまう状態」で書き、具体的な手順は書きません。手順を知らなくても、どの枝を塞ぐべきかは判断できます。

• 他人の残高を見る
  • 他人としてログインする（S）
    • 短い・使い回しのパスワードが受け付けられる状態（対策：6.2.1、6.2.4、二要素認証）
    • ログアウト後もセッションが生きている状態（対策：7.4.1）
  • 自分としてログインし、他人のデータに届く（E・I）
    • URLのIDを変えると他人の記録が返る状態（対策：8.2.2）
    • 管理者専用の処理がログインだけで呼べる状態（対策：8.2.1）
    • RLSが無効なテーブルが公開用の鍵で読める状態（対策：第10章のRLS）
  • アプリを通さずに読む（I）
    • 管理用の鍵がコードやGitの履歴に残っている状態（対策：第9章）
    • エラー画面やログに残高が出る状態（対策：第12章、V16）

この木を見ると、実践編の演習がどの枝を塞いでいたかが分かります。逆に、まだ塞いでいない葉があれば、それが次の点検項目です。

優先順位：発生可能性×影響度

脅威を洗い出すと、たいてい十数個以上になります。全部に同じ力を注ぐことはできません。OWASPのCheat Sheetは「理屈のうえでは、発生可能性と影響度の掛け算で順位を付ける」と述べ、同時に「両方とも正確に計算するのは難しい」とも認めています。

より細かく評価したいときのために、OWASP Risk Rating Methodology（OWASPリスク評価手法）があります。発生可能性を「攻撃者側の要因」（技能、動機、機会、人数）と「脆弱性側の要因」（発見のしやすさ、悪用のしやすさ、知られている度合い、検知のされにくさ）で、影響度を「技術的影響」（機密性、完全性、可用性、説明責任の損失）と「業務上の影響」（金銭的損害、評判、法令違反、プライバシー侵害）で、それぞれ0〜9で採点します。平均を取り、3未満を低、3以上6未満を中、6以上を高とし、次の表で最終的な深刻度を決めます。

経理のリスク評価で「発生可能性×金額的影響」のマトリクスを作るのと同じ構造です。非エンジニアが個人開発で使うなら、0〜9の採点までは要りません。「発生可能性：高・中・低」「影響度：第8章の資産の表で大・中・小」の2軸で十分です。影響度が「大」の資産に届く脅威は、発生可能性にかかわらず上位に置いてください。

あなたは脅威モデリングの相手役です。私のアプリの全体図をもとに、一緒に脅威を洗い出してください。

私のアプリ：
- 登場人物：（例：利用者、管理者）
- 画面：（例：ログイン、口座一覧、振込、取引履歴、管理画面）
- サーバー処理：（例：残高取得、振込実行、利用者一覧）
- データベースのテーブル：（例：利用者、口座、取引）
- 外部サービス：（例：Supabase Auth、メール送信）
- 預かっている資産と重さ：（例：メールアドレス＝大、残高＝中〜大）

お願い：
1. 信頼境界をまたぐ矢印を一覧にしてください（ブラウザ→サーバー、サーバー→外部サービス、外部サービス→サーバー）
2. 矢印1本ごとに、STRIDEの6分類それぞれについて「起こりうる脅威」を一言で書いてください。起こりえないものは「該当なし」と理由を書いてください
3. 各脅威に、発生可能性（高・中・低）と影響度（大・中・小）を付け、理由を一言添えてください
4. 上位5つを選び、それぞれにOWASP ASVS 5.0の関連する要件番号と、対策の方針を添えてください
5. 対策の方針は「〜を確認する」「〜をサーバー側で検証する」のように、守る側の言葉で書いてください。攻撃の具体的な手順や攻撃用の文字列は書かないでください

最後に、私に確認すべき「業務上の決め事」（誰に何が許されるべきか）があれば、質問として列挙してください。