Cloud Key Management Service の詳細

作成者: Sonal Shah、Il-Sung Lee、Walter Poupore、Hunter Freyer、Honna Segel、Dwight Worley

謝辞: Adrian Sears、John Randolph、Tim Dierks、Chris Rezek、Stanley McKenzie、Kevin Plybon、David Hale、Sergey Simakov、David U. Lee、Carrie McDaniel、Anton Chuvakin、Dave Tonisson

最終更新: 2020 年 4 月

1. はじめに

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

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

Cloud KMS プラットフォームを使用すると、Google Cloud のお客様は暗号鍵を 1 つの中央クラウド サービスで管理でき、直接または他のクラウド リソースおよびアプリケーションから暗号鍵を使用できるようになります。鍵のソースとして、Cloud KMS には次のオプションが用意されています。

  • Cloud KMS ソフトウェア バックエンドを使用すると、制御可能な対称鍵または非対称鍵のいずれかを使って柔軟にデータを暗号化できます(Cloud KMS)。
  • ハードウェア キーが必要な場合は、Cloud HSM を使って、対称鍵と非対称鍵が FIPS 140-2 レベル 3 認証済みのハードウェア セキュリティ モジュール(HSM)でのみ使用されるようにできます。
  • ご自分で生成した鍵を使用する必要がある場合、Cloud KMS では独自の暗号鍵をインポートできます。
  • Cloud KMS によって生成された鍵を他の Google Cloud サービスで使用することもできます。この鍵は、顧客管理の暗号鍵CMEK)と呼ばれます。CMEK 機能を使用すると、他の Google Cloud サービスのデータを保護するために使用される暗号鍵を生成、使用、ローテーション、破棄できます。
  • Cloud External Key Manager(Cloud EKM)を使用すると、Google Cloud 外の鍵マネージャーで鍵を作成して管理できます。さらに、Cloud KMS プラットフォームにより、外部鍵を使用して保存データを保護できます。顧客管理の暗号鍵と Cloud EKM 鍵は併用できます。現時点で、Cloud EKM はこのホワイトペーパーの対象外です。

Google では、Compute Engine と Cloud Storage で顧客指定の暗号鍵(CSEK)もサポートしています。この機能では、データの暗号化と復号に API 呼び出しで提供される鍵が使用されます。CSEK はこのドキュメントの対象外です。詳細については、オンライン ドキュメントをご覧ください。

「KMS ポートフォリオの図」

Cloud KMS により、Google は、幅広いオプションを備えた、スケーラビリティと信頼性が高くパフォーマンスに優れたソリューションを使いやすいプラットフォームで提供できます。Cloud KMS には、その設計上、次の 5 つの特性があります。

  • お客様による管理。Cloud KMS では、ソフトウェアとハードウェアの暗号鍵の管理や、独自の鍵の指定ができます。
  • アクセス制御とモニタリング。Cloud KMS では、個々の鍵の権限を管理し、鍵の使用状況をモニタリングできます。
  • リージョン。Cloud KMS では、すぐにリージョン指定を行えます。このサービスは、選択した Google Cloud リージョンでのみソフトウェア鍵を作成、保存、処理するように構成されています。
  • 耐久性。Cloud KMS は、Google Cloud で最も高い耐久性基準を満たしています。データの破損を防止し、データを正常に復号できるようにするため、Cloud KMS はすべての鍵マテリアルとメタデータを定期的にスキャンしてバックアップします。
  • セキュリティ。Cloud KMS は不正アクセスから鍵を強力に保護し、Identity and Access Management(IAM)および Cloud Audit Logs の制御と完全に統合されています。

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

2. Google での暗号化のコンセプトと鍵管理

このセクションでは、Google のマルチレイヤの鍵管理インフラストラクチャのコンテキストにおける鍵管理のいくつかの用語と定義を定義します。

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

このセクションでは、鍵、鍵バージョン、鍵のキーリングへのグループ化について説明します。次の図に、鍵のグループ化を示します。図の後に関連用語の定義を説明します。

