Amazon SCS-C02: 事件應變與鑑識 — 學習指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

屬於 AWS Security Specialty SCS-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

隔離受感染的 EC2 執行個體

當懷疑 EC2 執行個體遭到入侵時，首要的營運目標是在不破壞證據的情況下進行圍堵。在 AWS 上，圍堵是一項分層的活動，涉及執行個體的網路曝險、其生命週期綁定，以及應變人員的可存取性。

標準的隔離順序始於收緊執行個體的安全群組。理想情況下，每個執行個體都有其專屬的安全群組，因此您可以將傳入和傳出規則替換為一組最小化的規則，僅允許鑑識團隊（或一個專用的診斷安全群組）連線到它。如果執行個體位於 Application Load Balancer 後方或在目標群組中，請先將其取消註冊；如果它是 Auto Scaling 群組的成員，請使用 --should-decrement-desired-capacity 旗標將其分離，這樣 ASG 就不會立即啟動替代執行個體，或更糟的是，在調查中途終止「不健康」的執行個體。

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

啟用終止保護至關重要，因為善意的操作員、自動化腳本或 ASG 的縮減事件，否則可能會摧毀您正試圖保存的磁碟區。終止保護不能替代從 ASG 分離——除非您也將執行個體從群組的範圍中移除，否則 ASG 仍然可以在縮減期間終止受保護的執行個體。

當您需要立即切斷傳出流量時（例如，執行個體向已知的惡意 IP 發出信標），您可以在子網路的網路 ACL 中新增一條明確的全部拒絕傳出規則，作為編號最前面的規則，以進行子網路層級的圍堵。這是無狀態的，並立即對所有流量生效，不像安全群組的變更只會影響新的流量。一旦您透過診斷 SG 建立了鑑識存取路徑，就可以移除 NACL 的拒絕規則，以便應變人員的子網路可以透過 SG 的允許清單連線到目標。

保存揮發性與非揮發性證據

揮發性證據——處理程序列表、開啟的網路通訊端、已載入的核心模組、記憶體內容、tmpfs 內容——在執行個體停止的瞬間就會被銷毀。非揮發性證據存在於 EBS 上，能夠在停止/啟動後存留，但如果磁碟區被分離或執行個體在沒有快照的情況下被終止，仍然可能會遺失。順序規則是：先在執行個體仍在執行時收集揮發性產物，然後再對 EBS 進行快照。

揮發性證據的收集應該透過 SSM Run Command 以腳本化方式執行，而不是由人員在互動式 shell 中手動輸入指令。Run Command 會將呼叫、參數、執行主體以及輸出記錄在 CloudWatch Logs 或 S3 中，這本身就成為監管鏈記錄的一部分。

實務問題：使用案例情境

情境： Meridian Financial 在單一 AWS 帳戶中，跨多個 VPC 執行其面向客戶的 Web 應用程式，使用 Application Load Balancers 後方的 Auto Scaling 群組、由 EBS 支援的 EC2 執行個體、集中式的 CloudTrail 和 CloudWatch 日誌記錄、GuardDuty，以及一個使用 KMS 加密的 S3 日誌存檔。安全營運團隊使用 AWS Systems Manager 進行遠端管理，並將備份和快照儲存在指定的復原帳戶中。

挑戰： 一台生產環境的 EC2 執行個體出現受感染的跡象，有可疑的傳出流量和非預期的處理程序活動；團隊必須隔離該執行個體，並保存揮發性記憶體和非揮發性磁碟證據以進行鑑識分析，同時不能破壞稽核軌跡。

建議方法：

