カテゴリー別アーカイブ: 未分類

ISMSを基盤としたゼロトラストの展開

CSAジャパン ゼロトラストWG 諸角昌宏

ゼロトラストに取り組んでいる組織が増えている中、ゼロトラストの戦略を曖昧にしたままセキュリティ製品の導入に走っているケースが見受けられる。ゼロトラストは、今までのセキュリティの考え方、特にリスク管理の延長線上にある考え方である。すべてのアクセスを検証する、最小権限の原則、継続的な監視とログ分析など、今までのどちらかというと静的なセキュリティ対策に対して、動的なセキュリティ対策にしていくことにより、現在のITシステムの環境に適合させていこうというものである。したがって、ゼロトラストの考え方や戦略を正しく理解し、自組織に適用していくことが求められる。

本ブログのベースになっている「ISMSを基盤としたゼロトラストの展開」資料では、ゼロトラストの考え方を理解するために3つのゼロトラスト導入戦略(NIST SP800-207、CISA成熟度モデル、NSTACモデル)を説明し、ゼロトラストの考え方や戦略の理解を深めたうえで、ISMSフレームワークにゼロトラストを採用する方法について考察している。したがって、ゼロトラストの戦略についてはそちらの資料を参照していただくこととし、本ブログではISMSフレームワークにゼロトラストを採用する方法についての考察を説明する。

なぜISMSフレームワークにゼロトラストを採用する方法を考えたか?

