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

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

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

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

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

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

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

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

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

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

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

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

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

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

<なぜこれが重要か>

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

<組織は何をすべきか>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<なぜこれが重要か>

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

<組織は何をすべきか>

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

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

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

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

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

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

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

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

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

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

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

<なぜこれが重要か>

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

<組織は何をすべきか>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[組織は何をすべきか]

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

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

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

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

[Googleの責任]

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

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

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

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

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

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

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

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

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

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

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

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

海外に学ぶSMBのクラウドセキュリティ基礎（CSP編）AWS（1）に引き続き、今回は、シンガポールサイバーセキュリティ庁のサイバーエッセンシャルズおよびサイバートラストマークに基づいて開発されたAWSユーザー向けガイドにおけるセキュリティ管理策の事例を紹介する。

スタートアップ向けに軽量化したAWSユーザー向けクラウドセキュリティガイド

前回取り上げた「サイバートラスト向けAWS クラウドコンパニオンガイド – AWSとの共同開発」（https://d1.awsstatic.com/whitepapers/compliance/CSA_Cyber_Trust_mark_certification_Cloud_Companion_Guide.pdf）（2023年10月13日公表）には、物理的制御、保守制御などのコンプライアンストピックや、ポリシー、人事管理など、組織固有の要求事項が含まれていない。これによってガイドを軽量化し、中小／スタートアップ企業のライトユーザレベルでも活用できるよう、AWSサービスのセキュリティに関する考慮事項に焦点を当てている。

本ガイドでは、以下の12ドメインを設定している。

• B8. ドメイン：資産管理
• B9. ドメイン：データ保護とプライバシー
• B10. ドメイン：バックアップ
• B12. ドメイン：システムセキュリティ
• B13. ドメイン：ウイルス対策／マルウェア対策
• B14. ドメイン：セキュアソフトウェア開発ライフサイクル (SDLC)
• B15. ドメイン：アクセス制御
• B16. ドメイン：サイバー脅威管理
• B18. ドメイン：脆弱性評価
• B20. ドメイン：ネットワークセキュリティ
• B21. ドメイン：インデント対応
• B22. ドメイン：事業継続と災害復旧

以下では、「B8. ドメイン：資産管理」（組織は、環境内に存在するハードウェアおよびソフトウェアを特定し、一般的なサイバー脅威から保護している）に絞って、マッピングされたサブドメイン（[B.8.1]、[B.8.4]、[B.8.6]、[B.8.9]）とそれらに関連するAWSサービスの概要およびベストプラクティスを挙げる。

[B.8.1] 組織は、環境内に存在するハードウェアおよびソフトウェアを特定し、一般的なサイバー脅威から保護している。

(関連するAWSサービス)
(1)AWS Config（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/WhatIsConfig.html）

AWS Configは、AWSアカウント内のAWSリソースの構成の詳細なビューを提供する。これには、リソースが互いにどのように関連しているか、および過去にどのように構成されていたかが含まれており、構成や関係性が時間とともにどのように変化するかを見ることができる。

<AWS Configのセキュリティベストプラクティス>
•AWS Configでのデータ保護
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/data-protection.html）
•AWS ConfigのIDとアクセス管理
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-iam.html）
•AWS Configでのログ記録とモニタリング
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-logging-and-monitoring.html）
•AWS Configとインターフェイス Amazon VPC エンドポイントの使用
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/config-VPC-endpoints.html）
•AWS Configのインシデントへの対応
（ https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/incident-response.html）
•AWS Configのコンプライアンス検証
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/config-compliance.html）
•AWS Configの耐障害性
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/disaster-recovery-resiliency.html）
•AWS Configのインフラストラクチャセキュリティ
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/infrastructure-security.html）
•サービス間の混乱した代理の防止
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/cross-service-confused-deputy-prevention.html）
•AWS Configのセキュリティベストプラクティス
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-best-practices.html）

(2)AWS コストと使用状況レポート(CUR)（https://docs.aws.amazon.com/ja_jp/cur/latest/userguide/what-is-cur.html）

AWSコストと使用状況レポート（AWS CUR）には、利用可能な最も包括的なコストおよび使用状況データが含まれている。

<セキュリティベストプラクティス>
•AWSコストと使用状況レポートは、AWSの使用状況を追跡し、アカウントに関連する推定料金を提供する。各レポートには、AWSアカウントで使用するAWS製品、使用タイプ、および操作の各組み合わせに対する明細項目が含まれている。

[B.8.4]組織は、ハードウェアおよびソフトウェアを機密性および/または機微度レベルに従って分類および処理するプロセスを確立し、実装している。これにより、それらが適切なセキュリティと保護を受けることを保証する。

(関連するAWSサービス)
タグ付けとTag Editor（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/tagging.html）：
AWSリソースにメタデータをタグの形で割り当てることができる。各タグは、ユーザー定義のキーと値から成るラベルである。タグはリソースの管理や識別、整理、検索、フィルタリングに役立つ。リソースを目的や所有者、環境、その他の基準で分類するためにタグを作成できる。
<タグ付けのためのセキュリティベストプラクティス>
•Tag Editorでのデータ保護（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security_data-protection.html）
•Tag Editorのアイデンティティ／アクセス管理（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security-iam.html）
•Tag Editorでのタグ記録とモニタリング（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security_logging-monitoring.html）
•Tag Editorのコンプライアンス検証（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security_compliance.html）
•Tag Editorにおける耐障害性（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security_resilience.html）
•Tag Editorのインフラストラクチャセキュリティ（https://docs.aws.amazon.com/ja_jp/tag-editor/latest/userguide/security_infrastructure.html）

[B.8.6] 組織は、適切な、業界で認識されている資産ディスカバリーツールを確立し、実装している。これにより、ネットワークに接続されている資産をスキャンして検出し、すべての資産が安全に管理されることを保証する。

(関連するAWSサービス)
AWS Systems Manager Inventory：AWS Systems Manager Inventoryは、AWSのコンピューティング環境に対する可視性を提供する。

インベントリを使用して、管理ノードからメタデータを収集できる。このメタデータを中央のAmazon S3バケットに保存し、組み込みツールを使用してデータをクエリし、ソフトウェアを実行しているノードや、ソフトウェアポリシーによって要求される構成・更新が必要なノードを迅速に特定できる。また、複数のAWSリージョンおよびAWSアカウントからインベントリデータを構成および表示することもできる。

[B.8.9] 組織は、ハードウェアおよびソフトウェア資産を追跡して管理するために、適切な、業界で認識されている資産インベントリ管理システムの使用を確立し、実装している。これにより、正確性を確保し、見落としを避けることができる。

(関連するAWSサービス)
AWS Config：AWS Configは、AWSアカウント内のAWSリソースの構成の詳細なビューを提供する。これには、リソースが互いにどのように関連しているか、および過去にどのように構成されていたかが含まれており、構成および関係が時間とともにどのように変化するかを見ることができる。

<AWS Configのセキュリティベストプラクティス>（前掲）
•AWS Configでのデータ保護
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/data-protection.html）
•AWS ConfigのIDとアクセス管理
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-iam.html）
•AWS Configでのログ記録とモニタリング
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-logging-and-monitoring.html）
•AWS Configとインターフェイス Amazon VPC エンドポイントの使用
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/config-VPC-endpoints.html）
•AWS Configのインシデントへの対応
（ https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/incident-response.html）
•AWS Configのコンプライアンス検証
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/config-compliance.html）
•AWS Configの耐障害性
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/disaster-recovery-resiliency.html）
•AWS Configのインフラストラクチャセキュリティ
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/infrastructure-security.html）
•サービス間の混乱した代理の防止
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/cross-service-confused-deputy-prevention.html）
•AWS Configのセキュリティベストプラクティス
（https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/security-best-practices.html）

AWSユーザー向けガイドとCCMv4のマッピング事例

参考までに、AWSユーザー向けガイドの「B8. ドメイン：資産管理」に対応するCCMv4コントロール項目を挙げると、以下の通りである。

・UEM-04エンドポイントのインベントリ：企業データの保存やアクセスに使う全てのエンドポイントをインベントリに保持する。
・DCS-01オフサイト機器の廃棄ポリシーと手順：組織の外部で使用される機器を安全に廃棄するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。機器が物理的に破壊されていない場合は、情報の回復を不可能にするデータ破壊手順が適用されるべきである。ポリシーと手順を少なくとも年1回確認して更新する。
・DCS-05資産の分類：組織のビジネスリスクに基づいて、物理的および論理的な資産（アプリケーションなど）を分類して文書化する。
・DCS-06資産のカタログ化と追跡：CSPのすべてのサイトにある関係する物理的および論理的資産を、セキュアなシステム内でカタログ化し追跡する。
・CCC-04承認されていない変更からの保護：組織の持つ資産への承認されていない追加や削除、更新、管理などを制限する。
・DSP-02セキュアな廃棄：業界で認められている方法を用いて、ストレージメディアからデータをセキュアに廃棄し、いかなるフォレンジック手段によってもデータが復元できないようにする。

