AWS 資安事件應變計畫與服務整合

AWS 資安事件應變計畫總覽

**資安事件應變計畫（incident response plan）**在 AWS 的脈絡下，是一套正式書面化、經過演練的行動序列，定義組織在雲端環境發生安全事件時所採取的完整措施。SCS-C02 考試把 incident response plan 視為遠超過一份文件的存在：它期望你能設計技術控制、識別每個階段正確的 AWS 服務、明文規定角色與職責，並儘可能將 incident response plan 自動化，讓人員能專注於判斷決策，而不是在 console 裡一步一步點選操作。

任何 AWS incident response plan 的權威參考文件是 AWS Security Incident Response Guide，它將 NIST SP 800-61 改編為雲端原生的實務版本。SCS-C02 考試指南的知識點明確引用了這份白皮書，因此每個階段——Prepare、Detect、Analyze、Contain、Eradicate、Recover、Lessons Learned——都是考試範圍。incident response plan 也必須具備帳號意識：AWS Organizations、委派管理（delegated administration）和跨帳號角色，都會改變偵測、隔離、鑑識相較於單一帳號架構的運作方式。

本文完整涵蓋 SCS-C02 task 1.1 的考試範圍：你將看到如何部署偵測服務堆疊（GuardDuty、Security Hub、Macie、Inspector、Config、Detective、IAM Access Analyzer）、如何透過 EventBridge 將 ASFF findings 串接至 Lambda 或 Step Functions、如何在 IAM 憑證外洩時執行撤銷、如何隔離 EC2 執行個體以進行鑑識採樣，以及如何在 incident response plan 的 RACI 矩陣中明確分配角色。每個概念都對應到具體的考試技能，讀完這份筆記後，你應能看到一道 SCS-C02 長情境題就立即判斷出正確的 incident response plan 應對動作，而不需要重讀題幹。

SCS-C02 為何重視 Incident Response Plan

SCS-C02 Domain 1 佔比 14%，其中三個 task statements（1.1、1.2、1.3）全部直接涉及 incident response plan。Task 1.1 明確要求你設計並實作 incident response plan，而 1.2 與 1.3 則涵蓋偵測資料來源與實際應變動作。考試經常呈現表面看起來像「最佳架構」的情境題，但實際上是在測試你是否理解 incident response plan 必須包含自動化圍堵，而不只是告警。

incident response plan 主導 Domain 1 的另一個原因，是 AWS 將其視為共同責任的分界線。AWS 提供構建模組（GuardDuty findings、Security Hub 聚合、EventBridge 事件、Lambda 自動化），但客戶必須將這些模組組裝成一套完整的 incident response plan。考試測試的是這個組裝能力，而非個別服務的存在。

AWS 事件應變七個階段

AWS Security Incident Response Guide 將 incident response plan 分為七個階段。請依序記熟——考題常以名稱指涉某個階段，或描述對應特定階段的情境。

Phase 1 — Prepare（準備）

準備是事件發生前的所有工作：在每個帳號和區域啟用 GuardDuty、以委派管理員身份啟用 Security Hub、部署集中化 CloudTrail 組織 trail、預先建立鑑識應變人員的 IAM 角色，以及在隔離的安全帳號中預先建置乾淨的鑑識 VPC。incident response plan 也應包含預先撰寫並存放於 Systems Manager Documents 的 runbook。

Phase 2 — Detect（偵測）

偵測資料來源於 GuardDuty、Macie、Inspector、IAM Access Analyzer、AWS Config rules、CloudWatch alarms 以及第三方工具，饋入 incident response plan。所有 findings 應正規化為 ASFF 格式並集中到 Security Hub。

Phase 3 — Analyze（分析）

分類（triage）回答的是「這是真實事件嗎？」使用 Amazon Detective 從 GuardDuty finding 樞軸展開，進入相關 API 呼叫、VPC flows 和 Kubernetes audit log 的關聯圖譜。

Phase 4 — Contain（圍堵）

圍堵在不摧毀證據的前提下限制爆炸半徑。對 IAM 而言，是將 access key 設為 inactive 或附加 deny-all 政策。對 EC2 而言，是透過替換 security group 進行隔離。對 S3 而言，是套用限制性儲存桶政策。

Phase 5 — Eradicate（消除）

