靜態加密與 KMS 政策（SSE-KMS、Key Policies、Grants、CloudHSM、Object Lock）

靜態加密與 KMS 政策是 AWS 上每一項資料保護控制的基石。身為安全工程師，你的職責不再只是「勾選加密選項」——而是要設計一套能通過稽核的 customer-managed CMK 階層，包含 key policy、grants 與 encryption context，將每個服務（S3、RDS、DynamoDB、EBS、EFS、SQS）的加密正確接線，讓建立時才能設定的選項不會讓你踩坑，並透過 Block Public Access、aws:SecureTransport、Object Lock 鎖定資源政策，以及在法規要求 KMS 無法滿足時知道何時需要 CloudHSM。靜態加密與 KMS 政策幾乎完整涵蓋 Domain 5（資料保護，SCS-C02 佔比 18%），並在每道牽涉機密性、完整性或合規保留的題目中延伸至 Domain 2 和 Domain 3。

本指南依照 SCS-C02 考試的測驗方式帶你走過靜態加密與 KMS 政策：從 CMK 設計與 key policy 機制出發，經過 envelope encryption 與 encryption context，進入各服務加密設定與建立時的陷阱，再到資源政策與 S3 強化，最後是不可竄改的合規儲存控制（Object Lock、Vault Lock、Backup Vault Lock）與 CloudHSM 的窄用途案例。全程以一家受監管的 FinTech 公司儲存付款記錄、客戶個資和稽核日誌的情境作為主軸，讓取捨更加具體。

什麼是靜態加密與 KMS 政策？

靜態加密與 KMS 政策是 AWS 用來保護儲存中資料（S3 bucket、RDS volume、DynamoDB table、EBS volume、EFS 檔案系統、SQS 佇列及更多服務）的組合機制，所使用的密碼學金鑰其生命週期、存取權限與稽核軌跡均由你掌控。安全工程師必須同時推理三個層次：

1. 金鑰層（Key layer）：customer-managed CMK（密碼學根源）、AWS-managed key（aws/s3、aws/rds 等）、AWS-owned key（不可見），以及 CloudHSM 常駐金鑰（適用於要求單租戶 HSM 的少數工作負載）。
2. 政策層（Policy layer）：key policy（強制，每個 CMK 上的資源政策）、IAM policy（身分端）、grant（程式化委派）、encryption context（以密碼學綁定的 key-value 組合），以及 VPC endpoint policy（用於 kms:* 流量）。
3. 服務整合層（Service-integration layer）：各 AWS 服務如何將靜態加密接入其資料平面——SSE-S3 vs SSE-KMS vs DSSE-KMS、RDS 儲存加密、EBS volume 加密、DynamoDB 預設加密、EFS 建立時加密、SQS 伺服器端加密，以及補充 CMK 存取控制的資源政策（S3 bucket policy、DynamoDB 資源型政策）。

為何靜態加密與 KMS 政策對 SCS-C02 如此重要

Domain 5（資料保護）佔 SCS-C02 成績的 18%，其 Task Statement 5.2（「設計並實作提供靜態資料機密性與完整性的控制」）本質上就是本指南所有決策的清單：選哪個 CMK 類別、哪個 key policy、哪個 encryption context、哪個服務層設定、哪個不可竄改的儲存原語。Domain 2（安全日誌與監控）對日誌完整性也會重用靜態加密與 KMS 政策的概念。Domain 3（基礎設施安全）在你透過 SCP 與 Config rules 強制拒絕未加密資源時也會交疊。把靜態加密與 KMS 政策的決策樹搞清楚，就能以大幅超過比例的成績橫掃考試。

白話文解釋 Encryption at Rest and KMS Policies

把這套架構映射到日常物件，你會發現它其實沒那麼神秘。

類比一：銀行保管箱（Envelope Encryption + Key Policy）

想像銀行的保管箱業務。客戶把貴重物品放進鐵盒（data key 加密的 ciphertext object），鐵盒上有一把唯一鑰匙（data key）。但客戶不會把這把鑰匙隨身帶——鑰匙本身被鎖進銀行金庫的萬能鎖匣（CMK）。要取出物品，客戶請銀行員工先用萬能鎖匣解開鐵盒鑰匙，再用鐵盒鑰匙打開鐵盒。

• Envelope encryption = 雙層鎖：data key 鎖物品，CMK 鎖 data key。CMK 永遠不離開金庫（KMS HSM），物品本身永遠不需要對 CMK 做整個 round-trip。
• Key policy = 金庫管理員的授權清冊：哪個櫃員、哪個經理、哪個區域督導可以打開萬能鎖匣，每個動作都記在簿子上（CloudTrail）。
• AWS-managed key = 銀行自己的萬能鎖匣——對小客戶夠用，但你無法決定誰能用、無法在出事時鎖死它、無法跨分行共用。
• Customer-managed CMK = 你自己定做的萬能鎖匣，授權清冊由你寫，懷疑出事可以立刻關掉它（disable），所有 ciphertext 瞬間變廢紙。