なおAWSは、CSA STAR Lebel 1およびLebel 2の認証を取得しており、CSAサイト上で、Consensus Assessments Initiative Questionnaire（CAIQ）v4.0.2の質問に対する回答内容を公開している（https://cloudsecurityalliance.org/star/registry/amazon/services/amazon-web-services）。前述のAWSユーザー向けガイドの「B8. ドメイン：資産管理」に対応するCAIQ v4.0.2の質問6項目への回答内容（2024年12月16日時点）を挙げると、以下の通りである。

①質問ID：UEM-04.1
質問：使用するすべてのエンドポイントのインベントリがあり、企業データの保存やアクセスのために保持しているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明：Amazonは、業界のベストプラクティスに準じたベースラインのインフラストラクチャ基準を設定している。これには、エンドポイントのインベントリ管理が含まれる。
CSCの責任：N/A
CCM Control ID：UEM-04
CCM Control仕様：企業データの保存やアクセスに使う全てのエンドポイントをインベントリに保持する。
CCM Controlタイトル：エンドポイントのインベントリ
CCM Domainタイトル：ユニバーサルエンドポイント管理

②質問ID：DCS-01.1
質問： 組織の敷地外で使用される機器の安全な廃棄に関するポリシーと手順が設定され、文書化され、承認され、伝達され、施行され、維持されているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明： AWS サービスの提供に使用される環境は、認可された担当者によって管理され、AWS が管理するデータセンターに配置される。データセンターのメディア取扱管理は、AWS メディア保護ポリシーに従って AWS によって管理されている。このポリシーには、アクセス、マーキング、保管、輸送、および無害化に関する手順が含まれている。データセンターの安全ゾーン外に輸送されるライブメディアは、認可された担当者によって護衛される。
CSCの責任：N/A
CCM Control ID：DCS-01
CCM Control仕様：組織の敷地外で使用される機器の安全な廃棄に関するポリシーと手順を設定し、文書化し、承認し、伝達し、適用し、評価し、維持する。機器が物理的に破壊されない場合は、情報の回復を不可能にするデータ破壊手順を適用する必要がある。ポリシーと手順を少なくとも年に一度見直し、更新する。
CCM Controlタイトル：オフサイト機器廃棄ポリシーと手順
CCM Domainタイトル：データセンターセキュリティ

③質問ID：DCS-05.1
質問： 物理的および論理的資産の分類と文書化は、組織のビジネスリスクに基づいているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明： ISO 27001 規格に準拠して、AWS の資産に所有者が割り当てられ、AWS 独自のインベントリ管理ツールを使用して AWS の担当者によって追跡および監視されている。
CSCの責任：N/A
CCM Control ID：DCS-05
CCM Control仕様： 物理的および論理的資産（例：アプリケーション）を組織のビジネスリスクに基づいて分類し、文書化する。
CCM Controlタイトル：資産分類
CCM Domainタイトル：データセンターセキュリティ

④質問ID：DCS-06.1
質問：すべての CSP サイトで、関連するすべての物理的および論理的資産がカタログ化され、安全なシステム内で追跡されているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明： ISO 27001 規格に準拠して、AWS の資産に所有者が割り当てられ、AWS 独自のインベントリ管理ツールを使用して AWS の担当者によって追跡および監視されている。
CSCの責任：N/A
CCM Control ID：DCS-06
CCM Control仕様：CSPのすべてのサイトにある関連するすべての物理的および論理的資産を、安全なシステム内でカタログ化し、追跡する。
CCM Controlタイトル：資産のカタログ化と追跡
CCM Domainタイトル：データセンターセキュリティ

⑤質問ID：CCC-04
質問： 組織資産の無許可の追加、削除、更新、管理は制限されているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明： 認可されたスタッフは、データセンターフロアにアクセスするために、少なくとも 2 回の二要素認証を通過する必要がある。サーバーの場所への物理的なアクセスポイントは、AWSデータセンター物理セキュリティポリシーで定義されているように、閉回路テレビカメラ (CCTV) によって記録される。
CSCの責任：N/A
CCM Control ID：CCC-04
CCM Control仕様： 組織資産の無許可の追加、削除、更新、管理を制限する。
CCM Controlタイトル：
CCM Domainタイトル：

⑥質問ID：DSP-02.1
質問： ストレージメディアからのデータの安全な廃棄のために、情報がフォレンジック手段によって回復できないようにするために、業界で受け入れられている方法が適用されているか？
CSA CAIQ回答：はい
SSRM Controlオーナーシップ：CSP所有
CSP実装の説明：ストレージデバイスがその有効な寿命を迎えたとき、AWS の手順には、顧客データが不正な個人にさらされないようにするための廃棄プロセスが含まれている。AWS は、廃棄プロセスの一環として、NIST 800-88（”メディアの消去に関するガイドライン”）に記載されている技術を使用している。詳細については、https://aws.amazon.com/architecture/security-identity-complianceのWeb サイトを参照のこと。
CSCの責任：N/A
CCM Control ID：DSP-02
CCM Control仕様：ストレージメディアからのデータの安全な廃棄のために、情報がフォレンジック手段によって回復できないようにするために、業界で受け入れられている方法を適用する。
CCM Controlタイトル：安全な廃棄
CCM Domainタイトル：データセキュリティとプライバシーのライフサイクル管理

AWSユーザー向けガイドとISO/IEC 27001:2022のマッピング事例

また、AWSユーザー向けガイドの各ドメインとISO/IEC 27001:2022の管理策の関係については、シンガポールサイバーセキュリティ庁が、「サイバートラストとISO/IEC 27001:2022間のクロスマッピング」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/20231006-cross-mapping-cyber-trust-iso27k-v202310.pdf?sfvrsn=d660e5e3_1）を公開している。

前述の「B8. ドメイン：資産管理」の中小・スタートアップ企業レベル（Supporter）に対応するISO/IEC 27001:2022附属書Aの情報セキュリティ管理策は、以下の通りである。

・A5.9 情報及びその他の関連資産の目録
・A5.10 情報及びその他の関連資産の許容される利用
・A5.23 クラウドサービスの利用における情報セキュリティ
・A7.10 記憶媒体
・A7.13 装置の保守
・A7.14 装置のセキュリティを保った処分又は再利用
・A8.10 情報の削除

参考までに、AWSユーザー向けガイドの「B9. ドメイン：データ保護とプライバシー」の中小・スタートアップ企業レベル（Supporter）に対応するISO/IEC 27001:2022附属書Aの情報セキュリティ管理策を挙げると、以下の通りである。

・サブドメインB.9.1：組織は、ビジネスにとって重要なデータ（個人データ、企業秘密、知的財産など）を特定し、その位置を特定して、保護することができるよう保証するために、 「A.3 資産：データ」に基づくサイバーエッセンシャルマークすべての要求事項を実装している。
（ISO/IEC 27001:2022の管理策）
・A5.10 情報及びその他の関連資産の許容される利用
・A5.13 情報のラベル付け
・A7.10 記憶媒体
・A7.14 装置のセキュリティを保った処分又は再利用
・A8.12 データ漏えい」防止
・A8.26 アプリケーションセキュリティの要求事項

・サブドメインB.9.2：組織は、ビジネスにとって重要なデータ（個人データ、企業秘密、知的財産など）の漏えいを報告するプロセスを定義し、適用している。また、経営陣、関連当局、関連する個人などの利害関係者が情報を得られるようにしている。
（ISO/IEC 27001:2022の管理策）
・A5.5 関係当局との連絡
・A5.24 情報セキュリティインシデント管理の計画策定及び準備
・A6.8 情報セキュリティ事象の報告

・サブドメインB.9.3：クラウドサービスを利用する組織は、データのプライバシーとセキュリティに関して、クラウドサービスプロバイダー（CSP）との間でクラウド責任共有モデルを確立し、実装している（例：組織とCSPの間における明確な役割と責任を確立するための合意）。
（ISO/IEC 27001:2022の管理策）
・A5.2 情報セキュリティの役割及び責任
・A5.10 情報及びその他の関連資産の許容される利用
・A5.20 供給者との合意における情報セキュリティの取扱い
・A5.23 クラウドサービスの利用における情報セキュリティ
・A8.12 データ漏えい防止

今回紹介したのは、シンガポールサイバーセキュリティ庁が公開しているAWSユーザー向けガイドの中小・スタートアップ企業レベル（Supporter）向け管理策の一部である。同ガイドは、シンガポール情報通信メディア開発庁（IMDA）がボストンコンサルティンググループと連携して開発した「デジタルアクセラレーションインデックス（DAI）」（https://www.imda.gov.sg/how-we-can-help/digital-acceleration-index）のデジタル成熟度指標に準拠した5つのサイバーセキュリティ対応準備段階に応じて、情報セキュリティ管理策を追加していくシナリオの下に策定されている。

