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 のプロダクトや機能の使用と構成に関するガイダンスがハイライト表示されています。

エージェント スキルを使用してワークロードを評価する

AI エージェントがこの柱の原則と推奨事項に照らしてクラウド ワークロードを評価できるようにするには、GitHub の Google Agent Skills リポジトリにある google-cloud-waf-security スキルを使用します。

スキルをインストールするには、エージェントのクライアントまたはターミナルで次のコマンドを実行します。

npx skills add google/skills --skill google-cloud-waf-security

プロンプトが表示されたら、スキルをインストールする AI エージェントを指定し、インストール スコープ（プロジェクトまたはグローバル）を設定します。

基本原則

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

  • 安全性を重視した設計を実装する: アプリケーションとインフラストラクチャの初期設計フェーズから、クラウド セキュリティとネットワーク セキュリティの考慮事項を組み込みます。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, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
  • Gary Harmson | プリンシパル アーキテクト
  • Gino Pelliccia | プリンシパル アーキテクト
  • Jose Andrade | カスタマー エンジニア兼 SRE スペシャリスト
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Laura Hyatt | カスタマー エンジニア兼 FSI
  • Marwan Al Shawi | パートナー カスタマー エンジニア
  • Nicolas Pintaux | カスタマー エンジニア、アプリケーション モダナイゼーション スペシャリスト
  • Noah McDonald | クラウド セキュリティ コンサルタント
  • Osvaldo Costa | ネットワーキング スペシャリスト カスタマー エンジニア
  • Radhika Kanakam | Google Cloud Well-Architected Framework プログラム リード
  • Samantha He | テクニカル ライター
  • Susan Wu | アウトバウンド プロダクト マネージャー

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

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

原則の概要

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

  • デフォルトで保護: システムのデフォルト設定がセキュアモードに設定されていることを確認し、ユーザーや管理者がシステムを保護するためのアクションを実行する必要性を最小限に抑えます。このアプローチは、すべてのユーザーにベースライン レベルのセキュリティを提供することを目的としています。
  • セキュア バイ デザイン: システムの開発ライフサイクル全体にわたってセキュリティを考慮することを重視します。このアプローチは、潜在的な脅威と脆弱性を早期に予測し、リスクを軽減する設計を選択することです。このアプローチでは、安全なコーディング手法を使用し、セキュリティ レビューを実施して、設計プロセス全体にセキュリティを組み込みます。安全性を重視した設計アプローチは、開発プロセスを導く包括的な理念であり、セキュリティが後回しにされることなく、システム設計に不可欠な要素となるようにします。

推奨事項

クラウド ワークロードにセキュア バイ デザインの原則を実装するには、次のセクションの推奨事項を検討してください。

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

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

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

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

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

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

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

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

  • AI と ML のセキュリティ
  • インフラストラクチャのセキュリティ
  • Identity and Access Management
  • データ セキュリティ

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

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

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

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

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

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

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

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

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

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

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

機密性の高いワークロードの場合は、Shielded VM を使用します。これにより、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 が管理を委託している物理的境界の外へデータが移動するときに、Google は 1 つ以上のネットワーク層で転送中のデータを暗号化して認証します。VPC ネットワーク内およびピアリングされた VPC ネットワーク間のすべての VM 間トラフィックは暗号化されます。MACsec を使用すると、Cloud Interconnect 接続を介したトラフィックを暗号化できます。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 を使用します。たとえば、サービス プロジェクトの管理者は、一元管理された共有 VPC ネットワークをホストするプロジェクトから承認されたサブネットを使用する Compute Engine インスタンスを作成できます。
    • データの引き出しを防ぐには、VPC Service Controls を使用して、機密性の高い Google Cloud API とサービスの周囲に安全な境界を確立し、厳格な下り（外向き）ファイアウォール ルールを使用してインターネットへのトラフィックを制限します。
  • 境界セキュリティ: DDoS 攻撃やウェブ アプリケーションの脅威から保護します。
    • 脅威から保護するには、Google Cloud Armor を使用します。
    • Google Cloud エッジでトラフィックを許可、拒否、またはリダイレクトするようにセキュリティ ポリシーを構成します。
  • 自動化: Infrastructure as Code（IaC）の原則を採用し、Terraform、Jenkins、Cloud Build などのツールを使用して、インフラストラクチャのプロビジョニングを自動化します。IaC は、一貫したセキュリティ構成、デプロイの簡素化、問題発生時の迅速なロールバックを可能にします。
  • 安全な基盤: エンタープライズ基盤のブループリントを使用して、安全なアプリケーション環境を構築します。このブループリントには、セキュリティのベスト プラクティスを実装し、Google Cloud リソースを安全に構成するための規範的なガイダンスと自動化スクリプトが用意されています。

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

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

  • Identity and Access Management
  • セキュリティ運用（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 連携を使用して、リソースに安全にアクセスします。
  • 堅牢なプロセス: クラウド セキュリティのベスト プラクティスに沿って ID プロセスを更新します。
    • 規制要件を確実に遵守するため、ID ガバナンスを実装して、アクセス、リスク、ポリシー違反を追跡します。
    • アクセス制御のロールと権限の付与と監査を行う既存のプロセスを確認して更新します。
  • 強力な認証: ユーザー認証に SSO を実装し、特権アカウントに MFA を実装します。
    • Google Cloud は、Titan セキュリティ キーなど、さまざまな MFA 方式をサポートしており、セキュリティを強化できます。
    • ワークロード認証には、OAuth 2.0 または署名付き JSON ウェブトークン（JWT）を使用します。
  • 最小権限: 最小権限の原則と職務分掌の原則を適用することで、不正アクセスとデータ侵害のリスクを最小限に抑えます。
    • ユーザー アクセスのオーバープロビジョニングを避ける。
    • 機密性の高いオペレーションに対して、ジャストインタイム特権アクセスの実装を検討してください。
  • ロギング: 管理者アクティビティとデータアクセス アクティビティの監査ロギングを有効にします。

