Cloud HSM アーキテクチャ

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

企業やコンプライアンスの規制を遵守できるように、Cloud HSM では暗号鍵を生成し、FIPS 140-2 レベル 3 認定ハードウェア セキュリティ モジュール(HSM)で暗号オペレーションを実行できます。

このドキュメントでは、ハードウェアの管理方法や鍵の認証と作成の方法など、Cloud HSM のアーキテクチャについて説明します。

概要

暗号オペレーションには、保存データの暗号化、Certificate Authority Service の秘密鍵の保護、データ暗号鍵の保護などがあり、これらは暗号化されたデータと一緒に保存されます。Cloud HSM は、ファームウェア バージョン 3.4(ビルド 09)の Marvell LiquidSecurity HSM(モデル CNL3560-NFBE-2.0-G および CNL3560-NFBE-3.0-G)を使用します。Google の認定について詳しくは、認定証 #3718 をご覧ください。

Cloud HSM はフルマネージドであるため、HSM クラスタの管理に伴う運用上のオーバーヘッドなしにワークロードを保護できます。このサービスには次のような利点があります。

  • グローバルな可用性
  • 一貫性のある統合 API
  • 使用状況に基づく自動スケーリング
  • 一元管理と規制遵守

Cloud HSM は、より広い地域にまたがるマルチリージョンを含む、世界中のすべての Google Cloud リージョンで利用可能です。Cloud HSM を有効にすると、HSM でサポートされる鍵を作成してデータの保護に使用できます。BigQuery、Cloud Storage、Persistent Disk など、他の Google Cloud サービスに保存されているデータも保護できます。

Cloud HSM と HSM ハードウェアは Google によって管理されるため、本番環境で HSM がサポートする鍵を管理する必要はありません。Cloud HSM を使用すると、データは Google Cloud の他のテナントやサービスから厳密に分離されます。Cloud Key Management Service API の一部である Cloud HSM データプレーン API を使用すると、HSM がサポートする鍵をプログラムで管理できます。

Google Cloud 全体で CMEK 鍵がサポートされている場合、Cloud HSM は、HSM でサポートされる顧客管理の暗号鍵(CMEK)をサポートします。たとえば、自身で管理する Cloud HSM 鍵を使用して、Cloud Storage バケットや Cloud SQL テーブルのデータを暗号化できます。

Cloud HSM の管理

Cloud HSM 内では、Google Cloud データセンターの各ロケーションで作業する Google サイト信頼性エンジニア(SRE)と技術者によって HSM のクラスタが維持されています。Google は、物理セキュリティ、論理セキュリティ、インフラストラクチャ、キャパシティ プランニング、地域拡大、データセンターの障害復旧計画に対応しています。

HSM ハードウェアの抽象化

通常、アプリケーションは PKCS#11 とクラスタ管理 API の両方を使用して HSM と直接通信します。この通信では、HSM がサポートする鍵を使用または管理するワークロード専用のコードを維持する必要があります。

Cloud HSM は、Cloud Key Management Service API を介して HSM がサポートする鍵のリクエストをプロキシすることで、HSM から通信を抽象化しています。この抽象化により、HSM 固有のコードの必要性が軽減されます。Cloud HSM は Cloud KMS との緊密なインテグレーションを継承します。

Cloud KMS との緊密なインテグレーションにより、多大なセキュリティ上のメリットが得られます。Cloud Key Management Service API を使用すると、利用可能な HSM インターフェースの範囲が大幅に縮小されるため、顧客のセキュリティ侵害が発生した場合のリスクを軽減できます。たとえば、攻撃者は HSM 全体をワイプできません。デフォルトでは、個々の鍵の破棄は、デフォルトの 24 時間の安全期間を通じて軽減されます。constraints/cloudkms.minimumDestroyScheduledDuration 組織のポリシーを設定すると、新しい鍵の破棄が予定されている期間に最小期間を適用できます。また、constraints/cloudkms.disableBeforeDestroy 組織のポリシーを設定すると、無効になっている鍵バージョンのみを削除できます。詳細については、鍵バージョンの破棄を制御するをご覧ください。

