資料保護：KMS、ACM、Secrets Manager 與安全發現

AWS 資料保護是 SysOps 工程師維持資料機密性、完整性與可用性的所有日常任務的總稱——管理 KMS 金鑰、透過 ACM 更新 TLS 憑證、在 Secrets Manager 輪換密鑰，以及從 GuardDuty、Security Hub 和 Inspector 分類安全 findings。SOA-C02 Task Statement 4.2「實作資料與基礎設施保護策略」是本主題的核心，而考試的切入角度明確是運維層面：不是「要設計哪種加密策略」，而是「如何操作已存在的金鑰、憑證、密鑰和 findings 流水線」。SAA-C03 問「應該用 SSE-S3 還是 SSE-KMS？」；SOA-C02 問「昨晚 ACM 憑證自動更新失敗，你第一步看什麼？」——答案涉及 DNS 驗證記錄、alternate names、更新視窗和 CloudWatch Events。

本指南從 SysOps 角度走過 AWS 資料保護全流程。你將看到 KMS customer managed keys 如何建立、自動輪換如何運作（以及它不做什麼）、grants 為何和 key policies 並存、envelope encryption 如何讓每物件 data key 保持高效、如何在 S3、EBS、RDS 和 EFS 上啟用靜態加密而無需重建基礎設施、ACM 憑證如何在到期前 60 天自動更新及更新失敗時的排查步驟、Secrets Manager 與 Parameter Store SecureString 的差異、RDS 憑證的輪換 Lambda 機制，以及透過 Security Hub 彙整後 GuardDuty 和 Inspector findings 的標準補救流程。每個段落最後都附上反覆出現的 SOA-C02 場景模式，將冗長的學習清單化為少數幾種重複出現的考題結構。

為什麼資料保護是 SOA-C02 Domain 4.2 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 4.2 下列出六項技能：執行資料分類方案、建立並保護加密金鑰、使用 KMS 實作靜態加密、使用 ACM 和 VPN 實作傳輸中加密、使用 Secrets Manager 和 Parameter Store 安全儲存密鑰，以及審查 Security Hub、GuardDuty、Config 和 Inspector 的報告或 findings。清單中的每項技能都是運維動詞——「建立」、「實作」、「安全儲存」、「審查」——因此每道資料保護題都有「你要按哪個按鈕、執行哪道命令、翻動哪個開關」的答案。

在 SysOps 層級，資料保護的視角是動手操作。SysOps 工程師是那個在客戶觸發重新加密時輪換 KMS key alias 的人、在自動更新失敗被抓到後將新 ACM 憑證掛到 ALB 的人、把 Secrets Manager 密鑰從手動切換到自動輪換的人，以及凌晨三點收到 GuardDuty UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding 的人。因為資料保護貫穿每個 domain——Domain 5 的 VPC 傳輸中加密、Domain 2 的備份加密金鑰、Domain 1 的 CloudTrail trail 加密、Domain 1 的 Config Rule 未加密資源補救——資料保護主題是讓 SOA-C02 其餘部分融會貫通的結締組織。

白話文解釋 Data Protection on AWS

資料保護術語堆疊很快——keys、grants、envelope encryption、驗證記錄、輪換 Lambdas。三個類比能讓這些概念變得具體好記。

類比一：公司門禁鑰匙階層

KMS 是公司門禁鑰匙階層。AWS-owned key 是物業管理的萬能鑰匙——你永遠看不到它，AWS 用它來加密建築物不可見的後台管線，你無法直接操作它。AWS-managed key 是樓層主管的備用鑰匙——AWS 建立它並以你帳號的服務命名（aws/s3），鑰匙放在你那層的鑰匙櫃裡，服務每年自動換一把新的。Customer-managed key（CMK） 是你自己去鎖匠配的鑰匙——你決定誰在准入名單（key policy），你決定是否啟用年度自動輪換，你每個月付一塊美元持有它。Grants 是前台臨時發放的訪客通行證——範圍受限、自動到期、比改寫 key policy 更容易撤銷。Envelope encryption 是你儲物格裡的雙重保險箱：內層保險箱（data key）速度快、負責解鎖文件，但保險箱本身被主要 CMK 鎖住，就算小偷偷走了內層保險箱，沒有主鑰匙也打不開。

類比二：郵局掛號信驗證系統

ACM 和傳輸中 TLS 是郵局掛號信驗證系統。公開 ACM 憑證是掛號信的郵戳章，向任何人證明寄件人就是他們聲稱的那個人——因為郵局（公開 CA）蓋了章，任何人都能驗證。DNS validation 是在公開戶籍資料登記你的地址，讓郵局在蓋章前確認你真的住在那裡。私有 CA（ACM Private CA）是公司內部的文書室——發行的章只有你自家建築認得，適合那些絕對不應該被公開網路存取的內部服務。到期前 60 天自動更新是郵局的定期提醒信，提早提醒你去換章，但提醒只有在你的戶籍地址還在公開登記時才有效——如果你在第一次發章後就把 DNS 驗證記錄刪掉了，自動更新會靜悄悄地失敗，最後章過期作廢。

類比三：醫院住院手環與病歷系統

Security Hub、GuardDuty 和 Inspector 是醫院住院手環與病歷系統。GuardDuty 是床邊生命徵象監視器，持續監看每位病患（帳號），一旦有異常就發出警示——心律不整（網路異常）、突然發燒（可疑 DNS 查詢）、陌生訪客（未授權存取）。Amazon Inspector 是定期健康篩檢，掃遍每位現有病患並標記潛在舊疾——軟體弱點、暴露的網路路徑、容器映像 CVE——即使病患目前沒有症狀也照樣找出來。Security Hub 是中央護理站，彙整每台監視器和每份篩檢報告的所有警示，統一正規化為同一格式（ASFF），並依嚴重程度排序，讓值班醫師能按優先順序分類處理。Findings workflow status（NEW → NOTIFIED → SUPPRESSED → RESOLVED）是護理人員隨案件進度更新的手環顏色。