每次 SCS-C02 題目出現「audit every use」「disable on incident」「cross-account」「imported material」，銀行保管箱的類比都會把你帶到 customer-managed CMK 這個答案。

類比二：醫院病歷室的封存牆（S3 Object Lock + Backup Vault Lock + Glacier Vault Lock）

想像醫院的舊病歷儲存室。法規規定病歷必須保存 7 年，且任何人——包括院長——都不能在期限內銷毀。

• S3 Object Lock compliance mode = 牆內封存的物理水泥牆：法定保留期內，連 root account 都動不了。governance mode 則只是上鎖的鐵門——院長有特權鑰匙可以打開。
• Glacier Vault Lock = 整面牆都被 vault-lock policy 凍結；policy 一旦 lock 就再也不能修改，你只能加新東西、不能刪舊東西、不能放寬條件。
• AWS Backup Vault Lock = 備份保管庫的混凝土版本：備份本身被 lock，連備份管理員也不能在 retention 內 delete recovery point。
• MFA Delete + Block Public Access = 儲存室外牆的雙人保管和門禁卡：連房間都進不去，遑論動裡面的東西。

把法規 retention 看成「物理水泥牆」是每次 ransomware / insider-threat 題目的關鍵——「ransomware 加密了 S3 但備份要可恢復」的標準答案永遠是 Object Lock + Backup Vault Lock。

類比三：大使館外交郵袋（KMS Grants + Encryption Context + CloudHSM）

想像大使館的外交郵袋系統。

• CMK = 大使的印戒，永遠不離開大使館。
• KMS Grant = 大使簽給某個信差的單次授權書：只能對特定收件人、特定密封盒、在特定時間內使用印戒。任務完成或時間到期，授權書自動作廢。EBS 掛載 volume、RDS 拍快照時，AWS 服務拿到的就是這種一次性授權。
• Encryption context = 郵袋上的收件地址標籤：印戒蓋章時把 tenant_id=4271, data_class=phi 一併壓進蠟封；解封時必須出示同一組標籤，少一個字都打不開。這是把 CMK 用法綁死到具體 logical resource 的最強手段。
• CloudHSM = 大使館裡獨立的私人金庫，連 AWS 工作人員都沒鑰匙；只有當法規（PCI HSM、PSD2 QES、某些 sovereign cloud）要求「AWS 不能持有任何 crypto credential」時才用。

Customer-Managed CMK 設計——何時 AWS-Managed Key 不夠用

SCS-C02 每道牽涉靜態加密的題目都隱含著「選哪個 CMK 類別」的問題。決策樹雖小，但代價慘烈。

當以下任一條件成立時，請使用 customer-managed CMK

• 稽核每次使用：只有 customer-managed CMK 會在 CloudTrail 中完整記錄每次 Encrypt/Decrypt/GenerateDataKey 呼叫及呼叫身分。
• 跨帳號存取：AWS-managed key 無法透過 key policy 共享。一旦帳號 B 的工作負載需要解密帳號 A 產生的資料，就需要在 A 建立 customer-managed CMK，並在 key policy 中指名 B。
• 事件時停用：customer-managed CMK 可以停用（即時生效）或排程刪除（7–30 天視窗期）。AWS-managed key 則不行。
• 匯入金鑰材料（BYOK）：只有 customer-managed CMK 允許 Origin=EXTERNAL。
• 多 Region 複寫：只有 customer-managed CMK 可以設定 MultiRegion=true。
• Encryption context 的 key policy 條件：只有 customer-managed CMK policy 能使用 kms:EncryptionContext:* 或 kms:EncryptionContextKeys 條件。
• 細粒度 IAM 分離：customer-managed CMK 允許你將 kms:Encrypt、kms:Decrypt、kms:ReEncrypt* 分開授予；AWS-managed key 則對整合服務給予一攬子權限。

AWS-managed key 仍有其位置

對於完全在單一帳號內、低監管要求、對成本敏感的工作負載，AWS-managed key（aws/s3、aws/ebs、aws/rds、aws/dynamodb、aws/secretsmanager）是合適的。每月零費用、每年免費自動輪換、且完全不需要操作。

命名、alias、標籤與生命週期

一個健全的 customer-managed CMK 艦隊具備：

• Alias 編碼層級與用途：alias/security/audit-log-cmk、alias/finance/payments-cmk、alias/dev/sandbox-cmk。
• Tags 標記 Owner、Environment、DataClassification 與 RotationCadence。
• 啟用年度輪換（針對使用 AWS 管理材料的金鑰）。輪換會建立新的金鑰材料；舊材料仍保留以解密歷史 ciphertext。
• AWS Config rules，例如 kms-cmk-not-scheduled-for-deletion 與要求標籤完整性的自訂規則。
• SCP 拒絕在緊急存取角色以外執行 kms:ScheduleKeyDeletion 和 kms:DisableKey。

KMS Key Policy——強制的資源政策