Identity and Access Management(IAM)を使用して、HSM リソースへのアクセスを制御できます。IAM 構成では、カスタム HSM ソリューションよりも構成ミスやバグが発生する可能性が低くなります。

Cloud HSM アーキテクチャの図。

厳密な地理的分離を考慮した設計

Cloud HSM では、鍵をグローバルに使用可能にすることも、制限を必要とする鍵に対して厳密な地理的制限を適用することもできます。

多くの場合、HSM はパーティションに分割されるため、1 つの物理デバイスが複数の論理デバイスとして動作できます。HSM の管理と鍵を分離する必要がある場合は、パーティションを使用してデプロイコストを削減できます。

Cloud HSM の各リージョン ロケーションは、個別のラッピング鍵に関連付けられています。ラッピング鍵のクローンが各リージョン ロケーションの HSM でパーティションに作成されますが、HSM はロケーションに残りません。クローンの作成により、同じリージョンの HSM は同じ顧客鍵のセットを提供し、リージョン外の HSM はそれらの鍵を提供できなくなります。

Cloud HSM では、マルチリージョンの作成にもラッピング鍵を使用します。マルチリージョンのすべての顧客鍵は、マルチリージョンを構成するすべてのロケーションのパーティションに存在するラッピング鍵でラップされます。このサービスでは、同じハードウェアをマルチリージョンで利用しますが、異なるリージョン間に存在するリージョンとマルチリージョンの間でも強力な分離が実現されます。

Cloud HSM の地域の図

リージョン化スキームでは、ラッピング鍵は適切なパーティションにのみ複製する必要があります。各構成の変更は、Cloud HSM チームの複数のメンバーによって承認されてからアクティブになります。データセンターの技術者は、現場の HSM 構成、ランタイム、ストレージにアクセスできません。

一元化された管理

HSM をホストする従来のデータセンターでは、HSM とそのリソースの管理は他の暗号リソースの管理とは完全に分離されています。Cloud HSM は Google Cloud と緊密に統合されているため、Cloud HSM リソースをシームレスに管理できます。たとえば、以下を管理できます。

  • HSM がサポートするリソースは、Cloud KMS の他の鍵と、Cloud External Key Manager(Cloud EKM)の外部管理鍵と一緒に管理します。
  • IAM 内で HSM がサポートするリソースへのアクセスを管理します。
  • HSM がサポートする鍵を使用する暗号操作のレポート費用は、Cloud Billing に報告されます。
  • HSM がサポートする鍵は、CMEK によるリソースの暗号化をサポートするすべての Google Cloud サービスで透過的に使用できます。CMEK を統合するには、CMEK 鍵と暗号化するデータを互換性のある地理的位置に配置する必要があります。Cloud HSM 鍵の地理的な制限が厳しいため、CMEK データのすべての暗号化と復号も地理的に制限されます。
  • HSM でサポートされるリソースの管理オペレーションは、常に Cloud Audit Logs の API レイヤに記録されます。データアクセス ロギングを有効にすることもできます。詳細については、Cloud KMS 監査ロギングの情報をご覧ください。
  • Google は HSM メーカーと直接連携して、各 HSM のハードウェアとソフトウェアを最新の状態に維持し、問題をリアルタイムで見つけて修正しています。HSM でゼロデイ エクスプロイトが発生した場合、Google は影響を受ける HSM クラスタで攻撃を受けたコードパスを、エクスプロイトが修正されるまで選択的に無効にできます。

デベロッパーとユーザー エクスペリエンス

Google が HSM の管理を担当しているため、Cloud HSM はデベロッパーとエンドユーザーに大きなメリットをもたらします。

Google 規模の HSM

