海外に学ぶSMBのクラウドセキュリティ基礎（OTセキュリティ編）(2)

コメントをどうぞ

海外に学ぶ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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

SaaS Security Capability Framework（SSCF）v1.0のご紹介：SaaSセキュリティのレベルを向上させる

コメントをどうぞ

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

SaaS Security Capability Framework（SSCF）v1.0のご紹介：
SaaSセキュリティのレベルを向上させるフォームの始まり

CSA EMEA, AVP of GRC Solutions、Eleftherios Skoutaris

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

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

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

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

SSCF v1.0の登場

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

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

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

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

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

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

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

v1.0の内容

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

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

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

なぜこれが重要なのか

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

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

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

今後の展望

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

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

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

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

以上

海外に学ぶSMBのクラウドセキュリティ基礎（OTセキュリティ編）(1)

コメントをどうぞ

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

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

過去にSMBユーザーを対象とする「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」および「サイバートラストマーク: クラウドセキュリティコンパニオンガイド」（2023年10月13日公表）（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security-for-organisations）を紹介したが、これらと並行して、シンガポールサイバーセキュリティ庁は、2024年8月20日に「制御技術(OT)サイバーセキュリティマスタープラン2024」を公表している（https://www.csa.gov.sg/resources/publications/singapore-s-operational-technology-cybersecurity-masterplan-2024）。

このマスタープランは、国家の重要インフラを支えるOTシステムのサイバーセキュリティ強化を目的とした戦略的計画で、2019年に初版が策定された。これは、産業用制御システムを運用する組織や、物理的制御機能を支えるOT技術を活用する組織のセキュリティとレジリエンスを強化するための継続的な取り組みである。2024年版マスタープランは、OTエコシステムの成熟度の進展と、地政学的・技術的変化に伴いOTシステムを標的とするサイバー脅威の性質が急速に変化している現状を反映している。

2024年版では、「人材」「プロセス」「技術」の各領域における以下のような内容が示されており、OTシステムや技術を運用する各分野のサイバーセキュリティ強化に向けた継続的な取り組みの一環として位置づけられている：

  1. OTサイバーセキュリティ人材パイプラインの強化
  2. 情報共有と報告体制の強化
  3. 重要インフラ（CII）を超えたOTサイバーセキュリティレジリエンスの向上
  4. OTサイバーセキュリティのCentre of Excellenceの設立と、OTシステムのライフサイクル全体にわたるSecure-by-Deploymentの推進

シンガポールのサイバーセキュリティコンパニオンガイドをOTセキュリティに拡大

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