KMS key policy 是 CMK 的主要存取控制機制。與大多數其他 AWS 服務不同，IAM 在那些服務上已足夠，但 KMS 金鑰需要明確的 key policy 授予權限；除非 key policy 透過標準的「Enable IAM」陳述句將信任委回帳號，否則 IAM 單獨使用永遠不夠。

預設 key policy

當你在主控台建立 customer-managed CMK 時，AWS 會附加一個預設 key policy，其中包含一個陳述句：

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
  "Action": "kms:*",
  "Resource": "*"
}

這個陳述句的意思是：「帳號 111111111111 中任何 IAM principal，只要其 IAM policy 也允許，即可使用此 CMK。」若沒有這個陳述句（或更嚴格的明確授予），即使是帳號 root 也無法使用該金鑰——你可能把自己鎖在外面，且復原需要聯絡 AWS Support。

SCS-C02 期望你會撰寫的 key policy 模式

• 僅限管理員：kms:Create*、kms:Describe*、kms:Enable*、kms:List*、kms:Put*、kms:Update*、kms:Revoke*、kms:Disable*、kms:Get*、kms:Delete*、kms:TagResource、kms:UntagResource、kms:ScheduleKeyDeletion、kms:CancelKeyDeletion——指派給小型管理角色。
• 金鑰使用（資料平面）：kms:Encrypt、kms:Decrypt、kms:ReEncrypt*、kms:GenerateDataKey*、kms:DescribeKey——指派給工作負載角色。
• Grant 管理：kms:CreateGrant、kms:ListGrants、kms:RevokeGrant——通常透過 kms:GrantIsForAWSResource: true 條件限縮給 AWS 服務。
• 條件式 encryption context 強制："Condition": { "StringEquals": { "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/tenant_id}" } }——將金鑰使用鎖定在 encryption context 符合呼叫者標籤的 ciphertext 上。

跨帳號 key policy

在集中式日誌 bucket 的情境中，擁有者的 CMK key policy 必須明確允許生產帳號：

• 陳述句 1——擁有者帳號的 root principal，完整 kms:*。
• 陳述句 2——生產者 principal（特定帳號 root 或透過 aws:PrincipalOrgPaths 指定 OU），具備 kms:GenerateDataKey* 與 kms:Encrypt。
• 陳述句 3——少數讀取者 principal，具備 kms:Decrypt。

生產者帳號也需要指名 CMK ARN 的 IAM 政策。忘記任一側都會產生 AccessDeniedException，訊息指向 KMS 而非資料服務——這是 Professional 級最常見的除錯陷阱。

KMS Grants——暫時性、有範圍的委派

Grant 是 SCS-C02 最愛考的窄範圍程式化委派機制。Key policy 是靜態的，IAM 是半靜態的，grant 則是動態的。

Grant 的解剖

一個 Grant 包含：

• Grantee principal——將使用 CMK 的 IAM 身分。
• Allowed operations——Encrypt、Decrypt、GenerateDataKey*、ReEncrypt*、CreateGrant、RetireGrant、DescribeKey 的子集。
• Constraints——EncryptionContextEquals 或 EncryptionContextSubset 將 Grant 鎖定在 context 符合的 ciphertext 上。
• Retiring principal——誰可以撤銷此 Grant。
• 選擇性的到期（無原生時間限制；必須明確呼叫 RetireGrant，或由發行者透過外部機制實作時間限制）。

AWS 服務何時自動使用 Grant

• EBS 在加密 volume 掛載時建立 Grant，範圍限縮至該 volume 的 encryption context（aws:ebs:id=<vol-id>）。
• RDS 在快照、還原及 read-replica 操作期間建立 Grant。
• DynamoDB 在以 customer-managed CMK 建立 table 時建立 Grant。
• Lambda 建立 Grant 以解密加密的環境變數。

這些整合用的 Grant 是正常行為——不要盲目刪除，否則服務會故障。

何時明確建立 Grant

• 每個租戶的 SaaS 隔離——在共用 CMK 上每個租戶一個 Grant，搭配 EncryptionContextEquals: { tenant_id: "<id>" }。
• 即時提權——緊急存取工作流程為處理人員建立 Grant，記錄發行動作，事件結束後撤銷。
• 跨帳號臨時工作負載——Lambda 或 Fargate task 假設某個角色，並由協調者為其發行 Grant。

Envelope Encryption 與 Encryption Context

每個與 KMS 整合的 AWS 服務在底層都使用 envelope encryption。身為安全工程師，你必須內化這個模式，因為**「為何解密失敗」的答案幾乎都與 encryption context 有關**。

Envelope encryption 流程

1. 應用程式呼叫 CMK 上的 kms:GenerateDataKey，傳入 encryption context，例如 { "purpose": "audit-log", "tenant": "4271" }。
2. KMS 回傳兩個值：明文 data key（立即使用，使用後丟棄）與加密後的 data key（與 ciphertext 一起儲存）。
3. 應用程式以明文 data key 使用 AES-256-GCM 加密資料，然後丟棄明文 data key。
4. 儲存的 ciphertext = [加密後的 data key | IV | 加密後的 payload | auth tag]。
5. 解密時，應用程式將加密後的 data key 連同相同的 encryption context 傳送給 kms:Decrypt。KMS 驗證 context（以密碼學方式——context 是 AAD），回傳明文 data key，應用程式再解密 payload。

