Cloud Service
Cloud KMS
Google Cloud 上で暗号鍵を集中管理するマネージドサービス。GCS/永続ディスク/BigQuery 等と統合し、鍵のアクセス制御・自動ローテーション・利用監査を提供。AWS KMS に相当。
- 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=「シークレット値(パスワード/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 KMS | AWS KMS |
|---|---|---|
| 位置づけ | 暗号鍵の集中管理(マネージド) | 暗号鍵の集中管理(マネージド) |
| 鍵の単位 | CryptoKey + CryptoKeyVersion | KMSキー(CMK) + 鍵マテリアル |
| 利用者管理の暗号化 | CMEK | カスタマー管理キー(CMK) |
| 鍵の持ち込み/外部保持 | CSEK / Cloud EKM | 外部キーマテリアルのインポート / External Key Store(XKS) |
| 専用HSM | Cloud HSM(FIPS 140-2 Lv3) | AWS CloudHSM / KMS HSMバックエンド |
| シークレット値の保管 | Secret Manager(別サービス) | Secrets Manager(別サービス) |
| 利用監査 | Cloud Audit Logs | CloudTrail |
ハンズオン / 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
他クラウドの同等サービス
役割が近いサービスです。設計の置き換えや比較検討の参考に。