Well-Architected Framework: セキュリティ、プライバシー、コンプライアンスの柱

Last reviewed 2025-02-14 UTC

Google Cloud Well-Architected Framework のセキュリティ、プライバシー、コンプライアンスの柱では、セキュリティ、プライバシー、コンプライアンスの要件を満たすクラウド ワークロードを設計、デプロイ、運用するうえで役立つ推奨事項について説明します。

このドキュメントは、さまざまなセキュリティ プロフェッショナルとエンジニアのニーズを満たす貴重な分析情報を提供する目的で作成されています。次の表に、このドキュメントの対象読者を示します。

オーディエンス このドキュメントの内容
最高情報セキュリティ責任者（CISO）、ビジネス ユニット リーダー、IT マネージャー クラウドで優れたセキュリティを確立して維持し、セキュリティ分野の包括的なビューを確保して、セキュリティ投資に関する十分な情報に基づいた意思決定を行うための一般的なフレームワーク。
セキュリティ アーキテクトとセキュリティ エンジニア ソリューションがセキュリティ、効率性、スケーラビリティを重視して設計されるように、設計フェーズと運用フェーズで行う主なセキュリティ対策。
DevSecOps チーム 包括的なセキュリティ制御を組み込み、安全で信頼性の高いインフラストラクチャを実現する自動化を計画するためのガイダンス。
コンプライアンス担当者、リスク管理担当者 コンプライアンス義務を満たすための安全保護対策を備えた、構造化されたリスク管理アプローチに沿った主なセキュリティ推奨事項。

Google Cloud ワークロードがセキュリティ、プライバシー、コンプライアンスの各要件を満たすようにするには、組織内のすべての関係者が協力的なアプローチを採用する必要があります。また、クラウド セキュリティはお客様と Google の間で共有される責任であることを認識する必要があります。詳細については、 Google Cloudにおける責任と運命の共有をご覧ください。

この柱の推奨事項は、コア セキュリティ原則にグループ化されています。各原則ベースの推奨事項は、組織にとって重要となる可能性があるクラウド セキュリティの重点分野の 1 つ以上にマッピングされます。各推奨事項では、組織のセセキュリティ ポスチャーを改善するうえで役立つGoogle Cloud のプロダクトや機能の使用と構成に関するガイダンスがハイライト表示されています。

基本原則

この柱の推奨事項は、次のセキュリティの基本原則にグループ化されています。この柱の原則はどれも重要です。組織やワークロードの要件によっては、特定の原則を優先させることができます。

  • 安全性を重視した設計を実装する: アプリケーションとインフラストラクチャの初期設計フェーズから、クラウド セキュリティとネットワーク セキュリティの考慮事項を組み込みます。Google Cloud には、この原則を適用するためのアーキテクチャ ブループリントと推奨事項が用意されています。
  • ゼロトラストを実装する: 「決して信用するな、常に検証せよ」のアプローチを使用します。リソースへのアクセスは、信頼の継続的な検証に基づいて許可されます。 Google Cloudは、Chrome Enterprise Premium や Identity-Aware Proxy（IAP）などのプロダクトを通じてこの原則をサポートしています。
  • シフトレフト セキュリティを実装する: ソフトウェア開発ライフサイクルの早い段階でセキュリティ管理を実装します。システムを変更する前にセキュリティ上の欠陥が生じるのを防ぎます。システムの変更が commit された後、セキュリティ バグを早期に、迅速かつ確実に検出して修正します。 Google Cloud は、Cloud Build、Binary Authorization、Artifact Registry などのプロダクトを通じてこの原則をサポートしています。
  • 先制的なサイバー防御を実装する: 脅威インテリジェンスなどの堅牢な基本的対策を実装して、セキュリティに対するプロアクティブなアプローチを採用します。このアプローチにより、脅威の検出と対応をより効果的に行うための基盤を構築できます。Google Cloudの階層化されたセキュリティ管理へのアプローチは、この原則に沿っています。
  • AI を安全かつ責任を持って使用する: AI システムを責任を持って安全に開発してデプロイします。この原則の推奨事項は、Well-Architected Framework の AI と ML の視点と Google の セキュア AI フレームワーク（SAIF）のガイダンスに沿っています。
  • セキュリティに AI を使用する: AI 機能を使用し、Gemini in Security と全体的なプラットフォーム セキュリティ機能を通じて、既存のセキュリティのシステムとプロセスを改善します。AI をツールとして使用して、復旧作業の自動化を促進し、セキュリティ対策を確実にして他のシステムのセキュリティを強化します。
  • 規制、コンプライアンス、プライバシーのニーズを満たす: 業界固有の規制、コンプライアンス標準、プライバシー要件に準拠します。 Google Cloud は、Assured Workloads、組織ポリシー サービス、コンプライアンス リソース センターなどのプロダクトを通じて、これらの義務への対応を支援します。

組織のセキュリティに関する考え方

クラウドの導入と運用を成功させるには、セキュリティを重視する組織の考え方が不可欠です。この考え方は組織の文化に深く根付いており、前述のコア セキュリティ原則に沿った実践に反映されている必要があります。

組織のセキュリティに関する考え方では、システム設計時にセキュリティを考慮し、ゼロトラストを前提として、開発プロセス全体を通じてセキュリティ機能を組み込むことが強調されます。この考え方では、サイバー防衛対策についても事前に検討し、AI を安全に使用してセキュリティを確保し、規制、プライバシー、コンプライアンスの各要件も考慮します。これらの原則を採用することで、脅威に事前に対処し、貴重なアセットを保護して、責任を持ってテクノロジーを使用するように支援するセキュリティ重視の文化を組織で育むことができます。

クラウド セキュリティの重点分野

このセクションでは、アプリケーション、システム、データのセキュリティを計画、実装、管理する際に重点を置くべき領域について説明します。この柱の各原則の推奨事項は、これらの重点分野の 1 つ以上に関連しています。このドキュメントの残りの部分では、推奨事項で対応するセキュリティの重点分野を明記し、さらに明確に詳細な背景を明らかにしています。

重点分野 アクティビティとコンポーネント 関連する Google Cloud のプロダクト、機能、ソリューション
インフラストラクチャのセキュリティ
  • ネットワーク インフラストラクチャを保護する。
  • 転送中と保存中のデータを暗号化する。
  • トラフィック フローを制御する。
  • IaaS サービスと PaaS サービスを保護する。
  • 不正なアクセスから保護する。
Identity and Access Management
  • 認証、認可、アクセス制御を使用する。
  • Cloud Identity を管理する。
  • Identity and Access Management ポリシーを管理する。
データセキュリティ
  • データを Google Cloud に安全に保存する。
  • データへのアクセスを管理する。
  • データを検出して分類する。
  • 暗号化、アクセス制御、データ損失防止といった必要な制御を設計する。
  • 保存中、転送中、使用中のデータを保護する。
AI と ML のセキュリティ
  • AI と ML のインフラストラクチャとパイプラインのさまざまなレイヤにセキュリティ制御を適用する。
  • モデルの安全性を確保する。
セキュリティ運用（SecOps）
  • 最新の SecOps プラットフォームと一連のプラクティスを採用して、効果的なインシデント管理、脅威の検出、対応プロセスを実現する。
  • システムとアプリケーションを継続的にモニタリングしてセキュリティ イベントを検出する。
アプリケーションのセキュリティ
  • ソフトウェアの脆弱性や攻撃からアプリケーションを保護する。
クラウドのガバナンス、リスク、コンプライアンス
  • クラウド リソースを効果的かつ安全に管理するためのポリシー、手順、制御を確立する。
ロギング、監査、モニタリング
  • ログを分析して潜在的な脅威を特定する。
  • コンプライアンスとセキュリティ分析のためにシステム アクティビティを追跡して記録する。

寄稿者

著者:

  • Wade Holmes | グローバル ソリューション ディレクター
  • Hector Diaz | クラウド セキュリティ アーキテクト
  • Carlos Leonardo Rosario | Google Cloud セキュリティ スペシャリスト
  • John Bacon | パートナー ソリューション アーキテクト
  • Sachin Kalra | グローバル セキュリティ ソリューション マネージャー

その他の寄稿者:

  • Anton Chuvakin | CISO オフィス、セキュリティ アドバイザー
  • Daniel Lees | クラウド セキュリティ アーキテクト
  • Filipe Gracio 博士 | カスタマー エンジニア
  • Gary Harmson | プリンシパル アーキテクト
  • Gino Pelliccia | プリンシパル アーキテクト
  • Jose Andrade | エンタープライズ インフラストラクチャ カスタマー エンジニア
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Laura Hyatt | エンタープライズ クラウド アーキテクト
  • Marwan Al Shawi | パートナー カスタマー エンジニア
  • Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
  • Noah McDonald | クラウド セキュリティ コンサルタント
  • Osvaldo Costa | ネットワーキング スペシャリスト カスタマー エンジニア
  • Radhika Kanakam | シニア プログラム マネージャー、Cloud GTM
  • Samantha He | テクニカル ライター
  • Susan Wu | アウトバウンド プロダクト マネージャー

安全性を重視した設計を実装する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、クラウド アプリケーション、サービス、プラットフォームの設計に堅牢なセキュリティ機能、制御、プラクティスを組み込むための推奨事項が示されています。アイデア出しから運用まで、セキュリティは設計プロセスのあらゆる段階に不可欠な要素として組み込まれている場合に、より効果を発揮します。

原則の概要

Google の Secure by Design への取り組みの概要で説明されているように、デフォルトでセキュリティを確保すると設計でセキュリティを確保するは同じ意味で使われることが多いですが、安全なシステムを構築するための異なるアプローチを表しています。どちらのアプローチも脆弱性を最小限に抑え、セキュリティを強化することを目的としていますが、範囲と実装が異なります。

  • デフォルトで安全: システムのデフォルト設定が安全なモードに設定されていることを確認し、ユーザーや管理者がシステムを保護するための操作を行う必要性を最小限に抑えることに重点を置いています。このアプローチは、すべてのユーザーにベースライン レベルのセキュリティを提供することを目的としています。
  • Secure by design: システムの開発ライフサイクル全体を通してセキュリティ上の考慮事項を積極的に組み込むことを重視します。このアプローチでは、潜在的な脅威や脆弱性を早期に予測し、リスクを軽減する設計を選択します。このアプローチでは、安全なコーディング プラクティスを使用し、セキュリティ レビューを実施し、設計プロセス全体にセキュリティを組み込みます。セキュア・バイ・デザイン アプローチは、開発プロセスを導き、セキュリティが後付けではなく、システムの設計に不可欠な部分となるようにする包括的な哲学です。

