メインコンテンツまでスキップ

SSPMをSalesforceに適用するときの見方

目的​

SSPM（SaaS Security Posture Management）を検討するとき、話が混ざりやすい論点がある。

  • SSPMは単なる設定比較ツールなのか
  • 脆弱性対応にどこまで効くのか
  • ライセンスのユーザー数は、誰を数えるのか
  • Salesforceを対象にする場合、全従業員を数えるのか、Salesforce上のIDを数えるのか
  • 複数orgや複数テナントでは、同じ人が重複カウントされるのか
  • 検出結果は強制的に直すべきか、現場確認を挟むべきか

本記事では、SSPMを導入・見積もりする前提整理として、上記をSalesforceの例に寄せてまとめる。結論から言えば、SSPMは「SaaSの設定・権限・共有・連携を継続監視し、逸脱を是正運用につなげる管理基盤」と見るのが実務に合う。

ただし、ライセンス母数と是正範囲は製品ごとの差が大きい。ここを一般論で決め打ちすると、見積もりと運用設計を誤る。

先に結論​

SSPMは、SaaSの設定値をAPIで取得してベンチマークと比べるだけの製品ではない。実際には、設定不備、過剰権限、外部共有、OAuthやAPI連携、休眠ID、監査ログ、設定ドリフトを継続監視する製品群として捉える方がよい。CMSのSSPM解説でも、SSPMはSaaSアプリの設定不備、アクセス課題、コンプライアンスギャップを継続監視し、API連携で可視化するものとして説明されている。1

一方、SSPMはSaaSベンダー製品そのものへパッチを当てる装置ではない。脆弱性情報を受けて、自社テナント側に危険な設定、公開状態、過剰権限、危険な連携が残っていないかを確認し、是正判断を早めるための仕組みである。CMSも、SSPMの検出結果は従来型のパッチやソフトウェア更新ではなく、SaaSの設定に関する所見として扱うべきだと整理している。1

ライセンスの「ユーザー数」は、SSPMコンソールを触る運用担当者数とは限らない。むしろ多くの場合は、監視対象SaaS側のユーザー、対象SaaSごとのユーザー、アクティブアカウント、クラウドディレクトリ上のユーザーなどが母数になる。たとえばAWS Marketplace上のAppOmni公開価格では「100 Users per SaaS」という単位が示されており、CrowdStrike Falcon Shieldはクラウドディレクトリ上のユーザー数を基にする説明になっている。23

したがって、Salesforceに絞った見積もりでは、まず「対象Salesforce orgに存在するID群」を確認する。ただし、製品がディレクトリ単位で課金する場合や、企業全体のID基盤を母数にする場合は、SalesforceだけのID数では済まない可能性がある。ここは営業確認事項であり、一般論で固定してはいけない。

SSPMは何を管理するのか​

SSPMの中心は、SaaSのセキュリティ態勢を継続的に見ることである。Microsoft Defender for Cloud AppsのSSPM解説でも、SaaSアプリケーションのセキュリティ状態を可視化し、セキュリティ構成評価と推奨事項によってリスク低減を支援するものと説明されている。4

SSPMで見やすい論点は、だいたい次の領域に集まる。

領域確認観点
認証SSO、MFA、ローカルID、セッション、条件付きアクセス
権限管理者権限、特権ロール、権限セット、過剰権限、職務分掌
共有外部共有、公開リンク、ゲストアクセス、組織外コラボレーション
連携OAuthアプリ、API接続、外部アプリ、連携用ID、サービスアカウント
監査監査ログ、設定変更履歴、ログ保存、アラート
ID状態休眠ID、退職者ID、部分的な無効化、未使用の特権ID
標準準拠CIS、社内ポリシー、規制、ベンダーベストプラクティス

