同區網也要加密的理由

自用工具的 SDK 和 collector 通常在同一台機器或同一個區域網路（LAN / Tailscale tailnet）。常見的假設是「同區網不需要加密，因為只有我自己在用」。

這個假設在以下情境不成立：

共用網路：咖啡廳、共享辦公室、飯店 WiFi — 同一個 AP 下的其他裝置可以用 ARP spoofing 或 WiFi sniffing 攔截未加密的 HTTP 流量。

未來的網路拓撲變更：目前在同一台機器上的 SDK 和 collector，可能之後拆到不同的機器或不同的網路段。如果一開始就用 HTTPS，拓撲變更不需要額外的安全調整。

養成正確習慣：在自用工具上用 HTTP 是因為「反正只有我」，但相同的開發者在商業專案中可能延續這個習慣。從自用工具開始就用 HTTPS，讓加密傳輸成為預設行為。

HTTPS 設定

自簽憑證

自用工具和內部服務用自簽憑證（self-signed certificate）就足夠。不需要購買 CA 憑證 — 自簽憑證提供加密（防竊聽）和完整性（防篡改），只是不提供身份驗證（client 無法確認 server 是不是「官方的」）。在自用場景中 server 就是自己架的，身份驗證不是問題。

1openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Go collector 使用自簽憑證：

1http.ListenAndServeTLS(":8443", "cert.pem", "key.pem", handler)

SDK 端需要信任自簽憑證。開發期可以在 HTTP client 設定 badCertificateCallback 接受自簽憑證；production 應該把自簽憑證加入系統的信任清單。

Let’s Encrypt

如果 collector 有公開的 domain name，用 Let’s Encrypt 取得免費的 CA 憑證。自動續期、不需要手動管理。適合部署在 VPS 或雲端的 collector。

Basic Auth

HTTPS 保護傳輸層（防竊聽），basic auth 保護 endpoint 層（防未授權存取）。兩者互補，缺一不可 — basic auth 在 HTTP 上傳送的是 base64 編碼的帳密，沒有 HTTPS 的加密保護等於明文傳送。

1Authorization: Basic base64(username:password)

SDK 在每個 HTTP POST request 的 header 中帶上 basic auth。Collector 端驗證帳密，不匹配則回傳 401。

Basic auth 的帳密管理：

• 帳密存在 SDK 的設定檔或環境變數中，不硬編碼在程式碼裡
• Collector 端的帳密用 bcrypt hash 儲存，不存明文
• 定期輪替帳密（自用工具半年到一年一次即可）

API Key 替代方案

如果不需要 username/password 的雙因素，單一 API key 更簡單。

1X-API-Key: sk_monitor_abc123...

API key 的管理比 basic auth 簡單（一個字串而非帳密對），但安全性略低（只有一個 factor）。自用工具場景下 API key 通常足夠。

下一步路由

• SDK 端的 redaction → SDK Redaction API 設計
• Collector 端的 access control → Collector Access Control 實作
• Server-side 的 secret management → backend 07 資安

服務定位

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

服務定位

CloudHSM 的核心定位是 把 cryptographic root of trust 放回客戶手上 — 適合金融、政府、醫療這類有資料主權、FIPS 140-2 Level 3、PCI HSM、HIPAA 合規壓力的場景。跟 AWS KMS 比、KMS 也滿足 FIPS 140-2 Level 3、但 HSM cluster 是 AWS 多租戶共用、key material 由 AWS-controlled HSM 持有、控制面 API 也是 AWS。CloudHSM 把 HSM cluster 物理隔離給單一客戶、PKCS#11 / JCE / OpenSSL Dynamic Engine 直接打 HSM、AWS 在資料平面 沒有讀 key 的能力。

跟 自管 on-prem HSM（SafeNet / Thales 自架）比、CloudHSM 把硬體採購、機房、network、firmware patch 交還 AWS、客戶只管 key custody 跟 Crypto User policy；代價是不能完全脫離 AWS region。跟 Vault auto-unseal 整合場景中、CloudHSM 是 Vault master key 的 root custodian — Vault unseal key 用 CloudHSM 加密、CloudHSM 出事整個 Vault cluster 沒法 unseal、所以可用性設計（cross-AZ cluster、cross-region backup）很關鍵。多數一般 web app / SaaS 用 KMS 即可、不需要 CloudHSM 的物理隔離。