資料分類：運維層面的基礎提醒

在金鑰和憑證有意義之前，SysOps 工程師需要知道哪些資料正在被保護。AWS 不強制規定分類方案——你的組織才做決定——但 SOA-C02 Exam Guide 明確將「執行資料分類方案」列為技能，因此運維任務必須清晰可見。

實務上的分類層級

多數組織使用三到四個資料保護層級：

• 公開（Public） — 行銷頁面、公開文件、開放資料集。沒有加密要求，但傳輸中 TLS 仍是基本衛生標準。
• 內部（Internal） — 操作日誌、內部儀表板、非敏感 metrics。靜態加密使用 AWS-managed keys；傳輸中 TLS 使用 ACM 公開憑證。
• 機密（Confidential） — 客戶個資、員工記錄、廠商合約。靜態加密使用 customer-managed KMS keys；傳輸中 TLS；憑證使用 Secrets Manager。
• 限制（Restricted） — 支付卡資料、健康記錄、認證密鑰。Customer-managed KMS keys 加上嚴格 key policies、自動輪換、每次金鑰使用的 CloudTrail 記錄，以及每個工作負載的專屬 grants。

運維標籤

為每個資源加上 DataClassification 標籤（Public、Internal、Confidential、Restricted）。AWS Config rules 接著強制執行：

• Confidential 和 Restricted 資源必須啟用靜態加密。
• Restricted 資源必須使用 customer-managed KMS keys（而非 AWS-managed）。
• Restricted 資源不得位於可公開存取的子網路。

這是 AWS 資料保護的運維骨幹——分類決定加密選擇，加密選擇決定金鑰管理工作，而金鑰管理工作才是 SOA-C02 真正考的內容。

KMS Customer Managed Keys：類型、建立與運維任務

KMS 資料保護模型以三種金鑰類型和清楚的所有權分工為基礎。

KMS key 類型比較表

建立 customer-managed key

Customer-managed key 可透過主控台、CLI 或 CloudFormation 建立。運維檢查點：

• Key spec：對稱（AES-256）是預設值，涵蓋 95% 的資料保護需求。非對稱 KMS keys（RSA、ECC）用於數位簽章和非對稱加密使用案例——在 SOA-C02 運維題中罕見。
• Key usage：ENCRYPT_DECRYPT 用於資料加密、SIGN_VERIFY 用於非對稱簽章、GENERATE_VERIFY_MAC 用於 HMAC。
• Key policy：附加於金鑰的資源政策。至少必須包含帳號 root 主體，以及被授權管理或使用金鑰的特定主體。
• Alias：如 alias/prod-rds-data-protection 的友善名稱，抽象化底層金鑰 ID。Aliases 可以重新指向新金鑰而不需要更改應用程式程式碼——這是重新加密（re-keying）的運維槓桿。
• 標籤：至少加上 DataClassification、Environment、Owner，用於成本分配和稽核。

Key policies 與 IAM policies

KMS 同時使用兩者。Key policy 是 KMS key 上的資源政策；IAM policy 是使用者或角色上的身分政策。主體要使用 KMS key，必須：

• Key policy 允許存取（或透過標準「Enable IAM User Permissions」陳述句委派給 IAM）。
• 且 IAM policy 允許該動作（如果 key policy 委派的話）。

這比其他 AWS 服務更嚴格。單靠 IAM policy 不夠，除非 key policy 明確委派給 IAM。SOA-C02 常考這個陷阱：擁有 kms:* IAM 權限的管理員，如果 key policy 沒有委派給 IAM，仍然無法使用金鑰。

Grants：彈性的替代方案

Grant 是附加於 KMS key 的程式化權限，針對特定主體和特定一組操作，不需修改 key policy。Grants：

• 透過 CreateGrant API 建立，以 grant ID 和 grant token 識別。
• 指定被授權主體、允許的操作（Encrypt、Decrypt、GenerateDataKey 等）以及可選的限制條件（encryption context）。
• 最終一致性——建立時回傳的 grant token 可立即使用，不需等待 grant 完全傳播。
• 可由被授權方或授權方終止（retire），或由授權方單方面撤銷（revoke）。
• 是 AWS 推薦的短期程式化存取模式——例如需要暫時存取 CMK 以加密磁碟的 EBS volume 建立操作。

KMS Key 輪換：自動、手動，以及它不做的事

Key 輪換是 SOA-C02 上測試最多的 KMS 運維主題，也是最常被誤解的。

Customer-managed keys 的自動輪換

當你為 customer-managed 對稱金鑰啟用自動輪換時，KMS 每 365 天輪換一次底層金鑰素材（backing key material）。輪換後：

• 金鑰 ID 保持不變。
• Alias 保持不變。
• 舊的底層金鑰素材被保留，使現有密文仍可解密。
• 新的加密操作使用新的金鑰素材；新密文帶有內部金鑰版本識別碼。
• KMS 在解密時透明地處理版本選擇——應用程式感受不到輪換。

自動輪換不做的事：

• 它不重新加密現有資料。舊密文保持原樣，使用保留的舊金鑰素材仍可解密。
• 它不輪換金鑰 ID、ARN 或 alias。
• 它不適用於非對稱金鑰或匯入的金鑰素材——這些必須手動輪換。

透過 aliases 手動輪換

對於非對稱金鑰、匯入的金鑰素材，或組織政策要求全新 ARN 的情況，手動輪換模式如下：

1. 使用相同 key spec 建立新的 KMS key。
2. 更新 alias（alias/prod-rds-data-protection）指向新金鑰。
3. 新的加密操作使用新金鑰；現有密文繼續對著舊金鑰（仍啟用，只是不再是 alias 目標）解密。
4. 選擇性地透過 alias（現已指向新金鑰）讀取再寫入來重新加密現有資料——這是實際淘汰舊金鑰素材的唯一方法。
5. 確認重新加密完成後，排程刪除舊金鑰。

AWS-managed keys 的金鑰輪換

