TL

Cloud Service

Cloud KMS

Google Cloud 上で暗号鍵を集中管理するマネージドサービス。GCS/永続ディスク/BigQuery 等と統合し、鍵のアクセス制御・自動ローテーション・利用監査を提供。AWS KMS に相当。

中級セキュリティ運用上の優秀性
最終更新: 2026-06-03公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.暗号化の鍵を安全に作り・管理し・監査するマネージドな金庫。
  • 2.CMEK で各サービスの暗号鍵を握り、自動ローテと利用監査が可能。
  • 3.鍵は用途・環境ごとに分け、暗号化と復号のロールを分離する。

解決する課題

データを暗号化したいが、鍵そのものの管理・統制が重荷になります。Cloud KMS はその「鍵」のライフサイクルをマネージドに引き受けます。

  • データを暗号化したいが、鍵の生成・保管・破棄の管理が大変
  • 鍵のアクセス制御・ローテーション・監査を組織として統制したい
  • 各サービスの暗号化を CMEK(顧客管理の暗号鍵) で一元的に扱いたい
  • FIPS 140-2/140-3 や鍵主権など、コンプライアンス要件を満たしたい

主要概念と用語

  • キーリング(KeyRing): 鍵をまとめる入れ物。ロケーション(リージョン/マルチリージョン/グローバル)に紐づき、後から移動・削除できない
  • 鍵(CryptoKey): 暗号化の論理単位。用途は対称暗号化、非対称暗号化、非対称署名、MAC(HMAC)から選ぶ
  • 鍵バージョン(CryptoKeyVersion): 実際の鍵マテリアル。ローテーションのたびに新バージョンが作られ、PRIMARY/ENABLED/DISABLED/DESTROY_SCHEDULED 等の状態を持つ
  • 保護レベル(Protection Level): SOFTWARE(ソフトウェア)、HSM(Cloud HSM の専用ハードウェア)、EXTERNAL/EXTERNAL_VPC(Cloud EKM で外部キー管理を参照)
  • CMEK(Customer-Managed Encryption Key): 利用者が管理する鍵で各サービスを暗号化する仕組み(AWS のカスタマー管理キー相当)
  • CSEK(Customer-Supplied Encryption Key): 利用者が鍵そのものを持ち込み、Google には保持させない方式(GCS / Compute の一部のみ)
  • エンベロープ暗号化: データ暗号鍵(DEK)でデータを暗号化し、その DEK を Cloud KMS の鍵暗号鍵(KEK)で暗号化して保管
  • Cloud HSM / Cloud EKM: FIPS 140 Level 3 の専用 HSM/外部 KMS との連携が必要な場合の選択肢

仕様・制限・クォータ

  • デフォルト暗号化: Google Cloud は保存データを既定で暗号化済み。Cloud KMS は CMEK でその鍵を利用者管理に置き換える
  • ロケーション: 鍵はリージョン(例 asia-northeast1)、マルチリージョン(例 asia)、global のいずれかに作成。CMEK はリソースと同一ロケーションの鍵が原則
  • 自動ローテーション: 対称鍵は --rotation-period でローテーション間隔を設定可能(非対称鍵・HSM 由来の一部は自動ローテーション非対応で手動)
  • 鍵の削除: 鍵バージョンは即時削除されず、既定 24時間〜最大120日の「破棄予定(DESTROY_SCHEDULED)」期間を経て破棄。期間内なら復元可能
  • 暗号化サイズ上限: encrypt で直接扱える平文は対称鍵で最大 64 KiB。それ以上はエンベロープ暗号化(DEK)を使う
  • クォータ: 暗号オペレーション(cryptoKeyVersions.useToEncrypt/Decrypt 等)には QPS のレート上限があり、必要に応じ引き上げ申請が可能

内部の仕組み

Cloud KMS はエンベロープ暗号化を前提に設計されています。実データは高速な**データ暗号鍵(DEK)で暗号化し、その DEK 自体を Cloud KMS の鍵暗号鍵(KEK)**で暗号化(ラップ)して保管します。復号時はラップされた DEK の復号(アンラップ)を Cloud KMS に依頼し、得た平文 DEK でデータを復号します。

  • KEK のマテリアルは Cloud KMS の外に平文で出ません。SOFTWARE はソフトウェアバックエンド、HSM は FIPS 140-2 Level 3 認証の HSM 内に閉じ込められます
  • 鍵の利用(暗号化/復号/署名)と管理操作は Cloud Audit Logs(Data Access / Admin Activity)に記録され、誰がいつどの鍵バージョンを使ったかを監査できます
  • GCS や永続ディスクなどの CMEK 統合では、サービス側が DEK を生成し、利用者の KMS 鍵(KEK)でラップして自動的にエンベロープ暗号化します
Cloud KMS と Secret Manager の違い

