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.

Amazon GuardDuty 的發現項目與修復

GuardDuty 是一項託管式威脅偵測服務，它在背後持續擷取三種遙測串流：CloudTrail 管理事件 (以及可選的 S3 資料事件)、VPC Flow Logs 和 Route 53 DNS 查詢日誌。您不需要為了讓 GuardDuty 使用這些日誌來源而另外啟用、交付或付費——該服務會直接讀取一個複製的串流。這就是為什麼 GuardDuty 只需一個 API 呼叫就能開啟，並在幾分鐘內開始產生發現項目，完全不需要任何日誌管線的工程。

發現項目帶有一個介於 0.1 到 8.9 之間的嚴重性數值，對應到低 (0.1–3.9)、中 (4.0–6.9) 和高 (7.0–8.9)。典型的可採取行動的發現項目包括 UnauthorizedAccess:EC2/SSHBruteForce、Backdoor:EC2/C&CActivity.B!DNS、CryptoCurrency:EC2/BitcoinTool.B 和 Recon:IAMUser/MaliciousIPCaller。修復模式因發現項目而異：一個基於 EC2 的入侵事件通常需要用一個隔離用的安全群組來隔離該執行個體、為磁碟區建立快照以供鑑識，然後終止它；一個基於 IAM 的發現項目則需要輪換存取金鑰並檢視該主體最近的 CloudTrail 活動。

對於多帳戶的環境，請透過 AWS Organizations 啟用 GuardDuty 並指定一個 委派管理員 帳戶 (通常是安全工具帳戶)。委派管理員可以在所有已開啟該服務的區域中，為每個現有和新的成員帳戶自動啟用 GuardDuty。若沒有委派管理員的設定，每個帳戶各自的 GuardDuty 發現項目會被隔離在該成員帳戶中——個別啟用偵測器並不會將它們集中彙總。

AWS Security Hub 與跨帳戶彙總

Security Hub 是標準化與彙總層。它會從 GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config 以及數十個合作夥伴產品中擷取發現項目，並將它們轉換為 AWS Security Finding Format (ASFF)。它也會根據 CIS AWS Foundations、AWS 基礎安全最佳實務、PCI DSS 和 NIST 800-53 等標準來執行自己的控制項。

跨帳戶、跨區域的彙總方式與 GuardDuty 相同：向 Organizations 委派管理員註冊 Security Hub，然後指定一個 彙總區域，這樣來自其他區域的發現項目就會複製到該單一窗格中。一個常見的錯誤是在每個帳戶中都啟用 Security Hub，並期望能看到一個整合的視圖——若沒有委派管理員加上彙總區域的設定，每個帳戶仍然只能看到自己的發現項目。

Security Hub 本身不會發送電子郵件。通知和自動化是透過在預設的 EventBridge 事件匯流排上比對 Security Hub 的發現項目事件，並將它們轉發到 SNS、Lambda、Step Functions 或 Systems Manager Automation 文件來建立的。

CloudTrail：管理事件 vs. 資料事件

CloudTrail 記錄兩種類型的活動，而混淆這兩者是偵測覆蓋範圍中最常見的單一缺口。

管理事件： 控制平面操作——RunInstances、CreateBucket、AttachRolePolicy、PutBucketAcl。在任何新的追蹤上預設啟用。
資料事件： 大量、資源層級的操作——S3 物件層級的呼叫 (GetObject、PutObject、DeleteObject、PutObjectAcl)、Lambda Invoke、DynamoDB 項目層級的 API 呼叫。預設停用且另外計費。

如果一個安全需求是「偵測是否有人透過 PutObjectAcl 將 S3 物件設為公開」，一個單純只記錄管理事件的追蹤將無法捕捉到它，因為對個別物件的 ACL 變更是資料事件。同樣地，若沒有資料事件，從敏感儲存貯體流出的 GetObject 將是不可見的。PutBucketAcl (儲存貯體層級) 是管理事件，會被記錄下來；PutObjectAcl (物件層級) 則不是。

使用在管理帳戶或委派管理員帳戶中建立的 組織追蹤，這樣每個成員帳戶的事件都會被捕捉到單一的 S3 儲存貯體中，且成員帳戶的主體無法將其停用。用以下方式保護該追蹤：

