Cloud HSM (Cloud KMS)

解決する課題

暗号鍵をマネージドに扱いたいが、鍵マテリアルがソフトウェア上に存在すること自体を規制やポリシーが許さない場面があります。Cloud HSM は Cloud KMS の保護レベルの一つとして、鍵を FIPS 140-2 Level 3 認証の専用ハードウェア（HSM） の内部に閉じ込めて生成・利用します。

• 金融・公共・医療など、HSM での鍵保護が要件として定められている
• 鍵マテリアルをソフトウェアやメモリ上に平文で出したくない
• ただし HSM クラスタの調達・冗長化・パッチ・可用性管理は自前で抱えたくない
• 既存の Cloud KMS の API・IAM・監査の仕組みはそのまま使い回したい

主要概念と用語

• 保護レベル（Protection Level）: 鍵マテリアルをどこに置くかの指定。SOFTWARE、HSM（Cloud HSM）、EXTERNAL（Cloud EKM）から選ぶ。Cloud HSM は鍵作成時に --protection-level hsm を指定したもの
• HSM（Hardware Security Module）: 鍵を内部で生成・保管し、暗号処理だけを外に提供する耐タンパーな専用ハードウェア
• FIPS 140-2 Level 3: 米国 NIST の暗号モジュール認証規格の水準。物理的な耐タンパーやアイデンティティベースの認証などを要求する。Cloud HSM の HSM はこの水準で認証されている
• キーリング / 鍵 / 鍵バージョン: Cloud KMS と共通の概念。Cloud HSM 鍵も KeyRing の下の CryptoKey とその CryptoKeyVersion として扱う
• アテステーション（Attestation）: 鍵バージョンが実際に正規の HSM 内で生成・保持されていることを示す、HSM 製造元の署名付き証明
• インポート: 外部で生成した鍵マテリアルを HSM に取り込む方式。Cloud KMS のインポートジョブ経由でラップして持ち込む
• CMEK（Customer-Managed Encryption Key）: 各サービスの暗号化に利用者管理の鍵を使う仕組み。その鍵の保護レベルとして Cloud HSM を選べる

仕様・制限・クォータ

• 位置づけ: 独立サービスではなく Cloud KMS の保護レベル。課金・クォータ・公式ドキュメントも Cloud KMS の一部として扱われる
• 対応用途: 対称暗号化、非対称暗号化・署名、MAC など、Cloud KMS が提供する主要な鍵用途に対応（提供範囲はリージョンや時期で変わるため公式参照）
• ロケーション: 鍵はリージョン／マルチリージョン等のロケーションに作成し、CMEK は原則リソースと同一ロケーションの鍵を使う。Cloud HSM が利用できるロケーションは限られるため事前確認が必要
• 鍵マテリアルの境界: HSM 鍵のマテリアルは HSM の外に平文で出ない。エクスポート不可で、利用は暗号オペレーション API 経由に限られる
• アテステーション: 各 HSM 鍵バージョンについてアテステーションを取得でき、HSM 由来であることを検証できる
• クォータ: 暗号オペレーションには QPS のレート上限があり、ソフトウェア鍵とは別枠になりうる。具体値は変動するため公式のクォータページを参照

内部の仕組み

Cloud HSM では、鍵マテリアルが HSM の内部で生成され、その境界を平文で越えません。利用者は Cloud KMS の API を通じて「この鍵バージョンで暗号化・復号・署名してほしい」と依頼し、実際の暗号処理は HSM 内で行われます。Google が HSM クラスタの冗長構成・容量・パッチ・物理セキュリティを運用するため、利用者は HSM 機器を意識せずマネージドに使えます。

• 鍵の利用・管理操作は Cloud Audit Logs（Data Access / Admin Activity）に記録され、誰がいつどの鍵バージョンを使ったかを監査できる
• 各 HSM 鍵バージョンには アテステーション が紐づき、鍵が正規の HSM 内に存在することを暗号学的に検証できる
• 大きなデータは エンベロープ暗号化 が基本。ローカルで生成したデータ暗号鍵（DEK）でデータを暗号化し、その DEK を HSM 鍵（KEK）でラップして保管する

