SSPMをSaaS攻撃面管理として再評価する
要旨
SSPM（SaaS Security Posture Management）は、以前よりも評価を上げるべき領域である。理由は、SaaSへの攻撃が単なる設定不備の悪用にとどまらなくなったためである。
現在の攻撃は、ID、OAuth、セッション、API、外部連携、過剰権限、外部共有を組み合わせる。そのため、SSPMは「設定チェックツール」ではなく「SaaS攻撃面管理」として評価すべきである。
特に優先監視すべきSaaSは、Microsoft 365、Entra ID、Google Workspace、Salesforce、Okta、GitHub、Slack、ServiceNow、Boxである。ただし、SSPM単体でSaaSリスク全体を守れるわけではない。SSPMは、CASB、SWG、IdP、ITDR、EDR、DLP、SIEM、ITSMと組み合わせて効果を発揮する。
なぜ今SSPMを再評価すべきか
SaaSは、企業システムの周辺部ではなくなった。メール、ファイル、ID、CRM、開発、チケット、社内Wiki、会議、顧客接点がSaaS上に集まっている。
その結果、攻撃者にとってSaaSは最初の侵入口であり、横展開の足場であり、データ流出の出口でもある。
従来のSSPM評価では、MFAが有効か、外部共有が許可されているか、管理者が多すぎないかが中心だった。現在は、それだけでは足りない。
見るべき対象は、次のように広がっている。
- OAuthアプリが過剰なスコープを持っていないか
- APIトークンが長期間放置されていないか
- 退職者、外部ユーザー、休眠アカウントが残っていないか
- SaaS間連携が過剰権限になっていないか
- 公開リンクや外部共有がデータ流出経路になっていないか
この変化により、SSPMの価値は「設定棚卸し」から「攻撃経路の継続的な可視化」に移っている。
昨今のSaaS攻撃特性
正規ログインに見える攻撃が増えている
攻撃者は、必ずしもパスワードだけを狙わない。MFA疲れ攻撃、AiTM、デバイスコードフィッシング、OAuth同意フィッシングにより、正規の認証フローを悪用する。この場合、ログ上はユーザー本人が認証したように見えることがある。Microsoftは、AiTMによるトークン侵害やOAuthリダイレクト悪用も報告している。12
Microsoftは、2026年にAIを使ったデバイスコードフィッシング事例を公表している。同事例では、窃取されたトークンがメールの持ち出しや永続化に使われた。さらに、悪意ある受信トレイルールの作成やMicrosoft Graphによる偵察も確認されている。3 Cloud Security Allianceも、Microsoft 365組織を対象にしたOAuthデバイスコードフィッシングの広がりを調査ノートで扱っている。4 また、FBI IC3はPhishing-as-a-Serviceキットによる認証情報窃取リスクを注意喚起している。5
これは、MFAの有無だけでSaaS侵害リスクを判断できないことを示している。
OAuthとAPIトークンが主要な攻撃対象になっている
OAuthトークンやAPIトークンは、SaaS連携に不可欠である。しかし、これらは人間のログインとは異なる管理になりやすい。
典型的には、次の問題が起きる。
- ユーザー退職後も連携アプリが残る
- 高権限スコープが放置される
- トークンの棚卸し責任者が曖昧になる
Google Threat Intelligence Groupは、2025年のSalesloft Drift関連事案で、Salesforce連携に使われるOAuthトークンの悪用を報告している。同事案では、Salesforceデータへの不正アクセスが発生した。また、Drift Email連携に関連するOAuthトークンの侵害も確認されている。6
この事案は、SaaS連携そのものがサプライチェーンリスクになることを示している。
SaaS間連携が侵入口になる
企業は、Salesforce、M365、Google Workspace、Slack、GitHub、ServiceNow、Boxなどを相互に連携させる。この連携は業務効率を高める。一方で、攻撃者にとっては別SaaSへ移動する橋になる。
たとえば、CRM連携アプリのトークンが侵害されると、Salesforce内の顧客情報が抽出される可能性がある。GitHub連携が侵害されると、ソースコード、シークレット、CI/CD権限に到達する可能性がある。SlackやTeams連携が侵害されると、内部情報、ファイル、Webhookが悪用される可能性がある。
データ流出はファイル共有とCRM抽出に集中しやすい
SaaS上のデータは、境界防御の内側に閉じていない。
特に、次の経路は流出経路になりやすい。
- SharePoint公開リンクは、意図せず外部流出の経路になる
- OneDrive外部共有は、退職者や協力会社との関係整理が難しい
- Google Drive共有は、個別ファイル単位で棚卸しが必要になる
- Salesforceは、オブジェクト単位で大量データを抽出される可能性がある
- SlackやTeamsは、会話履歴と添付ファイルの検索により機密情報が見つかることがある
人間以外のIDが弱点になる
SaaSには、人間のアカウント以外にも多くの権限主体が存在する。
- サービスアカウント
- OAuthアプリ
- APIキー
- CI/CDトークン
- バックアップSaaS連携
これらはNon-Human Identityとして扱うべきである。SSPMは、NHI管理と接続アプリ管理に近づいている。
GenAI系SaaSが新しい抜け道になる
ChatGPT、Copilot、Gemini、Claude、Notion AI、Slack AIなどの利用が広がっている。無許可利用は、シャドーITならぬシャドーAIになる。
GenAI系SaaSでは、次の論点が生じる。
- 機密情報の入力は、データガバナンス上の問題になる
- 外部プラグインやコネクタは、SaaS連携リスクを増やす
- 社内データへの過剰アクセスは、権限設計の問題になる
よく狙われるSaaS一覧
| SaaS | 狙われ方 | 見るべき設定 | SSPM価値 | 理由 |
|---|---|---|---|---|
| Microsoft 365 / Entra ID | アカウント乗っ取り、OAuth同意、デバイスコードフィッシング、AiTM、SharePoint/OneDrive流出 | MFA、条件付きアクセス、外部共有、管理者ロール、アプリ同意、デバイスコードフロー、Graph権限 | 非常に高い | M365がメール、ファイル、ID、Teams、デバイス管理と強く結び付くため。CISAのSCuBAも、M365とGoogle Workspace向けにセキュア設定ベースラインを示している。7 |
| Google Workspace | Gmail侵害、Drive共有、OAuthアプリ、外部転送、管理者権限悪用 | 2段階認証、外部共有、サードパーティアプリ、メール転送、管理者ロール | 高い | メールとDriveの両方がデータ流出経路になりやすいため |
| Salesforce | OAuthトークン悪用、SOQLによる抽出、過剰権限、接続アプリ悪用、外部連携悪用 | 接続アプリ、プロファイル、権限セット、APIアクセス、エクスポート権限、ログイン制限 | 非常に高い | 顧客情報、商談情報、問い合わせ情報が集中するため |
| Okta / Entra ID / OneLogin / Ping | IdP乗っ取り、MFA回避、管理者権限奪取、アプリ割当悪用 | MFAポリシー、管理者、アプリ割当、APIトークン、条件付きアクセス | 非常に高い | IdPが他SaaSへの入口になるため |
| GitHub / GitLab / Bitbucket | ソースコード窃取、シークレット窃取、CI/CDトークン悪用、外部Collaborator悪用 | ブランチ保護、外部Collaborator、PAT、Secrets、Actions権限、Organization権限 | 高い | 開発環境の侵害が本番環境やサプライチェーンへ波及するため |
| Slack / Microsoft Teams | 外部招待悪用、機密検索、Webhook悪用、ファイル共有、なりすまし | 外部ゲスト、アプリ連携、Webhook、ファイル共有、保持期間 | 中から高 | 会話履歴に業務情報と機密断片が混在しやすいため |
| ServiceNow / Jira / Confluence | チケット内機密、構成情報、脆弱性情報、社内Wiki流出、APIトークン悪用 | 匿名公開、外部共有、管理者、プロジェクト権限、APIトークン | 高い | システム構成、障害情報、脆弱性情報が集まりやすいため |
| Box / Dropbox / Egnyte | 外部共有、公開リンク、退職者アクセス、同期端末からの流出 | 共有リンク、外部ユーザー、DLP、期限切れ設定、端末同期制御 | 中から高 | ファイル共有SaaSでは設定一つで社外公開範囲が大きく変わるため |
| Zoom | 録画流出、外部連携、会議情報漏えい、参加制御不備 | 録画共有、参加制御、アプリ連携、待機室、録画保存先 | 中 | 録画と会議情報の機密性が業務によって大きく変わるため |
| Snowflake / Databricks | 認証情報窃取、大量データ抽出、MFA未設定、過剰ロール | MFA、ネットワーク制限、ロール、キー管理、監査ログ | 高い | データ基盤に直接アクセスされると被害が大規模化するため |
| HubSpot / Zendesk / Marketo | 顧客情報窃取、問い合わせ履歴窃取、API連携悪用、エクスポート権限悪用 | 接続アプリ、管理者、エクスポート権限、外部連携 | 中から高 | 顧客接点の情報と外部連携が集中しやすいため |
SSPMで見るべき観点
旧来のSSPM観点
旧来のSSPMでは、主に次の観点を確認していた。
- 設定がベストプラクティスに合っているかを見る
- MFAが有効かを見る
- 外部共有が許可されているかを見る
- 管理者が多すぎないかを見る
- 監査ログが有効かを見る
現在必要なSSPM観点
現在は、次の観点まで見る必要がある。
- OAuthアプリの権限が危険ではないかを見る
- サードパーティ連携が過剰権限ではないかを見る
- 退職者、休眠者、外部ユーザーが残っていないかを見る
- 公開リンクが棚卸しされているかを見る
- APIトークンが長期放置されていないかを見る
- サービスアカウントが人間以上の権限を持っていないかを見る
- 設定変更が継続監視されているかを見る
- 危険な変更を検知できるかを見る
- 修正担当者を割り当てられるかを見る
- 証跡として監査に出せるかを見る
M365だけを前提にした場合のSSPM再評価
M365だけでも、SSPMの価値は中から高である。
理由は次の通りである。
- M365は攻撃頻度が高い
- Entra IDは全SaaSの入口になりやすい
- Exchange Onlineはメール侵害の中心になりやすい
- SharePointとOneDriveは外部共有事故の中心になりやすい
- Teamsは会話履歴、ファイル、外部招待の接点になる
- OAuth同意と接続アプリは見落とされやすい
- 設定項目が多く、手作業レビューには限界がある
一方で、M365単体ならMicrosoft標準機能で代替できる範囲もある。CISA BOD 25-01はクラウドサービスのセキュアプラクティス実装を求め、その実装ガイダンスも公開している。89
- Microsoft Secure Score
- Entra ID Identity Protection
- Defender for Cloud Apps
- Defender for Office 365
- Microsoft Purview
- CISA SCuBA
- PowerShellによる定期監査
Google Workspace側では、SCuBA関連ツールとしてScubaGogglesも公開されている。10
したがって、M365だけなら「SSPMを入れるか」ではなく「Microsoft標準機能とSCuBAでどこまで代替できるか」を先に確認すべきである。
AvePoint等が既に入っている場合は、機能重複を確認すべきである。AvePointは、バックアップ、運用、ガバナンス、権限棚卸しで一定の役割を持つ可能性がある。しかし、攻撃者視点のOAuth、NHI、危険連携、横断リスク分析まで十分に見られるとは限らない。
SSPM追加の価値は、既存製品でOAuth、API、外部共有、設定差分、危険変更をどこまで継続監視できるかで決まる。
導入判断フロー
導入判断では、次の質問を順番に確認する。
| 質問 | Yesの場合 | Noの場合 |
|---|---|---|
| Q1. 重要SaaSがM365だけか | Microsoft標準機能とCISA SCuBAでどこまで足りるか確認する | SSPM候補として評価する |
| Q2. Salesforce、GitHub、Slack、ServiceNow、Boxがあるか | SSPMの優先度は高い | M365中心評価でよい |
| Q3. OAuthアプリとAPIトークンを定期棚卸しできているか | SSPMの追加価値は下がる | SSPM価値は高い |
| Q4. 外部共有リンクを継続監視できているか | SSPMの追加価値は下がる | SSPM価値は高い |
| Q5. SaaS設定変更を差分検知できているか | SSPMの追加価値は下がる | SSPM価値は高い |
| Q6. 指摘事項をシステム管理者へ自動で割当できるか | 運用成熟度は高い | SSPMのワークフロー機能が効く |
| Q7. 監査証跡として説明できるか | 既存運用でも継続可能である | SSPMのレポート価値がある |
SSPM製品評価で重視すべき項目
SSPM製品評価の必須項目
SSPM製品評価では、少なくとも次の項目を必須として見る。
- M365とEntra IDに対応していること
- Google Workspaceに対応していること
- Salesforceに対応していること
- Oktaに対応していること
- GitHubに対応していること
- OAuthアプリを棚卸しできること
- APIトークンを棚卸しできること
- 外部共有を検出できること
- 管理者権限をレビューできること
- 設定変更差分を検知できること
- リスク優先度を付けられること
- 修正手順を提示できること
- チケット連携ができること
- SIEM連携ができること
SSPM製品評価であると強い項目
次の項目まで備えていると、SaaS攻撃面管理としての価値が上がる。
- NHI管理ができること
- GenAI SaaSを検出できること
- SaaS間の攻撃経路を分析できること
- MITRE ATT&CKにマッピングできること
- CISA SCuBAに対応できること
- PCI DSS、ISO 27001、NIST向けのレポートを出せること
- 危険なOAuthスコープを自動スコアリングできること
製品選定時の注意点
対応SaaS数だけで選んではいけない。重要なのは、自社で使っているSaaSを深く見られるかである。
製品選定時には、次の点を確認する。
- 読み取り専用APIで何が見えるかを確認すべきである
- SaaS側のIP制限やAPI制限と両立できるか確認すべきである
- 設定変更まで自動実行させる場合は慎重に設計すべきである
- 検出結果を誰が修正するかを先に決めるべきである
- SSPMのアラートをSOCだけに投げても解決しない
- SaaS管理者、システム所管、セキュリティ部門、監査部門の役割分担が必要である
最終判定
SSPMは、以前より評価を上げるべきである。特に評価すべき理由は、OAuthトークン悪用が現実化していることである。
加えて、次の点も重要である。
- SaaS連携がサプライチェーン化している
- MFAだけではSaaS侵害を防げない
- SaaS設定は人手レビューに向かない
- ファイル共有と外部ユーザーの棚卸しが難しい
- 監査証跡として継続評価が求められる
ただし、SSPMだけでは不足する。周辺領域は、次の製品・仕組みが担う。
| 領域 | 主な担い手 |
|---|---|
| 通信制御 | CASB、SWG |
| 端末起点の検知 | EDR |
| IDリスク | IdP、ITDR |
| メール起点 | SEG、Defender |
| データ分類 | DLP、Purview |
| ログ相関 | SIEM |
M365単体運用なら、Microsoft標準機能、CISA SCuBA、定期監査と比較する。複数SaaS運用なら、SSPM導入価値は高い。Salesforce、GitHub、Slack、ServiceNow、Boxがあるなら、優先度はさらに上がる。
SSPMは、チェックリスト代替ではなく、SaaS攻撃面管理として評価する。