「鍵グループ化の図」

  • 鍵: 特定の目的に使用される暗号鍵を表す名前付きのオブジェクト。マテリアル(暗号オペレーションに使用される実際のビット)は、新しい鍵バージョンを作成するたびに随時変更されます。

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

    Cloud KMS は、非対称鍵と対称鍵の両方をサポートしています。対称鍵は、一部のデータコーパスを保護するために対称暗号化に使用されます。たとえば、GCM モードで AES-256 を使用して平文ブロックを暗号化します。非対称鍵は、非対称暗号化やデジタル署名の作成に使用できます。サポートされる用途とアルゴリズムについては、Cloud KMS のドキュメントをご覧ください。

  • キーリング: 鍵を整理するための鍵のグループ。キーリングは Google Cloud プロジェクトに属し、特定の場所に格納されます。鍵は格納されているキーリングから IAM ポリシーを継承します。関連する権限を持つ鍵をキーリングにグループ化すると、個別に鍵を操作することなく、キーリング レベルでこれらの鍵に対する権限の付与、取り消し、変更を行うことができます。キーリングは利便性と分類を提供するものですが、キーリングのグループ化が役立たない場合は、鍵で権限を直接管理できます。

    リソース名の競合を防ぐため、キーリングは削除できません。キーリングと鍵には請求可能な費用や割り当ての上限がないため、これらが存在し続けても費用や本番環境の上限に影響することはありません。鍵と鍵マテリアルの破棄について詳しくは、このドキュメントの後半の破棄に関するセクションをご覧ください。

  • 鍵のメタデータ: リソース名、KMS リソースのプロパティ(IAM ポリシー、鍵のタイプ、鍵のサイズ、鍵の状態、およびそれらから派生したデータ)。鍵メタデータは、鍵マテリアルとは異なる方法で管理できます。

  • 鍵バージョン: ある時点で鍵に関連付けられた鍵マテリアルを表します。鍵バージョンは、実際の鍵マテリアルを含むリソースです。バージョンにはバージョン 1 から順に番号が振られます。鍵をローテーションすると、新しい鍵バージョンが新しい鍵マテリアルで作成されます。同じ論理鍵が時間の経過とともに複数のバージョンを持つことがあるため、1 つのバージョンの使用が制限されます。対称鍵には常にメインのバージョンがあります。このバージョンは、デフォルトで暗号化に使用されます。Cloud KMS は、対称鍵を使用して復号を実行するときに、復号に必要な鍵バージョンを自動的に識別します。

2.2. 鍵の階層

次の図は、Google の内部鍵管理サービスの鍵の階層を示しています。Cloud KMS では、Cloud KMS で暗号化された鍵が Google KMS によって Google の内部 KMS にラップされます。Cloud KMS は、Google KMS と同じルート オブ トラストを使用します。図の後に関連用語の定義を説明します。

「内部鍵階層の図」

  • データ暗号鍵(DEK): データの暗号化に使用する鍵。
  • 鍵暗号鍵(KEK): データ暗号鍵の暗号化またはラップに使用する鍵。鍵暗号鍵は、Cloud KMS プラットフォームのオプション(ソフトウェア、ハードウェア、外部バックエンド)を使って制御します。
  • KMS マスター鍵: 鍵暗号鍵(KEK)の暗号化に使用する鍵。この鍵はメモリ内で配布されます。KMS マスター鍵はハードウェア デバイスにバックアップされます。この鍵は、使用する鍵の暗号化を管理します。
  • ルート KMS: Google の内部鍵管理サービス。

2.3. 運用

  • プロジェクト: 他のすべての Google Cloud リソースと同様に、Cloud KMS リソースは Google Cloud プロジェクトに属します。Cloud KMS 鍵が存在するプロジェクト以外のプロジェクトでは、データをホストできます。この機能は、鍵管理者とデータ管理者の職務の分離に関するベスト プラクティスに対応しています。
  • ロケーション: プロジェクト内では、Cloud KMS リソースはロケーションに作成されます。詳細については、地域とリージョンをご覧ください。

