集中化日誌、可觀測性與加密架構

集中式安全日誌是一套架構學科，將 AWS Organization 中每個帳號、每個區域的所有安全相關事件——API 呼叫、網路流量、DNS 查詢、Web ACL 決策、威脅發現、合規評估——匯聚到單一個可稽核、可查詢、受保留期限管控的儲存空間，讓規模精簡的 SOC 團隊能夠在龐大的多帳號環境中進行調查、偵測，並舉證合規。在 SAP-C02 考試中，集中式安全日誌橫跨 Domain 3 的 Task 3.1（提升維運卓越性）與 Task 3.2（強化安全性），只要情境中出現「今天有 15 個帳號各自記錄日誌」、「稽核人員要求 10 年不可竄改保留期」，或「SOC 分析師需要透過 Splunk 單一畫面管理」，正確答案永遠是 CloudTrail Lake、Amazon Security Lake、跨帳號 S3 傳送、subscription filter，以及委派管理員聚合的組合，絕不會是某項單一服務的捷徑。

本深度指南涵蓋 SAP-C02 考試中你會遇到的每個元件：寫入 Log Archive 帳號的組織層級 CloudTrail 追蹤、CloudTrail Lake 的 SQL 引擎與 10 年保留期、Amazon Security Lake 的 OCSF 正規化與訂閱者模型、VPC Flow Logs 集中到 S3 供 Athena 查詢 vs 透過 Firehose 串流供即時 SIEM 使用、CloudWatch Logs 跨帳號目的地與 Kinesis Firehose、GuardDuty / Security Hub / Inspector 聚合至委派管理員、Route 53 Resolver 查詢日誌、WAF 完整流量日誌、日誌保留期限與 Object Lock 防竄改機制、第三方 SIEM 整合，以及 AWS Audit Manager 打包證據。集中式安全日誌也帶出一個經典 Pro 場景——針對現有 15 帳號組織的 30 天改造——我們將逐步拆解說明。

什麼是集中式安全日誌？

AWS 的集中式安全日誌是一種聚合模式：每個帳號的安全相關遙測資料都被傳送至專屬的日誌與安全帳號，而非只保留在產生它的帳號中。在 landing zone 中，集中式安全日誌存在於兩個職責嚴格劃分的帳號：Log Archive 帳號（原始日誌保留、不可變儲存、合規證據）與 Security/Audit 帳號（偵測工具委派管理員、SIEM pipeline、分析師工具）。工作負載帳號產生日誌，但不擁有它們——這是一項根本性的職責分離，防止遭入侵的工作負載管理員竄改證據軌跡。

集中式安全日誌對 SAP-C02 為何至關重要

SAP-C02 的 Task 3.1 和 Task 3.2 情境題會設定 15、50 或 200 個帳號的規模，並詢問哪種集中式安全日誌架構能在特定時間視窗（常見為 30、60 或 90 天）內解決特定的改造問題。來自 SAA-C03 的單一帳號日誌知識已不夠用。考試會懲罰只在單一帳號啟用日誌、將日誌路由到工作負載帳號自己的 S3 bucket，或依賴逐帳號手動建立 CloudTrail 追蹤的答案。正確模式始終是：組織範圍傳送至獨立帳號中 Log Archive bucket，以及偵測工具委派管理員從獨立 Security 帳號運作。

六條你必須集中化的日誌流

完整的集中式安全日誌架構需聚合六條獨立的日誌流：管理平面事件（CloudTrail 管理事件、控制平面 API 呼叫）、資料平面事件（S3 物件與 Lambda 呼叫的 CloudTrail 資料事件）、網路流量（VPC、子網路或 ENI 粒度的 VPC Flow Logs）、DNS 查詢（Route 53 Resolver 查詢日誌）、Web 層流量（WAF 完整日誌與 ALB 存取日誌），以及安全發現（GuardDuty、Security Hub、Inspector、Macie、Access Analyzer、Config、Firewall Manager）。每條日誌流有各自的傳送機制、保留期考量與查詢工作流程——集中式安全日誌是將它們統合在一起的總體模式。

白話文解釋集中式安全日誌

集中式安全日誌乍聽像另一堆縮寫術語，但三個日常類比能讓其結構直覺易懂。請全部讀完——每個類比都能揭示集中式安全日誌的不同特性。

類比一：台鐵票務與調度中心（鐵路系統類比）

把整個架構想像成台灣鐵路的運作系統，有 15 個分散各地的車站（你的 AWS 成員帳號）和一個中央調度中心（你的 Log Archive 帳號），外加一個列車安全監控局（你的 Security 帳號）。集中式安全日誌就是設計票務與行車紀錄的流向，讓每一張票、每一筆進出站記錄——不論在哪個車站發生——都能匯整、索引並保存在中央調度中心，可疑的異常狀況則即時回報安全監控局。

在這套系統中，全線聯網票務帳本就是 CloudTrail 組織追蹤——每一次上車（API 呼叫）都寫入主帳本，不論哪個車站受理，且帳本以密碼學簽章確保事後無法竄改。統一站名對照系統是 Amazon Security Lake——它將所有進站紀錄（原始 CloudTrail JSON、原始 VPC Flow Log 文字、原始 DNS 查詢）以共同格式（OCSF）重新標記，調查人員搜尋「所有旅客 X 的記錄」時不必管資料是從哪個車站、以何種格式產生。防竄改的長期存檔室是 Log Archive bucket 上的 S3 Object Lock Compliance 模式設定——一旦寫入，十年內任何人都無法刪除或修改。全線即時 CCTV 錄影儲存是每個成員 VPC 集中到 Log Archive 的 VPC Flow Logs。安全監控局的鑑識分析師使用 CloudTrail Lake（對帳本進行 SQL 查詢）和 Athena（對流量日誌存檔查詢）。可疑行為警報網路是 GuardDuty 發現流向委派管理員。最後，定期取走合規證據包的外部稽核員是 Audit Manager，將存證映射到 SOC 2、PCI 等法遵框架。所有資料都匯入中央；沒有任何車站能說「我們找不到那張票了。」

類比二：醫院電子病歷系統（醫療類比）

想像一個有 15 家診所（成員帳號）、一個中央病歷室（Log Archive 帳號）以及一個感染管制小組（Security 帳號）的醫療體系。集中式安全日誌就是讓每家診所的每次就診紀錄，都成為一份統一、防竄改、對適當醫療人員開放的電子病歷，而不會因本地遺失而消失。

追蹤每張處方、每項處置與每次轉介的電子病歷就是 CloudTrail Lake——一個單一事件資料存儲，任何醫療人員（具備適當權限）都能執行 SQL 查詢，如「查詢過去 12 個月跨所有診所患者 X 的所有胰島素處方」。因為 CloudTrail Lake 可查詢長達 10 年且具不可變保留期，它滿足了多年記錄保存的法規要求。把各診所本地簡語統一為共通詞彙的標準化病歷格式是 Amazon Security Lake 中的 OCSF——一家診所可能記錄「BP 120/80」，另一家記錄「血壓正常」，但 OCSF 將兩者正規化為相同欄位名稱，跨診所分析因此可行。即時監測生命徵象的串流是 VPC Flow Logs 與 CloudWatch Logs subscription filter，透過 Firehose 以分鐘以內的延遲傳送。跨診所偵測群聚感染的感控篩查是 GuardDuty 加上 Security Hub，發現透過 Security Hub 跨區域聚合流入中央感控局的儀表板。供法規查驗的密封實體備份是 Log Archive bucket 上的 S3 Object Lock 保險庫——稽核人員等級的證據，無法被竄改。提交給衛生主管機關的稽查套件是 Audit Manager 的證據收集。同一事件會流經多條 pipeline（即時送至 SOC SIEM；存檔至不可變 S3；在 CloudTrail Lake 中以 SQL 可查；正規化為 OCSF 供 Security Lake 訂閱者使用），因為不同的消費者有不同的延遲與保留期需求。集中式安全日誌是讓 15 家診所運作起來如同一家醫院的資訊主幹。

類比三：高速公路收費與監控網路（交通類比）

想像一個有 15 個地區收費所（成員帳號）和一個中央交通控制中心（Security 帳號）的國道系統，而控制中心依賴一個中央錄影存檔室（Log Archive 帳號）。集中式安全日誌就是讓每個收費所的每台攝影機、每筆通行記錄、每個速度偵測器的資料，都能匯入一個存檔室和一個即時控制中心。

