加密、金鑰管理與憑證架構

Professional 等級的 AWS 加密與憑證管理，已經不只是「選 SSE-KMS 就好」這麼簡單。它是一門設計金鑰層級與憑證層級的學科，範圍橫跨數十個 AWS 帳號、多個 AWS 區域、混合雲地端端點，以及長達七到十年的合規保留窗口——而這些帳號正同時被遷移、重構、上線。AWS 在此規模的加密與憑證管理，結合了 AWS KMS（客戶自管 CMK、Multi-Region 金鑰、跨帳號金鑰、KMS Grants、External Key Store 自帶金鑰）、AWS CloudHSM（FIPS 140-3 Level 3 單租戶叢集，用於 PCI HSM 與主權工作負載）、AWS Certificate Manager（ELB 與 CloudFront 的公開 TLS）、AWS Private CA（具有各 OU 子 CA 的內部 mTLS CA 層級）、AWS Secrets Manager（自動化 RDS 憑證與憑證輪替），以及 AWS Nitro Enclaves（帶有密碼學驗證的機密運算）。本指南涵蓋 SAP-C02 期望你實際運用而非僅是認識的企業級加密與憑證管理模式。

SAP-C02 在各考試領域中都橫跨了加密與憑證管理的考點。Domain 1（設計組織複雜性解決方案）考驗跨帳號 KMS 與 Private CA 層級。Domain 2（設計新方案）考驗從零開始的 BYOK 與 mTLS 基線。Domain 3（持續改善）考驗 CMK 輪替、憑證自動化，以及從舊有地端 HSM 遷移至受管加密的過程。Domain 4（加速工作負載遷移與現代化）考驗在遷移時補上加密控制——包括 Oracle TDE 至 Aurora 搭配 KMS、RDS 快照就地加密複製、PCI HSM 至 CloudHSM，以及 Windows PKI 至 AWS Private CA。本指南以醫療應用遷移需要 BYOK、mTLS、HIPAA 及五年稽核軌跡的貫穿情境，讓取捨變得具體可感。

什麼是 Professional 等級的 AWS 加密與憑證管理？

Professional 等級的 AWS 加密與憑證管理，是在多帳號、多區域、混合地端 AWS 環境中，治理密碼金鑰與 X.509 憑證的企業規模框架。它在 Associate 等級基礎（AWS KMS、SSE-KMS、CloudHSM、ACM）之上，新增了三項只有在大規模環境才真正重要的能力：

1. 範圍與生命週期：AWS KMS CMK 與 ACM 憑證分布在數十至數百個 AWS 帳號、多個 AWS 區域，以及通常超過七年的合規保留窗口。你需要一套能在帳號拆分、帳號關閉、區域上線、服務棄用後依然存活的金鑰與憑證層級。
2. 委派與隔離：產出 AWS KMS 金鑰的團隊鮮少是使用該金鑰的團隊。中央安全團隊擁有 CMK；業務單位工作負載透過跨帳號金鑰政策與短效 KMS Grants 來使用它。同樣的不對等關係適用於 AWS Private CA 層級——中央 PKI 擁有根 CA，以 OU 為範圍的子 CA 將簽發權下放給業務單位。
3. 法規現實：HIPAA、PCI-DSS（尤其是 HSM 標準）、FedRAMP High 與 GDPR 各自對金鑰材料存放位置、誰可以實際觸及金鑰，以及稽核記錄保留多久有不同限制。Professional 等級的 AWS 加密與憑證管理，就是在不把每個工作負載都變成 CloudHSM 部署的前提下，滿足這些限制的藝術。

為何 AWS 加密與憑證管理在 SAP-C02 如此重要

SAP-C02 的每個 Domain 至少有一道加密與憑證管理題。Domain 1 考驗跨帳號 AWS KMS 金鑰共享與 Private CA 子 CA 委派。Domain 2 考驗 BYOK vs XKS vs CloudHSM 等從零設計選擇，以及服務網格的 mTLS 基線。Domain 3 考驗大規模 CMK 輪替策略（數千個 CMK、數千份密文）與 ACM 更新自動化。Domain 4 考驗遷移時補加密——這也是加密與憑證管理決策最難逆轉的地方。自信地應對這些情境，加密與憑證管理就能成為你 SAP-C02 分數的高槓桿區段。

白話文解釋 AWS 加密與憑證管理

Professional 等級的加密與憑證管理，最好的理解方式是把密碼學資產對應到日常生活中的具體事物。

類比一：健保卡系統（KMS 層級 + Multi-Region + 跨帳號）

想像台灣的健保卡系統：健保卡本身是加密後的有效負載，健保局核發的晶片金鑰是 AWS KMS 金鑰，而每次刷卡核驗的讀卡機是執行信封加密的 AWS 服務。單一診所自用時，一把金鑰（一個區域的 CMK）就夠了。但健保局要服務全國：

• Multi-Region KMS 金鑰就像健保卡晶片金鑰同步複製到各縣市健保局——在台北核發的加密記錄，可由高雄辦事處用同一把邏輯金鑰解密，不需重新加密。金鑰材料由健保局（AWS KMS 服務）在各辦事處之間同步維護。
• 跨帳號金鑰政策就像健保局給勞保局一份授權書，讓勞保局可以在自己權責範圍內呼叫金鑰做解密，但金鑰本身永遠不離開健保局；授出去的只有使用授權。
• KMS Grant 是給單一業務窗口的一次性授權單，辦完就自動失效，或在預設時間到期——非常適合短效工作負載。
• External Key Store (XKS) 就是健保局晶片金鑰的主材料其實鎖在行政院地下保險庫（你的地端 HSM）。每次需要加解密，都要透過安全線路呼叫保險庫完成運算，材料從不上雲。
• AWS CloudHSM 是一台裝在你自己辦公室的保險箱——它確實在 AWS 機房內，但是你專屬租用的，AWS 工作人員拿不到鑰匙。

這個類比讓每道涉及多個區域或帳號的 AWS 加密與憑證管理題目都有了立足點。

類比二：醫院的雙重信封病歷系統（BYOK + HIPAA + 五年稽核軌跡）

一間醫院保存病人病歷。新的 HIPAA 系統設計如下：

• 搭配 BYOK CMK 的用戶端加密，就是醫師把病歷夾進一個用醫院自有蠟封封緘的內層信封（客戶自帶的金鑰材料）。
• 底層 S3 儲存桶的 SSE-KMS，是收發室再套上一個醫院通用印章封緘的外層信封。
• 稽核軌跡是病歷室入口的登記本：每次有人取閱病歷，管理員記下是誰、何時、為何。CloudTrail + AWS Config + S3 Object Lock + CloudWatch Logs，交付到五年保留期的儲存桶，就是那本登記本。
• 護理站的 mTLS 意味著護理師的識別證（用戶端憑證）與病歷室窗口的識別證（伺服器憑證）都必須驗證通過，才能取出病歷。AWS Private CA 同時核發這兩張識別證，由 Secrets Manager 整合自動輪替。

