Cloud Key Management Service の暗号化

このコンテンツの最終更新日は 2025 年 1 月で、作成時点の状況を表しています。お客様の保護の継続的な改善のために、Google のセキュリティポリシーとシステムは変更される場合があります。

このドキュメントでは、Cloud Key Management Service（Cloud KMS）が、保存データの暗号化のために Google Cloud の鍵管理サービスを提供します。 Google Cloud は、 Google Cloud のお客様がご自分のデータに責任を持ち、その使用状況を管理していることを前提としています。

Google Cloudでデータを保存する際、データはデフォルトで保存時に暗号化されます。Cloud KMS プラットフォームを使用すると、保存データの暗号化方法と暗号鍵の管理方法をさらに詳細に管理できます。

このドキュメントでは、Cloud KMS プラットフォームの内部構造について説明します。これらのオプションは、 Google Cloudに保存されている鍵やその他の機密データの保護に役立ちます。このドキュメントは、Cloud KMS のアーキテクチャ、インフラストラクチャ、機能について詳しく把握する必要があり、技術的な意思決定を行う担当者を対象としています。このドキュメントでは、暗号化のコンセプトとクラウドアーキテクチャに関する基本的な知識があることを前提としています。

Google Cloudの鍵

次の表に、 Google Cloudのさまざまなタイプの鍵を示します。

鍵の種類	Cloud KMS Autokey	お客様管理の Cloud KMS（手動）	Google-owned and Google-managed encryption key （Google のデフォルトの暗号化）
鍵のメタデータを閲覧可能	はい	はい	いいえ
鍵の所有権¹	お客様	お客様	Google
鍵の管理²と制御³が可能	鍵の作成と割り当ては自動化されます。お客様による手動制御は完全にサポートされています。	お客様、手動制御のみ	Google
顧客管理の暗号鍵の規制要件をサポート	はい	はい	いいえ
鍵の共有	お客様に固有	お客様に固有	通常、複数のお客様のデータは共有鍵暗号鍵（KEK）で保護されます。
鍵のローテーションの制御	はい	はい	いいえ
CMEK の組織のポリシー	はい	はい	いいえ
暗号鍵への管理とデータアクセスをログに記録する	はい	はい	いいえ
暗号化による論理データ分離	はい	はい	×
料金	可変	可変	無料

¹ 鍵の所有者は鍵に対する権利の所有者を示します。お客様が所有する鍵は、アクセスが厳格に制限されているか、Google はこれにアクセスできません。

² 鍵の管理には次のタスクが含まれます。

鍵を作成する。
鍵の保護レベルを選択する。
鍵を管理する権限を割り当てる。
鍵へのアクセスを制御する。
鍵の使用を制御する。
鍵のローテーション期間を設定および変更したり、鍵のローテーションをトリガーしたりする。
鍵のステータスを変更する。
鍵バージョンを破棄する。

³ 鍵の制御とは、鍵の種類と鍵の使用方法に対する制御の設定、差異の検出、必要に応じた是正措置の計画を意味します。ユーザーは鍵を制御できますが、鍵の管理は第三者に委任します。

Cloud KMS の原則

Google では、Cloud KMS を使用して、スケーラビリティ、信頼性、パフォーマンスに優れ、幅広い制御オプションを備えたソリューションの提供に重点を置いています。Cloud KMS は、次の原則に基づいてサポートされています。

お客様による管理: Cloud KMS では、暗号化と署名に使用するソフトウェア鍵とハードウェア鍵をお客様が独自に管理できます。この特性には、Bring-Your-Own-Key（BYOK）と Hold-Your-Own-Key（HYOK）のサポートも含まれています。
アクセス制御とモニタリング: Cloud KMS では、個々の鍵の権限を管理し、鍵の使用状況をモニタリングできます。
リージョンの制限: Cloud KMS では、最初にリージョンの指定を行います。このサービスは、選択した Google Cloud ロケーションでのみソフトウェア鍵を作成、保存、処理するように構成されています。
バックアップ: データの破損を防止し、データを正常に復号できるようにするため、Cloud KMS はすべての鍵マテリアルとメタデータを定期的にスキャンし、バックアップします。
セキュリティ: Cloud KMS は、鍵に対する不正アクセスを防ぐ強力な保護機能を提供します。Identity and Access Management（IAM）および Cloud Audit Logs の制御と完全に統合されています。
論理データの分離: Cloud KMS 暗号化は、暗号化による論理データの分離を提供します。論理データ分離とは、データオーナーが暗号鍵（KEK と DEK）を共有しないことを意味します。

暗号鍵のソースと管理オプション

Cloud KMS プラットフォームでは、中央のクラウドサービスで直接使用する暗号鍵を管理したり、他のクラウドリソースやアプリケーションで使用する暗号鍵を管理できます。

鍵の Google Cloud ポートフォリオには次のものが含まれます。

デフォルトの暗号化: Google で保存されるすべてのデータは、高度暗号化標準（AES）アルゴリズムである AES-256 を使用してストレージレイヤで暗号化されます。デフォルトの暗号化に使用する鍵は Google が生成して管理します。お客様に鍵に対するアクセス権はありません。また、鍵のローテーションと管理を行う権限もありません。デフォルトの暗号鍵はお客様の間で共有される場合があります。詳細については、デフォルトの保存データの暗号化をご覧ください。
Cloud KMS とソフトウェアで保護された鍵: Cloud KMS で生成される鍵を制御できます。Cloud KMS ソフトウェアバックエンドにより、管理する対称鍵または非対称鍵のいずれかを使用してデータの暗号化や署名を柔軟に行うことができます。
Cloud KMS とハードウェアで生成された鍵（Cloud HSM）: Cloud HSM バックエンドと Cloud KMS を使用すると、Google が所有および運用するハードウェアセキュリティモジュール（HSM）によって生成され、保存される鍵を所有できます。ハードウェアで保護された鍵が必要な場合は、Cloud HSM バックエンドを使用することで、FIPS 140-2 レベル 3 認定済みの HSM でのみ鍵が使用されるようにすることができます。ハードウェアで保護された鍵は、Cloud KMS 管理者を必要とする手動の方法でプロビジョニングすることも、Cloud KMS Autokey を使用して自動的にプロビジョニングすることもできます。Autokey を使用すると、顧客管理の暗号鍵（CMEK）の鍵のプロビジョニングと鍵の割り当てプロセスを自動化できます。従来の HSM 鍵では、リクエストに応じて KMS 管理者が鍵を作成する必要があります。
Cloud KMS と鍵のインポート: BYOK の要件を満たすために、自身で生成した独自の暗号鍵をインポートできます。これらの鍵はGoogle Cloudの外部で使用または管理できます。また、Cloud KMS の鍵マテリアルを使用して、 Google Cloudに保存するデータの暗号化または署名を行うこともできます。
Cloud KMS と外部鍵マネージャーの使用（Cloud EKM）: HYOK の要件を満たすため、 Google Cloudの外部にある鍵マネージャーに格納される鍵を作成し、制御できます。さらに、外部鍵を使用して保存データを保護するように Cloud KMS プラットフォームを設定できます。これらの暗号鍵は Cloud EKM 鍵で使用できます。外部鍵管理と Cloud EKM の詳細については、Cloud EKM のリファレンスアーキテクチャをご覧ください。

