CloudTrail、AWS Config 與運維儀表板

CloudTrail 與 AWS Config 審計儀表板構成了每個 DOP-C02 監控場景中的 合規與治理層。CloudWatch 監看指標，X-Ray 監看請求，而 CloudTrail 監看 API 調用（「誰在何時對哪個資源做了什麼」），Config 則監看 資源配置歷史（「這個資源在每個時間點看起來是什麼樣子」）。它們共同回答了審計員的問題、安全調查員的問題，以及 DevOps 工程師在發生意外停機後提出的「發生了什麼變化？」問題。DOP-C02 期望你能設計組織追蹤、使用 SQL 查詢 CloudTrail Lake、區分資料事件與管理事件、大規模構建 Config 規則與一致性套件 (conformance packs)、跨帳戶彙總 Config、與 Security Hub 整合、偵測 CloudFormation 漂移，並透過 EventBridge 和 SSM 自動化將這一切串聯成自動修正鏈。

本指南假設你已了解基礎 CloudTrail（記錄 API 調用）與基礎 Config（跟蹤資源配置）。本篇重點在於 DOP-C02 的實作深度：組織追蹤 vs 單帳戶追蹤、多區域追蹤設計、管理事件 vs 資料事件 vs Insights 事件及其定價影響、CloudTrail Lake 作為「發送到 S3 再用 Athena 查詢」模式的 SQL 查詢替代方案、用於對象級審計的 S3 資料事件、Config 規則（受管 vs 自定義）、用於範本化規則組合的 一致性套件、用於中央合規視圖的 多帳戶 Config 彙總器、用於 IaC 治理的 CloudFormation 漂移偵測、用於落地區 (landing-zone) 衛生的 Control Tower 漂移、整合 Security Hub 以實現統一發現結果、對追蹤與 Config 歷史進行 KMS 加密，以及用於執行報告的 QuickSight + Athena 儀表板模式。領域 4.2（審計、監控、分析）與領域 6.3（安全監控與審計）涵蓋了這些內容。

為什麼 CloudTrail 與 Config 審計儀表板在 DOP-C02 中很重要

DOP-C02 從結構上講是一個多領域考試。監控（15%）、事件回應（14%）以及安全與合規（17%）都共享相同的審計基礎。CloudTrail 與 Config 是出現在每個「誰改了什麼」問題、每個「此資源是否合規」問題以及每個自動修正鏈中的兩項服務。如果你誤讀了 CloudTrail vs Config 的題目，你可能會在多個領域丟分。

這裡的考試風格是 高壓下的服務辨析。多份社群學習報告將「CloudTrail vs Config vs Trusted Advisor vs GuardDuty vs Inspector」列為主要陷阱區。CloudTrail 告訴你 誰調用了 API。Config 告訴你 資源現在及歷史上的配置情況。它們不可互換。一個典型的 DOP-C02 題目如下：「審計員需要證明在過去 90 天內沒有任何 S3 儲存桶被設置為公共讀取。」錯誤選項會提供 GuardDuty（威脅偵測服務）或 CloudTrail Insights（API 速率異常偵測）。正確答案是 AWS Config 規則 s3-bucket-public-read-prohibited 配合存儲在 S3 中的 歷史配置紀錄 作為證明，並可選配跨帳戶彙總。

白話文解釋 CloudTrail 與 AWS Config 審計儀表板

由於四個 AWS 服務在功能上有重疊，審計與合規部分確實容易令人困惑。以下用三個類比來理清它們。

類比 1：銀行 —— 攝影機畫面、金庫清單、可疑活動報告

銀行運行著三種不同的審計系統。安全攝影機畫面 記錄了誰走進金庫、打開了哪個抽屜以及在什麼時間。這就是 CloudTrail —— 誰做了什麼 API 調用的持續記錄。金庫清單 每小時清點一次：每個保險箱的內容和鎖定狀態的快照。這就是 AWS Config —— 資源配置的時點快照。可疑活動報告 在偵測到異常模式時提交：櫃員在 5 分鐘內處理了 200 筆交易，或客戶提取了比平時更多的金額。這就是 CloudTrail Insights —— 對攝影機畫面的異常偵測。當審計員問「上週二凌晨 3 點有人動過 47 號抽屜嗎」，答案在攝影機畫面 (CloudTrail) 中。當審計員問「47 號抽屜在過去 90 天內是否曾沒鎖好」，答案在金庫清單歷史 (Config) 中。當審計員問「現在有什麼奇怪的事情發生嗎」，答案在可疑活動報告 (Insights) 中。DOP-C02 測試你能否針對每個問題選取正確的系統。