CrowdStrike Falcon Shieldの製品説明でも、SaaSアプリの設定不備、ID、脅威への可視性、過剰権限や休眠状態のID、連携アプリの発見といった機能が前面に出ている。5 つまり、SSPMの価値は「設定を一覧化すること」ではなく、「設定・ID・共有・連携のリスクを継続的に見つけ、是正に回すこと」にある。

脆弱性対応での位置づけ​

脆弱性対応の文脈では、SSPMを「脆弱性修正装置」と呼ぶと誤解が出る。SaaS本体の脆弱性を修正し、パッチを適用する主体は通常SaaSベンダーである。利用企業がSSPMでできるのは、自社テナント側の露出を早く把握することだ。

たとえば、あるSaaSで外部共有やOAuth連携に関係する脆弱性情報が出たとする。このときSSPMで確認したいのは、次のような点である。

  1. 影響を受ける設定を持つテナントがあるか
  2. 危険な公開設定や緩いアクセス制御が残っているか
  3. 関係する管理者権限、連携アプリ、サービスアカウントがあるか
  4. 既知の安全設定に戻せるか
  5. 例外設定を承認済みとして扱えるか

ここでの役割は、パッチ適用ではなく、構成面の露出確認と是正判断である。特にSaaSは利用部門が設定変更できる範囲が広く、時間とともに設定がずれやすい。脆弱性情報を受けた一回限りの確認だけでなく、平時から設定ドリフトを見ておくことに意味がある。

ライセンス母数は「誰が触るか」ではなく「何を監視するか」​

SSPMの見積もりで最も混乱しやすいのが、ユーザー数の意味である。

「ユーザー数」と聞くと、次のどれかを想像しやすい。

  • 顧客企業の全従業員数
  • SSPMコンソールを触る保守担当者数
  • 設定変更を行うシステム子会社の担当者数
  • 対象SaaSの利用者数
  • 対象SaaS内の総ID数またはアクティブID数
  • 共通ID基盤やクラウドディレクトリ上のユーザー数

しかし、SSPMの課金母数は「SSPMを操作する人」よりも、「監視対象環境の規模」で決まることが多い。公開情報だけでも、AppOmniはAWS MarketplaceでSaaSごとのユーザー単位を示しており、CrowdStrike Falcon Shieldはクラウドディレクトリのユーザー数を基にする説明になっている。23

この違いは大きい。もし「Salesforceだけを監視対象にするSaaS別ユーザー課金」であれば、Salesforceに存在するID群が見積もりの出発点になる。一方で「クラウドディレクトリ全体のユーザー課金」であれば、Salesforceを使わない従業員も母数に影響する可能性がある。

したがって、調達時には次を分けて確認する必要がある。

論点確認すること
費用負担者事業会社が払うのか、システム子会社が払うのか
監視対象母数何をユーザー数として数えるのか
運用利用者誰がSSPMコンソールを操作するのか
是正実施者誰がSaaS側の設定を変えるのか

事業会社がシステムオーナーで、システム子会社が保守を担う体制でも、この4つは別物である。システム子会社の保守担当者だけがSSPMを触るからといって、その人数がライセンス母数になるとは限らない。

Salesforceでは何を数えるべきか​

Salesforceを対象SaaSとして見るなら、最初に棚卸しすべきはSalesforce org上のIDである。

  • 一般利用者ID
  • 管理者ID
  • 権限の強い業務管理者ID
  • 連携用ID
  • サービスアカウント
  • 外部ユーザーやExperience Cloud利用者
  • 休眠ID
  • 無効化済みだが残存しているID

ただし、どこまでが課金対象かは製品と契約定義による。たとえば、総ID数か、アクティブID数か、一定期間ログインしたアカウントか、サービスアカウントを含むか、外部ユーザーを含むかで数字は変わる。CrowdStrikeのライセンスFAQでも、製品カテゴリによってアクティブアカウント、サービスアカウント、クラウドディレクトリユーザーなど、カウントの考え方が異なることが分かる。3

