Google Cloud Well-Architected フレームワーク: セキュリティ、プライバシー、コンプライアンス

Last reviewed 2025-02-14 UTC

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

このドキュメントは、さまざまなセキュリティ担当者とエンジニアのニーズを満たす貴重な分析情報を提供することを目的としています。次の表に、このドキュメントの対象読者を示します。

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

Google Cloud ワークロードがセキュリティ、プライバシー、コンプライアンスの要件を満たすようにするには、組織内のすべての関係者がコラボレーション アプローチを採用する必要があります。また、クラウド セキュリティはお客様と Google の間で共有される責任であることを認識する必要があります。詳細については、Google Cloud における責任の共有と運命の共有 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 フレームワークのAI と ML の視点と Google のセキュア AI フレームワーク（SAIF）のガイダンスに沿っています。
  • セキュリティに AI を使用する: Gemini in Security と全体的なプラットフォーム セキュリティ機能を通じて、AI 機能を使用して既存のセキュリティ システムとプロセスを改善します。AI をツールとして使用して、修復作業の自動化を促進し、セキュリティ対策を強化して他のシステムのセキュリティを強化します。
  • 規制、コンプライアンス、プライバシーのニーズを満たす: 業界固有の規制、コンプライアンス標準、プライバシー要件に準拠します。 Google Cloud は、Assured Workloads、組織のポリシー サービス、コンプライアンス リソース センターなどのプロダクトを通じて、これらの義務を果たすお手伝いをします。

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

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

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

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

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

フォーカス領域 アクティビティとコンポーネント 関連 Google Cloud プロダクト、機能、ソリューション
インフラストラクチャのセキュリティ
  • ネットワーク インフラストラクチャを保護する。
  • 転送中と保存中のデータの暗号化
  • トラフィック フローを制御する。
  • IaaS サービスと PaaS サービスを保護する。
  • 不正アクセスから保護する。
ID とアクセスの管理
  • 認証、認可、アクセス制御を使用します。
  • 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
  • Susan Wu | アウトバウンド プロダクト マネージャー

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

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

原則の概要

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

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

推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

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

セキュリティ レイヤを設計するときは、リスク評価を実施して、内部セキュリティ要件と外部規制要件を満たすために必要なセキュリティ機能を決定します。クラウド環境に適用され、規制要件に関連する業界標準のリスク評価フレームワークを使用することをおすすめします。たとえば、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 が管理を委託している物理的境界の外へ出るときに、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 管理インフラストラクチャを拡張して、ユーザーのシングル サインオン（SSO）を有効にできます。 Google Cloud
    • 既存の 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 Web Token（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 のセキュリティ ピラーにあるこの原則は、ソフトウェア開発ライフサイクルの早い段階で実装できる実用的な制御を特定して、セキュリティ対策を改善するのに役立ちます。予防的なセキュリティ ガードレールとデプロイ後のセキュリティ管理の実装に役立つ推奨事項が提供されます。

原則の概要

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

  • システムの変更前にセキュリティ上の欠陥を回避します。予防的なセキュリティ ガードレールを実装し、CI/CD パイプラインで Infrastructure as Code（IaC）、Policy as Code、セキュリティ チェックなどのプラクティスを採用します。 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 などのツールを使用してポリシー as Code などのプラクティスを採用することもできます。インフラストラクチャの変更を経時的に監査し、変更をデプロイする前にインフラストラクチャ コードの自動チェックを実行できます。

インフラストラクチャのデプロイを自動化するには、Config Controller、Terraform、Jenkins、Cloud Build などのツールを使用できます。IaC と自動化を使用して安全なアプリケーション環境を構築できるように、Google Cloud にはエンタープライズ基盤のブループリントが用意されています。このブループリントは、Google の推奨プラクティスと構成に従った 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 の創設者の言葉を借りれば、「自社のビジネス、システム、トポロジ、インフラストラクチャについて、どの攻撃者よりも熟知しているはずです。これは大きな利点です。」この固有の利点を活用できるように、このドキュメントでは、Defender's Advantage フレームワークにマッピングされた、予防的で戦略的なサイバー防御手法に関する推奨事項について説明します。

推奨事項

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

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

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

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

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

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

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

この推奨事項では、インテリジェンス機能が強力なサイバー防御プログラムのコア部分として強調されています。脅威インテリジェンスは、脅威アクター、その 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 Enterprise を使用すると、セキュリティ担当者は複数のクラウド環境にまたがるセキュリティ問題を効率的に評価、調査、対応できます。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 をご覧ください。

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

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

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

以下のサービスと機能は、Mission Control 機能を実装する際に役立ちます。

  • 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 サイバー防御のあらゆる側面でインテリジェンス機能を使用: 情報漏洩のリスクからユーザーを保護し、マルウェアを防止し、安全でないブラウザ アクティビティを可視化します。

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

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

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）に準拠しています。SAIF は、AI システムのセキュリティとリスクに関する懸念に対処するための実用的なアプローチを提供します。SAIF は、責任ある方法で AI を構築、デプロイするための業界標準を提供することを目的とした概念フレームワークです。

