服務定位

AWS KMS 的核心定位是 AWS-only 的 multi-tenant managed key management，FIPS 140-2 Level 3 認證、跨服務 envelope encryption 的共同地基。跟 CloudHSM 比、KMS 是 managed + shared HSM 池、CloudHSM 是 single-tenant dedicated HSM；需要更高隔離 / 自管 cluster / FIPS Level 3 single-tenant 時走 CloudHSM、或用 KMS Custom Key Store 把 KMS 後端指向自己的 CloudHSM。跟 Google Cloud KMS / Azure Key Vault 比、設計概念相近、但 KMS 把 secret store 切出去（Secrets Manager）、Key Vault 則把兩者合一。

跟 Vault transit engine 比、行為相似（key 不離 service、app 拿 ciphertext）、但治理面完全不同：KMS 綁 AWS 控制面、IAM + Key Policy 雙層授權、CloudTrail 是稽核入口；Vault transit 是跨雲統一介面、token + policy 為主、需要自管 cluster。AWS-heavy 組織首選 KMS、跨雲組織才會把 KMS 當下游、上游用 Vault transit 抽象。

本章目標

讀完本頁、讀者能判斷：

1. 哪些資料 / 場景該用 Customer Managed KMS Key、哪些 AWS Managed Key 已經夠用、什麼時候直接走 CloudHSM
2. Key Policy + IAM + Grant 三層授權的分工、production 必開的 CloudTrail Data event 與 monitor 範圍
3. Multi-Region Key、Custom Key Store、External Key Store、BYOK 等進階形態的取捨
4. KMS 出事（IAM 過寬、Key Policy 把自己鎖死、Schedule Deletion 誤觸發）時的判讀路徑跟回退選項

最短判讀路徑

判斷一個 AWS KMS deployment 是否健康、最少看四件事：

• Key Policy 設計：是否含 root principal（不然 key 變孤兒）、是否走 least privilege（不是 kms:* 給整個 account）、admin / user / monitor 三類 principal 是否分開、policy 變更是否走 PR review
• Grant 治理：哪些 service-to-service 短期授權走 Grant（rotation Lambda / RDS / EBS）、Grant TTL 是否設、廢棄 grant 是否定期 RetireGrant
• Multi-Region 與 rotation 策略：是否啟用 annual automatic rotation（適用 symmetric encryption key）、Multi-Region Key 的 replica 是否跟 DR plan 對齊、asymmetric / signing key 的 manual rotation 流程是否有 runbook
• CloudTrail Data Event 必開：management event 預設記、但 Encrypt / Decrypt / GenerateDataKey 是 data event、預設不記 — 沒這層 forensic 沒著力點、Storm-0558 對照下完全無法回答「誰用哪把 key 簽了什麼 token」

四件事任一缺失、就回到 7.6 秘密管理與機器憑證治理 跟 Audit Log 的補丁清單。

日常操作與決策形狀

Key Type 選擇：symmetric encryption key（AES-256-GCM、最常用、S3 / EBS / RDS / Secrets Manager 都走這個）；asymmetric key pair（RSA / ECC、用於 sign / verify 或 encrypt / decrypt、JWT 簽署、CodeSign、文件簽章）；HMAC key（generate / verify MAC、API request signing）。對應 Storm-0558 signing key chain — 自己 host signing key 出事的核心教訓是 key 不該離 HSM service、所以 JWT signing 用 asymmetric KMS key 是 baseline 設計、private key 永遠不離 KMS。

Key Origin（key material 來源）：AWS_KMS（KMS 內部生成、預設）；EXTERNAL（BYOK、組織自己生成 key material、import 進 KMS、可以隨時 reimport 或刪除）；AWS_CLOUDHSM（Custom Key Store、key material 存在自己的 CloudHSM cluster）；EXTERNAL_KEY_STORE（XKS、AWS 外的 HSM、控制面在 AWS、key material 在 on-prem）。多數場景用 AWS_KMS 就夠、合規 / 主權需求才走 EXTERNAL / Custom Key Store。

Key Policy 跟 IAM 的雙層：KMS 跟其他 AWS service 最大差異是 Key Policy 是主要授權機制、IAM policy 單獨不夠。Key Policy 必含 arn:aws:iam::ACCOUNT_ID:root 給 root principal（不是 root user、是讓 IAM 能參與授權的開關）— 沒這條 key 變孤兒、即使 IAM 開了 admin 也救不回來。production 通常分三類 statement：admin（Create / Delete / Schedule、走 break-glass）、user（Encrypt / Decrypt / GenerateDataKey、給 app）、monitor（Describe / List、給 SRE）。

Grant 是程式化短期授權：service-to-service 整合（Secrets Manager rotation Lambda、RDS 自動加密、EBS volume attach）通常走 Grant 而不是改 Key Policy — 每個 grant 有自己的 grant token、可以帶 TTL、可以 RetireGrant / RevokeGrant 收回、不跟 key policy 永久綁定。沒治理時 grant 累積上千個 / 沒人 retire 是常見問題、跟 Failure: Credential Rotation Without Scope 同類 — 沒 scope map 等於沒治理。

