Google Cloud における責任の共有と運命の共有

Last reviewed 2023-08-21 UTC

このドキュメントでは、Google Cloud の責任共有モデルと運命の共有について扱います。責任共有モデルの課題および微妙な違いについて取り上げ、運命の共有とは何か、クラウドのセキュリティ課題に対処するために Google がどのようにお客様と連携するかについて説明します。

Google Cloud 上のデータとワークロードの最適な保護方法を判断するうえで、責任共有モデルの理解は不可欠です。責任共有モデルは、クラウド内のセキュリティに関して利用者が担うべきタスクと、クラウド プロバイダ側で行うべきタスクとの違いを表しています。

しかし、責任の共有を理解するのは容易ではありません。このモデルでは、使用する各サービス、各サービスが提供する構成オプション、サービスを保護するために Google Cloud が何をするかについて深く理解する必要があります。すべてのサービスに異なる構成プロファイルがあるため、最適なセキュリティ構成を決定するのは容易ではありません。Google では、クラウドのお客様がより優れたセキュリティを得られるように支援するだけでは、責任共有モデルは成立しないと考えています。責任を単に共有するだけではなく、運命の共有も必要だと考えています。

運命の共有には、ワークロード用の信頼できるクラウド プラットフォームの構築と運用が含まれます。Google では、安全な方法でワークロードをデプロイするために使用できるベスト プラクティスのガイダンスと安全で実証済みのインフラストラクチャ コードを提供しています。さまざまな Google Cloud サービスを組み合わせて、複雑なセキュリティ問題を解決するソリューションをリリースし、お客様が受け入れなければならないリスクを測定して軽減できるように革新的な保険オプションを提供しています。お客様が Google Cloud でお客様のリソースを保護していくために、より緊密に協力していくことが必要になります。

責任の共有

お客様は、ビジネスのセキュリティと規制の要件、そして機密データやリソースを保護する要件を把握するエキスパートです。Google Cloud でワークロードを実行する場合、機密データと各ワークロードを保護するために、Google Cloud で構成する必要のあるセキュリティ コントロールを特定する必要があります。実装するセキュリティ コントロールを決定するには、次の要素を考慮する必要があります。

  • 法令遵守義務
  • 組織のセキュリティ基準とリスク管理計画
  • お客様とベンダーのセキュリティ要件

ワークロードによる定義

これまで、責任は、実行するワークロードの種類と必要なクラウド サービスに基づいて定義されてきました。クラウド サービスには次のカテゴリがあります。

クラウド サービス 説明
Infrastructure as a Service（IaaS） IaaS サービスには、Compute Engine、Cloud Storage のほかに、Cloud VPN、Cloud Load Balancing、Cloud DNS などのネットワーク サービスが含まれます。

IaaS は従量課金制で、コンピューティング、ストレージ、ネットワーク サービスをオンデマンドで提供します。IaaS は、リフト＆シフトで既存のオンプレミス ワークロードをクラウドに移行する場合、または特定のデータベースまたはネットワーク構成を使用してアプリケーションを特定の VM 上で実行する場合に利用されます。

IaaS では、セキュリティ責任の大部分をお客様が負い、Google の責任は、主に基盤となるインフラストラクチャと物理的なセキュリティになります。
Platform as a Service（PaaS） PaaS サービスには、App Engine、Google Kubernetes Engine（GKE）、BigQuery が含まれます。

PaaS は、アプリケーションの開発と実行に使用できるランタイム環境を提供します。PaaS は、アプリケーション（ウェブサイトなど）を構築していて、基盤となるインフラストラクチャではなく開発に集中したい場合に利用されます。

PaaS では、Google はネットワーク制御など、制御の責任を IaaS よりも多く負っています。お客様はアプリケーション レベルの制御と IAM の管理の責任を Google と共有します。データ セキュリティとクライアント保護については、お客様が引き続き責任を負います。
Software as a Service（SaaS） SaaS アプリケーションには、Google Workspace、Chronicle、Google Cloud Marketplace で入手できるサードパーティの SaaS アプリケーションが含まれます。

SaaS は、サブスクリプションできるか、なんらかの方法で決済が可能なオンライン アプリケーションを提供します。SaaS アプリケーションは、社内にアプリケーションを構築するための部門やビジネス要件を持たないものの、ワークロードを処理する能力が必要な場合に利用されます。

SaaS では、セキュリティの責任の大部分が Google にあります。アクセス制御とアプリケーションに保存するデータについては、引き続きお客様の責任となります。
Function as a Service（FaaS）またはサーバーレス

FaaS は、デベロッパーが特定のイベントに応答して実行される小規模な単一目的のコード（関数と呼ばれる）を実行するためのプラットフォームを提供します。FaaS は、特定のイベントに基づいて特定の処理を行う場合に利用されます。たとえば、データを Cloud Storage にアップロードするたびに実行され、データを分類する関数を作成する場合などに利用します。

FaaS には、SaaS と同様の責任共有リストがあります。Cloud Functions は FaaS アプリケーションです。

次の図は、クラウド サービスに対してクラウド プロバイダとお客様がどのように責任を共有するのかを示しています。

セキュリティの責任の共有

図が示すように、基盤となるネットワークとインフラストラクチャについてはクラウド プロバイダが常に責任を負います。お客様はアクセス ポリシーとデータについて常に責任を負います。

業界と規制のフレームワークによる定義

さまざまな業界で規制のフレームワークが定められており、導入しなければならないセキュリティ コントロールが定義されています。ワークロードをクラウドに移行する場合は、次のことを理解する必要があります。

  • ユーザー側で責任を負うべきセキュリティ コントロール
  • クラウド サービスの一部として利用できるセキュリティ コントロール
  • 継承されるデフォルトのセキュリティ コントロール

継承されたセキュリティ コントロール（デフォルトの暗号化やインフラストラクチャ制御など）は、セキュリティ対策のエビデンスの一部として監査担当者や規制当局に提供できるコントロールです。たとえば、Payment Card Industry Data Security Standard（PCI DSS）では、決済代行業者の規制が定義されています。ビジネスをクラウドに移行すると、これらの規制がお客様と CSP の間で共有されます。PCI DSS の責任を Google Cloud と共有する方法については、Google Cloud: PCI DSS の共有責任マトリックスをご覧ください。

別の例として、米国では、医療保険の相互運用性と説明責任に関する法律（HIPAA）によって、電子個人健康情報（PHI）を処理するための標準が定められています。これらの責任も CSP とお客様の間で共有されます。HIPAA に基づく Google の責任を Google Cloud でどのように果たされているか、詳細は HIPAA - コンプライアンスをご覧ください。

他の業界（金融や製造など）にも、データの収集、処理、保存の方法に対する規制があります。これらに関連する責任の共有の詳細と、Google Cloud で Google の責任がどのように果たされているかについては、コンプライアンス リソース センターをご覧ください。

場所による定義

ビジネス事例によっては、オフィス、顧客、データの所在地に応じて責任を考慮する必要があります。それぞれの国と地域では、お客様のデータの処理と保存の方法に対する規制が定められています。たとえば、EU に拠点を置く顧客に対するビジネスの場合、一般データ保護規則（GDPR）に記載されている要件を遵守する必要があります。また、顧客データを EU 域内に留めなければならない場合もあります。そのような状況では、収集したデータを EU 内の Google Cloud リージョン内に保持する責任があります。Google による GDPR 義務の遂行については、GDPR と Google Cloud をご覧ください。

リージョンに関連する要件については、コンプライアンスの提供をご覧ください。特に複雑なシナリオの場合は、セールスチームまたはパートナーに連絡して、セキュリティ責任の評価を受けることをおすすめします。

責任の共有での課題

責任共有は、ユーザーとクラウド プロバイダが担うセキュリティのロールを定義するのに役立ちますが、責任共有への依存には課題が生じる可能性があります。次のようなシナリオを考えてみましょう。

  • クラウド セキュリティ侵害のほとんどは構成ミスが原因で発生しています（Cloud Security Alliance の Pandemic 11 レポートでは 3 番目に多い原因と報告されています）。この傾向は今後さらに増加することが予想されます。クラウド プロダクトは絶えず変化しており、新しいプロダクトが常にリリースされています。絶え間ない変化に対応するのは大変な作業のように思えます。利用者には、デフォルトのベスト プラクティスと、ベースラインとなる安全な構成を用意し、変化に対応できる独自のベスト プラクティスを提供するクラウド プロバイダが必要です。
  • クラウド サービスで項目を分割することは便利ですが、企業の多くには、複数の種類のクラウド サービスを必要とするワークロードがあります。このような状況では、サービス間でさまざまなセキュリティ コントロールがどのように影響しあうのかを検討しなければなりません（たとえば、サービス間で重複するかどうかなど）。Google Workspace を会社のメールシステムとして利用し、製品の品質向上のため BigQuery でデータを分析しているときに、オンプレミス アプリケーションを Compute Engine に移行するケースもあります。
  • ビジネスと市場は、規制の変化、新規市場への参入、他の企業の買収に伴い常に変化しています。新しい市場には異なる要件があり、新しく買収した企業は別のクラウドにワークロードをホストしているかもしれません。絶え間ない変更を管理するには、リスク プロファイルを継続的に再評価し、新しいコントロールを迅速に実装できるようにする必要があります。
  • データ暗号鍵をどこで、どのように管理するかは、データを保護する責任と結びついた重要な判断となります。選択するオプションは、ハイブリッド クラウド環境を実行しているのか、あるいはオンプレミス環境にあるのか、さらに処理、保存するデータの機密性に応じた規制要件によって変わります。
  • インシデント管理は、お客様の責任とクラウド プロバイダの責任を簡単に定義できない領域であり、重要ですが見落とされがちです。多くのインシデントでは、インシデントの調査と軽減のためにクラウド プロバイダとの緊密な協力とサポートが必要になります。クラウド リソースの構成ミスや認証情報の盗難によって発生するインシデントもあり、リソースとアカウントを保護するためのベスト プラクティスを確実に実施することは容易ではありません。
  • 高度な持続的脅威（APT）と新たな脆弱性により、クラウド トランスフォーメーションの開始時には想定していなかった影響がワークロードに生じる可能性があります。特に、組織に大規模なセキュリティ チームがない場合は、変化する状況に応じて常に最新の状態に保ち、脅威軽減の責任者を確保することは至難の業です。

