3-5. 脅威モデリング - 設計段階で攻撃を予測する

所要時間: 50-70分（卒業課題込み） ゴール: STRIDE フレームワークを使って、自分の Web アプリに対する脅威を体系的に列挙・優先順位付けできる コミット内容: 自作TODO API の脅威モデリング結果を ~/learn/security/day35/threat_model.md にコミット（卒業課題）

前章とのつながり

このレッスンの位置づけ

セキュリティ章の 総まとめ・卒業課題 回。これまで学んだ全要素を 「事前に体系的に考える」 思考法に統合する。

1-1 で予告した STRIDE がついに本編

3-4: 起きた後の動き

本章 (3-5): 起きる前に予測する思考法

関連: 1-1〜3-4 のすべての技術を「STRIDE のどれに対応するか」で整理し直す

ここまで学んだ技術の総動員回。Level 1 の基礎、Level 2 の実装、Level 3 の運用が、設計段階の 1つの思考プロセス に統合される。

実害シーン: 設計段階で見落とした代償

Slack (2015): 「2FA は後で」と判断 → 従業員アカウント侵害で DB 流出。設計段階で「内部アカウントが侵害されたら？」を STRIDE で考えていれば防げた

多くの IoT 機器: デフォルトパスワード固定で出荷 → Mirai ボットネットに大量取り込み → 巨大 DDoS

多くの SaaS: マルチテナント設計時に「テナント間で ID 推測できる？」を考えず → IDOR 量産

Boehm の法則: 修正コストは 設計時1 / 実装時10 / 運用時100+。脅威モデリングは「運用で100払う問題を、設計で1で潰す」投資。

大前提: なぜ脅威モデリングを学ぶか

ここまでのレッスンは「攻撃から守る」具体技術。本レッスンは**「攻撃を予測する思考法」**。

ソフトウェア開発の流れ:

要件 → 設計 → 実装 → テスト → デプロイ → 運用

セキュリティを後付けすると、こうなる:

要件 → 設計 → 実装 → テスト → デプロイ → 運用 → [侵害発生] → 大改修
                                                    ↑
                                          ここで初めてセキュリティを考える
                                          → 数倍のコストと時間

設計段階でセキュリティを考えると、こうなる:

要件 → 設計（脅威モデリング） → 実装 → テスト → デプロイ → 運用
       ↑
       ここで「何が起きうるか」を予測 → 対策を設計に組み込む

修正コストは設計段階で1、実装で10、運用で100以上と言われる（Boehm の法則）。脅威モデリングは「設計段階で見えていなかった攻撃面」を可視化する作業。

実例:

Slack 2015年漏洩: 「2段階認証は後で実装」と判断 → その間に従業員アカウント侵害でDB流出。後から2FA実装したが信頼ダメージ大。設計段階で「内部アカウントが侵害されたら？」を考えていれば違った。
Capital One 2019: WAF + IAM の組み合わせ脆弱性。「IAM 認証情報が SSRF で取られたら？」を考えていれば、メタデータエンドポイントへのアクセス制限を入れられた。
Microsoft Threat Modeling: 2002年の「Trustworthy Computing」イニシアチブ以降、設計レビューで必ず脅威モデリングを実施するプロセスを導入。Windows のセキュリティが劇的に改善。

脅威モデリングは「やらない理由がない」工程。コードを書く前の30-60分で、後の数十時間〜数百時間のインシデント対応を防ぐ。

セッション①: STRIDE と攻撃面の特定（30-40分）

1. STRIDE - 6つの脅威カテゴリ

Microsoft が1999年に提唱、現在も世界中で使われる脅威分類フレームワーク。S/T/R/I/D/E の頭文字。

略	名前	意味	対策の方向
S	Spoofing	なりすまし（誰かのフリ）	認証
T	Tampering	改ざん（データ書き換え）	完全性検証
R	Repudiation	否認（やったことを認めない）	監査ログ
I	Information Disclosure	情報漏洩	機密性、暗号化
D	Denial of Service	サービス妨害	可用性、レート制限
E	Elevation of Privilege	権限昇格	認可、最小権限

