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つの中核的要素により構成される。

エージェンティック 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リーダー
笹原英司

前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「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リーダー
笹原英司

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

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

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リーダー
笹原英司

海外に学ぶSMBのクラウドセキュリティ基礎（OTセキュリティ編）(1)に引き続き、今回は、シンガポールサイバーセキュリティ庁の大企業・クラウドサービスプロバイダーを対象とするサイバートラストに基づいて開発されたOTセキュリティ固有のガイドを紹介していく。

シンガポール政府が大企業／CSP向けOTセキュリティガイドラインを提供

シンガポールサイバーセキュリティ庁のサイバートラストマークとCSA STAR認証との間には、相互承認制度（MRA：Mutual Recognition Agreement）が確立されている。サイバートラストマークの各管理策項目に対応するCCM v4の管理策項目については、「CSA サイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4のクロスマッピング」で公開されている（https://isomer-user-content.by.gov.sg/36/2afb6128-5b9b-4e32-b151-5c6033b993f1/Cloud-Security-Companion-Guide-Cyber-Trust.pdf）。

以下では、サイバートラストマーク認証関連文書（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-for-organisations/cyber-trust/certification-for-the-cyber-trust-mark/）の1つとして公開されている「サイバートラスト(2025) マーク – 自己評価テンプレート」より、サイバートラストマークの各管理策項目におけるOTセキュリティ固有の管理策およびフォーカス領域を紹介する。

• B.1 ドメイン: ガバナンス
• B.2 ドメイン: ポリシーと手順
• B.3 ドメイン: リスクマネジメント
• B.4ドメイン: サイバー戦略
• B.5 ドメイン: コンプライアンス
• B.6 ドメイン: 監査
• B.7 ドメイン: トレーニングと認識
• B.8 ドメイン: 資産管理
• B.9 ドメイン: データ保護とプライバシー
• B.10 ドメイン: バックアップ
• B.11 ドメイン: Bring Your Own Device (BYOD)
• B.12 ドメイン: システムセキュリティ
• B.13 ドメイン: ウイルス対策／マルウェア対策
• B.14 ドメイン: 安全なソフトウェア開発ライフサイクル（SDLC）
• B.15ドメイン: アクセス制御
• B.16 ドメイン: サイバー脅威管理
• B.17 ドメイン: サードパーティリスクと監督
• B.18 ドメイン: 脆弱性評価
• B.19 ドメイン: 物理／環境セキュリティ
• B.20 ドメイン: ネットワークセキュリティ
• B.21 ドメイン: インシデント対応
• B.22 ドメイン: 事業継続／災害復旧

サイバートラストのOTセキュリティ管理策は、ガバナンス、リスクマネジメント、戦略、技術的制御、インシデント対応、事業継続を網羅している。特に、OTの安全性と可用性の優先、レガシーシステムのリスク、OT特有のプロトコルへの対応を強調している。そして、CISOの明確化と経営層の関与を促し、ITとOTのポリシー統合、部門間の連携強化、脅威に応じた技術的制御（セグメンテーション、OT向けIDS/IPS等）、OT固有のシナリオを含む演習によるサイバーレジリエンスの確保を求めている。

---

【サイバートラスト】B.1 ドメイン: ガバナンス

B.1.4 組織は、サイバーセキュリティプログラムの実装を監督し、組織内のサイバーセキュリティリスクを管理する責任者（例：最高情報セキュリティ責任者〈CISO〉）が誰であるかを明確にするために、役割と責任を定義し、割り当てている。
【OTセキュリティ固有の管理策】
・OTセキュリティが経営陣の関心を得られるよう、組織はITおよびOTセキュリティの両方を監督し、全体的な責任を担う上級管理職のメンバーを特定している。
【フォーカス領域】

・役割と責任の定義

B.1.5 取締役会および／または上級管理職は、サイバーセキュリティに関する十分な専門知識を有しており、サイバーセキュリティ戦略、方針、手順、ならびにリスク管理の実装を承認し、監督する役割を担っている。
【OTセキュリティ固有の管理策】
・取締役会および／または上級管理職は、OTに特有のリスク（例：サイバーセキュリティを十分にサポートできない可能性のあるレガシーOTシステムの継続運用）に関連する影響を考慮した適切な経営判断を下すために、OTセキュリティに関する十分な専門知識を有しているべきである。。
【フォーカス領域】

・取締役会および／または上級管理職の関与

B.1.7 取締役会および／または上級管理職は、サイバーセキュリティに関する取り組みや活動について定期的に議論し、サイバーセキュリティリスクを監督・監視するための専任のサイバーセキュリティ委員会／フォーラムを設置しており、組織のサイバーセキュリティ方針、手順、法規制の要求事項への準拠を確保している。
【OTセキュリティ固有の管理策】
・サイバーセキュリティ委員会／フォーラムは、OTセキュリティの最新のプラクティスに関する情報を常に把握するための施策を実装しており、例えばOTの特別研究会への参加などが含まれる。
【フォーカス領域】
・サイバーセキュリティ委員会／フォーラムの設置

---

【サイバートラスト】B.2 ドメイン: ポリシーと手順

B.2.3 組織は、サイバーセキュリティリスクの管理に採用しているプロセス、業界のベストプラクティスや標準、そして情報資産を保護するための対策について、従業員に定期的に伝達・更新するためのプラクティスを実装している。
【OTセキュリティ固有の管理策】
・組織内のOTおよびITセキュリティ運用が交差する領域において、OTとITのチームがそれぞれ独立して運用されている可能性があるため、そのギャップを埋めるために、組織は部門横断的またはチーム横断的なコミュニケーションの取り組みを実装している。
【フォーカス領域】

・サイバーセキュリティに関する指針や要求事項を従業員に定期的に伝達すること

B.2.4 組織は、サイバーセキュリティリスクを管理し、自身の環境における情報資産を保護するために、関連する要求事項、指針、方針を取り入れたポリシーおよび手順を策定・実装しており、従業員が明確な指針と方向性を持てるようにしている。
【OTセキュリティ固有の管理策】
・組織は、OT環境の安全な利用のためのポリシーおよび手順を策定・実装しており、OTとIT環境の違いを考慮しつつ、それらをITのポリシーおよび手順と統合している。
【フォーカス領域】
・ポリシーおよび手順の策定

---

【サイバートラスト】B.3 ドメイン: リスクマネジメント

B.3.1　組織は、環境内のサイバーセキュリティリスクを特定しており、オンプレミスのリスクに加え、該当する場合にはリモート環境におけるリスクも含めて、特定されたすべてのサイバーセキュリティリスクに対処できるようにしている。
【OTセキュリティ固有の管理策】
・組織は、OT特有のリスクを考慮に入れており、業界に影響を与えたインシデントに基づく業種固有のリスクも含めている。
【フォーカス領域】

・リスクの特定と是正対応

B.3.6 組織は、特定されたリスクとその優先度、対応計画、タイムライン、追跡および監視の担当従業員を含むサイバーセキュリティリスク登録簿を策定・実装・維持している。
【OTセキュリティ固有の管理策】
・リスク登録簿には、OT環境の特性により軽減が困難なOTセキュリティリスクを記録する必要がある。たとえば、安全でないまたは旧式のプロトコル、サポートが終了したシステム、保守スケジュールによる更新の遅延などが該当する。
【フォーカス領域】

・サイバーセキュリティリスク登録簿の策定

B.3.9 組織は、取締役会および／または経営陣によって承認されたサイバーセキュリティリスクの許容度およびリスク許容声明を策定しており、受容可能なサイバーセキュリティリスクの種類と水準について、組織内で合意が得られていることを確保している。
【OTセキュリティ固有の管理策】
・重大または重要なOTセキュリティリスク（例：サイバーセキュリティを十分にサポートできないレガシーOTシステムの継続的な導入）が軽減できない場合には、そのトレードオフおよび適切な補完的管理策の活用について、取締役会および／または経営陣に報告し、承認を得る必要がある。
【フォーカス領域】
・サイバーセキュリティリスクの許容度および許容範囲の策定

---

【サイバートラスト】B.4ドメイン: サイバー戦略

B.4.5 組織は、サイバーレジリエンスを確保し、人材・プロセス・技術の観点からサイバーセキュリティ脅威に対抗するためのサイバーセキュリティ戦略を策定している。この戦略は、計画された目標を一定期間内に達成するためのロードマップへと具体化されている。
【OTセキュリティ固有の管理策】
・サイバーセキュリティ戦略およびロードマップでは、以下の要素が考慮されている:
–OTシステムにおけるサイバーセキュリティ目標（安全性、信頼性、物理的なシステムおよびプロセスへの重点など）
–OT資産の長期ライフサイクル
–組織のOTに関する運用モデル（例：内製、外部委託、マネージドセキュリティサービスの利用など）
【フォーカス領域】

・サイバーセキュリティ戦略とロードマップ

B.4.9 組織は、事業目標との整合性を確保し、変化するサイバー脅威の状況を考慮するために、サイバーセキュリティ戦略、ロードマップおよび作業計画を少なくとも年に一度見直し、更新している。
【OTセキュリティ固有の管理策】
・組織はまた、OT（制御技術）への敵対的関心が高まっているというOTの脅威状況も考慮に入れている。
【フォーカス領域】
・サイバーセキュリティ戦略、ロードマップおよび作業計画の更新

---

【サイバートラスト】B.5 ドメイン: コンプライアンス

B.5.1 組織は、自社の事業領域に適用されるサイバーセキュリティ関連の法律、規制、および（業界特有の）ガイドラインを特定し、それらに準拠するための対応を行っている。
【OTセキュリティ固有の管理策】
・関連する法律、規制およびガイドラインを特定するにあたり、組織は適用される安全に関する法律、規制およびガイドラインも考慮している。
【フォーカス領域】
・サイバーセキュリティ関連の法律および規制の領域の特定

---

【サイバートラスト】B.6 ドメイン: 監査

B.6.6 組織は、OT環境における制約により十分なサイバーセキュリティ対策の実装が困難な場合（例：時間的制約により暗号化の使用が難しい、OT運用への影響により脆弱性修正のためのソフトウェア更新が困難など）、監査結果への対応およびリスク軽減のために、適切な代替管理策を策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、OT環境における制約により十分なサイバーセキュリティ対策の実装が困難な場合（例：時間的制約により暗号化の使用が難しい、OT運用への影響により脆弱性修正のためのソフトウェア更新が困難など）、監査結果への対応およびリスク軽減のために、適切な代替管理策を策定・実装している。
【フォーカス領域】
・監査結果への対応

---

【サイバートラスト】B.7 ドメイン: トレーニングと認識

B.7.6 その組織は、研修の種類、頻度、参加者の要求事項、および研修の実装・参加手順に関する方針と手続きを策定・実装しており、それらが確実に遵守されるようにしている。
【OTセキュリティ固有の管理策】
・組織は、ITチームとOTチームのクロスドメイン研修を導入しており、統合されたIT／OT環境に備えるためのスキルを習得させている。
【フォーカス領域】
・サイバーセキュリティ意識向上および研修に関するポリシーと手順の策定

---

【サイバートラスト】B.8 ドメイン: 資産管理

B.8.4 組織は、ハードウェアおよびソフトウェアを機密性および/または機微度レベルに従って分類および処理するプロセスを確立し、実装している。これにより、それらが適切なセキュリティと保護を受けることを保証する。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織はそれらを考慮した分類および取り扱いのプロセス（例：セキュリティレベル）を策定・実装している。
【フォーカス領域】

・高度に機密性の高い資産の取り扱いに関する対策

B.8.9 組織は、ハードウェアおよびソフトウェア資産を追跡して管理するために、適切な、業界で認識されている資産インベントリ管理システムの使用を確立し、実装している。これにより、正確性を確保し、見落としを避けることができる。
【OTセキュリティ固有の管理策】
・組織の資産インベントリ管理システムには、OT資産を追跡・管理する機能が備わっている。
【フォーカス領域】
・資産インベントリ管理システム

---

【サイバートラスト】B.9 ドメイン: データ保護とプライバシー

B.9.3 暗号化を使用している組織は、推奨されるプロトコルやアルゴリズム、最小鍵長の使用に関するプロセスを定義し、適用しており、安全性が確保され、業界のベストプラクティスと整合していることを保証している。
【OTセキュリティ固有の管理策】
・暗号化を実装した結果、OTの運用や安全性に悪影響を及ぼすような遅延が発生する場合には、組織は合理的な代替管理策を策定・実装している。
【フォーカス領域】

・暗号アルゴリズムおよび鍵長を業界のベストプラクティスに整合させること

B.9.5 組織は、リスク分類を行い、機密性および機微度レベルに従ってビジネスに重要なデータ（個人データ、企業秘密、知的財産など）を取り扱うためのポリシーおよび手順を確立し、実装している。これにより、データが適切なセキュリティおよび保護を受けることを保証する。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織はそれらを考慮した分類および取り扱いに関するポリシーと手順を策定・実装している。
OTデータの例としては、コントローラーの設定ファイル、プログラマブルロジックコントローラー（PLC）のプログラムコード、CAD/CAM（コンピュータ支援設計／製造）ファイルなどが挙げられる。
【フォーカス領域】

・高度に機密性の高い資産の取り扱いに関する対策

B.9.6 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産を含む）が、組織内の情報システムやプログラムを通じてどのように流れるかを文書化するためのデータフロー図に関するポリシーと手順を策定・実装しており、これらのデータが組織の環境内に留まるよう、適切な管理措置も実装している。
【OTセキュリティ固有の管理策】
・組織のOT向けデータフロー図には、OT環境における想定される運用上のデータの流れが含まれており、以下の内容が示されている:
–ネットワーク境界を越えるデータフロー（論理セグメントまたは物理セグメント間の通信経路を含む）
–安全でないプロトコルを通じたデータフローの事例
【フォーカス領域】

・データフロー図の作成

B.9.11 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産など）を組織内で通信・保存・転送する際に、認可されたデバイスのみが安全なプロトコルを用いて行えるようにするためのポリシーと手順を策定・実装している。
【OTセキュリティ固有の管理策】
・OT環境において、認可されたデバイスが安全でないプロトコルを使用している場合には、組織は合理的な代替管理策を策定・実装している。
【フォーカス領域】
・暗号鍵のライフサイクル管理

---

【サイバートラスト】B.10 ドメイン: バックアップ

B.10.3 組織は、バックアップ作業が確実に実行され、人の介入なしに行えるよう、自動化されたバックアッププロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・自動バックアップが適切でない、または推奨されない状況（例：OTの運用や安全性に悪影響を及ぼす場合）において、組織は定期的なスケジュールに基づく手動バックアップの実装を策定・実装している。
【フォーカス領域】

・自動化されたバックアップの利用

B.10.4 組織は、業務上重要なデータをバックアップするために取るべき手順を明確にするため、バックアップの種類、頻度、保存方法に関する計画を策定・実装している。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が優先されるため、組織は重要なOTデータ（プログラムやデバイスの設定などを含む可能性がある）に対してイミュータブルストレージ（不可変ストレージ）の活用を検討している。このようなストレージは以下の利点を提供する:
–読み取り専用形式で保存することによるデータ完全性の強化
–保守用ワークステーションで読み取り専用ドライブとして使用することで、新たなソフトウェアのインストールに対する追加的な保護
【フォーカス領域】
・バックアップ計画の策定

---

【サイバートラスト】B.12 ドメイン: システムセキュリティ

