現有架構的安全態勢改善

提升現有 AWS 架構的安全態勢，和設計全新工作負載有本質上的差異。設計新系統時，你從一開始就選好軌道——預設加密開啟、從第一天就使用 Secrets Manager、用 IAM Identity Center 取代 IAM 使用者、每個 Listener 都配 ACM 頒發的憑證。但在現有系統中，你繼承了前一個團隊（或被購併公司）已交付的一切：大量未加密的 EBS Volume、Docker 映像檔 latest-prod 中硬式編碼的資料庫憑證、一個名為 jenkins-deploy 且 Access Key 建立於 2019 年的單一 IAM 使用者、兩百個從未清點過的 S3 儲存桶、一台不在任何 SSO 範圍內的老舊 OpenVPN 設備，以及一個仍附有 Access Key 的 root 帳號。SAP-C02 Task 3.2 考驗的，是你能否走進這種局面、執行診斷，並依照正確順序開立修復處方——而不只是列出你所知道的每一項 AWS 安全服務。

本指南假設你已具備 Associate 等級的 IAM、KMS 與 CloudTrail 知識，並聚焦在 Professional 考試所獎勵的先診斷再修復思維。我們將涵蓋：以 Security Hub FSBP 基準作為計分面、以 Inspector v2 作為漏洞修補引擎、以 Macie 對既有儲存桶進行 PII 探索、IAM Access Analyzer 的三項互補功能、能在有狀態資源中存活的靜態加密遷移手冊、讓你脫離硬式編碼憑證的密碼輪替模式、從傳統 VPN 遷移至 AWS Verified Access + IAM Identity Center、對現有 ALB 強制執行 TLS、以 GuardDuty 推進執行期防護，以及以 Amazon Detective 收尾的事件回應手冊。每個章節最後附有 SAP-C02 的陷阱訊號，以及考試要求你完全掌握的自動修復整合（EventBridge → Config → SSM Automation）。

SAP-C02 中「安全態勢改善」的定義

安全態勢改善是一門學科：在 AWS 環境已在承載正式流量的前提下，提高安全基準——關閉缺口、強制加密、輪替憑證、啟用偵測控制，並驅動持續合規——而不強迫進行全面重寫。Professional 考試將 Task 3.2 定義為診斷問題：給定一組症狀（EC2 機群的 CVE、稽核員發現的公開 S3 儲存桶、Git 儲存庫中的硬式編碼 AWS Access Key、未輪替的 KMS 金鑰、成員帳號中停用的 CloudTrail），找出能達到修復狀態的正確 AWS 服務組合，並依序排列這些服務，讓高爆炸半徑的發現優先被關閉。

關鍵在於，Domain 3 的題目與 Domain 2 的語氣截然不同。Domain 2 問的是「一家公司正在建立全新 SaaS 產品，安全架構應該如何設計？」；Domain 3 問的是「一家公司已有 SaaS 產品在第一次 SOC 2 稽核中失敗，接下來應該依序做什麼？」正確答案必然尊重考試反覆重用的三個限制：將有狀態資源的停機時間降到最低、優先選擇原生託管服務而非第三方代理程式，以及用預防性 + 偵測性控制組合取代單點修復。

白話文解釋 Security Improvement of Existing Systems

對現有系統做安全改善，一半是考古、一半是水電工程。三個來自不同日常生活的類比，能讓工作流程更好記。

類比一：公司門禁升級

公司搬進一棟老舊辦公大樓。在換壁紙之前，物業管理委員會先請來一位驗樓師，拿著清單逐一檢查——煙霧偵測器、電器配電盤、屋頂、管線、石棉、白蟻——最後交給你一份附有嚴重程度評級的報告。AWS Security Hub 搭配 FSBP 就是這位驗樓師：它列舉 100 多項你本應執行的檢查，並給你合規評分和優先排序的發現清單。Amazon Inspector v2 是專門負責你「木造結構」資源（EC2 AMI、Lambda 程式碼、ECR 映像檔）的白蟻 + 病蟲害檢測師——它不評論你的油漆顏色，但會找出牆壁裡爬行的每一個 CVE。Amazon Macie 是你另外雇來的文件稽核員，開啟每一個抽屜和檔案櫃（S3 儲存桶），告訴你哪些裡面放了前任留下的舊護照、報稅文件或信用卡卡號。IAM Access Analyzer 是鎖匠，走遍每扇門，找出哪把鑰匙能開哪個房間，注意到清潔人員的鑰匙竟然能開主臥室（外部存取發現），並記下哪些鑰匙已 90 天沒用過（未使用存取）。四份報告都到手後，你按正確順序安排施工：先裝好缺少的煙霧偵測器（CloudTrail + MFA）、再換門鎖（輪替 Access Key）、再加密保險箱（RDS/S3/EBS），最後才進行大翻新（Verified Access 切換）。

類比二：接手一間混亂廚房

新主廚接手一間每況愈下的餐廳。前任留下了冷藏庫裡過期的食材（未使用的 IAM 使用者）、走廊掛鉤上的酒窖總鑰匙（root 帳號 Access Key）、貼在爐台上方包含供應商密碼的手寫食譜（硬式編碼憑證），以及完全沒有監視攝影機（沒有 CloudTrail 資料事件）。主廚不能關閉餐廳——今晚還要繼續接待客人。因此她按爆炸半徑排序行動。第一天：先換冷藏庫門鎖和酒窖鑰匙（撤銷 root 金鑰、強制執行 MFA）。第一、二天：在做其他任何事之前先安裝監視攝影機，這樣修復過程中才能即時監控（啟用 CloudTrail 組織追蹤 + Security Hub + GuardDuty）。第一週：清點每一樣食材（對 S3 執行 Macie、對 EC2 執行 Inspector、對 IAM 執行 Access Analyzer）。第二週：把所有供應商密碼移進每週自動換密碼的保險箱（Secrets Manager）。第三至四週：開始更換不符合食安規定的廚具（透過快照還原進行靜態加密遷移）。第二個月：把外送員走的偏門（傳統 VPN）換成每次進出都驗證身分的門禁刷卡機（Verified Access）。餐廳從未停業；每次修復都是附有確認點的小變更。

類比三：機場在資安事件後升級安檢系統

一座有二十年歷史的國際機場剛通不過監管機關稽核。解法不是「蓋一座新機場」，而是分層推進。AWS Config 規則 + SSM Automation 是自動行李重新檢查輸送帶——若行李在沒有正確標籤的情況下抵達登機口，輸送帶會自動將它導回掃描，無需人工介入。Inspector v2 是每個安檢點的 X 光機，持續對每位旅客的行李（EC2 AMI、Lambda 套件、容器映像檔）進行掃描，並每小時更新威脅資料庫。GuardDuty 執行期防護是在航廈走動的便衣安全人員，在旅客通過安檢後監視可疑行為（容器向已知 C2 網域發出 DNS 查詢、Lambda 函數產生非預期的 Shell）。Amazon Detective 是調查室——一旦有東西觸發警報，首席安全官坐下來面對單一視窗，該視窗整合了 CloudTrail、VPC Flow Log 和 GuardDuty 發現，建構出完整時間軸。AWS Verified Access 是取代老舊不可靠員工側門的新優先通關閘口——每次進入都需要身分 + 裝置態勢核查，而不是一次性的門禁感應。

診斷入口：如何從一個陌生帳號開始