HIPAA 的五年稽核窗口，讓 CloudTrail 和 AWS Config 從除錯工具升格為合規基礎建設。

類比三：家族族譜（ACM Private CA 層級）

AWS Private CA 是一棵信任族譜。根 CA 是開台祖——簽名一次後離線保存在保險箱，極少動用，根的簽名只出現在子 CA 上。每個子 CA 對應一個組織單位（OU）、區域或子公司，負責簽發其範圍內工作負載的末端憑證。若某個子 CA 遭到入侵，只需撤銷該子 CA，不影響其他分支的族人。微服務、資料庫、Kubernetes 服務網格的末端憑證是第三代成員——短效、自動輪替、數量龐大。

企業規模下，CA 層級自然對映 AWS Organizations 的 OU 層級：一個根、每個 OU 一個中間 CA、末端憑證按需自動輪替。這正是 SAP-C02 對零信任微服務架構的預期結構。

類比四：公寓大樓門禁系統（憑證自動化 + 輪替）

想像一棟公寓大樓，住戶期望自己的門卡永遠有效。房東每 13 個月悄悄更換所有門鎖，住戶毫無感覺，因為：

• ACM 公開憑證在 ALB 與 CloudFront 上自動輪替；ARN 從不變動，因此底層接線不受影響。
• Secrets Manager 依你設定的排程輪替資料庫密碼與 RDS CA 憑證套件。應用程式按名稱讀取 Secret，不是按值讀取。
• Nitro Enclaves 在每次呼叫時向 KMS 驗證身份，因此即便 enclave 映像檔更新，也不需重新佈建金鑰——enclave 在執行時自行證明自己是合法租戶。

房東等級的目標：任何加密與憑證管理的變更，都不需要重新部署應用程式。 在 Professional 規模，這是基本標準。

KMS 金鑰層級設計——客戶自管 vs AWS 受管的取捨

在 Associate 等級，「使用客戶自管 CMK」是預設的正確答案。在 Professional 等級，每個客戶自管 CMK 都是一個治理物件，必須編列預算、命名、標記、輪替、稽核，並在最終退役。組織若不謹慎，可能累積數萬個 CMK，大多孤兒化、每月各花一美元、範圍重疊。有紀律的組織只維持一個精簡、分層的 CMK 層級。

CMK 所有權的三個層級

• Tier 1——中央安全 CMK：由安全組織擁有的少量高度管控 CMK，通常每種工作負載類別一把（日誌、備份、客戶個資、支付資料）。金鑰政策由中央安全撰寫。使用者只能透過跨帳號金鑰政策委派或 KMS Grants 取得存取權。
• Tier 2——共享服務 CMK：由平台團隊（日誌平台、資料平台、ML 平台）擁有的 CMK，透過跨帳號政策供數十個工作負載帳號使用。當平台跨區域複製資料時，這些金鑰使用 Multi-Region。
• Tier 3——工作負載 CMK：由個別工作負載帳號擁有，僅在該帳號內使用。當工作負載不需要對外共享加密資料時，這是預設選擇。

Professional 等級的技能，就是識別情境落在哪個層級。「集中式日誌儲存桶必須允許 400 個帳號寫入、但只有安全團隊可以解密」→ 安全帳號中的 Tier 1 CMK，搭配對外的跨帳號金鑰政策。「SaaS 應用程式的每租戶客戶自管 CMK」→ Tier 3，搭配每個租戶動態核發的 KMS Grants。

AWS 受管金鑰：什麼時候可以用，什麼時候不行

AWS 受管金鑰（如 aws/s3、aws/rds、aws/secretsmanager 等別名）在大規模環境中仍有其適用場合：

• 資料完全限於單一帳號內，且稽核人員不要求明確的客戶金鑰所有權。
• 成本壓力極大，且 CMK 數量若持續增加將達到數千個。
• 工作負載不受法規約束，且不需要跨帳號解密。

以下情況不得使用 AWS 受管金鑰：

• 情境要求「稽核每次使用」→ 搭配 CloudTrail 的客戶自管 CMK。
• 情境要求「跨帳號」→ 客戶自管 CMK（AWS 受管金鑰無法透過金鑰政策跨帳號共享）。
• 情境要求「事件時撤銷」或「停用金鑰」→ 客戶自管 CMK（你無法停用 AWS 受管金鑰）。
• 情境要求「匯入金鑰材料」或「BYOK」→ 帶有匯入材料的客戶自管 CMK。
• 情境要求「Multi-Region」→ 客戶自管 Multi-Region CMK（AWS 受管金鑰為單區域）。

金鑰命名、別名與大規模標記

Professional 等級的 CMK 管理，成敗在於命名慣例。健全的慣例包含：

• 按層級與領域設定別名前綴：alias/central/logs-cmk、alias/platform/data-lake-cmk、alias/workload/app123-cmk。
• 成本分攤與所有權標記鍵：Owner、Environment、DataClassification、RotationCadence。
• AWS Config 規則強制執行：kms-cmk-not-scheduled-for-deletion、要求標記完整性的自訂規則。
• AWS Organizations SCP 在生產 OU 中拒絕 kms:ScheduleKeyDeletion，除非使用明確的緊急存取角色。

Multi-Region KMS 金鑰——複製材料、獨立金鑰政策

Multi-Region KMS 金鑰解決一個特定問題：多區域主動-主動工作負載需要在任一區域解密同一份密文，而無需重新加密。若沒有 Multi-Region 金鑰，你必須在來源區域解密後，在複製時以目標區域的 CMK 重新加密——成本高昂、速度慢，且是你不想要的跨區域資料平面耦合。

Multi-Region 金鑰的運作方式

Multi-Region KMS 金鑰由一個主要金鑰加上一個或多個副本金鑰組成。所有副本共享相同的金鑰 ID（mrk- 後綴）、相同的金鑰材料，以及相同的密碼學等價性：主要金鑰產生的密文可由任何副本解密，反之亦然。每個副本擁有各自的金鑰政策、Grants、輪替排程，以及繫結至所在區域的獨立 ARN，因此各區域的存取控制保持獨立。

何時使用 Multi-Region 金鑰

• 主動-主動 Amazon DynamoDB Global Tables：在各區域以同一邏輯金鑰對項目進行用戶端加密。
• Amazon S3 跨區域複製搭配 SSE-KMS：目標金鑰與來源共享材料，避免重新包裝的延遲。
• Amazon Aurora Global Database：對敏感欄位進行應用層加密。
• 災難復原情境：容錯移轉到備援區域必須即時完成，不需要重新加密步驟。

何時不應使用 Multi-Region 金鑰

