脅威モデリングとは？STRIDE手法でシステムの弱点を洗い出す実践ガイド

「うちのシステム、本当に大丈夫なのかどうか、どうやって確認すればいいんだろう」「セキュリティ対策はしているつもりだけど、見落としている穴があるんじゃないか」
情シス担当として日々の運用をこなしながら、そんな不安を抱えている方は少なくないはずです。場当たり的に対策を積み重ねていても、攻撃者が狙うのは意外な盲点だったりします。

この記事では、設計段階からシステムの脆弱な部分を体系的に洗い出す手法「脅威モデリング」と、実務で最も広く使われるSTRIDEフレームワークについて、現場で使えるレベルで解説します。ツールの準備も高価なコンサルも不要で、ホワイトボード1枚から始められる考え方です。

脅威モデリングとは？なぜ今これが重要なのか

脅威モデリング（Threat Modeling）とは、システムやアプリケーションに対して「攻撃者はどこを狙うか」を構造的に考え、設計の早い段階で脆弱性を発見・対処する手法です。

従来のセキュリティ対策は、システムが完成してからペネトレーションテスト（侵入テスト）を行うか、インシデントが起きてから対処するか、という後追い型が主流でした。しかしそのアプローチには根本的な問題があります。設計の欠陥は、後から修正するほどコストが跳ね上がるからです。

MicrosoftのSDL（セキュリティ開発ライフサイクル）研究によると、設計フェーズで発見されたセキュリティ欠陥の修正コストは、リリース後に発見されたものと比べて最大30倍安くなるとされています。脅威モデリングは、この「早期発見」を可能にするための道具です。

誰が対象か

「脅威モデリングは大企業や専門のセキュリティチームだけのもの」と思われがちですが、実際はそうではありません。社内システムの設計・改修・新機能追加を担当するインフラエンジニアや社内SEにとっても、十分に活用できる実践的なスキルです。情シス1人体制の中小企業でも、自社のシステム構成を把握しているなら今日から始められます。

STRIDEモデルとは？6つの脅威カテゴリを理解する

STRIDEはMicrosoftのLoren KohnfelderとPraerit Gargが1990年代末に考案した脅威分類フレームワークです。6つの脅威カテゴリの頭文字をつなげた名称で、現在も業界標準として広く使われています。

カテゴリ	英語	意味	侵害されるセキュリティ特性
Spoofing	なりすまし	正当な利用者・システムになりすます行為	認証（Authentication）
Tampering	改ざん	データやコードを不正に書き換える行為	完全性（Integrity）
Repudiation	否認	自分が行った操作を後から否定できてしまう状態	否認防止（Non-repudiation）
Information Disclosure	情報漏洩	本来見えてはいけない情報が外部に露出する状態	機密性（Confidentiality）
Denial of Service	サービス拒否	正当な利用者がサービスを使えなくなる状態	可用性（Availability）
Elevation of Privilege	権限昇格	本来持つべきでない権限を取得する行為	認可（Authorization）

この6カテゴリは、CIA三原則（機密性・完全性・可用性）を拡張した形になっており、セキュリティの基礎と直結しています。

各カテゴリを具体例で理解する

・Spoofing（なりすまし）: 盗んだAPIキーで外部サービスのAPIを叩く、フィッシングで得たパスワードで社内システムにログインする、ARPスプーフィングで通信相手を偽装するなど
・Tampering（改ざん）: データベースに格納された注文金額を書き換える、Webサイトのコンテンツを差し替える、ソフトウェアのバイナリに悪意あるコードを埋め込む、通信経路でHTTPレスポンスを書き換えるなど
・Repudiation（否認）: 操作ログが残っていないため「やっていない」と言われても証明できない、監査証跡が改ざん可能な状態にある、タイムスタンプが信頼できないなど
・Information Disclosure（情報漏洩）: エラーメッセージにスタックトレースが含まれる、S3バケットがパブリックになっている、デバッグ用のAPIエンドポイントが本番に残っている、ネットワーク通信が平文など
・Denial of Service（サービス拒否）: 大量リクエストによるサーバー過負荷、ファイルアップロード無制限によるディスク枯渇、認証失敗の繰り返しによるアカウントロックアウト（正規ユーザーを締め出す）など
・Elevation of Privilege（権限昇格）: 一般ユーザーがsudoの設定ミスを突いてrootになる、SUID/SGIDビットの悪用、JWTのalgヘッダー操作で管理者トークンを偽造するなど

STRIDE手法でシステムを分析する4ステップ

1. データフロー図（DFD）でシステムの全体像を描く

最初のステップは、システムを「データの流れ」として可視化することです。データフロー図（DFD: Data Flow Diagram）を使い、以下の4要素を洗い出します。

・外部エンティティ: システムの外側にいる人やシステム（ユーザー、外部API、別部署のシステムなど）
・プロセス: データを処理する機能やコンポーネント（Webアプリ、バッチ処理、認証サービスなど）
・データストア: データが保存される場所（データベース、ファイルサーバー、キャッシュなど）
・データフロー: 要素間でデータが移動する経路（HTTP通信、内部API呼び出し、DB接続など）

ホワイトボードや紙に手書きしたものでも構いません。「ユーザーがブラウザからWebサーバーにリクエストを送り、Webサーバーがデータベースを参照して結果を返す」という流れを図にするだけで、思いのほか多くの気づきが生まれます。

2. 信頼境界（Trust Boundary）を設定する

DFDを描いたら、次に「信頼境界」を引きます。信頼境界とは、セキュリティの信頼レベルが変わるポイントのことです。

インターネットと社内ネットワークの境界、一般ユーザーが操作できる領域と管理者権限が必要な領域の境界、異なるクラウドアカウント間の境界などが代表例です。

