資料加密與金鑰管理

AWS 資料加密與金鑰管理，是一套保護資料在靜態（磁碟、物件儲存、資料庫）與傳輸中（客戶端與 AWS 服務之間、AWS 服務彼此之間的網路傳輸）安全的 AWS 服務與設計模式。旗艦服務是 AWS Key Management Service（AWS KMS），負責建立並管控加密金鑰，供 Amazon S3、Amazon EBS、Amazon RDS、Amazon DynamoDB、AWS Lambda 及數十項其他 AWS 服務用來加密您的資料。對於需要單租戶 FIPS 140-2 Level 3 硬體的工作負載，AWS CloudHSM 提供您專屬的硬體安全模組（HSM）叢集。對於終止 Elastic Load Balancers、Amazon CloudFront 及 Amazon API Gateway 上 HTTPS 流量所需的 TLS 憑證，AWS Certificate Manager（ACM） 自動處理簽發、更新與部署。AWS KMS、AWS CloudHSM 與 AWS Certificate Manager 共同構成 AWS 的資料加密與金鑰管理層。

在 SAA-C03 考試中，Task Statement 1.3（「判斷適當的資料安全控制」）要求您能針對各種情境挑選正確的 AWS 資料加密與金鑰管理服務、理解 envelope encryption、區分 SSE-S3、SSE-KMS、SSE-C 與 DSSE-KMS，知道何時該選 CloudHSM 而非 AWS KMS、了解 AWS KMS 金鑰輪換，以及正確套用 TLS 傳輸中加密。本指南以白話文解說每個概念，點出讓考生屢屢失誤的陷阱，並提供容易記憶的類比，讓資料加密與金鑰管理的詞彙真正紮根。

什麼是 AWS 資料加密與金鑰管理？

AWS 資料加密與金鑰管理是 AWS 原生框架，在資料的整個生命週期中施加密碼學保護。靜態加密在資料寫入儲存媒體（Amazon S3 物件、Amazon EBS 磁碟區、Amazon RDS 資料表、Amazon DynamoDB 項目、Amazon EFS 檔案）前將其轉換為密文，確保媒體遭竊或未授權的 AWS 操作員無法讀取。傳輸中加密以 TLS 包裹資料，讓客戶端與 AWS 服務之間、或兩個 AWS 服務之間的網路竊聽者只能看到密文。

兩個面向都依賴金鑰，而金鑰才是難點所在。洩露的金鑰能使最強的演算法失效，因此 AWS 資料加密與金鑰管理把金鑰存放位置、使用者、輪換時機與稽核方式視為首要設計考量。AWS KMS 是 AWS 對這些問題的解答：一項受管 AWS 服務，底層配備硬體安全模組，絕不將您的金鑰材料暴露給 AWS KMS 邊界之外的任何人或程序。

AWS 資料加密與金鑰管理對 SAA-C03 的重要性

Task 1.3（「判斷適當的資料安全控制」）約佔 Design Secure Architectures 領域（佔考試 30%）的四分之一，而 AWS 資料加密與金鑰管理是其中最主要的子主題。出題者偏好以下情境：「哪種 AWS KMS 金鑰類型可讓您稽核使用記錄？」（客戶受管金鑰）、「如何強制執行 FIPS 140-2 Level 3？」（AWS CloudHSM）、「如何在 Application Load Balancer 上終止 TLS 且不需購買憑證？」（AWS Certificate Manager）、「哪種 S3 加密選項讓我擁有金鑰所有權？」（SSE-C 或搭配客戶受管金鑰的 SSE-KMS）。能自信回答這四題，資料加密與金鑰管理就不再是弱點。

白話文解釋 AWS Data Encryption and Key Management

理論若能對應到具體的事物，才容易記住。以下四個類比涵蓋 SAA-C03 所有主要的 AWS 資料加密與金鑰管理概念。

類比一：銀行保險庫與保管箱（Envelope Encryption）

想像一間大銀行，有一個主保險庫和數千個保管箱。主保險庫就是 AWS KMS key——它藏在厚重的牆後，由行庫管理員（AWS KMS 服務）控管，從不離開銀行。每個保管箱的鑰匙就是 AWS KMS data key——每當客戶要存入新東西，管理員就會產生一把全新的鑰匙。您的實際文件（客戶資料）以這把 data key 鎖進保管箱。存放文件時，客戶請 AWS KMS 產生一把全新的 data key，用明文 data key 鎖好文件後，立即將明文版本送回保險庫（從記憶體清除），只保留加密後的 data key放在文件旁。之後要取出文件，客戶將加密的 data key 交還管理員，管理員在保險庫內解密後，將明文 data key 交回以開啟保管箱。保險庫的金鑰（AWS KMS key）從未離開保險庫。這就是 envelope encryption，也是幾乎所有 AWS 服務在整合 AWS KMS 時採用的模式。

類比二：飯店總鑰匙 vs 私人房間保險箱（KMS vs CloudHSM）

想像一間飯店。AWS KMS 是飯店集團的中央配鑰台——方便、隨時有人值班、供多間房間共用，但飯店集團擁有並營運這個配鑰台。AWS CloudHSM 是您在豪華套房裡的私人保險箱——只有您知道密碼，飯店集團的人無法打開，備份與可用性也由您一人負責。當法遵稽核人員要求就連 AWS 員工都無法碰觸金鑰材料、且硬體必須達到 FIPS 140-2 Level 3 認證時，您就需要私人保險箱（AWS CloudHSM）。否則，中央配鑰台（AWS KMS）更便宜、更簡單，且在預設模式下已符合絕大多數常見金鑰操作的 FIPS 140-2 Level 3 要求。