• 獨立的區域資料駐留：若歐盟資料必須用歐盟駐留金鑰加密、美國資料用美國駐留金鑰，請使用獨立單區域 CMK，按區域分開管理密文。
• 稽核範圍隔離：若稽核人員要求可以證明某區域的金鑰使用從未接觸其他區域材料，單區域金鑰更容易辯護。
• 輪替隔離：Multi-Region 輪替會跨區域同步材料；若你想讓各區域的輪替事件彼此獨立，請維持單區域。

跨帳號 KMS 金鑰——共享服務的核心基礎

跨帳號 KMS 是每個集中式日誌、集中式備份，以及資料湖共享服務架構的承重基礎元件。模式不變：一個帳號擁有 CMK，許多帳號產出落入擁有者儲存桶的加密資料，只有嚴格限定的帳號集合能讀回。

標準跨帳號 KMS 金鑰政策

跨帳號 KMS 金鑰政策在預設之外包含三條陳述：

1. 根帳號 Principal："Principal": { "AWS": "arn:aws:iam::111111111111:root" } 搭配 "Action": "kms:*"——讓擁有者可管理金鑰。
2. 跨帳號加密：允許特定的 AWS Organizations OU ID 或帳號根呼叫 kms:GenerateDataKey* 與 kms:Encrypt。這讓 400 個生產者帳號得以寫入加密物件。
3. 跨帳號解密（嚴格限定範圍）：只允許擁有者帳號中安全團隊的角色，以及可能的共享服務讀取角色，呼叫 kms:Decrypt。

搭配集中式儲存桶的 S3 儲存桶政策，要求 s3:x-amz-server-side-encryption-aws-kms-key-id 必須等於擁有者的 CMK ARN——這樣生產者帳號就無法替換成不同的 CMK。

消費者端 IAM

在消費者端（400 個生產者帳號），寫入儲存桶的 IAM 角色需要對擁有者帳號中的特定 CMK ARN 具備 kms:GenerateDataKey。這就是 Associate 等級 KMS 雙政策陷阱在大規模下的放大版：你必須在 400 個帳號中佈建 IAM，任何一個角色缺漏都會讓寫入靜默失敗。

透過 AWS CloudFormation StackSets 或 Terraform landing zone 模組，將 IAM 角色自動注入每個成員帳號即可解決此問題。

跨帳號 KMS Grant 替代方案

與其在靜態金鑰政策中列出數十個帳號 Principal，你可以透過程式化方式核發 KMS Grants——每個工作負載一個 Grant，各有嚴格範圍與可選的退役 Principal。Grants 特別適合：

• 短效工作負載（Lambda、Fargate、Step Functions），呼叫方身份是短暫的。
• 每租戶 SaaS 隔離，每個租戶在共享 CMK 上擁有各自的 Grant。
• 自動化管道，CI/CD 系統核發 Grant、使用後退役。

Grants 是對金鑰政策的附加，因此金鑰政策仍須委派核發 Grants 的能力——通常透過限定 Grant 核發者角色的 kms:CreateGrant。

KMS Grants——臨時委派存取

KMS Grants 是 Professional 等級 KMS 設計中最被低估的武器。金鑰政策是靜態的，IAM 政策是半靜態的，而 Grant 是程式化、有範圍、有時效，且可自動撤銷的。

Grant 的組成要素

一個 Grant 指定：

• 受讓 Principal：將使用 CMK 的 IAM 身份。
• 允許的操作：Encrypt、Decrypt、GenerateDataKey、ReEncryptFrom、ReEncryptTo、CreateGrant、RetireGrant、DescribeKey 的子集。
• Grant 限制條件：加密上下文必須符合特定鍵值對，將 Grant 限縮到特定資源。
• 退役 Principal：誰可以退役（撤銷）此 Grant。
• 過期時間：可選，但對短效工作流程建議設定。

Grants 優於金鑰政策的使用場景

• AWS 服務整合：當 AWS 服務（EBS 掛載磁碟區、Aurora 建立快照、Lambda 呼叫加密環境變數）需要針對特定資源的窄範圍權限時，它會透過加密上下文建立限定該資源的 Grant——而非修改金鑰政策。
• 每租戶 SaaS：在共享 CMK 上每個租戶核發一個 Grant，搭配加密上下文 tenant_id=<id>。租戶離開時退役 Grant。
• 即時提權：緊急應變工作流程為應變人員建立 Grant，將核發事件記錄在 CloudTrail，並在事件窗口結束後自動退役。

帶加密上下文的 Grant 限制條件

加密上下文是傳遞給 Encrypt/Decrypt 呼叫的鍵值對集合；解密時必須提供相同的上下文。Grant 限制條件可以要求特定的加密上下文值，將 Grant 綁定至特定的邏輯資源：

Constraints:
  EncryptionContextEquals:
    tenant_id: "tenant-4271"
    data_class: "phi"

有了這個 Grant，受讓方只有在密文最初以那些精確的加密上下文對加密時，才能解密。這是 AWS 提供的最精細的 KMS 委派方式。

BYOK 與 External Key Store (XKS)——主權金鑰控制

Bring Your Own Key (BYOK) 在 Professional 規模下有兩種截然不同的 AWS 實作方式：

透過匯入金鑰材料的 BYOK

你在地端（HSM 或類似設備）產生金鑰材料，將其匯入客戶自管 CMK，並在 AWS 外保留一份主備份。AWS KMS 使用匯入的材料執行所有密碼學操作，但你可以隨時將材料從 AWS KMS 刪除，讓所有密文立即無法讀取——即所謂的「密碼學銷毀」能力。

取捨：

• 無法自動輪替（匯入材料的 CMK 必須透過將新材料匯入新 CMK 來手動輪替）。
• 可設定過期——你可以為匯入材料設定到期日，過期後 AWS KMS 拒絕使用它。
• 單一授權點：若地端的主備份遺失，且材料已從 AWS 刪除，密文將無法復原。

當法規要求可證明的客戶原始金鑰材料所有權，以及在特定時間窗口內執行密碼學銷毀的能力時，請使用匯入材料的 BYOK。

透過 External Key Store (XKS) 的 BYOK

XKS 是更新、更強的 BYOK 選項。它不是將材料匯入 KMS 讓 KMS 操作，而是讓金鑰材料保留在你自己操作的外部 HSM 或 KMIP 相容金鑰管理員中。每次針對 CMK 的密碼學操作，都透過 XKS Proxy 代理到你的外部金鑰管理員執行，由後者完成操作後回傳結果。AWS KMS 永遠看不到金鑰材料。

取捨：

• 最高主權性：AWS 操作人員在任何情況下都無法存取金鑰材料。
• 操作負擔：你必須自行操作 HSM、XKS Proxy、網路路徑與高可用性。
• 延遲：每次 Encrypt/Decrypt 呼叫都需往返你的 HSM，增加數十至數百毫秒。
• 可用性風險：若 XKS Proxy 或 HSM 無法連線，CMK 操作失敗。依賴該 CMK 的 AWS 服務（RDS、EBS、S3）將遭遇錯誤。