Cloud KMS によって生成された鍵は、他のGoogle Cloud サービスと組み合わせて使用できます。この鍵は CMEK と呼ばれます。CMEK 機能を使用すると、他の Google Cloudサービスのデータを保護するための暗号鍵を生成し、使用、ローテーション、破棄を行うことができます。 Google Cloud サービスで CMEK を使用すると、鍵のアクセスと追跡が自動的に管理されます。

Google での暗号化と鍵管理

このセクションでは、Google の多層鍵管理インフラストラクチャのコンテキストにおける鍵管理に関する用語を定義します。

キーリング、鍵、鍵バージョン

次の図に、鍵のグループ化を示します。ここには、キーリングと、1 つのプライマリバージョンと以前の複数のバージョンを持つ鍵を示します。

鍵グループ化の図。

上の図に示されているコンセプトは次のとおりです。

鍵: 特定の目的に使用される暗号鍵を表す名前付きのオブジェクト。鍵マテリアル（暗号オペレーションに使用される実際のビット）は、新しい鍵バージョンを作成するたびに随時変更されます。IAM 許可ポリシーをリソース階層のキーレベルで割り当てることができます。

鍵の目的とその他の属性は、鍵を使用してリンクされ、管理されます。したがって、KMS の使用状況を把握するうえで、鍵は最も重要なオブジェクトとなります。

Cloud KMS は、非対称鍵と対称鍵の両方をサポートしています。対称鍵は、MAC 署名を作成または検証するため、またはデータのコーパスの一部を保護するめの対称暗号化に使用されます。たとえば、GCM モードの AES-256 を使用して、平文のブロックを暗号化できます。非対称鍵は、非対称暗号化または非対称署名に使用できます。詳細については、サポートされる目的とアルゴリズムをご覧ください。
キーリング: 鍵を整理するための鍵のグループ。キーリングは Google Cloud プロジェクトに属し、特定の場所に格納されます。鍵は、キーリングから許可ポリシーを継承します。関連する権限を持つ鍵をキーリングにグループ化すると、個別に鍵を操作することなく、キーリングレベルでこれらの鍵に対する権限の付与、取り消し、変更を行うことができます。キーリングは利便性と分類を提供しますが、キーリングのグループ化が不要な場合は、鍵で直接権限を管理できます。タグを使用すると、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでポリシーを許可または拒否することが可能になります。リソース階層のキーリングレベルでタグを適用できます。

リソース名の競合を防ぐため、キーリングや鍵は削除できません。キーリングと鍵には、請求可能な費用や割り当ての上限がないため、これらが存在し続けても費用や本番環境の上限には影響しません。
鍵のメタデータ: リソース名、KMS リソースのプロパティ（許可ポリシー、鍵の種類、鍵のサイズ、鍵の状態、鍵とキーリングから派生したデータなど）。
鍵バージョン: ある時点で鍵に関連付けられた鍵マテリアル。鍵バージョンは、実際の鍵マテリアルを含むリソースです。バージョンにはバージョン 1 から順に番号が振られます。鍵をローテーションすると、新しい鍵バージョンが新しい鍵マテリアルで作成されます。同じ論理鍵が時間の経過とともに複数のバージョンを持つことがあり、データが異なる鍵バージョンで暗号化される場合があります。対称鍵にはプライマリバージョンがあります。デフォルトでは、プライマリバージョンが暗号化に使用されます。Cloud KMS は、対称鍵を使用して復号を行うときに、復号に必要な鍵バージョンを自動的に識別します。

鍵の階層

次の図は、Cloud KMS と Google の内部キーストアの鍵階層とエンベロープ暗号化を示しています。エンベロープ暗号化は、鍵を安全に保管する場合や、信頼できないチャネルで送信する場合に、鍵を別の鍵で暗号化する処理です。この図の鍵はすべて対称鍵です。

内部鍵階層の図。

鍵階層内で、データ暗号鍵（DEK）がデータチャンクを暗号化します。鍵暗号鍵（KEK）は、DEK を暗号化またはラップするために使用されます。すべての Cloud KMS プラットフォームオプション（ソフトウェア、ハードウェア、外部バックエンド）を使用して、KEK を制御できます。KEK は Cloud KMS に保存されます。鍵マテリアルが Cloud KMS システム境界の外部に出ることはありません。

ソフトウェアで保護された鍵の場合、ロケーション固有の KMS マスター鍵が KEK を暗号化します。KMS マスター鍵はキーストアに保存されます。キーストアには、Cloud KMS のロケーションごとに個別の KMS マスター鍵があります。各 Cloud KMS サーバーは起動時に KMS マスター鍵のコピーをハード依存関係として取得します。KMS マスター鍵の新しいコピーは毎日取得されます。KMS マスター鍵は、キーストア内のキーストアマスター鍵を使用して定期的に再暗号化されます。キーストアマスター鍵はルートキーストアマスター鍵で保護されています。

ハードウェアで保護された鍵の場合、ロケーション固有の HSM ラッピング鍵が KEK を暗号化し、HSM ラッピング鍵は KMS マスター鍵で暗号化されます。詳細については、鍵の作成をご覧ください。外部鍵の場合、EKM ラッピング鍵がラップされた DEK を暗号化し、EKM ラッピング鍵は KMS マスター鍵で暗号化されます。

Cloud KMS は、Google の内部鍵管理サービスであるキーストアを使用して、Cloud KMS で暗号化された鍵をラップします。Cloud KMS は、キーストアと同じルートオブトラストを使用します。キーストアの詳細については、保存データの暗号化の鍵管理をご覧ください。

運用上の制約

Cloud KMS は次の制約内で動作します。

プロジェクト: 他のすべての Google Cloudリソースと同様に、Cloud KMS リソースは Google Cloudプロジェクトに属します。Cloud KMS 鍵は、鍵で保護するデータとは別のプロジェクトに配置できます。リソースが保護するデータと同じプロジェクトに鍵を保持する場合は、鍵管理者とデータ管理者の職掌分散のベストプラクティスをサポートするために、プロジェクトからオーナーのロールを削除できます。
ロケーション: プロジェクト内では、Cloud KMS リソースはロケーションに作成されます。ロケーションの詳細については、地域とリージョンをご覧ください。
整合性: Cloud KMS は、強整合性または結果整合性を使用して、鍵、鍵リング、鍵バージョンに対するオペレーションを伝播します。詳細については、Cloud KMS リソースの完全性をご覧ください。

顧客管理の暗号鍵

デフォルトでは、 Google Cloud は保存されているすべての顧客データを暗号化し、暗号化に使用される鍵は Google が管理します。お客様のコンテンツを永続的に保存する互換性のある Google Cloudプロダクト（Cloud Storage など）の場合は、代わりに Cloud KMS を使用して顧客管理の暗号鍵（CMEK）を管理できます。CMEK は、お客様が所有する暗号鍵であり、外部鍵、ソフトウェア保護鍵、ハードウェア保護鍵で使用できます。