Professional 考試獎勵先做診斷而非先做修復的考生。當題目開頭是「一家公司剛購併了規模較小的競爭對手，並繼承了對方的 AWS 帳號——第一個動作是什麼？」，正確答案幾乎從來不是「啟用加密」或「輪替金鑰」——而是「取得可見性」。第一個目標是了解你擁有什麼、什麼已暴露在外、哪些發現已達到緊急等級；唯有如此，才能確立優先順序。

四個診斷問題

1. 我有資源清單嗎？ 在帳號的所有 Region 啟用 AWS Config（記錄器 + 傳遞通道）。Config 在每次資源變更時記錄完整的資源快照。沒有 Config，你就是在黑暗中問問題。
2. 我有稽核日誌嗎？ 啟用 CloudTrail 組織追蹤，將日誌推送至中央 Log Archive 帳號的 S3 儲存桶，並設定 Object Lock 或 MFA Delete。管理事件必須開啟；S3 物件層級和 Lambda 呼叫的資料事件緊隨其後。沒有 CloudTrail，你就無法回答「是誰做的？」
3. 我的基準分數是多少？ 啟用 AWS Security Hub 並套用 FSBP 標準（如有需要，也套用 CIS AWS Foundations 和 PCI DSS）。Security Hub 將 Config 規則結果、GuardDuty、Inspector、Macie、IAM Access Analyzer 和 Firewall Manager 的發現彙整成統一模型（ASFF — AWS Security Finding Format），並產生每個標準的百分比合規分數。
4. 現在什麼東西著火了？ 啟用 GuardDuty（包含 S3、EKS、Lambda、RDS 和 Runtime Monitoring 功能），以點亮任何正在活躍的惡意活動。GuardDuty 分析 CloudTrail、VPC Flow Log、DNS 日誌和執行期感測器；它是最快速的「我現在是否正遭受入侵？」訊號。

只有在這四個基礎都啟用之後，才應開始發布修復工單。在考試中，若題目詢問「繼承陌生帳號後的第一個步驟」，正確答案幾乎一定是以下其中之一：啟用 CloudTrail、啟用 Security Hub + 標準、啟用 Config、啟用 GuardDuty——通常以「啟用基礎服務並將發現彙整至安全工具帳號」的方式呈現。

購併公司的診斷情境

情境：你的公司剛購併了一家 50 人的競爭對手。被購併的 AWS 帳號顯示：200 個內容不明的 S3 儲存桶、root 使用者有一個七天前仍在使用的有效 Access Key、所有帳號皆未強制執行 MFA、CloudTrail 只在 us-east-1 啟用、有一個名為 Admins 的 IAM 群組共 14 名成員且全使用長期 Access Key，以及 Security Hub 從未開啟過。第一天你該怎麼做？

SAP-C02 的正確答案是一個序列，而不是單一動作：

1. 先鎖好前門：立即輪替或刪除 root Access Key（AWS 最佳實踐是 root 使用者不應有 Access Key）；為 root 啟用 MFA；為每位有主控台存取權的 IAM 使用者新增硬體或虛擬 MFA，並透過 SCP 或 IAM 政策條件（aws:MultiFactorAuthPresent）強制執行 MFA。若 root Access Key 已洩漏，還需撤銷當天所有 IAM 角色的 Session 憑證。
2. 在做任何事之前先開啟監視攝影機：啟用具有日誌檔案驗證的多 Region CloudTrail 追蹤，將日誌推送至中央 Log Archive 帳號的 S3 儲存桶並設定 Object Lock；在每個 Region 啟用 Config。先做這一步再進行修復，是因為後續的任何金鑰輪替、政策變更或資源修改都會留下可供日後稽核的鑑識記錄。
3. 啟用偵測服務：開啟 GuardDuty、搭配 FSBP 和 CIS 標準的 Security Hub、組織範圍的 IAM Access Analyzer，以及具備三種掃描（EC2 + Lambda + ECR）的 Inspector v2。此時你已取得基準分數和完整發現清單。
4. 依爆炸半徑分類處理發現：Critical/High 發現優先——公開的 S3 儲存桶、具有 AdministratorAccess 且無 MFA 的 IAM 使用者、帶有公開快照的未加密 RDS 執行個體、允許 0.0.0.0/0 存取 22 或 3389 埠的安全群組、任何地方停用的 CloudTrail、已排定刪除的 KMS 金鑰。
5. 開始分批執行範圍修復：每批針對一組相關控制（憑證、加密、網路暴露、密碼、執行期），並各自附有回滾計畫。

Security Hub FSBP 基準與合規漂移修復

AWS Security Hub 是計分板。AWS Foundational Security Best Practices (FSBP) 標準是一套精心挑選的 100 多項控制，對應 IAM、S3、EC2、RDS、KMS、CloudTrail、Config、EFS、Lambda、ELB 等服務中最具代表性的安全衛生項目。每項控制底層對應一個或多個 AWS Config 規則；Security Hub 執行這些規則、以 AWS Security Finding Format (ASFF) 蒐集發現，並計算每個標準的合規百分比。

Security Hub 如何驅動改善

在現有帳號上，Security Hub 的任務有三項：

• 基準：給你一個今日分數（例如「FSBP 合規率 58%」），讓你能逐週追蹤進度。
• 優先排序：依嚴重程度（Critical / High / Medium / Low / Informational）排列發現，並為每項附上修復連結。
• 自動化：將發現饋送至 EventBridge，讓自訂動作、SNS 通知或 SSM Automation Runbook 能在無需人工介入的情況下觸發修復。

考試中的關鍵架構要點：

• 彙整帳號：透過 AWS Organizations 將 Audit / Security Tooling 帳號指定為 Security Hub 的委派管理員，再啟用跨 Region 彙整，讓每個成員帳號每個 Region 的所有發現都匯入單一主控台和單一 S3 儲存桶供下游使用。
• 跨 Region 彙整：連結 Region 功能讓彙整 Region 能接收所有其他連結 Region 的發現副本，讓單一儀表板反映整個環境的狀況。
• 發現生命週期：發現具有工作流程狀態（NEW / NOTIFIED / SUPPRESSED / RESOLVED）以及可翻轉工作流程、指派嚴重程度或透過 EventBridge 路由的自動化規則。

透過 Config + SSM Automation 進行合規漂移與自動修復

Professional 考試中，「漂移」意指資源曾經合規後來又發生變更。例如：有人新增了一條安全群組規則，開放 22 埠給 0.0.0.0/0。修復架構永遠是相同的三步驟模式：

1. 偵測 — AWS Config 規則根據預期設定評估資源。受管規則 restricted-ssh 會標記任何允許 0.0.0.0/0 存取 22 埠的安全群組。
2. 路由 — EventBridge 規則比對 Config 合規變更事件（source: aws.config、detail-type: Config Rules Compliance Change），條件為 newEvaluationResult.complianceType = NON_COMPLIANT。
3. 修復 — Config 的原生修復動作呼叫 SSM Automation 文件（受管或自訂），移除違規規則；或由 EventBridge 路由至 Lambda 執行相同動作。

AWS 提供了一批預建的 SSM Automation Runbook 用於常見修復：AWSConfigRemediation-RemoveSecurityGroupIngressRule、AWSConfigRemediation-EnableEbsEncryptionByDefault、AWSConfigRemediation-EnableCloudTrail、AWSConfigRemediation-RotateKMSKey、AWSConfigRemediation-EnableS3BucketEncryption 等。將它們附加到 Config 規則作為修復目標，可選擇設定為自動執行（含或不含核准）。