通行費交易帳本是 CloudTrail 組織追蹤——每個收費站掃描的每個車牌都被記錄到中央帳本，並附上地區收費所的識別碼。以不可刪除磁碟長期存放的高速公路原始監控錄影是啟用 Object Lock 的 S3 Log Archive bucket——GB 級的 VPC Flow Logs、WAF 日誌與 Firehose 輸出以原始格式落地。控制中心顯示即時路況、事故與警報的統一儀表板是 CloudWatch Unified Cross-Account Observability 加上 Security Hub 跨區域聚合——一個操作員不需要在 15 個帳號間切換螢幕就能看到全局。讓首席調查員能寫 SQL 的結構化事故資料庫——如「給我上週二凌晨 2 點到 4 點，第 7 區的所有車道關閉、雷達警報和收費異常」——是 CloudTrail Lake 加上 Athena 對分區 flow log 的查詢。即時雷達與測速攝影機資料流透過 Firehose subscription filter 串流至控制中心 SIEM（Splunk 或 Datadog 或區域 OpenSearch 網域）。送交主管機關的檢查報告是 Audit Manager 的證據套件，將通行費資料映射至法規控制項。新的地區收費所（新的 AWS 帳號）上線時，透過委派管理員自動啟用設定，自動接入所有系統——無需手動佈線。集中式安全日誌是將 15 個獨立收費所轉化為一個整合管理局的神經系統。

集中式安全日誌參考架構

每道 SAP-C02 集中式安全日誌題目都隱含 Security Reference Architecture (SRA) 的配置。熟記這份標準藍圖——考試答案直接對應其中各個區塊。

三種帳號角色

不論組織規模大小，集中式安全日誌都涉及三種帳號角色：

• Log Archive 帳號 — 持有 S3 bucket，接收來自每個成員帳號的 CloudTrail、Config、VPC Flow Logs、ALB 存取日誌、WAF 日誌、Route 53 Resolver 查詢日誌。Bucket policy 授予已知日誌產生服務與 principal 的跨帳號寫入權限。S3 Object Lock Compliance 模式提供 WORM（寫一次讀多次）保留期。
• Security/Audit 帳號 — 託管 GuardDuty、Security Hub、Config、Inspector v2、Macie、IAM Access Analyzer、Detective 與 Audit Manager 的委派管理員。也託管 CloudTrail Lake 事件資料存儲（組織層級）、CloudWatch Cross-Account Observability 監控帳號，以及中央 OpenSearch 網域或 Firehose 至 SIEM 的 pipeline。
• 成員工作負載帳號 — 產生日誌但不集中保留。本地 CloudWatch Logs 群組可能存在，用於應用程式日誌和短期除錯；安全相關日誌必須流出。

從產生者到存檔的日誌流

每條日誌流都遵循相同模式：在成員帳號產生 → 透過服務專屬機制傳送 → 落地至 Log Archive S3 或 Security 帳號 CloudWatch → 從 Security 帳號索引與查詢。傳送機制因日誌流而異（CloudTrail 和 Flow Logs 直接寫入 S3；CloudWatch Logs 內容透過 subscription filter 加 Firehose；發現透過 event bus），但目的地始終是跨帳號的。

為何需要兩個帳號而非一個

Log Archive 帳號與 Security 帳號刻意分開。Log Archive 帳號持有原始證據——對產生者唯寫、對稽核人員唯讀、受 Object Lock 保護。在 Compliance 模式下，沒有任何人、包括 SOC 分析師，能從中刪除。Security 帳號持有主動工具與分析師存取——GuardDuty 主控台、Security Hub 儀表板、CloudTrail Lake 查詢主控台、Firehose 至 SIEM 的傳送串流。角色分離意味著即使 Security 帳號分析師的憑證遭入侵，仍無法摧毀證據存檔；而 Log Archive 帳號憑證遭入侵，仍無法操作偵測工具。這種分離是重要的考試訊號——任何將兩個角色放在同一帳號的答案通常是錯誤的。

CloudTrail 組織追蹤 — 集中式安全日誌的基礎

CloudTrail 是任何集中式安全日誌架構中第一個也是最根本的元件。沒有組織範圍的 CloudTrail 追蹤，其他所有集中式安全日誌元件都無法正確運作。

組織追蹤的運作機制

組織追蹤是在管理帳號（或從 CloudTrail 委派管理員帳號）建立的單一 CloudTrail 追蹤，它會自動套用到組織中每個當前及未來的成員帳號、在每個區域。追蹤傳送至 Log Archive 帳號中的一個 S3 bucket——跨帳號傳送由 Log Archive bucket 的資源政策授權。成員帳號無法從自己的主控台停用或修改組織追蹤；只有管理帳號或委派管理員才能進行操作。

管理事件 vs 資料事件

CloudTrail 記錄兩類事件，各有不同的成本與涵蓋範圍。管理事件（預設開啟，第一份免費）記錄控制平面 API 呼叫——RunInstances、CreateRole、PutBucketPolicy。資料事件（預設關閉，依事件計費）記錄資料平面活動——每次 S3 GetObject、每次 Lambda Invoke、每次 DynamoDB 選定資料表的 GetItem。集中式安全日誌幾乎都會在持有敏感資料的 S3 bucket、所有 Lambda 函數，以及持有受管制資料的 DynamoDB 資料表上啟用資料事件。考試會測試考生是否記得資料事件必須明確啟用，且會產生額外的每事件費用。

CloudTrail Insights — 異常 API 偵測

CloudTrail Insights（付費附加功能）識別管理事件中的異常模式——DeleteObject 的突然激增、AssumeRole 呼叫的異常集中，或使用了意外的區域。Insights 發現整合 EventBridge 以觸發自動回應。對於集中式安全日誌，在組織追蹤上啟用 Insights，分析的是所有帳號的聚合模式，而非可能忽略跨帳號橫向移動的個別帳號模式。

S3 傳送與 Bucket 強化

接收 CloudTrail 的 Log Archive S3 bucket 需要一個 bucket policy，授予 CloudTrail 服務主體 cloudtrail.amazonaws.com 的 s3:PutObject 權限，並以 aws:SourceArn 鎖定追蹤 ARN——這是 CloudTrail 指南中記載的 confused-deputy 防護。集中式安全日誌的 bucket 強化要點：封鎖所有公開存取、以組織共享的 KMS CMK 啟用預設加密、啟用版本控制、在 root 帳號上啟用 MFA 刪除、依法規要求（通常 7 或 10 年）在 Compliance 模式下套用 S3 Object Lock 保留期。

完整性驗證

CloudTrail 日誌檔完整性驗證每小時產生以 SHA-256 和 RSA 簽署的摘要檔案，允許以密碼學方式驗證日誌檔在傳送後未被竄改。在每個集中式安全日誌追蹤上啟用完整性驗證——稽核人員期望看到它，而法庭也將簽署的日誌檔視為可採納的證據。

CloudTrail Lake — 長期調查的 SQL 查詢引擎

CloudTrail Lake 是更新的 SQL 可查詢事件資料存儲，在許多集中式安全日誌使用案例中，它與傳統 S3 傳送並行運作，或取而代之。

CloudTrail Lake 的功能

CloudTrail Lake 將 CloudTrail 事件（管理、資料、Insights）以及非 AWS 和自訂事件，導入一個採用無綱要儲存和 Apache Presto 風格 SQL 查詢的事件資料存儲。保留期可設定長達 10 年。查詢可橫跨數年的事件執行，無需佈建 OpenSearch 或執行 Glue 任務——CloudTrail Lake 在內部處理索引與分區。

組織事件資料存儲

從管理帳號或 CloudTrail 委派管理員建立組織層級的事件資料存儲。該存儲自動收集啟用 CloudTrail 的每個區域中，每個成員帳號的事件。來自 Security 帳號（具備適當 IAM 權限）的查詢，可掃描整個 Organization 的事件歷史。

集中式安全日誌的 SQL 查詢模式

在 SAP-C02 情境中常見的 CloudTrail Lake 查詢：「查詢過去 30 天所有帳號中，從特定來源 IP 發出的每一次 AssumeRole」、「列出過去一年在任何標記為 Compliance=HIPAA 的 bucket 上的每一次 DeleteObject」、「顯示組織中使用 root 憑證的每一次 ConsoleLogin」、「識別所有 CreateAccessKey 事件，其中的 principal 過去未曾在該帳號建立金鑰」。這些查詢在沒有分區調校的原始 S3+Athena 上會非常耗時，但 CloudTrail Lake 能在數秒內返回數年資料的答案。

