CloudTrail 與 AWS Config 稽核合規

稽核與合規操作是 SysOps 工程師的核心職責，在 SOA-C02 考試中明確歸屬於 Domain 1（監控、日誌與補救）。當監理機關、稽核人員或資安長詢問「是誰在 02:14 UTC 刪除了正式環境的 S3 bucket？」或「請證明過去 90 天內所有 RDS 執行個體持續啟用了靜態加密」，SysOps 工程師必須提出證據——而這些證據恰好來自兩個服務：AWS CloudTrail 與 AWS Config。CloudTrail 回答的是「誰在何時執行了哪個 API 呼叫」；AWS Config 回答的是「這個資源在任意時間點的組態設定為何」。兩者共同構成「AWS 稽核的兩組監控鏡頭」——一組拍攝 API 層面，一組拍攝資源設定層面——SOA-C02 Domain 1.1 幾乎所有稽核與合規題目都依賴於了解何時應把哪組鏡頭對準場景。

本指南從 SysOps 角度涵蓋 CloudTrail 與 AWS Config：management events 與 data events 與 Insights events 的差異、單一 region 與多 region 與 organization trails 的選擇、使用 SHA-256 digest files 進行 log file integrity validation、將 API 事件轉發至 CloudWatch Logs 以進行即時告警、AWS Config 持續設定錄製、configuration timeline 與 resource relationships 圖、AWS 受管 Config rules 與自訂 Lambda-backed rules、CIS/NIST/PCI-DSS 的 conformance packs、多帳號多 region 的 aggregators、透過 Systems Manager Automation runbooks 進行 auto-remediation，以及 SOA-C02 反覆出現的場景——CloudTrail 偵測出「誰做了什麼」，Config rules 驅動「如何修正」。SAA-C03 考的是「架構上要選哪個稽核服務」，SOA-C02 考的則是「如何正確設定 trail 的 S3 bucket policy」、「如何在不讓帳單爆炸的前提下啟用 data events」，以及「如何為 Config rule 搭配具備正確 remediation IAM role 的 SSM Automation document」。

為什麼稽核與合規在 SOA-C02 屬於 Domain 1

官方 SOA-C02 Exam Guide v2.3 將 CloudTrail 與 AWS Config 列於 Task Statement 1.1「使用 AWS 監控與日誌服務實作 metrics、alarms 與 filters」之下，與 CloudWatch Metrics 和 CloudWatch Logs 並列。這樣的配對是刻意設計的：CloudWatch 是日常運維的「監控表面」，而 CloudTrail 和 Config 是稽核與事後調查的「證據表面」。Task Statement 4.1 則再次將同樣的服務拉回資安疑難排解（「透過 AWS 服務稽核與疑難排解存取問題——例如 CloudTrail、IAM Access Analyzer、IAM policy simulator」），這意味著整場考試大約有 8 到 10 道題目會觸及 CloudTrail、AWS Config，或兩者兼有。

在 SysOps 層級，題目框架是運維操作，而非架構設計。SAA-C03 問「哪個服務記錄了誰刪除了 S3 物件？」SOA-C02 問「S3 bucket 在 02:00 UTC 變為公開；CloudTrail trail 設定為僅記錄 management events，data event opt-in 是關閉的；SysOps 團隊能找出翻轉 bucket policy 的那個 API 呼叫嗎？」正確回答需要了解 bucket policy 變更是 management event（預設記錄），而 bucket 物件層級的 GET/PUT/DELETE 呼叫是 data event（必須 opt-in）。考試嘉獎能夠釐清哪類事件屬於哪種場景、各自的保留期限，以及下游管道（CloudWatch Logs Insights、S3 上的 Athena、Security Hub、EventBridge）的正確工具選擇的考生。CloudTrail 與 AWS Config 也直接串聯至 Domain 3（透過 Config rules → EventBridge → SSM Automation 自動補救）、Domain 4（由 Config rules 與 conformance packs 強制執行的合規護欄）以及 Domain 5（記錄 VPC 與網路變更），因此掌握這兩個服務在整場考試中都能發揮效益。

白話文解釋 CloudTrail and AWS Config

CloudTrail 與 AWS Config 之間的心智邊界，是 Domain 1 最難釐清的區分點。三個類比能讓這條邊界深植記憶。

類比一：便利商店的監控攝影機 vs 庫存盤點表

想像一家 24 小時便利商店。CloudTrail 是店內的監控攝影機系統，拍下每一位店員在收銀台的每個動作——每一筆結帳、每一次退貨、每一張發票開立，畫面顯示「誰」站在哪台收銀機前、「做了什麼操作」、「什麼時間」、「從哪個 IP/班次」。AWS Config 是倉庫的商品庫存盤點表，記錄每個貨架上商品的狀態——不是交易本身，而是每個時間點每樣商品的「存量與設定」。如果貨架上的泡麵突然不見，你查攝影機（CloudTrail）找出是誰拿走的；如果需要向廠商證明「這款商品在過去 90 天始終擺在冷藏區且溫度正常」，你查庫存盤點表（Config）。攝影機記錄「動作」；盤點表記錄「狀態」。真實的稽核通常兩者都需要——先由盤點表發現問題，再由攝影機揪出是誰做的。

類比二：醫院的醫囑本 vs 病歷表

在醫院裡，CloudTrail 是醫師的醫囑本——每張處方、每個檢查單、每項手術核准，都有醫師簽名、時間與原因。AWS Config 是病歷表——持續記錄病患任意時間點的生命徵象、診斷、目前用藥與過敏清單。如果病患突然用錯藥（S3 bucket 突然變為公開），你翻醫囑本（CloudTrail）找是哪位醫師寫了那張醫囑。如果需要證明「這位病患從第 1 天到第 14 天持續使用抗生素」（加密全程啟用），你看病歷表（Config）。CloudTrail = 醫囑與動作；Config = 病歷與狀態。Config 的 Auto-remediation 就像醫院的標準作業協議——一旦病歷顯示過敏病患被開了盤尼西林，自動停藥並呼叫主治醫師。

類比三：大樓門禁系統 — 門卡刷卡記錄 vs 樓層平面圖快照