このため、Salesforceだけに焦点を当てる場合の現実的な整理は次の通りである。

対象通常の扱い
Salesforce内の一般利用者原則として確認対象
Salesforce管理者原則として確認対象
連携用ID、サービスアカウント契約定義次第だが、セキュリティ上は確認対象
休眠ID課金対象かは契約次第。リスク管理上は確認対象
Salesforceを使わない従業員SaaS別課金なら通常は対象外。ただしディレクトリ課金なら影響する可能性あり
SSPMコンソール利用者別枠の管理者課金がなければ、通常は主たる母数ではない

見積もりでは、Salesforceのライセンス数だけでなく、実際のユーザー、管理者、連携ID、休眠ID、外部ユーザーの棚卸しを先に行う方がよい。

複数org・複数テナントでは重複カウントを確認する​

Salesforceでは、企業が複数orgを持つことは珍しくない。SalesforceのData 360 Provisioningガイドでも、企業がM&A、地域運営、機能分離、規制・セキュリティ分離、歴史的経緯によって複数orgを運用することが説明されている。6

SSPMの見積もりでは、ここで重複カウントが問題になる。

たとえば同じ従業員 user@example.com が、Salesforce org Aにもorg Bにも存在する場合である。この人を1人と数えるのか、2つの監視対象アカウントとして数えるのかは、契約定義とベンダーの名寄せルール次第である。

確認すべきことは単純である。

確認事項意味
テナント単純合算かorg AのID数 + org BのID数で数えるのか
同一人物の名寄せ有無メールアドレス、IdP ID、社員番号などで重複排除するのか
サービスアカウントの扱い人ではないIDを課金対象に含めるのか
休眠IDの扱いログイン実績がないIDも含めるのか
外部ユーザーの扱い顧客、代理店、協力会社IDを含めるのか
最小課金単位SaaS単位、テナント単位、企業単位、ユーザーバンド単位のどれか

この確認を省くと、見積もりが簡単に崩れる。特に大企業では、Salesforce orgの分散、M&A由来の別環境、地域別環境、検証環境、外部ユーザーが絡むため、単純な従業員数では実態を表せない。

Salesforce orgは「必ず1社1org」ではない​

Salesforceのorg構成は、「1社なら必ず1org」でも「システムごとに必ず別org」でもない。SalesforceのSingle Org Architectureでは、単一のSalesforceインスタンスを中央に置き、複数の事業部やアプリケーションをその中で構成する考え方が示されている。7

一方、Salesforce Developers Blogのsingle-org versus multi-org戦略では、org戦略はエンタープライズアーキテクチャ上の意思決定であり、事業プロセスの統合度や標準化度、規制、セキュリティ、運用体制、コスト、統合複雑性を踏まえて判断すべきものとして整理されている。8

実務上は、次の整理が扱いやすい。

方針向いている条件
単一org寄せ顧客データを横断利用したい、業務プロセスを標準化したい、ガバナンスを中央集約したい、監査と監視をまとめたい
複数org機密分離が強い、法規制や地域要件が異なる、事業部ごとに独立性が強い、M&A由来の環境がある、データモデルや開発体制が衝突する

SSPM観点では、単一orgの方が監視対象と標準設定をまとめやすい。一方で、単一orgは例外管理が膨らみやすい。複数orgは分離統制しやすいが、設定基準、台帳、検出結果、名寄せ、コスト管理が重くなる。

結論としては、「可能なら単一orgまたは少数orgに寄せる。ただし、分離理由が強い場合はmulti-orgを前提に、監視・台帳・名寄せ・是正責任を設計する」が現実的である。

ASPはSSPM対象になるのか​

ASPという言葉は広い。古い意味では外部提供アプリケーション全般を指すこともあり、現在のSaaSに近いものもあれば、個別ホスティングされた業務アプリに近いものもある。

