threat-modeling

脅威モデリング — 実装前のセキュリティ設計

提案中の機能、システム、またはアーキテクチャに対して、体系的な脅威モデリングのセッションを実施します。これは設計時のセキュリティスキルであり、既存のコードを調査する監査とは異なります。設計ドキュメント、機能仕様、アーキテクチャ図はあるものの、コードはまだない場合に使用してください。

使用するタイミング：

• 認証、決済、マルチテナントデータ、または機密性の高い PII に関わる新機能
• 新しい外部連携（サードパーティ API、OAuth プロバイダー、Webhook 受信側）
• アーキテクチャに新しいサービス／マイクロサービスを追加する場合
• セキュリティ上重要なコンポーネントを大幅にリファクタリングする場合
• 主要なアーキテクチャ上の決定（イベント駆動とリクエスト／レスポンスの比較、モノリスの分割、AI 機能の導入など）を確定する前

関連項目：owasp-audit（ここで明らかになる脅威に対応するコードレベルのチェックリスト）、api-audit（API 固有のカテゴリ分類）、iam-audit（ID に関する判断は、すべての脅威モデルに関係します）。

承認

ユーザーが所有、構築、または評価を許可されているシステムを、ユーザーから提供された設計、図、コードに基づいてモデル化します。脅威モデリングは設計分析であり、何かをテストするものではありません。許可を得ずに、他者の製品の攻撃ツリーを作成してはいけません。

4 つの問い

Adam Shostack の考え方では、すべての脅威モデルが次の 4 つの問いに答えます。

1. 何に取り組んでいるのか？（スコープとモデル）
2. 何が問題になり得るか？（脅威）
3. それに対して何をするのか？（緩和策）
4. 適切に実施できたか？（検証）

このスキルでは、以降、それぞれの問いに順番に取り組みます。

ステップ 1 — 何に取り組んでいるのか？

次の 3 つのレベルのいずれかで、データフロー図（DFD）を作成します。

• レベル 0 — コンテキスト図。システムを 1 つのバブルで表し、すべての外部エンティティ（ユーザー、サードパーティ API、内部管理ツール）に線を引きます。「このシステムはそもそも何に接続しているのか？」を把握するときに使用します。
• レベル 1 — 主要なプロセス。認証サービス、API ゲートウェイ、プライマリデータストア、決済連携などを表します。ほとんどの機能レベルの脅威モデルで使用します。
• レベル 2 — 詳細なコンポーネントモデル。具体的なエンドポイント、テーブル、キューを表します。最も複雑な部分にのみ使用します。

有用な DFD には次の要素があります。

• 外部エンティティ（四角形） — ユーザー、サードパーティサービス、管理者
• プロセス（円） — 自社のサービス、関数、ハンドラー
• データストア（平行線／円筒形） — データベース、キャッシュ、Blob ストレージ、キュー
• データフロー（矢印。流れるデータのラベルを付けます） — リクエスト本文、トークン、ファイル、イベント
• 信頼境界（破線） — 境界を越える箇所はすべて、データを検証、認証、またはフィルタリングする場所です

信頼境界は最も有用な要素です。機能内のすべての信頼境界を示す図を 1 つだけ描けるなら、すでに作業の 60% は完了しています。

テキストのみの環境では、Mermaid で DFD を記述します。

flowchart LR
  User[User] -- HTTPS --> WAF[WAF / CDN]
  WAF -- request --> API[API Gateway]
  API -- JWT --> Service[Service]
  Service -- SQL --> DB[(Postgres)]
  Service -- HTTPS --> Stripe[Stripe]

  classDef trust fill:#fff,stroke:#f00,stroke-dasharray:4 4
  class API,Service trust

ステップ 2 — 何が問題になり得るか？（STRIDE）

各プロセス、データストア、データフローについて、STRIDE の各文字に対応する脅威カテゴリを 1 つずつ確認します。すべての要素にすべてのカテゴリが当てはまるわけではありません。それで問題ありません。