AWS-managed keys（aws/s3、aws/ebs、aws/rds）每年由 AWS 自動輪換，你無法停用。AWS-managed keys 的輪換時間點不是考試重點；只需知道它是自動進行的。

KMS key 刪除：7 到 30 天等待期

當你排程刪除 customer-managed key 時，KMS 強制執行 7 到 30 天（預設 30 天）的強制等待期。等待期間：

• 金鑰處於 PendingDeletion 狀態。
• 金鑰上的所有加密和解密操作均會失敗——應用程式無法使用它。
• 你可以在視窗期間隨時取消刪除並恢復金鑰。
• 等待期結束後，金鑰連同其所有金鑰素材被不可逆地刪除；以它加密的資料永久無法復原。

等待期的存在正是因為刪除 KMS key 會永久斷絕所有用它加密的資料的存取。這是 AWS 資料保護中後果最嚴重的單一操作，SOA-C02 要你記住 7 到 30 天的視窗。

Envelope Encryption：AWS 服務如何使用 KMS 而不拖慢速度

對每個位元組的資料呼叫 KMS 會慢得難以接受，費用也高得驚人。AWS 以 envelope encryption 解決這個問題：資料本身用每物件的 data key（快速對稱加密）加密，data key 本身再用 KMS customer master key 加密（一次小型 KMS API 呼叫）。

Envelope encryption 逐步運作流程

S3（或 EBS、RDS、EFS）使用 SSE-KMS 加密物件時的流程：

1. 服務每個物件（或每個區塊）呼叫一次 kms:GenerateDataKey。
2. KMS 回傳兩個東西：一個明文 data key（256-bit AES 金鑰）和一個加密的 data key（同一把金鑰用你的 CMK 加密後的版本）。
3. 服務使用明文 data key 在本地以 AES-256 加密物件。
4. 服務將加密的 data key 連同物件一起儲存（放在 S3 物件中繼資料、EBS volume 中繼資料等）。
5. 服務立即從記憶體中清除明文 data key。

解密時：

1. 服務從物件中繼資料讀取加密的 data key。
2. 服務對加密的 data key 呼叫 kms:Decrypt，取得明文 data key。
3. 服務使用明文 data key 解密物件。

這表示每個物件只需一次 KMS API 呼叫（而非每個位元組）。對於高請求率的 S3 bucket，bucket 可以使用 S3 Bucket Keys 將 KMS 呼叫分攤到多個物件——以一個 data key 涵蓋整個 bucket-key 時間切片，而非每個物件各用一個。這能大幅降低 KMS API 成本。

Encryption context

每次 KMS 加密呼叫都可以包含 encryption context——一個鍵值對 map，記錄於 CloudTrail，且在解密時必須提供。Context 不加密；它以額外認證資料（AAD）的形式綁定於密文。SOA-C02 常見用法：

• AWS 服務自動附加如 aws:s3:arn（S3 物件）或 aws:ebs:id（EBS volume）等 context。
• 自訂應用程式可要求自己的 context（tenant_id、purpose），使從一個租戶洩漏的密文無法在另一個租戶的 context 下解密。

靜態加密：各 AWS 服務啟用方式

靜態加密是儲存資料的資料保護基礎。SOA-C02 考的是如何對每個服務啟用、驗證和排查加密。

S3 — 三種加密模式

• SSE-S3 — S3 管理的金鑰，AES-256，免費。2023 年起新 bucket 預設啟用。
• SSE-KMS — KMS 管理的金鑰（AWS-managed aws/s3 或你的 CMK）。為每次物件存取新增 CloudTrail 記錄。每次 KMS API 呼叫計費（使用 Bucket Keys 分攤費用）。
• SSE-C — 客戶在每次請求中提供金鑰，AWS 不儲存金鑰。在 SOA-C02 上罕見，因為金鑰管理在 AWS 之外。

在 bucket 層級啟用預設加密，讓每次 PUT 都繼承所選模式，不需要每次請求都帶標頭。用 aws s3api get-bucket-encryption 驗證。使用 AWS Config 托管規則 s3-bucket-server-side-encryption-enabled 進行持續合規檢查。

EBS — 加密為每個 volume 設定，在建立時決定

EBS volumes 在建立時使用 AWS-managed aws/ebs key 或 customer-managed key 進行加密。一旦建立，未加密的 volume 無法就地啟用加密——你必須製作快照、在啟用加密的情況下複製快照，再從加密快照建立新 volume。運維槓桿：

• 帳號層級預設加密：EnableEbsEncryptionByDefault，讓每個新 volume 自動加密。
• 跨帳號快照共用：共用加密快照需要目標帳號透過你的 CMK 上的 key policy 或 grant 擁有 kms:Decrypt 權限。
• AMI 共用：加密 AMI 的共用遵循相同的 KMS 權限模型。

RDS — 透明加密，在 instance 建立時設定

RDS 加密在 DB instance 建立時設定。一旦 instance 在沒有加密的情況下建立，就無法就地啟用——運維遷移步驟是：製作快照、在啟用加密的情況下複製快照、從快照還原為新的加密 instance。這是 SOA-C02 最愛的場景，因為遷移涉及短暫停機和 CNAME 切換。

EFS — 靜態加密與傳輸中加密

EFS 靜態加密使用 KMS（必須），並透過 EFS mount helper 支援傳輸中 TLS 加密。兩者都必須在檔案系統建立時啟用。EFS 傳輸中加密需要 efs-utils mount helper，而非標準 NFS 客戶端。

傳輸中加密：ACM 憑證佈建與更新

ACM 是為 ALB、NLB、CloudFront、API Gateway、AppSync 及整合服務發行、部署和更新 TLS/SSL 憑證的 AWS 服務。資料保護使用案例是 HTTPS 終止——確保客戶端和 AWS edge 之間的傳輸中資料已加密。

公開憑證佈建

請求公開 ACM 憑證的步驟：