Alias 與 Key ID 的解耦：alias（alias/my-app-prod-key）是 指向 key 的可變指標、key ID / ARN 是 不可變識別。production code 應該用 alias、要換 key 時只需要重綁 alias、不用改 deployment。Cross-account 跨帳號使用必須用 ARN（alias 不跨帳號）。

Key Rotation 的真實語義：annual automatic rotation（symmetric encryption key 才支援）換的是 KMS 內部的 backing key material、key ARN / Alias / Key ID 都不變、app 完全不需要動。舊資料仍用舊 backing key 解密、KMS 自動處理、不是「資料全部重新加密」— 這是常見誤解。asymmetric / HMAC key 不支援 automatic rotation、必須 manual 建新 key + alias 切換 + app 端雙讀容忍窗口（跟 JWT signing key rotation 同套路）。

Multi-Region Key：跨 region replicate 的 KMS key 共用 key material 跟 Key ID（後綴帶 mrk-）、不是建立新 key — 跨 region 加密的 ciphertext 在另一 region 可以直接 decrypt、不用 cross-region API call。適合 multi-region active-active app + DR scenario。代價是 replica region 跟 primary region 的權限要分別治理、Key Policy 不會自動同步。

Encryption Context 是 authenticated data：encrypt 時帶的 key-value pair（例：{"app": "billing", "tenant": "acme"}）、decrypt 必須提供同一組 context — 否則失敗。用來防 ciphertext 被 replay 到別的 context（攻擊者拿到 billing 的 ciphertext 想當 payroll 的 ciphertext 用）、所有 context 都會進 CloudTrail、是 forensic 上的關鍵欄位。production 一律帶 context、單純加密不帶 context 等於少一層防護。

Customer Managed vs AWS Managed vs AWS Owned：三層分權 — Customer Managed（CMK、自己控 Key Policy + 自選 rotation）、AWS Managed（aws/secretsmanager、aws/s3、AWS 管 Key Policy、看得到但改不了）、AWS Owned（完全看不見、AWS 自己用、無 CloudTrail）。production 高敏感資料應該用 Customer Managed、才能控 policy + 開 data event + 自選 rotation 週期。

核心取捨表

KMS 是 AWS 上的 預設選擇、CloudHSM 是合規 / 自管要求才上的 昇級、Vault transit 是跨雲統一介面、Google / Azure 對標品在各自雲一樣是預設選擇。

進階主題

KMS Custom Key Store + CloudHSM 整合：Custom Key Store 把 KMS 的 控制面（API、Key Policy、CloudTrail、IAM 整合）保留、但 key material 存在自己的 CloudHSM cluster。組織需要 FIPS 140-2 Level 3 single-tenant 但又不想放棄 KMS 的 service 整合（S3 SSE-KMS / EBS encryption）時用。代價是 CloudHSM cluster 的運維成本（cluster HA、user 管理、backup）。

External Key Store (XKS)：更激進的形態 — key material 完全在 AWS 之外（on-prem HSM 或第三方 HSM）、AWS 透過 XKS proxy 呼叫外部 HSM 做 cryptographic operation。用於 資料主權 場景（金融 / 政府 / 跨境合規要求 key 不出組織邊界）、代價是 latency 跟 availability 完全綁外部 HSM、AWS service 整合面要算清楚。

Multi-Region Replica Key 跟 DR：primary region 出事時 replica region 仍能 decrypt 既有 ciphertext、不需要 cross-region API call。但 primary 跟 replica 是各自獨立的 Key Policy、變更不會自動同步 — 跟 Audit Log 治理一樣、replica region 也要納入 CloudTrail Data Event 覆蓋範圍。

BYOK（Bring Your Own Key）：Origin = EXTERNAL 的 KMS Key、key material 由組織自己生成、用 wrapping key 加密後 import 進 KMS。優點是組織保有 master copy（KMS 出事時仍能 re-import 到別處）、缺點是 automatic rotation 不支援（必須手動 import 新 key material）、且必須自己處理 wrapping key 的生命週期。

跟 Secrets Manager 的整合：Secrets Manager 的 secret 本身用 KMS key 加密（預設 AWS Managed aws/secretsmanager、production 應該指到 Customer Managed CMK）。rotation Lambda 透過 Grant 取得 Decrypt + Encrypt 能力、跟 Secrets Manager 一起構成 static secret rotation 的證據鏈 — 跟 credential rotation scoped evidence 對齊。

