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.

在整個 Organization 中集中管理 GuardDuty

Amazon GuardDuty 是一項持續性威脅偵測服務，可分析 CloudTrail 管理與資料事件、VPC Flow Logs、DNS 查詢日誌、EKS 稽核日誌、RDS 登入活動以及執行時期遙測資料。它會產生的發現項目，並依據威脅目的 (Backdoor、CryptoCurrency、Recon、UnauthorizedAccess、PenTest、Policy、Stealth、Trojan、Impact) 和資源類型 (EC2、IAMUser、S3、Kubernetes、RDS、Lambda、Runtime) 進行分類。

逐一帳戶地操作 GuardDuty 並不具備擴展性。在 AWS Organizations 環境中，正確的架構是使用 Organizations 管理帳戶來指定一個委派管理員——通常是專門的安全或稽核帳戶。從委派管理員帳戶，您可以為整個組織啟用 GuardDuty，並開啟自動啟用功能，這樣新的成員帳戶和新的 Region 在建立時就會自動受到保護。若沒有自動啟用，新建立的帳戶會處於盲點狀態，直到操作員手動啟用偵測為止，而這正是攻擊者在帳戶啟用初期利用的空窗期。

實務問題：使用案例情境

情境： Meridian Financial 在橫跨 28 個帳戶的多帳戶 AWS 環境中執行其生產、開發和共享服務。他們的管理帳戶透過 AWS Organizations 來治理帳戶，並設有集中化的 CloudTrail 和 S3 日誌記錄，但安全警示和調查資料分散在各個成員帳戶中，使得事件分類變得緩慢且不一致。

挑戰： 最近在某個帳戶中偵測到的橫向移動產生了 GuardDuty 發現項目，但中央 SOC 工具無法即時看到，從而延遲了圍堵和鑑識調查。

建議方法：

1. 在管理帳戶中指定一個 GuardDuty 委派管理員，並透過 AWS Organizations 為整個組織啟用 GuardDuty，以便所有成員帳戶都將發現項目轉送到一個中央偵測器。
2. 在管理帳戶中開啟集中化的 AWS Security Hub 作為彙總器，並為所有帳戶和 Region 啟用 Security Hub，以將 GuardDuty 的發現項目與其他安全標準一起標準化。
3. 在管理帳戶中設定 Amazon EventBridge 規則，以捕獲 GuardDuty 和 Security Hub 的發現項目，並將它們路由到集中的目標，例如用於呼叫通知的 Amazon SNS、用於封存到 S3 的 Amazon Kinesis Data Firehose，或直接傳送到您的 SIEM。
4. 部署由 EventBridge 觸發的 Lambda 回應器，以執行自動化的圍堵行動 (例如，透過 EC2 API 隔離一個 EC2 執行個體，並建立一個 AWS Systems Manager 事件)，並為發現項目加上標籤以供調查。
5. 整合 Amazon Detective 進行集中調查，並將封存在 S3 中的發現項目轉送到您的分析/SIEM 系統，以進行長期關聯分析和報告。

理由： 根據 AWS 的最佳實務，使用帶有 Security Hub 和 EventBridge 的 GuardDuty 委派管理員，可以集中化偵測、標準化警示，並實現自動化且可稽核的回應，以達成全組織的威脅偵測和及時的事件應變。

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty 是區域性的服務，因此委派管理員關係和自動啟用設定必須在您營運的每個 Region 中建立。這是一個常見的盲點來源——團隊在 us-east-1 中啟用了 GuardDuty，就以為涵蓋了全球。

特定服務的保護功能

基礎的 GuardDuty 涵蓋了基本的資料來源，但有幾個保護計畫必須明確啟用，因為它們會增加成本和額外的遙測資料擷取：

• RDS Protection： 分析 Aurora MySQL/PostgreSQL 和 RDS 引擎的登入活動輪廓，當未知使用者對資料庫端點進行身份驗證時，會產生如 CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin 的發現項目。這是偵測可疑資料庫登入的正確來源——當 RDS Protection 已經可以原生發出發現項目時，不要在資料庫稽核日誌上建立自訂的 CloudWatch 指標篩選器。

• EKS Protection： 擷取 Kubernetes 稽核日誌，以偵測異常的 API 存取、特權 pod 的建立，以及使用暴露在外的儀表板。

• Runtime Monitoring： 在 EC2、ECS/Fargate 或 EKS 上部署一個輕量級、基於 eBPF 的代理程式，以揭露程序、檔案和網路事件——這是偵測執行時期的無檔案惡意軟體或反向 shell 所必需的。

• Malware Protection： 快照掃描被其他發現項目標記的執行個體所掛載的 EBS 磁碟區，或在上傳時對 S3 物件進行隨選掃描。

• Lambda Protection 和 S3 Protection： 分別涵蓋函式調用模式和資料層面的 S3 存取。