B.12.5 組織は、各種ログを安全に保存・分類するためのログ管理プロセスを定義・運用しており、効果的なトラブルシューティングに活用できるようにしている。
【OTセキュリティ固有の管理策】
・OT機器にはディスク容量やメモリに制限がある可能性があるため、組織は以下の対策を実施している:
–機器の容量超過やログ記録機能の喪失を防ぐための、十分なローカルまたはリモートストレージの確保
–OT機器から代替ストレージへログを安全に転送・保存するための仕組みの導入
【フォーカス領域】

・ログ管理プロセスの実装

B.12.6 組織は、アップデートやパッチを安全にテスト・適用するためのパッチ管理プロセスを定義・運用しており、悪影響が生じないようにしている。
【OTセキュリティ固有の管理策】
・パッチ管理プロセスでは、OTサブシステムやネットワークセグメントごとに異なる可用性要求事項や、パッチ適用に対する対応能力の違いを考慮しており、組織は対応すべき主要な脆弱性を追跡している。
【フォーカス領域】

・パッチ管理プロセスの実装

B.12.11 組織は、システムの構成を望ましくかつ一貫した状態に維持するために、業界で認知され、適切とされる構成管理ツール／ソリューションを導入・運用している。
【OTセキュリティ固有の管理策】
・組織は、可能な範囲でOTの構成情報を管理できる構成管理ツール／ソリューションを導入・運用している。
【フォーカス領域】

・構成管理ツール／ソリューションの実装

B.12.12 組織は、システムの構成要求事項が業界のベンチマークや標準に整合するよう、ポリシーおよび手順を策定・実装している。
※補足：システム構成のベンチマークを提供している組織の一例として、Center for Internet Security（CIS）が挙げられる。
【OTセキュリティ固有の管理策】
・特殊なOTシステムに関して、組織はOTベンダーやサービスプロバイダーから構成要求事項を取得している。
【フォーカス領域】
・システム構成ベンチマークの策定

---

【サイバートラスト】B.13 ドメイン: ウイルス対策／マルウェア対策

B.13.6 組織は、出所不明のコードやアプリケーションを業務環境で使用する前に、ウイルスおよび／またはマルウェアの有無を検査するため、隔離されたテスト環境内で実行するプロセスを定義し、適用している。
【OTセキュリティ固有の管理策】
・組織は、出所不明のコードやアプリケーションがOT環境に導入されないようなプロセスを実装している。
認可されたベンダーから新しいアップデートが提供され、かつ組織に冗長機器や予備システムがなくテストが困難な場合には、ベンダーのテスト環境での検証を行うか、定期保守期間やダウンタイム中に自社環境でテストを実施する体制を整えている。
【フォーカス領域】

・コードやアプリケーションの隔離

B.13.8 組織は、外部機関からの脅威インテリジェンスに加入し、ウイルスやマルウェア攻撃を含むサイバー攻撃に関する情報の共有および検証を行うためのポリシーとプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、OT特有の脅威に対する可視性を維持するための方針およびプロセスを策定・実装しており、自組織または関連業界向けに特化されたOT向け脅威インテリジェンスへの加入や、OT関連の専門グループ等への参加を通じて、新たな脅威や脆弱性に関する早期警戒や助言を受けられる体制を整えている。
【フォーカス領域】
・脅威インテリジェンスの利用

---

【サイバートラスト】B.14 ドメイン: 安全なソフトウェア開発ライフサイクル（SDLC）

B.14.4 組織は、ソフトウェア開発ライフサイクル（SDLC）を管理するために、サイバーセキュリティ対策および要求事項を組み込んだSDLCフレームワークを策定・実装しており、これによりデータの完全性、認証、認可、責任追跡、例外処理などの領域に対応できる体制を整えている。
【OTセキュリティ固有の管理策】
・組織は、OT環境に適したSDLCフレームワークを導入・運用しており、以下の要素が含まれている:
–セキュリティ管理
–セキュリティ要求事項の明確化
–セキュリティ・バイ・デザインの実践
–安全な実装
–セキュリティ要求事項に基づくテスト
–セキュリティアップデートの管理
–セキュリティガイドライン
【フォーカス領域】
・セキュアなSDLCフレームワークの策定

---

【サイバートラスト】B.15ドメイン: アクセス制御

B.15.6 組織は、機密情報および／または業務上重要なデータへのアクセス、ならびに特権アクセスを適切に管理・制限するために、要求事項・ガイドライン・具体的な手順を明記したセキュアなログオンポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・組織は、従業員の認証情報が漏えいした場合に、コーポレートITネットワークからOT環境へのラテラルムーブメント（水平移動）を防止するため、OTおよびIT（またはコーポレート）ネットワークの両方にアクセスする従業員に対して、認証メカニズムおよび／または認証情報を分離して実装している。
・OTにおいては、安全性と可用性が最優先されるため、組織はセキュアなログオンポリシーおよび手順に伴う潜在的な遅延が、緊急時におけるOT担当者のアクセスを妨げないよう配慮している。
【フォーカス領域】

・安全なログオンポリシーおよび手順

B.15.7 組織は、強固なパスフレーズの定義に関する指針を提供するために、パスフレーズの設定およびアップデートに関する要求事項・ガイドライン・具体的な手順を明記したパスフレーズポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・このポリシーおよび手順では、以下のようなOT資産に関する制約と、それに対応する代替的な管理策（補完的統制）が明記されている:
–初期設定のパスワードが変更できない場合
–セキュアなパスワードやパスフレーズがサポートされていない場合
–レガシープロトコルの影響で、パスワードやパスフレーズが平文で送信される場合
–パスワードの使用が推奨されない場合
–その他の制約や制限が存在する場合
【フォーカス領域】

・パスフレーズポリシーおよび手順

B.15.11 組織は、ユーザーの認証および役割に基づくアクセスの承認を行うために、業界で適切かつ認知された特権アクセス管理ソリューションを策定・実装しており、より効率的かつ効果的なアクセス管理を実現している。
【OTセキュリティ固有の管理策】
・組織は、特権アクセス認証情報が漏えいした場合に、コーポレートITネットワークからOT環境へのラテラルムーブメント（水平移動）を防止するため、OT環境とIT環境それぞれに対して特権アクセス管理ソリューションを分離して導入・運用している。

---

【サイバートラスト】B.16 ドメイン: サイバー脅威管理

B.16.5 組織は、システムのログ監視およびレビュー、インシデントの調査、関係者への報告を実施するための役割と責任を定義し、割り当てている。
【OTセキュリティ固有の管理策】
・組織は、OTおよびITのセキュリティ運用が統合されつつある状況を踏まえ、両者がそれぞれ独立して運用される可能性があることを考慮し、OTおよびITのログ監視・レビュー、インシデントの調査および報告を行うための役割と責任を割り当てている。
【フォーカス領域】

・ログ監視に関する役割と責任

B.16.6 組織は、ログを中央で保管・相関分析し、より効果的なログ監視を実現するために、セキュリティ情報イベント管理（SIEM）を実装している。
【OTセキュリティ固有の管理策】
・SIEMソリューションによるアクティブスキャンがOT環境において適切でない、または推奨されない状況では、組織は以下の対応を行っている:
–パッシブスキャンの実施
–計画されたメンテナンス期間やダウンタイム中にアクティブスキャンを実施
【フォーカス領域】

・セキュリティ情報イベント管理（SIEM）の実装

B.16.7 組織は、システム上で異常を特定できるように分析および監視を行うためのセキュリティベースラインプロファイルを策定・実装している。
【OTセキュリティ固有の管理策】
・OT環境には決定論的な特性があり、OTの活動やトラフィックは予測可能かつ反復的である傾向があることを踏まえ、組織は通常の人間の行動およびOTプロセスの挙動を考慮したネットワークトラフィックおよびデータフローのベースラインを確立している。これにより、通常または一時的な状態と異常を区別し、誤検知（フォールスポジティブ）アラートの最小化を図っている。
【フォーカス領域】

・セキュリティベースラインプロファイルの確立

B.16.8 組織は、異常または不審なログを検出した際に、それらを迅速に調査・報告・是正するための要求事項、ガイドライン、および具体的な手順を明記したポリシーおよび手順を策定・実装している。
【OTセキュリティ固有の管理策】
・OTにおいては、安全性と可用性が最優先であるため、組織のポリシーおよび手順では、対応の優先順位（例：フォレンジックデータの保全や調査よりも、OTの運用を正常状態に復旧すること）を明示している。
【フォーカス領域】

・異常または不審なログを検出した際のポリシーおよび手順

B.16.11 組織は、IT環境内に潜む脅威を積極的に探索するための対策およびプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・これには、OT環境や、組織自身の業界および隣接する業界を標的とする潜在的な脅威に対する脅威ハンティングも含まれる。
【フォーカス領域】
・積極的な脅威ハンティング

---

【サイバートラスト】B.17 ドメイン: サードパーティリスクと監督

B.17.4 組織は、サードパーティに対して最低限のサイバーセキュリティ要求事項が定義されていることを確保し、サードパーティが自らのセキュリティ上の責務を認識するよう周知するとともに、システムおよびデータのセキュリティが確保されるよう対策を策定・実装している。
【OTセキュリティ固有の管理策】
・これには、OTサプライチェーンへの依存度が高い状況、たとえばOTベンダーに関して、組織がサードパーティの運用を見直すことも含まれている:
–サードパーティが提供する製品、サービス、またはシステムのサイバーセキュリティ体制
–組織のOTシステムに対して、ソフトウェアのアップグレードやパッチの提供、統合サービスの実施、運用・保守の支援を行う際のサードパーティのサイバーセキュリティ運用
【フォーカス領域】

・サードパーティのセキュリティ責務

B.17.5 組織は、サードパーティと契約を締結する前やオンボーディングの段階で、提供されるサービスの種類に応じたリスクに基づき、必要なセキュリティ義務をすべて満たしていることを確認するための評価措置を策定・実装している。
【OTセキュリティ固有の管理策】
・これには、プロジェクトのリスクレベルに基づき、サードパーティが満たすべき最低限のサイバーセキュリティ要求事項の評価が含まれている。
【フォーカス領域】
・サードパーティの関与時に実施するセキュリティ評価

---

【サイバートラスト】B.18 ドメイン: 脆弱性評価

B.18.3 組織は、自身のシステムに対して脆弱性評価をレビュー・実施するために、目的、範囲、要求事項を定めた脆弱性評価計画を策定している。
【OTセキュリティ固有の管理策】
・脆弱性評価計画には、各OTサブシステム、ネットワークセグメント、および／またはゾーン内の脅威と脆弱性の特定および評価が含まれている。
【フォーカス領域】

・脆弱性評価計画の策定

B.18.4 組織は、少なくとも年に一度、システムに対して非侵入型のスキャンを実施し、脆弱性を発見するための定期的な脆弱性評価を行っている。
【OTセキュリティ固有の管理策】
・脆弱性評価を実施する際、リアルタイムのOT運用に影響を与える可能性があるアクティブスキャンについて、組織はOTシステムに干渉しないパッシブスキャンや監視ツールの活用を検討している。
・アクティブスキャンを実施する場合には、脆弱性評価計画の中に、事前のテストを行うプロセスや、スキャンを計画されたメンテナンス期間またはダウンタイム中に実施する手順を含めている。
【フォーカス領域】

・定期的な脆弱性評価の実装

B.18.7 組織は、評価によって明らかになった脆弱性について、その重大度に応じて適切に是正されるよう、追跡、レビュー、評価、および対応のための対策とプロセスを策定・実装している。
【OTセキュリティ固有の管理策】
・脆弱性を速やかに緩和できない状況（例：レガシーなOT機器や、ソフトウェアパッチが提供されていないシステム）において、組織はこれらの脆弱性に対応するための代替的な管理策（補完的対策）を実施している。
【フォーカス領域】

・特定された脆弱性の追跡と是正

B.18.8　組織は、ペネトレーションテスト（侵入テスト）を安全に実施できるように、目的、範囲、および実施ルールを定めたテスト計画を策定・実装している。
【OTセキュリティ固有の管理策】
・組織のOT環境におけるペネトレーションテスト計画には、以下の内容が含まれている:
–OTシステムはタイミング制約に敏感だったり、リソースが限られていたりする場合があるため、テストによってOT機能に悪影響を及ぼさないようにするための対策を実施していること
–必要に応じて、複製された環境、仮想化された環境、またはシミュレーション環境を用いてペネトレーションテストを実施するなど、代替的な管理策を考慮していること
–テストの実施にあたって、必要に応じて本番OT環境を計画されたメンテナンス期間やダウンタイム中にオフラインにする必要性を考慮していること
【フォーカス領域】
・ペネトレーションテスト計画の策定

---

【サイバートラスト】B.19 物理／環境セキュリティ

B.19.2 組織は、自らの環境における物理的・環境的リスクを特定し、脅威に迅速に対応できるようにするための検知手段を実装している。
【OTセキュリティ固有の管理策】
・例としては、以下が含まれる:
–OT環境への許可されていない人物による物理的アクセス
–自然災害や停電によって組織のサイバーセキュリティ対策が妨げられ、OT環境がサイバーセキュリティインシデントに対して脆弱になること
【フォーカス領域】

・検知的統制の確立

B.19.3 組織は、内部および外部の脅威から物理的資産を保護するための対策を講じており、例えば盗難や改ざんを防ぐためにケーブルロックを使用している。
【OTセキュリティ固有の管理策】
・論理的および／または物理的なセグメンテーションが、リスクや重要度、セキュリティ要求事項に基づいてOT資産を分類・隔離するために用いられていることから、組織はOTのサブシステムやネットワークセグメントを隔離するための物理的統制を実施している。例えば、OT資産を収納するために施錠されたキャビネットや部屋を使用することなどが挙げられる。
【フォーカス領域】
・内部および外部の脅威に対する保護

---

【サイバートラスト】B.20 ドメイン: ネットワークセキュリティ

B.20.3 組織は、基本的なパケットフィルタリング型ファイアウォールよりも高度なコンテキストに基づいてパケットをフィルタリングできるよう、ステートフルファイアウォールの使用を確立し、実装している。これにより、より高い効果でセキュリティを確保している。
【OTセキュリティ固有の管理策】
・組織は、OT環境向けに特化して設計された、またはOT環境に合わせて調整されたファイアウォールを実装しており、一般的なOTプロトコルに対応している。これにより、論理的または物理的なセグメント間のOTネットワーク、ならびにIT環境やインターネットに接続されるOTネットワークの保護が可能となっている。
【フォーカス領域】

・ステートフルファイアウォールの実装

B.20.5 組織は、有線および無線ネットワークの両方を安全に構成するためのプロセスを定義し、実装している。これには、少なくとも安全なネットワーク認証と暗号化プロトコルの使用、およびWPS(Wi-Fi Protected Setup)の無効化が含まれており、ネットワークの安全性を確保し、データの損失や漏えいを防止している。
【OTセキュリティ固有の管理策】
・OTの通信やネットワークの保護が適切でない、または推奨されない状況（例：OTの運用や安全性に悪影響を及ぼす場合）において、組織は代替的な管理策を実施している。
例としては:
–安全なネットワーク認証や暗号化プロトコルが実装できない場合、MAC（メディアアクセス制御）アドレスフィルタリングなどの対策を講じる
–レガシーなOT機器が安全でない無線接続しか対応していない場合、物理的な制御（例：無線ネットワークのカバレッジ範囲を安全な物理エリア内に限定する）を用いる
【フォーカス領域】