為何 Encryption context 對 SCS-C02 很重要

Encryption context 提供已驗證的附加資料：解密時必須完全符合，否則 KMS 拒絕。這是以密碼學綁定 ciphertext 到邏輯資源（租戶、table、列）的唯一方式。

• AWS 服務自動使用 encryption context——例如 S3 SSE-KMS 使用 { "aws:s3:arn": "arn:aws:s3:::bucket/key" } 作為 encryption context。這意味著複製到不同 bucket 的 ciphertext 無法解密，除非同時使用 kms:ReEncrypt* 或以新 context 重新寫入。
• DynamoDB 使用 { "aws:dynamodb:tableName": "<name>", "aws:dynamodb:subscriberId": "<account>" }。
• 你可以透過 key policy 條件強制自訂 encryption context："StringEquals": { "kms:EncryptionContext:tenant": "${aws:PrincipalTag/tenant}" }。

Encryption context 出現在 CloudTrail 中

每次 KMS API 呼叫都會記錄 encryption context（context 的 key 會被記錄；value 也會記錄，除非你選擇不記錄）。這讓你的偵測控制能在不解析應用程式日誌的情況下，將 KMS 使用與邏輯資源關聯。

各服務加密——S3、RDS、DynamoDB、EBS、EFS、SQS

SCS-C02 不只測試 KMS 抽象概念，還測試各服務的設定旋鈕。陷阱模式是「這個服務的加密只能在建立時設定」——搞錯了，你的遷移計畫就垮了。

Amazon S3——SSE-S3、SSE-KMS、DSSE-KMS、SSE-C

S3 支援四種伺服器端加密模式：

• SSE-S3（2023 年起預設）——AES-256，使用 S3 自有金鑰。無 CloudTrail 金鑰使用可見度。
• SSE-KMS——AES-256，使用 customer-managed 或 AWS-managed CMK；完整 envelope encryption，encryption context 為 aws:s3:arn。
• DSSE-KMS（雙層伺服器端加密，使用 KMS）——對同一物件執行兩次獨立的 KMS 加密操作。某些美國國家安全工作負載（CNSA Suite）需要此模式。費用較高；商業場景罕見。
• SSE-C——客戶提供金鑰；你在每次請求時透過 TLS 傳輸金鑰，S3 使用一次後丟棄。適用於完全無法將金鑰放入 KMS 但又想要伺服器端加密的情況。

大規模使用 SSE-KMS 時，啟用 S3 Bucket Keys：每日產生一個 bucket 層級的 data key，可將 KMS 請求量降低約 99%——對 KMS API 費用是主要成本的高吞吐量 bucket 至關重要。

Amazon RDS 與 Aurora——加密只能在建立時設定

RDS 儲存加密在建立 DB instance 時設定。之後無法切換。要加密現有的未加密 RDS instance：

1. 拍快照。
2. 複製快照時啟用 --kms-key-id，並開啟加密。複製後是一份新的加密快照。
3. 從加密快照還原至新的 instance。
4. 透過 DNS、藍綠部署或邏輯複寫切換流量。

要將停機時間降至最低，請使用 RDS Blue/Green Deployments（MySQL、MariaDB、PostgreSQL）：Green 是加密後的副本，透過邏輯複寫保持同步，一個指令即可升級。

Amazon DynamoDB——預設加密，三種 CMK 選項

DynamoDB 預設對每個 table 進行靜態加密。你可以選擇：

• AWS-owned key（免費，無稽核軌跡）——新 table 的預設值。
• AWS-managed key（aws/dynamodb，免費，無跨帳號）。
• Customer-managed CMK——完整控制、跨帳號、encryption context 為 aws:dynamodb:tableName。

你可以在現有 table 上切換 CMK 類別（DynamoDB 會在背景以新金鑰重寫 item），這與 RDS 只能在建立時設定不同。

Amazon EBS——預設加密

在帳號 + Region 層級啟用 EBS 預設加密（ec2:EnableEbsEncryptionByDefault），這樣所有新 volume 和快照都會以預設 CMK（或你指定的 CMK）加密。現有的未加密 volume 不會溯及既往地加密；對於這些 volume：

1. 建立未加密 volume 的加密快照。
2. 從該快照建立新的加密 volume。
3. 卸載舊的，掛載新的（需要停機）。

對現有 instance 的 root volume 加密，請使用 AMI 加密（copy-image --encrypted --kms-key-id）並重新啟動。

Amazon EFS——加密只能在建立時設定

與 RDS 相同，EFS 檔案系統只有在以 --encrypted 建立時才會靜態加密。無法對現有的 EFS 啟用加密。遷移方式：使用 aws datasync 或 rsync 從未加密的 FS 複製到新的加密 FS。

Amazon SQS——以 CMK 進行伺服器端加密

