受駭資源數位鑑識：Amazon Detective、EBS Snapshot 與 Athena 完整指南

受駭資源數位鑑識總覽

受駭資源數位鑑識（compromised resources forensics）是一門在攻擊者可能已掌控 AWS 工作負載的情境下，對其進行封鎖、擷取與分析的學科，同時必須維護完整的數位物證監管鏈（chain of custody）。在 SCS-C02 考試中，受駭資源數位鑑識直接對應 Domain 1 Task 1.3——「回應受駭資源與工作負載」——並橫跨 Detective、EBS、S3、Athena、Systems Manager、EventBridge、Lambda 與 Step Functions 等服務。精通此主題，是整個佔比 14% 的 Domain 1 中槓桿效益最高的單一課題，因為幾乎所有關於受駭資源的情境題都要求你選出一個既能封鎖威脅、又能保全鑑識證物的答案。

官方 AWS Security Incident Response Guide 將受駭資源數位鑑識定義為五階段循環：隔離（isolate）、蒐集（collect）、分析（analyze）、清除（eradicate）、復原（recover）。SCS-C02 每個階段都會考。預期會遇到以下類型的題目：對受駭 EC2 instance 採取哪一個行動序列，能同時阻斷攻擊者的橫向移動並保存記憶體狀態以供鑑識分析？當來源磁碟區以客戶自管 KMS key 加密時，如何與獨立鑑識帳號共享 EBS snapshot？如何以 Athena 查詢存放在 S3 中的 CloudTrail 日誌，以判定遭竊 IAM 憑證的爆炸半徑？

本主題將逐一走過完整的生命週期，包含具體的服務選擇、手冊模式（runbook patterns），以及讓多數考生落入陷阱的誘答選項。讀完之後，你應能看到任何受駭資源情境就立刻辨識出題目在問的是隔離、蒐集、分析、保全還是自動化——並精確知道哪些 AWS 服務解決了每個階段的問題。

受駭資源數位鑑識是一套有紀律的流程：封鎖疑似遭惡意控制的 AWS 工作負載、在監管鏈完整的前提下擷取揮發性與非揮發性證物、透過行為圖分析與日誌查詢找出根因，並將所有數位物件保存於防篡改的儲存空間。在 AWS 中，受駭資源數位鑑識結合了手冊自動化（Lambda、Step Functions、Systems Manager）、證物服務（EBS snapshots、S3 Object Lock）與分析服務（Detective、Athena）。參考：AWS Security Incident Response Guide — Develop Forensic Capabilities。

為什麼受駭資源數位鑑識對 SCS-C02 如此重要

SCS-C02 考試指南明確列舉了受駭資源數位鑑識的技能項目：隔離 EC2 instance、擷取 EBS snapshot 與記憶體傾印、以 Detective 進行根因分析、以 Athena 查詢 S3 中的日誌、以及使用 S3 Object Lock、隔離鑑識帳號、S3 Lifecycle 與複寫來保全鑑識物件。每一個考點都是一道等著被出題的題目。受駭資源數位鑑識是 Domain 1 中唯一將實戰回應手冊與證物保全治理結合在一起的主題——而這種多服務合成的考驗，正是 Specialty 等級考試的標誌性特徵。

除了考試以外，受駭資源數位鑑識之所以重要，是因為真實攻擊者在現實時間中造成真實損害。受駭 EC2 instance 保留其安全群組、IAM instance profile 和網路連線的時間越長，洩漏的憑證就越多、橫向移動就越廣，攻擊者也有更多時間竄改日誌。受駭資源數位鑑識因此既是一種技術實踐，也是一種操作反射。

三種模式主導了 SCS-C02 中受駭資源數位鑑識的考題：

隔離優先於終止 — 絕對不要在 EBS snapshot 與記憶體擷取完成前終止受駭 EC2 instance，那等同於銷毀證物。
跨帳號共享加密 snapshot 必須授予 KMS 權限 — 加密的 snapshot 必須先透過 key policy 或 grant 共享 KMS key，鑑識帳號才能複製。
S3 Object Lock compliance mode 用於法律保全 — 對於法律層級的鑑識物件，governance mode 是誘答；只有 compliance mode 才是真正的不可刪除，即使 root user 也不例外。

參考：AWS Security Incident Response Guide — Forensic Investigation。

白話文解釋

讓我們把 compromised resources forensics 從 AWS 服務術語拆解成三個直觀的類比，這樣你之後看任何 compromised resources 題目都可以反射性地對應到正確的階段。