・ネットワークセキュリティの実装

B.20.6 組織は、ネットワークをプライベートネットワークとパブリックネットワークに分離するためのネットワークセグメンテーションのプロセスを定義し、実装している。プライベートネットワークには業務上重要なデータが保持されており、インターネットとは接続されていないことで、外部の脅威から隔離された状態が確保されている。
【OTセキュリティ固有の管理策】
・組織は、以下の目的のために（物理的セグメンテーションを含む）セグメンテーションを実装している:
–セキュリティ要求事項、リスク、重要度に基づいて、セグメント間の通信および情報の流れを制限・管理すること
–セキュリティ上の脆弱性を抱えるOTのレガシーシステムを保護し、他のセグメントやインターネットから拡散する脅威から隔離すること
【フォーカス領域】

・ネットワークセグメンテーションの実装

B.20.9 組織は、悪意のあるネットワークトラフィックを監視・検出するためにネットワーク侵入検知を確立し、実装している。これにより、脅威を迅速に特定し、対処できる体制が整えられている。
【OTセキュリティ固有の管理策】
・OTネットワークにおけるネットワーク侵入検知について、組織はOT向けに特化または調整されたネットワーク侵入検知ソリューションを確立し、実装している。これには、Modbus TCP、Distributed Network Protocol 3（DNP3）、Inter-Control Center Communications Protocol（ICCP）など、一般的なOTプロトコルに対応した攻撃シグネチャが組み込まれている。
・OT環境において非IPベースのプロトコルやコントローラベースのオペレーティングシステムに対応したネットワーク侵入検知ソリューションが利用できない場合には、組織は補完的な管理策（例：異常検知システム）を検討している。
【フォーカス領域】

・ネットワーク侵入検知の実装

B.20.11 組織は、悪意のあるネットワークトラフィックを遮断し、脅威から保護するためにネットワーク侵入防止を確立し、実装している。
【OTセキュリティ固有の管理策】
・OTネットワークにおけるネットワーク侵入防止について、組織はOT向けに特化または調整されたネットワーク侵入防止ソリューションを確立し、実装している:
・ネットワーク侵入防止システムに伴う自動応答がOT環境に影響を及ぼす可能性がある場合（例：誤検知による影響）、組織は適切な緩和策を講じている。たとえば、ネットワーク侵入防止システムをOTネットワーク内のDMZ（非武装地帯）インターフェースなど、より上位のレベルに配置することで対応している。
【フォーカス領域】
・ネットワーク侵入防止の実装

---

【サイバートラスト】B.21 ドメイン: インシデント対応

B.21.3 組織は、サイバーセキュリティインシデント対応計画に関与する従業員と迅速に連絡が取れるように、連絡先情報の確認手段を定義し、適用している。
通常関与する機能別グループには以下が含まれる:
–経営陣
–インシデント対応チームまたはサイバーセキュリティチーム
–法務チーム
–広報・コミュニケーションチーム
【OTセキュリティ固有の管理策】
・OTのインシデント管理においては、以下のような他の機能部門が関与する場合がある:
–OT業務に関与するIT担当者
–OT担当者
–セキュリティ担当者および安全管理担当者
【フォーカス領域】

・インシデント対応に関与する担当者の連絡可能性の確認

B.21.4 組織は、関係者がインシデント発生時に何をすべきかを理解し、十分に備えられるようにするため、サイバー演習を実施するプロセスを定義し、適用している。
【OTセキュリティ固有の管理策】
・組織は、これらのサイバー演習にOT特有のシナリオを含めている。
・OTの顧客とOTのサプライチェーン（例：OTベンダー）との間に強い依存関係や接点がある場合には、これらの演習にOTサプライチェーン上の主要な外部関係者も参加させている。
【フォーカス領域】

・サイバー演習の実施

B.21.6 組織は、インシデントを調査して証拠を収集し、根本原因を特定できるようにするための要求事項、指針、具体的な手順を明記したポリシーおよび手順を定義し、確立している。
【OTセキュリティ固有の管理策】
・組織は、OT特有のインシデント対応を全社的なインシデント対応計画に統合している。
・策定されたポリシーおよび手順には、必要な対応措置とそれがOT業務に与える影響の評価が含まれている。例えば、侵害されたシステムの物理的な隔離はOT業務に悪影響を及ぼす可能性があり、運用パフォーマンスや安全性の低下を招くことがある。
【フォーカス領域】
・インシデント調査のためのポリシーおよび手順の策定

---

【サイバートラスト】B.22 ドメイン: 事業継続／災害復旧

B.22.2 組織は、高可用性が求められる重要資産を特定し、それらに対して冗長性を確保するための対策を実装している。
【OTセキュリティ固有の管理策】
・組織は、サイバーセキュリティインシデント発生時に制限された運用や縮小された運用を維持するために必要な重要な接続性および資産を特定している。
また、容易に入手できないOTコンポーネントに対しては、冗長性や代替品を確保するための措置を講じている。
【フォーカス領域】

・高可用性が求められる重要資産の特定

B.22.5 組織は、事業継続／災害復旧に関するポリシーを確立し、実装している。このポリシーには、システムの重要度に応じて事業再開を実施できるようにするための要求事項、役割と責任、指針（RTOおよびRPOを含む）が明記されている。
【OTセキュリティ固有の管理策】
・復旧活動の優先順位を決定する際、組織はリスク評価を考慮し、運用上の依存関係を持つOT機器の起動活動に対して適切な順序を策定している。
【フォーカス領域】

・事業継続／災害復旧ポリシーの確立

B.22.6 組織は、サイバーセキュリティインシデントを含む一般的な業務中断シナリオに対応・復旧するための事業継続／災害復旧計画を確立し、実装している。これにより、サイバーレジリエンスの確保を図っていまる。
【OTセキュリティ固有の管理策】
・組織は、復旧活動の優先順位を決定している。例えば、OTシステムよりも先に重要なインフラを支えるシステムを復旧するなどである。
・組織の事業継続／災害復旧計画は、電子形式と紙形式の両方で文書化され、すぐにアクセスできる状態で保管されなければならない。
【フォーカス領域】

・事業継続／災害復旧計画の策定

B.22.8 組織は、事業継続／災害復旧計画の目的達成に向けた有効性を確保するために、少なくとも年に一度は定期的に計画をテストするためのポリシーおよびプロセスを確立し、実施している。
【OTセキュリティ固有の管理策】
・運用上または安全上の理由により復旧計画のテストが困難な場合、組織はOT機器の復旧手順を確認するために、ラボでのテストやオフラインでのテストなどの代替手段を実施している。
【フォーカス領域】

・事業継続／災害復旧計画のテスト

B.22.10 組織は、プロセスおよび手順の有効性を評価するために、第三者と連携して一定期間にわたる事業継続／災害復旧演習を実施している。
【OTセキュリティ固有の管理策】
・OTの顧客とOTのサプライチェーン（例：OTベンダー）との間に強い依存関係や連携がある場合、これらの演習にはOTサプライチェーンにおける主要な外部関係者も参加している。
【フォーカス領域】
・事業継続／災害復旧演習の実施

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

前回は、シンガポールサイバーセキュリティ庁のスタートアップ／SMBを対象としたサイバーエッセンシャルズマークに基づいて開発された人工知能（AI）セキュリティ固有のガイドを紹介したが、今回は、大企業／インフラ系クラウドサービスプロバイダー（CSP）を対象としたサイバートラストマークのAIセキュリティ版ガイドを紹介する。

シンガポール政府が大企業／CSP向けAIセキュリティガイドラインを提供

シンガポールサイバーセキュリティ庁のサイバートラストマークとCSA STAR認証との間には、相互承認制度（MRA：Mutual Recognition Agreement）が確立されている。サイバートラストマークの各管理策項目に対応するCCM v4の管理策項目については、「CSA サイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4のクロスマッピング」で公開されている（https://isomer-user-content.by.gov.sg/36/2afb6128-5b9b-4e32-b151-5c6033b993f1/Cloud-Security-Companion-Guide-Cyber-Trust.pdf）。

以下では、サイバートラストマーク認証関連文書（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-for-organisations/cyber-trust/certification-for-the-cyber-trust-mark/）の1つとして公開されている「サイバートラスト(2025) マーク – 自己評価テンプレート」より、サイバートラストマークの各管理策項目におけるAIセキュリティ固有の管理策およびフォーカス領域を紹介する。

————————————————
【サイバートラスト】B.1 ドメイン: ガバナンス
————————————————
【サイバートラスト】
B.1.3 組織は、事業の文脈においてサイバーセキュリティの重要性を高めるためのプラクティスを確立・実装しており、従業員、顧客、パートナーなどのステークホルダー全員にその重要性を伝えている。
【AIセキュリティ固有の管理策】
・このようなプラクティスには、以下のようなメカニズムの確立が含まれる：
–組織が、自社のAIシステムに関する必要なセキュリティ情報をユーザーやその他の関係者に提供すること（例：組織内でのAIシステムの適正使用ポリシーなど）
–従業員や外部関係者が、組織内のAIシステムに関するセキュリティ上の懸念を報告できるようにすること。
【フォーカス領域】
・サイバーセキュリティの重要性の理解
————————————————
【サイバートラスト】
B.1.4 組織は、サイバーセキュリティプログラムの実装を監督し、組織内のサイバーセキュリティリスクを管理する責任者（例：最高情報セキュリティ責任者〈CISO〉）が誰であるかを明確にするために、役割と責任を定義し、割り当てている。
【AIセキュリティ固有の管理策】
・AIが倫理、法務、リスク管理など複数の組織機能にまたがる学際的な性質を持つことから、組織はAIセキュリティに関する役割と責任を定義し、適切に割り当てている。
【フォーカス領域】
・役割と責任の定義
————————————————
【サイバートラスト】
B.1.5 取締役会および／または上級管理職は、サイバーセキュリティに関する十分な専門知識を有しており、サイバーセキュリティ戦略、方針、手順、ならびにリスク管理の実装を承認し、監督する役割を担っている。
【AIセキュリティ固有の管理策】
・取締役会および／または上級管理職は、AIに特有のリスク（例：AIへの過度な依存）に関連する影響を考慮した適切な経営判断を下すために、AIセキュリティに関する十分な専門知識を有しているべきである。
【フォーカス領域】
・取締役会および／または上級管理職の関与
————————————————
【サイバートラスト】
B.1.6 組織は、サイバーセキュリティの目標／目的を策定しており、それらは少なくとも年に一度、取締役会および／または上級管理職によって見直し・承認され、方針や手順を通じて実装されている。
【AIセキュリティ固有の管理策】
・これには、AIシステムの安全な利用を導くための目的を特定し文書化すること、そしてそれらのシステムが意図された目的に沿って使用されることを確保することが含まれる。
【フォーカス領域】
・サイバーセキュリティ目標の達成
————————————————
【サイバートラスト】
B.1.7 取締役会および／または上級管理職は、サイバーセキュリティに関する取り組みや活動について定期的に議論し、サイバーセキュリティリスクを監督・監視するための専任のサイバーセキュリティ委員会／フォーラムを設置しており、組織のサイバーセキュリティ方針、手順、法規制の要求事項への準拠を確保している。
【AIセキュリティ固有の管理策】
・サイバーセキュリティ委員会／フォーラムは、急速に進化するAIセキュリティのプラクティスやガバナンスの動向を把握するための施策を実装しており、例えばAIの特別研究会への参加などが含まれる。
【フォーカス領域】
・サイバーセキュリティ委員会／フォーラムの設置

————————————————
【サイバートラスト】B.2 ドメイン: ポリシーと手順
————————————————
【サイバートラスト】
B.2.3 組織は、サイバーセキュリティリスクの管理に採用しているプロセス、業界のベストプラクティスや標準、そして情報資産を保護するための対策について、従業員に定期的に伝達・更新するためのプラクティスを実装している。
【AIセキュリティ固有の管理策】
・AIの学際的な性質により、AIセキュリティが組織内の他の機能領域と交差する場面において、組織は部門横断的またはチーム横断的なコミュニケーションの取り組みを実装している。
【フォーカス領域】
・サイバーセキュリティに関する指針や要求事項を従業員に定期的に伝達すること
————————————————
【サイバートラスト】
B.2.4 組織は、サイバーセキュリティリスクを管理し、自身の環境における情報資産を保護するために、関連する要求事項、指針、方針を取り入れたポリシーおよび手順を策定・実装しており、従業員が明確な指針と方向性を持てるようにしている。
【AIセキュリティ固有の管理策】
・組織は、AIシステムの安全な利用のためのポリシーおよび手順を策定・実装しており、それらを他の組織内のポリシーや手順（例：全社的リスク管理やサイバーセキュリティリスク管理）と統合している。
【フォーカス領域】
・ポリシーおよび手順の策定
————————————————
【サイバートラスト】
B.2.8 組織は、自身のサイバーセキュリティに関するポリシーおよび手順の遵守を確保するために、必要な対策を策定・実装している。
【AIセキュリティ固有の管理策】
・これには、AIシステムの安全な利用を確保するためのポリシーおよびプロセスが含まれており、組織のポリシーに従って、AIシステムの安全な利用に関するプロセスを定義し文書化することも含まれる。
【フォーカス領域】
・ポリシーおよび手順の遵守を確保するための対策の策定

————————————————
【サイバートラスト】B.3 ドメイン: リスクマネジメント
————————————————
【サイバートラスト】
B.3.1　組織は、環境内のサイバーセキュリティリスクを特定しており、オンプレミスのリスクに加え、該当する場合にはリモート環境におけるリスクも含めて、特定されたすべてのサイバーセキュリティリスクに対処できるようにしている。
【AIセキュリティ固有の管理策】
・組織は、以下を含むAI特有のリスクを考慮に入れている：
–悪意ある攻撃や従業員による意図しないデータ漏えいに起因するデータ漏えいのリスク
–データおよび／またはAIモデルの完全性が損なわれることによって、AIシステムから意図しない出力が生じるリスク（組織のAIシステムに対して適切な人間による監視を行うための仕組みも含む）
【フォーカス領域】
・リスクの特定と是正対応
————————————————
【サイバートラスト】
B.3.5 組織は、サイバーセキュリティリスクを特定し、依存関係を評価し、既存の対策を検証するためのリスク評価プロセスを定義・適用しており、サイバーセキュリティリスクの評価方法を明確にしている。
【AIセキュリティ固有の管理策】
・組織は、AIシステムに対するサイバーセキュリティリスク評価において、以下のような活用されているリソースを考慮し、文書化している:
–データ資産
–ソフトウェア資産
–システムおよび計算処理リソース
–従業員によるAIの利用
これにより、リスクと影響を十分に理解している。
【フォーカス領域】
・リスク評価プロセスの定義
————————————————
【サイバートラスト】
B.3.9 組織は、取締役会および／または経営陣によって承認されたサイバーセキュリティリスクの許容度およびリスク許容声明を策定しており、受容可能なサイバーセキュリティリスクの種類と水準について、組織内で合意が得られていることを確保している。
【AIセキュリティ固有の管理策】
・重大または重要なAIセキュリティリスク（例：AIの集中リスク、AIへの過度な依存）が軽減できない場合には、そのトレードオフおよび適切な緩和策について、取締役会および／または経営陣に報告し、承認を得る必要がある。
【フォーカス領域】
・サイバーセキュリティリスクの許容度および許容範囲の策定
————————————————
【サイバートラスト】
B.3.12 組織は、残留するサイバーセキュリティリスクが自社のリスク許容度および許容範囲内に収まるよう、逸脱を確認・評価するための方針およびプロセスを策定・実装している。
【AIセキュリティ固有の管理策】
・AIシステムを導入している組織では、逸脱を確認・評価するための方針およびプロセスに、意図した成果を達成する能力に影響を及ぼす可能性のあるデータやモデルのドリフトを監視する方法が含まれており、それによってAIリスクの曝露状況が変化する可能性がある。
【フォーカス領域】
・リスクレビュー