Asymmetric signing 的 use cases：JWT signing（KMS Sign API 直接簽 JWT header.payload、private key 不離 KMS、跟 Storm-0558 的設計對照鮮明）；CodeSign / S3 object signing（artifact integrity）；mTLS client cert 的 private key（搭配 cert-manager AWS issuer）。代價是 latency（每次 sign 一次 KMS API call、~10ms 級別、不適合超高 QPS）跟 cost（asymmetric operation 比 symmetric 貴 ~5x）。

排錯與失敗快速判讀

• Key Policy 沒有 root principal：Schedule 時忘了寫、key 立刻變孤兒、誰都不能用 — 只能透過 AWS Support 救（流程慢）；建立流程強制 template 含 root principal
• IAM admin 改不動 KMS key：Key Policy 沒授權 IAM 介入、即使 admin policy 有 kms:* 也擋掉 — 加 Enable IAM User Permissions statement 給 root principal、IAM 才能參與授權
• Schedule Key Deletion 誤觸發：min 7 天、max 30 天的等待期、期內可 cancel — production key 必含 alert（CloudWatch Alarm on ScheduleKeyDeletion event）+ 強制 4-eyes approval
• CloudTrail Data Event 沒開：事故後想查「誰 decrypt 了什麼」、發現只有 management event — production 必開 KMS data event、預估 cost（每 100k events ~$0.10）、敏感 key 一律開
• Encryption Context 不一致：encrypt 時帶 context、decrypt 時忘了帶（或帶錯）、InvalidCiphertextException — code review 強制 context schema、用 typed wrapper 避免人手帶錯
• Grant 累積 + 沒 retire：每個 KMS key 有 50,000 grant 上限、rotation Lambda 跑久了 grant 累積 — 定期 ListGrants + RetireGrant 廢棄的、IaC 治理 grant lifecycle
• Cross-region decrypt 失敗：以為 ciphertext 跨 region 通用、結果原本不是 Multi-Region Key — production 跨 region 場景一律建 Multi-Region Key、不要事後補
• CMK rotation 後舊 ciphertext 還能 decrypt：annual rotation 不會 re-encrypt 舊資料、KMS 自動用對應 backing key — 這是設計、不是 bug；真要全量 re-encrypt 要走 application-level migration

何時改走其他服務

不在本頁內的主題

• KMS 完整 API reference 跟 SDK 範例
• 各 AWS service（S3 SSE-KMS、EBS encryption、RDS encryption、DynamoDB encryption）的詳盡設定步驟
• 跟 AWS Organizations / SCPs 的 cross-account KMS sharing 完整治理流程
• CloudHSM cluster 的完整運維（高可用、user 管理、backup）— 看 CloudHSM
• 各種 cryptographic algorithm 的數學原理跟選型細節

案例回寫

KMS 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（KMS 為 TLS / signing key 的 root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：Google Cloud KMS、Azure Key Vault、CloudHSM
• 下游：AWS Secrets Manager（後端用 KMS）、cert-manager（可用 KMS asymmetric key 當 issuer）
• 對照：HashiCorp Vault（transit engine / 跨雲統一介面）
• 跨模組：8 事故處理 vendor 清單（KMS 事件如何 routing 進 IR 流程）
• 官方：AWS KMS Documentation

服務定位

Cloud KMS 的核心定位是 GCP-native envelope encryption + signing 控制面、用 KeyRing 作為 organizational + locational grouping、CryptoKey + CryptoKeyVersion 作為 key material 的版本軸。跟 AWS KMS 相比、最大差異是 沒有獨立的 Key Policy：權限完全走 GCP IAM（Role Binding 綁到 KeyRing 或 CryptoKey resource）、好處是跟 Google Cloud IAM 統一治理（同一份 IAM audit、同一套 conditional binding）、代價是少了 AWS KMS Key Policy 那種 key-level 的獨立 deny override。

跟 Azure Key Vault 相比、Cloud KMS 拆得更細：Azure 把 secret + key + certificate 合在同一個 Key Vault service、Google 拆成 Google Secret Manager（secret）+ Cloud KMS（key）+ Certificate Authority Service（PKI），各 service IAM、quota、audit 獨立。跟 CloudHSM 相比、Cloud KMS Protection Level=HSM 是 managed HSM（FIPS 140-2 Level 3、Google 顧 cluster）、CloudHSM 是 single-tenant 專屬 HSM（客戶顧 cluster、合規隔離更強）。跟 Vault transit 相比、Cloud KMS 綁 GCP、Vault transit 可跨雲；但 Vault 自己常用 Cloud KMS 當 auto-unseal master key custodian。

本章目標

讀完本頁、讀者能判斷：

1. KeyRing 該放哪個 location（global / regional / dual-regional / multi-regional）、為何一旦決定無法搬遷
2. CryptoKey Version + Primary 版本軸怎麼支撐 rotation、何時該 disable / destroy 舊 version
3. Protection Level（SOFTWARE / HSM / EXTERNAL）跟 Cloud HSM、External Key Manager 的取捨
4. CMEK 整合 GCS / BigQuery / Persistent Disk 跟 cloud-native default encryption 的邊界差異