想像一棟辦公大樓的保全系統。CloudTrail 是門禁刷卡記錄——每一次感應進出、每一次電梯按樓層、每一道門的開關，都歸屬於特定的員工識別證。AWS Config 是定期歸檔的樓層平面圖快照——每當有人移動辦公桌、重新隔間或拆除一扇門，就會在樓管系統中存入一份新的平面圖，且系統保留所有歷史版本。Config rules 是定期巡邏的建築法規檢查員——「每間機房都必須有上鎖的門」（s3-bucket-public-read-prohibited）；「消防逃生口不得堵塞」（vpc-default-security-group-closed）。Conformance packs 是 CIS/NIST 稽核包——一份預建的 50 項檢查清單，讓檢查員一次掃完。Auto-remediation 是大樓在檢查員發現門未上鎖的瞬間自動鎖門——SSM Automation document 就是被自動派遣的鎖匠。

CloudTrail Event Types：Management、Data 與 Insights

CloudTrail 記錄三種不同的事件類別，SOA-C02 考試持續測試這三者之間的邊界。

Management events — 控制層面

Management event 是影響 AWS 資源設定的 API 呼叫：RunInstances、CreateBucket、PutBucketPolicy、AttachRolePolicy、DeleteVolume、UpdateFunctionConfiguration、CreateUser、ConsoleLogin、AssumeRole。Management events 的特性：

• 每個 trail 都免費記錄（讀取事件與寫入事件可分別切換）。
• 90 天內可在 CloudTrail Event History 免費查看——即使沒有明確建立 trail，主控台也預設提供這個介面。
• 新建立的 trail 預設記錄 management events。

90 天的 Event History 可在主控台免費搜尋，但僅涵蓋當前帳號、當前 region，且只有 management events。如需跨帳號、跨 region 或更長的保留期限，必須建立 trail 並傳送至 S3。

Data events — 資料層面

Data event 是高流量的資料層面 API 呼叫：S3 GetObject / PutObject / DeleteObject、Lambda Invoke、DynamoDB 項目層級讀寫、EBS 直接 API 存取。Data events 的特性：

• 所有 trail 預設關閉——必須依資源類型明確 opt-in。
• 按事件計費，費率雖小但不可忽視。流量大的 S3 bucket 每天可產生數億次 GET 請求，該 bucket 的 data events 費用可能遠超其餘 CloudTrail 帳單。
• 可使用advanced event selectors按 ARN 前綴、事件名稱或 readOnly 屬性精確過濾範圍——例如「只記錄 arn:aws:s3:::sensitive-bucket/* 的 S3 PutObject 與 DeleteObject，排除 GET」。

在需要稽核「誰讀取或寫入了特定物件」的場景中，data events 是必要條件——若未啟用，trail 根本不會記錄這些呼叫。

Insights events — 寫入 API 的異常偵測

CloudTrail Insights 是付費功能，持續分析寫入 management API 呼叫的速率，當速率偏離學習基準超過閾值時產生 Insights event。範例：

• AttachRolePolicy 呼叫突然激增——可能是權限提升攻擊。
• RunInstances 呼叫瞬間爆量——可能是加密貨幣挖礦入侵。
• PutObject 速率異常下降——可能是應用程式故障。

Insights events 記錄在目的地 S3 bucket 的獨立資料夾中，並在主控台的「CloudTrail Insights」頁面呈現。需額外付費，通常只在涵蓋正式環境帳號的 management trails 上啟用。

CloudTrail Trail 設定：單一 Region、全 Region 與 Organization Trails

CloudTrail 提供三種 trail 範圍，這三者之間的運維選擇是 SOA-C02 的常見考點。

單一 region trail

單一 region trail 只記錄特定 region 的事件。除非是小眾場景，否則很少是正確答案，原因如下：

• 全域服務事件（IAM、STS、CloudFront、Route 53）只會記錄在 us-east-1，且只有設定為全域服務 region 的 trail 才能捕捉。
• 大多數工作負載橫跨至少一個 region，缺乏 region 覆蓋就等於留下稽核盲區。

全 region（多 region）trail

全 region trail 是運維預設值。一個 trail 設定涵蓋所有現有 region 以及日後自動新增的 region，也能捕捉全域服務事件。SOA-C02 運維最佳實踐：

• 除非有特定合規或成本原因，否則一律使用全 region trail。
• 啟用 log file integrity validation，讓竄改行為可被偵測。
• 傳送至專屬且鎖定的 S3 bucket，bucket policy 授予 cloudtrail.amazonaws.com 寫入權限，並拒絕所有人刪除。

Organization trail

Organization trail 從 AWS Organizations 的管理帳號或委派管理員帳號建立，自動涵蓋組織中每個成員帳號——包括日後加入的新帳號。關鍵特性：

• 一個 trail 涵蓋每個帳號、每個 region。
• 日誌集中存放於單一 S3 bucket（通常位於專屬日誌帳號）。
• 成員帳號無法停用、刪除或修改 organization trail——管理帳號或委派管理員才有控制權。
• 成員帳號管理員若有額外需求（例如本地化日誌操作），仍可建立自己的 trail（organization trail 不排除帳號本地 trail）。

這是 SOA-C02 對任何「跨帳號集中稽核日誌」場景的標準答案。手動部署並管理 200 個獨立帳號 trail 是錯誤答案。

Trail 目的地

Trail 一律傳送至 S3。此外可選擇同時傳送至：

• CloudWatch Logs — 透過 metric filters 與 Logs Insights 查詢進行即時告警。
• Amazon EventBridge — 每個 CloudTrail 事件自動作為 aws.<service> 事件出現在預設 event bus，不論 trail 設定為何。事件傳送至 EventBridge 基本上免費且即時。

Log File Integrity Validation：Digest Files 與 SHA-256 雜湊

未啟用 integrity validation 的 trail 等於讓攻擊者有機可乘——刪除日誌、竄改內容或替換檔案。Log file integrity validation 是 CloudTrail 的內建防竄改功能。

運作原理

啟用 integrity validation 後，CloudTrail 每小時產生一份 digest file，其中包含：

• 前一小時內每個已傳送日誌檔的 SHA-256 雜湊值。
• 前一份 digest file 的 SHA-256 雜湊值，形成雜湊鏈。
• 使用 CloudTrail 私有 RSA private key 簽章；驗證時從 CloudTrail 公鑰端點取得對應公鑰。

Digest files 存放於 S3 bucket 的同層資料夾（AWSLogs/<account>/CloudTrail-Digest/<region>/...）。

驗證日誌

AWS CLI 指令 aws cloudtrail validate-logs --trail-arn ... --start-time ... --end-time ... 會逐一走過 digest 鏈、重新計算雜湊，並回報以下任何一種狀況：

• 日誌檔案遺失。
• 日誌檔案的雜湊值與記錄的雜湊值不符（遭竄改）。
• Digest file 被刪除（鏈中出現缺口）。
• 簽章與 CloudTrail 公鑰不符（偽造）。

任何上述發現都是啟動事件回應的依據——完整性保證已被破壞。

CloudTrail 傳送至 CloudWatch Logs：API 事件的即時告警

CloudTrail 的 S3 目的地用於封存與鑑識查詢。若要對關鍵 API 事件即時告警，trail 還必須傳送至 CloudWatch Logs。這個模式是 SOA-C02 針對「root 使用者登入時告警」或「安全群組被改為 0.0.0.0/0 時告警」的標準答案。

設定方式

在 trail 設定中啟用 CloudWatch Logs 傳送，選擇或建立一個 log group。CloudTrail 會建立一個 IAM role（CloudTrail_CloudWatchLogs_Role），授予對所選 log group 的 logs:CreateLogStream 與 logs:PutLogEvents 權限。

高價值事件的 metric filters

一旦事件串流進入 CloudWatch Logs，就可建立 metric filters 來比對高價值 API 事件的 JSON 模式，並遞增自訂 CloudWatch metric，再對該 metric 設定 alarm。

範例：

• Root 帳號主控台登入：filter pattern { ($.userIdentity.type = "Root") && ($.eventName = "ConsoleLogin") } → 遞增 metric RootLoginCount → threshold ≥ 1 時觸發 alarm。
• Security group 修改：filter pattern { ($.eventSource = "ec2.amazonaws.com") && ($.eventName = "AuthorizeSecurityGroupIngress") } → metric → alarm。
• CloudTrail trail 被停用：比對 StopLogging 或 DeleteTrail 的 filter pattern → metric → alarm — 立即傳呼資安團隊，因為有人試圖讓稽核失效。
• IAM policy 變更：AttachUserPolicy、PutUserPolicy、CreatePolicy 等。

替代方案：EventBridge rules

等效但更靈活的做法是在預設 event bus 上建立 EventBridge rule，比對同樣的 JSON 模式，並直接路由至 SNS、Lambda 或 SSM Automation。EventBridge 愈來愈成為 SOA-C02 偏好的路徑，因為它可以組合下游自動化，並支援跨帳號 event bus 以集中資安操作。

CloudTrail Lake — 可查詢的事件儲存庫

CloudTrail Lake 是受管的可查詢事件儲存庫，可保存 CloudTrail 事件長達 7 年（預設 7 年；可設定從 7 天到 3,650 天 / 10 年的延伸保留期），並提供 SQL 查詢介面。對於需要一站式稽核查詢介面的合規團隊，這是「trail 傳至 S3 + Athena 查詢」的替代方案。

主要運維特性：

• Event data store 是設定單元；可設定為帳號範圍或組織範圍。
• SQL 查詢語言，熟悉 Athena 的人上手無門檻。
• Federated query 讓你可以同時查詢事件資料與其他 AWS 資料來源。
• 依每 GB 攝入計費；預設 7 年保留期的儲存費用已含在攝入費用中，延伸保留期另外計費。

在 SOA-C02 的典型場景中，「稽核人員需要能用 SQL 查詢五年前 API 呼叫的介面」——CloudTrail Lake 是答案。「將日誌存至低成本 S3 存檔並偶爾用 Athena 查詢」——一般 trail 搭配 lifecycle policy 是答案。

AWS Config：持續設定錄製

AWS Config 持續記錄你帳號中受支援 AWS 資源的設定，並儲存每次變更的歷史記錄。它是 CloudTrail 記錄「API 動作」的對應物——專注於「資源狀態」。

Config 記錄的內容

對每個受支援的資源類型（S3 buckets、EC2 instances、security groups、IAM roles、RDS instances、VPCs 及數百種其他類型），每當資源發生變更，Config 就產生一份 configuration item (CI)。CI 包含：

• 資源 metadata — ARN、類型、region、帳號、建立時間、tags。
• Configuration — 描述當前狀態的 JSON（加密設定、公開存取封鎖、security group rules 等）。
• Relationships — 連結至其他資源（security group 的 CI 參照 VPC 以及使用它的 ENIs）。
• Related events — 觸發此變更的 CloudTrail event IDs。
• Compliance state — 對每個評估此資源的 Config rule，狀態為 COMPLIANT、NON_COMPLIANT、NOT_APPLICABLE 或 INSUFFICIENT_DATA。

Configuration timeline

在 Config 主控台中，每個資源都有一條 configuration timeline——每份 CI 的時間序列視覺化呈現。點擊任意時間點即可看到當時的完整設定、與前一份 CI 的差異，以及連結的 CloudTrail event(s)。這是 SOA-C02 回答「給我看這個資源 30 天前的樣子」或「提供加密持續啟用的證據」的標準答案。

Resource relationships 圖

Configuration item 同時捕捉 relationships：EC2 instance CI 連結至它的 security groups、subnets、EBS volumes、IAM instance profile 與 ENIs；RDS DB instance CI 連結至它的 DB subnet group、security groups、parameter group 與 option group。這些關係可在主控台查詢，也可透過 Config Advanced Query SQL 介面查詢——例如「列出所有使用 security group sg-xxx 的 EC2 instances」或「找出 subnet-yyy 中的每個資源」。

設定錄製

Config 錄製依 region opt-in：你建立一個 configuration recorder，指定要記錄的資源類型以及快照傳送目的地。Recorder 的輸出包括：

• 每 6 小時（或可設定週期）傳送至 S3 的 Configuration history 檔案。
• 依需求或排程產生的 Configuration snapshots。
• 傳送至 SNS 或 Config rule 消費的 Configuration change notifications。

Config 支援所有受支援的資源類型（預設）或當成本是考量時的精選清單。記錄所有資源是 SOA-C02 合規姿態的預設值；選擇性錄製用於只有少數資源類型重要的成本最佳化場景。

Config Rules：AWS 受管 vs 自訂 Lambda-Backed

Config rule 是產生合規狀態的評估單元。Config 在 configuration item 變更時（組態變更觸發規則）或按排程（周期規則）評估 rules，並將 COMPLIANT / NON_COMPLIANT 寫回資源的 CI。

AWS 受管 rules

AWS 發布了數百條涵蓋常見合規檢查的受管 rules。直接出現在 SOA-C02 的範例：

• s3-bucket-public-read-prohibited — 任何 S3 bucket 允許公開讀取即失敗。
• s3-bucket-public-write-prohibited — 任何 S3 bucket 允許公開寫入即失敗。
• s3-bucket-server-side-encryption-enabled — 未設定 SSE 即失敗。
• encrypted-volumes — 任何 EBS volume 未加密即失敗。
• rds-storage-encrypted — 任何 RDS DB instance 缺乏加密即失敗。
• ec2-instance-no-public-ip — 任何 EC2 instance 有公開 IP 即失敗。
• restricted-ssh — 任何 security group 在 port 22 允許 0.0.0.0/0 即失敗。
• iam-password-policy — 帳號密碼政策不符條件即失敗。
• cloudtrail-enabled — 沒有 CloudTrail trail 在記錄即失敗。
• vpc-flow-logs-enabled — 任何 VPC 缺乏 flow logs 即失敗。

每條受管 rule 都有可調整的參數（例如 iam-password-policy 接受 MinimumPasswordLength、RequireUppercaseCharacters 等）。

自訂 rules — Lambda-backed

當沒有受管 rule 符合需求時，以 AWS Lambda function 撰寫自訂 rule。Config 以 configuration item 呼叫 Lambda；Lambda 檢查後回傳 COMPLIANT、NON_COMPLIANT 或 NOT_APPLICABLE。自訂 rules 適用於組織特定的合規檢查（例如「每個 EC2 instance 必須有來自核准財務清單的 CostCenter tag」）。

自訂 rules — CloudFormation Guard

較新的替代方案是以 CloudFormation Guard policy-as-code 規則——宣告式 DSL 用於合規檢查。彈性不如 Lambda，但免去維護程式碼的負擔。

Rule 觸發類型

兩種觸發模式：

• Configuration changes — 相關 CI 變更時 rule 立即評估。最適合「必須在任意時間點成立」的檢查。
• Periodic — 無論 CI 是否變更，每 1、3、6、12 或 24 小時評估一次。最適合需要綜觀多個資源的檢查（例如「至少一個 CloudTrail trail 必須存在」）或需要捕捉緩慢漂移的場景。

部分受管 rules 支援兩種模式；部分只支援其中一種。選錯觸發類型是 SOA-C02 的常見陷阱。

Conformance Packs：預建合規套件

Conformance pack 是 Config rules 與 remediation actions 的打包集合，以 YAML 範本定義，可一次 API 呼叫部署至單一帳號或整個組織。

AWS 提供的範例套件

AWS 發布了對齊常見框架的 conformance packs：

• CIS AWS Foundations Benchmark v1.2 / v1.3 / v1.4
• NIST 800-53 rev 4 / rev 5
• PCI DSS v3.2.1
• HIPAA Security
• AWS Operational Best Practices for Amazon S3 / EC2 / RDS / IAM 等
• SOC 2、FedRAMP Moderate、ISO 27001

每個 pack 都是 YAML；可直接部署、刪除不適用的 rules，或加入自訂 rules 擴充。

部署範圍

• 單一帳號、單一 region：標準 conformance pack。
• 組織範圍：organization conformance pack，從管理帳號或委派管理員部署；自動涵蓋現有及新加入的成員帳號。

輸出

Conformance pack 在 Config 主控台提供一個合規 dashboard，顯示每個 pack 的資源合規百分比、違規 rules 與違規資源。合規長喜歡它，因為一個畫面取代了三十個 Config rule 狀態頁面。

AWS Config Auto-Remediation 與 SSM Automation

Config 控制層面是偵測。Auto-remediation 是關閉回路的動作——當資源被判定為 NON_COMPLIANT 時，SSM Automation document 執行以恢復合規。

設定機制

每條 Config rule 都可附加一個 remediation action，動作指定：

• SSM Automation document — AWS 受管（例如 AWS-DisablePublicAccessForS3Bucket）或自訂（你自己的 document）。
• Parameters — 資源 ID 通常自動注入；其他參數可寫死或從 rule 取得。
• IAM role — automation assumes role，必須具備呼叫修正 API 所需的權限。這個 role 是最常見的靜默失敗點——缺乏 s3:PutBucketPolicy（或 document 所需的任何其他權限）時，remediation 會失敗而資源持續不合規。
• Mode — Automatic（NON_COMPLIANT 時立即執行）或 Manual（操作員在主控台點擊「Remediate」）。
• Maximum attempts 與 retry intervals — 有界限的重試行為。

常見的 AWS 受管 remediation documents

• AWS-DisablePublicAccessForS3Bucket — 與 s3-bucket-public-read-prohibited 配對。
• AWS-EnableS3BucketEncryption — 與 s3-bucket-server-side-encryption-enabled 配對。
• AWS-DetachVPCInternetGateway — 與 VPC 隔離 rules 配對。
• AWS-EnableCloudTrail — 與 cloudtrail-enabled 配對。
• AWS-AddTagsToResource — 與自訂 tag policy rules 配對。

Auto-remediation 不適合的情境

當「不合規」狀態可能是刻意為之時，auto-remediation 是危險的。s3-bucket-public-read-prohibited rule 若自動修正一個刻意對外公開的靜態網站 bucket，會造成正式環境中斷。SOA-C02 的正確姿態：只對合規判斷明確無歧義的 rules（加密、tagging）啟用 auto-remediation，對需要人工確認的 rules（公開存取、security group rules）使用 Manual 模式。

Config Aggregator：多帳號多 Region 視圖

Config aggregator 是獨立的 Config 功能，將多個帳號與 region 的設定與合規資料彙集至單一視圖。

Aggregator 類型

• Organization aggregator：在管理帳號或委派管理員帳號建立；自動從指定 region 的每個成員帳號拉取資料。新加入組織的帳號自動納入。
• Account aggregator：在任意帳號建立，搭配精選的來源帳號與來源 region 清單；每個來源帳號必須授權 aggregator 帳號存取。

Aggregator 提供的能力

• 彙整合規 dashboard — 在單一視圖中查看所有 rules、所有帳號、所有 regions。
• 彙整資源清單 — 以單一 SQL Advanced Query 查詢每個帳號與 region。
• 彙整 conformance pack 狀態 — 整個組織的每個 pack 合規百分比。

運維注意事項

• Aggregator 只讀取——它無法驅動跨帳號的 auto-remediation。Remediation 必須在資源所在的來源帳號中執行。
• 彙整不產生額外的 Config 費用——你只需為每個來源帳號的底層 CIs 付費。
• 對於跨帳號 auto-remediation，模式是 EventBridge 跨帳號 event bus + 資源帳號中的 SSM Automation；aggregator 僅用於可見性。

Config vs CloudTrail：你必須記住的邊界

這條邊界是 SOA-C02 稽核/合規最常考的差異點。

心智捷徑：API 動作（動詞）→ CloudTrail。資源狀態（名詞）→ Config。 當題目同時混合兩者（「bucket 被變為公開，誰做的？AND 證明它持續維持私有」），答案是兩者都用——CloudTrail 找出「誰」，Config rule 提供「證明 + 自動還原」。

場景模式：S3 Bucket 被設為公開——誰做的？如何預防再次發生？

這是 SOA-C02 的典型雙服務場景。執行步驟：

1. 找出是誰做的（CloudTrail）。對 bucket policy 或 ACL 的變更是 management event（PutBucketPolicy、PutBucketAcl、DeletePublicAccessBlock），預設免費記錄在 90 天 Event History 或 trail 的 S3 目的地中。依 eventName = PutBucketPolicy 與 requestParameters.bucketName = sensitive-bucket 搜尋。userIdentity 區塊記錄了發出呼叫的 IAM user、role 或假冒 role 的 session。sourceIPAddress、userAgent 與請求參數補全了鑑識記錄。
2. 主動偵測未來發生（Config rule）。部署 s3-bucket-public-read-prohibited（或 s3-bucket-public-write-prohibited，或兩者）。以 configuration-changes 觸發設定 rule，讓 Config 在任何 bucket 公開存取狀態一有變更時立即評估。
3. 自動還原（SSM Automation）。附加 AWS 受管的 AWS-DisablePublicAccessForS3Bucket document 作為 remediation action，設定為 Automatic 模式。為 assume-role 配置 s3:PutBucketPublicAccessBlock 與 s3:PutBucketPolicy 權限。rule + document 的組合可在變更發生後數分鐘內將公開 bucket 還原為私有。
4. 告警（EventBridge）。新增 EventBridge rule，監聽此 rule 的 Config Rules Compliance Change 事件，篩選 newEvaluationResult.complianceType = NON_COMPLIANT，目標設為資安團隊的 SNS topic。即使 auto-remediation 已到位，團隊也應知道它執行了。
5. 大規模預防（SCP）。對不應有任何公開 bucket 的帳號，在 OU 層級附加 SCP，拒絕 s3:PutBucketPolicy 與 s3:PutBucketAcl 動作（當 aws:RequestTag/Public 不為 "true" 時），在變更發生前就封鎖它，作為偵測與補救的前置防線。

答案鍵是：CloudTrail 找出誰做的、Config rule 偵測、SSM Automation 補救、EventBridge 通知、SCP 預防——五個服務串成一條管線。SOA-C02 這類家族的每道題目都嘉獎能命名並排列全部五個服務的考生。

場景模式：合規團隊需要 90 天前的資源設定

合規團隊詢問「2 月 1 日 02:00 UTC 時，每個 EC2 instance、security group 與 S3 bucket 的設定是什麼？」CloudTrail 是錯誤答案——CloudTrail 記錄變更，不記錄狀態。

正確答案：

1. 確認 Config recorder 在相關時間點是否運作中。 若 90 天前 Config 未在錄製，資料根本不存在——無法事後復原。
2. 使用 Config 主控台的 configuration timeline 查看每個相關資源，導航至 2 月 1 日 02:00，查看當時確切的 configuration item。
3. 大量擷取時，使用 Config 每 6 小時傳送至 S3 的 configuration history 檔案——它們依日期分區，包含該時間窗口的每份 CI。
4. SQL 存取時，以 Config Advanced Query 查詢當前狀態，以 Athena 在 configuration history S3 bucket 上建立資料表查詢歷史狀態。

這個模式強化了邊界：時間點狀態問題找 Config，時間點動作問題找 CloudTrail。

場景模式：監管機關要求說明誰刪除了 Bucket X

監管機關要求找出在 3 月 15 日刪除 customer-data-prod bucket 的使用者。SysOps 工程師必須提出證據。

1. Bucket 刪除（DeleteBucket）是 management event——每個 trail 預設記錄的 management event，以及 CloudTrail Event History 90 天內均可查。不需要 data event opt-in。
2. 在相關 region 搜尋 CloudTrail Event History（S3 的某些呼叫有全域服務事件行為；同時檢查 bucket 所在 region 與 us-east-1）。
3. 事件記錄顯示 userIdentity.arn，若透過假冒 role 則顯示 role/session，以及來源 IP、MFA 狀態與時間戳記。若透過主控台操作，userAgent 會反映主控台 URL。
4. 若刪除時間超過 90 天，Event History 已消失——只有 trail 的 S3 目的地保留記錄。這正是為什麼在專屬日誌帳號中建立長期保留的 organization trail 是 SOA-C02 的標準做法。

注意「誰刪除了 bucket」與「誰刪除了 bucket 裡的 object X」之間的差異——後者是 data event（S3 data events 的 DeleteObject），只有在 trail 明確 opt-in data events 的情況下才有記錄。SOA-C02 經常在這類場景中互換「bucket」與「object」，用來測試考生是否了解 management/data 的邊界。

常見陷阱：CloudTrail 不記錄 OS 層級變更；Config 不記錄應用程式輸出

SOA-C02 出乎意料的常見混淆點。這對稽核工具有其限制：

• CloudTrail 只記錄 AWS API 呼叫。 它不記錄：

  • EC2 上執行的 OS 層級指令（useradd、rm -rf、iptables rules）。
  • 應用程式層級事件（使用者登入你的 Web 應用程式）。
  • CloudWatch agent 的 metric 發布（這些是 API 呼叫，但產生的量如此龐大，CloudTrail 預設不記錄——它們屬於特殊排除類別）。
  • 網路封包內容（使用 VPC Flow Logs）。

• AWS Config 只記錄資源層級的設定。 它不記錄：

  • EC2 instance 內的檔案內容。
  • Lambda function 內的應用程式程式碼或資料（只有 function 的 metadata 與 runtime 設定）。
  • S3 bucket 內的物件層級狀態（只有 bucket 的設定）。
  • DynamoDB table 的每一列資料。

OS 層級稽核需要 CloudWatch Logs（搭配 agent） 加上 Systems Manager Inventory。應用程式層級稽核需要應用程式日誌傳送至 CloudWatch Logs 加上 CloudTrail data events（若 API 存取是其中一環）。考試以「用 CloudTrail 記錄 EC2 instance 上的 SSH 登入嘗試」來測試這條邊界——這是錯誤的，那是透過 CloudWatch agent 傳送的 auth.log；或「用 AWS Config 偵測 instance 內部是否有檔案被修改」——這也是錯誤的，那屬於 OS 層級，超出 Config 的範疇。

常見陷阱：Data Events 的成本——謹慎 Opt-In

Data events 按事件計費，高流量的 S3 bucket 或 Lambda function 每分鐘可產生數百萬個事件。草率地「對所有 S3 bucket 啟用 data events」可能讓 CloudTrail 帳單大幅攀升。SOA-C02 最佳實踐：

• 使用 advanced event selectors 將 data events 範圍限定在特定資源 ARNs。
• 當只有變更才重要時，限制為僅記錄寫入 data events（isReadOnly = false）。
• 排除服務間的內部流量（例如，接收 CloudTrail 自身日誌的日誌 bucket——遞迴放大成本）。
• 在正式環境啟用前，先在非正式環境測試 data event 流量。

常見場景：「合規團隊對每個 bucket 都啟用了 S3 data events，包括 CloudTrail 日誌 bucket；CloudTrail 帳單一夜之間變成五倍」。答案是用 advanced event selector 排除日誌 bucket ARN 來縮小 data events 範圍。

常見陷阱：Organization Trail vs 多個本地 Trails——成本與稽核姿態

Organization trails 是 SOA-C02 集中稽核的預設答案。但有三個細節：

• Management events 的第一份副本每個 trail 免費。若 organization trail 與成員帳號的本地 trail 都記錄相同的事件，你需要為第二份副本（本地 trail 那份）付費。
• Organization trails 無法被成員帳號修改或停用——這對資安是優點，但對委派稽核團隊而言是限制。
• 成員帳號仍可為運維目的建立自己的 trails（例如，傳送至 region 本地 CloudWatch Logs group 供 ChatOps 使用）。Organization trail 處理合規；本地 trail 處理運維操作。考試正確答案通常兩者兼用。

CloudTrail/Config 在 Security Hub 與彙整 Findings

AWS Security Hub 是跨 GuardDuty、Inspector、Macie、IAM Access Analyzer 與 AWS Config 的資安 findings 彙整介面。Config rule 評估結果以 findings 形式浮現於 Security Hub，並自動依嚴重性評分。Security Hub 也執行自己的檢查，對齊合規標準（CIS AWS Foundations、AWS Foundational Security Best Practices、PCI-DSS），底層由 Config rules 支撐。

SOA-C02 的 Security Hub 角度：

• 整個組織合規姿態的單一視窗。
• Findings 流向 EventBridge（aws.securityhub 事件來源），支援基於 findings 的 auto-remediation 管線。
• Security Hub 不取代 Config——它消費 Config rule 結果，Config rules 仍是政策強制執行層。
• 啟用 Security Hub 會自動啟用一組基礎 Config rules；預期 Config 帳單會增加。

SOA-C02 vs SAA-C03：運維稽核視角的差異

SAA-C03 與 SOA-C02 都考 CloudTrail 和 Config，但視角不同。

SAA-C03 考生選擇稽核服務；SOA-C02 考生正確設定服務、在運作異常時疑難排解，並在合規審查期間操作 dashboard。

考試信號：如何辨認 CloudTrail/Config 題目

CloudTrail/Config 題目有可預測的模式。認出它們，每道題的作答時間就會大幅縮短。

• 「誰在 T 時間點做了 X？」 — CloudTrail（≤ 90 天用 Event History，更舊的用 trail 的 S3）。
• 「資源在 T 時間點長什麼樣？」 — AWS Config configuration timeline。
• 「X 在過去 N 天是否持續為真？」 — AWS Config configuration history。
• 「偵測不合規並還原」 — Config rule + SSM Automation auto-remediation。
• 「集中所有帳號的稽核日誌」 — 在管理帳號或委派管理員帳號建立 Organization trail。
• 「集中所有帳號的合規姿態」 — Config organization aggregator + organization conformance pack。
• 「對齊 CIS / NIST / PCI-DSS / HIPAA 進行驗證」 — 符合框架的 Config Conformance Pack。
• 「S3 物件被刪除但不在 trail 中」 — data events 未啟用；往後 opt-in。
• 「偵測日誌竄改」 — Trail 建立時啟用 log file integrity validation；用 aws cloudtrail validate-logs 驗證。
• 「對資安相關 API 呼叫即時告警」 — trail 傳至 CloudWatch Logs + metric filter，或 EventBridge rule on aws.<service> event source。
• 「跨多年稽核資料的 SQL 查詢」 — CloudTrail Lake。
• 「Auto-remediation 未執行」 — 檢查 SSM Automation document 的 assume-role 權限；對 Automation 執行失敗設定 alarm。

決策矩陣 — 各 SysOps 稽核目標對應的 CloudTrail/Config 工具

考試時使用這份查找表。

常見陷阱總整理 — CloudTrail 與 AWS Config

每次 SOA-C02 考試都會出現其中兩三個干擾選項。

陷阱一：Trail 預設捕捉 S3 物件操作

並非如此——那些是 data events，必須 opt-in。

陷阱二：Event History 涵蓋 90 天以上的記錄

並非如此——Event History 恰好是 90 天。更早的資料，trail 的 S3 目的地才是真實來源。

陷阱三：Config aggregator 可以跨帳號 auto-remediate

並非如此——aggregators 是唯讀的。

陷阱四：Detailed monitoring 或 CloudTrail 捕捉記憶體/磁碟

並非如此——那些是 CloudWatch agent metrics，屬於獨立的攝入路徑。

陷阱五：Log file integrity validation 可事後補做

並非如此——digest files 只從啟用時間點往後產生。

陷阱六：Config periodic rule 設 24 小時週期卻能在幾分鐘內還原

並非如此——periodic rules 在設定的週期才評估。分鐘級補救需要 configuration-change-triggered rules。

陷阱七：SSM Automation 沒有正確 IAM role 也能執行

並非如此——automation assume-role 必須具備 document 所呼叫 API 的權限。缺少權限 = 靜默失敗。

陷阱八：Organization trail 讓成員帳號的本地 trail 變得多餘

並非如此——本地 trails 為運維目的補充 organization trail（例如，region 本地 CloudWatch Logs 傳送供 ChatOps 使用）。

陷阱九：CloudTrail 記錄 agent 的 PutMetricData 呼叫

並非如此——高量遙測呼叫如 PutMetricData 被排除在 CloudTrail 記錄之外。

陷阱十：Conformance packs 取代 SCPs

並非如此——conformance packs 偵測；SCPs 預防。完整的安全姿態兩者都需要。

FAQ — CloudTrail 與 AWS Config

Q1：CloudTrail 上的 management events 與 data events 有何確切差異？

Management events 記錄控制層面的 API 呼叫——設定或管理 AWS 資源的呼叫。範例：RunInstances、CreateBucket、PutBucketPolicy、AttachRolePolicy、DeleteVolume、ConsoleLogin、AssumeRole。Trails 預設記錄 management events，且第一份副本免費。Data events 記錄資料層面的 API 呼叫——對資源內部資料的操作。範例：S3 GetObject / PutObject / DeleteObject（bucket 內容的物件層級操作，非 bucket 本身）、Lambda Invoke、DynamoDB 項目層級讀寫。Data events 在每個 trail 上必須 opt-in，按事件計費，並可用 advanced event selectors 依 ARN、事件名稱或讀/寫屬性精確選取。SOA-C02 的陷阱是將 bucket 層級操作（management）與物件層級操作（data）混淆——PutBucketPolicy 是 management event，PutObject 是 data event，預設只記錄前者。

Q2：CloudTrail 保留資料多久？如何為稽核證明持續涵蓋？

三個儲存層對應三種保留期：(a) 主控台的 CloudTrail Event History——恰好 90 天的 management events，免費，僅限當前 region；(b) S3 的 Trail logs——依你的 S3 lifecycle policy保留，可實質上永久保存；(c) CloudTrail Lake——最長 10 年、具延伸保留期、可用 SQL 查詢。為在稽核中證明持續涵蓋，標準模式是：傳送至 S3 的 organization trail，開啟版本控制、MFA Delete，並在 trail 建立時啟用 integrity validation。定期執行 aws cloudtrail validate-logs --trail-arn ... --start-time ... --end-time ...（以 SysOps Automation runbook 排在維護時段執行是乾淨的實作），驗證 digest 鏈沒有缺口。

Q3：何時應選自訂 Config rule 而非受管 rule？自訂 rule 的後端是什麼？

受管 rules 涵蓋數百種常見合規檢查，包括加密、公開存取、IAM 密碼政策、security group rules、CloudTrail 狀態、VPC Flow Logs，以及大多數服務特定最佳實踐。當沒有受管 rule 涵蓋政策時使用自訂 rules——幾乎都是組織特定場景，例如「每個 EC2 instance 必須有來自核准清單的 CostCenter tag」或「environment tag 為 production 的 RDS instance 必須使用名稱以 prod- 開頭的 parameter group」。後端可選 AWS Lambda（完整的程式化彈性）或 CloudFormation Guard（用於 policy-as-code 的宣告式 DSL）。Lambda 彈性最高但需維護程式碼；Guard 在檢查能清晰表達為政策時較輕量。SOA-C02 偏好有受管 rule 涵蓋時用受管 rule，否則用 Lambda。

Q4：如何讓 AWS Config auto-remediate 不合規資源而不破壞正式環境？

透過 rule 的 remediation action 將 Config rule 串接至 SSM Automation document，設定 Automatic 模式，並指定具備 document 所需精確權限的 assume-role。三道運維防護措施能避免災難：(a) 限定 rule 的範圍，讓它只評估你真正想自動管理的資源——使用資源 tags 或 rule 的資源 ID 參數排除刻意的例外（例如公開網站 bucket）；(b) 先以 Manual 模式運行一到兩週，觀察 rule 觸發的情況，再升級為 Automatic；(c) 對 SSM Automation 執行事件設定 alarm——透過 EventBridge aws.ssm Automation Execution Status-Change Notification 篩選狀態 Failed，讓靜默失敗也能呼叫待命人員。Auto-remediation 在沒有這些防護的正式環境中很危險，因為 rule 會還原刻意的變更——許多 SysOps 團隊曾在容災演練進行到一半時，被 Config rule 還原了演練設定而留下慘痛教訓。

Q5：Organization trail 與本地 trail 有何不同？合規需要哪一種？

本地 trail 在單一帳號建立，只捕捉該帳號的事件。Organization trail 從 AWS Organizations 管理帳號或委派管理員帳號建立，自動捕捉組織中每個成員帳號的事件（包括日後加入的新帳號），集中存入一個 S3 bucket。就合規而言，organization trail 是標準答案，原因是：(a) 成員帳號無法停用或修改，提供防竄改保障；(b) 一個 trail 涵蓋每個帳號，消除成員帳號遺漏日誌的可能；(c) 一個 S3 bucket 存放所有證據，簡化稽核人員的取證；(d) organization trail 不受成員帳號被攻陷影響——攻擊者無法關閉你的稽核。成員帳號仍可為運維目的建立本地 trail（region 本地 CloudWatch Logs 供 ChatOps 使用、帳號特定 data events），但合規 trail 是 organization trail。SOA-C02 對任何「跨帳號集中稽核」場景都偏好 organization trail。

Q6：CloudTrail Lake 與標準「trail 傳至 S3 + Athena」模式有何不同？

標準 trail 傳至 S3 將壓縮 JSON 檔案傳送至你的 bucket；查詢需要分區、建立 Athena 資料表、維護 Glue Crawler 以及 SQL 技能。CloudTrail Lake event data store 是受管事件儲存庫，內建 SQL 查詢介面，自動分區與索引，保留期最長 10 年，支援 federated query。CloudTrail Lake 依每 GB 攝入計費，但免去維護 Athena 資料表與分區的運維負擔。以下情況選 CloudTrail Lake：合規團隊需要一站式 SQL 介面，且資料量支撐每 GB 費用。以下情況選 trail-to-S3-plus-Athena：你想要最低的儲存成本（S3 standard / IA / Glacier lifecycle）、願意維護 Athena 層，且查詢頻率低。

Q7：哪個 IAM 權限缺口會導致 Config auto-remediation 靜默失敗？

Config rule 的 remediation action 指定一個 assume-role ARN，SSM Automation 執行 document 時會扮演此角色。此 role 的 policy 必須允許：(a) ssm:StartAutomationExecution 及其他透過 SSM 服務角色模式隱含授予的 SSM API 呼叫，以及最關鍵的 (b) document 實際執行的特定 AWS API 呼叫——以 AWS-DisablePublicAccessForS3Bucket 為例，就是目標 bucket 的 s3:PutBucketPublicAccessBlock 與 s3:GetBucketPublicAccessBlock。若 role 缺乏修正 API 的權限，document 執行、API 呼叫回傳 AccessDenied，資源持續 NON_COMPLIANT，且沒有內建告警——靜默失敗是預設行為。SOA-C02 明確測試此場景；答案結合 (a) 正確的 role policy 以及 (b) 針對 aws.ssm Automation 執行事件中狀態為 Failed 的 EventBridge rule，導向 SNS 以便你能看到 remediation 失敗。

Q8：為何 Config rule 上會出現「INSUFFICIENT_DATA」或「NOT_APPLICABLE」結果？

INSUFFICIENT_DATA 表示 Config 尚無法完成評估——通常是因為 configuration recorder 未捕捉相關資源類型、rule 剛建立，或 Lambda-backed 自訂 rule 逾時。修正方式：檢查 configuration recorder 的資源類型清單（是否包含 rule 針對的類型）、rule 的近期評估歷程，以及 Lambda function 的 CloudWatch Logs。NOT_APPLICABLE 表示 rule 刻意判定此資源超出範圍——例如 s3-bucket-public-read-prohibited 針對非 S3 資源，或自訂 Lambda 對不符合政策意圖的資源回傳 NOT_APPLICABLE。NOT_APPLICABLE 是正常且預期的；INSUFFICIENT_DATA 是值得調查的設定問題。

Q9：如何在稽核中證明 EBS volume 在過去 12 個月持續加密？

三個步驟。(a) 確認 AWS Config 在整個 12 個月期間都在記錄 EBS 資源類型——檢查 configuration recorder 的歷程。若錄製曾中斷，資料就不存在。(b) 在 Config 主控台使用該 volume 資源 ID 的 configuration timeline；每份 CI 都捕捉 encrypted 屬性。從 12 個月前走到今天；每份 CI 都必須顯示 "encrypted": true。(c) 機器可讀的證據，用 Athena 在 configuration history S3 bucket 上查詢——SELECT configurationItemCaptureTime, configuration.encrypted FROM config_history WHERE resourceId = 'vol-xxx' ORDER BY configurationItemCaptureTime。匯出結果 CSV 給稽核人員。Conformance Pack 方式提供彙整百分比；configuration history 提供每個資源每個時間點的詳細證據。

Q10：我應該用 Config rules 還是 SCPs 來強制執行合規政策？

兩者分層並用。SCPs 是預防性的——它們從源頭拒絕 API 呼叫的發生。位於 AWS Organizations 層級，適用於受影響帳號中的每個 IAM principal。適合用在硬性規則，例如「不允許在 ap-southeast-1 以外建立資源」或「不允許建立 IAM user」。Config rules 是偵測性的——它們觀察已設定的內容並標記違規，也能透過 SSM Automation auto-remediation 驅動修正動作。兩層互補：SCPs 阻擋明顯的惡意變更；Config rules 偵測 SCP 無法封鎖的細微偏差（例如「每個 EBS volume 必須有 backup tag」——沒有 API 可以拒絕，因為 volume 建立 API 本身是合法的，只是需要標籤檢查）。SOA-C02 對全面政策的答案是「SCP 用於預防 + Config rule 用於偵測 + auto-remediation 用於修正 + EventBridge 告警 + organization conformance pack 用於框架整體彙整」。只選一層是不完整的。

延伸閱讀與相關運維模式

• AWS CloudTrail User Guide
• Logging Management and Data Events with CloudTrail
• Logging Insights Events with CloudTrail
• Creating and Updating a CloudTrail Trail
• Creating a CloudTrail Trail for an Organization
• Validating CloudTrail Log File Integrity
• Monitoring CloudTrail Log Files with CloudWatch Logs
• Viewing CloudTrail Event History
• What is AWS Config
• Evaluating Resources with AWS Config Rules
• AWS Config Conformance Packs
• Remediating Noncompliant Resources with AWS Config Rules
• Multi-Account Multi-Region Data Aggregation
• Viewing Configuration Timeline
• AWS Security Hub User Guide
• AWS SOA-C02 Exam Guide v2.3 (PDF)

CloudTrail 與 Config 到位後，自然延伸的運維層包括：CloudWatch Logs 與 Logs Insights（CloudTrail 與 Config 未涵蓋的應用程式與系統日誌分析層）、EventBridge rules 與 SNS notifications（將 Config rule findings 與 CloudTrail 偵測到的異常路由至 remediation 管線的骨幹）、CloudWatch Metrics、Alarms 與 Dashboards（在合規姿態旁的運維態勢感知），以及 IAM Policies、MFA、SCPs 與 Access Troubleshooting（位於 Config 偵測與 SSM 修正之上的預防層）。

• CloudWatch Metrics、Alarms 與 Dashboards — SOA-C02 學習筆記
• CloudWatch Logs、Log Groups 與 Logs Insights — SOA-C02 學習筆記
• EventBridge Rules、SNS 與自動補救 — SOA-C02 學習筆記
• IAM Policies、MFA、SCPs 與 Access 疑難排解 — SOA-C02 學習筆記