単一テナント Cloud HSM の概要

このドキュメントでは、シングルテナント Cloud HSM のコンセプトと機能の概要について説明します。

単一テナント Cloud HSM を使用すると、Cloud HSM の単一テナント インスタンスを作成して管理できます。単一テナント Cloud HSM インスタンスは、お客様専用のハードウェア セキュリティ モジュール（HSM）上のパーティションの専用クラスタです。各インスタンスは、マルチテナント Cloud HSM と同じ冗長性と高可用性を提供します。各シングルテナント Cloud HSM クラスタは、選択したリージョン内の複数のゾーンにある複数の HSM に分散されます。各パーティションは、HSM 上の他のパーティションから暗号的に分離されています。

クラスタへの Google のアクセスを許可または拒否できます。クラスタはインスタンス管理者が管理します。インスタンス管理者は、2 要素認証（2FA）に非対称制御鍵を使用するクォーラム承認モデルを使用してインスタンスを制御します。コントロール鍵はGoogle Cloudの外部で作成するため、Google がプライベート コントロール鍵にアクセスすることはありません。

シングルテナント Cloud HSM インスタンスを構成すると、Cloud KMS 管理者はシングルテナント鍵を作成できます。また、デベロッパーは、コードを変更することなく、他の Cloud HSM 鍵と同様にシングルテナント鍵を使用できます。

単一テナント Cloud HSM を使用すると、費用が発生します。料金情報については、Cloud KMS の料金をご覧ください。

クォーラムベースの認証

シングルテナント Cloud HSM は、クォーラム ベースの認証を使用して、重要なオペレーションが複数のインスタンス管理者の承認を得るようにします。シングルテナント インスタンスを作成する前に、Cloud KMS の外部で非対称制御鍵のセットを作成し、インスタンスに対するオペレーションに必要な承認の数を定義する必要があります。たとえば、インスタンスが 5 人の管理者によって管理されている場合、インスタンスに対する各メンテナンス オペレーションを 3 人の管理者が承認することを要求できます。

クォーラム認証が必要なオペレーションには、次の 3 つのステージがあります。

  1. 提案: インスタンス管理者がオペレーション（新しい制御キーの登録など）を提案します。提案により、システムの現在の状態の不変スナップショットが作成されます。提案は 24 時間後に期限切れになります。承認されたオペレーションが開始されるまで、いつでもキャンセルできます。

  2. 承認: 必要な数の管理者が、固有の制御キーを使用してチャレンジに署名する必要があります。署名付きチャレンジは、オペレーションを承認する管理者を指定します。十分な数の署名付きチャレンジが準備できたら、インスタンス管理者がそれらをアップロードして提案を承認します。チャレンジが有効で、プロポーザルの有効期限が切れていない場合、プロポーザルは承認されます。

  3. 実行: プロポーザルが承認された後、有効期限が切れる前に、提案されたオペレーションを実行できます。

単一テナント Cloud HSM の機能

このセクションでは、シングルテナント Cloud HSM のコア機能について説明します。

インスタンスの管理

管理者は、シングルテナント Cloud HSM インスタンスのライフサイクルを管理します。

  • インスタンスを作成する: 単一リージョンに新しいインスタンスをプロビジョニングします。作成プロセスでは、クォーラム認証を設定する必要があります。
  • インスタンス情報を取得する: インスタンスのメタデータと構成をクエリできます。このオペレーションでは、クォーラム認証は必要ありません。
  • インスタンスを無効または有効にする: インスタンスを一時的に無効にすると、パーティションに対する Google のアクセス権が取り消されます。インスタンスは後で有効にできます。どちらのオペレーションでもクォーラム認証が必要です。インスタンスを有効にすると、有効化操作の時点から disableDate が 120 日にリセットされます。インスタンスが無効になっている間は、インスタンスで作成されたすべての鍵が使用できなくなり、それらの鍵を使用しようとするすべてのオペレーションが失敗します。
  • インスタンスを更新する: インスタンスを定期的に更新して、利用可能な状態を維持する必要があります。インスタンスは 120 日以内に更新する必要があります。各インスタンスには、インスタンスの更新期限が切れるタイミングを示す disableDate があります。インスタンスを更新すると、disableDate が更新時から 120 日にリセットされます。このオペレーションにはクォーラム認証が必要です。disableDate 時までに更新されないインスタンスは自動的に無効になります。
  • インスタンスを削除する: インスタンスを削除できます。インスタンスを削除すると、そのインスタンスで作成されたすべての鍵が完全に破棄されます。これは、元に戻せない破壊的なオペレーションです。インスタンスで作成された鍵を使用して暗号化されたすべてのデータを暗号シュレディングする場合を除き、インスタンスを削除しないでください。このオペレーションにはクォーラム認証が必要です。

