海外に学ぶ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)プログラムのアップグレード

CSAValid-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. 完成したCAIQSTARレベル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ジャパン関西支部メンバー
健康医療情報管理ユーザーワーキンググループリーダー
笹原英司

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

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

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

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

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

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

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

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

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

[組織は何をすべきか]

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

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

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

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

海外に学ぶSMBのクラウドセキュリティ基礎(CSP編)Google Cloud(1)

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

Google Workspaceの管理策におけるユーザーとCSPの関係

今回取り上げるのは、SMBユーザーを対象とする「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に準拠した「サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド– Googleとの共同開発による(2023年10月13日公表)」である。これらのガイドは、シンガポールサイバーセキュリティ庁(CSA)のWebサイトより無料でダウンロードできる。

Google Workplace版ガイドは、「サイバーエッセンシャルズマーク: クラウドセキュリティコンパニオンガイド」に従って、以下のような構成になっている。

  • イントロダクション
  • 資産
    • A1. 人々
    • A2. ハードウェアとソフトウェア
    • A3. データ
  • セキュア化/保護
    • A4. ウイルスとマルウェアの保護
    • A5. アクセス制御
    • A6. セキュアな構成
  • アップデート
    • A7. ソフトウェアのアップデート
  • バックアップ
    • A8. 不可欠なデータのバックアップ
  • 対応
    • A9. インシデント対応

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

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

最初に「A1. 人々– 従業員に、防衛の最前線となるノウハウを装備させる」では、セキュリティトレーニングやサイバーハイジーンといった人的対策について記述している。

たとえば、サイバーセキュリティトレーニングについては、各ガイドで、下記の通り要求事項に基づく管理策を提示している。

————————————————
【サイバーエッセンシャルズ】
A.1.4(a) <要求事項>
組織は、すべての従業員が、セキュリティプラクティスや期待される行動を意識していることを保証するために、サイバーセキュリティ意識向上トレーニングを設定すべきである。組織は、この要求事項を様々な方法で充足する可能性がある(例. 従業員または関与する外部トレーニング プロバイダー向けに自己学習教材を提供する)。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
[エンドユーザー組織(SaaSカスタマー)の責任]
•エンドユーザー組織(SaaSカスタマー)は、単独で責任を負う
<なぜこれが重要か>
•ますますビジネスユーザー(IT部門と対照的に)は、SaaSアプリケーションにアクセスして管理しており、SaaSのセキュリティを管理するために、適切な装備を備えていない可能性がある。
• ヒューマンエラーは、クラウドリスクの主要な要因の一つとして広く認識されている。
<組織は何をすべきか>
• 従業員向けの一般的なサイバー意識向上トレーニングの範囲を越えて、組織は、SaaSを管理するビジネスユーザーが、なぜクラウドセキュリティにおいて重要な役割を果たすのか、どのようにしてクラウド上でセキュリティを運用できるのかについて理解するためのトピックを含めるべきである。
[クラウドプロバイダーの責任]
•主要クラウドプロバイダーは、ベストプラクティスを公開し、クラウドカスタマーに対してよりよいサポートを提供する。
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
•カスタマーは、従業員にどのようなトレーニングを提供するかを決定する責任がある。これには、GoogleのWorkspaceを安全に使用する方法に関する資料をどのように取り入れるか、またその他のセキュリティベストプラクティスを採用するか否かが含まれる。
[Googleの責任]
•Google Workspace を利用するカスタマーは、Google Cloud セキュリティショーケースのコンテンツのトレーニングプログラムへの組み込みを決定することができる。これは、Google のプロダクトマネージャーが実施するオンデマンドのトピック別ビデオトレーニングセッションである。関連するコンテンツの例として、「Google Workspace に導入すべき重要なセキュリティコントロールは何か?」や「Gmail アカウントをフィッシングやマルウェア攻撃から保護する方法」がある。
•Google のセーフティセンターも、ユーザーがオンラインで安全を保つのに役立つ一連の一般的なツールとヒントを提供している。これには、Google のユーザーがプライバシーを保護し、詐欺を避けるために取るべき具体的な推奨ステップが含まれる。
さらに一般的には、Google ユーザーは Coursera 経由で無料のサイバーセキュリティトレーニングや、より高度な Google サイバーセキュリティ証明書に関する情報を利用することができる。Google サイバーセキュリティ証明書の奨学金も、適格なビジネス向けに利用可能である。
————————————————

クラウドセキュリティコンパニオンガイドでは、セキュリティトレーニングの責任共有について、「エンドユーザー組織(SaaSカスタマー)は、単独で責任を負う」、「主要クラウドプロバイダーは、ベストプラクティスを公開し、クラウドカスタマーに対してよりよいサポートを提供する」と明記している。

これを受けてGoogle Workspaceクラウドセキュリティコンパニオンガイドでも、「カスタマーは、従業員にどのようなトレーニングを提供するかを決定する責任がある」とGoogle Workspaceを使用するカスタマーの責任を明記した上で、SaaSプロバイダーとしてのベストプラクティスや支援策について触れている。