STRIDE のうれしさ

「セキュリティを考えろ」だと無限に発散する。STRIDE で6つの観点に分割することで:

チェックリスト的に網羅できる

漏れを発見しやすい

「これは S と E の組み合わせ」のように分類して議論できる

設計思想: 「全ての脅威は6つのカテゴリのどれか」と捉える。完璧な分類ではないが思考の枠組みとして極めて有効。

2. 各カテゴリの具体例

S: Spoofing（なりすまし）

例:
- 他人のアカウントに不正ログイン
- セッションハイジャック
- 中間者攻撃（攻撃者がサーバーを偽装）
- メール送信元の偽装（SPF/DKIM 未設定）
- API トークンの盗用

対策の方向: 多要素認証、強力なパスワード、セッション固定攻撃対策、TLS、JWT 署名検証、API キーローテーション。

T: Tampering（改ざん）

例:
- HTTP リクエストのパラメータ改ざん（price=1000 を price=1 に）
- データベースの直接編集
- ログファイルの改ざん
- バイナリへのマルウェア注入
- メッセージ転送中の改変（中間者攻撃）

対策の方向: HTTPS、HMAC/署名、入力検証、データベース直接アクセス禁止、追記専用ログ、コードサイニング。

R: Repudiation（否認）

例:
- ユーザー「私は注文していない」と主張、しかしログがない
- 管理者「データを消したのは私じゃない」と主張、操作履歴がない
- 取引相手「契約に同意していない」と主張、署名がない

対策の方向: 監査ログ、デジタル署名、タイムスタンプ、改ざん不能なログ保存。法的紛争を想定した記録設計。

I: Information Disclosure（情報漏洩）

例:
- ユーザーのパスワード漏洩
- 個人情報漏洩
- ソースコード漏洩
- エラーメッセージから内部構造漏洩（スタックトレース、SQL文）
- バックアップファイルが公開ディレクトリに
- HTTP ヘッダから情報漏洩（Server: Apache/2.4.41 (Ubuntu)）

対策の方向: 暗号化（保管時・通信時）、アクセス制御、エラーメッセージの抽象化、最小公開原則、HTTPヘッダの最小化。

D: Denial of Service（サービス妨害）

例:
- DDoS で帯域・CPU 枯渇
- レート制限なしの API を連打して DB 過負荷
- ファイルアップロード機能で巨大ファイルを送り続けてディスク満杯
- 正規表現の Catastrophic Backtracking (ReDoS)
- 同じ重い検索クエリを並列実行

対策の方向: レート制限、リソースクォータ、タイムアウト、CDN/WAF、入力サイズ制限、CAPTCHA。

E: Elevation of Privilege（権限昇格）

例:
- 一般ユーザーが管理画面にアクセスできる
- 別ユーザーのデータを取得・編集できる（IDOR）
- アプリ権限から OS 権限へ（SQL injection 経由の RCE）
- コンテナから Host OS へ（コンテナエスケープ）
- 一般ロールが Cloud IAM の管理者ロールを取得

対策の方向: 厳密な認可チェック、最小権限の原則、ロールベースアクセス制御、コンテナのcapability制限、AppArmor/SELinux。

3. 攻撃面（Attack Surface）の特定

攻撃面 = 攻撃者と接する全ての境界

システムを「信頼境界線（trust boundary）」で区切り、信頼度が異なるゾーンの境界を攻撃面として列挙する。

典型的な境界:

インターネット ⇔ Webサーバー（最大の攻撃面）

Webサーバー ⇔ APIサーバー

APIサーバー ⇔ DB

認証済みユーザー ⇔ 未認証ユーザー

一般ユーザー ⇔ 管理者

自社ネット ⇔ 外部SaaS

コンテナ内 ⇔ ホスト

境界を越えるデータは全て検証。これが鉄則。

4. データフロー図（DFD）の書き方