類比一：犯罪現場勘查 SOP（CSI 流程）。當警察接到通報抵達犯罪現場，第一件事不是把嫌犯抓起來開車送警局，而是先拉封鎖線、拍照、採集 DNA、紀錄屍體姿勢、收集彈殼。為什麼？因為一旦人和證物移動了，現場就毀了。AWS 的 compromised resources forensics 完全一樣：你看到 GuardDuty 的 finding 跳出某台 EC2 在挖礦，第一反射不是按下 terminate，而是先「拉封鎖線」（換成 deny-all security group、拔出 ASG、撤銷 IAM instance profile）、再「拍照採集 DNA」（snapshot EBS、dump 記憶體、複製 instance metadata），最後才「把嫌犯帶走」（quarantine 到隔離 VPC 或 terminate）。考試最常見的陷阱題就是先終止 instance — 這等於兇案現場沒採證就把屍體火化，整個 forensic chain of custody 都壞掉。

類比二：臺灣地檢署的傳染病隔離兼搜索令流程。想像地檢署接獲線報，某棟大樓同時可能是傳染病感染源也是犯罪現場。檢察官的標準動作是：第一步封鎖大樓出入口（對應換成隔離 VPC、deny-all SG，讓受駭 instance 無法對外通訊）；第二步由法醫鑑識人員在大樓內採集所有跡證——指紋、現金帳冊、監視器硬碟、血跡棉棒（對應 EBS snapshot、memory dump、log 收集）；第三步由流行病學調查官畫出接觸者地圖（對應 Detective behavior graph 找出 instance 連到哪些其他 resources、被哪些 IAM principals 操作過）；第四步檢察官依調查結果聲請搜索票和逮捕令（eradicate：撤掉 IAM key、rotate secrets、patch vulnerability）；第五步建築重新開放（recover：從 clean AMI 重建）。Amazon Detective 在這個類比裡就是流行病學調查官——它不治療病人，它畫出感染地圖。

類比三：公證人時間戳與銀行金庫保全。台灣法院認可的公文書必須有公證人蓋章，且一旦公證完成，任何人都不能回頭修改文件內容。更嚴格的做法是把這份文件鎖進銀行金庫，只有在特定保留期限到期後才能取出銷毀。在 AWS forensics 的世界裡，這就是 S3 Object Lock compliance mode——就像公證人蓋章（WORM 寫入後不可改）加銀行金庫（compliance mode 鎖定，連 root user 都無法在到期前刪除）。再加上「把金庫設在攻擊者絕對進不去的另一棟銀行大樓」（isolated forensic account），以及「這份文件同時在台北和高雄各有一份公證副本」（S3 cross-region replication）。為什麼不用 governance mode？因為 governance mode 的檔案可以被有 s3:BypassGovernanceRetention 權限的內部人員刪掉——律師會說這不算法庭認可的 immutable evidence。為什麼要放到 isolated forensic account？因為如果攻擊者已經拿到原 production account 的 admin credential，他可以順手把證據刪光；只有把證據存到他完全進不去的另一個 account，chain of custody 才不會被質疑。

把這三個類比記熟，你看到題目「a security engineer suspects an EC2 instance is compromised, what is the FIRST step」就會反射性想到「先拉封鎖線、別動屍體」——答案絕對不是 terminate，而是 isolate 加 snapshot。看到題目「preserve forensic evidence for 7 years against insider threat」就會反射性想到「法庭公證等級需要 compliance mode 加獨立帳號金庫」——答案不是 governance mode 也不是普通 lifecycle policy。

Phase 1 — Isolation：封鎖受駭 EC2 Instance

受駭資源數位鑑識的第一個階段是隔離（isolation）。隔離的目標是在不破壞證物的前提下終止攻擊者的活動。官方 Amazon EC2 Incident Response runbook 模式列出四項依序執行的隔離動作：

將 instance 從任何 Auto Scaling group 中卸離，呼叫 DetachInstances 並設定 ShouldDecrementDesiredCapacity=false，如此 ASG 就不會替換它。這能防止 ASG 健康檢查在你蒐集證物前就終止 instance。
將所有掛載的安全群組替換成 deny-all 鑑識 SG，完全沒有入站規則，出站只允許連到鑑識蒐集 bucket 的 VPC endpoint 與 Systems Manager endpoint。修改 SG（而非 NACL）是首選，因為 SG 的修改具有狀態性且立即生效，而 NACL 的修改不會丟棄既有連線。
移除 IAM instance profile，呼叫 DisassociateIamInstanceProfile。這能阻止 instance 繼續透過 EC2 metadata service 使用遭竊的角色憑證呼叫 AWS API。如果攻擊者已快取了暫時憑證，必須額外透過帶有 aws:TokenIssueTime 條件的 IAM policy 撤銷所有有效 session。
暫時啟用 DisableApiTermination=true 直到你準備好，以防止意外銷毀；等到要清除時再關閉。