参考までに、SaaSプロバイダー側では、「Google Workspace セキュリティ」(https://www.cloudskillsboost.google/course_templates/48?locale=ja)や「高度なセキュリティ」(https://workspace.google.com/intl/ja/security/threat-prevention/)など、具体的なトレーニングプログラムを公開している。

サイバーハイジーン

次に、サイバーハイジーンのプラクティス/ガイドラインに関しては、各ガイドで、下記の通り要求事項に基づく管理策を提示している。
————————————————
【サイバーエッセンシャルズ】
A.1.4(b) <要求事項>
サイバーハイジーンのプラクティスとガイドラインは、従業員が日々の業務に採用するために開発されるべきである。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
*A.1.4(a)と共通の内容
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、サイバーハイジーンのベストプラクティスを定義して作成する責任を負い、使用している主要なソフトウェア(例. Google Workspace)からの既存のサイバーハイジーンに関する推奨事項を取り入れることが可能である。
[Googleの責任]
Googleのセキュリティベストプラクティスのチェックリストには、一般従業員やIT担当者を含むさまざまなユーザー向けの推奨事項が含まれている。
————————————————

さらにサイバーハイジーンののうち、ヒューマンエラーに起因するインシデント軽減策に関しては、下記の通り推奨事項に基づく管理策を提示している。
————————————————
【サイバーエッセンシャルズ】
A.1.4 (c) <推奨事項>
サイバーハイジーンのプラクティスとガイドラインには、人為的な要因によるサイバーセキュリティインシデントを軽減するための以下のトピックが含まれるべきである:
– フィッシングから身を守る
– 強力なパスフレーズを設定し、それを保護する
– 企業用および/または個人用のデバイス(仕事に使用するもの)を保護する
– サイバーセキュリティインシデントを報告する
– 事業に重要なデータを慎重に取り扱い、開示する
– 現場およびリモートで安全に作業する
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
• これは、以下のようなクラウドの主なリスクと低減策に関するクラウド特有のトピックを含むべきである:
− クラウドリスクの主な要因の一つとしての人為的ミス
− クラウドにおける共有責任
− 身元やユーザーアクセスアカウントの侵害から生じるリスクと、それを低減するためのベストプラクティス
− 高度な権限を持つアカウントの誤用から生じるリスクと、それを低減するためのベストプラクティス
− 弱い設定を選択することによるリスクと、それを低減するためのベストプラクティス
− クラウド内でのデータの安全な管理
[エンドユーザー組織(SaaSカスタマー)の責任]
• これは、以下のようなクラウドの主なリスクと低減策に関するクラウド特有のトピックを含むべきである:
− クラウドリスクの主な要因の一つとしての人為的ミス
− クラウドにおける共有責任
− 身元やユーザーアクセスアカウントの侵害から生じるリスクと、それを低減するためのベストプラクティス
− 高度な権限を持つアカウントの誤用から生じるリスクと、それを低減するためのベストプラクティス
− 弱い設定を選択することによるリスクと、それを低減するためのベストプラクティス
− クラウド内でのデータの安全な管理
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、Google Workspaceなど外部クラウドサービスにおけるものを含む、不注意なミスから生じるITシステムのリスクに対処するために、自らのプラクティスとガイドラインを確実にする責任がある。
[Googleの責任]
カスタマーは、ビジネスの規模に基づいて分けられたGoogleのセキュリティベストプラクティスのチェックリストを参照することも可能である。
————————————————

参考までに、サイバーハイジーンに関連してシンガポールサイバーセキュリティ庁は、サイバーエッセンシャルズに定義されたサイバーハイジーン対策に基づいて、「組織のためのサイバーセキュリティ健康診断」(https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-health-check-for-organisations)を公開している。

SaaS利用時のローカル環境におけるハードウェア資産管理はユーザーの責任

次に「A2. ハードウェアとソフトウェア」では、SaaSユーザーが利用するハードウェアおよびソフトウェアに係るIT資産管理について記述している。

まず、ハードウェア資産(クラウド内)およびソフトウェア資産に係るIT資産目録の作成・維持に関して、下記の通り要求事項に基づく管理策を提示している。
————————————————
【サイバーエッセンシャルズ】
A.2.4 (a) <要求事項>
組織内のすべてのハードウェアおよびソフトウェア資産について最新の資産目録を維持する必要がある。組織は、この要件を満たすために、例えばスプレッドシートやIT資産管理ソフトウェアを使用してIT資産目録を維持するなど、さまざまな方法で対応することができる。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
• ハードウェア資産(クラウド内)の場合、SaaSはソフトウェア資産と見なされるため、エンドユーザー組織(SaaS顧客)には適用されない。
• ソフトウェア資産の場合、エンドユーザー組織(SaaS顧客)が責任を負う。
<なぜこれが重要か>
• SaaSモデルの人気が高まっており、組織は多数のSaaSサブスクリプションを管理している。
<組織は何をすべきか>
• さまざまな業務機能にわたるSaaSサブスクリプションのインベントリを追跡および監視するためのメカニズムを実装する。
• これは、プロセスまたは技術的なソリューションを通じて実現できる。例:
− すべてのSaaSの購入および取得を使用前にITおよびセキュリティに提出する手続き方法を通じて
− ファイアウォール、Webゲートウェイ、クラウドアクセスサービスブローカー(CASB)からのログの分析および評価を通じて
− SaaSセキュリティポスチャ管理(SSPM)ソリューションの使用を通じて
− SaaSに関連する項目に関する経費報告書および財務記録の分析を通じて
[クラウドプロバイダーの責任]
[クラウドインフラストラクチャプロバイダー]
ハードウェア資産については、クラウドインフラストラクチャプロバイダーが責任を負う
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、自らのローカル環境内のハードウェアと、Google Workspaceなどのクラウドベースのソフトウェア資産を含む、最新で包括的な資産目録を維持する責任がある。また、カスタマーはGoogle Workspaceを通じて利用可能なツールを使用して、資産目録の管理をサポートするかどうか、およびその方法を決定する責任がある。
[Googleの責任]
Google Workspaceにはデバイス在庫管理が含まれており、カスタマーはGoogle Workspaceに接続されている、またはアクセスに使用されているデバイス(例. コンピューター、ラップトップ、モバイルデバイス)を簡単に確認することができる。この在庫には、オペレーティングシステムのレベル、ブラウザのレベル、モデルなどの基本的な情報が含まれている。カスタマーはこの情報を抽出し、より広範な資産在庫管理の一部として使用することを選択できる。
————————————————

ソフトウェア資産管理については、SaaSユーザーが責任を負い、特にユーザー組織内におけるシャドーITの把握が課題となってくる。他方、ハードウェア資産管理については、SaaSプロバイダーがクラウド環境内の責任を負い、SaaSユーザーがローカル環境内の責任を負うと明記している。

ローカル環境のハードウェア資産管理に関連しては、SaaSプロバイダーが提供する標準的な支援機能のほか、ファイアウォール、Webゲートウェイ、CASB、SSPMなどサードパーティベンダーが提供する各種ソリューションを活用しながら、SaaSユーザーがインベントリ管理体制を構築・運用することが必要になってくる。

未認可・サポート切れSaaSのハードウェア・ソフトウエア資産管理

IT部門が発展途上段階にあるスタートアップ/SMB企業のSaaS利用時に課題となるのが、組織が認可していないハードウェアおよびソフトウェア資産や、サポート終了日(EOS)を迎えた資産の取扱いである。
各ガイドでは、未認可・サポート切れSaaSに係るIT資産管理に関して、下記の通り要求事項に基づく管理策を提示している。

【サイバーエッセンシャルズ】
A.2.4 (g) <要求事項>
認可されていないハードウェアおよびソフトウェア資産や、それぞれのサポート終了日(EOS)を迎えた資産は交換する必要がある。
【サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイド】
• サービス説明書や利用規約に記載されているとおり、SaaSプロバイダーのサポート終了(EOS)資産に関する義務を確認する。例. 移行または切り替えのための顧客へのリードタイム
【サイバーエッセンシャルズ向けGoogle Workspaceクラウドセキュリティコンパニオンガイド】
[Google Workspaceユーザーの責任]
カスタマーは、ローカル環境におけるシステム上の不適切な資産を交換する責任を負う。これには、Google Workspaceの無許可のサブスクリプションも含まれる。
[Googleの責任]
カスタマーのGoogle Workspaceインスタンスは、サブスクリプション期間の終了時にEOS期間に到達する。カスタマーがGoogle Workspaceのアクティブなサブスクリプションを維持している限り、インスタンスはEOSに到達しない。

たとえば、SaaSユーザーとSaaSプロバイダーの間のサブスクリプションが切れたり、サポートが切れたりした場合でも、引き続きローカル環境のIT資産管理を担うのはSaaSユーザーである。残存するサポート終了(EOS)資産に脆弱性があると、外部アクターの標的にされやすいので注意が必要である。

このように、該当するセキュリティ管理項目ごとに、責任共有モデルにおけるSaaSユーザー、SaaSプロバイダー、クラウドインフラストラクチャプロバイダーの関係性を明確化した点が、シンガポールのサイバーエッセンシャルズ向けコンパニオンガイドの特徴となっている。SaaSユーザーは、調達から廃棄に至るまでのライフサイクル全体で責任共有モデルを理解しておくことが不可欠である。

次回の「海外に学ぶSMBのクラウドセキュリティ基礎(CSP編)Google Cloud(2)」では、CSP側の責任が明記されていないセキュリティ管理項目に対するSaaSユーザー側の取扱いに焦点を当てる。

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