本章目標

讀完本頁、讀者能判斷：

1. 何時需要 CloudHSM 的 dedicated 模型、何時 AWS KMS 已足夠
2. CloudHSM cluster 的最低安全 / 可用性需求（cross-AZ、Crypto Officer 分離、Quorum、backup）
3. Crypto User credential 出事的降級路徑（AWS 不能幫忙、靠 backup + Quorum）
4. 跟 KMS Custom Key Store / Vault auto-unseal 整合的取捨

最短判讀路徑

判斷 CloudHSM deployment 是否健康、最少看四件事：

• Cluster 拓樸：production cluster 是否至少 2 個 HSM instance 跨 AZ、cluster 內自動 replicate、單一 AZ 故障時 key 是否仍可用
• Crypto User 管理：Crypto Officer（CO）跟 Crypto User（CU）是否分離、CO password 是否走 break-glass 保管、CU credential 是否走 short-lived 取得 + audit
• Quorum-based policy：高敏 operation（建 CU、改 policy、key export wrapped）是否設 M-of-N approval、避免單一 admin compromise 後 silent abuse
• Backup 治理：automatic 24h backup 跟 manual backup 是否都開、cross-region backup 是否走 explicit copy、restore 流程是否定期演練

四件事任一缺失、就是 CloudHSM deployment 待補項目 — 跟 secret management 的 evidence 邊界同類。

日常操作與決策形狀

Cluster + HSM Instance 拓樸：CloudHSM 的部署單位是 cluster、cluster 內可以有 1-N 個 HSM instance。production 場景至少 2 個 HSM instance 跨 AZ、cluster 自動把 key material replicate 在所有 instance 上、單一 AZ 失效不影響 cryptographic operation。跨 region 不自動 replicate — 跨 region DR 要靠 backup copy。

Crypto Officer (CO) vs Crypto User (CU)：CO 是 cluster 管理員、能建 / 刪 CU、設 policy、做 backup；CU 是真的做 cryptographic operation 的 identity（encrypt / decrypt / sign / verify）。production 必須分離 — CO credential 走 break-glass 保管、CU credential 給 application 使用、application compromise 只影響 CU 邊界、不能改 CO policy。

Quorum-based policy（M-of-N approval）：CloudHSM 支援把高敏操作（建 CU、改 policy、key export wrapped）綁定 M-of-N CO approval。例如 3-of-5 quorum、單一 CO 即使 credential 外洩也不能單獨建後門 CU、必須拿到另外 2 個 CO 的 signed token。對應 Storm-0558 signing key chain 啟示：高價值 key custodian 的 admin operation 不該是 單人單 token、必須有第二人簽核才能改變信任根。

Backup 治理：CloudHSM 每 24 小時自動 backup 整個 cluster state（含 key material）、backup 是 AWS-managed encrypted blob、AWS 自己也不能解密、restore 必須在 CloudHSM cluster context 內進行。可手動 backup、可 copy 到其他 region 做 DR。Backup retention 預設 90 天、可延長。Backup 不是 export — 不能把 key material 從 HSM 拿出來看 plaintext。

Key Replication 跨 region：CloudHSM cluster 綁定單一 AWS region、跨 region 走 backup → copy → restore 流程、不是 active replication。設計 DR 時要算 RTO：restore 一個 cluster 從 backup 大約小時級、不適合 hot failover、應該 primary region 跑、DR region 備好空 cluster + backup copy。

PKCS#11 / JCE / OpenSSL Dynamic Engine 整合：application 不用 AWS SDK 講 CloudHSM、而是透過 標準 cryptographic API library（PKCS#11 for C/C++、JCE Provider for Java、OpenSSL Dynamic Engine 走 TLS termination）。好處是 application code 用業界標準介面、未來換 HSM 廠也只需要換 library。代價是 client SDK 要裝在 application host、CU credential 要 deploy 到 host、host security baseline 變成 cryptographic boundary 的一部分。

跟 KMS Custom Key Store 整合：KMS Custom Key Store 把 KMS Key 的 backing material 放在 CloudHSM、API 仍透過 KMS（kms:Encrypt / kms:Decrypt）、application code 不需要改。這是 KMS 易用 + HSM dedicated 雙重：保留 KMS 的 IAM policy / key rotation / audit log（CloudTrail）、又得到 single-tenant HSM 的合規屬性。代價是 CloudHSM 失效時、Custom Key Store backing 的 KMS Key 全部不可用、需要監控 cluster health。

