第3回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第3回会議の内容をまとめて公開する。

2026年01月20日　18:30-20:00　開催

問題点の概要

BetterCloud社が公開した「Common SaaS security risks, horrifying recent breaches, and mitigation tips」において、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例、そしてそれらへの対策について解説している。第3回SaaSセキュリティリーグでは、ここで述べられている７つのセキュリティリスクについて、実際にSaaSのセキュリティ管理を行っている立場からディスカッションした。また、主なSaaSセキュリティリスクを軽減する方法（資料内の FAQ）の有効性についてディスカッションした。

SaaS 環境でよくあるセキュリティリスク

BetterCloud社が公開した資料で挙げられている7つのセキュリティリスクは以下である。

1. 設定ミス（Misconfigurations）
   • 誤った設定により脆弱点が露出。
   • 例：認証不要のページに内部データが公開された Salesforce サイト。設定ミスが侵害につながった典型例。
2. オフボーディングの遅延（Delayed offboarding）
   • 退職者アカウントが削除されずに残ると、データへの不正アクセスや情報窃取につながる危険性。
   • 例： Cash Appでの退職者によるデータ抜き出し事件を紹介。
3. 管理者権限の過剰付与（Excessive admin privileges）
   • 権限の過剰なユーザーがいると、侵害時の被害拡大リスクが高まる
   • 例：Verkada の内部カメラ映像が暴露された事件。
4. 認証情報の漏洩（Compromised credentials）
   • フィッシングや盗難によるアカウント侵害が依然として主要なリスク。
   • 例：Okta 社のサポートチケット情報にアクセスされた事例。
5. 過剰なアプリ権限（Overly permissive app data access）
   • サードパーティアプリに対して不要なデータアクセスを許可してしまうと、意図せぬ情報漏洩につながる。
   • 例： OneDriveで、アプリ連携（OAuth権限/スコープ）により過剰なデータアクセスが起こり得るリスクが指摘されているケース。
6. 不十分な第三者統合（Insecure third-party integrations）
   • 連携サービス側の脆弱性が本体システムへ影響を与える可能性。
   • 例：Okta 侵害 → Cloudflare の Atlassian への不正アクセスに波及。
7. 不適切なファイル共有（Improper file sharing practices）
   • 誰でもアクセス可能な公開リンクなどにより、機密データが漏洩する危険性。
   • 例：日本のゲーム会社 Ateam が Google Drive の公開リンクを誤設定し、長期間データ公開状態となった事件。

セキュリティリスクに対するディスカッション

上記SaaS 環境でよくあるセキュリティリスクについて、実際にどのように問題点として捉えているか、既に解決済みなのか、あるいは、どのような検討が行われているかについてディスカッションを行った。

1. 設定ミス（Misconfigurations）
   組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。
   組織全体で利用するSaaSの場合は、情報システム部門が直接対応しているので対策が取れている。部門等で利用するSaaSの場合は、情報システム部門が助言はするが直接対応はしていない。部門と委託先（SaaSの調達・管理を委託）が協力して対応できているところはできているが、部門が独自にやっている場合は難しい。情報システム部門としてチェックをしているが、数が多いため難しい場合がある。したがって、基本的な運用としては、監査において定期的なチェックを行うこととしている。
2. オフボーディングの遅延（Delayed offboarding）
   退職者アカウントについては管理できている。作業漏れの対策として、棚卸を定期的に実施している。部門で管理しているSaaSアカウントは、手動で管理するのは限界であり、人事システムとの連携が行えるようにIGA（Identity Governance and Administration）を利用することを検討している。人事システムとの連携ができるIGAは有効なツールになると考えている。その上で棚卸を実施し、定期的にチェックする。
3. 管理者権限の過剰付与（Excessive admin privileges）
   過剰権限、過剰設定を確認するチェックシートを作って管理している。チェックシートの中で最小権限等の指示を行っている。管理者権限の付与に対する対応は、どうしてもアナログにならざるを得ない。というのは、誰に対してどのような権限を付与するかについてはシステムオーナーしか分からないため、どうしても個別の対応になってしまう。したがって、情報システム部門としては、過剰権限になっていないかどうかのチェックを行うことで対応している。
   SSPMが過剰な権限を指摘してくれるので、SSPMを利用して管理を行うのは有効であるが、以前から指摘されているSSPMのコストの問題がある。
   管理者権限等の特権の管理としてPAM（Privileged Access Management）があり、これを利用することも考えられるが、現状はIaaSで一部利用している程度でSaaSでは利用していない。
4. 認証情報の漏洩（Compromised credentials）
   この問題も、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。組織全体で利用するSaaSでは、情報システム部門が管理しているため、条件付きアクセスの設定を付けることでアカウント侵害を防いでいる。しかしながら、部門等で利用するSaaSでは、どこまで徹底できているかは不明な部分がある。
   認証情報については、アクセス元のチェック、端末認証等を導入して対応している。これにより、モニタリングができているので、もしアカウントの漏洩が発生すれば、情報システム部門から注意するという運用ができている。
5. 過剰なアプリ権限（Overly permissive app data access）
   API連携の申請が来るケースがあり、情報システム部門でチェックしている。サードパーティアプリから不要なデータアクセスをされるケースには、APIアクセスキーのローテーションで対応している。最近課題として出てきているのは、Microsoft graphAPIに対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
   以前（第１回SaaSセキュリティリーグ）指摘されたが、AIが社内の見えないところを見てしまう、つまり、AIが社内の機密データを見つけて公開してしまう問題がある。自律型AIの権限をどうするのかは今後課題となる。
6. 不十分な第三者統合（Insecure third-party integrations）
   上記5で検討した内容と同様。
7. 不適切なファイル共有（Improper file sharing practices）
   ファイル共有については、ルール化をどう定義するかが難しいポイントである。Microsoft 365では、外部DLP製品に頼らず、自社クラウドの標準機能として DLP を公式に提供している。このDLP機能を使ってクラウドストレージサービスの共有問題に対応している。Google Driveについては、ダウンロードはOKにしているが、アップロードはNGとする対応を取っている。これは、CASB/SGWでコントロールしている。また、クラウドストレージに外部公開する場合には申請が必要で、申請があれば特定領域を共有できるようにするという運用でカバーしている。

主なSaaSセキュリティリスクを軽減する方法

以下の12個が、BetterCloud社が公開した資料でSaaSセキュリティリスクを軽減する方法の概要をFAQとして記述したものである。

1. Q1. SaaS ベンダーのセキュリティリスク評価はどのように行うべきか？
   SaaS ベンダー評価では、次の点を確認する必要がある：
   • SaaS プラットフォームの運用するデータセンターやインフラのセキュリティ体制データ暗号化（保存時／移動時）の仕組みアクセス制御（認証・認可）の方式実施済みのセキュリティ監査や認証（たとえばSOC 2など）
   • サードパーティ連携や API のセキュリティ設計・権限付与の仕組み
     これらの評価を自動化ツールで継続的にチェックすると、ベンダー変更や構成変化にも適応しやすくなる。
2. Q2. 多要素認証（MFA）をどのように強制するか？
   • できる限りすべてのユーザーに MFA を必須化する
   • MFA未設定のユーザーにはログインを拒否するルールを設ける
   • 権限レビューを定期的に実施し、認証強度を維持する