只有當法規明確要求金鑰材料絕對不能存放於 AWS 基礎設施（即便是包裝形式）時，才使用 XKS。這種情況極為罕見，通常是主權政府規模的需求；大多數 HIPAA 和 PCI 工作負載並不需要 XKS。

遷移時的加密補強

遷移時補強加密，是架構永久定型為好或壞的關鍵時刻。Professional 等級對此有大量考題，因為遷移時的錯誤代價最高，也最難逆轉。

Oracle TDE 遷移至搭配 KMS 的 Aurora

Oracle Transparent Data Encryption (TDE) 使用 Oracle 自有的錢包與主金鑰基礎設施。從 Oracle 遷移至 Aurora MySQL 或 Aurora PostgreSQL 時，你不會將 TDE 帶過去——Aurora 在儲存層使用 KMS。遷移模式如下：

1. 確認來源 Oracle 已啟用 TDE，且在遷移期間應用層可以解密（AWS DMS 必須能讀取明文或具備 TDE 憑證）。
2. 建立目標 Aurora 叢集時在建立時啟用 KMS 加密（Aurora 與 RDS 一樣，加密只能在建立時設定）。
3. 對來源與目標端點都使用 SSL 強制執行的 AWS DMS——確保傳輸中的資料絕不以明文出現在網路上。
4. 切換後，針對 Oracle 中以儲存格層級 TDE 保護的欄位，重新引入應用層加密——Aurora 的儲存層 KMS 加密覆蓋面更廣，但粒度較低。

對於保留 TDE 並遷移至 Amazon RDS for Oracle 的工作負載，搭配引用 CMK 的 RDS Option Group 使用 Oracle TDE，以 KMS 作為錢包——保留 TDE 語義，同時透過 AWS 管理錢包。

RDS 快照就地加密複製

「加密未加密的 RDS 執行個體」是每次 SAP-C02 考試的固定考點：

1. 對未加密的來源建立快照。
2. 以 --kms-key-id 指定目標 CMK ARN 並啟用加密來複製快照，複製後產生全新的加密快照。
3. 從加密快照還原至新的加密 RDS 執行個體。
4. 切換應用程式流量（DNS 切換、藍綠部署或邏輯複製）。
5. 退役未加密的來源。

對於最短停機時間，使用 RDS Blue/Green Deployment 功能（適用於 MySQL、MariaDB、PostgreSQL）：Blue 是未加密的生產環境，Green 是從快照建立的加密複製，兩者透過邏輯複製保持同步，執行單一提升命令即可切換。

地端 PKI 遷移至 AWS Private CA

從 Windows Active Directory Certificate Services (AD CS) PKI 遷移至 AWS 時，最乾淨的模式是：

1. 在專用安全帳號中建立 AWS Private CA 根 CA，最好在符合主要工作負載駐留的區域。
2. 在各自帳號中按 OU 或業務單位建立子 CA（從根所在帳號透過 RAM 共享）。
3. 逐步遷移末端憑證：新的核發走 AWS Private CA，現有憑證在目前的有效期內自然消耗。
4. 在過渡期間，將舊的 AD CS 根 CA 與新的 AWS Private CA 根 CA 並列放入信任存放庫。
5. 一旦所有末端憑證都已輪替至 AWS Private CA，從信任存放庫移除 AD CS 根 CA。

PCI HSM 遷移至 CloudHSM

地端 PCI HSM 工作負載（PIN 轉換、以 HSM 為後端的金鑰包裝）無法移到 KMS，因為 KMS 不提供 PCI HSM 工作負載所依賴的 PKCS #11 操作。請改遷移至 CloudHSM：

1. 在目標 VPC 中至少跨兩個可用區域佈建含兩個 HSM 的 CloudHSM 叢集。
2. 使用 CloudHSM Client SDK 的 PKCS #11 函式庫——與地端 HSM 的 API 相同。
3. 在 PCI-DSS 合規文件（Report on Compliance）中記錄 HSM 的 FIPS 140-3 Level 3 認證。
4. 只有在希望 KMS 整合的 AWS 服務（S3、EBS）使用實際駐留在 CloudHSM 叢集上的金鑰時，才將 CloudHSM 連接為 AWS KMS 自訂金鑰存放區。

CloudHSM vs KMS——FIPS 140-3 Level 3 的取捨

在 Associate 等級，規則是「預設用 KMS，只有明確要求時才用 CloudHSM」。在 Professional 等級，你必須能說明為何特定受管制情境下必須使用 CloudHSM。

FIPS 140-3 Level 3 的關鍵差異

AWS KMS 底層 HSM 模組通過 FIPS 140-3 Level 3 驗證（此前為 140-2 Level 3，隨著認證更新持續過渡至 140-3）。使用 FIPS 端點時，整體 KMS 服務以 FIPS 140-3 Level 3 運作。AWS CloudHSM 同樣是 FIPS 140-3 Level 3——但關鍵差異在於誰是 HSM 操作員：

• KMS FIPS 140-3 Level 3：AWS 是 HSM 操作員；AWS 運維團隊持有 HSM 管理憑證（受 AWS 內部控制約束）。
• CloudHSM FIPS 140-3 Level 3：你是 HSM 操作員；你持有密碼學長官（Crypto Officer）憑證；AWS 運維無法對你的 HSM 執行任何密碼學操作。

對許多法規而言，這個差異無關緊要——KMS 已足夠。對少數受管工作負載，它卻是關鍵：

• PCI HSM（PIN 轉換、PIN 驗證）：要求單租戶 HSM，收單銀行為唯一操作員。
• 部分美國 DoD 與情報社群工作負載：要求客戶自操 HSM。
• 部分歐盟金融法規（PSD2 合格電子簽章、德國 BSI TR-03145）：要求具有文件記錄的獨家保管 HSM。
• AWS 區域以外司法管轄區的資料主權駐留：當法規接受 AWS 硬體但不接受 AWS 操作時——CloudHSM 是折衷方案。

CloudHSM 的可用性與成本現實

CloudHSM 叢集生產環境至少需要跨兩個可用區域的兩個 HSM。以約每 HSM 每小時 USD 1.45 計算，兩個 HSM 的叢集按牌價約每月 USD 2,100，不含資料傳輸費用。跨三個可用區域的三個 HSM 才是真正容錯隔離的最佳實踐，讓每月費用超過 USD 3,000（每叢集）。這還未計入密碼學長官的人力成本。

相較之下，KMS 每個客戶自管 CMK 每月 USD 1.00 再加請求費用。超過 99% 的工作負載，KMS 在成本上勝出。

CloudHSM 作為 KMS 自訂金鑰存放區

若你想使用 CloudHSM 駐留的金鑰，同時享有 KMS 服務整合的優勢，可將 CloudHSM 連接為 KMS 的自訂金鑰存放區。自訂金鑰存放區中的 CMK，金鑰材料實際位於 CloudHSM 上，但對 KMS 整合的服務（S3、EBS、RDS）看起來就像普通 CMK。取捨：這些 CMK 的每次密碼學操作都會打到 CloudHSM，因此 CloudHSM 的可用性成為你的 S3/RDS/EBS 流量的依賴條件。