文字	脅威	侵害される特性	例
S	なりすまし	認証	盗まれたトークン、偽造 JWT、リプレイ攻撃、サービスへのなりすまし
T	改ざん	完全性	通信中のリクエストの変更、パラメーターの改ざん、保存データの変更
R	否認	否認防止	ユーザーが操作を否認するが、ログではその操作を行ったことを証明できない
I	情報漏えい	機密性	エラーメッセージ経由の漏えい、他のユーザーのデータを露出させる IDOR、公開された S3 バケット
D	サービス拒否	可用性	リソースの枯渇、高コストなクエリによる攻撃、有料の下流 API を介した課金額の上限到達
E	権限昇格	認可	マスアサインメント、BFLA、サンドボックスからの脱出によるユーザーから管理者への昇格

要素ごとの STRIDE

有用な脅威モデリングの習慣として、DFD の各要素について、短い表を作成します。

**Element:** API Gateway

| STRIDE | Threat | Likelihood | Impact |
|---|---|---|---|
| S | Forged JWT — symmetric secret in env, leaks if .env exposed | M | H |
| T | Request body modified between gateway and upstream service | L | M |
| R | Gateway access logs deleted by attacker post-breach | L | H |
| I | Verbose error responses expose internal hostnames | M | L |
| D | No rate limit at the gateway → upstream services overwhelmed | H | H |
| E | "X-Admin: true" header pass-through from external requests | L | C |

可能性と影響：L／M／H／C（Critical）です。定性的な評価で問題ありません。ほとんどの取り組みでは、定量的なスコアリングは見せかけにすぎません。

不正利用ケース（STRIDE と対になるもの）

ビジネスフローに懸念がある機能については、不正利用ケースも確認します。形式は次のとおりです。

As a malicious actor, I want to [goal] so that I can [outcome].

例：

• 悪意ある顧客として、同じクーポンコードを100回利用し、割引予算を使い果たしたい
• 競合他社として、すべての商品詳細を一括でスクレイピングし、カタログをコピーしたい
• 読み取りアクセス権を持つ内部関係者として、1年かけてすべての顧客の PII を抽出し、DLP アラートを発生させずに販売したい

不正利用ケースは STRIDE が見逃すものを捉えます。STRIDE は「セキュリティ特性が侵害された」状況の把握に優れ、不正利用ケースは「ビジネス上の意図が侵害された」状況の把握に優れています。

ステップ 3 — それに対して何をするか？

ステップ 2 で明らかになった脅威ごとに、次の4つの対応から1つを選びます。

• 軽減 — 可能性または影響を低減するコントロールを設計します
• 移転 — リスクをほかの誰かに移します（Stripe が PCI コンプライアンスを、Vercel が DDoS 対策を担います）
• 受容 — 残存リスクと、その根拠を文書化します
• 回避 — この方法では機能を構築せず、再設計します

軽減策は具体的である必要があります。

悪い軽減策	良い軽減策
「レート制限を追加する」	「/api/coupon/redeem にユーザー IP ごとに毎分5リクエストの制限を設け、Redis でカウンターを管理します。429 レスポンスをキューに入れ、アラートを発生させます」
「入力を検証する」	「制御文字（\t、\n、\0）、バックスラッシュ、またはパーセントエンコードされたスラッシュを含む ?next= URL を拒否します。new URL(target, ...).pathname で正規化します（owasp-audit A01 を参照）」
「データを暗号化する」	「AWS KMS 管理の CMK を使用したアプリケーションレベルの暗号化、行ごとのエンベロープ暗号化、90日ごとの鍵ローテーション、すべての Decrypt 呼び出しの監査ログを実装します」

よくある軽減パターン

• なりすまし → 強力なアイデンティティ — 有効期間の短いトークン、MFA、相互 TLS、署名付きリクエスト、ワークロード ID フェデレーション（iam-audit を参照）
• 改ざん → 整合性コントロール — HMAC、署名付き Cookie、通信時の暗号化、先行書き込みログ、イミュータブルなインフラストラクチャ
• 否認 → 監査ログ — イミュータブルな追記専用ログ、独立したログ記録用アカウント、ログ改ざんの試みに対するアラート
• 情報漏えい → 露出の最小化 — 最小権限の IAM、データ分類、保存時および転送時の暗号化、レコード全体ではなく DTO（api-audit API3 を参照）
• サービス拒否 → リソース制限 — レート制限、クォータ、クエリ深度の制限、課金アラーム、サーキットブレーカー
• 権限昇格 → 認可チェック — 一元化された can(user, action, resource)、デフォルト拒否、関連ルートの監査（owasp-audit の関連ルートを参照）