類比三：瑞士刀的多種刀刃（S3 加密選項）

Amazon S3 的伺服器端加密就像一把有四種刀刃的瑞士刀。SSE-S3 是主刀刃——隨時鋒利、無需設定：Amazon S3 自行選擇金鑰、管理、輪換並加密您的物件。SSE-KMS 是專用切割刀刃——您選擇使用哪把 AWS KMS key（AWS 受管或客戶受管），每次解密呼叫都有 AWS CloudTrail 稽核記錄，並可套用細粒度的 AWS KMS 金鑰政策與 grants。SSE-C 是您自帶的工具——每次請求都必須附上加密金鑰，Amazon S3 用完就丟，不保留該金鑰，若金鑰遺失，物件即永久無法存取。DSSE-KMS 是加強版雙層刀刃——兩層獨立的伺服器端 AES-256 加密疊加，針對需要高保證標準的法規工作負載設計。根據需求選刀刃：快速預設 → SSE-S3；需要稽核＋金鑰控管 → SSE-KMS；必須自行持有金鑰材料 → SSE-C；需達到雙層法規要求 → DSSE-KMS。

類比四：郵局信封與封蠟印章（TLS 傳輸中加密與 ACM）

TLS 傳輸中加密就像透過郵局寄送密封信件。信封是 TLS 工作階段，封蠟印章是 TLS 憑證，郵局驗章員是確認印章真偽的 TLS 握手過程。AWS Certificate Manager 是文具行，免費為您印製封蠟印章，並在舊印章過期前自動將新印章送到您的收件地址（Application Load Balancer、Amazon CloudFront 分發、Amazon API Gateway 或 AWS App Runner），您完全不需碰觸私鑰材料——ACM 將其保存在 AWS 服務內部，每 13 個月自動更新一次。若您需要在組織內部建立私有郵遞網絡，AWS Certificate Manager Private CA 就是您的自用印章機，只有組織內部認可，用於內部微服務間的 TLS 通訊。

AWS KMS 概念：CMK、AWS 受管金鑰與客戶受管金鑰

AWS KMS 以 AWS KMS key（歷史上稱為 customer master key，CMK）為核心物件，其他所有 AWS KMS 功能（data key、grants、輪換、金鑰政策）都圍繞此物件運作。理解 AWS KMS key 的三種類型，是提升 AWS 資料加密與金鑰管理 SAA-C03 分數最重要的關鍵。

AWS 自有金鑰（AWS-owned keys）

AWS-owned keys 由 AWS 代表所有客戶擁有並管理。您在 AWS KMS 主控台中看不到它們，無法稽核其使用記錄，無法輪換，也無法變更金鑰政策。許多 AWS 服務在未設定其他選項時，以 AWS-owned keys 作為預設加密方式。費用為零。在 SAA-C03 考試中，AWS-owned keys 代表「在不需要明確指定金鑰的情況下涵蓋靜態加密」的基準線。

AWS 受管金鑰（AWS-managed keys）

AWS-managed keys 在特定 AWS 服務首次需要加密資料時，自動建立於您的 AWS 帳戶中。它們會出現在 AWS KMS 主控台，別名以 aws/ 開頭（例如 aws/s3、aws/ebs、aws/rds）。您可以查看並透過 AWS CloudTrail 稽核其使用記錄，但無法修改金鑰政策、無法刪除、也無法停用每年自動輪換。AWS-managed keys 的儲存費用為零，但對其發出的 API 呼叫會計入 AWS KMS 請求定價。

客戶受管金鑰（Customer-managed keys，CMK）

Customer-managed keys 是您在 AWS 帳戶中明確建立的 AWS KMS 金鑰。您可控制：

• AWS KMS 金鑰政策（誰可以管理金鑰、誰可以使用金鑰）。
• IAM 政策整合（AWS IAM 可授權哪些主體）。
• Grants（暫時性的範圍委派）。
• 自動輪換（開啟或關閉；開啟時，AWS KMS 預設每 365 天輪換一次金鑰材料，可設定為 90 至 2560 天）。
• 刪除（需要 7 至 30 天的強制等待期）。
• 多區域複製（用於災難復原與低延遲跨區域工作負載）。

Customer-managed keys 每月每把金鑰收費 1.00 美元，當情境要求稽核可見度、自訂存取控制或明確的金鑰所有權時，應選擇此類型。

對稱 vs 非對稱 AWS KMS 金鑰

上述三種類別中，AWS KMS 金鑰分為兩種形式：

• 對稱 AWS KMS 金鑰使用 AES-256-GCM。同一份金鑰材料負責加密與解密，且金鑰材料永遠不離開 AWS KMS。幾乎所有 AWS 服務的資料加密與金鑰管理情境都使用此類型。
• 非對稱 AWS KMS 金鑰使用 RSA 或 ECC 金鑰對。公鑰可匯出並散布；私鑰留在 AWS KMS 內。用於數位簽章、簽章驗證，以及只有發送方持有公鑰半部的加解密工作流程。

Envelope Encryption — AWS KMS 如何包裹 Data Key