最短判讀路徑

判斷一份 Cloud KMS 部署是否健康、最少看四件事：

• KeyRing location 對不對：production sensitive key 用 region / multi-region、避免不必要的 global KeyRing；location 一旦設定 不能改、key 也搬不出原 KeyRing — 設錯只能建新 KeyRing + 重新加密所有 ciphertext
• IAM Conditions 跟 least privilege：roles/cloudkms.cryptoKeyEncrypterDecrypter 不該綁到 KeyRing level（會放大爆炸半徑）、應綁到具體 CryptoKey；admin 跟 use 角色分離（roles/cloudkms.admin ≠ roles/cloudkms.signer）；敏感 key 加 IAM Condition（時間窗、resource attribute）
• Cloud Audit Logs 開到對的層級：Admin Activity（建 key、改 IAM、destroy version）預設開、Data Access（每次 Encrypt / Decrypt / Sign）預設關 — production sensitive key 必須在 IAM audit config 把 Data Access 開、否則「誰用 key 做了什麼」查不到
• Protection Level 對齊合規：production 跟 PII / 金融 / 醫療資料的 key 應走 HSM 或 EXTERNAL、SOFTWARE 只給 dev / 低敏感場景；EKM 對應 資料主權（key 物理上不在 GCP）

四件事任一缺失、就是 Audit Log 與 KMS 邊界的待補項目。

日常操作與決策形狀

KeyRing 設計：KeyRing 是 組織單位 + 位置鎖。建議切法：依 環境 + 用途 拆（prod-data-encryption-asia-east1、prod-signing-global、dev-data-encryption-asia-east1），不要全公司一個 KeyRing。Location 選擇：跟資料 colocate（GCS bucket 在 asia-east1 的 key 也放 asia-east1 KeyRing、避免跨區延遲與資料主權問題）；signing key 多半放 global 或 multi-region 提高可用性；CMEK 給 BigQuery 時 KeyRing location 必須跟 dataset location 一致、否則綁不上。一個原則：KeyRing location 是一次性決策、上線前確認跟 cloud resource location + 法規要求對齊。

CryptoKey Version 與 Primary：CryptoKey 有多個 version（projects/.../cryptoKeys/k/cryptoKeyVersions/1、v2、v3）、其中一個是 Primary — 所有 Encrypt API 預設用 Primary version 加密、Decrypt 自動依 ciphertext 內嵌的 version ID 找對應 version 解。Rotation 不是「換 key」、是 建立新 version 並 promote 為 Primary；舊 version 仍可 decrypt 既有 ciphertext（除非手動 disable / destroy）。Destroy 是 24 小時延遲（可在期內 restore）、destroy 之後 ciphertext 永久不可解 — 排程 destroy 前必須確認沒有遺留 ciphertext 還在用該 version。

Auto Rotation：CryptoKey 可設 rotationPeriod（最短 1 天、預設 90 天）、KMS 在到期時自動建立新 version + promote 為 Primary、app 不需要改 code。Auto rotation 只對 symmetric encryption key 有效；asymmetric key（signing / decryption）不支援 auto rotation、需要手動建 version + 通知 consumer 更新 public key。注意 auto rotation 是 key version 換、不會 re-encrypt 既有資料 — 真正的 資料 re-encryption 是另一條工作流（讀回 ciphertext + 用新 Primary 重加密寫回）、要依 CMEK-integrated resource 各自規劃。

Protection Level：SOFTWARE（軟體運算、最便宜、FIPS 140-2 Level 1）/ HSM（Cloud HSM 後端、FIPS 140-2 Level 3、key 物理上在 Google 管理的 HSM cluster）/ EXTERNAL（External Key Manager、key 在客戶自管的外部 HSM、Cloud KMS 把運算委派出去）。Production sensitive key 應走 HSM、SOFTWARE 給 dev / 低敏感場景。Protection Level 是 CryptoKey 建立時決定、不能改 — 要升等只能建新 CryptoKey + 遷移 ciphertext。

CMEK 整合：CMEK 把 Cloud KMS key 綁到 GCS bucket / BigQuery dataset / Persistent Disk / Cloud SQL / GKE etcd / Pub/Sub topic / Dataflow job 等 resource。設定方式：cloud service 的 service account（如 service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com）取得該 CryptoKey 的 cryptoKeyEncrypterDecrypter 權限、resource 在加密時自動呼叫 KMS。跟 cloud-native default encryption（GCP 自己管 key）的差異：CMEK 下 客戶可隨時 disable key 讓整個 bucket / dataset 立刻無法解（compliance kill switch）、default encryption 沒這個能力。代價是 KMS 故障 = CMEK-integrated resource 全部讀寫卡住、所以 production KMS 自身 SLA 跟 monitoring 是 cluster-level dependency。

