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モデルにマッピングしたレポートを作成すれば、短期間で進捗を確認することができます。

以上