• 「Advocate」: 先導的なデジタル成熟度を有する組織、大規模組織またはそれらで活動している人／規制セクター向けのプロバイダー
• 「Performer」: “Performer”のデジタル成熟度を有する組織、大・中堅規模組織
• 「Promoter」: “Literate”のデジタル成熟度を有する組織、中堅・大規模組織
• 「Practitioner」: “Starter” のデジタル成熟度を有する組織、中堅・小規模組織
• 「Supporter」: “Starter” のデジタル成熟度を有する組織、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズ

そして、様々な情報セキュリティ管理策をマッピングする際に重要な役割を果たしているのがCSA CCM／CAIQである。このCSA CCM／CAIQを標準軸とするシンガポールのフレームワークを、日本の中小規模／スタートアップ企業のクラウドユーザーによる情報セキュリティ管理策に拡張できれば、日本発ユニコーン企業の創出支援にもつながるであろう。

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

 

 

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

最初に取り上げるのは、エンタープライズユーザーを対象とするサイバートラストマークに準拠した「AWS Cloud Companion Guide for Cyber Trust – Jointly developed with AWS」（https://d1.awsstatic.com/whitepapers/compliance/CSA_Cyber_Trust_mark_certification_Cloud_Companion_Guide.pdf）（2023年10月13日公表）である。このAWS版ガイドは、以下のような構成になっている。

• イントロダクション
• 本ガイドの使用方法
• あなたはWell-Architectedですか？
• AWS責任共有モデル
• AWSサービスおよび機能のCyber Trustドメインへのマッピング
• B8. ドメイン：資産管理
• B9. ドメイン：データ保護とプライバシー
• B10. ドメイン：バックアップ
• B12. ドメイン：システムセキュリティ
• B13. ドメイン：ウイルス対策／マルウェア対策
• B14. ドメイン：セキュアソフトウェア開発ライフサイクル (SDLC)
• B15. ドメイン：アクセス制御
• B16. ドメイン：サイバー脅威管理
• B18. ドメイン：脆弱性評価
• B20. ドメイン：ネットワークセキュリティ
• B21. ドメイン：インデント対応
• B22. ドメイン：事業継続と災害復旧
• 結論

CSAサイバートラストマーク認証のためのクラウドコンパニオンガイドは、あらゆる規模の組織がAWS特有のサービスを導入して効果的なセキュリティ管理を達成できるよう支援することを目的としている。AWS上で利用可能なセキュリティサービスおよびツールと、それに適用される管理を理解することにより、ユーザーはAWS上で安全なワークロードおよびアプリケーションを構築することができるとしている。

サイバートラスト向けコンパニオンガイドは、総計22のサイバーセキュリティ対応準備ドメインを設定しているが、このAWS版ガイドでは、SMBユーザーを考慮して、上記の通り12のドメインに絞り込んでいる点が特徴だ。以下では、AWS版ガイドが推奨する具体的なセキュリティ管理策および関連するAWSサービス（2023年10月時点で提供しているもの）を挙げる。

情報資産保護

B.8 資産管理：
このドメインの目的は、組織内のハードウェアおよびソフトウェア資産を特定し、追跡することによって、サイバーセキュリティ対策およびプロセスが資産ライフサイクル全体で実装されるよう保証することにある。積極的な資産管理により、組織はリスクを監視し、環境内における資産の制御を可能にして、許可された資産のみが使用およびインストールされるようにする。
・B.8.1. 組織は、環境内に存在するハードウェアおよびソフトウェアを特定し、一般的なサイバー脅威から保護している。
（関連するAWSサービス）AWS Config、AWS Cost and Usage Reports (CUR)
・B.8.4. 組織は、ハードウェアおよびソフトウェアを機密性および／または機微度レベルに従って分類および処理するプロセスを確立し、実装している。これにより、それらが適切なセキュリティと保護を受けることを保証する。
（関連するAWSサービス）ユーザーのAWSリソースのタグ付け
・B.8.6. 組織は、適切な、業界で認識されている資産ディスカバリーツールを確立し、実装している。これにより、ネットワークに接続されている資産をスキャンして検出し、すべての資産が安全に管理されることを保証する。
（関連するAWSサービス）AWS Systems Manager Inventory
・B.8.9. 組織は、ハードウェアおよびソフトウェア資産を追跡して管理するために、適切な、業界で認識されている資産インベントリ管理システムの使用を確立し、実装している。これにより、正確性を確保し、見落としを避けることができる。
（関連するAWSサービス）AWS Config

B.9. データ保護とプライバシー：
このドメインの目的は、組織環境内のビジネスに重要なデータが特定され、追跡されることによって、サイバーセキュリティ対策およびプロセスが資産ライフサイクル全体で実施されるようにすることである。また、データの収集や処理、転送、保存が安全に行われ、不正アクセスや漏えいから保護されることを保証する。
・B.9.5. 組織は、リスク分類を行い、機密性および機微度レベルに従ってビジネスに重要なデータ（個人データ、企業秘密、知的財産など）を取り扱うためのポリシーおよび手順を確立し、実装している。これにより、データが適切なセキュリティおよび保護を受けることを保証する。
（関連するAWSサービス）Amazon Macie
・B.9.11. 組織はデータを保護するために暗号化を使用しており、暗号鍵管理ライフサイクル全体で鍵が安全に取り扱われることを保証するための暗号化ポリシーおよびプロセスを確立し、実装している。
（関連するAWSサービス）AWS Key Management Service
・B.10.3. 組織は、自動化されたバックアッププロセスを確立し、実装している。これにより、バックアップタスクが確実に実行され、人間の介入が不要になる。
（関連するAWSサービス）AWS Backup、Amazon EBS Snapshots、AWS Backup Vault Lock

B.10. バックアップ：
このドメインの目的は、情報資産が定期的に、安全かつ一貫した方法でバックアップされることを確保し、サイバーセキュリティインシデントやデータ侵害インシデントが発生した場合に、組織がシステムおよびデータを復旧・回復できるようにすることである。
・B.10.3. 組織は、自動化されたバックアッププロセスを確立し、実装している。これにより、バックアップタスクが確実に実行され、人間の介入が不要になる。
（関連するAWSサービス）AWS Backup
・B.10.4. 組織は、バックアップ計画を確立し、実装している。これには、バックアップの種類、頻度、および保存方法が含まれており、組織内のビジネスに重要なデータをバックアップするための手順が明確にされる。
（関連するAWSサービス）Amazon EBS Snapshots
・B.10.6. 組織は、バックアップの状態を定期的にレビューし、失敗したバックアップジョブに対処し、修正するためのポリシーおよび手順を確立し、実装している。
（関連するAWSサービス）Amazon S3 Object Lock、AWS Backup Vault Lock

B.12. システムセキュリティ：
このドメインの目的は、サイバーセキュリティ対策と保護策を実施および維持し、組織のシステムを保護することである。これらの対策と保護策には、セキュアな構成、ログ記録、更新およびパッチ適用が含まれる。
・B12.3. 組織は、更新プログラムおよびパッチがインストールされた後の監視を実施し、影響や悪影響がタイムリーに特定および修正されるようにしている。
（関連するAWSサービス）AWS Systems Manager／Patch Manager
・B.12.6. 組織は、更新およびパッチを安全にテストしインストールして、悪影響がないことを確認するためのパッチ管理プロセスを定義し、適用している。
（関連するAWSサービス）AWS Systems Manager／Patch Manager
・B.12.9. 組織は、未承認のアクセスからログを保存、保持および削除するための要件、ガイドライン、および詳細な手順を含むセキュアなログポリシーおよび手順を確立し、実装している。
（関連するAWSサービス）AWS Systems Manager／Patch Manager
・B.12.10. 組織は、システムが優先度に従って定義された期間内にパッチまたは更新されることを確保するための要件、ガイドライン、および詳細な手順を含むポリシーおよび手順を確立し、実装している。
（関連するAWSサービス）Guidance for Log Storage on AWS
・8.12.11. 組織は、システムの構成が望ましい一貫した状態で維持されることを保証するために、業界で適切かつ認知された構成管理ツール／ソリューションを実装している。
（関連するAWSサービス）AWS Security Hub
・8.12.12. 組織は、システムの構成要件が業界のベンチマークや標準、例えばCIS構成ベンチマークと一致することを保証するためのポリシーおよび手順を確立し、実装している。
（関連するAWSサービス）AWS Config