有一類常見的受駭資源數位鑑識陷阱題會給你四個選項，其中一個是「立即停止 EC2 instance」，另一個是「終止並讓 ASG 替換」。兩者都會破壞證物。停止（Stopping） EBS 支援的 instance 會清空 RAM（你會失去記憶體鑑識——正在執行的程序、已解密的機密、記憶體中的惡意程式）。終止（Terminating） 在預設 DeleteOnTermination=true 的情況下也會銷毀根磁碟區。永遠要先透過 SG 和 IAM 卸離完成隔離、再 snapshot、最後才視需要清除。參考：EC2 Instance Lifecycle。

對於受管服務（如 EKS 或 ECS）中的 instance，隔離模式略有調整：透過 kubectl cordon 阻止新 pod 被排程到該節點、將非系統 pod 排走（drain）到其他節點，再對底層 EC2 主機套用 deny-all SG。對於 Lambda 的受駭資源數位鑑識則有所不同——你無法對 Lambda runtime 做 snapshot，因此等效操作是將函式的保留並行數設為 0（有效停止呼叫），同時保留 CloudWatch Logs 與 X-Ray 追蹤記錄。

Phase 2 — Collection：EBS Snapshot 與記憶體傾印

一旦受駭 EC2 instance 被隔離，蒐集（collection）階段便為後續的受駭資源數位鑑識分析擷取證物。有兩種證物類型至關重要：非揮發性（磁碟）與揮發性（記憶體）。

EBS Snapshot 鑑識

EBS snapshot 鑑識是受駭資源數位鑑識的基礎。操作程序如下：

對受駭 instance 上所有掛載的 EBS 磁碟區（包含根磁碟區）呼叫 CreateSnapshot。將 snapshot 標記為 Forensics=true、IncidentID=<id>、SourceInstanceID=<i-xxx>、CapturedAt=<timestamp>。
如果磁碟區以客戶自管 KMS key 加密，snapshot 會繼承該加密。若要將 snapshot 複製或共享給鑑識帳號，必須透過 kms:CreateGrant 將 KMS key 共享給鑑識帳號 principal，或在跨帳號複製時以鑑識帳號的 KMS key 重新加密。
利用 EBS Direct API（ListSnapshotBlocks + GetSnapshotBlock）計算 snapshot block list 的 SHA-256 雜湊值，以建立監管鏈完整性。將雜湊值與案件檔案一同儲存在獨立的 S3 Object Lock bucket 中。
在鑑識專用 EC2 instance 中，將 snapshot 掛載為新的 EBS 磁碟區，使用分析工具包（Volatility、Sleuth Kit、plaso）進行分析。掛載時必須以唯讀模式，以防止時間戳遭污染。

將以客戶自管 KMS key 加密的 EBS snapshot 共享給隔離鑑識帳號時，三件事必須同時到位：

Snapshot 的 CreateVolumePermission 包含鑑識帳號 ID。
KMS key policy 允許鑑識帳號 principal 呼叫 kms:Decrypt、kms:CreateGrant 與 kms:DescribeKey。
鑑識帳號的 IAM role 具有對應的 IAM 權限來使用該 KMS key。

任一項缺少，鑑識帳號就會看到 KMSKeyNotAccessibleFault。參考：Share an Amazon EBS Snapshot。

透過 Systems Manager 擷取記憶體

記憶體傾印擷取是受駭資源數位鑑識中最時間敏感的部分——一旦 instance 被停止或終止，RAM 就永遠消失了。使用 AWS Systems Manager Run Command 在運行中的 instance 上執行適當的工具：

Linux instance：呼叫 AWS-RunShellScript 安裝並執行 LiME（Linux Memory Extractor），透過 aws s3 cp 將 .lime 檔案直接輸出到 S3 鑑識 bucket。部分團隊使用 AVML（Microsoft 的使用者空間 Linux 記憶體工具），它是靜態連結的，無需編譯 kernel module。
Windows instance：呼叫 AWS-RunPowerShellScript 執行記憶體擷取工具（如 DumpIt、Magnet RAM Capture 或 Belkasoft Live RAM Capturer），同樣將 .dmp 輸出重導至 S3。
擷取完成後，在鑑識帳號離線使用 Volatility 3 分析記憶體映像：vol.py -f memory.lime windows.pslist、linux.bash、linux.malfind 等。

受駭資源數位鑑識團隊選用 SSM Run Command 而非 SSH，原因如下：

SSM 不需要開放入站連接埠（你的 deny-all SG 可以維持 deny-all；SSM 透過 VPC endpoint 使用出站 HTTPS）。
每條指令及其輸出都會記錄在 CloudTrail 與 SSM command history 中——這本身就是鑑識證物。
不需要分發 SSH key，因此不會有「應急回應人員是否修改了 ~/.ssh/authorized_keys」的監管鏈疑慮。

參考：Systems Manager Run Command。

隔離 vs 終止