類比 2：建築工地 —— 日誌本、藍圖、檢查員清單

建築工地有一本 每日活動日誌本 (CloudTrail) —— 記錄了每位到場的承包商、簽收了什麼、領用了什麼工具。一套 竣工藍圖 (Config) —— 保持最新，記錄建築中實際存在的每一面牆、每一根管子和每一根電線。檢查員清單 (Config 規則與一致性套件) —— 每季度安全檢查員會巡視並勾選「逃生出口未受阻？灑水噴頭每 3 公尺安裝一個？出口指示燈亮著？」。當檢查員發現違規時，他們會貼上標籤（非合規的 Config 規則發現結果），工地主管必須進行修正。漂移偵測 是指有人在未更新藍圖的情況下挪動了一面牆 —— 這是未經授權的修改。多帳戶彙總器 是總公司對所有 50 個活動工地的總覽視圖。一致性套件 是總公司下發給每個工地的標準化檢查員清單（透過 CloudFormation StackSets 部署的 Config 一致性套件範本）。

類比 3：醫院 —— 醫療記錄、病歷表、JCAHO 審計

醫院保留每項操作的 醫療記錄 (CloudTrail)：施用了什麼藥物、執行了什麼程序、由哪位工作人員執行。病歷表 (Config) 記錄當前狀態 —— 體溫、生命徵象、過敏史、診斷。JCAHO 認證審計 是一項週期性評估：醫生洗手了嗎？病歷表是否在 4 小時內更新？管制藥品鎖好了嗎？每項標準都是一條 Config 規則。認證團隊的標準清單就是 一致性套件。當病患情況惡化時，醫療記錄 (CloudTrail) 會告訴你誰施用了什麼藥物。病歷表歷史 (Config 歷史) 會告訴你生命徵象何時開始異常。CloudFormation 漂移偵測 是醫院的審計，旨在捕獲有人在未經過正式更新程序的情況下修改了病歷表上的診斷 —— 這是一種帶外修改。

CloudTrail 追蹤解剖

追蹤 (trail) 捕獲以下三類事件：

管理事件 (Management events)

控制平面操作：CreateBucket、DeleteBucket、RunInstances、AssumeRole。每個帳戶的第一個追蹤免費 提供管理事件；額外的追蹤需付費。預設情況下，追蹤會捕獲唯讀 (Get*, List*, Describe*) 和僅寫事件；你可以進行過濾。

資料事件 (Data events)

資料平面操作：s3:GetObject、s3:PutObject、lambda:Invoke、dynamodb:GetItem。始終付費。預設關閉。資料事件量極大（一個 S3 儲存桶每天可能有數百萬次調用），因此請謹慎配置 —— 使用儲存桶前綴、函式名稱過濾器和資源 ARN 包含列表。

Insights 事件

對 管理 API 調用速率 和 錯誤率 的異常偵測。偵測 RunInstances、AssumeRole 等的異常激增。Insights 事件本身是收費的，且必須顯式啟用。適用於捕獲憑證洩漏（來自新委託人的 API 調用突然激增）。

追蹤目的地

追蹤可以傳送到 S3（必選）、CloudWatch Logs（選配，用於查詢和警示）以及 EventBridge（預設總線，對管理事件是自動的）。S3 儲存桶應具備：

• KMS 加密（用於合規的客戶受管金鑰）。
• 如果監管機構要求 WORM（一寫多讀），請使用帶有監管/合規保留的 S3 對象鎖定。
• 儲存桶政策應防止除破窗 (break-glass) 角色外的任何人刪除。
• 跨帳戶複寫到日誌封存帳戶。

組織追蹤 —— 一次配置，全組織適用

在管理帳戶中配置的 組織追蹤 會自動應用於每個成員帳戶，包括新加入的帳戶。這是「跨組織集中審計日誌」的正確答案。常見的 DOP-C02 陷阱：考生選擇「在每個帳戶中建立追蹤並透過 S3 複寫進行彙總」。錯誤 —— 請使用組織追蹤。

CloudTrail Lake —— 無需 Athena 的 SQL 查詢