3. Cloud KMS プラットフォームの概要

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

「Cloud KMS のアーキテクチャ図」

上の図は、Cloud KMS プラットフォームの主なコンポーネントを示しています。管理者は、Google Cloud Console または gcloud コマンドライン ツールを使用するか、REST または gRPC API を実装するアプリケーションで、鍵管理サービスにアクセスします。アプリケーションは REST API または gRPC を使用して鍵管理サービスにアクセスします。アプリケーションでは、顧客管理の暗号鍵(CMEK)の使用が有効になっている Google サービスを使用できます。CMEK は Cloud KMS API を使用します。Cloud KMS API では、ソフトウェア(Cloud KMS)鍵またはハードウェア(Cloud HSM)鍵を使用できます。ソフトウェア ベースとハードウェア ベースの両方の鍵で、Google の冗長バックアップ保護が利用されます。

Cloud KMS プラットフォームでは、鍵の作成時に保護レベルを選択して、鍵を作成し、その鍵での今後すべての暗号オペレーションを実行する鍵のバックエンドを決定します。Cloud KMS プラットフォームでは、2 つのバックエンド(Cloud EKM を除く)が Cloud KMS API で SOFTWARE および HSM 保護レベルとして公開されます。保護レベル SOFTWARE は、暗号オペレーションを実行するためにソフトウェア セキュリティ モジュールによってラップ解除される鍵に適用されます。保護レベル HSM は、鍵ですべての暗号オペレーションを実行するハードウェア セキュリティ モジュールによってのみラップ解除できる鍵に適用されます。

Google Cloud は、Cloud Storage、BigQuery、Compute Engine などの複数のサービスで CMEK をサポートしています。CMEK では、Cloud KMS プラットフォームを使用して、これらのサービスによるデータの保護に使用される暗号鍵を管理できます。

Cloud KMS 暗号オペレーションは、FIPS 140-2 認証済みモジュールによって実行されます。保護レベルが SOFTWARE である鍵、およびそれらを使用して実行される暗号オペレーションは、FIPS 140-2 レベル 1 を遵守しています。保護レベルが HSM である鍵、およびそれらを使用して実行される暗号オペレーションは、FIPS 140-2 レベル 3 を遵守しています。

3.1. 環境と依存関係

このセクションでは、Cloud KMS プラットフォームが実行される Google インフラストラクチャと、インフラストラクチャで使用される通信プロトコルについて詳しく説明します。

3.1.1. Cloud KMS Borg ジョブ

Cloud KMS のプラットフォーム要素は、本番環境の Borg ジョブとして実行されます。Borg は、API サービス処理ジョブとバッチジョブを処理するための Google の大規模クラスタ マネージャーです。物理インフラストラクチャと本番環境インフラストラクチャのセキュリティの詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

3.1.1.1. Cloud KMS API サービス処理ジョブ

Cloud KMS API サービス処理ジョブは、鍵の管理と使用というお客様のリクエストを処理する本番環境 Borg ジョブです。これらのサービス処理ジョブは、Cloud KMS が利用可能なすべての Google Cloud リージョンで実行されます。各ジョブは単一のリージョンに関連付けられ、関連付けられた Google Cloud リージョン内に地理的に配置されたシステムのデータにのみアクセスするように構成されます。鍵の所在地について詳しくは、この記事の後半のリージョンをご覧ください。

3.1.1.2. Cloud KMS バッチジョブ

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

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

高可用性を維持するために、Cloud KMS プラットフォームは、Cloud KMS API サーバータスクをホストする共有サービスの各インスタンスで冗長データストアを保持します。各サービスは、スナップショット サービスの独自のインスタンスをデプロイします。この冗長性により、サービスの独立性が高まり、あるゾーンでの障害が他のゾーンに与える影響が制限されます。Cloud KMS API ジョブは、暗号オペレーションを実行する必要がある場合、ローカル スナップショット ジョブと並行してプライマリ データストアに対してクエリを実行します。その後、Cloud KMS API は最初にリクエストを正常に完了したジョブを使用します。スナップショット パイプラインの遅延が原因で過度に古いデータが提供されるのを防ぐため、API サーバーは 2 時間以上前のスナップショット ジョブの結果を使用しません。スナップショットは、各リージョンで継続的に実行されるバッチジョブの出力として作成されます。スナップショットは、鍵マテリアルに関連付けられているクラウド リージョンにあります。

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