推奨事項

クラウド ワークロードに設計によるセキュリティ原則を実装するには、次のセクションの推奨事項を検討してください。

ワークロードの保護に役立つシステム コンポーネントを選択する

この推奨事項は、すべての重点分野に関連しています。

効果的なセキュリティを実現するための基本的な決定は、プラットフォーム、ソリューション、サービスを構成する堅牢なシステム コンポーネント（ハードウェア コンポーネントとソフトウェア コンポーネントの両方を含む）の選択です。セキュリティ攻撃の対象領域を減らし、潜在的な損害を制限するには、これらのコンポーネントのデプロイ パターンとその構成も慎重に検討する必要があります。

アプリケーション コードでは、脆弱性のクラスを排除するために、シンプルで安全かつ信頼性の高いライブラリ、抽象化、アプリケーション フレームワークを使用することをおすすめします。ソフトウェア ライブラリの脆弱性をスキャンするには、サードパーティ ツールを使用できます。また、Assured Open Source Software を使用することもできます。これは、Google が使用して保護しているオープンソース ソフトウェア（OSS）パッケージを使用することで、ソフトウェア サプライ チェーンに対するリスクを軽減するのに役立ちます。

インフラストラクチャでは、安全な運用をサポートし、セキュリティ要件とリスク許容レベルに沿ったネットワーキング、ストレージ、コンピューティングのオプションを使用する必要があります。インフラストラクチャのセキュリティは、インターネットに接続するワークロードと内部ワークロードの両方にとって重要です。

この推奨事項をサポートする他の Google ソリューションについては、シフトレフト セキュリティを実装するをご覧ください。

階層化されたセキュリティ アプローチを構築する

この推奨事項は、次の重点分野に関連しています。

  • AI と ML のセキュリティ
  • インフラストラクチャのセキュリティ
  • ID とアクセスの管理
  • データ セキュリティ

多層防御アプローチを適用して、アプリケーションとインフラストラクチャ スタックの各レイヤでセキュリティを実装することをおすすめします。

プラットフォームの各コンポーネントのセキュリティ機能を使用します。セキュリティ インシデントが発生した場合にアクセスを制限し、潜在的な影響の範囲（ブラスト半径）を特定するには、次の操作を行います。

  • 可能であれば、柔軟性に対応するためにシステム設計を簡素化します。
  • 各コンポーネントのセキュリティ要件を文書化します。
  • 復元性と復元の要件に対応する堅牢なセキュリティ メカニズムを組み込みます。

セキュリティ レイヤを設計するときは、リスク評価を実施して、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を特定します。クラウド環境に適用され、規制要件に関連する業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、Cloud Security Alliance（CSA）は Cloud Controls Matrix（CCM）を提供します。リスク評価では、リスクのカタログと、それらを軽減するための対応するセキュリティ制御が提供されます。

リスク評価を行う際は、クラウド プロバイダとの責任共有契約があることを念頭に置いてください。そのため、クラウド環境におけるリスクは、オンプレミス環境におけるリスクとは異なります。たとえば、オンプレミス環境ではハードウェア スタックの脆弱性を軽減する必要があります。一方、クラウド環境では、こうしたリスクはクラウド プロバイダが負担します。また、共有責任の境界は、クラウド プロバイダごとに IaaS、PaaS、SaaS サービスで異なることに注意してください。

潜在的なリスクを特定したら、技術的、管理的、運用的コントロール、契約による保護、サードパーティの証明を使用して、軽減計画を設計して作成する必要があります。また、OWASP アプリケーションの脅威モデリング方法などの脅威モデリング方法を使用すると、潜在的なギャップを特定し、ギャップに対処するためのアクションを提案できます。

強化された証明済みのインフラストラクチャとサービスを使用する

この推奨事項は、すべての重点分野に関連しています。

成熟したセキュリティ プログラムは、セキュリティ情報で説明されている新しい脆弱性を軽減します。セキュリティ プログラムでは、既存のデプロイの脆弱性を修正し、VM イメージとコンテナ イメージを保護するための修復も提供する必要があります。イメージの OS とアプリケーションに固有の強化ガイドと、インターネット セキュリティ センター（CIS）が提供するベンチマークなどのベンチマークを使用できます。

Compute Engine VM にカスタム イメージを使用する場合は、イメージに自分でパッチを適用する必要があります。また、定期的にパッチが適用される Google 提供の厳選された OS イメージを使用することもできます。Compute Engine VM でコンテナを実行するには、Google が厳選した Container-Optimized OS イメージを使用します。Google はこれらのイメージのパッチと更新を定期的に行っています。

GKE を使用している場合は、クラスタノードに常に最新のパッチが適用されるように、ノードの自動アップグレードを有効にすることをおすすめします。Google は GKE コントロール プレーンを管理し、自動更新を行ってパッチを適用しています。コンテナの攻撃対象領域をさらに縮小するには、ディストロレス イメージを使用します。Distroless イメージは、セキュリティが重視されるアプリケーション、マイクロサービス、イメージ サイズと攻撃対象領域の最小化が最優先される状況に最適です。

機密性の高いワークロードには、VM 起動サイクル中に悪意のあるコードが読み込まれるのを防ぐ Shielded VM を使用します。Shielded VM インスタンスは、ブート セキュリティを提供し、整合性をモニタリングします。また、Virtual Trusted Platform Module（vTPM）を使用します。

SSH アクセスのセキュリティを強化するために、OS Login を使用すると、従業員は SSH 認証鍵に依存することなく、Identity and Access Management（IAM）権限を信頼できる情報源として使用して VM に接続できます。したがって、組織全体で SSH 認証鍵を管理する必要はありません。OS Login では、管理者による従業員のライフサイクルへのアクセスが関連付けられます。そのため、従業員がロールを変更したり、退職した場合、そのユーザーのアクセス権はそのユーザーのアカウントで取り消されます。OS Login は Google の 2 要素認証もサポートしています。これにより、アカウントの乗っ取り攻撃に対するセキュリティを強化できます。

GKE では、アプリケーション インスタンスは Docker コンテナ内で実行されます。定義済みのリスク プロファイルを有効にして、ユーザーがコンテナを変更できないようにするには、コンテナをステートレスにし、変更されないようにします。不変性の原則は、従業員がコンテナを変更したり、コンテナにインタラクティブにアクセスしないことを意味します。コンテナを変更する必要がある場合は、新しいイメージを作成してデプロイします。特定のデバッグ シナリオでのみ、基盤となるコンテナへの SSH アクセスを有効にします。

環境全体で構成をグローバルに保護するには、組織のポリシーを使用して、クラウド アセットの動作に影響するリソースに制約またはガードレールを設定します。たとえば、次の組織のポリシーを定義し、 Google Cloud 組織全体にグローバルに適用するか、フォルダまたはプロジェクトのレベルで選択的に適用できます。

  • VM への外部 IP アドレスの割り当てを無効にします。
  • リソースの作成を特定の地理的ロケーションに制限します。
  • サービス アカウントまたはそのキーの作成を無効にします。

保存データと転送中のデータを暗号化する

この推奨事項は、次の重点分野に関連しています。

  • インフラストラクチャのセキュリティ
  • データ セキュリティ

データ暗号化は、機密情報を保護するための基本的な制御であり、データ ガバナンスの重要な部分です。効果的なデータ保護戦略には、アクセス制御、データのセグメンテーションと地理的所在地、監査、要件の慎重な評価に基づく暗号化の実装が含まれます。

デフォルトでは、 Google Cloudは保存されている顧客データを暗号化します。ユーザーが特別な操作を行う必要はありません。Google Cloud では、デフォルトの暗号化に加えて、エンベロープ暗号化と暗号鍵を管理できます。ストレージ、コンピューティング、ビッグデータ ワークロード用の鍵の選択に関しては、鍵の生成、保管、ローテーションの要件にどのソリューションが最適かを判断する必要があります。たとえば、顧客管理の暗号鍵（CMEK）は Cloud Key Management Service（Cloud KMS）で作成できます。CMEK は、暗号鍵を定期的にローテーションする必要があるなど、規制要件やコンプライアンス要件を満たすために、ソフトウェア ベースまたは HSM で保護できます。Cloud KMS Autokey を使用すると、CMEK のプロビジョニングと割り当てを自動化できます。また、Cloud External Key Manager（Cloud EKM）を使用して、サードパーティの鍵管理システムから取得した独自の鍵を持ち込むこともできます。

転送中のデータを暗号化することを強くおすすめします。転送中のデータはすべて、Google が管理しているまたは Google が管理を委託している物理的境界の外へ出るときに、1 つ以上のネットワーク レイヤで暗号化され認証されます。VPC ネットワーク内およびピアリングされた VPC ネットワーク間の VM 間トラフィックはすべて暗号化されます。Cloud Interconnect 接続を介したトラフィックの暗号化には、MACsec を使用できます。IPsec は、Cloud VPN 接続を介したトラフィックの暗号化を提供します。コンテナ化されたアプリケーションでは、Apigee の TLS と mTLS の構成や Cloud Service Mesh などのセキュリティ機能を使用して、クラウド内のアプリケーション間のトラフィックを保護できます。

デフォルトでは、 Google Cloud はネットワーク全体で保存データと転送中のデータを暗号化します。ただし、メモリ内で使用中のデータはデフォルトでは暗号化されません。組織で機密データを扱う場合は、アプリケーション メモリまたはシステムメモリ内のデータの機密性と整合性を損なう脅威に対処する必要があります。これらの脅威を軽減するには、コンピューティング ワークロードに信頼できる実行環境を提供する Confidential Computing を使用します。詳細については、Confidential VMs の概要をご覧ください。

ゼロトラストを実装する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則は、クラウド ワークロード全体で包括的なセキュリティを確保するうえで役立ちます。ゼロトラストの原則では、次のプラクティスが重視されます。

  • 暗黙的な信頼の排除
  • アクセス制御に最小権限の原則を適用する
  • すべてのアクセス リクエストの明示的な検証を適用する
  • 継続的な検証とセキュリティ体制のモニタリングを可能にするために、侵害を想定した考え方を採用する

原則の概要

ゼロトラスト モデルでは、セキュリティの焦点が境界ベースのセキュリティから、ユーザーやデバイスは本質的に信頼できるとは見なされないアプローチに移行します。代わりに、アクセス リクエストは発信元に関係なく検証する必要があります。このアプローチでは、すべてのユーザーとデバイスを認証して認可し、コンテキスト（場所とデバイスのポスチャー）を検証し、必要なリソースにのみ最小権限のアクセス権を付与します。