脅威モデリングの基本ツール。システム内のデータの流れを可視化する。

              [信頼境界1: インターネット境界]
                       │
   ┌──────┐ HTTPS    ┌────────┐
   │ User │ ────────→│ Web LB │
   └──────┘          └────────┘
                          │
                  ┌───────┴───────┐
                  │               │
         [信頼境界2: アプリ層]
                  ↓               ↓
            ┌─────────┐    ┌─────────┐
            │ API #1  │    │ API #2  │
            └─────────┘    └─────────┘
                  │               │
            [信頼境界3: DB層]
                  ↓               ↓
            ┌─────────────────────┐
            │     PostgreSQL      │
            └─────────────────────┘

DFD の基本要素:

記号	意味
外部エンティティ（ユーザー、外部API）	四角
プロセス（API、Webサーバー）	円 / 角丸四角
データストア（DB、ファイル）	平行二重線
データフロー（矢印）	→
信頼境界	点線で囲む

DFDを描く粒度

第一階層 (Context Diagram): システム全体と外部の関係のみ

第二階層: 主要コンポーネント間

第三階層: 各コンポーネントの内部

初学者は第二階層までで十分。深掘りは必要に応じて。

5. STRIDE per Element（各要素に STRIDE を当てはめる）

DFD の各要素・各データフローに対して、**「この要素にどの S/T/R/I/D/E が成立しうるか」**を機械的にチェックしていく。

要素タイプ	適用可能な STRIDE
外部エンティティ	S, R
プロセス	S, T, R, I, D, E（全て）
データストア	T, R, I, D
データフロー	T, I, D

チェックの進め方
1. DFD を描く
2. 各要素について、上の表のSTRIDEを順に検討
3. 「このプロセスに Spoofing は可能か？」「Tampering は？」と機械的に問う
4. 「可能」となった脅威を記録（後で対策を考える）
例: ログインAPI（プロセス）

S: 他人のパスワードを当ててなりすまし → ブルートフォース対策必要

T: リクエスト改ざん → HTTPS、入力検証

R: ログインしたのに「してない」と主張 → 監査ログ必須

I: パスワード平文流出 → HTTPS、ハッシュ保存

D: ログイン連打で過負荷 → レート制限

E: 一般ログインから管理者権限獲得 → 認可チェック

セッション②: 優先順位付けと実例（25-30分）

6. リスク = 発生確率 × 影響度

脅威を全て列挙すると数百件出る。全てに対策すると時間が足りない。優先順位付けが必要。

リスク = 発生確率 × 影響度

	影響小	影響中	影響大
確率高	中	高	最高
確率中	低	中	高
確率低	極小	低	中

確率と影響の見立て方

発生確率:

インターネットからアクセス可能な機能: 高い（毎日攻撃される）

認証済みユーザーのみアクセス可能: 中

管理者ネットワーク内のみ: 低い

物理アクセス必要: 極低

影響度:

全ユーザーデータ漏洩: 致命的

個別ユーザーデータ漏洩: 大

サービス一時停止: 中

機能の一部停止: 小

表示ずれ: 極小

DREAD（補助フレームワーク）

Microsoft が提案したリスク評価。5項目を 1-10 でスコア化:

略	名前	意味
D	Damage	被害の大きさ
R	Reproducibility	再現の容易さ
E	Exploitability	悪用の容易さ
A	Affected users	影響ユーザー数
D	Discoverability	発見の容易さ

DREAD の使い方と限界

各項目1-10で評価 → 合計または平均でリスクスコア。

メリット: 数値化で比較可能 デメリット: 評価が主観的、Microsoft自身が現在は推奨していない（再現性に欠ける）

「数値出すための儀式」になりがちなので、素直に「高・中・低」の3段階で十分という実務派が多い。

7. 対策の選択肢

各脅威に対して、対策には4つの選択肢がある:

1. Mitigate（軽減）   - 対策を実装
2. Eliminate（除去）  - そもそも機能を削除
3. Transfer（転嫁）   - サードパーティに任せる（保険、外部認証）
4. Accept（受容）     - リスクを承知の上で対策しない

「受容」も正当な選択

全ての脅威に対策すると製品が完成しない。「リスクは認識した上で、コストが見合わないので受容する」も合理的。