考試陷阱：Security Hub 本身不執行修復

Security Hub 產生發現；它不修復問題。修復動詞永遠是委派出去的——通常委派給 AWS Systems Manager Automation 或 AWS Lambda，再由 EventBridge 作為黏合劑。若題目問「哪個服務自動修復發現？」，答案是 Config 修復動作或 SSM Automation，而不是 Security Hub。Security Hub 的價值在於標準化與彙整，而非執行動作。

Inspector v2：EC2、Lambda 與 ECR 漏洞的修補導入

Amazon Inspector v2 是自動化的持續漏洞管理服務。在現有架構上，Inspector 是將「我們有 200 台 EC2 執行個體，鬼才知道它們的修補程式等級」轉化為「每個發現附有 Inspector 分數的 CVE 排序清單」的工具。與前一代 Inspector Classic 不同，Inspector v2 在大多數工作流程下為無代理模式（針對 EC2 使用已部署的 SSM Agent），並掃描三種資源類型。

Inspector v2 的掃描範圍

• EC2 執行個體 — 作業系統 CVE，以及可選的網路可達性發現（位於公開子網路且 22 埠開放且存在嚴重 OpenSSH CVE 的 EC2，其嚴重程度遠高於位於私有子網路 ALB 後方的相同執行個體）。當執行個體在執行且已安裝 SSM Agent 時，掃描會持續進行。
• ECR 容器映像檔 — 基礎作業系統 CVE、程式語言套件 CVE（Python、Node、Java、Ruby、Go、.NET）。Inspector 的 ECR 增強掃描是預設模式；增強掃描在推送時、依排程，以及持續對 CVE 資料庫執行，因此當針對映像檔中套件的新 CVE 發布時，映像檔會自動變成不合規。
• Lambda 函數 — 兩種模式：標準掃描（部署 ZIP 或 Layer 中的套件 CVE）和程式碼掃描（對你的處理程式碼進行靜態分析，找出注入漏洞、硬式編碼密碼、弱加密）。

現有帳號的導入模式

1. 透過委派管理員模型（通常是 Audit / Security Tooling 帳號）啟用 Inspector v2。
2. 在 AWS Organizations 中為新帳號自動啟用，讓新成員帳號繼承掃描功能。
3. 依 Inspector 分數和可利用性分類處理發現。Inspector 評分會依環境調整 CVSS（考量網路可達性、套件是否在執行中的程序中、漏洞是否已有公開 Exploit）。
4. 優先處理面向網際網路 + 嚴重 CVE。若 Inspector 顯示「此執行個體可從網際網路存取，且 Apache 中有嚴重 RCE 漏洞」，那就是第一天必須修復的項目。
5. 將發現推送至 Security Hub，讓單一彙整視圖同時追蹤漏洞發現和錯誤設定發現。
6. 透過 Systems Manager Patch Manager 自動化修補 — 依 OU 或標籤定義修補基準、排程維護時間窗，並使用 Inspector 發現驗證修補後的 CVE 數量確實下降。

生成 SBOM

Inspector v2 可以 CycloneDX 或 SPDX 格式，匯出每個資源的軟體物料清單（SBOM）。SBOM 匯出是企業客戶和監管機關日益要求的稽核成品——在考試中，當情境說「我們必須提供每個容器中每個第三方函式庫的機器可讀清單」時，SBOM 就是正確答案。

Macie：對既有儲存桶進行 S3 PII 探索

Amazon Macie 專為 SAP-C02 中不斷出現的一個問題而生：「這個 S3 儲存桶存在五年了，沒有人知道裡面有什麼——它是否包含 PII？」Macie 使用受管資料識別碼（姓名、地址、政府 ID、信用卡號碼、健康記錄、AWS 憑證）和可選的自訂資料識別碼（正規表示式 + 關鍵字）對物件進行取樣，並產生精確到物件層級的發現。

既有儲存桶的 Macie 探索模式

1. 透過委派管理員模型在組織層級啟用 Macie。
2. 使用自動敏感資料探索（預設的持續、低成本取樣模式）快速取得整個環境中所有儲存桶的態勢概覽。此模式使用智慧取樣，給你一張哪些儲存桶可能含有敏感資料的熱點地圖。
3. 對熱點地圖標記為高風險的儲存桶執行目標探索作業。探索作業可以是一次性或排程性（每日/每週/每月），且可依標籤、大小或物件鍵前綴縮小範圍。
4. 審查發現：SensitiveData:S3Object/Credentials（AWS 金鑰、OAuth Token）、SensitiveData:S3Object/Financial、SensitiveData:S3Object/Personal，以及政策發現如 Policy:IAMUser/S3BucketPublic。
5. 透過 Macie ↔ Security Hub 整合將發現饋送至 Security Hub，並透過 EventBridge → Lambda → 儲存桶政策更新 / 物件標記 / 物件移至隔離儲存桶來觸發修復。

情境：200 個儲存桶的問題

當情境說「購併帳號中有 200 個未掃描的儲存桶」，正確序列是：

1. 啟用 Macie 並開啟自動敏感資料探索——這是可擴展且符合成本效益的第一輪掃描。
2. 立即在帳號層級啟用 S3 Block Public Access（透過 aws s3control put-public-access-block），在探索執行期間防止新的意外暴露。
3. 為 S3 啟用 S3 Server Access Logging + CloudTrail 資料事件，確保你有物件層級讀取的稽核歷史。
4. 讓 Macie 取樣一週，然後對任何被標記為高敏感度的儲存桶執行探索作業。
5. 修復：將確認含有 PII 的儲存桶移至以條件 aws:SecureTransport: false 拒絕公開存取的 S3 儲存桶政策後方；以專屬 KMS CMK 啟用預設加密；套用 ABAC 標籤實現資料分類驅動的存取控制；若消費者為分析使用者，則與 Lake Formation 整合。

IAM Access Analyzer：外部存取、未使用存取與政策生成

IAM Access Analyzer 是 SAP-C02 中最常被低估的服務之一，因為它執行三項截然不同的工作，每一項都與改善工作流程息息相關。了解每項工作的確切功能——以及它不做什麼——是一個常見的考試陷阱。

功能一：外部存取分析器（信任區）

外部存取分析器持續檢查 S3 儲存桶、IAM 角色（信任政策）、KMS 金鑰、Lambda 函數、SQS 佇列、Secrets Manager 密碼、SNS 主題、IAM Identity Center 應用程式、RDS 快照、ECR 儲存庫、EFS 檔案系統等資源型政策。給定一個信任區——單一 AWS 帳號或整個 AWS 組織——只要有資源將存取權授予信任區外部的 Principal，它就會發出發現。

這是當題目詢問「找出我們環境中所有授予組織外部人員存取權的資源」時的正確工具。對於 SAP-C02 情境中「被購併公司多年來一直與外部顧問共用 S3 儲存桶、KMS 金鑰和 IAM 角色信任」的問題，外部存取分析器能在幾分鐘內產生完整的外部存取清單。

功能二：未使用存取分析器

未使用存取分析器檢查你帳號中的 IAM 實體並回報：