SQS 支援使用 AWS-managed（aws/sqs）或 customer-managed CMK 的 SSE-KMS。與 S3 不同，SQS 在讀取端自動解密——生產者端只需要 kms:GenerateDataKey，消費者端只需要 kms:Decrypt。

資料保護的資源政策——S3、DynamoDB、KMS

加密保護靜態資料；資源政策保護圍繞它的資料平面。這兩層是互補的——寬鬆的 bucket policy 可以像洩漏明文一樣輕易洩漏加密資料，只要消費者同時擁有 CMK 的存取權。

S3 bucket policy 強化

• Block Public Access（BPA）——在帳號和 bucket 層級設定。會覆蓋任何衝突的 bucket policy 或 ACL。非公開 bucket 一律開啟；SCS-C02 預期你會設定它。
• aws:SecureTransport——當 aws:SecureTransport 為 false 時拒絕 s3:*，強制所有存取使用 TLS。
• s3:x-amz-server-side-encryption——拒絕 s3:PutObject，除非請求指定了 SSE-KMS（或 SSE-S3）並使用預期的演算法。
• s3:x-amz-server-side-encryption-aws-kms-key-id——拒絕 s3:PutObject，除非指名的 CMK 符合預期的 ARN；防止生產者替換成較弱的 CMK。
• aws:SourceVpce 或 aws:SourceVpc——限制存取只能透過特定 VPC endpoint，封鎖經由公開 S3 的資料外洩路徑。

DynamoDB 資源型政策（相對較新）

DynamoDB 現在支援對 table、stream 和 index 設定資源型政策。身為安全工程師，你可以：

• 拒絕來自 OU 外的存取（aws:PrincipalOrgID）。
• 要求 aws:SecureTransport。
• 限制來源 VPC endpoint。

搭配 table 的 customer-managed CMK key policy，你可以獲得縱深防禦——即使工作負載帳號中有過度寬鬆的 IAM policy，也無法外洩 table 內容。

KMS key policy 作為資源政策

KMS key policy 本身就是資源政策——你放在 bucket policy 上的每個條件，都可以鏡像到保護該 bucket 資料的 CMK 上。在信任的 VPC 以外拒絕 kms:Decrypt、沒有特定 encryption context 時拒絕、在高敏感度金鑰的上班時間以外拒絕。

資料完整性控制——雜湊、數位簽章、Object Lock、Vault Lock

機密性是 Domain 5 任務的一半——完整性是另一半。SCS-C02 透過雜湊、數位簽章和不可竄改儲存來測試完整性。

雜湊與數位簽章

• SHA-256 是 S3（x-amz-content-sha256）、CloudTrail 日誌完整性和大多數 AWS 服務的預設完整性雜湊。用於上傳/下載時的物件層級完整性驗證。
• KMS 非對稱金鑰（RSA、ECC）支援 kms:Sign 和 kms:Verify 操作——你可以讓 KMS 簽署 artifact 並驗證簽章，而私鑰永遠不會離開 KMS。使用案例：簽署 CodePipeline artifact、簽署 CloudTrail Lake 查詢、簽署 Lambda 函數程式碼。
• AWS Signer 將 KMS 非對稱簽署包裝給 Lambda、IoT 和容器映像簽署使用——在上面加上了撤銷和金鑰輪換處理。
• CloudTrail 日誌完整性驗證——啟用後，CloudTrail 每小時產生一份以 SHA-256 雜湊簽署的摘要檔案。事件後使用 aws cloudtrail validate-logs 驗證完整性。

S3 Object Lock——compliance vs governance 模式

S3 Object Lock 在固定保留期或無限期的法律保留下，以 WORM（寫一次讀多次）模式儲存物件。

• Compliance mode——任何使用者，包括 root 帳號，都無法在保留期到期前縮短保留或刪除物件。保留期本身一旦設定就無法縮短。設定為 compliance 後，無法切回 governance。SEC 17a-4(f)、FINRA 4511、CFTC 1.31 要求此模式。
• Governance mode——具有 s3:BypassGovernanceRetention 權限的使用者可以縮短保留或刪除。適用於想要預設 WORM 但需要人為錯誤逃生艙的情況。
• Legal hold——獨立於保留期；明確鎖定，刪除前必須移除。

Object Lock 需要啟用 bucket 層級的版本控制。一旦在 bucket 上啟用 Object Lock，就無法停用它。

Glacier（S3 Glacier vault）Vault Lock

對於 S3 Glacier vault（舊版 Glacier API，非 S3 Glacier 儲存類別），Vault Lock 是將 vault 存取政策鎖定到位的機制。一旦鎖定（24 小時的可編輯視窗內），政策就是不可變的——你無法新增例外、移除限制或縮短保留期。適用於 SEC 受監管的存檔、醫療 7 年保留期等。

AWS Backup Vault Lock

AWS Backup Vault Lock 將相同的 WORM 原則套用於 AWS Backup 的 recovery point。兩種模式：

