こんにちは、Luup SREチームのにわです。
本記事は、Luup Advent Calendar 2025の6日目の記事です。
最初に
本記事では、私が脅威モデリングを学習し、社内勉強会を主催して展開を進めている取り組みについて紹介します。セキュリティリスクを設計段階で見える化する手法として、脅威モデリングの基礎知識と、実際に勉強会で共有した内容をお伝えします。
注記: 本記事のDFDや事例は一般的な架空システムの例示であり、Luupの実システム構成や運用の詳細を示すものではありません。社内の具体的情報や設定は含みません。
経緯
Luupでは、高いセキュリティレベルを要求されるシステムがあります。そして、システムリリース後に脆弱性を発見した場合、ユーザーへの影響リスクが大きく、複雑なシステムのため修正コストも増大します。
そのため、サービスを拡大していくうえでセキュリティリスクを分析する必要性が高まる中、脅威モデリングという手法を知り、実施に向けて動くこととしました。脅威モデリングを実施することで、システム全体のリスクを可視化し、セキュリティ対策をどこに集中すべきかを判断する材料にもなります。
社内からも「リスク分析に有効ではないか」という声があり、私自身が脅威モデリングの手法を学習することにしました。脅威モデリングは、SLOを広める活動と同様に、一人で完結するものではなく、開発チーム、SRE/インフラチームなど、SLO以上に広範な利害関係者（ステークホルダー）との合意形成が重要なプロセスです。そのため、まずは脅威モデリングが何なのかを理解してもらい、協力を得る必要がありました。また、社内勉強会のネタとしても面白いと感じたこともあり、社内勉強会を開催することにしました。
書籍や論文、オンライン資料を参考に基礎から学び、STRIDEフレームワークやDFD(データフロー図)の作成方法を習得しました。その学びをもとに、開発チーム、SRE/インフラチームのメンバーを対象に勉強会を開催し、脅威モデリングの基礎と実践方法を共有しました。勉強会を通じて「こういう取り組みをやっているので、一緒に協力してほしい」という理解を得ることができました。本記事では、勉強会で説明した内容と、導入を進める上での気づきをまとめます。
目的
- 脅威モデリングの基礎知識を共有すること
- Luupでの取り組み状況を紹介すること
- 同じ課題を持つ企業への参考情報を提供すること
脅威モデリングとは
脅威モデリングは、攻撃者の視点でシステムを分析し、脆弱性を事前に発見する手法です。セキュリティを後付けではなく、設計の一部として組み込むことを目的としています。
脅威モデリングの第一人者であるAdam Shostack氏は、以下の4つの質問を継続的に繰り返すことが重要だと述べています。
その詳細:
- 何を作っているか？ - システムの全体像を可視化する
- 何が問題になりうるか？ - 脅威を網羅的に洗い出す
- どう対処するか？ - 対策を検討する
- 正しく対処できたか？ - 検証し、継続的に改善する
STRIDEフレームワーク
今回の勉強会では、STRIDEというフレームワークを採用しました。STRIDEは、脅威を6つのカテゴリに分類し、網羅的に分析する手法です。
| 脅威 | 説明 | 具体例 |
|---|---|---|
| Spoofing | なりすまし | 他人のアカウントで不正ログイン |
| Tampering | 改ざん | 決済金額や個人情報の書き換え |
| Repudiation | 否認 | ログ消去により不正操作の証拠隠滅 |
| Info Disclosure | 情報漏洩 | 個人情報やクレジットカード情報の流出 |
| DoS | サービス拒否 | 過負荷によるシステムダウン |
| Elevation | 権限昇格 | 一般ユーザーが管理者権限を不正取得 |
STRIDEを採用した理由は以下の通りです。
- 初心者にわかりやすい: 6つの脅威カテゴリで網羅的に分析できる
- 汎用性が高い: Webアプリ、API、IoTなど幅広く適用可能
- DFD(データフロー図)との相性が良い: システムの各コンポーネントに対してSTRIDEを適用できる
- パターン化されている: 生成AIでの自動化にも適している
勉強会で共有した内容
勉強会の実施内容
勉強会は、開発チーム、SREチーム、インフラチームのメンバーを対象に、10分版で実施しました。参加者全員が脅威モデリングの基礎を理解し、実践方法のイメージを持つことを目的としました。
勉強会では、脅威モデリングの基礎理論、STRIDEフレームワーク、DFDの作成方法、そして具体的な分析手法を説明しました。説明では、実際のシステムではなく、スマートロックという一般的なシステムを例に用いました。
DFD(データフロー図)の説明
脅威モデリングでは、まずシステムの全体像を可視化することが重要です。勉強会では、**DFD(データフロー図)**を使ってシステムのデータの流れを可視化する方法を説明しました。
DFDは以下の要素で構成されます。
- 外部エンティティ: ユーザー、外部サービスなど
- プロセス: アプリケーション、APIなど
- データストア: データベース、ファイルストレージなど
- データフロー: データの流れ(通信経路)
スマートロックシステムを例に、Mermaidを使ってDFDを作成する方法を説明しました。
スマートロックシステムのDFD
このDFDにより、ユーザーがスマホアプリからBLE通信でスマートロックを制御し、クラウドサービスを経由して認証や鍵データの管理が行われる全体像を可視化できることを示しました。
STRIDE分析の実践
DFDを作成した後、各コンポーネントに対してSTRIDE分析を実施する方法を説明しました。一例として以下のように脅威を洗い出す方法を示しました。
| コンポーネント | 脅威 | リスク | 対策 |
|---|---|---|---|
| BLE通信 | S: なりすまし | 偽装アプリで解錠 | 暗号化ペアリング |
| BLE通信 | T: リプレイ攻撃 | 解錠コマンド再送 | タイムスタンプ検証 |
| クラウドAPI | I: 鍵データ漏洩 | 全ユーザーの鍵流出 | 暗号化保存、アクセス制御 |
| スマートロック | E: 物理的ハッキング | デバイス分解 | 耐タンパー設計 |
| 管理画面 | E: 権限昇格 | 不正な鍵発行 | RBAC、監査ログ |
この説明を通じて、参加者がシステムの各コンポーネントに対する脅威を具体的にイメージできるよう工夫しました。
信頼境界の重要性
脅威モデリングでは、信頼境界の概念も重要です。信頼境界とは、セキュリティレベルが変わる境界のことで、境界を越えるときに認証・暗号化が必要になります。
勉強会では、スマートロックシステムにおける3つの信頼境界を説明しました。
mermaidで作られたデータフロー図を表示
スマートロックシステムの信頼境界
- 信頼境界0(物理デバイス): 信頼度が低く、物理的な攻撃のリスクがある
- 信頼境界1(モバイルアプリ): 信頼度が中程度、アプリの改ざんリスクがある
- 信頼境界2(クラウド): 信頼度が高く、厳格なアクセス制御が可能
境界を越える通信(BLE、HTTPS)には、必ず認証と暗号化が必要になることを説明しました。
参加者からの反応
勉強会後、参加者から以下のような反応がありました。
- 「システム全体を俯瞰できて、セキュリティリスクを具体的にイメージできた」
- 「設計段階での対策の重要性を実感した」
- 「チーム全体で共通認識を持てた」
- 「STRIDEのフレームワークが実践的だった」
特に、DFDを使ってシステムを可視化することで、開発・運用・インフラの各チームが共通の理解を持てたことが大きな成果でした。
導入を進める上での気づき
専門家がいない場合でも始められる
脅威モデリングの学習を通じて、セキュリティ専門家がいなくても始められる手法だと感じました。勉強会では、初学者でも取り組みやすい以下のようなアプローチを紹介しました。
簡易STRIDE(3つだけ):
STRIDEの中でも特に重要な3つの脅威に絞って分析を始める方法です。
- S (Spoofing): 認証は適切か？多要素認証は導入されているか？
- T (Tampering): 通信は暗号化されているか？入力検証は行われているか？
- I (Info Disclosure): ログに個人情報が出力されていないか？データは暗号化されているか？
D、R、Eは余裕があれば追加する形で、まずは小さく始めることができます。
外部リソースの活用:
OWASP Top 10やクラウドプロバイダー(AWS、GCP、Azure)のセキュリティベストプラクティスガイドなど、既存のリソースを参考にすることで、初学者でも実践的な知見を得られます。
また、脅威モデリングは、システム全体のリスクを可視化し、脆弱性診断などのセキュリティ対策の優先順位を判断する材料としても活用できると考えています。
チーム全体で取り組む意義
脅威モデリングは、一人で完結する活動ではなく、チーム全体で取り組む合意形成のプロセスだと実感しました。
勉強会を通じて、開発チーム、運用チーム、インフラチームがそれぞれの視点から脅威を洗い出すことで、一人では気づかないリスクを発見できることを確認できました。この点は、SREのSLO策定に似ていますが、脅威モデリングではより広範な部署が関わります。
結果として、「セキュリティは全員の責任」という意識が共有され、責任の分散と抜け漏れ防止につながりました。
完璧を求めない
脅威モデリングを始める際、完璧主義に陥らないことが重要だと学びました。
失敗例:
- DFDをレベル3まで詳細化(全テーブル、全API)
- 全コンポーネントにSTRIDEの6項目を完璧に網羅
- 結果: 3週間かかり、開発が止まる
改善策:
- まずはレベル0(全体像)から始める
- 高リスク部分だけ詳細化する
- 30-60分で終わらせる(完璧を求めない)
脅威モデリングは継続的なプロセスであり、1回で完璧にする必要はありません。まずは小さく始めて、継続的に更新していくことが大切であることを勉強会でも強調しました。
生成AIの活用可能性
脅威モデリングの効率化において、生成AIの活用可能性も検討しています。
DFD自動生成の可能性
システム仕様書やコードからMermaid形式のDFDを自動生成できれば、継続的な更新の手間を大幅に削減できます。STRIDEはパターン化されているため、生成AIとの相性が良いと考えています。
コード分析の効率化
脅威の洗い出しを生成AIが支援することで、初心者でも網羅的な分析が可能になるかもしれません。
Adam Shostack氏の見解
脅威モデリングの第一人者であるAdam Shostack氏は、YouTubeの動画(Threat Modeling with LLMs)の中で、「LLMは下書き生成に有用だが、最終判断は人が行うべき」と述べています。
生成AIはあくまで補助ツールとして活用し、最終的な判断はチームで行うことが重要だと考えています。
考慮事項 / 今後
現在の課題
分析の精度のばらつき:
勉強会を実施したものの、経験者と初心者で分析の深さが異なるため、テンプレート化やペアレビューなどで精度を揃える仕組みが必要だと感じています。
継続的な更新の仕組み化:
新機能追加時にDFDを確実に更新する仕組みが必要です。DFDのGit管理やPRレビューフロー化を検討しています。
リスク評価の定量化:
影響度と発生確率をどう評価するか、定量的な基準が必要だと考えています。
今後の取り組み
高リスクシステムでの本格導入を進めていければと考えています。脅威モデリングで特定したリスクをもとに、脆弱性診断などのセキュリティ対策の優先順位を判断する仕組みも整えていく予定です。Attack Treeなど他手法の学習も視野に入れています。
また、勉強会を継続的に開催し、チーム全体でのセキュリティ意識向上と、脅威モデリングの実践を定着させていければと思います。
最後に
私自身が脅威モデリングを学習し、社内勉強会を主催してみて、参加者から「シフトレフトだね」という声をいただけたことが嬉しかったです。脅威モデリングは継続的なプロセスであり、まずは小さく始めることが大切だと考えています。
少しでも参考になれば幸いです。
参考資料
書籍:
今回の学習では、以下の書籍を参考にしました。
-
Threat Modeling: Designing for Security (Adam Shostack)
- 脅威モデリングの第一人者による包括的な入門書です。4つの質問を軸にした実践的なアプローチが詳しく解説されています。
-
Threat Modeling: A Practical Guide for Development Teams (Izar Tarandach, Matthew J. Coles)
- 開発チーム向けの実践ガイドです。アジャイル開発環境での脅威モデリングの組み込み方や、具体的なワークフローが参考になりました。
オンライン資料:
注記:
- RBACはロールベースアクセス制御(Role-Based Access Control)の略です。
- 図中のアイコンは説明用の絵文字です。信頼度区分は便宜上のもので、一般的な理解のための表現です。
Discussion