• 未使用的 IAM 使用者（在追蹤期間內沒有任何活動）。
• 未使用的 IAM 角色（該角色的信任政策在 N 天內未被擔任）。
• 未使用的 Access Key（N 天內沒有 API 呼叫記錄）。
• 在使用中的角色內的未使用權限——即該角色有 s3:*，但在追蹤時間窗內只用過 s3:GetObject 和 s3:ListBucket。
• 未使用的主控台密碼。

未使用存取分析器是「在不中斷工作負載的前提下縮小 IAM 身分爆炸半徑」這一問題的正確工具。它是付費功能（每個資源每月計費），與免費的外部存取分析器分開——這個細節在考試中具有區別意義。

功能三：從 CloudTrail 生成政策

政策生成功能讀取某個 Principal（IAM 角色或使用者）最多 90 天的 CloudTrail 歷史，並生成僅包含該 Principal 實際呼叫過的動作的最低權限 IAM 政策。當情境說「我們有一個帶有 AdministratorAccess 的舊版 IAM 角色，想要在不中斷應用程式的情況下收緊它」時，這就是要使用的工具。執行政策生成、審查產生的政策、將其附加為替換政策，並可選擇在分離 AdministratorAccess 之前保留一週的觀察回退期。

IAM Access Analyzer 不做的事

Access Analyzer 不評估 Identity-based IAM 政策是否符合最佳實踐（那是 IAM Access Advisor 和 AWS Config 規則的領域）。它不偵測程式碼中洩漏的憑證（那是 Secrets Manager、Macie、Inspector Lambda 程式碼掃描或第三方工具如 GitHub Secret Scanning 的職責）。它不掃描 Active Directory 或 Identity Center 的弱密碼。

靜態加密修補手冊

靜態加密修補是考試中最常見的「現有系統」修復情境，因為各服務的就地升級路徑各不相同。手冊分四個階段。

第一階段：清點

使用 AWS Config 進階查詢（或 Security Hub FSBP 控制）列出：

• encrypted = false 的 EBS Volume。
• ServerSideEncryptionConfiguration 不存在或設定為 SSE-S3 而政策要求 SSE-KMS 的 S3 儲存桶。
• StorageEncrypted = false 的 RDS 執行個體。
• 公開或未加密的 RDS 快照。
• Encrypted = false 的 EFS 檔案系統。
• 政策要求客戶自管金鑰（CMK）但仍使用 AWS 預設金鑰的 DynamoDB 資料表。
• 加密為選用項目的 Redshift 叢集、ElastiCache Redis、SageMaker 網域及其他資料儲存。

第二階段：啟用帳號層級預設值（防止新的暴露）

• EBS 預設加密：帳號層級設定，按 Region 分別啟用。立即啟用——從那時起，每個新 Volume、每個新快照和每個新 AMI 都會以指定的 KMS 金鑰加密。
• S3 預設加密：每個新建立的儲存桶預設開啟加密（預設為 SSE-S3；若需更高控制度，升級至使用 CMK 的 SSE-KMS）。
• RDS：沒有全域「預設加密新 DB 執行個體」的開關，但你可以透過 SCP 拒絕不附 StorageEncrypted=true 的 rds:CreateDBInstance，或透過 Config 規則 rds-storage-encrypted 搭配自動修復拒絕不合規資源。
• AWS Organizations SCP：在 OU 之間拒絕建立未加密資源，作為強制的預防層。

第三階段：遷移現有未加密資源（困難部分）

由於加密對大多數 AWS 資料儲存而言是建立時不可變的屬性，每個有狀態資源都需要不同的遷移方式。考試要求你了解每個服務的模式。

• EBS Volume 遷移：(a) 建立未加密 Volume 的快照，(b) 以指定 --encrypted --kms-key-id <CMK> 的方式複製快照，(c) 從加密快照建立新 Volume，(d) 停止執行個體、分離舊 Volume、附加新加密 Volume、啟動執行個體。停機時間通常為幾分鐘；可以 SSM Automation Runbook 形式撰寫腳本。對於根 Volume，則從加密快照產生加密 AMI 後重新啟動。
• S3 物件遷移：在儲存桶上啟用預設加密，然後使用 S3 Batch Operations 搭配 CopyObject 作業重新寫入所有現有物件（就地複製加密）。對於非常大的儲存桶，S3 Batch 可擴展至數十億個物件；作業可標記、計費和稽核。
• RDS 遷移：無法在執行中的未加密 RDS 執行個體上啟用加密。模式是 (a) 建立快照，(b) 啟用加密並指定 CMK 複製快照，(c) 從加密快照還原至新執行個體，(d) 切換流量（DNS CNAME、Read Replica 提升模式，或使用 AWS DMS 實現近零停機）。對於 Aurora，相同的快照複製還原模式適用。
• EFS 遷移：建立新的加密檔案系統，並使用 AWS DataSync 複製資料，再重新掛載。
• DynamoDB：加密永遠開啟；若要從預設 AWS 自有金鑰改為客戶自管 CMK，透過 UpdateTable 修改資料表即可——不需要複製資料，變更屬於中繼資料層級。這是最順暢的遷移路徑之一。
• Redshift：修改叢集以啟用加密——這會啟動背景重新加密，大型叢集可能需要數小時到數天；規劃變更時間窗時應降低叢集負載。
• ElastiCache Redis：靜態加密在叢集建立時設定；遷移需要備份後還原至新的加密叢集，再切換客戶端。

第四階段：KMS CMK 策略

當你需要金鑰政策層級的存取控制、跨帳號使用、手動/自動輪替控制、金鑰使用 CloudTrail 或每年自動輪替時，請使用客戶自管 CMK（而非 AWS 自管的 aws/<service> 金鑰）。對於多 Region 工作負載，使用 KMS Multi-Region Keys (MRK)，讓相同的金鑰 ID 存在於多個 Region，且密文可跨地互通——這是 DR 策略要求加密快照能在 DR Region 解密而無需重新封裝時的正確答案。

密碼輪替遷移：從硬式編碼憑證到 Secrets Manager

被購併帳號中最常見的稽核發現，是硬式編碼憑證——原始程式碼中的資料庫密碼、環境變數中的第三方 API 金鑰、Dockerfile 中的 AWS Access Key。修復方法是將每個密碼遷移至 AWS Secrets Manager（或針對不需輪替的值使用 SSM Parameter Store SecureString），並在支援的情況下啟用自動輪替。

探索

• Amazon Macie 可偵測 S3 物件內的憑證，包括舊備份壓縮檔和封存日誌。
• Amazon Inspector Lambda 程式碼掃描可偵測 Lambda 處理程式碼中的硬式編碼密碼。
• GitHub / Bitbucket 密碼掃描加上 AWS CodeGuru Security 可捕獲原始碼儲存庫中的密碼。
• IAM Credentials Report 列出每個 IAM 使用者的 Access Key 及其建立日期和最後使用日期——任何超過 90 天或從未輪替的金鑰都是立即輪替的候選對象。

遷移模式