Google は、Application Layer Transport Security(ALTS)を使用して、Google のリモート プロシージャ コール(RPC)メカニズムを使用するクライアント サーバー通信(転送中の暗号化)のセキュリティを保護します。ALTS は以下を提供します。

  • アプリケーション用のピアツーピア認証プロトコル
  • レコード暗号化プロトコル
  • 認可用に認証済みユーザーを公開する API

ALTS handshake およびレコード暗号化プロトコルは、Transport Layer Security(TLS)の handshaking およびレコード プロトコルに似ています。ALTS には Google の本番環境用に最適化するためにいくつかのトレードオフがありますが、ALTS は本番環境ハードウェアおよびソフトウェア スタック全体に完全に統合されています。詳細については、後述の Cloud KMS プラットフォームの運用環境をご覧ください。

4. Cloud KMS プラットフォーム アーキテクチャの詳細

このセクションでは、アーキテクチャの詳細について説明します。まず、鍵マテリアルのセキュリティデータストアの保護について説明し、次に鍵マテリアルのソースのオプションについて詳しく取り上げます。

このセクションでは、顧客管理の暗号鍵(CMEK)のオプションについても説明します。

これまでに導入したアーキテクチャ構造がどのように使用されるかを動的に示すために、このドキュメントでは、鍵マテリアルの破棄を含む Cloud KMS リクエストのライフサイクルについても説明します。

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

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

  • お客様が使用している場合
  • 顧客鍵マテリアルの保護に使用する Google の内部鍵がローテーションされているか、整合性チェックが行われている場合。

Cloud KMS へのユーザー リクエストは、お客様と Google Front End(GFE)間の TLS を介した転送中に暗号化されます。クライアント サーバー通信のセクションで説明した Application Layer Transport Security(ALTS)は、異なるデータセンターの Cloud KMS ジョブとそのバックエンド間の暗号化に使用されます。ALTS と転送中の暗号化については、この後の Cloud KMS リクエストのライフサイクルで詳しく説明します。

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

Google のポリシーでは、検証可能な方法でビルド、テスト、レビューされたソースコードのみが使用されるようになっています。Binary Authorization for Borg(BAB)は、このポリシーを運用レベルで適用します。詳細については、こちらのセキュリティ ドキュメントをご覧ください。

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

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

4.2. データストアの保護

このセクションでは、Google KMS で鍵データを保護する方法について説明します。

4.2.1. マスター鍵

Cloud KMS はマスター鍵を使用して、すべての顧客鍵を保存します。各 Cloud KMS サーバーは起動時にマスター鍵のコピーをハード依存関係として取得します。マスター鍵の新しいコピーは毎日取得されます。マスター鍵は定期的に再暗号化されます。

4.2.2. ローテーション ポリシー

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

4.2.3. データ所在地

各 Cloud KMS データストアに保存されるデータは、データが関連付けられている Google Cloud リージョン内にのみ存在します。これは、us マルチリージョンなど、マルチリージョンのロケーションにも適用されます。データ所在地の詳細については、このドキュメントの後半のリージョンをご覧ください。

4.3. 作成後の鍵の可用性

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

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

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

4.4.1. アルゴリズムによる実装

ソフトウェア鍵の場合、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 の非対称暗号鍵を使った暗号化、復号、署名の操作も含まれています。

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

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

4.5. Cloud KMS HSM バックエンド: ハードウェアの保護レベル