運命の共有

Google は、共有責任モデルで対応できない課題に対処するために、Google Cloud に運命の共有という考えを導入しました。運命の共有は、すべての関係者が継続的に協力してセキュリティを向上させる方法に重点を置いています。運命の共有は責任共有モデルの上に構築されるもので、クラウド プロバイダとお客様の関係を継続的なパートナーシップとして捉え、セキュリティを向上させることを目指しています。

運命の共有とは、お客様と Google が Google Cloud の安全性を高めるために責任を持つことです。運命の共有には、安全なランディング ゾーンの構築の支援だけでなく、推奨されるセキュリティ コントロール、設定、関連するベスト プラクティスに対して明確さ、独自性、透明性を持たせることも含まれます。また、Google の Risk Protection Program を使用したサイバー保険でリスクを定量化し、管理することも含まれます。Google は運命の共有を使用して、標準的な責任共有フレームワークを進化させ、ビジネスを保護しながら Google Cloud での信頼関係を構築できる、より優れたモデルに発展させたいと考えています。

以下のセクションでは、運命の共有におけるさまざまなコンポーネントについて説明します。

サポート

運命の共有の主要なコンポーネントは、Google Cloud の安全な構成を利用するためのリソースです。安全な構成から始めることで、ほとんどのセキュリティ侵害の根本原因である構成ミスの問題を削減できます。

Google では、次のリソースを用意しています。

Risk Protection Program

運命の共有には、Risk Protection Program（現在プレビュー版）も含まれています。これはクラウド ワークロードを単に管理する必要のあるリスクソースの一つとしてとらえるのではなく、Google Cloud の機能をリスク管理のプラットフォームとして使用できるように支援します。Risk Protection Program は、Google Cloud が大手サイバー保険会社である Munich Re および Allianz Global & Corporate Speciality と共同で開発したプログラムです。

Risk Protection Program には、クラウド セキュリティ ポスチャーをより深く理解するために使用できるデータドリブンな分析情報を提供する Risk Manager が含まれています。サイバー保険のカバレッジが必要な場合は、Risk Manager から得たこれらの分析情報を保険パートナーと直接共有して見積もりを取ることができます。詳細については、プレビュー版の Google Cloud Risk Protection Program をご覧ください。

デプロイとガバナンスに関するサポート

運命の共有は、お客様の環境へのガバナンスの継続にも役立ちます。たとえば、Google では次のようなプロダクトに注力しています。

  • Assured Workloads: コンプライアンスの遵守に役立ちます。
  • Security Command Center Premium。脅威インテリジェンス、脅威検出、ウェブスキャン、その他の高度な方法を使用して脅威をモニタリングし、検出します。また、これらの脅威の多くを迅速かつ自動的に解決する方法も提供されます。
  • 組織のポリシーとリソース設定。フォルダとプロジェクトの階層全体でポリシーを構成できます。
  • Policy Intelligence ツール。アカウントやリソースへのアクセスに関する分析情報を提供します。
  • Confidential Computing - 使用中のデータを暗号化できます。
  • Sovereign Cloud。ドイツで利用可能なプロダクトで、データ所在地の要件を実装します。

責任の共有と運命の共有の実践

計画プロセスの一環として、適切なセキュリティ コントールを理解して実装するため、次のアクションを検討してください。

  • Google Cloud でホストするワークロード タイプと、IaaS、PaaS、SaaS サービスが必要かどうかのリストを作成します。責任の共有の図をチェックリストとして使用して、検討が必要なセキュリティ コントールを確実に把握します。
  • 遵守する必要のある規制要件のリストを作成し、それらの要件に関連するコンプライアンス リソース センターのリソースにアクセスします。
  • アーキテクチャ センターで利用可能なブループリントとアーキテクチャのリストで、特定のワークロードに必要なセキュリティ コントロールを確認します。このブループリントは、アーキテクチャのデプロイに必要な推奨コントロールと IaC コードのリストを提供します。
  • ランディング ゾーンのドキュメントとエンタープライズ基盤ガイドの推奨事項を使用して、要件を満たすリソース階層とネットワーク アーキテクチャを設計します。安全なデータ ウェアハウスなど、独自のワークロード ブループリントを使用することで、開発プロセスをスムーズに進めることができます。
  • ワークロードをデプロイしたら、Risk Manager、Assured Workloads、Policy Intelligence ツール、Security Command Center Premium などのサービスを使用して、セキュリティの責任を満たしていることを確認します。

詳細については、CISO のクラウド トランスフォーメーション ガイドの文書をご覧ください。

次のステップ