Cloud Audit Logs 簡介
在安全領域，如果沒有記錄，就代表事情沒發生過。Cloud Audit Logs (雲端稽核記錄) 為您 Google Cloud 環境中發生的每項操作提供了「誰 (Who)、做了什麼 (What)、在哪裡 (Where)、何時 (When)」的資訊。
對於 PSE 而言，深入理解記錄類型、如何路由以進行集中分析，以及如何維護記錄以符合合規性，是進行事件回應與數位鑑識調查的基礎。
白話文解釋
比喻 1：辦公大樓的監視器
把整個 GCP 組織想像成一棟辦公大樓。Admin Activity Logs 是大廳與機房門口的監視器——只要有人「改動建築物本身」（建立 VM、修改 IAM 政策），就會被錄下來。它永遠是開的、不收錢，錄影帶保存 400 天。Data Access Logs 則是主管文件室裡的監視器——記錄誰打開了哪份檔案（讀取 GCS 物件、查詢 BigQuery 資料表）。因為這支監視器錄到的資料量極大，預設是關閉的（BigQuery 除外）、需要付錢，而且錄影帶預設只保存 30 天，除非你升級儲存。System Event Logs 是大樓維修日誌——Google 工程師幫你修電梯（替你的 VM 做即時遷移），這部分不收錢，一樣保存 400 天。
比喻 2：郵件分揀室（Log Router）
Log Router 就是 GCP 環境裡的郵件分揀室。每一條 log 都是一封信。Log Sink 是轉寄規則：「符合這個篩選條件的信，全部寄到這個信箱」。你可以把信轉寄到四個信箱——Cloud Storage（便宜的封存倉庫，配 Bucket Lock 適合 7 年合規保存）、BigQuery（分析師的辦公桌，可以用 SQL）、Pub/Sub（特快專送，餵給 Splunk / Chronicle 等 SIEM）、或 Log Buckets（Cloud Logging 內部的信箱）。在組織層級設定 Aggregate Sink，等於在大樓中央信件室裝一條轉寄規則——所有樓層（專案）一次涵蓋。
比喻 3：銀行金庫的時間鎖
GCS Bucket Lock 保留政策就是銀行金庫的時間鎖機制。一旦你在 logging 儲存桶上設定 7 年保留政策並鎖定，任何人——即使是擁有完整 IAM 權限的專案擁有者——在時間鎖到期前都無法刪除這些 logs。這正是稽核員在 SOX、HIPAA、PCI-DSS 證據保全上要看到的東西。把它跟組織層級的 Aggregate Sink 搭配，把 log 全部路由到獨立的「合規專案」，你就建構了一個防竄改的金庫——即使子專案管理員帳號被攻陷，也無法銷毀證據。金庫鑰匙（專案 IAM）與監視器（log 產生端）分離，這正是職責分離（separation of duties）的精髓。
三種稽核記錄類型
Google Cloud 將稽核記錄分為三種主要類型，每種類型都有不同的保留期限與成本配置。
1. 管理活動記錄 (Admin Activity Logs)
- 內容： 記錄修改資源配置或元數據的 API 呼叫或其他操作（例如：建立 VM、更改 IAM 政策）。
- 成本： 始終啟用且完全免費。
- 保留期限： 400 天。
2. 資料存取記錄 (Data Access Logs)
- 內容： 記錄建立、修改或讀取使用者提供資料的 API 呼叫（例如：讀取 GCS 物件、查詢 BigQuery 資料表）。
- 成本： 預設為停用（BigQuery 除外），因為它們可能產生海量資料並產生費用。
- 保留期限： 預設 30 天，但可延長。
3. 系統事件記錄 (System Event Logs)
- 內容： 記錄 Google Cloud 內部修改資源配置的管理操作（例如：由 Google 啟動的 VM 遷移）。
- 成本： 始終啟用且完全免費。
- 保留期限： 400 天。
由於資料存取記錄預設是停用的，您必須在「IAM 與管理」主控台中針對想要監控的服務手動啟用它們。這是安全稽核中常見的疏漏點。
使用 Log Sinks 路由記錄
Log Router (日誌路由器) 決定了記錄的流向。透過建立 Log Sinks (日誌接收器)，您可以將記錄匯出到外部目的地，以進行長期儲存或分析。
Sink 目的地：
- Cloud Storage (GCS)： 用於符合成本效益的長期合規儲存。
- BigQuery： 使用 SQL 進行複雜的安全分析。
- Pub/Sub： 即時串流到 SIEM（如 Splunk 或 Chronicle）或透過 Cloud Functions 觸發自動化修補。
- 日誌桶 (Log Buckets)： 用於 Google Cloud 內部的集中式記錄。
Log Sink (日誌接收器) 是一項配置，包含一個篩選器 (Filter)（決定匯出哪些記錄）以及一個目的地 (Destination)（決定發送到哪裡）。
集中式記錄架構
對於企業環境，記錄應集中在一個專用的「日誌專案 (Logging Project)」中。
- 聚合接收器 (Aggregate Sinks)： 在組織 (Organization) 或資料夾 (Folder) 層級建立，自動收集所有子專案的記錄。
- 日誌桶 (Log Buckets)： 您可以在日誌專案中建立自訂日誌桶，並將其他專案的記錄路由至此。
針對長期合規封存（例如 HIPAA / SOX / PCI-DSS 要求的 7 年保留），不要依賴預設的 _Default 日誌桶（上限 3650 天、僅限專案範圍、專案擁有者可刪除）。正確做法是在組織節點建立 Aggregate Sink，目的地指向獨立合規專案中的 GCS 儲存桶，並在該儲存桶啟用 Bucket Lock 搭配 Retention Policy。Bucket Lock 會讓保留期變成不可撤銷 (irrevocable) ——即使是組織管理員也無法在期限到期前縮短或刪除已鎖定的物件，這正是稽核員需要的防竄改 WORM 儲存。
日誌分析與 SQL
Log Analytics (日誌分析) 是一項功能，允許您在 Logging 主控台內使用標準 SQL 查詢記錄。
- 連結的資料集 (Linked Datasets)： 您可以將日誌桶連結到 BigQuery，將記錄資料與其他業務資料結合，以獲得更深層的洞察。
- 安全使用情境： 「找出過去 24 小時內存取特定 KMS 金鑰的所有使用者，並識別其 IP 位址。」
成本管理：排除篩選器
如果不妥善管理，記錄費用可能會變得非常昂貴。
- 排除篩選器 (Exclusion Filters)： 允許您捨棄不需要的記錄（例如：「排除所有來自高流量 GCS 儲存桶的成功
get請求」）。 - 取樣 (Sampling)： 您可以選擇僅記錄一定百分比的某些事件，以在維持可見性的同時減少資料量。
務必優先記錄寫入 (Write) 操作與 IAM 變更。讀取操作（資料存取）通常量極大，應僅針對高價值資源啟用。
常見的考試陷阱：在 _Required sink 上設定的排除篩選器會被靜默忽略 ——Admin Activity、System Event 與 Access Transparency 記錄是強制性的，無法在 sink 層級排除或停用。排除篩選器只對 _Default sink 與使用者自建的 sink 有效。第二個陷阱：當你在組織層級建立 Aggregate Sink 並設定 include_children=true，該 sink 的寫入服務帳號 (writer service account)（p[PROJECT_NUMBER]-[ID]@gcp-sa-logging.iam.gserviceaccount.com）必須在目的地被授予 roles/bigquery.dataEditor 或 roles/storage.objectCreator 權限。如果寫入身分缺乏權限，sink 會 fail open（靜默丟棄 log），你只會在事件發生時，發現該有的證據根本不存在。
稽核稽核者
記錄本身也是敏感資料。您必須保護它們免受未經授權的存取或刪除。
- Logging 的 IAM 權限： 使用
logging.viewer與logging.privateLogViewer角色。後者是查看「資料存取記錄」的必要條件。 - 存取透明度 (Access Transparency)： 記錄 Google 人員何時存取您的資料（作為稽核記錄的補充）。
調查安全事件
Log Explorer (日誌探索器)
用於即時排錯與調查的主要工具。
- 使用 Power Queries 根據
resource.type、methodName與principalEmail進行篩選。 - 儲存常用調查的查詢語句（例如：「未經授權的防火牆變更」）。
VPC Flow Logs 與防火牆分析
- VPC Flow Logs： 記錄網路流量（來源/目的地 IP、連接埠、協定）。對於偵測橫向移動至關重要。
- Firewall Insights： 識別被遮蔽 (Shadowed) 或過度寬鬆的防火牆規則。
PSE 考試情境
情境 1：保留記錄 7 年
「法律要求一家公司必須將所有『管理活動記錄』與『資料存取記錄』保留 7 年。如何以最具成本效益的方式實現？」 解答： 在組織層級建立一個聚合接收器 (Aggregate Log Sink)，將目的地設定為獨立「合規專案」中的 Cloud Storage 儲存桶。在該 GCS 儲存桶上設定保留政策 (Retention Policy) 以強制執行 7 年的保留要求。
情境 2：IAM 變更的即時告警
「安全營運中心 (SOC) 需要在任何專案中授予使用者『擁有者 (Owner)』角色時，在數秒內收到告警。最佳架構是什麼？」
解答： 建立一個 Log Sink，篩選器設定為 protoPayload.methodName="SetIamPolicy"，並將其路由至 Pub/Sub。由該 Pub/Sub 主題觸發 Cloud Function 進行日誌解析並向 SOC 發送告警。
記憶重點：保留期、log 類型與 Sink 機制
保留期預設值（背起來）：
- Admin Activity 記錄：400 天、免費、永遠啟用，無法停用。
- System Event 記錄：400 天、免費、永遠啟用，無法停用。
- Data Access 記錄：30 天、付費、預設停用（例外：BigQuery 的
DATA_READ預設開啟）。子類別有ADMIN_READ、DATA_READ、DATA_WRITE。 - Policy Denied 記錄：30 天、免費、當 VPC Service Controls 拒絕請求時預設啟用；應路由到 SIEM 以做周界破口告警。
- Access Transparency 記錄：400 天、記錄 Google 員工存取行為（需 Premium / Enterprise 支援等級）。
Log Bucket 保留期： _Required = 400 天（不可變、無法修改）；_Default = 30 天（可設定到 3650 天）；自訂桶 = 1 到 3650 天。
Log-based metrics（兩種）：
- 系統定義指標： 內建（例如
logging.googleapis.com/byte_count）。 - 使用者定義指標： Counter（符合篩選條件的事件數）或 Distribution（抽取數值，例如回應延遲）。Counter 指標餵給 Cloud Monitoring 告警政策——經典模式是
protoPayload.methodName="SetIamPolicy"的 counter，60 秒內 count > 0 即告警。
Sink 目的地決策矩陣：
- BigQuery → 即席 SQL 鑑識、與業務資料 join、分區資料表。
- GCS（搭配 Bucket Lock） → 多年期 WORM 合規封存。
- Pub/Sub → 即時 fan-out 到 Splunk / Chronicle / Cloud Function 自動修補。
- Log Bucket → 在 GCP 內部保留 + 使用 Log Analytics SQL，不離開 Logging。
privateLogViewer 角色是讀取 Data Access 與 Access Transparency 記錄的必要條件；單純的 logging.viewer 看不到。
總結檢查表
- 區分管理活動記錄、資料存取記錄與系統事件記錄。
- 解釋為什麼資料存取記錄預設是停用的。
- 列出 Log Sink 的四個主要目的地。
- 描述在資料夾/組織層級使用聚合接收器的好處。
- 識別查看資料存取記錄所需的角色 (
privateLogViewer)。 - 解釋如何使用 Log Analytics 透過 SQL 查詢記錄。