消除排除威脅：在快照採樣後終止受入侵的執行個體、輪換所有密鑰、撤銷活躍 session，並透過 Inspector findings 修補根本原因漏洞。

Phase 6 — Recover（復原）

復原還原服務：從已強化的 AMI 啟動替換執行個體、從不可變備份還原資料、重新啟用應用程式流量。

Phase 7 — Lessons Learned（事後檢討）

事後檢討回饋至 incident response plan：更新 runbook、新增 GuardDuty 抑制規則、收緊 SCP，並針對偵測到的任何偏差提交 IaC 變更。

白話文解釋

如果你第一次接觸 incident response plan，三個生活化的類比可以幫你把抽象概念立刻內化。

類比一：醫院急診 SOP 台灣醫院急診室不是病人來了才開始想流程。檢傷分類（triage）、外傷小組編組、輸血申請動線、家屬溝通話術，全部寫在牆上的 SOP 裡，每個月演練一次。AWS 的 incident response plan 一模一樣：你不能等到 GuardDuty 半夜噴出 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration 警報才開始查 access key 怎麼撤銷。Security Hub 是檢傷護理師（把所有來源標準化成 ASFF），EventBridge 是廣播系統（把警報送到對的科別），Lambda playbook 是預先準備好的急救車（不用現場臨時找器材）。

類比二：捷運控制中心應變流程 台北捷運控制中心一旦偵測到異常，指揮中心、現場站務、維修人員、乘客廣播各司其職，沒人去搶別人的工作。AWS 的 incident response plan 用 RACI 矩陣寫死誰負責什麼：IR Commander 拍板、Security Engineer 執行圍堵、SOC Analyst 看 dashboard、Application Owner 評估服務衝擊、Compliance Officer 通報主管機關。沒寫清楚就會出現「大家都以為對方在處理」的真空時間，這在 SCS-C02 考題裡是經典反例。

類比三：24 小時便利商店食安事件應變 便利商店總部的食安應變計畫一定包含「立即下架」「封存樣品」「通報衛生局」「事後根因分析」四個動作，順序不能亂。AWS 的 EC2 isolation runbook 順序也一樣：先從 ASG 脫離（不讓新流量進來）→ 換成 deny-all security group（立即下架）→ 拍 EBS snapshot（封存樣品）→ 用 SSM 抓 memory dump（再採樣）→ 移至鑑識 VPC（隔離區）→ 產出 Detective 分析報告（事後根因分析）。如果把順序顛倒（例如先 terminate 才想到要 snapshot），證據就消失了，這也是考題常見陷阱。

角色與職責 — RACI 矩陣

SCS-C02 考試指南明確將「incident response plan 中的角色與職責」列為知識考點。AWS 建議使用 RACI 式矩陣，讓每個階段都有唯一一位**當責（Accountable）負責人，以及明確命名的執行（Responsible）**人員。典型的雲端 incident response plan RACI 如下：

R = Responsible（執行）、A = Accountable（當責）、C = Consulted（諮詢）、I = Informed（知會）。IR Commander 是事件期間的單一決策權威；Security Engineer 實際執行 AWS console / CLI 指令；SOC Analyst 監控 Security Hub 和 Detective dashboard；Application Owner 決定是否接受停機；Compliance Officer 負責通知主管機關。

incident response plan 也必須預先建立這些人員所需承擔的 IAM 角色。AWS 建議在鑑識帳號中設置一個專用的 SecurityIncidentResponseRole，具備讀取 CloudTrail、拍攝 EBS snapshot、執行 SSM 指令和修改 security group 的權限——但不得刪除 CloudTrail 或修改 Config rules（職責分離）。

部署 AWS 偵測服務堆疊

一套有效運作的 incident response plan 需要遙測資料。SCS-C02 task 1.1 列出七項服務作為標準偵測堆疊：AWS Security Hub、Amazon Macie、Amazon GuardDuty、Amazon Inspector、AWS Config、Amazon Detective，以及 AWS IAM Access Analyzer。你必須了解每一項服務的功能，以及如何在整個組織層級部署。

GuardDuty — 威脅偵測器