————————————————
【サイバートラスト】B.4ドメイン: サイバー戦略
————————————————
【サイバートラスト】
B.4.5 組織は、サイバーレジリエンスを確保し、人材・プロセス・技術の観点からサイバーセキュリティ脅威に対抗するためのサイバーセキュリティ戦略を策定している。この戦略は、計画された目標を一定期間内に達成するためのロードマップへと具体化されている。
【AIセキュリティ固有の管理策】
・サイバーセキュリティ戦略およびロードマップでは、組織のAIシステムの安全な利用を導くための目標が特定され、文書化されている
【フォーカス領域】
・サイバーセキュリティ戦略とロードマップ
————————————————
【サイバートラスト】
B.4.9 組織は、事業目標との整合性を確保し、変化するサイバー脅威の状況を考慮するために、サイバーセキュリティ戦略、ロードマップおよび作業計画を少なくとも年に一度見直し、更新している。
【AIセキュリティ固有の管理策】
・組織はまた、AIの導入が進む中で、AIに関連する脅威の状況も考慮に入れている。
【フォーカス領域】
・サイバーセキュリティ戦略、ロードマップおよび作業計画の更新

————————————————
【サイバートラスト】B.5 ドメイン: コンプライアンス
————————————————
【サイバートラスト】
B.5.1 組織は、自社の事業領域に適用されるサイバーセキュリティ関連の法律、規制、および（業界特有の）ガイドラインを特定し、それらに準拠するための対応を行っている。
【AIセキュリティ固有の管理策】
・関連する法律、規制およびガイドラインを特定するにあたり、組織は自社が事業を展開する国々におけるAI規制の新たな動向も考慮に入れている。
【フォーカス領域】
・サイバーセキュリティ関連の法律および規制の領域の特定

————————————————
【サイバートラスト】B.8 ドメイン: 資産管理
————————————————
【サイバートラスト】
B.8.3 組織は、環境内のハードウェアおよびソフトウェア資産を安全に分類・取り扱い・廃棄するためのセキュリティ要求事項、ガイドライン、および具体的な手順に関するポリシーと手順を策定・実装しており、従業員が明確な指針と指導を得られるようにしている。
【AIセキュリティ固有の管理策】
・AIに使用される、またはAIのために使用される組織のデータの分類、安全な取り扱いおよび削除に関して、組織はAIモデルおよびそれらの学習に使用されたトレーニングデータをポリシーと手順の中に含めている
【フォーカス領域】
・資産の取り扱いに関するポリシーおよび手順
————————————————
【サイバートラスト】
B.8.9 組織は、ハードウェアおよびソフトウェア資産を追跡して管理するために、適切な、業界で認識されている資産インベントリ管理システムの使用を確立し、実装している。これにより、正確性を確保し、見落としを避けることができる。
【AIセキュリティ固有の管理策】
・組織の資産インベントリ管理システムには、AIツール、サービス、またはシステムを追跡・管理する機能が備わっている
【フォーカス領域】
・資産インベントリ管理システム

————————————————
【サイバートラスト】B.9 ドメイン: データ保護とプライバシー
————————————————
【サイバートラスト】
B.9.5 組織は、リスク分類を行い、機密性および機微度レベルに従ってビジネスに重要なデータ（個人データ、企業秘密、知的財産など）を取り扱うためのポリシーおよび手順を確立し、実装している。これにより、データが適切なセキュリティおよび保護を受けることを保証する。
【AIセキュリティ固有の管理策】
・組織は、従業員が組織内のデータセットのうち、社内外のAIツールやサービス（例：生成系AI）で使用され得るものを識別できるように、分類および取り扱いに関するポリシーと手順を策定・実装している。
【フォーカス領域】
・高度に機密性の高い資産の取り扱いに関する対策
————————————————
【サイバートラスト】
B.9.6 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産を含む）が、組織内の情報システムやプログラムを通じてどのように流れるかを文書化するためのデータフロー図に関するポリシーと手順を策定・実装しており、これらのデータが組織の環境内に留まるよう、適切な管理措置も実装している。
【AIセキュリティ固有の管理策】
・組織のAI向けデータフロー図には、AIシステムに関連するデータの文書化が含まれており、以下の内容が示されている:
–AIシステムの学習に使用されたデータ（該当する場合）
–AIシステムへの入力データ（プロンプトなどを含む）
–AIシステムからの出力データ
【フォーカス領域】
・データフロー図の作成
————————————————
【サイバートラスト】
B.9.7 組織は、業務上重要なデータ（個人データ、企業秘密、知的財産など）を安全に取り扱い、分類や要求事項（収集、利用、保護、廃棄など）に応じて保護するためのポリシーと手順を策定・実装している。
【AIセキュリティ固有の管理策】
・組織は以下の項目について、安全な取り扱いを実装している:
–AIシステムへの入力データ
–データモデル（該当する場合）
–AIシステムからの出力データ
AIシステムへの入力データの安全な取り扱いの例には、以下の対策が含まれる:
–データの完全性
–データの来歴
–データの検証および／または無害化
–クエリインタフェースの保護（データへのアクセス、改ざん、持ち出しの試みを検知・緩和するためのガードレールやクエリのレート制限など）
AIモデルの安全な取り扱いの例には、以下の対策が含まれる
–ハッシュや署名によるモデルの検証
–導入前のAIシステムのセキュリティ評価（ベンチマーク、セキュリティテスト、レッドチームによる検証など）
AIシステムからの出力データの安全な取り扱いの例には、以下の対策が含まれる:
–出力データの完全性の検証
–利用者にとって有用な出力を生成しつつ、攻撃者に不要な情報を漏らさないようにすること
【フォーカス領域】
・データの安全な取り扱いに関するポリシーおよび手順
————————————————
【サイバートラスト】
B.9.10 組織はデータを保護するために暗号化を使用しており、暗号鍵管理ライフサイクル全体で鍵が安全に取り扱われることを保証するための暗号化ポリシーおよびプロセスを確立し、実装している。
【AIセキュリティ固有の管理策】
・機微なデータに対して、組織はデータ保護のために匿名化や差分プライバシー（該当する場合）などのプライバシー保護技術の活用を検討している。
【フォーカス領域】
・暗号ポリシーの策定

————————————————
【サイバートラスト】B.12 ドメイン: システムセキュリティ
————————————————
【サイバートラスト】
B.12.4 組織は、すべてのシステム、サーバー、オペレーティングシステム、およびネットワーク機器に対して安全な構成が適用されるよう、プロセスを定義し、運用している。
【AIセキュリティ固有の管理策】
・安全な構成管理の一環として、組織はAIモデルの複雑性および利用目的に対するモデルの適合性を考慮しており、複雑なモデルは追加のソフトウェアパッケージやライブラリを伴う可能性があるため、攻撃対象領域が拡大することを認識している。
【フォーカス領域】
・安全な構成を適用するためのプロセスの実装
————————————————
【サイバートラスト】
B.12.8 組織は、セキュリティ構成に関する要求事項、ガイドライン、および詳細な手順についての方針と手順を策定・実施しており、それらがセキュリティ基準に整合していることを確保している。
【AIセキュリティ固有の管理策】
・AIに対する安全な構成に関する組織のポリシーおよび手順には、ベストプラクティスが組み込まれている。
例としては以下が挙げられる:
–モデルのハードニング（強化）、例：敵対的学習の活用
–ガードレールの使用を含むプロンプトエンジニアリングのベストプラクティス
–AIシステムへのクエリ頻度の監視および制限
–攻撃耐性を高めるためのモデルアンサンブル（複数モデルの組み合わせ）の活用
【フォーカス領域】
・セキュリティ構成に関するポリシーおよび手順をセキュリティ基準に整合させること

————————————————
【サイバートラスト】B.13 ドメイン: ウイルス対策／マルウェア対策
————————————————
【サイバートラスト】
B.13.8 組織は、外部機関からの脅威インテリジェンスに加入し、ウイルスやマルウェア攻撃を含むサイバー攻撃に関する情報の共有および検証を行うためのポリシーとプロセスを策定・実装している。
【AIセキュリティ固有の管理策】
・組織は、AIを標的とする攻撃者など、AI特有の脅威に対する可視性を維持するためのポリシーおよびプロセスを策定・実装しており、AI関連の脅威情報への加入や、AIに関する専門グループ等への参加を通じて、新たな脅威や脆弱性に関する早期警戒や助言を受けられる体制を整えている。
【フォーカス領域】
・脅威インテリジェンスの利用

————————————————
【サイバートラスト】B.14 ドメイン: 安全なソフトウェア開発ライフサイクル（SDLC）
————————————————
【サイバートラスト】
B.14.3 組織は、システムおよび／またはアプリケーションの開発において、セキュリティガイドラインおよび要求事項を策定・実装している。
例としては以下が挙げられる:
–セキュアコーディングの実施
–APIキーの安全な管理
–オープンソースを含むサードパーティソフトウェアのセキュリティポスチャーの確認
–ベストプラクティスや標準規格への準拠
これらを通じて、セキュリティ原則の遵守を確保している。
※補足：シンガポールでは、Safe App Standard により、モバイルアプリ開発に必要なセキュリティ管理策やベストプラクティスに関する指針が提供されている。
【AIセキュリティ固有の管理策】
・これらのセキュリティガイドラインおよび要求事項は、組織のAIシステムのライフサイクル全体（すなわち、以下の各段階）にわたって策定・実施されている:
–設計
–開発
–デプロイ
–運用および保守
【フォーカス領域】
・安全なSDLCガイドラインおよび要求事項の策定
————————————————
【サイバートラスト】
B.14.4 組織は、ソフトウェア開発ライフサイクル（SDLC）を管理するために、サイバーセキュリティ対策および要求事項を組み込んだSDLCフレームワークを策定・実装しており、これによりデータの完全性、認証、認可、責任追跡、例外処理などの領域に対応できる体制を整えている。
【AIセキュリティ固有の管理策】
・組織は、AI（人工知能）に適したSDLC（ソフトウェア開発ライフサイクル）フレームワークを導入・運用しており、以下の要素が含まれている:
–セキュアな設計
–セキュアな開発
–セキュアなデプロイ
–セキュアな運用および保守
【フォーカス領域】
・セキュアなSDLCフレームワークの策定
————————————————
【サイバートラスト】
B.14.6 組織は、システムおよび／またはアプリケーションの展開前にセキュリティテストを実施し、セキュリティ上の弱点や脆弱性を特定するためのポリシーおよびプロセスを策定・実装している。
【AIセキュリティ固有の管理策】
・これには、組織のAIシステムに対するセキュリティテスト（例：敵対的テスト）が含まれている。
【フォーカス領域】
・安全なシステムおよび／またはアプリケーションの開発

————————————————
【サイバートラスト】B.16 ドメイン: サイバー脅威管理
————————————————
【サイバートラスト】
B.16.4 組織は、脅威や異常の検出を目的としてセキュリティログを監視するための要求事項、ガイドライン、および具体的な手順を明記したログ監視のポリシー、プロセスおよび手続きを策定・実装している。
【AIセキュリティ固有の管理策】
・ログ監視に関するポリシー、プロセスおよび手順には、以下の内容が含まれている:
–AIモデルまたはAIシステムへの入力に対する攻撃や不審な活動の監視
–AIモデルまたはシステムの出力およびパフォーマンスの監視
【フォーカス領域】
・ログ監視に関するポリシー、プロセスおよび手順
————————————————
【サイバートラスト】
B.16.11 組織は、IT環境内に潜む脅威を積極的に探索するための対策およびプロセスを策定・実装している。
【AIセキュリティ固有の管理策】
・これには、組織のAIシステムに対してレッドチーム演習を実施するなどの対策も含まれる。
【フォーカス領域】
・積極的な脅威ハンティング

————————————————
【サイバートラスト】B.17 ドメイン: サードパーティリスクと監督
————————————————
【サイバートラスト】
B.17.3 組織は、サードパーティがサービス提供時にサイバーセキュリティに関する責務や期待事項を満たすよう、サードパーティとの間でサービスレベル契約（SLA）を策定・実装している。
【AIセキュリティ固有の管理策】
・組織がAIサプライヤーと締結しているサービスレベル契約（SLA）には、AIセキュリティに関連する重要な項目が盛り込まれている。
例としては、以下のような内容が含まれる:
–AIサービスのパフォーマンス指標（例：可用性）
–情報セキュリティ要求事項（サプライヤーのセキュリティ責任を含む）
–セキュリティのために導入されたガードレールやその他の対策
–変更管理プロセス（例：ソフトウェアのアップデート）
–ログ取得および監視の運用
–インシデント対応の運用方法
–サプライヤーのAIモデルの学習における、組織のデータの利用
【フォーカス領域】
・サービスレベル契約（SLA）
————————————————
【サイバートラスト】
B.17.4 組織は、サードパーティに対して最低限のサイバーセキュリティ要求事項が定義されていることを確保し、サードパーティが自らのセキュリティ上の責務を認識するよう周知するとともに、システムおよびデータのセキュリティが確保されるよう対策を策定・実装している。
【AIセキュリティ固有の管理策】
・これには、可能な場合において、組織のAIプロバイダとの間でAIに関するセキュリティの共有責任モデルを確立することも含まれており、以下の内容を対象としている:
–組織が責任を負うセキュリティ領域（顧客の期待やニーズを満たす責任を含む）
–サプライヤーおよび／またはサードパーティパートナーが責任を負うセキュリティ領域
【フォーカス領域】
・サードパーティのセキュリティ責務
————————————————
【サイバートラスト】
B.17.5 組織は、サードパーティと契約を締結する前やオンボーディングの段階で、提供されるサービスの種類に応じたリスクに基づき、必要なセキュリティ義務をすべて満たしていることを確認するための評価措置を策定・実装している。
【AIセキュリティ固有の管理策】
・これには、プロジェクトのリスクレベルに基づき、サードパーティが満たすべき最低限のサイバーセキュリティ要求事項の評価が含まれている。
–外部のモデル提供者に対して: 提供者自身のセキュリティポスチャーに関するデューデリジェンス評価
–外部のソフトウェアライブラリ（オープンソースを含む）に対して: ライブラリのデューデリジェンス評価（例：AIコードのチェック、脆弱性スキャン、脆弱性情報データベースとの照合など）
–外部APIに対して: 組織外のサービスに送信されるデータに対する制御の実施（例：機微な情報を送信する前に、ユーザーにログインして確認を求める）
信頼できるソース以外のモデルやコードを使用する場合、組織は適切な制御策（例：サンドボックス化）を実施している。
【フォーカス領域】
・サードパーティの関与時に実施するセキュリティ評価