Envelope encryption 是讓 AWS KMS 具備可擴展性的設計模式。若沒有它，AWS KMS 就必須透過自己的硬體加解密每一個位元組的客戶資料；有了它，AWS KMS 只需處理微小的 data key，而大量的資料則在擁有它的 AWS 服務內部進行本地加密。

GenerateDataKey API 呼叫

當 Amazon S3 等 AWS 服務收到指定 SSE-KMS 的 PutObject 請求時，它會對您選擇的 AWS KMS key 呼叫 kms:GenerateDataKey。AWS KMS 在同一個回應中返回兩樣東西：

1. 一把明文 data key（通常是 256 位元的 AES 金鑰）。
2. 以 AWS KMS key 加密的同一把 data key（密文 blob）。

Amazon S3 使用明文 data key 以 AES-256-GCM 加密物件位元組，將密文物件連同加密後的 data key 一起儲存，並立即從記憶體中丟棄明文 data key。之後要讀取物件時，Amazon S3 以 kms:Decrypt 呼叫將加密的 data key 送回 AWS KMS，取得明文 data key，解密物件，並再次丟棄明文 data key。

Envelope encryption 的重要性

• AWS KMS 金鑰材料永遠不離開 AWS KMS。 即便在主動加密期間，也只有微小的 data key 來回傳遞。AWS KMS key 本身在整個生命週期內都留在 AWS KMS 的硬體邊界內。
• 吞吐量可擴展。 AWS KMS 不需要加密 PB 級 Amazon S3 物件的每個位元組，只需處理 data key。這讓 AWS KMS 能以極高的請求速率服務所有 AWS 服務。
• 爆炸半徑受限。 一把被洩露的 data key 只會曝露一個物件。被洩露的 AWS KMS key 理論上會曝露所有曾用它包裹過的 data key——但 AWS KMS key 存放在 AWS KMS 的硬體安全模組中，從不對外提供。

S3 加密選項：SSE-S3、SSE-KMS、SSE-C 與 DSSE-KMS

Amazon S3 提供四種伺服器端加密（SSE）選項，加上客戶端加密。SAA-C03 的題目往往完全取決於您能否選出正確的那一種。

SSE-S3（2023 年起為預設）

SSE-S3 使用 AES-256，金鑰由 Amazon S3 自行擁有、管理並輪換。自 2023 年 1 月起，SSE-S3 是每個新 Amazon S3 物件的預設加密方式——什麼都不做，您的資料就已在靜態加密。您對金鑰沒有可見性，也沒有 AWS CloudTrail 對金鑰使用的稽核記錄。不產生直接的 AWS KMS 費用。當您只需要靜態加密且不需證明金鑰所有權時，使用 SSE-S3。

SSE-KMS

SSE-KMS 使用 AWS KMS key（AWS 受管的 aws/s3 或客戶受管金鑰），透過 envelope encryption 包裹每個物件的 data key。相較於 SSE-S3 的優點：

• 每次加解密呼叫的 AWS CloudTrail 稽核記錄。
• 透過 AWS KMS 金鑰政策控制誰能使用金鑰。
• 客戶受管金鑰選項，提供完整的生命週期控制。
• 透過 AWS KMS 金鑰政策實現跨帳戶與多區域資料共享模式。

取捨：每次 Amazon S3 操作都會產生一個 AWS KMS API 呼叫，計入 AWS KMS 請求定價與請求吞吐量限制。對於高流量的 Amazon S3 工作負載，請啟用 Amazon S3 Bucket Keys，透過快取短暫有效的儲存桶層級中間金鑰，將 AWS KMS 請求量減少約 99%。

SSE-C（客戶提供金鑰）

SSE-C 要求您在每次請求時提供加密金鑰。Amazon S3 使用該金鑰進行加密（PUT 時）或解密（GET 時），之後將其從記憶體中刪除；Amazon S3 絕不儲存 SSE-C 金鑰。金鑰的管理與可用性完全由您負責。若金鑰遺失，物件將永久無法復原。使用情境較少，通常用於法規要求客戶必須在任何 AWS 受管服務之外完整擁有金鑰材料的工作負載。

DSSE-KMS（雙層伺服器端加密，2023 年起）

DSSE-KMS 套用兩層獨立的 AES-256 伺服器端加密，均綁定至您的 AWS KMS key。此功能針對美國聯邦工作負載（含 Committee on National Security Systems，CNSS 資料）及其他需要雙層物件加密的法規情境設計。一般商業工作負載應繼續使用 SSE-KMS。

客戶端加密

客戶端加密在資料抵達 Amazon S3 之前就在您這端加密；Amazon S3 儲存的是已加密的位元組。請使用 AWS Encryption SDK 或 Amazon S3 Encryption Client。金鑰由您管理（通常透過 AWS KMS、AWS CloudHSM 中的 customer key store，或您自己的金鑰庫）。當威脅模型需要不信任 AWS 服務本身時使用——例如法規要求 AWS 在任何情況下都無法讀取資料。

EBS、RDS、EFS 與 DynamoDB 靜態加密

靜態加密不只是 Amazon S3 的議題。每個主要的儲存與資料庫 AWS 服務都以相同的 envelope encryption 模式整合 AWS KMS。

Amazon EBS 加密

Amazon Elastic Block Store 磁碟區可在建立時以 AWS KMS key 加密；加密對掛載的 Amazon EC2 執行個體是透明的。AWS KMS key 包裹一把磁碟區專屬的 data key，用來加密磁碟區的每個區塊及其快照。跨 AWS 區域複製的快照會以您指定的目標區域 AWS KMS key 重新加密。您可以在 AWS 區域層級啟用 Amazon EBS 預設加密，讓該 AWS 區域中每個新磁碟區都自動使用您選擇的 AWS KMS key 加密。

