SaaS 環境におけるPAM利用について

コメントをどうぞ

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

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

問題点の概要

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

  1. ガートナー社の調査：インシデントの50％以上が、アイデンティティ、アクセス、特権の管理不備に起因
  2. ベライゾン社のData Breach Investigations Report（DBIR）：データセキュリティインシデントの80％が、侵害または悪用されたクレデンシャル（特権・非特権を含む）に関連している

      現代のPAMの中核となる原則は最小特権であり、ユーザーは業務に必要な最小限のアクセス権のみを、必要な期間のみ保持すべきであるということで、ジャストインタイム（JIT）およびジャストイナフアクセス（JEA）モデルへの移行が求められている。また、特権アカウントや特権アクセスを慎重に管理するために監査で確認することが求められているが、それをさらに確実にしていくには自動化と継続的なモニタリングが必要であり、PAMはこれを支援することができる。

      このような状況を受けて、今回のSaaSセキュリティリーグでは、PAMの利用状況の現状、問題点、考慮事項等についてディスカッションした。

        ディスカッション内容

        1. PAMの利用状況
          現在は、PAMの利用を始めたという状況で、徐々に利用範囲を広げている状況である。したがって、対象範囲を絞って重要なシステムのサーバーにおける特権管理としてサーバーOS上のユーザーをまず対象として開始している。
          PAMの利用方法としては、アカウント管理とログ・監視をメインにして利用している。利用方法の検討もまだ始まったばかりであり、今後の方向性について議論している状況である。SaaSへの利用についてはまだこれからである。また、監督官庁からPAMの利用を推奨されていたり、PCIDSSでPAM的なものを入れる要件があるため導入しているが、PAMの有効性についてはまだあまり感じていない。
          このような状況の中ではあるが、PAMの機能としての特権の承認プロセスやログ管理機能に対する要求があり、この観点での利用が広がっていく可能性がある。
          なお、JITはあまりやられていない状況である。

        2. 管理者にとって JITは現実的か？
          JITは、特権を恒常的に付与しないことで攻撃に可能な時間と影響範囲を最小化できる一方、可用性、運用効率、ユーザーエクスペリエンスの問題が発生する。特に、緊急時対応時の対応が遅れる可能性があると考えられる。このような背景を受けて、JITがどのように利用できるかであるが、一般的な管理・運用としては有効と思われるが、運用上できるのかどうかの検討が必要と思われるということであった。また、システムの管理は特権アカウントを使って行うという既存の運用方法があり、JIT運用そのものが社内でも抵抗が強いことが分かった。
          SaaSでの利用の観点で行くと、SaaS自体がJIT機能を持っていない状況では難しいということである。なお、IaaS/PaaSでは、JITの仕組みを使っているケースが多いので利用可能である。

        3. NHI（サービスアカウント等）をどう扱うべきか？
          NHIの利用としてSaaS間の連携は結構行われており、この部分において連携方法等を検討しているとのことである。agenticAIについては、まだ社内で使われている状況ではないので、NHI等の連携の問題はまだ明確ではない。
          NHIのアイデンティティとアクセス管理は、台帳を用いた手動による管理を行っており、連携においてどのくらいの権限を与えるかについて検討が必要である。AIに関しては、付与する権限は情報収集的な読み取り権限のみとかシステムに影響を与えない権限のみを与えることで管理している。

        まとめ

        現状、PAMの本格導入を行っているケースは少ないものと思われる。
        攻撃に可能な時間と影響範囲を最小化できる特徴を持ったJITについては、まだ検討段階が多いようである。常時特権を持つアカウントによる管理に慣れている状況もあり、文化の変更も伴う。導入に向けては、ユースケースが広がることが必要であると思われる。
        AIにどこまで権限を持たせるかはすでに問題になってきている。AIの利活用とデータ保護の問題は、今後大きな問題になってくると思われる。合わせて、NHIによるアプリ連携の課題やagenticAIへの対応も今後取り組んでいかなければならない課題である。

        参考資料

        以上

        開発者向けクラウドネイティブセキュリティの基礎（アプリケーションセキュリティ編）(1)

        コメントをどうぞ

        CSAジャパン関西支部では、「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(1)」（https://cloudsecurityalliance.jp/newblog/2025/07/14/smb_aisec_1/）および「海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(2)」（https://cloudsecurityalliance.jp/newblog/2025/09/16/smb_aisec_2/）で、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発された人工知能（AI）セキュリティ固有のガイドを紹介したが、今回は、エージェンティックAIのガバナンスについて取り上げる。

        シンガポール政府が世界初のエージェンティックAIガバナンス文書を発行

        2026年1月19日、シンガポール情報通信メディア開発庁（IMDA）は、「エージェンティックAI向けモデルAIガバナンスフレームワーク」（https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf）を公開している。現時点で、エージェンティックAIに特化した包括的なガバナンス文書を発行したケースとしては、本書が世界初となる。

        本文書は、エージェンティックAIの導入に伴う新たなリスクに対して、組織が信頼性と安全性を確保しながら活用できるように支援することを目的としており、以下のような構成になっている。

        エグゼクティブ・サマリー

        1. エージェンティックAIの紹介
          1.1 エージェンティックAIとは？
           1.1.1 エージェントの中核構成要素
           1.1.2 マルチエージェント構成
           1.1.3 エージェント設計がその限界と能力に与える影響
          1.2 エージェンティックAIのリスク
           1.2.1 リスクの発生源
           1.2.2 リスクの種類
        2. エージェンティックAI向けモデルAIガバナンスフレームワーク
          2.1 リスクを事前に評価し、制限する
           2.1.1 エージェント導入に適したユースケースの特定
           2.1.2 エージェントの限界と権限を定義することで設計段階からリスクを制限
          2.2 人間の意味ある責任を確保する
           2.2.1 組織内外における責任の明確な割り当て
           2.2.2 意味ある人間による監督を設計に組み込む
          2.3 技術的な制御とプロセスを実装する
           2.3.1 設計・開発段階における技術的制御の活用
           2.3.2 導入前のエージェントのテスト
           2.3.3 導入時の継続的な監視とテスト
          2.4 エンドユーザーの責任を可能にする
           2.4.1 ユーザーの多様性とニーズの違い
           2.4.2 エージェントと直接やり取りするユーザー
           2.4.3 エージェントを業務プロセスに統合するユーザー
          附表A：参考資料 .
          附表B：フィードバックと事例の募集

        エージェンティックAIを構成する6つのコアコンポーネント

        本フレームワークにおいて、エージェンティックAIシステムとは、AIエージェントを用いて、特定の目的を達成するために複数のステップにわたる計画を立てて実行できるシステムを指す。一般的に、エージェントは、ユーザーが定めた目標を達成するために、ある程度自律的に計画を立て、行動を実行する能力（例：ウェブ検索やファイルの作成など）を備えていることが多い。

        エージェントは言語モデルの上に構築されており、以下のような6つの中核的要素により構成される。

        1. モデル（Model）：
          • SLM（小規模言語モデル）、LLM（大規模言語モデル）、またはMLLM（マルチモーダル大規模言語モデル）で構成され、エージェントの中核となる推論・計画エンジンとして機能する。指示を処理し、ユーザーの入力を解釈し、文脈に応じた応答を生成する。
        2. 指示（Instructions）：
          • エージェントの役割、能力、行動上の制約を定義する自然言語によるコマンド。たとえば、LLMに与えるシステムプロンプトなどが該当する。
        3. 3メモリ（Memory）：
          • LLMがアクセス可能な情報で、短期記憶または長期記憶として保存されるデータ。過去のユーザーとのやり取りや外部知識ソースからの情報を取得できるようにするために追加されることがある。
        4. 計画と推論（Planning and Reasoning）：
          • モデルは通常、推論と計画を行うように訓練されており、タスクを達成するために必要な一連のステップを出力できる。
        5. ツール（Tools）：
          • エージェントがファイルやデータベースへの書き込み、デバイスの制御、取引の実行など、他のシステムとやり取りしながら行動を実行するための手段です。モデルはタスクを完了するためにツールを呼び出す。
        6. プロトコル（Protocols）：
          • エージェントがツールや他のエージェントと通信するための標準化された方法。たとえば、Model Context Protocol（MCP）はエージェントがツールと通信するためのプロトコルであり、Agent2Agent Protocol（A2A）はエージェント同士が通信するための標準を定義している。

        エージェンティック AI向けモデルAIガバナンス・フレームワーク（MGF）は、エージェント型AIに関するリスクと、それらのリスクを管理するための新たなベストプラクティスを、組織が体系的に把握できるようにするための枠組みである。リスクが適切に管理されれば、組織はより安心してエージェンティックAIを導入することができるとしている。

        エージェンティックAI実装に際して考慮すべき4つの領域

        このMGFは、自社でAIエージェントを開発する場合でも、外部のエージェントソリューションを利用する場合でも、エージェンティックAIの導入を検討している組織を対象としている。これまでのモデルガバナンス・フレームワークを基盤として、エージェントに関して組織が考慮すべき4つの主要な領域を以下のように整理している。

        1. リスクを事前に評価し、制限する
          ・組織は、エージェントによって新たに生じるリスクを考慮し、内部の構造やプロセスを適応させる必要がある。その第一歩は、エージェントの行動によってもたらされるリスクを理解することであり、エージェントが取り得る行動の範囲、行動の可逆性、エージェントの自律性の度合いなどが関係する。
          ・リスクを早期に管理するために、組織は計画段階でエージェントの影響範囲を制限する設計（例：ツールや外部システムへのアクセス制限）を行うことが推奨される。また、エージェントの行動が追跡可能かつ制御可能であるように、堅牢なID管理やアクセス制御を導入することも重要である。
        2. 人間の意味ある責任を確保する
          ・エージェンティックAIの導入に「ゴーサイン」が出た後は、人間の責任を確保するための措置を講じる必要がある。ただし、エージェントの自律性が高まることにより、従来の静的なワークフローに基づく責任の割り当てが複雑化する可能性がある。さらに、エージェントのライフサイクルには複数のステークホルダーが関与するため、責任の所在が分散するリスクもある。
          ・組織内外の関係者の責任範囲を明確に定義し、技術の進化に応じて迅速に対応できるよう、適応的なガバナンス体制を整備することが重要である。特に、ヒューマン・イン・ザ・ループ（HITL：Human-in-the-Loop）の設計は、自動化バイアスへの対処を含めて再考する必要がある。たとえば、重大な判断や不可逆な行動には人間の承認を必須とするチェックポイントを設けることや、人間による監督が時間とともに有効に機能しているかを定期的に監査することが求められる。
        3. 技術的な制御とプロセスを実装する
          ・エージェントを安全かつ信頼性の高い形で運用するために、ライフサイクル全体にわたって技術的な対策を講じる必要がある。
          ・開発段階では、計画機能、ツール、成熟途上のプロトコルなど、エージェンティック AI特有の新しい構成要素に対して、技術的制御を組み込むことが重要である。これにより、新たな攻撃対象領域から生じるリスクに対応できる。
          ・導入前には、エージェントの基本的な安全性と信頼性（実行精度、ポリシー遵守、ツール使用の適切性など）を検証する必要がある。これには、従来とは異なる新しいテスト手法が求められる。
          ・導入時および導入後には、エージェントが環境と動的に相互作用するため、すべてのリスクを事前に予測することは困難である。そのため、段階的な導入と継続的なモニタリングが推奨される。
        4. エンドユーザーの責任を可能にする
          ・エージェントの信頼性ある導入は、開発者だけでなく、それを使用するエンドユーザーの責任ある利用にも依存する。
          ・責任ある利用を促すために、最低限として、ユーザーにはエージェントの行動範囲、アクセス可能なデータ、ユーザー自身の責任について明確に伝える必要がある。
          ・組織は、人間とエージェントの相互作用を適切に管理し、効果的な監督を行うための知識を従業員に提供するトレーニングを実施することも検討すべきである。これは、従業員が自身の専門性や基本的なスキルを維持しながら、エージェントと協働できるようにするためである。 　シンガポールサイバーセキュリティ庁のサイバーセキュリティ認証プログラムに準拠したAIセキュリティガイドラインが、AIシステム全般（モデル、データ、インフラ）を対象とし、セキュリティ・バイ・デザイン、攻撃耐性、アクセス制御の観点から、技術的セキュリティ対策（設計・運用）に焦点を当てているのに対して、本フレームワークは、エージェンティックAIを対象とし、リスク評価、責任分担、技術制御、ヒューマン・イン・ザ・ループの観点から、ガバナンス、責任、リスク管理、ユーザー教育に焦点を当てている。

        AIセキュリティ認証プログラムは、エージェンティックAIを含むAIシステム全般の技術的な安全性と堅牢性を担保するための基盤を提供する一方、エージェンティック AI向けモデルAIガバナンスフレームワークは、エージェンティックAIの設計・導入・運用におけるリスク管理と責任の明確化を通じて、信頼性ある社会実装を支援する。両者は、技術とガバナンスの両輪として、シンガポールにおけるAIの安全・信頼・倫理的な活用を支える枠組みとなっている。

        エージェンティックAI固有のセキュリティ課題

        　シンガポールのエージェンティックAI向けモデルAIガバナンスフレームワークは、クラウドセキュリティアライアンス（CSA）の公開情報の中で、「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」（2025年5月12日公開、https://cloudsecurityalliance.org/blog/2025/05/12/agentic-ai-understanding-its-evolution-risks-and-security-challenges）と、「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」（2025年8月18日公開、https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach）を参照している。

        前者の「エージェンティックAI: その進化、リスク、セキュリティ課題の理解」では、エージェンティックAIのセキュリティ課題として、安全性（エージェントが有害な行動を取らないようにする）およびセキュリティ（悪意ある攻撃者による悪用を防ぐ）を挙げた上で、以下のような脅威例を挙げている。

        ・意図の破壊・目標の操作：プロンプトインジェクションなどにより、エージェントの目的を誤認させる。
        ・メモリポイズニング：履歴やデータストアを改ざんし、意思決定を誤らせる。
        ・連鎖的なハルシネーション：LLMが誤情報を生成し、それがシステム全体に波及する。

        そして、エージェンティックAIのセキュリティが重要な理由として、以下のような点を挙げている。

        ・データやシステムの悪用リスク：アクセス権限を持つエージェントが乗っ取られると深刻な被害に遭う
        ・予期せぬ結果：モデルの非決定性により、意図しない行動が発生する可能性がある
        ・自律性のリスク：人間の関与が減ることで、過剰な自律性が暴走する恐れがある
        ・規制・コンプライアンス対応：将来的にはエージェンティックAIにも特有の法的要件が課される見込みである

        エージェンティックAIは、自律性・適応性・複雑なタスク処理能力を備えた次世代AIとして期待される一方で、新たなセキュリティリスクやガバナンス課題をもたらす。これに対応するには、従来のサイバーセキュリティに加え、以下の通りAI特有のリスクに対応した新しいフレームワークとプロアクティブな対策が不可欠だとしている。

        ・新たなガバナンス基準やフレームワークが必要（例：OWASP Top 10 for LLM Apps、MITRE OCCULTなど）。
        ・設計段階からのセキュリティ重視、エージェントの認証・認可・監視の強化が求められる

        エージェンティックAIで進化するアイデンティティ／アクセス管理

        　次に、後者の「エージェンティックAIにおけるアイデンティティ／アクセス管理：新たなアプローチ」では、エージェンティックAIにおけるアイデンティティ／アクセス管理（IAM）が、従来のID管理システムとは根本的に異なるパラダイムシフトを示している点を強調している。従来のIAMプロトコルは、予測可能な人間のユーザーや静的なアプリケーションを対象に設計されていたが、エージェンティックAIシステムは自律的に動作し、動的な意思決定を行い、リアルタイムで適応可能なきめ細かなアクセス制御を必要とする。

        しかしながら、OAuth 2.1やSAMLといった従来のプロトコルは、粗い粒度の静的な性質や、マシンレベルの高速な認証処理への非対応、そして自律的なAIの運用に必要な文脈認識の欠如といった理由から、エージェンティックAIには適していない。

        この課題に対する解決策としては、以下の機能を統合した包括的なフレームワークが求められる。

        ・ゼロトラスト・アーキテクチャ
        ・分散型ID管理
        ・動的なポリシーベースのアクセス制御
        ・継続的な監視

        これにより、安全性・説明責任・コンプライアンスを確保したAIエージェントの導入が可能になるとしている。

        従来のIAMシステムは、主に人間のユーザーや静的なマシンIDを対象に、OAuth、OpenID Connect（OIDC）、SAMLなどのプロトコルを通じて設計されてきた。しかし、これらのシステムは、複数の知的エージェントが相互に連携して動作するマルチエージェントシステム（MAS）のような、動的・相互依存的・一時的な性質を持つAIエージェントのスケーラブルな運用には本質的に不十分である。

        CSAは、以下の通り新たなエージェンティックAI向けアイデンティティ／アクセス管理（IAM）フレームワークの必要性を提唱している。

        1. 既存プロトコルの限界の分析：
          まず、マルチエージェントシステム（MAS）に既存のプロトコルを適用した際の限界を分解し、粗い粒度の制御、単一エンティティへの最適化、文脈認識の欠如がなぜ効果的でないのかを具体例を交えて説明する。
        2. 新たなIAMフレームワークの提案：
          エージェントの能力、出自、行動範囲、セキュリティ姿勢を包括的に表現できる、検証可能なリッチなエージェントアイデンティティ（ID）に基づいたフレームワークを提案する。これには、分散型識別子（DID）と検証可能な資格情報（VC）を活用する。

        このフレームワークには以下の要素が含まれる。

        ・Agent Naming Service（ANS）：
        エージェントの安全かつ能力認識に基づく発見（ディスカバリ）を可能にする命名サービス。
        ・動的かつきめ細かなアクセス制御メカニズム：
        属性ベースアクセス制御（ABAC）、ポリシーベースアクセス制御（PBAC）、ジャストインタイム（JIT）アクセスなどを活用する。
        ・統合されたグローバルセッション管理とポリシー強制レイヤー：
        リアルタイム制御と一貫したアクセス権の取り消しを、異種のエージェント通信プロトコル間で実現する。

        さらに、ゼロ知識証明（ZKP）を活用することにより、プライバシーを保護しながら属性情報を開示し、ポリシー準拠を検証可能にする方法についても検討するとしている。

        CSAは、この新しいIAMパラダイムのアーキテクチャ、運用ライフサイクル、革新的な貢献点、セキュリティ上の考慮事項を概説し、エージェンティックAIとその複雑なエコシステムに必要な信頼性・説明責任・セキュリティの基盤構築を目指すとしている。

        このようにみていくと、シンガポールは、エージェンティックAIの社会実装に向けたガバナンスとセキュリティの両面で世界をリードしている。シンガポールサイバーセキュリティ庁のAIセキュリティガイドラインとシンガポール情報通信メディア開発庁のエージェンティックAI向けフレームワークは、相互補完的に機能し、信頼性あるAI活用の基盤構築に寄与している。その中で、クラウドセキュリティアライアンスのクラウドセキュリティおよびAIセキュリティ関連文書も有効活用されている。

        CSAジャパン関西支部メンバー
        DevSecOps／サーバーレスWGリーダー
        笹原英司

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

        コメントをどうぞ

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

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

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

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

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

        ゼロトラストは、セキュリティ対策としては適切なものであるが、リスク管理として重要である情報資産の重要性について言及されていない。特定非営利活動法人デジタル・フォレンジック研究会のコラム第８９６号：「ゼロトラストアプローチとリスク論的アプローチ」（https://digitalforensic.jp/2025/10/20/column896/）において佐々木良一 理事（東京電機大学　名誉教授　兼同大学サイバーセキュリティ研究所　客員教授）が以下のように述べている。「ゼロトラストの考え方自体は適切なものであるが、同時にリスクアセスメントを中心とするリスク論的アプローチも併用しないと適切な対策にならない」。リスクについて、上記コラムでは「リスク＝損害の大きさ×損害の発生確率」という工学分野の確率論的リスク評価の定義を使っている。情報セキュリティにおいてリスクは、「リスク＝影響度ｘ発生確率」と表現されるが、概念的には同じであり、ここでは影響の方が損害より広い概念として捉え、「損害の大きさ＝影響度」と捉えることとする。ここで、ゼロトラストは、「損害の発生確率」と結び付けることができるが、「損害の大きさ」（対象システムの重要性）についてはカバーされていない。したがって、ゼロトラストにおいてリスク論的アプローチを併用することが重要であるということになる。 そこで、「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セキュリティリーグでは、ここで述べられている７つのセキュリティリスクについて、実際に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のカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

          以上

          開発者向けクラウドネイティブセキュリティの基礎（ワークロードセキュリティ編）(2)

          コメントをどうぞ

          前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみたが、今回は、AIの普及とともに急増する人間以外のアイデンティティ（NHI：Non-Human Identity）に焦点を当てる。

          ノンヒューマン・アイデンティティ（NHI）とAIワークロードの関係

          クラウドセキュリティアライアンス（CSA）のブログ記事「ノンヒューマン・アイデンティティ管理」（関連情報（https://cloudsecurityalliance.org/blog/2024/07/15/non-human-identity-management））によると、ノンヒューマン・アイデンティティ（NHI）とは、現代の企業システムにおいて、マシン同士や人とマシンとの間のアクセスおよび認証を安全に行うためのデジタル・ゲートキーパーとして機能するものである。イノベーションの推進により、マイクロサービス、サードパーティ製ソリューション、クラウドベースのプラットフォームの導入が進み、相互に接続されたシステムの複雑なネットワークが形成されているという背景がある。

          そしてノンヒューマン・アイデンティティ管理（NHIM）とは、非人間の識別情報のライフサイクル全体を統制・自動化するプロセスであり、以下のような項目が含まれるとしている。

          ・発見と分類
          ・プロビジョニング（識別情報の作成と割り当て）
          ・所有者の割り当て
          ・状態の監視と異常検知
          ・保管庫への格納と安全な保存
          ・資格情報のローテーション（定期的な更新）
          ・コンプライアンス対応
          ・廃止（使用終了時の適切な処理）

          他方、AIワークロードとは、機械学習モデルのトレーニング、推論、データ処理、API連携など、AIが関与する一連の処理やタスクのことを指す。AIワークロードはクラウドやオンプレミス環境で自動的に実行されることが多く、人間の介在なしに動くのが特徴となっている。

          AIワークロードは、以下のような人間以外のエンティティによって構成されていることが多い：

          ・AIモデル自体（例：推論エンジン）
          ・スクリプトやバッチ処理
          ・APIクライアント
          ・コンテナやマイクロサービス
          ・CI/CDパイプラインの自動化ツール

          これらはすべて人間ではないが、システムにアクセスし、機密データを扱い、他のサービスと通信する存在となっている。そこで、誰が何にアクセスしているのかを明確にするためには、NHIの管理が不可欠になる。

          NHIに対するリスク認識と具体的セキュリティ対策のアンバランス

          CSAでは、ボット、APIキー、サービスアカウント、OAuthトークン、シークレットなどノンヒューマン・アイデンティティ（NHI）セキュリティで見落とされがちな側面を理解するために、2024年6月にオンライン調査を実施し、ITおよびセキュリティ専門家から818件の回答を得た。この結果を取りまとめたのが、2024年9月11日に公開された「ノンヒューマン・アイデンティティ・セキュリティの現状」である（関連情報（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report））。

          この報告書では、以下の点について洞察を提供している。

          ・NHIとそのセキュリティリスクに関する認識
          ・現在のNHIのセキュリティ対策、ポリシー、管理
          ・サードパーティベンダーとの接続に関する課題
          ・APIキーの現在の管理とポリシー

          主な調査結果は以下の通りである。

          ・NHI攻撃の防止に高い自信を持つ組織はわずか15%で、69%が懸念を表明している。これは、リスクを認識しているものの、現在のセキュリティ対策に自信がないことを示している。
          ・主な問題点としては、サービス アカウントの管理、監査と監視、アクセスと権限の管理、NHI の検出、ポリシーの適用などが挙げられる。
          ・APIキーのオフボーディングと失効に関する正式なプロセスを設けている組織はわずか20%であった。APIキーのローテーション手順を設けている組織はさらに少ない。
          ・多くの組織は、NHI向けに特別に設計されていないセキュリティツールを混在して使用している結果、一貫性と有効性が欠如している。
          ・有望な傾向として、NHI セキュリティ機能への投資が増加している。組織の 24% が今後 6 か月以内に、36% が今後 12 か月以内に投資する予定としている。

          新たなノンヒューマン・アイデンティティ（NHI）のリスクとは？

          前述のブログでは、MITRE ATT&CK Matrix for Enterprise（関連情報（https://attack.mitre.org/matrices/enterprise/））を参照しながら、管理されていないノンヒューマン・アイデンティティ（NHI）が、以下のような攻撃者の戦術・技術に関与することがあるとしている。

          初期アクセス：攻撃者がネットワークへの侵入を試みる段階
          ・サプライチェーンの侵害（T1195）
          ・信頼された関係性の悪用（T1199）
          ・正規アカウントの悪用（T1078）
          永続化：攻撃者がアクセスを維持しようとする段階
          ・アカウント操作（T1098）
          ・アカウントの新規作成（T1136）
          ・正規アカウントの悪用（T1078）
          資格情報へのアクセス：攻撃者が権限昇格や横展開を目的に、認証情報を盗もうとする段階
          ・パスワードストアからの資格情報取得（T1555）
          ・保護されていない資格情報の取得（T1552）
          ・アプリケーションのアクセストークンの窃取（T1528）

          そして攻撃者は、以下のような脅威ベクトルを通じてノンヒューマン・アイデンティティ（NHI）を悪用し、アクセスを獲得するとしている。

          1. 放置された特権NHI（資格情報のローテーションなし）：
            ・特権アクセスを持ちながらも、所有者不在や責任の所在不明、資格情報の未更新により放置されたアカウントは、攻撃者にとって格好の標的となる。
          2. 退職者に晒された未ローテーションのシークレット：
            ・退職した従業員が依然としてアクセス可能なシークレットがローテーションされずに残っている場合、特にそれがインターネット上でアクセス可能で特権を持っていると、重大なリスクとなる。
          3. 放置されたストレージアカウント
            ・長期間使用されていないストレージアカウントは、古い設定のまま放置されていることが多く、機密データが不正アクセスや漏洩の危険にさらされる可能性がある。
          4. 有効期限が50年以上のアクティブなシークレット：
            ・極端に長い有効期限を持つシークレットは、攻撃者にとって脆弱性を突くための長期間のチャンスを提供してしまい、セキュリティリスクが高まる。
          5. 未使用のアクセスポリシーを含むボールト（保管庫）
            ・使われていないアクセスポリシーが残されたボールトは、見落とされがちなセキュリティギャップとなり、意図しないアクセス権を通じて機密リソースやデータへの不正アクセスを許す可能性がある。

          AIエージェントで複雑化するノンヒューマン・アイデンティティの保護

          CSAの「AIエージェント時代におけるノンヒューマン・アイデンティティの保護」（2025年4月29日公開）では、人間1人に対して45のノンヒューマン・アイデンティティが存在しており、AIエージェントの普及によりこの数はさらに増加すると指摘している（関連情報（https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025））。

          AIエージェントは、サービスアカウント、APIキー、シークレット情報のようなNHIを使ってシステムにアクセスする。これらは組織の機密データや重要なシステムにアクセスするための鍵となるため、攻撃者にとって格好の標的になる。

          しかしながら、従来のアイデンティティ・アクセス管理（IAM）は静的なアプリケーションや人間のユーザー向けに設計されており、AIエージェントのような存在には対応しきれない。AIエージェントは、自律的に意思決定を行い、タスクごとに一時的なIDを使い分けて、他のAIエージェントに権限を委譲するといった特徴を持つため、新しいIAMの枠組みが必要となる。

          CSAでは、ノンヒューマン・アイデンティティ（NHI）について、以下のようなセキュリティ課題を挙げている。

          ・NHIに関する可視性の欠如：多くの組織が、どのNHIがどこで使われているかを把握できていない
          ・アクセス権の過剰付与：最小権限の原則が徹底されていない
          ・認証情報の管理不備：APIキーやシークレットが適切に保護・ローテーションされていない

          これらに対して、以下のような対策を推奨している。

          ・NHIの発見・分類・監視の自動化
          ・エージェンティックIAMの導入
          ・ゼロトラスト原則に基づいたアクセス制御

          適切なノンヒューマン・アイデンティティ管理プラットフォームの選び方

          AIに代表される新技術の導入とともに、アイデンティティが新たなセキュリティ境界となる中で、人間のアイデンティティだけに注目していたのでは不十分な状況となっている。今や、ノンヒューマン・アイデンティティ管理（NHIM）は、アイデンティティ＆アクセス管理（IAM）における大きな転換点となっている。

          非人間エンティティの特有の要件に対応するために、NHIMプラットフォームには以下の基本要件を満たすことが求められる。

          1. 包括的かつコンテキストに基づく可視性：
            ・非人間アイデンティティの全体像を把握することが不可欠である。
            ・NHIMプラットフォームは、使用状況、依存関係、エコシステム内の関係性を含む包括的な可視性を提供すべきである。
          2. ハイブリッドクラウド全体での対応力：
            ・NHIMプラットフォームは、従来のインフラの枠を超え、ハイブリッドクラウド環境全体でシームレスに動作する必要がある。
            ・AWS、Azure、Google Cloudなどの主要なIaaSだけでなく、PaaSやSaaS、オンプレミス環境もカバーすべきである。
          3. アクティブなポスチャー管理：
            ・脅威が進化する中で、リアルタイムでのセキュリティ状態の評価とリスク軽減のための能動的な対策が不可欠となる。
            ・NHIMプラットフォームは、これを可能にする機能を備えている必要がある。
          4. ライフサイクル管理と自動化：
            ・プロビジョニングから資格情報のローテーション、廃止に至るまで、NHIのライフサイクル管理は自動化されるべきである。
            ・NHIMプラットフォームは、これらのタスクを自動化し、運用効率とセキュリティの両立を実現する機能を提供すべきである。
          5. シークレット管理ツールやPAMとの連携：
            ・主要なシークレット管理ソリューションと統合できること。
            ・特権アクセス管理（PAM）ソリューションと連携し、発見されたシークレットを安全に保管・管理できることが求められる。
          6. 開発者に優しい設計：
            NHIMプラットフォームは、堅牢なAPIを備え、アプリケーションやサービスとの統合が容易であるべきである。
            ・Infrastructure as Code（IaC）ツール、ITサービス管理（ITSM）システム、ログフレームワーク、開発ツールなど、運用スタックとのシームレスな統合も重要である。

          必要なエコシステムとの統合機能や各種機能を備えた堅牢なノンヒューマン・アイデンティティ管理（NHIM）プラットフォームを導入することにより、組織は非人間アイデンティティを効果的に管理し、セキュリティ体制を強化し、自動化やシステム間連携の利点を最大限に活用することができるとしている。

          　なお特権アクセス管理（PAM）に関連して、CSAでは、2025年11月24日に「クラウドファースト時代における特権アクセス管理」を公開している（関連情報（https://cloudsecurityalliance.org/artifacts/managing-privileged-access-in-a-cloud-first-world）、日本語版（https://www.cloudsecurityalliance.jp/site/?p=41892））。

          OWASP Non-Human Identities Top 10とは？

          参考までに、CSAと連携するOWASPでは、「OWASP Non-Human Identities Top 10」を公開している（関連情報（https://cloudsecurityalliance.org/blog/2025/06/30/introducing-the-owasp-nhi-top-10-standardizing-non-human-identity-security））。具体的な10項目は、以下の通りである。

          ・NHI1:2025 – 不適切なオフボーディング
          不適切なオフボーディングとは、サービスアカウントやアクセスキーなどのノンヒューマン・アイデンティティ（NHI）が不要になった際に、適切に無効化または削除されないことを指す。監視されていない、または廃止されたサービスが脆弱なまま残る可能性があり、それに関連するNHIが攻撃者に悪用され、機密性の高いシステムやデータへの不正アクセスにつながるおそれがある。
          ・NHI2:2025 – シークレット漏えい
          シークレット漏えいとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、ソフトウェア開発ライフサイクル全体を通じて、許可されていないデータストアに漏えいすることを指す。たとえば、ソースコードにハードコーディングされたり、平文の設定ファイルに保存されたり、公的なチャットアプリで送信されたりすると、これらのシークレットは露出しやすくなり、悪意ある第三者に悪用されるリスクが高まる。
          ・NHI3:2025 – 脆弱なサードパーティNHI
          サードパーティのノンヒューマン・アイデンティティ（NHI）とは、統合開発環境（IDE）やその拡張機能、サードパーティのSaaSを通じて、開発ワークフローに広く統合されている。もしサードパーティの拡張機能が、セキュリティの脆弱性や悪意あるアップデートによって侵害された場合、それを悪用して認証情報を盗んだり、付与された権限を不正に使用されたりする可能性がある。
          ・NHI4:2025 – 安全でない認証
          開発者は、内部および外部（サードパーティ）のサービスをアプリケーションに頻繁に統合する。これらのサービスは、システム内のリソースにアクセスするために、認証情報を必要とする。しかし、一部の認証方式はすでに非推奨であったり、既知の攻撃に対して脆弱であったり、古いセキュリティ慣行により安全性が低いと見なされたりしている。安全でない、または時代遅れの認証メカニズムを使用すると、組織は重大なリスクにさらされる可能性がある。
          ・NHI5:2025 – 過剰な特権を与えられたNHI
          アプリケーションの開発や保守の過程で、開発者や管理者がノンヒューマン・アイデンティティ（NHI）に、その機能に必要以上の権限を付与してしまうことがある。こうした過剰な権限を持つNHIが、アプリケーションの脆弱性やマルウェア、その他のセキュリティ侵害によって侵害されると、攻撃者はその過剰な権限を悪用する可能性がある。
          ・NHI6:2025 – 安全でないクラウド展開構成
          CI/CD（継続的インテグレーションおよび継続的デプロイ）アプリケーションは、コードのビルド、テスト、そして本番環境へのデプロイを自動化するために、開発者に広く利用されている。これらの統合には、クラウドサービスとの認証が必要であり、通常は静的な認証情報やOpenID Connect（OIDC）を使用して実現される。静的な認証情報は、コードリポジトリ、ログ、設定ファイルなどを通じて、意図せず漏えいする可能性がある。もしこれらが侵害されると、攻撃者に対して永続的かつ特権的なアクセス権を与えてしまう恐れがある。一方、OIDCはより安全な選択肢であるが、IDトークンが適切に検証されていなかったり、トークンクレームに厳格な条件が設定されていなかったりすると、不正なユーザーがその弱点を突いてアクセスを得る可能性がある。
          ・NHI7:2025 – 長きにわたるシークレット
          長期間有効なシークレットとは、APIキー、トークン、暗号鍵、証明書などの機密性の高いノンヒューマン・アイデンティティ（NHI）が、非常に長い有効期限を持っていたり、まったく期限切れにならないように設定されていたりする状態を指す。こうしたシークレットが漏えいした場合、有効期限が長いために、攻撃者が時間の制限なく機密サービスへアクセスできてしまうリスクがある。
          ・NHI8:2025 – 環境の分離
          環境の分離とは、クラウドアプリケーションのデプロイにおける基本的なセキュリティ対策であり、開発・テスト・ステージング・本番といった環境を分けて運用することを指す。アプリケーションのデプロイプロセスやライフサイクル全体において、ノンヒューマン・アイデンティティ（NHI）が頻繁に使用される。しかし、同じNHIを複数の環境、特にテスト環境と本番環境で使い回すと、重大なセキュリティ脆弱性を招く可能性がある。
          ・NHI9:2025 – NHIの再利用
          同じノンヒューマン・アイデンティティ（NHI）を、異なるアプリケーション、サービス、またはコンポーネント間で使い回すことは、たとえそれらが一緒にデプロイされていたとしても、重大なセキュリティリスクを引き起こす。もしある領域でNHIが侵害された場合、攻撃者はその認証情報を悪用して、同じ資格情報を使用している他のシステム部分にも不正アクセスできてしまう可能性がある。
          ・NHI10:2025 – 人間におけるNHIの使用
          アプリケーションの開発や保守の過程で、開発者や管理者が本来は適切な権限を持つ人間のIDで実行すべき手作業を、ノンヒューマン・アイデンティティ（NHI）を使って行ってしまうことがある。このような運用は、NHIに過剰な権限を与える原因となり、また人間と自動化の活動が区別できなくなることで、監査や責任追跡が困難になるなど、重大なセキュリティリスクを引き起こす。

          　今後、「OWASP Non-Human Identities Top 10」に関しては、CI/CDやIaC（Infrastructure as Code）、サードパーティ統合など、クラウドネイティブな開発環境におけるNHIの利用実態に即したベストプラクティスの整備が期待されている。

          CSAジャパン関西支部メンバー
          DevSecOps／サーバーレスWGリーダー
          笹原英司

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

          以上

          Valid-AI-ted：AIをセキュリティに活用するツール

          コメントをどうぞ

          CSAジャパン　AIワーキンググループメンバー　諸角昌宏

          本ブログは、AIのクラウドセキュリティへの活用としてCSAが提供しているValid-AI-tedについて解説します。このValid-AI-tedツールは、最先端のLLM技術を用いて強化されたAIの革新的な利用方法となります。

          Valid-AI-tedとは

          Valid-AI-tedは、クラウドサービスプロバイダがクラウドサービスのセキュリティについて自己評価（Self-Assessment）した結果をAIが評価し、合格するとValid-AI-tedバッジが与えられるものです。

          CSAでは、以前よりクラウドサービスプロバイダがCAIQ（Consensus Assessment Initiative Questionnaire）を使用して、その評価レポートを公開できるウエブサイトとしてSTAR Registryを提供していました。これにより、クラウドサービス利用者は、利用しようとしているクラウドサービスのセキュリティについて、STAR Registryから該当するクラウドサービスのCAIQ評価レポートをダウンロードし、自らの要求事項を満たしているかどうかを評価することができます。STAR Registryの詳細についてはこちらを参照してください。
          Valid-AI-tedの登場により、クラウドサービスプロバイダは、今までは自己評価だけであったものが、AIを活用して評価することとなり、評価の質を高め、信頼性を大きく向上することができます。また、クラウドサービスプロバイダが行う監査の前の自己チェックや改善点の特定に用いることができます。クラウドサービス利用者は、より信頼性の高い評価レポートを入手することができます。

          Valid-AI-ted概要

          Valid-AI-tedでは、クラウドサービスプロバイダがSTAR Registryに公開しているCAIQ評価レポートをAIが評価し、合格するとValid-AI-tedバッジ（セルフアセスメントがセキュリティベースラインを達成していることを保証）がSTAR Registry上に表示されます。
          CAIQでは、クラウドサービスプロバイダが自己評価した結果を記載します（下図の赤丸の部分）が、その中の「CSP Implementation Description」には、その管理策に対する実装・実施方法の説明（逆に、管理策が実装・実施されていない場合にはその理由）が記述されます。Valid-AI-tedは、この「CSP Implementation Description」の内容をAIが評価します。また、Valid-AI-tedは評価するだけではなく、詳細なフィードバックと修正ガイダンスをすぐに提供します。これにより、クラウドサービスプロバイダはどのような追加対策等を取る必要があるかを知ることができます。



          また、評価のベースになるのが、CCM（Cloud Controls Matrix）のImplementation Guidelinesになります。CCMは、CSAが提供するクラウドセキュリティ管理策集です。CCMでは、管理策を記述するだけでなく、以下の図で示すような情報を含んでいます。

          CCMのEXCELシートのタグにあるImplementation Guidelinesには、管理策の実装方法が書かれており、この内容がValid-AI-tedの評価のベースとなっています。
          以上のように、Valid-AI-tedは、既存のCSAのガバナンス・フレームワーク（STAR認証、CCM、CAIQ）をそのまま維持し、その上にAIによる評価を構築したものとなっています。

          Valid-AI-tedのメリット

          以下の表に、Valid-AI-tedのメリットについてまとめてみました。クラウドサービスプロバイダ（CSP）、クラウドサービス利用者（CSC）、監査者（Auditor）のそれぞれについて、既存のSTAR Level1:セルフアセスメントとValid-AI-tedによる評価を比較しています。今までのセルフアセスメントもメリットがあるのですが、Valid-AI-tedにより、より多くのメリットを享受することができます。

          Valid-AI-tedの今後の展開

          2025年12月31日時点で、Valid-AI-tedバッジを取得しているクラウドサービスプロバイダは12社あります。その中には、GoogleやMicrosoftなどのメガプロバイダも含まれています。STAR Registryに登録されているクラウドサービスプロバイダは4,000社を超えており、これらが順次Valid-AI-ted対応を進めていくことになることを考えると、Valid-AI-tedが幅広く利用される状況になっていくものと思われます。

          また、ここからは個人的な考えになりますが、Valid-AI-tedを現在のCAIQを使った評価だけでなく、様々な標準に対応できたら素晴らしいと考えています。たとえば、日本のISMAPやJC-STARの評価、国際的なISMSの評価、その他様々な監査などです。アーキテクチャ的には可能であると思われます。CSAは、ベンダーニュートラルの組織で、様々なリサーチ活動を行っています。もし、このような取り組みに関心がありましたら、info @ cloudsecurityalliance.jp(アットマークの前後の空白を削除)までメールでご連絡ください。一緒にやりましょう！

          その他、関連情報

          以上

          開発者向けクラウドネイティブセキュリティの基礎（ワークロードセキュリティ編）(1)

          コメントをどうぞ

          CSAジャパン関西支部では、2024年7月15日にCSA本部が公開した「クラウドコンピューティングのためのセキュリティガイダンス V5」（https://cloudsecurityalliance.org/artifacts/security-guidance-v5）と前後して、クラウドワークロードセキュリティおよびアプリケーションセキュリティの観点から、以下のようなブログを展開してきた。

          ・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (前編)（2024年6月25日）https://cloudsecurityalliance.jp/newblog/2024/06/25/devsecops_3/
          ・コンテナ／マイクロサービス／サーバーレスセキュリティとDevSecOps(組織編) (後編)（2024年7月16日）https://cloudsecurityalliance.jp/newblog/2024/07/16/devsecops_4/
          ・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年8月13日）https://cloudsecurityalliance.jp/newblog/2024/08/13/cloud_workload/
          ・コンテナ／マイクロサービス／サーバーレスセキュリティと自動化／AI(技術編)(前編)（2024年9月8日）https://cloudsecurityalliance.jp/newblog/2024/09/08/ssdlc/

          今回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「MLOps」に焦点を当てながら、AIワークロードセキュティの動向をみていく。

          膨大な量の学習用データを処理するAIワークロードとリスク低減策

          前述の「クラウドコンピューティングのためのセキュリティガイダンス V5」のうち、「ドメイン8: クラウドワークロードセキュリティ」の「8.6 AIワークロード」では、AIワークロードについて、AI機能の構築、提供、または利用に関わるタスク、プロセス、あるいはオペレーションを指すとしている。AIワークロードは、ユーザー行動に基づく製品の推奨から、車両の自律的な操縦に至るまで、非常に幅広い複雑性と応用分野を包含しているのが特徴である。

          AIワークロードは、モデルのトレーニングに大量のデータセットを必要とし、効率化のためにGPU（グラフィックス処理ユニット）やTPU（テンソル処理ユニット）などの専用ハードウェアを活用するなど、かなりの処理能力を要求する。さらに、これらのワークロードは、需要の変動に対応するために動的にスケールする必要があり、クラウド環境によって提供される柔軟なコンピューティングリソースが重要になる。AIワークロードへの取り組みは、単に計算能力を活用することだけではなく、様々な分野でイノベーションと価値を解き放つために、データ、アルゴリズム、リアルタイム処理の複雑な要素を乗りこなすことでもあるとしている。

          　CSAガイダンスV5では、AIワークロードセキュリティにおけるリスク低減策として、以下のような点を挙げている。

          ・データセキュリティ：データを保護するために、暗号化、差分プライバシー、セキュアなマルチパーティ計算を利用する
          ・モデルセキュリティ：敵対的な攻撃に対してモデルをハードニングし、堅牢なトレーニング手法を利用し、盗難防止のために固有識別子を組み込む
          ・インフラストラクチャセキュリティ：割当・レート制限を実装し、クラウドサービスに関するベストプラクティスをフォローする
          ・サプライチェーンセキュリティ：サイバーセキュリティポリシーを定義し、定期的にサードパーティの依存性を監査し、信頼されたリソースを利用する

          CSA DevSecOps WG が「MLOpsの概要」を公開

          CSA DevSecOps WGは、2025年8月27日に「MLOpsの概要」（https://cloudsecurityalliance.org/artifacts/machine-learning-ops-overview）を公開している。

          機械学習(ML)は、ますます企業の中核的な業務機能と結びつくようになっており、それに伴いMLパイプラインのセキュリティ確保が不可欠となっている。そこで本書では、MLSecOps（Machine Learning Security Operations）の概念を紹介し、ML資産を保護する上で特有の課題や、従来のセキュリティ対策がMLシステムに対する新たな脅威に対して十分に機能しない理由について説明することを目的としている。

          ・謝辞
          ・目次
          ・はじめに
          ・目標.
          ・対象読者
          ・エグゼクティブサマリー（概要）
          ・MLOpsとは？
          ・LLMOps vs. AgentOps vs. 従来型MLOpsの融合
          ・MLOpsのステークホルダー
          －データサイエンティスト
          －機械学習エンジニア
          －運用チーム
          －プラットフォームチーム
          ―セキュリティチーム／セキュリティエンジニア.
          ―プライバシーチーム
          ―データおよびコンプライアンスチーム
          ―Cレベル職／経営層.
          ―プロジェクト／プロダクトチーム
          ―顧客
          ・MLOpsの各ステージ
          ―設計ステージ
          ―モデル開発ステージ
          ―運用ステージ
          ―継続的フィードバックステージ
          ・MLOpsの課題
          ・結論

          ここ数年で、従来のMLOpsの概念は、古典的な機械学習モデルを運用化するための一連のプラクティスやワークフローとして業界内で発展してきた。しかし、近年の大規模言語モデル（LLM）およびLLMを活用したAIエージェントの進化に伴い、これらの技術を運用化する際に特有の課題に対応するための新たなプラクティスやワークフローを表す用語として、「LLMOps」や「AgentOps」といった言葉が業界で使われるようになっている。LLMは、従来の機械学習モデルと比べてはるかに高い計算複雑性を持ち、専門的なインフラや最適化技術が必要とされる。LLMOpsは、こうしたLLMモデルを本番環境で学習・デプロイ・管理するために進化してきたものである。

          本書では、MLOps(機械学習運用)、LLMOps(大規模言語モデル運用)、AgentOps(エージェント運用)の特徴を以下のように整理している。

          【MLOps（機械学習運用）】
          ・対象範囲：一般的な機械学習モデル（分類、回帰、強化学習など）
          ・モデルサイズ：通常は数MB〜数GBの小〜中規模モデル
          ・データ要件：構造化データ／表形式データ、画像、時系列、小規模なテキストデータセット
          ・学習プロセス：モデルはゼロから学習されるか、小規模なデータセットでファインチューニングされる
          ・インフラ要件：従来型のMLモデルは、スケーラビリティとクラウドネイティブ環境に重点を置いた中程度のインフラを必要とする
          ・モデルのデプロイ：モデルは通常コンテナ化され、DockerやKubernetesなどのプラットフォーム、および自動化されたCI/CDパイプラインを用いて継続的にデリバリーされる
          ・推論：予測モデルはREST APIとしてデプロイされるか、アプリケーションに組み込まれる
          ・モニタリングと可観測性：モニタリングはモデルの性能、レイテンシ、ドリフト検出、精度に焦点を当てる。PrometheusやGrafanaなどの可観測性ツールが一般的
          ・バージョン管理：モデルのバージョン、特徴量、ハイパーパラメータを追跡
          ・ガバナンスとコンプライアンス：ガバナンスはデータプライバシー、規制遵守（例：GDPR、CCPA）、モデルおよびデータへの安全なアクセスに重点を置く
          ・最適化手法：従来型のML最適化（例：ハイパーパラメータチューニング、特徴量エンジニアリング）
          ・ライフスパンと更新：モデルは新しいデータセットや変化するトレンドに応じて頻繁な更新と再学習が必要

          【LLMOps(大規模言語モデル運用)】
          ・対象範囲：大規模言語モデル（LLM）に特化しており、ファインチューニング、推論、プロンプトエンジニアリングを含む
          ・モデルサイズ：数百億〜数千億パラメータ規模の大規模モデル
          ・データ要件：学習・ファインチューニング・継続学習のための膨大な非構造化テキストデータや埋め込みベクトル
          ・学習プロセス：事前学習済みモデル（例：OpenAIのChatGPT、MetaのLLaMA）をファインチューニングするか、プロンプトベースで適応させる手法が一般的
          ・インフラ要件：LLMは大規模なインフラ資源を必要とし、分散コンピューティング、高性能GPU/TPU、大規模データセットや並列学習に対応する高度なストレージソリューションが求められる
          ・モデルのデプロイ：推論効率を高めるために、量子化、モデル分割、知識蒸留などの最適化技術が用いられることがある。また、エッジAIやハイブリッドクラウドでの展開も行われる
          ・推論：プロンプトベースの推論、リアルタイムのテキスト生成、チャット型インターフェースなど
          ・モニタリングと可観測性：言語生成の品質、応答時間、モデルの倫理的側面（例：バイアス、不適切な応答、幻覚、攻撃的表現など）の監視が追加で求められる
          ・バージョン管理：プロンプト、モデルのチェックポイント、ファインチューニングされたバリアントのバージョン管理を含む
          ・ガバナンスとコンプライアンス：責任あるAIの実践、大規模モデルにおける知的財産の管理、生成AIシステムに対する倫理的ガイドラインの遵守に強く焦点を当てる

          【AgentOps(エージェント運用)】
          ・対象範囲： ユーザー、ツール、環境と対話する自律型AIエージェントの管理、およびマルチステップ推論、記憶、ツール使用のオーケストレーション
          ・モデルタイプ： 計画・推論・ツール使用が可能な動的かつ対話型のエージェント
          ・デプロイ： API、データベース、ユーザーとやり取りするサービスとしてエージェントをデプロイ
          ・推論： マルチステップ推論、反復的な意思決定、ツールの活用
          ・モニタリングと可観測性： エージェントの推論の正確性、ハルシネーションの検出、状態の追跡
          ・バージョン管理： エージェントのプロンプト、推論ログ、記憶状態、ツール統合の履歴を追跡
          ・最適化手法： エージェントの記憶のファインチューニング、推論ステップの改善、ツール使用の最適化

          MLOpsを取り巻く多様なステークホルダーの存在

          業界では現在、MLOps、LLMOps、AgentOpsといった用語を区別して使う傾向があるが、CSAとしては、これらの用語は最終的に統合されるべきであり、「MLOps」という用語が、機械学習に関連するすべての運用プラクティス、ワークフロー、技術アーキテクチャを包括するべきだと考えている。

          定義上、機械学習の世界は、あらゆる学習手法とモデリングアーキテクチャを含む上位概念（スーパーセット）であり、現在LLMが使用しているトランスフォーマーのような手法、畳み込みニューラルネットワーク（CNN）、再帰型ニューラルネットワーク（RNN）、長短期記憶（LSTM）といった他の生成系AIの学習技術、さらにはサポートベクターマシン（SVM）、回帰モデル、人工ニューラルネットワーク（ANN）などのより古典的な機械学習手法もすべて含まれる。従って、本書においては、「MLOps」という用語を業界標準とは異なる意味で使用しており、LLMOpsやAgentOpsをも内包する広義の概念として扱っている。

          MLOpsは、機械学習モデルの調査、データ収集、トレーニング、開発に多くの時間が費やされるため、従来のDevOpsと比べてややアジャイル性が低い傾向がある。MLOpsのプラクティスを導入することによって、機械学習モデルのライフサイクルに自動化を取り入れることが可能になる。MLOpsのパイプラインには複数の重要なステークホルダーが関与しており、それぞれが異なる役割を担いながら、機械学習と運用の橋渡しを行い、MLOpsを実現している。

          　本書では、以下の通り、10の重要なステークホルダーを挙げている。

          ・データサイエンティスト：
          データサイエンティストは、機械学習モデルを作成・学習させるためのアルゴリズムやデータを含む、モデルエンジニアリングのパイプラインを管理することが多い。彼らの役割には、モデルの作成、トレーニング、評価、テスト、パッケージ化などが含まれる。ただし、データサイエンティストは、実運用に耐えるソフトウェアサービスを構築する熟練のソフトウェアエンジニアであるとは限らない。

          ・機械学習エンジニア：
          機械学習エンジニアは、データサイエンスチームから引き渡されたモデルを、呼び出し可能なアーティファクト（例：API統合）へと変換する役割を担うことが多い。大規模な機械学習モデルのトレーニング、モデルの保存、コードリポジトリやモデルレジストリへのアップロード、モデルのデプロイと利用可能な状態への展開、さらにスケーラブルな推論パイプラインやアプリケーションの構築などが、機械学習エンジニアの主な業務である。

          ・オペレーションチーム：
          オペレーションチームは、継続的インテグレーション（CI）および継続的デリバリー（CD）のパイプラインを管理する。機械学習のデプロイメントにおいては、データ、モデル、トレーニング成果物といった複数のワークフローに対応する必要があるため、従来のソフトウェアのCI/CDフロー（例：開発 → QA → 本番）よりもパイプラインが複雑になる。モデルは頻繁に更新されるのではなく、全体として繰り返しリリースされる傾向があるため、データ用のパイプラインとモデル用のパイプラインが分かれて存在することが一般的である。

          ・プラットフォームチーム：
          プラットフォームチームは、インフラの管理、自動化、スケーラビリティ、システムの監視を担当する。機械学習の文脈においては、MLモデルを迅速かつ信頼性高くスケーラブルにデプロイするためのフレームワークを設計・維持する上で、非常に重要な役割を果たす。

          ・セキュリティチーム／セキュリティエンジニア：
          セキュリティチームは、MLOpsライフサイクル全体において、セキュリティ対策が設計段階から統合されていることを確保するという重要な役割を担う。このチームは、機械学習システムの脅威モデリングの実施、データおよびモデルにおける潜在的な脆弱性の特定、セキュリティガードレールの実装、セキュリティインシデントの監視、セキュリティポリシーや標準への準拠の確保などを担当する。

          ・プライバシーチーム：
          MLOpsライフサイクルにおいて、プライバシーチームは、モデルの開発やトレーニングに使用されるデータが、適用されるプライバシー規制および組織の基準に準拠していることを確保する責任を担う。このチームは、データ最小化の原則の適用、個人識別可能情報（PII）の特定、そしてデータの匿名化、仮名化、差分プライバシーといった技術の導入を通じて、ユーザーデータの保護を行う。プライバシーチームは、MLOpsライフサイクル全体にわたってプライバシーの観点が組み込まれるようにし、倫理的なAIの実践と規制遵守の両方を支援する。

          ・データ／コンプライアンスチーム：
          データ／コンプライアンスチームは、データライフサイクルの管理を担い、機械学習モデルが高品質で関連性があり、偏りのないデータでトレーニングされることを確保する責任がある。これには、さまざまなソースからの新たなデータの導入や収集、データ管理、分析、データセキュリティなどが含まれる。MLOpsパイプラインにおいては、データセキュリティが最重要事項の一つであり、コンプライアンスチームは機密情報を保護・管理するための対策を講じる必要がある。

          ・Cレベル職／経営層：
          経営層やCレベルのチームは、社内プロセスの最適化や顧客向けビジネスの強化を目的として、機械学習の導入に関心を持っている。このチームは、MLOpsによって実現される開発期間の短縮、モデルの信頼性や最新性の確保、コストや稼働率の要件への適合、そしてビジネスの主要業績評価指標（KPI）や各種メトリクスに対する大きなインパクトに注目している。

          ・プロジェクト／プロダクトチーム：
          プロダクトチームは、機械学習プロダクトのビジョンを導くうえで不可欠な存在であり、しばしばMLのユースケースの優先順位付けを担当する。一方、プロジェクトチームは、そのプロダクトビジョンを実現し、目標期日までに成果を届けるための推進役として重要な役割を果たす。

          ・顧客：
          顧客は、自身のデータがMLOpsパイプラインにおいてどのように活用されているかに関心を持っている。具体的には、自分のデータがモデルのトレーニングに使用されているかどうか、機密データが適切に保護されており、マルチテナント環境で他の利用者に漏洩しないこと、退会後にデータが適切に削除され、機械学習モデルに機密情報が残らないことなどを気にしている。また、機械学習モデルの信頼性や説明可能性についても高い関心を持っている。

          MLOpsパイプラインにおけるセキュリティ部門の役割とは？

          次に本書では、以下の通り、MLOpsパイプラインの4つのステージを紹介し、各ステージにおける主要なステークホルダーとの関係を説明している。

          1.設計ステージ：
          ・要求事項の収集、設計、計画策定
          （ステークホルダー）経営層／リーダーシップ、製品／プロジェクトチーム、データサイエンティスト、機械学習エンジニア、セキュリティエンジニア

          2.モデル開発ステージ：
          ・データ準備／モデルのためのデータ収集
          （ステークホルダー）データ／コンプライアンスチーム、プライバシーチーム、データサイエンティスト、機械学習エンジニア
          ・モデル検証とテスト
          （ステークホルダー）データサイエンティスト

          1. 運用ステージ：
            ・モデルトレーニング
            （ステークホルダー）機械学習エンジニア、データサイエンティスト
            ・デプロイ
            （ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム
            ・モニタリング
            （ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム、サイト信頼性エンジニア

          4.継続的なフィードバックステージ
          ・モデルの結果の利用
          （ステークホルダー）下流アプリケーション、内部ステークホルダー、外部顧客
          ・新たなモデルのアップデート
          （ステークホルダー）機械学習エンジニア、データサイエンティスト、製品／プロジェクトチーム

          早期からDevSecOpsの導入に取り組んできたユーザー企業をみると、既存のオンプレミス環境をベースとするレガシーなエンタープライズシステム体制の改革からスタートし、クラウド環境への移行を図ってきたケースが多い。これに対してMLOpsの場合、DevOpsやDevSecOpsの原則やプラクティスを拡張し、機械学習（ML）のライフサイクルに適用することを目指すが、前述のステークホルダーの顔ぶれを見てもわかるように、組織の開発部門（Dev）や運用部門（Ops）、情報セキュリティ部門（Sec）だけでなく、社内のCレベル職／経営層やユーザー部門、組織外にある外部委託先／パートナー、顧客など、多様なステークホルダーとのコミュニケーションを行いながら、プロジェクトを進めることが必要になる。

          その一方でMLOpsは、人間による操作を最小限に抑え、エンドツーエンドの自動化を実現するために、AIワークロードを実行する「非人間アイデンティティ（NHI: Non-Human Identity）」を活用しており、従来とは異なる認証／認可管理やアクセス制御ポリシーの策定が不可欠になってくる。参考までにCSAでは、2024年9月11日に「ノンヒューマンアイデンティティ・セキュリティの状況」（https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report）を公開している。

          このようなMLOps固有のセキュリティ対策が設計段階から組み込まれるよう確保することが、今後、セキュリティチーム／セキュリティエンジニアの重要な役割となってくる。

          CSAジャパン関西支部メンバー
          DevSecOps／サーバーレスWGリーダー
          笹原英司

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

          コメントをどうぞ

          第２回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のセキュリティ機能の標準化ができるようになると非常に有効である。しかしながら、どのように強制できるかが今後の課題となる。

          以上