傳輸中加密——TLS、ACM、VPN 與安全遠端存取

AWS 上的「傳輸中加密」究竟是什麼

傳輸中加密（encryption in transit）是指在資料穿越任何網路時的密碼學保護——無論是使用者到 Load Balancer 之間、兩個 VPC 之間、VPC 與地端之間，還是應用程式與 AWS API 端點之間。在 SCS-C02 中，傳輸中加密是 Domain 5 Task 5.1 的主軸，考試測驗的重點是：你能否在不同情境下選出正確的基本元件（TLS、IPsec、MACsec、SSH-over-Session-Manager）、能否在使用者試圖繞過時強制執行，以及你是否理解讓傳輸中加密在運營上可持續的憑證生命週期管理。

傳輸中加密對考試而言有三項承諾：機密性（竊聽者無法讀取酬載）、完整性（傳輸途中的竄改可被偵測），以及真實性（對端確實是它聲稱的那方，透過憑證或預共用金鑰證明）。每當考題要求你「確保用戶端與伺服器之間的資料不被截取」，答案必然是某種傳輸中加密——應用程式流量通常是 TLS，站對站網路流量是 IPsec，Layer 2 光纖是 MACsec，人員對執行個體的存取則是 Session Manager 或 EC2 Instance Connect。

傳輸中加密也與靜態加密並列，共同構成 AWS「隨處加密」的兩個半部。兩者互補但不可互換——靜態加密保護磁碟上的資料，傳輸中加密保護線路上的資料。SCS-C02 喜歡在同一個情境中混用兩者，測試你能否分辨清楚。

傳輸中加密必知的 TLS 基礎

Transport Layer Security（TLS）是 AWS 上最常見的傳輸中加密形式。握手建立工作階段金鑰，記錄協定再用這些金鑰對每個位元組進行加密與認證。你必須熟記的當前版本是 TLS 1.2 與 TLS 1.3。

TLS 1.2 採用五步握手：ClientHello、ServerHello、Certificate + ServerKeyExchange、ClientKeyExchange + ChangeCipherSpec、Finished。它支援廣泛的 cipher suite 選單，包括缺乏前向安全性的 RSA 金鑰傳輸，以及提供完美前向安全性（PFS）的 ECDHE-based cipher suite。

TLS 1.3 將握手簡化為單一往返，完全移除舊版 cipher suite，強制使用短暫 Diffie-Hellman 以確保前向安全性，並對整個握手記錄進行認證。TLS 1.3 的每個 cipher suite 都依設計提供完美前向安全性——無法關閉，也沒有 RSA 金鑰傳輸。

在 AWS 的傳輸中加密中，「完美前向安全性」是考試常見的關鍵詞。PFS 意味著即使長期私鑰事後遭到洩漏，過往的工作階段流量也無法被解密，因為每個工作階段衍生的短暫金鑰在握手後即被丟棄。CloudFront、ALB 和 API Gateway 都在其安全政策中支援具備 PFS 能力的 cipher suite——選擇正確的政策是設計強健傳輸中加密的關鍵。

Cipher Suite 與安全政策

TLS 連線在握手期間挑選一個 cipher suite——cipher suite 指定金鑰交換演算法（ECDHE）、認證演算法（RSA 或 ECDSA）、主體加密演算法（AES-128-GCM、AES-256-GCM、ChaCha20-Poly1305），以及 MAC（使用 GCM 等 AEAD cipher 時通常是隱式的）。AWS 的 Load Balancer、CloudFront 和 API Gateway 透過安全政策——形如 ELBSecurityPolicy-TLS13-1-2-2021-06 或 TLSv1.2_2021 的具名套件——來呈現這個選擇。選擇更嚴格的政策是在邊緣強化傳輸中加密最簡單的手段。

ACM——傳輸中加密背後的憑證引擎

AWS Certificate Manager（ACM） 是負責佈建、部署與更新 X.509 憑證的服務，這些憑證使傳輸中加密成為可能。ACM 有三種模式，必須在 SCS-C02 考試中加以區分：

