Cloud Key Management Service の詳細

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

Google Cloud は、お客様がご自分のデータに責任を持ち、その使用状況を管理していることを前提としています。

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

次の表に、Google Cloud 鍵の種類を示します。

鍵の種類	鍵管理	鍵の共有	自動ローテーション	料金
デフォルトの暗号鍵	これらの鍵は Google のみが管理します。	複数のお客様のデータが同じ鍵暗号鍵（KEK）を使用することがあります。	あり。デフォルトの保存データの暗号化をご覧ください。	無料。
Cloud KMS 鍵	これらの鍵はお客様が管理します。	お客様に固有のものです。	対称暗号化の場合は、あり。非対称鍵の場合は、なし。鍵のローテーションをご覧ください。	Cloud Key Management Service の料金をご覧ください。

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

Cloud KMS の設計上の特性

Google では、Cloud KMS を使用して、スケーラビリティ、信頼性、パフォーマンスに優れ、幅広い制御オプションを備えたソリューションの提供に重点を置いています。Cloud KMS には、次の 5 つの設計上の特性があります。

お客様による管理: 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 プラットフォームでは、中央のクラウドサービスで直接使用する暗号鍵を管理したり、他のクラウドリソースやアプリケーションで使用する暗号鍵を管理できます。

次の図に、Google が管理する鍵マテリアルからお客様が管理する鍵マテリアルまでの、鍵に関する Google Cloud ポートフォリオを示します。

鍵に関する Google Cloud ポートフォリオ。

上の図に示されているオプションは次のとおりです。

デフォルトの暗号化: Google で保存されるすべてのデータは、Advanced Encryption Standard（AES）アルゴリズムである AES-256 を使用してストレージレイヤで暗号化されます。デフォルトの暗号化に使用する鍵は Google が生成して管理します。お客様に鍵に対するアクセス権はありません。また、鍵のローテーションと管理を行う権限もありません。デフォルトの暗号鍵はお客様の間で共有される場合があります。詳細については、デフォルトの保存データの暗号化をご覧ください。
Cloud KMS とソフトウェアで生成された鍵: Cloud KMS を使用すると、Google によって生成された鍵を制御できます。Cloud KMS ソフトウェアバックエンドにより、管理する対称鍵または非対称鍵のいずれかを使用してデータの暗号化や署名を柔軟に行うことができます。
Cloud KMS とハードウェアで生成された鍵（Cloud HSM）: Cloud HSM バックエンドと Cloud KMS を使用すると、Google が所有および運用するハードウェアセキュリティモジュール（HSM）によって生成され、保存される鍵を所有できます。ハードウェアで保護された鍵が必要な場合は、Cloud HSM バックエンドを使用することで、FIPS 140-2 レベル 3 認定済みの HSM でのみ対称鍵と非対称鍵が使用されるようにすることができます。
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 での暗号化のコンセプトと鍵管理

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

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

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

鍵グループ化の図。

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

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

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

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

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

ソフトウェア鍵の階層

次の図は、Cloud KMS と Google の内部キーストアの鍵階層を示しています。Cloud KMS は、Google の内部鍵管理サービスであるキーストアを使用して、Cloud KMS で暗号化された鍵をラップします。鍵のラッピングは、鍵を安全に保管する場合や、信頼できないチャネルで送信する場合に、鍵を別の鍵で暗号化する処理です。Cloud KMS は、キーストアと同じルートオブトラストを使用します。

内部鍵階層の図。

上の図に示す鍵の階層は次のとおりです。

データ暗号鍵（DEK）はデータチャンクを暗号化します。
鍵暗号鍵（KEK）は、DEK を暗号化またはラップするために使用されます。すべての Cloud KMS プラットフォームオプション（ソフトウェア、ハードウェア、外部バックエンド）を使用して、KEK を制御できます。KEK は Cloud KMS に保存されます。
KMS マスター鍵は KEK を暗号化します。KMS マスター鍵はキーストアに保存されます。キーストアには、Cloud KMS のロケーションごとに個別の KMS マスター鍵があります。Cloud KMS の KEK は、ロケーションの KMS マスター鍵によって保護されます。各 Cloud KMS サーバーは起動時に KMS マスター鍵のコピーをハード依存関係として取得します。KMS マスター鍵の新しいコピーは毎日取得されます。KMS マスター鍵は定期的に再暗号化されます。
KMS マスター鍵は、キーストアのキーストアマスター鍵によって保護されます。
キーストアマスター鍵はルートキーストアマスター鍵で保護されています。