EBS snapshot 與記憶體傾印安全存入帶有 Object Lock 的 S3 後，你有兩個選擇：終止受駭 instance，或將其移至隔離鑑識 VPC 進行即時行為分析。多數組織選擇終止，因為每一個仍在運行的受駭 instance 都是風險面。部分成熟團隊選擇隔離——將 ENI 移至鑑識 VPC，出站流量被 null route 但透過 VPC Traffic Mirroring 鏡像到 Suricata 感測器——以便研究攻擊者的即時行為。考試傾向給出「snapshot 後終止」的答案，除非情境明確要求行為分析。

Phase 3 — Analysis：Amazon Detective 行為圖

證物蒐集完成後，受駭資源數位鑑識進入根因分析階段。Amazon Detective 是這個階段最重要的 AWS 服務。Detective 無需任何設定便會自動擷取三個資料來源：VPC Flow Logs、CloudTrail management events 與 GuardDuty findings。它以這些資料持續更新一個行為圖（behavior graph），將 IAM principals、EC2 instance、IP 位址與 AWS API 呼叫連結成可瀏覽的時間軸。

行為圖是一個圖形資料庫（底層使用 Amazon Neptune），以節點與邊將 AWS 實體（IAM user、IAM role、EC2 instance、AWS 帳號、IP 位址、finding ID）依據在 CloudTrail 與 VPC Flow Logs 中觀察到的活動相互連結。Detective 持續更新圖形，讓調查人員得以從 GuardDuty finding 轉向「這個 IP 還碰了什麼？」或「這個 IAM role 在過去 30 天做了什麼？」——完全不需要寫任何 SQL 查詢。參考：Amazon Detective Behavior Graph。

在受駭資源數位鑑識期間，Detective 的調查工作流程：

開啟 GuardDuty finding（例如 UnauthorizedAccess:EC2/SSHBruteForce 或 CryptoCurrency:EC2/BitcoinTool.B）——Detective 在內嵌處加入「在 Detective 中調查」連結。
Detective 開啟帶有三個時間軸面板的 finding profile：API 呼叫量、網路流量量與成功登入地點。異常以紅色標示。
轉向受駭 instance 的 resource profile——查看每個對此 instance 呼叫 API 的 IAM principal、每個連線的 IP，以及它通訊過的其他所有 instance。
轉向任何可疑 IP 的 IP address profile——查看你環境中的哪些其他 AWS 資源曾被該 IP 存取。這是找出**爆炸半徑（blast radius）**的方法。
若攻擊者竊取了角色憑證，轉向 IAM role profile——查看以該角色執行的每個 API 呼叫，包含不尋常的 region 或 API action。

Detective 是回答「這次入侵的爆炸半徑是什麼？」最快的單一方式——這正是 SCS-C02 喜歡問的問題。若沒有 Detective，你得手動撰寫半打 Athena 查詢，耗費數小時。

Phase 3b — Athena 查詢 S3 日誌

當受駭資源數位鑑識需要 Detective 無法表達的查詢——通常是跨 CloudTrail、VPC Flow Logs、S3 存取日誌與 ALB 存取日誌的時間邊界 JOIN——Athena 是正確的工具。設定模式如下：

將所有日誌集中存放在專用安全帳號的日誌封存 bucket（AWS Security Reference Architecture 稱之為 Log Archive 帳號）。
為每個日誌來源定義 AWS Glue Data Catalog 資料表。CloudTrail 與 VPC Flow Logs 有官方的分區投影（partition projection）模式，已記載於 Athena CloudTrail 整合指南中。
直接在 Athena 執行鑑識 SQL 查詢。

常用的受駭資源數位鑑識 Athena 查詢：

UserIdentity 時間軸：SELECT eventTime, eventSource, eventName, sourceIPAddress, userAgent FROM cloudtrail WHERE useridentity.arn LIKE '%role/CompromisedRole%' AND eventTime BETWEEN '...' AND '...' ORDER BY eventTime。此查詢可重建攻擊者的 API session。
來源 IP 爆炸半徑：SELECT DISTINCT eventSource, eventName, resources FROM cloudtrail WHERE sourceIPAddress = '1.2.3.4' AND eventTime > '...'。列出來自攻擊者 IP 的所有 API 呼叫。
VPC Flow Logs 橫向移動：SELECT srcaddr, dstaddr, dstport, action FROM vpc_flow_logs WHERE srcaddr = '10.0.1.50' AND action = 'ACCEPT' AND dstport NOT IN (80, 443)——找出受駭 instance 的異常東西向流量。
S3 外洩查核：SELECT key, requester, bytes_sent FROM s3_access_logs WHERE bucket = 'sensitive-data' AND operation = 'REST.GET.OBJECT' AND bytes_sent > 1000000 AND requester LIKE '%CompromisedRole%'。

針對 SCS-C02 受駭資源數位鑑識情境，內化這個對應關係：