1. 以描述性名稱和標籤（App=billing、Env=prod、Owner=team-foo）將密碼移入 Secrets Manager。
2. 更新應用程式在執行期透過 AWS SDK 取得密碼（GetSecretValue）。對於 Lambda，新增允許針對特定密碼 ARN 執行 secretsmanager:GetSecretValue 的 IAM 政策，並在 Lambda 暖機期間快取密碼。
3. 從原始碼和容器映像檔中移除硬式編碼值。使用 BFG Repo-Cleaner 或 git filter-repo 清理 git 歷史、強制推送，並使曾包含密碼的映像檔標籤失效。
4. 啟用自動輪替。Secrets Manager 為 RDS（MySQL、PostgreSQL、Oracle、MSSQL、MariaDB）、Amazon RDS Proxy、DocumentDB、Redshift 內建輪替 Lambda 範本，以及可自訂的「通用」輪替函數用於第三方 API。
5. 定義輪替排程——服務帳號通常為 30 天，第三方 API 金鑰為 90 天。輪替由 Lambda 函數處理：建立新的密碼版本、測試、更新目標資源，並以原子方式翻轉 AWSCURRENT 版本標籤。
6. 對舊憑證的最後使用建立 CloudWatch 警報——若應用程式仍從任何地方讀取舊的硬式編碼值，警報就會觸發，讓你追蹤到尚未遷移的呼叫方。

Secrets Manager vs Parameter Store 的取捨

• Secrets Manager：內建輪替、跨帳號資源政策、多 Region 複寫、每個密碼成本較高。用於任何需要輪替的密碼。
• SSM Parameter Store SecureString：成本較低、無內建輪替、易與 CloudFormation / SSM 整合。用於恰好屬於敏感性但不輪替的設定值（加密環境變數、功能旗標）。

從傳統 VPN 遷移至 Verified Access + IAM Identity Center

大多數舊版 AWS 架構透過 EC2 上的 OpenVPN 設備、AWS Site-to-Site VPN 或 AWS Client VPN 路由員工/承包商對內部 Web 應用程式的存取。這些方案可行，但模式是「信任網路隧道」——一旦使用者連上 VPN，他們就有廣泛的網路可達性，Session 長期存在，且態勢只在連線時檢查一次。現代零信任替代方案是 AWS Verified Access。

Verified Access 模式

Verified Access 針對每個 HTTPS 請求，依照以 Cedar 表達的政策進行評估，輸入來自：

• 身分，透過信任提供者——IAM Identity Center（推薦用於以 AWS 為中心的組織）或 OIDC 相容的外部 IdP（Okta、Auth0、Entra ID / Azure AD、Ping）。
• 裝置態勢，透過可選的裝置信任提供者（macOS 使用 Jamf、透過擴充套件使用 CrowdStrike / Jamf）。態勢訊號包括磁碟加密狀態、作業系統版本、EDR 是否存在。

Verified Access 政策看起來像：permit(principal, action, resource) when { context.identity.groups.contains("finance-admins") && context.device.os == "macOS" && context.device.disk_encryption == "enabled" };。

從 VPN 的遷移模式

1. 識別目前在 VPN 後方的應用程式——通常是內部管理介面、Jira/Confluence、Grafana 儀表板、Jenkins、舊版財務工具。
2. 將每個應用程式放在私有子網路的 ALB 後方（若尚未如此）。
3. 建立 Verified Access 執行個體、信任提供者（IAM Identity Center）、每個應用程式的 Endpoint（指向 ALB），以及存取政策。
4. 將公司 DNS（公開或透過 Route 53 私有託管區域）指向 Verified Access Endpoint URL。
5. 分批遷移使用者——從一個應用程式和一個試點群組開始，驗證稽核日誌（Verified Access 將每次決策以 OCSF 格式記錄至 CloudWatch Logs / S3 / Kinesis Firehose），然後擴大規模。
6. 所有應用程式都在 Verified Access 後方且使用者確認沒有中斷的存取路徑後，停用 VPN。
7. 在 IdP 層強制執行 IAM Identity Center MFA，使用抗釣魚方法（硬體金鑰 / 平台密鑰），確保每次 Verified Access 決策都有 MFA 支撐。

為何優於 VPN

• 每次請求授權，而非每次 Session 的網路隧道。
• 無需維護 IP 允許清單——存取基於身分，而非來源 IP。
• 每次請求的裝置態勢，在 MDM 將裝置標記為不合規後的幾分鐘內，就能捕獲遺失/被盜裝置。
• 完整稽核日誌，記錄每次決策（允許/拒絕）的身分、裝置訊號、來源 IP 和政策評估追蹤——以 OCSF 格式彙整至 Security Lake。

IAM Identity Center 作為身分單一來源

遷移時，IAM Identity Center 也應取代各帳號的 IAM 使用者用於主控台 / API 存取。序列是：(1) 在組織管理帳號啟用 Identity Center，(2) 透過 SCIM + SAML 連接外部 IdP 進行使用者/群組佈建，(3) 依角色建立權限集（ReadOnly、DataAnalyst、SecurityAdmin），(4) 透過群組將權限集指派給帳號，(5) 隨著團隊遷移，撤銷 IAM 使用者 Access Key。這也解鎖了屬性型存取控制（ABAC），IdP 來源的標籤會傳播至 Session，IAM 政策以此為條件。

TLS 強制執行修補：ACM、SSL 政策與 ALB 加固

在現有環境中強制執行 TLS 有三個要素：每個面向公眾的 Endpoint 必須有有效憑證、每個 Listener 必須強制執行強 SSL 政策，以及每個純 HTTP Listener 必須重新導向或移除。

步驟一：憑證資產清點

• 清點：每個 Region 的 ACM 主控台，以及任何直接上傳至 Load Balancer、CloudFront、API Gateway 或 EC2 的憑證。
• 儘可能以 ACM 頒發的憑證取代自行管理 / 第三方憑證。ACM 會自動為其整合的資源（ALB、NLB、CloudFront、API Gateway）處理更新。
• 內部私有 TLS：使用 ACM Private CA 為內部服務頒發憑證（微服務對微服務的 TLS、內部 ALB、Service Mesh Sidecar）。Private CA 提供完整的憑證層級控制、短期憑證以及透過 RAM 進行跨帳號共享。

步驟二：ALB / NLB SSL 政策加固

ALB 上的每個 HTTPS Listener 和 NLB 上的每個 TLS Listener 都引用一個 SSL 政策——一個命名的協定版本和加密套件組合。現有舊版 Listener 常使用允許 TLS 1.0 和 1.1 的 ELBSecurityPolicy-2016-08。修補步驟：

• 以 ELBSecurityPolicy-TLS13-1-2-2021-06（TLS 1.2 + 1.3，現代加密套件）或 FIPS 相容變體取代（若有需要）。
• 明確停用 TLS 1.0 和 TLS 1.1——許多合規框架（PCI DSS、FedRAMP）強制要求這一點。
• 在 80 埠新增 HTTP Listener，設定為 301 重新導向至 HTTPS，讓存取 HTTP 的舊版客戶端被移轉至 TLS 而非提供純文字服務。

步驟三：對 S3 和 API Endpoint 強制執行 TLS

• S3 儲存桶政策：新增帶有條件 "Bool": {"aws:SecureTransport": "false"} 的 Deny 陳述式，拒絕任何非 HTTPS 請求。這是一個 2 行的變更，也是 FSBP 控制項目。
• CloudFront：將每個快取行為的 ViewerProtocolPolicy 設定為 redirect-to-https，最低 TLS 版本設為 TLSv1.2_2021。
• API Gateway：設定每個網域的最低 TLS 版本、要求 SigV4 或 JWT 授權，並透過具有適當憑證的 Regional / Edge Endpoint 強制執行 TLS。