核心取捨表

選 CloudHSM 的核心訴求：合規明文要求 dedicated HSM（PCI HSM、某些國家資料主權法規）、或 trust model 上不接受 AWS 持 key。多數 AWS-heavy workload 用 KMS 即可、加 CloudHSM 反而引入 Crypto User credential 的單點失誤（丟了 = key 永久遺失）。需要 KMS API 但又要 dedicated HSM、走 Custom Key Store 是折衷路徑。

進階主題

Quorum Auth 設計：production 把 Quorum threshold 設為 3-of-5 或 2-of-3、五位 CO 由不同部門 / 不同地理位置持有、避免單一辦公室 / 單一網路同時被攻陷。Quorum token 有 TTL、單次 operation 用完就失效、防止 replay。建議 quarterly 演練：模擬一個 CO 不在、用剩餘 quorum 完成 emergency operation、驗證流程在事故時跑得通。

KMS Custom Key Store 整合決策：用 Custom Key Store 的關鍵問題是 availability blast radius — KMS Key 出事影響範圍是 使用該 Key 的 AWS service（S3、EBS、RDS encryption）、Custom Key Store backing 失效會讓這些 service 同步斷。設計時做 分層 key strategy：mass volume 的 S3 / EBS 用 AWS-managed KMS Key、高合規敏感的 database / secret 才用 Custom Key Store backing 的 KMS Key、降低單一 cluster 失效的影響面。

Cross-Region Backup：DR 要把 backup copy 到第二個 region、走 CopyBackupToRegion API、restore 時建空 cluster + 套 backup。整個 RTO 通常數小時、不適合熱備、設計上是 容忍小時級 outage 換到 BCDR 環境、不是 秒級 failover。對應 Azure AD Identity Control Plane 2021 對照啟示：身份 / 加密控制面的單點 outage 影響整個 platform、availability 的 topology 設計跟 confidentiality 同等重要。

跟 Vault auto-unseal 整合：Vault auto-unseal 可用 CloudHSM 作 master key custodian、走 PKCS#11 plugin、Vault unseal 時呼叫 CloudHSM Unwrap master key。比起 AWS KMS auto-unseal 多一層 dedicated HSM 保證、適合監管特別嚴的場景。代價是 CloudHSM cluster 失效 → Vault 不能 unseal → 下游所有 secret 拿不到、要設計 break-glass 流程。

合規憑證：CloudHSM 同時持有 FIPS 140-2 Level 3、PCI HSM、Common Criteria EAL4+ 多個認證、可作金融 PIN block 處理、payment 業者的 HSM 上鏈、政府機敏資料加密的 直接合規承諾、不需要客戶端再做 HSM 認證 audit。

排錯與失敗快速判讀

• Crypto User credential 丟失：CU password 全公司只有一份、保管人離職 → AWS 不能 reset、key material 永久不可用 — CU credential 要走 password manager + 多人持有、CO 有能力 revoke 舊 CU 建新 CU
• Cluster 只有單一 HSM instance：成本省了、單一 instance 故障 cluster 整個失效 — production 強制至少 2 個 instance、跨 AZ
• Backup 沒測過 restore：每天 automatic backup 跑、從未 restore 演練、DR 真要用時發現流程不通 — quarterly 演練 restore 到測試 cluster、驗證 key material 可用
• Custom Key Store 沒監控 CloudHSM health：CloudHSM cluster degraded 時、KMS Custom Key Store 跟著失效、application 看到 KMS 5xx — CloudWatch metric 監 HsmsActive / HsmTemperature、cluster health degrade 立即 alert
• PKCS#11 library 版本漂移：application host 的 client SDK 版本跟 cluster firmware 不相容、cryptographic operation 失敗 — version compatibility matrix 進 deployment pipeline、firmware upgrade 前先測 staging
• Quorum CO 全部同地點：5 個 CO 全在同一個辦公室、辦公室斷網 = quorum 不能組 — CO 跨 region / 跨組織分散
• Audit log 沒接 SIEM：CloudHSM activity 透過 CloudTrail + cluster audit log、沒接 SIEM 就無 forensic — CloudTrail 跟 cluster audit 都 push 到 SIEM（見 7.13 偵測覆蓋率與訊號治理）