ゼロトラスト モデルを実装すると、潜在的な侵害の影響を最小限に抑え、機密データとアプリケーションを不正アクセスから保護することで、組織のセキュリティ体制を強化できます。ゼロトラスト モデルは、クラウド内のデータとリソースの機密性、完全性、可用性を確保するのに役立ちます。

推奨事項

クラウド ワークロードにゼロトラスト モデルを実装するには、次のセクションの推奨事項を検討してください。

ネットワークを保護する

この推奨事項は、インフラストラクチャ セキュリティという重点分野に関連しています。

従来の境界ベースのセキュリティからゼロトラスト モデルへの移行には、複数の手順が必要です。組織によっては、すでに特定のゼロトラスト制御をセキュリティ体制に統合している場合があります。ただし、ゼロトラスト モデルは単一のプロダクトやソリューションではありません。複数のセキュリティ レイヤとベスト プラクティスを包括的に統合したものです。このセクションでは、ネットワーク セキュリティにゼロトラストを実装するためのおすすめの方法と手法について説明します。

  • アクセス制御: Chrome Enterprise Premium や Identity-Aware Proxy（IAP）などのソリューションを使用して、ユーザー ID とコンテキストに基づいてアクセス制御を適用します。これにより、セキュリティがネットワーク境界から個々のユーザーやデバイスに移行します。このアプローチにより、きめ細かいアクセス制御が可能になり、攻撃対象領域が縮小されます。
  • ネットワーク セキュリティ: オンプレミス環境、 Google Cloud環境、マルチクラウド環境間のネットワーク接続を保護します。
  • ネットワーク設計: 既存のプロジェクトでデフォルト ネットワークを削除し、新しいプロジェクトでデフォルト ネットワークの作成を無効にすることで、潜在的なセキュリティ リスクを防ぎます。
    • 競合を回避するには、ネットワークと IP アドレスの割り振りを慎重に計画してください。
    • アクセス制御を効果的に実施するには、プロジェクトあたりの Virtual Private Cloud（VPC）ネットワークの数を制限します。
  • セグメンテーション: ワークロードを分離しますが、ネットワーク管理は一元化されたままです。
    • ネットワークをセグメント化するには、共有 VPC を使用します。
    • 組織、フォルダ、VPC ネットワークのレベルでファイアウォール ポリシーとルールを定義します。
    • データの引き出しを防ぐには、VPC Service Controls を使用して、機密データとサービスの周囲に安全な境界を確立します。
  • 境界セキュリティ: DDoS 攻撃とウェブ アプリケーションの脅威から保護します。
    • 脅威から保護するには、Google Cloud Armor を使用します。
    • Google Cloud エッジでトラフィックを許可、拒否、またはリダイレクトするようにセキュリティ ポリシーを構成します。
  • 自動化: Infrastructure as Code（IaC）の原則を採用し、Terraform、Jenkins、Cloud Build などのツールを使用して、インフラストラクチャのプロビジョニングを自動化します。IaC は、一貫したセキュリティ構成、デプロイの簡素化、問題発生時の迅速なロールバックを保証するのに役立ちます。
  • 安全な基盤: エンタープライズ基盤ブループリントを使用して、安全なアプリケーション環境を確立します。このブループリントでは、セキュリティのベスト プラクティスを実装し、Google Cloud リソースを安全に構成するための規範的なガイダンスと自動化スクリプトを提供します。

すべてのアクセス試行を明示的に検証する

この推奨事項は、次の重点分野に関連しています。

  • ID とアクセスの管理
  • セキュリティ運用（SecOps）
  • ロギング、監査、モニタリング

クラウド リソースにアクセスしようとするユーザー、デバイス、サービスに対して、厳格な認証メカニズムと認可メカニズムを実装します。セキュリティ制御として、ロケーションやネットワーク境界に依存しないでください。ネットワーク内にすでに存在する場合でも、ユーザー、デバイス、サービスを自動的に信頼しないでください。代わりに、リソースへのアクセス試行はすべて厳密に認証され、認可される必要があります。多要素認証（MFA）などの強力な本人確認対策を実装する必要があります。また、アクセス権判定が、ユーザーの役割、デバイスのポスチャー、場所などのさまざまなコンテキスト要素を考慮したきめ細かいポリシーに基づいて行われるようにする必要があります。

この推奨事項を実装するには、次の方法、ツール、テクノロジーを使用します。

  • 統合 ID 管理: 単一の ID プロバイダ（IdP）を使用して、組織全体で一貫した ID 管理を実現します。
    • Google Cloud は、オンプレミスの Active Directory など、ほとんどの IdP との連携をサポートしています。連携を使用すると、既存の ID 管理インフラストラクチャを Google Cloud に拡張し、ユーザーのシングル サインオン（SSO）を有効にできます。
    • 既存の IdP がない場合は、Cloud Identity Premium または Google Workspace の使用を検討してください。
  • サービス アカウントの権限を制限する: サービス アカウントを慎重に使用し、最小権限の原則を遵守します。
    • 各サービス アカウントが指定されたタスクを実行するために必要な権限のみを付与します。
    • Google Kubernetes Engine（GKE）で実行されるアプリケーション、またはGoogle Cloud の外部で実行されるアプリケーションがリソースに安全にアクセスするには、Workload Identity Federation を使用します。
  • 堅牢なプロセス: クラウド セキュリティのベスト プラクティスに沿って ID プロセスを更新します。
    • 規制要件の遵守を確実にするため、ID ガバナンスを実装して、アクセス、リスク、ポリシー違反を追跡します。
    • アクセス制御のロールと権限の付与と監査に関する既存のプロセスを確認して更新します。
  • 強力な認証: ユーザー認証に SSO を実装し、特権アカウントに MFA を実装します。
    • Google Cloud は、セキュリティ強化のために、Titan セキュリティ キーなど、さまざまな MFA 手法をサポートしています。
    • ワークロード認証には、OAuth 2.0 または署名付き JSON ウェブトークン（JWT）を使用します。
  • 最小権限: 最小権限の原則と職務分離の原則を適用することで、不正アクセスとデータ侵害のリスクを最小限に抑えます。
    • ユーザー アクセスのオーバープロビジョニングを回避します。
    • 機密性の高いオペレーションにジャストインタイム特権アクセスを実装することを検討します。
  • ロギング: 管理者とデータアクセス アクティビティの監査ロギングを有効にします。
    • 分析と脅威の検出を行うには、Security Command Center Enterprise または Google Security Operations を使用してログをスキャンします。
    • セキュリティ ニーズとストレージ費用とのバランスを取るように、適切なログ保持ポリシーを構成します。

ネットワークのモニタリングとメンテナンス

この推奨事項は、次の重点分野に関連しています。

  • ロギング、監査、モニタリング
  • アプリケーションのセキュリティ
  • セキュリティ運用（SecOps）
  • インフラストラクチャのセキュリティ

セキュリティ対策を計画して実装する際は、攻撃者がすでに環境内に侵入していることを前提としてください。この事前対応型のアプローチでは、次の複数のツールと手法を使用して、ネットワークの可視性を高めます。

  • ロギングとモニタリングの一元化: 一元化されたロギングとモニタリングを通じて、すべてのクラウド リソースからセキュリティ ログを収集して分析します。

    • 通常のネットワーク動作のベースラインを確立し、異常を検出し、潜在的な脅威を特定します。
    • ネットワーク トラフィック フローを継続的に分析して、疑わしいパターンと潜在的な攻撃を特定します。

  • ネットワーク パフォーマンスとセキュリティに関する分析情報: ネットワーク アナライザなどのツールを使用します。トラフィックをモニタリングして、悪意のあるアクティビティを示す可能性のある異常なプロトコル、予期しない接続、データ転送の急増がないか確認します。

  • 脆弱性のスキャンと修復: ネットワークとアプリケーションの脆弱性を定期的にスキャンします。

    • Web Security Scanner を使用します。これは、Compute Engine インスタンス、コンテナ、GKE クラスタの脆弱性を自動的に特定できます。
    • 脆弱性の重大度とシステムに対する潜在的な影響に基づいて、修復の優先順位を付けます。

  • 侵入検知: Cloud IDS と Cloud NGFW 侵入防止サービスを使用して、ネットワーク トラフィックで悪意のあるアクティビティをモニタリングし、不審なイベントを自動的にブロックするか、アラートを取得します。

  • セキュリティ分析: Google SecOps の実装を検討して、さまざまなソースからのセキュリティ イベントを関連付け、セキュリティ アラートのリアルタイム分析を提供し、インシデント対応を容易にします。

  • 一貫性のある構成: 構成管理ツールを使用して、ネットワーク全体で一貫性のあるセキュリティ構成を確保します。

シフトレフト セキュリティを実装する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則は、ソフトウェア開発ライフサイクルの早い段階で実装してセキュリティ対策を改善できる実用的な制御を特定するうえで役立ちます。予防的なセキュリティ ガードレールとデプロイ後のセキュリティ管理の実装に役立つ推奨事項が提供されます。

原則の概要

シフトレフト セキュリティとは、ソフトウェア開発ライフサイクルの早い段階でセキュリティ プラクティスを採用することを意味します。この原則の目標は次のとおりです。

  • システムを変更する前にセキュリティ上の欠陥が生じるのを防ぎます。予防的なセキュリティ ガードレールを実装し、Infrastructure as Code（IaC）、Policy as Code、CI/CD パイプラインでのセキュリティ チェックなどのプラクティスを採用します。 Google Cloudでは、組織のポリシー サービスや強化された GKE クラスタなど、他のプラットフォーム固有の機能も使用できます。
  • システムの変更が commit された後、セキュリティ バグを早期に、迅速かつ確実に検出して修正します。コードレビュー、デプロイ後の脆弱性スキャン、セキュリティ テストなどの手法を採用します。

安全性を重視した設計を実装する原則とシフトレフト セキュリティの原則は関連していますが、範囲が異なります。設計によるセキュリティの原則は、システム全体の再構築が必要になるような根本的な設計上の欠陥を回避するのに役立ちます。たとえば、脅威モデリングの演習で、現在の設計に認可ポリシーが含まれておらず、それがないとすべてのユーザーが同じレベルのアクセス権を持つことが明らかになったとします。シフトレフト セキュリティは、変更が適用される前に実装の欠陥（バグや構成ミス）を回避し、デプロイ後の迅速かつ信頼性の高い修正を可能にします。

推奨事項

クラウド ワークロードにシフトレフト セキュリティ原則を実装するには、次のセクションの推奨事項を検討してください。

予防的なセキュリティ管理を導入する