在目標儲存貯體上使用 SSE-KMS 加密，並搭配一個拒絕未經授權解密的 KMS 金鑰政策。
一個儲存貯體政策，拒絕沒有 CloudTrail 服務主體的 s3:PutObject 並拒絕刪除。
啟用 日誌檔案完整性驗證，這會產生每小時用 SHA-256 簽署的摘要檔案，以便證明竄改行為。

建立範例：

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridge 是將發現項目連接到真人與自動化回應者的路由結構。每個 GuardDuty 發現項目、每個 Security Hub 發現項目更新，以及每個源自 CloudTrail 的事件都會到達預設的事件匯流排。規則使用 JSON 事件模式來篩選，然後分送到一個或多個目標 (SNS、Lambda、SQS、Kinesis Data Firehose、Step Functions、Systems Manager)。

一個用於高嚴重性 GuardDuty 發現項目的典型模式，同時轉發到用於電子郵件的 SNS 主題和一個饋送資料到 OpenSearch 以供分析的 Firehose 交付串流：

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

對於路由到電子郵件的 Security Hub CRITICAL 發現項目：

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

電子郵件端點是一個簡單的 SNS 訂閱；訂閱者必須透過電子郵件中的連結進行確認，交付才會開始。單一規則最多可以有五個目標，所以警示和下游的分析不需要重複的規則。

在撰寫模式時，請記住 CloudTrail 管理事件會以 "detail-type": "AWS API Call via CloudTrail" 的形式到達，而資料事件不會出現在預設匯流排上，除非您設定一個將日誌發佈到 CloudWatch Logs 的追蹤，並使用指標篩選器或透過 EventBridge 的 CloudTrail 資料事件整合來訂閱。在未啟用資料事件的情況下，於預設匯流排上撰寫一個比對 "eventName": "PutObjectAcl" 的 EventBridge 規則，將不會有任何匹配結果。

CloudWatch Logs、Insights、指標篩選條件與警示

將 CloudTrail (以及 VPC Flow Logs 和應用程式日誌) 傳送到 CloudWatch Logs 可實現近乎即時的偵測。指標篩選條件 (Metric filters) 會根據一個模式掃描每一個傳入的日誌事件，並遞增一個自訂的 CloudWatch 指標；而該指標上的 CloudWatch 警示則會觸發 SNS。

範例：針對重複的主控台登入失敗發出警示。

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights 提供使用專用查詢語言的臨時查詢功能，這在警示觸發後的事件應變中非常有用：

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

常見陷阱

遺漏 S3 物件層級的活動： PutObjectAcl、GetObject 和 DeleteObject 都是資料事件。預設的追蹤只會擷取管理事件；您必須新增資料事件選擇器，否則針對這些 API 名稱的調查結果、警示或 EventBridge 規則將會無聲無息地永不觸發。
沒有委派管理員的集中可視性： 在每個帳戶中啟用 GuardDuty 或 Security Hub 並不會彙總結果。只有在 AWS Organizations 中註冊了委派管理員，並且 (對 Security Hub 而言) 選擇了一個彙總區域之後，調查結果才會集中匯集。跨帳戶邀請適用於小型環境，但無法擴展，且需要每個帳戶個別接受。
篩選條件中對管理事件與資料事件的混淆： PutBucketAcl (儲存貯體) 是一個管理事件，可在任何標準的 EventBridge 或指標篩選條件中運作；但 PutObjectAcl (物件) 則不行，無論模式設計得多麼精巧，除非已啟用資料事件並將其傳送到同一個管線。

實務問題：使用案例情境

情境： Meridian Financial 公司營運一個多帳戶的 AWS Organization，其中包含一個專用的安全帳戶和一個集中化的日誌記錄帳戶。他們的環境中，S3 存有客戶的個人可識別資訊 (PII)，EC2/Lambda 上有交易型 API，且 CloudTrail 已經將管理事件寫入一個中央 S3 儲存貯體；團隊希望能夠更快速地偵測並在各帳戶間進行協同應變。

挑戰： 安全工程師偵測到 S3 GET 請求突然飆升，以及相關的 GuardDuty 調查結果顯示可能存在資料外洩，但警示充滿雜訊，且缺乏關聯的 CloudTrail 上下文和跨帳戶的自動化圍堵措施。

建議方法：