1. 公用 ACM 憑證 — 由 Amazon 的公用 CA 簽發，免費，有效期 13 個月，且只能用於整合的 AWS 服務（ALB、具 TLS 監聽器的 NLB、CloudFront、API Gateway、App Runner、Verified Access）。你無法匯出私鑰。只要 DNS 或 Email 驗證保持完整，ACM 會在到期前 60 天自動更新這些憑證。
2. 匯入憑證 — 你攜帶由外部 CA 簽發的憑證與私鑰。ACM 儲存並提供給整合服務使用，但無法自動更新。你必須在到期前手動輪換，可透過 CloudWatch + EventBridge 在 ACM Certificate Approaching Expiration 事件觸發時收到通知。
3. ACM Private CA 憑證 — 由你在 AWS 內部運營的私有 CA 階層簽發，用於內部傳輸中加密（mTLS、內部微服務、EKS Pod 識別、IoT 裝置識別）。私有憑證可匯出（含私鑰），供非 AWS 工作負載使用。

ACM Private CA 階層

對於大規模內部傳輸中加密，ACM Private CA 提供受管的 CA 階層。建議採用三層架構：

• Root CA — 離線式，只簽發從屬 CA，效期極長（10 年以上），保存於專屬的安全帳號中。
• Subordinate CA — 簽發終端實體憑證，效期約 3-5 年，可依區域部署並透過 AWS RAM 分享。
• 終端實體憑證 — 短效（mTLS 為數小時到數天，一般 TLS 為 13 個月），由 Lambda/EventBridge 自動化或 EKS Pod Identity、IoT Core 等服務自動簽發。

短效終端實體憑證是 SCS-C02 在傳輸中加密方面的明確最佳實務，因為它限縮了金鑰遭竊後的爆炸半徑，並降低對憑證吊銷的依賴（後者向來脆弱）。

AWS 受管服務的傳輸中加密

每項受管服務都有各自的傳輸中加密設定。考試會把它們當作一組模式來測驗，請逐服務記住其設定面。

CloudFront

CloudFront 在兩段強制執行傳輸中加密：瀏覽器到邊緣，以及邊緣到來源。

• Viewer 協定政策 — redirect-to-https 或 https-only 強制用戶端在瀏覽器段使用 TLS。瀏覽器憑證來自us-east-1 的 ACM（CloudFront 是全球服務，只從維吉尼亞北部區域拉取憑證）。
• Origin 協定政策 — https-only 或 match-viewer 確保 CloudFront 對來源的流量重新加密。來源的憑證必須有效且鏈結至 CloudFront 信任庫中的 CA。自簽憑證的來源會使傳輸中加密失敗並被拒絕，除非來源是 S3 網站端點（僅用 HTTP，應改用 OAC 保護的 S3 REST 端點取代）。
• 安全政策 — 選擇提供給瀏覽器的最低 TLS 版本與 cipher suite 選單。新發行版請使用 TLSv1.2_2021 或更嚴格的政策。

ALB 與 NLB

Application Load Balancer 在監聽器終止 TLS；憑證來自同一區域的 ACM。ALB 支援 SNI，因此單一監聽器最多可提供 25 個預設憑證，加上每條監聽器規則額外的 ACM 憑證。Network Load Balancer（NLB）也使用 ACM 憑證支援 TLS 監聽器並將解密流量轉發至目標，或者你可以使用 TCP 監聽器進行端對端傳輸中加密，由目標自行終止 TLS。

ALB 另外支援兩種 mTLS 模式：

• mTLS passthrough — ALB 直接將用戶端憑證透過 X-Amzn-Mtls-Clientcert header 轉發給目標，不做驗證。
• mTLS verification — ALB 根據以 S3 bucket 中 CA bundle 為後盾的信任庫驗證用戶端憑證，在未驗證的用戶端到達目標前即拒絕。

API Gateway

REST 和 HTTP API 在 *.execute-api.<region>.amazonaws.com 端點預設使用 TLS。自訂網域名稱附加 ACM 憑證（區域型），或 edge-optimised 端點使用 us-east-1 的 ACM 憑證。API Gateway 在自訂網域上支援 mTLS，根據 S3 中的信任庫物件驗證用戶端憑證——典型使用案例是需要比單純 bearer token 更強傳輸中加密保護的 B2B 合作夥伴 API。

RDS