CloudTrail Lake vs S3 + Athena

兩種方法相輔相成。CloudTrail Lake：受管查詢引擎、10 年保留期、無需基礎設施的 SQL、一鍵簡易設定，依攝入 GB 數與掃描 GB 數計費。S3 + Athena：需要分區設計、Glue Data Catalog、Athena workgroup，但原始物件的長期儲存成本較低，且非 CloudTrail 消費者也可存取原始格式。多數組織同時執行兩者——S3 存檔用於原始合規證據，CloudTrail Lake 用於主動調查。

CloudTrail Lake 不可變性

CloudTrail Lake 中的事件在設定的保留期內是不可變的。與 CloudWatch Logs（允許寫入後刪除）不同，CloudTrail Lake 在保留期到期前無法清除。這是讓 CloudTrail Lake 適合作為法規合規查詢層的特定功能。

Amazon Security Lake — OCSF 正規化的集中式安全日誌

Amazon Security Lake 是 AWS 專為聚合、正規化並服務來自 AWS 和非 AWS 來源的安全資料而建置的服務，將資料存入客戶自有的 S3 data lake。

Security Lake 的功能

Security Lake 佈建一個 S3 bucket（慣例上位於客戶的 Log Archive 帳號中）、建立 Glue Data Catalog 資料表，並從支援的 AWS 來源攝入安全相關資料——CloudTrail 管理與資料事件、VPC Flow Logs、Route 53 Resolver 查詢日誌、Security Hub 發現、AWS WAF 日誌——以及透過 OCSF 綱要的自訂來源。所有攝入的資料都被正規化為 Open Cybersecurity Schema Framework (OCSF) JSON 格式，並依來源、帳號、區域和日期分區，以供有效率地查詢。

OCSF 正規化

OCSF 是一個開放標準（由 AWS、Splunk、IBM 等共同主導），用於統一跨廠商的安全事件資料。沒有 OCSF，SOC 分析師查詢「顯示所有來自網路、應用程式、雲端控制平面的身份驗證失敗」時，需要跨三種不同綱要撰寫三種不同的查詢。OCSF 讓每一次身份驗證失敗都具有相同的欄位名稱（actor.user.name、src_endpoint.ip、activity_id、disposition），無論它來自 CloudTrail、VPC Flow Logs 還是第三方 EDR 工具。

委派管理員與多帳號啟用

Security Lake 遵循與其他所有組織範圍 AWS 安全服務相同的委派管理員模式。Security 帳號被指定為 Security Lake 委派管理員。從那裡，在每個成員帳號、每個所需區域中啟用 Security Lake，並對新帳號設定自動啟用。所有成員帳號的資料流向中央 Security Lake bucket。

訂閱者模型 — 查詢與資料存取

Security Lake 支援兩種訂閱者類型：查詢訂閱者（透過 Lake Formation 授予資料分析師角色，可在帳號內或跨帳號使用 Athena）和資料訂閱者（第三方 SIEM 或 SOAR 透過 SQS 通知消費 S3 事件，在新的 OCSF 物件落地時拉取）。Splunk Cloud、Datadog、IBM QRadar、Palo Alto Cortex XSOAR 與 SentinelOne 都原生支援 Security Lake 資料訂閱——無需自訂資料 pipeline。

自訂來源

Security Lake 接受自訂來源（CrowdStrike Falcon、Okta 日誌、本地防火牆日誌），只要它們被轉換為 OCSF JSON 並寫入 lake 佈建的自訂來源前綴。OCSF 綱要有涵蓋身份驗證、網路活動、檔案活動、程序活動、系統活動、發現與探索等類別的分類——自訂來源選擇相關類別並進行欄位映射。

Security Lake vs 自建 Data Lake

在 Security Lake 出現之前，等效的方案需要 CloudTrail → S3 → Glue crawler → Athena partition projection → VPC Flow Logs 自訂 ETL → Resolver 查詢日誌自訂 ETL → 若需要正規化則需手動 OCSF 轉換。Security Lake 將這一切壓縮為一個在委派管理員帳號中啟用服務的操作。費用按每月每 GB 攝入量計算。對於 SAP-C02 情境中詢問「在 30 天內完成具備 OCSF 正規化與 Splunk/Datadog 整合的中央安全 data lake」，Security Lake 是標準答案——自建方案無法在該時程內完成。

VPC Flow Logs 集中化模式

VPC Flow Logs 擷取每個在 VPC、子網路或 ENI 上傳輸之封包的 IP 層流量中繼資料。集中化它們是集中式安全日誌中資料量最大的挑戰之一。

在何處啟用 Flow Logs

Flow logs 可在三個粒度啟用：VPC 層級（涵蓋 VPC 中所有 ENI，最容易進行組織範圍管理）、子網路層級（針對特定層級的聚焦監控）、ENI 層級（針對性的問題排查）。對於集中式安全日誌的基準涵蓋，在每個啟用區域每個帳號的每個 VPC 上啟用 VPC 層級的 flow logs。透過 AWS Config 搭配受管規則（vpc-flow-logs-enabled）加上 SSM 自動修復，或透過管理帳號的 CloudFormation StackSets，自動化啟用作業。

目的地選擇 — S3 vs CloudWatch Logs vs Firehose

Flow logs 支援三個目的地，各有不同的取捨：

• S3（集中式安全日誌存檔的推薦選項） — 直接傳送至 Log Archive bucket，依年/月/日分區。長期儲存成本低，Athena 可使用 partition projection 查詢，與 Security Lake 整合。
• CloudWatch Logs — 在產生帳號中的 log group，再透過 subscription filter 透過 Firehose 進行跨帳號傳送。每 GB 成本高於 S3，但支援即時的 CloudWatch Logs Insights 查詢和基於警報的觸發。
• Amazon Data Firehose — 直接傳送至 Firehose，透過 Lambda 轉換，傳送至 S3 / OpenSearch / Splunk / 第三方 HTTP 端點。最適合即時 SIEM 攝入的模式。

自訂 Flow Log 格式

預設 flow log 格式包含 14 個欄位（srcaddr、dstaddr、srcport、dstport、protocol、packets、bytes、windowstart、windowend、action、logstatus、version、account-id、interface-id）。自訂格式新增 20 個以上的欄位（vpc-id、subnet-id、instance-id、tcp-flags、type、pkt-srcaddr、pkt-dstaddr、region、az-id、sublocation-type、sublocation-id、pkt-src-aws-service、pkt-dst-aws-service、flow-direction、traffic-path）。對於集中式安全日誌，務必使用自訂格式——預設格式缺少鑑識分析的關鍵欄位（用於連線建立偵測的 TCP flags、NAT 改寫流量的封包層來源/目的地）。

Athena 查詢成本的分區策略

Athena 依掃描 GB 數計費。100 個 VPC 一年的 VPC Flow Logs 是 TB 級別。沒有分區，每次查詢都掃描全部資料。設定 Hive 風格分區（/year=2026/month=04/day=20/hour=14/）並在 Glue 資料表上設定 Athena partition projection，查詢只觸及相關分區。適當的分區可將長時間範圍查詢的 Athena 成本降低 50 至 100 倍。

集中式 Flow Log 架構

標準模式：每個成員 VPC 的 VPC Flow Logs → 直接傳送至 Log Archive S3 bucket（依帳號和區域設前綴）→ Glue crawler 建立分區資料表 → Security 帳號中的 Athena workgroup 查詢資料表，結果位置在 Security 帳號 bucket 中。對於即時需求，每個成員帳號中的 Firehose 串流訂閱 VPC Flow Log 的 CloudWatch log group，並傳送至中央 Firehose 至 Splunk 端點。多數成熟組織同時執行兩條 pipeline——S3 存檔用於鑑識查詢，Firehose 用於即時 SOC 警報。

成本最佳化

VPC 層級的 VPC Flow Logs 在繁忙的正式環境 VPC 上每小時產生 GB 量級資料。成本最佳化方式：對低重要性 sandbox VPC 以 10% 取樣、在 Log Archive bucket 上使用 S3 Intelligent-Tiering 並在 180 天後轉移至 Glacier Deep Archive、若法規範圍不要求則透過 SCP 豁免在 Sandbox OU 中停用 flow logs。