何時改走其他服務

不在本頁內的主題

• CloudHSM 完整 PKCS#11 / JCE API reference
• CloudHSM Classic（舊版、已 EOL）的差異
• 每種合規法規（PCI HSM、HIPAA、FedRAMP）的逐條對應
• CloudHSM CLI 跟 cloudhsm_mgmt_util 詳細指令
• 應用層使用 HSM-bound key 做 TLS termination 的 nginx / Apache 配置細節

案例回寫

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

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（HSM 為 CA / signing key 的 FIPS-grade root custodian）、7.13 偵測覆蓋率與訊號治理
• 平行：AWS KMS、Google Cloud KMS、Azure Key Vault
• 整合：HashiCorp Vault（CloudHSM 作為 Vault auto-unseal master key custodian）
• 整合：KMS Custom Key Store（KMS API + CloudHSM backing 雙重）
• 跨模組：8 事故處理 vendor 清單（HSM 失效如何 routing 進 IR 流程）
• 官方：AWS CloudHSM Documentation

本文的判讀錨點是：加密要服務於 threat model。若風險是磁碟遺失，at-rest encryption 是重點；若風險是網路攔截，TLS 是重點；若風險是內部濫用，還需要 role、audit、masking 與 SIEM。

官方文件路由的核心責任是固定 MySQL 8.4 security claim。實作前先查 InnoDB data-at-rest encryption、MySQL keyring 與 SHOW BINARY LOG STATUS；本文最後檢查日是 2026-05-22。

Protection Layers

Protection layers 的核心責任是把保護面分層。

這些層級要一起設計。資料檔加密後，backup 若以明文落到 object storage，保護鏈仍然破洞；TLS 開啟後，client 若允許 insecure fallback，也會失去網路保護。

Keyring Boundary

Keyring boundary 的核心責任是定義 MySQL 如何取得與保護 encryption key。MySQL 支援 keyring component / plugin 與外部 KMS 整合；managed MySQL 可能由 provider 接管 key storage。

Keyring 要進入 backup / restore drill。還原 database 時，只有 data file 而沒有對應 key，restore 會失敗；runbook 要保存 key dependency 與 emergency access。

TLS Policy

TLS policy 的核心責任是讓 client connection、replication connection 與 admin connection 都有明確安全等級。

TLS 驗證要包含 certificate rotation。過期憑證造成的 downtime 很常見；runbook 要記錄 CA、server cert、client cert、rotation window 與 reload / restart 條件。

1SHOW VARIABLES LIKE 'require_secure_transport';
2SHOW STATUS LIKE 'Ssl_cipher';

這些查詢只能提供 connection 層 evidence。正式驗證還要從 client 設定確認 ssl-mode 是否驗證 CA / identity。

Backup and Binlog Encryption

Backup and binlog encryption 的核心責任是保護資料離開 primary 後的生命週期。MySQL backup、binlog、logical dump、object storage、replica seed 都可能含敏感資料。

Restore drill 要確認加密 artifact 可被解密並啟動。只有成功產出 encrypted backup，還不足以證明災難時能恢復。

Rotation Runbook

Rotation runbook 的核心責任是讓 key、certificate、password 都可定期更換。

1. Inventory：列出 DB user、TLS cert、KMS key、backup key。
2. Impact：確認哪些 client / replica / backup job 使用它。
3. Staging：先在 staging 旋轉並跑 smoke test。
4. Rollout：使用雙憑證 / 雙 secret window。
5. Validation：查連線、replication、backup、restore。
6. Cleanup：移除舊 key / cert / secret。

Rotation 要設 calendar 與 owner。安全設定長期無人輪替時，incident 後會難以判斷 exposure window。

Failure Modes

Failure modes 的核心責任是提前列出加密常見事故。

安全 runbook 要和 audit log 串接。Key rotation、failed TLS、privilege change、restore access 都應留下可追溯紀錄。

下一步路由

Encryption / TLS / key management 完成後，操作證據讀 Audit Log + SIEM；備份恢復讀 PITR / Backup；資料保護治理讀 Data Protection。