例: 「政府機関レベルの国家アクターからの標的型攻撃」→ 一般企業が完全防御は無理。**何が起きたら何をするか（受容＋検知）**で対応。

重要なのは「意思決定したことを文書化する」こと。後から「気付かなかった」ではなく「意識して受容した」状態にする。

8. 脅威モデリングのタイミング

いつやるか

設計段階: 必ず（新機能、新サービス）

大きな変更時: 認証方式変更、外部連携追加、新規データ取扱

定期見直し: 半年〜年1回、既存システムを再評価

インシデント後: 同種の攻撃を防ぐためモデル更新

コードを書く前にやるのが最重要。書いてから「設計が間違ってた」と発覚すると修正コストが跳ね上がる。

9. 簡易版: 「もし悪用されたら？」の問いかけ

STRIDE まで重く感じる場合の最小版:

新機能を実装する前に、以下を自問:
 
1. この機能を悪用するとどうなる？
2. 攻撃者の立場で考えて、最初に試す攻撃は？
3. もし攻撃が成功したら、最悪何が起きる？
4. その最悪を防ぐ最小限の対策は？

「悪役の視点で考える」習慣

セキュリティエンジニアの基本姿勢は「攻撃者の気持ちになる」。

「この機能を悪用するとお金が儲かる？」

「この入力欄に何を入れたら壊れる？」

「この API を1分間に1万回叩いたらどうなる？」

「この URL のパラメータを変えたら他人のデータが見える？」

これを機能設計時の思考の癖にする。Code review でも同じ視点。

10. 実例: TODO API を STRIDE で分析

簡単な TODO API を想定:

ユーザー（インターネット）
  ↓ HTTPS
Webサーバー（Go / Gin）
  ├─ POST /api/todos       (タスク作成)
  ├─ GET  /api/todos       (一覧取得)
  ├─ PUT  /api/todos/:id   (更新)
  └─ DELETE /api/todos/:id (削除)
  ↓
PostgreSQL（user_id, title, content, due_date）

STRIDE で各要素を分析:

Webサーバー (プロセス) に対する STRIDE

脅威	具体例	対策	優先度
S	他人のJWTを盗用	HttpOnly Cookie, Secure flag, 短期有効期限	高
S	パスワード総当り	レート制限, アカウントロック, MFA	高
T	リクエストパラメータ改ざんで他人のtodo編集	サーバー側で owner チェック	最高
R	「削除してない」と主張	操作ログ全保存（user_id, action, timestamp）	中
I	エラーで内部情報漏洩	エラーメッセージ抽象化、stack trace 非表示	高
I	ヘッダから内部情報	`Server:` ヘッダ削除	低
D	POST 連打でDB圧迫	レート制限（IP別、ユーザー別）	高
E	一般ユーザーが他人のtodoを操作	全エンドポイントで authz チェック	最高

PostgreSQL（データストア）に対する STRIDE

脅威	具体例	対策	優先度
T	DBに直接アクセスして改ざん	DB アクセスを内部ネット限定、強パスワード	高
R	DB変更のログがない	DBサイドの audit log 有効化	中
I	DB ダンプ流出	暗号化（at rest）、バックアップアクセス制御	最高
D	重いクエリで全体ダウン	アプリ側でクエリタイムアウト、コネクションプール上限	高

データフロー (HTTPS) に対する STRIDE

脅威	具体例	対策	優先度
T	通信路で改ざん	HTTPS（TLS 1.2+）、HSTS	最高
I	通信路で盗聴	HTTPS、Perfect Forward Secrecy	最高
D	大量リクエスト	レート制限、CDN/WAF	高

この分析から見える最優先対策

認可チェックの徹底: 全ての /api/todos/:id で todo.user_id == auth.user_id を確認
HTTPS の強制: HTTP は受け付けない、HSTS ヘッダ
入力検証: title, content の長さ制限、SQL injection 対策（プリペアドステートメント）
レート制限: IP/ユーザー別の API レート制限
エラーハンドリング: 500エラー時にスタックトレース非表示
DB バックアップの暗号化