Amazon RDS、Aurora 與 Redshift 加密

Amazon RDS、Amazon Aurora 與 Amazon Redshift 均支援以 AWS KMS 進行靜態加密。SAA-C03 最重要的規則：加密只能在建立時啟用。若要加密現有未加密的 Amazon RDS 資料庫，請建立快照，在複製快照時啟用加密（選擇 AWS KMS key），再將加密快照還原為新的加密 Amazon RDS 執行個體。讀取副本繼承來源的加密設定；加密的來源會產生加密的副本，未加密的 Amazon RDS 資料庫無法擁有加密的讀取副本。

Amazon EFS 與 FSx 加密

Amazon EFS 在檔案系統建立時使用 AWS KMS 進行靜態加密，並透過 mount helper 整合支援傳輸中 TLS 加密。Amazon FSx（Windows File Server、Lustre、NetApp ONTAP、OpenZFS）同樣支援 AWS KMS 靜態加密，並在法規要求時整合客戶受管金鑰。

Amazon DynamoDB 加密

Amazon DynamoDB 資料表永遠啟用靜態加密——沒有停用選項。三種金鑰選擇：AWS 自有（預設，免費）、AWS 受管（aws/dynamodb）或客戶受管。全域資料表將加密設定複製到所有副本 AWS 區域，各區域可獨立選擇 AWS KMS key。

AWS KMS 金鑰政策、IAM 與 Grants — 三層存取控制

AWS KMS 是少數幾個存取控制並非完全委派給 AWS IAM 的 AWS 服務之一。存取 AWS KMS key 由三層重疊的機制把關。

金鑰政策（Key policies）

每把 AWS KMS key 都有一份金鑰政策——一份直接附加在 AWS KMS key 上的 JSON 文件。它是主要存取控制機制：若金鑰政策不允許某個操作，其他任何政策都無法授予它（少數例外除外）。AWS KMS 主控台建立的預設金鑰政策會將管理權委派給 AWS 帳戶 root，並指定同一 AWS 帳戶中的 AWS IAM 政策可授權 AWS KMS 操作——這就是 IAM 政策能向使用者授予 kms:Decrypt 的前提。

IAM 政策

當且僅當金鑰政策委派給 AWS IAM（透過標準的「Enable IAM policies」陳述式），以身分為基礎的 AWS IAM 政策才能向主體授予 AWS KMS 操作。若金鑰政策中沒有該委派條款，AWS IAM 政策對此 AWS KMS key 完全無效——這是鎖定客戶受管金鑰的強力手段，確保只有金鑰政策中明確列出的主體才能使用。

Grants

Grant 是一種暫時性的程式化委派，將 AWS KMS 權限從一個主體授予另一個主體。Grants 通常由 AWS 服務代您發出——例如，當 Amazon EBS 需要讓 Amazon EC2 使用某個特定磁碟區的 AWS KMS key 時，Amazon EBS 會建立一個範圍精確到該磁碟區的 grant。Grants 是金鑰政策與 IAM 政策的附加授權；它們永遠無法覆蓋金鑰政策中的明確拒絕。

跨帳戶使用 AWS KMS 金鑰

若要讓 AWS 帳戶 B 中的主體以帳戶 A 擁有的 AWS KMS key 進行加解密，必須同時設定以下兩項：

1. 帳戶 A 的金鑰政策必須允許帳戶 B 的主體（或帳戶 B 的 root）呼叫所需的 AWS KMS 操作。
2. 帳戶 B 的 AWS IAM 政策必須向該主體授予對帳戶 A AWS KMS key ARN 的相同 AWS KMS 操作。

這個雙政策模型在跨帳戶 Amazon S3 情境中頻繁出現：帳戶 A 的儲存桶以帳戶 A 的客戶受管 AWS KMS key 加密，帳戶 B 的消費者嘗試存取。若 AWS KMS 金鑰政策或帳戶 B 的 AWS IAM 政策任一缺少授權，下載將失敗，並出現 AccessDeniedException，且錯誤訊息指向 AWS KMS 而非 Amazon S3。

AWS KMS 金鑰輪換 — 自動 vs 手動

輪換（Rotation）在保留金鑰身分（金鑰 ID 與 ARN）不變的情況下，替換底層的金鑰材料。這是 SAA-C03 測試頻率最高的單一知識點之一。

自動輪換

對於客戶受管的對稱 AWS KMS 金鑰，您可以啟用自動金鑰輪換。AWS KMS 預設每 365 天輪換一次底層加密材料（自 2024 年起可設定為 90 至 2560 天）。重要細節：

• AWS KMS 金鑰的金鑰 ID 與 ARN 不會改變——您的應用程式繼續引用相同的 ARN。
• 舊的金鑰材料會被保留，使先前加密的資料仍可解密。
• 輪換是透明的——不需要重新加密現有資料。
• AWS 受管金鑰每年自動輪換，您無法關閉（也無法修改輪換週期）。
• 自動輪換僅適用於使用 AWS 自有金鑰材料的對稱 AWS KMS 金鑰。 非對稱金鑰與使用匯入金鑰材料的金鑰無法自動輪換。

手動輪換