3. Q3. 従業員向けにはどんなセキュリティ教育をすべきか？
   • 最新のフィッシング手法の理解
     → フィッシング攻撃による認証情報漏洩防止
   • ファイル共有の責任ある利用法
     → 過度に公開リンクを作らない／意図しない共有範囲を避ける
4. Q4. SaaS 全体のセキュリティを常に把握する方法？
   「可視性の欠如」がSaaSリスクの根底にある。自動化された可視化／監視ツールの導入が有効。これによって次が可能になる：
   • 新規・非承認アプリの検出（シャドーIT）
   • ユーザーアクセスログとファイル共有状況の自動監視
   • 外部共有や不正アクセスのリアルタイムアラート
5. Q5. 「Super Admin（管理者権限）」の数を制限する方法？
   • セキュリティポリシーとしてアプリ毎に許容する最大Super Admin数を定め、しきい値を超えたらアラートを出す仕組みを設定
   • 単純な管理者数の制御だけでなく、不適切な権限拡大を未然に検知する
6. Q6. ユーザーのオフボーディング（退職時処理）はどう自動化するか？
   • SaaS 管理プラットフォームでは、退職者やロールチェンジの際にアカウントを自動無効化・権限削除するワークフローを設定可能。
   • これにより「幽霊アカウント」問題や放置されたアクセス権限のリスクを抑制できる。
7. Q7. 定期的なコンテンツスキャンをどのように実行するか？
   ファイルやデータをスキャンして以下を特定する：
   • 機密データ（PII、顧客情報、知的財産など）の所在
   • 過剰な共有設定ファイル
   • 不適切なアクセス権限が付与されたファイル
     これも自動化ツールが必要で、人手ベースでは難しい。
8. Q8. どのようなファイル共有モニタリングが必要か？
   • 外部共有の過剰検出
   • 許可範囲の過度な広さ（過剰権限）
   • 非アクティブ共有の把握と削除
     これらのモニタリングにより、ファイル共有に起因する漏洩リスクを削減可能。
9. Q9. ファイル共有方針を強制する方法？
   • 教育に加え、自動化された定期的なファイル権限のクリーニングやポリシー例外を検出する仕組みを運用することで、方針遵守を強制する。
10. Q10. SaaS セキュリティポスチャを高める最良の方法？
    • 強力なSSPM機能を持つ管理プラットフォームを使い、継続的な可視化、監査、ポリシー施行、自動リメディエーションを実施する。
11. Q11. インシデント発生時の即時対応（IR）計画はなぜ重要か？
    • 侵害疑いを検知したら、影響範囲の隔離、パスワード変更、侵害アカウントの停止、ファイル共有のブロックなどを迅速に行うIR計画が必要である。
    • これはインシデントの被害拡大を防ぐうえで極めて重要である。
12. Q12. ルート原因分析（Root-Cause Analysis）はいつ行うべきか？
    侵害の封じ込め後に実施。分析の対象は以下：
    • 初期侵入経路
    • 誤設定や脆弱性
    • データ抽出・ラテラルムーブメントのプロセス
    • 影響した他 SaaS との関連
      これらにより恒久的な改善策が設計できる。

主なSaaSセキュリティリスクを軽減する方法に関するディスカッション

上記の12個の対策に対して、ディスカッションした内容を以下に記述する。

1. MFAの強制について
   機密情報等を扱うSaaSについては、MFAは必須である。また、SSOへの対応も有効であり、SAMLで管理を行っている。これは、部門等で利用するSaaSで機密情報を扱う場合においても強制している。
   また、MFAができない場合には、グローバルIP等で制限を掛けることでSaaSへのアクセスを制限している。グローバルIPによる制限は、完全ではないが、想定外の国やネットワークからの直接アクセスが防げるということで有効である。
   また、業務に合わせて端末レベルでの制御も行っている。
2. 従業員向けのセキュリティ教育
   従業員教育は必ず実施しているが、きちんと理解されているかどうかは疑問なところもある。今後の対策として、教育を超えてシステム的な対策が必要であると考える。例として、一般的な内容ではなく、自分が直面するような問題・危機感を持たせるような（シナリオ的）教育を進めることが有効である。
   また、日常的な観点に基づいてコンテンツ化することも有効である。
3. SaaS セキュリティポスチャを高める方法
   これには、SSPMが有効であるが、実際にはコストの観点から広め切れていない。セキュリティの可視化ができないとリスクが分からないので、うまくSSPMを使う方法を考えていきたいし、ベンダー側の対応も期待したい。
4. インシデント対応
   SaaSのインシデントレスポンスでは、インシデントの検知の報告が、SaaS側ではなく利用者側からの報告ベースになることが多い。あるいは、代理店が検知して対応してくれるケースがある。これは、SaaS側からのインシデントの報告が十分でないことを意味しており、特に部門で利用するSaaSの場合この傾向が顕著である。

まとめ

今回は、SaaS 環境でよくあるセキュリティリスクと実際のインシデント事例とそれらへの対策について、BetterCloud社が公開した資料をベースにディスカッションを行った。「あるある」的な内容ではあるが、実際にディスカッションしてみて以下の点が明確になった。

1. あらためて、組織全体で利用するSaaSと部門等で利用するSaaSを分けて考える必要がある。情報システム部門が直接対応しきれない部門等で利用するSaaSへの対応をチェックリストや監査を通してうまく進めていくことが求められる。
2. 特権アカウントおよび権限付与の扱いが、SaaS利用においても重要になっている。これは、人手による対応では厳しい状況となっており、IGAやPAM等を効果的に使っていくことが求められる。
3. API連携の問題がクローズアップされてきている。これは、自組織側の管理だけではなく、連携元の管理にも依存してくるため、どのように連携して対応していくかを検討する必要がある。
4. SaaSのインシデント対応が重要になる。インシデントの報告がSaaS側からきちんと行われないと、利用者側で対応することができない。しかしながら、現状は、SaaS側からの報告があまり行われていないようである。利用者とSaaS側とのより良い連携が求められている。
5. いつも話題となるが、SSPMのカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

以上

CSAジャパン　クラウドセキュリティ自動化WGメンバー　諸角昌宏

本ブログでは、SaaSプロバイダに求められるセキュリティ能力を整理/可視化するフレームワークとしてCSAが提供しているSaaSセキュリティ能力フレームワーク（SSCF, SaaS Security Capability Framework）について解説する。

1. SSCFの背景
   SSCFが作られた背景として、企業におけるSaaS利用についての以下のような課題が上げられる。
   1. SaaS の利用数が急増、多様なSaaSを使う企業が増加
      1社あたりの利用数のデータは把握が難しい（SaaSの定義の違い、シャドーIT・部門契約の影響、頻繁に導入／廃止される）状況ではあるが、様々な調査レポートから判断するとこの傾向がみられる。
   2. 誤設定によるインシデントの増大
      CSAが提供しているクラウドコンピューティングに対する重大な脅威2024において、クラウド利用者の「設定ミスと不十分な変更管理」が一番の脅威として上げられている。
   3. SaaSプロバイダが提供するセキュリティ機能の差が大きい
      セキュリティに注力できるSaaSプロバイダと、あまり注力できないSaaSプロバイダがいるため、SaaSを利用する企業内でSaaSセキュリティの要求事項を統一することが難しくなっている。
   4. SaaSログの標準化の欠如
      SaaSごとにログ形式、ログ項目、イベント名、取得方法がバラバラであり、企業が横断的に監査、検知、可視化を行うことができない。
      
      こうした背景のもと、SaaS利用者が負うセキュリティ責任を統一的かつ実務レベルで遂行できるようにすることを目的として、SSCFが整理・策定された。
      
      