「誰在何時呼叫了哪個 API」 → CloudTrail in S3 + Athena
「instance 建立了哪些網路連線」 → VPC Flow Logs in S3 + Athena
「視覺化關係並互動式轉向」 → Amazon Detective
「跨多個安全服務找出 findings」 → AWS Security Hub
「誰存取了哪個 S3 物件」 → S3 server access logs 或 CloudTrail S3 data events
「攻擊者在 instance 內執行了什麼」 → memory dump（Volatility）+ EBS snapshot 檔案系統分析

參考：Querying CloudTrail Logs with Athena。

Phase 4 — 鑑識物件保全

保全鑑識物件是受駭資源數位鑑識中多數考生最低估的部分，在 SCS-C02 考試中大約佔兩道題。威脅模型是：一個擁有 admin 權限的內部人員，或已提權為 admin 的攻擊者，必須無法刪除證物——即使是 root user 憑證也不例外。AWS 提供四個建構元件。

S3 Object Lock — Compliance 與 Governance Mode

S3 Object Lock 是一次寫入多次讀取（WORM）的儲存機制。它有兩種模式：

Governance mode：普通使用者無法刪除物件，但擁有 s3:BypassGovernanceRetention 的 principal 可以覆寫。適用於操作性的「保留勿刪」政策，不適用於法律等級的證物。
Compliance mode：任何使用者（包含 AWS 帳號 root user）都無法在保留期限到期前刪除物件。保留期限本身只能延長，絕不能縮短。這是唯一滿足 SEC 17a-4(f)、CFTC、FINRA 以及多數 HIPAA/GxP 保留要求的模式。

對於受駭資源數位鑑識，永遠使用 compliance mode，保留期限至少與你的事故回應政策要求一樣長（通常為 1、3 或 7 年）。

多道 SCS-C02 練習題會呈現一個以 Object Lock governance mode 設定的鑑識 bucket，並詢問為什麼內部調查團隊抱怨證物遭篡改。答案是「governance mode 允許擁有 s3:BypassGovernanceRetention 的使用者刪除物件」。Compliance mode 才是法律等級受駭資源數位鑑識證物的正確選擇——即使是 AWS Support 也無法在保留期限到期前刪除 compliance 鎖定的物件。參考：S3 Object Lock Modes。

隔離鑑識帳號

鑑識帳號是同一個 Organization 中的一個獨立 AWS 帳號，但位於專用的鑑識 OU 中。它具有以下特性：

擁有自己的鑑識 KMS key（如此 production 帳號遭入侵也不會取得鑑識加密 key 的存取權）。
在鑑識 OU 層級套用的 SCP，明確拒絕對鑑識資源執行 s3:DeleteObject、s3:DeleteBucket、s3:PutBucketLifecycleConfiguration、kms:ScheduleKeyDeletion——即使 root 也不例外。
跨帳號 IAM role 供案件指定調查人員唯讀存取，並以 MFA 和 CloudTrail Lake breakglass logging 把關。
VPC 無對外 internet egress，只有到 S3 和 KMS 的 VPC endpoint。

鑑識帳號是 snapshot 被複製過去、記憶體傾印被落地、Athena 查詢執行，以及 Detective 可以獨立圖形模式啟用的地方。等到攻擊者觸及你的 production root，他仍然找不到任何進入鑑識帳號的路徑。

S3 Lifecycle 轉移至 Glacier Deep Archive

鑑識物件體積龐大（多 TB 的記憶體傾印、完整的 EBS snapshot 匯出），且在活躍調查結束後存取頻率極低。S3 Lifecycle 政策在 90 或 180 天後將物件從 S3 Standard 移至 S3 Glacier Deep Archive，成本降低約 95%。Object Lock 保留期限在儲存類別轉換後仍持續有效——Glacier Deep Archive 遵守 Object Lock 保留計時器。

S3 跨區域複寫以提升高可用性

S3 Cross-Region Replication（CRR）將鑑識物件複製到第二個 region。透過同帳號、同 Object Lock 模式的複寫，你可以防範 region 級別的災難，以及攻擊者以某種方式破壞主要 bucket 的情況（例如勒贖 KMS key）。設定複寫時，將 DeleteMarkerReplication=Disabled，使來源端嘗試刪除時不會在目的端產生刪除標記。

對於 Specialty 等級的受駭資源數位鑑識證物保全，請疊加以下四層：

S3 Object Lock compliance mode — 對所有 principal（包含 root）的不可變性。
隔離鑑識帳號 + SCP — 防止跨帳號觸及。
S3 Lifecycle 轉至 Glacier Deep Archive — 具成本效益的長期保留。
S3 Cross-Region Replication — 防範 region 故障或針對性勒贖軟體。

缺少任何一層都是常見的 SCS-C02 錯誤答案模式。參考：Logging Strategies — Building a Multi-Account Logging Architecture。