External Key Manager (EKM)：GCP 把 encryption / decryption operation 委派 給客戶自管的外部 HSM（Thales、Equinix SmartKey、Fortanix 等）、key 物理上不在 GCP、Cloud KMS 只是個 proxy。適合 資料主權 嚴格的場景（歐盟金融、政府機密、跨境法規）— 客戶撤銷外部 HSM 的存取、GCP 立刻無法解密、達成「Google 看不到資料」的合規承諾。代價：每次 Encrypt / Decrypt 都打外部 HSM、延遲跟可用性受外部 HSM 影響、運維複雜度大幅上升。

IAM 整合：用 Role Binding 控制存取（綁在 KeyRing 或 CryptoKey resource）— roles/cloudkms.cryptoKeyEncrypterDecrypter（Encrypt + Decrypt）/ roles/cloudkms.signer（AsymmetricSign）/ roles/cloudkms.signerVerifier（含 public key 取得）/ roles/cloudkms.admin（建 key、改 IAM）。對應 Google Cloud IAM 的 conditional binding、可加時間窗、resource attribute、access level 條件。跟 AWS KMS 的關鍵差異：沒有 Key Policy — 所有授權都在 IAM、好處是統一治理、代價是少了 key-level 的獨立 deny override（AWS KMS Key Policy 可寫「即使 IAM 給了 admin、仍 deny destroy」、Cloud KMS 要用 Organization Policy 或 IAM Deny 達成類似效果）。

核心取捨表

選 Cloud KMS 的核心訴求：GCP 是主力雲 + 需要 CMEK 把 GCS / BigQuery / PD / Cloud SQL 的加密 key custody 拉回客戶手上 + 接受 IAM-only 授權模型。需要 跨雲統一 key custody 走 Vault transit 或 EKM；需要 單一專屬 HSM 隔離 走 CloudHSM 或 EKM 接 on-prem HSM。

進階主題

External Key Manager (EKM) 與資料主權：EKM 讓 key 物理上不在 GCP、Cloud KMS 變成 proxy 把 cryptographic operation 委派給客戶自管 HSM。常見部署：金融 / 政府用 EKM via VPC（外部 HSM 在客戶 VPC 內、Cloud KMS 走 PSC 連線、延遲較低）、跨境合規用 EKM via Internet（HSM 在第三方 KMS provider、延遲較高但治理邊界更乾淨）。代價：每次 Encrypt / Decrypt = 一次外部呼叫、CMEK-integrated resource 的讀寫吞吐量受外部 HSM 限制、外部 HSM 故障 = 整個 GCP 端讀寫卡住。

Cloud HSM（Protection Level=HSM）：把 CryptoKey 物理上鎖在 Google 託管的 FIPS 140-2 Level 3 HSM cluster 內、key 不可 export、所有 cryptographic operation 在 HSM 邊界內完成。對應 Microsoft Storm-0558 Signing Key 2023 的對照啟示：signing key 一旦能被 export 或從 memory crash dump 撈出、整個信任鏈崩 — HSM-bound key 從設計上斷掉這條路徑。代價：HSM 後端比 SOFTWARE 貴、operation 延遲略高（典型多 < 10ms）、quota 也獨立計算。

Asymmetric Key 做 JWT signing：CryptoKey purpose=ASYMMETRIC_SIGN 配 algorithm（RSA / EC）、app 透過 AsymmetricSign API 把 JWT header+payload 的 hash 送進 KMS、KMS 回 signature。Public key 走 GetPublicKey API 取得、給 JWKS endpoint 對外發布。優勢：private key 不離 KMS、即使 app server compromise 也無法搬走 signing key；劣勢：每次簽名都 round-trip 一次 KMS、高 QPS 場景要算 quota 跟延遲（典型 ~10-30ms / sign）。

跟 Google Secret Manager 的 CMEK 整合：Google Secret Manager 預設用 GCP 管的 key 加密 secret、若要 客戶管 key、可設 CMEK 把 GSM 的 secret 用客戶 Cloud KMS key 加密。意義：disable Cloud KMS key 立刻讓 GSM secret 不可讀（compliance kill switch）— 但代價是 KMS 故障 = GSM 也卡住、是強耦合 dependency。

Multi-region key：Cloud KMS 的 multi-region KeyRing（如 us、europe、asia）讓 key material 在多 region 鏡像、提高可用性但加密 / 解密延遲較高。AWS KMS 的 Multi-Region Key 設計不同（單一 key ID 跨 region 同步、有獨立的 primary / replica 角色）— 跨雲遷移 / 多雲 active-active 設計時要留意這個差異、Cloud KMS multi-region 比較像 單一邏輯 key 多 region 可用、不是 多 region 各自獨立可寫。

