前回は、機械学習モデルの開発から運用・保守までを一貫して管理・自動化する「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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司