Phase 5 — 清除與復原

分析確認根因後，清除（eradication）移除攻擊者的立足點：

輪換攻擊者可能接觸過的所有憑證：IAM access key、IAM Identity Center session policy、AWS Secrets Manager secret、SSH host key、應用程式 JWT。
在角色的 trust policy 或掛載的 deny 上，以帶有 aws:TokenIssueTime 條件（設為當前時間戳記）的 inline policy 全域撤銷有效的 IAM role session。
修補導致初始存取的漏洞——通常透過 AWS Systems Manager Patch Manager 修補未更新的 OS CVE，或透過部署管道修復應用層缺陷。
更新偵測控制，使相同的攻擊模式下次能更快發出警報：新增 GuardDuty filter、新增 Security Hub custom insight、新增 EventBridge rule。

復原（recovery）從已知良好狀態重建工作負載：

從由 EC2 Image Builder 全新建置的強化 AMI 啟動新 EC2 instance——即使受駭 AMI「看起來很乾淨」也絕不重用。
從已由 Detective 建立的時間軸所驗證完整性、在入侵前建立的 AWS Backup recovery point 還原應用程式資料。
進行事後回顧並更新手冊。

自動化：EventBridge → Step Functions → Lambda

手動的受駭資源數位鑑識太慢。成熟的模式是完全自動化的手冊執行。參考架構如下：

GuardDuty 產生 finding（例如 Trojan:EC2/BlackholeTraffic）。
Finding 透過 GuardDuty 預設的 event bus 整合流入 EventBridge。
EventBridge rule 比對 source = aws.guardduty AND detail.severity >= 7，並以 Step Functions state machine 為目標。
Step Functions state machine 將手冊各階段編排為離散狀態：
- IsolateInstance（Lambda — 呼叫 ModifyInstanceAttribute 替換 SG，並呼叫 DisassociateIamInstanceProfile）
- SnapshotVolumes（Lambda — 迭代磁碟區並呼叫 CreateSnapshot）
- CaptureMemory（Lambda — 以記憶體傾印文件呼叫 SSM SendCommand，並以 Step Functions wait state 等待 SSM 指令完成）
- CopyEvidenceToForensicAccount（Lambda — 將 snapshot 與 S3 物件複製至鑑識帳號）
- NotifySOC（Lambda — 推送至 SNS、PagerDuty、Slack）
- OptionallyTerminate（Choice state — 僅在 severity >= 8 時執行）

單一 Lambda 函式上限 15 分鐘，無法編排完整的受駭資源手冊（光是記憶體擷取就可能超過 15 分鐘）。Step Functions 提供：

每個狀態的指數退避和抖動（jitter）重試
長時間等待 SSM 指令而不需要支付 Lambda 閒置費用
主控台中的視覺化 state machine 介面——凌晨三點發生事故時非常有價值
每個狀態的成功／失敗率整合 CloudWatch 指標
高流量低延遲事件使用 Express workflow；長時間執行的鑑識手冊使用 Standard workflow

參考：Step Functions for Incident Response。

手冊本身以版本控制的形式儲存為 Systems Manager Automation 文件或 CloudFormation/CDK 定義。SCS-C02 期望你能辨認這個模式：GuardDuty → EventBridge → 編排 → Lambda action，每個 Lambda 只執行一個有界限的步驟。

受駭資源數位鑑識常見錯誤

請避免以下行為——每一項都是 SCS-C02 的錯誤答案模式：

在 snapshot 之前終止 instance。 銷毀證物。永遠先隔離、再蒐集、再終止。
使用 NACL 而非 SG 進行隔離。 NACL 是無狀態的，不會丟棄既有連線；SG 會（透過移除所有規則來有效阻斷）。
共享加密 snapshot 時未共享 KMS key。 鑑識帳號會看到 KMSKeyNotAccessibleFault。
對法律證物使用 S3 Object Lock governance mode。 擁有 s3:BypassGovernanceRetention 的內部人員可以刪除。
將鑑識物件存放在與入侵來源相同的帳號中。 攻擊者取得 root = 證物遭銷毀。
透過 SSH 而非 SSM Run Command 執行記憶體擷取。 需要開放入站連接埠、沒有自動 CloudTrail 稽核，且有 key 分發的管理負擔。

參考：AWS Security Incident Response Guide — Common Anti-Patterns。

服務對照參考表

SCS-C02 在受駭資源數位鑑識主題下會參考的每個服務速查：