鍵管理

管理者は、クォーラム認証に使用する制御鍵を所有します。デベロッパーや他のリソース オーナーが、インスタンスで暗号鍵を作成して使用します。

  • 管理者制御鍵をローテーションする: 管理者は、管理クォーラムのメンバーの 2FA 制御鍵をローテーションできます。このオペレーションにはクォーラム認証が必要です。
  • 暗号鍵を生成する: デベロッパーとリソース オーナーは、単一テナント HSM 保護レベルで CryptoKey を作成できます。このオペレーションでは、クォーラム認証は必要ありません。
  • 暗号オペレーションを実行する: 作成された後、シングルテナント インスタンスに保存された鍵は、他の Cloud Key Management Service 鍵と同様に暗号オペレーションに使用できます。

単一テナント Cloud HSM のベスト プラクティス

シングルテナント Cloud HSM を使用する場合は、次のベスト プラクティスに従ってください。

  • プロジェクト リーエン: プロジェクト リーエンを使用して、アクティブなシングルテナント Cloud HSM インスタンスを含むプロジェクトを保護します。シングルテナント Cloud HSM インスタンスを含むプロジェクトを削除すると、そのインスタンスで作成された鍵は復元できません。
  • 物理トークン: 物理トークンを使用して、インスタンス管理者のプライベート 2FA キーを保持します。これらの物理トークンは安全に保管してください。鍵のクォーラムを失った場合、Google はインスタンスへのアクセス権を復元できません。インスタンスは定期的に更新する必要があるため、鍵のクォーラムを失うと、最終的にインスタンスが無効になります。
  • バックアップ キー: 定足数メンバーが保持するキーに加えて、少なくとも 1 つの予備の 2FA キーを登録します。クォーラム メンバーのキーが紛失または盗難された場合にアクセスできるように、バックアップ キーを安全な場所に保管します。
  • 職掌分散: インスタンス管理者の職掌分散を維持します。提案、承認、実行には個別の IAM ロールが必要です。これらのロールは少なくとも 2 人のユーザーに分散して割り当て、1 人のユーザーが 3 つのロールすべての権限を持たないようにする必要があります。ユーザーがすべての基盤となる権限を持っている場合、データが誤って削除されたり、意図的に削除されたりするリスクが高くなります。
  • 鍵の配布: 信頼できるユーザー間で 2 段階認証プロセスの秘密鍵が安全に配布されていることを確認します。クォーラムを達成するのに十分な数の秘密鍵を保持する個人は存在しないようにします。必要なクォーラム サイズを満たすのに十分な数の秘密鍵に個人がアクセスできる場合、偶発的または意図的なデータ損失のリスクが高まります。
  • 更新スケジュール: Single-tenant Cloud HSM インスタンスの更新を継続的なメンテナンス手順に組み込みます。各インスタンスの disableDate をモニタリングし、その時間までに更新オペレーションを完了する必要があります。インスタンスの更新にはクォーラムの承認が必要なため、disableDate の前に提案が承認されて実行されるように、更新オペレーションを十分に早い段階で提案してください。

次のステップ