良い対策の例

// OK: 全ての操作で owner チェック
func deleteHandler(c *gin.Context) {
    todoID := c.Param("id")
    authUserID := c.MustGet("user_id").(string)
 
    var todo Todo
    if err := db.Where("id = ? AND user_id = ?", todoID, authUserID).First(&todo).Error; err != nil {
        // 「存在しない」と「他人の」を区別しない（情報漏洩防止）
        c.JSON(404, gin.H{"error": "not found"})
        return
    }
 
    db.Delete(&todo)
    logger.Info("todo_deleted",
        "user_id", authUserID,
        "todo_id", todoID,
    )
    c.JSON(204, nil)
}

アンチパターン: 認可チェックなし
// NG: ID だけで操作、認可チェックなし
func deleteHandler(c *gin.Context) {
    todoID := c.Param("id")
    db.Where("id = ?", todoID).Delete(&Todo{})
    c.JSON(204, nil)
}
なぜNGか:

/api/todos/123 を叩けば他人のtodoでも削除可能

これは IDOR (Insecure Direct Object Reference) という典型的脆弱性

認証はあるが認可がない、よくある事故

OWASP Top 10 の「Broken Access Control」筆頭

セッション③: ツールと運用（10-15分）

11. Microsoft Threat Modeling Tool

無料ツール。DFD を描いて自動的に STRIDE 脅威候補をリストアップ。

ダウンロード: https://aka.ms/threatmodelingtool
- Windows 専用（macは仮想環境かWeb版検討）
- Visio 風の UI で DFD を描く
- 要素をドラッグ → 自動的に脅威候補リスト生成
- Word 形式でレポート出力

12. OWASP Threat Dragon

OSS、Web/デスクトップ両対応、macOSでも動く。Microsoft Threat Modeling Tool の代替。

# macOS インストール例
brew install --cask threat-dragon
# または Web版
# https://www.threatdragon.com/

ツールを使うかどうか

小規模・初学者: 紙とペン、または markdown で表を書くだけで十分

中規模: OWASP Threat Dragon

大規模・規制業界: 専用ツール（Microsoft、IriusRisk、ThreatModeler）

「ツールがない」を言い訳にしない。テキストで書ける。

13. 脅威モデリングを「文化」にする

継続のコツ

PR テンプレに項目追加: 「セキュリティ影響: なし / 低 / 中 / 高 / 要 threat modeling」

設計レビューで必須: 機能設計レビュー時に「STRIDE 通した？」を聞く

新人研修に組み込み: 全エンジニアが基本を知っている状態に

定期見直しを予定化: 半年ごとに既存システムを再評価

小さく始める: 全システム一気にやらない。重要な機能から

完璧主義より継続主義。10%の脅威モデリングでも 0% より圧倒的に良い。

卒業課題: 自分の Web アプリを STRIDE で1ラウンド回す

課題

これまで Backend Master のレッスンで作ってきた（または自分が作っている）Web アプリに対して、以下を実施し ~/learn/security/day35/threat_model.md に書く:

# 脅威モデリング: <自分のサービス名>
 
## 1. システム概要
（1段落で説明）
 
## 2. データフロー図

（ASCII図 or 画像）

3. 信頼境界

境界A: <説明>
境界B: <説明>

4. 各要素の STRIDE 分析

コンポーネント1: <名前>

脅威	具体例	確率	影響	対策	状態
S	…	高	大	…	実装済 / 未実装 / 受容
T	…	中	中	…	…
R	…	低	小	…	…
I	…	高	大	…	…
D	…	中	中	…	…
E	…	高	大	…	…

コンポーネント2: <名前>

…

5. 優先対応事項

<最優先の対策と理由>
…

6. 受容するリスク

<受容したリスクと理由>

7. 次回見直し予定

期日: YYYY-MM-DD
トリガー: <大きな変更があった時 / 半年ごと>


### 提出基準

- 全コンポーネントに STRIDE 6項目を全て検討（「該当なし」も明記）
- 最優先対策を3つ以上抽出
- 受容するリスクを最低1つ明記（全部対策はあり得ない）
- 紙の上だけでなく、**最優先対策の1つは実コードに反映**