ACM Private CA 架構——內部 mTLS 的 CA 層級設計

AWS Private CA（前稱 ACM Private CA，現通常簡稱 Private CA）是發行私有 TLS 憑證的受管服務——這些憑證只有在客戶端的信任存放庫中包含 Private CA 根憑證時才會被信任。在 Professional 規模下，Private CA 設計就是層級設計。

三層層級模式

企業級 Private CA 部署採用三層層級：

1. 根 CA——單一根、離線啟動、放在專用安全帳號，只對子 CA 簽名。有效期通常為 10 年。以 KMS 加密靜態儲存，極少動用。
2. 子（中間）CA——每個 OU、業務單位或主要工作負載領域一個。從安全帳號透過 RAM 共享至擁有帳號。簽發末端憑證。有效期 3–5 年。輪替計畫：在舊有效期到期前 6 個月建立新子 CA，逐步遷移工作負載，然後退役舊的。
3. 末端憑證——短效（通常 1–30 天），針對個別服務發行，透過 ACM-Private-CA 整合或直接 API 呼叫核發，自動輪替。

每 OU 各有子 CA

選擇每 OU 一個子 CA 而非單一扁平 CA 的原因是爆炸半徑。若某個子 CA 的私鑰遭到入侵，只需撤銷該子 CA——其他 OU 的憑證不受影響。撤銷透過發布至 S3 的 CRL（Certificate Revocation List）或 OCSP（Online Certificate Status Protocol）回應伺服器進行；兩者都由 Private CA 管理，但必須由你的客戶端消費。

AWS Organizations OU 結構自然對映到此：每個 OU 的共享服務帳號中各有一個子 CA，透過 RAM 共享至該 OU 內的工作負載帳號。

mTLS 服務網格整合

Private CA 末端憑證讓整個服務網格可以啟用 mutual TLS：

• App Mesh 透過 Virtual Node 的 TLS 政策消費 Private CA；每個 Proxy sidecar 都擁有自己的末端憑證。
• EKS 搭配 Istio 或 Linkerd 可透過 cert-manager 附加元件或 AWS 自身整合使用 Private CA。
• Kubernetes Ingress 的 mTLS——ALB 支援 mTLS，帶有針對信任存放庫驗證用戶端憑證的功能，信任存放庫通常由 Private CA 的 CRL 或靜態憑證鏈填充。

每個 mTLS 端點都必須佈建：

• 來自 Private CA 的伺服器憑證（每 1–30 天輪替）。
• 來自 Private CA 的用戶端憑證（相同節奏）。
• 包含相關子 CA 憑證的信任存放庫套件。

ACM-Private-CA 整合實現受管輪替

ACM 可以作為 Private CA 在 ELB 與 CloudFront 上末端憑證的受管前端——你透過 ACM 申請憑證，指定 Private CA 為核發者，ACM 就像處理公開憑證一樣自動處理更新。這避免了為 ELB 終端 mTLS 撰寫輪替膠水程式碼。

憑證自動化——Secrets Manager、RDS、ELB、CloudFront、Nitro Enclaves

憑證自動化是確保憑證輪替永遠不需要人工介入、也不需要重新部署應用程式的學科。

Secrets Manager 管理 RDS 憑證與 CA 套件

Secrets Manager 透過基於 Lambda 的輪替函數，按排程輪替資料庫憑證。應用程式按 ARN 讀取 Secret；輪替函數同步更新 Secret 值與資料庫使用者密碼。對於 RDS CA 憑證套件輪替（簽署 RDS 伺服器憑證的 AWS RDS CA），Amazon 每隔幾年輪替一次 CA；在過渡期間，你需要更新客戶端的信任套件，同時包含新舊兩個 RDS CA，然後再移除舊的。

大規模的模式如下：

1. Secrets Manager 同時保存資料庫密碼與 CA 套件路徑或 CA 指紋。
2. 應用程式在啟動時和收到類似 SIGHUP 的重新載入觸發時，從 Secrets Manager 讀取。
3. EventBridge 規則監聽 aws.rds:rds-ca-rotation 觸發一條管道，將新 CA 套件推送至所有應用程式。

ACM 用於 ELB 與 CloudFront

ACM 公開憑證在 ALB、NLB（帶 TLS 監聽器）、CloudFront、API Gateway、App Runner 上自動透明輪替。操作規則：

• 在憑證整個生命週期內保持 DNS 驗證 CNAME 可連線。
• 對於 CloudFront，ACM 憑證必須位於 us-east-1。
• 對於多 SAN 憑證，使用 ACM 萬用字元或明確的 SAN 清單；每張憑證的輪替是原子性的。

Nitro Enclaves 實現機密運算

Nitro Enclaves 是一個隔離的 Amazon EC2 運算環境，可向 AWS KMS 密碼學驗證自身身份。驗證文件證明：

• Enclave 映像雜湊（正在執行哪個二進位檔）。
• 父執行個體身份。
• PCR（Platform Configuration Registers）量測值。

KMS 支援政策條件鍵 kms:RecipientAttestation:ImageSha384，允許 CMK 被映像雜湊符合的 enclave 所使用。金融服務公司就是這樣建立錢包託管系統，醫療公司就是這樣建立 PHI 處理 enclave：enclave 在記憶體中解密敏感資料、進行處理並回傳結果——並提供密碼學證明，讓人確信沒有其他程式碼可以存取明文。

資料庫傳輸中 TLS 遷移

對於 Aurora、RDS、Redshift：

• Aurora MySQL / MySQL RDS：在 DB 參數群組中啟用 require_secure_transport=1，拒絕非 TLS 連線。
• Aurora PostgreSQL / PostgreSQL RDS：在 DB 參數群組中設定 rds.force_ssl=1。
• Aurora TLS 模式：AWS_RDS_FORCE_SSL、VERIFY_CA、VERIFY_IDENTITY——選擇 VERIFY_IDENTITY 以驗證主機名稱，這是防禦 MITM 的必要條件。
• 客戶端 CA 套件：rds-combined-ca-bundle.pem 包含所有區域的 RDS CA，或使用各區域套件以縮小信任範圍。

現有明文連線的遷移計畫：

1. 將 RDS CA 套件部署至所有客戶端。
2. 在客戶端啟用 TLS（連線字串加上 sslmode=require 或對等設定）。
3. 確認所有客戶端成功透過 TLS 連線（CloudWatch 指標 DatabaseConnections 搭配 Performance Insights）。
4. 在參數群組中切換 require_secure_transport=1 / rds.force_ssl=1。
5. 監控被拒連線；若出現意外失敗，回滾參數群組。

輪替策略——CMK 輪替、別名、大規模金鑰政策與 IAM