只啟用基礎服務卻期望資料庫登入異常會出現，是一個常見的錯誤設定——在相應功能開啟之前，這些發現項目類型根本不會產生。

將 Security Hub 作為彙總層

Security Hub 會擷取來自 GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config、Health 以及第三方 ISV 產品的發現項目，並將其標準化為 AWS Security Finding Format (ASFF)。它也會執行自己的合規標準 (AWS Foundational Security Best Practices、CIS、PCI DSS、NIST 800-53)。

若要跨 Organization 進行集中管理：

• 在 Organizations 中啟用 Security Hub 作為一項服務，並指定一個委派管理員 (通常與 GuardDuty 使用同一個安全帳戶)。

• 開啟自動啟用新帳戶，以便成員帳戶能自動加入。

• 設定一個發現項目彙總區域 (也稱為主區域)，並將所有其他區域連結至此。若無跨區域彙總，每個區域都會維持一個獨立的 Security Hub 執行個體，分析師必須在各個主控台之間切換。

因此，一個全域組織性的部署模式需要兩個協調的設定：彙總區域的連結，以及整個組織的自動啟用開關。只啟用其中一個而忽略另一個，會導致新帳戶未被涵蓋，或是新區域各自為政。

一個重要的限制：Security Hub 會彙總和排定優先順序，但不會修復。將其視為一個修復平台是個類別錯誤——修復是透過下游的 EventBridge 進行。

將 EventBridge 作為自動化架構

GuardDuty 和 Security Hub 都會將發現項目發佈到預設的事件匯流排。aws.guardduty 會發出 GuardDuty Finding 事件，而 aws.securityhub 則會發出 Security Hub Findings - Imported (由 Hub 建立/更新) 和 Security Hub Findings - Custom Action (由操作員觸發) 事件。

過於寬鬆的規則，例如 {"source": ["aws.securityhub"]}，會在每次發現項目更新時都叫用目標，這會迅速地讓 SNS 主題被大量訊息淹沒，並用資訊性的雜訊呼叫值班工程師。正確的方法是根據 severity.Label、ProductArn、Types 或特定的 Title 值進行篩選：

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

對於一個以 Security Hub 為中心的模式，希望只在高嚴重性的 GuardDuty 發現項目上觸發，同時忽略吵雜的第三方 ISV 產品：

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

常見的目標包括：用於電子郵件/簡訊/Slack 通知的 SNS 主題、透過更換其安全群組來隔離執行個體的 Lambda 函數、一個 SSM Automation runbook，或是一個用來協調多步驟回應的 Step Functions 狀態機。對於 Aurora 登入異常的使用案例，最省力的路徑是 GuardDuty RDS Protection → 根據 RDS 發現項目類型篩選的 EventBridge 規則 → 帶有電子郵件訂閱的 SNS 主題。不需要自訂輪詢、不需要 Lambda、也不需要第三方 SIEM。

Security Hub 自訂動作

自訂動作是由操作員驅動的觸發器。在 Security Hub 主控台中，分析師選取一或多個發現項目，並選擇一個自訂動作 (例如，「隔離 EC2」)。Security Hub 會發出一個 Security Hub Findings - Custom Action 事件，其中包含所選發現項目的 ARN；一個 EventBridge 規則會比對自訂動作的 ARN，並叫用一個執行回應動作的 Lambda。這讓您無需建立客製化的 UI，就能擁有一個人為介入迴圈的按鈕：

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

產生的 ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) 會成為 EventBridge 規則中 resources 欄位的比對值。

抑制與訊號管理

雜訊管理是一門紀律，而非一次性的篩選器設定。使用 Security Hub 自動化規則或 GuardDuty 抑制規則來自動封存已知為良性的發現項目 (例如，滲透測試工具預期會產生的 Recon:EC2/Portscan 發現項目)。透過 ProductArn 篩選 EventBridge 規則，以便在不完全停用一個吵雜的第三方整合的情況下將其靜音。結合 Severity.Label 與 Workflow.Status = NEW，這樣重新開啟或已通知過的發現項目就不會再次發出呼叫。目標是讓每一個送達人手的警示都代表一個可採取行動、高可信度的事件——任何其他情況都會削弱應變準備度。

調查的切入點

當一個高嚴重性的發現項目觸發時——例如 Backdoor:EC2/C&CActivity.B!DNS——最快的調查路徑不是手動撰寫 Athena 查詢來分析 CloudTrail 和 Flow Logs。當 Amazon Detective 與 GuardDuty 一同啟用時，它會從 CloudTrail、VPC Flow Logs 和 GuardDuty 發現項目預先建立實體圖。從發現項目直接切換到 Detective 中的 IAM 角色或 EC2 執行個體設定檔，可以呈現出在相關時間範圍內的 API 活動、網路對等體，以及成功與失敗的連線計數，而無需任何自訂的查詢工作。

← 身分與存取管理 · 所有領域 · 日誌、稽核與鑑識 →

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

瀏覽 Amazon →