---

## 業界事例: Microsoft の Trustworthy Computing

2002年1月、Bill Gates は全社員に有名なメモを送った: **「セキュリティを機能より優先する」**。

きっかけは:
- Windows XP の Code Red、Nimda ワーム被害（数十億ドルの世界経済損失）
- 「Microsoft 製品はセキュリティが甘い」というイメージ確立

導入された変更:
- **Security Development Lifecycle (SDL)** 制定
- 全プロジェクトで**脅威モデリング必須**
- セキュリティ専門レビュー
- 数千人の開発者にセキュリティ教育（10時間以上）

結果:
- Windows Vista 以降、深刻な脆弱性が大幅減少
- Microsoft は「セキュリティ大手」へ転身（現在は Azure や Defender でセキュリティ事業展開）
- SDL は業界標準として広く採用

**教訓**: 脅威モデリングは「**個別プロジェクトの工程**」ではなく「**組織文化の一部**」にした時に最大効果。

---

## 締め: git で証跡を残す

```bash
cd ~/learn/security/day35
git add threat_model.md
git commit -m "feat(security): 自作Webアプリの脅威モデリング (STRIDE)"

# セキュリティ章 Level 3 完走の記念コミット
git log --oneline | head -20

チェックリスト

STRIDE の6つを略字込みで暗唱できる
各カテゴリの具体例を3個ずつ挙げられる
DFD を描いて信頼境界を引ける
STRIDE per Element の手順を理解した
リスク = 確率 × 影響の優先順位付けができる
「受容」も正当な選択であると理解した
自分のアプリで脅威モデリングを1ラウンド回した（卒業課題）
最優先対策をコードに反映した

詰まった時のチートシート

略	カテゴリ	主な対策
S	Spoofing	認証、MFA、TLS
T	Tampering	HTTPS、署名、入力検証
R	Repudiation	監査ログ、デジタル署名
I	Information Disclosure	暗号化、アクセス制御、エラーメッセージ抽象化
D	Denial of Service	レート制限、リソース上限、CDN/WAF
E	Elevation of Privilege	認可、最小権限、ロール分離

要素別の STRIDE 適用範囲:

要素	適用
外部エンティティ	S, R
プロセス	S, T, R, I, D, E
データストア	T, R, I, D
データフロー	T, I, D

「実務OK」基準

新機能設計時に「STRIDE 通した？」が口癖になる
DFD を30分で描ける
STRIDE per Element で機械的に脅威列挙できる
リスク評価で優先順位付けし、「受容」も判断できる
「うちは狙われない」と言う人を3つの実例で論破できる
チームに脅威モデリング文化を広められる

さらに深掘りするなら

公式: OWASP Threat Modeling Cheat Sheet
ツール: OWASP Threat Dragon
ツール: Microsoft Threat Modeling Tool
書籍: 『Threat Modeling: Designing for Security』Adam Shostack - この分野のバイブル
書籍: 『Threat Modeling: A Practical Guide for Development Teams』 - 実務向け
フレームワーク: PASTA (Process for Attack Simulation and Threat Analysis) - STRIDE より重厚な代替
フレームワーク: LINDDUN - プライバシー特化の脅威モデリング

メタ認知: 自分の理解度を診断する

30秒セルフテスト

STRIDE の6項目を順に

データフロー図 (DFD) で 信頼境界 を引くべき場所の例3つ

DREAD で優先順位付けする時の5要素

「Misuse Case」と「Use Case」の違い

脅威モデリングをいつやるべきか（設計フェーズ・新機能・定期見直し）

詰まったら → STRIDE 各項目に Level 1-2 で学んだ攻撃を マッピングし直す 演習をやる。これが最高の総復習。

セキュリティ章完走の振り返り（メタ認知）

セキュリティ章全17レッスンで身につけたこと

Level 1 - 基礎概念 (1-1〜1-6): 認証/認可・パスワード保存・HTTPS・OWASP・SQLi・XSS Level 2 - 実装 (2-1〜2-6): JWT・セッション・CSRF/SSRF・シークレット・入力検証・認可設計 Level 3 - 運用 (3-1〜3-5): サーバーhardening・依存スキャン・ログ監視・インシデント対応・脅威モデリング

3層が揃って初めて「実務で使えるセキュリティエンジニア」。

自己評価:

OWASP Top 10 を1分で説明できる

新規VPSを30分でハードニングできる

JWT vs セッションを要件から判断できる

SQLi / XSS / CSRF / SSRF をコードで防御できる

自作サービスに STRIDE で脅威モデリングを適用した

インシデント Runbook を持っている

セキュリティ章 Level 3 完走

ここまでで Backend Master セキュリティ章 Level 3（運用フェーズ）が完走。学んだことを振り返る:

サーバーハードニング: 新規VPSを30分で本番運用に耐える状態へ
依存スキャン: サプライチェーン攻撃から守る自動化
ログと監視: 起きていることに気付く力
インシデント対応: 起きた時の最初の30分で勝負を決める
脅威モデリング: 起きる前に予測する思考法

これら5つが揃って初めて「運用できるセキュリティエンジニア」。Level 1（基礎概念）、Level 2（実装）、Level 3（運用）の3層が完成した。

次は他の章（インフラ、Go、Linux）と組み合わせて、**「セキュアな本番運用ができるバックエンドエンジニア」**として総合力を磨いていく段階。

卒業後の間隔反復計画

週1回: 各章の「詰まった時のチートシート」を1分で眺める

月1回: 自分のサービスの脅威モデルを更新（STRIDE で見直す）

3ヶ月毎: Runbook を机上演習で走らせて穴を見つける

半年毎: 新しい OWASP Top 10 / 主要 CVE を追跡（業界はゆるやかに動く）

セキュリティは 継続して触り続けないと劣化する 領域。この章を「読んで終わり」にせず、運用に取り込めば本物の戦力になる。

バックエンドマスター

エクスプローラー

3-5_脅威モデリング

3-5. 脅威モデリング - 設計段階で攻撃を予測する

前章とのつながり

大前提: なぜ脅威モデリングを学ぶか

セッション①: STRIDE と攻撃面の特定（30-40分）

1. STRIDE - 6つの脅威カテゴリ

2. 各カテゴリの具体例

S: Spoofing（なりすまし）

T: Tampering（改ざん）

R: Repudiation（否認）

I: Information Disclosure（情報漏洩）

D: Denial of Service（サービス妨害）

E: Elevation of Privilege（権限昇格）

3. 攻撃面（Attack Surface）の特定

4. データフロー図（DFD）の書き方

5. STRIDE per Element（各要素に STRIDE を当てはめる）

セッション②: 優先順位付けと実例（25-30分）

6. リスク = 発生確率 × 影響度

DREAD（補助フレームワーク）

7. 対策の選択肢

8. 脅威モデリングのタイミング

9. 簡易版: 「もし悪用されたら？」の問いかけ

10. 実例: TODO API を STRIDE で分析

Webサーバー (プロセス) に対する STRIDE

PostgreSQL（データストア）に対する STRIDE

データフロー (HTTPS) に対する STRIDE

この分析から見える最優先対策

セッション③: ツールと運用（10-15分）

11. Microsoft Threat Modeling Tool

12. OWASP Threat Dragon

13. 脅威モデリングを「文化」にする

卒業課題: 自分の Web アプリを STRIDE で1ラウンド回す

課題

3. 信頼境界

4. 各要素の STRIDE 分析

コンポーネント1: <名前>

コンポーネント2: <名前>

5. 優先対応事項

6. 受容するリスク

7. 次回見直し予定

チェックリスト

詰まった時のチートシート

「実務OK」基準

さらに深掘りするなら

メタ認知: 自分の理解度を診断する

セキュリティ章 完走の振り返り（メタ認知）

セキュリティ章 Level 3 完走

グラフビュー

目次

バックリンク

セキュリティ章完走の振り返り（メタ認知）