第2章 脅威モデリング — STRIDEとデータフロー図

2.1 脅威モデリングとは

脅威モデリングとは、システムを作る(あるいは変更する)前に、「どこが、どんな攻撃にさらされ得るか」を構造的に洗い出し、対策を設計に織り込む作業です。攻撃を受けてから慌てて対処するのではなく、設計図の段階で攻撃者になりきって弱点を探します。第1章で触れた「攻撃者視点と防御者視点の往復」を、開発プロセスの中で制度化したものだと考えてください。

難しく考える必要はありません。脅威モデリングは、次の4つの問いに順番に答えていく営みに集約できます。この4つは Adam Shostack が広めた枠組みで、実務でも標準的に使われます。

重要なのは、これが一度きりの儀式ではなく、設計が変わるたびに回す反復作業だという点です。新しいAPIを1本足す、外部SaaSと連携する、といった変更のたびに「②何がうまくいかなくなり得るか」を問い直します。完璧な網羅を目指すより、チームで対話しながら「見落としていた脅威に気づく」ことに価値があります。

2.2 データフロー図(DFD)と信頼境界

脅威を洗い出す前に、まず「何を作っているのか」を目に見える形にします。そのための道具がデータフロー図(Data Flow Diagram, DFD)です。DFDは以下の5種類の要素だけで、システム内をデータがどう流れるかを表現します。

この中でセキュリティ上もっとも重要なのが信頼境界(trust boundary)です。信頼境界とは、「ここから内側と外側では、データやリクエストの信頼度が違う」という境目を指します。たとえば「インターネット」と「自社のWebサーバー」の間、「Webサーバー」と「データベース」の間、「一般ユーザー権限」と「管理者権限」の間などです。

脅威は、境界を越えるところに集中します。境界の外から来るデータは信頼できないため、境界を越える瞬間こそ検証・認証・認可・サニタイズを行うべき地点です。DFDを描いたら、まず信頼境界に印をつけ、その線を横切るデータフローを重点的に見ます。「この矢印は、信頼できない側から来ていないか?」——これが脅威発見の出発点です。

2.3 STRIDE — 脅威を体系的に洗い出す

DFDで対象が見えたら、次は「何がうまくいかなくなり得るか」を洗い出します。ここで思いつきに頼ると必ず抜けが出ます。そこで、STRIDEという6分類のチェックリストを使い、各要素・各データフローに対して機械的に問いかけます。STRIDEは6つの脅威カテゴリの頭文字です。

STRIDEの美点は、入門で学んだCIA・認証・認可ときれいに対応していることです。SはCIAでいう認証(なりすまし対策)、Tは完全性、Iは機密性、Dは可用性、Eは認可、Rは否認防止です。「この要素はSpoofingされ得るか?Tamperingは?…」と6問ずつ問いかけるだけで、CIAの全方向を漏れなく点検できます。

実務では、DFDの要素ごとに「効きやすいSTRIDE」が決まっていることを利用すると効率的です。たとえば外部エンティティは主にS(なりすまし)とR(否認)、データフローは主にT・I・D、データストアはT・I・D(場合によりR)、プロセスは6種すべてが対象になります。この対応を頭に入れておくと、洗い出しが速くなります。

2.4 実践 — シンプルなWebアプリを脅威モデリングする

具体例で通しでやってみましょう。題材は「利用者がブラウザからログインし、自分のプロフィールを閲覧・編集できる」ごく一般的なWebアプリです。構成は次のとおりとします。

[利用者(ブラウザ)]  --- HTTPS --->  [Webアプリ(プロセス)]  --- SQL --->  [DB(データストア)]
       外部エンティティ                    プロセス                         データストア

信頼境界①: インターネット / アプリサーバー(利用者とWebアプリの間)
信頼境界②: アプリサーバー / データ層(WebアプリとDBの間)

まず信頼境界①(利用者→Webアプリ)に注目し、この境界をまたぐ「ログインリクエスト」というデータフローにSTRIDEを当てていきます。

次に信頼境界②(Webアプリ→DB)を見ます。ここで代表的なのはT(SQLインジェクションによる改ざん)とI(情報漏えい)です。SQLインジェクション自体は入門コース第10章の既知の話ですが、脅威モデリングの価値は「どのデータフローにその脅威が乗るか」を設計図上で特定できる点にあります。対策(プレースホルダ、DBアカウントの最小権限)を、この矢印に対して明示的に割り当てます。

2.5 洗い出した脅威にどう対応するか

脅威をすべて潰そうとするとコストが無限に膨らみます。第1章の「リスク = 発生可能性 × 影響度」に立ち返り、優先順位をつけて対応方針を選びます。個々の脅威に対して取れる選択肢は、原則として次の4つです。

ありがちな誤りは「すべて緩和しなければ」と気負うことです。実務では、影響度の低い脅威を意識的に受容する判断も立派なセキュリティ設計です。大切なのは、受容したことを記録し、根拠を説明できる状態にしておくこと。監査や事故のとき、「知らなかった」のか「理解した上で受け入れた」のかは天と地ほど違います。

優先順位づけには、影響度と発生可能性で脅威をランク付けする簡易な方法(高・中・低のマトリクス)で十分に始められます。DREADのようなスコアリング手法もありますが、数字の精密さより「チームで合意した優先順位」を持つことが目的です。そして④「十分な仕事をしたか」を問い、モデルを設計変更のたびに更新します。

2.6 アタックサーフェスを減らす

あらゆる緩和策の中で、最も確実で費用対効果が高いのはアタックサーフェス(攻撃対象領域)を減らすことです。アタックサーフェスとは、攻撃者がシステムに触れられる入口の総体——公開ポート、APIエンドポイント、入力フォーム、有効な機能、付与された権限、稼働中のサービスなどの合計です。

ここで発想を逆転させます。脆弱性を1つずつ塞ぐ「もぐら叩き」ではなく、「そもそも叩くべき穴を減らす」のです。存在しない機能は攻撃されず、閉じているポートは突かれず、保持していないデータは漏れません。具体的には次のような打ち手があります。

• 使っていない機能・エンドポイント・管理画面を無効化・削除する
• 外部に公開する必要のないサービスは内部ネットワークに閉じる
• アカウントやプロセスに与える権限を最小限にする(最小権限、第3章)
• 不要な個人情報を「そもそも集めない・保持しない」(データ最小化)
• 使っていないソフトウェア・ライブラリ・ポートを止める

脅威モデリングの過程でDFDを見直すと、「この外部連携、本当に必要か?」「この管理APIをインターネットに晒す意味はあるか?」といった問いが自然に浮かびます。機能を1つ削る判断は、対策を1つ足す判断より強い——これがアタックサーフェス削減の考え方です。

まとめ

• 脅威モデリングは「①何を作るか ②何が起き得るか ③どう対処するか ④十分か」の4問を反復する営み
• DFDで対象を可視化し、信頼境界をまたぐデータフローに脅威が集中することを見抜く
• STRIDEの6分類はCIA・認証・認可ときれいに対応し、漏れのない洗い出しを助ける
• 洗い出した脅威は緩和・受容・転嫁・回避から選び、リスクの大きさで優先順位をつける
• 最も確実な緩和は、機能・入口・権限・保持データを削ってアタックサーフェスを減らすこと

練習問題