使用 Auto Scaling 和 ELB API 將執行個體從目標群組中分離並暫停 Auto Scaling 程序，然後套用一個限制性的安全群組（拒絕所有傳入/傳出流量），並更新執行個體的網路 ACL 規則以隔離網路存取，同時透過 AWS Systems Manager Session Manager 保留管理能力。
使用 AWS Systems Manager Run Command 執行客體作業系統內的記憶體擷取（例如 LiME），將 RAM 傾印寫入一個已掛載的加密 EBS 磁碟區，或直接寫入一個以 SSE-KMS 加密並啟用 S3 物件鎖定以供保留的 S3 儲存貯體。
使用 EC2 CreateSnapshot（或 CreateImage）為所有已掛載的磁碟區擷取時間點 EBS 快照，然後將這些快照複製到一個獨立的 AWS 帳戶或另一個區域，以維護監管鏈並防止竄改。
為執行個體的 ENI 啟用或擷取 VPC Traffic Mirroring，將封包擷取收集到一台專用的監控 EC2，並同時將 VPC Flow Logs、ELB 存取日誌、CloudTrail、CloudWatch Logs 和 GuardDuty 的發現結果匯出到安全的 S3 存檔中。
在 AWS Security Hub 或工單系統中為所有收集到的產物加上標籤並建立清單，確保 S3 物件已加密並設定了物件鎖定，並將 IAM 存取權限限制在一個小型的鑑識團隊，同時透過 CloudTrail 記錄所有存取活動。

理由： 在擷取映像檔之前隔離網路存取可防止進一步的污染，而使用 SSM 則避免了開啟新的網路途徑；先擷取揮發性記憶體，再建立不可變的 EBS 快照和安全的 S3 存檔，這符合 AWS 事件應變最佳實務，能夠維護證據的完整性和監管鏈。

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

在揮發性證據擷取完成後，立即為每個掛載的 EBS 磁碟區建立快照。為快照加上事件識別碼的標籤，以便它們能明確地與該案件關聯。

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

為執行個體本身也加上相同的事件工單、調查人員姓名以及狀態標籤（例如 Quarantine）。一致性的中繼資料標籤是 AWS 原生的監管鏈機制——它可供查詢，可透過 IAM 條件金鑰設為不可變，並且會出現在關於該資源的每一個 CloudTrail 事件中。

使用 Session Manager 與 Run Command 進行即時應變

一個細微但考試中至關重要的觀念：既有的 SSH 連線在安全群組規則被移除後仍然會存在。 Security groups 是有狀態的 (stateful)，且只在連線建立時評估規則；一個已經建立的 TCP 連線會繼續流通，即使當初允許它的傳入規則 (ingress rule) 已被刪除。如果應變人員為了隔離一台執行個體而移除 SG 規則，同時又依賴自己的 SSH 連線來存取，那麼該連線會繼續運作——直到它中斷為止，屆時他們將被鎖在外面，任何透過堡壘主機或金鑰的重新進入都將變得不可能。

正確的模式是透過 SSM Session Manager 授予鑑識團隊存取權限，它不需要開啟任何傳入連接埠 (inbound port)。Session Manager 是透過 SSM Agent 對 SSM、EC2 Messages 和 SSM Messages 端點的對外連線來運作的（理想情況下，是透過 VPC interface endpoints，這樣被隔離的執行個體就不需要網際網路路由）。附加一個允許 ssm:UpdateInstanceInformation 和 messages API 的 instance profile，並授予應變人員 ssm:StartSession 權限，並透過標籤 (tag) 將範圍限定在被隔離的執行個體上。

因為 Session Manager 的連線是由 SSM 控制平面 (control plane) 所代理，所以收緊或完全清空安全群組的傳入規則並不會干擾這些連線，而且每個按鍵操作都可以記錄到 S3 或 CloudWatch Logs——成為一個可稽核的互動式連線，而不是一個黑盒子。

加密快照的跨帳戶復原

成熟的環境會將鑑識快照路由到一個專用的鑑識帳戶，與被入侵的工作負載帳戶隔離。跨帳戶共享快照需要兩件事：快照必須與目標帳戶共享（modify-snapshot-attribute --create-volume-permission），以及如果快照是用客戶管理的 KMS 金鑰 (customer-managed KMS key) 加密的，KMS 金鑰政策必須授予鑑識帳戶的主體 (principals) kms:Decrypt、kms:CreateGrant 和 kms:DescribeKey 權限。使用 AWS 管理的 aws/ebs 金鑰加密的快照無法跨帳戶共享——您必須先透過複製操作，用一個 CMK 重新加密。在鑑識帳戶中，複製共享的快照，並用本地的鑑識 CMK 重新加密，這樣後續建立磁碟區時就不會依賴來源帳戶。