1. 提交網域名稱（一個或多個，包括萬用字元如 *.example.com）。
2. 選擇驗證方式——DNS validation（建議）或email validation（舊版）。
3. 使用 DNS validation 時，ACM 為每個網域提供一筆 CNAME 記錄，你需要發布到授權 DNS。ACM 偵測到 CNAME 後即發行憑證（通常在幾分鐘內）。
4. 將憑證掛到 ALB、NLB、CloudFront 或 API Gateway。

公開 ACM 憑證免費，AWS 負責發行、部署和自動更新。

ACM 自動更新：60 天視窗

ACM 在憑證到期前 60 天開始自動更新。自動更新流程：

1. ACM 確認驗證方式仍然有效——對於 DNS validation，CNAME 記錄必須仍存在於授權 DNS 中。
2. 若有效，ACM 發行新憑證，並在不中斷的情況下靜靜地替換掛載資源（ALB、CloudFront 等）上的舊憑證。
3. CloudWatch Events / EventBridge 為更新結果發出事件——無論成功或失敗。

自動更新失敗的常見原因：

• 首次發行後 DNS validation CNAME 被刪除（最常見原因）。
• 憑證的 alternate names 有 CNAME 記錄從未被新增。
• 憑證長期未掛載到任何 AWS 服務——ACM 最終會停止更新未使用的憑證。
• 對於 email validation，網域 WHOIS 聯絡人過期或無法聯繫。

更新失敗的解法幾乎都是補回遺失的 DNS validation CNAME 並觸發重新發行。SOA-C02 要求你知道 60 天更新視窗以及 DNS CNAME 記錄的作用。

私有 CA 憑證

對於不應從公開網路存取的內部服務，AWS Private Certificate Authority（Private CA） 從你在 AWS 內部運營的 CA 發行憑證。Private CA 憑證不免費（CA 本身有每月費用和每張憑證費用）。適用場景：

• 服務僅限內部使用，且必須信任企業 CA。
• 合規要求憑證來自受控的 CA 鏈。
• Mutual TLS（mTLS）認證使用從你的 CA 發行的客戶端憑證。

Private CA 憑證若由 ACM Private CA 整合管理也可自動更新，但運維模型略有不同——CA 本身必須處於啟用狀態，且更新權限政策必須就位。

監控憑證到期

即使有自動更新，你也應該對即將到期的憑證設 alarm，作為縱深防禦：

• ACM 為每張憑證發出 CloudWatch metric DaysToExpiry。
• 在剩餘 45 天和 30 天時建立 CloudWatch alarm——如果看到這些 alarm 觸發，自動更新就是失敗了，你有 bug 需要修。
• 將 alarm 連接到 SNS，通知 SysOps on-call。

SysOps 團隊以 DNS validation 請求 ACM 憑證，ACM 發行後，團隊將憑證掛到 ALB，接著有人在 Route 53 整理過程中「清理」了驗證 CNAME 記錄，因為憑證已經發行了。到期前 60 天，ACM 嘗試透過同一個 CNAME 重新驗證，發現它不見了，於是靜悄悄地更新失敗。憑證到期，ALB 提供過期憑證，客戶看到瀏覽器警告。解法是永遠不要刪除 DNS validation CNAME，並對 DaysToExpiry CloudWatch metric 設 alarm 作為縱深防禦。參考：https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html ::

Secrets Manager：儲存憑證並自動輪換

Secrets Manager 是 AWS 用來儲存憑證、API keys 和 OAuth tokens 的資料保護服務——任何敏感、有結構、且可能需要輪換的東西。

密鑰結構與 KMS 加密

Secrets Manager secret 儲存一個 JSON 物件（{"username":"db_user","password":"..."}）和一份版本清單。每個版本有唯一的版本 ID 和一份暫存標籤清單（AWSCURRENT、AWSPENDING、AWSPREVIOUS）。密鑰靜態加密使用 KMS key——預設為 aws/secretsmanager（Secrets Manager 的 AWS-managed key），或使用 customer-managed key 以滿足更嚴格的資料保護需求。

在應用程式中讀取密鑰

應用程式以密鑰 ID 呼叫 secretsmanager:GetSecretValue，AWS 回傳當前版本。最佳實務：

• 使用 IAM 角色存取（instance profile、Lambda execution role）。
• 將密鑰快取於記憶體中並設定短 TTL，以減少 API 呼叫。
• 對於 RDS，使用 AWS SDK 的 RDS-Secrets Manager 整合，當密鑰輪換時自動刷新憑證。

透過 Lambda 自動輪換

Secrets Manager 支援透過按排程呼叫 Lambda 函數進行自動輪換。輪換視窗可設定為 1 到 365 天。AWS 提供預建的輪換 Lambda 範本，適用於：

• RDS MySQL、PostgreSQL、MariaDB、Oracle、SQL Server。
• Amazon DocumentDB。
• Amazon Redshift。

四階段輪換 Lambda 流程：

1. createSecret — 產生新密碼，以 AWSPENDING 版本儲存於 secret 中。
2. setSecret — 用新密碼更新資料庫（對生產系統的實際變更）。
3. testSecret — 以 AWSPENDING 嘗試連線，驗證新密碼有效。
4. finishSecret — 將 AWSPENDING 升級為 AWSCURRENT，將舊的 AWSCURRENT 降級為 AWSPREVIOUS。

對於非 RDS 的密鑰（第三方 API、SSH keys），你撰寫一個遵循相同四階段合約的自訂輪換 Lambda。

常見輪換 Lambda 失敗原因

• 網路路徑缺失：Lambda 必須同時能到達密鑰（Secrets Manager VPC endpoint 或公開 NAT 路徑）和資料庫（Lambda ENI 的安全群組 ingress）。最常見的單一失敗原因是 Lambda 子網路到 RDS instance 的安全群組存取缺失。
• IAM 權限缺失：Lambda execution role 需要 secretsmanager:GetSecretValue、secretsmanager:PutSecretValue、secretsmanager:UpdateSecretVersionStage，以及相關的資料庫修改權限。
• 輪換逾時：Lambda 必須在執行逾時內完成所有四個階段。對於大型資料庫或慢速網路，將 Lambda 逾時增加到 5 分鐘。
• 跨帳號密鑰：跨帳號的 Secrets Manager 輪換需要密鑰上的資源政策，允許輪換主體執行操作。

