威脅偵測：GuardDuty、Security Hub、Macie 與 IAM Access Analyzer

AWS 上的威脅偵測是什麼

AWS 上的威脅偵測，是把原始遙測資料——CloudTrail 事件、VPC Flow Logs、DNS 查詢、S3 資料事件、EKS 稽核日誌、執行期系統呼叫、IAM 存取模式、資源組態變化——轉化為有優先順序、可採取行動的 finding 的一門學科。SCS-C02 任務聲明 1.2 要求你評估 AWS 托管服務的 finding、跨資料來源進行關聯，並在觸發事件回應前以查詢驗證結果。因此，威脅偵測既不是單一服務，也不是單一儀表板；它是一條有明確意見的 pipeline，從 GuardDuty 的行為與威脅情報偵測出發，疊加 Security Hub 的 finding 聚合與合規評分，加入 Macie 對敏感資料風險的偵測，包含 AWS Config 對組態漂移的檢查，以及 IAM Access Analyzer 對權限暴露的偵測。

考試測試你是否理解每項服務的優勢、缺口與重疊。它也測試你能否識別 finding 本身不夠的情況——何時需要透過 Detective 建立行為圖、對 Security Lake 或原始 CloudTrail 執行 Athena 查詢，或建立 CloudWatch 指標篩選器來捕捉沒有任何托管服務能浮現的異常。現代 AWS 威脅偵測在設計上是多來源的；單一 GuardDuty finding 幾乎不能說清楚一個事件的完整故事。本篇涵蓋所有在考試範圍內的偵測服務，展示 finding 如何流入 Security Hub，並提供在考試情境需要威脅偵測時的決策框架。

威脅偵測為何對 SCS-C02 至關重要

Domain 1——威脅偵測與事件回應——佔考試 14%，而任務聲明 1.2 單獨涵蓋 finding 評估、跨服務關聯、基於查詢的驗證，以及基於指標的異常偵測。實際上，這表示你的考試中大約有 7 至 9 道題將取決於你如何在 GuardDuty、Security Hub、Macie、Detective、Athena、CloudWatch 與 Config 之間做出選擇。更麻煩的是，任務 1.1 和 1.3 中許多事件回應題目都以「GuardDuty 發出一個 finding……」開頭——這意味著你對威脅偵測的理解，決定了你能否解讀題目本身。

考試風格幾乎不是「GuardDuty 是什麼？」而是「GuardDuty 在生產 EC2 執行個體角色上發出 UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding；安全團隊需要確認憑證是否在 AWS 外部被使用，以及哪些 API 被呼叫。哪種服務組合能以最低的維運負擔驗證這一點？」正確答案幾乎不是單一服務。威脅偵測掌握度代表你能不假思索地串連 GuardDuty（告警）→ Detective（關聯）→ Athena（驗證）→ Security Hub（集中化）→ EventBridge（回應）。

Amazon GuardDuty 深度解析

Amazon GuardDuty 是永遠啟用的托管威脅偵測服務。它分析三個基礎資料來源——CloudTrail 管理事件、VPC Flow Logs 與 DNS 查詢日誌——而無需你明確啟用它們，另外還有可選的保護方案，涵蓋特定工作負載。GuardDuty 結合機器學習、異常偵測與來自 AWS Security 及合作夥伴（CrowdStrike、Proofpoint）的精選威脅情報清單，以 0.1 至 8.9 的嚴重性分數以及 Low（1.0–3.9）、Medium（4.0–6.9）、High（7.0–8.9） 等嚴重性等級浮現 finding。

GuardDuty 保護方案

保護方案將覆蓋範圍延伸至基礎來源之外。每個方案可以按帳號啟用，或透過 Organizations 層級的委派管理員集中啟用：