應變計畫設計與最小化額外開銷

將圍堵步驟編寫成 SSM Automation 文件或 Step Functions 工作流程，由 GuardDuty 或 Security Hub 的發現項目 (findings) 透過 EventBridge 觸發。一個單一的自動化流程應該要能：(1) 透過 Run Command 擷取揮發性資料，(2) 為磁碟區建立快照並附上事件標籤，(3) 啟用終止保護，(4) 從 ASG 分離並從 ELB 目標群組中取消註冊，(5) 用隔離用的 SG 取代原有的 SG，以及 (6) 用工單 ID (ticket ID) 標記該執行個體。保持執行個體運行可以保存即時證據，並能透過 Session Manager 進行互動式調查——關機應該是一個深思熟慮後的後續步驟，而不是自動化圍堵的一部分，因為關機會清除揮發性證據，並可能觸發惡意軟體中內嵌的清理邏輯。

需要內化的陷阱：在信任既有 SSH 連線的情況下移除 SG 規則，會讓應變人員變得束手無策，並對隔離措施產生錯誤的信心；在建立快照前就地修復會破壞能回答入侵如何發生的跡證；將執行個體留在其 ASG 或目標群組中，會招致自動終止，或更糟的是，被無聲地替換，從而隱藏了事件的範圍。

立即圍堵

當一個工作負載被懷疑遭到入侵時，第一個決定是要就地隔離還是將其從服務中移除。將其移除——也就是停止或終止——會銷毀揮發性證據，例如 RAM 內容、執行中的程序、開啟的通訊端 (sockets)，以及任何只存在於記憶體中的惡意軟體。就地圍堵幾乎永遠是正確的起手式，而且必須夠快，才能在控制措施生效前，阻止攻擊者竊取更多資料或進行橫向移動。

兩種 AWS 原生控制措施在不同層級運作，了解其區別很重要。Security groups 是有狀態的 (stateful) 並附加到彈性網路介面 (ENIs)；Network ACLs (NACLs) 則是無狀態的 (stateless) 並附加到子網路。用一個鎖定的「隔離」SG 來替換執行個體的安全群組，是一種外科手術般精準的方法——它只隔離一個 ENI，而不會干擾同一子網路中的其他工作負載，並保留了執行個體的執行階段狀態。然而，安全群組的變更只會影響到達 ENI 的新流量，如果被入侵的執行個體已經持有長期的對外連線，既有的狀態可能會持續存在。NACL 的拒絕規則會立即在子網路邊界生效，當速度比外科手術般的精準度更重要時，它可以更快地阻斷流量——例如，當同一子網路中的多個執行個體都受到牽連，或者當攻擊者的活動連線必須被立即切斷時。當政策不允許直接修改執行個體時，NACLs 也很有用。

標準的隔離 SG 允許沒有任何傳入流量，而傳出流量只允許到 com.amazonaws.<region>.ssm、com.amazonaws.<region>.ssmmessages 和 com.amazonaws.<region>.ec2messages 的 VPC interface endpoints。這保留了 Systems Manager Session Manager 的存取權限，同時阻擋了 C2 通道、資料外洩和橫向移動。

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

證據保全順序

鑑識價值會從最易揮發到最不易揮發的順序遞減，因此操作順序是固定且不容協商的：

首先啟用終止保護。 設定 DisableApiTermination=true 可以防止 Auto Scaling 事件、操作人員的失誤或排程動作在調查過程中摧毀執行個體。同時，將執行個體從其 Auto Scaling 群組中分離，這樣 ASG 的運作狀態檢查就不會替換掉它。
從 Auto Scaling 分離或保護。 使用 EnterStandby 或分離執行個體，這樣 ASG 就不會因為其運作狀態不良而將其終止。
為每個掛載的 EBS 磁碟區建立快照。 CreateSnapshot（或用於多磁碟區原子級擷取的 CreateSnapshots）可以產生一個不可變、加密的鑑識產物。為快照加上標籤，註明事件 ID、來源執行個體 ID、時間戳記和分析師。將快照複製到由安全團隊擁有的專用鑑識帳戶，這樣即使原帳戶遭到入侵，快照也能保存下來。
擷取記憶體。 使用 SSM RunCommand 文件來呼叫記憶體擷取工具（Linux 上的 LiME、AVML；Windows 上的 WinPMEM），並將映像檔串流到啟用合規模式 Object Lock 的 S3 鑑識儲存貯體。記憶體必須在執行個體仍在執行時擷取——已停止的執行個體沒有 RAM 可供擷取。
收集元數據。 記錄執行個體 ID、AMI、IAM 執行個體設定檔、VPC/子網路、ENI ID、標籤、執行中的處理程序列表、netstat 輸出以及 IMDS 內容。為執行個體加上 Status=Quarantined 和 IncidentId=<id> 的標籤，以便下游的自動化流程和真人操作員能識別其狀態。
只有在調查需要離線磁碟分析時，才停止執行個體。停止執行個體會清除記憶體，所以這永遠是最後一個步驟。

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