————————————————
【サイバートラスト】B.18 ドメイン: 脆弱性評価
————————————————
【サイバートラスト】
B.18.4 組織は、少なくとも年に一度、システムに対して非侵入型のスキャンを実施し、脆弱性を発見するための定期的な脆弱性評価を行っている。
【AIセキュリティ固有の管理策】
・脆弱性評価には、組織のAIシステムも含まれている。
【フォーカス領域】
・定期的な脆弱性評価の実装

————————————————
【サイバートラスト】B.20 ドメイン: ネットワークセキュリティ
————————————————
【サイバートラスト】
B.20.6 組織は、ネットワークをプライベートネットワークとパブリックネットワークに分離するためのネットワークセグメンテーションのプロセスを定義し、実装している。プライベートネットワークには業務上重要なデータが保持されており、インターネットとは接続されていないことで、外部の脅威から隔離された状態が確保されている。
【AIセキュリティ固有の管理策】
・ネットワークセグメンテーションの一環として、組織はAIシステムと他の社内システムとの接続を管理するための対策を実装している。例えば、データの機微性に基づいて接続を制御するなどの方法が取られている。
【フォーカス領域】
・ネットワークセグメンテーションの実装

なお、シンガポールサイバーセキュリティ庁がクラウドセキュリティアライアンスと共同で策定した「サイバートラストマーク：クラウドセキュリティコンパニオンガイド」に関連して、AWS版（https://d1.awsstatic.com/whitepapers/compliance/CSA_Cyber_Trust_mark_certification_Cloud_Companion_Guide.pdf）のほか、Huawei版（https://res-static.hc-cdn.cn/cloudbu-site/intl/en-us/TrustCenter/WhitePaper/Best%20Practices/Singapore_CSA_Cyber_Trust_mark_Cloud_Companion_Guide.pdf）のコンパニオンガイドも公開されている。現在、クラウドセキュリティアライアンスは、「サイバートラスト向けクラウドセキュリティコンパニオンガイド」からAIセキュリティへの拡張領域に関連して、「AI Controls Matrix (AICM)」や「STAR for AI」など、様々な新規サービスやドキュメントを公開しているが、HuaweiやAlibaba Cloudなど、中国系CSPがどのように対応していくのか注目される。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

海外に学ぶSMBのクラウドセキュリティ基礎（総論編）(1)(2)、（CSP編）AWS(1)(2)、（CSP編）Google Cloud(1)(2)、（CSP編）Microsoft(1)(2)に引き続き、今回は、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発された人工知能（AI）セキュリティ固有のガイドを紹介していく。

シンガポール政府がSMBユーザー向けAIセキュリティガイドラインを提供

過去にSMBユーザーを対象とする「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」および「サイバートラストマーク: クラウドセキュリティコンパニオンガイド」（2023年10月13日公表）（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security-for-organisations）を紹介したが、これらと並行して、シンガポールサイバーセキュリティ庁は、AIセキュリティやOTセキュリティに関するガイドの策定作業を行ってきた。そして2024年10月15日には、「AIシステムのセキュリティ確保に関するガイドライン」および「AIシステムのセキュリティ確保に関するコンパニオンガイド」を公開している（https://www.csa.gov.sg/resources/publications/guidelines-and-companion-guide-on-securing-ai-systems）。

AIセキュリティガイドラインは、AIのライフサイクル全体にわたりシステムオーナーがAIを安全に運用できるようにすることを目的としており、サプライチェーン攻撃のような従来型のサイバーセキュリティリスクや、敵対的機械学習のような新たなリスクからAIシステムを保護するのに役立つとしている。

なおAIセキュリティガイドラインは、以下のような構成になっている。

1. イントロダクション
1.1. 本書の目的と範囲
2. AIに対する脅威の理解
3. AIのセキュリティ確保
3.1. ライフサイクルアプローチの採用
3.2. リスク評価から始める
3.3. AIシステムのセキュリティ確保に関するガイドライン
用語集
附表A

他方、AIセキュリティコンパニオンガイドは、システムオーナーを支援するために、AIおよびサイバーセキュリティの専門家と連携して作成した、コミュニティ主導による上記ガイドラインの補完ガイドである。指示型（prescriptive）ではなく、業界や学術界の実践的な手法、セキュリティ対策、ベストプラクティスを厳選した内容になっており、MITREのATLASデータベースや、OWASPの「機械学習と生成AI向けトップ10」などのリソースも参照されている。

なおAIセキュリティコンパニオンガイドは、以下のような構成になっている。

1.イントロダクション
1.1. 目的とスコープ
2.コンパニオンガイドの利用
2.1. リスク評価から始める
2.2. 関連する対策・管理策の特定
2.2.1. 計画と設計
2.2.2. 開発
2.2.3. 導入
2.2.4. 運用と保守
2.2.5. 運用終了
3. ユースケースの例
3.1. 詳細な手順の例
3.1.1. リスク評価の例
3.1.2. 一覧形式の対策・管理策の手順
3.2. 簡易導入例
3.2.1. リスク評価の例 – パッチ攻撃
3.2.2. 補足ガイドにおける対応策
用語集
附表A
AIテストツール一覧
攻撃的AIテストツール
防御的AIテストツール
AIガバナンステストツール
附表B
参考文献

なお、シンガポールサイバーセキュリティ庁のAIセキュリティガイドラインおよびAIセキュリティコンパニオンガイドは、「ISO/IEC 42001:2023情報技術－人工知能－マネジメントシステム」や「ISO/IEC 23894:2023 情報技術 – 人工知能 – リスク管理に関するガイダンス」を参照している。

シンガポールのサイバーセキュリティ認証制度をAIセキュリティに拡大

その後2025年4月15日、シンガポールサイバーセキュリティ庁は、サイバーエッセンシャルズマークおよびサイバートラストマークの認証プログラムについて、クラウドセキュリティ、AIセキュリティ、OTセキュリティの領域をカバーするように拡張することを発表した。各領域における拡張の概要は以下の通りである。

[クラウドセキュリティへの拡張]
・組織は、拡張されたサイバーエッセンシャルズの内容を参照して、自社のクラウド利用におけるセキュリティ対策を講じることができる。たとえば、組織はクラウドサービスプロバイダーとの業務範囲を定義する際に、クラウド共有責任モデルを参考にして、クラウドを利用する従業員がユーザーレベルの設定を安全に構成するよう対策を行う必要がある。
・サイバートラストでは、組織が自社のリスクプロファイルに基づいてサイバーセキュリティ評価を行えるよう、クラウド関連のリスクシナリオ一覧を提供している。たとえば、あるシナリオにおいては、攻撃者が組織のクラウドサービスにおける安全性の低いアプリケーションプログラミングインタフェース（API）を悪用し、データへの不正アクセスを行ったり、クラウドサービスの提供を妨害したりする可能性がある。

[AIセキュリティへの拡張]
・AIを利用しているまたは今後利用予定の組織は、AIを安全に活用するための方法について、拡張されたサイバーエッセンシャルズの内容を参考にすることができる。たとえば、「資産」カテゴリでは、組織が自社のソフトウェア資産を把握する必要性に焦点を当てており、従業員が使用しているが組織が提供していない外部のAIツール（いわゆるBYOAI：Bring Your Own AI）について、組織がその利用状況を把握する方法について指針を示している。組織は、このようなツールの利用に伴うリスクに対応すべきであり、情報が漏洩する可能性があるため、適切な対策を講じる必要がある。
・サイバートラストでは、リスクシナリオの一例として、攻撃者が組織で使用している安全性の低い大規模言語モデル（LLM）の弱点を突き、悪意のある内容をプロンプトとして注入し、LLMの動作を操作するというケースが挙げられている。

[OTセキュリティへの拡張]
・拡張されたサイバーエッセンシャルズは、組織がOT環境を安全に確保し、OTとITの融合を安全に管理する方法について指針を提供する。たとえば、OTは通常、情報技術（IT）よりも投資サイクルが長いため、OT環境には強力なアクセス制御（例：安全なパスフレーズ）をサポートしていない古いデバイスやシステムが存在する可能性がある。したがって、組織は代替的な制御手段として、物理的アクセス制御やネットワークの分割などの対策を講じる必要がある。
・サイバートラストでは、リスクシナリオの一例として、OTベンダーが別の顧客のネットワークでマルウェアに感染したノートパソコンを組織のOTネットワークに接続し、そのネットワークを感染させるケースが挙げられている。

上記の拡張に合わせて、サイバーエッセンシャルズマーク認証関連文書（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-for-organisations/cyber-essentials/certification-for-the-cyber-essentials-mark/）およびサイバートラストマーク認証関連文書（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-for-organisations/cyber-trust/certification-for-the-cyber-trust-mark/）も改定されている。

既存のセキュリティ対策にAIセキュリティ固有の管理策をアドオンする

以下では、前述のサイバーエッセンシャルズマーク認証関連文書の1つとして公開されている「サイバーエッセンシャルズ(2025) マーク – 自己評価テンプレート」より、サイバーエッセンシャルズマークの各管理作項目において、AIセキュリティ固有の管理策を提示する。

————————————————
【サイバーエッセンシャルズ】
A.1 資産: 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
————————————————
A.1.4 (c) ＜推奨事項＞
・サイバーハイジーンのプラクティスとガイドラインには、人為的な要因によるサイバーセキュリティインシデントを軽減するための以下のトピックが含まれるべきである：
– フィッシングから身を守る
– 強力なパスフレーズを設定し、それを保護する
– 企業用および／または個人用のデバイス（仕事に使用するもの）を保護する
– サイバーセキュリティインシデントを報告する
– 事業に重要なデータを慎重に取り扱い、開示する
– 現場およびリモートで安全に作業する
【AIセキュリティ固有の管理策】
・サイバーハイジーンのプラクティスおよびガイドラインのトピックには、以下のような人工知能(AI)に特化したトピックを含めるべきである:
–公共または企業向けAIツールやサービスを使用する際の、重要な業務データの管理：データの整理、分類、適切な取り扱いおよび開示を行う
–組織内でAIを使用することによる一般的なリスク：AIの導入によって生じる潜在的なリスクについて理解し、備える

【サイバーエッセンシャルズ】
A.1.4 (d) ＜推奨事項＞
可能な場合、トレーニング内容は従業員の役割に基づいて区別されるべきである:
– 上級管理職またはビジネスリーダー – 例. 組織内でのサイバーセキュリティ文化／マインドセットの開発や、サイバーセキュリティ戦略や作業計画の確立
– 従業員 – 例. 強力なパスフレーズの使用と、仕事に使用する企業用および／または個人用デバイスの保護
【AIセキュリティ固有の管理策】
・AIツールやサービスの利用に関与する役割の違いに基づき、区別が行われる場合があり、以下のような役割別の観点が含まれる：
–経営幹部や事業責任者：ビジネス上の利点とAIに関するセキュリティリスク（AIやAI提供者への過度な依存を含む）との間でトレードオフのバランスを取る
–従業員：生成AIサービスを含む、公共または企業向けAIサービスを利用する際の、業務上重要なデータの安全な取り扱いや開示に関する責任

————————————————
【サイバーエッセンシャルズ】
A.2 資産: ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
————————————————
A.2.4 (a)＜要求事項＞
・組織内のすべてのハードウェアおよびソフトウェア資産について最新の資産目録を維持する必要がある。組織は、この要件を満たすために、例えばスプレッドシートやIT資産管理ソフトウェアを使用してIT資産目録を維持するなど、さまざまな方法で対応することができる
【AIセキュリティ固有の管理策】
・これには以下のようなAIツールやサービスの使用または契約が含まれる
–無料または公開されたAIサービス
–企業向けのAIツール
・この取り組みの目的は、組織内における”シャドーAI”に関連するリスクを軽減することである

【サイバーエッセンシャルズ】
A.2.4 (d) ＜要求事項＞
・認証のスコープ内のソフトウェア資産には、組織が使用するソフトウェアアプリケーションが含まれる場合がある。認証のスコープにクラウド環境が含まれている場合:
– クラウド: 組織はクラウドインスタンス上にホストされているもの（例. ソフトウェアおよびオペレーティングシステム（OS））を含める必要がある。
【AIセキュリティ固有の管理策】
・AI資産のインベントリ一覧には、以下も追加で含める必要がある:
–無料または公開されたAIサービス
–企業向けAIツール

【サイバーエッセンシャルズ】
A.2.4 (h) ＜要求事項＞
・EOS資産を引き続き使用する場合、組織はリスクを評価し理解し、上級管理職からの承認を得て、資産が交換されるまで監視する必要がある
【AIセキュリティ固有の管理策】
・AI資産に関しては、承認プロセスに、AI資産の提供元またはプロバイダーのサイバーセキュリティ体制と実績の確認、または悪意のあるコードのスキャンが含まれる場合がある

————————————————
【サイバーエッセンシャルズ】
A.3 資産: データ – 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
————————————————
A.3.4 (a) ＜要求事項＞
・組織は、組織内の重要なビジネスデータのインベントリを特定し、維持する必要がある。組織は、この要件をさまざまな方法で満たすことができる。たとえば、スプレッドシートや資産インベントリソフトウェアを使用する方法がある。インベントリリストには以下のデータの詳細が含まれる必要がある:
– 説明
– データの分類および／または機密性
– 場所
– 保存期間
【AIセキュリティ固有の管理策】
・インベントリには、以下のデータセットに関する情報を示す必要がある:
–組織内でAIツールやサービスに入力として使用されるデータセット
–組織内の主要なAIツールやサービスから生成された出力データセット
–上記のデータセットを使用または生成する組織内の該当するAIツールやサービス

【サイバーエッセンシャルズ】
A.3.4 (c) ＜要求事項＞
・組織は、ビジネス上重要なデータを保護するためのプロセスを確立する必要がある。たとえば、パスワードで保護されたドキュメント、個人データの暗号化（保存時）および／または電子メールの暗号化などである
【AIセキュリティ固有の管理策】
・AIツールやサービスで使用されるデータの保護に関して、組織は以下の対応を行う:
–AIツールやサービスに入力されるデータの機密性や分類が漏えいした場合に、どのような悪影響が生じる可能性があるかを評価する
–組織内でAIに入力されるデータの完全性を確認し、入力データの改ざんによってAIの出力が影響を受けるリスクを軽減するため、必要に応じてデータの無害化対策を実施する
–組織内でAIから生成される出力データの完全性を確認し、不正操作やハルシネーション（AIによる誤った出力）のリスクを軽減する

【サイバーエッセンシャルズ】
A.3.4 (d) ＜要求事項＞
・機密情報および／または機微なデータを組織外部に漏えいするのを防ぐための対策も講じられる必要がある。たとえば、USBポートを無効にすることなどである
【AIセキュリティ固有の管理策】
・組織は、以下の目的において、組織内で使用されるデータの管理措置を講じる:
–外部または公開AIツール・サービスへの入力データ（例：データ漏えいを防ぐための対策）
–内部または企業向けAIツール・サービスへの入力データ（例：組織内の部門ごとに適切なデータ分類を実施する）

————————————————
【サイバーエッセンシャルズ】
A.4 セキュア化／保護: ウイルスおよびマルウェアの保護 – ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
————————————————
A.4.4 (j) ＜要求事項＞
・組織は、従業員が公式または信頼できるソースからのみ、組織内で許可されたソフトウェアや添付ファイルをインストールまたはアクセスすることを確実にする必要がある
【AIセキュリティ固有の管理策】
・組織は、従業員がAIに関するセキュリティ上の懸念や予期しないAIの挙動を認識し、それをさらなる調査のために報告できるようにする