B.13. ウイルス対策／マルウェア対策：
このドメインの目的は、ネットワークを破壊または損傷させる可能性のある悪意のあるソフトウェアを継続的に監視し、防御するために、保護対策および技術が実装、維持、および更新されることを保証することである。このドメインはまた、成功した悪意のあるソフトウェア攻撃を管理するために設置されたプロセスにも対処し、さらなる損害やネットワークおよび環境への拡散を防ぐことを目指している。
・8.13.4 組織は、悪意のあるサイトの閲覧からビジネスを保護するために、Webフィルタリングを確立し、実装している。
（関連するAWSサービス）Amazon Route53 DNS Resolver Firewall、AWS Network Firewall

B.14. セキュアソフトウェア開発ライフサイクル：
このドメインの目的は、システムのソフトウェア開発ライフサイクルにセキュリティ仕様と実践を組み込み、ソフトウェアが安全かつ一貫した方法で開発されることを保証することである。
・B.14.6. 組織は、セキュリティ原則に従うことを確実にするために、システムおよび／またはアプリケーション開発においてセキュリティガイドラインと要件（例：セキュアコーディング）を確立し、実装している。
（関連するAWSサービス）Amazon Inspector
・B.14.7. 組織は、変更や本番環境への展開が安全にレビューおよびテストされるようにするための変更管理ポリシーおよびプロセスを確立し、実装している。また、変更が管理されていることを確認するために、ロールバックプランも用意している。
（関連するAWSサービス）AWS CodeCommit
・B.14.8. 組織は、セキュリティの弱点や脆弱性を特定するために、システムやアプリケーションの展開前にセキュリティテストを実施するためのポリシーおよびプロセスを確立し、実装している。
（関連するAWSサービス）Amazon CodeGuru Security、Amazon CodeWhisperer、AWS Secrets Manager

セキュアなアクセスと環境

B.15. アクセス制御：
このドメインの目的は、組織の資産およびデータへのアクセス管理の制御と正式なプロセスを確立し、従業員、請負業者、および第三者が最小権限の原則に基づいてのみアクセスできるようにし、管理が統制され、一貫した方法で行われることを保証することである。
・B.15.1. 組織は、データおよび資産へのアクセスに関してサイバーセキュリティ対策が確立されていることを確保するために、すべてのサイバーセキュリティ要件を実装している。
（関連するAWSサービス）AWS Identity and Access Management、AWS Identity Center
・B.15.11. 組織は、ユーザーを認証し、役割に基づいてアクセスを許可するための業界で適切かつ認知された特権アクセスソリューションを確立し、実装しており、より効率的で効果的なアクセス管理方法を確保している。
（関連するAWSサービス）Temporary elevated Access with AWS IAM Identity Center

B.16. サイバー脅威管理：
組織は、システムのログ監視およびレビューを実施し、インシデントを調査し、関連する利害関係者に報告する役割と責任を定義し、割り当てている。
・B.16.1. 組織は、システムのログ監視およびレビューを実施し、インシデントを調査し、関連する利害関係者に報告する役割と責任を定義し、割り当てている。
（関連するAWSサービス）Systems Manager／Incident Manager、AWSアカウントの連絡先およびセキュリティ連絡先情報
・B.16.6. 組織は、ログを相関するために中央で保存し、ログの監視をより効果的に行うために、セキュリティ情報およびイベント管理（SIEM）を導入している。
（関連するAWSサービス）SIEM on Amazon OpenSearch Service、Amazon Security Lake、Guidance for Log Storage on AWS、AWS CloudTrail Lake
・B16.7. 組織は、異常を特定するためにシステム上でセキュリティベースラインプロファイルを確立し、実装して分析および監視を行っている。
（関連するAWSサービス）AWS Control Tower、AWS Security Hub、AWS Config
・B.16.9. 組織は、業界で適切かつ認知された高度な分析プロセスおよびソリューションを確立し、実装して、異常なシステムおよびユーザーの行動、ユーザー行動分析を検出している。
（関連するAWSサービス）Amazon GuardDuty
・B.16.11. 組織は、IT環境内に隠れた脅威を積極的に探すための対策とプロセスを確立し、実装している。
（関連するAWSサービス）Amazon Detective

B.18. 脆弱性評価：
このドメインの目的は、脆弱性評価と管理を確立し、組織のネットワークおよびシステムが既知の悪用から安全であることを確保することである。このドメインはまた、システムおよびソフトウェアのセキュリティ脆弱性を識別、評価、緩和、および報告するためのプロセスを確立する。
・B.18.7. 組織は、評価の一環として発見された脆弱性を追跡、レビュー、評価、対処するための対策とプロセスを確立し、実装して、脆弱性がその重大度に応じて修正されていることを確保している。
（関連するAWSサービス）Amazon Inspector、AWS Security Hub、ECR Container Registry (Amazon ECR) Image Scanning、
・B.18.10. 組織は、オープンまたは期限切れ、重大な脆弱性に関する報告と追跡を提供するためのメトリクスと閾値を確立し、ダッシュボードを含む可視性を確保するためのメトリクスと閾値を実装し、確立されたタイムライン内での追跡および修正を提供している。
（関連するAWSサービス）AWS Systems Manager／Patch Manager、Amazon QuickSightソリューションを使用してSystems Managerのパッチとコンプライアンスデータを管理し閲覧する

B.20. ネットワークセキュリティ：
このドメインの目的は、組織のネットワークとデータの機密性およびアクセス可能性を確保するための十分なサイバーセキュリティ対策およびプロセスを確立することである。
・B.20.2. 組織は、ネットワークセキュリティポリシーを強制し、許可されていないユーザーやデバイスが排除されるようにするために、ネットワークへのアクセス制御（許可リストまたは拒否リスト）を設定して実装している。
（関連するAWSサービス）Network Access Control Lists (ACLs)
・B.20.3. 組織は、パケットがより効果的にフィルタリングされるように、基本的なパケットフィルタリングファイアウォールではなくステートフルファイアウォールを使用することを確立し、実装している。
（関連するAWSサービス）Amazon VPC Security Groups
・B.20.6. 組織は、ネットワークセグメンテーションを実行するプロセスを定義および適用して、ネットワークをプライベートネットワークとパブリックネットワークに分離し、プライベートネットワークにはすべてのビジネスに不可欠なデータを保持し、インターネットに接続しないことで、外部の脅威から隔離されるようにしている。
（関連するAWSサービス）AWS Network Firewall
・B.20.11. 組織は、悪意のあるネットワークトラフィックをブロックし、脅威から保護するために、組織のネットワーク上でネットワーク侵入防止システムを確立し、実装している。
（関連するAWSサービス）AWS Web Application Firewall

サイバーセキュリティレジリエンス

B.21. インシデント対応：
このドメインの目的は、組織が正式なインシデント対応計画を策定し、定期的な演習を実施して現在のインシデント管理の設定の有効性を維持することを確実にすることである。これにより、サイバーセキュリティインシデントが発生した場合に、組織がタイムリーかつ専門的に、適切な方法でインシデントを検出、対応、および回復できるようにする。
・B.21.6. 組織は、根本原因を特定できるようにするために、インシデントの調査を実施し証拠を収集するための要件、ガイドラインおよび詳細な手順に関するポリシーと手順を定義および確立している。
（関連するAWSサービス）Systems Manager／Incident Manager

B.22. 事業継続と災害復旧：
このドメインの目的は、組織が重要な資産と業務プロセスを特定し、回復優先順位を設定できるようにすることである。事業継続および災害復旧管理は、組織が混乱に耐え、業務を継続できるようにするために、能力、計画およびテストを開発し、維持して従業員を準備させることを確保する。
・B.22.2. 組織は、高い可用性を必要とする重要な資産を特定し、それらに冗長性を確保するための対策を実施している。
（関連するAWSサービス）AWS Backup
・B.22.5. 組織は、ビジネス継続および災害復旧ポリシーを確立および実施し、要件、役割と責任、ガイドライン（復旧時間目標（RTO）および復旧ポイント目標（RPO）を含む）を定めて、システムの重要度に応じて業務再開が実施できるようにしている。
（関連するAWSサービス）AWS Backup、AWS Elastic Disaster Recovery
・B.22.6. 組織は、サイバーセキュリティインシデントによるものを含む一般的な業務中断シナリオに対処し、回復するためのビジネス継続および災害復旧計画を確立し、実装して、サイバー レジリエンスを確保している。
（関連するAWSサービス）AWS Backup、AWS Elastic Disaster Recovery
・B.22.8. 組織は、ビジネス継続および災害復旧計画の効果を確保するために、少なくとも年に1回、定期的にテストする方針とプロセスを確立し、実装している。
（関連するAWSサービス）AWS Fault Injection Simulator

なお、AWS版ガイドでは、追加的リソースとして、以下の3つを挙げている。