• Compliance mode——一旦鎖定（並在 3 天冷靜期後），任何人都無法縮短最短保留期或在視窗內刪除 recovery point。即使 root 也無法刪除鎖定或 recovery point。這是備份的勒索軟體韌性答案。
• Governance mode——等同於 S3 Object Lock governance。

對於勒索軟體威脅模型，典型答案是：AWS Backup 搭配跨帳號 vault + Vault Lock 的 compliance mode + 隔離的還原帳號。攻擊者入侵生產環境後無法同時入侵備份。

CloudHSM——當 KMS 不夠用時

KMS 能滿足 99% 的加密需求。CloudHSM 存在是為了法規要求或客戶拒絕信任 AWS 操作的 HSM 的窄用途工作負載。

何時是必要而非偏好使用 CloudHSM

• PCI HSM——PIN 翻譯、PIN 區塊加密及其他 PCI HSM 標準操作。KMS 未實作 PCI HSM API 表面。執行卡面授權的收單銀行需要 CloudHSM（或等效的地端 HSM）。
• PKCS #11 / JCE / OpenSSL ENGINE 工作負載——直接使用 PKCS #11 的舊版應用程式。KMS 僅公開 HTTPS API。
• 有文件佐證的唯一保管、單租戶 FIPS 140-3 Level 3——當法規（BSI TR-03145、特定美國 DoD/IC 標準、PSD2 QES）要求客戶為唯一的 HSM 操作者，且 crypto officer 金鑰只由你的員工持有。
• AWS 操作人員不得有任何金鑰存取路徑的主權資料常駐——罕見；通常需要主權雲端區域，但 CloudHSM 有時是折衷方案。
• 密碼學卸載的效能——大量簽署或包裝工作負載，其中每次請求的 KMS 費用或延遲令人無法接受。

CloudHSM 可用性與費用

• 叢集至少需要 2 個 AZ 各 1 台 HSM 才能用於生產；3 個 AZ 各 1 台是最佳實踐。
• 費用約為 每台 HSM 每小時 USD 1.45——2 台 HSM 叢集每月約 USD 2,100，3 台叢集每月約 USD 3,150，不含資料傳輸與營運開銷。
• 叢集是 Regional 的——跨 Region 的 DR 需要第二個叢集和你自己的備份/還原金鑰同步。

CloudHSM 作為 KMS 自訂金鑰存放區

若你希望 CloudHSM 常駐的金鑰能整合支援 KMS 的 AWS 服務（S3、EBS、RDS），請將 CloudHSM 連結為 KMS custom key store。custom key store 中的 CMK 材料實體存放在 CloudHSM，但看起來像普通的 CMK。取捨：KMS 整合服務現在依賴 CloudHSM 的可用性——如果 CloudHSM 無法連線，S3/RDS/EBS 的加密操作就會失敗。

靜態加密的偵測控制

加密是預防性的；偵測控制用來證明加密保持有效。

• AWS Config rules——受管規則 s3-bucket-server-side-encryption-enabled、rds-storage-encrypted、dynamodb-table-encrypted-kms、ebs-encrypted-volumes、efs-encrypted-check。在組織層級的 AWS Config aggregator 中彙總，以獲得全艦隊可見度。
• AWS Security Hub 控制——[S3.4] 確保 S3 bucket 已設定 SSE；[S3.5] 要求 aws:SecureTransport；[KMS.1] 標記具有過度寬鬆 kms:Decrypt 的 IAM principal；[Backup.1] 檢查 Backup Vault Lock。
• Amazon Macie——在 S3 中發現並分類敏感資料（PHI、PCI 持卡人資料、PII），並回報未加密或公開存取的 bucket。
• CloudTrail data events（S3 + Lambda + KMS）——記錄每次物件層級存取和每次 KMS API 呼叫。搭配 Athena 查詢，偵測每個 principal 的異常解密量。
• GuardDuty 發現——Stealth:S3/ServerAccessLoggingDisabled、Policy:S3/BucketBlockPublicAccessDisabled、CredentialAccess:Kubernetes/MaliciousIPCaller（竊取憑證呼叫 KMS）。

真實的 SCS-C02 情境

情境一——集中式稽核日誌 Bucket（跨帳號）

需求：200 個生產帳號將 CloudTrail 日誌寫入 security 帳號的 bucket；只有 security 團隊可以讀取；並需驗證完整性。

• security 帳號中的 customer-managed CMK，key policy 允許生產者 org path 執行 kms:GenerateDataKey*，只有 security 角色可執行 kms:Decrypt。
• security 帳號 bucket 的 bucket policy：aws:SecureTransport=true、s3:x-amz-server-side-encryption=aws:kms 並指定特定 CMK ARN、aws:SourceOrgID 符合組織。
• Object Lock compliance mode，保留期 7 年。
• CloudTrail 日誌完整性驗證已啟用；透過 aws cloudtrail validate-logs 驗證完整性。

情境二——每個租戶一個 CMK 的多租戶 SaaS

需求：SaaS 平台有數千個租戶，每個租戶的資料必須有密碼學隔離。