大規模的輪替不是「啟用自動輪替然後走人」。它是一場讓數千個 CMK 在七到十年合規期限內維持健康的編排工作。

自動輪替——何時足夠

對於帶有 AWS 自有材料的客戶自管對稱 CMK，自動輪替是正確的預設值。預設 365 天，可設定為 90–2560 天。透過 AWS Config 規則（cmk-backing-key-rotation-enabled），在每個此類 CMK 上預設啟用它。

手動輪替——何時自動輪替不可用

自動輪替不適用於：

• 非對稱 CMK。
• 帶有匯入金鑰材料的 CMK（BYOK）。
• 由 external key store (XKS) 支援的 CMK。
• CloudHSM 自訂金鑰存放區中的 CMK（須遵循 CloudHSM 特定程序）。

對於這些情況，輪替模式如下：

1. 以全新材料建立新的 CMK。
2. 更新別名（alias/my-app-cmk）指向新的 CMK。
3. 對需要使用新材料的現有密文，執行使用 kms:ReEncrypt* 的重新加密掃描。
4. 排定舊 CMK 刪除（7–30 天等待期）。

只引用別名的應用程式可持續運作，無需修改程式碼。

別名作為唯一事實來源

每個生產工作負載都應透過別名引用 CMK，而非透過金鑰 ID 或 ARN。別名讓你可以輪替底層 CMK，而不需修改應用程式組態。別名命名慣例應編碼層級、工作負載與環境：alias/workload-phi-prod、alias/central-logs-prod。

大規模下金鑰政策與 IAM 的交互

大規模環境中，金鑰政策 + IAM + SCP + Grants 的交互作用形成一個治理問題：

• 金鑰政策是主角。大規模環境中，透過 IaC（CloudFormation 或 Terraform）維護金鑰政策，並要求變更審核。
• IAM 身份政策從金鑰政策授權委派而來。大多數工作負載只授予 kms:Decrypt 與 kms:GenerateDataKey；kms:ScheduleKeyDeletion 與 kms:DisableKey 保留給專用安全角色。
• SCP 在 AWS Organizations 層級，在沒有特定緊急存取角色標記的情況下，拒絕生產 OU 中的 kms:ScheduleKeyDeletion。
• Grants 動態處理每工作負載的委派，特別是無伺服器與每租戶場景。
• CloudTrail + AWS Config + Security Hub 追蹤漂移——任何 IaC 範圍外的金鑰政策變更都會產生告警。

Professional 情境——醫療應用遷移：BYOK + mTLS + HIPAA + 五年稽核軌跡

貫穿情境是一家美國醫療 SaaS 從地端遷移至 AWS，需求如下：

• HIPAA 合規，已簽署 BAA，所有 PHI 靜態與傳輸中均加密。
• BYOK：客戶的合規團隊堅持從地端 HSM 帶入自有金鑰材料（需要密碼學銷毀能力）。
• mTLS 應用於所有內部微服務——VPC 內不允許任何明文流量。
• 五年稽核軌跡：記錄每一筆 PHI 存取事件。

目標架構

AWS Organizations 結構：安全 OU、工作負載 OU（Prod / Non-prod 子 OU）、Logging OU。CMK 與 CA 層級遵循 OU 樹。

金鑰層級：

• Tier 1 中央安全帳號 CMK：帶匯入材料的 BYOK CMK（alias/phi-central），us-east-1 與 us-west-2 的 Multi-Region 副本用於 DR。匯入材料每兩年到期，透過新的匯入流程輪替。
• Tier 2 資料湖 CMK：客戶自管、自動輪替，跨帳號政策共享至所有工作負載帳號。
• Tier 3 工作負載 CMK：每個工作負載各自的客戶自管 CMK，用於 EBS、RDS、Aurora、Secrets Manager。啟用自動輪替。
• KMS Grants：由 SaaS 控制平面按租戶核發，以加密上下文 tenant_id=<uuid> 限定範圍。

憑證層級：

• AWS Private CA 根 CA 位於安全帳號，除子 CA 簽名事件外保持離線。
• 每個 OU（Prod-Workloads、Non-prod-Workloads）各有子 CA，透過 RAM 共享至各帳號。
• 末端憑證短效（7 天），透過 ACM-Private-CA 整合核發，自動輪替。
• 服務網格（App Mesh）在每個服務間呼叫上強制執行 mTLS。
• 外部 API 的用戶端 mTLS 在 ALB 處理，信任存放庫引用已發布的 CRL。

傳輸中控制：

• RDS Aurora PostgreSQL 設定 rds.force_ssl=1，客戶端強制執行 VERIFY_IDENTITY。
• S3 儲存桶的儲存桶政策拒絕 aws:SecureTransport=false。
• KMS、S3、Secrets Manager 的 VPC 端點，確保資料不穿越公網。

五年稽核軌跡：

• CloudTrail 組織軌跡寫入專用 Logging 帳號 S3 儲存桶，搭配 Object Lock 合規模式與五年保留期。儲存桶以帶有跨帳號唯寫政策的日誌專用客戶自管 CMK 加密。
• AWS Config 組織聚合器位於安全帳號，將設定歷史記錄至同一日誌儲存桶。
• CloudWatch Logs 保留 KMS 金鑰使用事件、Secrets Manager 輪替事件、Private CA 憑證核發事件，保留期五年。
• Security Hub + GuardDuty 將發現事件交付至同一五年保留期的 S3 接收端。

密碼學銷毀能力：

• 由於 Tier 1 BYOK CMK 使用匯入材料，合規團隊在地端保留一份密封的主材料備份。若合約終止，地端主材料銷毀後，從 KMS 刪除材料（kms:DeleteImportedKeyMaterial）——所有以該 CMK 衍生的信封加密的密文都將無法復原。

為何此處不使用 CloudHSM？

客戶的合規團隊最初要求 CloudHSM。架構審查後推翻了此要求：HIPAA 不強制要求單租戶 HSM，BYOK 匯入材料 CMK 滿足「自帶金鑰」的需求，而 KMS + Private CA 整合比 CloudHSM 用於一般資料平面便宜得多，且自動化程度更高。若未來因新增支付處理功能而出現 PCI HSM 需求，CloudHSM 仍可作為選項。

為何此處不使用 XKS？

XKS 能讓金鑰材料完全保存在地端，但對於擁有數百個並發租戶、每分鐘執行數千次解密呼叫的 SaaS 而言，其操作與延遲成本令人無法承受。XKS 保留給未來的主權工作負載（歐盟資料駐留合約），屆時取捨才是可接受的。

關鍵數字與必記事實——大規模 AWS 加密與憑證管理

常見考試陷阱——大規模 AWS 加密與憑證管理

陷阱 1：Multi-Region 金鑰 vs 跨帳號金鑰