在每個成員帳戶中啟用 Amazon GuardDuty，並指定安全帳戶為 GuardDuty 的委派管理員；啟用 S3 資料事件保護，以便調查結果能包含物件層級的存取異常。
設定每個帳戶的 CloudTrail，將管理事件傳送到中央 S3 以供留存，並將選定的高價值資料事件 (S3 GetObject/PutObject/DeleteObject 和 Lambda Invoke) 轉發到安全帳戶中的 CloudWatch Logs，以進行低延遲的檢查。
在安全帳戶中開啟 AWS Security Hub，並啟用與成員帳戶的跨帳戶彙總功能，以便將 GuardDuty 調查結果、源自 CloudTrail 的調查結果以及 Config/Inspector 的結果集中化和標準化。
建立 EventBridge 規則，以匹配高嚴重性的 GuardDuty 和 Security Hub 調查結果，並將其路由到 SNS 以發送呼叫器通知，以及路由到一個修復用的 Lambda，該 Lambda 會利用 CloudTrail 的上下文來採取圍堵措施 (例如撤銷 API 金鑰、移除 IAM 工作階段、隔離 EC2 ENI)。
針對依 IAM 主體範圍劃分的異常 s3:GetObject 速率，新增 CloudWatch Logs 指標篩選條件，並設定一個警示來觸發相同的 EventBridge/SNS/Lambda 管線；在安全帳戶中使用 CloudWatch Logs Insights 查詢，以關聯的 CloudTrail 事件來豐富警示內容，以便進行事件分類。

基本原理： 集中化調查結果 (GuardDuty + Security Hub) 並將目標性的 CloudTrail 資料事件傳送到 CloudWatch，可以透過 EventBridge/SNS/Lambda 實現低延遲的關聯、警示和自動化圍堵——這與 AWS 在偵測、跨帳戶彙總和自動化應變方面的最佳實務一致。

集中化的 CloudTrail 與日誌完整性

CloudTrail 是 AWS API 活動的權威記錄，任何稽核架構的基礎都是單一的多區域追蹤 (multi-Region trail)，它會將日誌傳送到一個集中的 S3 儲存貯體，理想情況下是位於 AWS Organizations 內一個專用的日誌封存帳戶中。多區域追蹤會自動擷取每個當前區域以及 AWS 未來推出的任何新區域的管理事件——單一區域的追蹤一旦有工作負載在別處啟動，就會產生盲點，這是稽核期間典型的完整性失敗。當應用於組織層級時，該追蹤也會擷取每個成員帳戶的事件，因此新加入組織的帳戶無需任何個別帳戶設定即可被涵蓋。

在追蹤上啟用日誌檔案驗證 (log file validation)。CloudTrail 接著會每小時將一個簽署過的摘要檔案傳送到同一個 S3 儲存貯體，其中包含已傳送日誌檔案的 SHA-256 雜湊值。aws cloudtrail validate-logs 命令會遍歷摘要鏈並偵測竄改、刪除或間斷。若無驗證，防禦方無法證明日誌在事件發生後未被修改，這會使其作為鑑識證據而失效。

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

傳送失敗幾乎總是下游的權限問題，而不是 CloudTrail 的錯誤。S3 儲存貯體必須在建立追蹤之前就存在，其儲存貯體政策必須授予 s3:PutObject 權限給 cloudtrail.amazonaws.com，並帶有與該追蹤相符的 aws:SourceArn 條件，且物件擁有者必須是儲存貯體擁有者 (bucket-owner-full-control)。如果追蹤使用 SSE-KMS，CMK 政策必須允許 CloudTrail 服務主體執行 kms:GenerateDataKey*，並且每個消費者 (Athena、安全工程師、Lambda 解析器) 都必須擁有該金鑰的 kms:Decrypt 權限。一個常見的服務中斷模式是：日誌傳送正常，但 Athena 查詢卻回傳「AccessDenied」，因為查詢角色缺乏對日誌加密 CMK 的 Decrypt 權限。應在金鑰政策上修復此問題，而不是透過停用加密來解決。

CloudWatch Logs、指標篩選器與即時警示

CloudTrail 以 5 到 15 分鐘的批次將日誌交付到 S3——這對於回溯性稽核來說足夠，但對於即時偵測而言太慢。若要針對敏感事件發出警示，可以將追蹤串流至 CloudWatch Logs (這是一個追蹤選項)，或透過 EventBridge 路由特定事件。CloudWatch Logs 的方法是使用指標篩選器 (metric filters)，它會對 JSON 事件進行模式比對，並遞增一個 CloudWatch 指標，該指標接著會觸發 CloudWatch Alarm 和 SNS 通知。最典型的範例是 root 主控台登入：

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