對於非對稱 AWS KMS 金鑰及使用匯入金鑰材料的 AWS KMS 金鑰，輪換必須手動進行。模式如下：

1. 建立一把含有新材料的 AWS KMS 金鑰。
2. 更新別名（alias）指向新的 AWS KMS 金鑰。
3. 若希望新材料保護現有密文，則對其重新加密。

引用別名（alias/my-app-key）而非底層金鑰 ID 的應用程式，無需變更程式碼即可繼續運作。

使用匯入金鑰材料的 AWS KMS 金鑰

您可以將自己的金鑰材料匯入 AWS KMS 金鑰（Bring Your Own Key，BYOK）。匯入材料的金鑰讓您可以在 AWS 之外保留一份金鑰主本，並在需要時從 AWS KMS 刪除金鑰材料。此類金鑰無法使用自動輪換，定價上視同客戶受管金鑰。

AWS CloudHSM vs AWS KMS — 專用 HSM vs 受管金鑰服務

AWS CloudHSM 與 AWS KMS 都以硬體安全模組支撐其加密操作，但所有權與法遵模型大相逕庭。

AWS CloudHSM 是什麼

AWS CloudHSM 在您的 Amazon VPC 內部佈建一個或多個單租戶硬體安全模組。您是這些 HSM 設備的唯一擁有者——AWS 負責實體硬體的運作，但無法查看金鑰材料、使用者或在上面執行的加密操作。AWS CloudHSM 通過 FIPS 140-2 Level 3 認證（HSM 硬體具備防竄改跡象偵測與防竄改回應能力），且操作員（您）是唯一的信任根。

工作負載為何選擇 AWS CloudHSM 而非 AWS KMS

• 單租戶硬體要求。 某些法規（例如部分美國國防部工作負載、PCI PIN 交易處理，以及特定歐盟金融法規）要求金鑰材料必須存放於專屬於單一客戶的 HSM。
• 整個操作堆疊均符合 FIPS 140-2 Level 3。 AWS KMS 通過 FIPS 140-2 驗證，但其多租戶架構與 CloudHSM 的單租戶 HSM 有所不同。
• 直接整合 PKCS #11、JCE 或 Microsoft CNG。 地端應用程式與第三方軟體往往需要 AWS KMS 不提供的標準 HSM API。
• AWS KMS 未提供的加密操作。 例如在專用 HSM 上的 SSL/TLS 卸載、舊式 3DES，或自訂橢圓曲線。
• 作為 AWS KMS 的 custom key store。 您可以將 AWS CloudHSM 叢集連結為 AWS KMS 的 custom key store，使存放於其上的 AWS KMS 金鑰位於您的 CloudHSM HSM，同時仍透過 AWS KMS API 整合 AWS 服務。

為何大多數工作負載選擇 AWS KMS

• 全受管。 AWS KMS 負責可用性、擴展、輪換與修補。
• 與所有主要 AWS 服務整合。 Amazon S3、Amazon EBS、Amazon RDS、Amazon DynamoDB、AWS Lambda 及數十項其他服務開箱即用。
• 更便宜。 每把客戶受管金鑰每月 1.00 美元，相較於 CloudHSM 叢集每個 HSM 約每小時 1.45 美元，且高可用性至少需要兩個 HSM。
• FIPS 合規程度對大多數企業與法規工作負載已足夠。

CloudHSM 高可用性與最小叢集規模

AWS CloudHSM 叢集是高可用性的單位。一個只有一個 HSM 的叢集是允許的，但不提供備援；AWS 建議至少將兩個 HSM 分散在至少兩個可用區域以用於正式環境。CloudHSM 自動在叢集中的所有 HSM 之間同步金鑰材料；若某個 HSM 故障，其餘 HSM 繼續提供服務。

AWS Certificate Manager（ACM）— 公開 vs 私有 CA、自動更新與服務整合

AWS Certificate Manager（ACM） 是 AWS 資料加密與金鑰管理服務中負責簽發、部署與更新 TLS/SSL 憑證的服務，用於加密傳輸中的資料。在 SAA-C03 中，ACM 題目集中於三個主題：公開 vs 私有 CA、自動更新，以及哪些 AWS 服務可直接使用 ACM 憑證。

公開 ACM 憑證

公開 ACM 憑證由 Amazon 的公開憑證授權機構（Amazon Trust Services）簽署，受所有主流瀏覽器、作業系統與 HTTP 客戶端信任。公開 ACM 憑證在搭配支援的 AWS 服務使用時免費。網域驗證可透過 DNS（Amazon Route 53 或其他 DNS 提供商的 CNAME 記錄，搭配 Route 53 整合只需一鍵）或電子郵件完成。驗證後，ACM 簽發憑證，並在到期前 60 天開始自動更新——只要驗證記錄持續存在，您永遠不需要手動處理更新。

私有 ACM 憑證（AWS Private CA）

AWS Private CA（前身為 ACM Private CA）佈建一個由您完全控制的私有憑證授權機構階層。私有 ACM 憑證只受信任您私有根的客戶端認可——通常是內部微服務、容器網格流量與 VPN 客戶端。AWS Private CA 是一項付費 AWS 服務（每月 CA 費用 + 每張憑證簽發費）。用於零信任微服務間 TLS、IoT 裝置群組，以及公開憑證會浪費資源或洩露內部名稱至公開日誌的 Kubernetes 網格部署。

ACM 憑證可部署至哪些服務

ACM 簽發的公開憑證可自動部署至以下特定 AWS 服務：

• Elastic Load Balancing（Application Load Balancer、具 TLS 接聽器的 Network Load Balancer、Classic Load Balancer）。
• Amazon CloudFront 分發。
• Amazon API Gateway 自訂網域名稱。
• AWS App Runner 自訂網域。
• AWS Elastic Beanstalk（透過底層負載平衡器）。
• AWS Nitro Enclaves（透過 ACM-Nitro 整合）。

值得注意的是，ACM 公開憑證無法匯出。私鑰永遠不離開 ACM。對於需要直接在主機上使用憑證的 Amazon EC2 執行個體，您必須使用 AWS Private CA（可匯出）、第三方憑證，或更常見的作法是在 Amazon EC2 執行個體前放置一個 ALB，由 ALB 持有 ACM 憑證。

ACM 在 CloudFront vs 區域 AWS 服務中的差異

搭配 Amazon CloudFront 使用的 ACM 憑證，無論來源位於何處，都必須在 us-east-1（北維吉尼亞） AWS 區域簽發，因為 Amazon CloudFront 是錨定於該區域的全球 AWS 服務。區域 AWS 服務（ALB、API Gateway）的憑證必須與服務位於相同的 AWS 區域。

傳輸中加密：TLS、VPC Endpoints 與 AWS 服務模式

傳輸中加密保護資料在客戶端與 AWS 服務之間，或兩個 AWS 服務之間移動時的安全。「如何啟用傳輸中加密？」的答案幾乎都是「終止 TLS」——但各 AWS 服務的實作方式有所不同。

以 ACM 實現面向公開的 TLS

對於 Application Load Balancer、Amazon CloudFront 分發或 Amazon API Gateway 上的 HTTPS，請附加 ACM 憑證。ALB/CloudFront/API Gateway 終止 TLS 後，依設定決定是否重新加密至後端。Amazon CloudFront 支援純 HTTPS 檢視器政策、TLS 1.2 與 1.3 最低版本，甚至可以以獨立憑證重新加密至來源——實現端對端 TLS。

VPC Endpoints 與 AWS PrivateLink

當 Amazon VPC 資源呼叫 AWS 服務時，每個現代 AWS 服務 API 的傳輸預設均以 TLS 加密。但當呼叫透過 Internet Gateway 或 NAT Gateway 離開 Amazon VPC 時，流量仍會經過 AWS 公開網路邊界。AWS PrivateLink（Interface VPC endpoints） 讓流量留在 AWS 私有網路上：

• 流量永遠不離開 Amazon VPC。
• TLS 仍在 AWS 內部終止，而非在公開網際網路上。
• 不需要 Internet Gateway、NAT Gateway 或 Direct Connect 公開 VIF。
• 許多法規要求的 AWS 架構，明確要求使用 VPC endpoints 以確保流量路徑保持私有。

Gateway VPC endpoints（用於 Amazon S3 和 Amazon DynamoDB）提供類似的私有路徑，且不產生 interface endpoint 費用，但它們在路由層運作而非透過 PrivateLink。

AWS KMS VPC Endpoints

AWS KMS 本身支援 Interface VPC endpoint。啟用後，對於必須證明所有 AWS KMS 流量不經過公開網際網路（即便在 AWS 內部）的架構，這是法遵方面的加分項。搭配 endpoint policy 限制哪些主體與 AWS KMS 金鑰可透過該 endpoint 呼叫。

儲存與資料庫的傳輸中加密

• Amazon S3 支援所有客戶端請求使用 TLS 1.2+；您可以使用儲存桶政策拒絕 aws:SecureTransport = false 以強制 HTTPS。
• Amazon RDS / Aurora 支援以 Amazon RDS 簽發的憑證進行 TLS；透過 rds.force_ssl = 1（PostgreSQL）或在資料庫參數群組中要求 SSL（MySQL）強制執行。
• Amazon EFS 透過 EFS mount helper 使用 -o tls 掛載選項支援傳輸中 TLS 加密。
• Amazon Redshift 支援 JDBC/ODBC 連線的 TLS；透過叢集參數群組強制執行。
• Amazon DynamoDB 每次 API 呼叫均要求 HTTPS——沒有辦法停用 TLS。

關鍵數字與必記事實

請熟記此清單。它涵蓋 SAA-C03 中 AWS 資料加密與金鑰管理的大多數數字與分類陷阱。

常見考試陷阱 — AWS 資料加密與金鑰管理

每次 SAA-C03 考試預計至少遇到其中兩項。請在閱讀選項前就先掌握模式。

陷阱一：SSE-KMS vs SSE-S3 的客戶控制權

情境要求「客戶能稽核每次存取且在金鑰遭洩露時能停用」。SSE-S3 無法滿足此需求，因為 Amazon S3 對您隱藏金鑰。正確答案是搭配客戶受管 AWS KMS key 的 SSE-KMS，其使用記錄記錄於 AWS CloudTrail，且存取由您控制的 AWS KMS 金鑰政策把關。

陷阱二：CMK 與 data key 混淆

描述「以 AWS KMS key 直接加密一個 100 MB 的 Amazon S3 物件」的選項是干擾項。AWS KMS 金鑰不直接在此規模加密資料——它加密的是 data key，再由 data key 加密實際內容。記住 envelope encryption：AWS KMS key → data key → 客戶資料。

陷阱三：AWS KMS 輪換限制

自動輪換只適用於使用 AWS 自有材料的客戶受管對稱 AWS KMS 金鑰。非對稱 AWS KMS 金鑰與使用匯入金鑰材料的金鑰需要手動輪換。情境提到「匯入的 BYOK」或「非對稱金鑰」並結合「啟用自動輪換」，即指向錯誤答案。

陷阱四：AWS KMS 金鑰政策必須委派給 IAM

授予 kms:Decrypt 的 AWS IAM 政策若 AWS KMS key 的金鑰政策中不含「Enable IAM policies」陳述式，則毫無作用。情境呈現「儘管已有 IAM 權限，呼叫仍神秘失敗」，通常關鍵就在金鑰政策中缺少該委派陳述式。

陷阱五：CloudHSM 幾乎總是錯的

AWS CloudHSM 只有在題目明確說明單租戶 HSM、HSM 擁有者需符合 FIPS 140-2 Level 3 或需要 PKCS #11 / Microsoft CNG 整合時才是正確答案。否則 AWS KMS 更便宜、更簡單，且與 AWS 服務整合更完善。「公司需要以受管金鑰服務加密靜態資料」→ AWS KMS，非 AWS CloudHSM。

陷阱六：ACM 憑證無法匯出

「下載 ACM 憑證並安裝到 Amazon EC2 執行個體」是錯誤答案。ACM 公開憑證從不暴露私鑰。若需要 Amazon EC2 直接終止 TLS，請使用 AWS Private CA（可匯出）、安裝第三方憑證，或在 Amazon EC2 執行個體前放置一個 ALB 並在 ALB 上使用 ACM。

陷阱七：跨帳戶 AWS KMS 需要兩個政策

帳戶 B 若要解密帳戶 A 中使用帳戶 A AWS KMS key 加密的物件，帳戶 A 的 AWS KMS 金鑰政策與帳戶 B 的 AWS IAM 政策都必須允許該操作。單方面的授權無效。

陷阱八：Amazon RDS 加密無法就地切換

任何「修改 Amazon RDS 執行個體以啟用靜態加密」的選項都是錯誤的。快照 → 啟用加密複製 → 還原是唯一路徑。相同的陷阱也適用於 Amazon EBS 磁碟區與 Amazon Redshift 叢集。

加密 vs 存取控制 — 互補而非互換

在 SAA-C03 中，考生有時將加密與存取控制視為可替換的方案，但它們並非如此。

存取控制（AWS IAM、儲存桶政策、安全群組、NACL、AWS KMS 金鑰政策）決定誰能呼叫 API。加密（AWS KMS、SSE-*、TLS、AWS CloudHSM）保護的是資料位元組本身，即便 API 邊界被繞過也有效——例如，磁碟遭竊、AWS 操作員遭入侵，或網路竊聽者。

縱深防禦架構同時使用兩者：

• AWS IAM 與儲存桶政策限制 s3:GetObject 僅限授權主體存取。
• 搭配客戶受管 AWS KMS key 的 SSE-KMS，確保即使主體以某種方式繞過 Amazon S3，若未同時獲得 AWS KMS 金鑰政策授權，也無法讀取原始物件位元組。
• 傳輸中 TLS 確保網路攻擊者即便攔截到位元組，也無法讀取線路上的內容。

許多 SAA-C03 題目會因為您能認識到架構需要加密加上存取控制，而非取代它，而給予額分。

練習題連結 — Task 1.3 對應情境

• 「哪種 AWS KMS 金鑰類型讓客戶能稽核每次使用記錄並在遭洩露時停用？」→ 客戶受管 AWS KMS key（透過 AWS CloudTrail 稽核，完整生命週期控制）。
• 「法規要求 FIPS 140-2 Level 3 的單租戶 HSM 及 PKCS #11 存取。」→ AWS CloudHSM，在 2 個 AZ 中至少各 1 個，共 2 個 HSM。
• 「Amazon S3 儲存桶需加密，且只有特定 AWS IAM 角色能解密物件，且每次存取均須記錄。」→ 搭配客戶受管 AWS KMS key 的 SSE-KMS，金鑰政策指定 IAM 角色，並啟用 CloudTrail。
• 「公司需要每年輪換 AWS KMS 金鑰的底層材料，且應用程式不需任何變更。」→ 在客戶受管對稱 AWS KMS 金鑰上啟用自動輪換。
• 「Application Load Balancer 需以自動更新且免費的憑證終止 HTTPS。」→ ACM 公開憑證搭配 DNS 驗證。
• 「Amazon VPC 內的微服務網格需要 Pod 對 Pod 的私有 TLS 憑證。」→ AWS Private CA + ACM 簽發的私有憑證。
• 「現有未加密的 Amazon RDS 資料庫需要靜態加密。」→ 建立快照 → 啟用加密複製快照 → 還原 → 切換流量。
• 「私有子網路中的 Amazon EC2 執行個體需呼叫 AWS KMS，且不經過公開網際網路。」→ AWS KMS Interface VPC endpoint 加上限制性 endpoint policy。
• 「Amazon S3 儲存桶必須拒絕所有非 HTTPS 的請求。」→ 儲存桶政策拒絕 aws:SecureTransport = false。
• 「客戶要求對法規要求的 Amazon S3 工作負載進行雙層伺服器端加密。」→ DSSE-KMS。

FAQ — AWS 資料加密與金鑰管理常見問題

Q1：AWS KMS 與 AWS CloudHSM 的差異是什麼？