情境：帳號 A 的區域 B 工作負載讀取以帳號 A 區域 A CMK 加密的物件。干擾選項建議 Multi-Region 副本可以解決此問題。事實上，Multi-Region 只解決區域維度——若兩個帳號相同，你只需要在區域 B 的副本。但若工作負載位於帳號 B，你仍然需要在區域 B 副本 CMK 上設定跨帳號金鑰政策。

陷阱 2：BYOK vs XKS

情境：「客戶要求 Bring Your Own Key」。干擾選項跳到 XKS。若要求只是「持有主備份並能密碼學銷毀」，匯入材料的 BYOK 就足夠了。只有在「金鑰材料絕不能存放於 AWS 基礎設施，即便是包裝形式」被明確要求時，才需要 XKS。

陷阱 3：CloudHSM vs KMS 用於 HIPAA

HIPAA 不要求 CloudHSM。預設使用 KMS 客戶自管 CMK。只有當法規或合約明確要求單租戶 HSM、PCI HSM，或以客戶為操作員的 FIPS 140-3 Level 3 時，CloudHSM 才是必要的。

陷阱 4：RDS/EBS/Aurora 的加密無法就地啟用

任何「修改 RDS 執行個體以啟用加密」的答案都是錯的。正確流程：快照 → 啟用加密的複製 → 還原 → 切換，或使用 Blue/Green Deployment。

陷阱 5：ACM 憑證無法匯出（僅限公開）

公開 ACM 憑證無法匯出。AWS Private CA 末端憑證可以匯出。需要在 EC2 執行個體或地端端點安裝憑證的情境，必須使用 Private CA、第三方，或 ALB 終端。

陷阱 6：KMS 金鑰政策必須明確委派給 IAM

大規模環境中，新 CMK 的金鑰政策若缺少「啟用 IAM 政策」陳述，會讓所有僅用 IAM 的工作負載失效。在每個建立 CMK 的 IaC 範本中都加入此陳述。

陷阱 7：跨帳號 KMS 需要兩端都佈建

光有 CMK 金鑰政策，若消費者帳號缺少 IAM 角色，呼叫仍然失敗。請在擁有者設定金鑰政策的同時，透過 StackSets 或 Terraform 在消費者帳號佈建 IAM。

陷阱 8：Multi-Region 金鑰不是免費複製

每個副本都按獨立 CMK 計費（每月 USD 1.00）。十個區域的 Multi-Region 金鑰每月基礎費用 USD 10.00，加上各區域的請求費用。請妥善規劃。

陷阱 9：Nitro Enclave 的 KMS 存取需要 ImageSha384 條件

映像雜湊未綁定在 CMK 金鑰政策條件中的 enclave 無法解密，即便 enclave 的父執行個體角色具有 kms:Decrypt。這是設計如此——以驗證綁定的條件，才是讓 enclave 具有密碼學隔離性的關鍵。

陷阱 10：Private CA 根不得直接簽發末端憑證

提議根 CA 直接核發工作負載憑證的情境是不良實踐。一定要使用子 CA，無論是為了爆炸半徑考量，還是為了維持根離線狀態。

AWS 加密與憑證管理 vs 存取控制

在 Professional 等級，AWS 加密與憑證管理和存取控制的交互作用是多層次的：

• IAM、SCP、RCP、資源政策決定誰能呼叫 API。
• KMS 金鑰政策、Grants、加密上下文決定誰能使用密碼金鑰。
• Private CA + mTLS 決定誰甚至可以與服務建立網路連線。
• Nitro Enclaves + 驗證決定哪個程式碼能解密資料，而不只是哪個 IAM 角色。
• CloudTrail + Config + Object Lock 在五到七年的期限內向稽核人員證明上述一切。

成熟的 Professional 等級架構應用所有五個層次；SAP-C02 情境的得分關鍵，在於識別何時加密上下文、mTLS 或 enclave 驗證是缺失的那一環。

情境練習題索引

• 「集中式日誌儲存桶必須允許 400 個成員帳號寫入，但只有安全團隊的調查角色可以解密。」→ 安全帳號中的中央 CMK，搭配加密的跨帳號金鑰政策，以及對單一角色的窄範圍解密，儲存桶政策要求指定的 CMK ARN。
• 「醫療 SaaS 要求 BYOK，且在合約終止時可執行密碼學銷毀。」→ 匯入金鑰材料 CMK，搭配地端主備份；透過 kms:DeleteImportedKeyMaterial 執行銷毀。
• 「多租戶 SaaS 在共享 CMK 上實現每租戶隔離。」→ 搭配加密上下文 tenant_id 的每租戶 KMS Grants。
• 「以最短停機時間將 Oracle TDE 資料庫遷移至 Aurora，並保留加密。」→ 建立時啟用 KMS 加密的 Aurora + 帶 SSL 端點的 DMS + Blue/Green Deployment 切換。
• 「零信任微服務網格，每 7 天輪替一次憑證。」→ 每 OU 一個 AWS Private CA 子 CA + ACM-Private-CA 整合用於 ELB + App Mesh/Istio 用於內部 mTLS。
• 「機密運算：只在已簽名的 enclave 映像內解密 PHI。」→ Nitro Enclaves + 帶 kms:RecipientAttestation:ImageSha384 條件的 CMK。
• 「跨區域 DR，無重新加密步驟。」→ 在目標區域的 Multi-Region CMK 副本。
• 「PCI HSM 工作負載從地端 Thales HSM 遷移至 AWS。」→ 跨 2 個可用區域、含 2 個以上 HSM 的 CloudHSM 叢集 + PKCS #11 客戶端函式庫。
• 「對整個組織的每個 S3 儲存桶強制執行僅 HTTPS。」→ 在 aws:SecureTransport = false 時拒絕 s3:* 的 SCP。
• 「每次 KMS 解密呼叫的五年防竄改稽核軌跡。」→ CloudTrail 組織軌跡寫入帶 Object Lock 合規模式的 S3 儲存桶，五年保留期，搭配日誌專用 CMK。

FAQ——Professional 規模的 AWS 加密與憑證管理

Q1：何時應使用 Multi-Region KMS 金鑰，何時應使用兩個獨立的單區域 CMK？

當相同密文必須在多個區域解密，且無需重新加密步驟時，使用 Multi-Region KMS 金鑰——典型場景包括帶用戶端加密的 DynamoDB Global Tables、帶 SSE-KMS 的 S3 跨區域複製、Aurora Global Database 欄位層級加密，以及主動-主動 DR。若各區域有不同的資料駐留邊界（歐盟 vs 美國）、稽核範圍必須按區域可證明，或你希望輪替事件各區域獨立，則使用獨立單區域 CMK。Multi-Region 金鑰每個副本區域每月計費一美元，費用線性增長。Multi-Region 解決地理問題，而非租戶問題：跨帳號解密仍需在每個副本上設定標準跨帳號金鑰政策。

Q2：HIPAA 應選擇匯入金鑰材料 BYOK 還是 External Key Store (XKS)？

