脅威モデリング

システムに対する潜在的な脅威を体系的に特定 / 評価し、対策を設計するセキュリティ手法

セキュリティ設計

脅威モデリングとは

脅威モデリング (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 回で完成させるものではなく、設計が変わるたびに差分を更新する。

  1. システムの図を描く。データフロー図で構成要素 / データの流れ / 信頼境界 (信頼できる領域とできない領域の境目) を描く。信頼境界を越える矢印が脅威の発生点になる。
  2. 脅威を特定する。信頼境界を越える箇所ごとに STRIDE の 6 分類を当てはめ、該当する脅威を列挙する。
  3. リスクを評価する。影響度と発生しやすさの 2 軸で並べ、対策の優先順位を決める。
  4. 対策を設計する。脅威ごとに「防ぐ」「検知する」「受容する」のいずれかを決め、受容する場合は理由を記録する。
  5. 対策を検証する。設計した対策が実装や設定に反映されたかをテストとレビューで確認する。

データフロー図の例

サーバーレス構成のデータフロー図を簡略化して示す。信頼境界の外から入ってくるデータはすべて検証対象になる。

[ブラウザ] → 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 つの項目が複数の分類に関わることもある)。

OWASPSTRIDE
A05 インジェクションTampering
A07 認証の不備Spoofing
A01 アクセス制御の不備Elevation of Privilege
A04 暗号化の失敗Information Disclosure

いつ実施するか

  • 新しいシステムの設計時 (最も効果的)
  • 大きな機能追加時
  • セキュリティインシデント後の振り返り

実務での判断基準と落とし穴

  • 範囲を絞る。システム全体を一度に扱わず、信頼境界を越えるデータフローから着手する。網羅を目指して着手できないのがよくある失敗である。
  • 優先順位は採点で決める。影響度と発生しやすさを 3 段階程度で採点し、上位から対策する。採点の厳密さより、関係者が同じ基準で並べ替えられることを優先する。
  • 受容したリスクを記録する。対策しないと決めた脅威は理由と再検討の条件を残す。記録が無いと次の改修で同じ議論を繰り返す。
  • 図を更新し続ける。外部連携の追加や認証方式の変更があれば、変わった部分だけ再評価する。古い図に基づく脅威モデルは誤った安心感を生む。
  • 実装と突き合わせる。「対策済み」とした項目が実際の IAM ポリシーや WAF ルールに反映されているかを確認するまでが 1 サイクルである。

より深く学ぶには関連書籍が役立つ。

共有:

この記事は役に立ちましたか?

関連用語

関連する記事