RDS 透過 rds.force_ssl 參數群組設定（PostgreSQL）或 require_secure_transport（MySQL）支援資料庫連線的飛行中 TLS。伺服器憑證由 Amazon 的 RDS CA 簽發——歷史上是 rds-ca-2019，之後是 rds-ca-rsa2048-g1 和 rds-ca-rsa4096-g1。生命週期至關重要：當 CA bundle 接近到期時，AWS 會發送通知，你必須同時更新資料庫和任何用戶端信任庫。未能更新會導致釘選舊 CA 的用戶端的每一條傳輸中加密連線中斷。

S3、DynamoDB 及其他物件/API 服務

所有 AWS 服務端點預設支援 HTTPS，且大多數已完全停用 HTTP。然而對於 S3，HTTP 請求仍然有效，除非你明確拒絕——這正是 aws:SecureTransport 條件存在的原因。

使用 aws:SecureTransport 強制執行 TLS

傳輸中加密只有在無法被繞過時才真正有效。在 AWS 上的標準強制執行元件是全域 IAM 條件金鑰 aws:SecureTransport，當請求使用 HTTPS 時評估為 true，使用 HTTP 時評估為 false。在資源政策上附加一個「當 false 時拒絕」的陳述句，即可在 API 層封鎖明文請求——即使呼叫者擁有其他有效憑證也不例外。

最常被測驗的範例是 S3 bucket 政策：