[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/）も改定されている。

OTセキュリティ固有の管理策を支える組織体制の整備が課題

ここからは、スタートアップ／SMBを対象としたサイバーエッセンシャルズマークの各管理策項目において、OTセキュリティ固有の管理策および具体的な対策例を紹介していく。参考までに、サイバーエッセンシャルズマークの管理策は、以下のような構成になっている。

A.1 資産: 人々 – 従業員に、防衛の最前線となるノウハウを装備させる
A.2 資産: ハードウェアとソフトウェア – 組織が何のハードウェアとソフトウェアを所有しているかを知り、それらを保護する
A.3 資産: データ – 組織が何のデータを持っているのか、どこにあるのか、データをセキュア化しているのかについて知る
A.4 セキュア化／保護: ウイルスおよびマルウェアの保護 – ウイルスやマルウェアのような悪意のあるソフトウェアから保護する
A.5 セキュア化／保護: アクセス制御 – 組織のデータやサービスへのアクセスを制御する
A.6 セキュア化／保護: セキュアな構成 – 組織のハードウェアやソフトウェアのために、セキュアな設定を使用する
A.7 アップデート : ソフトウェア・アップデート – デバイスやシステム上のソフトウェアをアップデートする
A.8 バックアップ: 不可欠なデータのバックアップ – 組織の不可欠なデータをバックアップして、オフラインに保存する
A.9 対応: インシデント対応 – サイバーセキュリティインシデントを検知し、対応して、復旧の準備をする

最初に、（A.1 人的資産）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. OT人材の育成と能力強化
・OT環境に特化したサイバーセキュリティ教育プログラムの導入
・現場技術者向けのハンズオン訓練（例：ICS/SCADAシステムの脆弱性対応）
・サイバー演習の定期的な実施（模擬攻撃シナリオを含む）
2. 意識向上と責任の明確化
・OT従業員に対するセキュリティ意識向上キャンペーン（ポスター、動画、クイズなど）
・OT資産に関わる役割ごとのセキュリティ責任の明確化（例：保守担当 vs 制御担当）
3. OT環境におけるアクセス管理の教育
・物理アクセスと論理アクセスの違いを理解させる教育
・特権アクセスのリスクと管理策（例：ジャンプサーバーの利用、ログ監査）
4. サードパーティ・ベンダーへの教育と契約管理
・外部保守業者やベンダーに対するOTセキュリティ研修の義務化
・契約書にセキュリティ要件（例：インシデント報告義務、アクセス制限）を明記
5. インシデント対応能力の強化
・OT環境に特化したインシデント対応手順の訓練
・OTとITの連携体制の構築（クロスファンクショナルなCSIRT）

人的資産面に関しては、クラウドセキュリティの場合、ユーザー組織が責任を負うが、OTセキュリティになると、OT組織とIT組織が責任を共有する形態が一般的である。特に、OT環境では、人的ミスが重大な物理的影響を及ぼすため、教育と責任の明確化が特に重要になる。

次に、（A.2 ハードウェアとソフトウェア）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. OT資産の可視化とインベントリ管理
・OT機器（PLC、RTU、HMIなど）の物理・論理構成を網羅した資産台帳の整備
・ネットワークセグメントごとの資産分類（例：制御層、監視層、運用層）
・自動検出ツールによる定期的な資産スキャン（パッシブ型推奨）
2. レガシー機器の保護とリスク評価
・サポート終了済みの機器に対する補完的な防御策（例：ネットワーク分離、仮想パッチ）
・レガシー資産の脆弱性評価とリスク優先度の定期見直し
3. ソフトウェア構成と更新管理
・制御系ソフトウェア（SCADA、DCS等）のバージョン管理と変更履歴の記録
・アップデート前の影響評価とテスト環境での検証（本番環境への即時適用は避ける）
・ベンダー提供のセキュリティパッチ情報の定期収集と適用計画
4. OTネットワークのセグメンテーションとアクセス制御
・IT/OT間の境界にファイアウォールやデマリケーションゾーンを設置
・OT資産へのアクセスはホワイトリスト方式で制限
・リモートアクセスはジャンプサーバー経由＋多要素認証を必須化
5. OT資産のライフサイクル管理
・導入時のセキュリティ要件チェック（例：暗号化通信、ログ機能）
・廃棄時のデータ消去と物理破壊の実施
・保守契約にセキュリティ更新・監査対応を含める

このようにOTセキュリティ固有の管理策としては、ITとは異なる制約やリスクを踏まえた対応が求められる。

次に、（A.3 データ）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. OTデータの分類と所在の明確化
・制御ログ、プロセスデータ、イベント履歴などのデータ種別を分類
・データの保存場所（オンプレミスのHMI、SCADAサーバー、エッジデバイスなど）を特定
・データフローの可視化（センサー → PLC → SCADA → Historian）
2. 機密性・完全性・可用性（CIA）の優先順位付け
・OT環境では「可用性」が最優先となるため、リアルタイム性を損なわない保護策を設計
・機密性が高いデータ（例：製造レシピ、工程パラメータ）には暗号化を適用
・完全性を担保するための改ざん検知（例：ハッシュ値、ログ監査）
3. データ保護とバックアップ
・OTシステムに特化したバックアップ手法（例：イメージベースの定期取得、オフライン保管）
・バックアップ対象の優先順位付け（制御設定、履歴データ、構成ファイル）
・リストア手順の定期的な検証（本番環境に影響を与えない方法で）
4. データアクセス制御と監査
・OTデータへのアクセスは職務ベースで制限（RBACの導入）
・外部ベンダーや保守業者によるアクセスは一時的かつ監査可能な方法で提供
・アクセスログの保存と定期レビュー（異常なアクセスの検知）
5. データのライフサイクル管理
・データ保持期間の定義（例：運用データは3年、監査ログは5年）
・廃棄時の安全な削除（例：物理破壊、データ消去ツール）
・データ移行時のセキュリティ（例：新SCADAシステムへの移行）

OTセキュリティ固有の管理策については、物理的な制御システムとデジタルデータが交差するOT環境ならではの特性を踏まえて設計する必要がある。また、これらの管理策は、OT環境の「止められない」「外部とつながりにくい」「レガシーが多い」といった特性を踏まえた、実践的かつ現場志向のものである必要がある。特に、リアルタイム制御とデータ保護のバランスが重要になってくる。

次に、（A.4 ウイルス・マルウェア対策）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. アンチマルウェア対策の適用判断
・OT機器へのウイルス対策ソフトの導入は、リアルタイム制御への影響を評価した上で慎重に実施
・SCADA/HMIサーバーなど、Windowsベースの機器には軽量型アンチウイルスを導入
・リアルタイム性が重要な制御機器（PLC等）には、代替策としてネットワーク監視や仮想パッチを適用
2. ネットワーク分離と境界防御
・IT/OT間の通信を制限するファイアウォールやDMZの設置
・外部接続（USB、リモートアクセス）に対する制限と監視
・OTネットワーク内でのマルウェア拡散を防ぐセグメンテーション
3. メディア制御と検疫
・USBメモリや外部媒体の使用を原則禁止、または専用検疫端末でスキャン
・メディア使用履歴の記録と定期監査
4. マルウェア検知とログ監視
・OT環境に特化したIDS/IPS（例：プロトコル認識型）による異常検知
・ログ収集・分析によるマルウェア兆候の早期発見（例：異常な通信、プロセス変更）
5. インシデント対応体制の整備
・OT環境におけるマルウェア感染時の封じ込め手順（例：ネットワーク遮断、手動制御への切替）
・IT/OT連携型CSIRTの構築と定期的な模擬演習
6. ベンダー管理と保守作業のセキュリティ
・外部ベンダーによる保守作業時のマルウェアリスクを最小化（例：事前スキャン、限定アクセス）
・ベンダー契約にセキュリティ要件（マルウェア対策、報告義務）を明記

OTセキュリティ固有の管理策については、IT環境とは異なる制約（例：リアルタイム性、レガシー機器、可用性重視）を踏まえた対応が必要である。また、OT環境では「止めない防御」が基本なので、予防と検知のバランスがカギになってくる。

次に、（A.5 アクセス制御）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. 物理アクセスの制御
・制御室や機器設置場所への入退室管理（例：ICカード、監視カメラ）
・OT資産への物理的アクセスは職務ベースで制限（保守担当者のみ許可）
2. 論理アクセスの制御
・OTシステムへのログインは個人ID＋強固な認証（例：MFA、トークン）
・制御機器（PLC、RTU等）へのアクセスはホワイトリスト方式で制限
・アクセス権限は最小限に設定
3. ロールベースアクセス制御（RBAC）の導入
・操作員、保守員、監視員などの役割に応じたアクセス権限の定義
・権限変更は承認制＋ログ記録を義務化
4. リモートアクセスの制限と監視
・リモート保守はジャンプサーバー経由＋一時的な認証で実施
・VPN接続は時間制限＋監査ログの取得を必須化
・外部接続は原則禁止、例外時は事前申請と検疫を実施
5. アクセスログの記録と監査
・OT資産へのアクセス履歴を自動記録（例：SCADAログ、HMI操作履歴）
・定期的なログレビューと異常検知（例：深夜のアクセス、権限外操作）
6. サードパーティ管理
・外部ベンダーのアクセスは契約で制限（例：アクセス時間、操作範囲）
・ベンダーごとのアクセス履歴を分離管理

OTセキュリティ固有の管理策については、制御系システムの可用性と安全性を守るために、ITとは異なるアプローチが必要である。OT環境では、「誰が、いつ、どこから、何をしたか」を明確にすることが、事故や攻撃の早期発見につながる。

次に、（A.6 セキュアな構成）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. 初期設定の見直しと不要機能の無効化
・OT機器（PLC、HMI、SCADA等）の初期設定（デフォルトパスワード、ポート開放）をすべて確認・変更
・使用しないサービスやプロトコル（例：Telnet、FTP）は無効化
・制御機器のファームウェア設定も含めてセキュアな構成を文書化
2. セキュリティベースラインの策定
・OT資産ごとにセキュリティ設定のベースラインを定義（例：SCADAサーバーのログ設定、HMIのユーザー権限）
・ベースラインからの逸脱を検知する仕組み（例：構成変更監視）
3. 設定変更の管理と承認プロセス
・構成変更は事前承認制＋変更履歴の記録
・ベンダーによる設定変更も含めてログ取得とレビューを実施
・変更前のバックアップ取得とロールバック手順の整備
4. OT機器のセキュアな導入と廃棄
・新規導入時はセキュリティ要件（暗号化通信、認証機能）を満たす機器を選定
・廃棄時は設定情報の完全消去と物理破壊を実施
5. セキュリティ設定の定期レビュー
・半期または年次で構成設定の棚卸しとリスク評価を実施
・ベンダー提供のセキュリティガイドラインに基づく設定見直し
6. IT/OT融合環境での構成管理
・IT側のセキュリティポリシーがOTに影響しないよう、分離された構成管理体制を確立
・OT環境におけるセキュリティ設定は、可用性優先の原則に基づいて調整

OTセキュリティ固有の管理策については、制御系システムの安定性と可用性を維持しながら、設定ミスや脆弱性を防ぐための工夫が求められる。特に重要インフラや製造業では設定ミスが事故につながる可能性があるため、構成管理は極めて重要な領域となっている。

次に、（A.7 ソフトウェア・アップデート）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. アップデートのリスク評価と事前検証
・制御系ソフトウェア（SCADA、DCS、HMI等）の更新は、事前に影響評価を実施
・テスト環境での動作確認を必須化（本番環境への即時適用は避ける）
・アップデートによる停止リスクを最小化するため、更新は計画停止期間中に限定
2. アップデート対象の優先順位付け
・セキュリティパッチの緊急度に応じて分類（例：重大脆弱性は即時対応、機能改善は延期）
・レガシー機器には仮想パッチやネットワーク制御による代替策を検討
3. ベンダーとの連携による安全な更新
・ベンダー提供のアップデート情報を定期的に収集し、適用可否を判断
・アップデート手順はベンダー監修のもとで実施し、ログを取得
4. 更新プロセスの文書化と監査
・アップデート手順書、影響評価記録、テスト結果を文書化
・更新履歴を資産台帳と紐づけて管理し、定期監査を実施
5. 自動更新の無効化と手動管理
・OT機器では自動更新を無効化し、手動による制御を徹底
・IT環境との連携部分（例：データ収集サーバー）には更新通知の監視を導入
6. アップデート後の安定性確認
・更新後は一定期間の監視を強化し、異常動作の有無を確認
・不具合発生時のロールバック手順を事前に準備

OTセキュリティ固有の管理策については、可用性重視の制御環境において“更新＝リスク”となる可能性を踏まえた慎重な運用が求められる。OTでは、更新しないという判断も時には必要となるので、最新の注意が必要である。

次に、（A.8 バックアップ）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. バックアップ対象の明確化
・制御設定、構成ファイル、履歴データ、イベントログなど、復旧に不可欠なデータを特定
・PLCやSCADAのプロジェクトファイル、HMI画面構成なども対象に含める
2. オフライン・バックアップの実施
・ランサムウェア対策として、ネットワークから隔離されたオフライン媒体（例：外付けHDD、テープ）に定期保存
・オフライン媒体は物理的に施錠された場所で保管
3. バックアップの頻度とスケジュール管理
・制御系データは変更頻度に応じて日次・週次で取得
・重要イベント（例：設備更新、設定変更）後は即時バックアップを実施
4. バックアップの整合性確認とリストア検証
・定期的にバックアップファイルの整合性チェック（ハッシュ値照合など）
・テスト環境での復元検証を実施し、復旧手順を文書化
5. バックアップの分散保管
・災害対策として、異なる物理拠点にコピーを保管（例：工場外部の保管庫）
・クラウド利用時は、OT環境に適したセキュリティ要件（暗号化、アクセス制限）を満たすこと
6. バックアップ操作の権限管理と監査
・バックアップ作業は特定の担当者に限定し、操作ログを取得
・外部ベンダーによるバックアップは事前承認制＋監査対象とする

OTセキュリティ固有の管理策については、制御系システムの可用性とレジリエンスを重視した設計が求められる。特に重要インフラでは、復旧の速さが安全確保の鍵となるので、注意が必要である。

最後に、（A.9 インシデント対応）におけるOTセキュリティ固有の管理策および具体的対策例を整理すると以下のようになる。

1. OT環境に特化したインシデント対応計画の策定
・制御系システムの停止リスクを最小化するため、ITとは分離した対応フローを設計
・「切り離す」「手動制御に切り替える」など、物理的対応を含む手順を明記
・重要設備のフェイルセーフ動作を確認し、対応計画に反映
2. OT/IT連携型CSIRTの構築
・OT技術者とITセキュリティ担当が連携するクロスファンクショナルな対応チームを編成
・OT特有のプロトコルや機器構成に精通したメンバーを含める
3. インシデント検知の強化
・OT環境に特化したIDS/IPS（例：Modbus、DNP3対応）を導入
・制御ログやイベント履歴をリアルタイムで監視し、異常動作を早期検知
4. 初動対応と封じ込め手順の整備
・感染・侵害が疑われる機器のネットワーク遮断手順を明文化
・制御系の手動操作への切替手順を現場レベルで訓練
・外部ベンダーとの連携体制（緊急連絡先、対応契約）を整備
5. 復旧手順とバックアップ活用
・事前に取得したオフライン・バックアップからの復元手順を文書化
・復旧後の構成確認と再感染防止策（例：再設定、ログ監査）を実施
6. インシデント後のレビューと改善
・インシデント対応後は、OT環境に特化した事後レビューを実施
・対応手順の改善、教育内容の見直し、構成変更の検討を含める

OTセキュリティ固有の管理策としては、制御系システムの可用性を守りながら、迅速かつ安全に対応・復旧するための体制づくりが重要でなる。特に重要インフラや製造業では、止めない対応が必要となるケースが多いので、インシデント対応については、「技術」だけでなく「現場力」を強化しておく必要がある。

このように、サイバーエッセンシャルズのOT拡張版では、組織がOT環境をどのように保護し、OTとITの融合を安全に管理するかについての指針を提供している。OTは一般的にITよりも投資サイクルが長いため、OT環境にはレガシーな機器・システムが存在し、セキュアなパスフレーズなどの強力なアクセス制御に対応していない場合がある。従って組織は、物理的なアクセス制御やネットワークのセグメンテーションなど、代替的な制御策を用意しておく必要がある。

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

海外に学ぶSMBのクラウドセキュリティ基礎（AIセキュリティ編）(2)

コメントをどうぞ

前回は、シンガポールサイバーセキュリティ庁のスタートアップ／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のクラウドセキュリティ基礎（AIセキュリティ編）(1)

コメントをどうぞ

海外に学ぶ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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

AI Controls Matrix (AICM) 速報

コメントをどうぞ

AI Controls Matrix (AICM) 速報

2025年7月10日
諸角　昌宏

本ブログは、2025年7月10日にCSA本部が公開したAI Control Matrix (AICM)について、その概要を説明します。

  1. AICMとは？

    AICMは、クラウドにおけるセキュアで信頼性の高いAIシステムのためのフレームワークを提供する管理策集です。組織がAI技術をセキュアかつ責任ある方法で開発、導入、および活用するための支援を目的とした管理策のフレームワークとなります。
    今回、CSA本部から、AIセキュリティとガバナンスのための最初のベンダーニュートラルフレームワークとして公開されました。AICMでは、以下の点で組織をサポートすることができます。

    • AI固有のリスクを評価し、管理する
    • 信頼性の高いAIシステムを構築する
    • 国際基準に準拠する

  2. AICMの構成

    AICMでは、以下の18のドメインと243の管理策で構成されます。以下が18のドメインの内容です。AICM固有に追加されたドメインがModel Security(MDS)で、それ以外の17のドメインはCCM（Cloud Controls Matrix）のドメインで、CCMのドメインにAICMとしての管理策が記述されています。

  3. AICMのアーキテクチャ

    AICMの各管理策は、以下の内容を含んでいます。

    • Control Type
      管理策がAI向け、クラウド向け、AIとクラウド向け（AI-Specific, Cloud-Specific, Cloud&AI-Related）のいずれかを明示。
    • Control Applicability and Ownership
      管理策の所有者（Cloud Service Provider(CSP), Model Provider(MP), Application Provider(AP)）を表示、および、その責任共有モデル
    • Architectural Relevance – GenAI Stack Components
      対象となる物理インフラ（Network, Compute, Storageなど）
    • Lifecycle Relevance
      AIライフサイクルのうち、対象となるステージ（Preparation, Development, Evaluation, Deployment, Service Retirement）。責任を持つチーム（GRC Team, Internal Audit Team）。
    • Threat Category
      管理策に想定される脅威

  4. AICMの現在の提供状況

    下の図が、AICMとして提供するコンポーネント。また、赤で囲った部分が今回提供されたコアの部分です（MappingについてはBSI AIC4とNIST AI 600-1 (2024)を提供）。
    今後の予定

    • ISO42001とのマッピング（現在公開レビュー中）
    • Implementation Guidelines（現在公開レビュー中）
    • EU AI Actとのマッピング（作業中）
    • Auditing Guidelines（作業中）

  5. 参照

以上

 

ValidAIted　ー　CSAの最新STARレベル1セルフアセスメントツール

コメントをどうぞ

Valid-AI-ted
CSAの最新STARレベル1セルフアセスメントツール

2025年6月16日
日本クラウドセキュリティアライアンス　諸角昌宏

本ブログは、CSA本部が公開している「Valid-AI-ted Overview」の日本語訳です。また、本ブログのPDF版は、こちらからダウンロードできます。

なお、本ブログと原書（「Valid-AI-ted Overview」）の内容に差異があった場合には、原書の内容が優先されます。

Security, Trust, Assurance & Risk（STAR）プログラムのアップグレード

CSAのValid-AI-tedツールは、STARレベル1のセルフアセスメント（自己評価）の新しい方法です。最先端のLLM技術を用いて強化されたこの機能は、STARレベル1のセルフアセスメントで提供している情報の自動品質チェック機能を提供します。”Valid-AI-ted “は、”validated “と発音し、この新しいツールにおけるAIの革新的な利用を強調しています。

Valid-AI-tedにセルフアセスメント結果を提出すると、プロバイダーはすぐに詳細なフィードバックと修正ガイダンスを受け取ります。プロバイダーは、継続的な改善を奨励するため、最大10回まで再提出を行うことができます。合格すると、プロバイダーは、Valid-AI-tedのSTARレベル1バッジを獲得し、コンプライアンスをアピールすることができます。

Valid-AI-tedのメリット

CSAのValid-AI-tedツールは、AIを使用したクラウドセキュリティ評価の自動化という点でユニークです。このツールは、STAR レベル 1 の申請に対して、正確で客観的かつ迅速な検証を提供します。さらに、Valid-AI-tedは以下を提供します。

  • 保証の向上。従来のSTARレベル1のセルフアセスメントでは、プロバイダーの回答の質には大きなばらつきがありました。Valid-AI-tedは、セルフアセスメントが慎重に実施され、組織が強固なセキュリティベースラインを達成したことを保証します。
  • 定性的なベストプラクティス分析Valid-AI-tedは、クラウドコントロールマトリックス（CCM）による実証済みのimplementation guidanceに基づき、標準化されたスコアリングモデルを実施します。
  • より実用的な洞察。合格、不合格に関わらず、組織は、管理策ごとにきめ細かなフィードバックを受け、改善が必要な領域を強調できます。
  • STAR Registryにおける認知度の向上。STAR Level 1 Valid-AI-tedバッジを持つ組織は、顧客、パートナー、規制当局に対して、チェックボックスによるコンプライアンスを超えていることを示すことができます。
  • 継続的改善への容易なアクセス。修正と再提出が可能なため、成熟しつつある組織にとって理想的であり、STAR Level 2の第三者評価ソリューションに向けた、より利用しやすい道筋を提供します。

CSAプログラムの強力な組み合わせ

AI Safety Initiative:　AIブームへの対応として、CSAは2024年にAI Safety Initiativeを立ち上げました。この業界の連携は、さまざまな背景を持つ専門家で構成され、力を合わせて不可欠なAIガイダンスを提供し、組織が安全で責任あるAIソリューションを展開できるようにします。AI Safety Initiativeの活動により、CSAはセキュリティに配慮したAI開発の最前線に立つことになります。

リサーチ:　CSAは、ベンダーニュートラルなリサーチと専門教育のための機敏なプログラム、および業界エキスパートと支部によるグローバルなフットプリントにより、クラウドサービスプロバイダーのニーズとペインポイントを常に念頭に置いた、権威あるAIツールを構築しています。

STAR:　2011年に開始されたSTARプログラムは、長い歴史と信頼を得ています。世界中で、STARのエントリーは、クラウドサービスの信頼性を示す指標として、民間部門と公共部門の両方で使用されています。イタリアのように、公的部門や重要インフラに対する国家要件遵守のメカニズムとしてSTARを公式に使用している国もあります。この主要な認証プログラムは、Valid-AI-tedのような市場初のAIコンプライアンスツールをサポートするために、長年にわたって確立された強固な基盤を提供しています。

Valid-AI-tedの仕組み

  1. 完成したCAIQ（STARレベル1セルフアセスメント）をSTARプラットフォーム上の安全なポータルから提出してください。開始前に$595の料金をお支払いいただきます。
    • この料金で、1年以内に10回のスコアリングを試みることができます。
    • 複数の製品/サービスをSTAR Registryに掲載する場合は、複数の提出書類に記入し、製品/サービスごとに$595を支払う必要があります。
    • CSA会員はValid-AI-tedに無料で利用できます。
    • スコアを最適化するには、セルフアセスメントの「CSP Implementation Description」カラムに、Y/N の各回答の説明を行う必要があります。
  2. Valid-AI-tedは、提出が完了したことを確認し、回答を処理し、合否ステータス、ドメインスコア、および改善のための推奨事項を含む詳細なレポートを作成します。
  3. 合格すると、Valid-AI-tedバッジが発行され、STARレジストリに表示されます。このデジタルバッジを自身のプラットフォームに表示し、信頼できるステータスをオーディエンスにアピールすることが推奨されます。Valid-AI-tedバッジは、将来的な継続的検証のアップデートがあるまで、現在のところ有効期限はありません。

さらに詳しく

Valid-AI-ted の詳細と申請については、CSA STAR のウェブサイトをご覧ください。Valid-AI-tedに関するご質問や、この新しいツールの活用方法については、support@cloudsecurityalliance.org までお問い合わせください。

CCSKv5 合格体験記

コメントをどうぞ

【CCSKv5 合格体験記】

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

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

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

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

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

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

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

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

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

2. CCSKv5の試験概要・特徴

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）Microsoft(2)

コメントをどうぞ

海外に学ぶ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)]

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

アカウント管理は、エンドユーザー組織（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)]

物理的なアクセス制御は、エンドユーザー組織（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)]

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

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

参考までに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)]

パスワード管理については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のクラウドセキュリティ基礎（CSP編）Microsoft(1)

コメントをどうぞ

海外に学ぶ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 Azure) の責任]

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 Azure) の責任]

前述の通り、クラウドのウイルス／マルウェア保護の責任の大部分は、クラウドプロバイダーにあるが、一部のウイルス／マルウェア配布の経路は、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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司