ネットワークをモニタリングして維持する

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

  • ロギング、監査、モニタリング
  • アプリケーションのセキュリティ
  • セキュリティ運用（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 された後、セキュリティ バグを早期に、迅速かつ確実に検出して修正します。コードレビュー、デプロイ後の脆弱性スキャン、セキュリティ テストなどの手法を採用します。

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

推奨事項

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

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

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

  • Identity and Access Management
  • クラウドのガバナンス、リスク、コンプライアンス

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

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

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

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

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

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

  • IAM を使用したタグ: 各リソースのアクセス権限を定義するのではなく、リソースのセットにタグを割り当てて、タグ自体のアクセス定義を設定します。
  • IAM 条件: リソースに条件付きの属性ベースのアクセス制御を定義します。
  • 多層防御: 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 フレームワークが推奨するベスト プラクティスの一つです。

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）または 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:2025 の緩和をご覧ください。

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

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

プリエンプティブなサイバー防御を実装する

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

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

原則の概要

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

推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前述のように、自社のビジネス、システム、トポロジ、インフラストラクチャを完全に把握していれば、攻撃者よりも優位に立つことができます。この知識の優位性を活かすには、サイバー防御の計画時に環境に関するデータを利用します。

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

  • Chrome Enterprise Premium は、情報漏洩のリスクからユーザーを保護することで、エンタープライズ デバイスのセキュリティを強化します。Sensitive Data Protection サービスをブラウザに拡張し、マルウェアを防止します。また、マルウェアやフィッシングからの保護などの機能により、安全でないコンテンツにさらされるのを防ぐことができます。また、拡張機能のインストールを管理できるため、安全でない拡張機能や未検証の拡張機能を防止できます。これらの機能は、オペレーションの安全な基盤を確立するのに役立ちます。

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

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

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

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

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

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

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

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

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

  • Chrome Enterprise Premium には、新しく進化する脅威に対処し、引き出しリスクやマルウェアに対する防御を継続的に更新できる脅威対策とデータ保護機能が用意されています。

  • Cloud Next Generation Firewall（Cloud NGFW）は、ネットワーク モニタリングとデータ引き出しのモニタリングを提供します。これらの機能は、現在のセキュリティ ポスチャーの有効性を検証し、潜在的な弱点を特定するのに役立ちます。データ引き出しのモニタリングは、組織のデータ保護メカニズムの強度を検証し、必要に応じてプロアクティブな調整を行うのに役立ちます。Cloud NGFW の脅威検出結果を Security Command Center と Google SecOps に統合すると、ネットワークベースの脅威検出を最適化し、脅威対応を最適化して、ハンドブックを自動化できます。

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

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

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

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

  • Security Command Center は、サイバー防御オペレーションを調整、管理するための中央ハブとして機能します。ツール、チーム、データを統合し、組み込みの 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 サイバー防御のあらゆる側面でインテリジェンス機能を使用する: AI を使用してリスクを評価し、脆弱性の優先順位を付け、修復のための実用的な分析情報を提供します。

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

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

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

