SSPM市場
この記事の位置づけ
この記事は、SSPM（SaaS Security Posture Management）が必要とされる背景を整理する入口記事です。
対象は、SaaS利用の拡大、設定不備リスク、SSPMという製品カテゴリがどの問題を扱うのかに限定します。個別SaaSの設定確認や導入チェックリストは、次の記事へ分けます。
SaaS利用の拡大で管理対象が増える
企業の業務、開発、運用では、CRM、コラボレーション、ソースコード管理、ITSMなど、多数のSaaSが使われるようになっています。Oktaの調査では、利用アプリ数の平均が2024年時点で89から93へ増え、従業員2,000人以上の組織では平均231アプリとされています。1
この数字は、すべての組織にそのまま当てはまるものではありません。ただし、SaaS利用が一部門の個別導入に留まらず、組織横断の管理対象になっていることは読み取れます。
日本企業については、クラウド/SaaS活用が米国より遅れているという見方もあります。2022年時点でIT支出に占めるクラウドサービスの割合を日本4.4%、米国14%とする推計が紹介されています。2 一方で、クラウド活用やDX推進により、SaaS設定を組織として管理する必要性は日本でも増えています。
ここで見るべき点は、SaaSの導入数そのものではなく、次の管理対象が増えることです。
| 管理対象 | 例 |
|---|---|
| ID | 管理者、一般利用者、外部ユーザー、サービスアカウント |
| 認証 | SSO、MFA、ローカルID、セッション設定 |
| 権限 | 管理者権限、共有権限、職務分掌、休眠ID |
| 共有 | 公開リンク、外部共有、ゲストアクセス |
| 連携 | OAuthアプリ、APIトークン、外部アプリ連携 |
| 監査 | 監査ログ、設定変更履歴、アラート、保存期間 |
SaaS設定不備は利用者側の責任にも残る
SaaSでは、インフラ運用やアプリケーション本体の保守はベンダー側に寄ることが多いです。一方で、テナント設定、利用者管理、共有範囲、外部連携、監査ログの有効化などは利用企業側に残ります。
CSAの調査では、SaaS設定ミスに起因するセキュリティインシデントを経験した組織が43%と報告されています。3 この数値は調査対象や設問に依存しますが、設定不備がSaaS利用時の主要な論点であることを示す材料になります。
設定不備の例は、次のように分類できます。
| 分類 | 例 |
|---|---|
| 認証設定 | 管理者MFA未設定、SSO未連携、弱いローカルIDの残存 |
| 権限設定 | 管理者権限過多、退職者ID残存、外部ユーザー棚卸し不足 |
| 共有設定 | 公開リンク許可、社外共有の過剰許可、ゲスト権限の放置 |
| 連携設定 | 不要なOAuthアプリ、無期限APIトークン、連携用IDの過剰権限 |
| 監査設定 | 監査ログ未取得、保存期間不足、設定変更履歴の未確認 |
SaaSは導入後も設定が変わります。導入時点の確認だけでは、後から追加された管理者、共有設定、連携アプリ、例外設定を捕捉できません。
SSPMが扱う範囲
SSPMは、SaaSの設定、権限、共有、連携、監査ログなどを継続的に確認し、設定不備やポリシー逸脱を見つけるための製品カテゴリです。
SSPMを「SaaSへパッチを当てる仕組み」と捉えると誤解が出ます。SaaS本体の脆弱性修正は通常ベンダー側の責任です。SSPMが主に扱うのは、自社テナント側の設定状態、過剰権限、公開状態、外部連携、監査ログの有無です。
典型的な機能は次の通りです。
| 領域 | SSPMで確認しやすいこと |
|---|---|
| 設定評価 | ベストプラクティスや社内基準との比較 |
| ID・権限 | 管理者、休眠ID、過剰権限、外部ユーザー |
| 共有・公開 | 公開リンク、外部共有、ゲストアクセス |
| 外部連携 | OAuthアプリ、APIトークン、連携用ID |
| 監査 | ログ取得、設定変更履歴、アラート設定 |
| 是正運用 | 検出結果の通知、チケット連携、例外管理 |
SSPMだけで統制は完結しない
SSPMは有用な自動化手段ですが、SaaS統制の全体を置き換えるものではありません。
主な限界は次の通りです。
- 対応SaaSに偏りがある。
- 対応SaaSでも、取得できる設定項目には差がある。
- 契約、再委託、通知義務、監査権の確認は別管理になる。
- 業務上必要な例外設定は、自動的に良否判定しにくい。
- 部門独自導入SaaSの棚卸しは別途必要になる。
そのため、SSPMは「設定確認を自動化する部品」として扱い、チェックリスト、責任分界、契約確認、証跡台帳、例外管理と組み合わせる必要があります。
運用設計は、SaaS設定不備リスクへのチェックリスト統制 で扱います。Salesforceのように、複数org、外部ユーザー、連携ID、ライセンス母数が絡む場合は、SSPMをSalesforceに適用するときの見方 に分けて整理します。
市場を見るときの注意点
SSPM市場を見るときは、ベンダー数や市場規模だけで判断しない方がよいです。導入可否に直結するのは、自社で使っているSaaSに対して、どこまで深く見えるかです。
確認すべき観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
| 対応SaaS | 自社の主要SaaSが対象か |
| 取得深度 | 権限、共有、連携、監査ログまで見えるか |
| 課金単位 | SaaS単位、ユーザー単位、ディレクトリ単位、テナント単位のどれか |
| 是正連携 | 通知だけか、チケット、承認、例外管理まで持てるか |
| 運用体制 | 誰が検出結果を確認し、誰が設定を直すか |
| 証跡 | 監査や2線確認に使える形で履歴が残るか |
まとめ
SaaS利用が広がるほど、利用企業側に残る設定、ID、共有、連携、監査の管理対象が増えます。SSPMは、その状態を継続的に確認するための製品カテゴリです。
ただし、SSPMはSaaS統制の一部です。導入時には、対象SaaS、取得できる項目、是正責任、例外管理、証跡の扱いを合わせて設計する必要があります。