Amazon GuardDuty 持續分析 CloudTrail 管理事件、CloudTrail S3 資料事件、VPC Flow Logs、DNS 日誌、EKS audit logs、RDS 登入事件及 Lambda 呼叫，偵測加密貨幣挖礦、IAM 異常行為、連接埠掃描、憑證外洩等威脅。透過 Organizations 委派管理員啟用 GuardDuty，確保每個成員帳號自動加入。

Security Hub — 聚合器

AWS Security Hub 從 GuardDuty、Macie、Inspector、IAM Access Analyzer、Config、Firewall Manager 及數十個合作夥伴產品取用 findings，全部正規化成 ASFF，並對 CIS AWS Foundations、AWS Foundational Security Best Practices、PCI DSS、NIST 800-53 等標準持續執行合規檢查。在單一 home region 進行跨區域 finding 聚合。

Macie — 資料分類器

Amazon Macie 使用託管與自訂資料識別符掃描 S3 儲存桶，識別敏感資料（PII、憑證、PHI）。Macie findings 透過 ASFF 流入 Security Hub，讓 incident response plan 能在公開儲存桶發現敏感資料時自動觸發修復。

Inspector — 漏洞掃描器

Amazon Inspector v2 持續掃描 EC2 執行個體、ECR 中的容器映像及 Lambda 函數，偵測 CVE 及非預期的網路曝露。Findings 正規化為 ASFF 並饋入 Security Hub。

AWS Config — 組態記錄器

AWS Config 記錄每一次資源組態變更，並依規則（託管或自訂 Lambda 支援）評估資源合規性。Config Conformance Packs 讓你以一個 CloudFormation stack 部署完整合規框架。

Detective — 調查工具

Amazon Detective 將 CloudTrail、VPC Flow Logs 和 GuardDuty findings 引入行為圖譜，讓分析師在 Analyze 階段能跨實體（IAM principals、EC2 執行個體、IP 位址）進行樞軸分析。

IAM Access Analyzer — 政策稽核器

IAM Access Analyzer 識別與外部 principal 共用的資源（S3 儲存桶、IAM 角色、KMS 金鑰、Secrets Manager 秘密、Lambda 函數、SQS 佇列）。新的外部存取會產生 finding 並流入 Security Hub。

ASFF — Incident Response Plan 的共同語言

**AWS Security Finding Format（ASFF）**是所有 Security Hub findings 遵循的 JSON schema。SCS-C02 考試指南在 task 1.1 知識點中明確列出 ASFF。熟悉關鍵欄位，是寫出有效 EventBridge rule 和寫出無效 rule 之間的差異。

incident response plan 自動化將讀取的關鍵 ASFF 欄位：

• SchemaVersion — 固定為 "2018-10-08"
• Id 與 ProductArn — 唯一識別 finding
• GeneratorId — 哪個偵測器產生（例如 GuardDuty rule ID）
• AwsAccountId — 來自哪個成員帳號
• Types — 分類法，例如 "TTPs/Initial Access/UnauthorizedAccess:IAMUser-InstanceCredentialExfiltration"
• Severity.Label — INFORMATIONAL、LOW、MEDIUM、HIGH、CRITICAL
• Resources[] — 受影響的 ARN；這是你的 playbook 將隔離的對象
• Workflow.Status — NEW、NOTIFIED、SUPPRESSED、RESOLVED
• RecordState — ACTIVE 或 ARCHIVED

進入 Security Hub 的每一個 finding——無論來自 AWS 原生服務或第三方 SIEM——都必須符合 ASFF。這個標準化正是讓你的 incident response plan 能以一條 EventBridge rule 處理任何來源 findings 的原因。

EventBridge 作為 Incident Response Bus

一旦 findings 以 ASFF 格式進入 Security Hub，Amazon EventBridge 就是驅動 incident response plan 的引擎。Security Hub 自動將每個 finding 以 Security Hub Findings - Imported 事件發布至預設事件匯流排。你的任務是撰寫帶有內容過濾模式的 EventBridge rules，比對特定 finding 類型並路由至正確目標。

標準模式：一條比對 Types 包含 UnauthorizedAccess:IAMUser 的規則，觸發一個 Step Functions state machine，步驟為（1）從 finding 取得 IAM user，（2）呼叫 iam:UpdateAccessKey 將金鑰設為 inactive，（3）附加 deny-all 政策作為預防措施，（4）透過 Lambda 建立 JIRA ticket，（5）將 Security Hub finding 的 Workflow.Status 更新為 NOTIFIED。