原則の概要

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

Google は AI を使用して、脅威の特定、セキュリティ タスクの自動化、検出機能の向上などのセキュリティ対策を強化しながら、重要な意思決定には人間が関与できるようにしています。

Google は、AI のセキュリティを強化するために協調的なアプローチを重視しています。このアプローチでは、お客様、業界、政府と連携して SAIF ガイドラインを強化し、実用的で実践的なリソースを提供します。

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

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

AI を安全に使用するには、基本的なセキュリティ管理と AI 固有のセキュリティ管理の両方が必要です。このセクションでは、AI と ML のデプロイが組織のセキュリティ、プライバシー、コンプライアンスの要件を満たすようにするための推奨事項の概要について説明します。 Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要については、Well-Architected フレームワークの 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 にモデルを登録してそこで利用することもできます。

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

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

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

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

AI システムの開発、デプロイ、結果について明確な責任を定めます。

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

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

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

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

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

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

サイバー攻撃の増加と高度化に伴い、セキュリティ強化に AI の可能性を活用することが重要になっています。AI は、脅威の数を減らし、セキュリティ プロフェッショナルが行う必要のある手作業を減らし、サイバーセキュリティ ドメインの専門家の不足を補うことができます。

原則の概要

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

これらの 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 がセキュリティ タスクのより多くの責任を負います。

AI を使用して脅威アクターによる動作と悪質なコードを分析する Google Threat Intelligence は、この推奨事項の実装に役立ちます。

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

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

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

AI を搭載したツールは、アラートを要約し、緩和策を推奨できます。これらの機能により、幅広い人員がセキュリティにアクセスできるようになります。この推奨事項は、次の SAIF 要素に対応しています。

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

実装に応じて、この推奨事項は次のレベルの自動性に関連する場合があります。

  • アシストあり: AI がセキュリティ情報のアクセス性を向上させます。
  • 半自律型: AI により、すべてのユーザーにとってセキュリティ対策をより効果的に行うことができます。

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

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 のセキュリティ ピラーのこの原則は、クラウド デプロイメントの規制、コンプライアンス、プライバシーの要件を特定して満たすのに役立ちます。これらの要件は、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 のデータ処理に関する追加条項（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 サポート担当者が適切なバックグラウンド チェックを完了しているかどうかを選択できます。
  • Google が所有し、FIPS-140-2 に準拠し、FedRAMP Moderate コンプライアンスをサポートする鍵を使用します。 Google-owned and Google-managed encryption key 制御レイヤの追加と職掌分散のため、顧客管理の暗号鍵（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はハイブリッド デプロイとマルチクラウド デプロイをサポートしています。また、GKE Enterprise では、クラウド環境とオンプレミス環境の両方でアプリケーションを管理およびデプロイできます。データ主権上の理由でオンプレミス デプロイを選択する場合は、ハードウェアとソフトウェアを組み合わせた Google Distributed Cloud をデータセンターに導入します。 Google Cloud

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

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

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

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

データ所在地を制御する

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

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

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

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

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

機密データを分類する

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

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

他の業界（金融や製造など）にも、データの収集、処理、保存の方法に対する規制があります。これらに関連する責任の共有の詳細と、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 Cloud運命の共有には、安全なランディング ゾーンの構築の支援だけでなく、推奨されるセキュリティ コントロール、設定、関連するベスト プラクティスに対して明確さ、独自性、透明性を持たせることも含まれます。また、Google の Risk Protection Program を使用したサイバー保険でリスクを定量化し、管理することも含まれます。Google は運命の共有を使用して、標準的な責任共有フレームワークを進化させ、ビジネスを保護しながら Google Cloudでの信頼関係を構築できる、より優れたモデルに発展させたいと考えています。

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

サポート

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

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

  • エンタープライズ基盤のブループリント。セキュリティ上の主な懸念事項と推奨事項について説明します。

  • セキュアなブループリント。Infrastructure as Code（IaC）を使用して安全なソリューションをデプロイし、維持するためのブループリントです。ブループリントでは、セキュリティの推奨事項がデフォルトで有効になっています。多くのブループリントは、Google のセキュリティ チームが作成し、プロダクトとして管理しています。このサポートはつまり、ブループリントは定期的に更新され、厳格なテストプロセスを経て、第三者のテストグループから証明書を受け取っているということです。ブループリントには、エンタープライズ基盤のブループリントと安全なデータ ウェアハウスのブループリントがあります。

  • Google Cloud 設計にセキュリティを組み込む際の最善の推奨事項に対応する Well-Architected フレームワークのベスト プラクティス。Well-Architected フレームワークには、エキスパートや同僚との接点として使用できるセキュリティ セクションとコミュニティ ゾーンが用意されています。

  • ランディング ゾーンのナビゲーション ガイドには、リソース階層、ID オンボーディング、セキュリティ、鍵管理、ネットワーク構造など、ワークロードの安全な基盤を構築するために必要な基本的な決定事項が記載されています。

Risk Protection Program

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

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

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

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

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

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

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

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

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

次のステップ