この推奨事項は、次の重点分野に関連しています。

  • ID とアクセスの管理
  • クラウドのガバナンス、リスク、コンプライアンス

予防的セキュリティ制御は、クラウドで強固なセキュリティ体制を維持するために不可欠です。これらの制御により、リスクを事前に軽減できます。構成ミスやリソースへの不正アクセスを防ぎ、デベロッパーが効率的に作業できるようにし、業界標準と内部ポリシーへの準拠を確保できます。

予防的なセキュリティ管理は、Infrastructure as Code（IaC）を使用して実装すると、より効果的です。IaC を使用すると、変更がデプロイされる前に、インフラストラクチャ コードに対するよりカスタマイズされたチェックを予防的セキュリティ制御に含めることができます。自動化と組み合わせると、予防的セキュリティ制御は CI/CD パイプラインの自動チェックの一部として実行できます。

次のプロダクトと機能は、環境に予防的制御を実装するのに役立ちます。 Google Cloud

IAM を使用すると、権限に基づいて特定のリソースを操作できるユーザーを承認できます。詳細については、IAM を使用した組織リソースのアクセス制御をご覧ください。

組織ポリシー サービスを使用すると、リソースの制限を設定して、構成方法を指定できます。たとえば、組織のポリシーを使用して次のことができます。

組織のポリシーを使用するだけでなく、次の方法でリソースへのアクセスを制限できます。

  • IAM を使用したタグ: 各リソースのアクセス権限を定義するのではなく、リソースのセットにタグを割り当てて、タグ自体のアクセス定義を設定します。
  • IAM Conditions: リソースに条件付きの属性ベースのアクセス制御を定義します。
  • 多層防御: VPC Service Controls を使用して、リソースへのアクセスをさらに制限します。

リソース管理の詳細については、 Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。

クラウド リソースのプロビジョニングと管理を自動化する

この推奨事項は、次の重点分野に関連しています。

  • アプリケーションのセキュリティ
  • クラウドのガバナンス、リスク、コンプライアンス

クラウド リソースとワークロードのプロビジョニングと管理を自動化する場合は、命令型スクリプトではなく宣言型 IaC を採用すると、より効果的です。IaC はセキュリティ ツールやセキュリティ対策そのものではありませんが、プラットフォームのセキュリティ強化に役立ちます。IaC を採用すると、再現可能なインフラストラクチャを作成し、運用チームに既知の正常な状態を提供できます。また、IaC はロールバック、変更の監査、トラブルシューティングの効率も向上させます。

IaC を CI/CD パイプラインや自動化と組み合わせると、OPA などのツールを使用して Policy as Code などのプラクティスを採用することもできます。インフラストラクチャの変更を監査し、変更がデプロイされる前にインフラストラクチャ コードの自動チェックを実行できます。

インフラストラクチャのデプロイを自動化するには、Config Controller、Terraform、Jenkins、Cloud Build などのツールを使用できます。IaC と自動化を使用して安全なアプリケーション環境を構築できるように、Google Cloud はエンタープライズ基盤のブループリントを提供します。このブループリントは、Google の推奨プラクティスと構成に沿った独自の設計です。このブループリントには、Terraform と Cloud Build を使用して Google Cloud トポロジを構成してデプロイする手順が記載されています。

エンタープライズ基盤ブループリントのスクリプトを変更して、Google の推奨事項に沿って独自のセキュリティ要件を満たす環境を構成できます。このブループリントと追加のブループリントに基づいて構築することも、独自の自動化を設計することもできます。Google Cloud アーキテクチャ センターには、エンタープライズ基盤ブループリントの上に実装できる他のブループリントが用意されています。以下に、これらのブループリントの例をいくつか示します。

安全なアプリケーション リリースを自動化する

この推奨事項は、アプリケーション セキュリティという重点分野に関連しています。

自動化されたツールを使用しない場合、一貫したセキュリティ要件を満たすために、複雑なアプリケーション環境のデプロイ、更新、パッチの適用を行うことは容易なことではありません。ソフトウェア開発ライフサイクル（SDLC）用に自動化された CI/CD パイプラインを構築することをおすすめします。自動化された CI/CD パイプラインを使用すると、手動によるエラーをなくすことができます。標準化された開発フィードバック ループが提供されるので、プロダクトの効率的な反復が可能になります。継続的デリバリーは、DORA フレームワークが推奨するベスト プラクティスの 1 つです。

CI/CD パイプラインを使用してアプリケーション リリースを自動化すると、セキュリティ バグを早期に、迅速かつ確実に検出して修正する能力が向上します。たとえば、アーティファクトの作成時にセキュリティの脆弱性を自動的にスキャンしたり、セキュリティ レビューの範囲を絞り込んだり、既知の安全なバージョンにロールバックしたりできます。さまざまな環境（開発環境、テスト環境、本番環境など）に対してポリシーを定義し、検証されたアーティファクトのみをデプロイすることもできます。

アプリケーション リリースを自動化し、CI/CD パイプラインにセキュリティ チェックを組み込むために、 Google Cloud は Cloud Build、Cloud Deploy、Web Security Scanner、Binary Authorization などの複数のツールを提供しています。

SDLC で複数のセキュリティ要件を検証するプロセスを確立するには、Google が定義したソフトウェア アーティファクトのサプライ チェーン レベル（SLSA）フレームワークを使用します。SLSA では、ソースコード、ビルドプロセス、コードの来歴のセキュリティ チェックが必要です。これらの要件の多くは、自動化された CI/CD パイプラインに含めることができます。Google がこれらのプラクティスを社内でどのように適用しているかについては、変更に対するGoogle Cloudのアプローチをご覧ください。

アプリケーションのデプロイが承認プロセスに従っていることを確認します

この推奨事項は、アプリケーション セキュリティという重点分野に関連しています。

攻撃者が CI/CD パイプラインを侵害すると、アプリケーション スタック全体が影響を受ける可能性があります。パイプラインを保護するには、コードを本番環境にデプロイする前に、確立された承認プロセスを適用する必要があります。

Google Kubernetes Engine（GKE）、GKE Enterprise、Cloud Run を使用する場合は、Binary Authorization を使用して承認プロセスを確立できます。Binary Authorization は、構成可能な署名をコンテナ イメージに適用します。これらのシグネチャ（証明書）はイメージの検証に役立ちます。デプロイ時に、Binary Authorization はこれらの証明書を使用して、プロセスが完了したかどうかを判断します。たとえば、Binary Authorization を使用して次のことができます。

  • 特定のビルドシステムまたは CI パイプラインによってコンテナ イメージが作成されたことを確認する。
  • コンテナ イメージが脆弱性署名ポリシーを遵守していることを確認する。
  • コンテナ イメージが次のデプロイ環境（デプロイから QA まで）に昇格するための基準を満たしていることを確認する。

Binary Authorization を使用すると、信頼できるコードのみがターゲット プラットフォームで実行されるようにできます。

アプリケーションのデプロイ前に既知の脆弱性をスキャンする

この推奨事項は、アプリケーション セキュリティという重点分野に関連しています。

アプリケーション アーティファクトを本番環境にデプロイする前に、アプリケーション アーティファクトに対して継続的に脆弱性スキャンを実施できる自動化ツールの使用をおすすめします。

コンテナ化されたアプリケーションの場合は、Artifact Analysis を使用して、コンテナ イメージの脆弱性スキャンを自動的に実行します。Artifact Analysis は、Artifact Registry にアップロードされた新しいイメージをスキャンします。このスキャンにより、コンテナ内のシステム パッケージに関する情報が抽出されます。最初のスキャンの後、Artifact Analysis は、Artifact Registry 内でスキャンされたイメージのメタデータに新たな脆弱性がないか継続的にモニタリングを行います。Artifact Analysis は、新しい脆弱性情報と更新された脆弱性情報を脆弱性ソースから受け取ると、次の処理を行います。

  • スキャンしたイメージのメタデータを更新して、最新の状態に保つ。
  • 新しいメモ用の新しい脆弱性オカレンスを作成する。
  • 有効ではなくなった脆弱性を削除する。

アプリケーション コードで既知の脆弱性をモニタリングします

この推奨事項は、アプリケーション セキュリティという重点分野に関連しています。

自動化ツールを使用して、アプリケーション コードの既知の脆弱性（OWASP Top 10 など）を常にモニタリングします。OWASP Top 10 の緩和策をサポートする Google Cloud プロダクトと機能の詳細については、 Google Cloudにおける OWASP Top 10 緩和策をご覧ください。

Web Security Scanner を使用すると、App Engine、Compute Engine、GKE ウェブ アプリケーションの脆弱性を特定できます。このスキャナは、アプリケーションをクロールして、開始 URL の範囲内にあるすべてのリンクをたどり、できる限り多くのユーザー入力とイベント ハンドラを処理しようとします。クロスサイト スクリプティング、コード インジェクション、混合コンテンツ、古いライブラリや安全でないライブラリなど、一般的な脆弱性を自動的にスキャンして検出できます。Web Security Scanner は、誤検出を発生させることなく、これらの脆弱性を早期に特定します。

また、GKE Enterprise を使用して Kubernetes クラスタのフリートを管理している場合、セキュリティ ポスチャー ダッシュボードには、フリートのセキュリティ ポスチャーを改善するための独自の実行可能な推奨事項が表示されます。

先制的なサイバー防御を実装する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、全体的なセキュリティ戦略の一環として堅牢なサイバー防御プログラムを構築するうえで役に立つ推奨事項が示されています。

この原則では、防御側の優位性: サイバー防御のアクティブ化へのガイドで定義されているように、脅威インテリジェンスを使用して、コア サイバー防御機能全体で取り組みを事前にガイドすることを重視しています。

原則の概要

サイバー攻撃からシステムを防御する際には、攻撃者に対して大きな、十分に活用されていない利点があります。Mandiant の創設者が述べているように、自社のビジネス、システム、トポロジ、インフラストラクチャについて、どの攻撃者よりも熟知しているはずです。これは大きな利点です。」この固有の利点を活用するために、このドキュメントでは、防御側の優位性フレームワークにマッピングされた、予防的で戦略的なサイバー防御対策に関する推奨事項について説明します。

推奨事項

クラウド ワークロードに予防的なサイバー防御を実装するには、次のセクションの推奨事項を検討してください。

サイバー防御の機能を統合する

この推奨事項は、すべての重点分野に関連しています。