步驟四：監控與稽核

• AWS Config 規則 alb-http-to-https-redirection-check 標記未將 HTTP 重新導向至 HTTPS 的 ALB Listener。
• Config 規則 elb-tls-https-listeners-only 標記具有非 TLS Listener 的 NLB/ELB。
• Config 規則 s3-bucket-ssl-requests-only 驗證儲存桶政策要求 SecureTransport。
• 每條規則都配合 SSM Automation 修復，確保漂移在幾分鐘內關閉。

執行期防護推進：GuardDuty EKS、Lambda、RDS 與 S3 惡意軟體防護

Amazon GuardDuty 涵蓋了以錯誤設定為重點的服務所遺漏的威脅：主動入侵、憑證濫用、橫向移動、挖礦程式和惡意軟體。在現有帳號上，你在組織層級啟用一次 GuardDuty，然後逐步開啟與你工作負載相關的防護計畫。

需評估的防護計畫

• GuardDuty Foundational（原始版本）：CloudTrail、VPC Flow Log 和 DNS 日誌分析。永遠優先啟用。
• S3 Protection：監控異常 S3 API 使用的資料事件（異常下載、停用 Public Access Block、異常跨帳號存取）。
• Malware Protection for S3：上傳時或按需對物件內容進行惡意軟體掃描。適用於接受使用者上傳的儲存桶（客服附件、資料攝取區）。
• Malware Protection for EC2：當 GuardDuty 偵測到可疑行為時，對 EBS Volume 進行無代理掃描；也可按需主動執行。
• EKS Protection：監控 EKS 稽核日誌，識別 Kubernetes API 濫用模式（權限提升、可疑 exec、Service Account Token 誤用）。
• EKS Runtime Monitoring（現已統一納入 ECS / EC2 的 Runtime Monitoring）：來自 GuardDuty 安全代理程式（EKS Add-on 或 EC2 SSM Distributor 套件）的程序層級和網路層級遙測，捕獲容器逃逸、反向 Shell、挖礦程式二進位。
• RDS Protection：偵測 RDS Aurora MySQL/PostgreSQL 的登入異常——偵測暴力破解、異常地理位置/使用者模式。
• Lambda Protection：監控 Lambda 函數的網路活動——標記向 C2 網域發出請求或向非公司目的地異常資料外洩的函數。

推進序列

1. 透過組織層級的委派管理員啟用 GuardDuty Foundational；為新帳號自動啟用。
2. 在整個組織啟用 S3 Protection。
3. 對具有公開 Endpoint 或敏感工作負載的叢集啟用 EKS Protection。
4. 透過受管 EKS Add-on 部署 Runtime Monitoring 代理程式；驗證安全代理程式 Pod 正在執行且能產生發現（GuardDuty 提供範例發現供驗證）。
5. 建立基準後啟用 Lambda Protection——Lambda Protection 成本隨呼叫量擴展，若成本是考量因素，依標籤選擇性啟用。
6. 對暴露於應用程式登入的 Aurora MySQL/Postgres DB 啟用 RDS Protection。
7. 對接受使用者上傳的儲存桶啟用 Malware Protection for S3。

謹慎調整抑制規則

成熟的 GuardDuty 推進需要抑制規則來靜音已知的無害發現（滲透測試來源 IP、安全團隊的內部掃描器）。將抑制規則存為 IaC（CloudFormation / Terraform），確保可審查並自動到期。

利用 Amazon Detective 進行事件回應

當 GuardDuty 發現在凌晨兩點觸發時，值班工程師需要一個畫面看到完整故事。Amazon Detective 就是那個畫面。Detective 攝取 CloudTrail、VPC Flow Log、GuardDuty 發現、EKS 稽核日誌和 Security Lake 資料，將它們縫合成行為圖，讓分析師能以任何 IP、Principal、角色或資源為基準，查看時間窗內所有相關事件。

Detective 的啟用

• 透過委派管理員帳號啟用 Detective（與 GuardDuty / Security Hub 相同的模式）。
• 連結所有成員帳號，讓 Detective 的圖涵蓋整個組織。
• 連結每個你運作的 Region。
• 預建的發現群組將相關發現叢集（相同 Principal、相同目標、重疊時間窗），讓你對攻擊活動進行分類，而非逐一處理單獨警報。

事件回應手冊序列（購併公司範例）

針對「GuardDuty 對長期休眠的 IAM 使用者觸發 UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B」的 Detective 驅動 IR 手冊：

1. 圍堵 — 透過 aws iam update-access-key --status Inactive 立即撤銷 IAM 使用者的 Access Key 和有效 Session，並對任何假設的角色鏈執行 aws sts revoke-access-keys-for-role。
2. 在 Detective 中調查 — 開啟發現，轉向 IAM 使用者的設定檔，檢視過去 24 小時內的登入位置、API 呼叫量和新資源建立。
3. 範圍評估 — 使用者是否建立了新的 IAM 使用者、新的 Access Key、新的 EC2 執行個體，或變更了 CloudTrail 設定？Detective 在同一個視圖中呈現所有這些內容。
4. 根除 — 刪除任何新建立的身分、終止未授權資源、輪替使用者可能存取過的任何密碼。
5. 復原與加固 — 對所有 IAM 使用者強制執行 MFA（或更好地，遷移至具有抗釣魚 MFA 的 IAM Identity Center 並完全移除 IAM 使用者）；啟用 GuardDuty 可疑登入通知；更新 SCP 以拒絕未來建立 IAM 使用者。
6. 事後處理 — 將 CloudTrail + GuardDuty + Detective 時間軸匯出至 Security Lake 作為長期證據保存；若事件確認為無害，在 Security Hub 以抑制原因開啟發現。

Detective vs Security Hub vs CloudTrail Lake

• Security Hub 是計分板和路由器（發現與嚴重程度）。
• CloudTrail Lake 是可用 SQL 查詢的事件儲存，用於鑑識臨時查詢。
• Detective 是預建的互動式調查圖（無需 SQL），具有可突顯異常的行為基準。

三者相輔相成；在考試中，單一視窗鑑識調查情境指向 Detective，可 SQL 查詢的事件封存指向 CloudTrail Lake，標準化多來源 SIEM 風格資料湖指向 Security Lake。

購併公司情境的修復序列

我們承諾了對先前介紹的診斷情境進行完整演練。以下是 Professional 考試期望看到的完整排序修復——按正確順序排列。

情境回顧：被購併的 AWS 帳號有 200 個未掃描的 S3 儲存桶、root Access Key 正在使用中、任何使用者都未強制執行 MFA、CloudTrail 只在單一 Region 啟用、Admins 群組的 14 名成員持有長期 Access Key，以及 Security Hub 從未啟用。

第 0 天 — 緊急圍堵（前 2 小時）

1. Root 帳號加固：刪除 root Access Key；為 root 啟用硬體 MFA；將 root 憑證鎖入實體保險箱。依照 AWS 最佳實踐，root 不應有 Access Key。
2. 立即在帳號層級啟用 S3 Block Public Access — 單一 API 呼叫，在探索執行期間防止任何新的意外公開暴露。
3. 透過 IAM 政策強制執行 MFA — 對 Admins 群組附加「未啟用 MFA 拒絕所有」政策，直到每個成員都有 MFA。