Parameter Store SecureString vs Secrets Manager：何時使用哪個

兩個服務都提供敏感值的加密儲存。資料保護決策矩陣：

SOA-C02 乾淨的判斷規則：

• 使用 Parameter Store SecureString：用於不需輪換的敏感設定（API endpoint、加密鹽值、授權金鑰），Secrets Manager 的 $0.40/月/密鑰費用超出所需。
• 使用 Secrets Manager：當密鑰需要排程自動輪換、當它是資料庫憑證，或當值超過 4 KB 時。

審查 Findings：Security Hub、GuardDuty、Inspector

資料保護運維循環以審查 findings 作為收尾——來自安全服務的主動偵測，揭露你的加密、存取或弱點姿態的缺口。

GuardDuty：持續威脅偵測

GuardDuty 分析 VPC Flow Logs、DNS 查詢日誌和 CloudTrail 事件日誌，以偵測異常行為：

• 偵察 findings（Recon:EC2/Portscan）——從外部或內部進行連接埠掃描。
• 後門 findings（Backdoor:EC2/C&CActivity.B!DNS）——instance 與已知 C2 網域通訊。
• 加密貨幣挖礦（CryptoCurrency:EC2/BitcoinTool.B）——對挖礦池的 DNS 查詢。
• 未授權存取（UnauthorizedAccess:EC2/MaliciousIPCaller.Custom）——從威脅情報標記的 IP 登入。

GuardDuty 按 region 和帳號啟用。AWS Organizations 支援讓委派管理員在每個成員帳號啟用 GuardDuty。Findings 有嚴重程度（低/中/高）和 finding ID；CloudTrail 來源的 findings 包含主體 ID。

Amazon Inspector：弱點掃描

Inspector 掃描以下資源的軟體弱點和非預期網路暴露：

• EC2 instances — 套件、核心 CVE。
• ECR 容器映像 — 基礎映像弱點、套件 CVE。
• Lambda functions — 函數程式碼依賴關係。

Inspector 預設為持續掃描——當 EC2 instance 以 SSM agent 執行啟動時，Inspector 自動接管；當 ECR 映像被推送時，Inspector 掃描它。Findings 帶有 CVSS 分數和修復建議。

Security Hub：彙整與 ASFF

Security Hub 是中央彙整層。它從 GuardDuty、Inspector、Macie、Firewall Manager、IAM Access Analyzer、AWS Config 及第三方合作夥伴拉取 findings，將所有內容正規化為 AWS Security Finding Format（ASFF），並呈現：

• Findings 清單，帶嚴重程度、workflow status、region、帳號。
• Insights — 儲存的查詢（例如「生產環境中所有嚴重 findings」）。
• Standards & Controls — 預建的合規套件（CIS AWS Foundations、AWS Foundational Security Best Practices、PCI-DSS）。
• Workflow status 轉換：NEW → NOTIFIED → SUPPRESSED → RESOLVED。

Security Hub finding workflow 是 SOA-C02 的考點：

• 新 finding 到達；SysOps 團隊確認（NOTIFIED）。
• 補救後，團隊標記 RESOLVED。
• 對於已接受風險的誤報，團隊標記 SUPPRESSED，使其不再觸發警示。

將 findings 連接到自動化補救

SOA-C02 標準補救流水線：

1. GuardDuty / Inspector / Security Hub finding 產生。
2. EventBridge 規則在 aws.securityhub 或 aws.guardduty 事件來源上比對 finding 模式。
3. EventBridge 目標——Lambda 函數或 Systems Manager Automation runbook。
4. 補救動作：隔離 EC2（安全群組隔離）、撤銷 IAM session、製作快照以供鑑識、呼叫 on-call。

場景模式：ACM 憑證無法自動更新

SOA-C02 標準排查模式。操作手冊：

1. 確認驗證方式。 ACM 主控台 → Certificates → 選擇憑證 → 「Domains」分頁。若驗證方式為 DNS，每個網域必須有有效的 CNAME 驗證記錄目前存在於 DNS 中。
2. 檢查每個網域的驗證狀態。 尋找「Pending validation」或「Failed」。整張憑證只有在每個網域都通過驗證後才更新。
3. 在 Route 53（或外部 DNS）中驗證 CNAME 記錄。 ACM 的驗證 CNAME 有特定的名稱和值——兩者都必須存在並能從公開網路解析。
4. 確認憑證是否掛載到某個服務。 ACM 不會積極更新未掛載到任何 AWS 服務的憑證。將憑證掛到 ALB、NLB、CloudFront 或 API Gateway 可重新啟用更新。
5. 在 CloudWatch Events 中查看更新事件。 EventBridge aws.acm 事件，detail-type 為 ACM Certificate Approaching Expiration 或 ACM Certificate Renewal Failure，顯示精確的失敗原因。
6. 對於 email validation，確認網域管理員聯絡 email 可聯繫；如果無法，改用 DNS validation 重新發行。

解法幾乎都是補回遺失的 DNS validation CNAME。CNAME 補回後，ACM 在下次嘗試時恢復自動更新（通常在幾小時內）。

場景模式：GuardDuty 回報可疑的 EC2 對外流量

另一個 SOA-C02 典型模式。GuardDuty 對 instance i-0abc123 觸發 Backdoor:EC2/C&CActivity.B!DNS。資料保護補救操作手冊：

1. 優先隔離。 將 instance 移入隔離安全群組，拒絕所有輸入和輸出，除了 SSM endpoint（讓調查人員仍能透過 Session Manager 存取）。不要立即終止——你需要鑑識資料。
2. 製作 EBS volumes 快照，供離線鑑識分析。
3. 停用 instance 的 IAM instance profile，撤銷任何已從 instance 洩漏的憑證。
4. 標記 instance Investigation=true，並連結到 GuardDuty finding ID。
5. 透過 EventBridge → Security Hub finding 流水線連接的 SNS topic 通知 on-call。
6. 保存 CloudTrail 和 VPC Flow Logs，針對受影響的時間視窗——它們通常已透過生命週期規則儲存在 S3，但要在清理前確認。
7. 調查完成後——從已知乾淨的 AMI 重建，輪換任何可能已暴露的憑證，將 GuardDuty Security Hub finding workflow status 更新為 RESOLVED。

