Cloud HSM アーキテクチャ
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

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

Cloud HSM は Cloud Key Management Service（Cloud KMS）アーキテクチャの一部であり、ハードウェアで保護された鍵のプロビジョニングと管理のためのバックエンドを備えています。企業やコンプライアンスの規制を遵守できるように、Cloud HSM では暗号鍵を生成し、FIPS 140-2 レベル 3 認定ハードウェアセキュリティモジュール（HSM）で暗号オペレーションを実行できます。

このドキュメントでは、ハードウェアの管理方法や鍵の認証と作成の方法など、Cloud HSM のアーキテクチャについて説明します。Cloud KMS の詳細については、Cloud Key Management Service の暗号化をご覧ください。

概要

暗号オペレーションには次のようなものがあります。

保存データを暗号化する
Certificate Authority Service の秘密鍵を保護する
データ暗号鍵を保護して、暗号化されたデータと一緒に保存できるようにする
デジタル署名や認証などの暗号オペレーションに非対称鍵を生成して使用する

Cloud HSM は、ファームウェアバージョン 3.4（ビルド 09）の Marvell LiquidSecurity HSM（モデル CNL3560-NFBE-2.0-G および CNL3560-NFBE-3.0-G）を使用します。Google が保持する認証の詳細については、Certificate #4399 をご覧ください。HSM デバイスとハードウェアで保護された鍵については、キー構成証明をご覧ください。

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

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

Cloud HSM は、より広い地域にまたがるマルチリージョンを含め、世界中のすべての Google Cloud リージョンで利用できます。ハードウェアで保護された鍵を Cloud HSM で作成して使用するには、Cloud KMS サービスエンドポイントを使用する必要があります。これにより、BigQuery、Cloud Storage、Persistent Disk など、他のGoogle Cloud サービスに保存されているデータも保護できます。

Cloud HSM を使用すると、HSM ハードウェアを自分で管理しなくても、ハードウェアで保護された鍵を使用できます。Google は、デプロイ、構成、モニタリング、パッチ適用、メンテナンスなど、HSM ハードウェアを所有して管理します。Cloud HSM を使用すると、データは Google Cloudの他のテナントやサービスから厳密に分離されます。Cloud Key Management Service API の一部である Cloud HSM データプレーン API を使用すると、ハードウェアで保護された鍵をプログラムで管理できます。

Google Cloud サービスで CMEK 鍵がサポートされている場合、Cloud HSM はハードウェアで保護された Cloud KMS Autokey と顧客管理の暗号鍵（CMEK）をサポートします。たとえば、自身で管理する Cloud HSM 鍵を使用して、Cloud Storage バケットや Cloud SQL テーブルのデータを暗号化できます。

Cloud HSM の管理

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

HSM ハードウェアの抽象化

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

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

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

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

次の図は、Cloud HSM のアーキテクチャを示しています。

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

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

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

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

Cloud HSM の地域の図

リージョンとマルチリージョンごとに鍵を分離するため、各 Cloud HSM リージョンは個別の HSM リージョンのラッピング鍵に関連付けられます（鍵の作成の図を参照）。高可用性をサポートするため、ラッピング鍵は、リージョンに物理的に配置されている各 HSM のパーティションにクローンが作成されます。HSM リージョンの鍵は、そのロケーションの HSM から移動することはありません。クローンの作成により、同じリージョンの HSM は同じ顧客鍵のセットを提供し、リージョン外の HSM はそれらの鍵を提供できなくなります。

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

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

一元管理

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

ハードウェアで保護された鍵は、Cloud KMS の他の鍵と、Cloud External Key Manager（Cloud EKM）の外部管理鍵と一緒に管理します。
ハードウェアで保護された鍵へのアクセスを IAM 内で管理します。
ハードウェアで保護された鍵を使用する暗号オペレーションのレポート費用は、Cloud Billing で報告されます。
ハードウェアで保護された鍵は、CMEK を使用したリソースの暗号化をサポートするすべての Google Cloudサービスで透過的に使用できます。CMEK を統合するには、CMEK 鍵と暗号化するデータを互換性のある地理的位置に配置する必要があります。Cloud HSM 鍵の地理的な制限が厳しいため、CMEK データのすべての暗号化と復号も地理的に制限されます。
ハードウェアで保護された鍵の管理オペレーションは、常に 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 のソフトウェア鍵を使用してハードウェアで保護された鍵をサポートする既存のアプリケーションを更新する際に、コードを変更する必要はありません。代わりに、使用する鍵のリソース名を更新します。

PKCS#11 のサポート

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

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

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

暗号鍵の証明書

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

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

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

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

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

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 に到達しません。

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

リクエストフロー

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

鍵の作成

ハードウェアで保護された鍵を作成する場合、Cloud Key Management Service API は鍵マテリアルを作成しませんが、HSM に鍵の作成をリクエストします。

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

次の図は、ハードウェアで保護された鍵が Cloud KMS でラップされる方法を示しています。

HSM 鍵の作成図。

鍵の作成プロセスは次のようになります。

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

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

暗号オペレーション

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

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

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

次の図は、Cloud KMS でハードウェアで保護された鍵とソフトウェアで保護された鍵を作成する際の違いを示しています。

CMEK 統合

ハードウェアで保護された鍵はすべて CMEK です。Cloud HSM 鍵を使用するように CMEK 対応サービスを構成するのは、サービス固有の手順に沿って HSM 保護レベルで鍵を選択するのと同じくらい簡単です。

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

ハードウェアで保護された鍵とソフトウェアで保護された鍵では、同じ CMEK オペレーションフローが使用されますが、ハードウェアで保護された鍵を使用する場合は次の例外があります。

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

Autokey を使用して Cloud KMS 鍵をプロビジョニングする場合は、Cloud HSM が必要です。Autokey を使用すると、Cloud KMS サービスエージェントはリクエストに応じてハードウェアで保護された鍵を自動的にプロビジョニングできます。詳細については、CMEK の自動プロビジョニングをご覧ください。

独自の HSM を使用する

Cloud HSM が使用する HSM は Google によって管理されます。ただし、特定の状況では、組織は独自の HSM を使用して、ワークロードのハードウェアで保護された鍵を保存することを検討する必要があります。たとえば、独自の HSM を使用すると、ワークロードを Google Cloudに移行する際に役立つ可能性があります。

特定のロケーションでのみ、Google は、Google Cloudで安全な暗号トランザクション用の暗号鍵オペレーションを提供するインフラストラクチャ HSM-as-a-Service（HSMaaS）を提供しています。これらのプロダクトは、ベアメタルラック HSM とベアメタル HSM と呼ばれます。ベアメタルラック HSM またはベアメタル HSM では、独自の HSM を購入して構成し、Google データセンターに送って Google がホストできるようにします。HSM への完全な論理アクセス権はお客様が維持し、デバイスの管理とトラブルシューティングは HSM ベンダーと直接連携して行う必要があります。Google は、物理セキュリティとネットワークセキュリティ、ラックスペース、電力、ネットワーク統合を有料で提供しています。詳細については、ベアメタルラック HSM とベアメタル HSM をご覧ください。

次のステップ

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

Cloud HSM アーキテクチャ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要