Import 自有 key material（BYOK）：Cloud KMS 可 import 客戶自產的 key material（透過 wrapping key 包覆後上傳）、適合需要 客戶端 key generation 證據鏈 的合規場景。代價：import 的 key 不能 auto rotate（rotation 必須客戶端重新產 key 再 import），且 SOFTWARE / HSM Protection Level 都支援、EXTERNAL 不適用（EXTERNAL 本來就在外部 HSM、不走 import 路徑）。

Organization Policy 與防護欄：跟 Google Cloud IAM 整合的 Org Policy 可在 organization-level 強制 只允許 HSM / EXTERNAL key（constraints/gcp.restrictNonCmekServices）、防止工程師建出 SOFTWARE key 處理敏感資料。這層防護欄比依賴 reviewer 紀律有效、屬於 Failure: Credential Rotation Without Scope 同類「規約靠系統而非紀律」的設計。

排錯與失敗快速判讀

• KeyRing location 設錯：KeyRing 建在 global、要綁 asia-east1 的 BigQuery dataset CMEK — 綁不上、location 不能改、只能建新 KeyRing + 重新加密 — 上線前 review KeyRing location 跟 resource location 對齊
• Data Access audit 沒開：production 用 Cloud KMS 做 signing、事故時要查 誰用 key 簽了什麼、發現只有 Admin Activity log、沒有 Decrypt / Sign 記錄 — IAM audit config 加 dataAccess log type、留意 audit log 自己會增加成本與 quota
• CMEK key disable 後 resource 全卡：disable CryptoKey 想做 compliance 演練、整個 GCS bucket 讀寫立刻 503 — disable 是 全或無、要演練得排維護窗、有 rollback 計畫（re-enable 後恢復）
• Auto rotation 設定 + asymmetric key：以為 asymmetric signing key 也會 auto rotate、上線數月後發現 version 1 還在用 — asymmetric key 不支援 auto rotation、要手動建 version + 通知 JWKS consumer
• IAM Role 過寬：給整個 KeyRing cryptoKeyEncrypterDecrypter、單一 service account 可以解所有 key — 改綁到具體 CryptoKey、加 IAM Condition
• EKM 外部 HSM 故障：外部 HSM 連線中斷、Cloud KMS 端 Encrypt / Decrypt 全 fail、所有 CMEK-integrated resource 讀寫卡住 — EKM 需要 dual HSM redundancy + Cloud KMS 端 monitoring alert
• Destroy 後資料不可解：CryptoKeyVersion destroy 後 24 小時 grace period 過了、發現某個 backup 還是用該 version 加密 — destroy 前必須跑 inventory 確認沒有 ciphertext 還掛在該 version

何時改走其他服務

不在本頁內的主題

• Cloud KMS 完整 API reference 跟 gcloud kms CLI 詳盡用法
• Cloud HSM partition 內部架構、FIPS 140-2 Level 3 驗證細節
• EKM 各 partner（Thales / Fortanix / Equinix）的整合步驟與 API 對照
• BigQuery / GCS / Cloud SQL 各自 CMEK 設定的完整教學
• Cloud KMS pricing 詳盡計算（key version 數、operation 次數、HSM 加成）

案例回寫

Cloud KMS 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（KMS 為 TLS / signing key 的 root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：AWS KMS、Azure Key Vault、CloudHSM
• 平行（secret）：Google Secret Manager、HashiCorp Vault
• 上游（IAM）：Google Cloud IAM（Cloud KMS 權限完全走 IAM Role Binding）
• 跨模組：8 事故處理 vendor 清單（KMS 事件如何 routing 進 IR 流程）
• 官方：Cloud KMS Documentation

服務定位

Azure Key Vault 的核心定位是 三合一 secret + key + cert service 加 Azure-native secret-less 取用。AWS 是 Secrets Manager + KMS + ACM 三個獨立 service、職責邊界清楚但要管三套權限；GCP 是 Google Secret Manager + Cloud KMS + Certificate Authority Service 三個獨立；Azure 把這三件事合在 Key Vault — 同一 RBAC role 可同時管 secret / key / cert、減少 IAM 維護成本、但治理上需要在 Vault 內用 naming convention + 多 Vault instance 自己劃分敏感度邊界（例：production secret / cert 分開不同 Vault、admin access 分人）。

跟 HashiCorp Vault 相比、Azure Key Vault 是 Azure-only 的 static-focused 服務 — 沒有 dynamic credential engine、沒有 transit encryption-as-a-service、沒有跨雲統一介面。優勢是 零運維 + Managed Identity 取用免 client secret + Premium tier 直接 HSM-backed。Azure-heavy + 一站式 secret/key/cert + secret-less workload 取用是 Key Vault 的甜蜜點。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret / key / cert 適合放 Key Vault、哪些該走 Managed HSM（FIPS 140-2 Level 3 需求）
2. Access Policy 跟 Azure RBAC 兩種授權模型的差異與 migration 路徑
3. Soft Delete + Purge Protection 的 防誤刪 與 防勒索 邊界
4. 何時用 Key Vault、何時改走 HashiCorp Vault（跨雲 + dynamic credential）的取捨