CMEK を使用すると、互換性のある Google Cloud サービス内で保存データの暗号化に使用する鍵をより細かく制御し、データに暗号境界を設定できます。CMEK は、Cloud KMS で直接管理することも、Autokey を使用してプロビジョニングと割り当てを自動化することもできます。サービスが CMEK を使用する場合、ワークロードはデフォルトの暗号化のみを使用している場合と同じ方法でリソースにアクセスできます。

Cloud KMS ではユーザーが、鍵の作成、有効化、無効化、ローテーション、破棄など、鍵の多くの側面を制御し、鍵に対する適切な IAM 権限を管理できます。推奨される職掌分散を適用するため、Cloud KMS には特定の権限と制限があり、特定のユーザーとサービスアカウントに付与できる IAM 事前定義ロールがいくつか用意されています。

Cloud KMS はエンベロープ暗号化を使用するため、CMEK は DEK を暗号化する KEK です。詳細については、鍵の階層をご覧ください。

CMEK のローテーションは、鍵が保護するリソースタイプによって異なります。以下の例を考えてみましょう。

Spanner では、新しい鍵バージョンで DEK が再暗号化されます。
Cloud Storage バケットなどの他のリソースタイプの場合、新しく作成されたリソースのみが新しい鍵バージョンを使用して暗号化されます。つまり、異なるバージョンの鍵で、異なるデータのサブセットが保護されます。
シナリオによっては、新しい鍵バージョンを使用してクラウドリソースを再作成する必要があります。たとえば、テーブルに関連付けられている Cloud KMS 鍵のローテーションが行われても、BigQuery がそのテーブルの暗号鍵のローテーションを自動的に行うことはありません。既存の BigQuery テーブルでは引き続き、作成時に使用された鍵バージョンが使用されます。

鍵のローテーションの詳細については、各プロダクトのドキュメントをご覧ください。

CMEK の組織のポリシーにより、プロジェクト内で CMEK を使用する方法をより詳細に制御できます。これらのポリシーを使用すると、CMEK で許可される鍵を保持するサービスとプロジェクト、および鍵の保護レベルを制御できます。

Google Cloud は、Cloud Storage、BigQuery、Compute Engine などの多くのサービスで CMEK をサポートしています。CMEK 統合と CMEK 準拠のサービスの一覧については、CMEK 統合をご覧ください。Google は、引き続き他の Google Cloud プロダクトの CMEK 統合に投資していきます。

Cloud KMS Autokey

Autokey を使用すると、CMEK のプロビジョニングプロセスを効率化できます。手動の CMEK プロビジョニングプロセスでは、Cloud KMS 管理者は、キーリング、鍵、サービスアカウントの種類を必要になる前に計画し、デベロッパーと連携して鍵をプロビジョニングする必要があります。Autokey を使用すると、Cloud KMS 管理者はプロジェクト内の Cloud KMS サービスエージェントに権限を委任します。Autokey を有効にすると、デベロッパーは Cloud KMS から鍵をリクエストできます。サービスエージェントは、デベロッパーの意図に適した鍵をプロビジョニングします。Autokey を使用すると、鍵はオンデマンドで使用でき、一貫性があり、業界標準のプラクティスに準拠しています。

Autokey は、デベロッパーがクラウドリソースを作成するときに、役割分担を尊重しながら、キーリング、鍵、サービスアカウントをオンデマンドでプロビジョニングして割り当てます。鍵のプロビジョニングと割り当ては、次のようなデータセキュリティに関する業界標準のプラクティスと推奨事項に準拠しています。

HSM 保護レベル: Autokey を使用して作成された鍵は常に HSM 鍵であるため、Cloud HSM バックエンドに保存されます。これらは AES-256 GCM 暗号鍵です。
職務分離: 職務分離を維持するため、鍵を使用して暗号化と復号を行うことができる ID は、鍵を管理する ID（ローテーション、破棄、状態の変更など）とは異なります。
鍵のローテーション: 鍵は毎年ローテーションされます。
鍵とリソースのコロケーション: 鍵は、鍵が保護するリソースと同じロケーションに存在します。
鍵の限定性: 鍵の限定性は、鍵が保護するリソースタイプに適しています（リソースタイプごとに）。特定性とは、各サービスのリソースタイプを手動で確認し、1 つの鍵で保護する各リソースタイプの数を決定する必要がないことを意味します。

Autokey を使用してリクエストされた鍵は、同じ設定を持つ他の Cloud HSM 鍵と同じように機能します。Autokey を使用すると、鍵の作成権限を昇格して Infrastructure as Code を実行する必要がなくなるため、Terraform の使用が簡素化されます。Autokey は、Cloud HSM が利用できるすべてのGoogle Cloud ロケーションで利用できます。

Autokey は特定の　 Google Cloud 　リソースでのみ使用できます。詳細については、Autokey の概要をご覧ください。

Cloud KMS プラットフォームのアーキテクチャとコンポーネント

Cloud KMS プラットフォームは複数の暗号アルゴリズムをサポートし、外部鍵、ハードウェア保護鍵、ソフトウェア保護鍵を使用して、暗号化とデジタル署名を行います。Cloud KMS プラットフォームは、Identity and Access Management（IAM）および Cloud Audit Logs に統合されているため、個別の鍵の権限を管理し、使用状況を監査できます。

Cloud KMS のアーキテクチャ図。

前の図は、Cloud KMS プラットフォームの主なコンポーネントを示しています。

管理者は、Cloud コンソールまたは Google Cloud CLI を使用して、鍵管理サービスにアクセスします。
アプリケーションは REST API、gRPC、またはクライアントライブラリを実装して、鍵管理サービスにアクセスします。アプリケーションは、CMEK の使用が有効になっている Google サービスを使用できます。次に CMEK が Cloud Key Management Service API を使用します。アプリケーションで PKCS #11 を使用している場合は、PKCS #11 用のライブラリを使用して Cloud KMS と統合できます。
Cloud KMS API では、ソフトウェ鍵、ハードウェア鍵、外部鍵を使用できます。 Cloud KMS サービスエンドポイントを使用して、ソフトウェア保護鍵とハードウェア保護鍵を生成して管理できます。ソフトウェア保護とハードウェア保護の両方の鍵で、Google の冗長バックアップ保護が利用されます。
ハードウェアで保護された鍵を使用する場合、Google Cloud の FIPS 140-2 レベル 3 認定済み HSM では鍵が保存されます。Google が保持する認証の詳細については、Certificate #4399 をご覧ください。
Cloud KMS は、Google の内部データストアを使用して、暗号化された顧客鍵マテリアルを保存します。このデータストアは可用性が高く、Google の多くの重要なシステムをサポートしています。データストアの保護をご覧ください。
独立したバックアップシステムが、データストア全体をオンラインストレージとアーカイブストレージの両方に定期的にバックアップします。このバックアップにより、Cloud KMS は耐久性の目標を達成できます。データストアの保護をご覧ください。

FIPS 140-2 認定

Cloud KMS 暗号オペレーションは、FIPS 140-2 認定モジュールによって実行されます。保護レベルが SOFTWARE である鍵と、それらを使用して実行される暗号オペレーションは、FIPS 140-2 レベル 1 を遵守しています。これらの暗号オペレーションでは、Google が管理するオープンソースの暗号ライブラリである BoringCrypto を使用します。保護レベルが HSM である鍵と、それらを使用して実行される暗号オペレーションは、FIPS 140-2 レベル 3 を遵守しています。

鍵マテリアルのセキュリティ

Cloud KMS では、鍵マテリアルは保存時も転送時も常に暗号化されます。鍵マテリアルが復号されるのは、次の場合に限られます。

お客様が使用している場合。
お客様の鍵マテリアルを保護するために使用される Google の内部鍵をローテーションしているか、その完全性を確認している場合。

Cloud KMS へのユーザーリクエストは、お客様と Google Front End（GFE）間の TLS を介した転送中に暗号化されます。

認証は、Google データセンター内と Google データセンター間で行われるすべての Cloud KMS ジョブの合間に行われます。

Google のポリシーでは、検証可能な方法でビルド、テスト、レビューされたソースコードのみが使用されるようになっています。Binary Authorization for Borg（BAB）は、このポリシーを運用レベルで適用します。

Cloud KMS API ジョブは、鍵メタデータ（許可ポリシーやローテーション期間など）にアクセスできます。文書化された、ビジネス上の有効かつ正当な理由（バグやお客様の問題など）がある Google 社員も、鍵メタデータにアクセスできます。アクセスは内部で記録され、資格のあるお客様は、アクセスの透明性の対象となるデータのログも閲覧できます。

復号された鍵マテリアルは、API インターフェースまたは別のユーザーインターフェースからエクスポートまたは表示することはできません。暗号化されていない顧客鍵マテリアルに Google 社員は一切アクセスできません。さらに、鍵マテリアルはキーストア内のマスター鍵で暗号化されます。マスター鍵に個人が直接アクセスすることはできません。HSM では、Cloud KMS API ジョブが鍵マテリアルに復号された状態でアクセスすることはありません。

データストアの保護

Cloud KMS のデータストアは可用性が高く、耐久性があり、安全に保護されています。

可用性。Cloud KMS は Google の内部データストアを使用します。このデータストアは可用性が高く、Google の多数の基幹システムをサポートしています。

耐久性。Cloud KMS は認証された暗号化を使用して、顧客鍵マテリアルをデータストアに保存します。また、すべてのメタデータはハッシュベースのメッセージ認証コード（HMAC）を使用して認証され、保存時に変更されることや破損しないことを保証します。バッチジョブはすべての鍵マテリアルとメタデータを 1 時間ごとにスキャンし、HMAC が有効で、鍵マテリアルがそれを正常に復号できることを確認します。データが破損した場合、Cloud KMS エンジニアが対処できるようにすぐにアラートが通知されます。

Cloud KMS は、データストアに複数のタイプのバックアップを使用します。

デフォルトでは、データストアは各行の変更履歴を 4 日間保持します。緊急時には、この存続期間を延長して問題を修正する時間を長くできます。
データストアは 1 時間ごとにスナップショットを記録します。スナップショットは、必要に応じて検証して復元に使用できます。スナップショットは 4 日間保持されます。
毎日、フルバックアップがディスクとアーカイブストレージにコピーされます。

Cloud KMS チームでは、サービス側で緊急事態が発生した場合のデータ損失を軽減するため、バックアップを復元する手順を文書化しています。

バックアップ。Cloud KMS データストアのバックアップは、関連する Google Cloud リージョンに存在します。これらのバックアップはすべて保存時に暗号化されます。バックアップのデータへのアクセスは、アクセスの正当性（Google サポートに提出したチケット番号など）に基づいてゲートされ、アクセスの透明性ログに記録されます。

保護。Cloud KMS のアプリケーションレイヤでは、鍵マテリアルは保存前に暗号化されます。データストアにアクセスできるエンジニアは、平文の顧客鍵マテリアルにアクセスできません。また、データストアは、管理するすべてのデータを暗号化してから永続ストレージに書き込みます。したがって、ディスクやアーカイブストレージなどの基盤となるストレージレイヤにアクセスしても、キーストアに保存されているデータストア暗号鍵にアクセスできないと、暗号化された Cloud KMS データにアクセスすることはできません。

ローテーションポリシー。鍵のローテーションは、鍵マテリアルの扱いに関するベストプラクティスの一環として一般に行われています。Cloud KMS データストアを保護する鍵にはローテーションポリシーがあります。鍵のローテーションポリシーは、Cloud KMS マスター鍵をラップするキーストアマスター鍵にも適用されます。キーストアマスター鍵では、暗号テキストの最長存続期間は 90 日間、クライアントでキャッシュに保存された鍵の最長存続期間は 1 日に設定されています。Cloud KMS は、KMS タスクの KMS マスター鍵を 24 時間ごとに更新し、すべての顧客鍵を毎月再暗号化します。

データ所在地。各 Cloud KMS データストアの基礎となるデータは、データが関連付けられている Google Cloud リージョン内にのみ存在します。これは、us マルチリージョンなど、マルチリージョンのロケーションにも適用されます。

作成後の鍵の可用性

Cloud KMS では、Cloud KMS データストアが鍵の作成トランザクションを commit した直後、およびストレージレイヤが鍵の作成を確定した直後に鍵を使用できるようになります。

鍵のバックエンドと保護レベル

Cloud KMS で鍵を作成する場合は、保護レベルを選択して、どのキーバックエンドで鍵を作成し、その鍵に対して今後すべての暗号オペレーションを行うかを決定できます。バックエンドは、次の保護レベルとして Cloud KMS API で公開されます。

SOFTWARE: 暗号オペレーションを実行するためにソフトウェアセキュリティモジュールによってラップ解除される鍵に適用されます。
HSM: 鍵を使用してすべての暗号オペレーションを実行する HSM でのみラップ解除できる鍵に適用されます。
EXTERNAL または EXTERNAL-VPC: 外部キーマネージャー（EKM）に適用されます。EXTERNAL-VPC により、VPC ネットワークを介して EKM を Google Cloud に接続できます。

Cloud KMS ソフトウェアバックエンド: ソフトウェアの保護レベル

保護レベル SOFTWARE は、暗号オペレーションをソフトウェアで実行する鍵に適用されます。ここでは、このレベルの実装方法について詳しく説明します。

アルゴリズムによる実装

ソフトウェア鍵の場合、Cloud KMS は関連するすべての暗号オペレーションに Google の BoringSSL 実装内の BoringCrypto モジュールを使用します。BoringCrypto モジュールは FIPS 140-2 検証済みです。Cloud KMS バイナリは、このモジュールの FIPS 140-2 レベル 1 検証済みの暗号プリミティブに対して構築されています。このモジュールで使われている最新のアルゴリズムは、鍵の目的とアルゴリズムに記載されています。これには、AES256-GCM の対称暗号鍵および RSA 2048、RSA 3072、RSA 4096、EC P256、EC P384 の非対称暗号鍵を使った暗号化、復号、署名のオペレーションも含まれています。

乱数の生成とエントロピー

暗号鍵を生成するとき、Cloud KMS は BoringSSL を使用します。FIPS 140-2 では、独自の PRNG を使用する必要があります（DRBG とも呼ばれます）。BoringCrypto では、Cloud KMS が AES-256 で CTR-DRBG のみを使用します。これにより、システムの残りの部分がランダムなデータを取得する際のプライマリインターフェースとなる RAND_bytes の出力が提供されます。この PRNG は Linux カーネルの RNG からシード値を取得しており、Linux カーネルの RNG は複数の独立したエントロピーソースからシード値を取得しています。このシーディングにはデータセンター環境からのエントロピーイベントが含まれます。たとえば、ディスクシークの詳細な測定、パケット間の到着時間、また使用可能な場合は Intel の RDRAND 命令などがこれに該当します。BoringSSL（FIPS 準拠モード）の乱数ジェネレータの動作の詳細については、RNG 設計をご覧ください。

Cloud HSM バックエンド: HARDWARE 保護レベル

Cloud HSM は、Cloud KMS にハードウェアで保護された鍵を提供します。これにより、Google データセンターのフルマネージド FIPS 140-2 レベル 3 認定済み HSM によって保護された暗号鍵を使用できます。Cloud HSM は可用性が高く、Cloud KMS と同様の柔軟なスケーリングが可能です。Cloud KMS と同じ API とクライアントライブラリを使用して Cloud HSM バックエンドにアクセスできます。Cloud HSM バックエンドの詳細については、Cloud HSM アーキテクチャをご覧ください。

Cloud EKM: EXTERNAL 保護レベル

Cloud EKM では、ユーザーが制御するオフクラウドの暗号鍵を使用してデータを暗号化できます。

保護レベルが EXTERNAL と EXTERNAL_VPC の鍵は、外部の鍵管理システムに保存され、管理されます。詳細については、Cloud EKM のリファレンスアーキテクチャをご覧ください。

鍵の作成プロセス

次の図は、さまざまな鍵バックエンドと保護レベルの鍵作成プロセスを示しています。

鍵の作成プロセスの図。

鍵の作成プロセスは次のとおりです。

ユーザーは Cloud KMS API を使用して、Cloud KMS に鍵の作成をリクエストします。このリクエストには、保護レベル（鍵がソフトウェアで保護されているか、ハードウェアで保護されているか、外部で保護されているか）が含まれます。
Cloud KMS は、ユーザー ID と、ユーザーに鍵を作成する権限があるかどうかを確認します。
鍵は次のように生成されます。
- ソフトウェアで保護された鍵の場合、Cloud KMS がカスタマー鍵を生成します。
- ハードウェアで保護された鍵の場合、Cloud KMS は Cloud HSM にリクエストを送信します。Cloud HSM は、新しい鍵を生成するためにリクエストを HSM に送信します。HSM は、お客様の鍵を生成し、HSM リージョンのラッピング鍵でこの鍵を暗号化（ラップ）します。Cloud HSM は、ラップされた鍵を Cloud KMS に返します。
- 外部鍵の場合、Cloud KMS は Cloud EKM にリクエストを送信します。Cloud EKM は、新しい鍵を生成するためにリクエストを外部鍵マネージャーに送信します。EKM は新しい鍵を生成し、この鍵を EKM ラップ鍵で暗号化します。Cloud EKM は、ラップされた鍵を Cloud KMS に返します。
Cloud KMS は、ラップされたカスタマー鍵を KMS マスター鍵で暗号化し、保存のために KMS データストアに送信します。
Cloud KMS は、鍵バージョンの完全な URI を含む成功レスポンスをユーザーに送信します。

鍵のインポート

オンプレミスまたは EKM で作成した独自の鍵をクラウド環境にインポートできます。たとえば、クラウドデータの暗号化に使用する鍵が特定の方法または環境で生成されるという規制要件があるとします。鍵のインポートでは、これらの鍵をインポートして、これらの規制上の義務を果たすことができます。署名機能をクラウドに拡張する場合は、非対称鍵をインポートすることもできます。

鍵をインポートする過程で、Cloud KMS はサポートされているインポート方法のいずれかを使用して公開鍵/秘密鍵のペアであるラッピング鍵を生成します。このラッピング鍵で鍵マテリアルを暗号化することで、転送中の鍵マテリアルが保護されます。

公開ラッピング鍵を使用して、クライアントにインポートする鍵を暗号化します。公開鍵と一致する秘密鍵は Google Cloud内に保存され、Google Cloud プロジェクトに到達した後に公開鍵をラップ解除するために使用されます。選択したインポート方法によって、ラッピング鍵の作成に使用されるアルゴリズムが決まります。ラップされた鍵マテリアルは、Cloud KMS の新しい鍵または鍵バージョンにインポートできます。

インポートした鍵は、HSM または SOFTWARE の保護レベルで使用できます。Cloud HSM の場合、ラッピング鍵の秘密鍵の部分は Cloud HSM 内でのみ使用できます。Cloud HSM 外では秘密鍵を使用できないため、鍵マテリアルが Cloud HSM の外部でラップ解除されることはありません。

Cloud KMS リクエストのライフサイクル

このセクションでは、鍵マテリアルの破棄など、Cloud KMS リクエストのライフサイクルについて説明します。次の図は、us-east1 と us-west1 の Cloud KMS サービスインスタンスへのアクセスをリクエストするクライアントと、Google Front End（GFE）を使用してリクエストをルーティングする方法を示しています。

KMS リクエストのライフサイクル図

このライフサイクルのステップは次のとおりです。

組織内の人員または組織に代わって実行されるジョブが、Cloud KMS サービス https://cloudkms.googleapis.com へのリクエストを作成します。DNS はこのアドレスを GFE のエニーキャスト IP アドレスに解決します。
GFE は、パブリック DNS 名のパブリック IP ホスティング、サービス拒否攻撃（DoS）に対する防御、TLS 終端を提供します。リクエストを送信すると、通常はそのリクエストの宛先の場所に関係なく、お客様に近い GFE にルーティングされます。GFE は TLS ネゴシエーションを処理し、リクエスト URL とパラメータを使用して、リクエストをルーティングする Global Software Load Balancer（GSLB）を決定します。
Cloud KMS リージョンごとに個別の GSLB ターゲットがあります。リクエストが us-east1 の GFE に到着し、リクエストの宛先が us-west1 の場合、リクエストは us-east1 と us-west1 のデータセンター間でルーティングされます。データセンター間のすべての通信は、ALTS を使用して転送中に暗号化され、GFE と Cloud KMS のジョブが相互に認証されます。
リクエストが Cloud KMS ジョブに到達すると、まず、すべてのGoogle Cloud サービスに共通する処理の大部分を行うフレームワークによって処理されます。このフレームワークはアカウントを認証し、次のことを確認するためにいくつかのチェックを行います。
- アカウントに有効な認証情報があり、認証を受けることができる。
- プロジェクトで Cloud KMS API が有効になっていて、有効な請求先アカウントがある。
- リクエストを実行するのに十分な割り当てがある。
- アカウントが、関連するGoogle Cloud リージョンの使用を許可するリストに登録されている。
- リクエストが VPC Service Controls によって拒否されない。
これらのチェックに合格すると、フレームワークはリクエストと認証情報を Cloud KMS に転送します。Cloud KMS は、リクエストを解析してアクセスされているリソースを特定し、IAM で呼び出し元にリクエストを行う権限があるかどうかを確認します。IAM は、リクエストの発生を監査ログに書き込む必要があるかどうかについても指示します。Key Access Justifications が有効になっている場合は、承認が必要な理由通知が送信されます。
リクエストが認証され、承認されると、Cloud KMS はリージョン内のデータストアバックエンドを呼び出して、リクエストされたリソースを取得します。リソースがフェッチされた後、鍵マテリアルが復号され、使用できるようになります。
その後、鍵マテリアルを使用して、Cloud KMS は暗号オペレーションを実行し、ラップされた鍵のバージョンを、鍵の保護レベルに応じて Cloud KMS ソフトウェアバックエンド、Cloud HSM バックエンド、Cloud EKM バックエンドのいずれかに転送します。
暗号オペレーションが完了すると、リクエストと同じ種類の GFE-to-KMS チャネルとともにお客様にレスポンスが返されます。
レスポンスが返されると、Cloud KMS は次のイベントを非同期でトリガーします。
- 監査ログとリクエストログが書き込まれ、キューに配置されます。
- 請求や割り当て管理を目的としてレポートが送信されます。
- リクエストがリソースのメタデータを更新した場合、その変更はバッチジョブの更新を通じて Cloud Asset Inventory に送信されます。

エンドツーエンドのデータの整合性

Cloud KMS では、鍵と鍵マテリアルのチェックサムを計算し、破損がないことを確認できます。これらのチェックサムは、ハードウェアの障害やソフトウェアの破損によって引き起こされる可能性があるデータ損失から保護するのに役立ちます。ヘルパーライブラリを使用すると、キーの整合性を検証できます。ヘルパーライブラリを使用してキーの整合性を検証するには、サーバーによって検証される Cloud KMS にチェックサムを提供します。また、これらのライブラリを使用すると、チェックサムを受け取って、クライアントのレスポンスデータを確認できます。

エンドツーエンドのデータの整合性は、次のような脅威から環境を保護するのに役立ちます。

転送中の破損。たとえば、データが送信されてから TLS で保護されるまでの間のスタックの破損。
エンドポイントと KMS の間の中間プロキシの問題（受信リクエストなど）。
Cloud KMS アーキテクチャでの暗号オペレーションの不具合、マシンメモリの破損や HSM の破損。
外部 EKM との通信中の破損。

詳細については、エンドツーエンドのデータの完全性の検証をご覧ください。

鍵マテリアルの破棄

鍵マテリアルは顧客データとみなされるため、Cloud KMS にも Google Cloudでのデータの削除で説明されているアプローチが適用されます。破棄のスケジュール期間が終了し、バックアップの有効期限が切れると、鍵マテリアルはリクエストによって破棄されます。（破棄のスケジュール期間が終了した後の）バックアップにまだ存在する鍵マテリアルは、リージョンの障害復旧にのみ使用できます。個々の鍵の復元には使用できません。Cloud KMS コントロール外に存在する、インポートされた鍵のコピーについては、このプロセスが保証されません。

デフォルトでは、Cloud KMS の鍵は破棄がスケジュールされている（削除（復元可能））状態で 30 日が経過した後、鍵マテリアルがシステムから論理的に削除されます。この期間は変更できます。詳細については、破棄のスケジュール期間をご覧ください。

鍵マテリアルは破棄されますが、鍵とキーリングは削除できません。鍵バージョンも削除できませんが、鍵バージョンマテリアルを破棄することによって、リソースは使用できなくなります。キーリングと鍵には、請求可能な費用や割り当ての上限がないため、これらが存在し続けても費用や本番環境の上限には影響しません。

鍵バージョンの破棄がスケジュールされると、鍵バージョンは暗号オペレーションで使用できなくなります。削除保留期間中、鍵バージョンを復元して破棄されないようにすることができます。

インポートした鍵を誤って削除した場合は、再インポートできます。詳細については、破棄された鍵の再インポートをご覧ください。

鍵を誤って削除しないように、次のベストプラクティスを検討してください。

鍵ごとの破棄スケジュール期間の最短期間の制約を長い期間に設定します。この制約は、新しい鍵の破棄の予定期間の最小時間を定義します。
鍵の破棄を無効な鍵に制限する制約を適用して、無効な鍵のみを破棄できるようにします。詳細については、破棄の前に鍵の無効化を要求するをご覧ください。
cloudkms.cryptoKeyVersions.destroy 権限を含まないカスタムの KMS ロールを作成します。
destroy_scheduled_duration フィールドをより長い期間に変更します。
鍵破棄イベントをモニタリングしてアラートを追加します。たとえば、次の Cloud Logging フィルタを作成します。
```
  resource.type="cloudkms_cryptokeyversion"
  protoPayload.methodName="DestroyCryptoKeyVersion"
```
鍵が削除されるまでの数日間に、鍵を無効にするプロセスを作成します。

Google インフラストラクチャの依存関係

Cloud KMS のプラットフォーム要素は、本番環境の Borg ジョブとして実行されます。Borg は、API サービス処理ジョブとバッチジョブを処理するための Google の大規模クラスタマネージャーです。

物理インフラストラクチャと本番環境インフラストラクチャのセキュリティについては、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

Cloud KMS API サービングジョブ

Cloud KMS API サービングジョブは、鍵の管理と使用というお客様のリクエストを処理する本番環境 Borg ジョブです。Cloud KMS API サービングジョブでは、スケジュールに基づく鍵のローテーション、非対称鍵の作成、鍵のインポートなど、顧客リクエストからの遅延アクションも処理します。これらのサービス処理ジョブは、Cloud KMS が利用可能なすべてのGoogle Cloud リージョンで実行されます。各ジョブは単一のリージョンに関連付けられ、関連付けられたGoogle Cloud リージョン内に地理的に配置されたシステムのデータにのみアクセスするように構成されます。

Cloud KMS バッチジョブ

Cloud KMS プラットフォームでは、さまざまなスケジュールで本番環境の Borg ジョブとして実行される多数のバッチジョブも保持されます。バッチジョブはリージョン固有で、関連する Google Cloudリージョンのデータのみを集計し、そのリージョン内でのみ実行されます。これらのジョブが実行するタスクは次のとおりです。

お客様への課金対象となるアクティブな鍵をカウントする。
Cloud KMS の公開プロトコルバッファ API からリソースを集約し、メタデータを Cloud Asset Inventory に転送する。このコンテキストのリソースとは、Cloud KMS が管理するあらゆるリソース（鍵やキーリングなど）のことです。
ビジネス分析のすべてのリソースとレポート情報を集約する。
高可用性を確保するため、データのスナップショットを作成する。
基になるデータストアに保存されているすべてのデータが破損していないか検証する。
KMS マスター鍵がローテーションされたときに、顧客鍵マテリアルを再暗号化する。

Cloud KMS 鍵のスナップショット