————————————————
【サイバーエッセンシャルズ】
A.5 セキュア化／保護: アクセス制御 – 組織のデータやサービスへのアクセスを制御する
————————————————
A.5.4 (a) ＜要求事項＞
・アカウント管理を確立し、アカウントのインベントリを維持し、管理する必要がある。組織は、スプレッドシートを使用する、またはソフトウェアディレクトリサービスからリストをエクスポートするなど、さまざまな方法でこれを実現することができる
【AIセキュリティ固有の管理策】
・インベントリには、組織が保有するAIツールやサービスへのアクセス情報（例：ログインアカウント、APIなど）を含める必要がある

————————————————
【サイバーエッセンシャルズ】
A.6 セキュア化／保護: セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
————————————————
A.6.4 (a) ＜要求事項＞
・セキュリティ構成は、デスクトップコンピューター、サーバー、ルーターを含む資産に対して強制的に適用されるものとする。 その方法としては、業界の推奨事項や標準の採用、ベースラインセキュリティ分析ツールの実行、構成の保護（例：スクリプトを使用した設定）などが含まれる
※ セキュリティ構成ガイドラインを提供している団体のひとつとして、Center for Internet Security（CIS）が挙げられる
【AIセキュリティ固有の管理策】
・このようなセキュアな構成のベストプラクティスおよび／または設定は、組織がAIツールやサービスを展開するために使用している環境にも適用されるものとする

【サイバーエッセンシャルズ】
A.6.4 (g)＜推奨事項＞
・攻撃の検出・把握・復旧に役立つイベントに関する監査ログは、記録が有効化されるものとする。 例：ユーザーレベルのイベント（ユーザーのログインやファイルアクセスなど）
【AIセキュリティ固有の管理策】
・組織は、AIツールおよびサービスにおいてログ記録（監査ログ）がサポートされている場合、監査ログの記録を有効化するものとする

————————————————
【サイバーエッセンシャルズ】
A.9 対応: インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする
————————————————
A.9.4 (a) ＜要求事項＞
・組織は、一般的なサイバーセキュリティインシデントにどのように対応するかを指針とする、最新の基本的なインシデント対応計画を策定し維持する必要がある。例として、フィッシング、データ漏洩、ランサムウェアが挙げられる。この計画には、以下の詳細が含まれるべきである：
–インシデント対応計画プロセスに関与する組織内の主要な担当者の明確な役割と責任
– 一般的なサイバーセキュリティ脅威シナリオ（例: フィッシング、ランサムウェア、データ漏えい）を検出し、対応し、復旧するための手順
–規制当局、顧客、経営幹部などの内部および外部の関係者に対して、インシデントをエスカレーションし、報告するためのコミュニケーション計画およびタイムライン
【AIセキュリティ固有の管理策】
・組織は、AIに特有のインシデントに関連するシナリオをインシデント対応計画に含めなければならない。 たとえば、従業員が機密性の高い組織情報を外部のAIツールやサービスに漏えいするケースなどが挙げられる

なお、AI固有の管理策の記載がない項目については、従来からのサイバーエッセンシャルズマーク管理策を適用する形となる。

現時点では、主にインフラストラクチャセキュリティをカバーするサイバートラストマークとCloud Controls Matrix v4とのクロスマッピング文書が公開されている（https://isomer-user-content.by.gov.sg/36/2afb6128-5b9b-4e32-b151-5c6033b993f1/Cloud-Security-Companion-Guide-Cyber-Trust.pdf）。その中で、主にSaaSセキュリティをカバーするサイバーエッセンシャルズマークとの整合性も考慮されており、基本的な対策は共通化されている。

すでに、シンガポールサイバーセキュリティ庁は、クラウドセキュリティアライアンスと共同で「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」や「サイバートラスト向けクラウドセキュリティコンパニオンガイド」を開発しているので、AIセキュリティへの拡張領域においても、「AI Controls Matrix (AICM)」や「AICM to ISO 42001 Mapping」の活用が期待される。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(1)に引き続き、今回は、アクセス制御の視点から、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発されたMicrosoft固有のガイドを紹介していく。

アイデンティティ／アクセス管理はクラウドユーザーの責任

Microsoft版ガイドでは、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に従い、以下のような管理策について触れている。

[資産]
A1. 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
A2. ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
A3. データ– 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
[セキュア化／保護]
A4. ウイルスとマルウェアの保護– ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する
A6. セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
[アップデート]
A7. ソフトウェアのアップデート – デバイスやシステム上のソフトウェアをアップデートする
[バックアップ]
A8. 不可欠なデータのバックアップ– サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする
[対応]
A9. インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

このうち「A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する」の中で、アクセス制御に関する要求事項や管理策を提示している。

「サイバーエッセンシャルズ」や「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」では、「A5. アクセス制御」のうちA.5.4 (a)のアカウント管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (a) <要求事項>
アカウント管理を確立し、アカウントのインベントリを維持し、管理する必要がある。組織は、スプレッドシートを使用する、またはソフトウェアディレクトリサービスからリストをエクスポートするなど、さまざまな方法でこれを実現することができる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

• エンドユーザー組織（SaaSカスタマー）が責任を負う。

<なぜこれが重要なのか>

• アイデンティティ、資格情報、アクセス管理、および特権アカウントが不十分であることは、主要なクラウドセキュリティの懸念の一部である。
• 組織が管理するSaaSサブスクリプションの数が増加する可能性がある。
• さまざまな事業部門の業務ユーザーが、それぞれのSaaSアプリケーションにアクセスし管理する場合がある。
• 各SaaSサブスクリプションにはそれぞれ固有のアイデンティティが存在する可能性がある。
• その結果、組織は多数のアイデンティティを管理する必要があるかもしれない。
• 各SaaSサブスクリプションは、アイデンティティを定義、表示、および保護する方法が異なる場合がある。

<組織は何をすべきか>

• SaaSサブスクリプションへのアカウントのインベントリを追跡および監視する仕組みを実装する。
• 多数のSaaSサブスクリプションおよびアイデンティティを管理する必要がある組織は、個々のSaaSサブスクリプションのパスワードを個別に管理するのではなく、アイデンティティプロバイダーを活用してシングルサインオン（SSO）ソリューションを通じてユーザーを認証することで、アイデンティティ管理をスケールすることができる。
• SaaSサブスクリプションへのユーザーアクセスを制限することを検討する。例：ビジネスセキュリティポリシーに従う承認されたデバイスからのみユーザーがアクセスできるようにする。
• 組織が「Bring Your Own Device（BYOD）」の方針を採用している場合は、リスクベースのアプローチを検討する。例：管理されていないBYODデバイスからのSaaSサブスクリプションへのアクセスを制限する。

-[クラウドプロバイダーの責任]
-[SaaSプロバイダーの責任]
(該当なし)
-[クラウドインフラストラクチャプロバイダー]
(該当なし)

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]

• CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

• M365はAzure Active Directoryを使用してユーザーアカウントを管理する。M365のカスタマーは、M365管理センターまたはAzure Active Directoryを使用してユーザーアカウントを管理することができる（https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/manage-microsoft-365-accounts?view=o365-worldwide）。
• また、カスタマーはPowerShellスクリプトを活用してユーザーアカウントを一覧表示し、それをExcelにエクスポートすることも可能である（https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/view-user-accounts-with-microsoft-365-powershell?view=o365-worldwide）。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

• Azureのカスタマーは、アイデンティティ管理プラットフォームとしてAzure Active Directoryを使用する。Azureポータルでユーザーのリストにアクセスする方法については、こちらを参照（https://learn.microsoft.com/ja-jp/entra/identity/users/users-bulk-download）。
• また、カスタマーはPowerShellスクリプトを活用してユーザーアカウントを一覧表示し、それをExcelにエクスポートすることもできる（https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/view-user-accounts-with-microsoft-365-powershell?view=o365-worldwide#use-the-azure-active-directory-powershell-for-graph-module）。

アカウント管理は、エンドユーザー組織（SaaSカスタマー）の責任範囲であるが、Microsoftの場合、Azure Active DirectoryやPowerShellスクリプトなど、固有のツールを利用した管理サポート策を提供している。これらのツールは、既存のオンプレミス環境と新たなクラウド環境を連携させる場合に重要な役割を果たすが、ユーザー組織の規模が拡大すると、アイデンティティ／アクセス管理が複雑になる。このような状況を支援するために、サードパーティプロバイダーによるIDaaS（Identity as a Service）などがある。IDaaSを利用する場合でも、最終的な責任は、ユーザー組織にあることを忘れてはならない。

参考までに、Google Workspaceでは、A.5.4 (a)に関して、以下のような管理策を提示している。

[Google Workspaceユーザーの責任]

•  カスタマーは、自身のシステムアカウントユーザーを管理および追跡する責任を負う。この責任には、Google Workspaceユーザーアカウントを管理するために利用可能なツールを使用することが含まれる。

[Googleの責任]

•  Google Workspaceは、カスタマーがユーザーやそのデバイスを簡単に追加し、管理できる集中型ダッシュボードを提供する。

オンプレミスとクラウドの連携環境で複雑化する物理的なアクセス制御

次に、A.5.4 (i)の物理的なアクセス制御については、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (i) <要求事項>
物理的なアクセス制御を実施し、認可された従業員や契約者のみが組織のIT資産および／または環境にアクセスできるようにする必要がある。たとえば、作業用端末を固定するためのケーブルロックの使用や、認証および承認された入室を行うためのカードアクセス式ドアロックの利用が挙げられる。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]
• エンドユーザー組織（SaaSカスタマー）は、物理的なアクセス制御について責任を負わない。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
• クラウドインフラストラクチャプロバイダーは、基盤となるクラウドインフラストラクチャの物理的なセキュリティに責任を負う。
• 主要クラウドインフラストラクチャプロバイダーは、物理的なセキュリティ対策に関するベストプラクティスを公開していることが一般的である。

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

•  Microsoft Azureに関する情報を確認する。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

• カスタマーは、Microsoftがデータセンターを物理的にどのように保護しているかについて学ぶことができる（https://learn.microsoft.com/ja-jp/azure/security/fundamentals/physical-security#physical-security）。

物理的なアクセス制御は、エンドユーザー組織（SaaSカスタマー）の責任範囲外であるが、Microsoftの場合、クラウドプロバイダー（例. Microsoft 365、Microsoft Azure）としての管理状況をユーザー組織が確認できる仕組みになっている。

ただし、オンプレミス環境における物理的なアクセス制御について、クラウドプロバイダーは言及していない。参考までにGoogle Cloudの場合、「カスタマーは、自身のローカル環境における物理的なスペースおよび資産のセキュリティを確保する責任を負う。」と明記してある。ハイブリッド環境上のSaaSでは、ユーザーがオンプレミス環境とクラウド環境の間をシームレスに行き来しながら利用するのが普通だが、物理的なアクセス制御に関する責任分担は異なるので、注意が必要だ。

非アクティブなアカウントの維持管理は要注意

さらに、A.5.4 (k)の非アクティブなアカウントに関して、以下の通りクラウドプロバイダー共通の管理策を推奨している。

【サイバーエッセンシャルズ】
A.5.4 (k) <推奨事項>
長期間（例：60日間）非アクティブまたは休眠状態となっているアカウントは、削除または無効化されるべきである。
[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

• カスタマーには、定期的に未使用のユーザーアカウントを確認し、レビューすることが推奨される。未使用のユーザーアカウントの管理方法に関する詳細はこちらを参照（https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-phone）。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]

• カスタマーには、定期的に未使用のユーザーアカウントを確認し、レビューすることが推奨される。未使用のユーザーアカウントの管理方法に関する詳細はこちらを参照（https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-phone）。

未使用のユーザーアカウントの場合、一定期間が経過すると、データの削除やサービスの無効化が行われる規定になっていることがあるので、クラウドユーザーは、定期的に未使用のユーザーアカウントを確認し、必要な措置を講じておく必要がある。

参考までにGoogle Cloudの場合、「カスタマーは、Google Workspaceアカウントを含むすべての非アクティブなユーザーアカウントを削除または無効化する責任を負う。」と明記している。

プロバイダーや政府機関が推奨する多要素認証（MFA）

A.5.4 (l)のパスワード管理に関して、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】
A.5.4 (l) <要求事項>
組織は、すべてのデフォルトのパスワードを変更し、強力なパスフレーズに置き換える必要がある。たとえば、12文字以上で、大文字、小文字、および／または特殊文字を含むべきである。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

•  SaaSサブスクリプションごとに別々のパスワードを維持・管理するのではなく、アイデンティティプロバイダーとSSOの使用に関するA.5.4(a)のガイダンスを参照のこと。
• もし別々のパスワードを維持・管理する必要がある場合：
  • 安全なパスフレーズの使用を導入する。
  • パスフレーズが複数のSaaSサブスクリプション間で再利用されないようにする。
  • パスフレーズが複数のアカウント間で共有されないようにする。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]

•  カスタマーは、M365パスワードに関するパスワードポリシーの推奨事項について、この資料を参照することができる（https://learn.microsoft.com/ja-jp/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide）。
• Microsoftは、全てのユーザーに対して多要素認証（MFA）の使用を推奨しており、認証目的でパスワードに依存しないことを提案している。M365に多要素認証を実装する方法に関する詳細はこちらを参照（https://learn.microsoft.com/ja-jp/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide）。
• また、カスタマーはパスワードレスMFAの導入を検討することもできる（https://learn.microsoft.com/ja-jp/entra/identity/authentication/howto-authentication-passwordless-phone）。
  -[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure)]
• カスタマーには、Azureのアイデンティティ管理のベストプラクティスとアクセス制御をレビューし、実践することが推奨される（https://learn.microsoft.com/ja-jp/azure/security/fundamentals/identity-management-best-practices）。
• Microsoftは、Azureユーザーアカウントに対してMFA（多要素認証）の実施を推奨している（https://learn.microsoft.com/ja-jp/azure/security/fundamentals/identity-management-best-practices#enforce-multi-factor-verification-for-users）。

パスワード管理についてはSaaSユーザーが責任を持っている。これに対してMicrosoftは、一貫してMFAの導入を推奨しており、シンガポールサイバーセキュリティ庁も、MFAの重要性を訴えている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2023-006）。

さらに、A.5.4 (o)の2要素／他要素認証に関しては、以下の通りクラウドプロバイダー共通の推奨事項として提示している。

【サイバーエッセンシャルズ】
A.5.4 (o) <推奨事項>
可能であれば、重要なシステムへの管理者アクセスには二要素認証（2FA）を使用するべきである。たとえば、機密情報や業務に重要なデータを含むインターネット向けシステムが該当する。組織はこれをさまざまな方法で実施することができる。例として、モバイル上の認証アプリケーションやワンタイムパスワード（OTP）トークンの使用が挙げられる。
[エンドユーザー組織(SaaSカスタマー)の責任]

• SaaSサブスクリプションは公共のインターネット経由でアクセスされる可能性があるため、二要素認証（2FA）を導入して、SaaSサブスクリプションにアクセスするユーザーが本人であることを確認する必要がある。

[クラウドプロバイダーの責任]
-[SaaSプロバイダー]
（該当なし）
-[クラウドインフラストラクチャプロバイダー]
（該当なし）

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
（該当なし）
[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)]
• A.5.4 (l)を参照
-[クラウドインフラストラクチャプロバイダー]
• A.5.4 (l)を参照

