月別アーカイブ: 2026年2月

開発者向けクラウドネイティブセキュリティの基礎（アプリケーションセキュリティ編）(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のカバレッジとコストの高さが導入に向けてのハードルとなっている。ベンダー側の対応が期待される。

    以上