The Defender's Advantage フレームワークでは、サイバー防御の 6 つの重要な機能（インテリジェンス、検出、対応、検証、ハンティング、管制センター）を特定しています。各機能はサイバー防御ミッションの個別の部分にフォーカスしますが、効果的な防御を提供するには、これらの機能が適切に連携し、連携して動作する必要があります。各機能が相互にサポートする堅牢な統合システムの構築に注力します。導入に段階的なアプローチが必要な場合は、次の推奨順序を検討してください。現在のクラウドの成熟度、リソース トポロジ、特定の脅威の状況に応じて、特定の機能を優先することがあります。

  1. インテリジェンス: インテリジェンス機能は、他のすべての機能をガイドします。最も可能性の高い攻撃者、その戦術、手法、手順（TTP）、潜在的な影響など、脅威の状況を把握することは、プログラム全体でアクションの優先順位付けを行ううえで非常に重要です。インテリジェンス機能は、ステークホルダーの特定、インテリジェンス要件の定義、データの収集、分析と普及、自動化、サイバー脅威プロファイルの作成を担当します。
  2. 検出と対応: これらの機能は、悪意のあるアクティビティを特定して対処するアクティブ ディフェンスの中核を構成します。これらの関数は、インテリジェンス関数によって収集されたインテリジェンスに基づいて行動するために必要です。検出機能では、検出を攻撃者の TTP に合わせ、堅牢なロギングを確保する体系的なアプローチが必要です。Respond 機能は、初期トリアージ、データ収集、インシデントの修復に重点を置く必要があります。
  3. 検証: 検証機能は、セキュリティ対策機能のエコシステムが最新の状態であり、設計どおりに動作していることを保証する継続的なプロセスです。この機能により、組織は攻撃対象領域を理解し、脆弱性が存在する場所を把握し、コントロールの有効性を測定できます。セキュリティ検証は、検出エンジニアリング ライフサイクルの重要なコンポーネントでもあり、検出のギャップを特定して新しい検出を作成するために使用する必要があります。
  4. ハンティング: ハンティング機能は、環境内のアクティブな脅威をプロアクティブに検索します。この関数は、組織の検出機能と対応機能の成熟度がベースライン レベルに達している場合に実装する必要があります。ハンティング機能は検出機能を拡張し、コントロールのギャップや弱点を特定するのに役立ちます。Hunt 関数は、特定の脅威に基づく必要があります。この高度な機能は、堅牢なインテリジェンス、検出、対応機能の基盤を活用しています。
  5. 管制センター: 管制センター機能は、他のすべての機能を接続する中央ハブとして機能します。この機能は、サイバー防御プログラム全体の戦略、コミュニケーション、断固とした行動を担当します。すべての機能が連携して動作し、組織のビジネス目標に沿って動作するようにします。他の機能を接続する前に、管制センター機能の目的を明確に理解することに重点を置く必要があります。

サイバー防御のあらゆる側面でインテリジェンス機能を使用する

この推奨事項は、すべての重点分野に関連しています。

この推奨事項では、インテリジェンス機能を強力なサイバー防御プログラムの中核として強調しています。脅威インテリジェンスは、攻撃グループ、その TTP、セキュリティ侵害の証拠、痕跡（IoC）に関する知識を提供します。この知識は、すべてのサイバー防御機能にわたってアクションを通知し、優先順位を付ける必要があります。インテリジェンス主導のアプローチは、組織に最も影響を与えそうな脅威に防御を合わせるのに役立ちます。このアプローチは、リソースの効率的な割り当てと優先順位付けにも役立ちます。

次の Google Cloud プロダクトと機能は、脅威インテリジェンスを活用してセキュリティ運用をガイドするのに役立ちます。これらの機能を使用して、潜在的な脅威、脆弱性、リスクを特定して優先順位を付け、適切なアクションを計画して実施します。

  • Google Security Operations（Google SecOps）を使用すると、セキュリティ データを一元的に保存して分析できます。Google SecOps を使用して、ログを共通のモデルにマッピングし、ログを拡充して、ログをタイムラインにリンクし、攻撃の全体像を把握します。検出ルールの作成、IoC の照合、脅威探査アクティビティの実行も可能です。このプラットフォームには、脅威の特定に役立つ事前定義されたマネージド ルールである、キュレートされた検出機能も用意されています。Google SecOps は Mandiant の最前線のインテリジェンスとも統合できます。Google SecOps は、業界をリードする AI と、Mandiant の脅威インテリジェンスおよび Google VirusTotal を独自に統合しています。この統合は、脅威の評価と、組織を標的とするユーザーとその潜在的な影響を把握するうえで重要です。

  • Security Command Center Enterprise は Google AI を活用しており、セキュリティ担当者は複数のクラウド環境にまたがるセキュリティの問題を効率的に評価、調査、対応できます。Security Command Center を活用できるセキュリティ専門家には、セキュリティ オペレーション センター（SOC）アナリスト、脆弱性と体制のアナリスト、コンプライアンス マネージャーなどが含まれます。Security Command Center Enterprise は、セキュリティ データを拡充し、リスクを評価して、脆弱性の優先順位を付けます。このソリューションは、リスクの高い脆弱性に対処し、アクティブな脅威を修復するために必要な情報をチームに提供します。

  • Chrome Enterprise Premium は、脅威対策とデータ保護を提供します。これにより、情報漏洩のリスクからユーザーを保護し、マルウェアが企業の管理対象デバイスに侵入するのを防ぐことができます。Chrome Enterprise Premium では、ブラウザ内で発生する可能性のある安全でないアクティビティや潜在的に安全でないアクティビティを可視化することもできます。

  • Network Intelligence Center などのツールによるネットワーク モニタリングにより、ネットワーク パフォーマンスを可視化できます。ネットワーク モニタリングは、異常なトラフィック パターンを検出したり、攻撃やデータ不正搬出の試みを示す可能性のあるデータ転送量を検出したりするのにも役立ちます。

防御側の優位性を理解して活用する

この推奨事項は、すべての重点分野に関連しています。

前述のように、ビジネス、システム、トポロジ、インフラストラクチャを十分に理解していれば、攻撃者よりも有利になります。この知識の優位性を活かすには、サイバー防御の計画時に環境に関するこのデータを活用します。

Google Cloud には、脅威を特定し、リスクを把握し、潜在的な損害を軽減するためにタイムリーに対応できるように、可視性をプロアクティブに高めるための次の機能が用意されています。

  • Chrome Enterprise Premium は、情報漏洩のリスクからユーザーを保護することで、エンタープライズ デバイスのセキュリティを強化します。Sensitive Data Protection サービスをブラウザに拡張し、マルウェアを防止します。また、マルウェアやフィッシング対策などの機能も提供しており、安全でないコンテンツへのアクセスを防ぐことができます。また、拡張機能のインストールを制御して、安全でない拡張機能や審査されていない拡張機能を防ぐこともできます。これらの機能により、運用の安全な基盤を確立できます。

  • Security Command Center Enterprise には、包括的で継続的なリスク分析と管理を提供する継続的なリスクエンジンが用意されています。リスクエンジン機能は、セキュリティ データを拡充し、リスクを評価して、脆弱性の優先順位付けを行い、問題を迅速に解決できるようにします。Security Command Center を使用すると、組織は脆弱性を事前に特定し、軽減策を実装できます。

  • Google SecOps はセキュリティ データを一元化し、タイムラインを含む拡充されたログを提供します。これにより、防御側はアクティブな侵害を事前に特定し、攻撃者の行動に基づいて防御を適応させることができます。

  • ネットワーク モニタリングは、攻撃を示す可能性のある異常なネットワーク アクティビティを特定し、対策を講じるために使用できる早期の指標を提供します。データを盗難からプロアクティブに保護するには、データ引き出しを継続的にモニタリングし、提供されているツールを使用します。

防御を継続的に検証して改善する

この推奨事項は、すべての重点分野に関連しています。

この推奨事項は、攻撃対象領域全体の強みと弱みを理解するために、ターゲットを絞ったテストと継続的なコントロールの検証の重要性を強調しています。これには、次のような方法で、制御、オペレーション、スタッフの有効性を検証することが含まれます。

また、脅威を積極的に検索し、その結果を使用して検出と可視性を向上させる必要があります。次のツールを使用して、実際の脅威に対する防御を継続的にテストして検証します。

  • Security Command Center Enterprise には、脆弱性を評価して修復の優先順位を付ける継続的なリスク エンジンが用意されています。これにより、セキュリティ対策の全体的な状況を継続的に評価できます。Security Command Center Enterprise では、問題の優先順位付けを行うことで、リソースを効果的に使用できます。

  • Google SecOps には、脅威ハンティングとキュレートされた検出機能が用意されています。これにより、コントロールの弱点をプロアクティブに特定できます。この機能により、脅威を検知する能力を継続的にテストして改善できます。

  • Chrome Enterprise Premium は、新たな脅威や進化する脅威に対処し、データ漏洩のリスクやマルウェアに対する防御を継続的に更新するのに役立つ脅威対策とデータ保護の機能を提供します。

  • Cloud Next Generation Firewall（Cloud NGFW）は、ネットワーク モニタリングとデータ漏洩モニタリングを提供します。これらの機能は、現在のセキュリティ対策の有効性を検証し、潜在的な弱点を特定するのに役立ちます。データ漏洩のモニタリングは、組織のデータ保護メカニズムの有効性を検証し、必要に応じて事前に対策を講じるのに役立ちます。Cloud NGFW の脅威検出結果を Security Command Center と Google SecOps に統合すると、ネットワーク ベースの脅威検出を最適化し、脅威対応を最適化して、プレイブックを自動化できます。この統合の詳細については、クラウド防御の統合: Security Command Center と Cloud NGFW Enterprise をご覧ください。

サイバー防御の取り組みを管理、調整する

この推奨事項は、すべての重点分野に関連しています。

サイバー防御の機能を統合するで説明したように、管制センター機能はサイバー防御プログラムの他の機能を相互接続します。この機能により、プログラム全体の調整と統合的な管理が可能になります。また、サイバーセキュリティに取り組んでいない他のチームとの連携にも役立ちます。管制センター機能は、権限委譲と説明責任を促進し、アジリティと専門知識を促進し、責任と透明性を推進します。

