為什麼安全監控與告警設計對 SCS-C02 考試如此重要
安全監控與告警設計是 AWS Certified Security – Specialty（SCS-C02）考試 Domain 2 的核心，佔總分 18%。Task 2.1 與 2.2 要求你設計 CloudWatch metric filter、EventBridge 規則、Security Hub insight、GuardDuty 行為基線，以及 SNS 告警扇出——並在安全監控與告警 pipeline 靜默失效時進行疑難排解。這個主題頻繁出現在情境題中，錯誤的服務組合、缺少的 IAM 權限，或鬆散的事件比對條件，可能讓你在兩分鐘與兩天之間才能偵測到憑證洩漏。
由於 AWS 上的安全監控與告警橫跨七個以上相互傳遞事件的服務，只記憶單一服務的應試者往往失分。考試鍾愛串接式 pipeline：GuardDuty 發現 → EventBridge 規則 → Lambda 函數 → SNS 主題 → AWS Chatbot → Slack。每一跳都有權限邊界、事件格式合約，以及失效模式。紮實的安全監控與告警設計要求你同時考慮所有環節。
本主題筆記將安全監控與告警視為一套系統，而非功能清單。我們將逐一檢視資料平面（事件從何而來）、控制平面（哪個 AWS 服務負責評估）、行動平面（誰收到通知或什麼被自動修復），最後是告警失效時的疑難排解決策樹。讀完之後，你應能在白板上畫出安全監控與告警架構、解釋每條箭頭的理由，並診斷任何斷掉的環節。
安全監控與告警的核心積木
AWS 上的安全監控與告警由一小組基本元件組成，可組合出多種模式。CloudWatch 提供指標、告警、日誌群組與儀表板。EventBridge 提供事件匯流排、規則、排程與輸入轉換器。Security Hub 提供 ASFF 聚合器與自訂 insight。GuardDuty 提供受管理的威脅情資基線。Lambda 與 Step Functions 提供執行動作的運算資源。SNS、SQS 與 AWS Chatbot 提供人工通知管道。
考試的重複題型要求你為正確的工作選擇正確的元件。CloudWatch 告警在時間視窗內監控數值指標；EventBridge 規則監控個別事件的結構；Security Hub 監控跨安全服務正規化後的發現。若混淆這三者，你會在需要規則時去設告警，或建立一個輪詢 CloudTrail 的 Lambda，而 EventBridge 本可免費幫你觸發。
安全監控與告警同樣區分「監控」（收集遙測資料、計算聚合值）與「告警」（通知人員或觸發自動化）。許多考試的錯誤選項混淆了兩者——例如聲稱可以直接從 CloudWatch Logs metric filter 發布到 SNS。這是不可能的：filter 建立指標，告警監控指標，告警才發布到 SNS。
ASFF 是 Security Hub 用來正規化來自 GuardDuty、Inspector、Macie、IAM Access Analyzer、AWS Config、AWS Health、第三方合作夥伴與自訂整合的發現所使用的 JSON 結構描述。每個 Security Hub 發現都有相同的頂層結構（Severity、Resources、Workflow、Compliance、ProductFields），讓 EventBridge 的比對條件在所有來源中均可預測。參考：https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html
安全監控與告警的 CloudWatch 模式
CloudWatch 是 AWS 上所有數值型安全監控與告警的基礎底層。SCS-C02 考試主要出現三種模式：log group 上的 metric filter、用於降噪的複合告警，以及異常偵測帶狀區間。
Metric Filter 在 Log Group 上 → CloudWatch 告警 → SNS
第一個標準模式從 CloudWatch Logs log group 開始——通常是 CloudTrail 或 VPC Flow Logs 寫入的那個。你附加一個 metric filter，對每個日誌事件掃描某個比對條件（例如 { $.eventName = "ConsoleLogin" && $.errorMessage = "Failed authentication" }）。當比對成立，filter 就遞增一個自訂 CloudWatch 指標。CloudWatch 告警監控該指標，當閾值觸發時告警轉為 ALARM 狀態並發布到 SNS 主題。SNS 主題再扇出至電子郵件、AWS Chatbot、PagerDuty 或 Lambda 訂閱者。
考試會考每個步驟。你必須記得：只有在 trail 明確設定 CloudWatch Logs 角色的情況下，CloudTrail 日誌才會落入 CloudWatch Logs。你必須記得：metric filter 只套用於 filter 建立之後才被 ingested 的日誌事件——歷史資料不會被掃描。你必須記得：SNS 訂閱必須由接收端確認後，主題才能向其傳遞訊息。
複合告警用於降噪
單一指標的單一告警對大多數安全訊號而言太吵。複合告警讓你可以對多個子告警表達布林規則——例如「只在（登入失敗 > 5）AND（地理位置異常 = true）AND（NOT 維護視窗）時才發出告警」。複合告警降低安全運作中心的傳呼負擔，只浮現可能是真實事件的相關事件。
建立一個「ChangeWindow」告警，其狀態由你從 CI/CD pipeline 發布的 CloudWatch 指標驅動。在複合規則中以 NOT ALARM("ChangeWindow") 引用它，即可在計劃性部署期間靜音安全告警，而不需停用底層偵測器。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm_How_To.html
異常偵測帶狀區間
對於具有每日或每週季節性的指標——登入量、API 呼叫速率、特定角色的 S3 GetObject 次數——固定閾值在尖峰時段告警過多，或在離峰時段錯過攻擊。CloudWatch Anomaly Detection 使用最多兩週的歷史資料訓練出預期值的帶狀區間。當指標偏離帶狀區間超過 N 個標準差時觸發告警。這個模式在「使用者行為基線」情境題中深受考試青睞。
若在主動事件發生期間啟用異常偵測，模型會將攻擊行為學習為正常。請務必以已知良好的時間視窗為異常帶狀告警的訓練起點。由於模型持續重新訓練，長時間的事件最終會壓平帶狀區間。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html
以 EventBridge 實現安全自動化
EventBridge 是連接偵測服務與行動服務的事件匯流排。CloudWatch 告警監控指標，而 EventBridge 規則監控個別事件的結構。每個值得了解的安全服務都會向預設匯流排發出事件：GuardDuty、Security Hub、Config、AWS Health、IAM Access Analyzer、Macie、Inspector 與 CloudTrail 管理事件。
GuardDuty 發現規則
考試最常考的規則是 GuardDuty 發現規則。比對條件設為 source = "aws.guardduty" 且 detail-type = "GuardDuty Finding"。通常再進一步縮小 detail.severity 的範圍——例如 { "numeric": [">=", 7] }——只對 HIGH（嚴重性 7.0–8.9）與 CRITICAL（嚴重性 9.0+）的發現告警，抑制否則會淹沒頻道的 LOW 發現。
IAM 根帳號使用規則
每個受規範的環境都必須在 AWS 帳號根使用者登入或進行 API 呼叫時發出告警。比對條件設為 CloudTrail 事件中 detail.userIdentity.type = "Root" 且 detail.eventType != "AwsServiceEvent"。搭配一個可立即傳呼值班工程師的 SNS 目標。考試將此視為每個多帳號題目的基本控制項。
Config 合規變更規則
當 Config 規則將資源從 COMPLIANT 轉為 NON_COMPLIANT 時，Config 發出 source = "aws.config" 且 detail-type = "Config Rules Compliance Change" 的事件。過濾 detail.newEvaluationResult.complianceType = "NON_COMPLIANT" 讓你只在狀態實際惡化時觸發修復 Lambda，而不是每次定期重新評估都觸發。
Security Hub 發現規則（含嚴重性過濾器）
Security Hub 以 ASFF 格式在 source = "aws.securityhub" 且 detail-type = "Security Hub Findings - Imported" 重新發出所有底層服務的發現。SCS-C02 最愛的過濾條件是 detail.findings[0].Severity.Label 符合 "HIGH" 或 "CRITICAL"，並搭配 detail.findings[0].Workflow.Status = "NEW"，讓已分類的發現不再重複傳呼團隊。
設定 "Severity": "HIGH" 的規則不會比對到 JSON 中包含 "severity": 7 的發現，因為欄位名稱大小寫不同且值的類型也不同。在撰寫規則之前，務必從 Security Hub 控制台的「Sample event」面板複製實際事件，並使用輸入轉換器重塑資料——而非用比對條件強制轉型。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html
自動修復 Pipeline
EventBridge 規則比對後，問題變成：AWS 應該做什麼？兩種主要模式是：EventBridge → Lambda 用於固定的單步驟動作，以及 EventBridge → Step Functions 用於需要分支、重試或人工核准的多步驟工作流程。
EventBridge → Lambda 用於固定動作
當修復動作是單一 API 呼叫時使用 Lambda：撤銷安全群組的輸入規則、停用 IAM 存取金鑰、附加隔離政策、終止 EC2 執行個體、建立 EBS 磁碟區快照。Lambda 函數從輸入事件讀取發現，呼叫一兩個 AWS API，並寫下結構化日誌供稽核。冷啟動延遲是可接受的，因為安全修復幾乎不需要毫秒級的回應速度。
EventBridge → Step Functions 用於多步驟流程
當修復需要分支（「若執行個體在生產環境，先傳呼；否則自動隔離」）、平行工作（「建立磁碟區快照 AND 複製記憶體傾印 AND 標記 forensic-hold」）、重試政策（「以指數退避重試 API 呼叫三次」），或透過 SNS-and-token 活動進行人工核准時，使用 Step Functions。Step Functions 還提供稽核人員喜愛的視覺化執行歷程。
- 對於 Lambda 目標，EventBridge 使用 Lambda 函數上的資源型政策（
AddPermission搭配events.amazonaws.com）。 - 對於 SNS、SQS、Step Functions 與 Kinesis 目標，EventBridge 使用你在規則中指定的 IAM 角色。
- 對於跨帳號目標，目的地帳號的匯流排政策必須允許來源帳號的
PutEvents，且目的地端的規則再分派到實際目標。 參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-resource-based.html
自訂 Security Hub Insight 與 Automation Rule
Security Hub insight 是對 ASFF 發現的已儲存查詢。控制台內建約十幾個受管理的 insight（依發現數量排列的最高風險資源、依嚴重性排列的最高風險帳號等）。自訂 insight 讓你表達自己的分組查詢——例如「過去 7 天所有標記 env=prod 的資源中，CRITICAL 發現依 ResourceId 分組」。Insight 是唯讀檢視，本身不觸發任何動作。它們相當於儀表板層次的 SQL GROUP BY。
Security Hub automation rule（2023 年推出）確實採取行動。Automation rule 包含一個條件區塊（ASFF filter）與一個動作區塊（設定 Workflow.Status、設定 Severity.Label、抑制、新增備注，或變更 Confidence）。它們在 Security Hub 內部伺服器端執行，在發現重新發布到 EventBridge 之前就已處理完畢。這讓你可以，例如，自動抑制 dev 帳號資源上的發現，或自動提升標記 pci=true 的資源上的嚴重性。Automation rule 按優先順序執行；只有符合條件的規則才會觸發，且規則可以標記為 terminal 以中斷後續規則的執行。
由於 Security Hub automation rule 可以在發現重新發布到 EventBridge 之前對其進行變更或抑制，你的下游 EventBridge 規則看到的是後規則狀態。若你的自動修復 Lambda 未被觸發，請先檢查 Security Hub automation rule 清單，再檢查 EventBridge 比對條件。參考：https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html
GuardDuty 行為基線追蹤與行為監控
GuardDuty 是 AWS 安全監控與告警的受管理威脅偵測骨幹。它預設分析三個主要資料來源——VPC Flow Logs、CloudTrail 管理事件與 Route 53 DNS 查詢日誌——無需你另外啟用這些日誌。選用的防護方案可延伸覆蓋範圍至 S3 資料事件（S3 Protection）、EKS 稽核日誌（Kubernetes Protection）、EC2 執行個體惡意軟體掃描（Malware Protection）、RDS 登入活動（RDS Protection），以及 Lambda 執行遙測（Lambda Protection）。
SCS-C02 考試強調的「基線」面向是：GuardDuty 會隨時間側寫每個主體的正常行為，並標記偏差。UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B 這類發現並非只是說「有人登入」；它說的是「這個主體從未使用過的地理位置登入了」。停用再重新啟用 GuardDuty 會重置行為基線，這就是為什麼考試的正確答案永遠偏好抑制規則模式，而非先停用再重新啟用的做法。
抑制規則 vs 篩選器
GuardDuty 篩選器是對發現的已儲存檢視，不會改變哪些發現被產生。抑制規則則相反，它在符合條件的發現一到達時就自動封存，使其永遠不會流向 EventBridge 或 Security Hub。對已知良好的服務帳號、弱點掃描器 IP，以及有意的滲透測試視窗使用抑制規則。永遠不要用它們來靜音你根本不理解的發現。
使用 AWS Organizations 指定安全工具帳號為 GuardDuty 委派管理員。新成員帳號自動加入，所有發現聚合到一個控制台，你在單一位置撰寫抑制規則與 EventBridge 串接，而非在 N 個帳號中各自設定。同樣的模式也適用於 Security Hub、Macie、Inspector、IAM Access Analyzer 與 Detective。參考：https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html
Systems Manager 合規用於基線追蹤
GuardDuty 追蹤行為基線，而 AWS Systems Manager 追蹤 EC2 機群上的設定基線。兩個要點對安全監控與告警設計至關重要。
Patch Manager 發布修補程式合規資料：對每個受管理的執行個體，記錄哪些已核准的修補程式已安裝、缺少、失敗或遭拒絕。聚合的合規狀態可透過 Systems Manager Compliance API 查詢，呈現於 Compliance 儀表板，並在與 ec2-managedinstance-patch-compliance-status-check 受管理 Config 規則配對時作為 Config 規則評估發出。
State Manager 與 Association Compliance 追蹤你要求在每個執行個體上執行的 SSM 文件——防毒軟體安裝、CIS 基準強化、日誌代理安裝——是否確實成功執行。當文件在任何目標上失敗時，Association compliance 立即變為 NON_COMPLIANT，而 Config 規則評估透過 ASFF 將該狀態重新發出到 Security Hub。
關鍵的考試要點：Systems Manager Compliance 本身不傳呼任何人。你透過 EventBridge → SNS 串接 Config compliance-change 事件，與其他 Config 規則的處理方式相同。這就是為什麼本主題屬於安全監控與告警設計，而非修補主題。
你的應用程式發布到 CloudWatch 的任何自訂安全訊號都必須使用 cloudwatch:PutMetricData API。IAM 主體——無論是 EC2 執行個體角色、ECS 任務角色、Lambda 執行角色，或本地端 IAM 使用者——必須擁有該權限，且呼叫必須指定 Namespace 加上至少一個 Dimension 才可供查詢。缺少 PutMetricData 權限是「我的自訂指標沒有出現」疑難排解工單的第一大原因。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html
定義指標、閾值與告警數學運算
CloudWatch 告警由五個在考試中都會出現的參數定義：指標（或指標數學運算式）、統計資料（Average、Sum、Maximum、p99 等）、期間（以秒為單位的桶大小）、評估期間（連續桶數），以及閾值（數值或異常帶狀區間）。第六個參數 treatMissingData 決定當桶內沒有資料點時的處理方式——notBreaching、breaching、ignore 或 missing。
對於「沒有資料」表示「代理程式已死，我們失去視野」的安全訊號，你需要 treatMissingData: breaching。對於預期會有間隔的季節性訊號（一個只在上班時間發出的指標），你需要 notBreaching。選錯策略是告警頻繁切換狀態，或更糟——靜默失效的最常見原因。
指標數學運算讓你將多個指標合併成單一告警輸入。常見的安全運算式：m1/m2（登入失敗比率）、RATE(m1)（每秒速率）、IF(m1 > 100, 1, 0)（二元訊號）。數學告警的費用與純量告警相同，但可減少傳呼次數。
不要為關鍵安全告警設定不足的評估期間。1 分鐘期間加 5 個評估期間，最少等待 5 分鐘。根帳號使用告警應使用 1-of-1（period = 60s、evaluationPeriods = 1、datapointsToAlarm = 1）。對於吵雜的指標，使用 3-of-5 來吸收單桶尖峰，同時不忽視持續性問題。參考：https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
告警失效疑難排解 — 決策樹
Task 2.2 專門針對安全監控與告警失效的疑難排解。考試情境題總是描述一個「應該」告警卻保持靜默的 pipeline。按從來源到目的地的資料路徑順序逐一檢查，在每一跳找出最常見的斷點。
SNS 未收到 / 訂閱者未收到通知
確認訂閱狀態為 Confirmed，而非 PendingConfirmation。電子郵件與 HTTPS 訂閱者必須點擊確認連結，SNS 才會傳遞訊息。確認主題存取政策——來自另一個帳號的 Lambda 或 CloudWatch 告警需要明確的 sns:Publish Allow。確認 SNS 傳遞狀態日誌（你必須為每種通訊協定啟用並搭配 IAM 角色），查看 HTTP 4xx 回應是否表示接收端拒絕了酬載。
EventBridge 規則未觸發
使用規則的 MatchedEvents 與 Invocations CloudWatch 指標來區分「比對條件從未符合」與「已符合但目標失敗」。若 MatchedEvents 為零，比對條件有誤：透過 EventBridge 沙箱或 aws events test-event-pattern 重播來源服務的範例事件並進行比對。若 MatchedEvents 非零但 Invocations 為零，目標 IAM 角色或資源政策有誤；檢查 FailedInvocations 與規則的死信佇列（DLQ）。
輸入轉換器的錯誤是特別難以察覺的失效模式：規則觸發了，但目標收到格式錯誤的 JSON 並靜默拒絕。務必為輸入轉換器搭配目標 DLQ。
CloudWatch 告警頻繁切換狀態或卡在 INSUFFICIENT_DATA
頻繁切換的告警通常是閾值與期間不匹配。增加 evaluationPeriods 並使用 datapointsToAlarm（M-of-N）來吸收噪音。卡在 INSUFFICIENT_DATA 的告警表示設定期間內沒有資料點到達；確認底層指標是否有在發出、期間是否符合指標的原生解析度，以及 treatMissingData 是否應改為 breaching。
Lambda 目標未執行
確認 Lambda 的 CloudWatch Logs /aws/lambda/<fn> 日誌群組。若完全沒有日誌串流，函數從未被呼叫：確認 EventBridge 目標權限（Lambda 上的資源型政策）與來源的呼叫權限。若有日誌串流但含有錯誤，修復執行期問題，並為函數新增 DLQ（SQS 或 SNS），使未來的失敗可被察覺。確認執行角色擁有函數使用的每個 API 權限，包括對任何已加密環境變數或 Secrets 的 kms:Decrypt。
自訂應用程式指標未回報
執行個體角色、ECS 任務角色、Lambda 執行角色，或本地端 IAM 主體缺少 cloudwatch:PutMetricData。新增該權限，可選擇透過 cloudwatch:namespace 條件金鑰限制至單一命名空間。確認代理程式或 SDK 設定的是正確的區域——誤發布到 us-east-1 的指標永遠不會出現在 eu-west-1 儀表板上。確認指標名稱、命名空間與維度集與告警的設定完全一致；任何偏差 CloudWatch 都會靜默建立獨立的指標。
沒有 DLQ，失敗的傳遞在 EventBridge 的內部重試預算（24 小時、指數退避）耗盡後就會被丟棄。有了 DLQ——SQS 或 SNS——你可以獲得事件的永久記錄以及失敗原因，這是診斷間歇性目標失敗的唯一實際可行方法。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html
端對端參考架構
將所有元件組合在一起，AWS 上的生產等級安全監控與告警設計如下所示。CloudTrail 組織 trail 將管理事件寫入安全工具帳號中的中央 S3 儲存貯體與 CloudWatch log group。VPC Flow Logs 與 Route 53 Resolver 日誌落入同一組 log group。GuardDuty 在整個組織範圍啟用，以安全工具帳號為委派管理員，並啟用 S3、EKS 與 Malware Protection。
Security Hub 同樣在同一帳號委派管理員，所有成員帳號自動加入，並啟用 AWS Foundational Security Best Practices、CIS 與 PCI 標準。Automation rule 預先分類發現：dev 帳號抑制、prod 標記提升、已知弱點去重複。後自動化規則的發現串流流入 EventBridge。
從那裡，一小組 EventBridge 規則扇出：HIGH/CRITICAL 發現流向 Lambda，後者開立 JIRA 工單並透過 SNS 傳呼 PagerDuty；根使用者活動流向獨立的 SNS 主題，透過 AWS Chatbot 傳遞至 #sec-alerts Slack 頻道；Config NON_COMPLIANT 事件流向 Step Functions 自動修復工作流程，包含 30 秒人工覆蓋視窗；GuardDuty 類型為 Backdoor: 或 CryptoCurrency: 的發現直接流向 Step Functions 隔離流程，卸離執行個體的安全群組並建立磁碟區快照。
CloudWatch metric filter 在中央 log group 上捕獲 GuardDuty 未覆蓋的長尾訊號：未使用 MFA 的控制台登入、KMS 金鑰停用嘗試、授予 Principal: "*" 的 S3 儲存貯體政策變更。每個 filter 饋入含複合邏輯的 CloudWatch 告警，以抑制維護視窗噪音。來自應用程式團隊的自訂應用程式指標透過 Custom/AppSec 命名空間流動，並繼承相同的告警/SNS 配置。
在安全工具帳號中使用自訂 EventBridge 匯流排，讓所有成員帳號透過跨帳號 PutEvents 作為目標。應用程式團隊擁有從匯流排消費至自身目標的規則，而安全團隊擁有匯流排政策、標準目標（PagerDuty、Slack、JIRA），以及稽核軌跡。參考：https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-account.html
白話文解釋
類比一：捷運控制中心
把 AWS 帳號想成整個捷運系統。每個車站（EC2、Lambda、S3 儲存貯體）都有自己的感應器。CloudWatch 就像捷運的中央控制中心，把每個站點的數值資料（旅客流量、電力消耗、月台門開關次數）拉到一整面監控牆上；CloudWatch 告警就是「某站月台門在一分鐘內開關超過十次就響起的異常警報」。EventBridge 不看數字，它看「事件」——列車延誤廣播被觸發、月台進站感應器失聯、司機按下緊急鈕——一有事件就立刻路由到對應的調度員或自動修復程序。Security Hub 像總調度長的整合白板，把不同線路控制室（GuardDuty、Inspector、Macie、Config）回報的異常，用同一份標準格式（ASFF）整理在同一面牆上，讓你一眼比較各站嚴重程度。少了任何一塊，你都只是有「資料」而沒有「警覺」。
類比二：機場航管塔台
GuardDuty 像機場雷達，自動掃描所有進出空域的飛機（VPC Flow Logs、CloudTrail、DNS）並比對國際黑名單；它不需要你去裝感測器，啟用就有覆蓋。Systems Manager Compliance 像地勤的起飛前安全檢查表，每架飛機起飛前要核對 100 個項目（修補程式是否齊全、SSM 文件是否成功執行完畢），少一項就標記 NON_COMPLIANT。EventBridge 是塔台的緊急廣播系統：雷達抓到異常飛機，立即通知對應處置小組——Lambda 是只負責一件事的地勤（拒絕降落許可），Step Functions 是多步驟標準作業程序（先警告、不從則禁止進入空域、最後通報軍方攔截）。SNS 是廣播喇叭，把告警同時送給管制員、督導、外部協調單位。整個流程中的每一跳都有權限管控：地勤沒有塔台憑證就無法回應廣播，就像 Lambda 沒有 IAM 權限就無法執行 API 呼叫。
類比三：大樓消防警報系統
CloudWatch metric filter 像煙霧感應器，每偵測到一次觸發就替計數器加一。CloudWatch 告警是設定「五分鐘內觸發超過三次就啟動警鈴」的中央邏輯。複合告警是更聰明的規則：「警鈴響起」AND「不在消防演練排程內」AND「不在廚房烹飪期間的誤報白名單時段」才真的撥打消防局。SNS 是同時通知大樓管委會、保全公司、消防局的群發系統。Lambda 是裝在樓梯間的自動噴水裝置，收到告警就直接啟動，同時鎖上電梯、阻絕外部進入。Step Functions 是有指揮腳本的保全主任：先廣播疏散通知、三分鐘沒有人工確認再啟動噴水、五分鐘沒有解除才呼叫消防隊。疑難排解「告警失效」就是發現警鈴不響時，從煙霧感應器電池、訊號線、中央控制箱、電話線路、消防局接收端訂閱狀態逐一回頭排查——任何一環斷了，整套系統就沉默了。
考試常見陷阱與避免方法
SCS-C02 考試喜歡在安全監控與告警上設陷阱，因為涵蓋面很廣，單一錯誤設定就能摧毀整條 pipeline。請注意以下模式。
「自動」答案通常是錯的。若題目說「系統自動通知安全團隊」，請確認提議的解決方案實際上包含通知步驟。CloudWatch metric filter 不通知；它需要告警。Security Hub insight 不通知；它需要連接到 SNS 的 EventBridge 規則或 automation rule。
只有 CloudTrail 幾乎不夠。許多錯誤答案建議「啟用 CloudTrail 並每天審查日誌」。每日審查不是告警；那是鑑識。正確答案幾乎都是將 CloudTrail 與 CloudWatch Logs metric filter 或 EventBridge 規則配對使用。
單一帳號幾乎不夠。SCS-C02 以多帳號為優先。若答案在 AWS Organizations 的範疇下只在單一帳號啟用 GuardDuty、Security Hub 或 Config，請尋找委派管理員替代方案並優先選擇它。
FAQ
EventBridge 與 CloudWatch Events 在安全監控上有什麼不同？
EventBridge 是 CloudWatch Events 改版並擴充後的繼任者。預設匯流排由兩個服務名稱共用，舊規則繼續有效。EventBridge 新增了自訂匯流排、結構描述登錄檔、合作夥伴來源（Zendesk、Datadog、Auth0）、Pipe 管線與排程器。針對安全監控與告警設計，2026 年請一律說 EventBridge；考試兩個名稱交替使用，但現代功能（匯流排目標上的輸入轉換器、封存與重播、跨帳號事件匯流排）僅限 EventBridge。
面對同一個安全事件，何時應用 CloudWatch 告警，何時應用 EventBridge 規則？
當觸發條件是隨時間變化的數值閾值時使用 CloudWatch 告警——每 5 分鐘的登入失敗次數、超過基線的 KMS Decrypt API 計數、上升的 GuardDuty 發現數量。當觸發條件是結構很重要的單一事件時使用 EventBridge 規則——根使用者登入一次、特定類型的 GuardDuty 發現觸發、Config 規則轉為 NON_COMPLIANT。許多真實系統兩者都用：CloudWatch 告警提供量的訊號，EventBridge 規則向應變人員提供每個事件的細節。
Security Hub insight 與 Security Hub automation rule 有什麼差別？
Security Hub insight 是已儲存的查詢——對 ASFF 發現的 GROUP BY 檢視，你可以在控制台讀取或透過 API 拉取。Insight 不採取任何動作。Security Hub automation rule 有條件區塊與動作區塊；它在伺服器端變更發現（設定 Workflow.Status 為 NOTIFIED、變更 Severity.Label、新增備注、抑制），然後重新發布到 EventBridge。使用 insight 建立儀表板與報告；使用 automation rule 在大規模環境中執行分類政策。
為什麼我的 GuardDuty 發現沒有觸發我的 EventBridge 規則？
按順序確認四件事：（1）GuardDuty 偵測器與 EventBridge 規則位於同一區域（發現是區域性的）；（2）事件比對條件符合實際的發現 JSON——從 GuardDuty 控制台複製範例，而非猜測欄位名稱；（3）沒有 Security Hub automation rule 在重新發布前抑制該發現；（4）該發現是新的，而非現有發現的更新（GuardDuty 以不同的 detail-type 重新發出更新，但 service.archived = false——若你也在乎更新，請確認你的比對條件允許它們）。在規則上新增 CloudWatch Logs 目標進行除錯，這樣你才能看到確切的比對結果。
Lambda 函數需要哪些權限才能修復安全發現？
Lambda 執行角色需要修復動作呼叫的 AWS API（例如 ec2:RevokeSecurityGroupIngress、iam:UpdateAccessKey、s3:PutBucketPolicy），加上用於自身日誌記錄的 logs:CreateLogStream 與 logs:PutLogEvents，以及若讀取已加密環境變數或 Secrets Manager Secrets 時的 kms:Decrypt。套用最小權限原則：將每個修復 Lambda 的範圍限定在一種資源類型，以防遭入侵的函數進行提權。Lambda 函數 URL 僅使用 IAM 驗證，永遠不要使用公開存取，且安全自動化請優先使用 EventBridge 呼叫而非函數 URL。
如何立即對根帳號使用發出告警？
在預設匯流排上建立 EventBridge 規則，比對條件為 {"source":["aws.signin","aws.cloudtrail"], "detail":{"userIdentity":{"type":["Root"]}}} （控制台登入與 API 事件的確切欄位集有所不同；將兩者合併）。目標設為有電子郵件、AWS Chatbot 與 PagerDuty 訂閱者的 SNS 主題。規則在 CloudTrail 事件後幾秒內觸發。搭配中央 CloudTrail log group 上 { $.userIdentity.type = "Root" } 的 metric filter CloudWatch 告警作為雙重保險，並確保 trail 為多區域，讓告警無論根使用者觸及哪個區域都能觸發。
我可以不透過 CloudWatch 直接從 CloudTrail 將安全告警送到 SNS 嗎？
不行。CloudTrail 本身沒有用於告警的 SNS 發布步驟（其 SnsTopicName 欄位僅用於 trail 傳遞通知，而非日誌內容告警）。兩條支援的路徑是：（1）CloudTrail → CloudWatch Logs → metric filter → CloudWatch 告警 → SNS，以及（2）CloudTrail 管理事件 → EventBridge 預設匯流排 → 規則 → SNS 目標。路徑 2 更快（分鐘以內），是大多數安全監控與告警的推薦方式。路徑 1 在需要跨日誌行進行數值聚合時是必要的。
如何在不停用告警的情況下防止告警疲勞？
使用含維護視窗抑制器的複合告警、Security Hub automation rule 靜音已知良好的發現、含嚴重性過濾器的 EventBridge 規則（Severity.Label in ["HIGH","CRITICAL"]）、針對已驗證弱點掃描器的 GuardDuty 抑制規則，以及對吵雜指標的 datapointsToAlarm（M-of-N）。將告警量本身追蹤為指標：一個 CloudWatch 儀表板磁貼，顯示每日每類別的傳呼次數，可在應變人員開始忽略告警之前，讓安全運作中心發現疲勞趨勢並調整閾值。
傳送 Slack 與 Microsoft Teams 通知一定要用 AWS Chatbot 嗎？
AWS Chatbot 是 AWS 原生的方式，無需 Lambda 即可將 SNS 訊息以豐富格式傳遞到 Slack 與 Teams 頻道，並支援斜線命令操作。替代方案——呼叫 Slack Webhook 的 Lambda 訂閱者，或 PagerDuty 的 SNS 整合等第三方工具——雖然可行，但需要你維護程式碼與 Secret。針對 SCS-C02，當題目同時提到 Slack 或 Teams 以及 SNS 時，AWS Chatbot 是標準答案。
SCS-C02 關鍵要點
AWS 上的安全監控與告警設計是 CloudWatch（數值閾值）、EventBridge（事件結構路由）、Security Hub（ASFF 正規化與 automation rule）、GuardDuty（受管理行為基線）、Lambda 與 Step Functions（行動），以及 SNS 加上 AWS Chatbot（通知）的協作編排。掌握這些服務之間的資料流，你就掌握了 Domain 2 Task 2.1。
疑難排解遵循相同的資料流，只是方向相反：SNS 訂閱 → SNS 主題政策 → CloudWatch 告警狀態 → metric filter 比對條件 → 日誌 ingestion 權限，或 SNS → EventBridge 目標權限 → EventBridge 呼叫指標 → 事件比對條件 → 來源服務發出。了解順序比死背任何單一服務更有價值。
多帳號安全監控與告警是 SCS-C02 的差異化要點。永遠先考慮 AWS Organizations、委派管理員、組織範圍的 CloudTrail，以及跨帳號 EventBridge 匯流排。單帳號答案在這個考試上幾乎永遠是錯的。有了這些模式，加上本主題的疑難排解決策樹，你應能應對考試能構建的所有 Domain 2 Task 2.1 與 2.2 情境題。