對於較高嚴重性的 findings，規則可以扇出：同一條 EventBridge rule，多個目標——Step Functions 負責自動化、SNS 透過 PagerDuty 呼叫人員、Kinesis Firehose 長期封存至 S3 + Athena 查詢。

Runbook 與 Playbook — 不要混淆

SCS-C02 明確區分 runbook 和 playbook，考試喜歡測試你是否清楚兩者的差異。

Runbook 是已知且可重複任務的逐步程序——例如「隔離 EC2 執行個體以進行鑑識採樣」。Runbook 是確定性的：輸入 → 精確步驟 → 輸出。AWS 以 Systems Manager Automation Documents（SSM Documents）實作 runbook，以 YAML 或 JSON 撰寫，透過 aws ssm start-automation-execution 執行。

Playbook 是更高層次的決策樹，將多個 runbook 加上人員決策串連起來，應對一類事件——例如「回應疑似憑證入侵事件」。Playbook 包含分支邏輯（「principal 是人類使用者還是服務角色？」、「攻擊者存取了 S3 還是 EC2？」），據此選擇呼叫哪個 runbook。AWS 以 Step Functions state machines 實作 playbook，呼叫 SSM runbooks、Lambda 函數及人工核准步驟。

incident response plan 同時儲存兩者：SSM runbooks 負責確定性的操作細節，Step Functions playbooks 負責協調編排。

IAM 憑證入侵應變序列

IAM 憑證入侵是 SCS-C02 最常見的事件應變情境。incident response plan 必須依以下精確順序執行——順序錯誤是考試的經典陷阱。

Step 1 — Detect（偵測）。 當 EC2 執行個體角色的憑證從 AWS 以外使用，或 root user 從異常地點登入時，GuardDuty 會發出 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS 或 UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B finding。S3 儲存桶上的 CloudTrail 資料事件也能為 Detective 提供攻擊者的 API 呼叫歷史。

Step 2 — Preserve evidence（保存證據）。 在變更任何設定之前，確保 CloudTrail 記錄至啟用 S3 Object Lock 合規模式的 S3 儲存桶。如果受影響帳號的 CloudTrail 尚未集中化，手動對其 CloudTrail 儲存桶拍攝快照。

Step 3 — Invalidate the credentials（撤銷憑證）。 對於 access key 外洩的 IAM user，立即呼叫 aws iam update-access-key --status Inactive。不要刪除——inactive 的金鑰保留稽核軌跡；刪除的金鑰會失去歸因依據。對於暫時憑證外洩的 IAM role，附加帶有 Condition 條件（aws:TokenIssueTime）的 inline deny-all 政策，撤銷當前時間點之前的活躍 session（撤銷活躍 session 模式）。

Step 4 — Apply a deny-all SCP（套用 deny-all SCP）。 若入侵情形嚴重，在 OU 層級附加一個 SCP，拒絕受影響帳號的所有操作（僅保留 IR 應變人員角色的例外）。這相當於 AWS 版本的拔掉網路線。

Step 5 — Rotate（輪換）。 輪換 principal 可存取的所有其他憑證：Secrets Manager 中的資料庫密碼（使用輪換 Lambda）、KMS 客戶託管金鑰（輪換或替換 alias）、Parameter Store 中的 API 金鑰、第三方 token。

Step 6 — Investigate root cause（調查根本原因）。 使用 Detective 追蹤 principal 的完整 API 歷史，識別最初入侵路徑（金鑰是否出現在公開 GitHub 儲存庫？EC2 metadata service 的 IMDSv1 是否遭到抓取？），並進行修補。

Step 7 — Recover and document（復原與記錄）。 透過最小權限角色核發新憑證，在 incident response plan runbook 中加入新的 IOC，並只在 finding 類型確定為已知誤報時才新增 GuardDuty 抑制規則。

EC2 執行個體隔離 Runbook

當 GuardDuty 發出 Backdoor:EC2/C&CActivity.B!DNS 或 CryptoCurrency:EC2/BitcoinTool.B finding 時，incident response plan 必須在不摧毀揮發性證據的前提下隔離執行個體以進行鑑識採樣。標準 runbook 順序：