次のプロダクトと機能は、ミッション コントロール機能の実装に役立ちます。

  • Security Command Center Enterprise は、サイバー防御オペレーションを調整、管理するための中央ハブとして機能します。ツール、チーム、データを統合し、Google SecOps のレスポンス機能を組み込んでいます。Security Command Center は、組織のセキュリティ状態を明確に可視化し、さまざまなリソースにわたるセキュリティの構成ミスを特定できるようにします。
  • Google SecOps は、ログをマッピングしてタイムラインを作成することで、チームが脅威に対応するためのプラットフォームを提供します。検出ルールを定義して脅威を検索することもできます。
  • Google Workspace と Chrome Enterprise Premium を使用すると、機密性の高いリソースに対するエンドユーザーのアクセスを管理および制御できます。ユーザー ID とリクエストのコンテキストに基づいて、きめ細かいアクセス制御を定義できます。
  • ネットワーク モニタリングは、ネットワーク リソースのパフォーマンスに関する分析情報を提供します。ネットワーク モニタリングの分析情報を Security Command Center と Google SecOps にインポートして、一元的なモニタリングと、他のタイムライン ベースのデータポイントとの相関関係を把握できます。この統合により、悪意のあるアクティビティによって発生する可能性のあるネットワーク使用量の変化を検出し、対応することができます。
  • データ引き出しのモニタリングは、データ損失の可能性のあるインシデントを特定するのに役立ちます。この機能を使用すると、インシデント対応チームを効率的に動員し、損害を評価して、さらなるデータ漏洩を制限できます。また、現在のポリシーと制御を改善して、データ保護を確保することもできます。

プロダクトの概要:

次の表に、このドキュメントで説明するプロダクトと機能を示し、関連する推奨事項とセキュリティ機能にマッピングします。

Google Cloud プロダクト 適用可能な最適化案
Google SecOps サイバー防御のあらゆる側面でインテリジェンス機能を使用する: 脅威ハンティングと IoC マッチングを有効にし、Mandiant と統合して包括的な脅威評価を行います。

防御側の優位性を理解して活用する: 厳選された検出を提供し、セキュリティ データを一元化して、プロアクティブな侵害の特定を実現します。

防御を継続的に検証して改善する: 脅威検出機能の継続的なテストと改善を可能にします。

Mission Control を通じてサイバー防御の取り組みを管理、調整する: 脅威への対応、ログ分析、タイムライン作成のためのプラットフォームを提供します。
Security Command Center Enterprise サイバー防御のあらゆる側面でインテリジェンス機能を使用する: AI を使用してリスクを評価し、脆弱性の優先順位を付け、修復のための実用的な分析情報を提供します。

防御側の優位性を理解して活用する: 包括的なリスク分析、脆弱性の優先順位付け、弱点のプロアクティブな特定を提供します。

防御を継続的に検証して改善する: セキュリティ体制の継続的な評価とリソースの優先順位付けを行います。

管制センターを通じてサイバー防御の取り組みを管理、調整する: サイバー防御オペレーションを管理、調整するための中央ハブとして機能します。
Chrome Enterprise Premium サイバー防御のあらゆる側面でインテリジェンス機能を使用する: 情報漏洩のリスクからユーザーを保護し、マルウェアを防止し、安全でないブラウザ アクティビティを可視化します。

防御側の利点を理解して活用する: データ保護、マルウェア防止、拡張機能の制御により、企業デバイスのセキュリティを強化します。

防御を継続的に検証して改善する: データ漏洩のリスクやマルウェアに対する防御を継続的に更新することで、新しい脅威や進化する脅威に対処します。

ミッション コントロールを通じてサイバー防御の取り組みを管理、調整する: きめ細かいアクセス制御など、機密性の高いリソースに対するエンドユーザーのアクセスを管理、制御します。
Google Workspace ミッション コントロールを通じてサイバー防御の取り組みを管理、調整する: きめ細かいアクセス制御など、機密性の高いリソースに対するエンドユーザーのアクセスを管理、制御します。
Network Intelligence Center サイバー防御のあらゆる側面でインテリジェンス機能を使用する: ネットワーク パフォーマンスの可視性を高め、異常なトラフィック パターンやデータ転送を検出します。
Cloud NGFW 防御を継続的に検証して改善する: Security Command Center と Google SecOps との統合により、ネットワーク ベースの脅威の検出と対応を最適化します。

AI を安全かつ責任を持って使用する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、AI システムを保護するうえで役に立つ推奨事項が示されています。これらの推奨事項は、AI システムのセキュリティとリスクに関する懸念に対処するための実用的なアプローチを提供する Google のセキュア AI フレームワーク（SAIF）に沿っています。SAIF は、AI を責任を持って構築、デプロイするための業界全体の標準を提供することを目的とした概念的枠組みです。

原則の概要

AI システムがセキュリティ、プライバシー、コンプライアンスの要件を満たすようにするには、初期設計からデプロイと運用までを網羅する包括的な戦略を採用する必要があります。この包括的な戦略は、SAIF の 6 つの中核要素を適用することで実装できます。

Google は、脅威の特定、セキュリティ タスクの自動化、検出機能の改善など、セキュリティ対策を強化するために AI を使用しています。ただし、重要な決定については人間が関与します。

Google は、AI セキュリティの強化に向けて共同で取り組むアプローチを重視しています。このアプローチでは、お客様、業界、政府と連携して SAIF ガイドラインを強化し、実用的で実行可能なリソースを提供します。

この原則を実装するための推奨事項は、次のセクションにグループ化されています。

AI を安全に使用するための推奨事項

AI を安全に使用するには、基本的なセキュリティ管理と AI 固有のセキュリティ管理の両方が必要です。このセクションでは、AI と ML のデプロイが組織のセキュリティ、プライバシー、コンプライアンスの要件を満たすようにするための推奨事項の概要について説明します。 Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要については、Well-Architected Framework の AI と ML の視点をご覧ください。

AI の使用に関する明確な目標と要件を定義する

この推奨事項は、次の重点分野に関連しています。

  • クラウドのガバナンス、リスク、コンプライアンス
  • AI と ML のセキュリティ

この推奨事項は、周囲のビジネス プロセスにおける AI システムのリスクをコンテキスト化するという SAIF の要素に沿ったものです。AI システムを設計して進化させる場合は、特定のビジネス目標、リスク、コンプライアンス要件を理解することが重要です。

データを安全に保ち、損失や不正使用を防止する

この推奨事項は、次の重点分野に関連しています。

  • インフラストラクチャのセキュリティ
  • ID とアクセスの管理
  • データ セキュリティ
  • アプリケーションのセキュリティ
  • AI と ML のセキュリティ

この推奨事項は、次の SAIF 要素に沿ったものです。

  • 強固なセキュリティ基盤を AI エコシステムまで拡大します。この要素には、データ収集、ストレージ、アクセス制御、データ ポイズニングに対する保護が含まれます。
  • AI システムのリスクをコンテキスト化します。ビジネス目標とコンプライアンスをサポートするために、データ セキュリティを重視します。

AI パイプラインの安全性を確保し、改ざんに対して堅牢性を維持する

この推奨事項は、次の重点分野に関連しています。

  • インフラストラクチャのセキュリティ
  • ID とアクセスの管理
  • データ セキュリティ
  • アプリケーションのセキュリティ
  • AI と ML のセキュリティ

この推奨事項は、次の SAIF 要素に沿ったものです。

  • 強固なセキュリティ基盤を AI エコシステムまで拡大します。安全な AI システムを確立するうえで重要な要素として、コードとモデル アーティファクトを保護します。
  • 高速なフィードバック ループを実現するために、コントロールを適応させます。軽減とインシデント対応に不可欠であるため、アセットとパイプラインの実行を追跡します。

安全なツールとアーティファクトを使用して安全なシステムにアプリをデプロイする

この推奨事項は、次の重点分野に関連しています。

  • インフラストラクチャのセキュリティ
  • ID とアクセスの管理
  • データ セキュリティ
  • アプリケーションのセキュリティ
  • AI と ML のセキュリティ

AI ベースのアプリケーションで安全なシステムと検証済みのツールやアーティファクトを使用することは、強力なセキュリティ基盤を AI エコシステムとサプライ チェーンに拡大するという SAIF の要素に沿ったものです。この推奨事項は、次の手順で対応できます。

入力を保護してモニタリングする

この推奨事項は、次の重点分野に関連しています。

  • ロギング、監査、モニタリング
  • セキュリティ運用
  • AI と ML のセキュリティ

この推奨事項は、検出機能と対応機能を拡張して組織の脅威対策に AI を取り込むという SAIF の要素に沿ったものです。問題を回避するには、生成 AI システムのプロンプトを管理し、入力をモニタリングし、ユーザー アクセスを制御することが重要です。

AI ガバナンスに関する推奨事項

このセクションのすべての推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

Google Cloud は、責任ある倫理的な AI システムの構築に使用できる強力なツールとサービスのセットを提供します。また、AI システムの開発、デプロイ、使用を導くことができるポリシー、手順、倫理的考慮事項のフレームワークも提供しています。

Google の AI ガバナンスに対するアプローチは、以下の原則に沿って行われています。

  • 公平さ
  • 透明性
  • アカウンタビリティ
  • プライバシー
  • セキュリティ

公平性インジケーターを使用する

Vertex AI は、データ収集またはトレーニング後の評価プロセス中にバイアスを検出できます。Vertex AI には、モデルのバイアスの評価に役立つ、データバイアスやモデルバイアスなどのモデル評価指標が用意されています。

これらの指標は、人種、性別、階級などのさまざまなカテゴリ間の公平性に関連しています。ただし、カテゴリ間の差異がバイアスや有害性のシグナルによるものではない可能性があるため、統計的偏差の解釈は簡単ではありません。

Vertex Explainable AI を使用する

AI モデルがどのように意思決定を行うかを理解するには、Vertex Explainable AI を使用します。この機能は、モデルのロジックに隠れている可能性のあるバイアスを特定するのに役立ちます。

この説明可能性機能は、特徴ベースの説明を提供する BigQuery ML と Vertex AI に統合されています。説明可能性は、BigQuery ML で利用することも、Vertex AI にモデルを登録して Vertex AI で利用することもできます。

データリネージを追跡する

AI システムで使用されるデータの発生元と変換を追跡します。このトラッキングは、データの流れを把握し、バイアスやエラーの潜在的な原因を特定するのに役立ちます。

データリネージは、Dataplex Universal Catalog の機能で、システム内でのデータの移動（データの送信元、データの送信先、データに適用される変換）を追跡できます。

アカウンタビリティを確立する

AI システムの開発、デプロイ、結果に関する責任範囲を明確にします。

Cloud Logging を使用して、AI システムによって行われた重要なイベントと決定をログに記録します。ログは、システムのパフォーマンスを把握し、改善が必要な領域を特定するのに役立つ監査証跡を提供します。

Error Reporting を使用して、AI システムによって発生したエラーを体系的に分析します。この分析により、基盤となるバイアスや、モデルのさらなる改善が必要な領域を示すパターンを明らかにできます。

差分プライバシーを実装する