2. SSCFの目的
   SSCFの前提として、SaaS利用者が行わなければならないことをまとめてみると以下の2点である。
   1. SaaS利用者が直接設定/管理を行わなければならないこと（行うべきこと）
   2. SaaS利用者が直接管理できない領域を確認・判断すること（評価すべきこと）
      
      ここで、SSCFは、1のSaaS利用者が「行うべきこと」を対象としている。このSaaS利用者が直接設定/管理を行うにあたっては、SaaS利用者が自ら実施することができる部分と、SaaSプロバイダが提供する機能を使って実施する部分がある。後者のSaaSプロバイダが提供する機能を使用する場合、SaaSプロバイダが十分なセキュリティ機能を提供しないとSaaS利用者は設定を行うことができない。また、部門ごとに利用・管理されるSaaSセキュリティのベースラインを設定しようとすることも難しい。SSCFでは、このSaaSプロバイダがSaaS利用者に対して提供すべきセキュリティ機能を管理策として提供し、SaaS利用者が行うべきことを標準化することができるようにしている。IaaS/PaaSの場合、ほとんどのプロバイダが十分なセキュリティ機能を提供しているのであまり問題とはならないが、SaaSの場合、プロバイダが提供するセキュリティ機能がバラバラのため、SSCFのような管理策が必要とされている。
      
      
3. SSCFとは？
   SSCFを一言で言うと、「SaaS利用者がセキュリティ責任を「実行可能」にするための機能要件を提供するもの」である。SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を、SaaSプロバイダに要求し、標準化していこうという取り組みである。これを簡単な例で挙げると以下のようになる。
   
   
   
   SSCFでは、これをcapabilityと表現しているが、これは単に「能力」を意味しているのではなく、「必須となるセキュリティ機能」あるいは「利用者が設定/活用できる状態で提供される機能」と理解すべきである。これにより、SaaSにおける「設定できないリスク」を減らすことができる。その上で、SSCFは、技術的な機能だけでなく以下の3つのポイントにフォーカスしている。
   • 設定可能（Configurable）
     SaaS利用者がUI/APIを通じて、セキュリティ上の挙動そのものを変更・強制・制限できる。ただし、SaaSプロバイダの機能の内部実装は操作できない。
     例）MFA:　 利用者が有効化・強制できる。また、利用するかどうかの選択が可能である。
   • 技術仕様（Technical Dependency）
     SaaS利用者は操作できないが、SaaS利用者のセキュリティ管理（IAM/SOC/監査など）がSaaSプロバイダから提供される仕様などに依存する。
     例）ログの形式：　利用者は変更不可だが、SIEMに統合や監査を行うことができる。ログの取得は設定/構成可能だが、ログの形式は技術仕様となる。
   • その他（上記2つのポイントを補足・説明するための文書化/可視化に関する管理策）
     SaaS利用者が設定も操作もできず、SaaS利用者の管理が技術的に依存もしないがSaaSプロバイダが説明/可視化/内部運用として担保すべき事項である。
     例）可視化/通知：情報提供が必要である。
     
     以上のように、SSCFは内部統制のフレームではない。つまり、新たなコンプライアンス要件を求めているわけではない。あくまで、SaaS利用者が設定する、SaaS利用者は操作できないがSaaSプロバイダの機能に依存する、あるいは、SaaS利用者がSaaSの利用の説明目的で使用するのに必要となる管理策集である。
     
     
4. SSCFの６つのカテゴリーの内容
   SSCFでは、以下の6つのカテゴリーについて、SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を記述している。
   • CCC（変更管理と構成管理）
     • 定義されている内容
       SaaSのセキュリティ設定が「どのように構成」され、「どのように把握」され、「どのように変更」されるかを、SaaS利用者が管理できる能力を定義している。
     • 管理策のポイント
       SaaS利用者が設定/管理する以下の４つのポイントを記述している。
       • 現状のセキュリティ設定をプログラムで問い合わせることができること
       • 現在の設定状態を可視化できること
       • 設定変更が発生した事実を知ることができること
       • 設定内容を文書化することができること
         
         なお、ここで言う設定には、認証、RBACの割り当て、権限、アクセス許可、リソースACLなどがある。
     • DSP（データセキュリティとプライバシー）
       • 定義されている内容
         SaaS上で扱われるデータに対して、SaaS利用者が最低限のセキュリティ制御を適用できる能力を定義している。
       • 管理策のポイント
         SaaS利用者が不正データ、悪性データの取り扱いをコントロールできること
     • IAM（アイデンティティとアクセス管理）
       • 定義されている内容
         SaaSの利用者/権限/セッションをSaaS利用者が管理できる能力と、その管理が依存する機能/情報をSaaSプロバイダが提供することを定義している。
       • 管理策のポイント
         SaaS利用者が管理できることと、SaaSプロバイダがそのための機能と情報提供を行うこととして、以下の内容を定義している。
         • MFA、SSO、パスワード、セッション管理
         • ユーザー管理/権限管理
         • 認証/認可イベントの可視化
           
           なお、SSOなどは、機能提供を行うことがSaaSプロバイダにとって負担が大きいと考えられる。しかしながら、企業でのSaaS利用を考えた場合、SaaS利用者は数十から週百のSaaSを管理する必要があるので、SSOが必須機能と考える必要がある。
     • IPY（相互運用性と移植容易性）
       • 定義されている内容
         SaaSを他システムと連携あるいはほかのSaaSに移行する際に、SaaS利用者がセキュリティを保ったままコントロールできる能力を定義している。
       • 管理策のポイント
         • データエクスポートのコントロール
         • 外部アプリ/API連携の管理
     • LOG（ログとモニタリング）
       • 定義されている内容
         SaaSの挙動を、SaaS利用者が監査/監視/インシデント対応できる形で記録/取得/理解できる能力を定義している。
       • 管理策のポイント
         • どんなイベントがログに残るか
         • ログの形式と内容
         • 利用者がログを取得、活用する方法
     • SEF（セキュリティインシデント管理、Eディスカバリ、フォレンジック）
       • 定義されている内容
         SaaSでインシデントが起きた際に、SaaS利用者が通知を受け、事実確認や対応判断を行える能力を定義している。
       • 管理策のポイント
         • インシデント通知の方法・タイミング
         • 利用者が設定できる通知先
         • フォレンジック対応に関するSaaSプロバイダのポリシーの明示
           
           