CloudTrail Lake 是一個託管的 事件資料儲存區，CloudTrail 事件以結構化格式存儲，你可以直接透過 CloudTrail 控制台或 API 使用 SQL 查詢。當你想要減少維護組件時，它取代了「發送到 S3 再用 Athena 查詢」的模式。定價按擷取的事件量和掃描的資料量計算；保留期最長 7 年。Lake 還透過自定義整合接受 非 AWS 事件（例如第三方 SaaS 審計日誌）。

CloudTrail Insights

Insights 偵測管理事件中的 API 調用速率和錯誤率異常。常見發現：

• ConsoleLogin 失敗次數異常激增（潛在的暴力破解）。
• RunInstances 出現意外高峰（憑證洩漏導致的加密貨幣挖礦）。
• AssumeRole 失敗次數激增（自動化配置錯誤或遭受攻擊）。

Insights 發現結果會作為 CloudTrail Insights 事件發送到追蹤和 EventBridge，並可路由到 SNS、Lambda 或 Incident Manager。Insights 不涵蓋 資料事件。

AWS Config —— 持續配置記錄

Config 將資源配置記錄為一系列 配置項目 (configuration items, CIs)：對每個受支援資源（EC2, S3, IAM, RDS 等）的每次狀態變更。每個 CI 都是帶有變更時間戳的 JSON 快取。配置時間表讓你看到「週二 14:32 這個 S3 儲存桶長什麼樣」。

Config 規則

Config 規則評估資源的合規性。兩種類型：

• 受管規則: AWS 提供的約 250 條規則，涵蓋常見合規檢查 (s3-bucket-public-read-prohibited, iam-password-policy, restricted-ssh)。
• 自定義規則: 由 Lambda（你編寫的任何邏輯）或使用 AWS CloudFormation Guard 語言（宣告式，無需 Lambda）的 AWS Config 自定義政策 規則驅動。

觸發器可以是 配置變更（當資源變更時評估）或 定期（每 1、3、6、12 或 24 小時）。

一致性套件 (Conformance packs)

這是一個 YAML 範本，捆綁了多條規則和修正動作。範例：

• Operational-Best-Practices-for-PCI-DSS
• Operational-Best-Practices-for-HIPAA-Security
• Operational-Best-Practices-for-Amazon-S3

你可以透過 CloudFormation StackSets 或直接透過 Config 的組織部署 API 將一致性套件部署到多個帳戶。

多帳戶彙總器 (Multi-account aggregator)

彙總器將來自多個帳戶與區域的 Config 資料合併到中央帳戶，從而實現跨帳戶合規儀表板和搜尋。在審計/安全帳戶中設置一次；如果你使用 Organizations 整合，新成員帳戶可以自動加入。

自動修正 (Auto-remediation)

每個不合規的發現結果都可以觸發一個 SSM 自動化文件 進行修正。範例：

• 偵測到非公共 S3 儲存桶 → 運行 AWS-DisableS3BucketPublicReadWrite。
• 非加密 EBS 磁碟區 → 運行自定義文件進行快照並重新建置為加密磁碟區。
• 22 端口開放的公共安全組入站規則 → 運行 AWS-DisablePublicAccessForSecurityGroup。

修正可以是 自動 或 手動（需要人工批准）；按規則設定。

CloudFormation 漂移偵測

漂移偵測將 當前資源狀態 與 範本定義的狀態 進行對比，呈現差異。漂移發生在：

• 工程師對受管資源進行手動控制台變更。
• 另一個 IaC 工具修改了資源。
• Lambda 執行了更改資源配置的 SDK 調用。

漂移偵測是 按需執行 的 —— 它不會持續運行。你可以透過 EventBridge 排程器每週排程，或透過 Config 規則 (cloudformation-stack-drift-detection-check) 執行。偵測到漂移後，選項包括：

• 更新範本以匹配現狀（將漂移代碼化）。
• 手動修正資源。
• 刪除並從範本重新部署。

Control Tower 漂移

Control Tower 有其專屬的漂移概念，涵蓋落地區級別的變更：

• 移除了強制性護欄。
• 禁用了 CloudTrail 組織追蹤。
• 修改了共享服務帳戶。
• 在 Control Tower 之外建立了新 OU。

Control Tower 漂移會呈現在儀表板中，並作為 EventBridge 事件發出。修正透過 Reset (重設) 動作執行，以恢復護欄。