成熟的 SysOps 團隊會透過 EventBridge → Lambda 或 Systems Manager Automation runbook 將整個操作手冊自動化，讓第一步（隔離）即時完成，其餘步驟半自動化，on-call 同步收到通知。

常見陷阱：KMS Multi-Region Keys

Multi-Region KMS key 在各 regions 具有相同的金鑰 ID 和相同的金鑰素材，因此在一個 region 加密的密文可以在另一個 region 解密。陷阱：

• Multi-Region keys 不是預設值——你必須明確地以 multi-Region 方式建立 primary key，再在目標 regions 建立 replica keys。標準 KMS keys 是單一 region。
• 每個 replica 有自己的 key policy——在一個 region 授予權限不代表在另一個 region 也有權限。資料保護管理員必須同步各 region 的 policies。
• Multi-Region keys 不自動複製到新 region——新增 region 需要建立新的 replica。
• Multi-Region keys 適用於資料被複製（S3 CRR、DynamoDB global tables）且必須在復原 region 仍可解密的跨 region 災難復原場景。它們不能取代跨帳號存取模式。

常見陷阱：KMS 刪除永久清除資料

當 customer-managed key 被刪除後，所有用該金鑰加密的密文都永久無法復原。7 到 30 天的等待期是安全網，而非保障——一旦等待期過去，金鑰素材就被不可逆地銷毀。運維實務：

• 每次刪除請求都預設使用 30 天，絕不用 7 天。
• 先停用金鑰至少一週，再排程刪除。停用的金鑰會讓所有加密/解密呼叫失敗，因此任何仍在使用它的應用程式會立即浮現依賴關係。
• 稽核 CloudTrail 查找停用期間對該金鑰的任何 kms:Decrypt 呼叫。若有任何使用，不要繼續刪除。
• 對於任何資料保護關鍵金鑰（RDS 加密、S3 CRR 目標），在排程刪除前需要第二位工程師的審核。

常見陷阱：ACM 憑證以 Email 方式更新

Email validation 是 ACM 的舊版驗證方式。它向一小組 WHOIS 衍生地址（admin@、administrator@、hostmaster@、webmaster@、postmaster@ 加上 WHOIS 聯絡人）發送驗證 email。透過 email validation 自動更新很脆弱，因為：

• Email 聯絡人過時——原本的 webmaster@ 信箱不再路由到任何地方。
• WHOIS 記錄被隱私服務遮蔽，中斷更新 email 路徑。
• 更新 email 容易被誤認為垃圾郵件或釣魚郵件。

SOA-C02 對任何新公開憑證的正確答案是 DNS validation。對於現有的 email 驗證憑證，遷移方式是在下一個更新週期前以 DNS validation 重新發行憑證。

常見陷阱：Secrets Manager 輪換 Lambda 靜悄悄失敗

輪換失敗不會通知任何人，除非你明確連接通知。運維強化：

• 為密鑰設定輪換排程，並在輪換 Lambda 的 Errors metric 上建立 CloudWatch alarm。
• 將 alarm 訂閱到呼叫資料保護 on-call 的 SNS topic。
• 建立 CloudWatch dashboard widget，顯示每個密鑰最後一次成功輪換的時間——可見的偏移就代表輪換已中斷，即使沒有 alarm 觸發。
• 對於 RDS 輪換，監控 Lambda 的 VPC 連線能力（DurationByPhase metric）——多數失敗是到資料庫的網路路徑問題。

SOA-C02 vs SAA-C03：資料保護的運維視角

同樣的服務，不同的視角。

SAA 考生選擇資料保護服務；SOA 考生操作它、排查失敗模式，並將它整合到更廣泛的監控和補救架構中。

考試訊號：如何辨識 Domain 4.2 題目

Domain 4.2 題目遵循可預測的形狀。認識它們，你每題的作答時間會大幅縮短。

• 「KMS key 被刪除，資料還能恢復嗎？」 — 在 7 到 30 天等待期內可以（取消刪除）；等待期結束後永遠不行。
• 「ACM 憑證自動更新失敗」 — DNS validation CNAME 被刪除、憑證未再掛載，或網域驗證過期。補回 CNAME。
• 「資料庫密碼必須每 30 天輪換一次且不停機」 — 帶輪換 Lambda 的 Secrets Manager；RDS 管理的主憑證是最簡單的路徑。
• 「應用程式日誌記錄了敏感憑證」 — 將憑證遷移到 Secrets Manager 或 Parameter Store SecureString；從日誌輸出中移除。
• 「GuardDuty 標記了一個 EC2 instance 正在與 C2 通訊」 — 透過安全群組隔離、製作快照以供鑑識、停用 IAM profile、通知 on-call，不要立即終止。
• 「合規要求使用 customer-managed key 而非 AWS-managed key」 — 以 customer-managed CMK 重建或遷移資源，並更新 key policy 以允許服務存取。
• 「儘管 IAM 允許，跨帳號解密仍然失敗」 — 來源帳號的 KMS key policy 必須授予目標帳號主體 kms:Decrypt（或使用 grant）；IAM 單獨對 KMS 是不夠的。
• 「Inspector 回報 EC2 instance 上有嚴重 CVE」 — 透過 Systems Manager Patch Manager 修補或從更新的 Image Builder AMI 重建；將 Security Hub finding 標記為 RESOLVED。

決策矩陣 — 各 SysOps 目標對應的資料保護構件

考試時使用此查詢表。

常見陷阱彙整 — AWS 資料保護

每次 SOA-C02 考試都會出現兩到三個這樣的干擾項。

陷阱 1：自動 key 輪換會重新加密現有資料