{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

IPsec Site-to-Site VPN——跨網際網路的傳輸中加密

當你需要保護的路段是 AWS 與地端之間（或透過公網的兩個 VPC 之間）時，TLS 很少是正確的元件——太多協定，太多通訊埠。AWS Site-to-Site VPN 使用 IPsec 在網路層提供傳輸中加密，對應用程式透明。

Site-to-Site VPN 連線在 AWS 側終止於 Virtual Private Gateway（VGW）或 Transit Gateway，在地端終止於客戶閘道裝置。每個連線有兩條隧道作為備援，各自終止於不同的 AWS 可用區域，各有其預共用金鑰或憑證。

IPsec 分兩個階段運行：

• Phase 1（IKE — Internet Key Exchange） — 對端相互認證（PSK 或 X.509 憑證），協商 Diffie-Hellman 參數，衍生用於保護 Phase 2 協商的安全關聯（SA）。
• Phase 2（ESP — Encapsulating Security Payload） — 對端協商用於保護實際使用者資料的 SA，包括加密演算法（現代預設為 AES-256-GCM）與完整性演算法。ESP 提供機密性、完整性與重放保護。

現代 AWS Site-to-Site VPN 支援 IKEv2、AES-256-GCM、SHA-2 系列完整性演算法、DH group 14 到 24，以及透過 Phase 2 重新金鑰時的新鮮 DH 交換實現的完美前向安全性。這些設定可以每條隧道單獨調整——選擇你的客戶閘道裝置所支援的最強組合。

MACsec on Direct Connect——Layer 2 傳輸中加密

MACsec（IEEE 802.1AE） 是一種介於 Ethernet 與 IP 之間的 Layer 2 傳輸中加密標準。在 AWS 上，MACsec 適用於 10 Gbps 和 100 Gbps 速率的專用 Direct Connect 連線（不適用於託管連線、1 Gbps 連線或更低階的埠）。

與 IPsec 的差異比較：

你透過將 Connection Key Name（CKN）和 Connectivity Association Key（CAK）配對上傳至 Direct Connect 連線及你的路由器來設定 MACsec。金鑰必須完全一致。AWS 使用 MKA（MACsec Key Agreement）自動輪換從 CAK 衍生的工作階段金鑰。

當考題強調在私有光纖連結上以最低額外負荷進行線速加密時，MACsec 通常是正確答案。當路徑經過公共網際網路，或需要在託管/低於線速的 Direct Connect 上運行時，IPsec 是正確答案。

Systems Manager Session Manager——不需 SSH 的 SSH

SCS-C02 已將堡壘機（bastion host）排除在建議模式之外。現代 AWS 對於人員傳輸中加密到 EC2 執行個體的答案是 AWS Systems Manager Session Manager。

Session Manager 透過 SSM agent 中繼的 WebSocket 隧道，對 EC2 執行個體（或地端受管節點）開啟互動式 Shell 工作階段。流量是端對端 TLS 1.2——你的電腦與 SSM 區域端點通訊，執行個體上的 SSM agent 輪詢同一個端點，兩端由工作階段 ID 進行密碼學繫結。沒有 SSH 通訊埠，沒有 SSH 金鑰對，安全群組上也沒有入站規則。

為何這是 SCS-C02 對執行個體傳輸中加密的預設答案：

• 無入站通訊埠 — 安全群組可以拒絕所有入站流量。執行個體只需對 SSM、EC2 messages 和 S3 端點開放出站 443（或在執行個體為私有時使用這些服務的 VPC 介面端點）。
• IAM 型存取 — 透過 IAM 政策授予 ssm:StartSession。撤銷立即生效，且不需要輪換 SSH 金鑰。
• 工作階段記錄 — 每個按鍵與指令輸出都可串流至 CloudWatch Logs 或 S3，並可選擇以 KMS 加密。這滿足了大多數以前依賴堡壘機上 auditd 的稽核要求。
• 通訊埠轉發 — Session Manager 可將任意本地通訊埠轉發至執行個體上的通訊埠，或執行個體能到達的遠端主機通訊埠。這取代了存取私有 RDS、ElasticSearch 或管理 Web UI 的 SSH 隧道模式，同時保持傳輸中加密端對端。

EC2 Instance Connect——直接 SSH 的短效金鑰

EC2 Instance Connect（EIC） 是 AWS 原生的第二個傳輸中加密到執行個體選項。EIC 透過 EC2 Instance Connect API 將一次性 SSH 公鑰（有效期 60 秒）注入執行個體，然後使用對應的私鑰透過一般 SSH（通訊埠 22）連線。

有兩種模式：

• 公有子網路 EIC — 只適用於具有公有 IP 的公有子網路執行個體，因為 SSH 工作階段從使用者的機器經由網際網路發起。安全群組必須允許來自特定來源的通訊埠 22。
• EIC Endpoint（EICE） — 一個受管閘道，讓你無需堡壘機或 NAT 即可到達私有子網路的執行個體。SSH 連線透過端點隧道傳輸，以端對端 TLS 包裝。安全群組必須允許來自 EICE 端點安全群組的通訊埠 22。

EIC 的吸引力在於公鑰推送提供了即時憑證核發，具備完整的 CloudTrail 稽核與 IAM 管控（ec2-instance-connect:SendSSHPublicKey）。然而它仍然是 SSH——協定假設、金鑰類型和主機金鑰驗證全都存在於 SSH 層。在大多數 SCS-C02 情境中，若考題詢問「以傳輸中加密且最低運營負擔安全遠端存取 EC2」，Session Manager 勝過 EIC，因為它完全去除了 SSH。

決策樹——選擇正確的傳輸中加密元件

當 SCS-C02 考試呈現一個情境時，沿著這棵決策樹走：

1. 是人員存取 EC2 執行個體嗎？
   • 預設 → Session Manager（無入站通訊埠、IAM 管控、TLS 1.2、稽核日誌）。
   • 需要真正的 SSH 語義？→ 使用 EICE 的 EC2 Instance Connect（短效金鑰）。
   • 不得不用堡壘機的舊有需求？→ 堡壘機 + SG + 金鑰輪換，但視為最後手段。
2. 是應用程式連線至 AWS 受管 HTTPS 端點嗎？
   • 預設使用 TLS。透過資源政策上的 aws:SecureTransport 強制執行。
3. 是對外的 Web 應用程式嗎？
   • CloudFront 搭配 ACM 憑證，viewer policy 設為 redirect-to-https，安全政策設為 TLSv1.2_2021 或更嚴格，origin protocol 設為 https-only。
4. 是 VPC 內部的私有微服務網格嗎？
   • ALB 或 VPC Lattice 上的 mTLS，使用 ACM Private CA 簽發的終端實體憑證，短效輪換。
5. 是地端與 VPC 的通訊嗎？
   • 公共路徑 → IPsec Site-to-Site VPN。
   • 私有 DX 路徑有嚴格加密要求 → MACsec（10/100 Gbps 專用）或 IPsec over DX。
6. 是兩個 VPC 之間的流量嗎？
   • 同帳號/同區域 → VPC peering 或 Transit Gateway，仍建議在應用層使用 TLS 進行深度防禦。
   • 不同帳號/不同區域 → Transit Gateway peering 加應用層 TLS；或使用 PrivateLink 進行服務對服務通訊。

這棵決策樹就是考試預期你掌握的心智模型。

白話文解釋

技術名詞看起來嚇人，但 encryption in transit 其實就是「資料在路上不被偷看」。換三個生活類比看看：

類比一：郵政系統 vs. 機密快遞 普通明信片寄出去，每一個經手的郵差都看得到內容，這就是 HTTP。把信放進專屬密封袋、貼上防拆封條、收件人才有鑰匙拆封 — 這就是 TLS。aws:SecureTransport=true 就像「這個地址只收密封快遞，明信片一律退件」。Session Manager 則更狠 — 連送件員都沒見到信封，整個過程在加密管道裡完成。

類比二：保險箱與保險櫃車隊 TLS 像是把貨品放進保險箱再送出去；IPsec VPN 則是整輛運鈔車改裝成裝甲車，連車廂外殼都隔絕窺視 — 因為它是 layer 3，不只保護一份檔案，是把整段網路流量都包起來。MACsec 又更底層一層，連高速公路本身的柏油路面都換成加密版本（layer 2 鋪設），所以開多快都不損效率。

類比三：開書考試的監考員 ACM 像是那個負責簽發、收回、定期換發學生證的教務處 — 每張證件（憑證）都有有效期、可信簽發單位。ACM Private CA 則是公司內部的識別證系統，自己決定誰可以發證、誰可以驗證。mTLS 就是進門時不只要看你的識別證（client cert），保全也要把自己的識別證（server cert）秀給你看，雙方都驗證後才能談話。encryption in transit 沒有 mTLS 的話，就是只有單向驗證，攻擊者可能假冒你信任的伺服器。

把三個類比放在一起：encryption in transit 是一條完整的「路上保護鏈」 — 包裝（TLS/IPsec/MACsec）、簽收身份（憑證）、與不可旁路（aws:SecureTransport SCP 強制）。SCS-C02 出題時常常只是換一層包裝皮，核心就這三件事。

TLS 1.2 vs TLS 1.3——考試常考的具體差異

對於 SCS-C02 傳輸中加密的現代化問題：TLS 1.3 在每個維度上都勝出，除了用戶端相容性。選擇允許 TLS 1.3 並可回退至 TLS 1.2 的安全政策，除非你有嚴格的法規或用戶端限制。

憑證生命週期——傳輸中加密的運營核心

已到期的憑證會讓傳輸中加密完全中斷。考試測驗你能否圍繞生命週期建立自動化。

• ACM 公用憑證自動更新要求網域驗證保持完整——DNS 驗證（CNAME 永久保留）是建議且最可靠的路徑。若列出的聯絡 Email 信箱失效，Email 驗證可能導致更新失敗。
• ACM Certificate Approaching Expiration 是一個 EventBridge 事件，在到期前 45 天觸發。將其接至 SNS 或開啟工單的 Lambda——這是考題說「在傳輸中加密中斷前提醒我」時的標準答案。
• AWS Config 有受管規則 acm-certificate-expiration-check，可在可設定的時間窗口內（預設 14 天）標示即將到期的憑證，適合作為 SCP/Audit Manager 的合規證據。
• ACM Private CA 終端實體憑證應由自動化而非人工重新簽發。搭配 EKS Pod Identity Webhook、IoT Core，或每隔 N 小時重新簽發的自訂 Lambda。

mTLS——雙向傳輸中加密認證

標準 TLS 只認證伺服器端。mTLS（mutual TLS）兩端都認證——用戶端也出示憑證，由伺服器根據信任庫進行驗證。mTLS 是 SCS-C02 最偏好用於 B2B API、IoT 設備群，以及零信任微服務網格的模式。

AWS 的 mTLS 介面：

• API Gateway — REST/HTTP API 在自訂網域上的 mTLS；信任庫是包含 CA bundle PEM 的 S3 物件；用戶端憑證驗證在 API Gateway 中進行，在請求到達 Lambda 或整合後端之前完成。
• ALB — mTLS passthrough 或 verification 模式；verification 模式使用以 S3 CA bundle 為後盾的 Trust Store 資源（ACM 相鄰的獨立服務）。
• VPC Lattice — 認證政策可要求 mTLS 出示身份，並結合 IAM 型授權。
• IoT Core — 每個裝置獲得唯一的 X.509 憑證，預設強制執行 mutual TLS；mTLS 是 AWS IoT 傳輸中加密的基礎元件。
• EKS service mesh（App Mesh、Istio、Linkerd） — 使用 ACM Private CA 簽發的憑證在 Pod 間實施 mTLS。

mTLS 比僅伺服器端 TLS 在運營上更昂貴，因為每個用戶端都需要自己的憑證、生命週期和吊銷路徑。回報是強健的身份繫結——能精確知道傳輸中加密連線另一端是哪個裝置或服務，而不必依賴 bearer token 或共用金密。

混合架構與跨區域設計的傳輸中加密

考試喜歡混合架構情境。以下是標準對應關係：

• 分支辦公室 → AWS — IPsec Site-to-Site VPN 到 TGW，備援隧道。
• 資料中心 → AWS，低延遲 — Direct Connect 搭配 MACsec（專用 10/100G），或 IPsec over Direct Connect 公用/transit VIF。
• 資料中心 → AWS，多帳號 — Direct Connect Gateway 搭配 TGW 關聯，再加上 IPsec 進行傳輸中加密。
• 區域 A → 區域 B — TGW 跨區域 peering（AWS 自動加密），或 VPC peering，再加上應用層 TLS。
• 同區域 AWS 服務對 AWS 服務 — 所有公用端點預設已加密。使用 VPC 介面端點（PrivateLink）讓流量完全不走公網。

日誌、監控與傳輸中加密的稽核

無法證明的傳輸中加密，在稽核中等同於不存在。SCS-C02 的思維是「設計出證明，而非只設計控制措施」。

• CloudFront 存取日誌記錄 cs-protocol（http/https）和 ssl-protocol（TLSv1.2/1.3）——在 Athena 中查詢以確認 100% TLS 採用率。
• ALB 存取日誌包含 ssl_cipher 和 ssl_protocol 欄位；標示任何非 TLS 的行。
• VPC Flow Logs 顯示流量有流動，但不顯示 cipher；搭配封包擷取（Traffic Mirroring）進行取證分析。
• CloudTrail 記錄每次 StartSession、SendSSHPublicKey、ACM RenewCertificate、KMS 使用，以及 Site-to-Site VPN CreateVpnConnection——這是證明誰發起哪條傳輸中加密通道的核心。
• AWS Config 規則——s3-bucket-ssl-requests-only、acm-certificate-expiration-check、alb-http-to-https-redirection-check、cloudfront-viewer-policy-https、elbv2-acm-certificate-required——將所有這些接入 Security Hub，打造全組織的傳輸中加密狀態儀表板。

常見陷阱與反模式

其他常見陷阱：

• 相信 aws:SecureTransport=true 單獨就能提供靜態加密。它不能。
• 忘記公用 ACM 憑證是區域繫結的（CloudFront 只從 us-east-1 拉取；ALB 從其所在區域拉取）。
• 在 Session Manager 可以滿足相同需求且不需要入站通訊埠和完整稽核的情況下，仍使用通訊埠 22 加金鑰對。
• 因為「Direct Connect 已經是私有的」而跳過 MACsec——DX 是私有的，不是加密的。
• 在 IPsec 考題中混淆 Phase 1（IKE，金鑰協商）和 Phase 2（ESP，資料加密）。
• 將 mTLS 視為授權。mTLS 只是認證；你仍然需要授權層（Cognito、IAM、Verified Permissions、Lattice 認證政策）。

常見問題

Q1：何時應使用 IPsec VPN 而非 MACsec 作為地端與 AWS 之間的傳輸中加密？

當你有 10 Gbps 或 100 Gbps 的專用 Direct Connect 連線、你的客戶路由器支援 MACsec（CKN/CAK），且你需要近乎零額外負擔的線速吞吐量時，使用 MACsec。當路徑經過公共網際網路、你的 DX 是託管或低於 10G（MACsec 不支援）時，或需要在現有公用 VIF 之上進行傳輸中加密時，使用 IPsec Site-to-Site VPN。你也可以疊加使用——IPsec over Direct Connect——以滿足要求無論實體層是否私有都必須進行密碼學保護的合規制度。

Q2：如何在整個 AWS Organization 強制執行所有 S3 請求的 TLS？

結合三個層次。（1）在組織根套用 SCP，當 aws:SecureTransport 為 false 時拒絕 s3:*，跨所有成員帳號封鎖明文請求。（2）透過 Config Conformance Pack 部署 AWS Config 受管規則 s3-bucket-ssl-requests-only，使每個 bucket 政策都能獨立驗證。（3）在 Security Hub 中呈現失敗項目。這是 SCS-C02 對物件儲存全組織傳輸中加密強制執行的標準答案。

Q3：ALB 上 mTLS passthrough 和 mTLS verification 有什麼差異？

在 passthrough 模式中，ALB 不做憑證驗證——它終止外層 TLS，但將用戶端憑證透過 X-Amzn-Mtls-Clientcert header 轉發給目標進行檢查。當你的應用程式有自己的 PKI 和授權邏輯時使用此模式。在 verification 模式中，ALB 根據 Trust Store（S3 為後盾的 CA bundle）驗證用戶端憑證，並在未驗證的用戶端到達目標前即拒絕。Verification 模式是更強的傳輸中加密姿態，因為未認證的流量永遠不會進入應用層。

Q4：為何部署公用 ACM 憑證後 13 個月傳輸中加密可能「中斷」？

ACM 在到期前 60 天自動更新公用憑證，但若網域驗證已中斷則更新會靜默失敗——最常見的情況是驗證 CNAME 記錄從 Route 53 被移除，或列出的驗證 Email 信箱不再收信。修復方法是使用 DNS 驗證並永久保留 CNAME，同時將 ACM Certificate Approaching Expiration EventBridge 事件接至 SNS，讓你有 45 天的預警時間。匯入的憑證完全不會自動更新，必須手動輪換。

Q5：Session Manager 能取代所有堡壘機使用案例嗎？

幾乎可以。Session Manager 涵蓋互動式 Shell、指令執行和通訊埠轉發（包括到執行個體可以到達的遠端主機），因此取代了堡壘機 95% 的功能——包括連接至私有 RDS 或管理 Web UI 的 ssh -L 隧道。剩餘的差距是你需要使用 SSH 特定功能的少數情況（在執行個體上透過 SSH 存取私有 repo 的 Git over SSH、特定的 SSH key-based agent forwarding 流程）。對於這些情況，EC2 Instance Connect Endpoint（EICE）提供以 TLS 包裝的 SSH 隧道，仍然避免來自網際網路的入站通訊埠 22。Session Manager 和 EICE 合在一起，讓傳統堡壘機架構在傳輸中加密到計算資源方面退場。

Q6：在同一個架構中，傳輸中加密與靜態加密如何互動？

兩者是獨立且互補的。傳輸中加密（TLS、IPsec、MACsec、Session Manager）在資料於網路上移動時保護它。靜態加密（KMS、SSE-S3、EBS 加密、RDS 加密）在資料靜置於磁碟時保護它。一個請求可以加密傳輸但以明文儲存（不好），或以明文傳輸但加密儲存（同樣不好）。在 SCS-C02 中，明確設計兩個層次：aws:SecureTransport=true 要求 API 呼叫使用 TLS，s3:x-amz-server-side-encryption=aws:kms（或 SSE-S3 預設 bucket 加密）要求儲存物件的靜態加密。KMS、Secrets Manager、SQS、SNS 也是同樣的模式——線路上加密傳輸，儲存中加密靜置。

Q7：使用 ACM Private CA 進行內部 mTLS 的建議憑證階層為何？

AWS 建議的大規模傳輸中加密模式是三層階層：（1）Root CA 位於強化的安全帳號，只用於簽發從屬 CA，效期 10 年以上。（2）Subordinate CA 依環境或業務單位分設，由 root 簽發，效期 3-5 年，透過 AWS RAM 分享給工作負載帳號。（3）短效終端實體憑證（mTLS 為數小時到數天，一般 TLS 為 13 個月），由自動化簽發。短效終端實體憑證最小化吊銷的運營負擔，並限縮私鑰洩漏的爆炸半徑——兩者都是 SCS-C02 傳輸中加密的核心主題。