CloudWatch Logs 跨帳號目的地與 Subscription Filter

CloudWatch Logs 是所有作業系統日誌（CloudWatch agent）、應用程式日誌、Lambda 日誌、傳送至 CloudWatch 的 VPC Flow Logs 及許多其他日誌來源的目的地。CloudWatch Logs 的集中式安全日誌使用兩個核心功能：跨帳號目的地與 subscription filter。

Subscription Filter — 即時轉送

CloudWatch log group 上的 subscription filter 以近即時方式將符合條件的日誌事件傳送至以下其中一個目的地：Amazon Data Firehose 傳送串流、Kinesis Data Stream、Lambda 函數，或 CloudWatch Logs 目的地（跨帳號接收者）。篩選模式讓你只轉送你關注的事件——例如，{ ($.eventName = "ConsoleLogin") && ($.responseElements.ConsoleLogin = "Failure") } 只轉送失敗的主控台登入。

跨帳號目的地

Security 帳號中的 CloudWatch Logs 目的地是一個具名端點，包裝一個 Kinesis Data Stream 或 Firehose 傳送串流。成員帳號建立 subscription filter，指向目的地的 ARN。目的地的存取政策授予特定成員帳號 ID 的 logs:PutSubscriptionFilter 權限。這是即時跨帳號日誌轉送的標準集中式安全日誌模式——Security 帳號中一個目的地，所有成員帳號中 N 個 subscription filter。

Subscription Filter → Firehose → S3 模式

完整的即時集中式安全日誌 pipeline：成員帳號 CloudWatch log group → subscription filter（比對安全相關事件的模式）→ Security 帳號中的 CloudWatch Logs 目的地 → Kinesis Firehose → 透過 Lambda 轉換以 OCSF 正規化格式儲存至 Log Archive S3 bucket → Security Lake 攝入 → SIEM 訂閱者可查詢。這個鏈路將各帳號的本地日誌轉化為集中、正規化、可查詢、SIEM 就緒的串流。

CloudWatch Unified Cross-Account Observability

CloudWatch Cross-Account Observability（2022 年推出）是更新的功能，讓監控帳號在統一儀表板中查看來自連結來源帳號的日誌、指標與追蹤。設定方式：在 Security 帳號中指定監控帳號，向每個來源帳號發送邀請，各帳號接受後，來源帳號的所有指標 / 日誌 / X-Ray 追蹤都可從監控帳號的 CloudWatch 主控台查詢。這是一個獨立（互補）的模式，不同於 subscription filter——Cross-Account Observability 用於互動式儀表板，subscription filter 用於自動化 pipeline。

何時使用 CloudWatch vs 直接 S3

對於純粹的存檔（VPC Flow Logs、CloudTrail、ALB 存取日誌），繞過 CloudWatch 直接傳送至 Log Archive S3 bucket——每 GB 更便宜且更簡單。對於即時警報或 SIEM 整合，使用 CloudWatch Logs 作為中間儲存並搭配 subscription filter。對於互動式維運問題排查，額外使用 CloudWatch Cross-Account Observability。

GuardDuty、Security Hub、Inspector — 發現聚合至委派管理員

安全發現是獨立於原始事件日誌之外的集中式安全日誌串流。發現已經過豐富處理（威脅偵測、CVE 分析、合規評估），而集中化模式是發現聚合而非原始日誌轉送。

GuardDuty 委派管理員與發現流程

如 cross-account-security-controls 主題中所述，Security 帳號中的 GuardDuty 委派管理員為所有成員帳號和區域的威脅發現提供單一管理視角。發現每 5 分鐘匯出至 Log Archive S3 bucket（頻率可設定），並自動流向 Security Hub 進行跨區域聚合。S3 中匯出的發現是原始 GuardDuty JSON——可用於長期存檔和自訂分析。

Security Hub 跨區域聚合

Security 帳號中的 Security Hub 搭配跨區域聚合（聚合區域一次性選定，通常為 us-east-1），接收來自每個成員帳號每個其他區域的發現。發現正規化為 AWS Security Finding Format (ASFF)。Security Hub Automation Rule 可依屬性自動豐富、自動抑制或自動升級發現（抑制 Environment=Sandbox 的發現，將 Environment=Production 中 Severity=CRITICAL 的發現透過 EventBridge 升級至 PagerDuty）。

Inspector v2 弱點發現

Security 帳號中的 Inspector v2 委派管理員，在每個成員帳號的 EC2 執行個體、ECR 容器映像和 Lambda 函數上持續進行弱點掃描。發現包含 CVE ID、CVSS 評分和修復版本資訊。所有發現流向 Security Hub；也可匯出一份複本至 S3，用於長期弱點趨勢分析。

與集中式安全日誌的整合

啟用 Security Lake 後，Security Hub 發現會自動匯出至 Amazon Security Lake。這是最乾淨的路徑：GuardDuty 偵測 → Security Hub 聚合 → Security Lake 正規化為 OCSF → SIEM 訂閱者消費。繞過 Security Lake，直接透過 EventBridge 將 Security Hub 發現傳送至第三方 SIEM 也是支援的，但需要在 SIEM 端進行綱要映射。

EventBridge 即時發現回應

每次 Security Hub 發現更新都發布至預設 EventBridge event bus。bus 上的規則可觸發 Lambda 進行自動修復、SNS 進行呼叫通知、Systems Manager runbook 進行修補，或路由至 SOC 工具帳號的自訂 event bus。集中式安全日誌的回應速度以確認所需分鐘數衡量；EventBridge 是讓關鍵發現低於該閾值的方式。

Route 53 Resolver 查詢日誌

DNS 查詢日誌是一條關鍵但常被忽略的集中式安全日誌串流。它擷取 VPC 工作負載的每一次 DNS 解析請求——對於偵測惡意軟體 C2 域名、對未授權端點的資料外滲，以及設定漂移，都是極為重要的資訊。

啟用 Resolver 查詢日誌

Route 53 Resolver 查詢日誌是以每個 VPC 為單位啟用的，設定中指定目的地（CloudWatch Logs、S3 或 Firehose），查詢日誌設定可透過 AWS RAM 跨帳號共享。推薦的集中化模式：在 Security 或共享 Networking 帳號中建立查詢日誌設定，透過 RAM 與所有成員帳號共享，在 VPC 建立時透過 CloudFormation / CDK / Terraform 將設定關聯至每個 VPC。

記錄的內容

關聯 VPC 中任何資源發出的每一次 DNS 查詢：查詢名稱、類型、回應代碼、答案記錄，以及來源 VPC / ENI。對私有託管區域的查詢、轉發至本地端解析器的查詢，以及對公開權威名稱伺服器的查詢都會被擷取。

安全使用案例

• 惡意軟體 C2 偵測 — 對已知惡意域名的查詢被查詢日誌擷取，GuardDuty 從此串流產生 Backdoor:EC2/C&CActivity.B!DNS 發現。
• 資料外滲偵測 — 對未授權外部 DNS 的查詢，尤其是大量的 TXT 查詢，可能是 DNS 隧道的指標。
• 合規證據 — 證明內部服務只解析了已批准的域名。

Athena 查詢模式

傳送至 S3 的查詢日誌是每條查詢一筆記錄的 JSON。Athena 對分區資料表的查詢可以回答「哪些執行個體在上週二解析了 malicious.example.com？」或「哪個 VPC 在凌晨 3 點有最多的外部 DNS 查詢？」搭配 VPC Flow Logs 可將 DNS 解析與後續的 IP 連線相關聯——這是 DFIR 工作流程的核心。

WAF 日誌 → Firehose → 集中式安全日誌

AWS WAF 完整流量日誌記錄 Web ACL 評估的每個請求——包含被封鎖和允許的——以及符合的規則、來源 IP、國家、user agent、標頭與 body 片段。

啟用 WAF 日誌

每個 Web ACL 可記錄至 Amazon Data Firehose、CloudWatch Logs 或 S3。對於集中式安全日誌，推薦 Firehose 作為目的地，因為它支援轉換（捨棄已編輯的欄位、以地理 IP 豐富資料）、緩衝，並傳送至 Log Archive 帳號的 S3（可選搭配 OpenSearch 鏡像）。

Firewall Manager 用於多帳號 WAF 日誌

從 Security 帳號使用 AWS Firewall Manager 政策，可以將相同的 Web ACL 搭配日誌設定部署至每個成員帳號的 ALB / CloudFront / API Gateway。政策變更自動傳播。這是跨帳號 WAF 日誌的模式——一個政策，N 個帳號涵蓋。

與 CloudTrail 和 Flow Logs 的關聯

一個經典的攻擊重建案例：WAF 日誌顯示來自 IP X 的 SQL 注入嘗試被規則 Y 封鎖。在 VPC Flow Logs 中關聯同一 IP，查看攻擊者是否掃描了其他連接埠。在 CloudTrail 中關聯，查看該 IP 是否有任何成功的 AssumeRole 呼叫。這種三路關聯正是集中式安全日誌必須將所有三條日誌流帶入同一查詢層（Athena 或 Security Lake）的原因。

日誌保留期、生命週期與防竄改儲存

保留期與不可變性對集中式安全日誌與收集本身同等重要。稽核人員詢問兩年前的日誌時，不會在乎這些日誌是否曾被收集，若它們在六個月前就被刪除了。

S3 Object Lock — Compliance 模式 vs Governance 模式

S3 Object Lock 在定義的保留期內將物件置於 WORM 狀態。兩種模式：

• Governance 模式 — 具備 s3:BypassGovernanceRetention 權限的授權 IAM principal 可繞過鎖定。適合不需要絕對不可變性的內部防竄改需求。
• Compliance 模式 — 連 root 帳號在保留期內都無法刪除。適合受管制資料（SEC 17a-4、FINRA、HIPAA 稽核軌跡）。不可逆——啟用 Compliance 模式是一條單向門。

對於受法規範圍約束的集中式安全日誌，在 Log Archive bucket 上使用 Compliance 模式，保留期符合最長的法規要求（通常為 SOX 的 7 年，或某些金融服務法規要求的 10 年）。

AWS Backup 的 S3 Vault Lock

另外，AWS Backup 在備份保險庫上支援 Vault Lock——類似的概念套用於 AWS Backup 快照而非 S3 物件。對於集中式安全日誌，Backup vault lock 保護關鍵資源的設定備份——EC2 AMI、RDS 快照、EFS 備份——免受勒索軟體式刪除的侵害。

成本最佳化的生命週期政策

Compliance 模式鎖定物件；它不阻止生命週期轉換。集中式安全日誌的標準生命週期：

• 第 0-30 天 — S3 Standard（主動調查窗口，熱查詢）。
• 第 31-90 天 — S3 Standard-IA（例行查詢，便宜 40%）。
• 第 91-365 天 — S3 Glacier Instant Retrieval（合規查詢，比 Standard 便宜 68%）。
• 第 366-3650 天 — S3 Glacier Deep Archive（存根保留，比 Standard 便宜 95%，12 小時取回）。

結合 Compliance 模式 Object Lock 於保留期，在最低成本下實現防竄改的長期保留。

CloudWatch Logs 保留期

每個 CloudWatch log group 都有保留期設定（預設：永不到期）。對於集中式安全日誌的衛生管理，請在每個 log group 上設定明確的保留期——正式環境應用程式日誌通常 30 天（之後透過 Firehose 轉移至 S3 存檔），sandbox 除錯日誌 7 天。使用 AWS Config 規則 cw-loggroup-retention-period-check 稽核合規狀況。

第三方 SIEM 整合 — Splunk、Datadog 等

多數成熟組織執行第三方 SIEM——Splunk、Datadog、Sumo Logic、Sentinel、QRadar。AWS 上的集中式安全日誌必須為這個 SIEM 提供資料，而非取代它。

路徑一 — Security Lake 訂閱者

新 SIEM 整合的推薦路徑：啟用 Security Lake，然後將 SIEM 訂閱為資料訂閱者。Splunk Cloud、Datadog、IBM QRadar、Palo Alto Cortex 等都有原生的 Security Lake 訂閱者——在 SIEM 的主控台中設定，而非在 AWS 中。SIEM 接收每個新 OCSF 物件的 SNS 通知，並透過 S3 GetObject 拉取。優點：OCSF 正規化在 SIEM 攝入前就完成（節省基於非結構化資料量的 SIEM 授權成本）、一個訂閱者涵蓋 Security Lake 攝入的所有日誌流，以及向 Security Lake 新增的日誌流會自動流向 SIEM。

路徑二 — 直接 Firehose 至 SIEM HTTP 端點

對於沒有 Security Lake 支援的 SIEM，或對於低延遲敏感的即時串流，可傳送 CloudWatch Logs subscription filter → Kinesis Firehose → HTTP 端點傳送（Splunk HEC、Datadog intake、通用 HTTPS）。Firehose 處理緩衝、重試和傳送失敗時的備份至 S3。這是 Security Lake 之前的模式，對 Security Lake 未涵蓋的串流（自訂應用程式日誌、第三方 EDR）仍然有效。

路徑三 — 受管 OpenSearch 作為 SIEM

Amazon OpenSearch Service 搭配 Security Analytics 外掛程式，可作為第一方 SIEM 替代方案。日誌透過 Firehose 流入 OpenSearch 索引；Security Analytics 提供預建的偵測規則、異常偵測和關聯分析。對於想要避免每 GB SIEM 授權費用的組織，這是具成本效益的方案。在 SAP-C02 考試中，當情境說「成本最佳化的 SIEM」或「避免第三方授權費」時，OpenSearch 就會出現。

資料傳輸成本考量

大型 SIEM 攝入 pipeline 每月可能跨 VPC 或跨區域移動 PB 級資料。集中式安全日誌的成本主要由以下因素決定：SIEM 授權的每日 GB 攝入量（Splunk 依每日 GB 計費）、若 SIEM 在 AWS 外部的 GB 出口費用（Splunk Cloud 從 AWS 的出口費用），以及 Firehose 的每 GB 處理費加重試費用。緩解方式：使用 Security Lake 的 OCSF 正規化在 SIEM 攝入前捨棄噪音欄位、對低重要性串流取樣（sandbox VPC Flow Logs 以 10% 取樣），以及若 SIEM 在 AWS 上則使用 Firehose 的 VPC 端點以避免 NAT Gateway 費用。

AWS Audit Manager 合規證據收集

Audit Manager 將集中式安全日誌資料打包成對齊合規框架、稽核人員就緒的證據。

Audit Manager 如何使用集中式安全日誌

Audit Manager 跨範圍內的每個帳號持續收集證據：從 CloudTrail（用於「誰在何時做了什麼」的認證）、AWS Config（用於設定合規認證），以及 Security Hub（用於「此控制是否處於通過狀態」）。它將每條證據映射至 SOC 2 Type 2、PCI DSS 4.0、HIPAA Security Rule、NIST 800-53、ISO 27001、GDPR 等框架中的特定控制 ID。

多帳號評估

透過 AWS Organizations 委派管理員，Security 帳號中的單一 Audit Manager 評估可自動橫跨每個成員帳號。稽核時，將評估報告匯出為 PDF 加結構化證據存檔——這正是外部稽核人員所需要的。

Audit Manager 為何屬於集中式安全日誌

沒有集中式 CloudTrail、集中式 Config 和 Security Hub 聚合，Audit Manager 就沒有資料可收集。Audit Manager 是集中式安全日誌基礎架構的頂層消費者——單獨存在時毫無意義。當 SAP-C02 情境說「我們需要為 SOC 2 Type 2 稽核做準備」時，答案鏈是：確保 CloudTrail 組織追蹤 → 確保 Config aggregator → 啟用 Security Hub 搭配 FSBP + SOC 2 控制 → 啟用 Audit Manager 搭配 SOC 2 框架評估且範圍涵蓋整個 Organization。沒有集中式安全日誌的 Audit Manager 產生的是空白證據。

Pro 稽核工作流程 — 調查跨帳號事件

SAP-C02 的標準情境：「GuardDuty 發現帳號 42 在 UTC 03:17 有加密貨幣挖礦的活動。請使用集中式安全日誌描述調查工作流程。」以下是參考答案。

步驟一 — 在 Security Hub 進行分類

開啟聚合區域的 Security Hub。發現已有完整脈絡：受影響帳號 42、受影響的 EC2 執行個體 ID、嚴重性，以及相關的 IAM 角色（若有）。點進 GuardDuty 查看包含觀察到的域名或 IP 目的地的完整發現詳情。

步驟二 — 在 VPC Flow Logs 中驗證