它不會。自動輪換輪換的是底層金鑰素材；現有密文繼續使用舊素材。若要重新加密，你必須讀取並寫入每個物件，或複製到使用新金鑰的新資源。

陷阱 2：KMS key 刪除是立即生效的

不是。有強制的 7 到 30 天等待期，期間金鑰處於 PendingDeletion。取消排程即可恢復。

陷阱 3：ACM email validation 自動更新可靠

它往往不可靠。WHOIS 聯絡人會過時，驗證 email 被當垃圾郵件處理。DNS validation 才是正確答案。

陷阱 4：只要 IAM 就能細粒度控制 KMS 存取

KMS 需要 key policy 和 IAM policy（委派時）都允許動作。除非 key policy 包含 IAM 委派陳述句，否則 IAM 單獨是不夠的。

陷阱 5：Secrets Manager 取代所有憑證儲存

對於不需輪換的敏感設定，Parameter Store SecureString 已足夠且更便宜。Secrets Manager 是用於輪換、大型值和原生資料庫整合的場景。

陷阱 6：Multi-Region keys 自動傳播 policies

它們不會。每個 replica 有自己的 key policy，管理員必須自行保持同步。

陷阱 7：GuardDuty findings 會自動呼叫 on-call

它們不會。你必須連接 EventBridge → SNS 或 Security Hub → EventBridge → SNS 才能真正呼叫 on-call。

陷阱 8：Inspector 需要手動掃描

不需要。持續模式是預設值，由 instance 啟動、映像推送和軟體變更觸發。

陷阱 9：Security Hub 預設彙整所有內容

不是。你必須明確啟用每個整合（GuardDuty、Inspector、Macie、Config）。

陷阱 10：傳輸中加密總是等於 ACM

ACM 是 AWS 終止 TLS 的正確答案。AWS regions 之間的傳輸中加密還包括 AWS 骨幹（已加密）加上 VPN/Direct Connect，以及可選的 MACsec 提供額外保障。

FAQ — AWS 資料保護

Q1：何時應使用 customer-managed KMS key vs AWS-managed key？

在以下任一情況使用 customer-managed key（CMK）：需要控制 key policy、需要授予跨帳號存取、需要可稽核的自動輪換、需要按自己的時間線停用或刪除金鑰、需要與其他工作負載區分的 CloudTrail 記錄，或需要提供資料保護金鑰在你直接管理下的合規證明。以下情況使用 AWS-managed key（aws/s3、aws/ebs、aws/rds）：上述要求都不適用——通常是開發環境或非受管工作負載，AWS-managed 預設在操作上更簡單。對 SOA-C02 而言，「合規團隊要求控制加密金鑰」或「稽核團隊需要看誰使用了金鑰」這樣的關鍵詞，每次都對應 customer-managed。

Q2：KMS 自動輪換如何與舊密文互動？

KMS 每 365 天輪換底層金鑰素材，但無限期保留舊素材，使現有密文仍可解密。金鑰 ID 和 ARN 不變。新的加密操作使用新素材；舊密文對著它們被加密時的版本解密。KMS 在內部處理版本選擇——應用程式感受不到。輪換不做的事是重新加密現有資料；如果資料保護政策要求重新加密（例如加密清除），你必須透過 alias 讀取並寫入每個密文，這會使加密使用當前素材。自動輪換為新資料購買前向保密，而非對舊資料的追溯清理。

Q3：如何正確補救 GuardDuty 對受損 EC2 instance 的 finding？

先隔離，再鑑識，最後復原。第一步：將 instance 移入隔離安全群組，拒絕所有流量，除了 SSM endpoint，讓 Session Manager 調查人員仍能存取主機，同時不給攻擊者任何出口。第二步：製作 EBS volumes 快照供離線分析。第三步：停用 IAM instance profile，撤銷任何從 instance 提取的憑證。第四步：透過你事先連接的 EventBridge → SNS 流水線呼叫 on-call。第五步：調查、找出根本原因，從已知乾淨的 AMI 重建。第六步：輪換任何可能洩漏的憑證（資料庫密碼、API keys、IAM access keys）。成熟的 SOA 團隊透過 EventBridge → Lambda 或 SSM Automation runbook 自動化一到四步；SOA-C02 偏好自動化答案而非手動步驟。

Q4：Parameter Store SecureString 何時足夠，何時需要 Secrets Manager？

當密鑰大多是靜態的時使用 Parameter Store SecureString——API endpoint URL、授權金鑰、應用程式設定、加密鹽值、feature flags。規模化的費用差異是顯著的：Parameter Store Standard tier 免費；Secrets Manager 是每密鑰每月 $0.40。以下情況使用 Secrets Manager：密鑰需要排程自動輪換（資料庫憑證、短 TTL 的 API tokens）、值超過 Parameter Store 的 4 KB / 8 KB 限制，或你需要原生 AWS 資料庫整合（RDS 管理的主憑證）。對於一個有 200 個密鑰的應用程式組合，混用兩者在運維上很正常——180 個靜態值用 Parameter Store，20 個需要輪換的用 Secrets Manager。

Q5：ACM 自動更新如何運作，為何會失敗？

ACM 在到期前 60 天開始自動更新。對於 DNS 驗證的公開憑證，ACM 重新檢查每個網域的驗證 CNAME 記錄；若每個網域仍通過驗證，ACM 發行新憑證，並在不中斷的情況下替換所有掛載資源（ALB、NLB、CloudFront、API Gateway）上的舊憑證。更新失敗的原因：（a）首次發行後 DNS validation CNAME 被刪除——最常見原因；（b）多網域憑證中某個 alternate name 的 CNAME 過時或遺失；（c）憑證長期未掛載到任何 AWS 服務；（d）email validation 聯絡人不再路由。解法是補回驗證 CNAME 並觸發重新發行。為縱深防禦，在剩餘 45 天和 30 天時對 CloudWatch DaysToExpiry metric 設 alarm，防範靜默更新失敗。

Q6：如何對現有的未加密 RDS instance 啟用靜態加密？