• 單一共用 CMK；encryption context tenant_id=<id> 透過 key policy 條件強制："StringEquals": { "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/tenant_id}" }。
• 應用程式 principal 在 session 建立時透過 sts:TagSession 以租戶 ID 標記。
• 每個租戶的 KMS Grant 用於臨時計算（Lambda），帶有相同的 encryption context 條件。
• DynamoDB customer-managed CMK 使用相同方案；最敏感欄位使用租戶 context 進行 per-item 屬性層級加密。

情境三——抵抗勒索軟體的備份

需求：勒索軟體攻擊者以 admin 入侵生產帳號；備份必須保持完整。

• AWS Backup 搭配專用隔離帳號中的跨帳號備份 vault。
• Backup Vault Lock 使用 compliance mode，最短保留期 90 天。
• 生產帳號的 IAM 無法存取隔離帳號的 vault；只有 Backup service role 可以扮演進入該帳號。
• 重要 bucket 使用 S3 Object Lock compliance mode。
• 隔離帳號的 customer-managed CMK，key policy 拒絕在帶有硬體 MFA 的緊急存取角色以外執行 kms:ScheduleKeyDeletion 和 kms:DisableKey。

情境四——PCI HSM 遷移至 AWS

需求：執行 PIN 翻譯的收單銀行需要在符合 PCI HSM 規範的情況下遷移至 AWS。

• KMS 不足——PCI HSM 需要 PKCS #11 + 有文件佐證的唯一保管的專用 HSM。
• 佈建 CloudHSM 叢集，3 個 AZ 各 1 台 HSM。
• 應用程式使用 CloudHSM PKCS #11 client SDK（可直接替換地端 HSM）。
• 在 PCI RoC 中記錄 FIPS 140-3 Level 3 認證。
• 仍使用 KMS 整合 AWS 服務（S3、EBS）以儲存靜態的 PCI 持卡人資料，key policy 將解密限縮至特定的計算角色。

SCS-C02 考試模式與干擾選項

• 「加密現有的 RDS instance」→ 快照 → 帶 --kms-key-id 複製 → 還原。絕不是 modify-db-instance --encrypted。
• 「跨帳號 KMS 不運作」→ 同時檢查 key policy 與消費者 IAM；若有使用，記得檢查 encryption context。
• 「即使 root 也不能刪除」→ S3 Object Lock compliance mode 或 Backup Vault Lock compliance mode。
• 「按需密碼學抹除」→ 帶有匯入金鑰材料的 BYOK；從 KMS 刪除材料，所有 ciphertext 立即變廢紙。
• 「AWS 操作人員不得有金鑰存取權」→ 使用你的員工持有 crypto officer 憑證的 CloudHSM。
• 「共用 CMK 上的每租戶隔離」→ encryption context + key policy 條件，限定在 kms:EncryptionContext:tenant_id。
• 「高吞吐量 S3 的 KMS 成本疑慮」→ 啟用 S3 Bucket Keys。
• 「以永遠不離開 AWS 的金鑰簽署 artifact」→ KMS 非對稱金鑰搭配 kms:Sign/kms:Verify。
• 干擾選項模式：「使用 SSE-C 以獲得最高安全性」（不對——每次請求都必須傳輸金鑰）；「使用 AWS-managed key 進行跨帳號」（不可能）；「CloudHSM 自動跨 Region 複寫」（不對，Region 限定）；「Object Lock 可被 root 移除」（只有 governance mode；compliance 不行）。

安全工程師常見錯誤

• 忘記跨帳號 KMS 的 IAM 那一側：key policy 委派給帳號 B，但帳號 B 的角色沒有指名 CMK ARN。AccessDeniedException 指向 KMS 而非 S3——讓第一次除錯的人感到困惑。
• 在生產資料上使用 AWS-managed key：阻斷了未來的跨帳號、未來的 BYOK、未來的停用操作。預設使用 customer-managed CMK。
• 跳過 encryption context：每次不帶 encryption context 的 KMS 呼叫都更難稽核，且無法以 ABAC 綁定。
• 嘗試在 RDS 建立後切換加密：不可能。每次都在建立時規劃加密。
• 混淆 Object Lock governance 與 compliance：governance 可被特權使用者逆轉；compliance 不行。稽核驅動的情境永遠需要 compliance。
• Backup Vault Lock 缺乏跨帳號隔離：如果備份與生產在同一帳號，特權攻擊者可以在冷靜期內停用 AWS Backup、排程金鑰刪除，並抹除還原路徑。跨帳號隔離彌補了這個缺口。
• 反射性選 CloudHSM：KMS 也是 FIPS 140-3 Level 3。只有特定法規才要求 CloudHSM。

FAQ——靜態加密與 KMS 政策

Q1：我何時必須使用 customer-managed CMK 而非 AWS-managed key？

當情境要求以下任一項時：跨帳號存取、multi-Region 複寫、事件時停用、匯入金鑰材料（BYOK）、CloudTrail 稽核每次金鑰使用，或 encryption context 的 key policy 條件。AWS-managed key 無法滿足上述任何一項。對生產資料預設使用 customer-managed CMK。

