SaaSプロバイダに求められるセキュリティ能力を整理/可視化するフレームワーク（SSCF）

コメントをどうぞ

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そのもののダウンロードおよびその他の参考情報について、以下に記述する。

付属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の支援・機能が必要となるためである。

以上

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA

*