1. 從 Auto Scaling Group 脫離。 使用 aws autoscaling detach-instances --no-should-decrement-desired-capacity，讓 ASG 啟動替換執行個體並停止向受入侵主機發送流量。執行個體仍存活，但不再位於負載均衡的機群中。

2. 以隔離 SG 替換 security group。 建立一個不允許任何入站與出站流量（僅開放鑑識應變人員的 bastion 例外）的 security group，透過 aws ec2 modify-instance-attribute --groups sg-quarantine 套用。這在不關閉執行個體的情況下切斷 C2 流量，讓記憶體內容得以保存。

3. 對每個已掛載的 EBS volume 拍攝快照。 呼叫 aws ec2 create-snapshot 針對每個 volume。以 GuardDuty finding ID 和事件票號標記快照。透過跨帳號 KMS 加密快照複製，將快照複製到鑑識帳號。

4. 透過 SSM 採集 memory dump。 若執行個體已安裝 SSM Agent（建議作為基線配置），呼叫一個 Run Command document，執行 lime 或 avml 將記憶體轉儲至啟用 Object Lock 的鑑識 S3 儲存桶。

5. （選擇性）移至鑑識 VPC。 若需要網路層級分析，將 ENI 替換至隔離的鑑識 VPC 子網路，即可在不影響生產環境的情況下進行封包擷取。

6. 保存證據後才終止。 終止操作會釋放 instance store 和臨時磁碟，因此必須是最後一個步驟。

鑑識帳號模式

AWS Security Reference Architecture 建議設置一個專用的 Forensics OU，其中包含一個或多個平時為空且鎖定的鑑識帳號。事件發生時，EBS snapshots 和 memory dumps 被複製進入鑑識帳號，應變人員可在乾淨的分析執行個體上掛載它們，而不會污染來源環境。

鑑識帳號的關鍵控制：

• S3 儲存桶設定合規模式的 Object Lock 作為證據保存
• KMS 金鑰政策僅允許具名 IR 角色執行 kms:Decrypt
• SCP 防止鑑識帳號向生產環境發起出站連線
• 在證據 S3 儲存桶上啟用 CloudTrail 資料事件，讓每次讀取都被記錄

透過委派管理員進行多帳號部署

現實世界的 incident response plan 橫跨擁有數十個帳號的組織。SCS-C02 期望你了解如何透過委派管理員在整個組織部署每項偵測服務，而不是登入每個成員帳號。

標準模式，以 AWS Security Reference Architecture 為依據：

1. 在 Security OU 中指定一個 Security Tooling 帳號。
2. 從 Organizations 管理帳號，將 Security Tooling 登記為 GuardDuty、Security Hub、Macie、Inspector、Config、Detective 和 IAM Access Analyzer 的委派管理員。
3. 從 Security Tooling 帳號，透過 auto-enable 設定為「所有現有和未來成員帳號」啟用每項服務。
4. 在 Security Hub 中，指定單一finding 聚合器 region（北美工作負載通常為 us-east-1），並將所有其他區域連結至此。
5. 部署集中化 Organization Trail，寫入 Log Archive 帳號中啟用 Object Lock 的 S3 儲存桶。
6. 在每個成員帳號中設置跨帳號 IR 角色，僅可從 Security Tooling 帳號搭配 MFA 進行 assume。

以 Step Functions 自動化 Incident Response Plan

當 incident response plan 超出簡單 Lambda 函數的能力範圍，AWS Step Functions 就成為編排層。Step Functions state machine 能將 EC2 隔離 runbook 表達為確定性圖形：並行分支分別執行快照 + memory dump + SG 替換，Choice state 決定是否觸發鑑識 VPC 移轉，Wait state 在終止前等待人工核准，每個 AWS SDK 呼叫都有內建的 retry/catch 機制。

Step Functions 與 EventBridge 原生整合：Security Hub finding 落入事件匯流排，EventBridge rule 的目標為 arn:aws:states:...:stateMachine:IncidentResponse，state machine 以完整的 ASFF JSON 作為輸入。在 state machine 內部，intrinsic functions 提取 Resources[0].Id 取得執行個體 ARN，提取 AwsAccountId 得知要 assume role 至哪個成員帳號，提取 Severity.Label 以 critical-vs-high 進行分支。