Cloud HSM サービスは、Cloud KMS にハードウェア格納型鍵を提供します。お客様は、Google データセンターのフルマネージド ハードウェア セキュリティ モジュール(HSM)によって保護された暗号鍵を管理、使用できます。このサービスは可用性が高く、水平方向に自動スケーリングされます。鍵は、キーリングが定義された KMS リージョンに暗号的にバインドされます。Cloud HSM では、鍵の作成時に指定されたリージョンに属する HSM のクラスタ外で、作成および使用する鍵を実体化できません。Cloud HSM を使用すると、暗号鍵がハードウェア デバイス内でのみ作成され、使用されていることを証明できます。既存の Cloud KMS のお客様が Cloud HSM を使用する際、アプリケーションを変更する必要はありません。Cloud HSM サービスには、Cloud KMS ソフトウェア バックエンドと同じ API とクライアント ライブラリを使用してアクセスします。

Cloud HSM は、FIPS 140-2 レベル 3 検証済みで、常に FIPS モードで実行される HSM を使用します。FIPS 標準では、HSM で使用される暗号アルゴリズムと乱数生成が指定されています。

4.5.1. Cavium HSM

Cavium HSM PCIe カードはベンダーによって FIPS 140-2 レベル 3 を遵守していることが確認されています。現在の証明書はリクエストで入手できます。

4.5.2. HSM 鍵の階層

次の図の上部には Cloud KMS が示されています。Cloud HSM は顧客鍵をラップし、Cloud KMS は Google のデータストアに渡される HSM 鍵をラップします。

「HSM 鍵の階層図」

Cloud HSM には、Cloud HSM 管理ドメイン内部のマテリアルの移行を制御する鍵(非表示)があります。1 つのリージョンに複数の HSM 管理ドメインがある場合もあります。

HSM ルート鍵には 2 つの特性があります。

  1. HSM で生成され、その有効期間中 HSM の明確な境界から出ることはありません。他の HSM やバックアップ HSM で複製されることがあります。
  2. HSM が使用する顧客鍵を直接または間接的にラップするための鍵暗号鍵として使用できます。

HSM ルート鍵でラップされた顧客鍵は HSM で使用できますが、HSM が顧客鍵の平文を返すことはありません。HSM は、オペレーションに顧客鍵のみを使用します。

4.5.3. データストアの保護

HSM は鍵の永続ストレージとしては使用されません。HSM に保存されるのは、使用中の鍵に限られます。HSM ストレージは制限されているため、HSM 鍵は暗号化され、Cloud KMS 鍵データストアに保存されます。詳細については、このドキュメントの後半の データストア バックエンドで詳しく説明しています。

4.5.4. ローテーション ポリシー

Cloud HSM の鍵保護戦略には、複数タイプの鍵が使用されます。顧客鍵はお客様が自らローテーションし、HSM 鍵は Cloud KMS を使用してローテーションします。

4.5.5. プロビジョニングと処理のプロセス

HSM のプロビジョニングは、物理的および論理的セキュリティ対策を複数備えたラボで実施されます。たとえば、1 人の操作者による不適切な使用を防ぐためには複数の認証により制御します。

Cloud HSM のシステムレベルの不変条件は次のとおりです。

  1. 顧客鍵は平文として抽出できません。
  2. 顧客鍵を元のリージョンの外に移動することはできません。
  3. プロビジョニングされた HSM の構成変更はすべて、複数のセキュリティ対策によって保護されます。
  4. 管理オペレーションは、Cloud HSM 管理者とロギング管理者の間での職務分離に従って、ログに記録されます。
  5. HSM は、運用ライフサイクル全体を通じて改ざん(悪意のあるハードウェアやソフトウェアの変更、不正なシークレットの抽出など)から保護されるように設計されています。

4.5.6. ベンダーが管理するファームウェア

HSM ファームウェアは HSM ベンダーによってデジタル署名されています。Google は HSM ファームウェアを作成または更新できません。テストに使用する開発用ファームウェアを含む、ベンダーのすべてのファームウェアが署名されています。

4.5.7. リージョン

顧客鍵は、特定の HSM ルート鍵にバインドされた結果として、特定の地理的リージョンに割り当てられます。たとえば、us-west1 リージョンで作成された鍵を us-east1 リージョンや us マルチリージョンに移行することはできません。同様に、us マルチリージョンで作成された鍵は、us-west1 リージョンとの間で移行できません。