モデルのトレーニング中に、個々のデータポイントを特定しにくくしながらも、モデルが効果的に学習できるように、データにノイズを追加します。BigQuery の SQL を使用すると、クエリの結果を差分プライベートの集計で変換できます。

セキュリティに AI を使用する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、AI を使用してクラウド ワークロードのセキュリティを強化するうえで役に立つ推奨事項が示されています。

サイバー攻撃の数と高度化が進んでいるため、セキュリティの強化に役立つ AI の可能性を活用することが重要です。AI は、脅威の数を減らし、セキュリティ専門家が手動で行う際に必要となる労力を軽減し、サイバーセキュリティ分野の専門家の不足を補うのに役立ちます。

原則の概要

AI 機能を使用して、既存のセキュリティ システムとプロセスを改善します。Gemini in Security と、 Google Cloud サービスに組み込まれている固有の AI 機能を使用できます。

これらの AI 機能は、セキュリティ ライフサイクルのあらゆる段階で支援を提供することで、セキュリティを変革できます。たとえば、AI を使用して次のことができます。

  • リバース エンジニアリングを行わずに、潜在的に悪意のあるコードを分析して説明します。
  • サイバーセキュリティ担当者の繰り返し作業を減らします。
  • 自然言語を使用してクエリを生成し、セキュリティ イベントデータを操作します。
  • コンテキスト情報を表示します。
  • クイック返信の候補を表示します。
  • イベントの修復を支援します。
  • 構成ミスや脆弱性に関する優先度の高いアラートを要約し、潜在的な影響をハイライトして、緩和策を推奨します。

セキュリティ自律性のレベル

AI と自動化は、絶えず進化するサイバーセキュリティの脅威に対処する際に、セキュリティの成果を向上させるのに役立ちます。セキュリティに AI を使用することで、より高いレベルの自律性を実現し、脅威を検出して防止し、全体的なセキュリティ ポスチャーを改善できます。Google は、セキュリティに AI を使用する際の 4 つの自律性レベルを定義しています。これらのレベルは、セキュリティ タスクの支援から最終的な主導まで、AI の役割が拡大していくことを示しています。

  1. 手動: セキュリティ ライフサイクル全体にわたって、すべてのセキュリティ タスク（防止、検出、優先順位付け、対応）を人間が実行します。
  2. 支援型: Gemini などの AI ツールは、情報の要約、分析情報の生成、推奨事項の提示により、人間の生産性を高めます。
  3. 半自律型: 多くのセキュリティ タスクにおいて AI が主な責任を負い、必要な場合にのみ人間に委任します。
  4. 自律型: AI は、組織の目標と設定に基づいてセキュリティ ライフサイクルを推進する信頼できるアシスタントとして機能し、人間の介入を最小限に抑えます。

推奨事項

以降のセクションでは、セキュリティに AI を使用するための推奨事項について説明します。また、これらのセクションでは、推奨事項が Google のセキュア AI フレームワーク（SAIF）のコア要素とどのように一致するか、また、セキュリティ自律性のレベルとどのように関連しているかについても説明します。

AI を活用して脅威の検出と対応を強化する

この推奨事項は、次の重点分野に関連しています。

  • セキュリティ運用（SecOps）
  • ロギング、監査、モニタリング

AI は、大量のセキュリティ データを分析し、脅威アクターの行動に関する分析情報を提供し、悪意のあるコードの可能性のある分析を自動化できます。この推奨事項は、次の SAIF 要素に沿ったものです。

  • 検出機能と対応機能を拡張し、組織の脅威対策に AI を取り込みます。
  • 防御を自動化し、既存および新規の脅威に対応します。

実装によっては、この推奨事項は次のレベルの自律性に関連する可能性があります。

  • 支援: AI が脅威の分析と検出を支援します。
  • 半自律型: AI がセキュリティ タスクのより多くの責任を負います。

Google Threat Intelligence は、AI を使用して脅威アクターの行動と悪意のあるコードを分析し、この推奨事項の実装を支援します。

エキスパートと非エキスパートの両方のセキュリティを簡素化する

この推奨事項は、次の重点分野に関連しています。

  • セキュリティ運用（SecOps）
  • クラウドのガバナンス、リスク、コンプライアンス

AI を搭載したツールは、アラートを要約して緩和策を推奨できます。これらの機能により、より多くの担当者がセキュリティにアクセスできるようになります。この推奨事項は、次の SAIF 要素に沿ったものです。

  • 防御を自動化し、既存および新規の脅威に対応します。
  • プラットフォーム レベルの管理を調整し、組織全体で一貫したセキュリティを確保します。

実装によっては、この推奨事項は次のレベルの自律性に関連する可能性があります。

  • アシスト: AI がセキュリティ情報のアクセシビリティの向上を支援します。
  • 半自律型: AI がすべてのユーザーのセキュリティ対策をより効果的にします。

Gemini in Security Command Center は、構成ミスや脆弱性に関するアラートの概要を提供できます。

AI を使用して時間のかかるセキュリティ タスクを自動化する

この推奨事項は、次の重点分野に関連しています。

  • インフラストラクチャのセキュリティ
  • セキュリティ運用（SecOps）
  • アプリケーションのセキュリティ

AI は、マルウェアの分析、セキュリティ ルールの生成、構成ミスの特定などのタスクを自動化できます。これらの機能により、セキュリティ チームのワークロードを軽減し、応答時間を短縮できます。この推奨事項は、既存および新規の脅威に対応するために防御を自動化するという SAIF 要素に沿ったものです。

実装によっては、この推奨事項は次のレベルの自律性に関連する可能性があります。

  • アシスト: AI がタスクの自動化を支援します。
  • 半自律型: AI がセキュリティ タスクの主な責任を負い、必要な場合にのみ人間の支援を求めます。

Gemini in Google SecOps は、アナリストの支援、関連するコンテキストの取得、次のステップの推奨を行うことで、高負荷のタスクを自動化できます。

リスク管理とガバナンスのプロセスに AI を組み込む

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

AI を使用して、モデル インベントリとリスク プロファイルを構築できます。AI を使用して、データ プライバシー、サイバー リスク、サードパーティ リスクに関するポリシーを実装することもできます。この推奨事項は、周囲のビジネス プロセスにおける AI システムのリスクをコンテキスト化する SAIF 要素に沿ったものです。

実装によっては、この推奨事項は半自律レベルの自律性に関連する可能性があります。このレベルでは、AI はプロセスを実行してカスタム セキュリティ目標を達成するセキュリティ エージェントをオーケストレートできます。

AI システムに安全な開発手法を実装する

この推奨事項は、次の重点分野に関連しています。

  • アプリケーションのセキュリティ
  • AI と ML のセキュリティ

AI を使用して、安全なコーディング、トレーニング データのクリーニング、ツールとアーティファクトの検証を行うことができます。この推奨事項は、強固なセキュリティ基盤を AI エコシステムまで拡大するという SAIF の要素に沿ったものです。

この推奨事項は、すべてのレベルのセキュリティ自律性に関連する可能性があります。これは、セキュリティに AI を効果的に使用する前に、安全な AI システムを導入する必要があるためです。この推奨事項は、セキュリティ プラクティスが AI によって強化されるアシスト レベルに最も関連しています。

この推奨事項を実装するには、AI アーティファクトのソフトウェア アーティファクトのためのサプライチェーン レベル（SLSA）ガイドラインに沿って、検証済みのコンテナ イメージを使用します。

規制、コンプライアンス、プライバシーのニーズに対応する

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則は、クラウド デプロイの規制、コンプライアンス、プライバシーの要件を特定して満たすうえで役立ちます。これらの要件は、Google Cloudのワークロードに使用する必要があるセキュリティ制御について行う必要のある意思決定に影響します。

原則の概要

規制、コンプライアンス、プライバシーのニーズを満たすことは、すべての企業にとって避けられない課題です。クラウドの規制要件は、次のような複数の要因によって異なります。

  • 組織の物理的な場所に適用される法律および規制
  • ユーザーのお客様の物理的な場所に適用される法律と規制
  • 業界の規制要件

プライバシー規制を使うと、ユーザーデータの取得、処理、保存、管理の方法をそれぞれ定義できます。ユーザーから受け取ったデータを含め、データはお客様に帰属します。そのため、Cookie の管理、セッション管理、ユーザー権限の取得など、プライバシー管理の多くはお客様の責任となります。

この原則を実装するための推奨事項は、次のセクションにグループ化されています。

組織のリスクに対処するための推奨事項

このセクションでは、組織のリスクを特定して対処するのに役立つ推奨事項について説明します。

組織におけるリスクを特定する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

Google Cloudでリソースを作成してデプロイする前に、リスク評価を実施します。この評価では、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を特定する必要があります。

リスク評価は、組織固有のリスクのカタログを提供し、組織がセキュリティ上の脅威の検出と対処にどのように役立つかを示します。リスク分析は、デプロイ直後と、ビジネスニーズ、規制要件、組織に対する脅威に変更があった場合は必ず実施する必要があります。

設計によるセキュリティの実装の原則で説明したように、クラウド環境におけるセキュリティ リスクはオンプレミス リスクとは異なります。この違いは、クラウドの責任共有モデルによるものです。このモデルは、サービス（IaaS、PaaS、SaaS）と使用状況によって異なります。Cloud Controls Matrix（CCM）などのクラウド固有のリスク評価フレームワークを使用します。OWASP アプリケーション脅威モデリングなどの脅威モデリングを使用して、脆弱性を特定して対処します。リスク評価に関する専門的なサポートについては、Google アカウント担当者にお問い合わせいただくか、 Google Cloudのパートナー ディレクトリをご覧ください。

リスクをカタログ化したら、どのようにリスクに対処するか（リスクを受け入れる、回避する、移転する、軽減する）を決定する必要があります。実装できる緩和策については、次のセクションでリスクの軽減について説明します。

リスクを軽減する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

新しいパブリック クラウド サービスを導入する際のリスクを軽減するには、技術的なコントロール、契約による保護、サードパーティの検証または証明を使用します。

技術的なコントロール。環境の保護に使用する機能とテクノロジーのことです。これには、ファイアウォールやロギングなどのクラウド セキュリティ コントロールが組み込まれています。技術的なコントロールには、セキュリティ戦略を強化またはサポートするサードパーティ ツールの使用も含まれます。技術的なコントロールには次の 2 つのカテゴリがあります。

  • Google Cloudのセキュリティ管理を実装して、環境に適用されるリスクを軽減できます。たとえば、Cloud VPN と Cloud Interconnect を使用して、オンプレミス ネットワークとクラウド ネットワーク間の接続を保護できます。
  • Google では、堅牢な内部管理と監査を実施して、インサイダーによるアクセスからお客様のデータを保護しています。Google の監査ログにより、 Google Cloudでは、Google 管理者アクセスのログがニア リアルタイムで提供されます。