オンプレミスやデータセンターにあるハードウェアに依存すると、ハードウェアがパフォーマンスのボトルネックになったり、単一障害点になる可能性があります。Cloud HSM は、予測できないワークロードやハードウェア障害に対する耐性が非常に高く設計されています。Cloud HSM バックエンドは、各リージョンで HSM のプールを使用して、高い可用性とスケーラビリティを確保します。この HSM のプールにより、Cloud HSM も高スループットを提供できます。詳細については、Cloud KMS の割り当てのモニタリングと調整をご覧ください。

すべての顧客鍵は Cloud KMS データベースのリージョン ラッピング鍵によってラップされた状態で保存され、暗号オペレーションの一部としてリージョンの HSM でのみラップが解除されます。このラッピングには次の利点があります。

  • 鍵の耐久性は、リージョン内の特定の HSM または HSM のサブセットに関連付けられません。
  • Cloud HSM の各ユーザーは、鍵を提供する Cloud HSM クラスタのフルスケールと可用性を体験できます。
  • Cloud HSM は、HSM に格納可能ではるかに大きい鍵セットを処理できます。
  • HSM の追加または交換は迅速で安全です。

統合型 API 設計

Cloud HSM と Cloud KMS は、共通の管理とデータプレーン API を共有します。HSM との通信の内部の詳細は呼び出し元から抽象化されます。

したがって、Cloud KMS のソフトウェア鍵を使用して HSM がサポートする鍵をサポートする既存のアプリケーションを更新する際に、コードを変更する必要はありません。代わりに、使用する鍵のリソース名を更新します。

PKCS#11 のサポート

Cloud Key Management Service API を使用すると、既存のアプリケーションを Cloud HSM に接続して暗号鍵を管理できます。PKCS#11 ライブラリを使用すると、HSM がサポートする鍵を使用してバイナリに署名し、TLS ウェブ セッションを提供できます。

セキュリティと規制の遵守

Cloud HSM は、FedRAMP HighC5:2020OSPAR など、多くの規制を遵守しています。また、Cloud HSM は、クラウド内のワークロードの規制遵守にも役立ちます。

暗号鍵の証明書

Cloud HSM 鍵を生成またはインポートするたびに、HSM は、パーティションに関連付けられた署名鍵で署名された証明書ステートメントを生成します。ステートメントには、鍵の属性に関する情報が含まれています。署名鍵は、Google と HSM メーカーの両方にルート化された証明書チェーンでサポートされています。証明書ステートメントと証明書をダウンロードして、ステートメントの信頼性を検証し、鍵および鍵を生成またはインポートした HSM のプロパティを検証できます。

証明書チェーンを使用すると、以下を確認できます。

  • HSM ハードウェアとファームウェアが正規のものであること。
  • HSM パーティションと HSM が Google によって管理されていること。
  • HSM が FIPS 動作モードになっていること。

構成証明ステートメントの内容では、以下を確認できます。

  • 鍵が抽出不可であること。
  • CryptoKeyVersion に対して鍵が生成されたこと。
  • 非対称鍵ペアの公開鍵が、HSM がサポートする秘密鍵に対応していること。
  • インポートした対称鍵の鍵マテリアルが、ラップした値と一致すること。

HSM に鍵を安全にインポートする

既存の鍵を Cloud HSM に安全にインポートして、Google Cloud 外部の鍵マテリアルのバックアップを維持できます。また、特定のワークロードの Google Cloud への移行を簡素化できます。鍵のインポート プロセスでは、ラップ解除された鍵マテリアルに Google が直接アクセスすることはできません。Cloud HSM は、HSM が生成したラッピング鍵の証明書ステートメントを提供し、アクセスが発生していないことを確認します。

鍵のインポートでは、ユーザーが提供元不明の鍵を使用でき、セキュリティとコンプライアンスのリスクが生じる可能性があります。個別の IAM ロールを使用することで、プロジェクトに鍵をインポートできるユーザーをきめ細かく制御できます。インポートされた鍵は、HSM がインポート時に生成する証明書ステートメントで区別できます。