•AWS Architecture Center
https://aws.amazon.com/architecture/
•AWS Security Reference Architecture
https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/welcome.html
•AWS Compliance Programs
https://aws.amazon.com/compliance/programs/

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

 

総論編(1)に引き続き、CSAのグローバル展開から生まれた知見や実績をベースとする基礎的なクラウドセキュリティプラクティスの啓発活動を紹介する。

サイバートラスト向けクラウドセキュリティ管理策の概要

前回紹介したように、シンガポールサイバーセキュリティ庁（CSA）の「CSAサイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4の間のクロスマッピング」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-trust.pdf）では、シンガポール情報通信メディア開発庁（IMDA）の「デジタルアクセラレーションインデックス（DAI）」（https://www.imda.gov.sg/how-we-can-help/digital-acceleration-index）のデジタル成熟度指標に準拠して、以下の通り、5つのサイバーセキュリティ対応準備段階を設定している。

• 「Advocate」: 先導的なデジタル成熟度を有する組織、大規模組織またはそれらで活動している人／規制セクター向けのプロバイダー
• 「Performer」: “Performer”のデジタル成熟度を有する組織、大・中堅規模組織
• 「Promoter」: “Literate”のデジタル成熟度を有する組織、中堅・大規模組織
• 「Practitioner」: “Starter” のデジタル成熟度を有する組織、中堅・小規模組織
• 「Supporter」: “Starter” のデジタル成熟度を有する組織、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズ

その上で、サイバートラスト向けコンパニオンガイドは、以下の通り、総計22のサイバーセキュリティ対応準備ドメインを設定している（*が付いている項目は、サイバーエッセンシャルズマークの管理策と共通）。

[サイバーガバナンスと監視]

1. ガバナンス
2. ポリシーと手順
3. リスクマネジメント
4. サイバー戦略
5. コンプライアンス
6. 監査

[サイバー教育]

7. トレーニングと意識向上*

[情報資産保護]

8. 資産管理*
9. データ保護とプライバシー*
10. バックアップ*
11. 私物端末の業務利用（BYOD）
12. システムセキュリティ*
13. ウイルス対策／マルウェア対策*
14. セキュアソフトウェア開発ライフサイクル（SDLC）

[セキュアなアクセスと環境]

15. アクセス制御*
16. サイバー脅威管理
17. サードパーティリスクと管理
18. 脆弱性評価
19. 物理的／環境的セキュリティ
20. ネットワークセキュリティ

[サイバーセキュリティレジリエンス]

21. インシデント対応*
22. 事業継続／災害復旧

ここで、サイバーセキュリティ対応準備ドメインとCCMv4コントロール項目をマッピングした結果を整理すると、各サイバーセキュリティ対応準備段階には、以下の数のドメインが含まれる。

• 「Advocate」（大規模組織／プロバイダー）：22ドメイン
• 「Performer」（大・中堅規模組織）：19ドメイン
• 「Promoter」（中堅・大規模組織）：16ドメイン
• 「Practitioner」（中堅・小規模組織）：13ドメイン
• 「Supporter」（小規模・マイクロエンタープライズ）：10ドメイン

サイバートラスト向けコンパニオンガイドは、より大規模またはデジタル化が進んだ組織を対象としているが、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズを対象とする「Supporter」区分も設けている。IMDAのDAIでは、「Supporter」について、「会社はまだデジタル技術を採用するための一貫した計画を定義していない。ビジネス機能とITは、デジタル関連のトピックでアドホックに協力することがあるが、プロジェクトはより大きな協力なしに独立して設計・実行されている。」と説明している。

「Supporter」の対応準備ドメインとCCMv4コントロール項目の概要

3. リスクマネジメント

・GRC-02リスク管理プログラム：クラウドセキュリティとプライバシーリスクの特定、評価、所有、処理、および受容のためのポリシーと手順を含む、正式で、文書化され、リーダーシップが支援するエンタープライズリスク管理 (ERM) プログラムを確立する。

5. コンプライアンス

・GRC-07情報システムに対する規制へのマッピング：組織に適用されるすべての関連する標準、規制、法律/契約、および法定要件を特定し、文書化する。

7. トレーニングと意識向上*

・HRS-11セキュリティ意識向上トレーニング：組織のすべての従業員に向けたセキュリティ意識向上トレーニングプログラムを確立、文書化、承認、伝達、適用、評価、維持し、定期的にトレーニングの更新を行う。

・HRS-12個人データおよび機微データの意識向上とトレーニング：従業員に、確立されたポリシーと手順、および適用される法律、法令、または規制のコンプライアンス義務の認識と、コンプライアンスを維持するための役割と責任を認識させる。

8. 資産管理*

・UEM-04エンドポイントのインベントリ：企業データの保存やアクセスに使う全てのエンドポイントをインベントリに保持する。

・DCS-01オフサイト機器の廃棄ポリシーと手順：組織の外部で使用される機器を安全に廃棄するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。機器が物理的に破壊されていない場合は、情報の回復を不可能にするデータ破壊手順が適用されるべきである。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-05資産の分類：組織のビジネスリスクに基づいて、物理的および論理的な資産（アプリケーションなど）を分類して文書化する。

・DCS-06資産のカタログ化と追跡：CSPのすべてのサイトにある関係する物理的および論理的資産を、セキュアなシステム内でカタログ化し追跡する。

・CCC-04承認されていない変更からの保護：組織の持つ資産への承認されていない追加や削除、更新、管理などを制限する。

・DSP-02セキュアな廃棄：業界で認められている方法を用いて、ストレージメディアからデータをセキュアに廃棄し、いかなるフォレンジック手段によってもデータが復元できないようにする。

9. データ保護とプライバシー*

・DSP-01セキュリティおよびプライバシーについてのポリシーおよび手順：データの分類、保護、取り扱いに関するポリシーおよび手順を、そのライフサイクルを通じて、適用されるすべての法律および規制、基準、およびリスクレベルに応じて確立し、文書化し、承認し、伝達し、適用し、評価し、維持する。少なくとも年1回、ポリシーと手順を見直し、更新する。

・DSP-03データインベントリ：少なくとも機微なデータや個人情報については、データインベントリを作成し、維持する。

・DSP-17機微なデータの保護：機微なデータをライフサイクル全体で保護するためのプロセス、手順、技術的手段を定義し、実施する。

・DSP-19データの所在地：データが処理またはバックアップされる場所を含む、データの物理的な場所を特定および文書化するためのプロセス、手順、および技術的な手段を定義し、実施する。

・UEM-11データ漏洩防止：管理対象のエンドポイントに、データ漏洩防止（DLP）技術を構成し、リスクアセスメントに従ったルールを構成する。

・SEF-07セキュリティ侵害の通知：セキュリティ侵害の通知のためのプロセス、手順、および技術的措置を定義し実装する。適用されるSLA、法令および規制に従い、関連するサプライチェーンの侵害を含む、実際のもしくは想定されるセキュリティ違反を報告する。

・STA-03 SSRMガイダンス：SSRM のサプライチェーンに対する適用可能性に関する詳細情報を 、CSC に SSRM ガイダンスとして提供する。

・STA-09主要なサービスと契約上の合意：CSP と CSC (テナント) の間のサービス契約には、少なくとも次の条項について相互に合意した内容を組み込む必要がある：

• 提供されるビジネス関係とサービスの範囲、特徴、場所
• 情報セキュリティ要件 (SSRMを含む)
• 変更管理プロセス
• ロギングおよびモニタリング能力
• インシデント管理とコミュニケーション手順
• 監査および第三者評価を行う権利
• サービスの終了条件
• 相互運用性と移植容易性の要件
• データプライバシー

10. バックアップ*

・BCR-08バックアップ：クラウドに保存したデータを定期的にバックアップする。バックアップの機密性、完全性、可用性を確保し、レジリエンスのためにバックアップからのデータ復元を検証する。

12. システムセキュリティ*

・TVM-01脅威と脆弱性管理ポリシーと手順：脆弱性の悪用からシステムを保護するために、脆弱性を特定、報告、その修復に優先順位をつけるためのポリシーと手順を策定、文書化、承認、周知、適用、評価、および維持する。少なくとも年１回、ポリシーと手順を見直して更新する。

・TVM-03脆弱性の修復スケジュール：特定されたリスクに基づいて脆弱性が特定された場合に、計画された対応と緊急時の対応の両方を可能にするためのプロセス、手順、技術的手段を定義、実施、評価する。

・CCC-01変更管理ポリシーと手順：資産が内部で管理されているか、外部で管理(例：外部委託)されているかに関わらず、アプリケーションやシステム、インフラストラクチャ、設定など、組織が持つ資産の変更に関連するリスクについて、それを管理するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、維持する。 少なくとも年1回はポリシーと手順をレビューし更新する。

・CCC-03変更管理技術：資産が内部で管理されているか、外部で管理(例：外部委託)されているかに関わらず、アプリケーションやシステム、インフラストラクチャ、設定など、組織が持つ資産の変更に関連するリスクを管理する。

・CCC-06変更管理のベースライン：組織の持つ資産に関連するすべての承認された変更について、変更管理のベースラインを確立する。

・DSP-07デザイン段階からのデータ保護とデフォルト設定：セキュリティ・バイ・デザインの原則と業界のベスト・プラクティスに基づいて、システム、製品、およびビジネス・プラクティスを開発する。

・IVS-03ネットワークセキュリティ：事業によって正当化される形態で認証、認可された接続に制限するように、環境間のコミュニケーションをモニタリング、暗号化、制限する。少なくとも年1回構成をレビューし、許可された全てのサービス、プロトコル、ポート、補完的コントロールの文書による正当性を文書化し、構成を支持する。

13. ウイルス対策／マルウェア対策*

・TVM-02マルウェア対策ポリシーと手順：管理対象資産上のマルウェアから保護するためのポリシーと手順を策定、文書化、承認、周知、適用、評価、および維持する。少なくとも年１回、ポリシーと手順を見直して更新する。

・UEM-09マルウェア対策による検知及び保護：管理対象のエンドポイントに、マルウェア対策による検知および保護に必要な技術やサービスを構成する。

・UEM-10ソフトウェアファイアウォール：管理対象のエンドポイントに、適切に設定したソフトウェアファイアウォールを構成する。

・IVS-09ネットワーク防御：ネットワークベースの攻撃に係る保護、検知、タイムリーな対応のために、プロセス、手順、多層防御技術を定義、実装、評価する。

・UEM-02アプリケーションおよびサービスの承認：組織管理のデータへのアクセスや保存の際、エンドポイントでの使用を許可する、承認済のサービス、アプリケーション、および、アプリケーションの入手先（ストア）の一覧を定義、文書化、適用、評価を行う。

・SEF-07セキュリティ侵害の通知：セキュリティ侵害の通知のためのプロセス、手順、および技術的措置を定義し実装する。適用されるSLA、法令および規制に従い、関連するサプライチェーンの侵害を含む、実際のもしくは想定されるセキュリティ違反を報告する。

15. アクセス制御*

・IAM-01アイデンティティ およびアクセス管理のポリシーと手順：アイデンティティ およびアクセス管理のポリシーと手順を確立、文書化、承認、周知、実装、適用、評価、および維持する。少なくとも年に1 回、ポリシーと手順を見直して更新する。

・IAM-02強固なパスワードポリシーと手順：強力なパスワードポリシーと手順を確立、文書化、承認、周知、実装、適用、評価、および維持する。少なくとも年 1 回、ポリシーと手順を見直して更新する。

・IAM-03アイデンティティ・インベントリ：システムアイデンティティとアクセスレベルの情報を管理、保存、およびレビューする。

・IAM-05最小権限：情報システムへのアクセスを実装するときは、最小権限の原則を採用する。

・IAM-06ユーザーアクセスのプロビジョニング：データと資産へのアクセスの変更を承認、記録、および伝達するためのユーザアクセスプロビジョニングのプロセスを定義および実装する。

・IAM-07ユーザーアクセスの変更と取り消し：アイデンティティとアクセスの管理ポリシーを効果的に採用して伝達するために、異動者/退職者のアクセスまたはシステムアイデンティティの変更をタイムリーにプロビジョニング解除または変更する。

・IAM-10特権的なアクセスロールの管理：特権的なアクセスロールと権限が限られた期間のみ付与されることを保証するためのアクセスプロセスを定義および実装し、分離された特権アクセスが極大化するのを防ぐための手順を実装する。

・IAM-14強固な認証：システム、アプリケーション、およびデータ資産へのアクセスを認証するためのプロセス、手順、および技術的手段を定義、実装、および評価する。これには、少なくとも特権ユーザーおよび機密データへのアクセスに対する多要素認証が含まれる。システムアイデンティティに対して同等レベルのセキュリティを実現するデジタル証明書または代替手段を採用する。

・IAM-15パスワード管理：パスワードのセキュアな管理のプロセス、手順、および技術的手段を定義、実装、および評価する。

・IAM-16認可メカニズム：データおよびシステム機能へのアクセスが認可されていることを確認するためのプロセス、手順、および技術的手段を定義、実装、および評価する。

・LOG-08ログの記録：関連するセキュリティ情報を含む監査記録を生成する。

・STA-12サプライチェーンにおけるサービスアグリーメント準拠：サプライ チェーン全体のすべての CSP に、情報セキュリティ、機密性、アクセス制御、プライバシー、監査、人事ポリシー、およびサービス レベル要求と適用標準規格に対して、準拠を要求したポリシーを実装する。

・HRS-10機密保持契約：計画された間隔で、データの保護と運用の詳細に関する組織のニーズを反映した非開示/機密保持契約の要件を特定、文書化、およびレビューする。

・DCS-03保護区域ポリシーと手順：オフィス、部屋、施設で安全でセキュアな作業環境を維持するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-09保護区域における認証：認可された担当者のみに保護エリアへのアクセスを許可し、すべての入口と出口のポイントを物理的なアクセス制御メカニズムによって制限し、文書化し、監視する。 組織が適切と見なす期間で定期的にアクセス制御記録を保持する。

21. インシデント対応*

・SEF-02サービス管理ポリシーと手順：セキュリティインシデントの適時な管理のためのポリシーおよび手順を確立、文書化、承認、周知、適用し評価、および維持する。少なくとも年1回、ポリシーと手順をレビューし更新する。

・SEF-03インシデントレスポンス計画：セキュリティインシデントレスポンス計画を策定、文書化、承認、周知、適用、評価、および維持する。本計画には、関連する社内部門、影響を受けるCSC、影響を受ける可能性のあるその他のビジネス上での重要な関係（サプライチェーン等）が含まれるが、これらに限定されない。

「Practitioner」の対応準備ドメインとCCMv4コントロールの追加項目

なお、「Practitioner」（中堅・小規模組織）では、上記10ドメインに、以下の3ドメインが追加される。

19. 物理的／環境的セキュリティ

・DCS-03保護区域ポリシーと手順：オフィス、部屋、施設で安全でセキュアな作業環境を維持するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-15設備の場所：ビジネス上重要な機器を、環境に関するリスクイベントの可能性が高い場所から遠ざける。

・IVS-08ネットワークアーキテクチャの文書化：高リスク環境を特定し文書化する。

・DCS-01 オフサイト機器の廃棄ポリシーと手順：組織の外部で使用される機器を安全に廃棄するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。 機器が物理的に破壊されていない場合は、情報の回復を不可能にするデータ破壊手順が適用されるべきである。 ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-02 オフサイト転送承認ポリシーと手順：ハードウェア、ソフトウェア、またはデータ/情報をオフサイトまたは代替場所に再配置または転送するためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。 再配置または転送要求には、書面または暗号手法により検証可能な承認が必要である。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-03 （前掲）

・DCS-04 セキュアなメディア輸送ポリシーと手順：物理メディアの安全な輸送のためのポリシーと手順を確立、文書化、承認、伝達、適用、評価、および維持する。ポリシーと手順を少なくとも年1回確認して更新する。

・DCS-05資産の分類：組織のビジネスリスクに基づいて、物理的および論理的な資産（アプリケーションなど）を分類して文書化する。

・DCS-06 資産のカタログ化と追跡：CSPのすべてのサイトにある関係する物理的および論理的資産を、セキュアなシステム内でカタログ化し追跡する。

・DCS-07制御されたアクセスポイント：人員、データ、および情報システムを保護するために、物理的なセキュリティ境界を実装する。管理領域、ビジネス領域とデータのストレージおよび処理施設エリアの間に物理的なセキュリティ境界を確立する。

・DCS-08機器の識別：接続の認証方法として、機器の識別を使う。

・DCS-09保護区域における認証：認可された担当者のみに保護エリアへのアクセスを許可し、すべての入口と出口のポイントを物理的なアクセス制御メカニズムによって制限し、文書化し、監視する。組織が適切と見なす期間で定期的にアクセス制御記録を保持する。

・DCS-10監視システム：許可されていない入場および退場の試行を検出するために、外部境界およびすべての入口と出口のポイントで、データセンタ監視システムを実装、保守、および運用する。

・DCS-12ケーブルのセキュリティ：すべての施設、オフィス、および部屋において、電力および通信ケーブルを傍受、干渉、または損傷の脅威からリスクベースで保護し保証するプロセス、手順、および技術的対策を定義、実装、および評価する。

・DCS-13環境システム：温度と湿度の状態が承認された業界標準範囲内にあることを継続的に監視、維持、およびテストするデータセンタ環境制御システムを実装および保守する。