4.6. Cloud KMS: 鍵のインポート

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

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

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

インポートした鍵は、HSM または SOFTWARE保護レベルで使用できます。

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

4.7. 顧客管理の暗号鍵(CMEK)

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

次のトピックでは、CMEK をサポートする Cloud KMS プラットフォームに統合されたプロダクトについて説明します。

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

CMEK 統合サービスと CMEK 準拠サービスの一覧については、こちらのドキュメントをご覧ください。Google では、引き続き他の Google Cloud プロダクトの CMEK 統合に投資していきます。

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

このセクションでは、これまでに導入したアーキテクチャ構造がどのように使用されるかを動的に示すために、鍵マテリアルの破棄を含む Cloud KMS リクエストのライフサイクルについて説明します。

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

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

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

4.9. 鍵マテリアルの破棄

Google Cloud におけるデータの削除については、こちらのホワイトペーパーをご覧ください。鍵マテリアルは顧客データと見なされるため、ホワイトペーパーでの手法は Cloud KMS に適用されます。また、Google が Cloud KMS 外で鍵マテリアルを共有することは決してありません。そのため、鍵マテリアルの破棄がリクエストされると、24 時間の破棄保留後バックアップが期限切れになると、鍵マテリアルが破棄されます。Cloud KMS コントロール外に存在する、インポートされた鍵のコピーについては、このプロセスが保証されません。

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

破棄がスケジュールされると、鍵バージョンは暗号オペレーションに使用できなくなります。24 時間以内であれば、鍵バージョンを復元して破棄を防ぐことができます。

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

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

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

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

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

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

Cloud KMS リソースは、次の 4 種類の Google Cloud ロケーションのいずれかに作成できます。

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

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

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

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

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

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

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

5.2.2. リージョン

一部の業界では、暗号鍵を特定の場所に配置する必要があります。上記の 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 リソースに相関するマルチリージョンを選択し、データ所在地を保証できます。この地理的な所在地を確実にするには、他のプロダクト ラインのリージョンが、選択した Cloud KMS リージョンのロケーションと一致するようにしてください。

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

Cloud KMS のデータ所在地 保存時、使用時
(単一リージョン)
保存時、使用時
(デュアル / マルチリージョン)
ソフトウェア鍵マテリアル 常駐 デュアル / マルチリージョンを構成するリージョンに常駐。
ハードウェア鍵マテリアル(HSM) 常駐 デュアル / マルチリージョンを構成するリージョンに常駐。

5.2.3. リージョン モニタリング

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

5.3. 認証と認可

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

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

  • お客様が Cloud KMS API を有効にし、有効な請求先アカウントを持っているかどうかを確認する。
  • お客様が割り当てを超えていないかどうかを確認し、割り当ての使用状況を報告する。
  • VPC Service Controls を適用する。
  • 該当するプライベート クラウド リージョンの許可リストにお客様が登録されているかどうかを確認する。

5.4. ロギング

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

5.4.1. Cloud Audit Logs

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

5.4.2. アクセスの透明性ログ

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

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

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

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

5.4.3. 内部リクエストログ

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

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

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

5.5. データストア バックエンド

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

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

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

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

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

Cloud KMS チームには、緊急時にバックアップを復元する文書化された手順があります。

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

保護。Cloud KMS のアプリケーション レイヤでは、顧客鍵マテリアルは保存前に暗号化されます。データストア エンジニアは、平文の顧客鍵マテリアルにアクセスできません。また、データストアは永続ストレージに書き込む前に管理するすべてのデータを暗号化します。そのため、ディスクやデータなどの基盤となるストレージ レイヤへのアクセス権があっても、Google の社内 KMS に格納されるデータストア暗号鍵にアクセスしなければ、暗号化された Cloud KMS データにはアクセスできません。

6. 関連情報

詳細については、次のリソースをご覧ください。

ホワイトペーパー:

その他のドキュメント: