AWS 日誌分析：Athena、CloudWatch Logs Insights、CloudTrail Insights、Security Hub Insights 與 Security Lake

日誌分析為何是 SCS-C02 的核心

日誌分析是雲端安全維運的骨幹，SCS-C02 考試將它列為 Domain 2 Task Statement 2.5 的一等公民技能。你建置的每一項偵測控制——從 GuardDuty 到 Security Hub 到自訂 Lambda 規則——最終都會產生日誌，這些日誌必須被解析、正規化、關聯，並加以查詢，才能回答真實問題：哪個身分承接了哪個角色、哪個 IP 掃描了你的 VPC、哪條 WAF 規則擋下了攻擊，以及昨晚的異常究竟是設定錯誤的排程工作還是真正的入侵。AWS 提供五個互補的日誌分析介面——Amazon Athena 提供對 S3 的臨機 SQL 查詢、CloudWatch Logs Insights 處理即時串流、CloudTrail Insights 偵測管理事件異常、Security Hub Insights 聚合發現項目，以及 Amazon Security Lake 進行 OCSF 正規化的跨帳號分析——稱職的 SCS-C02 考生必須知道何時該選用哪一個。

考試不會要求你背誦完整的 Athena DDL 語句。它考的是服務選擇與架構適配：在具有成本限制、查詢延遲目標、保留期視窗、多帳號範圍與整合需求的情境中，哪種日誌分析工具是正確答案？底層儲存又該如何設計，才能讓日誌分析快速、低成本且防竄改？本章節整理了在計分題中最常出現的模式，並提供你處理新型情境所需的推理框架。

五大日誌分析介面一覽

AWS 沒有單一的「日誌分析服務」。它擁有一套分層工具組，每個工具都針對特定的存取模式、保留期視窗與成本結構進行調校。請記住這五個介面與它們之間的邊界——考試會給你一個情境，並期待你選出唯一正確答案。

第一個介面是 Amazon Athena——對 S3 資料執行 serverless SQL。Athena 可讀取 CloudTrail 日誌、VPC Flow Logs、ALB 日誌、CloudFront 日誌、WAF 日誌，以及任何你放進 bucket 的自訂 JSON 或 Parquet。它使用 AWS Glue Data Catalog 做為 schema，按每 TB 掃描量計費。當題目出現**「查詢 S3 日誌」、「臨機查詢」、「長期保留」或「跨數月資料的鑑識調查」**時，Athena 就是正確答案。

第二個介面是 CloudWatch Logs Insights——一種內建於 CloudWatch Logs 的查詢語言，作用在 log group（而非 S3）上。它對於仍在 CloudWatch 保留期內的最近數天至數週的日誌查詢速度很快。當題目出現**「互動式排查 Lambda 錯誤」、「過去一小時的登入失敗激增」或「透過 CloudWatch agent 串流的應用程式日誌」**時，Logs Insights 就是正確答案。

第三個介面是 CloudTrail Insights——CloudTrail 本身的一項功能，使用機器學習來偵測異常的管理事件 API 呼叫速率。它不是查詢工具，它是偵測工具。當情境提到**「異常的 API 呼叫量」或「管理事件的基線偏移」**時，它就是正確答案。

第四個介面是 Security Hub Insights——對 Security Hub 聚合的 AWS Security Finding Format（ASFF）發現項目所做的已儲存篩選視圖。Insights 不是任意的日誌查詢；它們是對已正規化安全發現項目的篩選器。

第五個介面是 Amazon Security Lake——一個受管理的資料湖，從原生 AWS 來源和第三方合作夥伴擷取日誌，將它們正規化為 **Open Cybersecurity Schema Framework（OCSF）格式，以 Parquet 格式儲存在客戶自有的 S3 bucket 中，並透過 Athena、OpenSearch 或第三方 SIEM 向訂閱者公開。Security Lake 是「多帳號、多來源、schema 正規化分析」以及「與 SIEM 團隊共享正規化日誌」**的正確答案。

白話文解釋

類比一：國家圖書館閱覽系統（Athena）

把雲端日誌想成國家圖書館的館藏。CloudTrail、VPC Flow Logs、WAF 日誌就像從各地捐贈進來的書籍與期刊，全部進了中央倉庫（S3）。光有書不夠，你需要圖書館的卡片目錄（Glue Data Catalog）知道每本書放在哪一排哪一格，還需要書目索引（partition projection）讓館員不用翻遍所有書架。Athena 就是那位能根據索引卡快速找書的圖書館員——你提出 SQL 問題，館員直接跳到對的書架、翻到對的頁面，而不是把整個館藏搬出來翻一遍。Parquet 格式就像把書壓縮成縮印版本，同樣的書架空間能放十倍的資料；你要找的只是書中的某幾個欄位，縮印本只要翻那幾頁，帳單就大幅下降。

類比二：便利商店（CloudWatch Logs Insights）

CloudWatch Logs Insights 就像二十四小時便利商店。它離你最近、隨時能進門、商品種類有限但拿了就走。你不會在便利商店辦年夜飯（那是 Athena 的場合），但臨時想查最近一小時的 Lambda 錯誤、五分鐘前的登入失敗，便利商店就是最快的選擇。Logs Insights 的查詢語言（filter / stats / parse / sort）就是便利商店的貨架編號——熟了之後幾秒鐘就能找到要的東西。記住：便利商店的存貨只放最近這幾天（CloudWatch retention），舊貨早就出清到倉庫（S3）了，那時就得換 Athena。

類比三：全國警局統一報案系統（Security Lake）

Security Lake 就像全國警察局的統一報案系統。台北市警察局用一種格式登記案件、高雄市用另一種、台中市又是另一種——彼此之間資料格式不通，要跨縣市比對資料，分析師會累死。Security Lake 的角色就是設立一套全國統一報案格式（OCSF schema），每個服務（CloudTrail、VPC、Route 53、Security Hub）不論原本格式是什麼，進來之後都重新登錄為標準欄位。SOC 分析師（Athena 訂閱者、SIEM 系統）只要學會查一套格式，就能讀遍所有來源的案件——這就是正規化的核心價值，你的團隊不再需要為每種日誌格式各寫一支 parser。

Amazon Athena 安全查詢模式

Athena 是 SCS-C02 對於「我有幾個月的 CloudTrail 或 VPC Flow Logs 在 S3，需要找到證據」情境的預設答案。讓 Athena 表現良好的三件事：一份合理的 Glue Data Catalog 資料表、使用 partition projection 避免整個 bucket 掃描付費，以及使用 Parquet（或至少 gzip 壓縮的 JSON），讓每次掃描讀取壓縮的欄位資料而非原始文字。

CloudTrail 查詢模式

對於 CloudTrail，AWS 已發布資料表 schema，你可以用一道 CREATE EXTERNAL TABLE 建立它。最常見的安全查詢包括：

• 尋找 AssumeRole 濫用：篩選 eventName='AssumeRole'，以 userIdentity.arn、來源 IP 與被承接的角色 ARN 分組；尋找從未接觸過某角色的主體，或從非公司 IP 短時間內大量承接的情況。
• 識別異常的區域使用：選取 awsRegion、eventSource 與 userIdentity.userName，以區域分組，標記任何不在核准清單中的區域。當攻擊者使用竊取的憑證在受害者未監控的閒置區域（例如 ap-south-1）操作時，這個查詢就能抓出來。
• 使用者活動時間線：篩選 userIdentity.arn = 'arn:aws:iam::...:user/alice' 過去 30 天，依 eventTime 排序，即可得到按時間順序排列的稽核軌跡。搭配 sourceIPAddress 與 userAgent 可辨別是機器產生的呼叫（CLI vs SDK vs 主控台）。
• 偵測未使用 MFA 的主控台登入：eventName='ConsoleLogin' 且 additionalEventData.MFAUsed='No'——這是合規稽核人員的經典發現項目。

VPC Flow Logs 查詢模式

VPC Flow Logs（尤其是帶有擴充欄位的 v5 版本）是標準的網路偵測控制。常見的 Athena 查詢模式包括：

• 最大流量來源：以 srcaddr 和 dstaddr 分組，加總 bytes，降序排列。前 20 筆資料通常會揭露失控的資料外洩工作。
• REJECT 流量模式：篩選 action='REJECT'，以 srcaddr 和 dstport 分組。來自單一外部 IP 對 port 22 的大量 REJECT，通常代表 SSH 暴力破解掃描。
• 異常外部 IP 流量：將 Flow Logs 與已知公司 CIDR 清單 JOIN；任何 srcaddr 與 dstaddr 都不在你 VPC CIDR 或公司範圍內的流量，都值得懷疑。
• 僅出口濫用：找出 bytes_sent 遠大於 bytes_received、且連線至未知目的地 port 80/443 的 ENI——這是透過 HTTPS 外洩資料的經典特徵。

WAF 日誌查詢模式

WAF 日誌是 JSON 格式，儲存每個請求的豐富元資料，是應用層攻擊分析的金礦。實用查詢包括：

• 依規則統計阻擋請求：以 terminatingRuleId 分組計數並降序排列，可看出哪條受管或自訂規則做了最多攔截工作。
• 攻擊的地理分布：解析 httpRequest.country 欄位並依國家代碼分桶。來自你的業務未涉足的國家大量流量，是設定地理封鎖規則的候選對象。
• Bot 特徵：以 httpRequest.headers.User-Agent 分組，尋找空白 UA、腳本式 UA 與過時瀏覽器。

Glue Data Catalog 與 Partition Projection

Glue Data Catalog 是 Athena、EMR 與 Redshift Spectrum 共用的元資料層。在安全日誌分析中，你通常需要：

1. 建立一個 Glue 資料庫（例如 security_logs）。
2. 為每個日誌來源（cloudtrail、vpcflow、alb、cloudfront、waf、route53query）建立一個外部資料表，指向對應的 S3 前綴。
3. 使用 partition projection 而非 crawler 管理的分區；partition projection 從資料表屬性計算分區值，因此新的每日前綴可立即查詢，無需執行 crawler。
4. 使用 CTAS（CREATE TABLE AS SELECT）作業，將任何你頻繁查詢的日誌轉換為 Parquet。Parquet 通常能將掃描大小縮減 10 倍以上，並透過欄位下推，使 SELECT eventName 查詢只讀取 eventName 欄位。

CloudWatch Logs Insights 深度解析

CloudWatch Logs Insights 是疊加在 CloudWatch Logs 之上的查詢語言。它具有互動性、能在幾秒內返回結果，並按掃描資料量的 GB 數計費（比 CloudTrail Lake 便宜，但比 Parquet 上的 Athena 貴）。查詢語言有六個頂層指令你必須記住：fields、filter、stats、sort、limit 與 parse。

Logs Insights 中的常見安全查詢模式

• 登入失敗激增：對 SSH log group 執行 filter @message like /Failed password/ | stats count() by bin(5m)；尖峰會以直方圖的形式呈現。
• Lambda 錯誤率：fields @timestamp, @message | filter @type = "REPORT" and @message like /ERROR/ | stats count() by bin(1m)。
• 最常見錯誤代碼：fields @message | parse @message /errorCode=(?<code>[^,]+)/ | stats count() by code | sort count desc。
• 緩慢的 API 請求：filter @duration > 5000 | stats avg(@duration), max(@duration) by @logStream。

用 Parse 處理結構化日誌

parse 指令使用 glob 模式或正規表達式，將自由格式的日誌行轉換為具名欄位，之後就能對這些欄位使用 stats 與 filter。這是非結構化應用程式日誌與結構化分析之間的橋樑。如果你的應用程式原生就輸出 JSON，CloudWatch Logs 會自動將頂層 key 提取為以 @ 為前綴的欄位，這樣就能完全省略 parse。

CloudTrail Insights — 管理事件的異常偵測

CloudTrail Insights 不是查詢工具。它是你在 CloudTrail trail 上啟用的一項異常偵測功能，它會學習帳號中寫入管理事件的基線速率，然後將偏差作為 Insights 事件浮現出來。典型的 CloudTrail Insight 會顯示「RunInstances 呼叫速率在 14:00 到 15:00 UTC 之間超出基線 27 個標準差」——這正是當攻擊者使用竊取的憑證大量啟動加密貨幣挖礦執行個體時，你想要看到的訊號。

你必須知道兩個重要邊界：

1. CloudTrail Insights 只偵測寫入管理事件。它不分析資料事件（S3 GetObject、Lambda Invoke、DynamoDB GetItem）。如果情境詢問的是異常的資料事件速率，答案是 GuardDuty（S3 Protection）或自訂 CloudWatch 指標篩選器，而不是 CloudTrail Insights。
2. CloudTrail Insights 需要額外付費，按每 100,000 個分析的管理事件計費。你在每個 trail 和每種事件類型上分別啟用它。對於多帳號組織，請在日誌存檔帳號中的 org 層級 trail 上啟用它。

Security Hub Insights — ASFF 上的篩選視圖

Security Hub Insights 是已儲存的篩選器，能以所選屬性聚合發現項目（採用 AWS Security Finding Format，即 ASFF）。它們不是對原始日誌的查詢；它們是對已正規化發現項目的查詢。有兩種類型：

• AWS 受管 Insights：涵蓋常見模式的 100 多個預建 Insights。範例包括「擁有最多發現項目的 AWS 資源」、「具有公開讀取或公開寫入權限的 S3 bucket」、「有可疑活動的 IAM 使用者」以及「過去 90 天未輪替的存取金鑰」。
• 自訂 Insights：定義你自己對 ASFF 欄位（資源類型、嚴重性、標籤、工作流程狀態、合規狀態）的篩選器，並以某個屬性分組。常見的自訂 Insights 包括「生產帳號中依資源分組的所有 CRITICAL 發現項目」、「依負責團隊標籤分組的所有超過 30 天未解決的發現項目」，以及「PCI 標記的 bucket 上，依敏感資料類型分組的 Macie 發現項目」。

當考試題目詢問「如何建立一個持續更新的組織特定發現項目模式儀表板，而無需建置自訂基礎設施？」時，自訂 Insights 就是答案。它們按排程執行，並同時驅動 Security Hub 主控台與 EventBridge 規則。

Amazon Security Lake — OCSF 正規化資料湖

Security Lake 是 SCS-C02 日誌分析武器庫中最新且架構上最具代表意義的工具。它是一個受管服務，能夠：

1. 擷取來自原生 AWS 來源與第三方合作夥伴的日誌。
2. 正規化為 OCSF schema 1.x 版，每個 OCSF 事件類別對應一個 Parquet 資料表。
3. 儲存在客戶自有的 S3 bucket 中（Security Lake 建立 bucket，但你擁有資料），並設有彙總區域與生命週期政策。
4. 向訂閱者公開資料，訂閱者可透過 Athena、OpenSearch，或任何能理解 OCSF Parquet 的第三方 SIEM 進行查詢。

原生來源

Security Lake 在 GA 版本中支援以下第一等級的原生來源：

• AWS CloudTrail 管理事件、資料事件，以及 CloudTrail Lake 事件資料存儲。
• Amazon VPC Flow Logs。
• Amazon Route 53 Resolver 查詢日誌（DNS）。
• AWS Lambda 資料事件（透過 CloudTrail）。
• AWS Security Hub 發現項目（ASFF，映射至 OCSF Detection Finding 類別）。
• Amazon EKS 稽核日誌。

這些來源只需單鍵設定；Security Lake 處理分區配置、OCSF 映射與 Parquet 轉換，無需管理任何 Glue crawler。

自訂來源

你可以為任何第三方日誌格式登錄一個自訂來源。該來源必須產出符合 OCSF 規範的 Parquet（你負責映射工作），將其放入指定的 S3 前綴，Security Lake 會自動接收並公開給訂閱者。常見的自訂來源包括 Okta 日誌、Salesforce 稽核日誌、地端防火牆日誌，以及 Crowdstrike 或 SentinelOne 的 EDR 遙測資料。映射工作是主要成本，但一旦完成，每個訂閱者都能受益。

訂閱者模型

Security Lake 將生產者（來源）與消費者（訂閱者）分離。訂閱者有兩種類型：

• 查詢存取：訂閱者透過 Lake Formation 授權取得 S3 資料的讀取存取權，並可用自己的 Athena 工作群組直接查詢。最適合內部 SOC 團隊與資料科學家。
• 資料存取：當新的 Parquet 檔案落地時，訂閱者會收到 SQS 通知，並將資料拉入自己的 SIEM（Splunk、Sumo Logic、IBM QRadar 等）。最適合第三方 SIEM 整合。

日誌正規化、解析與關聯模式

正規化將異質的日誌格式統一為單一 schema，供分析師進行推理。解析從半結構化文字中提取結構化欄位。關聯則跨來源串連事件，建構出完整的事件經過。SCS-C02 期待你了解這三者的模式。

CloudTrail JSON 解析

CloudTrail 記錄是巢狀 JSON。你最常接觸的欄位是：

• eventTime（ISO-8601，UTC）。
• eventName（API 呼叫，例如 RunInstances）。
• eventSource（服務，例如 ec2.amazonaws.com）。
• userIdentity.type（IAMUser、AssumedRole、Root、AWSService）。
• userIdentity.arn 與 userIdentity.principalId。
• sourceIPAddress 與 userAgent。
• requestParameters 與 responseElements（呼叫特定的 payload，通常是最有鑑識價值的細節）。
• errorCode 與 errorMessage（只在失敗的呼叫中出現）。
• awsRegion。

在 Athena 中，一旦使用已發布的 CloudTrail Glue schema 定義了資料表，你就可以用點語法（userIdentity.arn）選取這些欄位。在 CloudWatch Logs Insights 中，頂層欄位會自動提取；巢狀欄位需要使用帶有正規表達式的 parse @message。

VPC Flow Log v5 欄位

預設的 v2 格式有 14 個欄位。v5 擴充格式新增了 pkt-srcaddr、pkt-dstaddr、region、az-id、tcp-flags、type（IPv4/IPv6）、flow-direction、traffic-path 與 sublocation-type 等欄位。兩個 pkt-* 欄位對於 Transit Gateway 和中間箱（middlebox）情境至關重要，因為它們顯示 NAT 或代理改寫之前的原始來源/目的地，而標準的 srcaddr/dstaddr 顯示的是 ENI 所看到的位址。

OCSF 統一分類法

OCSF 將每個事件映射到幾個事件類別之一，每個類別都有定義好的屬性集。對於 SCS-C02，相關的事件類別是：

• api_activity — 涵蓋 CloudTrail 及類似的 API 稽核事件。
• network_activity — 涵蓋 VPC Flow Logs 及類似的 L4 遙測資料。
• dns_activity — 涵蓋 Route 53 Resolver 查詢日誌。
• detection_finding — 涵蓋 Security Hub 發現項目（ASFF 映射至 OCSF）。
• file_activity — 用於物件存取事件（S3 資料事件）。

資料一旦進入 OCSF，分析師就可以執行像 SELECT * FROM amazon_security_lake_glue_db.amazon_security_lake_table_us_east_1_cloud_trail_mgmt_2_0 WHERE actor.user.name = 'alice' 這樣的查詢，並取得無論來源為何都一致的資料結構。

跨來源關聯

關聯是將五條日誌記錄串聯成一個故事的工作。經典模式：

• 入侵事件敘事：GuardDuty 發現項目（UnauthorizedAccess:IAMUser/MaliciousIPCaller）→ CloudTrail 顯示同一個主體從惡意 IP 呼叫 AssumeRole → VPC Flow Logs 顯示被承接角色的 Session 連往 C2 IP → S3 資料事件顯示同一個 Session 下載了敏感物件。Detective 服務會自動建構這張關係圖；Athena 可透過對時間視窗和主體 ID 進行 JOIN 來手動完成。
• 失敗後成功的登入：CloudWatch Logs Insights 中的 SSH 日誌顯示一個 IP 有 50 次 Failed password，幾分鐘後緊接著一次 Accepted password。若同一個人接著升級到 AWS 主控台，再與 CloudTrail 的 ConsoleLogin 事件 JOIN 比對。
• Bucket 暴露事件：Macie 敏感資料發現項目 → CloudTrail 顯示 PutBucketPolicy 將 bucket 設為公開 → Security Hub 聚合的發現項目嚴重性為 CRITICAL。

注重成本的日誌分析架構

日誌分析便宜，直到它變得不便宜。一個設計不良的 pipeline 可能每月燒掉五位數的費用，卻產出極少有用的結果。SCS-C02 期待你能辨識出注重成本的模式。

S3 生命週期轉移至 Glacier

90 天以上的日誌很少被互動式查詢，但必須為了合規（HIPAA、PCI、SOC 2 通常要求保留 1 至 7 年）而保存。模式如下：

• 第 0–30 天：S3 Standard，完整索引於 Glue，由 Athena 查詢。
• 第 30–90 天：S3 Standard-IA——相同的存取延遲，儲存成本減半。
• 第 90–365 天：S3 Glacier Instant Retrieval——毫秒級存取，適合偶發的 Athena 重新查詢。
• 第 365 天至 7 年：S3 Glacier Deep Archive——12 小時取回，成本最低。請提前規劃：Athena 無法直接讀取 Deep Archive。

Parquet 與分區管理

將原始 JSON 或文字轉換為 Parquet，通常能壓縮資料 5 至 10 倍，並使用謂詞下推，讓 Athena 只讀取你所選取的欄位。一個將昨天的 CloudTrail JSON 轉換為 Parquet 的排程 CTAS 查詢，幾分鐘即可完成，並在一週的分析師查詢後就能回收成本。以年、月、日（以及選擇性地加上帳號 ID 和區域）進行分區——但不要過度分區（每個資料表超過約 10,000 個分區會降低效能）。

Subscription Filter 到 Firehose 到 S3

CloudWatch Logs 在大規模保留時相對昂貴（每 GB 攝入 $0.50 加儲存費）。安全日誌保留的標準模式是：

1. 應用程式透過 CloudWatch agent 將日誌輸出至 CloudWatch Logs（即時追蹤與 Logs Insights）。
2. Subscription filter 將符合條件的事件發送至 Kinesis Data Firehose。
3. Firehose 緩衝、轉換為 Parquet（使用 Glue 資料表作為 schema），並寫入 S3。
4. CloudWatch 保留期設為 30 天；S3 保留期依合規需求設定。
5. Athena 查詢超過 30 天的 S3 存檔。

此模式讓 CloudWatch 成本與工作集成比例，同時允許在 S3 中進行無限制的保留。

Apache Iceberg 與現代資料湖模式

Athena 現在支援 Apache Iceberg 資料表，它在 S3 Parquet 之上新增了 ACID 交易、時間旅行、schema 演進與行級刪除功能。對於安全日誌分析，Iceberg 表示你可以：

• 更新豐富化欄位而無需重寫分區（例如攝入後回填 geo_country 欄位）。
• 時間旅行查詢過去某個時間點的資料表狀態，這對鑑識重現性非常有價值。
• 以交易方式將新資料 MERGE 至現有分區。

Security Lake 預設將其資料表儲存為與 Iceberg 相容的 Parquet 格式，CloudTrail Lake 也使用類似 Iceberg 的內部存儲。考試層面，請記住 Iceberg 是 S3 上安全資料湖的現代選擇，且它與 Athena、EMR 和 Glue 原生整合。請參閱 Athena Iceberg 文件。

OpenSearch Service 用於安全日誌搜尋

對於即時搜尋與預建儀表板（Kibana 風格），OpenSearch Service 是 Athena 的補充，而非替代品。常見的 SCS-C02 相關模式：

• GuardDuty 發現項目攝入：透過 EventBridge → Lambda → OpenSearch 串流發現項目，建立即時分類儀表板。
• VPC Flow Log 近即時串流：CloudWatch Logs 的 subscription filter → Firehose → OpenSearch，並透過索引生命週期將舊索引移至 UltraWarm 或 S3 上的冷儲存。
• 預建安全分析：OpenSearch Security Analytics 外掛隨附針對 CloudTrail、VPC 與主機日誌中常見攻擊技術的預建偵測規則（Sigma rule 格式）。

OpenSearch 在你需要子秒搜尋延遲、豐富儀表板與串流警示時勝出。Athena 在每 TB 成本、schema 彈性與多年保留上勝出。Security Lake 可同時餵給兩者。

威脅指標搜尋

威脅情報資訊流（商業版如 Recorded Future，或開放版如 AlienVault OTX）提供惡意 IP、域名、檔案 hash 與 TLS JA3 指紋的清單。日誌分析的挑戰在於大規模跨日誌搜尋這些指標。模式包括：

• S3 中的 IOC 資料表：維護一份每日更新的惡意 IP 及其威脅分數的 Parquet 資料表；與 VPC Flow Logs 在 Athena 中 JOIN，找出任何與已知惡意 IP 有流量往來的內部連線。
• GuardDuty 受管威脅情報：AWS 在幕後提供一份精選清單，你也可以為每個 detector 上傳自己的威脅情報集合與受信任 IP 清單。
• CloudWatch 指標篩選器比對 User-Agent：如果某個已知惡意工具具有獨特的 UA 字串，指標篩選器可在幾秒內產生警示，無需任何額外儲存成本。

端對端參考架構

適合中型組織的 SCS-C02 等級日誌分析架構通常如下：

1. Org 層級 CloudTrail（管理 + 資料事件，多區域）→ 日誌存檔帳號 S3，啟用 Object Lock + KMS CMK。
2. VPC Flow Logs v5（Parquet 格式）→ 日誌存檔帳號 S3。
3. Route 53 Resolver 查詢日誌 → 日誌存檔帳號 S3。
4. CloudFront、ALB、WAF 日誌 → 日誌存檔帳號 S3（分開前綴）。
5. 應用程式日誌透過 CloudWatch agent → CloudWatch Logs（30 天保留）→ subscription filter → Firehose → 日誌存檔 S3（長期保留）。
6. GuardDuty + Security Hub 在委派管理帳號中；發現項目透過 EventBridge → Firehose → S3 以 ASFF JSON 格式匯出。
7. Amazon Security Lake 原生訂閱 CloudTrail、VPC、Route 53、Security Hub，加上應用程式日誌的自訂來源；OCSF 正規化的 Parquet 存放在 rollup region S3。
8. Athena 工作群組設有按團隊的資料掃描限制；Glue Data Catalog 使用 partition projection；以 Iceberg 資料表建立豐富化/精選視圖。
9. OpenSearch Service 搭配 UltraWarm 層，用於過去 30 天的即時 SOC 儀表板。
10. Detective 用於實體關係調查；CloudTrail Lake 用於合規等級的不可變保留。

這個架構能清晰地對應大多數考試情境。當題目描述這些需求的某個子集時，識別出哪個層面受到影響。

SCS-C02 考試應試技巧

• 考試喜歡考服務邊界問題。請記住：CloudTrail Insights 只偵測管理事件的速率異常；GuardDuty 根據模式偵測威脅；Security Hub 聚合發現項目；Detective 調查關係；Athena 查詢 S3；Logs Insights 查詢 log group；Security Lake 正規化為 OCSF。
• 當題目提到**「長期保留」、「鑑識」或「低成本」加上「S3」**時，答案涉及 Athena。
• 當題目提到**「互動式」、「近期日誌」或「CloudWatch log group」**時，答案涉及 Logs Insights。
• 當題目提到**「第三方 SIEM」加上「正規化」加上「多帳號」**時，答案是 Security Lake 搭配資料存取訂閱者。
• 當題目提到**「異常 API 呼叫速率」**且沒有其他異常類型時，答案是 CloudTrail Insights。
• 當題目在 Security Hub 情境中提到**「已儲存視圖」、「發現項目模式」或「Insight」**時，答案是 Security Hub Insights。
• 留意**「自動」與「主控台」**這類干擾選項——根據社群智慧，它們常常是錯誤的。

常見問題

Q1. 我可以對另一個 AWS 帳號中 S3 日誌直接執行 Athena 查詢嗎？

可以。日誌存檔帳號的 bucket policy 必須授予 Athena 查詢帳號 s3:GetObject 與 s3:ListBucket（或使用 Lake Formation 跨帳號授權）。Glue Data Catalog 可以位於日誌存檔帳號中（透過 Lake Formation 共享），或複製到查詢帳號。大多數大型組織使用位於日誌存檔帳號中的單一 Glue Data Catalog，並透過 Lake Formation 授予跨帳號存取，額外享有行級與欄級安全性。