整合 Security Hub

Security Hub 彙總來自 Config、GuardDuty、Inspector、Macie、IAM Access Analyzer 以及合作夥伴（CrowdStrike, Palo Alto 等）的發現結果。它套用標準化嚴重性評分並支援以下 標準：

• AWS 基礎安全最佳實踐 (FSBP)
• CIS AWS Foundations Benchmark
• PCI DSS

標準在底層會轉換為一組 Config 規則；Security Hub 顯示統一的發現結果。考試會測試你是否知道 Security Hub 是 中央控制台，而非並行的偵測器 —— 它本身不產生發現結果，而是進行彙總。

Athena 與 QuickSight 儀表板

對於長期審計儀表板，標準模式為：

1. CloudTrail 日誌存放在 S3 中，並進行 Apache Parquet 轉換（透過 Firehose 或排程的 Glue ETL）。
2. 為 CloudTrail 日誌和 Config 快照建立 Glue Data Catalog 表。
3. 為常見問題建立 Athena 儲存的查詢（熱門 API 調用者、公共 S3 儲存桶、IAM 政策變更）。
4. QuickSight 儀表板從 Athena 讀取資料以供執行官視圖使用。

替代方案：使用帶有內置儀表板的 CloudTrail Lake，無需設置 Athena/Glue。

KMS 加密

CloudTrail 追蹤的 S3 目的地應使用 客戶受管 KMS 金鑰。金鑰政策必須允許 cloudtrail.amazonaws.com 進行加密，並允許審計帳戶委託人進行解密。Config 歷史儲存桶遵循相同模式。對於多帳戶設置，在審計帳戶中使用單個共享 KMS 金鑰可簡化跨帳戶解密。

高頻考試陷阱

陷阱 1：CloudTrail vs Config 混淆

CloudTrail = API 調用審計（誰、什麼、何時）。Config = 資源配置歷史（長什麼樣）。干擾項：「使用 CloudTrail 驗證不存在公共 S3 儲存桶」 —— 錯誤；那應該用 Config。

陷阱 2：資料事件預設關閉

S3 GetObject 和 Lambda Invoke 需要 顯式的資料事件配置。預設追蹤不捕獲它們。干擾項：「CloudTrail 預設記錄所有 S3 存取」 —— 錯誤。

陷阱 3：每個帳戶只有第一個管理事件追蹤免費

額外的追蹤或資料事件需付費。考試的成本優化題目會測試你是否知道預設追蹤涵蓋管理事件且不產生額外費用。

陷阱 4：成員帳戶無法修改組織追蹤

成員帳戶無法停用、刪除或修改組織追蹤。這是安全保證。干擾項：「成員帳戶管理員停用 CloudTrail」 —— 對於組織追蹤，他們做不到。

陷阱 5：Config 彙總器是區域性的

彙總器按區域整合。若要獲得全球單一面板視圖，請在每個區域複製彙總器或使用跨區域彙總功能。

陷阱 6：一致性套件在沒有權限的情況下無法自動修正

修正動作需要一個具備運行 SSM 文件權限的 IAM 角色。一致性套件必須引用現有角色，而非建立角色。

陷阱 7：CloudFormation 漂移是按需的，而非持續的

漂移偵測不會自動運行。干擾項：「當有人修改堆疊資源時，漂移偵測會立即提醒你」 —— 錯誤；你必須排程。

DOP-C02 考試模式與場景演練

場景 1：集中式多帳戶 API 審計日誌

題目：「組織中的 50 個帳戶需要集中式 API 審計。」 正確：在管理帳戶設置 組織追蹤，S3 存放在具備 KMS 的審計帳戶，審計帳戶中同樣設置 CloudTrail Lake 事件資料儲存區以進行 SQL 查詢。 錯誤：每個帳戶設置追蹤並透過 S3 複寫彙總。

場景 2：偵測全組織範圍內的公共 S3 儲存桶

題目：「審計員需要持續證明沒有 S3 儲存桶被設置為公共讀取。」 正確：透過 一致性套件（或直接）部署 Config 規則 s3-bucket-public-read-prohibited，並彙總到審計帳戶的 Config 彙總器。透過 SSM 自動化 AWS-DisableS3BucketPublicReadWrite 進行自動修正。

場景 3：調查可疑的資源變更

