SSPM（SaaS Security Posture Management：SaaSセキュリティ態勢管理）は、Microsoft 365・Salesforce・Slack・Zoomなど企業が利用するSaaSアプリケーションのセキュリティ設定・権限・リスクを継続的に可視化・評価・是正するソリューションです。クラウドセキュリティ連盟（CSA）の調査によれば、86%の組織がSaaSセキュリティを高優先度として認識する一方、設定ミスによるリスクが最大の課題となっています。本記事では、SSPMの定義・主要機能・CSPM クラウドセキュリティ態勢管理・CASBとの違い、そして導入のポイントを詳しく解説します。
SSPMとは：SaaSアプリのセキュリティ設定を一元管理する
SSPMの定義と背景
SSPMは、企業が利用する複数のSaaSアプリケーションのセキュリティ設定を継続的にスキャンし、ベストプラクティスやコンプライアンス基準からの逸脱を検出・是正するためのセキュリティカテゴリーです。
SSPMが必要になった背景：
クラウドサービスへの移行が加速した結果、企業が利用するSaaSアプリは急増しています。しかし、各SaaSには独自の設定画面・権限モデル・セキュリティオプションがあり、IT部門がすべてを手動で管理・監視することは現実的ではありません。
設定ミスが最大のリスク要因：
- 「誰でも閲覧可能」に設定されたSlackチャンネルやSharePointファイル
- 退職した従業員のアカウントが有効なまま放置
- 過剰な管理者権限を持つアカウントの増加
- MFA設定の例外（「VPN接続時は免除」など）
- 外部ユーザーへの無制限のファイル共有設定
SSPMが評価するSaaSアプリの例
| SaaSカテゴリ | 主なアプリ | 評価する設定の例 |
|---|---|---|
| コラボレーション | Microsoft 365, Google Workspace | 外部共有設定, MFA設定 |
| CRM | Salesforce | ユーザー権限, データアクセス設定 |
| コミュニケーション | Slack, Teams, Zoom | ゲスト招待設定, 録音・録画ポリシー |
| セキュリティ | Okta, Microsoft Entra ID | MFA強制設定, 条件付きアクセス |
| 開発 | GitHub, Jira, Confluence | リポジトリ公開設定, ユーザー権限 |
| ITSM | ServiceNow | アクセス制御, APIアクセス設定 |
SSOだけでは不十分 SSO×IGA一気通貫
SSOだけでは防げないセキュリティリスクを明らかにし、IGAとの統合による一気通貫のID管理がなぜ必要かを解説します。
SSPMの主要機能
1. セキュリティ設定の継続的スキャン
SSPMは接続されたSaaSアプリを定期的にスキャンし、現在の設定を事前定義されたセキュリティルール・ベストプラクティスと照合します。
検出する設定ミスの例：
- Microsoft 365でMFAが無効化されているユーザーアカウント
- Salesforceで必要以上の権限プロファイルが割り当てられている
- Slackで「全メンバーがワークスペース設定を変更可能」になっている
- GitHubのパブリックリポジトリに内部コードが含まれている
2. リスクスコアリングと優先順位付け
発見された設定ミスや脆弱性にリスクスコアを付与し、対応の優先順位を示します。膨大な数の設定項目の中から、まず何を修正すべきかを明確にします。
3. 権限・アクセス管理の可視化
各SaaSにおけるユーザーの権限状態を可視化します。
可視化する内容：
- 過剰な管理者権限を持つユーザー一覧
- 90日以上ログインしていない休眠アカウント
- 外部ゲストユーザーのアクセス範囲
- アプリ間の権限関係（OAuth連携）
- サードパーティアプリが要求しているスコープの過剰性
4. コンプライアンスマッピング
国際標準・法規制とのマッピングを自動化し、監査レポートを生成します。
対応するフレームワーク例：
- ISO/IEC 27001 / SOC 2 Type 2
- GDPR・個人情報保護法
- NIST Cybersecurity Framework
- CIS Benchmarks（Microsoft 365・Salesforce等各SaaS製品向け）
5. 自動修復と修復ガイド
- 自動修復：設定ミスを検出後、自動的に修正する（管理者の承認フロー付き）
- 修復ガイド：自動修復が難しい場合、管理者向けにステップバイステップの修正手順を提供
SSPM・CSPM・CASBの違いと使い分け
クラウドセキュリティ領域には複数のカテゴリーが存在し、SSPMとの関係を正確に理解することが重要です。
SSPMとCSPM（Cloud Security Posture Management）の違い
| 項目 | SSPM | CSPM |
|---|---|---|
| 管理対象 | SaaSアプリ（M365、Salesforce等） | クラウドインフラ（AWS、Azure、GCP） |
| 評価する設定 | SaaS設定・権限・アカウント | インフラ設定・ネットワーク・IAMポリシー |
| 典型的なリスク | 設定ミス・過剰権限・休眠アカウント | 公開バケット・脆弱なセキュリティグループ |
| 主なユーザー | IT部門・SaaS管理者 | クラウドエンジニア・セキュリティチーム |
| 関係 | 補完的（アプリ層とインフラ層） | 補完的 |
シンプルな理解：
- CSPM = AWSやAzureなどのクラウドインフラのセキュリティを管理
- SSPM = Microsoft 365やSalesforceなどのSaaSアプリのセキュリティを管理
SSPMとCASB（Cloud Access Security Broker）の違い
| 項目 | SSPM | CASB |
|---|---|---|
| 主な役割 | SaaSの設定・権限の評価と是正 | ユーザー・データのトラフィック制御 |
| アプローチ | 設定評価型（ポスチャー管理） | トラフィック制御型（プロキシ・API） |
| 強み | 設定ミスの深い検出・修復 | データ流出防止（DLP）・アクセス制御 |
| 弱み | リアルタイムトラフィック制御は対象外 | 設定レベルの評価は不得意 |
| 関係 | 補完的（両方を組み合わせると効果的） | 補完的 |
クラウドセキュリティの全体像における位置づけ
【クラウドセキュリティの4層】
インフラ層（IaaS/PaaS）
└ CSPM：AWSなどのインフラ設定の評価・修正
アプリケーション層（SaaS）
└ SSPM：SaaS設定・権限の評価・修正
トラフィック・データ層
└ CASB：SaaSへのアクセスとデータフローの制御
アイデンティティ層
└ ISPM：全アイデンティティのセキュリティ態勢評価
SSPMが解決する具体的なビジネス課題
課題1：シャドーSaaS・シャドーITの把握
従業員が業務で無断導入したSaaSツール（シャドーSaaS）は、IT部門が把握できず、セキュリティポリシーが適用されません。SSPMはOAuth連携や認証ログを分析し、未承認SaaSを検出します。
課題2：SaaS管理者のオーバーロード
企業が利用するSaaSが数十〜数百に達すると、各アプリの設定を個別に確認・管理することは不可能です。SSPMは複数のSaaSを一元的なダッシュボードで管理し、管理工数を大幅に削減します。
課題3：監査・コンプライアンス対応の負荷
ISO 27001やSOC 2の監査では、アクセス管理・設定管理に関する証跡が求められます。SSPMは継続的な評価と自動レポート生成により、監査準備の工数を削減します。
課題4：M&A・組織変更後のリスク
合併・買収・組織再編では、アカウントの引き継ぎ・権限の見直しが必要になりますが、漏れが生じやすいのがSaaS管理です。SSPMは変更後の権限状態を即座に可視化し、リスクを早期に検出します。
SSPM導入のステップ
ステップ1：利用中のSaaSを棚卸しする
まず、組織が公式・非公式に利用しているSaaSアプリを一覧化します。CASBやIDプロバイダーのOAuth連携レポートを活用すると効率的です。
ステップ2：優先度の高いSaaSから接続を開始
すべてのSaaSを一度に管理しようとせず、リスクとインパクトの大きいアプリ（Microsoft 365、Salesforce、Slackなど）から段階的に接続します。
ステップ3：ベースラインの設定とポリシー定義
組織のセキュリティポリシーに基づき、SSPMが評価するルールセット（ベースライン）を設定します。業界標準（ISO 27001、CIS Benchmarks）を参考にしつつ、組織固有のポリシーを追加します。
ステップ4：継続的なモニタリングと是正サイクルの確立
SSPMは「導入して終わり」ではなく、継続的な運用が価値を生みます。週次・月次でのリスクレポートレビューと、発見した設定ミスの是正サイクルを組織プロセスに組み込みます。
SSPMとISPMの関係
SSPMとISPMはどちらも「ポスチャー管理（態勢管理）」という概念を共有しますが、スコープが異なります。
| 項目 | SSPM | ISPM |
|---|---|---|
| スコープ | SaaSアプリ全体の設定・権限 | アイデンティティ（人間・非人間）のリスク |
| 主な評価対象 | SaaS設定ミス・アクセス権限 | IAM設定・特権アカウント・NHI |
| 関係 | 重複する部分あり（補完的） | 重複する部分あり（補完的） |
多くのSaaS管理には「誰がアクセスできるか」というアイデンティティの側面があるため、SSPMとISPMは重なり合う部分があります。統合的なクラウドセキュリティプラットフォームでは、両者の機能が一体化される方向性にあります。
LOCKED MSOとSSPMの関係
LOCKED MSOは、SSOを通じて企業内のSaaSへのアクセスを統合管理します。SSPMの観点では、LOCKED MSOが以下の基盤機能を提供します。
- SaaSアクセスの一元管理：従業員が使用するSaaSアプリをLOCKED MSOで集中管理
- 権限の可視化：どの従業員がどのSaaSにアクセスできるかを一元管理
- MFAの統一適用：全SaaSへのアクセスに対してMFAを強制し、認証リスクを低減
- 入退社管理：従業員の退職時にすべてのSaaSへのアクセスを一括で無効化
LOCKED MSOはSSPMの「アイデンティティ管理基盤」として機能し、SaaSのアクセス権限リスクを根本から管理します。
LOCKEDの詳細を見る SaaSセキュリティの強化にはLOCKED MSOをご検討ください。 資料請求・デモ依頼はこちら →
まとめ：SSPMはSaaS時代に欠かせないセキュリティ基盤
| ポイント | 内容 |
|---|---|
| 何を管理するか | 複数SaaSの設定ミス・権限・コンプライアンス |
| CSPMとの違い | インフラ層（CSPM）とアプリ層（SSPM）の補完 |
| CASBとの違い | 設定評価（SSPM）とトラフィック制御（CASB）の補完 |
| ISPMとの関係 | アイデンティティ視点でオーバーラップ、統合の方向性 |
| 価値 | 設定ミス検出・自動修復・監査対応の効率化 |
SaaSの利用が拡大し続ける現代において、SSPMは「見えないセキュリティリスク」を可視化するための必須ツールです。