設計パターン / ベストプラクティス

• 規制・ポリシーで HSM 保護が要求されるデータに限定して Cloud HSM 鍵を使い、汎用データはソフトウェア鍵に分けてコストを抑える
• 用途・環境・データ分類ごとに鍵を分割し、対称鍵は自動ローテーションを設定する
• 重要なリソースは CMEK の保護レベルに HSM を指定し、暗号化を利用者側の鍵で統制する
• 監査要件が厳しい場合は、鍵バージョンの アテステーションを取得・保管して HSM 由来を証明できるようにする
• HSM が利用できるロケーションを設計初期に確認し、対象リソースと同一ロケーションに鍵を配置する

運用・監視

• 鍵の利用・管理は Cloud Audit Logs で監査する。Data Access ログは明示的な有効化が必要
• PERMISSION_DENIED 時は対象鍵の IAM ポリシー と、呼び出し元のロール（暗号化／復号）を確認する
• CMEK で暗号化したリソースが読めない場合は、鍵バージョンの無効化・破棄予定やサービスエージェントへの権限付与漏れを疑う
• ローテーション後はプライマリバージョンと鍵の状態（有効／無効／破棄予定）を確認する
• レート上限に当たる場合は エンベロープ暗号化（DEK） でクライアント側に処理を寄せ、HSM 呼び出し回数を削減する

コスト

課金は Cloud KMS と同じく「有効な鍵バージョン数（月額）」＋「暗号オペレーションのリクエスト数」が基本です。Cloud HSM 鍵はソフトウェア鍵より単価が高い傾向があるため、用途を絞るのがコスト最適化の要点です。

セキュリティ

• 鍵リソースごとに IAM で最小権限。暗号化（cloudkms.cryptoKeyEncrypter）と復号（cloudkms.cryptoKeyDecrypter）のロールを用途で分離する
• HSM 鍵のマテリアルはエクスポート不可で、平文が境界を越えない点を前提に設計する
• 監査要件には アテステーション と Cloud Audit Logs（Data Access） を組み合わせ、HSM 由来と利用履歴の両方を残す
• 組織全体の暗号化方針は 組織ポリシー で強制し、重要リソースに CMEK と HSM 保護レベルを必須化する
• 削除は即時ではなく破棄予定期間を活用し、誤破棄に備える

関連サービス・比較

最も近い選択肢は同じ Cloud KMS の ソフトウェア保護レベル です。保護の強さ・コスト・要件適合の観点で比較します。

ハンズオン / CLI例

# キーリングを作成（ロケーションは作成後に変更不可）
gcloud kms keyrings create hsm-keyring \
  --location asia-northeast1

# HSM 保護レベルの対称暗号鍵を作成し、自動ローテーションを設定
gcloud kms keys create hsm-data-key \
  --location asia-northeast1 \
  --keyring hsm-keyring \
  --purpose encryption \
  --protection-level hsm \
  --rotation-period 90d \
  --next-rotation-time 2026-09-01T00:00:00Z

# 鍵バージョンのアテステーション（HSM由来の証明）を取得
gcloud kms keys versions describe 1 \
  --location asia-northeast1 \
  --keyring hsm-keyring \
  --key hsm-data-key \
  --attestation-file hsm-key-attestation.dat

# サービスアカウントに復号権限のみを最小権限で付与
gcloud kms keys add-iam-policy-binding hsm-data-key \
  --location asia-northeast1 \
  --keyring hsm-keyring \
  --member "serviceAccount:app@PROJECT_ID.iam.gserviceaccount.com" \
  --role roles/cloudkms.cryptoKeyDecrypter

# HSM 鍵を CMEK としてデフォルト指定した GCS バケットを作成
gcloud storage buckets create gs://my-hsm-cmek-bucket \
  --location asia-northeast1 \
  --default-encryption-key projects/PROJECT_ID/locations/asia-northeast1/keyRings/hsm-keyring/cryptoKeys/hsm-data-key