詳細については、Cloud Key Management Service に鍵をインポートするをご覧ください。

厳格なセキュリティ対策による HSM ハードウェアの保護

FIPS 140-2 レベル 3 で定められているとおり、HSM デバイスには、物理的な改ざんを防止し、証拠を提示するメカニズムが組み込まれています。

HSM ハードウェア自体が提供する保証に加えて、Cloud HSM のインフラストラクチャは Google インフラストラクチャのセキュリティ設計の概要に従って管理されます。

文書化された監査可能な手順により、プロビジョニング、デプロイ、本番環境における各 HSM の整合性が保護されます。

  • HSM をデータセンターにデプロイする前に、すべての HSM 構成を複数の Cloud HSM SRE が検証する必要があります。
  • HSM が稼働した後は、複数の Cloud HSM SRE によってのみ構成の変更の開始と検証が可能です。
  • HSM で使用できるのは、HSM メーカーによって署名されたファームウェアのみです。
  • HSM ハードウェアはどのネットワークにも直接公開されません。
  • HSM ハードウェアをホストするサーバーでは不正なプロセスの実行を防ぎます。

システム オペレータの義務は、標準的な運用手順で定義されます。システム オペレータは職務中に顧客鍵マテリアルにアクセス、使用、抽出することはできません。

サービスとテナントの分離

Cloud HSM アーキテクチャは、他のサービスまたはテナントからの悪意ある干渉や意図しない干渉から HSM を保護します。

このアーキテクチャに含まれる HSM は Cloud HSM からのリクエストのみを受け入れ、Cloud HSM サービスは Cloud KMS からのリクエストのみを受け入れます。Cloud KMS では、呼び出し元が使用を試みる鍵に対して適切な IAM 権限が付与されます。未承認のリクエストは HSM に到達しません。

HSM がサポートする鍵には、暗号オペレーションの割り当ても適用されます。これらの割り当てでは、サービスの過負荷につながる意図しない操作や悪意のある操作を防ぐことで、ワークロードの実行能力が保護されます。非対称暗号オペレーションの場合、デフォルトの割り当ては 3,000 QPM、対称暗号オペレーションの場合は 30,000 QPM です。これは、実際に測定した使用パターンに基づいています。割り当てはサービス容量を大幅に下回っており、リクエストに応じて増やすことができます。

リクエスト フロー

このセクションでは、上記のアーキテクチャの実際の使用例を、さまざまな種類のリクエストの手順を使用して説明します。これらのフローでは Cloud HSM の部分に焦点を当てています。すべての鍵に共通する手順については、Cloud Key Management Service の詳細をご覧ください。

鍵の作成

HSM がサポートする鍵を作成する場合、Cloud Key Management Service API は鍵マテリアルを作成しませんが、HSM に鍵の作成をリクエストします。

HSM はサポートしているロケーションでのみ鍵を作成できます。HSM の各パーティションには、Cloud KMS のロケーションに対応するラッピング鍵が存在します。ラッピング鍵は、Cloud KMS のロケーションをサポートするすべてのパーティションで共有されます。鍵の作成プロセスは次のようになります。

  1. Google Front End サービス(GFE)が、リクエストに対応するロケーションの Cloud KMS サーバーに鍵作成リクエストをルーティングします。
  2. Cloud Key Management Service API が、呼び出し元の ID、プロジェクトで鍵を作成する呼び出し元の権限、呼び出し元に十分な書き込みリクエスト割り当てがあることを確認します。
  3. Cloud Key Management Service API がリクエストを Cloud HSM に転送します。
  4. Cloud HSM が HSM と直接やり取りします。HSM:
    1. 鍵を作成し、ロケーション固有のラッピング鍵でラップします。
    2. 鍵の証明書ステートメントを作成し、パーティション署名鍵で署名します。
  5. ラップされた鍵と証明書を Cloud HSM が Cloud KMS に返すと、Cloud Key Management Service API は Cloud KMS 鍵の階層に従って HSM でラップされた鍵をラップし、プロジェクトに書き込みます。