查詢 Log Archive Athena 資料表，取得過去 24 小時受影響 ENI 的 flow logs。確認外部 IP 目的地與 GuardDuty 發現中的挖礦池 IP 相符。識別所有聯繫過相同目的地的其他 ENI（橫向移動偵測）。

步驟三 — 與 DNS 查詢關聯

查詢 Route 53 Resolver 查詢日誌資料表，取得受影響執行個體的 DNS 解析記錄。識別類似 pool.supportxmr.com 的挖礦池 DNS 域名。跨所有 VPC 交叉比對——若另一個執行個體解析了相同的域名，也要調查。

步驟四 — 在 CloudTrail Lake 重建存取記錄

CloudTrail Lake 中的 SQL 查詢：SELECT * WHERE userIdentity.sessionContext.sessionIssuer.arn LIKE '%AffectedInstanceRole%' AND eventTime > 2026-04-19T03:00:00Z。識別建立持久化的 session——它是否執行了 aws configure 新增憑證、是否呼叫 ec2:RunInstances 擴散、是否呼叫 s3:GetObject 取得敏感 bucket 的資料。

步驟五 — 確定受影響資料的範圍

若敏感 S3 bucket 上已啟用 CloudTrail 資料事件，查詢資料事件資料表取得受入侵角色的 GetObject 呼叫記錄。確定被外滲的資料範圍。

步驟六 — 透過 Systems Manager 進行修復

從 Security 帳號，呼叫 SSM Automation runbook AWS-IsolateInstance 套用隔離安全群組。呼叫對執行個體使用的任何憑證進行金鑰輪換。在進行鑑識映像擷取時停用 IAM 角色。

步驟七 — 在 Audit Manager 中記錄

將發現、調查證據和修復行動附加至受影響框架（SOC 2 CC7.3 事件回應、PCI DSS 12.10 事件回應計畫）的 Audit Manager 評估。此步驟產生稽核人員就緒的證據。

具備集中式安全日誌的總調查時間：30 至 90 分鐘。沒有集中式安全日誌——在 15 個帳號主控台間跳轉——同樣的調查需要數天，而且通常會遺漏跨帳號的指標。

Pro 改造方案 — 30 天集中化 15 個帳號

最常被考的 SAP-C02 情境模式：一個現有的 AWS Organization，有 15 個成員帳號各自本地記錄（或根本沒有記錄），需要在 30 天內部署中央 SOC 視角和集中式安全日誌架構。

第一週 — 基礎建設

1. 透過 Control Tower Account Factory（若使用 Control Tower）或手動佈建，專屬化 Log Archive 帳號和 Security/Audit 帳號。
2. 建立 Log Archive S3 bucket，使用組織共享 KMS CMK 的預設加密、版本控制、7 年保留期的 Object Lock Compliance 模式、生命週期規則（Standard → Standard-IA → Glacier Instant → Glacier Deep Archive）。
3. 從管理帳號建立 CloudTrail 組織追蹤，傳送至 Log Archive bucket。啟用管理事件（免費層）加上敏感 S3 和所有 Lambda 上的資料事件。啟用 CloudTrail Insights。啟用日誌檔完整性驗證。
4. 將 Config 委派管理員指定至 Security 帳號，建立組織範圍的 Config 並傳送至 Log Archive bucket，啟用 Config aggregator。
5. 將 GuardDuty、Security Hub、Inspector v2、Macie、Access Analyzer 委派管理員指定至 Security 帳號。啟用每個服務的組織範圍設定並對新帳號自動啟用。

第二週 — 網路和 DNS 日誌

1. 使用來自 Security 帳號的 CloudFormation StackSets，在每個 VPC 的 VPC 層級啟用 VPC Flow Logs。自訂格式涵蓋全部 34 個欄位。直接傳送至 Log Archive S3 bucket。
2. 在 Security 或 Networking 帳號建立 Route 53 Resolver 查詢日誌設定。透過 RAM 共享。關聯至每個 VPC。傳送至 Log Archive bucket。
3. 透過 Firewall Manager 部署 AWS WAF，涵蓋每個成員帳號的每個 ALB / CloudFront / API Gateway。將 WAF 日誌設定傳送至 Firehose，再傳送至 Log Archive S3。
4. 在 Security 帳號中設定 Athena workgroup 和 Glue Data Catalog 資料表，涵蓋 flow logs、DNS 日誌、WAF 日誌、CloudTrail。啟用 partition projection 以降低查詢成本。

第三週 — Security Lake 和發現聚合

1. 在 Security 帳號中以委派管理員身份啟用 Amazon Security Lake。攝入 CloudTrail、VPC Flow Logs、Route 53 Resolver 日誌、Security Hub 發現和 WAF 日誌。以 Log Archive bucket 所在區域為主要區域，並加入工作負載執行的其他區域。
2. 設定 Security Hub 跨區域聚合，以相同區域為主要區域。啟用 AWS Foundational Security Best Practices 和任何所需的合規標準（CIS、PCI、NIST）。
3. 使用 SIEM 的原生 Security Lake 整合，將 Splunk 或 Datadog 訂閱者新增至 Security Lake。驗證 OCSF 記錄流入 SIEM。
4. 啟用 CloudTrail Lake，使用組織範圍事件資料存儲，保留期 10 年。驗證 SQL 查詢跨所有帳號返回事件。

第四週 — 回應自動化與證據

1. 在 Security 帳號建立 EventBridge 規則，高嚴重性發現 → SNS → PagerDuty 通知 SOC 值班人員。在 Security Hub 中為常見的誤報建立 Automation Rule。
2. 部署 Systems Manager Automation runbook，包含 AWS-IsolateInstance、AWS-DisableIAMAccessKey 以及適合你技術棧的自訂 runbook。透過跨帳號角色，從 Security 帳號委派執行至成員帳號。
3. 啟用 AWS Audit Manager，搭配所需的框架評估（SOC 2、PCI 或行業特定框架）。範圍涵蓋整個 Organization。
4. 進行桌面推演（tabletop exercise），模擬 EC2 執行個體遭入侵的發現，並走過上方記錄的七步驟調查工作流程。根據發現的落差精修 runbook。

30 天後的成果

每個帳號的每條日誌流都流向中央不可變存儲。SOC 分析師從一個主控台查詢（CloudTrail Lake、Athena、Security Hub）。第三方 SIEM 接收正規化的 OCSF 事件。發現在五分鐘內路由至值班人員。Audit Manager 持續收集合規證據。透過 Account Factory 新增的帳號自動繼承所有這一切。

集中式安全日誌 — 成本架構

集中式安全日誌有隨組織規模和日誌量擴大的經常性成本。SAP-C02 考試會測試具成本意識的集中式安全日誌設計。

CloudTrail 成本模型

管理事件：第一份免費（組織追蹤），額外追蹤每 10 萬事件 $2 美元。資料事件：每 10 萬事件 $0.10 美元。CloudTrail Insights：每分析 10 萬事件 $0.35 美元。CloudTrail Lake：每攝入 GB $2.50 美元，加每掃描 GB $0.005 美元。對於 100 個帳號的組織，在敏感資源上啟用資料事件並以 10 年保留期使用 CloudTrail Lake，依活動量預估每月預算 $5,000 至 $20,000 美元。

Security Lake 成本模型

Security Lake 依每月每 GB 攝入量計費，較高用量有分級折扣。典型的多帳號部署跨所有串流每月攝入 1 至 10 TB。以標準費率計算，僅聚合服務每月 $1,000 至 $5,000 美元——加上 S3 儲存、Lake Formation 及下游 Athena 或訂閱者成本。

搭配生命週期的 S3 儲存成本

50 個帳號組織一年的集中式日誌通常為 10 至 50 TB。搭配第 180 天後轉至 Glacier Deep Archive 的生命週期設定，存檔資料的長期成本降至每月每 GB $0.00099 美元。中型組織的 10 年 Object Lock Compliance 保留期，年成本低於 $10,000 美元。

VPC Flow Logs 成本

Flow log 攝入至 S3 的資料攝入費為每 GB $0.50 美元。高吞吐量的正式環境 VPC 每天可產生 100 GB。在企業規模下，組織範圍的 flow logs 每月可達 $10,000 至 $50,000 美元——是集中式安全日誌中單項最大的費用。

Firehose 成本