你無法就地啟用加密——RDS 加密在 instance 建立時設定。資料保護遷移序列是：（1）對未加密 instance 製作手動 DB 快照；（2）複製快照，選擇「啟用加密」並搭配所需的 KMS key（AWS-managed aws/rds 或你的 customer-managed CMK）；（3）從加密快照還原到新的 DB instance；（4）更新應用程式連線字串，或使用 CNAME 切換將流量切換到加密 instance；（5）確認後，停用未加密 instance 並刪除其快照。切換造成的短暫停機等於應用程式的重連時間。對於 Multi-AZ instance，同樣的序列適用；對於 Aurora，你可以使用 cluster 快照複製方式。

Q7：Envelope encryption 是什麼，AWS 為何使用它？

Envelope encryption 是以快速對稱 data key 加密資料，再以較慢（較昂貴）的 KMS master key 加密那把 data key 的技術。AWS 使用它是因為對 S3 / EBS / RDS 的每個位元組呼叫 KMS 會慢得難以接受且費用高昂。使用 envelope encryption，KMS 每個物件（或使用 S3 Bucket Keys 時每個 bucket-key 時間切片）只被呼叫一次來包裝 data key。實際的大量加密在儲存主機上直接使用 AES-256，以線速進行。加密的 data key 連同物件以中繼資料形式儲存。解密時，儲存服務呼叫 KMS 一次解包 data key，再在本地解密物件。這個模式使 KMS API 成本和延遲保持可控，同時保留集中管理 master key 的資料保護好處。

Q8：如何為多帳號組織架構 Security Hub？

在 AWS Organizations 層級為 Security Hub 指定委派管理員帳號——通常是專門的安全工具帳號，而非管理帳號。透過委派管理員的「Auto-enable」功能在每個成員帳號啟用 Security Hub，讓新帳號自動加入。至少啟用 AWS Foundational Security Best Practices 標準和 CIS AWS Foundations Benchmark 標準。啟用 GuardDuty 和 Amazon Inspector 作為 findings 來源，以及 IAM Access Analyzer 和 AWS Config。設定跨帳號彙整，讓每個成員的 findings 流入委派管理員選擇的 region。在委派管理員帳號的 aws.securityhub 事件上連接 EventBridge 規則，將關鍵 findings 路由到 SNS / Lambda / SSM Automation 進行分類。這是 SOA-C02 的組織範圍資料保護可觀測性參考架構。

Q9：KMS grant 和 key policy 的運維差異是什麼？

Key policy 是 KMS key 上的資源政策——長期存在、宣告一次、廣泛適用於列出的主體。Grant 是附加於金鑰的程式化、輕量級權限，針對特定主體和特定一組操作，可選擇以 encryption context 限定範圍。以下情況選用 grants：（a）權限是短期的（EBS volume 建立的存活期、EC2 instance、Lambda 呼叫的生命週期）；（b）被授權方不應在 key policy 中有明確的權限；（c）你希望能在不改寫 policy 的情況下撤銷。AWS 服務在底層定期使用 grants——例如當你啟動加密的 EC2 instance 時，EC2 在 instance 期間對 volume 的 KMS key 呼叫 CreateGrant，instance 終止時再終止 grant。SOA-C02 要求你知道 grants 是服務對資源委派的 AWS 推薦模式；key policies 是人員和角色存取的設定。

Q10：如何在規模化環境中架構資料保護 findings 補救？

一次建立單一多帳號流水線，然後讓帳號加入它。參考架構：（1）透過 Organizations auto-enable 在每個帳號啟用 GuardDuty、Inspector、Macie、AWS Config、IAM Access Analyzer；（2）Security Hub 跨帳號和 regions 將 findings 彙整到委派管理員帳號；（3）委派管理員帳號中的 EventBridge 規則，針對 aws.securityhub finding-imported 事件，以嚴重程度（Critical、High）過濾；（4）EventBridge 目標——Lambda 用於快速動作如安全群組隔離，SSM Automation 用於多步驟 runbook（快照、隔離、呼叫、建立工單），SNS 用於人工通知；（5）CloudWatch dashboards 顯示每個帳號按嚴重程度分類的 finding 計數；（6）明確的 workflow status 衛生——每個 NEW finding 在 SLA 內被標記為 NOTIFIED，誤報以原因標籤標記為 SUPPRESSED，RESOLVED findings 追蹤平均補救時間作為運維指標。SOA-C02 對任何規模化資料保護場景的正確答案是「使用 Security Hub + EventBridge + SSM Automation」；臨時性的逐帳號腳本會失分。

延伸閱讀與相關運維模式

• AWS KMS Developer Guide
• AWS KMS Concepts and Key Types
• Rotating AWS KMS Keys
• KMS Grants
• KMS Key Policies
• KMS Multi-Region Keys
• Deleting AWS KMS Keys
• AWS Certificate Manager User Guide
• ACM Managed Certificate Renewal
• ACM DNS Validation
• AWS Private Certificate Authority
• AWS Secrets Manager User Guide
• Rotating Secrets in AWS Secrets Manager
• Systems Manager Parameter Store
• AWS Security Hub User Guide
• Amazon GuardDuty User Guide
• Amazon Inspector User Guide
• AWS SOA-C02 Exam Guide v2.3（PDF）

資料保護就位後，自然的後續運維主題包括：IAM Policies、MFA、SCPs 與存取故障排查——補充加密的存取控制面；CloudTrail 與 AWS Config 用於稽核與合規——證明你的資料保護控制正在運作的稽核追蹤；Multi-Account Strategy with Organizations and Control Tower——將這些資料保護模式擴展到多個帳號；以及備份、還原與災難復原程序——資料保護的韌性面，加密快照必須在復原場景中仍可解密。

• IAM Policies, MFA, SCPs, and Access Troubleshooting — SOA-C02 Study Notes
• Backup, Restore, and Disaster Recovery Procedures — SOA-C02 Study Notes
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 Study Notes
• Multi-Account Strategy with Organizations and Control Tower — SOA-C02 Study Notes