・DSP-16データの保持と廃棄：データの保持、アーカイブ、削除は、ビジネス要件、適用される法律および規制に従って管理する。

・DSP-19データの所在地：データが処理またはバックアップされる場所を含む、データの物理的な場所を特定および文書化するためのプロセス、手順、および技術的な手段を定義し、実施する。

・DCS-07（前掲）

20. ネットワークセキュリティ

・IVS-03ネットワークセキュリティ：事業によって正当化される形態で認証、認可された接続に制限するように、環境間のコミュニケーションをモニタリング、暗号化、制限する。少なくとも年1回構成をレビューし、許可された全てのサービス、プロトコル、ポート、補完的コントロールの文書による正当性を文書化し、構成を支持する。

・IVS-09ネットワーク防御：ネットワークベースの攻撃に係る保護、検知、タイムリーな対応のために、プロセス、手順、多層防御技術を定義、実装、評価する。

・IVS-07クラウド環境への移行：サーバー、サービス、アプリケーション、データをクラウド環境に移行する際、セキュアで暗号化されたコミュニケーションチャンネルを使用する。これらのチャンネルは最新の承認されたプロトコルだけを含まなければならない。

22. 事業継続／災害復旧

・BCR-11設備の冗長性：業界標準に従って、ビジネスクリティカルな機器に対して、合理的な範囲で最小限の離れた場所に独立して冗長機器を配置する。

このように、サイバートラスト向けコンパニオンガイドは、企業のデジタル成熟度や成長度に応じて、優先度の高いサイバーセキュリティ管理策を推奨する形態を採っているのが特徴だ。

サイバーセキュリティ教育面では、2024年7月15日、シンガポールサイバーセキュリティ庁（CSA）とシンガポール国立大学（NUS）が連携して、サイバーSGタレント・イノベーション・成長（TIG）コラボレーションセンターを設立したことを発表し、アカデミアとの連携を強化している（https://www.csa.gov.sg/News-Events/Press-Releases/2024/opening-of-cybersg-talent–innovation-and-growth-(tig)-collaboration-centre）。同センターは、以下のようなプログラムを提供している。

(a) SGサイバーアソシエイツ：

・サイバーセキュリティの専門家でない人々に対して、基礎レベルの特化したサイバーセキュリティトレーニングを提供し、日常業務に関連するサイバーセキュリティスキルを開発するためのプログラム

(b) SGサイバーユース：

・学生に、キャリアとしてサイバーセキュリティを探究する機会を提供し、関連する技術的知識やソフトスキルに触れることができるプログラムで、中学生および高等教育機関の学生を対象に設計されたユースサイバー探究プログラムと高度YCEPプログラムより構成される

(c) SGサイバープロフェッショナルズ：

・様々なバックグラウンドを持つミッドキャリアの転職者に対して、キャリア変換のための研修機会を提供し、それによって地元のサイバーセキュリティ人材を強化し、この重要分野における熟練した専門家の増大する需要に応える

(d) SGサイバータレント開発基金（SCTDF）：

・コミュニティ、団体、業界パートナーを奨励して、サイバーセキュリティ労働力を関与させ、スキルアップさせ、進歩させる取り組みを構築する

加えて2024年11月11日、同センターは、サイバーセキュリティ業界向けのオープンイノベーションコンテスト（CyberCall）の公募を開始した（募集期間：2025年1月10日まで）。（https://www.csa.gov.sg/News-Events/Press-Releases/2024/cybersg-tig-collaboration-centre-launched-the-cybersecurity-industry-call-for-innovation-(cybercall)-2024-november-edition）。

CyberCallは、オープン募集カテゴリーとユーザー駆動型カテゴリーから構成される。前者のテーマとしては、AI向けサイバーセキュリティ、サイバーセキュリティ向けAI利用、耐量子安全性、OT／IoTセキュリティ、クラウドセキュリティ、プライバシー強化技術（PET）がある。後者は、製造業やエネルギーなどのOT分野におけるサイバーセキュリティソリューションの効果を向上させるために、最新のAI技術を活用することを目的としており、具体的な課題は、エンドユーザー企業のYTLパワーセラヤとパナソニックから挙げられている。

CSA本部およびCSAシンガポールチャプターは、引き続きシンガポールの産官学連携エコシステムとの関係性強化に向けて取り組んでいる。

CSAジャパン関西支部メンバー

健康医療情報管理ユーザーワーキンググループリーダー

笹原英司

 

CSAジャパン関西支部および健康医療情報管理ワーキンググループでは、医療・ライフサイエンス業界を対象として、海外最新クラウド関連事例の紹介活動を行ってきたが、今回より、同様の課題をかかえる中堅中小規模の製造業やスタートアップ企業に対象を拡張して、CSAのグローバル展開から生まれた知見や実績をベースとして、基礎的なクラウドセキュリティプラクティスの啓発活動を紹介する。

シンガポール政府とCSAが企業規模別クラウドセキュリティガイドを開発

2023年10月17日、シンガポールサイバーセキュリティ庁とクラウドセキュリティアライアンスは、サイバーセキュリティ庁が開発した国家サイバーセキュリティ標準規格である「サイバーエッセンシャルズ」および「サイバートラスト」をサポートするツールとして、2種類の「クラウドセキュリティコンパニオンガイド」を策定したことを発表した。（https://www.csa.gov.sg/News-Events/Press-Releases/2023/launch-of-cloud-security-companion-guides-for-organisations）。本ガイドは、シンガポールサイバーセキュリティ庁（CSA）のWebサイトより無料でダウンロードできる。

このクラウドセキュリティコンパニオンガイドに先立ち、シンガポールサイバーセキュリティ庁は、2022年3月29日、「サイバーセキュリティ法」（2018年3月2日施行）に準拠した新しいサイバーセキュリティ認証プログラムを発表していた（https://www.csa.gov.sg/News-Events/Press-Releases/2022/csa-launches-new-cybersecurity-certification-programme-to-recognise-enterprises-with-good-cybersecurity-practices）。この認証プログラムは、サイバーハイジン対策を実施している中堅中小企業（SMB）などのクラウドユーザーを対象としたサイバーエッセンシャルズマークと、包括的なサイバーセキュリティ対策およびプラクティスを有する多国籍企業（MNC）などの大企業やクラウドサービスプロバイダーを対象としたサイバートラストマークから構成される。

二つのサイバーセキュリティ認証マークは、特定の製品・サービスのサイバーセキュリティを認証するものではなく、むしろ組織レベルで採用されたサイバーセキュリティ対策を認証するものである。これらの認証マークは、シンガポール企業の多様な組織形態や運用ニーズを考慮して、認証実務者、技術プロバイダー、業界団体などの業界パートナーとの協議を経て開発された。

これらのサイバーセキュリティ認証マークを踏まえて今回発表されたクラウドセキュリティコンパニオンガイドは、Amazon Web Services、Google Cloud、Microsoftとのパートナーシップに基づいて開発されたものであり、各プロバイダーは、顧客との体験に基づくインサイトを提供し、関連する成果や統計に寄与して、コンパニオンガイドのコンテンツを検証している。

本コンパニオンガイドは、SMBなどのクラウドユーザーがクラウド特有のリスクと責任をよく理解し、それに対する必要な対策を講じるためのアドバイスを提供している。これには、クラウドセキュリティにおける役割についての従業員のトレーニングや、クラウドで安全に操作する方法、クラウドサービスのインベントリを追跡・監視する仕組みの実装などが含まれている。

企業がクラウドを利用する際に混乱しがちなのが、クラウドユーザーとしての自身の責任とクラウドプロバイダーの責任分担である。オンプレミス型システム導入の場合、組織は自社のサイバーセキュリティに完全に責任を持つ。他方、クラウドサービス導入の場合、責任がユーザーとプロバイダーの間で共有されるが、ユーザーが責任を持つ領域を完全には把握していない可能性がある。これによって、設定ミスや悪意のある攻撃、データ侵害の可能性を高める場合があるとしている。

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）は、SMBを対象としており、責任共有モデルを使用して、ユーザー組織とプロバイダーがそれぞれクラウド環境を保護するために何を担当する必要があるかを理解するのに役立つ構成となっている。具体的には、以下のような構成となっている。

1. イントロダクション
2. 対象読者
3. 本文書のスコープ
4. 謝辞
5. サイバーエッセンシャルズ向けのクラウドの責任共有モデル (SRM)
6. 参考文献
   附表1 サイバーエッセンシャルズ向けのクラウド固有の実装に関するガイダンス

サイバーエッセンシャルズ向けクラウドセキュリティコンパニオンガイドでは、「サイバーエッセンシャルズマーク向けサイバーセキュリティ認証」（https://www.csa.gov.sg/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cybersecurity-certification-scheme-for-organisation/cyber-essentials/certification-for-the-cyber-essentials-mark）より、以下のようなセキュリティ管理項目を採用した上で、クラウド固有の管理策（要求事項および推奨事項）を設定している。

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