SSPMの対象になるかどうかは、呼び名よりも次の条件で判断する方がよい。

  1. 設定状態をAPIや管理連携で取得できるか
  2. 権限、共有、認証、監査ログ、外部連携が管理対象になるか
  3. テナント単位で継続監視する意味があるか
  4. 検出結果を是正ワークフローに載せられるか

名前がASPでも、実態としてSaaSに近く、設定・ID・共有・連携を継続監視できるならSSPM対象として扱える可能性がある。逆に、SaaSと呼ばれていてもAPIで設定取得できず、監査ログも取り出せないなら、SSPMで見える範囲は限定される。

国産SSPMと海外SSPMの見方​

国産か海外産かは重要だが、最初の評価軸にしすぎない方がよい。見るべきは、自社が監視したいSaaSに対して、どこまで深く見えるかである。

観点国産に期待しやすい点海外産に期待しやすい点
サポート日本語、国内商習慣、伴走支援グローバル標準のナレッジ
対応SaaS国内で需要のあるSaaSへの個別対応対応SaaS数の広さ、大規模実績
機能成熟度国内要件に合わせた運用支援検出ルール、連携、ワークフローの厚み
調達国内契約、国内支援体制グローバル契約、海外拠点展開

「国産だから安い」「海外産だから高機能」とは限らない。特にSSPMは、対応SaaS名が同じでも、見える設定項目、検出ルール、OAuth連携の深さ、是正手順、例外管理の有無が異なる。Salesforce対応と書かれていても、プロファイル、権限セット、外部共有、Connected App、監査ログ、ゲストユーザー、Experience Cloudまでどの深さで見えるかを確認する必要がある。

是正運用はハイブリッドにする​

SSPMの導入効果は、検出よりも是正運用で決まる。検出だけ増えて、誰も直さない状態になると、アラート疲れと例外の山が残る。

是正運用には極端な選択肢がある。

  • 全部を強制制御、自動是正する
  • 全部を現場ヒアリングで個別調整する

どちらか一方に寄せると運用が崩れやすい。重大で共通性の高い設定は強制統制し、業務要件と結びつく項目は例外管理や現場確認を挟む方がよい。

分類例運用方針
強制統制MFA無効、監査ログ無効、危険な外部公開、特権IDの放置期限を決めて是正。可能なら自動化または強制設定
例外管理付き統制特定部門だけ必要な共有設定、一時的な連携アプリ、検証環境の暫定設定例外理由、期限、承認者、再確認日を記録
現場確認前提業務権限設計、部門固有の承認フロー、既存運用に深く結びつく設定業務影響を確認して段階的に是正

この切り分けを事前に作ると、SSPMの検出結果を「全部危険」「全部任意対応」のどちらにも倒さずに済む。特にSalesforceは、権限設計が業務プロセスと直結しやすい。特権管理や外部公開は強く統制しつつ、業務権限の見直しは現場とシステムオーナーを巻き込む必要がある。

大きいSalesforceだけ先行導入できるか​

大規模なSalesforce orgだけにSSPMを先行導入する考え方は、理屈上はあり得る。特に、契約単位がSaaS単位、テナント単位、またはユーザーバンド単位であれば、大きい環境から始める導入計画は現実的である。

ただし、次の条件を確認しないまま前提にしてはいけない。

  1. ベンダーが部分導入を認めるか
  2. 最小課金単位はSaaS単位か、企業単位か
  3. 複数orgの同一人物を重複排除するか
  4. 監視対象外テナントをリスク説明上どう扱うか
  5. 将来ほかのSaaSやorgを追加するときの価格体系はどうなるか

部分導入は、PoCや段階導入としては有効である。一方で、企業全体のSaaSセキュリティ態勢を説明する場面では、監視対象外が残る。そのため「Salesforce大規模orgを第一段階にする」のか、「Salesforce以外も含めた全社SSPM構想の一部として始める」のかを明確にした方がよい。

調達時に必ず聞くこと​

