Cloud External Key Manager（Cloud EKM）で Cloud Key Management Service（Cloud KMS）を有効にすると、外部鍵管理パートナーで管理する鍵を使用して、Google Cloudのデータを保護できます。このドキュメントでは、Cloud KMS と Cloud EKM を使用して可用性の高い外部鍵マネージャー（EKM）サービスをデプロイする Google Cloud お客様向けのアーキテクチャについて説明します。
Cloud EKM を 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 のインフラストラクチャを使用してインターネット経由でトラフィックをルーティングし、信頼性を高め、レイテンシを短縮します。
- 適切なクライアント デッドラインを使用する: Cloud EKM 鍵に対して Cloud KMS API API を直接呼び出す場合は、外部鍵オペレーションが完了するのに十分な時間を確保するために、クライアント デッドラインを 10 秒以上に構成します。
高可用性を有効化
EKM サービスに単一障害点が存在すると、依存する Google Cloud リソースの可用性が単一障害点の可用性に低下します。このような障害点は、EKM サービスの重要な依存関係だけでなく、基盤となるコンピューティングとネットワーク インフラストラクチャにも存在する可能性があります。
高可用性を有効にするには、次の点を考慮してください。
- 独立した障害ドメインにレプリカをデプロイする: EKM サービスのレプリカを 2 つ以上デプロイします。マルチリージョン Google Cloudロケーションを使用している場合は、EKM を地理的に離れた 2 つ以上のロケーションにデプロイし、それぞれに 2 つ以上のレプリカを配置します。クロスレプリカの障害ベクトルを最小限に抑えて強化することで、各レプリカが EKM サービスのレプリケートされたデータプレーンを表すだけでなく、以下の例を考えてみましょう。
- サーバーのバイナリや構成の push など、本番環境の変更を一度に 1 つのレプリカのみを変更するように構成します。すべての変更が監督下で実行され、テスト済みのロールバックがすぐに利用できることを確認します。
- 基盤となるインフラストラクチャのクロスレプリカ障害モードを理解して最小限に抑えます。たとえば、レプリカが独立した冗長電源に依存するようにします。
単一マシンの停止に対してレプリカの復元力を高める: サービスの各レプリカが、3 つ以上のアプライアンス、マシン、VM ホストで構成されていることを確認します。この構成により、1 台のマシンが更新のためにダウンしている間や、予期しない停止が発生している間も、システムはトラフィックを処理できます（N+2 プロビジョニング）。
コントロール プレーンの問題の影響範囲を制限する: EKM サービスのコントロール プレーン（鍵の作成や削除など）を構成して、構成やデータをレプリカ間で複製します。これらのオペレーションは同期を必要とし、すべてのレプリカに影響するため、一般的に複雑になります。問題が迅速に伝播して、システム全体に影響する可能性があります。問題の影響を軽減するための戦略には、次のようなものがあります。
- 伝播速度を制御する: デフォルトでは、ユーザビリティとセキュリティで許容される範囲で、変更が可能な限りゆっくりと伝播するようにします。必要に応じて例外を設定します。たとえば、鍵へのアクセスを許可して迅速に伝播し、ユーザーが間違いを元に戻せるようにします。
- システムをシャードに分割する: 多くのユーザーが EKM を共有している場合は、完全に独立した論理シャードに分割して、1 つのシャードのユーザーによってトリガーされた問題が別のシャードのユーザーに影響しないようにします。
- 変更の効果をプレビューする: 可能であれば、変更を適用する前にユーザーが変更の効果を確認できるようにします。たとえば、鍵アクセス ポリシーを変更するときに、EKM は新しいポリシーで拒否される最近のリクエストの数を確認できます。
- データ カナリアリングを実装する: まず、システムのごく一部にのみデータをプッシュします。サブセットが正常な状態を維持している場合は、データをシステムの残りの部分に push します。
包括的なヘルスチェックを実装する: システム全体が機能しているかどうかを測定するヘルスチェックを作成します。たとえば、ネットワーク接続のみを検証するヘルスチェックは、多くのアプリケーション レベルの問題に対応するうえで役に立ちません。理想的には、ヘルスチェックは実際のトラフィックの依存関係を反映します。
レプリカ間のフェイルオーバーを設定する: ヘルスチェックを使用し、正常でないレプリカからトラフィックをドレインし、正常なレプリカに安全にフェイルオーバーするように、EKM サービス コンポーネントにロード バランシングを設定します。
過負荷を管理し、カスケード障害を回避するための安全機構を含める: システムが過負荷になる理由はさまざまです。たとえば、一部のレプリカが異常な状態になると、正常なレプリカにリダイレクトされたトラフィックによってレプリカが過負荷になる可能性があります。処理できるリクエスト数を超えるリクエストに直面した場合、システムは安全かつ迅速に処理できるリクエストを処理し、過剰なトラフィックを拒否する必要があります。
堅牢な耐久性を確保する: EKM サービスで外部鍵を使用して暗号化された Google Cloud のデータは、外部鍵がないと復元できません。そのため、鍵の耐久性は EKM サービスの中心的な設計要件の一つです。複数の物理ロケーションに鍵マテリアルの冗長コピーを安全にバックアップするように 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 サービスが複数のデータセンターにホストされている場合に直接接続を設定するには、同じ（エニーキャスト）IP アドレスを使用するすべてのデータセンターでロードバランサを構成する必要があります。この構成を使用する場合、データセンター間のロード バランシングとフェイルオーバーは、ルートの可用性のみに制限されます。
VPC ネットワークを設定する場合は、VPC ネットワーク経由でアクセスされる外部鍵で Cloud KMS のリージョン ロケーションを使用する必要があります。鍵はマルチリージョン ロケーションを使用できません。詳細については、外部鍵マネージャーとリージョンをご覧ください。
Google Cloudでインターネットからの負荷分散
マルチリージョン Cloud KMS 鍵が必要な場合は、インターネット接続のある Google Cloud でロードバランサを使用することをおすすめします。次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、EKM に 2 つのオンプレミス サイトにレプリカがあります。各バックエンドは、ハイブリッド接続ネットワーク エンドポイント グループ（NEG）を使用して Google Cloud で表されます。このデプロイでは、外部プロキシ ネットワーク ロードバランサを使用して、トラフィックをレプリカの 1 つに直接転送します。VPC ネットワーキングに依存する他のアプローチとは異なり、外部プロキシ ネットワーク ロードバランサには外部 IP アドレスがあり、トラフィックはインターネットから送信されます。
各ハイブリッド接続 NEG には複数の IP アドレスを含めることができます。これにより、外部プロキシ ネットワーク ロードバランサは、EKM サービスのインスタンスにトラフィックを直接分散できます。オンプレミス データセンターに追加のロードバランサは必要ありません。
外部プロキシ ネットワーク ロードバランサは特定のリージョンに関連付けられていません。受信トラフィックを最も近い正常なリージョンに転送できるため、マルチリージョン Cloud KMS 鍵に適しています。ただし、ロードバランサではプライマリ バックエンドとフェイルオーバー バックエンドの構成は許可されていません。トラフィックは、リージョン内の複数のバックエンドに均等に分散されます。
Google Cloudの VPC ネットワークでロードバランスされる
EKM をデプロイするほとんどの EKM サービスでは、VPC ネットワークでロードバランサを使用することをおすすめします。 Google Cloud 次の図は、このアーキテクチャを示しています。
このアーキテクチャでは、Cloud EKM は、 Google Cloud リージョンに中間ロード バランシングのレイヤとのハイブリッド接続を介して、2 つのオンプレミス データセンター間で複製された EKM サービスにアクセスします。オンプレミス データセンターへの接続でインターネットを使用する場合は、Cloud Interconnect の代わりに HA VPN を使用できます。
内部パススルー ネットワーク ロードバランサは、リソースが仮想ネットワーキングを使用してトラフィックを送信するために使用できる単一の IP アドレスを提供します。ロードバランサは、バックエンドの健全性に基づいてバックアップ データセンターにフェイルオーバーします。
内部ロードバランサはトラフィックをオンプレミス バックエンドに直接ルーティングできないため、トラフィックのプロキシには VM インスタンス グループが必要です。ロードバランサ プロキシをデプロイして、インスタンス グループの Cloud Marketplace から Nginx Docker イメージを実行できます。Nginx を TCP ロードバランサとして使用できます。
このアプローチでは Google Cloudのロードバランサを使用するため、オンプレミス ロードバランサは必要ありません。 Google Cloud ロードバランサは、EKM サービスのインスタンスに直接接続し、インスタンス間でロード バランシングを行うことができます。オンプレミス ロードバランサを排除すると、構成は簡素化されますが、EKM サービスで利用できる柔軟性が低下します。たとえば、オンプレミスの L7 ロードバランサは、1 つの EKM インスタンスがエラーを返した場合に、リクエストを自動的に再試行できます。
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 を使用できます。 |