對於範圍狹窄、已知的事件 (例如停用 KMS 金鑰、變更 IAM 政策)，EventBridge 通常是更好的選擇，因為其規則可以直接觸發 Lambda 或 Step Functions，而不會產生任何 Logs 成本。當您需要彙總計數或在儀表板上呈現時，才使用指標篩選器。

CloudWatch Logs 的保留期預設為永不過期 (Never Expire)，這既昂貴又很少是正確的設定。應根據您的合規制度，為每個日誌群組設定明確的保留期 (使用 aws logs put-retention-policy)——常見的做法是在 CloudWatch 中保留 90 天的熱資料，並透過訂閱篩選器或 Kinesis Data Firehose 將長期資料封存到 S3。

為了做好敏感資料的衛生管理，請在帳戶層級套用 CloudWatch Logs 資料保護政策。這些政策使用受管資料識別符 (如信用卡號、AWS 私密金鑰、SSN) 來遮罩擷取時相符的字串。關鍵在於，解除遮罩需要 logs:Unmask 權限；請只將此權限授予緊急存取角色 (break-glass role)。能夠讀取日誌群組但缺乏 Unmask 權限的使用者只會看到星號。全帳戶範圍的政策會套用到所有現有和未來的日誌群組，這是正確的控制方式——因為隨著新服務建立新群組，個別群組的政策容易產生設定偏差。

大規模日誌查詢：Insights 與 Athena

有兩種查詢引擎可處理不同層級的資料。

CloudWatch Logs Insights 使用專用的查詢語言來查詢已存在 CloudWatch Logs 中的資料。它非常適合查詢近期的營運資料 (如 Lambda 日誌、存放在 Logs 中的 VPC Flow Logs、應用程式日誌)。其優點是速度快、無需設定結構描述，但受限於 CloudWatch 的保留期和每掃描 GB 的成本。
Amazon Athena 可對 S3 中的資料執行 Presto/Trino SQL 查詢。它非常適合對 CloudTrail、ALB 存取日誌、儲存在 S3 的 VPC Flow Logs 以及 CloudFront 日誌進行大規模的鑑識查詢。其成本為每掃描 TB 5 美元；請使用分割區投影 (partition projection) 或依日期/區域建立的 Glue 分割區來大幅降低掃描成本。

一個典型的鑑識使用案例是：識別是誰停用了某個 KMS 金鑰。由於 CloudTrail 的 JSON 是巢狀結構，由 CloudTrail 建立的 Athena 資料表會將 userIdentity 揭露為一個結構 (struct)：

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

若要進行 ALB 機器人分析，請啟用 ALB 存取日誌到 S3，在該日誌前綴上定義一個 Athena 資料表，然後與一個包含已知惡意 IP 的資料表進行 join，最後在 QuickSight 中將彙總結果視覺化。QuickSight 會從 Athena 讀取資料，因此整個管線是：ALB → S3 → Athena → QuickSight。將 ALB 日誌傳送到 CloudWatch Logs Insights 並非支援的原生路徑——ALB 日誌只能送到 S3。

VPC Flow Logs 可以送到這兩個目的地中的任何一個：對於像 filter dstPort=3389 and action="REJECT" 這類策略性的調查，請選擇 Logs；對於月度規模的趨勢查詢，則選擇 S3 (使用 Parquet 格式並進行分割)。

Audit Manager 證據收集

AWS Audit Manager 可自動化地持續收集證據，並將其對應到 PCI DSS、HIPAA、SOC 2 和 CIS 等合規框架。它會從 Config 規則、Security Hub 調查發現、CloudTrail 事件和資源清查中提取證據，並將其打包到控制評估中。當在 Organizations 管理帳戶或委派管理員帳戶中啟用時，它會跨所有成員帳戶收集證據，並產生一份評估報告——這是一個包含資訊清單的證據壓縮檔，稽核人員會接受此報告以取代手動螢幕截圖。當情境題問到需要持續性、跨帳戶、與框架對齊的證據時，這就是正確答案：單獨使用 Config 只能提供資源合規性，但沒有框架對應；Security Hub 提供調查發現，但沒有評估打包功能；而自行開發的 Athena 報告則不是持續性的。

陷阱回顧

