SaaS向け脅威モデリングの実践方法
これは2021年に自分で試したSaaS向け脅威モデリングの内容を、今の自分が改めて気づきを整理した記事です。
1. リスクアセスメントの“曖昧さ”に気づいた日
2021年、私は脅威モデリングの書籍を片手に、SlackというSaaSに対してリスクを洗い出してみました。もともとリスクアセスメントには慣れていましたが、 それを他人に説明するときに「なぜそのリスクが高いのか」をうまく言語化できない という課題を感じていました。
自分の中ではリスクの重要性を理解していても、「どうしてそう言えるのか」を整理して伝えることが難しかったのです。
そんな中で出会ったのが「脅威モデリング」という考え方です。攻撃者の視点で「どんな脅威があるか」を整理し、対策を漏れなく考える。まさにリスクアセスメントを“構造化”するためのフレームワークだと感じました。
この記事では、自分の経験を含めて 初心者でもSaaSに脅威モデリングを適用できる考え方 を紹介します。「SaaSは中身が見えないからモデリングできない」と感じている方でも、自分たちが操作・設定できる範囲から始められる方法をお伝えします。
※
2021年当時、脅威モデリングのワークショップはほぼ存在していませんでした。また日本語記事もほぼなく、海外書籍や海外記事などを参考にしていました。現在は日本語情報も増えましたが、このような活用事例はまだ少ないと感じております。その知見を共有したいと思い、改めて記事化しました。
2. SaaSに脅威モデリングを適用してみると…
多くの書籍や海外記事は「自社開発システム」を対象にしています。つまり、アプリのアーキテクチャやデータフローを自分で描ける前提です。
でも、SaaSの場合は中身がブラックボックスです。たとえばSlackのログ保存先や暗号化方式は、利用者には分かりません。 バックエンドの構成や権限の仕組みを知ることはできず、見えるのはあくまで「設定画面と操作範囲」だけです。
たとえばSlackを題材にした場合、私たちが把握できるのは主に以下の範囲です。
- アカウント登録〜ログイン（ID管理）
- ワークスペースの権限設定
- 外部アプリ連携（OAuth）
- ファイル共有とアクセス制御
これらの設定変更が、どんなリスクに影響するのか？
たとえば「誰でもチャンネルに参加できる設定」や「不要な外部連携を許可している状態」が、どんな脅威につながるのか？ そう考え始めたとき、私は「従来の脅威モデリング（STRIDE）はこの問いに十分答えられない」と感じました。
SaaSでは、「自分が操作できる範囲」に対して脅威を考えることが大切。
この気づきが、次に紹介する「SaaS特有のリスク」を意識するきっかけになりました。
3. STRIDEだけでは見えない“クラウド特有のリスク”
脅威モデリングで有名なフレームワークに「STRIDE」があります。
ただし、STRIDEはアプリの内部構造を前提にした手法 であり、SaaSのように利用者が中身を操作できない環境では、「設定」や「アカウント管理」といった 利用者視点のリスク洗い出しには向いていません。
| 種類 | 意味 | Slackでの例 |
|---|---|---|
| S: Spoofing | なりすまし | 偽アカウントが参加する |
| T: Tampering | 改ざん | 投稿内容の不正変更 |
| R: Repudiation | 否認 | 発言や操作履歴を否認 |
| I: Information Disclosure | 情報漏えい | チャンネル情報の外部流出 |
| D: Denial of Service | サービス妨害 | APIの大量呼び出し |
| E: Elevation of Privilege | 権限昇格 | 権限のない設定変更 |
このように、STRIDEは「アプリケーション開発者」が脅威を整理する際には有効ですが、SaaSの 利用者 には適用しづらい面があります。なぜなら、SlackのデータベースやAPIの動作、内部の権限昇格の仕組みといった要素は、利用者からは見えないからです。
一方で、SaaS利用者が管理・制御できる範囲は、次のような“外部接点”にあります。
- アカウントの発行と削除
- 権限やチャンネル設定
- 外部アプリ連携（OAuth）
- 共有リンクや公開範囲
つまり、SaaS利用者にとっての脅威モデリングとは、これらの設定・操作を軸にした「利用リスクの洗い出し」 なのです。この視点を持つことで、クラウド特有のリスク構造がよりクリアに見えてきます。
このように、SaaSにSTRIDEを無理に当てはめるよりも、“利用者の責任範囲”を起点にしたフレームワークを使う方が効果的です。次章では、そのために役立つ2つの具体的なフレームワークを紹介します。
4. SaaSに合う“脅威モデリングの視点”とは
SaaSに対しては、ユーザ操作・設定・連携といった「利用面のリスク」に焦点を当てるのが現実的です。そこで役立つのが、以下の2つのフレームワークです。
1️⃣ SaaS Attacks Framework（Push Security）
https://github.com/pushsecurity/saas-attacks
このフレームワークは、実際のSaaS利用時に起こり得る攻撃を分類・整理しています。 カテゴリごとに「どんな操作・設定が悪用されるか」を理解しやすく、SaaS利用者のリスク洗い出しに直結 します。
たとえば
- 外部アプリのOAuthトークン悪用
- 公開リンクによるデータ流出
- 退職者アカウントの残存リスク
👉 Slackでの例
Push Securityのカテゴリ「Public Link Exposure」は、Slackで“誰でもアクセスできる共有リンク”を放置していないかを確認するのに役立ちます。 また、「Third-party App Abuse」は、Slack連携アプリのOAuth権限（読み取り・書き込み）を精査する際のガイドとして活用できます。
2️⃣ MITRE ATT&CK for Cloud (SaaS Matrix)
https://attack.mitre.org/matrices/enterprise/cloud/saas/
MITREのSaaS Matrixでは、攻撃者がクラウド環境をどのように悪用するかを体系化しています。
企業がSaaSを利用する際に「攻撃者が次にどんな手を打つか」を想定するうえで非常に有効です。
たとえば
- Access Managementの設定ミス
- アカウント乗っ取り後の横展開
- OAuthトークンを使ったデータ窃取
👉 Slackでの例
MITREの「Valid Accounts（T1078）」は、Slackで共有アカウントや退職者アカウントが放置されていないかを点検する際に参考になります。 また、「Data from Cloud Storage（T1530）」は、Slack上のファイル共有設定を見直す際の重要な観点です。
📊 フレームワーク比較（初心者向け）
| 観点 | Push Security (SaaS Attacks) | MITRE ATT&CK SaaS Matrix |
|---|---|---|
| 目的 | SaaS利用設定に潜むリスクを洗い出す | 攻撃者の行動パターンを理解する |
| 対象 | 利用者操作・設定・アプリ連携 | 攻撃シナリオ全体（ID, データ, 横展開） |
| 粒度 | 設定項目・利用シーン単位 | 戦術・テクニック単位 |
| 活用場面 | 現場の点検・設定レビュー | SOC/CSIRTや教育・訓練での脅威分析 |
| Slack例 | 公開リンク／外部連携チェック | アカウント管理／情報流出対策 |
これらを組み合わせることで、SaaSに対する脅威モデリングはより実践的になります。 Push Security で“設定リスク”を洗い出し、MITREで“攻撃者の行動”を照らし合わせる。この2軸を使うことで、技術者だけでなく運用担当者でも、SaaSリスクを体系的に理解できるようになります。
どちらのフレームワークも、社内教育資料やクライアント向け診断のベースとして再利用可能です。
コンサルタントやセキュリティ担当者が、組織・顧客のSaaS利用状況を体系的に整理する際の出発点として非常に有効です。
5. SaaS脅威モデリングの3ステップ
SaaSの脅威モデリングを始めるときは、複雑なツールや技術知識は不要です。重要なのは、 自分たちが操作できる範囲を整理し、そこにどんなリスクが潜んでいるかを順序立てて考えること です。
以下の3ステップで、初心者でも無理なく進められます。
| ステップ | 内容 | 目的 |
|---|---|---|
| ① 利用範囲を描く | 図にして「自社が操作できる範囲」を明示する（例：ユーザー、外部連携、権限設定など） | 可視化することで、考える範囲を絞る |
| ② 脅威の型をあてる | SaaS Attacks / MITRE SaaS Matrix を参照し、設定・操作・連携ごとに脅威を当てはめる | 抜け漏れを防ぐ |
| ③ 対策を整理する | 設定ポリシーや教育・監査の観点で対策を記述 | 現実的な改善計画を立てる |
🔍 Slackを例に各ステップの実践イメージ
① 利用範囲を描く
Slackで「ユーザー」「チャンネル」「外部アプリ連携」「ファイル共有」など、管理できる範囲を図にして整理します。
→ 例：ワークスペース管理者／一般ユーザー／ゲスト／外部アプリなどの関係を矢印で可視化
🧭 図の描き方のヒント：Miroやdraw.ioなどのツールを使い、「利用者（人）」と「SaaS（仕組み）」の関係を線でつなぐだけで十分です。目的は正確なシステム図ではなく、リスクの流れを可視化することです。
② 脅威の型をあてる
Push SecurityやMITRE SaaS Matrixを参考に、それぞれの範囲に対応する脅威を当てはめます。
→ 例：OAuth連携を洗い出し、“どのアプリにどんな権限を与えているか”を確認
→ 例：公開チャンネルに外部ユーザーが参加可能になっていないかをチェック
③ 対策を整理する
洗い出した脅威に対して、組織内で実施可能な設定や教育を整理します。
→ 例：「外部共有リンクは7日以内に自動失効」「退職者アカウントは自動で無効化」「OAuth連携は承認制」などのルールを定義
💡 ポイント
SaaSでは「開発ではなく設定が境界」です。 つまり、コードの安全性よりも「設定の安全性」「運用ルールの一貫性」が鍵になります。この3ステップをチームで繰り返すことで、SaaS利用の安全性を自律的に高める文化が育ちます。
また、コンサルの場合は 顧客と一緒にこの3ステップを行うと、“自社で制御できる範囲”の理解が深まり、対話が生まれます。 脅威モデリングは単なる分析手法ではなく、共通認識をつくるための“対話のフレームワーク”としても活用できるのです。
6. SaaSでの脅威モデリング適用から得た3つの気づき
Slackを題材に脅威モデリングを試してみて、私が得た学びは次の3つでした。
1️⃣ 可視化の重要性
自分たちが操作・設定できる範囲を図にすることで、「どこまで責任を持てるか」「どこがリスクポイントか」が明確になる。これは、リスクを“感覚”ではなく“構造”で捉える第一歩です。
2️⃣ フレームワーク選定の重要性
SaaSではSTRIDEよりも、Push SecurityやMITRE SaaS Matrixのような「利用者視点」のフレームワークが有効。環境に合った型を選ぶことで、抜け漏れが減り、議論の再現性が高まります。
3️⃣ 完璧主義を捨てること
脅威モデリングは「すべてを網羅する」ための作業ではなく、「共通言語で話せるようになる」ための思考プロセス。完璧さよりも、継続して考え続けることに価値があります。
SaaS利用の現場でも、“考えるリスクアセスメント”として脅威モデリングを取り入れる ことで、技術部門だけでなくコーポレートや営業など他部門との対話が格段にしやすくなります。
設定・操作・連携という日常の中に、リスクを見つめる視点を持つこと。それこそが、SaaS時代に求められる「現実的なセキュリティ文化」の第一歩です。
まずは1つのSaaSを選び、この3ステップを実践してみてください。
小さな気づきが、大きなセキュリティ文化の種になります。
Discussion