最短判讀路徑

判斷 Azure Key Vault deployment 是否健康、最少看四件事：

• 誰能 access：Vault 用 Access Policy 還是 Azure RBAC、是否還有 legacy Access Policy 沒清掉、Managed Identity 的 role assignment 是否最小化（Key Vault Secrets User 而非 Key Vault Administrator）
• RBAC vs Access Policy 模型：production 應該全走 Azure RBAC（跟 Azure RBAC vendor 同套）、舊 Access Policy 是 migration backlog、不可長期兩軌並存
• Soft Delete + Purge Protection：兩個都應開、Soft Delete 90 天 retention、Purge Protection 開了之後連 owner 都不能立即 purge — 防誤刪 + 防 ransomware 一次性刪光
• Diagnostic Logs：Key Vault 預設不記操作 log、必須手動配 Diagnostic Setting 推 Log Analytics / Event Hub / Storage — 沒這層 KeyVaultGet / SecretGet 都沒 audit trail

四件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

Vault Standard vs Premium：Standard 用 software protection（key 存在 Microsoft-managed software boundary）、Premium 用 FIPS 140-2 Level 2 HSM-backed key、key material 在 HSM 內、不可 export。Premium 適合 signing key / wrapping key 等高敏 key、Standard 適合 application secret + 常規 envelope encryption key。要 FIPS 140-2 Level 3、Standard 跟 Premium 都不夠、必須用 Managed HSM。

Access Policy vs Azure RBAC（兩種授權）：Access Policy 是 Key Vault legacy 模型 — 在 Vault 物件上掛一張 capability 表（Get / List / Set / Delete / Encrypt / Sign 等細粒度權限）、跟 Azure RBAC 體系獨立。Azure RBAC 模型是新版 — 用 Azure built-in role（Key Vault Secrets User / Key Vault Crypto User / Key Vault Administrator）走 Entra ID 統一身份治理。production 全走 RBAC、舊 Vault 的 Access Policy 是 migration backlog — 兩軌並存會出現 RBAC 拒絕但 Access Policy 允許 的權限漏洞。

Managed Identity 取用（secret-less）：Azure VM / Function / App Service / AKS pod 走 Managed Identity 直接呼叫 Key Vault API — 不需要存 client secret 或 cert。Workload 拿 IMDS token、token 帶 Entra ID identity、Key Vault 端用 RBAC role assignment 驗證 — 這是 Azure-native 的 secret-less 取用模式、跟 AWS IAM Role for Service Account / GCP Workload Identity 同類設計。production 應該 只允許 Managed Identity 取用、禁用 service principal + client secret。

Secret rotation（手動 / event-driven）：Key Vault Secret 沒有像 AWS Secrets Manager 內建的 rotation Lambda。Rotation 走兩條路：手動更新 secret version（app 端拉新版）、或 Event Grid 通知 secret 過期 + Azure Function 觸發 rotation。後者需要自己寫 rotation logic、Key Vault 只提供 版本管理 跟 過期通知、不負責執行 rotation。

Key Rotation Policy：Key（不是 Secret）有 native Rotation Policy — Vault 在 key 到期前自動生成新版、舊版保留可解密但不再 encrypt。policy 設 rotationPeriod + notifyBeforeExpiry、Key Vault 自動跑、不需要外部觸發。Secret 沒這功能、Key 才有。

Certificate auto-renewal：Certificate object 可整合 Issuer（DigiCert / GlobalSign / 自簽）做 auto-issue + auto-renew — Key Vault 在到期前自動跑 CSR、向 Issuer 申請新 cert、寫回同一個 Certificate object（保留歷史版本）。比起手動跑 OpenSSL + 寫進 AWS ACM、Certificate object 的優勢是 Issuer 在 Vault 端統一治理 — 不過只支援整合過的 public CA。

Soft Delete + Purge Protection：Soft Delete 預設開（2020 後新 Vault 強制開）、delete 後 90 天 retention、Recover 可救回。Purge Protection 是 額外 開關 — 開了之後 retention 內任何人（包含 subscription owner）都不能 purge 立即清除、必須等 90 天到期才會物理刪除。這是 防勒索 的關鍵 — 沒 Purge Protection、attacker 拿到 owner role 可以 delete + purge 一次性清光。

Private Endpoint：Key Vault 預設是 public endpoint（FQDN 走 internet）。Private Endpoint 把 Vault 拉進 VNet、只走內網存取 — 高敏 Vault 應該關 public access、強制走 Private Endpoint + Firewall rule（IP 白名單）。

核心取捨表

選 Azure Key Vault 的核心訴求：Azure-only、需要 secret + key + cert 一站式、workload 走 Managed Identity secret-less 取用、可接受 無 dynamic credential。需要跨雲統一 secret 控制面、或要 dynamic database credential、走 HashiCorp Vault。