將日誌遺失歸咎於 CloudTrail 通常是錯的：儲存貯體可能不存在、儲存貯體政策可能拒絕了 CloudTrail 主體，或是物件擁有權設定錯誤。請先檢查 S3。
單一區域的追蹤看似較便宜，但會產生不完整的稽核歷史紀錄；對於涵蓋整個組織的需求，多區域追蹤才是預設的正確答案。
經 SSE-KMS 加密的日誌對於 Athena、Lambda 解析器或工程師是不可見的，除非 CMK 的金鑰政策授予這些主體 kms:Decrypt 權限 — 停用加密並非解決之道；修正金鑰政策才是。

實務問題：使用案例情境

情境： Meridian Financial 營運一個多帳戶的 AWS Organization，其中包含生產、預備（staging）以及一個專用的日誌帳戶。他們的環境託管了面向客戶的 API、分析系統以及由 IAM 管理的機密，且他們需要集中化、防竄改的日誌記錄，外加快速的調查工具，以支援事件應變與合規性請求。

挑戰： 最近一連串可疑的主控台登入和 IAM 政策變更在數小時內都未被察覺，令人擔憂日誌的完整性和即時警示不足以進行鑑識重建（forensic reconstruction）和收集 Audit Manager 證據。

建議方法：

在所有區域啟用 AWS Organizations CloudTrail（組織追蹤），開啟 CloudTrail 日誌檔案完整性驗證，將日誌和摘要檔案交付到一個集中化的 S3 儲存貯體。該儲存貯體使用 KMS CMK 加密，其金鑰政策將解密權限限制給一個小型的安全團隊，並啟用 S3 存取日誌和版本控制。
設定 CloudTrail 將管理事件和選定的資料事件串流至 CloudWatch Logs，然後針對高風險模式（例如來自新 IP 的主控台登入失敗、CreateUser、PutRolePolicy）建立 CloudWatch Logs 指標篩選器，並將 CloudWatch Alarms 附加到 SNS 主題，以用於呼叫通知（paging）和自動化的 Lambda 教戰手冊（playbook）。
部署 CloudWatch Logs Insights 儀表板以對近期事件進行互動式調查，並在日誌帳戶中設定保留和生命週期規則，以根據政策保留證據。
使用 AWS Glue 將 CloudTrail S3 物件編入目錄，並執行 Athena 查詢（依區域/日期/服務進行分割）以進行大規模的回溯性分析，並為調查人員產出 CSV 格式的證據匯出檔案。
建立一個 AWS Audit Manager 評估，該評估會自動將 CloudTrail、AWS Config 和 IAM 的證據收集到一個證據資料夾中，並排定定期匯出給合規性審查人員。

基本原理： 集中化並驗證 CloudTrail、串流至 CloudWatch 以實現即時指標篩選器和警示、以及使用 Athena/Logs Insights 進行可擴展的查詢，這些都遵循了 AWS 在偵測、不可變日誌記錄和鑑識整備度（forensic readiness）方面的最佳實務。同時，Audit Manager 自動化了稽核所需的證據收集過程。

← 威脅偵測與警報 · 所有領域 · 加密、KMS 與機密管理 →

練習這些題目 → · 在 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: 日誌、稽核與鑑識 — 學習指南

Amazon GuardDuty 的發現項目與修復

AWS Security Hub 與跨帳戶彙總

CloudTrail：管理事件 vs. 資料事件

CloudWatch Logs、Insights、指標篩選條件與警示

常見陷阱

實務問題：使用案例情境

集中化的 CloudTrail 與日誌完整性

CloudWatch Logs、指標篩選器與即時警示

大規模日誌查詢：Insights 與 Athena

Audit Manager 證據收集

陷阱回顧

實務問題：使用案例情境

Pass the whole exam — not just this question

Related guides

一份訂閱。所有考試。

Amazon SCS-C02: 日誌、稽核與鑑識 — 學習指南

Amazon GuardDuty 的發現項目與修復

AWS Security Hub 與跨帳戶彙總

CloudTrail：管理事件 vs. 資料事件

EventBridge 與 SNS 警示

CloudWatch Logs、Insights、指標篩選條件與警示

常見陷阱

實務問題：使用案例情境

集中化的 CloudTrail 與日誌完整性

CloudWatch Logs、指標篩選器與即時警示

大規模日誌查詢：Insights 與 Athena

Audit Manager 證據收集

陷阱回顧

實務問題：使用案例情境

Pass the whole exam — not just this question

Related guides

一份訂閱。所有考試。