在 AWS 上的 HIPAA 情境，匯入金鑰材料 BYOK 幾乎總是足夠且務實的選擇。它滿足「客戶擁有主金鑰材料」的要求，並按需啟用密碼學銷毀，同時讓 KMS 以正常 KMS 延遲執行密碼學操作。XKS 讓所有密碼學操作在客戶自操 HSM 上執行，增加了數十至數百毫秒的延遲，並讓 HSM 成為每次加密資料平面呼叫的可用性依賴。只有當法規或合約明確要求「金鑰材料絕不能存放於 AWS 基礎設施，即便是包裝形式」時——通常是主權政府規模而非 HIPAA——才考慮 XKS。

Q3：如何為大型組織設計 AWS Private CA 層級？

已驗證的模式是三層：一個離線根 CA 位於專用安全帳號；每個 AWS Organizations OU 一個子 CA（Prod、Non-prod、Dev 或按業務單位），透過 RAM 共享至各帳號；以及短效末端憑證（通常 1–30 天），從子 CA 核發。這讓根的私鑰在子 CA 簽名事件以外保持離線、將子 CA 遭到入侵的爆炸半徑限縮至一個 OU，並透過 ACM-Private-CA 整合在 ELB、CloudFront 和 App Runner 上實現自動末端憑證輪替。撤銷使用發布至 S3 的 CRL 或 OCSP。對於服務網格 mTLS（App Mesh、EKS 搭配 Istio），每個 Proxy sidecar 都有自己每日或每週輪替的末端憑證。

Q4：KMS Grants 在多帳號企業中應如何定位？

KMS Grants 是臨時、程式化、資源範圍委派的正確工具——特別是當靜態金鑰政策會因數百個 Principal 而膨脹，或呼叫方是短效的（Lambda、Fargate、Step Functions）時。典型 Professional 等級用途：每租戶 SaaS 隔離（共享 CMK 上每個租戶一個 Grant，透過加密上下文 tenant_id 限定範圍）、AWS 服務整合（EBS 建立磁碟區、Aurora 建立快照），以及自動退役的即時事件應變提權。Grants 是附加性的——它們無法覆蓋金鑰政策的拒絕——且完整記錄在 CloudTrail 中。不要用 Grants 取代結構良好的金鑰政策；兩者應並用。每個 CMK 可持有約 50,000 個 Grants 才會達到軟性限制。

Q5：何時應選擇 CloudHSM 而非帶匯入金鑰材料的 KMS？

只有當法規或合約明確要求客戶為唯一密碼學長官的單租戶 HSM 時，才選擇 CloudHSM 而非 KMS BYOK——例如 PCI HSM（PIN 轉換、PIN 驗證）、某些美國 DoD/情報社群工作負載，以及部分要求 HSM 硬體獨家保管文件的歐盟金融法規。另外，當你需要地端或第三方軟體所依賴的 PKCS #11、JCE 或 Microsoft CNG 整合，而這些軟體不支援 KMS API 時，也應選擇 CloudHSM。對於純粹「自帶金鑰」的 HIPAA 或受管 SaaS 情境，若 KMS API 可接受，帶匯入材料的 KMS 更便宜（每月 USD 1 vs 數千美元）、更易操作，且足以滿足密碼學銷毀需求。

Q6：如何在不破壞現有信任的情況下，將地端 TLS PKI 遷移至 AWS？

在現有地端 PKI 旁邊建立 AWS Private CA 根 CA + 子 CA，將 AWS 根憑證與地端根憑證並列推入所有客戶端信任存放庫（雙信任期），然後逐工作負載進行末端憑證核發的可控移轉至 AWS Private CA 層級。現有地端憑證在有效期內自然消耗；新的核發走 AWS。一旦所有工作負載都已輪替至 AWS 核發的憑證，從信任存放庫移除地端根憑證。注意快取 CA 套件的客戶端（JVM 信任存放庫、嵌入式設備）——它們需要明確的套件更新才能信任新根憑證。對於 mTLS 服務網格，利用 cert-manager 或 AWS App Mesh 的原生 Private CA 整合，確保輪替自動化。

Q7：AWS 上的 KMS 與憑證事件的五年稽核軌跡長什麼樣？

啟用一條 CloudTrail 組織軌跡，將管理與資料事件記錄至專用 Logging 帳號 S3 儲存桶，並以 Object Lock 合規模式保護，設定五年保留期。Object Lock 合規模式連根使用者都無法縮短保留期——正是 HIPAA、PCI-DSS 和 SOX 稽核人員所需要的。以日誌專用客戶自管 CMK 加密儲存桶，設定窄範圍跨帳號唯寫政策（生產者帳號可以 PutObject 但無法 GetObject）。搭配 AWS Config 組織聚合器（每個 KMS CMK、每張憑證、每次輪替的設定歷史）、Security Hub 發現事件交付至同一接收端，以及帶五年保留期的 CloudWatch Logs 用於應用層存取日誌。每次 KMS 解密、每次 Grant 核發、每次 CMK 政策變更、每次 Private CA 憑證核發、每次 Secrets Manager 輪替事件，都在完整窗口內被捕獲且不可竄改。

Q8：如何從用戶端到 ALB 再到 Aurora，端到端強制執行 mTLS？

端到端 mTLS 有三個躍點：用戶端至 ALB、ALB 至應用程式、應用程式至 Aurora。對於用戶端至 ALB，設定 ALB 為 mTLS 驗證模式，搭配引用 AWS Private CA 子 CA 的信任存放庫套件。對於 ALB 至應用程式，從同一子 CA 向應用程式目標核發末端憑證，並在應用程式端驗證。對於應用程式至 Aurora，在 DB 參數群組中設定 rds.force_ssl=1 或 require_secure_transport=1，連線字串使用 sslmode=verify-full（PostgreSQL）或 --ssl-mode=VERIFY_IDENTITY（MySQL），並將 rds-combined-ca-bundle.pem 發送至每個應用程式執行個體——在 AWS 發布新 RDS CA 時透過 Secrets Manager 輪替。在切換強制執行前，使用 CloudWatch 指標和 RDS Performance Insights 監控非 TLS 連線，以避免將落後的連線鎖定在外。

延伸閱讀

• AWS Key Management Service Developer Guide
• AWS KMS Multi-Region Keys
• AWS KMS Cross-Account Access
• AWS KMS Grants
• AWS KMS External Key Store (XKS)
• AWS KMS Importing Key Material (BYOK)
• AWS KMS Rotating Keys
• AWS CloudHSM User Guide
• AWS CloudHSM Cluster Architecture
• AWS Certificate Manager User Guide
• AWS Private Certificate Authority User Guide
• AWS Private CA Hierarchy Planning
• AWS Nitro Enclaves User Guide
• Amazon RDS SSL/TLS Connections
• Amazon Aurora SSL/TLS Connections
• AWS Secrets Manager Rotation
• AWS SAP-C02 Exam Guide (PDF)