Q2. CloudTrail Insights 和 CloudTrail Lake 有什麼區別？

CloudTrail Insights 是疊加在一般 CloudTrail trail 上的異常偵測功能；當 API 呼叫速率偏離基線時，它會浮現事件，按每 100,000 個分析事件計費。CloudTrail Lake 是一個受管事件資料存儲，保留期最長 7 年，並提供對 CloudTrail 記錄的 SQL 查詢能力，按攝入 GB 與掃描 GB 計費。兩者是獨立的——你可以只有其中一個、兩個都有，或兩個都沒有。

Q3. 我應該使用 Security Lake，還是繼續對集中式 S3 日誌使用 Athena？

如果你的需求是單一來源（僅 CloudTrail）且單一團隊（你的內部 SOC），單獨使用 Athena 就夠了。當你有多個來源（CloudTrail + VPC + Route 53 + 第三方）、多個消費者（內部團隊 + 外部 SIEM + 資料科學家），並希望透過 schema 正規化讓每個消費者無需重新發明 parsing 時，Security Lake 才能帶來價值。OCSF 映射是殺手功能；如果你不需要它，Security Lake 就是額外的開銷。

Q4. 如何偵測 S3 中的異常資料事件（例如有人大量下載物件）？

CloudTrail Insights 不涵蓋資料事件。正確答案是 GuardDuty S3 Protection，它分析 CloudTrail 資料事件以偵測行為異常（Exfiltration:S3/AnomalousBehavior、UnauthorizedAccess:S3/MaliciousIPCaller）。對於自訂閾值，可在資料事件 log group 上建立 CloudWatch 指標篩選器，或執行排程的 Athena 查詢，統計每個主體每小時的 GetObject 呼叫次數，並在超過閾值時透過 SNS 發出警示。

Q5. 保留 7 年的 CloudTrail 日誌供偶發性稽核查詢，最便宜的方式是什麼？

使用 Compliance 模式的 S3 Object Lock + 生命週期：前 30 天使用 Standard，30–90 天使用 Standard-IA，90–365 天使用 Glacier Instant Retrieval，之後使用 Glacier Deep Archive。以 CTAS 作業將每日前綴轉換為 Parquet。Athena 無需特殊設定即可查詢 Standard、IA 與 Glacier Instant Retrieval。對於 Deep Archive，你必須先取回物件（12 小時以上），再進行查詢——對於罕見的稽核來說是可接受的。

Q6. 我可以用 CloudWatch Logs Insights 查詢已透過 subscription filter 移至 S3 的日誌嗎？

不行。Logs Insights 查詢的是 log group，而非 S3。一旦日誌進入 S3，就切換到 Athena。這是常見的考試陷阱：情境描述一個有 subscription filter 到 Firehose 到 S3 的 log group，並詢問如何查詢存檔——答案是 Athena，而非 Logs Insights。

Q7. Security Lake 中的 OCSF 如何處理不符合標準事件類別的廠商特定欄位？

OCSF 事件類別有一個 unmapped 屬性（一個 key-value 物件），廠商可以將無法映射到標準 schema 的欄位放在這裡。訂閱者可以在查詢中使用 unmapped['vendor_field_name'] 來參照這些欄位，但核心安全分析通常依賴標準屬性。在映射自訂來源時，優先確保標準屬性的正確性；將特殊欄位放入 unmapped，而不是強行塞入不合適的標準屬性。

Q8. Detective 在日誌分析中扮演什麼角色？

Amazon Detective 攝入 CloudTrail、VPC Flow Logs、GuardDuty 與 EKS 稽核日誌，並在過去一年中建構實體間關係的圖形（主體 → 角色 → IP → 資源 → 發現項目）。它不是查詢工具；它是一個調查 UI，能回答「告訴我所有與這個 GuardDuty 發現項目相關的內容」。Detective 是 Athena（臨機 SQL）的補充，透過視覺化方式互動呈現關係。在 SCS-C02 中，當題目問到「調查」、「根本原因」或「相關活動的圖形」時，Detective 就是答案。