Firehose 依每 GB 攝入量計費（500 TB/月以下：每 GB $0.029 美元）。每月透過 Firehose 的集中式安全日誌 10 TB，月費約 $290 美元——與下游 SIEM 成本相比相當低廉。

成本最佳化模式

• 對非關鍵串流取樣 — sandbox VPC Flow Logs 以 10% 取樣。
• 積極的生命週期 — 在合規允許的最早時間移至 Glacier Deep Archive。
• 先進行 OCSF 正規化 — Security Lake 捨棄冗餘欄位，降低下游 SIEM 攝入量。
• SCP 強制區域限制 — 在你未使用的區域進行集中式安全日誌浪費金錢；SCP 拒絕未批准的區域。

集中式安全日誌的常見考試陷阱

陷阱一 — 單一帳號可同時持有日誌和工具

錯誤。標準架構將 Log Archive（不可變證據）與 Security/Audit（主動工具）分開。將兩者合併的答案通常是干擾選項的訊號。

陷阱二 — CloudWatch Cross-Account Observability 取代了 Subscription Filter

錯誤。Cross-Account Observability 用於監控帳號主控台中的互動式儀表板。Subscription filter 用於自動化 pipeline（至 Firehose、Lambda、目的地）。它們解決不同的問題——成熟的集中式安全日誌兩者都用。

陷阱三 — CloudTrail Lake 消除了對 S3 存檔的需求

錯誤。CloudTrail Lake 是可查詢的儲存；S3 搭配 Object Lock 是防竄改的法規儲存。CloudTrail Lake 目前尚未通過 SEC 17a-4 的 WORM 存儲認證——S3 Object Lock Compliance 模式才是。多數成熟的集中式安全日誌同時執行兩者。

陷阱四 — Security Lake 取代了 CloudTrail Lake

部分正確。Security Lake 攝入 CloudTrail 事件、正規化為 OCSF 並服務訂閱者。CloudTrail Lake 是具備更豐富 CloudTrail 語義的 CloudTrail 專用 SQL 查詢引擎。兩者互補；Security Lake 用於跨來源 OCSF 分析，CloudTrail Lake 用於深度 CloudTrail 查詢。

陷阱五 — VPC Flow Logs 涵蓋所有網路流量

錯誤。VPC Flow Logs 擷取穿越 ENI 的流量的 IP 層中繼資料。它們不擷取：同一 ENI 內的流量（localhost）、對 169.254.169.253 的鏈路本地 Amazon DNS 查詢（使用 Resolver 查詢日誌）、以線速鏡像的流量（使用 VPC Traffic Mirroring）、加密酬載內容（flow logs 僅為中繼資料）。

陷阱六 — S3 Object Lock Governance 模式是防竄改的

錯誤。Governance 模式允許具備 s3:BypassGovernanceRetention 的授權 principal 刪除。只有 Compliance 模式才能防止包括 root 在內的所有人刪除。受管制的工作負載需要 Compliance 模式。

陷阱七 — 組織追蹤自動涵蓋資料事件

錯誤。即使在組織追蹤上，資料事件也是依資源選擇加入。忘記在敏感 S3 bucket 上啟用資料事件，是稽核中發現的最常見單一集中式安全日誌缺口。

陷阱八 — GuardDuty 單獨就是集中式安全日誌

錯誤。GuardDuty 是一個發現來源。集中式安全日誌是將 CloudTrail、Flow Logs、Resolver 日誌、WAF 日誌、Security Hub 發現、Inspector 發現和 Config 快照，收集到一個正規化、受保留期限管控的存儲中的總體架構。

陷阱九 — Security Lake 需要 Splunk 或 Datadog

錯誤。Security Lake 沒有任何訂閱者也能運作——它將資料正規化為客戶的 S3 bucket 並提供 Lake Formation 存取。第三方 SIEM 是可選的下游消費者。許多組織純粹使用 Security Lake 進行內部 Athena 分析。

陷阱十 — CloudWatch Logs 保留期是自動的

錯誤。預設保留期是「永不到期」。需要明確設定保留期，否則日誌會無限累積並產生不必要的費用。使用 Config 規則 cw-loggroup-retention-period-check 進行稽核。

關鍵數字與必記的集中式安全日誌事實

CloudTrail

• 組織追蹤從管理帳號或 CloudTrail 委派管理員建立。
• 管理事件：第一份免費。資料事件：需選擇加入，依事件計費。
• CloudTrail Lake：最長 10 年保留期，SQL 可查詢，不可變。
• 完整性驗證每小時產生 SHA-256 RSA 簽署的摘要檔案。

Security Lake

• Security 帳號中的委派管理員。
• OCSF JSON 正規化，在客戶自有 bucket 中的分區 S3 儲存。
• 查詢訂閱者透過 Lake Formation 授予；資料訂閱者透過 SQS + S3 拉取。
• 原生訂閱者：Splunk、Datadog、IBM QRadar、Palo Alto、SentinelOne。

VPC Flow Logs

• VPC / 子網路 / ENI 粒度。
• 目的地：S3（最便宜）、CloudWatch Logs（昂貴）、Firehose（即時）。
• 自訂格式 34 個欄位 vs 預設 14 個——務必使用自訂格式。
• Athena 上的 partition projection 將查詢成本降低 50 至 100 倍。

CloudWatch Logs 跨帳號

• 目的地是包裝 Kinesis Stream 或 Firehose 的具名端點。
• Subscription filter 從成員帳號 → Security 帳號中的目的地。
• Cross-Account Observability：監控帳號加來源帳號，提供統一儀表板。

S3 Object Lock

• Governance 模式——授權 principal 可繞過。
• Compliance 模式——無任何繞過，包括 root 帳號。
• SEC 17a-4、FINRA 4511、CFTC 1.31(c)-(d) 必需。

Route 53 Resolver 查詢日誌

• 每個 VPC 的設定，可透過 RAM 共享。
• 目的地：CloudWatch Logs、S3、Firehose。
• 擷取每一次 DNS 查詢，包括對私有託管區域和轉發至本地端的查詢。

發現聚合

• GuardDuty、Security Hub、Inspector v2、Macie、Access Analyzer——全部採用委派管理員模式。
• Security Hub 跨區域聚合：每個組織一個聚合區域。
• ASFF 是發現格式；OCSF 是日誌格式（Security Lake）。

Audit Manager

• 消費 CloudTrail、Config、Security Hub。
• 框架：SOC 2、PCI DSS、HIPAA、NIST 800-53、ISO 27001、GDPR、FedRAMP、AWS WA。
• 來自委派管理員的組織範圍評估。

改造時程

• 基礎建設（CloudTrail + Config + 發現委派管理員）：第一週。
• 網路 + DNS + WAF 日誌：第二週。
• Security Lake + SIEM 訂閱者 + CloudTrail Lake：第三週。
• 自動化 + Audit Manager + 桌面推演：第四週。

FAQ — 集中式安全日誌熱門問題

Q1 — CloudTrail Lake 和 Amazon Security Lake 有什麼差別？我應該使用哪個？

CloudTrail Lake 是專為 CloudTrail 事件（管理、資料、Insights，以及自訂 CloudTrail 綱要事件）建置的 SQL 查詢引擎。它保留最長 10 年、不可變，擅長具備 CloudTrail 專屬語義的深度 CloudTrail 鑑識。Amazon Security Lake 是更廣泛的集中式安全日誌 data lake，攝入 CloudTrail、VPC Flow Logs、Route 53 Resolver 日誌、Security Hub 發現和 WAF 日誌（以及自訂來源），將所有資料正規化為 OCSF 以供跨來源分析和 SIEM 訂閱者使用。兩者兼用：分析師專門針對 CloudTrail 進行具備最豐富語義的查詢時使用 CloudTrail Lake；需要跨來源查詢（CloudTrail API 呼叫與 VPC Flow Log 及 WAF 決策的關聯），或第三方 SIEM 消費資料時使用 Security Lake。兩者互補而非競爭。

Q2 — 對於 50 個帳號的組織，VPC Flow Logs 應傳送至 S3 還是 CloudWatch Logs？

集中式安全日誌存檔選 S3——每 GB 費用比 CloudWatch Logs 便宜約 5 倍，且與 Security Lake 原生整合。只有在需要即時 subscription filter 轉送至 Lambda 或 Firehose 處理特定安全事件（子集）時，才使用 CloudWatch Logs。50 個帳號正式環境的標準模式：直接傳送至 S3，搭配 Glue 資料表和 Athena partition projection 進行查詢，外加可選的 Firehose 即時串流至 SIEM。在這個路徑中間加入 CloudWatch Logs 會浪費金錢而不增加能力。

