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 Tonisso 氏

最終更新: 2020 年 4 月

1. はじめに

Google Cloud は、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)の handshake およびレコード プロトコルに似ています。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 鍵データストアに保存されます。詳細については、このドキュメントの後半の Datastore バックエンドで詳しく説明しています。

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 のデータセンター間でルーティングされます。データセンター間のすべての通信は、ALS を使用して転送中に暗号化され、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 監査ログ

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. Datastore バックエンド

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

6 関連情報

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

ホワイトペーパー:

その他のドキュメント: