網路加密 — TLS、ACM、IPsec 與 MACsec

為什麼網路加密對 ANS-C01 至關重要

傳輸中加密 (Encryption in transit) 是 AWS 機密性的基礎。ANS-C01 考試的網域 4 任務 4.3 — 「實作與維護網路資料與通訊的機密性」 — 測試了 AWS 提供的每一種加密機制：邊緣的 TLS、VPN 的 IPsec、Direct Connect 的 MACsec、DNS 解析的 DNSSEC、公有憑證的 ACM 以及內部憑證的 ACM Private CA。大約 8% 到 12% 的 ANS-C01 題目涉及其中至少一種機制，且每次考試都有幾題結合了多個加密層 (例如：ALB 的 mTLS 端到端加密加上 Direct Connect 上的 MACsec)。

本學習指南深度探討 AWS 上的網路加密。我們涵蓋了 TLS 交握與協定版本、ACM 發行的公有憑證與 ACM Private CA 發行的私有憑證、將憑證部署到 ALB / NLB / CloudFront / API Gateway、TLS 終止 (Termination) 與 TLS 透傳 (Passthrough) 的區別、AWS Site-to-Site VPN 的 IPsec 參數、Direct Connect 專用連線上的 MACsec 配置 (CAK/CKN, AES-256-GCM)、Route 53 上的 DNSSEC 區域簽署、憑證輪換策略、相互 TLS (mTLS) 以及端到端加密架構。

閱讀完本指南後，你應能設計考試要求的任何傳輸中加密架構。最後我們以 FAQ、情境分析和中文陷阱提醒作結。

TLS 基礎：交握、密碼套件與版本

TLS (傳輸層安全性) 是在 TCP 之上保護 HTTP、AMQP、MQTT 和許多其他應用程式協定的密碼協定。AWS 跨服務支援 TLS 1.0、1.1、1.2 和 1.3，但對於合規性工作負載 (HIPAA, PCI DSS, FedRAMP)，僅 TLS 1.2 和 TLS 1.3 是可接受的。

TLS 交握 (高階概觀)

TLS 交握涉及以下步驟 (以 TLS 1.2 為例)：

1. ClientHello：用戶端發送支援的密碼套件、TLS 版本和伺服器名稱指示 (SNI)。
2. ServerHello：伺服器選擇密碼套件與 TLS 版本，發送伺服器憑證。
3. 憑證驗證：用戶端針對受信任的 CA 鏈驗證伺服器憑證。
4. 金鑰交換：用戶端與伺服器協議工作階段金鑰 (RSA, ECDHE 或 DHE)。
5. Finished：雙方確認交握的 HMAC；加密的應用程式資料開始傳輸。

TLS 1.3 將此簡化為單次往返，並移除了舊有的密碼套件 (RSA 金鑰交換, RC4, SHA-1, MD5)。TLS 1.3 顯著更快且更安全。

伺服器名稱指示 (SNI)

SNI 是 ClientHello 中的 TLS 擴充功能，指出用戶端嘗試存取的主機名稱。SNI 讓單個 TLS 端點能為同一個 IP 上的不同主機名稱提供多個憑證。CloudFront、ALB 和 API Gateway 都支援 SNI 以實現多租戶 TLS。

一個細微且與考試相關的細節：SNI 在 ClientHello 期間以純文字發送，發生在 TLS 加密開始之前。這就是為什麼 AWS Network Firewall 和 Route 53 Resolver DNS Firewall 即使沒有 TLS 檢測也能讀取 SNI 進行過濾。

AWS 上的安全性策略 (Security Policies)

CloudFront 和 ALB 使用具名的「安全性策略」，將 TLS 協定版本與允許的密碼套件清單捆綁在一起。常見策略：

• ELBSecurityPolicy-TLS13-1-2-2021-06：TLS 1.2 + 1.3，現代密碼。
• ELBSecurityPolicy-FS-1-2-Res-2020-10：TLS 1.2，僅限具備轉發安全性 (Forward-secrecy) 的密碼。
• TLSv1.2_2021 (CloudFront)：最低 TLS 1.2，僅限 FS。

對於 ANS-C01 的合規性答案，優先選擇強制要求 TLS 1.2 或 1.3 並具備轉發安全性的策略。允許 TLS 1.0/1.1 的舊策略是不合規的。

AWS Certificate Manager (ACM)

ACM 是受管憑證服務，為 AWS 服務發行、部署及輪換公有 TLS 憑證。由 ACM 發行的公有憑證是免費的，透過 DNS 或電子郵件驗證，在到期前 60 天自動續期，並與 ALB、NLB、CloudFront、API Gateway 等服務整合。

DNS 驗證 vs 電子郵件驗證

DNS 驗證是現代的最佳實務 — ACM 在你的 DNS 提供商處建立 CNAME 記錄，該記錄證明你擁有該網域，只要 CNAME 保留，續期就會自動發生。電子郵件驗證每次都需要手動確認，且如果網域所有者的電子郵件更改則會失效。對於 Route 53 託管區域，ACM 提供一鍵式「在 Route 53 中建立記錄」按鈕，自動建立驗證 CNAME。

CloudFront 的 ACM 區域限制

無論你的源頭位於何處，附加到 CloudFront 分發的 ACM 憑證必須在 us-east-1 (維吉尼亞北部) 請求。這是因為 CloudFront 是一個全域服務，使用 us-east-1 作為其控制平面。任何其他區域的憑證都不會出現在 CloudFront 主控台中。

對於所有其他 AWS 服務 (ALB, NLB, API Gateway, App Runner)，ACM 憑證必須與資源位於同一區域。不支援跨區域使用憑證。

ACM 自動續期

只要驗證方法 (DNS CNAME 或電子郵件) 仍然有效，ACM 發行的公有憑證會在到期前 60 天自動續期。ACM 會在 60 天窗口內多次嘗試續期，並在成功或失敗時發送 CloudWatch 事件。針對 ACM Certificate Approaching Expiration 的 EventBridge 規則可觸發告警。

如果 DNS 驗證失敗 (例如驗證 CNAME 被刪除)，ACM 無法續期。憑證最終會過期，HTTPS 將會失效。務必對憑證過期指標設定警示。

ACM 匯入的憑證

你可以將第三方憑證 (來自 DigiCert, GoDaddy, Let's Encrypt) 匯入 ACM 並部署到 AWS 服務。匯入的憑證不會自動續期 — 你必須在到期前手動重新匯入新憑證。ACM 會發送匯入憑證過期的 CloudWatch 指標，以便你設定警示。

ACM Private CA (私有憑證授權單位)

ACM Private CA 是一項受管憑證授權單位服務，用於發行私有 (內部) 憑證。使用案例：需要 TLS 但不應受公共網際網路信任的內部微服務、帶有 X.509 身分憑證的 IoT 設備群、針對 B2B 合作夥伴的 ALB mTLS、內部公司網路。

根 CA 與次級 CA

ACM Private CA 支援階層結構：根 CA 發行次級 CA，次級 CA 發行最終實體憑證。根 CA 通常處於離線狀態 (僅用於簽署次級 CA)，而次級 CA 則在線並發行工作憑證。這是標準的 PKI 階層，也是合規稽核員所期望的。

定價：每個 CA 在活動期間每月費用為 400 美元。最終實體憑證的發行費用隨交易量增加而減少。ACM Private CA 比公有 ACM (免費) 昂貴得多 — 僅在確實需要私有憑證時才使用 Private CA。

短期憑證模式

ACM Private CA 支援短期憑證 (例如 24 小時 TTL)。搭配基於 Lambda 的續期自動化，每日發行新憑證並透過 Systems Manager Parameter Store 推送到工作負載。這是高保證環境中降低長期憑證安全風險的模式。

與 ACM 整合

你可以發行由私有 CA 支援的 ACM 憑證。該憑證會出現在 ACM 中，具有相同的生命週期功能 (自動續期、部署到 ALB/CloudFront 等)，但由你的私有 CA 而非 Amazon 的公有 CA 簽署。這是將私有憑證部署到 AWS 服務最乾淨的方式。

TLS 終止 vs TLS 透傳

一個關鍵的架構選擇：TLS 在哪裡終止？AWS 在不同服務中支援終止與透傳：

• ALB 的 TLS 終止：ALB 解密 TLS，執行第 7 層檢測 (主機/路徑路由、WAF)，然後重新加密到後端 (或透過 HTTP 發送純文字)。最常見的模式。
• NLB 的 TLS 透傳：NLB 不解密 TLS。加密的 TCP 串流透傳到後端，由後端自行終止 TLS。當後端需要查看原始 TLS 交握時 (不含 ALB 參與的 mTLS、自訂 TLS 擴充功能) 需要此模式。
• NLB 的 TLS 終止：如果你配置了帶有 ACM 憑證的 TLS 接聽受器，NLB 可以終止 TLS。用於不需要 ALB L7 功能的 HTTP/2 或其他基於 TCP 的 TLS 流量。
• CloudFront 的 TLS 終止：CloudFront 在邊緣終止 TLS，然後重新加密到源頭。CloudFront 到源頭的連線使用單獨的憑證 (源頭的憑證)。

端到端加密設計

對於從用戶端到後端的端到端加密，你可以使用：

• CloudFront → ALB → 後端：TLS 在 CloudFront 終止 (使用檢視器憑證)，重新加密到 ALB (使用源頭憑證)，在 ALB 終止，重新加密到後端 EC2/ECS (使用目標憑證)。三次 TLS 跳轉。
• CloudFront → NLB → 後端 (透傳)：TLS 在 CloudFront 終止，重新加密到 NLB (源頭憑證)，透傳到後端，在後端終止。當後端需要原始標頭時很有用。
• 帶有 mTLS 的 CloudFront → ALB → 後端：與第一種模式相同，但由 ALB 驗證用戶端憑證。

對於「後端必須看到原始用戶端憑證」的要求，答案是 NLB TLS 透傳。ALB mTLS 在 ALB 驗證用戶端，並在 X-Amzn-Mtls-Clientcert 標頭中轉發身分，但後端看不到實際的 TLS 交握。

用於 AWS Site-to-Site VPN 的 IPsec

AWS Site-to-Site VPN 使用 IPsec 加密內部部署客戶閘道與 AWS 虛擬私有閘道 (VGW) 或 Transit Gateway (TGW) 之間的流量。每個 VPN 連線有兩條隧道以實現冗餘，每條隧道終止於不同的 AWS 端 IP。

IPsec 參數

AWS Site-to-Site VPN 支援 IKEv1 和 IKEv2 進行隧道協商。預設的第 1 階段 (IKE) 和第 2 階段 (IPsec) 參數：

• IKE 加密：AES-128, AES-256
• IKE 哈希：SHA-1, SHA-256
• IKE Diffie-Hellman：群組 2, 14, 22, 23, 24
• IPsec 加密：AES-128, AES-256
• IPsec 哈希：SHA-1, SHA-256
• IPsec PFS 群組：2, 5, 14-24
• 隧道模式：隧道 (非傳輸)
• 身分驗證：PSK (預設) 或憑證 (自 2018 年起)

對於 ANS-C01，請記住 AWS 支援 IKEv2 + AES-256 + SHA-256 + DH 群組 14+ 作為現代合規基準。預設隧道使用 PSK 驗證；基於憑證的驗證則使用 ACM Private CA。

無回應對等端偵測 (DPD)

DPD 是偵測隧道故障的 IPsec 機制。AWS 使用 DPD 及預設逾時來決定何時將隧道標記為 down 並切換流量。DPD 間隔可按隧道配置，較短的間隔可實現更快的故障轉移，但會增加 Keepalive 開銷。

加速 VPN (Accelerated VPN)

加速 VPN 在 IPsec 隧道終止於 VGW/TGW 之前，透過 AWS Global Accelerator 的任播網路路由流量。這透過在最近的 Global Accelerator 邊緣進入 AWS 骨幹網路，減少了地理位置遙遠站點的延遲。加速 VPN 需要 TGW (而非 VGW) 和動態路由 (BGP)。

Direct Connect 上的 MACsec

MACsec (媒體存取控制安全性, IEEE 802.1AE) 是第 2 層加密，保護內部部署路由器與 AWS Direct Connect 路由器之間的流量。它使用 AES-256-GCM 並經過硬體加速，提供線速加密且延遲開銷低於亞毫秒。

何時需要 MACsec

當合規性要求對內部部署與 AWS 之間的物理連結進行加密時 (例如政府、金融服務和國防工作負載)，MACsec 就是答案。透過公有 VIF 的 Direct Connect 之上的 IPsec 在第 3 層提供相同的機密性，但 MACsec 位於第 2 層，可防範對租用線路本身的物理竊聽攻擊。

MACsec 硬體需求

Direct Connect 上的 MACsec 具有嚴格的前提條件：

• 專用 Direct Connect 連線：10 Gbps 或 100 Gbps。託管連線或 1 Gbps 及以下的連線不支持 MACsec。
• 用戶端具備 MACsec 能力的路由器：支援帶有 AES-256-GCM 的 IEEE 802.1AE。
• AWS 端具備 MACsec 能力的連接埠：訂購連線時選擇具備 MACsec 能力 (並非所有地點都支援)。

CAK 與 CKN：MACsec 金鑰

MACsec 使用連線關聯金鑰 (CAK) 和連線關聯金鑰名稱 (CKN) 進行相互驗證和金鑰衍生。CAK 是祕密金鑰 (32 位元組十六進位)；CKN 是金鑰識別碼 (16 位元組十六進位名稱)。

你需在帶外產生 CAK 和 CKN，在兩端配置相同的值，AWS Direct Connect 會使用它們建立 MACsec 工作階段。輪換金鑰需要兩端協調重新配置 — 維護時段是必須的。

對於更高安全性的部署，使用 AWS KMS 產生 CAK，以便由 AWS 受管金鑰支援 MACsec 關聯。這在運作上更複雜但具備稽核性。

用於 Route 53 的 DNSSEC

DNSSEC (網域名稱系統安全性擴充功能) 透過使用密碼金鑰簽署區域資料，保護 DNS 響應免受欺騙和快取中毒。Route 53 支援公有託管區域的 DNSSEC。

Route 53 DNSSEC 如何運作

當你在 Route 53 公有託管區域啟用 DNSSEC 時，Route 53 會：

1. 使用 AWS KMS 非對稱金鑰 (ECC_NIST_P256, SIGN_VERIFY 用途) 產生金鑰簽署金鑰 (KSK)。
2. 在內部產生區域簽署金鑰 (ZSK)。
3. 使用 ZSK 簽署所有區域記錄。
4. 使用 KSK 簽署 ZSK (建立 DNSKEY 記錄集簽章)。
5. 在父區域 (通常是註冊商) 發佈委派簽署者 (DS) 記錄。

支援 DNSSEC 驗證的 DNS 解析程式會從根區域向下追蹤 DS 鏈，驗證每個簽章。如果任何簽章驗證失敗，解析程式會返回 SERVFAIL，保護用戶端免受欺騙響應的影響。

DS 記錄發佈

對於在 Route 53 Domains 註冊的網域，DS 記錄會在註冊商處自動發佈。對於外部註冊的網域，你必須手動在註冊商處發佈 DS 記錄。不發佈 DS 記錄意味著 DNSSEC 驗證永遠不會開始 — 區域雖然已簽署但解析程式不會驗證。

私有託管區域中的 DNSSEC

Route 53 私有託管區域不支持 DNSSEC。私有託管區域本質上是受信任的 (僅在你控制的 VPC 內解析)，DNSSEC 是不必要的。考試可能會測試這一區別。

ALB 上的相互 TLS (mTLS)

ALB 自 2023 年起支援 mTLS。除了標準的伺服器對用戶端 TLS 驗證外，mTLS 還使用 X.509 用戶端憑證對用戶端向 ALB 進行身分驗證。

ALB 上的 mTLS 模式

ALB 提供兩種 mTLS 模式：

• 透傳模式 (Passthrough mode)：ALB 驗證用戶端是否呈現憑證，但不針對 CA 信任存放區驗證憑證。憑證在 X-Amzn-Mtls-Clientcert 標頭中轉發到後端。由後端應用程式執行驗證。適用於回溯相容的遷移。
• 驗證模式 (Verify mode)：ALB 針對配置的信任存放區 (受信任 CA 憑證捆綁包) 驗證用戶端憑證。無效憑證會在 ALB 被拒絕。憑證仍會在標頭中轉發供後端記錄。

mTLS 信任存放區按 ALB 接聽受器配置，捆綁包儲存在 S3 中。可以透過更新 S3 物件並觸發 ALB 重新整理來輪換信任存放區。

mTLS 使用案例

ALB 的 mTLS 是以下情境的標準邊緣安全性答案：

• 需要裝置綁定 TLS 驗證的 IoT 設備群。
• 合作夥伴持有核發的用戶端憑證的 B2B 合作夥伴 API。
• 零信任架構中的內部服務對服務驗證。

搭配 ACM Private CA 來發行用戶端憑證和 ALB 信任存放區。

憑證輪換策略

憑證輪換是維護運作的衛生，考試會透過「到期時會發生什麼」的情境間接測試。

策略 1：ACM 自動續期 (預設)

對於透過 DNS 驗證發行的 ACM 公有憑證，AWS 會自動處理續期。所需行動：監控 CloudWatch 事件中的 ACM Certificate Approaching Expiration 並對續期失敗設定警示。失敗原因：驗證 CNAME 被刪除，或網域所有權更改。

策略 2：匯入憑證的手動輪換

對於匯入的憑證，手動輪換需要：

1. 在舊憑證到期前從你的 CA 獲取新憑證。
2. 匯入 ACM。
3. 更新 ALB / CloudFront 接聽受器以使用新憑證的 ARN。
4. 等待 CloudFront 傳播 (約 15 分鐘)。
5. 刪除舊憑證。

Lambda + EventBridge 自動化可以簡化步驟 2-5。考試經常測試「自動化憑證輪換」 — 答案是受 EventBridge 觸發的 Lambda。

策略 3：ACM Private CA 短期憑證

對於具有短期憑證 (24 小時 TTL) 的內部服務，使用 SSM Run Command 或 Lambda 每日輪換憑證。透過 Systems Manager Parameter Store 向工作負載推送新憑證。這是高保證模式。

端到端加密架構

ANS-C01 考試可能會詢問的三種參考架構：

架構 1：具有完整 TLS 的用戶端到後端

用戶端 → CloudFront (TLS 1.3, ACM us-east-1)
       → ALB (TLS 1.2, ACM 區域性)
       → EC2 後端 (使用區域性 ACM 或自我簽署的 TLS 1.2)

三次 TLS 終止。每一跳都會重新加密。WAF 可以在 CloudFront 檢測 (解密後的視圖)。由於網路中沒有純文字流動，因此維持了端到端的機密性。

架構 2：用於用戶端憑證可見性的 NLB 透傳

用戶端 (帶有 X.509 憑證) → NLB TLS 透傳
                         → EC2 後端 (終止 TLS，驗證用戶端憑證)

NLB 轉發加密位元組；後端看到原始交握，包含用戶端的 X.509 憑證。NLB 無 L7 檢測。當後端必須看到原始憑證時使用 (例如具備硬編碼憑證驗證邏輯的舊版應用程式)。

架構 3：透過 Direct Connect 使用 VPN 的混合架構

內部部署 → 透過公有 VIF 的 IPsec 隧道 → AWS 端點
內部部署 → 帶有 MACsec 的 Direct Connect → AWS Direct Connect 路由器

兩層加密：第 2 層的 MACsec 保護物理連結；第 3 層的 IPsec 保護 IP 封包。當合規性要求對租用線路進行深層防禦時使用。

白話文解釋

把網路加密用日常生活類比拆開來：

類比一：寄掛號信的多層信封

把 HTTP request 想成一封信件：

• TLS = 你把信件裝進一個透明的塑膠袋，塑膠袋上寫著「給某某收」（SNI），但袋子裡的信被密封起來。郵差（網路）只看得到封套，看不到內容。塑膠袋的材質決定了強度（cipher suite），新的塑膠袋（TLS 1.3）比舊的（TLS 1.0）更難拆。
• ACM = 透明塑膠袋的製造商。AWS 幫你免費生產塑膠袋，且過期前自動換新（auto-renewal）。
• ACM Private CA = 你公司自己開塑膠袋工廠，做的袋子只有公司內部認得（trusted by your apps），但材質一樣好。
• mTLS = 寄信的人也要附上身分證（client certificate），收信端驗證後才肯收。
• TLS termination = 郵局先拆開塑膠袋檢查內容（路由、WAF），檢查完再裝回新塑膠袋寄出。
• TLS passthrough = 郵局完全不拆，原封不動轉寄。
• DNSSEC = 收件地址簿（DNS）有公證人簽章，避免有人偷改地址讓你寄到山寨郵局。

類比二：保險箱送貨車

把 Direct Connect 想成從工廠到倉庫的高速公路專屬貨車：

• 沒加密的 Direct Connect = 開敞篷車運貨。沒人攔貨，但路上可能有人偷拍。
• MACsec = 貨車本身加裝裝甲鋼板（L2 encryption）。整個物理層被保護，連路邊側錄器也偷不了內容。需要 dedicated 10/100 Gbps 才能裝（hosted connection 不行）。
• IPsec over Direct Connect = 貨物本身用密封箱裝（L3 encryption）。即使有人闖進貨車也打不開箱。
• MACsec + IPsec 雙層 = 裝甲車裡裝密封箱。最高規格，金融機構跟政府用。

類比三：圖書館借書證 vs 公證書

• ACM 公開憑證 = 圖書館自己發的免費借書證，全國通用。免費、自動續期。
• ACM Private CA = 你家公司發的內部識別證。只有公司內部系統認，外面不認。要付錢給公司管理識別證系統。
• DNSSEC = 圖書館門口貼公告，告訴大家「這張借書證是真的」，蓋了戶政事務所的章。沒蓋章的借書證一律拒絕（SERVFAIL）。

常見情境

情境 A：符合 HIPAA 的端到端加密

要求：位於 eu-west-1 的醫療 SaaS 必須強制執行從用戶端到 RDS 資料庫的端到端 TLS 1.2+ 加密。

架構：

• 帶有 TLSv1.2_2021 安全性策略的 CloudFront，在 us-east-1 的 ACM 憑證。
• 位於 eu-west-1 帶有 TLS 1.2 接聽受器的 ALB，在 eu-west-1 的 ACM 憑證。
• ALB 到後端 EC2 使用 HTTPS 目標群組，並配合自我簽署或來自 ACM Private CA 的憑證。
• EC2 到 RDS 使用強制 SSL 的參數群組 (rds.force_ssl=1) 並在用戶端使用 RDS CA 憑證。
• 在 Route 53 託管區域啟用 DNSSEC。

陷阱變體：題目建議使用帶有 HTTP 目標群組的 NLB (從 NLB 到後端無加密) — 錯誤，這會破壞端到端 TLS。

情境 B：聯邦合規要求的 Direct Connect MACsec

要求：聯邦客戶需要 Direct Connect 上的第 2 層加密以符合 FedRAMP High。

架構：

• 在具備 MACsec 能力的地點 (US-East-1 IAD 或 US-West-1 PDX) 訂購 10 Gbps 專用 Direct Connect。
• 在客戶端具備 MACsec 能力的路由器上配置 CAK/CKN。
• AWS 在 AWS 端連接埠配置匹配的 CAK/CKN。
• 透過客戶路由器上的 show macsec 驗證 MACsec 關聯。

陷阱變體：託管連線或 1 Gbps 連線 — 錯誤，MACsec 需要 10/100 Gbps 專用連線。

常見考試陷阱

其他反模式：

• 使用 ACM 發行的公有憑證作為 AWS Network Firewall TLS 檢測的 CA — ACM 不發行 CA 憑證，你必須匯入。
• 在啟用 DNSSEC 後忘記在註冊商處發佈 DS 記錄 — 區域雖然已簽署但沒有驗證。
• 在合規情境中使用 TLS 1.0/1.1 — 應選擇 TLS 1.2+ 安全性策略。
• 認為第 3 層的 IPsec 與第 2 層的 MACsec 涵蓋相同的威脅模型 — 它們防範不同的攻擊。
• 嘗試對 ACM 匯入的憑證使用自動續期 — 匯入的憑證不會自動續期。
• 在未設定正確 ALB IAM 權限的情況下將 ALB mTLS 信任存放區放入任何 S3 儲存貯體。
• 忘記 NLB TLS 終止使用 NLB 區域中的區域性 ACM 憑證。
• 使用加速 VPN 搭配 VGW (僅 TGW 支援) 或靜態路由 (需要 BGP)。

運作考量

憑證庫存與到期監控

維護單一儀表板，追蹤所有憑證：

• ACM 發行的 (自動續期)
• ACM 匯入的 (手動續期)
• EC2 執行個體上的自我簽署憑證
• ACM Private CA 發行的憑證
• 部署在 ACM 外部的第三方憑證

使用 AWS Config 規則 acm-certificate-expiration-check 追蹤到期情況，並使用 CloudWatch 警示進行主動告警。

記錄與稽核

CloudTrail 記錄 ACM API 呼叫 (RequestCertificate, ImportCertificate, DeleteCertificate)。VPC Flow Logs 不顯示 TLS 負載。要稽核 TLS 交握，請啟用 ALB 存取日誌 (顯示 TLS 版本和密碼) 和 CloudFront 存取日誌。

成本優化

公有 ACM 憑證：免費。ACM Private CA：每月每個 CA 400 美元 + 每張憑證費用。mTLS：無額外 ALB 費用但需要 Private CA。MACsec：包含在專用 DX 連接埠定價中 (無額外費用)。VPN 上的 IPsec：包含在 VPN 定價中。

成本動因是 ACM Private CA。如果你只需要為少數應用程式提供內部憑證，請評估自我簽署憑證 (運作開銷) vs Private CA (託管但每月 400 美元)。

FAQ

Q1: 我能否對 eu-west-1 中的 ALB 和 CloudFront 分發使用同一個 ACM 憑證？

不能。CloudFront 要求憑證位於 us-east-1；ALB 要求憑證與 ALB 位於同一區域 (在此案例中為 eu-west-1)。你需要兩個單獨的憑證 — 一個在 us-east-1 給 CloudFront，一個在 eu-west-1 給 ALB。兩者可以使用相同網域名稱；如果網域一致，兩者都能透過 DNS 驗證自動續期。

Q2: 何時該使用 NLB TLS 透傳而非 ALB TLS 終止？

當後端應用程式必須看到原始 TLS 交握時 (例如：帶有後端用戶端憑證驗證的 mTLS，或後端的自訂 TLS 擴充功能/基於 SNI 的邏輯)，就需要 NLB TLS 透傳。對於所有其他情況，優先選用 ALB TLS 終止，因為它能啟用 L7 功能 (主機/路徑路由、WAF)。NLB 透傳也提供完整的 IP 透明度而無需代理標頭。

Q3: MACsec 比 Direct Connect 上的 IPsec 快還是慢？

MACsec 更快。MACsec 在物理層進行硬體加速，增加的延遲低於亞毫秒。IPsec 在 AWS 端路由器上的軟體運行 (或在高級型號上以硬體運行)，會增加幾毫秒延遲。對於高傳輸量、低延遲工作負載 (HFT、即時分析)，MACsec 是正確答案。

Q4: 如何在不中斷連線的情況下輪換 MACsec CAK？

MACsec CAK 輪換需要客戶端與 AWS 端協調重新配置。AWS 支援在連線上配置兩個 CAK/CKN 對，允許「先建後拆」的輪換：在兩端配置新對，驗證新關聯已啟動，然後移除舊對。這避免了輪換期間連結中斷。請安排維護時段，因為配置錯誤可能會導致連結停機。

Q5: DNSSEC 會影響 DNS 查詢延遲嗎？

會有一點影響。DNSSEC 會向 DNS 響應新增簽章資料，將負載大小從 ~64 位元組增加到數百位元組。驗證需要解析程式追蹤 DS 鏈，這涉及額外的簽章驗證查詢。實務上，對於快取的查詢，延遲增加為個位數毫秒；對於新查詢，延遲增加為數十毫秒。對於大多數工作負載，DNSSEC 帶來的安全性效益超過延遲成本。

Q6: 我能否使用 ACM Private CA 簽署伺服器憑證以在 AWS 外部使用？

可以。ACM Private CA 可以發行最終實體憑證，你可以匯出這些憑證並在任何伺服器 (內部部署、第三方雲端、IoT 設備) 上使用。憑證匯出會為你提供憑證加私鑰。請注意，匯出的憑證不會自動續期 — 你需在 ACM 外部管理其生命週期。

Q7: ACM Private CA 與 AWS KMS 在密碼運算上有什麼區別？

ACM Private CA 發行用於 TLS 驗證的 X.509 憑證。AWS KMS 提供密碼原語 (加密/解密、簽署/驗證)，但不發行憑證。KMS 用於資料的封包加密、簽署任意 blob 以及管理金鑰內容。某些整合會同時使用兩者 — ACM Private CA 可能使用 KMS 金鑰作為底層 CA 的私鑰。

Q8: 對於 ANS-C01 而言，TLS 1.3 與 TLS 1.2 有什麼不同？

TLS 1.3 將交握從兩次往返減少到一次 (更快)，移除了舊有的密碼套件 (更安全)，並新增了 0-RTT 模式 (無往返恢復連線)。所有現代 AWS 端點 (ALB, CloudFront, NLB TLS 接聽受器, API Gateway) 均支援 TLS 1.3。對於 ANS-C01，優先選用除了 TLS 1.2 外還啟用 TLS 1.3 的安全性策略。

Q9: AWS Network Firewall TLS 檢測能否使用 ACM 發行的憑證？

不能。ACM 不發行 CA 憑證。Network Firewall TLS 檢測需要一個由你匯入 ACM 的 CA 憑證 (通常由 ACM Private CA 或外部 CA 產生，然後匯出並匯入 ACM)。TLS 檢測配置中會參考該憑證的 ARN。

Q10: 如何在 RDS 資料庫層強制執行 TLS？

使用 RDS 提供的憑證 (透過 AWS 發行的根 CA 鏈) 並透過參數群組強制 SSL (PostgreSQL 為 rds.force_ssl=1, MySQL 為 require_secure_transport=ON)。用戶端攜帶 RDS 根 CA 捆綁包連線並驗證伺服器憑證。為了更高的保證，請使用 IAM 資料庫身分驗證或 RDS Proxy 的強制 TLS 模式。

總結：網路加密答案模式

當你在 ANS-C01 中讀到網路加密題目時，請跑一遍此檢核表：

• 題目是關於 CloudFront 憑證嗎？ → ACM 必須在 us-east-1。
• 題目是關於區域性 ALB / NLB / API Gateway 憑證嗎？ → ACM 必須在同一區域。
• 題目是關於 Direct Connect 的 L2 加密嗎？ → MACsec 僅限 10/100 Gbps 專用連線。
• 題目是關於租用線路上的 L3 加密嗎？ → 透過公有 VIF 的 IPsec。
• 題目是關於用戶端到後端的端到端加密嗎？ → CloudFront → ALB → 後端，所有 TLS 終止。
• 題目是關於後端對原始用戶端憑證的可見性嗎？ → NLB TLS 透傳。
• 題目是關於 DNSSEC 驗證嗎？ → us-east-1 的 KMS ECC_NIST_P256，僅限公有託管區域。
• 題目是關於內部憑證管理嗎？ → ACM Private CA。
• 題目是關於負載平衡器上的 mTLS 嗎？ → ALB mTLS 使用來自 Private CA 的信任存放區。

掌握憑證區域限制、MACsec 硬體需求、DNSSEC KMS 規則以及 TLS 終止/透傳模式，ANS-C01 任務 4.3 的題目就會變得非常容易預測。

常考陷阱

• CloudFront 的 ACM 憑證必須在 us-east-1 — 不管 origin 在哪。
• ACM 不簽 CA 憑證 — Network Firewall TLS inspection 要 import CA，不能 request。
• MACsec 只支援 dedicated 10/100 Gbps — hosted connection 跟 1 Gbps 都不行。
• MACsec 需要 MACsec-capable port + MACsec-capable router — 訂 connection 時要選對 location。
• DNSSEC KMS 必須 ECC_NIST_P256, customer-managed, us-east-1 — 對稱、AWS-managed、其他 region 都會失敗。
• DNSSEC 只支援 public hosted zone — private hosted zone 不支援。
• DS record 要在 registrar 公告 — 不公告就沒人驗證，等於沒簽。
• ACM 自動續期只對 ACM-issued 憑證 — imported 憑證不會自動續期。
• Accelerated VPN 必須用 TGW + BGP — VGW 不支援，靜態路由也不支援。
• ACM Private CA 一個月 $400 — 不要為了一個服務開一個 CA。
• ALB mTLS truststore 放在 S3 — 要設對 ALB IAM 權限才能讀。
• TLS 1.0/1.1 不符合 HIPAA/PCI — 用 TLSv1.2_2021 或更新的 security policy。