脅威モデリング
システムに対する潜在的な脅威を体系的に特定 / 評価し、対策を設計するセキュリティ手法
脅威モデリングとは
脅威モデリング (Threat Modeling) は、システムに対する潜在的な脅威を体系的に特定 / 評価し、設計段階で対策を組み込むセキュリティ手法である。「何を守るか」「誰が攻撃するか」「どう攻撃されるか」「どう防ぐか」を構造的に分析する。
STRIDE モデル
Microsoft が開発した脅威の分類フレームワーク。6 種類の脅威の頭文字をとった名称で、洗い出した脅威を漏れなく分類するための共通語彙として使う。
| 脅威 | 説明 | 対策例 |
|---|---|---|
| Spoofing (なりすまし) | 他人になりすます | 認証 (Cognito, MFA) |
| Tampering (改ざん) | データを不正に変更 | 整合性チェック (署名, ハッシュ) |
| Repudiation (否認) | 行為を否定する | 監査ログ (CloudTrail) |
| Information Disclosure (情報漏洩) | 機密データの流出 | 暗号化 (KMS, TLS) |
| Denial of Service (サービス拒否) | サービスを利用不能にする | WAF, レート制限 |
| Elevation of Privilege (権限昇格) | 権限を不正に取得 | 最小権限 (IAM) |
脅威モデリングの手順
脅威モデリングは次の 5 段階を繰り返す。1 回で完成させるものではなく、設計が変わるたびに差分を更新する。
- システムの図を描く。データフロー図で構成要素 / データの流れ / 信頼境界 (信頼できる領域とできない領域の境目) を描く。信頼境界を越える矢印が脅威の発生点になる。
- 脅威を特定する。信頼境界を越える箇所ごとに STRIDE の 6 分類を当てはめ、該当する脅威を列挙する。
- リスクを評価する。影響度と発生しやすさの 2 軸で並べ、対策の優先順位を決める。
- 対策を設計する。脅威ごとに「防ぐ」「検知する」「受容する」のいずれかを決め、受容する場合は理由を記録する。
- 対策を検証する。設計した対策が実装や設定に反映されたかをテストとレビューで確認する。
データフロー図の例
サーバーレス構成のデータフロー図を簡略化して示す。信頼境界の外から入ってくるデータはすべて検証対象になる。
[ブラウザ] → HTTPS → [CloudFront] → [API Gateway] → [Lambda] → [DynamoDB]
↓
[Cognito] (認証)
信頼境界:
├── 外部 (ブラウザ) ← 信頼しない
└── 内部 (Lambda, DynamoDB) ← 信頼する
AWS での脅威と対策
STRIDE の分類のうち代表的なものを AWS 上の具体的な攻撃例と対策に対応させると次のようになる。
| 脅威 | 攻撃例 | AWS での対策 |
|---|---|---|
| なりすまし | 盗まれたトークンで API 呼び出し | Cognito + MFA |
| 改ざん | API リクエストの改ざん | API Gateway のリクエスト検証 |
| 情報漏洩 | S3 バケットの公開設定ミス | S3 Block Public Access |
| DoS | 大量リクエスト | WAF + API Gateway スロットリング |
| 権限昇格 | Lambda の過剰な IAM 権限 | 最小権限ポリシー |
OWASP Top 10 との関係
OWASP Top 10 は Web アプリケーションで重大なセキュリティリスクの上位 10 項目をまとめた文書で、改訂で項目の名称や構成が変わることがある。脅威モデリングで脅威を洗い出すときのチェックリストとして使える。STRIDE との対応の一例を 2025 年版の項目に対応させて示す (1 つの項目が複数の分類に関わることもある)。
| OWASP | STRIDE |
|---|---|
| A05 インジェクション | Tampering |
| A07 認証の不備 | Spoofing |
| A01 アクセス制御の不備 | Elevation of Privilege |
| A04 暗号化の失敗 | Information Disclosure |
いつ実施するか
- 新しいシステムの設計時 (最も効果的)
- 大きな機能追加時
- セキュリティインシデント後の振り返り
実務での判断基準と落とし穴
- 範囲を絞る。システム全体を一度に扱わず、信頼境界を越えるデータフローから着手する。網羅を目指して着手できないのがよくある失敗である。
- 優先順位は採点で決める。影響度と発生しやすさを 3 段階程度で採点し、上位から対策する。採点の厳密さより、関係者が同じ基準で並べ替えられることを優先する。
- 受容したリスクを記録する。対策しないと決めた脅威は理由と再検討の条件を残す。記録が無いと次の改修で同じ議論を繰り返す。
- 図を更新し続ける。外部連携の追加や認証方式の変更があれば、変わった部分だけ再評価する。古い図に基づく脅威モデルは誤った安心感を生む。
- 実装と突き合わせる。「対策済み」とした項目が実際の IAM ポリシーや WAF ルールに反映されているかを確認するまでが 1 サイクルである。
より深く学ぶには関連書籍が役立つ。
この記事は役に立ちましたか?
関連用語
ゼロトラスト
ネットワークの内外を問わず全てのアクセスを検証し、暗黙の信頼を排除するセキュリティモデル
セキュリティヘッダー
HTTP レスポンスヘッダーでブラウザーのセキュリティ機能を制御し、XSS やクリックジャッキングを防ぐ仕組み
IAM
AWS のアクセス管理サービスで、誰が何のリソースにどのような操作を行えるかを制御する
OWASP
Web アプリケーションセキュリティのベストプラクティスを提供するオープンコミュニティ
Security
情報やシステムを脅威から守り、機密性 / 完全性 / 可用性を維持する取り組み
IAM (概念)
Identity and Access Management の一般概念で、認証と認可を管理する仕組み
関連する記事
セキュリティ本ガイド - Web 開発者が読むべき技術書の選び方
Web セキュリティの基礎から実践まで学べる技術書の選び方マトリクスと、読了後にやるべき 3 つのアクションを紹介します。
AWS 本の選び方 - 全体像 / 構築 / 設計 / 運用 / セキュリティの 5 視点
AWS を学ぶ技術書の選び方を「全体像 / 構築 / 設計 / 運用 / セキュリティ」の 5 視点で整理。公式ドキュメントと本の役割分担、資格対策書の位置づけまで、2026 年 8 月時点の定番書で AWS 独学のルートを解説します。
体系的に学ぶ 安全な Web アプリケーションの作り方 第 2 版は初版と何が違うか - 買い直し判断ガイド
通称「徳丸本」こと体系的に学ぶ 安全な Web アプリケーションの作り方 第 2 版 (2018 年) と初版 (2011 年) の違いを出版社公表の改訂内容から整理。章の削除 / 新設 / 追加点の一覧と、初版所有者が買い直すべきかの判断基準を解説します。