Cloud External Key Manager（Cloud EKM）で Cloud Key Management Service（Cloud KMS）を有効にすると、外部鍵管理パートナーで管理する鍵を使用して、Google Cloudのデータを保護できます。このドキュメントでは、Cloud KMS と Cloud EKM を使用して高可用性の外部鍵マネージャー（EKM）サービスをデプロイする Google Cloud のお客様向けのアーキテクチャについて説明します。
EKM サービスで Cloud EKM を使用すると、クラウド ワークロードの信頼性とデータ保護制御の間で明示的なリスクのトレードオフが発生します。クラウド内の保存データをオフクラウドの暗号鍵で暗号化すると、 Google Cloud サービスデータにアクセスできなくなる可能性があり、新しい障害リスクが生じます。これらのリスクに対処するには、高可用性とフォールト トレラントで Cloud EKM アーキテクチャを構築する必要があります。
概要
Cloud EKM を使用すると、 Google Cloud の外部にある鍵マテリアルを使用して、サポートされている Google Cloudサービスに保存されているデータへのアクセスを制御できます。Cloud EKM 鍵は顧客管理の暗号鍵（CMEK）です。Cloud EKM を使用すると、EXTERNAL 保護レベルと EXTERNAL_VPC 保護レベルを使用して Cloud KMS 鍵リソースを作成して管理できます。Cloud EKM を有効にすると、すべての暗号オペレーション リクエストで外部鍵に対する暗号オペレーションが実行されます。最初のリクエスト オペレーションの成功は、外部鍵に対する暗号オペレーションの結果に大きく依存します。
Cloud KMS は、外部鍵管理システムと統合された特殊な API を使用して、外部鍵のオペレーションをリクエストします。このドキュメントでは、この API を提供するサービスを EKM サービスと呼びます。
EKM サービスが使用できなくなると、統合された Google Cloud サービスのデータプレーンからの読み取りと書き込みが失敗する可能性があります。これらの障害は、依存する Cloud KMS 鍵が使用できない状態（無効になっている場合など）で発生する障害と同様の方法で表示されます。エラー メッセージには、エラーの原因と対処方法が示されます。さらに、Cloud KMS データアクセス監査ログには、これらのエラー メッセージの記録と、説明的なエラータイプが含まれます。詳細については、Cloud EKM エラーのリファレンスをご覧ください。
Cloud EKM アーキテクチャのベスト プラクティス
Google の サイト信頼性エンジニアリング ブックでは、信頼性の高いシステムの開発とメンテナンスに役立つベスト プラクティスについて説明しています。このセクションでは、EKM サービスが Google Cloudと統合される方法のコンテキストで、これらのプラクティスの一部について説明します。次のベスト プラクティスは、Cloud EKM リファレンス アーキテクチャに適用されます。
- 低レイテンシで信頼性の高いネットワーク接続を構成する
- 高可用性の有効化
- 障害を迅速に検出して軽減する
低レイテンシで信頼性の高いネットワーク接続を構成する
Cloud KMS は、Virtual Private Cloud（VPC）ネットワークまたはインターネットを使用して EKM サービスに接続します。VPC ソリューションでは、多くの場合、ハイブリッド接続を使用して、オンプレミスのデータセンターに EKM サービスをホストします。Google Cloud とデータセンター間の接続は、高速で信頼できる必要があります。インターネットを使用する場合は、安定した途切れのない到達性と、高速で信頼性の高い DNS 解決が必要です。 Google Cloudの観点から、中断が発生すると、EKM サービスが利用できなくなり、EKM で保護されたデータにアクセスできなくなる可能性があります。
Google Cloud サービスのデータプレーンが EKM サービスと通信する場合、各 EKM サービスにバインドされた呼び出しには、定義されたタイムアウト期間（150 ミリ秒）があります。タイムアウトは、Cloud KMS 鍵の Google Cloud ロケーションの Cloud KMS サービスから測定されます。Google Cloud のロケーションがマルチリージョンの場合、Cloud KMS がリクエストを受信したリージョンでタイムアウトが開始されます。通常、これは CMEK で保護されたデータリソースに対するオペレーションが発生したリージョンです。このタイムアウトは、リクエストの発信元である近くのGoogle Cloud リージョンで EKM サービスがリクエストを処理するのに十分です。
タイムアウトにより、外部鍵に依存するダウンストリーム サービスでカスケード障害を防ぐことができます。通常、上位レベルのアプリケーションでユーザー エクスペリエンスの低下を引き起こす可能性があるテール レイテンシの問題は、実際には外部キーへのアクセスの失敗として現れ、上位レベルの論理オペレーションの失敗につながる可能性があります。
レイテンシを最小限に抑え、信頼性の高いネットワークを構築するには、次の点を考慮してください。
- Cloud KMS とのラウンドトリップ通信のレイテンシを最小限に抑える: EKM サービスを使用するように構成された Cloud KMS 鍵に対応する、 Google Cloud のロケーションに地理的にできるだけ近い場所でリクエストを処理するように EKM サービスを構成します。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスとリージョンとゾーンをご覧ください。
- 可能であれば Cloud Interconnect を使用する: Cloud Interconnect は、VPC ネットワークを使用して Google Cloudとデータセンターの間に高可用性で低レイテンシの接続を確立し、インターネットへの依存関係を排除します。
- 必要に応じて、EKM サービスに最も近いリージョンに Google Cloud ネットワーク ソリューションをデプロイします。理想的には、Cloud KMS 鍵は EKM サービスに最も近いリージョンに保存されます。Cloud KMS 鍵を保持するリージョンよりも EKM サービスに近いGoogle Cloud リージョンがある場合は、EKM サービスに最も近いリージョンで Cloud VPN などの Google Cloud ネットワーキング ソリューションを使用してください。このオプションを使用すると、ネットワーク トラフィックが可能な限り Google インフラストラクチャを使用するため、インターネットへの依存を軽減できます。
- EKM トラフィックがインターネットを経由する場合はプレミアム ティア ネットワークを使用する: プレミアム ティアは、信頼性を向上させ、レイテンシを短縮するために、可能な限り Google のインフラストラクチャを使用してインターネット経由でトラフィックをルーティングします。
高可用性の有効化
EKM サービスに単一障害点が存在すると、依存する Google Cloud リソースの可用性が単一障害点の可用性に低下します。このような障害ポイントは、EKM サービスの重要な依存関係や、基盤となるコンピューティング インフラストラクチャとネットワーク インフラストラクチャに存在する可能性があります。
高可用性を有効にするには、次の点を考慮してください。
- 独立した障害ドメインにレプリカをデプロイする: EKM サービスのレプリカを 2 つ以上デプロイします。マルチリージョンの Google Cloudロケーションを使用している場合は、少なくとも 2 つの別々の地理的ロケーションに、それぞれ 2 つ以上のレプリカをデプロイします。クロスレプリカの障害ベクトルを最小限に抑えて強化し、各レプリカが EKM サービスのレプリケートされたデータプレーンを表すだけでなく、次の例について考えてみましょう。
- サーバーのバイナリや構成の push など、本番環境の変更を構成して、一度に 1 つのレプリカのみを変更します。すべての変更が監督下で行われ、テスト済みのロールバックがすぐに利用可能であることを確認します。
- 基盤となるインフラストラクチャのクロスレプリカ障害モードを理解して最小限に抑えます。たとえば、レプリカが独立した冗長電源フィードに依存するようにします。
単一マシンの停止に対するレプリカの復元力を高める: サービスの各レプリカが 3 つ以上のアプライアンス、マシン、VM ホストで構成されていることを確認します。この構成では、1 台のマシンが更新のために停止している間や、予期しない停止中にシステムがトラフィックを処理できます（N+2 プロビジョニング）。
コントロール プレーンの問題の影響を受ける領域を制限する: 構成またはデータをレプリカ間で複製するように、EKM サービスのコントロール プレーン（鍵の作成や削除など）を構成します。これらのオペレーションは、同期が必要ですべてのレプリカに影響するため、通常は複雑です。問題はすぐに伝播してシステム全体に影響する可能性があります。問題の影響を軽減するための戦略には、次のようなものがあります。
- 伝播速度を制御する: デフォルトでは、ユーザビリティとセキュリティの観点から許容できる限り、変更がゆっくりと伝播するようにします。必要に応じて例外を設定します。たとえば、キーへのアクセスを許可して、ユーザーが間違いを元に戻せるようにすばやく伝播する場合などです。
- システムをシャードに分割する: 多くのユーザーが EKM を共有する場合は、完全に独立した論理シャードに分割して、1 つのシャードのユーザーによってトリガーされた問題が別のシャードのユーザーに影響しないようにします。
- 変更の効果をプレビューする: 可能であれば、変更を適用する前に、変更の効果をユーザーに確認してもらいます。たとえば、鍵アクセス ポリシーを変更するときに、EKM は新しいポリシーで拒否された可能性のある最近のリクエストの数を確認できます。
- データ カナリアを実装する: まず、システムの小さなサブセットにのみデータを push します。サブセットが正常な状態を維持している場合は、データをシステムの残りの部分に push します。
包括的なヘルスチェックを実装する: システム全体が機能しているかどうかを測定するヘルスチェックを作成します。たとえば、ネットワーク接続のみを検証するヘルスチェックは、多くのアプリケーション レベルの問題に対応するのに役立ちません。理想的には、ヘルスチェックは実際のトラフィックの依存関係を正確に反映します。
レプリカ間のフェイルオーバーを設定する: ヘルスチェックを使用し、正常でないレプリカからトラフィックを積極的にドレインし、正常なレプリカに安全にフェイルオーバーするように、EKM サービス コンポーネントにロード バランシングを設定します。
過負荷を管理し、カスケード障害を回避するための安全メカニズムを含める: システムはさまざまな理由で過負荷になる可能性があります。たとえば、一部のレプリカが異常な状態になると、正常なレプリカにリダイレクトされたトラフィックが過負荷になる可能性があります。処理できるリクエスト数を超えるリクエストが発生した場合、システムは余分なトラフィックを拒否しながら、安全かつ迅速に処理できるリクエストを処理しようとします。
堅牢な耐久性を確保する: Google Cloud で、EKM サービスで外部鍵で暗号化されたデータは、外部鍵がないと復元できません。したがって、鍵の耐久性は EKM サービスの中心的な設計要件の 1 つです。鍵マテリアルの冗長コピーを複数の物理ロケーションに安全にバックアップするように EKM サービスを構成します。価値の高い鍵には、オフライン バックアップなどの追加の保護手段を設定します。削除メカニズムでは、事故やバグが発生した場合に復元に時間がかからないようにしてください。
障害を迅速に検出して軽減する
EKM サービスが停止するたびに、依存する Google Cloudリソースにアクセスできなくなる可能性があります。これにより、インフラストラクチャの他の依存コンポーネントの連鎖的な障害の可能性がさらに高まります。
障害を迅速に検出して軽減するには、次の点を考慮してください。
- 信頼性を脅かすインシデントを示す指標を報告するように EKM サービスを構成する: レスポンス エラー率やレスポンス レイテンシなどの指標を設定して、問題を迅速に検出します。
- インシデントのタイムリーな通知と軽減のための運用手法を設定する: 平均検出時間（MTTD）と平均復元時間（MTTR）の指標を追跡し、運用手法の有効性を定量化し、これらの指標で測定される目標を定義します。これらの指標を使用すると、現在のプロセスとシステムのパターンと欠陥を見つけて、インシデントに迅速に対応できます。
Cloud EKM のリファレンス アーキテクチャ
次のアーキテクチャは、Google Cloud のネットワーキング プロダクトとロード バランシング プロダクトを使用して EKM サービスをデプロイする方法を示しています。
Cloud VPN または Cloud Interconnect を介した直接接続
Google Cloud で高スループット アプリケーションを実行し、EKM サービスが単一のデータセンターで実行されている場合は、 Google Cloud とオンプレミス データセンターを直接接続することをおすすめします。次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、Cloud EKM は、 Google Cloudで中間ロード バランシングを行わずに、リージョンのハイブリッド接続を介してオンプレミス データセンターにある EKM サービスにアクセスします。
可能であれば、単一リージョン アプリケーションの 99.9% の可用性構成を使用して、Cloud EKM から EKM へのサービス接続をデプロイします。99.99% の可用性の構成では、複数の Google Cloudリージョンで Cloud Interconnect を使用する必要があります。ビジネスでリージョン分離が必要な場合は、ニーズを満たさない可能性があります。オンプレミス データセンターへの接続でインターネットを使用する場合は、Cloud Interconnect ではなく HA VPN を使用します。
このアーキテクチャの主な利点は、 Google Cloudに中間ホップがないため、レイテンシとボトルネックの可能性を低減できることです。EKM サービスが複数のデータセンターにホストされているときに直接接続を設定する場合は、同じ（Anycast）IP アドレスを使用するすべてのデータセンターでロードバランサを構成する必要があります。この構成を使用する場合、データセンター間のロード バランシングとフェイルオーバーは、ルートの可用性に限定されます。
VPC ネットワークを設定する場合は、VPC ネットワーク経由でアクセスする外部鍵に Cloud KMS のリージョン ロケーションを使用する必要があります。鍵はマルチリージョンのロケーションを使用できません。詳細については、外部鍵マネージャーとリージョンをご覧ください。
Google Cloudでインターネットからロードバランスされる
マルチリージョンの Cloud KMS 鍵が必要な場合は、 Google Cloud でインターネット接続を備えたロードバランサを使用することをおすすめします。次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、EKM には 2 つのオンプレミス サイトにレプリカがあります。各バックエンドは、ハイブリッド接続ネットワーク エンドポイント グループ（NEG）を使用して Google Cloud で表されます。このデプロイでは、外部プロキシ ネットワーク ロードバランサを使用して、トラフィックをいずれかのレプリカに直接転送します。VPC ネットワーキングに依存する他のアプローチとは異なり、外部プロキシ ネットワーク ロードバランサには外部 IP アドレスがあり、トラフィックはインターネットから送信されます。
各ハイブリッド接続 NEG には複数の IP アドレスが含まれる場合があります。これにより、外部プロキシ ネットワーク ロードバランサは EKM サービスのインスタンスに直接トラフィックを分散できます。オンプレミス データセンターに追加のロードバランサは必要ありません。
外部プロキシ ネットワーク ロードバランサは特定のリージョンに関連付けられていません。受信トラフィックを最も近い正常なリージョンに転送できるため、マルチリージョンの Cloud KMS 鍵に適しています。ただし、ロードバランサでは、プライマリ バックエンドとフェイルオーバー バックエンドの構成はできません。トラフィックは、リージョン内の複数のバックエンドに均等に分散されます。
Google Cloudの VPC ネットワークでロード バランシングされる
EKM をデプロイするほとんどの EKM サービスでは、 Google Cloud のロードバランサと VPC ネットワークを使用することをおすすめします。次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、Cloud EKM は、 Google Cloud リージョンの中間ロード バランシングのレイヤを備えたハイブリッド接続を介して、2 つのオンプレミス データセンター間で複製された EKM サービスにアクセスします。オンプレミス データセンターへの接続でインターネットを使用する場合は、Cloud Interconnect の代わりに HA VPN を使用できます。
内部パススルー ネットワーク ロードバランサは、リソースが仮想ネットワーキングを使用してトラフィックを送信するために使用できる単一の IP アドレスを提供します。ロードバランサは、バックエンドのヘルスに基づいてバックアップ データセンターにフェイルオーバーします。
内部ロードバランサはトラフィックをオンプレミス バックエンドに直接転送できないため、トラフィックをプロキシするには VM インスタンス グループが必要です。ロードバランサ プロキシをデプロイして、Cloud Marketplace の Nginx Docker イメージをインスタンス グループで実行できます。Nginx を TCP ロードバランサとして使用できます。
このアプローチでは Google Cloudのロードバランサを使用するため、オンプレミス ロードバランサは必要ありません。 Google Cloud ロードバランサは、EKM サービスのインスタンスに直接接続し、インスタンス間で負荷を分散できます。オンプレミス ロードバランサを排除すると、構成が簡素化されますが、EKM サービスで利用できる柔軟性が低下します。たとえば、1 つの EKM インスタンスがエラーを返した場合、オンプレミス L7 ロードバランサはリクエストを自動的に再試行できます。
VPC ネットワークを設定する場合は、VPC ネットワーク経由でアクセスする外部鍵に Cloud KMS のリージョン ロケーションを使用する必要があります。鍵はマルチリージョンのロケーションを使用できません。詳細については、外部鍵マネージャーとリージョンをご覧ください。
リファレンス アーキテクチャの比較
次の表は、Cloud EKM のリファレンス アーキテクチャ オプションを比較したものです。この表には、パートナー管理の EKM アーキテクチャの列も含まれています。このシナリオでは、パートナーが EKM のデプロイと管理を行い、EKM をサービスとしてお客様に提供します。
| オプション | 直接接続 | インターネットからの負荷分散 | VPC ネットワークでのロード バランシング | パートナーが提供するフルマネージド EKM |
|---|---|---|---|---|
インターネットまたは VPC ネットワーク |
VPC |
インターネット |
VPC |
インターネット |
Google Cloudのロードバランサ |
× |
○ |
○ |
× |
オンプレミス ロードバランサが必要 |
○ |
いいえ |
× |
○（パートナーが管理） |
マルチリージョンの Cloud KMS ロケーションをサポート |
× |
○ |
いいえ |
○ |
最適な用途 |
EKM サービスが単一サイトで実行される高スループット アプリケーション。 |
マルチリージョン Cloud KMS 鍵が必要な場合。 |
独自の EKM をデプロイするほとんどの EKM サービス。 |
独自の EKM をデプロイする代わりに、パートナーの EKM を使用できます。 |