キーストアの詳細については、保存データの暗号化の鍵管理をご覧ください。

鍵の運用上の制約

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

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

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 では、ソフトウェ鍵、ハードウェア鍵、外部鍵を使用できます。ソフトウェアベースとハードウェアベースのどちらの鍵も、Google の冗長なバックアップ保護を使用します。
ハードウェア鍵を使用する場合、Google Cloud の FIPS 140-2 レベル 3 認定済み HSM では鍵が保存されます。Google の認定について詳しくは、証明書 #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 を遵守しています。

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 では、鍵マテリアルは保存時も転送時も常に暗号化されます。鍵マテリアルが復号されるのは、次の場合に限られます。

お客様が使用している場合。
お客様の鍵マテリアルを保護するために使用される 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 保護レベル

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

アルゴリズムによる実装

ソフトウェア鍵の場合、Cloud KMS は関連するすべての暗号オペレーションに Google の BoringSSL 実装内の BoringCrypto モジュール（BCM）を使用します。BCM は 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 のお客様はアプリケーションを変更する必要はありません。Cloud KMS と同じ API とクライアントライブラリを使用して Cloud HSM バックエンドにアクセスできます。Cloud HSM バックエンドの詳細については、Cloud HSM アーキテクチャをご覧ください。

Cloud EKM: EXTERNAL 保護レベル

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

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

鍵のインポート

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

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

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

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

顧客管理の暗号鍵（CMEK）

デフォルトで、Google Cloud は保存されているすべての顧客データを暗号化し、暗号化に使用される鍵は Google が管理します。一部の Google Cloud プロダクトでは、Cloud KMS を使用して、暗号化に使用する鍵を管理できます。CMEK は、外部格納型鍵、ソフトウェア格納型鍵、ハードウェア格納型鍵に使用できます。Cloud KMS ではユーザーが、鍵の作成、有効化、無効化、ローテーション、破棄など、鍵の多くの側面を制御し、鍵に対する適切な IAM 権限を管理できます。推奨される職掌分散を適用するため、Cloud KMS には特定の権限と制限があり、特定のユーザーとサービスアカウントに付与できる IAM 事前定義ロールがいくつか用意されています。

Cloud KMS 鍵をローテーションしても、関連する CMEK サービスでデータの再暗号化は行われません。代わりに、新しく作成されたリソースは新しい鍵バージョンを使用して暗号化されます。つまり、異なるバージョンの鍵で、異なるデータのサブセットが保護されます。たとえば、テーブルに関連付けられている Cloud KMS 鍵のローテーションが行われても、BigQuery がそのテーブルの暗号鍵のローテーションを自動的に行うことはありません。既存の BigQuery テーブルでは引き続き、作成時に使用された鍵バージョンが使用されます。新しい BigQuery テーブルでは現在の鍵バージョンが使用されます。詳細については、各プロダクトのドキュメントをご覧ください。

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

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

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 で受信され、リクエストの宛先が 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 は、リクエストの発生を監査ログに書き込む必要があるかどうかについても Cloud KMS に指示します。
リクエストが認証され、承認されると、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 の鍵は破棄がスケジュールされている（削除（復元可能））状態で 24 時間経過した後、鍵マテリアルがシステムから論理的に削除されます。この期間は変更できます。詳細については、破棄のスケジュール期間をご覧ください。

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

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

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

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

cloudkms.cryptoKeyVersions.destroy 権限を含まないカスタムの KMS ロールを作成します。
destroy_scheduled_duration フィールドをより長い期間に変更します。
鍵破棄イベントをモニタリングしてアラートを追加します。たとえば、次の Cloud Logging フィルタを作成します。
```
  resource.type="cloudkms_cryptokeyversion"
  protoPayload.methodName="DestroyCryptoKeyVersion"
```
鍵が削除されるまでの数日間に、鍵を無効にするプロセスを作成します。

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 インフラストラクチャのセキュリティの詳細を確認する。Google インフラストラクチャのセキュリティ設計の概要をご覧ください。
Google Cloud セキュリティの一般的な情報については、Google Cloud ウェブサイトのセキュリティをご覧ください。