5. SSCFの利用方法
   SSCFは、以下のようにSaaSプロバイダ、SaaS利用者、TPRM（サードバーティ・リスク管理）で利用することができる。
   • SaaSプロバイダ
     • SSCFに基づいて、SaaS利用者に提供するセキュリティ機能の実装方法の検討/開発を行う。
     • SSCFをセキュリティ機能のベースラインとする。SSCF準拠状況の情報を公開し、SaaS利用者が評価できるようにする。
     • SSCFフレームワークに基づいて評価回答を標準化し、SaaS利用者からの個別のチェックリストの評価に掛かる負担を軽減する。
   • SaaS利用者
     • SSCFに基づいて、セキュリティ機能の実装方法の検討/開発を行う。
     • SSCFをSaaS利用者のセキュリティポリシーのベースラインとし、各部門で利用しているSaaSのセキュリティ基準とする。
   • TPRM
     • SSCFをSaaSベンダー評価時のセキュリティ機能基準とし、リスク評価と調達プロセスを簡素化する。
       
       
       
6. SSCFのアーキテクチャ
   ここでは、SSCFがカバーしている範囲について考察する。
   まず、SSCFはCSAが提供しているCCM（Cloud Controls Matrix）をベースにしている。CCMは、クラウドセキュリティを包括的にカバーする管理策集であり、SSCFがCCMの管理策のどれをカバーしているか、また、どれはカバーされていないかを考えることにより、SSCFの有効性を理解することができる。CCMは以下の図で示すように17個の管理策のカテゴリーがあり、その中でSSCFがカバーしているカテゴリーは赤字で示した6個のカテゴリーである。
   
   
   SSCFがなぜ6個のカテゴリーをカバーしているかを理解するには、CCMに記述されているセキュリティ責任共有モデル（Shared Security Responsibility Model：SSRM）を理解することが必要である。SSRMは、クラウドサービスプロバイダ（CSP）とクラウドサービス利用者（CSC）の双方が、当事者ごとに管理策の所有と実施責任を理解するのを支援するため、CCMの管理策ごとに記述している。これを、「CSP-Owned（CSPが所有し自ら実施する責任）」、「CSC-Owned（CSCが所有し自ら実施する責任）」、「Shared Independent（CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任を負う）」、「Shared Dependent（CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を負う）」の4種類に分類して記述している。なお、SSRMの詳細については、「CCM v4.0実施ガイドライン セキュリティ責任共有モデルによるクラウドの保護」を参照していただきたい。
   SSCFは、SaaSプロバイダがSaaS利用者に対して提供すべきセキュリティ機能であるので、基本的に「Shared Dependent」が対象となる。また、機能だけではなく文書化・可視化が必要な部分があるため、一部「Shared Independent」が対象となってくる。ここではこのSSRMとSSCFとの関係について詳しく記述しないが、詳細については本書末尾の「付属A」を参照していただきたい。また、これを解説した資料である「SSCF（SaaSセキュリティ能力フレームワーク）解説　～　SaaSに実装されるべきセキュリティ機能と設定能力」を参照していただきたい。
   以上のように、SSRMに基づいてSSCFでは6つのカテゴリーをカバーしている。
   
   
7. SaaS利用者にとってのSSCF利用方法
   以上のSSCFの説明に基づいて、実際にSSCFを使ってSaaS利用者が行うことは、「自ら設定すべき管理を確実に実装し、依存せざるを得ない技術仕様を理解/前提化し、それ以外の事項を説明可能にすること」ということになる。したがって、以下の3つのポイントとなる。
   • SaaS利用者自らセキュリティ管理を実装、運用する。また、設定を自社セキュリティポリシーに適合し、設定状態を継続的に確認し維持する。
     • MFA 有効化・強制
     • SSO 設定・強制
     • ログ取得の有効化、など
   • SaaS利用者は、自ら操作することはできないが、管理の前提として評価を行う。
     • ログ形式/イベント種別、認証/認可イベントの生成、通知方法/タイミングの仕様の確認
     • 自社のSOC、SIEM、監査への組み込み、など
   • SaaS利用者は、SaaSプロバイダの内部運用などの情報に基づき文書化する。
     • SaaSプロバイダのセキュリティ設定の内容・挙動・制約を理解し内部文書に反映
     • SaaSプロバイダのログ仕様、ログ品質等を理解し内部文書に反映
     • SaaSプロバイダのフォレンジック支援に関する方針・対応可否を理解し内部文書に反映、など
       
       
8. SaaSプロバイダにとってのSSCF利用方法
   SSCFに基づいてSaaSプロバイダがすべきことは、SaaS利用者のセキュリティ管理を可能にするために必要な機能を、設定可能な機能と、依存される技術仕様として提供し、それ以外の責任範囲を明確に説明することである。
   • SaaS利用者が、自ら実装できる機能を提供/維持する
     • MFA、SSO機能の提供
     • ログ取得機能の提供、など
   • 技術仕様を明確に定義し、情報を提供する
     • ログ形式、イベント種別
     • 認証、認可イベントの生成
     • 通知方法、タイミング、など
   • その他の情報提供
     • 設定項目の説明、制約事項の説明
     • 重要な変更の通知
     • インシデント対応方針、など
       
       
9. まとめ
   SSCFにより、SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を、SaaSプロバイダに要求し、標準化していくことが可能になる。特に、企業におけるSaaS利用においては、全社的に利用しているSaaSの設定管理はIT部門が行っているが、個別の部門が利用しているSaaSの設定管理は、SaaSのセキュリティ機能のバリエーションの問題があり、あまり管理できていない。SSCFにより、SaaSのセキュリティ機能の標準化が行われることが非常に重要であると考えられる。SSCFがSaaSプロバイダおよびSaaS利用者に周知され、可能であればSSCFを強制できるような枠組みができていくことが望まれる。本ブログにより、SSCFが広く認識されることを期待したい。
   
   
10. 参考資料
    SSCFそのもののダウンロードおよびその他の参考情報について、以下に記述する。
    • SSCF資料
    • SSCF管理策 EXCELシート
    • ブログ「SaaS Security Capability Framework（SSCF）v1.0のご紹介：SaaSセキュリティのレベルを向上させる」
    • ブログ「SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性」
    • WGセミナー「SSCF（SaaSセキュリティ能力フレームワーク）解説　～　SaaSに実装されるべきセキュリティ機能と設定能力」資料
    • WGセミナー「SSCF（SaaSセキュリティ能力フレームワーク）解説　～　SaaSに実装されるべきセキュリティ機能と設定能力」ビデオ録画
      

付属A　CCMのSSRMの考え方

CSAのCCMで用いられている責任共有モデル（SSRM：Shared Security Responsibility Model）の責任の分類について説明する。その上で、SSRMとSSCFの関係について記述する。

