SSPMとは？SaaSの設定ミスを見つけて直す仕組みと導入の基本
SaaSを導入したあと、共有設定や管理者の権限まで継続して確認できているでしょうか。
サービス自体が安全に運営されていても、自分たちの使い方や設定まで自動で適切になるとは限りません。
そこで、SaaSの設定やアクセス権限などを点検し、改善につなげる考え方がSSPMです。
ただし、製品をつなげばすべてのSaaSを監視でき、問題も自動で直るわけではありません。
この記事では、何を確認し、誰が判断して直し、どう再確認するのかを、設定例と図で整理します。
この記事は以下のような人におすすめ！
- SaaSの設定を部署ごとに管理していて見落としが気になる人
- SSPMとCSPMやCASBの違いを整理したい人
- 検出した問題を放置せず改善まで回す仕組みを考えている人
SSPMとは、SaaSの安全な設定を保つための取り組み
1-1. 製品を守ることと、自社の設定を管理することを分ける
SSPMはSaaS Security Posture Managementの略です。
ここでいうPostureは、セキュリティ上の状態や構えを指します。
何かを一度チェックして終えるのではなく、利用するSaaSの設定やアクセス権限が、自社の方針に合っているかを確認し続ける取り組みです。
確認対象には、共有範囲や利用者のアクセス、認証などに関係する設定が含まれます。
ただし、実際に取得できる項目は、SaaS側の機能や製品の対応範囲によって変わります。
（参考1）
図で扱う「外部共有が許可されている」は、説明のために作った設定例です。
外部との共同作業が必要な部署もあるため、その状態だけで設定ミスだと決めることはできません。
守るべきデータや業務上の必要性と比べ、どの範囲を許可するかを判断します。
「見つかった設定」と「その設定を問題と判断する基準」を分けることが出発点です。
1-2. 導入しただけでは、改善まで終わらない
設定評価の結果は、次の対応を決めるための材料です。
担当者が内容を確かめ、必要な変更を選び、影響を確認してから適用する工程が残ります。
CMSの運用説明でも、発見された問題を調査して改善するための体制や作業時間が必要だとされています。
特定組織の費用や対応期限は、その組織の運用条件であり、すべての導入へ当てはめるものではありません。
（参考1）
まず小さな対象から、「問題を受け取ったあと、誰が何をするか」を決めてみると、機能比較だけでは見えない要件が分かります。
SSPMは、設定を見つけることだけでなく、判断・是正・再確認へつなぐ運用と合わせて考えます。
検出件数が多いことと、改善できていることは同じではありません。
SSPMはどのように設定を確認するのか
2-1. SaaSとの連携で、取得できる範囲を決める
製品の連携方式の一例がAPIです。
APIは、別のシステムから決められた方法で情報を取得したり操作したりするための窓口です。
APIを介してSaaSと連携し、情報を集めて評価する構成があります。
Microsoftの製品例では、SaaSアプリの接続が設定評価の前提になっています。
（参考2）
図では、接続したSaaS Aと、接続していないSaaS Bを分けます。
Aの評価結果が良くても、Bまで確認できたことにはなりません。
「対応アプリに載っているか」だけでなく、契約している版や取得権限、確認したい設定項目まで照合しましょう。
2-2. 評価結果には、取得した時点や条件がある
設定を評価するときは、結果だけでなく、いつどの範囲を確認したかも必要です。
たとえば、昨日の点検後に共有範囲が変わっていたら、昨日の結果だけでは現在の状態を説明できません。
継続監視をうたう製品でも、すべての項目を遅延なく把握できるとは限らないため、更新間隔や取得エラーの扱いを確認します。
連携が失敗している状態を「問題なし」と表示しないかも、評価したいポイントです。
この章の更新時刻やエラー状態は運用設計上の確認事項で、特定製品の画面や共通仕様を再現したものではありません。
SSPMとCSPM・CASBの違い
3-1. 名前より、何を確認したいのかで整理する
SSPMとCSPMは名前が似ていますが、導入を考えるときの出発点が違います。
SSPMでは、利用するSaaSの設定や権限を確認したい、という課題が中心です。
CSPMでは、クラウド環境の設定やリソースの状態などから、リスクを確認します。
たとえば、業務SaaSの共有範囲と、クラウド基盤で管理するリソースの公開状態では、調べる対象も担当者も異なります。
（参考4）
一方、CASBはクラウドサービスの利用状況の把握や、セキュリティポリシーに基づく制御などを扱います。
「設定を継続して確かめたい」のか、「どのように利用されているかを把握・制御したい」のかを分けると、比較の軸を作りやすくなります。
（参考5）
詳しい基礎は、それぞれの記事で確認できます。
3-2. 製品の機能は重なるため、一対一で分類しない
ここまでの整理は、目的を理解するためのものです。
実際の製品は、設定の評価、アプリの利用状況、データ保護などをまとめて提供する場合があります。
Palo Alto Networksの公式案内でも、SSPMはSaaS Securityの機能として説明されています。
（参考3）
「CASBを使っているからSSPMの要件も満たしている」とも、「SSPMを入れたら他の機能は不要」とも、名称だけでは判断できません。
比較表を作るときは、必要なSaaSと設定項目を行に並べ、取得できるか、評価できるか、是正にどうつながるかを確認します。
すでに持っている製品で足りる範囲が分かれば、重複した導入も避けやすくなります。
製品カテゴリーの名前は比較の入口です。
最終的には、自社の対象・権限・必要な確認項目が、その契約で使えるかを照合します。
検出した設定を改善へつなぐ流れ
4-1. 影響と担当者を確かめて、対応を選ぶ
問題らしい設定が見つかっても、すぐに一括変更するのは避けたいところです。
外部との共有を止めると、取引先との作業が中断するかもしれません。
まず、その設定が適用される範囲、扱うデータ、関係する部署、例外として認められている理由を確認します。
そのうえで、設定を変えるのか、範囲を狭めるのか、期限付きの例外として管理するのかを選びます。
ここで必要なのは、評価画面を見る人だけでなく、SaaSの管理者や業務の担当者との役割分担です。
図のS-001は、対応の管理方法を説明する架空の番号です。
検出された設定、確認した理由、変更する担当者、再確認の結果を一つにつなげています。
製品のリスク評価だけで対応順を固定せず、自社での影響も合わせて判断します。
4-2. 変更したことと、再評価で確かめたことを分ける
「修正しました」という報告だけで、対応を終わりにしないことも大切です。
想定した設定が保存されたか、業務に予期しない影響がないか、評価結果が更新されたかを分けて確認します。
再評価でまだ問題が残るなら、取得時点が古いのか、別の適用範囲があるのか、変更が意図した場所へ入っていないのかを調べます。
変更前の状態や戻し方を残しておくと、問題が起きたときにも状況を追いやすくなります。
検出結果を適切な担当者へつなぎ、是正の優先順位や進め方を管理する点は、製品のワークフローでも支援されます。
ただし、どこまで自動で変更できるかは製品や権限に依存するため、すべて共通の機能として考えないようにします。
（参考3）
検出した設定を自動で変える機能を使う場合は、対象・権限・影響・戻し方を先に確認します。
検出のための連携と、変更するための権限は同じものではありません。
SSPMを導入する前の確認事項
5-1. 対象SaaSと、必要な権限を棚卸しする
最初の確認表には、利用しているSaaSの名前だけでなく、契約している版、管理する部署、確認したい項目を書きます。
同じサービス名でも、使える管理機能やAPIの条件が違えば、想定どおりの評価ができるとは限りません。
Microsoftの製品例でも、必要なライセンスと、対応するアプリ接続が前提として示されています。
（参考2）
連携の際は、どの情報を読み取るか、どこへ保存するか、誰が結果を見られるかも確認します。
必要な読み取り権限だけで始められるのか、変更まで行う権限が必要なのかを分け、機能に合う範囲を選びます。
これは本稿で示す導入確認の考え方で、すべての製品が同じ権限モデルを採用しているという意味ではありません。
使わなくなった連携を解除するときの手順や、認証の有効期限も確認表へ加えておくと、運用の抜けを減らせます。
5-2. 更新・エラー・担当・費用まで合わせて比べる
機能一覧だけでは、日々の運用を回せるかまでは分かりません。
設定変更が評価へ反映されるまでの条件、取得に失敗したときの表示や通知、対応が止まったときの連絡先を確認します。
さらに、必要なサービスの契約、対象数、導入支援、社内の対応時間なども合わせて検討します。
ライセンス費用が安くても、結果を読む人や変更する人が決まっていなければ、問題がたまってしまいます。
比較のための検証では、小さな対象で「取得できる」「意味を判断できる」「担当へ渡せる」「変更後を確認できる」の一周を確かめると、足りない工程が見えます。
この一周は本稿の運用提案であり、特定の日数や改善効果を保証するものではありません。
図の確認票も、製品の点数をそのまま比較するためのものではありません。
自社で必要な機能と、実際に確認できた範囲を残すために使います。
対象外のSaaSや確認できない項目は、手動の点検など別の管理方法が必要かを考えましょう。
よくある疑問と運用の始め方
6-1. SSPMについてよくある五つの質問
Q1：SSPMを入れれば、すべてのSaaSを確認できますか？
そうとは限りません。
製品が対応するサービス、契約やAPIの条件、確認できる設定項目を照合する必要があります。
Q2：検出された設定は、すべてすぐに直すべきですか？
業務への影響と方針を確認してから判断します。
必要な外部共有など、例外として扱う理由がある設定は、範囲や期限も含めて管理します。
Q3：SSPMとCSPMはどちらか一つで十分ですか？
対象と機能が違うため、名前だけでは判断できません。
必要なSaaS設定とクラウド基盤の確認項目を整理し、既存製品で足りる範囲も確かめます。
Q4：設定の評価が良ければ、侵害されていないと分かりますか？
設定の評価だけで、過去や現在の侵害がないと証明できるわけではありません。
事故が疑われるときの調査や対応を、設定の点検だけで置き換えないようにします。
Q5：少ないSaaSでも取り組む意味はありますか？
数だけでなく、扱うデータや設定の重要性、手動で確認し続けられるかを考えます。
小さな対象から担当と確認手順を整理し、道具が必要な部分を見極める方法もあります。
6-2. 小さな対象から、検出と改善の一周を確かめる
SSPMを考えるときは、いきなり製品名を並べるより、自社で確かめたい設定を一つ挙げてみてください。
共有範囲なのか、管理権限なのか、認証に関係する設定なのかが分かれば、確認したい機能も具体的になります。
次に、取得できる範囲を確かめ、結果を判断する人と、必要な変更を行う人を決めます。
変更後に再確認するところまでつながると、点検をしただけで終わりにしにくくなります。
大切なのは、見えていない範囲を見えたことにしないことです。
確認できなかったSaaSや取得エラーも残し、必要な対策を次に選べる状態にしていきましょう。
SaaS自体の提供形態を整理したい場合は、基礎の記事も参考になります。
参考資料
- 参考1：CMS — What is SSPM/How does it work/What happens when there are findings：API連携、設定とアクセス、発見後の調査/是正の担当が必要。CMS固有の無料/期間/製品数を一般化しない。
- 参考2：Microsoft — 概要と前提：接続されたSaaSの設定評価/改善提案。製品ライセンスと接続アプリ要件を限定例として使い、全SaaSへ拡張しない。
- 参考3：Palo Alto Networks — 連続監視で設定誤りと是正ワークフローを扱う製品例。ライセンスと対象アプリを確認する必要。常時即時/全設定自動修正を一般化しない。
- 参考4：AWS — What is CSPM：クラウド基盤のセキュリティ状態/設定評価を扱う。SSPMとの比較は対象を整理する本稿の説明。
- 参考5：Microsoft — 定義/利用制御/API scanning：クラウド利用状況とポリシー。すべてのCASBが全通信を即時遮断すると一般化しない。