ただし、昨今、シンガポールでは、中間者攻撃（MITM：Man-in-the-Middle Attack）、MFA疲労攻撃、セッションハイジャック／cookie盗難、認証コード／トークン窃盗などの手法を使ってMFAをバイパスする攻撃による被害が増加しており、シンガポールサイバーセキュリティ庁が注意喚起を行っている（https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2024-020/）。MFAを導入したからといって、セキュリティリスクを100%低減できるわけではない点に注意する必要がある。

今回は、アクセス制御に焦点を当てたが、たとえば取引先の環境に合わせて、Microsoft 365とGoogle Workspaceを併用しなければならないケースが多く見受けられる。そのような場合には、Google Cloud版ガイドとMicrosoft版ガイドを組み合わせて管理策を検討する必要があろう。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

海外に学ぶSMBのクラウドセキュリティ基礎（総論編）(1)(2)、（CSP編）AWS(1)(2)、（CSP編）Google Cloud(1)(2)に引き続き、今回も、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発されたクラウドサービスプロバイダー（CSP）固有のガイドを紹介していく。

SaaSとIaaS／PaaSの両側面をカバーするMicrosoft版ガイド

今回取り上げるのは、SMBユーザーを対象とする「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security-for-organisations#f34bc8fc0fcda102914054b9481223ba）に準拠した「サイバーエッセンシャルズ向けMicrosoftクラウドセキュリティコンパニオンガイド– Microsoftとの共同開発による（https://isomer-user-content.by.gov.sg/36/b9820a85-64c0-4831-824d-344bda9647e8/Microsoft-Cloud-Security-Companion-Guide-Cyber-Essentials.pdf）（2023年10月13日公表）である。

Microsoft版ガイドでは、Google Workplace版ガイドと同様に、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に従い、以下のような管理策について触れている。。

[資産]
A1. 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
A2. ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
A3. データ– 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
[セキュア化／保護]
A4. ウイルスとマルウェアの保護– ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
A5. アクセス制御 – 組織のデータやサービスへのアクセスを制御する
A6. セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
[アップデート]
A7. ソフトウェアのアップデート – デバイスやシステム上のソフトウェアをアップデートする
[バックアップ]
A8. 不可欠なデータのバックアップ– サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする
[対応]
A9. インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

以下では、「サイバーエッセンシャルズ」や「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」と、「サイバーエッセンシャルズ向けMicrosoftクラウドセキュリティコンパニオンガイド」の管理策の関係、そしてクラウドセキュリティに係るMicrosoft 365ユーザーとMicrosoft 365およびMicrosoft Azureの間の責任共有について考察する。

セキュリティトレーニングはクラウドユーザーの責任

最初に、海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Google Cloud(1)( https://cloudsecurityalliance.jp/newblog/2025/02/24/smb_csp3/)で取り上げた「A1. 人々– 従業員に、防衛の最前線となるノウハウを装備させる」のサイバーセキュリティトレーニングに関する要求事項に基づく管理策をみていく。

「サイバーエッセンシャルズ」や「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」では、以下の通りクラウドプロバイダー共通の管理策を提示している。

【サイバーエッセンシャルズ】

A.1.4(a) <要求事項>
組織は、すべての従業員が、セキュリティプラクティスや期待される行動を意識していることを保証するために、サイバーセキュリティ意識向上トレーニングを設定すべきである。組織は、この要求事項を様々な方法で充足する可能性がある（例. 従業員または関与する外部トレーニング プロバイダー向けに自己学習教材を提供する）。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

[エンドユーザー組織(SaaSカスタマー)の責任]

• エンドユーザー組織(SaaSカスタマー)は、単独で責任を負う

<なぜこれが重要か>

• ますますビジネスユーザー（IT部門と対照的に）は、SaaSアプリケーションにアクセスして管理しており、SaaSのセキュリティを管理するために、適切な装備を備えていない可能性がある。
• ヒューマンエラーは、クラウドリスクの主要な要因の一つとして広く認識されている。

<組織は何をすべきか>

• 従業員向けの一般的なサイバー意識向上トレーニングの範囲を越えて、組織は、SaaSを管理するビジネスユーザーが、なぜクラウドセキュリティにおいて重要な役割を果たすのか、どのようにしてクラウド上でセキュリティを運用できるのかについて理解するためのトピックを含めるべきである。

[クラウドプロバイダーの責任]

• 主要クラウドプロバイダーは、ベストプラクティスを公開し、クラウドカスタマーに対してよりよいサポートを提供する。

これらを受けて、「サイバーエッセンシャルズ向けMicrosoftクラウドセキュリティコンパニオンガイド」では、以下のように提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]

• CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)の責任]