第 0-1 天 — 可見性基礎

4. 啟用帶有日誌檔案驗證的多 Region CloudTrail 組織追蹤，目標 S3 儲存桶位於專屬 Log Archive 帳號且設定為合規模式 Object Lock，並為關鍵儲存桶啟用 S3 資料事件。
5. 在每個 Region 啟用 AWS Config，並設定傳遞通道至 Log Archive 帳號。
6. 啟用 AWS Security Hub，套用 FSBP 和 CIS AWS Foundations 標準；將 Audit 帳號指定為委派管理員；啟用跨 Region 彙整。
7. 透過委派管理員啟用 GuardDuty，所有 Foundational 功能加上 S3 Protection 全部開啟。
8. 在組織範圍啟用 IAM Access Analyzer（外部存取分析器為免費；在最高風險帳號上啟用未使用存取分析器）。
9. 啟用 Amazon Macie，對所有 200 個儲存桶開啟自動敏感資料探索。
10. 為 EC2、Lambda 和 ECR 啟用 Inspector v2。

第 2-7 天 — 分類處理與高影響力修復

11. 審查 Security Hub 嚴重程度面板：優先修復所有 Critical 發現（公開儲存桶、公開的未加密 RDS 快照、某處停用的 CloudTrail、仍存在的 root Access Key）。
12. 對 Admins 群組和每個服務帳號執行 IAM Access Analyzer 未使用存取分析：所有 30 天以上未使用的 Access Key 先停用再刪除。
13. 在 Admins 角色上使用 Access Analyzer 政策生成產生最低權限替換政策；審查、以「觀察」模式套用，並取代 AdministratorAccess。
14. 將每個 Admins 成員遷移至 IAM Identity Center 使用者/權限集；隨著團隊遷移完全移除 IAM 使用者。
15. 在每個 Region 開啟 EBS 預設加密和 S3 預設加密。
16. 開始對任何被標記為高敏感度的儲存桶排程 Macie 探索作業；對每個確認含有 PII 的儲存桶以預設 SSE-KMS 加密、SecureTransport 必要的儲存桶政策以及透過 VPC Endpoint + Block Public Access 限制的存取進行修復。

第 2-4 週 — 靜態加密修補

17. 透過 Config 查詢清點未加密的 EBS / RDS / EFS。
18. 在排程的維護時間窗內，對每個 RDS 執行個體執行快照 → 加密複製 → 還原遷移。
19. 在新要求 SSE-KMS 的情況下，使用 S3 Batch Operations 重新加密現有物件。
20. 對執行中執行個體的 EBS Volume，透過 SSM Automation 將快照-複製-加密-替換腳本化，並排程在低流量時間窗執行。

第 3-5 週 — 密碼與 TLS

21. 透過 Macie（S3）、Inspector Lambda 程式碼掃描，以及（在 AWS 外）原始碼儲存庫密碼掃描，探索硬式編碼密碼。
22. 將每個密碼遷移至 Secrets Manager 並設定自動輪替（RDS 主密碼使用原生整合；第三方 API 金鑰使用自訂輪替 Lambda）。
23. 修補每個 ALB 的 TLS：將 SSL 政策升級至 TLS 1.3、新增 HTTP 至 HTTPS 重新導向、對每個 S3 儲存桶強制執行 SecureTransport。
24. 為每個內部服務頒發 ACM 憑證；對於內部 TLS，建立 ACM Private CA。

第 4-8 週 — VPN 替換與執行期防護

25. 以 Verified Access 替換傳統 VPN：建立 Verified Access 執行個體、信任提供者（Identity Center）、每個應用程式在 ALB 後方的 Endpoint、綁定 IdP 群組和裝置態勢的 Cedar 政策；分批遷移使用者；停用 OpenVPN 設備。
26. 透過受管 Add-on 為 EKS 叢集和 ECS 服務啟用 GuardDuty Runtime Monitoring。
27. 在 Aurora MySQL/Postgres Endpoint 上啟用 GuardDuty RDS Protection。
28. 審查呼叫量成本後啟用 GuardDuty Lambda Protection。
29. 在任何接受使用者上傳的儲存桶上啟用 Malware Protection for S3。

持續進行 — 合規漂移與自動修復

30. 盡可能將每個 FSBP 控制與預建 SSM Automation Runbook 的 AWS Config 自動修復配對，否則使用自訂 Runbook。
31. 將所有嚴重程度高於 High 的 Security Hub 發現路由至 SNS → 工單 / Slack。
32. 為 IR 調查啟用 Amazon Detective；每季使用 AWS FIS 進行 GameDay 演練。
33. 以每週 Security Hub FSBP 分數作為 KPI 追蹤；將修復節奏與業務 SLA 掛鉤。

SAP-C02 Task 3.2 常見陷阱

精選考試常重複出現的陷阱：

• 「對現有 RDS 啟用加密」≠ ModifyDBInstance。你必須建立快照、帶加密複製，再還原。RDS/Aurora 靜態加密不支援就地啟用。
• IAM Access Analyzer 不稽核 Identity-based IAM 政策。外部存取分析器只檢查資源型政策和信任政策。
• Security Hub 產生發現；它不執行修復。修復方是 AWS Config 修復動作、Systems Manager Automation，或透過 EventBridge 黏合的 Lambda。
• Macie 自動探索 ≠ 完整掃描。自動敏感資料探索以智慧取樣方式快速且低成本地給你態勢。若要在排程節奏上完整覆蓋物件，需要明確的探索作業。
• GuardDuty Runtime Monitoring 需要安全代理程式。對於 EKS，透過受管 Add-on 部署；對於 ECS / EC2，透過 SSM Distributor 套件。沒有代理程式，你只能獲得控制平面訊號。
• Detective 需要 48 小時的 GuardDuty 資料，其圖才有用。
• Verified Access 是針對每個 HTTP 應用程式，而非網路隧道。每個應用程式有自己的 Endpoint。
• ACM 憑證僅對 ACM 整合的資源自動更新。直接上傳至 ALB 的憑證（非透過 ACM）是客戶自己的更新責任。
• Config 規則是 Regional 的 — 你需要在每個有工作負載的 Region 都設定，並透過 Config Aggregator 或 Security Hub 跨 Region 彙整。
• 組織 CloudTrail 追蹤 vs 帳號別追蹤：組織追蹤在管理帳號建立，並套用至每個成員帳號；你無法從成員帳號刪除它。這既是特性（一致性），也是陷阱（成員帳號管理員無法竄改）。
• Macie + Security Hub 整合是原生的 — 兩者都啟用，發現就會自動流通。不需要 Lambda 黏合劑。
• Secrets Manager RDS 原生整合用於主密碼，移除了對自訂輪替 Lambda 的需求。考試中「最小化 RDS 密碼輪替的維運負擔」= 此功能。

常見問題

Q1：若我在某個 Region 啟用 EBS 預設加密，我現有的未加密 Volume 是否會立即被加密？

不會。預設加密只適用於設定啟用後新建立的 EBS Volume 和新建立的快照。現有的未加密 Volume 在你明確透過快照 → 帶加密複製 → 建立新 Volume → 分離/附加的模式（或為根 Volume 建立加密 AMI 後重新啟動）進行遷移之前，仍保持未加密狀態。S3 預設加密同理——新物件會被加密，現有物件維持寫入時的加密狀態。對於現有 S3 物件，使用 S3 Batch Operations 搭配 CopyObject 作業就地重新加密。對於 RDS，快照複製還原模式是唯一支援的路徑。