• 責任共有モデル（SSRM）概要
  SSRMでは、CSAが提供するクラウドセキュリティの管理策集であるCCMのそれぞれの管理策に対して、クラウドプロバイダが実施するものとクラウド利用者が実施するものを明確化している。SSRMでは、これを4つの種類（CSP-Owned, CSC-Owned, Shared(Independent), Shared(Dependent)）に分類している。ここでは、この4つの種類の説明とこれらがCSCにとってどのような対応が必要になるかを記述する。なお、ここではSaaSに限定した話ではなく、すべてのクラウドにおいて適用される考え方のため、CSP、CSCという表現にする。
  • CSP-Owned
    CSPが所有し、自ら実施する責任。CSPは、CCM管理策の実施に全責任と説明責任を負う。
    CSP-Ownedでは、CSCは、「設定・管理を行わない」が「評価が必要」となる。具体的には、以下のような内容を「評価すること」が含まれる。
    • CSPのインフラ管理（パッチ、ネットワーク、安全性）
    • アプリケーションの管理（脆弱性管理、分離制御）
    • CSP従業員のアクセス管理
    • サービス可用性（冗長化設計、RTO/RPO）
    • 変更管理（仕様変更・API変更・機能廃止）
    • 再委託先（Subprocessor）の情報
    • 法律・規制要件（データの所在値）
  • CSC-Owned
    CSCが所有し、自ら実施する責任。CSCは、CCM管理策の実施に全責任と説明責任を負う。
    CSC-Owned は、CSCが、自身ですべて 「行うべきこと」となる。具体的には、以下のような内容を「行うこと」が含まれる。
    • アクセス管理（IAM設定・MFA・ロール割当）
    • 利用者アカウントのライフサイクル管理
    • ログの取得・分析
    • データ分類
    • 教育・手順・ポリシー
    • 自社側のインシデント対応
    • クライアント管理
  • Shared （Independent)
    Shared （Independent)では、CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任を負う。つまり、同一目的の管理策を、双方が独立して実装する責任を負う。CSCは、自身の実装とCSPの仕様が整合しているかを「評価すること」が必要となる。具体的には、以下のような「行うこと」と「評価すること」が含まれる。
    • CSCが独立して行うこと（管理を行う）
      • 社内のインシデント対応体制
      • 情報セキュリティ／SaaS 利用ポリシー
      • リスク管理
      • 利用者教育・意識向上
      • 内部ガバナンス
    • CSCが評価すること
      • プロバイダの IR 体制
      • プロバイダのリスク管理プロセス
      • プロバイダのガバナンス枠組み
      • 第三者保証
  • Shared （Dependent）
    CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を負う。CSPの提供機能に依存し、CSCは提供される機能の“有無”で、「行うべきこと」と「評価すべきこと」が分かれる。これは CSP側の提供機能にCSCの実装が依存することになる。具体的には、以下のような「行うこと」と「評価すること」が含まれる。
    • CSCが行うべきこと
      • IAM / 認証
      • ログ運用
      • データ保護（共有範囲・公開設定の管理など）
      • インシデント対応
    • 評価すること
      • IAM / 認証基盤
      • ログ基盤
      • データ保護機構（暗号化等）
      • セキュリティイベント通知

• SSCFとSSRMの関係
  SSCFの考え方から、以下のように考えられる。
  • CSP-Owned
    CSPが所有し、自ら実施する責任。CSPは、CCM管理策の実施に全責任と説明責任を負う。したがって、SSCFでは対象としていない。
  • CSC-Owned
    CSCが所有し、自ら実施する責任。CSCは、CCM管理策の実施に全責任と説明責任を負う。したがって、SSCFでは、対象としていない。SSCFは、CSCの活動にCSPの支援・機能が必要となる場合が対象となるためである。
  • Shared （Independent)
    CSPとCSCが互いに依存しない形で共有し、それぞれ独立して実施する責任がある。これは、依存はしてしないがCSPの仕様等の説明に基づいてCSCが管理を行う場合に対象となるため、一部対象となる。
  • Shared （Dependent）
    CSPとCSCの両者で互いに依存する形で共有し、それぞれ実施する責任を持つ。したがって、基本的にSSCFの対象となる。これは、CSCが実施するにあたってCSPの支援・機能が必要となるためである。

以上

第一回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第一回会議の内容をまとめて公開する。

2025年10月14日　18:30-20:00　開催

テーマ：SaaS上の機密データの不十分な可視性と脆弱なアクセス制御のリスクと対応

1. 問題点の概要（引用：「SaaSセキュリティの現状レポート2025年～2026年の動向と洞察」）
   • 企業の63%は機微データや機密データの外部への過剰な共有を最大のリスクとして挙げており、56%は従業員が機微データを未認可なSaaSアプリケーションにアップロードしていると報告している。
   • このようなリスクの主な要因は、効果的でない特権とアクセス管理の実践であり、組織の41%が最小特権アクセスポリシーが効果的に実施されていないと報告している。つまり、ユーザーやシステムが過剰な権限を保持することが多く、データ漏えいや権限の乱用、内部脅威のリスクが高まっている。
   • 人間のアイデンティティに限ったことではなく、生成AIの統合は、新たな複雑性のレイヤーを導入しており、多くの場合、タスクを実行するために、複数のアプリケーションにわたる機密データへの広範なアクセスを必要とする。組織の56%は、サードパーティベンダーやAIを搭載したSaaSツールが、データへの過剰なAPIアクセスを獲得することを懸念している。
   • SaaS のデータフローが一元的に可視化されておらず、SaaS 間の統合が監視されていない。企業の 42% が SaaS アプリケーション全体の機微データの追跡と監視に苦慮している。
     
2. ディスカッションのポイント
   • SaaSアプリケーション上のアクセス設定が徹底できていない
   • 最小特権アクセスポリシーが効果的に実施されていない
   • サードパーティベンダーやAIを搭載したSaaSツールに対する過剰なAPIアクセスとなっている
   • SaaS アプリケーション全体の機微データの追跡と監視が不足している

以下、ディスカッション内容をまとめる。