Cloud KMS=「鍵」の管理(暗号鍵の生成・ラップ・ローテーション・署名)、Secret Manager=「シークレット値(パスワード/APIキー)」の保管・バージョン管理。役割が別で、Secret Manager 自体の保存暗号化に CMEK を使う、という組み合わせも可能です。

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

  • 統制が要るデータは CMEK を使い、鍵のアクセス制御・ローテーション・監査を利用者側で握る
  • 対称鍵+自動ローテーション--rotation-period--next-rotation-time)を基本とし、用途・環境・データ分類ごとに鍵を分割
  • 64 KiB を超えるデータは アプリ側でエンベロープ暗号化(KMS で DEK を生成・ラップ、Tink ライブラリの利用が推奨)
  • IAM は鍵リソース単位で最小権限に。暗号化と復号を別ロール(cryptoKeyEncrypter / cryptoKeyDecrypter)に分離
  • 厳格な鍵主権要件は Cloud EKM、FIPS Level 3 専用 HW 要件は Cloud HSM を選択

運用・監視

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

コスト

課金は「有効な鍵バージョン数(月額)」+「暗号オペレーションのリクエスト数」が基本です。保護レベルや外部連携で単価が変わります。

項目課金の考え方コスト最適化のヒント
ソフトウェア鍵有効な鍵バージョンごとの月額 + オペレーション課金不要バージョンを破棄し、用途で鍵を集約しすぎない範囲で整理
Cloud HSM 鍵HSM バージョンの月額 + オペレーション課金(単価高め)厳格要件のデータに限定して使い、汎用データはソフトウェア鍵に
Cloud EKM 鍵EKM 連携バージョンの月額 + オペレーション + 外部KMS費用外部参照が必須の鍵主権要件のみに限定
暗号オペレーションencrypt/decrypt/sign 等のリクエスト数で従量課金大容量データはエンベロープ暗号化(DEK)で呼び出し回数を削減

セキュリティ

  • 鍵リソースごとに IAM で最小権限。暗号化(cloudkms.cryptoKeyEncrypter)と復号(cloudkms.cryptoKeyDecrypter)のロールを用途で分離する
  • データ分類・環境(本番/検証)ごとに鍵を分割し、自動ローテーションを設定
  • 鍵主権・FIPS Level 3 要件は Cloud EKM / Cloud HSM。組織全体の暗号化方針は 組織ポリシー(CMEK 必須化など)で強制
  • 削除は即時ではなく破棄予定期間を活用し、誤破棄に備える
アンチパターン

プロジェクト全体や本番・検証のデータをたった1つの鍵で暗号化し、しかも roles/owner 等の広すぎる権限を鍵に付与するのは NG。 鍵を用途・環境・データ分類ごとに分割し、暗号化/復号ロールを最小権限で割り当て、ローテーションと監査ログ(Data Access)を有効化しましょう。

関連サービス・比較(AWS との対応)

観点Google Cloud KMSAWS KMS
位置づけ暗号鍵の集中管理(マネージド)暗号鍵の集中管理(マネージド)
鍵の単位CryptoKey + CryptoKeyVersionKMSキー(CMK) + 鍵マテリアル
利用者管理の暗号化CMEKカスタマー管理キー(CMK)
鍵の持ち込み/外部保持CSEK / Cloud EKM外部キーマテリアルのインポート / External Key Store(XKS)
専用HSMCloud HSM(FIPS 140-2 Lv3)AWS CloudHSM / KMS HSMバックエンド
シークレット値の保管Secret Manager(別サービス)Secrets Manager(別サービス)
利用監査Cloud Audit LogsCloudTrail

ハンズオン / CLI例

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

# 対称暗号化用の鍵を作成し、90日ごとの自動ローテーションを設定
gcloud kms keys create app-data-key \
  --location asia-northeast1 \
  --keyring app-keyring \
  --purpose encryption \
  --rotation-period 90d \
  --next-rotation-time 2026-09-01T00:00:00Z

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

# ファイルを暗号化(平文は64KiB以下。base64で暗号文を保存)
gcloud kms encrypt \
  --location asia-northeast1 \
  --keyring app-keyring \
  --key app-data-key \
  --plaintext-file secret.txt \
  --ciphertext-file secret.txt.enc

# 復号して元に戻す
gcloud kms decrypt \
  --location asia-northeast1 \
  --keyring app-keyring \
  --key app-data-key \
  --ciphertext-file secret.txt.enc \
  --plaintext-file secret.dec.txt

# CMEK で暗号化した GCS バケットを作成(バケットのデフォルト鍵に指定)
gcloud storage buckets create gs://my-cmek-bucket \
  --location asia-northeast1 \
  --default-encryption-key projects/PROJECT_ID/locations/asia-northeast1/keyRings/app-keyring/cryptoKeys/app-data-key

Google Cloud Service

Cloud KMSを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

セキュリティ・ID

比較で見る軸

クラウド: Google Cloud / カテゴリ: セキュリティ・ID / 難易度: intermediate

導入後に効く点

CMEK で各サービスの暗号鍵を握り、自動ローテと利用監査が可能。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
セキュリティ・ID
難易度
intermediate
関連資格
設計柱
security / operational

判断チェックリスト

  • 自社の用途が「セキュリティ・ID / security」に近いか確認する。
  • 強みである「暗号化の鍵を安全に作り・管理し・監査するマネージドな金庫。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

セキュリティ・IDsecurityoperational

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。