Q2：當 Macie 在 200 個儲存桶回報發現時，我如何優先排序要先修復哪些？

從三個訊號組合建立優先矩陣：(1) 暴露程度 — 儲存桶是否可被公開存取或從組織外部存取？（S3 Block Public Access 狀態 + IAM Access Analyzer 外部存取發現）；(2) 敏感度 — Macie 是否回報 PII、憑證、財務資料或 PHI 的 Critical / High 發現？（Macie 發現嚴重程度）；(3) 業務重要性 — 哪個應用程式擁有該儲存桶，以標籤衡量。高暴露 + 高敏感度的儲存桶為 P0：立即套用 Block Public Access、以專屬 CMK 加密、透過儲存桶政策強制執行 SecureTransport，並限制存取至特定 VPC Endpoint。中等儲存桶為 P1：排程在兩週內處理。低風險儲存桶為 P2：透過 Config 自動修復自動化並每月審查。

Q3：當題目說「在一小時內檢查 50 個帳號中的每個 IAM 角色的外部存取」，考試的正確答案是什麼？

搭配組織層級信任區的 IAM Access Analyzer。在委派管理員帳號建立分析器，並將信任區設定為「AWS organization」。分析器評估每個成員帳號每個 Region 的每個資源型政策和信任政策，對組織邊界外的任何 Principal 發出發現，並讓你透過封存規則封存已知無害的外部存取（例如第三方 SaaS 整合）。這比手動遍歷每個角色的信任政策快得多，也更全面。注意，分析器不檢查 Identity-based IAM 政策——對於那些，使用 IAM Access Advisor 和 Config 規則。

Q4：Inspector v2 在執行中的 EC2 執行個體發現嚴重 CVE。考試中的自動修復模式是什麼？

將 Inspector 發現傳送至 EventBridge，過濾嚴重程度為 Critical 或 High，並以 Systems Manager Automation Runbook 為目標，執行 AWS-PatchInstanceWithRollback 或自訂 Runbook，該 Runbook (a) 建立執行個體快照，(b) 呼叫 Patch Manager 在下個維護時間窗套用修補基準，(c) 驗證 Inspector 重新掃描執行個體且 CVE 已關閉，(d) 失敗時通知。對於容器映像檔，模式不同：Inspector 掃描 ECR，在映像檔推送時發出發現，EventBridge 觸發流水線階段，阻止部署有漏洞的映像檔標籤，並提醒服務負責人使用修補的基礎映像檔重建。絕對不要選「啟動新 AMI 並遷移所有工作負載」——考試獎勵透過 Patch Manager 就地修補。

Q5：Security Hub 與 Security Lake 的關係是什麼？兩者都需要嗎？

它們服務於不同目的並互補。Security Hub 是近即時的發現彙整器——標準化為 AWS Security Finding Format (ASFF)，依標準（FSBP、CIS、PCI、NIST）評分，透過 EventBridge 路由以進行修復。Amazon Security Lake 是長期、可 SQL 查詢的安全遙測資料湖，標準化為 Open Cybersecurity Schema Framework (OCSF)——它攝取 CloudTrail、VPC Flow Log、Route 53 DNS 日誌、Security Hub 發現、EKS 稽核日誌、Lambda 事件和自訂來源，以 Apache Parquet 格式儲存在 S3 上，並透過 Lake Formation 向訂閱者（Athena、QuickSight、第三方 SIEM）公開。在實踐中，企業兩者都使用：Security Hub 作為維運計分板和修復路由器；Security Lake 作為 SOC 團隊和事件回應的分析與長期保存稽核儲存。

Q6：情境說「將 14 名持有靜態 Access Key 的 IAM 管理員使用者遷移至安全的身分模型」。預期的答案是什麼？

遷移至搭配權限集的 IAM Identity Center，後端使用 Identity Center 內建目錄或透過 SAML 2.0 + SCIM 連接的外部 IdP（Azure AD、Okta）。每位管理員以 Identity Center 使用者身分佈建（或從公司 IdP 同步），透過群組指派至 Admins 權限集，並在 IdP 強制執行 MFA——理想情況下使用抗釣魚方法（硬體金鑰 / 平台密鑰）。主控台和 CLI 存取使用短期 Session 憑證（預設最長 12 小時，可設定至 1 小時）。隨後刪除所有 IAM 使用者及其 Access Key，並新增 SCP 阻止未來的 iam:CreateUser 和 iam:CreateAccessKey。對於來自 CI/CD 或應用程式的程式化存取，以透過 OIDC 擔任 IAM 角色（GitHub Actions、GitLab 等）或 Kubernetes 工作負載的 IRSA/Pod Identity 取代 IAM 使用者 Access Key。

Q7：當目標是讓員工存取內部 Web 應用程式時，什麼可以取代 Site-to-Site VPN？為何不直接保留 VPN？

AWS Verified Access 搭配 IAM Identity Center 是替換方案。考試強調 VPN 的四個結構性弱點：(1) 連線後粗粒度的網路層信任，(2) 對於使用動態網路的遠端工作者而言不適用的靜態來源 IP 允許清單，(3) 沒有每次請求的政策評估——裝置態勢只在連線時檢查一次，(4) 長期隧道隱藏橫向移動。Verified Access 逐一解決每個問題：每個 HTTPS 請求的政策評估、以身分和裝置為中心而非以網路為中心、基於 Token 的短期 Session，以及每次存取決策（允許/拒絕）的完整 OCSF 稽核日誌。話雖如此，VPN / Client VPN 對於非 HTTPS 的機器對機器情境仍然相關——Verified Access 只涵蓋 HTTP/HTTPS 應用程式，而非通用 IP 連接性。

考試訊號與總結

Task 3.2——改善現有架構的安全態勢——是 Domain 3 權重最高的領域之一，也是真實 SAP-C02 考試題目中的常見主題。出題者反覆使用少數幾個標誌性情境：被購併公司的帳號、稽核發現驅動的修復、「在不中斷正式環境的情況下輪替憑證」、「在不停機的情況下加密 RDS」、「傳統 VPN 至零信任」、「修補 200 台有 CVE 的 EC2 執行個體」、「200 個內容不明的儲存桶」，以及「成員帳號中停用的 CloudTrail」。對於每一個，獲勝的答案模式都是相同的形狀：

1. 可見性優先（CloudTrail + Config + Security Hub + GuardDuty + Access Analyzer + Inspector + Macie）。
2. 圍堵暴露的憑證和公開 Endpoint。
3. 依嚴重程度分類。
4. 依控制類別分批修復（身分、加密、密碼、網路、執行期）。
5. 初始掃描後透過 Config 規則 + SSM Automation 進行漂移自動修復。
6. 將安全改善作為持續 KPI（每週 FSBP 分數、按嚴重程度分類的未關閉發現數）。

如果你能走進「被購併公司」情境並不看筆記地排出上述 30 步修復順序，你在考試當天的 Task 3.2 將處於最佳狀態。訣竅是抵抗「立即到處啟用加密」的衝動——考試獎勵先啟用可見性、依爆炸半徑排列優先順序，並將每次修復視為 偵測 → 路由 → 修復 → 驗證 鏈的候選人，讓 AWS 原生服務完成工作。