信頼境界をまたぐデータフローは、攻撃者にとって特に狙いやすいポイントです。「外部からの入力が境界をまたいで内部に届く部分」に重点的にSTRIDEを適用することで、分析の効率が上がります。

3. 各要素にSTRIDEを適用し、脅威リストを作成する

DFDの各要素（プロセス・データストア・データフロー）に対して、STRIDE6カテゴリを順番に適用し、「その脅威が実現可能か」を問い直します。

例として、「ユーザーログイン処理（認証APIプロセス）」にSTRIDEを当てはめると次のようになります。

STRIDE	具体的な脅威シナリオ	適用の有無
Spoofing	攻撃者が他人のパスワードを使ってログインする	あり（MFA未導入なら特に）
Tampering	ログインリクエストをプロキシで書き換えてロジックを回避する	あり（サーバー側検証が弱い場合）
Repudiation	ログイン成功・失敗のログが残っておらず、不正ログインを後から追跡できない	あり（ログ設計次第）
Information Disclosure	「このユーザーは存在しません」と「パスワードが違います」を別エラーで返し、アカウント存在を確認される	あり（よくある実装ミス）
Denial of Service	大量のログイン試行でサーバー高負荷、またはアカウントロックで正規ユーザーを締め出す	あり（レートリミット次第）
Elevation of Privilege	JWTのroleフィールドを書き換えて管理者権限を取得する	あり（署名検証が甘い場合）

これを全プロセス・全データストア・全データフローに対して行うと、「システム全体の脅威一覧」が完成します。

4. リスクを評価し、対策を優先順位付きで設計する

脅威がリストアップできたら、次は対策の優先度を決めます。よく使われる評価軸はDREAD（Damage・Reproducibility・Exploitability・Affected Users・Discoverability）で、各項目を1～3点で採点して合計スコアで優先度をつける方法です。

ただし中小企業の情シスに余裕がない場合は、シンプルに「発生可能性」×「被害の深刻さ」の2軸マトリクスで十分です。重要なのはリストアップした脅威を放置しないことで、スコアリングが完璧である必要はありません。

対策は「防止」「検知」「限定」「回復」の4方向で考えます。全ての脅威を100%防止するのは現実的ではないため、防止しきれない脅威については検知・限定・回復のレイヤーで備えることが現場のリアルな設計です。

中小企業でも今日からできること

フルスケールの脅威モデリングは、新規システム開発の設計段階でなければ難しいと思われるかもしれません。しかし既存システムに対してでも、小さなスコープから始めることは十分可能です。

まず対象を1つに絞ります。「社員が外部からVPN経由でアクセスするシステム」「新しく追加した決済フロー」「バックアップの仕組み」など、最近変更を加えた箇所や気になっている箇所に絞ってDFDを描いてみましょう。

・ステップ1（30分）: 対象システムのデータフロー図を紙に書く。外部からの入力・データの保存場所・出力の流れを整理する
・ステップ2（1時間）: STRIDE6カテゴリを順番に当てはめて「これはあり得るか？」を自問する。YES/NOではなく「実現した場合の影響」を書く
・ステップ3（30分）: 発見した脅威のうち「今すぐできる対策」を2～3件選んで対応する
・ステップ4（定期的）: システム変更のたびに同じプロセスを繰り返す

Linuxサーバーが絡む部分なら、SSHアクセスの経路・sudo権限の設計・ログの保存場所を起点にDFDを書くと、STRIDE適用のイメージが掴みやすくなります。Linuxのアクセス制御や権限管理の詳細は、姉妹サイトLinuxMaster.JPで実コマンド付きで解説しています。

よくある誤解と注意点

【誤解1】脅威モデリングはセキュリティの専門家しかできない

STRIDEのカテゴリを暗記していなくても、「なりすまされたら？」「データが書き換えられたら？」「ログが残らなかったら？」という問いかけを順番にするだけで、脅威モデリングの本質的な作業は行えます。最初は粗くて構いません。

【誤解2】一度やれば終わり

システムは常に変化します。新機能追加・インフラ変更・外部サービス連携のたびに、脅威の状況も変わります。脅威モデリングは、開発・運用のサイクルに組み込む「継続的なプロセス」として位置づけることが重要です。

【誤解3】脅威を全て洗い出さなければ意味がない

脅威を100%リストアップすることより、「これまで考えていなかった脅威を1つでも発見して対処する」ことに価値があります。完璧を目指して着手できないより、不完全でも回すほうが圧倒的に安全です。

【注意】攻撃手法の知識は防御目的で使う

STRIDE分析の過程で、具体的な攻撃シナリオを想定します。これは防御設計のために「攻撃者の目線を借りる」行為であって、実際の攻撃を行うことは不正アクセス禁止法（不正アクセス行為の禁止等に関する法律）の違反になります。自社のシステム以外への脅威モデリング演習を行う場合は必ず適切な許可を得てください。詳細は法律の専門家にご確認ください。

本記事のまとめ

ポイント	内容
脅威モデリングとは	システムの弱点を設計段階で構造的に洗い出す手法
STRIDEの6カテゴリ	なりすまし・改ざん・否認・情報漏洩・サービス拒否・権限昇格
4ステップ	DFD作成 → 信頼境界設定 → STRIDE適用 → 優先度付き対策設計
中小企業での始め方	対象を1つに絞り、2時間で回せる最小サイクルから
継続のコツ	完璧を目指さず、システム変更のたびに繰り返す

脅威モデリングは、高価なツールも専門資格も不要です。DFDを描いてSTRIDEの問いかけをするだけで、これまで見えていなかった盲点が浮かび上がってきます。まず手元の1システムを対象に、今週中に試してみてください。