Amazon EC2 — 主要的受駭資源。使用 ModifyInstanceAttribute（SG）、DisassociateIamInstanceProfile、CreateSnapshot、StopInstances/TerminateInstances。EC2 文件。
Amazon EBS — 磁碟證物。CreateSnapshot，透過 ModifySnapshotAttribute 進行跨帳號共享。EBS Snapshots 文件。
AWS KMS — snapshot 與鑑識 S3 bucket 的加密 key。透過 key policy 與 grant 進行跨帳號存取。KMS Cross-Account Access。
AWS Systems Manager — Run Command 用於記憶體擷取、Patch Manager 用於清除、Automation 用於手冊。SSM 文件。
Amazon Detective — 行為圖用於根因分析與爆炸半徑判定。Detective 文件。
Amazon Athena — 對 S3 儲存的 CloudTrail/VPC Flow Logs 執行 SQL 自訂查詢。Athena 文件。
Amazon S3 Object Lock — compliance mode 的 WORM 儲存用於鑑識證物。Object Lock 文件。
AWS Lambda — 原子性手冊動作（每個函式一項任務）。Lambda 文件。
AWS Step Functions — 編排多階段受駭資源數位鑑識手冊。Step Functions 文件。
Amazon EventBridge — 將 GuardDuty finding 路由至 Step Functions。EventBridge 文件。
Amazon GuardDuty — 產生觸發受駭資源數位鑑識的 finding。GuardDuty 文件。
AWS CloudTrail — 「誰做了什麼」時間軸的主要日誌來源。CloudTrail 文件。

完整演練：實戰情境

假設 GuardDuty 在嚴重性 8 的情況下，針對 i-0abcd1234 發出 CryptoCurrency:EC2/BitcoinTool.B!DNS finding。Step Functions 手冊於 UTC 03:14:22 啟動。

03:14:23 — IsolateInstance Lambda 將 i-0abcd1234 從 ASG 卸離，將所有 SG 替換為 sg-forensic-deny-all，並卸除 IAM instance profile。

03:14:30 — SnapshotVolumes Lambda 建立 snapshot snap-root 與 snap-data，並以 IncidentID=INC-2026-0042 標記。

03:14:45 — CaptureMemory Lambda 以 AWS-RunShellScript 呼叫 SSM Run Command，載入 LiME 並將 RAM 傾印至 s3://forensic-acct-evidence/INC-2026-0042/memory.lime。Step Function 等待最多 30 分鐘。

03:18:11 — 記憶體傾印完成（3.2 GB）。S3 bucket 設有 7 年保留期限的 Object Lock compliance mode。SHA-256 雜湊值計算完成並儲存於傾印檔旁。

03:18:30 — CopyEvidenceToForensicAccount Lambda 以鑑識帳號的 KMS key 呼叫 CopySnapshot，並呼叫 ModifySnapshotAttribute 授予鑑識帳號 CreateVolumePermission。

03:18:45 — NotifySOC Lambda 推送至 PagerDuty。SOC 分析師開啟 Amazon Detective，從 GuardDuty finding 轉向 i-0abcd1234 的 resource profile，發現掛載在 instance 上的 IAM role 在 18 分鐘前也呼叫了 iam:CreateAccessKey——確認憑證外洩。

03:19:02 — 分析師對 CloudTrail 執行 Athena 查詢，列舉新 access key 的所有 API 呼叫——發現從敏感 bucket 下載了三個 S3 物件。爆炸半徑已確認。

03:25:00 — 由於 severity >= 8 且分析師已透過 Slack ChatOps 核准，OptionallyTerminate 執行。instance 遭終止。鑑識副本保存在隔離帳號中，在 7 年內無法觸及。

整個受駭資源數位鑑識流程耗時約 10 分鐘，具備完整的監管鏈，在時間關鍵的階段無需人工輸入，且證物保全完整。這正是 SCS-C02 希望你能辨認的黃金標準。

常見問答

Q1：回應受駭 EC2 instance 時，我應該先停止（stop）還是終止（terminate）它來遏制威脅？

A：兩者都不應該——至少在擷取證物之前不行。受駭資源數位鑑識的正確第一步是在不改變 instance 狀態的前提下進行隔離：將安全群組替換為 deny-all、卸除 IAM instance profile，並從 Auto Scaling group 卸離。停止 instance 會清空 RAM，你就失去記憶體鑑識。以預設設定終止會刪除根 EBS 磁碟區。先透過 Systems Manager Run Command 對 EBS 磁碟區做 snapshot 並擷取記憶體，之後再視需要終止或隔離。參考：AWS Security Incident Response Guide。

Q2：為什麼 Amazon Detective 需要 GuardDuty？我可以單獨執行 Detective 嗎？

A：Detective 並不需要 GuardDuty finding——它自主擷取 CloudTrail 與 VPC Flow Logs，無論如何都會建立行為圖。但當 Detective 與 GuardDuty finding 關聯時最有價值，因為 GuardDuty 提供初始訊號（「是什麼觸發了調查」），而 Detective 提供情境圖（「還有什麼與此相連」）。多數生產部署會同時啟用 GuardDuty、Security Hub 和 Detective。參考：Detective Behavior Graph。