高可用性を維持するために、Cloud KMS プラットフォームは、共有サービスの各インスタンスで冗長データストアを維持し、Cloud KMS API サーバータスクをホストします。各共有サービスは、スナップショットサービスの独自のインスタンスをデプロイします。この冗長性により、サービスの独立性が高まり、あるゾーンでの障害が他のゾーンに与える影響が制限されます。Cloud KMS API ジョブは、暗号オペレーションを実行する必要がある場合、ローカルスナップショットジョブと並行してプライマリデータストアに対してクエリを実行します。プライマリデータストアが低速であるか利用できない場合、スナップショットが作成後 2 時間以内のものであれば、スナップショットからレスポンスが提供されることがあります。スナップショットは、各リージョンで継続的に実行されるバッチジョブの出力として作成されます。スナップショットは、鍵マテリアルに関連付けられているクラウドリージョンにあります。

クライアントサーバー通信

Google は、Application Layer Transport Security（ALTS）を使用して、Google のリモートプロシージャコール（RPC）メカニズムを使用するクライアントサーバー通信を保護します。

詳細については、サービス間の認証、完全性、暗号化をご覧ください。

Cloud KMS プラットフォームの運用環境

Cloud KMS プラットフォームの運用環境には、鍵マテリアルを保護しながら信頼性、耐久性、可用性を最適化するように設計されたデータストレージとセキュリティポリシー、アクセス制限、リスク軽減戦略があります。このセクションでは、サービスの運用構造、運用チームメンバーの責任、認証メカニズム、監査とロギングのプロトコルについて説明します。このセクションは、ソフトウェア保護とハードウェア保護の両方の鍵機能に適用されます。

ソフトウェアエンジニア、サイト信頼性エンジニア、システムオペレータ

ソフトウェアエンジニアは、プロダクトマネージャーやサイト信頼性エンジニア（SRE）などの他の関係者と連携してシステムを設計し、Cloud KMS サービスのコード作成とテストの大部分を担当します。このコードには、お客様のリクエストに対応するメインのジョブと、データレプリケーションや課金などのアクティビティの付随的なジョブが含まれます。SRE がコードを記述することもあります。ただし、ソフトウェアエンジニアと SRE の職務は分離されています。SRE は主に、Cloud KMS ジョブの本番環境のメンテナンスを担当します。SRE は、エンジニアリングと運用の作業を通じて信頼性を測定し、達成します。

システムオペレータは、Cloud KMS のビルドとリリースのプロセス、モニタリング、アラート、容量計画を担当します。Cloud KMS のお客様の問題と停止に最初に対応します。たとえば、システムオペレータはツールや自動化を活用して手作業を最小限に抑えることで、長期的な価値をもたらす取り組みに注力できます。

システムオペレータの義務は、標準的な運用手順で定義されます。システムオペレータは、職務を遂行する際にお客様の鍵マテリアルにアクセスしません。

Cloud KMS リソースのリージョン

鍵所在地の要件を満たすため、次の Google Cloud ロケーションタイプのいずれかに Cloud KMS リソースを作成できます。

リージョンロケーション。アイオワなど、特定の地域内のゾーンで構成されます。
デュアルリージョンロケーション。アイオワとサウスカロライナなど、2 つの特定の地域内のゾーンで構成されます。
マルチリージョンロケーション。米国などの地理的なエリアに分散するゾーンで構成されます。
グローバルロケーション。世界中に広がるゾーンで構成されます。Cloud KMS リソースをグローバルロケーションに作成すると、世界中のゾーンから使用できるようになります。

ロケーションとは、特定のリソースに関する Cloud KMS へのリクエストが処理される地域、および対応する暗号鍵が格納される地域を表します。

Cloud KMS に使用可能なロケーションの詳細については、Cloud KMS のロケーションをご覧ください。

クラウドリージョンとデータセンター

Google Cloud リージョンには、特定のデータセンターまたはデータセンターのセットが含まれ、単一リージョン、デュアルリージョン、マルチリージョン、グローバルとして指定されます。 Google Cloud リージョンの詳細については、Google Cloud ロケーションをご覧ください。

各データセンターには、コンピューティング、ネットワーキング、データストレージ用のマシンのラックがあります。これらのマシンは Google の Borg インフラストラクチャを実行します。

Google のデータセンターには、厳しい物理的なセキュリティ要件があります。ユーザーデータを含む可能性のある物理的スペースでは、入室者を認証するため、入口にバッジリーダーと虹彩スキャナを設置する必要があります。ドアを開けたまま複数の人が入室することはできません。各自が個別に自身を認証する必要があります。これらのエリアに手荷物を持ち込むことはできません。ただし、明示的に許可されている透明なバッグは、セキュリティ担当者による検査を行った後に持ち込むことができます。データを送信または記録できる電子機器を持ち込みまたは持ち出しするには、特別な許可が必要です。

鍵の所在地

一部の業界では、暗号鍵を特定の場所に配置する必要があります。Cloud KMS には、データのロケーション規約があり、データ所在地が保証されています。Cloud KMS リソースのリージョンで紹介したように、Cloud KMS ではこれらの要件を満たすために 4 種類のリージョンのロケーションが用意されています。

単一リージョン、デュアルリージョン、マルチリージョンのロケーションの場合、Cloud KMS はそのロケーションでのみソフトウェア格納型およびハードウェア格納型の顧客鍵と鍵マテリアルを作成、保存、処理します。Cloud KMS が使用するストレージとデータ処理システムは、鍵マテリアルに関連付けられているGoogle Cloud リージョン内のリソースのみを使用するように構成されています。デュアルリージョンまたはマルチリージョンのロケーションで作成された鍵マテリアルは、選択したロケーションの境界を越えません。

グローバルリージョンの場合、特定のリージョンは保証されません。

Cloud KMS は、鍵のメタデータ、使用状況ログ、転送中の鍵マテリアルの常駐を保証しません。鍵のメタデータにはリソース名が含まれます。また、鍵のタイプ、鍵のサイズ、鍵の状態などの Cloud KMS リソースのプロパティに加え、Cloud IAM ポリシーおよびメタデータから派生したデータも含まれます。

CMEK を使用する場合、CMEK をサポートする他の Google Cloud プロダクトで選択したロケーションがカスタム、デュアルリージョン、マルチリージョンかに関係なく、次の Cloud KMS の地理的制限が鍵に適用されます。

特定のリージョン: 顧客管理の KMS 鍵のリージョンは、特定の Google Cloud サービスにおいて、その鍵で保護されるリソースのリージョンと必ず相関している必要があるため、単一リージョンの鍵とリソースの所在地制限に互換性があり、強制されることが保証されます。
デュアルリージョンまたはマルチリージョンのロケーションの場合: ユーザーは、鍵と Google Cloudリソースに Google 定義のマルチリージョンを選択し、所在地のコンプライアンスを保証できます。この地理的な所在地を確実にするには、他のプロダクトラインのリージョンが、選択した Cloud KMS リージョンのロケーションと一致するようにしてください。

次の表は、Cloud KMS の鍵マテリアルの所在地をまとめたものです。

リージョンタイプ	保存時、使用中
シングルリージョン	所在地
デュアルリージョンまたはマルチリージョン	デュアルまたはマルチリージョンを構成するリージョンに常駐。

リージョンモニタリング

Google の内部データモニタリングサービスは、鍵の所在地を積極的にモニタリングしています。Cloud KMS は、誤った構成を検出した場合、鍵マテリアルが構成されたリージョンの境界から離れた場合、鍵マテリアルが間違ったリージョンに保存された場合、鍵マテリアルが間違ったリージョンからアクセスされた場合に、SRE チームメンバーにアラートを送信します。