• サイバーセキュリティ意識向上コンテンツはMicrosoftによって公開されている。 カスタマーは、これらのコンテンツを自由に自社内で活用し、サイバーセキュリティ意識を高めることができる(リンク（https://www.microsoft.com/ja-jp/security/business/cybersecurity-awareness)）。
• 一般的なサイバーセキュリティ意識向上のために：
  初心者、ビジネス意思決定者、学生、管理者向けの学習パスウェイ (リンク(https://learn.microsoft.com/ja-jp/collections/yrrbdgy2d6158))
• サイバーセキュリティ 101 (リンク(https://www.microsoft.com/ja-jp/security/business/security-101/what-is-cybersecurity))
• 小規模企業向け – サイバー犯罪から守るための5つのステップ (リンク(https://www.microsoft.com/en-us/security/blog/2023/01/17/secure-your-business-like-you-secure-your-home-5-steps-to-protect-against-cybercrime/))

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure) の責任]

• サイバーセキュリティ意識向上コンテンツはMicrosoftによって公開されている。 カスタマーは、これらのコンテンツを自由に自社内で活用し、サイバーセキュリティ意識を高めることができる(リンク（https://www.microsoft.com/ja-jp/security/business/cybersecurity-awareness)）。
• 一般的なサイバーセキュリティ意識向上のために：
  初心者、ビジネス意思決定者、学生、管理者向けの学習パスウェイ (リンク(https://learn.microsoft.com/ja-jp/collections/yrrbdgy2d6158))
• サイバーセキュリティ 101 (リンク(https://www.microsoft.com/ja-jp/security/business/security-101/what-is-cybersecurity))
• 小規模企業向け – サイバー犯罪から守るための5つのステップ (リンク(https://www.microsoft.com/en-us/security/blog/2023/01/17/secure-your-business-like-you-secure-your-home-5-steps-to-protect-against-cybercrime/))
• Azureクラウドインフラストラクチャを管理しているカスタマーは、Azure上でホストされたシステムを管理・保護するために、より深い技術的知識が必要となる。カスタマーには、技術スタッフにSecurity Engineer学習パスウェイのトレーニングを受けさせることを強く推奨する(リンク(https://learn.microsoft.com/ja-jp/training/career-paths/security-engineer))。

Microsoftは、Microsoft 365を提供するSaaSプロバイダーかつAzureを提供するクラウドインフラストラクチャプロバイダーであり、SaaSおよびIaaS／SaaSの両側面から、クラウドユーザー向けにセキュリティトレーニング支援策を提示しているのが特徴だ。特に、初心者／ビジネス意思決定者／学生／管理者向けと技術スタッフ向けの2種類のパスを構築している点は注目される。

ソフトウェア資産の棚卸・管理はSaaSユーザーの責任

次に「A2. ハードウェアとソフトウェア」では、SaaSユーザーが利用するハードウェアおよびソフトウェアに係るIT資産管理について記述している。その中で、ハードウェア資産（クラウド内）およびソフトウェア資産に係るIT資産目録の作成・維持に関して、以下の通り要求事項に基づく管理策を提示している。

【サイバーエッセンシャルズ】

A.2.4(a) <要求事項>
組織内のすべてのハードウェアおよびソフトウェア資産について最新の資産目録を維持する必要がある。組織は、この要件を満たすために、例えばスプレッドシートやIT資産管理ソフトウェアを使用してIT資産目録を維持するなど、さまざまな方法で対応することができる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

• ハードウェア資産（クラウド内）の場合、SaaSはソフトウェア資産と見なされるため、エンドユーザー組織（SaaS顧客）には適用されない。
• ソフトウェア資産の場合、エンドユーザー組織（SaaS顧客）が責任を負う。

<なぜこれが重要か>

• SaaSモデルの人気が高まっており、組織は多数のSaaSサブスクリプションを管理している。

<組織は何をすべきか>

• さまざまな業務機能にわたるSaaSサブスクリプションのインベントリを追跡および監視するためのメカニズムを実装する。
• これは、プロセスまたは技術的なソリューションを通じて実現できる。例：
  − すべてのSaaSの購入および取得を使用前にITおよびセキュリティに提出する手続き方法を通じて
  − ファイアウォール、Webゲートウェイ、クラウドアクセスサービスブローカー（CASB）からのログの分析および評価を通じて
  − SaaSセキュリティポスチャ管理（SSPM）ソリューションの使用を通じて
  − SaaSに関連する項目に関する経費報告書および財務記録の分析を通じて

[クラウドプロバイダーの責任]
-[SaaSプロバイダーの責任]
(該当なし)
-[クラウドインフラストラクチャプロバイダーの責任]
ハードウェア資産については、クラウドインフラストラクチャプロバイダーが責任を負う

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

• [エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
• CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照
  [SaaSプロバイダー(例. Microsoft 365)の責任]
  <SaaSインベントリ管理>
• M365 SaaSライセンスとサブスクリプション
  カスタマーは、Admin Centerを通じてM365サブスクリプションを管理できる： Admin Center → 請求 → 製品ページ、またはこのリンク (リンク(https://learn.microsoft.com/ja-jp/microsoft-365/admin/?view=o365-worldwide))。
• ソフトウェアインベントリ (リンク(https://learn.microsoft.com/ja-jp/microsoft-365-apps/admin-center/inventory))
• サードパーティアプリケーションのサブスクリプション
  サードパーティ製のSaaSアプリケーションやサービスをサブスクライブしているカスタマーは、M365を通じてサブスクリプションを管理できる場合がある(リンク(https://learn.microsoft.com/ja-jp/microsoft-365/commerce/manage-saas-apps?view=o365-worldwide))。
  <ハードウェアインベントリ管理>
• Microsoftは、M365サービスを提供するサーバーの責任を負っている。カスタマーは、M365サーバーへの管理者アクセス権を持っていない (リンク(https://learn.microsoft.com/ja-jp/compliance/regulatory/offering-iso-27001))。
• クライアントコンピュートデバイス – ハードウェアインベントリ (SaaS環境外)
  エンドポイントマネージャーサービスにアクセスできるカスタマーは、M365を使用して自社のハードウェアデバイスを管理できる。これにより、デバイスと展開されたソフトウェアを管理・更新できる。管理対象デバイスのインベントリリストも生成可能である。
• ハードウェアインベントリ (リンク(https://learn.microsoft.com/ja-jp/defender-endpoint/machines-view-overview))
  [クラウドインフラストラクチャプロバイダー(例. Microsoft Azure) の責任]
  <クラウドサービスのインベントリ管理>
• Azureのカスタマーは、Azureポータルを活用してAzure上で展開されたすべてのサービスの一覧を確認できる。カスタマーが所有するサービスのインベントリリストを表示するには、Azureポータルにログインする: ホーム → All Resources 必要に応じて、結果をCSV形式でエクスポートし、さらに処理することが可能である。
• カスタマーはまた、Cloud Adoption Framework – Azure Management Guideを参照し、インベントリと可視性について確認することもできる(リンク(https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/manage/monitor#plan-your-monitoring-strategy))。
  <ハードウェアインベントリ管理>
• Azureサービスを利用しているカスタマーは、サーバーハードウェアを管理しない。サーバーハードウェアはMicrosoftが管理している。カスタマーは、自分たちがホストしているインフラストラクチャに焦点を当てる(リンク(https://learn.microsoft.com/ja-jp/compliance/regulatory/offering-iso-27001))。
• クラウドの責任共有モデルについての詳細情報はこちら: (リンク(https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility))。

上記に示す通り、SaaSを含むソフトウェア資産については、エンドユーザー組織（SaaS顧客）が管理責任を負う一方、ハードウェア資産については、インフラストラクチャプロバイダーが責任を負うとしている。そしてMicrosoftは、M365やAzureの管理機能を通じて、SaaSユーザーのインベントリ管理やアクセスするデバイスの管理を支援する機能を提供している。

SaaSユーザーはエンドポイントのマルウェア対策を忘れずに

さらに「A4.ウイルスとマルウェアの保護」では、ウイルスやマルウェアのような悪意のあるソフトウェアからの保護策について記述している。その中で、エンドポイントでのウイルス／マルウェア対策に関して、以下の通り要求事項に基づく管理策を提示している。

【サイバーエッセンシャルズ】

A.4.4(a) <要求事項>
組織の環境に対する攻撃を検出するために、マルウェア対策ソリューションを使用してエンドポイントにインストールする必要がある。エンドポイントの例としては、ノートパソコン、デスクトップコンピュータ、サーバー、および仮想環境が含まれる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

• クラウドのマルウェア保護の責任の大部分は、クラウドプロバイダーにある。
• しかし、一部のマルウェア配布の経路は、SaaSユーザーの制御下に残っている。例として、カスタマイズ可能な静的ファイルホスティングや添付ファイルが挙げられる。これらは、組織内の他の従業員や、SaaSアプリケーションがパブリック向けポータルを提供している場合、一般の人々によってアップロードされる可能性がある。

<なぜこれが重要か>

•  クラウドアプリケーション、特に企業に人気のあるものは、マルウェア配信のためのますます人気のあるチャネルになっている。

<組織は何をすべきか>

•  SaaSプラットフォームに組み込まれている標準化されたマルウェアおよびウイルススキャン機能を理解し、サービス説明書や利用規約に記載されているウイルスおよびマルウェア保護に関するSaaSプロバイダーの義務を確認する。

[クラウドプロバイダーの責任]
(SaaSプロバイダー／クラウドインフラストラクチャプロバイダー共通)

• 主要クラウドプロバイダーは、ベストプラクティスを公開し、クラウドカスタマーに対してよりよいサポートを提供する。

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]

• CSAサイバーエッセンシャルマーク：クラウドセキュリティコンパニオンガイドを参照

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)の責任]

• Microsoftは、M365サービスの一部としてホストされているサービスの保護に責任を持つ。この内容はSOC2で文書化され、監査されている（リンク(https://learn.microsoft.com/ja-jp/compliance/regulatory/offering-soc-2）)。
• カスタマーは、エンドポイントでのマルウェア対策ソリューションとしてDefender for Endpointsを使用することができる。展開概要についての詳細はこちらを参照（リンク(https://learn.microsoft.com/ja-jp/defender-endpoint/mde-planning-guide)）。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure) の責任]

• AzureにIaaS資産を展開しているカスタマーは、Defenderサービスを利用することができる。Azureリソースを保護するためのさまざまなDefenderサービスとその使用方法に関する詳細は、Defender for Cloudを参照（リンク(https://learn.microsoft.com/ja-jp/azure/defender-for-cloud/defender-for-cloud-introduction#protect-cloud-workloads)）。
• また、カスタマーはAzureの仮想マシンに関するセキュリティ推奨事項にも関心がある可能性がある（リンク(https://learn.microsoft.com/ja-jp/security/benchmark/azure/baselines/virtual-machines-windows-virtual-machines-security-baseline）)。

前述の通り、クラウドのウイルス／マルウェア保護の責任の大部分は、クラウドプロバイダーにあるが、一部のウイルス／マルウェア配布の経路は、SaaSユーザーのエンドポイントに残っている。これに対して、Microsoftは、SaaSユーザー向けのエンドポイントセキュリティソリューションとして、Microsoft Defender for Endpoint（https://www.microsoft.com/ja-jp/security/business/endpoint-security/microsoft-defender-endpoint）を挙げている。他方、Google版ガイドを見ると、「カスタマーは、ローカル環境のエンドポイントにマルウェア対策ソリューションを展開する責任がある」と明記しており、ソリューションとしてGoogle エンドポイント管理機能（https://support.google.com/a/topic/24642）を挙げている。

SaaSユーザーが責任を負わないネットワークデバイスの設定

加えて「A4.ウイルスとマルウェアの保護」では、ネットワークデバイスの設定に関して、以下のような管理策を提示している。

【サイバーエッセンシャルズ】

A.4.4(f) <要求事項>
ファイアウォールは、ネットワーク、システム、およびノートパソコン、デスクトップ、サーバー、仮想環境などのエンドポイントを保護するために展開または有効化される必要がある。組織のネットワーク設定がある環境では、ネットワーク周辺のファイアウォールを構成して、許可されたネットワークトラフィックのみが組織のネットワークに入るように分析および受け入れる必要がある。例としては、パケットフィルター、ドメインネームシステム (DNS) ファイアウォール、アプリケーションレベルゲートウェイファイアウォールがあり、それらはネットワークトラフィックを制限およびフィルタリングするためのルールを持っている。組織のネットワーク構成によって、ファイアウォール機能は他のネットワークデバイスと統合される場合や、単独のデバイスとして存在する場合がある。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

• エンドユーザー組織（SaaSカスタマー）は、物理的および仮想的なネットワークデバイスの設定に責任を負わない。
• 組織は、サービス記述および／または利用規約に記載されたネットワークセキュリティに関するSaaSプロバイダーの義務を確認する必要がある。

[クラウドプロバイダーの責任]
-[SaaSプロバイダーの責任]
(該当なし)

-[クラウドインフラストラクチャプロバイダーの責任]

• クラウドインフラストラクチャプロバイダーは、物理的および仮想的なネットワークデバイスの設定に責任を負う。

これらを受けて、Microsoft版ガイドでは、以下のように管理策を提示している。

[エンドユーザー組織(SaaSカスタマー)の責任(例. Microsoft 365カスタマー)]
(該当なし)

[クラウドプロバイダーの責任]
-[SaaSプロバイダー(例. Microsoft 365)の責任]

• M365において、MicrosoftはSaaSプロバイダーであり、クラウドインフラストラクチャプロバイダーでもある。そして、カスタマーにM365サービスを提供するためのインフラストラクチャの保護に責任を持つ。SOC2タイプ2レポートには、M365のインフラストラクチャを保護するためにファイアウォールを使用していることが記載されている（リンク（https://learn.microsoft.com/ja-jp/compliance/regulatory/offering-soc-2））。
• 責任共有モデルを参考にすると、カスタマーは管理権限内にある環境について責任を負う。M365によって管理されているエンドポイントについては、ポリシーを通じてエンドポイントでのファイアウォールの使用を強制することを検討できる（リンク(https://learn.microsoft.com/ja-jp/intune/intune-service/protect/endpoint-security-firewall-policy）)。

-[クラウドインフラストラクチャプロバイダー(例. Microsoft Azure) の責任]

• Azureでサーバーサービスをホストしているカスタマーは、Azure Firewallを活用してホストされているリソースを保護することができる（リンク(https://learn.microsoft.com/ja-jp/azure/firewall/tutorial-firewall-deploy-portal-policy）)。
• また、カスタマーはAzure Advisorの推奨事項を確認し、Azure上のサービスとインフラストラクチャを保護するための推奨事項を定期的にチェックすることが重要である。詳細については、こちらを参照（リンク(https://learn.microsoft.com/ja-jp/azure/defender-for-cloud/review-security-recommendations）)。

このケースでは、SaaSユーザーにネットワークデバイスの設定に関する責任はないが、Microsoftは、SaaSプロバイダーかつクラウドインフラストラクチャプロバイダーとしての責務を果たしている。SaaSユーザー自身は責任を負わないが、クラウドプロバイダーの遵守状況を確認できる機能は提供されている。

そして「A5. アクセス制御」以下の管理策項目においても、SaaSユーザー、SaaSプロバイダー、クラウドインフラストラクチャプロバイダーそれぞれの役割が明確化されている。Microsoftは、SaaSプロバイダーおよびクラウドインフラストラクチャプロバイダーの双方を兼ね備えた強みを活かしている。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

海外に学ぶSMBのクラウドセキュリティ基礎CSP編）Google Cloud(1)に引き続き、今回は、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズに基づいて開発されたGoogle Workspaceユーザー向けガイドを紹介していく。

Google Workspaceのセキュリティ設定はユーザーの責任

最初に、SMBユーザーを対象とする「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-essentials.pdf）およびそれに準拠した「サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド– Googleとの共同開発による」（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security-for-organisations）（2023年10月13日公表）より、「A.6.セキュア化／保護: セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する」のセキュリティ設定／管理についてみると、以下のような説明になっている。

【サイバーエッセンシャルズ】
A.6.4 (a)<要求事項>
セキュリティ設定は、デスクトップコンピューター、サーバー、ルーターなどの資産に対して適用される必要がある。組織は、この要件を満たすためにさまざまな方法を採用できる。たとえば、複数のベンダー製品にわたる設定ガイドラインに関する Center for Internet Security（CIS）ベンチマークなどの業界の推奨事項や標準を採用すること、ベースラインセキュリティアナライザーを実行すること、またはシステム設定スクリプトを使用することなどが挙げられる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]

• エンドユーザー組織（SaaS カスタマー）は、SaaSサブスクリプションにおけるユーザーレベルの設定に責任を負う。

[なぜこれが重要なのか]

• SaaS モデルの人気の高まりと、ビジネス主導の SaaS（ビジネスユーザーが SaaS アプリケーションへアクセスし、管理することが増加しているトレンド）により、組織が複数のビジネス機能によって管理される多くの SaaS サブスクリプションを抱える可能性がある。
• このような組織は、以下のリスクを抱える可能性がある：
  −多くの部門が SaaS セキュリティ設定へのアクセス権を持っている
  −SaaS セキュリティ設定の変更が見えにくくなる（可視性の欠如）

[組織は何をすべきか]

• 多数の SaaS サブスクリプションを持つ場合、SSPM ツールによる監視の自動化を通じて SaaS 管理の取り組みをスケールさせる。
• また、CASB を使用して、ユーザーのアプリケーションセッションの詳細な監視や行動のブロック制御を行うことも検討する。

【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]

• カスタマーは、自身のシステムに対して適切なセキュリティ設定を識別し、適用する責任を負う。これには、Google Workspace のようなソフトウェアベンダーが提供するデフォルト設定や推奨設定を適用するかどうかを決定することも含まれる。

[Googleの責任]

• プロバイダーはアプリケーションレベルの設定に責任を負う。
  Google’s Security Centerは、セキュリティの健全性に関する推奨事項を提供しており、推奨されるセキュリティ設定や、コンテンツ、通信、モビリティ、ユーザーセキュリティに関するセキュリティのベストプラクティスについてのカスタマイズされたアドバイスを通じて、ユーザーが脅威に先回りすることを可能にする。

上記に示す通り、セキュリティ設定管理全般については、SaaSユーザーが責任を負っており、SaaSプロバイダーが推奨する標準的な設定を採用するか、サードパーティ製のSaaSセキュリティポスチャ管理（SSPM）ツールやクラウド・アクセス・セキュリティ・ブローカー（CASB）ツールなどを導入するかなどについて最終的判断を行うのもSaaSユーザーとなる。他方、SaaSプロバイダーは、アプリケーションレベルの設定に責任を負うとしている。

また、セキュリティ設定の不備への対応についても、SaaSユーザーが責任を負うことになる。「サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド」では、以下のように記述している。

【サイバーエッセンシャルズ】
A.6.4 (b)<要求事項>
弱い設定やデフォルトの設定は使用前に避けるか更新する必要がある。たとえば、デフォルトのパスワードを変更したり、標準スキャンではなくマルウェア対策ソリューションを用いた深いスキャンを実行したりするなどの対策が含まれる。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

• SaaS サブスクリプションにおけるデフォルト設定が、セキュリティではなく使いやすさや利便性を重視して構成されている可能性があるため、該当する場合にはこれらの設定を見直し、更新する
• 利用可能な場合には、SaaS プロバイダーが公開しているセキュアな設定のベストプラクティスも実装する。

【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]

• カスタマーは、不適切な設定を回避する責任を負う。これには、Google Workspace のようなソフトウェアベンダーが提供するデフォルト設定または推奨設定を適用するかどうかを決定することも含まれる。

[Googleの責任]

• A.6.4(a) を参照のこと。そこには、推奨されるセキュリティ設定に関する Google リソースの説明が含まれている。

SaaSユーザーは、SaaSプロバイダーが提供するデフォルト設定を鵜呑みにするのではなく、使いやすさや利便性とセキュリティのバランスの観点に立って、事前にセキュリティ設定の状態を確認しておくことが必要になってくる。

多岐に渡るGoogle Workspaceのログ管理もSaaSユーザーの責任

次に、SaaS利用時におけるログの記録や管理についてみると、以下のような内容になっている。

【サイバーエッセンシャルズ】
A.6.4 (f)<要求事項>
可能であれば、ソフトウェアおよびハードウェア資産に対してログ記録を有効にする必要がある。たとえば、システムログ、イベントログ、セキュリティログなどである。

【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】

• SaaS アプリケーションのログ出力には、業界標準として受け入れられるフォーマットが存在しない。
• SaaS プロバイダーからのログ配信のタイミングも異なる場合がある。
• 組織が多数の SaaS サブスクリプションを管理する場合、以下を検討する：
  −SaaS プロバイダーからログを自動的に取得する。
  −SaaS アプリケーション全体の効果的な監視を行うために、ログ分析および／またはストレージソリューションに届ける前に、SaaS ログを共通のフォーマットに正規化する。
  −ユーザー名などのユーザー情報を含むイベント、監査、活動、その他のログエントリを企業アイデンティティに正規化し、異なる SaaS アプリケーションで異なるユーザー名／ユーザーアカウントを持つ同一人物に関連するイベントを相関付けられるようにする。
  −各 SaaS サブスクリプションにおいて、アクションとログエントリの可用性との間に予想される平均および最大遅延を文書化し、把握する。

[SaaSプロバイダーの責任]

• SaaS プロバイダーは、カスタマーがログ記録を有効にし、ログの時間ソースを利用できるようにするための機能を提供する責任を負う。

【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]

• カスタマーは、自身のシステム内でのログ記録を有効化し、管理する責任を負う。これには、Google Workspace も含まれる。

[Googleの責任]

• A.5.4(b) および (f) を参照のこと。そこには、Google Workspace の監査ログ機能に関する説明が含まれている。

上記の通り、SaaSユーザーは、自身のシステム内でのログ記録を有効化し、管理する責任を負う一方、SaaS プロバイダーは、カスタマーがログ記録を利用できるようにするための機能を提供する責任を負う。

しかしながら、Google Workspaceには、監査ログ（管理アクティビティ、システムイベント、ポリシー拒否）のほか、ユーザーのログイベント、ドライブのログイベント、APIで取得される使用状況データ、メールログ、デバイスのログイベントデータなど、様々なログが存在しており、各々のログの保存期間も異なっている。そのような状況下で、標準的なGoogle管理コンソールを利用するか、それともサードパーティ製のログ管理ツールを利用するかなどの判断は、SaaSユーザーに委ねられることになる。

SaaSユーザーはモバイル／IoTデバイス上のセキュリティ設定に注意

なお、「A.6.セキュア化／保護: セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する」には、[Google Workspaceユーザーの責任]のみが明記されており、[Googleの責任]が「該当なし(N/A)」になっている管理項目が存在する。具体的には、以下のような管理項目である。

【サイバーエッセンシャルズ】
A.6.4 (e)<要求事項>
自動的にオープンネットワークに接続する機能や、バックアップやマルウェア対策ソリューションなどを除く不要なプログラムの自動実行機能は無効化される必要がある。
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、ITシステムを構成して、オープンネットワークへの自動接続や不要なプログラムの自動実行を回避する責任を負う。

【サイバーエッセンシャルズ】
A.6.4 (g)<推奨事項>
グッドプラクティスとして、組織の資産において15分間の非アクティブ状態の後に自動ロック／セッションログアウトを有効にする必要がある。これには、ノートパソコン、サーバー、非モバイルデバイス、データベース、管理者ポータルでのユーザーセッションが含まれる。
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、非アクティブなユーザーセッションの後に資産をロックするようにシステムを構成する責任を負う。

【サイバーエッセンシャルズ】
A.6.4 (h)<推奨事項>
認証の範囲にモバイルデバイス、IoTデバイス、および／またはクラウド環境が含まれる場合：
– モバイルデバイス（例：携帯電話、タブレット）：
*モバイルデバイスは、ジェイルブレイクやルート化されてはならない。
*モバイルデバイスのパスコードを有効にする必要がある。
*非アクティブ状態が2分間続いた場合に、自動でモバイルデバイスがロックされる機能を有効にする必要がある。
*モバイルアプリケーションは、公式または信頼できるソースからのみダウンロードする必要がある。
–IoTデバイス：
*IoTデバイスをホストするネットワークは、組織の資産およびデータを含むネットワークから分離する必要がある。
*IoTデバイスのセキュリティ機能（例：デバイスの自動検出機能やUniversal Plug and Play（UPnP）の無効化）を有効にする必要がある。
*IoTデバイスを選定する際、（利用可能な場合）Cybersecurity Labelling Scheme（CLS）で評価されたデバイスを使用する必要がある。
– クラウド：
*クラウドの可視性を確保するために、セキュリティログおよび監視機能を有効化する必要がある（例：アプリケーションプログラミングインタフェース（API）コール履歴、変更の追跡、コンプライアンス）。
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、自身の資産の使用状況を管理および監視する責任を負う。これには、Google Workspace のようなクラウド環境も含まれる。

「サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド」では、SaaSユーザーの責任範囲として「SaaS内のユーザー設定」および「ログ記録の管理」を位置づけているが、上記で挙がっている管理項目をみると、SaaS環境だけでなくオンプレミス環境にも共通するようなテーマが目立つ。たとえばモバイル／IoTデバイス環境のSaaSユーザーは、デバイス経由で、オンプレミス環境にあるシステムと行き来するケースが当たり前なので、注意しておく必要がある。

SaaSプロバイダーとしてのGoogle Workspaceは、CSA STAR認証を取得しており、Consensus Assessments Initiative Questionnaire (CAIQ) v4.0.2の自己評価結果をCSA本部サイトで公開している（https://cloudsecurityalliance.org/star/registry/google/services/google-workspaces）。これやGoogle Workspaceの企業規模別セキュリティチェックリスト（https://support.google.com/a/answer/9184226）などのリソースを参照すると、SaaSプロバイダー側の対応状況が理解でき、SaaSユーザー側の管理策を策定する際に役立てることができる。

CSAジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司