まず、ISMSフレームワークにゼロトラストを採用する方法を考察した理由について説明する。

ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第896号:「ゼロトラストアプローチとリスク論的アプローチ」(https://digitalforensic.jp/2025/10/20/column896/)において佐々木良一 理事(東京電機大学 名誉教授 兼同大学サイバーセキュリティ研究所 客員教授)が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク=損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク=影響度x発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ=影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」(対象システムの重要性)についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。 そこで、「ISMSを基盤としたゼロトラストの展開」資料では、リスク管理プロセスにゼロトラストを統合させることでこれを実現することを考察した。さらに、リスク管理プロセス(ISO 31000 / ISO 27005)にゼロトラストを統合させるという概念的な話よりは、リスク管理プロセスを中核に据えているISMS(ISO/IEC27001)のプロセスにゼロトラストを統合することで、より実際に利用できる方法となると考えた。ISMSは、日本では約60%の組織が認証を取得しているように広く普及しており、このフレームワークにゼロトラストを統合させることが有効であると考えた。なお、リスク管理プロセスにゼロトラストを統合させるには、NISTのサイバーセキュリティフレームワーク(CSF)などをベースにすることも考えられるので、ISMSに限定する話ではないことは述べておく。

ISMSフレームワークにゼロトラストを統合させる方法

ISMSを基盤としたゼロトラストの展開」資料では、以下の仮想のインターネットオーダーシステムを用いて、これに必要となるISMSのプロセスとそれに統合するゼロトラストについて説明している(本ブログの図は、すべてこの資料より引用している)。詳細については、そちらの資料を参照していただくとして、ここではそのポイントとなる以下の点について説明する。

  1. 資産特定の考え方
  2. リスクアセスメントにおけるリスクスコアの考え方
  3. 適用宣言書の考え方
  4. モニタリングおよびレビューの考え方

1. 資産特定の考え方
資産特定として、ゼロトラストで説明されているプロテクトサーフェスを用いた。プロテクトサーフェスは、ビジネス情報システムとして資産の集まりとして管理する方法で、理解しやすく、関連する一連のトランザクションフロー、アーキテクチャ要素、アクセスポリシーの作成が容易となる。したがって、プロテクトサーフェスごとに管理することで、従来の資産ごとに比べて管理しやすいことになる。また、ゼロトラストの段階的な導入をこのプロテクトサーフェスごとに行うことができるため、既存の資産はISMSで管理しながら、定義できたプロテクトサーフェスから順次ゼロトラスト化していくことが可能になる。もちろん、対象となる資産を従来ISMSで用いたものをそのまま扱うことも可能であるが、プロテクトサーフェスとして管理することの方がメリットがあると考えている。
以下が、オンラインオーダーシステムを想定したプロテクトサーフェスの例である。

2. リスクアセスメントにおけるリスクスコアの考え方
リスクスコアとして、CISAのゼロトラスト成熟度モデルの成熟度を使用し、以下の観点でリスクスコアを計算する。

  • 影響度:資産の重要性に基づいてプロテクトサーフェスの重要度を評価

  • 発生確率:ゼロトラスト成熟度で評価

ここで、発生確率として成熟度を使用する理由であるが、CISA成熟度モデル(従来 → 初歩 → 高度 → 最適)を「セキュリティコントロールの強度」とみなし、成熟度が上がるほど発生確率が低下するとして評価に利用することができると考える。また、成熟度の向上に応じてリスクスコアがどう下がるかを定量的に評価することが可能になると考える。

以下が、オンラインオーダーシステムを想定したリスクスコアの例である。なお、発生確率は同じレベルにおいても振れ幅を考慮して数値化している。なお、ここではプロテクトサーフェス単位でリスクスコア化しているが、プロテクトサーフェスに含まれるトランザクションフロー単位、あるいは、プロテクトサーフェスに含まれるそれぞれの柱単位にリスクスコアすることも可能である。

    3. 適用宣言書の考え方
    ISMSでは管理策に基づいた適用宣言書が必須となる。ここは、ISO/IEC27001の管理策に対してプロテクトサーフェスとしてどのような管理になるかを記述し作成することができると考える。
    以下が、オンラインオーダーシステムを想定した適用宣言書の例の一部である。

    4. モニタリングおよびレビューの考え方
    ここでは、ゼロトラストの特徴であるリアルタイム性を持たせたリアルタイム/継続的なモニタリングと自動化による改善を行うことを考える。ログ、テレメトリ、ユーザー行動分析(UEBA)などを用いて、リアルタイムにアクセスを監視し、継続的評価とポリシーの調整を繰り返すことで、ゼロトラストの成熟度を高めるように進める。これにより、ISMSを動的かつ継続的に補完することができるものと考える。
    以下が、オンラインオーダーシステムを想定したモニタリングおよび改善の例である。

    まとめ:ISMSフレームワークにゼロトラストを統合させるメリット

    ここで述べた方法によるメリットをまとめると以下の3点になる。

    1. ゼロトラスト化においてリスク論的アプローチを併用することを実現できる。
    2. ISMSの延長線上にゼロトラストを統合させていくことで、ゼロトラストを1から始めることによる労力、投資を抑えることができる。
    3. リモートワークの普及、クラウドサービスの普及拡大など、ゼロトラストの導入は組織の喫緊の課題であり、ISMSフレームワークをベースとすることでスムーズな移行およびスモールスタートが可能である。既存のISMSはそのまま維持・継続しながら、プロテクトサーフェスごとにできるところからやり、ステップアップしていくという方法が取れる。

    このような点から、ISMSという既存のフレームワークを利用することで、ゼロトラストへの効果的な移行が可能になると考えられる。今後は、これを実際にユースケース化していくことを考えていきたい。

    以上

    クラウドファースト時代における特権アクセス管理解説

    CSAジャパン 諸角 昌宏

    特権的なアクセス権限は、ユーザーに異なる役割が割り当てられるあらゆる環境でセキュアに管理する必要がある。適切なコントロールが講じられていない場合に、組織は内部での不正利用や外部からの脅威に曝される。このような状況において、PAM(特権アクセス管理、Privileged access management)の重要性が高まっている。
    本ブログでは、PAMの現在の位置づけを整理した上で、CSA本部がクラウドファースト時代における特権アクセス管理、Managing Privileged Access In a Cloud-First World」として公開した資料に基づいて、クラウドファースト環境における特権アクセス管理のベストプラクティスについて解説する。

    PAMとは?

    まず、PAMの定義を明確にしたい。PAMというと、どうしても製品のイメージが強い。また、PAMの日本語訳である「特権アクセス管理」という言葉から考えられるのは、管理者が使用する特権アカウントをいかにセキュアにするか、つまり、特権を付与されているアイデンティティとアクセス管理を行う製品というイメージになる。しかしながら、WikipediaでPAMを検索すると、「Privileged access management(略称:PAM、別名:特権アクセス管理)は、組織内の特権アカウントの制御、監視、保護に焦点を当てたサイバーセキュリティ上重要なアイデンティティ管理である」としている。ここで「アイデンティティ管理」という部分については上記の特権アカウントの管理ということになるが、「組織内の特権アカウントの制御、監視、保護に焦点」を当てるという部分があり、単なる認証/認可だけではなく特権アクセスのセキュリティ統制を含んでいるといえる。そうすると、PAMを製品として捉えるのではなく、特権アクセスを付与・利用・監視・記録・不要になった場合の無効化を総合的に行うための統制モデルと考える必要がある。

    また、Gartnerは、PAMが必要な機能としてJust-In-Time(JIT)や Zero Standing Privileges(ZSP)という用語を使っており、特権というのは常設されるべきでなく、必要な瞬間に付与し必要無くなったら直ちに削除するということを要件としている。

    また、PAMと関連する用語としてIAM 、IGA、CIEMがあるが、これらとPAMとの違いは、IAM 、IGA、CIEMが「誰にどの権限を持たせるか」を管理するのに対して、PAMは「その権限をいつ、どのように使わせるか」を管理すると考える必要がある。 以上のことから考えて、PAMは、特権アクセスに対して、最小特権、時間制限、制御および監視を適用するセキュリティ統制であると考えるのが妥当である。その上で、PAM製品はその概念を技術的に実装する手段という位置づけになる。

    PAMの背景

    クラウドファースト時代における特権アクセス管理」において、特権アカウントは侵害において常に最も標的とされ最も深刻な被害をもたらす攻撃経路であると記述している。その理由として以下の点が挙げられている。

    • ガートナー社の調査によれば、インシデントの50%以上が、アイデンティティ、アクセス、特権の管理不備に起因している。
    • ベライゾン社のData Breach Investigations Report(DBIR)によると、データセキュリティインシデントの80%が、侵害または悪用されたクレデンシャル(特権・非特権を含む)に関連していることが統計で示されている。

    このように、特権アカウントあるいは特権を持っていることがデータ侵害に大きく影響していることがわかる。では、特権というものが厳密に管理されていればデータ侵害は起こらないのだろうか?理論的には以下の4つの前提がすべて満たされれば外部攻撃によるデータ侵害は極めて成立しにくいと言える(ここでは、外部からのデータ侵害に絞って考える)。

    • アカウント侵害ができない
    • 権限昇格が不可能である
    • 過剰権限が存在しない
    • 認可・設計・設定・運用が正しい

    しかしながら、現実のシステムではこの前提がほぼ崩れることになる。その理由は、設計・運用が「常に」維持できるものではなく、システム・人間・環境が「時間とともに変化する」からだということができる。変化により「正しかった設計」が「不正確」になってしまう。緊急対応での一時設定、トラブル回避の例外措置、手作業の微調整などにより、設定が意図せずドリフトする。業務優先のショートカット、「今回はいいだろう」という対応、引き継ぎ漏れ・理解不足などにより人間は必ず逸脱を引き起こしてしまう。また、使われていないアカウント、放置されたAPIキー、シャドーアカウントなどにより、存在を認識していないものは管理できないという可視性の問題も起こる。 このような設計・運用が「常に」維持できないという問題は、監査で確認することが求められているが、それをさらに確実にしていくには、自動化と継続的なモニタリングが必要であり、特権アカウントや特権アクセスが慎重に管理され、状況が認識されることが必要になる。これを支援するのがPAMの役割と考える。また、最小特権および時間制限という観点から、PAMは、ユーザーに業務に必要な最小限のアクセス権のみを、必要な期間のみ与えるための機能を提供することが必要になる。

    効果的なPAMによるコントロール

    PAMによるコントロールとして以下の点が必要となる。

    • 最小特権(Least Privilege)
      最小特権の原則をデフォルトで強制する。人/非人間の双方に、必要な権限のみを付与し、それ以上の権限は付与すべきではない。
    • 必要な期間のみ(Just In Time、JIT)
      特権は恒常的に付与せず、永続的な特権アカウントからジャストインタイム(JIT)や時間制限付きアクセスモードへ移行する。
    • ポリシー駆動(Policy-based Control)
      特権アクセスは事前定義されたポリシーに基づいて制御する。裁量ではなく、ポリシーに基づいて制御する。
    • 自動化(Automation)
      特権の付与・剥奪・管理プロセスは自動化する。未使用または期限切れのアカウントには自動失効機能を適用する。
    • 継続的モニタリング(Continuous Monitoring)
      特権アクセスの利用状況は継続的に監視・記録する。継続的にモニタリングし、新たに作成された特権アカウント、役割の変更、または予期せぬ特権の昇格を検出する。

    「特権は恒常的に付与しない」は可能か?

    ここでは、「クラウドファースト時代における特権アクセス管理」には記述されていないが、PAMによるコントロールを整理する中で気になった点として「特権は恒常的に付与しない」ということが可能なのかという点について考察してみる。
    特権を恒常的に付与しないことは、攻撃に可能な時間と影響範囲を最小化できるため重要である。恒常的な特権付与は、アカウント侵害時に即座に高権限を悪用されるリスクを内包するため、攻撃可能時間が無限になり、また特権取得を明確な監査イベントとして管理することができない。半面、特権を恒常的に付与せずJITとした場合、セキュリティが向上する代わりに、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時の障害対応において時間がかかってしまう(JITの承認者がすぐに対応できないなど)ことになる。

    PAM運用においては、特権付与の承認レベルに応じて以下のようなモデルが一般的に用いられる。

    • 事前承認JIT
      これは、特権の付与にあたって承認が必要となる。流れとしては、申請→承認→JIT付与→作業→自動失効となる。この場合、特権が必要な場合には常に事前承認が必要となるため、統制の観点では最強となる。したがって、高リスクの作業を必要とする場合に適している。ただし、緊急性が求められる場合には対応できないことが発生する可能性がある。
    • 無承認JIT(自己承認/ポリシー自動)
      これは、承認者が存在しない、別の言い方をすると自己承認JITというものである。流れとしては、本人要求→ポリシー判定→即JIT→作業→自動失効となる。この場合、承認者は存在しない。ガバナンスの観点では弱くなるが、ログが生成されるので監視・監査は可能である。したがって、これは低~中のリスクの作業に対して日常運用で用いることが考えられる。
    • 事後承認(先に付与、後でレビュー)
      これは、まず特権を付与し、使用した後でレビューする方式となる。流れとしては、JIT即時付与→作業→自動失効→後日レビュー(理由・操作内容)となる。承認なしで作業が行われるため、緊急対応や夜間対応の時に用いることが考えられる。

    これらの機能をうまく運用することで、セキュリティの向上、緊急時の障害対応などを「特権を恒常的に付与しない」形で実現できる。ただし、運用方針をしっかり定めておくことが重要となる。

    さて、上記の機能を使って「特権を恒常的に付与しない」運用をPAMを使って実現できるのであるが、常時特権を持ったアカウント(root等)は必要ないということにはならない。それは、非常事態として、PAMも認証基盤も壊れてしまった場合に最後に「必ず入れる道」を残す必要があるからである。いわゆる「Break-glass」である(注:Break-glassという考え方自体は「クラウドファースト時代における特権アクセス管理」に直接記載されているものではなく、実運用上一般的に用いられている設計パターンとして用いている)。認証基盤、PAM、管理プレーンなどが壊れた場合や緊急対応を必要とする重大インシデントへの対応などではどうしても「最後の管理者」が必要となる。そうすると、基本はPAMを使った「特権を恒常的に付与しない」運用を行い、緊急のためにBreak-glassで対応するという運用が必要となる。しかし、Break-glassを前提すべきではなく、あくまで基本はPAMを使った「特権を恒常的に付与しない」運用にすべきである。つまり、Break-glass は「存在させるが、通常は使わない」前提で設計する必要がある。

    もう一つ、特権というか権限を常時付与することが求められることとして、部門/業務等で日常的に必要な権限の付与がある。これには、業務で必要となる権限、機械的に付与される権限などがあり、「必要な時だけ権限を付与」ということがそもそも成り立たない。しかしながら、この部門/業務等で常時付与される権限は、侵害の起点となることが多く、権限昇格やラテラルムーブメントを引き起こすことにもなりうる。これを考えると、PAMは「全体の権限を統合管理する基盤」ではなく、あくまで管理者権限、IAMの高権限ロールを対象にしていて、情報システムそのものを破壊できるような高権限を管理することを目的とし、部門/業務等で日常的に必要な権限はIAM/IGAの範囲と考えるのが妥当である。まとめると、PAMは「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる。

    クラウドファースト環境における特権アクセス管理のベストプラクティス10選

    クラウドファースト時代における特権アクセス管理」では、クラウド環境における特権アクセス管理のベストプラクティスとして以下の10項目を挙げている。ここでは、その概要を説明する。

    1. ジャストインタイムアクセス(JIT)およびジャストイナフアクセス(JEA)を活用し、常時付与された特権を排除する
      • 永続的な管理者権限を廃止し、「必要な作業に必要な期間だけ最小権限」を動的に付与してアタックサーフェスを削減する。
      • 攻撃者は「常時存在する管理者権限」を狙うことが多いため、これを排除することで侵害リスクが大きく減少する。
    2. 自動化による特権アクセスの検出とインベントリ
      • シャドーアカウントを含むすべての特権アカウントを自動発見・棚卸しし、見えない特権(シャドー特権)を可視化し排除する。
      • クラウドでは「誰も把握していない管理権限」が必ず増えるため、これを可視化し排除することが重要である。
    3. きめ細かなアクセス制御と役割分担の導入
      • RBAC/PBACにより職務の分離と最小特権を徹底し、単一アカウントへの過剰集中を防止する。
      • 「管理者」という大雑把な権限をやめ、職務単位で分解し権限付与する。これにより、1アカウントを侵害することで全ての権限を持ってしまうという構造を壊すことができる。
    4. 権限付与、使用状況、および特権アクセス管理の行動パターンを分析する
      • 特権の使われ方を継続的に分析し、異常行動・過剰権限・リスク傾向を早期検知する。
      • 単にログを取るだけでなく、普段と違う操作、異常な時間帯、権限の使われ方の変化などを行動として分析する。クラウドでは、特に正規アカウントを使った侵害が起こるため、正規アカウントによる異常操作を見つける必要がある。
    5. 包括的な特権セッションのモニタリングおよび監査の有効化
      • すべての特権操作を記録・可視化し、フォレンジック・説明責任・規制対応を可能にする。
      • インシデント後に、誰が何をしたかを説明できるようにし、統制や復旧をスムーズに行えるようにする。
    6. すべての重要な資産とアイデンティティにPAMを拡張する
      • サーバーだけでなく、SaaS、業務アプリ、クラウド管理プレーンまでPAM対象に含める。
      • PAMの対象をSaaS管理プレーン、業務アプリ、クラウド管理APIまで広げることで、SaaSや業務アプリ側の侵害を防ぐ。
    7. 非人間アイデンティティとワークロードアクセスをセキュアにする
      • サービスアカウント、API、ボット、AIエージェントにもJIT・最小特権・監査を適用する。
      • 人ではなく、サービスアカウントやAIエージェントにも適用することでセキュアにする。
    8. セキュアなリモートおよびサードパーティアクセス
      • ベンダーや外部委託先のアクセスも一時的・監査可能を前提として制御する。
      • ベンダーや委託先に対しても、永続IDを渡さず時間限定や操作記録付きでアクセスさせるようにすることでセキュアにする。
    9. PAMをDevOps、CI/CDのInfrastructure-as-Code(IaC)ワークフローに統合する
      • PAMをDevOps、CI/CDのInfrastructure-as-Code(IaC)ワークフローに統合し、コード経由の特権漏洩や設定ミスを防止する。
      • CI/CD、Terraform などの中の特権もPAM管理下に置くことで、コード内シークレットの問題を解決する。
    10. 強固なガバナンスとコンプライアンスの確立
      • PAMログと統制をSOX/PCI DSS/NIST等の証跡として活用し、監査対応を自動化する。
      • PAMログを、そのまま監査証跡、規制対応、経営報告に使えるようにする。これにより、PAMを経営統制のインフラとする。

    まとめ

    本ブログでは、PAMの定義、PAMの守備範囲について説明した。また、現代のデータ侵害の起点となる特権の扱いとして、「「特権は恒常的に付与しない」は可能か」という点について、PAMの機能を中心に考察した。さらに、クラウドファースト環境における特権アクセス管理のベストプラクティスについてその概要を説明した。

    PAMは今後、必須の機能となるが、「全体の権限を統合管理する基盤」ではなく「特権の専門管理ツール」であり、業務権限を含めた統合的アクセス管理はIAM/IGAの領域となる点は理解しておく必要がある。

    以上

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

    第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セキュリティリーグでは、ここで述べられている7つのセキュリティリスクについて、実際に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に対する連携の依頼が多くなっていることである。組織全体にアクセスできる権利を要求されることがあり、他の部門のデータも見られてしまう可能性があり注意が必要である。
      以前(第1回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のカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

    以上

    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の6つのカテゴリーの内容
      SSCFでは、以下の6つのカテゴリーについて、SaaS利用者が管理/設定しなければならないことを「実行できるようにする」ための機能を記述している。
      • CCC(変更管理と構成管理)
        • 定義されている内容
          SaaSのセキュリティ設定が「どのように構成」され、「どのように把握」され、「どのように変更」されるかを、SaaS利用者が管理できる能力を定義している。
        • 管理策のポイント
          SaaS利用者が設定/管理する以下の4つのポイントを記述している。
          • 現状のセキュリティ設定をプログラムで問い合わせることができること
          • 現在の設定状態を可視化できること
          • 設定変更が発生した事実を知ることができること
          • 設定内容を文書化することができること

            なお、ここで言う設定には、認証、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 CCMSSRMの考え方

    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セキュリティ能力フレームワーク(SSCF)の有効性

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

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

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

    テーマ:SaaSセキュリティの設定問題と、SaaSセキュリティ能力フレームワーク(SSCF)の有効性

    ディスカッション内容

    1. SaaS利用者が実際に手を動かさなければならないこと(アイデンティティとアクセス管理、インシデント対応、ログ管理、データ保護等)の現状。どこまでできている/できていない点、課題。
      • 全社的に設定管理するものに関してはIT部門が管理している。SaaSが提供しているセキュリティ機能についても確認できていて、それに基づいて管理している。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。また、小さいSaaSについては統一的な管理ができていない。
      • 最初に、SaaS側のセキュリティ機能(ログを取っているか、ID/アクセス管理など)の確認を行っている。それに基づいて、設定管理を行っている。
      • 利用の申請、また、どのように使っているか、SaaSサービスがどうなっているかを確認している。その上で、実装をどうするかを決めていく。利用者側の設定はバリエーションが出てしまう。難しいガイドラインを作っても部門が対応できない(知識がない)ケースもある。
      • SaaSはロングテールになる傾向がある。O365のような主要なSaaSは情シスが面倒を見ている。それに対して、ロングテールとなる小さいところは、仕様変更に対して追従できているかも不明なところがある。また、SaaSそのものがそもそもセキュリティ機能を満たしていないところも多い。したがって、SaaSのセキュリティ管理を一律に制限することはできない。
      • リスクの大きくないサービスに対してはあまり関わらないし、関わる時間もない。CASBの評価で一定の基準を満たしていれば設定はあまり気にしていない。

        まとめると、SaaS側が提供するセキュリティ機能のバリエーションの問題、部門のセキュリティ管理者へのSaaSセキュリティの徹底はなかなか難しい問題であることが分かる。

    2. SaaSプロバイダはどこまで支援してくれているか。あるいは、機能提供しているか?
      • SaaS利用前に、SaaSプロバイダにチェックリストに回答してもらう。セキュリティチェックシートを満たさないと契約できないようにしている。Webフィルタリング機能で、契約していないSaaSは使えないようにしている。
      • チェックシートに回答がもらえないSaaSがある。また、チェックシートだけでは管理しきれないSaaSもある。

        SaaSプロバイダが提供しているセキュリティ機能がなかなか把握できず、SaaS利用者にはチェックリスト等による対応が求められているのが分かる。

    3. 利用しているSaaSはセキュリティ機能を持っているが、利用者側で正しく設定できていないケースはあるのか?
      • SaaS利用担当者に、以下の項目を実施することを指示。これにより、設定問題をできるだけ回避するようにしている。
        • ユーザーアカウントの登録、変更、削除、パスワード初期化
        • 利用マニュアルの整備、利用方法の指導、利用者に対するヘルプデスク
        • クラウドサービスに設定するデータの定期的なバックアップ
        • インシデント発生時の連絡調整、迂回処理等の検討・実施
        • クラウドサービスでの処理量の増減に応じたサービス利用量の調整
      • 利用者側の設定については、基本的には、監査とかで対応している。
      • 当初は正しい設定をしていても、今までの設定では不十分になるケースがある。
      • 他社で事故が発生した場合に、自社の設定問題が表面化するケースもある。

        上記1,2の状況を受けて、SaaS利用者側のセキュリティ設定を徹底する方法として、定期的な監査で設定問題を回避するというのが、現状取られている方法と考えられる。

    4. SSCFの有効性について

      ここで、CSAが最近公開した「SaaSセキュリティ能力フレームワーク(SSCF)」について、実際にSaaSセキュリティを担当している管理者の意見を出していただいた。
      まず、SSCFであるが、SaaSプロバイダが利用者に提供するセキュリティ機能をまとめた管理策集である。すべてのSaaSプラットフォームで利用可能な標準化されたセキュリティ機能を確立することを目的としている。
      • SSCFの資料
        SSCFの解説として提供されている情報(日本語)を以下に示す。本ブログでは、SSCFの詳細は記述しないので、これらの資料を参照していただきたい。
      • SSCFで提供されている管理策の有効性についての意見
        • SaaSプロバイダが、SSCFに基づいて実装してくれると助かる。たとえば、SSOしてくれるだけでもうれしいし、ログがAPIで提供されるだけでも助かる。
        • SSCFにより、共通言語化されるだけでも良い。どの機能が揃っているというのが分かるし、同じ土俵で会話できるのはありがたい。
        • ベンダー向けのチェックリストの中で、聞かなくても良い項目が出てくるので楽になる可能性がある。
        • 自動化対応とかは日本のSaaSベンダーはあまりできていない。フレームワークとしてできるようになれば良い。SIEM連携とか、メリットがある。
        • SSCFを、どのように強制できるかが課題である。SSCFの名前がインパクトがない。もっとSaaSでは絶対必要だというような名前にすべきである。「能力フレームワーク」というのが分かりにくい。SSCFをもっと知らしめてほしい。

          総じてSSCFについて好意的な意見をいただいた。今まで、SSCFのようなまとまった形でSaaSセキュリティ機能を記述している資料がなかったため、これがSaaSセキュリティのバリエーションを生んでおり、設定および設定管理の難しさをもたらしていた。SaaSセキュリティ機能をプロバイダと利用者で標準化できれば、双方にとって有効であることが分かった。

    5. その他
      今回の議論の内容ではなかったが、他社が使っているSaaSを利用する場合、直接そのSaaSの管理ができない(たとえば、他社がBOXを使っていて、そのBOXを共有するケース)という問題が提起された。これは、SaaSに対してチェックリストを出すことができない。このような場合に、セキュリティ対応はどうしたらよいのかが課題となる。

    6. まとめ
      • SaaS利用者設定の課題について、全社的に設定管理するものに関してはIT部門が管理できている。一方、個別部門が設定管理を行っているものについては、SaaSのバリエーションの問題がありあまり管理できていない。
      • 利用者側の設定の状況については、基本的に、監査で対応している。
      • SaaSプロバイダが提供しているセキュリティ機能については、セキュリティチェックリストを送付し、SaaS利用前に回答してもらう方法が取られている。また、セキュリティチェックシートを満たさないと契約できないようにしている。ただし、チェックシートに回答がもらえないSaaSもあり、課題はある。
      • SSCFにより、SaaSのセキュリティ機能の標準化ができるようになると非常に有効である。しかしながら、どのように強制できるかが今後の課題となる。

    以上

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

    第一回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 Security Capability Framework(SSCF)v1.0のご紹介:SaaSセキュリティのレベルを向上させる

    本ブログは、CSA本部が公開している「Introducing the SaaS Security Capability Framework (SSCF) v1.0: Raising the Bar for SaaS Security」の日本語訳です。なお、本ブログと原書の内容に差異があった場合には、原書の内容が優先されます。

    SaaS Security Capability FrameworkSSCFv1.0のご紹介:
    SaaS
    セキュリティのレベルを向上させるフォームの始まり

    CSA EMEA, AVP of GRC Solutions、Eleftherios Skoutaris

    SaaSセキュリティの再考が必要な理由

    SaaSはすべてを変えた。コラボレーションツールから重要なビジネスアプリケーションまで、SaaSは今や組織がテクノロジーを利用するデフォルトの方法となっている。しかし、この大規模な変化には大きな問題が伴う:セキュリティが追いついていないのだ

    多くのサードパーティリスク管理(TPRM)プログラムは、サプライヤーの組織全体のセキュリティ(SOC 2レポートやISO認証など)に焦点を当てている。しかし、各SaaSアプリケーション内部の実際のセキュリティ機能は評価されておらず、企業がそれらの機能を活用するための指針も提供されていない。その結果、企業は書類上はコンプライアンスを満たしているように見える数百のアプリケーションを導入しながら、実際にはセキュリティ上のギャップを残したままになっている。

    JPMorgan Chaseがサプライヤーに送った最近の公開書簡は、まさにこの問題を浮き彫りにした。同社は一貫性のないSaaSセキュリティコントロールを指摘し、業界の改善を強く求めた。明確な基準がなければ、企業、SaaSベンダー、セキュリティチームはそれぞれ独自にギャップを埋めようとし、重複した労力と不要なリスクを抱え続けることになる。

    SSCF v1.0の登場

    そこで登場したのが SaaS Security Capability Framework(SSCF)v1.0である。

    このプロジェクトは、MongoDBとGuidePoint Securityのセキュリティリーダーが主導し、自ら開発作業を率いた。彼らと共に、Cloud Security Alliance(CSAが共同して主導し、その強みである業界関係者の結集、Cloud Controls Matrix(CCM v4といった標準構築の豊富な経験、構造化された研究ライフサイクルを通じた作業の指導を行った。CSAはSaaSプロバイダ、SaaS利用者、監査人、コンサルティング企業すべてが意見を反映できるようにし、フレームワークが現実のニーズを反映するものとした

    その結果? SaaSベンダーがすぐに採用できる、利用者向けのセキュリティ機能フレームワークが実現した。これにより、SaaS利用者とベンダー双方におけるセキュリティレビューと実践の一貫性が確保され、潜在的なセキュリティリスクの低減に貢献する。

    「SSCF v1.0は、SaaSセキュリティにおける長年の課題である一貫性のある実行可能な管理策の欠如に対処する。ベンダーと利用者の双方が実装可能な実用的な解決策に焦点を当てることで、このフレームワークは高レベルのコンプライアンスと現実のセキュリティニーズの間のギャップを埋める。GuidePoint Securityでは、Cloud Security Allianceや業界の仲間と協力し、関係者全員にとってSaaSセキュリティを簡素化するものを創り上げたことを誇りに思う」と、GuidePoint SecurityのSenior Cloud Practice Director、Jonathan Villaは述べている。

    MongoDBのSenior Director, Security Engineering、Boris Sieklikは次のように付け加えている。「SSCFは、私たちのようなSaaS利用者がまさに求めていたものを提供する。明確で標準化された設定可能な管理策によって、SaaSアプリケーションの評価、採用、安全な運用が容易になる」。

    SSCFが目指すのは以下の通りである:

    • TPRMチーム向け:ベンダーリスク評価をより迅速かつ簡素化する一貫した基準を提供。
    • SaaSベンダー向け:回答を単一かつ広く認知された標準に統一することで、繰り返される質問票や評価方法の差異による負担を軽減。
    • SaaSセキュリティエンジニア向け:SaaS導入と日常的なセキュリティ運用を強化するための実践的なチェックリストを提供。

    v1.0の内容

    SSCF v1.0は、CSAのCCM v4から採用した6つの主要セキュリティドメインにわたる管理策を定めている:

    • 変更管理と構成管理(CCC
    • データセキュリティとプライバシーライフサイクル管理(DSP
    • アイデンティティとアクセス管理(IAM
    • 相互運用性と移植容易性(IPY
    • ログ記録と監視(LOG
    • セキュリティインシデント管理、E-ディスカバリ、クラウドフォレンジック(SEF

    これらのドメインは、SOC 2 や ISO 27001 などのフレームワークに取って代わるものではなく、それらの高レベルの要件を、利用者が実際に設定し、信頼できる具体的な SaaS セキュリティ機能に変換するものである。ログ配信、SSO実施、安全な設定ガイドライン、インシデント通知など、利用者が SaaS を日常的にセキュアに運用するために本当に必要なすべてのものを考えてみてください。

    なぜこれが重要なのか

    SSCFの核心は摩擦を減らすことにある。企業はSaaSポートフォリオ全体でより一貫したセキュリティ機能を得られ、多様性に富むSaaS環境全体で統一された実装基準を構築できる。ベンダーは求められるセキュリティ管理策を知り得る。そして、個別評価から共通基準への移行により、すべての関係者が時間を節約できる。

    最も重要なのは、信頼の構築である。SaaSがミッションクリティカルな存在となった現代において、この信頼こそがセキュアな導入とリスクの高い盲点の分かれ目となる。

    Valence SecurityのCo-Founder兼CTO、Shlomi Matichinは次のように述べている。「SSCFが広く採用される世界では、組織はセキュリティ運用コストを負担することなく、大規模かつセキュアにSaaSを利用できるようになる。SaaS導入とデータ移動を加速させる自律型AIの急速な普及に伴い、SSCFの重要性はさらに増大する」。

    今後の展望

    SSCF v1.0は始まりに過ぎない。プロジェクトの次フェーズは既に進行中で、フレームワークをさらに実践可能なものへと進化させることに焦点を当てている:

    • 組織が管理策を実践に移すための実装ガイドライン、および監査人がこれらの管理策を効果的に評価する方法の監査ガイドラインの確立。
    • それらの管理策が実際にどれほど効果的かを測定する評価および認証スキーム

    これらを組み合わせることで、SaaSプロバイダと利用者はチェックリストを超え、真に測定可能なセキュリティ改善を実現できる。


    CSAは、MongoDBGuidePoint SecurityGrip SecurityObsidian SecurityValence SecurityGitLabSiemensKaufman RossinAppOmniBand of Codersなど、多数の主要貢献者からなる広範なコミュニティと連携し、SSCF v1.0を実現できたことを誇りに思う。この最初のバージョンはより一貫性があり、よりセキュアで、より信頼できるSaaSエコシステムの基盤を築く。そして、この取り組みはここで終わりではない。最高の成果はまだこれからである。

    以上

    CCSKv5 合格体験記

    【CCSKv5 合格体験記】

    ~体系的なクラウドセキュリティ理解の第一歩として~

    クラウドセキュリティに関する知識と理解を深め、実務に活かせるスキルを証明する資格として注目されているのが、CSA(Cloud Security Alliance)が提供するCCSK(Certificate of Cloud Security Knowledge)です。その最新版である「CCSK v5」は、広範なクラウドセキュリティの知識体系を網羅しており、学習から試験対策、実務への応用まで、多くの気づきと発見を与えてくれる内容となっています。

    今回は、実際にこのCCSK v5に挑戦し、無事に合格を果たした筆者が、自身の学習プロセスや試験体験、そして今後への活用について、個人的な視点からまとめてみました。これから受験を考えている方や、クラウドセキュリティの学習を始めようとしている方にとって、少しでも参考になれば幸いです。

    1. 試験に向けてどのように勉強したか

    CCSKv5の受験に向けて、まず取り組んだのはCSAの公式資料であるCCSK v5 Prep Kitと、Certificate of Cloud Security Knowledge v5 Exam Bundleに含まれるオンラインコースの受講でした。このコースには「CCSK orb」という専用のGPTが付属しており、自然言語での質問に答えてくれるサポート機能があります。日本語にも対応しているため、理解を深める上で非常に役立ちました。

    加えて、CSA JAPANが提供している日本語の資料もフル活用しました。特にSecurity Guidanceの日本語訳は、理解の補完に非常に有効であり欠かせないものでした。また、CCSK v5 Prep Kitに含まれるSecurity GuidanceとPractice ExamをChatGPTにアップロードし、セクションごとの復習問題を生成しながら学習を進めました。この方法を用いると、Practice Exam の出題方法をモデルにし、Security Guidance の内容から問題を作成してくれます。ただし、問題のレベルとは若干差異が見られました。

    学習期間は約半年かかりました。2024年11月から学習を開始し、最初の2か月はオンラインコース中心に学びましたが、理解が浅く合格できる基準にないと感じたため、その後は日本語資料での読み込みを中心にじっくり進めていきました。

    効果的だったのは、まず12のドメインの枠組みを頭に入れ、全体像を意識しながら学ぶことです。ドメイン間の関係性(ビジネス・技術・運用の観点)を把握することで、理解が格段に深まりました。また、Practice Examにトライすることで出題傾向やレベル感が見えてくるため、非常に有効でした。

    試験範囲が広いため、丸暗記は現実的ではありません。要点を押さえる形での繰り返し学習と、アウトプット型のトレーニング(問題演習)が重要だと感じました。

    2. CCSKv5の試験概要・特徴

    試験は60問の選択式で、全問において4つの選択肢から1つを選ぶ形式です。合格基準が80%の正答になるため、49問以上の正答で合格になります。実試験はPractice Examに非常に近い形式で出題されました。選択肢のうち、明らかに誤っているものが2つ程度含まれていることも多く、実質的には二択問題として解けるケースも多かったです。

    試験時間は120分と十分ありますが、すべてのドキュメント参照が許されるとはいえ、最初から頼ると時間が足りなくなる可能性があります。私は最初の30分で一通り回答し、残りの90分を確認フェーズとして必要な部分をガイドで確認するスタイルを取りました。

    英語については、そこまで難解ではないものの、ある程度読み慣れていないと苦戦する可能性があります。私は念のため、日本語版ガイドと英語版を並べて参照しながら確認しました。

    受験は完全オンライン(BYOD)で、自宅やカフェなどでも受験可能です。ただし、一度開始すると通信トラブルがあっても時計は止まらないため、受験環境(特にネットワーク)の安定性には十分注意が必要です。

    3. 傾向と対策(個人的な体験談としての傾向と対策)

    出題傾向について、問題を持ち帰ることができないため断定はできませんが、全ドメインからバランス良く出題されている印象でした。特定の技術や知識というよりも、CSAが提示するガイドラインやフレームワークの「本質」に相当するような箇所にフォーカスした出題が多かったと感じています。

    個人的に難しいと感じたのは、ドメイン2~4のガバナンス領域でした。私は技術職のため、こうしたビジネス寄りのトピックには慣れておらず、理解に時間がかかりました。

    逆に、技術職の方にとって重要だと感じたポイントは以下の通りです:

    • クラウド環境における責任共有モデルの理解
    • IaaS / PaaS / SaaSの各モデルにおけるセキュリティの考え方
    • クラウド特有の運用(アプリケーション、サーバレス、開発プロセス)
    • IAM(アイデンティティ&アクセス管理)を中心とした認証・認可の設計

    特にIAMを含むドメイン5の内容は、他の領域とも深く関係しており、重点的に学習することをおすすめします。

    4. 今後の抱負・自由記述

    CCSK受験のきっかけは、オーストラリア人の上司からの勧めでした。私たちの会社では主にネットワークスイッチ製品を取り扱っていますが、我々の顧客の多くはクラウドシフトしている中でもなおオンプレミス思考から脱却できずにいます。クラウドを導入する上で、セキュリティの観点から正しくアドバイスできる人材が求められており、その期待に応えるべく、受験を決めました。

    私自身、これまでにAWS, Microsoft Azure, Google Cloud をはじめとした複数のクラウドベンダーのアーキテクト資格を取得してきましたが、クラウドサービス自体は異なるものの、認定試験で問われる内容は比較的内容が似通っているものの、各ベンダの独自色を出すがゆえに包括的なセキュリティ視点を養うには至りませんでした。CCSKはその空白を埋める資格として、非常に有効でした。

    今後はこの資格で得た知識を活かし、クラウドセキュリティの重要性をお客様に伝え、マインドチェンジを促していきたいと考えています。バージョンを“塩漬け”にしたまま変更による影響を考慮して運用するのではなく、変化を前向きに捉えるクラウド時代のセキュリティ思考へと導ける「トラステッド・アドバイザー」になることを目指しています。

    最後に、これから受験を考えている方へ。
    クラウドサービスの普及から10年以上が経ち、各クラウドベンダーが認定資格を提供していますが、それらはどうしてもベンダー依存の視点に偏りがちです。CCSKは、ベンダーに依存しない「クラウドセキュリティの標準」を学ぶ貴重な機会になります。クラウドを本質的に理解したい方にこそ、お勧めしたい資格です。

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

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

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

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

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

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

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

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

    • 【複数企業で発生した事例】(2022年)
      複数の企業が、タスク管理ツール(Trello)の設定を誤って利用し、社内情報や個人情報が外部に公開され、検索可能となっていたことが判明。内閣サイバーセキュリティセンター(NISC)からも注意喚起が行われるほど、話題となりました。
    • 【某自動車会社様の事例】(2023年)
      ソフトウェア開発用のプラットフォーム(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への対応はまだ十分ではありません。SSPMの利用を検討されている日本のお客様からも国産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利用実態調査レポート」

    以上

    ゼロトラストの2つの成熟度モデルを理解する

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

    以上