ステップ 4 — うまくできたか？

検証は次の3つの方法で行います。

1. 網羅性の確認 — DFD のすべての要素に STRIDE 表があり、すべての脅威に軽減策があり、すべての軽減策に担当者と期限が設定されていることを確認します。行の抜けが、最もよくある失敗です。
2. 敵対的な2回目のレビュー — 最初のセッションに参加していない人（または、このスキルの文脈では別のモデル）を招きます。「何を見落としたか」と尋ね、相関する盲点を崩すよう明示的に促します。owasp-audit の Second-Opinion Pass を参照してください。
3. テストへの追跡 — すべての High／Critical の軽減策に、テスト（ユニット、統合、本番監視でのカナリアテスト）があるべきです。テストを書けないのであれば、それは軽減策ではなく、単なる意図です。

脅威モデリングを行うべき場合（および行わなくてよい場合）

実施する価値がある場合：

• 新しい認証フロー／新しい決済連携／新しいサードパーティとのデータ交換
• マルチテナントのデータモデル
• 管理者機能、請求、または機密性の高い PII に関わるもの
• 大幅なアーキテクチャ変更
• AI 機能（prompt-injection を参照）

おそらく実施する価値がない場合：

• すでに十分にモデル化されているデータに対する内部 CRUD
• UI のみの変更
• 信頼境界を変更しないリファクタリング

判断基準：変更によって新たな信頼境界が導入される、既存の信頼境界が移動する、または信頼境界を越えるものが変わる場合は、脅威モデリングを行います。それ以外の場合は省略します。

出力形式

脅威モデルは一度きりのレポートではなく、継続的に更新されるドキュメントです。簡潔に保ち、レビューしやすくしてください。

# Threat Model: [Feature / System Name]
## Status: Draft / In Review / Approved
## Owner: [name]
## Date: [date]
## Reviewers: [names]

## 1. Scope
[2-3 sentences — what's in, what's out]

## 2. Data Flow Diagram
[Mermaid diagram or link to image]

## 3. Assumptions and constraints
- [Anything taken as given — e.g. "users authenticate via Okta, MFA enforced"]

## 4. Threats and mitigations
[STRIDE-per-element tables, then abuse cases]

## 5. Open questions
[Things we deferred or couldn't decide]

## 6. Decision log
[Material design decisions and why — including risks accepted]

## 7. Action items
| Item | Owner | Deadline | Status |
|------|-------|----------|--------|

別個のセキュリティトラッカーではなく、設計ドキュメントと一緒にリポジトリ内に保管してください。脅威モデルと実装の乖離は、最もよく見られる失敗の原因です。近くに置くことで、乖離を防ぎやすくなります。

境界

• このスキルが作成するのは計画用の成果物であり、攻撃ではありません
• 脅威モデルはリスクを明らかにするものであり、テストの権限を与えるものではありません。検証には web-pentest または owasp-audit と組み合わせてください
• 許可なく他者の製品の脅威モデルを作成しないでください（例：競合他社の攻撃ツリーを生成する）
• レビューや承認を受けない脅威モデルはノイズです。誰も読まないモデルをユーザーが作成している場合は、異議を唱えてください

参考資料

• Adam Shostack 著「Threat Modeling: Designing for Security」
• Microsoft の STRIDE 手法
• OWASP Threat Modeling Cheat Sheet
• OWASP pytm／threatspec（ツール）
• 「Threat Modeling Manifesto」（threatmodelingmanifesto.org）
• Mozilla Rapid Risk Assessment（RRA）フレームワーク
• NIST SP 800-154（Guide to Data-Centric System Threat Modeling）