たとえば、上記のうち、サイバーエッセンシャルズマークの「[カテゴリー：資産]・人々 – 従業員に、防衛の最前線となるノウハウを装備させる」では、以下のような要求事項が設定されている。

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

これを受けて、サイバーエッセンシャルズ向けコンパニオンガイドでは、「エンドユーザー組織(SaaSカスタマー)の責任」として、以下のような要求事項を設定している。

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

[なぜこれが重要か]

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

[組織は何をすべきか]

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

また、「クラウドプロバイダー（SaaSプロバイダーおよびクラウドインフラストラクチャプロバイダーの双方）」の責任として、以下のような要求事項を設定している。

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

このように、セキュリティ管理項目ごとに、責任共有モデルにおけるエンドユーザー組織(SaaSカスタマー)、SaaSプロバイダー、クラウドインフラストラクチャプロバイダーの関係性を明確化した点が、シンガポールのサイバーエッセンシャルズ向けコンパニオンガイドの特徴である。

なお、サイバーエッセンシャルズ向けコンパニオンガイドの参考文献として、以下のようなドキュメントを挙げている。

1. CIS Controls Cloud Companion Guide v8 by Center for Internet Security (CIS)
   （https://www.cisecurity.org/insights/white-papers/cis-controls-v8-cloud-companion-guide)
2. ISO/IEC 27017- Information technology – Security techniques – Code of practice for information security controls based on ISO/IEC 27002 for cloud services by ITU-T
   （https://www.iso.org/standard/43757.html）
3. Top Threats to Cloud Computing by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-deep-dive）
4. SaaS Governance Best Practices for Cloud Customers by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/saas-governance-best-practices-for-cloud-customers）
5. Cloud Incident Response Framework – A Quick Guide by Cloud Security Alliance
   （https://cloudsecurityalliance.org/artifacts/cloud-incident-response-framework-a-quick-guide）
6. 2022 SaaS Security Survey Report by Cloud Security Alliance and Adaptive Shield
   （https://cloudsecurityalliance.org/artifacts/saas-security-and-misconfigurations-report）
7. Cloud Security Foundations, Frameworks and Beyond by SANS Institute
   （https://www.sans.org/white-papers/cloud-security-foundations-frameworks-beyond/）
8. The State of SaaS Sprawl by Productiv Inc
   （https://productiv.com/resources/the-state-of-saas-sprawl/）
9. 2023 State of SaaSOps by BetterCloud, Inc
   （https://www.bettercloud.com/monitor/the-2023-state-of-saasops-report/）
10. Cloud and Threat Report: Global Cloud and Web Malware Trends by Netskope
    （https://www.netskope.com/wp-content/uploads/2023/05/cloud-and-threat-report-global-cloud-and-web-malware-trends.pdf）

CSA CCMを適用したサイバートラスト向けクラウドセキュリティ管理策

他方、サイバートラスト向けのクラウドセキュリティコンパニオンガイドである「CSAサイバートラストとクラウドセキュリティアライアンス・クラウドコントロールマトリクスv4の間のクロスマッピング」（https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/cloud-security-companion-guide-cyber-trust.pdf）は、より大規模またはデジタル化が進んだ組織を対象としており、サイバートラストマークの各サイバーセキュリティ対応準備ドメイン（サイバーガバナンスと監督、サイバー教育など）をクラウドセキュリティアライアンスのCloud Controls Matrix（CCM）v4にマッピングしている。このマッピングを通じて、企業がサイバートラストマークを取得するために必要な管理策の実行を容易にするためのレファレンスを提供する。

サイバートラスト向けのコンパニオンガイドでは、企業がサイバートラストマークを適用すべき理由として、以下のような点を挙げている。

• 堅牢なサイバーセキュリティを有する信頼されたパートナーとして、組織を認識するための優れたマークを意味する
• 国際的なサイバーセキュリティ基準（例：ISO/IEC 27001）への道を提供する
• 組織のサイバーセキュリティリスクと対応準備状況を評価するためのガイド付きアプローチを提供する
• 過剰投資することなく組織のニーズに応じたリスクベースのアプローチを採用する
• どのサイバーセキュリティ対応準備段階に自分の組織が属しているか？

1. そして、サイバートラスト向けコンパニオンガイドは、以下のような構成になっている。
2. イントロダクション
3. 対象読者
4. 本文書のスコープ
5. 謝辞
6. サイバートラスト向けのアプローチ

参考文献
附表I. サイバートラストマークのCCMv4へのマッピングを描写する可視化
附表II. サイバートラストマークの対応準備段階のCCMv4へのマッピングを描写する可視化
附表III. サイバートラストマークのCCMv4へのマッピング

　まずサイバートラスト向けコンパニオンガイドでは、シンガポール情報通信メディア開発庁（IMDA）の「デジタルアクセラレーションインデックス（DAI）」（https://www.imda.gov.sg/how-we-can-help/digital-acceleration-index）のデジタル成熟度指標に準拠して、以下の通り、5つのサイバーセキュリティ対応準備段階を設定している。

• 「Advocate」: 先導的なデジタル成熟度を有する組織、大規模組織またはそれらで活動している人／規制セクター向けのプロバイダー
• 「Performer」: “Performer”のデジタル成熟度を有する組織、大・中堅規模組織
• 「Promoter」: “Literate”のデジタル成熟度を有する組織、中堅・大規模組織
• 「Practitioner」: “Starter” のデジタル成熟度を有する組織、中堅・小規模組織
• 「Supporter」: “Starter” のデジタル成熟度を有する組織、”デジタルネイティブ”なスタートアップを含む小規模・マイクロエンタープライズ

その上で、サイバートラスト向けコンパニオンガイドは、以下の通り、サイバーセキュリティ対応準備ドメインを設定している。

[サイバーガバナンスと監視]

1. ガバナンス
2. ポリシーと手順
3. リスクマネジメント
4. サイバー戦略
5. コンプライアンス
6. 監査

[サイバー教育]

7. トレーニングと意識向上*

[情報資産保護]

8. 資産管理*
9. データ保護とプライバシー*
10. バックアップ*
11. 私物端末の業務利用（BYOD）
12. システムセキュリティ*
13. ウイルス対策／マルウェア対策*
14. セキュアソフトウェア開発ライフサイクル（SDLC）
[セキュアなアクセスと環境]
15. アクセス制御*
16. サイバー脅威管理
17. サードパーティリスクと管理
18. 脆弱性評価
19. 物理的／環境的セキュリティ
20. ネットワークセキュリティ

[サイバーセキュリティレジリエンス]

21. インシデント対応*
22. 事業継続／災害復旧

　上記のうち、*が付いている項目は、サイバーエッセンシャルズマークの管理策と共通である。このように、サイバートラストマークとサイバーエッセンシャルズマークは、一貫性のある管理策構成となっている。

サイバートラスト向けコンパニオンガイドでは、縦軸にサイバーセキュリティ対応準備ドメインを据え、横軸にCCMv4のコントロール項目を据えて、マッピングした結果を整理し、それらの関係性を可視化している。

なお、サイバートラスト向けコンパニオンガイドの参考文献として、以下のようなドキュメントを挙げている。

• Cloud Controls Matrix v4 by Cloud Security Alliance
  （https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4）

グローバルクラウドサービスプロバイダーとの連携による成果物

加えて、コンパニオンガイドの開発における密接なパートナーシップの一環として、Amazon Web Services、Google Cloud、Microsoftも、以下の通り、サイバーエッセンシャルズおよびサイバートラストマークに記載されている対策に基づいて構成されたプロバイダー固有のガイドを開発・公開している。

• Google Workspace Cloud Security Companion Guide for Cyber Essentials – Jointly developed with Google
  （https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/google-workspace-security-companion-guide-for-cyber-essentials.pdf?sfvrsn=a19355aa_1）
• Microsoft Cloud Security Companion Guide for Cyber Essentials – Jointly developed with Microsoft
  （https://www.csa.gov.sg/docs/default-source/our-programmes/support-for-enterprises/sg-cyber-safe-programme/cloud-security/microsoft-cloud-security-companion-guide-cyber-essentials.pdf?sfvrsn=1d677c69_1）
• AWS Cloud Companion Guide for Cyber Trust – Jointly developed with AWS
  （https://d1.awsstatic.com/whitepapers/compliance/CSA_Cyber_Trust_mark_certification_Cloud_Companion_Guide.pdf）

シンガポールの場合、ここまで紹介した汎用的なクラウドセキュリティ関連プログラムおよび関連ツール類を踏まえた上で、金融管理庁（MAS）や保健科学庁（HAS）などが制定した業種別の法規制・ガイドライン類に対応していく必要がある。

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