契約による保護とは、Google Cloud サービスに関して Google が行う法律上のコミットメントのことです。Google は、コンプライアンス ポートフォリオの維持と拡大に取り組んでいます。お客様のデータの処理とセキュリティに関する Google の取り組みについては、Cloud のデータ処理に関する追加条項（CDPA）をご覧ください。CDPA には、Google サポート エンジニアによるお客様の環境へのアクセスを制限するアクセス制御の概要と、厳格なロギングと承認プロセスについても説明しています。 Google Cloudの契約管理について、法的および規制の専門家に相談して、要件を満たしていることを確認することをおすすめします。詳しくは、テクニカル アカウント担当者にお問い合わせください。

第三者による検証または証明。クラウド プロバイダがコンプライアンス要件を満たしていることをサードパーティ ベンダーに監査してもらうことです。たとえば、ISO/IEC 27017 ガイドラインに関する Google Cloud 証明書については、ISO/IEC 27017 - コンプライアンスをご覧ください。現在の Google Cloud の認定資格と証明書については、コンプライアンス リソース センターをご覧ください。

規制要件とコンプライアンス要件に対応するための推奨事項

一般的なコンプライアンスの取り組みには、評価、ギャップの修復、継続的なモニタリングの 3 つのステージがあります。このセクションでは、これらの各ステージで使用できる推奨事項について説明します。

コンプライアンスのニーズを評価する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

コンプライアンス評価は、すべての規制義務と、それが企業でどのように実装されているかを徹底的に確認することから始まります。 Google Cloud サービスの評価に役立つよう、コンプライアンス リソース センターを使用します。このサイトでは、次の情報を提供します。

  • さまざまな規制に対応するサービス サポート
  • Google Cloud 認定資格と証明書

Google のコンプライアンス ライフサイクルと要件の遵守について理解を深めるには、営業担当者にお問い合わせのうえ、Google コンプライアンス スペシャリストのサポートをご依頼ください。または、Google Cloud アカウント マネージャーに連絡して、コンプライアンス ワークショップをリクエストすることもできます。

Google Cloud ワークロードのセキュリティとコンプライアンスの管理に使用できるツールとリソースの詳細については、クラウドでのコンプライアンスの確保をご覧ください。

コンプライアンス要件の実装を自動化する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

変化し続ける規制を遵守し続けるために、コンプライアンス要件の実装方法を自動化できるかどうかを判断します。 Google Cloud が提供するコンプライアンス重視の機能と、特定のコンプライアンス体制の推奨構成を使用するブループリントの両方を使用できます。

Assured Workloads は、 Google Cloud 内の制御に基づいて構築され、コンプライアンス義務の遵守を支援します。Assured Workloads では次のことができます。

  • コンプライアンス レジームを選択する。このツールは、選択した体制のベースライン担当者のアクセス制御を自動的に設定します。
  • 組織のポリシーを使用してデータのロケーションを設定し、保存データとリソースがそのリージョンにのみ保持されるようにする。
  • セキュリティとコンプライアンスの要件に最適な鍵管理オプション（鍵のローテーション期間など）を選択する。
  • FedRAMP Moderate などの特定の規制要件を満たすために、Google サポート担当者のアクセス基準を選択します。たとえば、Google サポート担当者が適切なバックグラウンド チェックを完了しているかどうかを選択できます。
  • FIPS-140-2 に準拠し、FedRAMP Moderate への準拠をサポートする Google-owned and Google-managed encryption keys を使用します。制御レイヤの追加と職掌分散のため、顧客管理の暗号鍵（CMEK）を使用します。鍵の詳細については、保存データと転送データを暗号化するをご覧ください。

Assured Workloads に加えて、コンプライアンス レジームに関連する Google Cloudブループリントを使用することもできます。これらのブループリントを変更して、セキュリティ ポリシーをインフラストラクチャのデプロイに組み込むことができます。

コンプライアンス要件をサポートする環境の構築を支援するため、Google のブループリントとソリューション ガイドには、推奨構成が含まれており、Terraform モジュールが提供されています。次の表に、セキュリティとコンプライアンス要件への対応を説明するブループリントを示します。

要件 ブループリントとソリューション ガイド
FedRAMP
HIPAA

コンプライアンスをモニタリングする

この推奨事項は、次の重点分野に関連しています。

  • クラウドのガバナンス、リスク、コンプライアンス
  • ロギング、モニタリング、監査

ほとんどの規制では、アクセス関連のアクティビティを含む特定のアクティビティをモニタリングする必要があります。モニタリングのために、次の項目を使用できます。

  • アクセスの透明性: Google Cloud 管理者がコンテンツにアクセスしたときに、ほぼリアルタイムのログを表示します。
  • ファイアウォール ルールロギング: 作成したルールに従って VPC ネットワーク内の TCP 接続と UDP 接続を記録します。これらのログは、ネットワーク アクセスを監査する場合や、ネットワークが承認されていない方法で使用されていることを早期に警告する場合に活用できます。
  • VPC Flow Logs: VM インスタンスによって送受信されたネットワーク トラフィック フローを記録します。
  • Security Command Center Premium: さまざまな標準への準拠をモニタリングします。
  • OSSEC（または別のオープンソース ツール）: 環境に対する管理者権限がある個人のアクティビティをログに記録します。
  • Key Access Justifications: 鍵アクセス リクエストの理由を表示します。
  • Security Command Center 通知: コンプライアンス違反の問題が発生した場合にアラートを受け取ります。たとえば、ユーザーが 2 段階認証プロセスを無効にした場合や、サービス アカウントに過剰な権限が付与されている場合にアラートを受け取ります。特定の通知に対する自動修復を設定することもできます。

データ主権を管理するための推奨事項

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

データ主権は、Google がユーザーのデータにアクセスできないようにするメカニズムを提供します。アクセスを承認するのは、ユーザーによる同意が必要なプロバイダの動作に限られます。たとえば、次の方法でデータ主権を管理できます。

運用主権を管理する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

運用主権は、Google の従業員がユーザーのワークロードを侵害できないことを保証します。たとえば、次の方法で運用主権を管理できます。

ソフトウェア主権を管理する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

ソフトウェア主権は、ワークロードの可用性を制御し、任意の場所で実行できることを保証します。また、単一のクラウド プロバイダに依存したり、ロックインされたりすることなく、この制御を行うことができます。ソフトウェア主権には、ワークロードのデプロイ先や外部接続の許可レベルを即座に変更する必要が生じるイベントに対処できることが含まれています。

たとえば、ソフトウェアの主権を管理するために、 Google Cloudはハイブリッド デプロイとマルチクラウド デプロイをサポートしています。また、GKE Enterprise では、クラウド環境とオンプレミス環境の両方でアプリケーションを管理およびデプロイできます。データ主権の理由でオンプレミス デプロイを選択する場合は、Google Distributed Cloud が適しています。これは、 Google Cloud をデータセンターに導入するハードウェアとソフトウェアの組み合わせです。

プライバシー要件に対応するための推奨事項

Google Cloud には、次に挙げるようなプライバシーを改善する管理の仕組みが含まれています。

  • デフォルトでの全データの暗号化（保存時、転送中、処理中）。
  • インサイダー アクセスに対する保護対策。
  • 多数のプライバシー規制への対応。

次の推奨事項では、実装できる追加の制御について説明します。詳しくは、プライバシー リソース センターをご覧ください。

データ所在地を制御する

この推奨事項は、クラウドのガバナンス、リスク、コンプライアンスという重点分野に関連しています。

データ所在地は、データが保存される場所を表します。データ所在地の要件は、システム設計の目標、業界の規制に関する懸念、国内法、税務上の影響、さらには文化によって異なります。

データ所在地の制御を開始する手順は次のとおりです。

  • データのタイプと場所を把握します。
  • データに存在するリスクと適用される法規制を把握します。
  • データの保存場所や保存先を管理する。

データ所在地の要件を遵守するため、 Google Cloud ではデータの保存場所、アクセス方法、処理方法を制御できます。リソース ロケーション ポリシーを使用して、リソースを作成する場所と、リージョン間でデータをレプリケートする場所を制限できます。リソースのロケーション プロパティを使用して、サービスのデプロイ先とメンテナンスを行うユーザーを特定できます。詳細については、リソース ロケーションのサポート対象サービスをご覧ください。

機密データを分類する

この推奨事項は、重点分野（データ セキュリティ）に関連しています。

どのデータが機密であるかを定義し、その機密データを適切に保護する必要があります。機密データには、クレジット カード番号、住所、電話番号、その他の個人情報（PII）などが含まれる場合があります。Sensitive Data Protectionを使用すると、適切な分類を設定できます。そうすると、 Google Cloudにデータを保存する前に、タグ付けおよびトークン化ができるようになります。また、Dataplex Universal Catalog には、メタデータを保存、管理、アクセスするためのプラットフォームを提供するカタログ サービスがあります。データ分類と匿名化の詳細と例については、Sensitive Data Protection を使用した PII の匿名化と再識別をご覧ください。

機密データへのアクセスを禁止する

この推奨事項は、次の重点分野に関連しています。

  • データ セキュリティ
  • ID とアクセスの管理

VPC Service Controls を使用して、機密データを独自のサービス境界に配置します。VPC Service Controls を使用すると、Google マネージド サービスから不正なデータ転送やコピー（データの引き出し）が行われるリスクを軽減できます。VPC Service Controls を使用すると、Google マネージド サービスのリソースにセキュリティ境界を構成し、境界をまたがるデータの移動を制御できます。データの Google Identity and Access Management（IAM）アクセス制御を設定します。センシティブ データへのアクセスを必要とするすべてのユーザーに対して、多要素認証（MFA）を構成します。

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

このドキュメントでは、 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、Google Security Operations、Google Cloud Marketplace で入手できるサードパーティの SaaS アプリケーションが含まれます。

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

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

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

FaaS には、SaaS と同様の責任共有リストがあります。Cloud Run 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 には、クラウド セキュリティ ポスチャーをより深く理解するために使用できるデータドリブンな分析情報を提供する サイバー保険ハブが含まれています。サイバー保険の保障内容を知りたい場合は、Cyber Insurance Hub から得たこれらの分析情報を保険パートナーと直接共有して見積もりを取ることができます。詳細については、Google Cloud Risk Protection Program のプレビュー版をご覧ください。

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

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

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

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

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

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

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

次のステップ