成熟的 incident response plan 擁有多個 state machines——每個事件類型一個（IAM 入侵、EC2 入侵、S3 曝露、Macie 敏感資料外洩）——以及一個頂層「路由器」state machine，根據 ASFF Types 決定呼叫哪個子 state machine。

人工介入核准

incident response plan 中並非所有步驟都應完全自動化。終止操作、金鑰刪除及可能封鎖人員存取的 SCP 變更，都需要設置確認關卡。Step Functions 透過 Wait for Callback（.waitForTaskToken） 整合模式實作：state machine 暫停，透過 Slack/PagerDuty/email 傳送附有回呼 URL 的核准請求，僅在核准者點擊後繼續執行。回呼 URL 有效期短暫（預設 24 小時），並與 IR Commander 的已驗證 session 綁定。

對於 SCS-C02，請認識到自動化不等於無人值守。考試會獎勵同時結合自動化（即時圍堵）和人工關卡（不可逆的消除操作）的答案。

事後檢討與持續改善

incident response plan 第七個階段是事後事件回顧。在事件關閉後五個工作天內，IR Commander 主持一場無責備的回顧會議，涵蓋：時間軸重建、MTTD（平均偵測時間）、MTTR（平均應變時間）、偵測覆蓋缺口、runbook 覆蓋缺口、需加入威脅情報資料庫的 IOC，以及防止再次發生所需的 IaC 變更。

產出回饋至：

• 新的 AWS Config rules，偵測引發事件的錯誤設定
• 新的 Security Hub custom insights，主動浮現類似模式
• 新的 GuardDuty suppression rules，僅針對已確認的誤報類型
• 更新的 SSM runbooks，納入過程中出現的手動步驟
• 更新的 Step Functions playbooks，若編排邏輯有遺漏的情況
• 更新的 SCPs，若爆炸半徑可在整個組織層面進一步縮小

SCS-C02 事件應變考題常見陷阱

綜合社群大量 SCS-C02 考試心得，以下是 incident response plan 考題反覆出現的陷阱：

陷阱 1 — 選擇「手動」答案。 任何選項說「SOC 分析師將手動...」或「發 email 等待審核」的，幾乎必定錯誤。考試偏好自動化圍堵。

陷阱 2 — 忘記跨區域聚合。 考題常描述多區域工作負載並詢問如何集中 findings。答案涉及 Security Hub finding 聚合器 + 組織層級委派管理員，而非各區域 SNS topic。

陷阱 3 — 混淆 Detective 和 Security Hub。 Security Hub 聚合 findings；Detective 調查它們。Detective 用於 Analyze 階段，Security Hub 用於 Detect/triage 階段。

陷阱 4 — 刪除 access key 而非停用。 刪除會摧毀歸因依據。Inactive 則保留。SCS-C02 請務必先選 Inactive。

陷阱 5 — 在快照之前終止 EC2。 終止會釋放 instance store 和臨時磁碟。請先快照。

陷阱 6 — 使用 IMDSv1。 許多憑證外洩情境以 IMDSv1 為前提；預防答案是透過 SCP 和 Config rule 強制執行 IMDSv2。

陷阱 7 — 忘記在證據儲存桶設定 Object Lock。 若無 Object Lock，攻擊者（或錯誤設定的 Lifecycle rule）可能銷毀證據。受監管的工作負載請使用合規模式。

常見問題

Q1：AWS incident response plan 中 runbook 和 playbook 的差異是什麼？

Runbook 是針對一項具體任務（例如「隔離 EC2 執行個體」）的確定性逐步程序，以 SSM Automation Document 實作。Playbook 是更高層次的編排，將多個 runbook 加上決策和人工核准結合起來，應對一類事件，以 Step Functions state machine 實作。incident response plan 同時使用兩者：runbook 負責操作細節，playbook 負責協調編排。

Q2：偵測到 IAM access key 入侵時，應該刪除還是停用？

請務必先停用，將金鑰狀態設為 Inactive。這能立即阻止攻擊者，同時保留 CloudTrail 歸因，讓調查人員能重建攻擊者的行為。調查階段完成、不再需要歸因歷史 API 呼叫後，再刪除金鑰。

Q3：ASFF 如何幫助我的 incident response plan？