題目：「上週二某個 RDS DB 參數群組發生了意外變更。」 正確：在 CloudTrail Lake 中針對該資源和日期查詢 eventName="ModifyDBParameterGroup"；交叉比對 Config 配置歷史，查看參數值的變更前後對比。

場景 4：偵測來自受損憑證的異常 API 活動

題目：「偵測長期休眠的 IAM 存取金鑰突然進行數百次 RunInstances 調用的情況。」 正確：使用 CloudTrail Insights 標記管理 API 調用速率異常；將 Insights 事件路由到 EventBridge → SNS → 值班人員。

場景 5：由 IaC 管理的堆疊發生漂移

題目：「工程師偶爾透過控制台微調資源，破壞了 IaC 作為唯一事實來源的現狀。」 正確：透過 EventBridge 排程器每週排程 CloudFormation 漂移偵測；偵測到漂移後，EventBridge 規則路由到 Lambda，建立一個 OpsCenter OpsItem；工程師審查後選擇代碼化或恢復原狀。

FAQ

Q1：我何時應使用 CloudTrail Lake 而非在 CloudTrail S3 日誌上使用 Athena？

Lake 適用於低設置成本、快速 SQL 查詢、長達 7 年的無需生命週期管理的保留期，以及對非 AWS 事件的支援。Athena 適用於極大規模下的成本優化（掃描 S3 上的 Parquet 格式更便宜），或當你已經有基於 Athena 的資料湖需要整合時。

Q2：如何偵測「有人手動修改了 Lambda 函式」？

兩條路徑：CloudTrail 捕獲包含委託人的 UpdateFunctionConfiguration API 調用。Config 捕獲包含變更前後狀態的配置項目變更。結合使用 —— CloudTrail 查是誰，Config 查改了什麼。

Q3：我應該在每個 S3 儲存桶上都啟用 CloudTrail 資料事件嗎？

不應該 —— 資料事件量非常大且昂貴。僅針對敏感儲存桶（財務記錄、PII、審計日誌本身）啟用。使用帶有前綴過濾器的 AWS 受管 S3 進階資料事件 來限定特定鍵值。

Q4：一致性套件與 Security Hub 標準有什麼區別？

一致性套件 是可按帳戶或全組織部署的 Config 規則集（可帶修正）。Security Hub 標準 在底層轉換為 Config 規則，並在 Security Hub 控制台中以標準化嚴重性呈現結果。它們有重疊；許多團隊兩者都啟用。

Q5：我可以完全防止 CloudFormation 漂移嗎？

在缺乏流程紀律的情況下無法完全防止。分層控制：SCP 拒絕生產帳戶的控制台寫入、偵測漂移的 Config 規則、每週排程的 CloudFormation 漂移偵測、限制哪些 IAM 角色能在 CloudFormation 之外修改資源的 服務控制政策。考試希望你知道在 API 層級無法針對所有變更進行強制硬性預防；偵測 + 修正才是現實的答案。

Q6：如何為合規性保留 CloudTrail 日誌 7 年？

S3 生命週期轉換到 Glacier Flexible Retrieval 或 Deep Archive。合規模式下的對象鎖定以防止刪除。或者使用原生支持長達 7 年保留的 CloudTrail Lake。

Q7：Control Tower 漂移與 CloudFormation 漂移有什麼區別？

Control Tower 漂移 發生在 落地區 層級 —— 移除強制性護欄、停用組織追蹤、修改受管 OU 與帳戶。CloudFormation 漂移 發生在 堆疊 層級 —— 個別資源的修改。兩者都透過 EventBridge 呈現以進行自動化。

交叉引用

• CloudWatch 指標與 Logs Insights 透過基於指標的警示與日誌查詢對 CloudTrail 進行補充；參見 cloudwatch-metrics-logs-insights。
• CloudWatch 警示與 EventBridge 接收 CloudTrail 與 Config 事件進行路由；參見 cloudwatch-alarms-eventbridge-integration。
• EventBridge 自動修正執行手冊 深入介紹了 Config + SSM 自動化修正鏈；參見 eventbridge-auto-remediation-runbooks。
• Incident Manager 與 AWS Health 接收 CloudTrail Insights 事件以觸發回應計畫；參見 systems-manager-incident-manager-health。
• 部署失敗疑難排解 使用 CloudTrail 識別導致失敗的部署 API 調用；參見 deployment-failure-troubleshooting。