Q2：KMS Grant 與 key policy 陳述句有何不同？

Key policy 是靜態的，附加在 CMK 上，透過 IaC pipeline 修改。Grant 是程式化的（透過 kms:CreateGrant 發行）、限縮到特定操作及選擇性的 encryption context 條件，且可按需撤銷。Grant 是累加的——無法覆蓋 key policy 中的明確拒絕。對臨時或每個資源的委派使用 grant；對穩定的全艦隊權限使用 key policy。

Q3：什麼是 encryption context，為何 SCS-C02 特別強調它？

Encryption context 是傳遞給 KMS Encrypt/Decrypt 的已驗證附加資料字典。解密時必須完全符合，KMS 以密碼學方式驗證。它會記錄在 CloudTrail 中。SCS-C02 強調它，因為它是以密碼學綁定 ciphertext 到邏輯資源（租戶、table、擁有者）的唯一方式，也是透過 key policy 條件實作 ABAC 式限制 CMK 使用的唯一方式。

Q4：S3 Object Lock compliance 模式與 governance 模式有何差異？

Governance mode 允許具有 s3:BypassGovernanceRetention 權限的使用者縮短保留或刪除物件——這是軟性的 WORM。Compliance mode 不允許任何人，包括 root 帳號，在保留期內縮短保留或刪除——真正的 WORM。SEC 17a-4(f)、FINRA、CFTC 要求 compliance；一旦設定，就無法將該物件版本逆轉回 governance。

Q5：何時需要 AWS CloudHSM 而非 AWS KMS？

當工作負載必須呼叫 KMS 未實作的 PKCS #11 / PCI HSM API、法規（BSI、PSD2 QES、某些 DoD/IC 標準）要求客戶唯一保管具有文件記錄的 FIPS 140-3 Level 3 單租戶操作的 HSM，或主權規則禁止 AWS 操作人員有任何金鑰材料存取路徑時。對於「一般高安全性」或靜態的例行 PCI-DSS，KMS 就足夠了，且其本身也是 FIPS 140-3 Level 3。

Q6：如何以最短停機時間加密現有的未加密 RDS 資料庫？

無法在現有 instance 上切換加密。拍快照，啟用加密並帶 --kms-key-id 複製快照，從加密快照還原至新的 instance，然後切換。最短停機時間請使用 RDS Blue/Green Deployment 功能（MySQL、MariaDB、PostgreSQL）：加密後的 Green 透過邏輯複寫保持同步，一個升級指令即可切換。

Q7：如何使備份對在生產環境擁有 admin 的勒索軟體攻擊者具有韌性？

使用 AWS Backup 搭配專用隔離帳號中的跨帳號備份 vault，以最短保留期啟用 compliance mode 的 Backup Vault Lock，並確保生產帳號沒有 IAM 路徑可到達隔離 vault——只有 Backup service role 可以扮演進入該帳號。結合重要 bucket 的 S3 Object Lock compliance mode，以及隔離帳號中 key policy 在緊急存取角色以外拒絕 kms:ScheduleKeyDeletion 的 customer-managed CMK。

Q8：強制所有 S3 bucket 存取使用 TLS 的正確方式是什麼？

在 bucket policy 中新增一個拒絕陳述句，當 aws:SecureTransport 為 false 時拒絕所有 s3:* 操作。搭配帳號和 bucket 層級的 Block Public Access，以及額外拒絕 s3:PutObject（除非 s3:x-amz-server-side-encryption 符合帶有預期 CMK ARN 的 aws:kms）。偵測控制：AWS Config rule s3-bucket-ssl-requests-only。

總結

靜態加密與 KMS 政策不是一個核取方塊——而是一套架構。身為備考 SCS-C02 的安全工程師，請內化：

• 預設使用 customer-managed CMK；只有在完全沒有跨帳號、停用需求、BYOK 和稽核要求時，才使用 AWS-managed key。
• Key policy 是強制的；IAM 是補充的；encryption context 是密碼學 ABAC 層；Grant 是動態的、可撤銷的、有範圍的委派。
• 各服務加密陷阱：RDS、Aurora、EBS、EFS、Redshift 只能在建立時設定；DynamoDB 和 S3 可以就地切換 CMK。
• 資源政策與 CMK 層疊：Block Public Access、aws:SecureTransport、bucket 上的加密要求陳述句；DynamoDB 的資源型政策；KMS 上的 key policy 條件。
• 不可竄改儲存以符合合規：S3 Object Lock compliance mode、Glacier Vault Lock、Backup Vault Lock——唯一抵抗 IAM 的原語。
• CloudHSM 只在法規禁止 AWS 操作的 HSM 時使用；其他情況使用 KMS。
• 偵測控制（Config、Security Hub、Macie、CloudTrail data events）證明你的預防性設計持續有效。

掌握靜態加密與 KMS 政策，帶著對 Domain 5 以及 Domain 2、3 相當大部分的信心走進考場。