最後に、見積もりと調達で確認すべき質問をまとめる。これはRFIやベンダー質問票にそのまま落とせる。

No.質問
1ユーザー数の定義は何か。総ID、アクティブID、クラウドディレクトリユーザー、対象SaaSユーザーのどれか
2Salesforce単位、Salesforce org単位、企業単位のどれで契約できるか
3複数orgに同じ人物がいる場合、重複排除されるか
4名寄せキーはメールアドレス、IdP ID、社員番号、その他のどれか
5サービスアカウント、連携ID、休眠ID、外部ユーザーを課金対象に含めるか
6SSPMコンソール利用者数は別課金か
7最小課金単位と最小契約期間は何か
8Salesforceで見える設定項目は何か。権限、共有、Connected App、監査ログ、Experience Cloudまで含むか
9検出結果は通知だけか、チケット連携、承認、例外管理、自動是正まで可能か
10例外管理に期限、承認者、再確認、証跡を持てるか
11日本語サポート、国内導入支援、国内時間帯の障害対応はあるか
12PoC時に本番orgへ接続する場合、必要権限、読み取り範囲、ログ取得範囲は何か

特に重要なのは、SaaS名だけで判断しないことである。「Salesforce対応」と書かれていても、自社が確認したい設定項目まで見えるとは限らない。

まとめ​

SSPMは、SaaSの設定・権限・共有・連携を継続監視し、逸脱とリスクを早期に把握するための管理基盤である。脆弱性対応においても、SaaS本体へパッチを当てるのではなく、自社テナント側の露出を確認し、設定面の是正判断を早める役割を持つ。

Salesforceに適用する場合、最初に見るべきはSalesforce orgに存在するID群である。ただし、製品によってはSaaSごとのユーザー数ではなく、クラウドディレクトリや企業全体のユーザー数を母数にすることがある。複数orgでは同一人物の重複カウントも起こり得るため、契約定義の確認が必須である。

Salesforceのorg構成は、単一orgか複数orgかの二択を思想で決めるものではない。業務標準化、データ統合、規制、機密分離、運用体制を踏まえて決めるエンタープライズアーキテクチャ上の判断である。SSPM導入時には、その判断結果を前提に、監視範囲、名寄せ、是正責任、例外管理を設計する必要がある。

最後に、SSPMの是正運用は「全部強制」でも「全部ヒアリング」でもない。重大で共通性の高い設定は強制統制し、業務依存が強い設定は例外管理や現場確認を併用する。このハイブリッド設計こそが、SSPMを単なる検出ツールで終わらせないための要点である。

参考資料​

Footnotes​

  1. CMS Information Security and Privacy Program, SaaS Security Posture Management (SSPM). https://security.cms.gov/learn/saas-security-posture-management-sspm ↩ ↩2

  2. AWS Marketplace, AppOmni-Prevent SaaS Breaches. https://aws.amazon.com/marketplace/pp/prodview-esohvavnjpcka ↩ ↩2

  3. CrowdStrike, CrowdStrike Licensing Metrics & FAQs. https://www.crowdstrike.com/en-us/legal/crowdstrike-licensing/ ↩ ↩2 ↩3

  4. Microsoft Learn, SaaS security posture management (SSPM) overview. https://learn.microsoft.com/en-us/defender-cloud-apps/security-saas ↩

  5. CrowdStrike, Falcon Shield. https://www.crowdstrike.com/en-us/platform/falcon-shield/ ↩

  6. Salesforce Architects, Data 360 Provisioning. https://architect.salesforce.com/docs/architect/decision-guides/guide/data-360-provisioning.html ↩

  7. Salesforce Architects, Single Org Architecture. https://architect.salesforce.com/diagrams/template-gallery/single-org-architecture ↩

  8. Salesforce Developers Blog, Enterprise Architecture: Single-org versus Multi-org Strategy. https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy ↩