ASFF（AWS Security Finding Format）是所有 AWS 安全服務發出 findings 所遵循的標準化 JSON schema。若無 ASFF，你的 incident response plan 就需要為 GuardDuty、Macie、Inspector 等各自撰寫解析器。有了 ASFF，單一 EventBridge rule pattern 就能比對任何來源的 findings，你的 Step Functions playbooks 也有可預期的輸入格式。

Q4：我能不登入每個帳號，就將 GuardDuty、Security Hub 及其他偵測服務部署至所有帳號嗎？

可以——使用 AWS Organizations 的委派管理員。從管理帳號將單一 Security Tooling 帳號登記為每項服務的委派管理員，然後啟用「新帳號自動啟用」。現有帳號會自動加入，未來任何新成員帳號也會自動加入。這是 AWS Security Reference Architecture 的標準模式。

Q5：EC2 執行個體隔離步驟的正確順序為何？

1）從 Auto Scaling Group 脫離（讓 ASG 啟動替換執行個體，load balancer 停止發送流量），2）以隔離 SG 替換 security group（不允許任何入站或出站，僅開放 IR bastion 例外），3）快照所有已掛載的 EBS volumes，4）透過 SSM Run Command 採集 memory dump，5）選擇性移至鑑識 VPC，6）保存證據後才終止。絕對不能先終止。

Q6：鑑識證據（快照、memory dumps、CloudTrail 日誌）應儲存在哪裡？

儲存於 Forensics OU 內的專用鑑識帳號中，存放在合規模式 Object Lock 的 S3 儲存桶裡。加密證據的 KMS 金鑰應設定金鑰政策，僅允許具名 IR 應變人員角色解密。在證據儲存桶上啟用 CloudTrail 資料事件，以建立完整的證據保管鏈。

Q7：如何處理橫跨多個 AWS 區域的事件？

在單一 home region 啟用 Security Hub 跨區域 finding 聚合（通常選擇距 IR 團隊最近的區域）。所有區域的所有 findings 流入 home region 的事件匯流排。僅在聚合器 region 撰寫 EventBridge rules。原始區域保留在 ASFF 的 Region 欄位中，讓 playbooks 能路由至區域特定的操作。

Q8：我的 incident response plan 應預先建立哪些角色？

至少包含：IR Commander（決策權威）、Security Engineer（執行圍堵和消除）、SOC Analyst（監控偵測資料來源並進行分類）、Application Owner（評估業務衝擊）、Compliance Officer（處理外部通報）。每個角色應對應到 Security Tooling 帳號中一個預先建立的 IAM 角色，僅可搭配 MFA 進行 assume，且權限範圍限定於 incident response plan 該階段所需。

Q9：SCS-C02 考試需要背 ASFF 欄位名稱嗎？

不需要背出所有 ASFF 欄位，但必須在情境題中識別關鍵欄位：Types、Severity.Label、Resources[]、AwsAccountId、Workflow.Status 及 RecordState。關於 EventBridge 過濾模式或 finding 抑制的考題，常常取決於這些欄位。

Q10：Incident response plan 如何與 AWS Organizations SCP 整合？

SCP 是最後手段的圍堵工具。在嚴重事件中，incident response plan 可在受影響帳號的 OU 附加 deny-all SCP（保留 IR 應變人員角色的例外），立即撤銷該帳號的所有權限——等同於拔掉網路線。SCP 也作為事後檢討的預防措施，透過 Lessons Learned 在整個組織強制執行基線控制，例如僅限 IMDSv2 或禁止公開 S3。

總結

SCS-C02 的 incident response plan 是七個階段（Prepare、Detect、Analyze、Contain、Eradicate、Recover、Lessons Learned）、七項偵測服務（GuardDuty、Security Hub、Macie、Inspector、Config、Detective、IAM Access Analyzer）、一套共同 finding 格式（ASFF）、一條事件匯流排（EventBridge）和一份清晰 RACI 人員角色矩陣的協同編排。熟練掌握 IAM 憑證入侵序列、EC2 隔離 runbook 順序，以及 runbook 與 playbook 的差異，你就能在 SCS-C02 考試拋出的任何 incident response plan 情境中辨認出正確答案。請務必偏好自動化圍堵、在修復前保存證據、停用優先於刪除，以及委派管理員優先於逐帳號設定。incident response plan 是 Domain 1 的連結組織——Domain 1 的其他所有主題（威脅偵測、受入侵資源應變）都與它緊密相扣。