この設計では、鍵をラップ解除したり、HSM の外部で使用することはできません。また、鍵を HSM から抽出することもできません。鍵は、指定のロケーション内でのみラップ解除された状態で存在します。

次の図は、Cloud KMS で Cloud HSM 鍵とソフトウェア鍵を作成する場合の違いを示しています。

HSM 鍵の作成図。

暗号オペレーション

Cloud KMS で暗号オペレーションを実行する場合、HSM がサポートする鍵とソフトウェア鍵のどちらを使用しているかを把握する必要はありません。Cloud Key Management Service API がオペレーションで HSM がサポートする鍵が使用されていることを検出すると、同じロケーションの HSM にリクエストを転送します。暗号オペレーションの手順は次のとおりです。

  1. GFE は、適切なロケーションの Cloud KMS サーバーにリクエストをルーティングします。Cloud Key Management Service API が、呼び出し元の ID、鍵にアクセスしてオペレーションを実行する呼び出し元の権限、暗号オペレーションに関するプロジェクトの割り当てを確認します。
  2. Cloud Key Management Service API は、ラップされた鍵をデータストアから取得し、Cloud KMS マスター鍵を使用して 1 レベルの暗号化を復号します。鍵は KMS ロケーションの HSM ラッピング鍵で引き続きラップされます。
  3. 保護レベルが HSM であることを Cloud Key Management Service API が検出し、部分的にラップ解除された鍵を暗号オペレーションへの入力とともに Cloud HSM に送信します。
  4. Cloud HSM が HSM と直接やり取りします。HSM は、次の処理を行います。
    1. ラップされた鍵とその属性が変更されていないことを確認します。
    2. 鍵をラップ解除し、HSM ストレージに読み込みます。
    3. 暗号オペレーションを実行して結果を返します。
  5. Cloud Key Management Service API が呼び出し元に結果を返します。

HSM がサポートする鍵を使用した暗号オペレーションは、構成済みロケーションの HSM 内ですべて実行され、呼び出し元にのみ結果が表示されます。

次の図は、Cloud HSM 鍵と Cloud KMS でソフトウェア鍵を作成する場合の違いを示しています。

HSM 暗号化オペレーションの図

CMEK 統合

CMEK と Cloud HSM を併用すると、HSM 鍵を使用して一部の Google Cloud サービス内のデータを保護できます。Cloud HSM 鍵を使用するように CMEK 対応サービスを構成するのは、サービス固有の手順に沿って HSM 保護レベルで鍵を選択するのと同じくらい簡単です。

呼び出し元が CMEK 対応サービスに対してデータを読み取り / 書き込みする際、鍵を使用する直接的な権限は必要ありません。また、鍵が HSM に保存されているかを呼び出し元が知っている必要はありません。

CMEK オペレーションのフローは、通常の暗号オペレーションのフローとよく似ていますが、次の点が異なります。

  • CMEK 対応サービスからのリクエストは Google のネットワーク内で開始され、GFE を走査する必要はありません。
  • Cloud Key Management Service API は、CMEK 対応サービスのサービス アカウントに、鍵を使用するための適切な権限があることを確認します。Cloud Key Management Service API は、CMEK 対応サービスのエンドユーザーの権限を検証しません。

Cloud HSM は Google Cloud のハードウェア鍵管理サービスです。HSM 鍵で保存データを保護したいユーザーにさまざまなメリットがあります。このサービスは、HSM への API アクセスのロックダウン、容易なスケーリング、鍵の厳密なリージョン化の原則を考慮して設計されています。

Cloud HSM は、すべての Google Cloud リージョン(マルチリージョンとグローバルを含む)で Cloud HSM の最も重要なサービスとプレゼンスに対するサポートを CMEK で提供しています。このサービスは、FIPS 140-2 レベル 3 認定デバイスで保護された鍵を使用して、機密データがどこにあっても簡単に保護できるように設計されています。

次のステップ

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