1. SaaS上の機密データの取り扱い
   • セキュリティ対策を考える前に、対象となるSaaSを明確化
     以下にリストしたように組織ごとに様々なSaaSの位置づけがあるが、一概にこれというものではないことが分かった。しかしながら、組織として対象となるSaaSを明確にすることは、具体的なセキュリティの問題の洗い出し・対策を取っていく上で重要である。
     • 社内の情報を預けるもの、IDのあるものをSaaS/クラウドと定義
     • データの持ち出しを念頭に置いて判断
     • 業務で使うものという括りで判断
     • 有償契約のあるクラウドを管理対象（ただし、無料であっても企業で使うケースもある）
       
       
   • 機密データをSaaSに上げることに対する管理の現状
     機密レベルに応じてSaaS/クラウド（ここでは、SaaSだけでなくクラウドとして捉えることが必要）に上げることができるデータとして、どのような基準を設けているかという問題に対して、以下のような意見が出された。
     
     • 機密データをクラウドに上げることは（極秘であっても）特に妨げてはいないが、機密レベルに応じて承認するかどうかを決めている。機密データの管理については、CASBのスコアベースで評価し、PaloAltoで止めるという方法を取っている。結果、リスクスコアが高いものはクラウドにアップロードできない。
       CASBのリスクスコアによる管理を行っている理由は、単純な仕組みで無いと従業員がついてこれないためである。
     • チェックリストに基づいて許可するかどうかを判断している。まずAssuredで評価し、それから独自のチェックリストに基づいて評価し許可を出している。技術的には、Zscalerのサービスでアクセス制御し、Web Filteringで制御している。
     • データ区分を設定して、データの重要度に応じてアクセスを制限している。IPアドレス等により、アクセスできる拠点、人等を管理する方法をとっている。
     • 使用できるSaaSを限定し、申請に基づいて評価している。技術的な管理は、SASEおよびCASBで実施している。
       
       各組織とも、SaaS/クラウドにアップできるデータに対する基準やチェックリストを設けて管理している。技術的には、CASBで管理し、その他の製品を使って制御していることが多い。チェックの仕方が煩雑だとうまく運用できない、特に部門主導のSaaSにおいては管理が難しいということもあり、できるだけシンプルな管理方法を取っている。
       
       
   • クラウド上の機密データの管理（過剰な外部との共有になっていないか？）
     機密データの外部への過剰な共有による情報漏洩が大きなリスクであることが言われているが、実際どのような状況なのか、また、どのように管理しているかについて、以下のような意見であった。
     
     • 部署の使い方（外部のゲストユーザの状況、退職者管理等）を、あらかじめ作成したチェック項目に基づいて管理している。また、棚卸、監査のタイミングで再チェックし、是正処置を実施している。
     • O365は外部と共有できないようにしている。BOXは共有に使っているが、ログを監査し対処している。
     • 外部だけでなく社内にオープンにされているケースが多いのも問題である。グループ内に閉じておかなければならない情報が共有できてしまっている（人事情報、パスワードなど）。たとえば、Sharepointが誰でも見れる状況になっていたりする。これは、AIの利用によりさらに問題となってきており、本来共有できない情報をAIが取り込んでしまう問題がある。
       
       以上のように、この問題に対しては基本的に管理的な対策に頼らざるを得ない状況のようである。しっかりした管理と定期的な監査・是正が求められる。
       
       
   • 最小権限アクセスポリシーが効果的に実施されていない
     これは、SaaS/クラウドに限らずオンプレでも同様であるが、ここでは、SaaSに限定して意見を出していただいた。
     • SaaSに対しては効果的な実施方法は無いのが実情である。オンプレであれば専門家が権限付与する時に申請ベースで動くことができ、過剰権限があれば運用において管理できる。
     • クラウドの場合、ツールの利用が必要である。SSPMであれば、過剰権限、SaaSに対する設定の確認、外部に公開されているリンクの検知などを行うことができる。SSPMによる可視化（公開設定管理など）もまた有効である。ただし、利用はまだ一部にとどまっている状況である。
     • アクセス権の付け間違いはどうしても発生する。データの管理者（SaaSの場合、特に部門）がそもそも理解できていないのが問題となるケースが多い。データをアップロードする人が一般事務の人だったりして、オンプレの慣習通りにアップロードしてしまい、クラウドにおいて問題となる。ITの専門家がいない部署が運営していて、設定がちゃんとしてない可能性があり、セキュリティ部門ではきちんとできているかを管理しきれない。
     • ツールの利用が考えられる。脅威インテリジェンス、アタックサーフェス用のツールで、公開されている情報を検知することが可能である。Avepointのようなツールが出てきており、うまく使うと有効であるという話もある。
     • ポリシーの教育は必須である。各拠点の担当者、エンドの利用者向けの教育を行っている。
       
       以上のように、効果的な管理は難しい状況ではあるが、SSPMやその他のツールを利用した技術的対策が有効であるので、検討していただくことが良いかと思われる。
       
       
   • 他社との共有リスク
     調査レポートの課題としては上げられてはいないが、クラウドストレージ等を使って他社と情報共有していることも問題になる場合がある。他社との共有は、会社間での情報のやり取りを行う場合、セキュリティ的にも有効な手段であるが、反面、利用者が誤って機密データを上げてしまい、それが他社と共有されてしまうという問題がある。この問題に対して現在取られている対策は以下である。
     
     
     • 外部の委託業者との共有、他社のBOX等の共有を使うケースは、基本禁止している。対策としては、管理を厳しく行っている。
     • この課題は、CASBで管理できる（他社と共有してはいけない機密情報をクラウドに上げるのを制限する）が、自社が管理している共有サイトは管理できるが、他社が管理しているサイトだと難しい。
       
       この問題は、クラウドストレージの利用が禁止される典型的な例であり、なかなか管理が難しい。引き続き、検討が必要なものと考えられる。
       
       
2. その他
   以上の議論とともに、以下の3点についても検討が必要であるとの意見があった。
   
   • データセキュリティの観点
     
     • データの機密性を従業員が適切に判断するのが難しいケースが多い。そのため、社内ポータルに上げてはいけない極秘データを簡単においてしまったりするケースがある。機密区分を人に頼るのではなくAIによって自動的に判定するようなことができるとこのような問題は少なくなるかと思われる。
     • DLPで制御させるためのタグ付けに対して限界を感じている人が多く、もっと踏み込んだ対策が求められている。DSPMには「AIによるファイルの機密区分の判定」などの機能があり、これが有効なツールとなる可能性がある。
       
   • Need-to-knowが分かる、あるいは、理解できる仕組み
     
     • 読みたい人がアクセス権を要求できる仕組みの方が良いのかもしれない。現状は、データオーナーの責任においてアクセスできる人を決めているが、これを読むべき人が自動的にNeed-To-Knowになるような仕組みができると良いかと思われる。
     • Need-to-knowを徹底できる仕組みとしてワークフロー化する方法では、共有グループのアクセス権の設定に対して承認を行うプロセスを作ることができる。
       
   • ブラウザのロギングの強化
     
     • ブラウザのロギングがしっかりしていれば管理しやすくなると思われる。独自のアプリ以外はブラウザ経由なので、しっかりしたログを出してほしい。これができると、ログ分析する時に非常に有効になると思われる。現状は、アクセスログぐらいしか出されていない。
       
       
3. まとめ
   今回のSaaSセキュリティリーグでの議論を以下の2点にまとめる。
   
   • SaaS上の機密データの取り扱いの問題は、管理的対策と技術的対策をうまくミックスさせて行うことが必要と思われる。チェックリスト等の整備、定期的な見直しとしての監査/是正を愚直に進めることが必要になる。CASB等のツールによる技術的対策は、管理的対策を補完する形で有効に利用できると思われる。
   • 最小権限アクセスポリシーが効果的に実施されていない問題は、ツールの利用が有効である。また、ポリシーの徹底のための教育は継続してきちんと行っていくことが求められる。

以上

SaaSのセキュリティ運用負荷を軽減させる方法とは

クラウドセキュリティ自動化WG
株式会社マクニカ
根塚　昭憲

クラウドセキュリティ自動化WGでは、クラウドセキュリティにおける運用担当者の方の負担を少しでも下げるために、様々な監視自動化の仕組みを紹介したいと考えています。まずはSaaSのセキュリティ自動化について取り上げたいと思います。

DXの中で進められていた業務システムのクラウド化は、コロナウイルス感染拡大に伴う企業のワークスタイルの変化によりさらに加速。企業ではテレワーク、Web会議システム、オンラインストレージなどのクラウドサービスなどのSaaSの導入が飛躍的に進みました。SaaSは拡張性もあり、導入もしやすい一方で、企業の機密データを扱うケースも多く、高度なセキュリティが求められています。

一方で、SaaSからの情報漏洩インシデントも多く発生しており、いくつか例を挙げたいと思います。

• 【複数企業で発生した事例】（２０１９年）
  プロジェクト管理システム（Jira）における、グローバル設定での設定不備により主にUSの企業データと個人情報の漏洩のリスクが露呈
• 【Microsoft PowerAppsの事例】（２０２１年）
  Microsoft Power Appsの設定ミスにより、個人情報、社会保障番号、氏名、メールアドレスなどの機密データが計3800万件流出
• 【某教育委員会の事例】（２０２２年）
  公立小・中・義務教育学校の令和3年度末退職予定者を対象にGoogleフォームを使って行ったアンケートにおいて、回答者に対し、結果の概要を共有する設定にしてしまったことにより、回答者の名前が他の回答者に閲覧できる状態であったことが判明した

Google Formsの結果の概要を表示する設定（デフォルトは無効）

• 【複数企業で発生した事例】（２０２２年）
  複数の企業が、タスク管理ツール(Trello)の設定を誤って利用し、社内情報や個人情報が外部に公開され、検索可能となっていたことが判明。内閣サイバーセキュリティセンター（NISC）からも注意喚起が行われるほど、話題となりました。
• 【某自動車会社様の事例】（２０２３年）
  ソフトウェア開発用のプラットフォーム(GitHub)において、データベースへのアクセスキーを含むソースコードが公開状態となっていた。このアクセスキーを利用することで、データサーバーに保管されているメールアドレスおよびお客様管理番号にアクセスできたことが判明。多くの場合、これらの問題はSaaSの設定不備から生じています。
  この点を示すデータとして、2022年に実施されたCSAの調査^※1では、SaaSセキュリティインシデントの63％が設定不備に起因する可能性が示唆されています。さらに、IPAが公表したデータ^※2によれば、2022年の不正アクセスの原因別比率では、設定不備が全体の16.1％で2位にランクされています。このことからも、SaaSの設定不備の対策検討が非常に重要であることがわかると思います。
  

なぜセキュリティ的に問題が発生しうる設定不備が発生するのでしょうか。
その答えは単純な作業ミス、設定ミスという人為的な問題ではなく、以下のような様々な要因が複雑に絡んで発生していると考えられます。

• 【少ない設定監査機会と手動での設定チェック】
  国内の企業でよくあるSaaSの導入プロセスとして採用判定時に、セキュリティチェックシートなどを活用してSaaS全体のデータ管理方法や、物理セキュリティ、コンプライアンスなどを確認してから利用可否を決定します。その後でSaaSの設定が行われていくのですが、設定が適切かどうか、セキュリティ的に問題が無いかどうかの確認はその導入時のみで、その後、セキュリティ設定の定期的な確認や監視を怠っている企業は少なくありません。さらに、定期的に設定確認を実施している企業でも、手動で設定を確認している場合もあります。この手動での設定確認は時間とリソースを消費し、SaaS利用数が増えれば、その対応量も増えていきます。そのため、運用に対応できない状況や工数ばかりかかる事態を招きかねません。
• 【SaaS毎に異なる設定と適切な設定判断】
  SaaSプロバイダーは異なる用途に対応するために多様な機能を提供し、その動作仕様や設定内容はSaaSごとに異なります。そのため、セキュリティの高い設定や、利用者の利便性も損なわない最適な設定を、各ベンチマーク（CISやCCMなど）を元に適切に判断してくことは、比較的難しいと思われます。このことも設定ミスを招く要因の一つと言えるでしょう。
• 【セキュリティ部門以外での運用管理】
  事業部でSaaSの運用管理を一任されているケースもあります、セキュリティ担当ではないチームで運用を行う場合、上記のような設定監視運用やセキュリティチェックの複雑さに対応しきれないケースも考えられ、このような運用体制の課題も要因の一つとして考えられます。実際に、CSAの調査^※1でも、SaaSの設定に最も責任を持つ部門はセキュリティ部門が59％、IT部門が50％、そしてビジネスアプリケーションの所有者が40％という結果が出ており、これはセキュリティ部門の外に存在する複数の部門がSaaSの設定に関与していることを示しています。

また、上記の要因をさらに加速させている背景として以下も考えられます。

• 【SaaS運用管理の複雑さの増加】
  • SaaS設定の可視性の欠如
  • 企業が管理するSaaS数の増大（11SaaS以上導入する企業が3割以上、40SaaS以上の企業も増加）^※3
  • SaaSの更新頻度の高さ
  • SaaSとSaaS間におけるデータ連携、API連携の増加における複雑性の増大
  • デフォルト設定では十分なセキュリティが考慮されていないケースがある

このような状況の中で、セキュリティ課題、運用課題を自動的に解決できる仕組みが、SaaS　Security Posture Management（SSPM）と呼ばれるソリューションがあります。これはSaaSアプリケーションの設定不備によるインシデント(不正アクセス、機密情報流出、etc)を予防するためのソリューションとなります。
CSPM（Cloud Security Posture Management）と名称が似ていますが、CSPMは主にIaaSに対する設定監査の機能を提供するのに対し、SSPMはSaaSに対する設定監査を提供するという違いがあります。

SSPMは主に以下の機能を提供します。

• 構成、設定の分析/追跡の自動化
• コンプライアンス準拠状況の評価
• データアクセス権の評価
• リスクの検出
• 分析結果の可視化
• ダッシュボード
• アラート
• リスクを軽減するための改善方法の教示
• 設定項目
• 設定パラメータ

動作としては主にAPIで各SaaSに対してアクセスを行い、設定情報を網羅的に監視・解析します。製品にも依存しますが、各設定をセキュリティベンチマークと比較し、どの程度準拠しているかを即座に確認することが可能です。ほぼ全てが自動化されているため、今まで数日かかっていた目視・手動での設定確認作業は不要となります。一部のSSPMでは、設定に課題がある場合、影響を受けるユーザをリストアップしてくれる機能もありますし、設定の修正案を提示、SaaS間連携の可視化など、SaaSの設定をセキュアに維持できる機能を備えています。そのため、先ほど挙げた設定ミスの複数の要因を網羅的にカバーできるソリューションとなっています。

SSPMは比較的新しいソリューションで、徐々に市場に浸透しつつあり、お客様の実績も出てきてます。
ただ、海外ベンダーが提供しているSSPMの対応SaaSの9割以上が海外製SaaSとなっており国産SaaSへの対応はまだ十分ではありません。SSPＭの利用を検討されている日本のお客様からも国産SaaSの対応数を増やしてほしいという声が多くあがっています。これは今後のSSPMが普及しいく中での課題といえるでしょう。

代替のツールとして各SaaSベンダー自身が提供する各テナントの設定状況チェックするツールもありますが、提供元のSaaSしか監視できない可能性が高く、SaaS毎の管理が必要となり煩雑さが残ります。そもそも大手SaaSベンダー以外からはそのようなツールがリリースされていない現状もありますので、その点でも複数のSaaSを管理しているのであれば、一気通貫で確認できるSSPMの方にメリットがあると考えています。

また、類似のソリューションとして、CASBがあげられます。
CASBの機能の一つに、APIを使って各SaaSに対するコントロールを実現する機能がありますが、どちらかというとユーザのアクティビティ監視やファイルチェックを行うことがメインの機能となっており、SSPMがカバーする設定の監査機能とは別物になります。
ただし、ベンダーにもよりますが、CASB機能の一部としてSSPM機能が提供されるケースも出てきていますので、SaaSのセキュリティ全体を検討される際にはしっかり理解してご検討いただきたいと思います。

まとめ

SaaSからの情報漏洩の原因の多くは設定不備となっており、今後も利用の増加が見込まれるSaaSに対し、何かしらの対策がクラウドセキュリティの観点からは必要です。このような課題を解決するためにSaaS Security Posture Management（SSPM）が注目されています。SSPMは自動化された監視と改善のツールで、SaaSのセキュリティを強化し、設定不備から引き起こされる問題を軽減、同時にそれにともなう運用負荷も削減できます。今後のクラウドセキュリティ強化の一案としてSSPMも検討してもらえればと思います。

参考文献

※1 https://cloudsecurityalliance.org/artifacts/saas-security-and-misconfigurations-report/

※2 引用元：コンピュータウイルス・不正アクセスの届出状況 ［2022年（1月～12月）］

※3 引用元：株式会社メタップス「2022年度 SaaS利用実態調査レポート」

以上

Understanding the Two Maturity Models of Zero Trust
ゼロトラストの2つの成熟度モデルを理解する

本ブログは、CSA本部のブログに公開されている「Understanding the Two Maturity Models of Zero Trust」の日本語訳となります。原文は、こちらを参照してください。本ブログは、著者の許可のもとに翻訳し公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。

Blog Article Published: 05/17/2023
Written by John Kindervag, Senior Vice President, Cybersecurity Strategy, ON2IT Cybersecurity.

ゼロトラストの世界における一番の間違いは、一枚岩的な思考です。一口で象全体を食べることが可能であると信じてしまっていることです。組織の最大の間違いは、すべてのゼロトラスト環境を同時に展開しようとすることです。規模が大きすぎるのです。その結果、すぐに失敗します。このような組織は、ゼロトラストについて考え、議論することにすべての時間を費やしていますが、実際に実行に移すことはできません。

2つ目の関連する間違いは、戦術的に考えすぎてしまうことです。製品や技術にのみ焦点が当たってしまっています。戦略を投げ捨てています。このような技術への過度の集中は、サイバーセキュリティの目的である「何を守る」ということを見失わせます。

このことは、進捗を測定することを難しくしています。私は、サイバーセキュリティの進歩を測る最適な方法は、成熟度であると確信しています。

Forrester Researchに在籍中、私は包括的な企業サイバーセキュリティ成熟度評価プロジェクトに携わりました。その後、私はそれをゼロトラストの最初の成熟度モデルに適応させ、報告書にまとめました： “Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model “というレポートです。(注)私がレポートを執筆したのは2016年末ですが、出版されたのは私がForresterを退社した後の2017年です。筆者名のところに私が3番目に記載されているのはこのためです)。

“Asses Your Network Security Architecture with Forrester’s Zero Trust Maturity Model” レポートの最初のページが以下です。

図1

何年もかけて、実際の顧客との関わりの中で、このモデルを改良する機会を得ました。このモデルは、NSTACの報告書の中で体系化されています。Appendix Aをご覧になれば、より深く理解することができます。

簡略化した図が下の図です。これは、最近CSAで行ったプレゼンテーションも含め、モデルを説明する際に使用している図です。

図2

この成熟度モデルは、「ゼロトラスト」の5ステッププロセスに基づいており、プロテクトサーフェス単位でスコア付けされます。カーネギーメロン大学が開発した標準的な5段階の成熟度パラダイムを使用しています。

各プロテクトサーフェスは個別にスコア付けされます。このモデルでは、プロテクトサーフェスとDAASの両方の要素を特定することが必要です。このようにして、成熟度のスコアを管理しやすい一口サイズの塊に分割しています。プロテクトサーフェスとしてディレクトリサービスを使用した例は、NSTACの報告書のAppendix Aに記載されています。

つまり、プロテクトサーフェスが完全に最適化されていれば、最大25点というスコアで採点されることになります。ON2ITでは、このようなことはほとんどありません。

図3

次に、すべてのプロテクトサーフェスを集計して、組織の総合スコアとプロテクトサーフェスごとの平均スコアを定義することができます。この例では、平均成熟度スコアは3.8であることがわかります。また、すべてのプロテクトサーフェスにおける成熟度の分布も見ることができます。この情報をもとに、組織は成熟度の低い特定のプロテクトサーフェスを重点的に強化することができます。

図4

では、新しいCISAゼロトラスト成熟度モデルはどのようにフィットするのでしょうか。この成熟度モデルは、実は5ステップ成熟度モデルにうまく統合されています。両者は補完関係にあると考えたほうがよいでしょう。

図5

私は最近、CISAの本社に行き、CSA Zero Trustの運営委員会のメンバーであるSean ConnellyとJohn Simmsを含む、この文書を作成した数人の人物とこの話題について話し合う機会を得ました。私たちは、5ステッププロセスの各ステップで使用される適切なテクノロジーをどのように定義できるかについて議論しました。

プロテクトサーフェスごとの成熟度モデルとCISA成熟度モデルの間のほとんどのマッピングは、ステップ3：ゼロトラスト環境の構築で行われます。以下は、ON2IT AUXOマネージドサービスポータルでどのように表示されるかの例です。

図6

どのコントロールが実施され、どのコントロールがまだ必要なのかを確認することができます。ポータルサイトでは、プロテクトサーフェスをForrester ZTXフレームワークまたはCISA成熟度モデルにマッピングしたレポートを作成することができます。

ForresterのZTXフレームワークといえば、まさにPillar（柱）成熟度モデルの前身といえるでしょう。Chase Cunningham博士がフォレスター・リサーチに在籍していたときに作成したもので、「プロテクトサーフェスごとの成熟度モデル」を補完するために作られました。この歴史は失われてしまいましたが、フレームワークの意図と、それがどのように “柱” につながったかを理解することは重要です。ChaseとForresterの彼のチームは、称賛に値します。

図7

では、どちらの成熟度モデルを使うのが良いでしょうか？その答えは、両方です。なお、CISAの文書には、「CISAのZTMMは、ゼロトラストへの移行をサポートするための多くのパスの1つです」と記載されています。

多くの組織が「柱のモデル」を文字通りに受け取りすぎており、それが重大な実装の問題につながっています。例えば、ある組織は、左から右へ進めていく必要があると考え、アイデンティティの柱から始めます。組織内のすべてのアイデンティティの問題を解決してから、デバイスの柱に移らなければならないと考えています。しかし、これは不可能なことです。この組織は、ID のアップグレードが必要な数千のシステムがあることを認識します。また、多くの組織と同様に、組織全体で複数の異なるIDソリューションを使用する必要があります。そのため、たとえ 1つのシステムの ID ソリューションを最適化できたとしても（CISA モデルのレベル 4）、すべてのシス テムの成熟度レベルは 1 のままになります。これはおそらく永久に続くことでしょう。

よりシンプルで効果的なソリューションは、1つのプロテクトサーフェスを取り上げ、柱にまたがる既存のコントロールをマッピングし、成熟度のギャップを判断することです。その情報をもとに、組織はプロテクトサーフェスの成熟度を向上させるためのプロジェクトを立ち上げることができます。そして、プロテクトサーフェスの成熟度をCISAモデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上