AWS KMS 是多租戶、全受管的 AWS 金鑰管理服務，整合所有主要 AWS 服務，每把客戶受管金鑰每月費用 1.00 美元。AWS CloudHSM 在您的 Amazon VPC 內佈建單租戶 FIPS 140-2 Level 3 硬體安全模組，讓您對 HSM 設備與金鑰材料擁有唯一所有權，費用較高（每個 HSM 約每小時 1.45 美元，且高可用性需至少 2 個 HSM）。除非情境明確要求單租戶硬體、FIPS 140-2 Level 3 擁有權，或 PKCS #11 / Microsoft CNG 整合，否則預設選 AWS KMS。

Q2：什麼是 envelope encryption，AWS KMS 為何使用它？

Envelope encryption 是以短暫的 data key 加密客戶資料，再以長期存在的 AWS KMS key 加密 data key 的模式。AWS KMS key 永遠不離開 AWS KMS 硬體；只有微小的 data key 來回傳遞。這代表 AWS KMS 不必處理每個位元組的客戶資料，從而維持高吞吐量；同時，被洩露的 data key 只曝露一份資料，而非主金鑰。幾乎每個與 AWS KMS 整合的 AWS 服務（Amazon S3、Amazon EBS、Amazon RDS、Amazon DynamoDB 等）在底層都使用 envelope encryption。

Q3：Amazon S3 中何時應選擇 SSE-KMS 而非 SSE-S3？

當您需要以下任一項時，選擇 SSE-KMS：客戶對金鑰生命週期的控制（輪換、停用、刪除）、每次加解密呼叫的 AWS CloudTrail 稽核記錄、透過 AWS KMS 金鑰政策實現跨帳戶資料共享模式，或要求明確客戶金鑰所有權的法遵認證。當您只需要靜態加密且不希望產生 AWS KMS 請求費用時，選擇 SSE-S3。對於高吞吐量的 SSE-KMS 工作負載，請啟用 Amazon S3 Bucket Keys，在不失去稽核記錄的情況下將 AWS KMS 請求量減少約 99%。

Q4：AWS KMS 自動輪換如何運作，限制是什麼？

自動輪換適用於使用 AWS 自有金鑰材料的客戶受管對稱 AWS KMS 金鑰。啟用後，AWS KMS 預設每 365 天產生新的底層加密材料（可設定為 90 至 2560 天）。AWS KMS 金鑰的 ID 與 ARN 不會改變，且舊的金鑰材料保留以供先前加密的資料仍可解密。非對稱 AWS KMS 金鑰與使用匯入（BYOK）材料的金鑰必須透過建立新 AWS KMS 金鑰並更新別名的方式手動輪換。AWS 受管金鑰每年自動輪換，且無法停用或修改輪換設定。

Q5：如何加密現有未加密的 Amazon RDS 資料庫或 Amazon EBS 磁碟區？

您無法就地切換現有 Amazon RDS 資料庫或 Amazon EBS 磁碟區的加密狀態。標準工作流程為：對現有未加密資源建立快照，複製快照時指定 AWS KMS key 並啟用加密，將加密快照還原為新資源，將應用程式流量切換到新的加密資源，最後淘汰舊的未加密原始資源。相同的模式適用於 Amazon Redshift 叢集。請在 AWS 區域層級啟用 Amazon EBS 預設加密，確保該 AWS 區域中每個新磁碟區都自動加密，從此不再出現未加密的新資源。

Q6：AWS Certificate Manager 如何處理憑證更新？

ACM 簽發的公開憑證，在部署至支援的 AWS 服務（Application Load Balancer、Network Load Balancer、Amazon CloudFront、Amazon API Gateway、AWS App Runner 等）時免費。自動更新在到期前 60 天開始，只要 DNS 驗證 CNAME 記錄（或電子郵件驗證）仍可存取，ACM 就會透明地輪換憑證——無需任何應用程式程式碼變更，無需手動上傳。更新後的憑證保持相同的 ARN，下游設定無需任何調整。對於 Amazon CloudFront，請記得 ACM 憑證必須在 us-east-1 簽發，無論來源位於何處。

Q7：為何授予 kms:Decrypt 的 AWS IAM 政策有時仍然失敗？

AWS KMS 是少數幾個單靠 AWS IAM 政策不足以授權的 AWS 服務之一。AWS KMS 金鑰政策是直接附加在金鑰上的主要授權文件。除非金鑰政策包含標準的「Enable IAM policies」陳述式（將授權權力委派給同一 AWS 帳戶的 AWS IAM），否則 AWS IAM 政策對該 AWS KMS key 沒有任何效力。對於跨帳戶使用，擁有帳戶的 AWS KMS 金鑰政策與呼叫帳戶的 AWS IAM 政策必須同時授予所需的 AWS KMS 操作，且呼叫方必須以完整 ARN 引用 AWS KMS 金鑰。

延伸閱讀

• AWS Key Management Service Developer Guide
• AWS KMS Envelope Encryption
• AWS KMS Key Policies
• AWS KMS Rotating Keys
• AWS KMS Grants
• AWS CloudHSM User Guide
• AWS Certificate Manager User Guide
• Amazon S3 Server-Side Encryption
• Amazon S3 DSSE-KMS Dual-Layer Encryption
• Amazon EBS Encryption
• AWS PrivateLink and VPC Endpoints
• AWS SAA-C03 Exam Guide（PDF）