自動化 IR 工作流程

GuardDuty 的發現項目應在幾秒內觸發圍堵措施，而不是幾小時。標準的流程是 EventBridge → Lambda → SSM Automation，並使用 SNS 進行通知。

一個 EventBridge 規則會比對 source: aws.guardduty、detail-type 為 GuardDuty Finding 的事件，並透過模式篩選出與 EC2 相關的發現項目類型，例如 UnauthorizedAccess:EC2/*、Backdoor:EC2/*、Trojan:EC2/* 和 CryptoCurrency:EC2/*。

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Lambda 目標會從 detail.resource.instanceDetails.instanceId 中提取執行個體 ID，然後呼叫一個 SSM Automation 文件（或直接呼叫 SDK）來：啟用終止保護、透過 ModifyNetworkInterfaceAttribute 將 ENI 的安全群組替換為隔離用的 SG、為所有掛載的磁碟區建立快照、為執行個體加上標籤，並發布一則 SNS 訊息到 SOC 頻道。使用 SSM Automation 而非直接呼叫 SDK，可以在 Automation 的執行歷史記錄中提供逐步的稽核軌跡。

用於分析資料外洩和 C2 的日誌記錄

沒有遙測數據的圍堵措施只是憑空猜測。必須在 VPC 或子網路層級啟用 VPC Flow Logs，並將流量類型設定為 ALL（包含 ACCEPT 和 REJECT）。REJECT 記錄能揭露掃描行為、被阻擋的資料外洩嘗試，以及試圖連線到已知惡意 IP 的 C2 信標；ACCEPT 記錄則顯示哪些流量成功通過。將流量日誌路由到 CloudWatch Logs 以進行即時查詢，並路由到 S3 以便使用 Object Lock 進行長期保留。在鑑識 S3 儲存貯體和 KMS 上啟用 CloudTrail 資料事件，可為證據處理提供稽核鏈。結合 DNS 查詢日誌（Route 53 Resolver），可以捕捉到單靠流量日誌會錯過的 DGA 和 DNS 隧道。

透過 Session Manager 進行受控的鑑識存取

Session Manager 免除了對 SSH 金鑰、堡壘主機或開放 22/3389 連接埠的需求，這也正是為什麼隔離用的 SG 可以阻擋所有傳統存取方式的原因。啟用工作階段日誌記錄，將其傳送到一個使用 SSE-KMS 的 S3 儲存貯體以及 CloudWatch Logs；在工作階段偏好設定中強制 EnforceEncryption=true，以確保沒有任何工作階段在未使用 TLS 和日誌加密的情況下執行。針對 ssm:StartSession 的 IAM 政策應將範圍限定在帶有 tag:Status=Quarantined 標籤的執行個體，並且只授予事件應變角色。

常見的陷阱及其失敗原因

先停止或終止執行個體。 停止 (Stopping) 會釋放記憶體、中斷現行連線，並讓你無法擷取揮發性的跡證 (volatile artifacts)。終止 (Terminating) 更會釋放根磁碟區 (除非 DeleteOnTermination=false)，但即使如此，你還是會遺失執行階段的狀態。在進行任何電源狀態變更前，務必先就地圍堵 (contain in place)。
在 NACL 更快的情況下，卻只依賴 security groups。 SG 的變更雖然精準，但只影響其附加的 ENI，且只管理新的流量。當子網路中有多個執行個體受影響，或需要立即切斷攻擊者現有的對外連線時，子網路層級的 NACL 拒絕規則能更快地關上大門，因為 NACL 是無狀態的 (stateless)，無論先前的狀態如何，都會封鎖每個封包。
在建立快照前就進行修復。 在建立 EBS 快照前就對執行個體進行重新映像 (Reimaging)、修補或替換，會破壞儲存在磁碟上的證據——例如惡意軟體二進位檔、持續性機制、日誌、時間戳記。快照既便宜又不可變 (immutable)；在採取任何修復行動前，請先建立快照，並將其複製到專用的鑑識帳戶，這樣即使生產帳戶被入侵，也無法刪除這些證據。

實務問題：使用案例情境

情境： Meridian Financial 公司在一個多帳戶的 AWS 環境中運行，其生產工作負載位於一個專用帳戶中：EC2 和 EKS 服務託管客戶資料、S3 儲存貯體用於存檔、在一個安全帳戶中啟用 CloudTrail、GuardDuty、Security Hub 和 Config 進行集中式日誌記錄，以及一個用於部署的 CI/CD 管道。他們的維運團隊使用 Systems Manager 進行修補和維護，並使用 Route 53/ALB 作為公開端點。

挑戰： 一則 GuardDuty 的發現 (finding) 和非預期的對外流量遽增，顯示某個 EC2 執行個體可能已遭入侵，正在進行資料外洩和可疑的 IAM API 呼叫，需要立即進行圍堵，同時保留鑑識證據，並維持可供稽核的調查人員存取權限。

建議方法：

針對 GuardDuty 的發現，透過 EventBridge 觸發即時圍堵，以叫用一個 Step Functions 工作流程，該流程使用 Lambda/SSM Automation 來附加一個隔離用的 security group、移除公有 IP 或分離 ENI，並透過 IAM 撤銷/輪換受影響的 IAM 憑證。
執行 SSM Automation 文件以保存揮發性與持續性證據，建立該執行個體的 EBS 快照和 AMI、將快照複製到專用的鑑識 AWS 帳戶，並將匯出的跡證儲存到啟用 S3 Object Lock (合規模式) 和 KMS 加密的 S3 儲存貯體中。
為了進行資料外洩和 C2 (命令與控制) 分析，需確保啟用 CloudTrail 管理事件和資料事件 (S3, Lambda) 以擷取日誌，將 VPC Flow Logs、ALB/NGINX 存取日誌和 Route 53 查詢日誌轉送到中央安全帳戶，並將此發現提升至 Amazon Detective 進行時間軸關聯分析。
使用 EventBridge -> Step Functions -> Lambda 來自動化協調與通知，以協調圍堵措施、證據複製、向事件負責人發送 SNS 通知，並在現有的 ITSM 系統中建立工單。
要求使用 AWS Systems Manager Session Manager 進行即時調查，以提供受控的鑑識存取，並將會話日誌記錄到 CloudWatch Logs 和鑑識 S3 儲存貯體，且僅允許具備 MFA 和臨時憑證的指定鑑識 IAM 角色存取。

理由： 此方法能快速隔離威脅，保存不可變的跡證和集中式日誌以供分析，自動化可重複的應變步驟以縮短圍堵時間 (time-to-contain)，並根據 AWS 最佳實踐，透過 Session Manager 強制執行可稽核的、最低權限的鑑識存取。

← 容器與無伺服器安全 · 所有領域

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通過考試 →

瀏覽 Amazon →

Amazon SCS-C02: 事件應變與鑑識 — 學習指南

隔離受感染的 EC2 執行個體

保存揮發性與非揮發性證據

實務問題：使用案例情境

使用 Session Manager 與 Run Command 進行即時應變

加密快照的跨帳戶復原

應變計畫設計與最小化額外開銷

立即圍堵

證據保全順序

自動化 IR 工作流程

用於分析資料外洩和 C2 的日誌記錄

透過 Session Manager 進行受控的鑑識存取

常見的陷阱及其失敗原因

實務問題：使用案例情境

Pass the whole exam — not just this question

Related guides

一份訂閱。所有考試。