Q3 — 如何將 15 個帳號的 CloudWatch Logs 集中至單一 Splunk 實例？

三個元件。(1) 在 Security 帳號建立一個 Kinesis Firehose 傳送串流，目標為 Splunk HTTP Event Collector，搭配適當的緩衝與重試設定。(2) 在 Security 帳號建立一個 CloudWatch Logs 目的地，包裝該 Firehose。其存取政策授予 15 個成員帳號 ID 各自的 logs:PutSubscriptionFilter 權限。(3) 在每個成員帳號中，對你想轉送的 log group 建立 subscription filter，指向目的地的 ARN。篩選模式只選取安全相關事件。結果：每個帳號中每個符合條件的日誌事件，都透過一個中央 Firehose 流入 Splunk，去重與重試由 AWS 處理。使用 Firewall Manager 或 CloudFormation StackSets 大規模部署 subscription filter。

Q4 — 什麼是 OCSF？為什麼 Amazon Security Lake 使用它？

Open Cybersecurity Schema Framework (OCSF) 是安全事件資料的開放廠商中立標準，由 AWS、Splunk、IBM 等共同開發。在 OCSF 之前，每個安全工具都有自己的綱要——CloudTrail 欄位、VPC Flow Log 欄位、Splunk Common Information Model、Elastic Common Schema、Microsoft Sentinel 綱要——迫使分析師學習各種綱要並撰寫工具專屬的查詢。OCSF 跨類別（身份驗證、網路活動、檔案活動、發現）統一欄位名稱（actor.user.name、src_endpoint.ip、activity_id、disposition），讓一個查詢不論來源為何都能運作。Security Lake 在存儲前將所有攝入資料正規化為 OCSF，這意味著下游 SIEM 消費者接收的是統一結構的事件，無論它們源自 CloudTrail、VPC Flow Logs 還是自訂 EDR 來源。這是集中式安全日誌的重大加速器。

Q5 — 如何在集中式安全日誌 Log Archive bucket 上啟用 S3 Object Lock，而不中斷現有的 CloudTrail 傳送？

S3 Object Lock 必須在 bucket 建立時啟用——無法在現有 bucket 上啟用。改造路徑：建立一個啟用 Object Lock 並設定預設保留期的新 bucket，建立一個傳送至新 bucket 的新 CloudTrail 追蹤（或更新現有追蹤的目的地），驗證傳送，然後使用 S3 Batch Operations 將歷史資料從舊 bucket 遷移至新 bucket（Batch Operations 可在複製時為 Object Lock 套用每物件的保留期）。驗證後，移除舊追蹤設定。對受管制的工作負載選擇 Compliance 模式而非 Governance 模式，因為 Governance 模式可以被繞過。Object Lock 是每物件的；Batch Operations 在複製過程中設定每物件的保留期。

Q6 — AWS Security Hub 需要啟用 CloudTrail 嗎？

是的，實質上需要。Security Hub 的 Foundational Security Best Practices 和 CIS 控制包含要求啟用 CloudTrail 並記錄至具完整性驗證的 S3 bucket 的規則。沒有 CloudTrail，Security Hub 合規分數會急劇下降，多個控制項會直接失敗。更廣泛地說，Security Hub 聚合來自 GuardDuty 的發現（GuardDuty 本身以 CloudTrail 事件串流作為主要資料來源），因此即使忽略特定的 FSBP 控制，Security Hub 的偵測價值也取決於 CloudTrail。在啟用 Security Hub 委派管理員之前，務必先啟用組織 CloudTrail 追蹤——它是基礎串流。

Q7 — 我可以使用 AWS Firewall Manager 在 100 個帳號中部署 WAF 日誌嗎？

可以。Firewall Manager 政策包含一個日誌設定，會套用至政策部署的每個 Web ACL。設定方式：在 Security 帳號（作為 Firewall Manager 委派管理員），建立一個 WAFv2 類型的 Firewall Manager 政策，附帶指定的規則群組和指向 Kinesis Firehose ARN 的日誌設定。政策針對指定的 OU 或帳號。Firewall Manager 將啟用日誌的 Web ACL 部署至每個目標帳號的 ALB / CloudFront / API Gateway。一個 Firewall Manager 政策取代 100 個手動的逐帳號 WAF 設定，並保證日誌的一致性。

Q8 — SOC 2 Type 2、PCI DSS 和 HIPAA 各需要多長的日誌保留期？

SOC 2 Type 2 不強制規定具體的保留期；稽核人員通常期望至少 12 個月涵蓋稽核期間的日誌，部分稽核人員要求兩個完整週期。PCI DSS 4.0 要求至少一年的日誌保留期，且三個月內的資料可立即供稽核使用（需求 10.5.1）。HIPAA Security Rule 164.316(b)(2) 要求從建立或最後生效日期（以較晚者為準）起保留文件六年。金融服務法規要求更嚴格：SEC 17a-4(f) 要求七年，前兩年必須可立即存取。受管制組織的集中式安全日誌生命週期模式：S3 Standard 保留 90 天（可立即存取），Standard-IA 保留 6 至 12 個月，Glacier Instant 保留 1 至 3 年，Glacier Deep Archive 至 7 年或 10 年標記，全程搭配 Compliance 模式 Object Lock。

Q9 — 如何集中化尚未加入我的 AWS Organization 的帳號的安全日誌？

依外部帳號是否能加入你的 Organization 有兩種路徑。若能加入（標準的企業併購模式），透過 Organizations 邀請，接受後，組織 CloudTrail 追蹤加上委派管理員服務會自動啟用日誌。若不能加入（合資、供應商帳號、合作夥伴），在你的 Log Archive bucket 上使用跨帳號 S3 bucket policy，授予外部帳號的 CloudTrail 服務主體 s3:PutObject 權限，搭配適當的 aws:SourceArn 和 aws:SourceAccount 條件；外部帳號建立自己的追蹤傳送至你的 bucket。VPC Flow Logs 和其他串流也可採用類似的資源政策方式。注意：外部帳號的日誌缺乏 GuardDuty / Security Hub / Inspector 自動委派管理員聚合——這些服務的集中化功能需要 Organization 成員資格。

Q10 — 對於目前沒有任何集中式安全日誌的組織，ROI 最高的單項改善是什麼？

啟用 AWS Organizations CloudTrail 追蹤，傳送至 Log Archive 帳號 S3 bucket，並設定 Object Lock Compliance 模式。這個單一動作產生：每個帳號每個區域的每次控制平面 API 呼叫的防竄改記錄、GuardDuty 偵測的基礎、Security Hub 合規評分的基礎、Audit Manager 證據收集的基礎，以及大多數法規稽核軌跡的最低可接受形式。成本：近乎為零（管理事件在組織追蹤上免費；搭配生命週期的 S3 儲存每 GB 僅幾分錢）。實施時間：一天。本指南中的所有其他內容都建立在這個基礎之上——如果只做一件事，就做這個。

延伸閱讀 — 集中式安全日誌的 AWS 官方文件

超出 SAP-C02 範圍的深度學習，權威 AWS 來源包括：AWS CloudTrail User Guide（特別是組織追蹤和 CloudTrail Lake 章節）、Amazon Security Lake User Guide（OCSF 綱要、訂閱者管理、自訂來源）、VPC User Guide（Flow Logs 章節）、Amazon CloudWatch Logs User Guide（跨帳號訂閱、subscription filter、Cross-Account Observability）、Amazon Data Firehose Developer Guide、Route 53 Developer Guide（Resolver 查詢日誌）、AWS WAF Developer Guide（日誌章節）、Amazon S3 User Guide（Object Lock）、GuardDuty / Security Hub / Inspector 使用者指南（組織整合章節），以及 AWS Audit Manager User Guide。

AWS Security Reference Architecture (SRA) 白皮書是集中式安全日誌的標準參考——它整理了 Log Archive / Security 帳號 / 委派管理員模式，是 SAP-C02 考試的必讀內容。AWS Well-Architected Security Pillar 白皮書提供概念基礎。過去兩年 AWS re:Inforce 的錄影課程，包含多個 Security Lake 和 OCSF 在正式環境應用的深度解析。最後，OCSF Schema Browser（schema.ocsf.io）是自訂來源工作的必備工具。