Q3：S3 Object Lock governance mode 與 compliance mode 在受駭資源數位鑑識中有何差異？

A：Governance mode 讓擁有 s3:BypassGovernanceRetention 權限的使用者可以刪除鎖定物件——適用於內部保留與釋放工作流程，不適用於法律證物。Compliance mode 才是真正的 WORM：任何使用者（包含 AWS 帳號 root user）都無法在計時器到期前刪除或縮短保留期限。對於旨在抵禦內部威脅或稽核要求的受駭資源數位鑑識證物，永遠使用 compliance mode，保留期限需與你的事故回應政策匹配（通常為 1、3 或 7 年）。參考：S3 Object Lock Modes。

Q4：如何將加密的 EBS snapshot 共享給我的隔離鑑識帳號？

A：三件事必須到位：（1）呼叫 ModifySnapshotAttribute，將鑑識帳號 ID 加入 CreateVolumePermission；（2）更新客戶自管 KMS key policy，允許鑑識帳號 principal 執行 kms:Decrypt、kms:CreateGrant 與 kms:DescribeKey；（3）在鑑識帳號中，授予將要複製 snapshot 的 IAM role 相對應的 IAM 權限。任何一層缺失，鑑識帳號就會看到 KMSKeyNotAccessibleFault。AWS 受管 key（aws/ebs）無法跨帳號共享——你必須使用客戶自管 key。參考：Sharing an Encrypted EBS Snapshot。

Q5：受駭資源數位鑑識分析應在何時使用 Amazon Athena，何時使用 Amazon Detective？

A：當你需要跨 IAM principal、IP、instance 與 finding 互動式轉向時使用 Detective——其行為圖專為「顯示過去 30 天中與此實體相連的所有內容」而設計。當你需要對歷史日誌執行精確 SQL 時使用 Athena——例如跨 CloudTrail 與 VPC Flow Logs 的時間邊界 JOIN，或依 bytes_sent > 1GB 篩選 S3 存取日誌。Detective 更適合關係探索；Athena 更靈活適合自訂查詢。成熟的受駭資源數位鑑識團隊兩者並用：Detective 負責調查的前 80%，Athena 負責需要自訂 SQL 的後 20%。參考：Querying CloudTrail Logs with Athena。

Q6：如何端對端自動化受駭資源數位鑑識手冊？

A：參考架構是 GuardDuty → EventBridge → Step Functions → Lambda。GuardDuty finding 預設流入 EventBridge；帶有嚴重性篩選器的 EventBridge rule 以 Step Functions Standard workflow 為目標；workflow 編排各手冊階段的離散 Lambda 函式（隔離、snapshot、透過 SSM 的記憶體傾印、跨帳號複製、通知 SOC、視需要終止）。Step Functions 優於單一 Lambda，因為完整手冊（尤其是透過 SSM Run Command 的記憶體擷取）可能超過 Lambda 的 15 分鐘上限，且受益於每個狀態的重試、等待與視覺化除錯。參考：Automating Incident Response with Step Functions。

Q7：為什麼需要獨立的鑑識帳號？在 production 帳號中用獨立的 S3 bucket 不行嗎？

A：同帳號中的獨立 bucket 是不夠的，因為如果攻擊者觸及 production 帳號 root，他可以透過刪除 AWS 帳號本身來刪除 bucket（在等待期過後）。更實際的問題是，擁有 admin 權限的攻擊者可以停用 CloudTrail、修改 KMS key policy，並竄改 production 帳號中的日誌。在鑑識 OU 中設有針對鑑識資源刪除操作的 deny-all SCP、加上獨立 KMS key 的隔離鑑識帳號，可以切斷攻擊者在 production 帳號完全淪陷後銷毀證物的能力。這是 AWS Security Reference Architecture 所認可的架構。

總結

AWS 上的受駭資源數位鑑識是一個五階段循環：以安全群組 + IAM 卸除隔離（isolate）、透過 Systems Manager 蒐集（collect） EBS snapshot 與記憶體傾印、以 Amazon Detective 進行關係轉向與以 Athena 執行自訂 SQL 來分析（analyze）、以隔離鑑識帳號搭配 S3 Object Lock compliance mode、S3 Lifecycle 轉至 Glacier Deep Archive 及 S3 Cross-Region Replication 來保全（preserve）證物，最後清除並復原（eradicate plus recover）——輪換憑證並從乾淨 AMI 重建。以 EventBridge → Step Functions → Lambda 自動化時間關鍵的階段，使得回應在 GuardDuty finding 發出後數秒內即啟動。對於 SCS-C02，掌握陷阱模式（不在 snapshot 前終止、不對法律證物用 governance mode、不在未共享 KMS grant 的情況下共享加密 snapshot）以及服務對應關係，受駭資源數位鑑識的題目將成為整張考試中最可預測的部分。