高可用性

Cloud KMS は、選択したリージョンに基づいて可用性要件を簡素化するのに役立ちます。ロケーションが詳細になるほど、ビルドの冗長性が高まります。可用性が高いアプリケーションでは、鍵の独自のレプリケーションシステムを構築するのではなく、マルチリージョンロケーションを使用してください。組み込みの冗長性機能とデータリージョンの指定の要件のバランスを取る必要があります。

認証と認可

Cloud KMS は、OAuth2、JWT、ALTS などのさまざまな認証メカニズムを受け入れます。メカニズムにかかわらず、Cloud KMS は提供された認証情報を解決してプリンシパル（認証され、リクエストを認可するエンティティ）を識別します。また、IAM を呼び出して、プリンシパルにリクエストの作成が認可されているかどうかと、監査ログが書き込まれているかどうかを確認します。

Cloud KMS は、サービス管理のさまざまな場面で、一般公開の Service Control API の内部バージョンを使用します。Cloud KMS ジョブがリクエストの処理を行う前に、まず Service Control API にチェックリクエストを送信します。これにより、すべての Google Cloud サービスに共通の次のような制御が適用されます。

Cloud KMS API が有効で、有効な請求先アカウントがあるかどうかを確認する。
割り当てを超過していないかどうかを確認し、割り当て使用量を報告する。
VPC Service Controls を適用する。
該当するプライベートクラウドリージョンの許可リストを使用しているかどうかを確認する。

割り当て管理

Cloud KMS では、サービスに対するリクエストに対して、割り当てという使用量上限があります。Cloud KMS には、次の割り当てが含まれています。

暗号化、復号、署名などのオペレーションに対する暗号リクエストの割り当て。
鍵メタデータや IAM ポリシーの取得などのオペレーションに対する読み取りリクエストの割り当て。
鍵の作成や IAM ポリシーの設定などのオペレーションに対する書き込みリクエストの割り当て。

これらの割り当ては、呼び出し元に関連付けられているプロジェクトに課金されます。これらの割り当てもグローバルで、すべてのリージョンとマルチリージョンで呼び出し元の KMS 使用量に適用されます。これらの割り当ては、すべての保護レベルで評価されます。

Cloud HSM と Cloud EKM には暗号オペレーション用の割り当てが追加で存在します。暗号リクエストの割り当てに加えて、これらの割り当てを満たす必要があります。鍵が存在するプロジェクトには Cloud HSM と Cloud EKM の割り当てが存在し、割り当てはロケーションごとに適用されます。

以下の例を考えてみましょう。

asia-northeast1 でソフトウェア鍵を使用して復号を呼び出すには、1 単位（グローバル）の暗号リクエストの割り当てが必要です。
us-central1 で HSM 鍵を作成するには、1 単位の書き込みリクエストの割り当てが必要です。HSM の割り当ては必要ありません。
europe で EKM 鍵を使用して暗号化を呼び出すには、europe で 1 単位（グローバル）の暗号リクエストの割り当てと、1 単位の外部 KMS リクエストの割り当てが必要です。

使用可能な割り当てのタイプの詳細については、Cloud KMS リソースの使用に関する割り当てをご覧ください。割り当て上限は、Cloud コンソールで確認できます。初期の割り当て上限は、ワークロードのニーズに応じて調整をリクエストできるソフト制限です。

ロギング

Cloud KMS に関連するログは、Cloud Audit Logs ログ、アクセスの透明性ログ、内部リクエストログの 3 種類です。

Cloud Audit Logs

Cloud KMS は、Cloud Audit Logs にアクティビティを記録します。これらのログは Cloud コンソールで確認できます。鍵の作成や破棄など、すべての管理アクティビティがこれらのログに記録されます。鍵を使用したデータの暗号化や復号など、鍵を使用するその他のすべてのアクションに対してロギングを有効にすることもできます。ログの保持期間とログを表示できるユーザーも制御できます。

アクセスの透明性ログ

対象のユーザーはアクセスの透明性ログを任意で有効にできます。このログは、Google 社員がGoogle Cloud 組織で行ったアクションのログを提供します。アクセスの透明性ログは、Cloud Audit Logs からのログとともに、誰がいつどこで何をしたかを調べるのに役立ちます。

アクセスの透明性ログを既存のセキュリティ情報およびイベント管理（SIEM）ツールに統合すると、対象となるアクションの監査を自動化できます。このログは、Cloud Audit Logs ログとともに Cloud コンソールで確認できます。

アクセスの透明性ログエントリに含まれる詳細は次のとおりです。

対象となるリソースとアクション。
アクションが行われた時刻。
アクションが行われた理由。理由の例としては、お客様が開始したサポート（ケース番号付き）、Google が開始したサポート、サードパーティのデータリクエスト、Google が開始した審査リクエストなどがあります。
データを操作している人物に関するデータ（Google スタッフがいる場所など）。

内部リクエストログ

リクエストログには、Cloud KMS プラットフォームに送信されたすべてのリクエストのレコードが保存されます。このレコードには、リクエストのタイプ（API メソッドやプロトコルなど）とアクセスされるリソース（リソース名、鍵アルゴリズム、鍵の保護レベルなど）に関する詳細が含まれます。これらのログには、お客様の平文、暗号テキスト、鍵マテリアルは保存されません。新しいタイプのデータをこれらのログに追加する前に、プライバシー調査を担当するチームが、記録されたデータの変更を承認する必要があります。

構成された有効期間（TTL）が経過すると、ログエントリは完全に削除されます。

オンコールローテーションの Cloud KMS SRE とエンジニアは、リクエストログにアクセスできます。人間によるログへのアクセス、および顧客データを返すアクセスには、有効かつ文書化されたビジネス上の正当な理由が必要です。いくつかの例外はありますが、人間によるアクセスはログに記録され、資格のあるお客様はアクセスの透明性ログでそのログを確認できます。

モニタリング

Cloud KMS は Cloud Monitoring と統合されています。この統合により、Cloud KMS の多くのオペレーションに対してモニタリング、ダッシュボードの構築、アラートの作成を行うことができます。たとえば、鍵の破棄がいつスケジュールされるかをモニタリングできます。また、暗号オペレーションが定義済みのしきい値を超えたときに、Cloud KMS 割り当てのモニタリングと調整を行うことができます。使用可能な Cloud KMS 指標の詳細については、Cloud KMS での Cloud Monitoring の使用をご覧ください。

さらに、Security Command Center には KMS 脆弱性検出機能が組み込まれています。これらの検出機能を使用することで、鍵を含むプロジェクトで推奨のベストプラクティスを実施できるようになります。KMS 脆弱性検出機能の詳細については、Cloud KMS の脆弱性の検出をご覧ください。

次のステップ

Cloud KMS の詳細については、次のリソースをご覧ください。
- Cloud KMS のドキュメント
- Cloud HSM のドキュメント
Google Cloudで独自の暗号鍵を使用する方法については、顧客管理の暗号鍵（CMEK）をご覧ください。
Google インフラストラクチャのセキュリティの詳細を確認する。Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

Cloud Key Management Service の暗号化 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。