進階主題

Managed HSM（dedicated）：Managed HSM 是 dedicated single-tenant HSM cluster、FIPS 140-2 Level 3、跟 multi-tenant 的 Key Vault Premium 是不同 service。Managed HSM 適合 主權合規（key material 完全自有控制權、Microsoft 也不可存取）、金融 / 醫療 / 政府場景。代價是 貴 跟 初始化要走 ceremony（多人持有 activation key、Microsoft 不可單方面操作）— 不是 Premium 的簡單升級、是另一條 product line。

Premium tier HSM-backed Key：Premium tier 的 key 有 HSM-protected 屬性、key material 在 multi-tenant HSM 內、API call 還是走標準 Key Vault endpoint、但 cryptographic operation 在 HSM 跑。比 Standard 慢一點、價格高、適合 signing key / wrapping key / root encryption key — 一般 application secret 還是 Standard 即可。

Certificate Issuer 整合：Vault 內可註冊 Issuer（DigiCert / GlobalSign / Entrust）、提供 API credential、Vault 在 Certificate 到期前自動跑 CSR、向 Issuer 申請、Issuer 簽完寫回 Vault。Self-signed / Unknown Issuer 也支援、後者表示 Vault 產 CSR、人或 pipeline 拿去外部 CA 簽完再 import 回 Vault。

Cross-tenant key access（federated identity）：Key Vault 可允許跨 Entra ID tenant 的 service principal 取用 — 透過 Federated Identity Credential（Workload Identity Federation）、外部 tenant 的 identity（甚至 GitHub Actions OIDC、AWS workload）拿 token 來 Key Vault 驗證。這是 cross-cloud workload 拉 Azure secret 的方式、不需要存 Azure service principal credential。

跟 Entra ID Conditional Access 整合：Key Vault 用 Azure RBAC 模型時、可走 Conditional Access policy — 特定 IP、已 enrolled 裝置、MFA 已驗證 才能取用 secret / key。production 高敏 Vault 應該疊 Conditional Access、避免單純 RBAC 在 token leak 時就直接被存取。

排錯與失敗快速判讀

• Diagnostic Setting 沒開：production Vault 啟用後忘了配 Diagnostic Setting 推 log、事故發生時無 SecretGet / KeyDecrypt 紀錄 — 啟動 checklist 必含「Diagnostic Setting → Log Analytics」、Azure Policy 強制全 subscription Vault 都配
• Access Policy 跟 RBAC 兩軌並存：migration 過程中 RBAC 已切換但舊 Access Policy 沒清、出現 RBAC 拒絕但 Access Policy 允許 — migration 一次切斷、跑 az keyvault update --enable-rbac-authorization true 後清空所有 Access Policy
• Soft Delete 沒開 / Purge Protection 沒開：誤刪 secret 救不回、或 attacker 拿到 owner role 一次 purge 清光 — 新 Vault 兩個都強制開、Azure Policy 阻擋 enablePurgeProtection: false 的 Vault 建立
• Managed Identity role 過寬：給 workload identity Key Vault Administrator 而非 Key Vault Secrets User — workload 拿到 admin role 等於可改 ACL — role assignment 走 least privilege built-in role
• Premium key 跑非 HSM operation：Premium key 配錯 attribute、key 變成 software-protected 而非 HSM-protected — 建 key 時明示 --protection hsm、CI 驗證 key attribute
• Certificate auto-renew Issuer credential 過期：Vault 內 DigiCert API credential 過期、auto-renew 默默失敗、cert 到期前才發現 — Issuer credential 也要 rotation + monitor
• Public access 開著：Vault 沒關 public endpoint、secret 暴露在 internet（雖然有 RBAC、但 attack surface 多一層）— 高敏 Vault 強制 Private Endpoint + Firewall rule

何時改走其他服務

不在本頁內的主題

• Key Vault REST API / Azure CLI 完整 reference
• Managed HSM activation ceremony 完整步驟
• Bicep / Terraform 配置 Key Vault 的完整 IaC 範例
• Certificate Issuer（DigiCert / GlobalSign）的合約與計價細節
• 每個 Entra ID role 的細粒度 permission map

案例回寫

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（Key Vault Certificate + Managed HSM 為 TLS / signing key 的 root custodian）、7.2 身分與授權邊界
• 平行（secret store）：AWS Secrets Manager、Google Secret Manager、HashiCorp Vault
• 平行（KMS-class）：AWS KMS、Google Cloud KMS、CloudHSM（Key Vault 是跨類 vendor、同時是 secret store 跟 key management）
• 下游：Azure RBAC（Managed Identity + RBAC 取用模型）
• 下游：cert-manager（K8s workload cert 自動化、可整合 Key Vault Certificate）
• 跨模組：8 事故處理 vendor 清單（Key Vault 事件如何 routing 進 IR 流程）
• 官方：Azure Key Vault Documentation