防御側の優位性を理解して活用する: データ保護、マルウェア防止、拡張機能の制御により、エンタープライズ デバイスのセキュリティを強化します。

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

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

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

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則では、AI システムを保護するうえで役に立つ推奨事項が示されています。これらの推奨事項は、Google のセキュア AI フレームワーク（SAIF）に沿っています。このフレームワークは、AI システムのセキュリティとリスクに関する懸念に対処するための実践的なアプローチを提供します。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 システムを設計して進化させる際には、特定のビジネスの目標、リスク、コンプライアンス要件を理解することが重要です。

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

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

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

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

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

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

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

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

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

  • 強固なセキュリティ基盤を AI エコシステムまで拡大する。安全な AI システムを構築するための重要な要素として、コードとモデル アーティファクトを保護します。
  • 制御を適応させてフィードバック ループを高速化する。これは、緩和とインシデント対応に重要であるため、アセットとパイプラインの実行を追跡します。

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

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

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

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

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

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

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

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

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

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

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

Google の推奨事項に反映されているように、Google の AI ガバナンスのアプローチは、次の原則に基づいています。

  • 公平さ
  • 透明性
  • 説明責任
  • プライバシー
  • セキュリティ

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

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

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

Vertex Explainable AI を使用する

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

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

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

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

データリネージは Knowledge 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 がセキュリティ タスクの主な責任を負い、必要な場合にのみ人間の支援を求めます。

Google SecOps の Gemini は、アナリストの支援、関連するコンテキストの取得、次のステップの推奨により、労力の大きいタスクを自動化できます。

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

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

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

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

AI システムの安全な開発手法を導入する

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

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

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

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

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

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

Google Cloud Well-Architected Framework のセキュリティの柱におけるこの原則は、Cloud Deploy の規制、コンプライアンス、プライバシー要件を特定して満たすうえで役立ちます。これらの要件は、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 Cloud は、コンプライアンス ポートフォリオの維持と拡大に取り組んでいます。Cloud のデータ処理に関する追加条項（CDPA）には、お客様のデータの処理とセキュリティに関する Google の取り組みが記載されています。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 フローログ: VM インスタンスによって送受信されたネットワーク トラフィック フローを記録します。
  • Security Command Center Premium: さまざまな標準への準拠をモニタリングします。
  • OSSEC（または別のオープンソース ツール）: 環境に対する管理者権限がある個人のアクティビティをログに記録します。
  • Key Access Justifications: 鍵アクセス リクエストの理由を表示します。
  • Security Command Center の通知: コンプライアンス違反の問題が発生したときにアラートを受け取ります。たとえば、ユーザーが 2 段階認証プロセスを無効にした場合や、サービス アカウントに過剰な権限が付与されている場合にアラートを受け取ります。特定の通知に対する自動修復を設定することもできます。

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

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

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

運用主権を管理する

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

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

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

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

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

たとえば、ソフトウェア主権の管理を支援するため、 Google Cloudはハイブリッド デプロイとマルチクラウド デプロイをサポートしています。データ主権を理由にオンプレミス デプロイを選択する場合、Google Distributed Cloud は、 Google Cloud をデータセンターに導入するハードウェアとソフトウェアの組み合わせです。

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

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

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

次の推奨事項は、実装できる追加のコントロールに関するものです。詳しくは、プライバシー リソース センターをご覧ください。

データ所在地を制御する

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

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

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

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

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

機密データを分類する

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

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

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

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

  • データ セキュリティ
  • Identity and Access Management

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 をご覧ください。

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

責任の共有での課題

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

  • クラウド セキュリティ侵害の多くは、構成ミスが原因で発生しています。クラウド プロダクトは絶えず変化しており、新しいプロダクトが常にリリースされています。絶え間ない変化に対応するのは大変な作業のように思えます。利用者には、デフォルトのベスト プラクティスと、ベースラインとなる安全な構成を用意し、変化に対応できる独自のベスト プラクティスを提供するクラウド プロバイダが必要です。
  • クラウド サービスで項目を分割することは便利ですが、企業の多くには、複数の種類のクラウド サービスを必要とするワークロードがあります。このような状況では、サービス間でさまざまなセキュリティ コントロールがどのように影響しあうのかを検討しなければなりません（たとえば、サービス間で重複するかどうかなど）。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 が含まれています。サイバー保険の補償内容をお探しの場合、Cyber Insurance Hub から得たこれらの分析情報を保険パートナーと直接共有して見積もりを取得できます。

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

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

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

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

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

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

次のステップ