• S3 Protection — 分析 S3 資料平面事件（GetObject、PutObject），偵測憑證誤用、資料外洩模式，以及來自匿名主體的存取。Discovery:S3/* 與 Exfiltration:S3/* finding 需要此方案。
• EKS Protection — 分為 EKS Audit Log Monitoring（控制平面）與 EKS Runtime Monitoring（透過工作節點上的 GuardDuty agent 偵測資料平面）。偵測 pod 逃逸、特權容器建立與反向 shell。
• Malware Protection — 對可疑 EC2 執行個體或 ECS/Fargate 任務上掛載的 EBS 磁碟區進行無 agent 掃描。在 GuardDuty 發出特定 finding 時自動觸發，或可對 S3 物件按需執行（Malware Protection for S3）。
• RDS Protection — 分析 RDS 登入活動（目前為 Aurora MySQL/PostgreSQL），偵測暴力破解、異常登入與憑證洩漏。
• Lambda Protection — 監控 Lambda 網路活動，偵測連接已知惡意 IP 或挖礦域名的行為。
• Runtime Monitoring — 將 EKS 執行期偵測擴展至 ECS on Fargate 與 EC2，使用托管 agent 觀察程序、檔案與網路系統呼叫。

GuardDuty Finding 類型

GuardDuty finding 類型遵循格式 ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.ThreatFamilyVariant!Artifact。威脅目的是你在考試題目中掃描的關鍵：

• Backdoor — 執行個體充當殭屍機，C2 通訊。
• Behavior — 與基準相比的網路或 API 行為異常。
• CryptoCurrency — 比特幣/門羅幣挖礦域名或礦池聯繫。
• Discovery — 偵察行為，從異常位置呼叫 GetCallerIdentity。
• Exfiltration — 資料被移出帳號，S3 GetObject 量異常。
• Impact — 破壞性行為，大量刪除 API 呼叫。
• Pentest — Kali、ParrotLinux、Pentoo user-agent。
• Persistence — 從異常位置建立新 IAM 使用者/角色。
• Policy — 使用 root 憑證，S3 Block Public Access 被停用。
• PrivilegeEscalation — 異常的 AssumeRole 進入高權限角色。
• Recon — 連接埠掃描、EC2 metadata 枚舉。
• Stealth — CloudTrail 日誌記錄被停止，密碼政策被弱化。
• Trojan — DGA 域名、黑洞流量、落點 IP。
• UnauthorizedAccess — 憑證外洩，從異常位置登入主控台，RDP 暴力破解。

抑制規則 vs 信任清單/威脅清單

這三種控制看起來相似，但解決不同問題，考試很喜歡把它們混在一起：

• 抑制規則（Suppression rules） — 自動封存符合屬性篩選條件的 finding（例如：accountId == 111122223333 AND type == 'Recon:EC2/Portscan'）。Finding 仍會產生但移至封存狀態；它們不會流入 Security Hub 或 EventBridge。
• 信任 IP 清單（Trusted IP lists） — GuardDuty 對這些 IP CIDR 的 VPC Flow Logs 或 CloudTrail 型 finding 不會發出告警。每個區域最多一份清單，最多 2,000 筆。完全跳過偵測。
• 威脅 IP 清單（Threat IP lists） — GuardDuty 會以 UnauthorizedAccess:EC2/MaliciousIPCaller.Custom 或類似的自訂 finding 標記這些 IP CIDR。每個區域最多六份清單。

AWS Security Hub 深度解析

AWS Security Hub 是雲端安全態勢管理（CSPM）與 finding 聚合服務。它執行三項工作，在考試中常常混淆：它聚合來自原生 AWS 服務與合作夥伴的 finding，它執行安全標準持續評估你的帳號是否符合合規框架，以及它自動化 finding 工作流程（自訂動作與自動化規則）。

Security Hub 安全標準

Security Hub 內建數個托管標準。每個標準是一組精選的 AWS Config 規則與 Security Hub 原生檢查：

• AWS Foundational Security Best Practices（FSBP）v1.0.0 — AWS 自訂的固執觀點基準。涵蓋 30+ 個服務的 250+ 個控制。永遠先啟用這個。
• CIS AWS Foundations Benchmark v1.4.0 / v3.0.0 — 網際網路安全中心基準；涵蓋 IAM、日誌、監控、網路。
• CIS AWS Foundations Benchmark v1.2.0 — 較舊的傳統版本，部分稽核人員仍要求使用。
• PCI DSS v3.2.1 / v4.0.1 — 支付卡產業控制。
• NIST SP 800-53 Rev. 5 — 完整的美國聯邦基準；700+ 個控制。
• AWS Resource Tagging Standard — 較新，專注於標籤合規。
• Service-Managed Standard: AWS Control Tower — Control Tower 部署控制時自動啟用。

每個控制產生 PASSED、FAILED、WARNING 或 NOT_AVAILABLE 結果。聚合後，它們產生每個標準的分數與 Security Hub 整體分數，兩者都是態勢儀表板的優秀關鍵績效指標。

Finding 聚合與跨區域聚合器

Security Hub 是區域性服務。若要跨區域集中，你需要在指定的主要區域設定 finding 聚合器（也稱為跨區域聚合）。聚合器從連結的區域拉取 finding，Security Hub 持續將更新複製回去，讓工作流程狀態變更得以傳播。將此與 AWS Organizations 中的委派管理員模式結合，你就能為整個組織獲得單一帳號、單一區域的統一管理介面。

自訂 Insight

自訂 insight 是針對 finding 儲存庫的已儲存查詢，以屬性分組（例如 ResourceId、AwsAccountId、ProductArn）。Insight 是你在 Security Hub 主控台內建立「最吵的前 10 名帳號」或「所有生產資源上的嚴重 finding」儀表板的方式。它們是唯讀視圖；不會修改 finding。

自動化規則

自動化規則（2023 年推出）讓你在 finding 到達時無需撰寫 Lambda 即可修改它。規則有條件（ASFF 欄位的篩選條件）與動作（設定 Workflow 狀態、設定 Severity、新增 Note、設定自訂欄位）。常見模式：

• 自動抑制沙箱帳號上的 FSBP 控制失敗。
• 提升任何標記 production: true 資源上的 finding 嚴重性。
• 當 finding 符合已知誤報形態時，新增備註「已由 SOC tier-1 審查」。
• 自動解決超過 90 天且符合低嚴重性資訊類型的 finding。

Security Hub 整合

Security Hub 原生接收來自 GuardDuty、Macie、Inspector、IAM Access Analyzer、AWS Config（透過 Config Conformance Pack 對應）、Firewall Manager、Health、Systems Manager Patch Manager 與 IoT Device Defender 的 finding。另外還有 70+ 個合作夥伴產品（CrowdStrike、Trend Micro、Palo Alto Cortex、Wiz、Lacework 等），全部以 ASFF 格式發布。考試模式：當你看到「第三方掃描器的 finding 需要與 AWS finding 並排出現」，答案是 Security Hub via ASFF。

Amazon Macie 資料威脅偵測

Amazon Macie 探索並分類 S3 儲存桶中的敏感資料，然後發出 policy finding（儲存桶層級態勢）與 sensitive data finding（物件層級內容）。它是考試中「如何偵測包含 PII／信用卡號／健康資料的 S3 儲存桶？」的首選答案。

托管與自訂資料識別符

托管資料識別符是 AWS 精選的偵測模式。100+ 個托管識別符涵蓋憑證（AWS 存取金鑰、GitHub token）、金融（信用卡號、SWIFT 代碼）、PII（美國 SSN、歐盟護照、巴西 CPF）與健康（美國 HCPCS 代碼）。你也可以將自訂資料識別符撰寫為帶有鄰近關鍵字需求與最大匹配數的正規表達式。

自動化敏感資料探索 vs 分類作業

Macie 同時以兩種模式運行：

• 自動化敏感資料探索 — 在帳號/組織中所有 S3 儲存桶中持續運行的抽樣掃描。為每個儲存桶與物件產生 敏感性分數（0–100）。永遠啟用，低成本。
• 分類作業 — 顯式的排程或一次性作業，完整（或抽樣）掃描定義的儲存桶集合。產生詳細的敏感資料 finding。成本較高，覆蓋率較深。

Macie Finding 類型

• Policy:IAMUser/S3BlockPublicAccessDisabled — 儲存桶不再強制執行 BPA。
• Policy:IAMUser/S3BucketEncryptionDisabled — 預設加密被移除。
• Policy:IAMUser/S3BucketPublic — 儲存桶政策或 ACL 授予公開讀取。
• SensitiveData:S3Object/Credentials — 物件中含有 AWS 金鑰／私密 SSH 金鑰。
• SensitiveData:S3Object/Financial — 信用卡或金融資料。
• SensitiveData:S3Object/Personal — 符合 PII。
• SensitiveData:S3Object/Multiple — 符合多個類別。

所有 Macie finding 在整合啟用時自動發布到 Security Hub。

IAM Access Analyzer 深度解析

IAM Access Analyzer 是權限暴露的威脅偵測服務。它不偵測執行期威脅；它在被利用前偵測政策層級的風險。該服務已演化為三種不同的分析器類型，經常讓考生感到困惑。

外部存取分析器

最初的分析器。識別你的帳號或組織中授予外部主體存取的資源——在你的信任區域之外的帳號。支援的資源包括 S3 儲存桶、IAM 角色（信任政策）、KMS 金鑰、Lambda 函數、SQS 佇列、Secrets Manager secret、RDS 快照、EFS 檔案系統、ECR 儲存庫與 SNS 主題。Finding 顯示主體、資源、條件與存取路徑。最好在組織範圍運行，這樣跨帳號但仍在內部的存取就不會被標記。

未使用存取分析器

2023 年推出，單獨計費。識別信任區域（帳號或組織）內未使用的 IAM 使用者、角色、存取金鑰與權限。浮現：

• 密碼/金鑰在 N 天內未使用的 IAM 使用者。
• N 天內未被假設的 IAM 角色。
• 已授予但從未調用的 IAM 權限（服務與動作）。

用於最小權限精調。Finding 以 Software and Configuration Checks/AWS Security Best Practices/Unused IAM Permission 類型流入 Security Hub。

自訂政策檢查（驗證與自訂檢查）

兩種類型：

• 政策驗證 — 免費；對 JSON 政策文件執行並在儲存政策前回傳 finding（錯誤、安全警告、建議、一般警告）。使用基於 Zelkova 的自動推理。
• 自訂政策檢查 — 付費；CI/CD 友好的檢查，如 CheckAccessNotGranted（驗證政策是否未授予指定動作）或 CheckNoNewAccess（驗證新政策是否未授予比舊政策更多的權限）。用作 pipeline 中的護欄。

AWS Config 作為偵測來源

AWS Config 主要是組態追蹤服務，但它的規則（托管與自訂）會產生饋送到 Security Hub 的合規 finding。每個 Config 規則根據期望狀態評估資源組態，並發出 COMPLIANT／NON_COMPLIANT 評估結果。NON_COMPLIANT 評估結果成為 Software and Configuration Checks/AWS Config/Compliance 類型的 Security Hub finding。

Config 偵測 GuardDuty 無法處理的威脅相鄰問題：

• 未啟用預設加密建立的 S3 儲存桶（s3-bucket-server-side-encryption-enabled）。
• 在連接埠 22 上允許 0.0.0.0/0 的安全群組（restricted-ssh）。
• 弱化的 IAM 密碼政策（iam-password-policy）。
• CloudTrail 追蹤被停用（cloudtrail-enabled）。
• 存在 root 帳號存取金鑰（iam-root-access-key-check）。

將 Config 與 Conformance Pack（與 NIST、HIPAA、PCI 對齊的範本化套件）配對，以取得即時合規基準；與 Auto Remediation（在 NON_COMPLIANT 時觸發的 SSM Automation 文件）配對，實現自我修復。

白話文解釋

威脅偵測聽起來很玄，但其實就是把雲端裡每天發生的事情錄下來，用三個不同角度的「監視器」找出哪些事情看起來不對勁。讓我用三個生活化的例子讓你秒懂這六、七個服務的分工。

類比一：便利商店的防盜與保全系統。GuardDuty 就是超商那套 24 小時的 AI 監控系統，它不管你的庫存有多少，而是看「這個人平常都是早上來買早餐，今天凌晨三點突然拿了整箱商品往後門走」這種行為模式。它盯著三條基本資料：收銀機的交易紀錄（CloudTrail）、店內監視器影像（VPC Flow Logs）、門口感應紀錄（DNS logs），加上超商總部共享的慣竊黑名單（threat intel lists）。Security Hub 則是保全公司的「全台通報中心」——所有門市（GuardDuty、Macie、Inspector）的可疑事件統一彙總到這裡，按法規（FSBP、CIS、PCI）打合規分數。Macie 是專門看儲藏室的保全員：它知道哪個架子放的是金飾（PII、信用卡號），哪個只是空紙箱。Detective 是刑事組的調查員，當通報中心覺得這筆案子可疑，調查員接手把這個人過去三個月所有相關的進出門市紀錄、使用的卡片、出沒的地點畫成關係圖，讓你一眼看穿背後脈絡。Athena 則是警局的案件資料庫搜尋：當你需要在十億筆交易紀錄中精確查「2026 年 4 月 24 日早上 9:15 到 9:20，誰用了這把存取金鑰」，Athena 用 SQL 直接查 S3 裡的原始 log。

類比二：夜市攤位巡邏隊與入口 X 光機。AWS Config 就像夜市入口的固定式 X 光機：每個進場攤車（資源）通過時都掃一次，看看有沒有違規（沒加密、連接埠 22 對外開放、CloudTrail 被關掉）。它不負責抓壞人，只負責確認所有攤車都符合規定。IAM Access Analyzer 是「攤位使用授權稽查員」：它不看攤車有沒有賣違禁品，而是看「這個攤位的鑰匙到底發給多少場外人員了？」（External Access Analyzer），以及「這把鑰匙過去 90 天有人用過嗎？」（Unused Access Analyzer）。Macie 是巡邏隊裡的緝毒犬，專門嗅 S3 桶裡的敏感資料。CloudWatch Metric Filter 則是巡邏隊自己設的警示牌：「如果今晚某個攤位被嘗試進入超過 100 次就響鈴」——這是你自訂的閾值警報，不需要等任何 AI 模型判定。

類比三：氣象局颱風警報系統。GuardDuty 是中央氣象局的雷達站：它一直在跑，偵測到颱風（高嚴重性 finding）會主動發警報；偵測到午後雷陣雨（低嚴重性）會記錄但不一定通知你。抑制規則就是「每年端午節都會施放煙火，請不要把煙火警報當颱風發」——告訴系統哪些已知正常事件不要叫。Trusted IP list 是「這架是我們自己的直升機，不要追蹤」。Threat IP list 反過來說「這架無人機就算偽裝成氣球也要追蹤」。Security Hub 的 Standards 是中央災防會的緊急應變準則：颱風要疏散、地震要停車、海嘯要往高處跑——每個 finding 都對應一條應該採取的標準動作。Detective 是颱風過後的損害評估小組，把雷達圖、衛星雲圖、地面回報全部攤開分析根因。

把這三個類比串起來：你的 AWS 帳號是一座城市，GuardDuty 是 24 小時雷達加警察情報，Security Hub 是 119/110 整合通報中心，Macie 是金庫稽查員，Config 是建築管理處（檢查違建），Access Analyzer 是地政事務所（檢查土地權狀），Detective 是刑事局（事後辦案），Athena 是檔案室（你問什麼它都能查）。整套組合起來才叫「威脅偵測」，少了任何一塊都會有盲點。

Amazon Detective 跨服務關聯

Detective 透過從 CloudTrail、VPC Flow Logs、EKS 稽核日誌與 GuardDuty finding 建立行為圖，將 finding 的脈絡帶到比 Security Hub 更深的層次。該圖將實體（使用者、角色、IP、執行個體、帳號）建模為節點，將其互動建模為邊，時間回溯最多一年。當你從 GuardDuty 或 Security Hub finding 點擊「在 Detective 中調查」，你會進入實體設定檔，其中有自動產生的面板：API 呼叫量隨時間的變化、來源 IP 的地理位置、存取的服務、相關 finding。

Detective 在考試中的殺手鐧功能是不需撰寫查詢的時間序列調查。圖表是預先建立並持續更新的，因此「這個 IAM 角色在 finding 前 7 天行為是否正常？」這類問題只需兩次點擊即可回答。相比之下，Athena 需要撰寫 SQL 並手動 JOIN CloudTrail 快照。

Athena 查詢用於安全事件驗證

Athena 是 SQL-on-S3 查詢引擎。對於威脅偵測，三個查詢目標至關重要：

1. CloudTrail 日誌 — 以 /AWSLogs/<accountId>/CloudTrail/<region>/yyyy/mm/dd/ 分區。使用 AWS 提供的 CloudTrail Glue 資料表定義。
2. VPC Flow Logs — 按日期與帳號分區；使用 Apache Parquet 格式可將速度與成本降低 10 倍。
3. AWS Security Lake — 標準化的 OCSF（Open Cybersecurity Schema Framework）資料表，聚合整個組織的 CloudTrail、VPC Flow、Route 53、Security Hub、EKS 稽核、Lambda 調用。查詢 Security Lake 意味著查詢一個規範化結構而非 N 種原始 log 格式。

每位 SCS-C02 考生都應熟悉的 IOC 驗證查詢範例：

-- 查詢疑似遭入侵存取金鑰在過去 24 小時發出的每個 API 呼叫
SELECT eventTime, eventName, sourceIPAddress, userAgent, awsRegion, errorCode
FROM cloudtrail_logs
WHERE userIdentity.accessKeyId = 'AKIAIOSFODNN7EXAMPLE'
  AND eventTime > date_format(current_timestamp - interval '1' day, '%Y-%m-%dT%H:%i:%sZ')
ORDER BY eventTime;

-- 與遭入侵 EC2 執行個體通訊的前幾名外部 IP
SELECT srcaddr, sum(bytes) as total_bytes, count(*) as flow_count
FROM vpc_flow_logs
WHERE dstaddr = '10.0.42.17' AND srcaddr NOT LIKE '10.%'
  AND start > to_unixtime(current_timestamp - interval '24' hour)
GROUP BY srcaddr ORDER BY total_bytes DESC LIMIT 20;

CloudWatch 指標篩選器與異常儀表板

當沒有任何托管服務能浮現你需要的內容時，你就退而求其次使用 CloudWatch 指標篩選器與自訂儀表板。指標篩選器根據 JSON 或文字模式掃描 CloudWatch Logs 條目，並在每次模式匹配時發出自訂指標。

CIS 建議的標準安全指標篩選器：

• 未授權 API 呼叫 — 模式 { ($.errorCode = "*UnauthorizedOperation") || ($.errorCode = "AccessDenied*") } 針對 CloudTrail Logs 群組。
• 未使用 MFA 登入 — { ($.eventName = "ConsoleLogin") && ($.additionalEventData.MFAUsed != "Yes") }。
• Root 帳號使用 — { $.userIdentity.type = "Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }。
• IAM 政策變更 — 模式匹配 DeleteGroupPolicy、DeleteRolePolicy、PutUserPolicy 等。
• 安全群組變更 — AuthorizeSecurityGroup*、RevokeSecurityGroup*、CreateSecurityGroup、DeleteSecurityGroup。

每個篩選器饋送一個 CloudWatch 指標，然後 CloudWatch 警示在超過閾值時觸發，然後 SNS 或 EventBridge 通知 SOC。在頂層疊加 CloudWatch 異常偵測：警示使用正常每小時行為的機器學習模型，而非靜態閾值。適用於「API 呼叫量異常飆升」的情境，無需手動調整基準。

集中 Finding：Security Hub 作為樞紐

反覆出現的考試模式：「你有 8 個帳號、4 個區域的 GuardDuty finding，加上 2 個帳號的 Macie finding，加上 12 個帳號的 Inspector finding。CISO 想要一個統一儀表板。」答案：

1. AWS Organizations，所有帳號加入。
2. 指定一個安全工具帳號（根據 AWS SRA）。
3. 從管理帳號，將安全工具帳號註冊為 GuardDuty、Security Hub、Macie、Inspector、IAM Access Analyzer 與 Detective 的委派管理員。
4. 在安全工具帳號中，為新舊組織帳號自動啟用每個服務。
5. 在選定的主要區域設定 Security Hub 跨區域聚合器。
6. 至少啟用 FSBP 標準，以及視需要啟用 CIS／NIST／PCI。
7. 在 Security Hub finding 透過 EventBridge 匯出至 S3 的基礎上，建立 CloudWatch 儀表板或 Amazon QuickSight。

多帳號組織中的威脅偵測

除了委派管理員，多帳號威脅偵測還有三個考試喜愛的額外模式：

• 組織追蹤（Organization trail） — 組織層級的單一 CloudTrail 追蹤，捕捉每個成員帳號的事件到一個 S3 bucket。成員帳號無法停用或修改。這是考試唯一可接受的「集中式 CloudTrail」架構。
• Config 聚合器（Config aggregator） — 將所有帳號與區域的 Config 組態項目與規則評估收集到單一聚合器帳號。與 Security Hub 配對以進行全組織合規評分。
• Security Lake 訂閱者帳號 — 安全工具帳號成為 Security Lake 訂閱者，並授予下游消費者（SOC 分析師透過 Athena、合作夥伴 SIEM 透過 Lambda 訂閱）對 OCSF 正規化資料的唯讀存取。

EventBridge 作為偵測到回應的橋樑

每個偵測服務預設都會將 finding 發布到 Amazon EventBridge：

• GuardDuty → aws.guardduty 來源，GuardDuty Finding detail-type。
• Security Hub → aws.securityhub，Security Hub Findings - Imported（新 finding）與 Security Hub Findings - Custom Action（分析師觸發）。
• Macie → aws.macie，Macie Finding。
• Inspector → aws.inspector2，Inspector2 Finding。
• Config → aws.config，Config Rules Compliance Change。

建立 EventBridge 規則將 finding 分發至：

• SNS 主題，向 SOC 發送人類可讀的電子郵件/SMS。
• Lambda 函數，用於自訂分類邏輯（自動標記、自動隔離）。
• Step Functions 狀態機，用於多步驟 playbook。
• Systems Manager Automation，用於預定義的 runbook（例如隔離 EC2）。
• 跨帳號 IAM 角色，路由至合作夥伴 SIEM。

調整偵測：在不失去訊號的情況下減少誤報

嘈雜的偵測 pipeline 比沒有 pipeline 更糟，因為 SOC 會開始忽略警報。考試測試的調整模式：

• GuardDuty 抑制規則，用於已知正常的屬性組合（開發人員工作站 IP 對測試基礎架構進行連接埠掃描）。
• GuardDuty 信任 IP 清單，用於企業 VPN 出口。
• Security Hub 自動化規則，降低標記開發/沙箱帳號上 finding 的嚴重性。
• Macie 允許清單，排除已知誤報的物件模式（樣本資料、示範 CSV）。
• Inspector 抑制規則，按 CVE 加資源標籤。
• Config 規則範圍，限定特定資源類型或標籤篩選器。
• CloudWatch 複合警示，要求多個同時條件才會發出呼叫。

常見考試陷阱

• GuardDuty 不需要啟用 CloudTrail 或 VPC Flow Logs。 它透過私有饋送讀取它們。單獨啟用那些服務可提供 Athena/CloudWatch 的日誌，但不影響 GuardDuty。
• Security Hub 是區域性服務。 在 4 個區域有工作負載的單一帳號，需要在所有 4 個區域加上一個聚合器才有 Security Hub。
• Inspector v2（Inspector）與 Inspector Classic 不同。 目前的 Inspector 持續掃描 EC2、ECR 與 Lambda，並發布到 Security Hub。Inspector Classic 已棄用。
• Macie 自動化探索是全組織的，前 30 天免費。 之後按掃描的 GB 計費。完整分類作業是單獨的計費項目。
• IAM Access Analyzer finding 在底層政策變更時自動解決。 不要撰寫 Lambda 來清理它們。
• Detective 需要 GuardDuty 在某個區域啟用至少 48 小時才能在該區域啟用。行為圖從 GuardDuty 的 CloudTrail/VPC/DNS 饋送建立。
• Athena 查詢 CloudTrail bucket 需要 Glue 資料表。 使用 AWS 提供的範本；手動撰寫結構描述容易出錯。
• CloudWatch 指標篩選器不會回溯處理舊 log 行。 它們只適用於篩選器建立後攝取的日誌。

決策框架：哪個服務偵測什麼？

考試情境描述偵測需求時，使用這張表格：

成本考量

偵測服務依使用量計費。考試用的粗略心理模型（不要記住確切費率）：

• GuardDuty 基礎 — 每百萬 CloudTrail 事件、每 GB VPC Flow Logs、每百萬 DNS 查詢。保護方案增加每資源成本（Runtime Monitoring 每 vCPU 小時，S3 Protection 每百萬 S3 事件）。
• Security Hub — 每個攝取的 finding 加每個評估的安全檢查。在嘈雜帳號中最貴。
• Macie — 每 GB 掃描（完整分類作業）加每個評估的 S3 儲存桶（自動化探索）。
• Inspector — 每個資源（EC2、ECR 映像、Lambda）每月。
• Detective — 每 GB 攝取日誌。
• Athena — 每 TB 掃描（使用 Parquet/分區大幅降低成本）。

實機練習實驗室概要

在考試前在沙箱帳號中執行以下實驗室，以鞏固所有內容：

1. 啟用 GuardDuty + S3 Protection + Malware Protection。
2. 啟用 Security Hub 並啟用 FSBP 與 CIS v3.0.0。
3. 啟用 Macie 並開啟自動化探索。
4. 啟用 IAM Access Analyzer（外部存取 + 未使用存取）。
5. 啟用 Inspector 用於 EC2/ECR。
6. 啟用 Detective。
7. 使用 GuardDuty aws guardduty create-sample-findings API 產生測試 finding。
8. 觀察 finding 如何流入 Security Hub。
9. 在某個 finding 上點擊「在 Detective 中調查」。
10. 針對你的 CloudTrail bucket 撰寫 Athena 查詢，將 finding 的主體 ID JOIN 至 API 呼叫歷史。
11. 建立未授權 API 呼叫的 CloudWatch 指標篩選器；用刻意的 AccessDenied 呼叫觸發它。
12. 建立一條 EventBridge 規則，將 GuardDuty 高嚴重性 finding 路由至 SNS 主題。
13. 建立一條 Security Hub 自動化規則，為標記 env=prod 的資源上的 finding 提升嚴重性。

常見問題

Q1：何時應使用 Detective 而非 Athena 進行調查？ 當你需要預先建立的、時間序列的、實體關係視圖而無需撰寫 SQL 時，使用 Detective。行為圖將 CloudTrail、VPC Flow、EKS 稽核與 GuardDuty finding 聚合為實體設定檔。當你需要精確的臨時查詢（例如「這個存取金鑰呼叫 s3:DeleteObject 的每個事件」）、需要與非 AWS 資料 JOIN、或需要跨多個帳號查詢 Security Lake 的 OCSF 結構時，使用 Athena。許多 SCS-C02 問題同時提供兩者作為選項；判斷標準是「低維運負擔、視覺化調查」→ Detective；「具體 SQL 問題、大量資料、自訂」→ Athena。

Q2：啟用 GuardDuty 是否自動啟用 Security Hub，反之亦然？ 不。每個服務獨立啟用。但是，當兩者在相同帳號與區域同時啟用時，GuardDuty finding 會透過整合自動流入 Security Hub。Macie、Inspector、IAM Access Analyzer 與 AWS Config 亦然。在 Security Hub 中停用整合會停止聚合，但不會停止來源服務產生 finding。

Q3：如何與合作夥伴 SIEM 共享 GuardDuty finding（例如 Splunk、Datadog）？ 三種模式：（1）aws.guardduty 來源的 EventBridge 規則，轉發至 Lambda → SIEM HTTP API，（2）如果你的 SIEM 在支援清單上，使用 Security Hub 合作夥伴整合，（3）Security Hub finding 透過 EventBridge 匯出至 S3，然後由 SIEM 攝取。考試優先選擇的模式是 Security Hub 以 ASFF 格式聚合，然後 EventBridge 至 SIEM。這避免了每個服務的自訂管線。

Q4：GuardDuty 抑制規則與 Security Hub finding 抑制有何不同？ GuardDuty 抑制規則在 GuardDuty 層封存匹配的 finding，因此它們永遠不會到達 Security Hub。Security Hub finding 抑制使用透過 BatchUpdateFindings 或自動化規則設定的工作流程狀態 SUPPRESSED；finding 仍存在於 Security Hub 但從預設視圖中隱藏。當某個 finding 類型無條件地是雜訊時，使用 GuardDuty 抑制；當你希望 finding 對稽核人員可見但從活躍佇列中排除時，使用 Security Hub 抑制。

Q5：如何在不每天掃描整個儲存桶的情況下偵測包含 PII 的 S3 儲存桶？ 在組織層級啟用 Macie 自動化敏感資料探索。它持續對所有 S3 儲存桶的物件進行抽樣，並產生敏感性分數以及 policy/sensitive-data finding。對特定儲存桶的徹底掃描，每月或每季排程分類作業。這種組合——永遠啟用的抽樣加上定期深度掃描——是 SCS-C02 敏感資料威脅偵測的最佳實踐。

Q6：我可以在 VPC Flow Logs 上使用 CloudWatch 指標篩選器嗎？ 可以，如果 VPC Flow Logs 傳送到 CloudWatch Logs 群組（而非 S3）。對拒絕的流量、特定來源 IP 或異常連接埠進行模式匹配。但是，GuardDuty 已原生分析 VPC Flow Logs 並產生更高品質的 finding；指標篩選器最適合保留給 GuardDuty 無法浮現的自訂閾值。對於高流量的 Flow 資料，改為傳送到 S3 並使用 Athena 查詢。

Q7：什麼是 AWS Security Finding Format（ASFF），為什麼它很重要？ ASFF 是 AWS 上安全 finding 的標準化 JSON 結構描述。它定義了 Severity、Resources[]、Types[]、ProductFields、Workflow.Status 與 RecordState 等欄位。每個與 Security Hub 的原生與合作夥伴整合都透過 BatchImportFindings API 以 ASFF 格式發布。當題目提到「從第三方工具集中 finding」或「建立出現在 Security Hub 中的自訂安全服務」時，考試就會測試 ASFF。答案：發出 ASFF。

Q8：我應該啟用所有 Security Hub 標準，還是僅啟用 FSBP？ 從 FSBP 開始——它是 AWS 精選的，涵蓋最常見的錯誤設定。如果你有 CIS 稽核義務，加入 CIS v3.0.0；如果你處理卡片資料，加入 PCI DSS；如果你服務美國聯邦客戶，加入 NIST 800-53。每個啟用的標準都會增加 finding 量與成本；只啟用你的合規計畫所需的標準。考試經常問「哪個標準滿足要求 X」——記住四個主要框架及其使用案例。

Q9：IAM Access Analyzer 與 IAM Policy Simulator 有何不同？ Access Analyzer 是偵測——它透過分析靜態政策找出現有的暴露（外部主體有存取權限、未使用的權限）。Policy Simulator 是測試——你提供主體、動作、資源與脈絡，它告訴你請求是否會被目前的政策允許。使用 Access Analyzer 進行持續監控；使用 Policy Simulator 進行「這個提議的政策是否有效？」的預飛行檢查。它們是互補的，而非可互換的。

Q10：當帳號離開組織時，Security Hub finding 會發生什麼？ 委派管理員失去對該帳號未來 finding 的可見性。現有的聚合 finding 仍保留在安全工具帳號的 Security Hub finding 儲存中，但對於來源帳號而言變為唯讀。重新加入帳號不會重新匯入歷史 finding；它從重新加入的時刻起恢復聚合。如果你需要持續的稽核歷史，請謹慎規劃帳號離開。

總結與後續步驟

AWS 上的威脅偵測是一條分層的 pipeline，而非單一服務。GuardDuty 處理 CloudTrail、VPC Flow、DNS 與可選保護方案的行為與威脅情報偵測。Security Hub 聚合來自 GuardDuty、Macie、Inspector、IAM Access Analyzer、Config 與合作夥伴的 finding——並執行持續的合規標準（FSBP、CIS、PCI、NIST）。Macie 處理 S3 上的敏感資料威脅偵測。IAM Access Analyzer 偵測權限暴露（外部存取）與休眠（未使用存取）。AWS Config 提供組態狀態 finding。Detective 透過行為圖加速調查。Athena 針對 Security Lake 或原始日誌驗證事件。CloudWatch 指標篩選器與儀表板捕捉其他任何服務無法浮現的內容。

對於 SCS-C02 任務聲明 1.2，元技能是在限制條件下選擇服務：給定情境題目，選擇以適當維運負擔、成本與整合深度實現偵測的最小服務集合。反覆練習上方的決策表直到成為反射動作。然後繼續前往任務聲明 1.3（回應自動化）——如果 Security Hub finding 不觸發修復，它們就毫無用處。威脅偵測是輸入；事件回應是輸出。