安全監控簡介
在複雜的雲端環境中，「您無法保護您沒有監控的東西」。對於 專業雲端安全工程師 (PSE) 來說，Cloud Monitoring 是用於了解基礎設施健康狀況和安全性的工具集。雖然 SCC 側重於發現和威脅，但 Cloud Monitoring 則側重於 性能指標、系統健康狀況 以及可能表示緩慢攻擊或配置錯誤的 基於日誌的模式。
安全監控的目標是通過確保在正確的時間通知正確的人，來縮短「平均檢測時間」(MTTD)。
白話文解釋
1. 汽車儀表板 (安全儀表板)
當您開車時，您不會一直盯著引擎蓋下面看。您看的是儀表板。它會告訴您車速（流量）、油量（配額使用情況）以及引擎檢查燈是否亮起（系統錯誤）。GCP 中的 安全儀表板 提供了雲端環境「健康狀況」的高級視圖。
2. 煙霧探測器 (基於日誌的告警)
煙霧探測器不會等火燒起來才發揮作用；它會尋找特定的模式（煙霧顆粒）。基於日誌的告警 就像那個探測器。它掃描數百萬條日誌條目，尋找特定模式，例如「1 分鐘內有 100 次登錄失敗」，並在發現該模式時立即發出尖叫（發送告警）。
3. 社區巡守隊 (運行狀況檢查)
想像一位鄰居每小時都會走過您家門口，確保前門是關著的。如果他們看到門開著，就會給您打電話。運行狀況檢查 (Uptime Checks) 為您的 Web 應用程序執行此操作。它們從全球不同地點「Ping」您的安全端點，以確保其可用並能正確響應。
創建以安全為中心的儀表板
安全儀表板應提供整個組織風險的高級視圖。
- 應包含的關鍵指標：
- 活動中的 SCC「關鍵 (Critical)」發現數量。
- VPC 流日誌流量（用於檢測流量激增）。
- IAM 政策更改頻率。
- API 錯誤率（4xx 和 5xx 錯誤可能表示掃描）。
- 服務帳戶使用量激增。
使用 Cloud Monitoring 中的 自定義儀表板 按「安全領域」（例如網絡安全、IAM、數據訪問）對指標進行分組。
基於日誌的指標與告警
有時，您需要的信息不是指標（如 CPU 使用率），而是日誌中的特定字串。
- 計數器指標 (Counter Metrics)： 計算特定日誌條目出現的次數（例如 BigQuery 中的「訪問被拒絕」）。
- 分佈指標 (Distribution Metrics)： 跟踪事件的大小或延遲（例如「從敏感 GCS 存儲桶下載的對象大小」）。
- 基於指標告警： 一旦有了指標，就可以設置閾值。例如：「如果『訪問被拒絕』指標在 5 分鐘內 > 50，則觸發告警。」
基於日誌的指標 (Log-based Metrics) 是 Cloud Monitoring 中的指標，其數值取決於 Cloud Logging 中日誌條目的內容。
通知管道與事件管理
如果沒有人看到，告警就是無效的。
- 管道： GCP 支持電子郵件、短信、Slack、PagerDuty、Webhooks 和 Google Cloud 移動應用。
- 最佳實踐： 對於高優先級的安全告警，使用 Slack 或 PagerDuty 以確保立即被看見。對於低優先級、信息類的告警，使用 電子郵件。
監控 API 使用情況與配額
攻擊者經常會掃描 API，或嘗試啟動數百台 VM 進行挖礦。
- 配額監控： 對
serviceruntime.googleapis.com/quota/exceeded設置告警。配額超限錯誤的突然激增是自動化攻擊或失控腳本的強烈信號。 - API 異常： 監控異常的 API 調用（例如，一個平時以「讀取」為主的服務帳戶突然執行大量的「刪除」操作）。
安全端點的運行狀況檢查 (Uptime Checks)
運行狀況檢查不僅是為了可用性，也是為了 完整性。
- 場景： 您有一個關鍵的內部安全 API。您設置運行狀況檢查來驗證它是否返回
200 OK並且標頭中包含特定字串。如果攻擊者將您的 API 替換為不返回該字串的惡意 API，則運行狀況檢查將失敗，並會向您發出告警。
運行狀況檢查可以配置為源自多個地理區域，以確保全球可用性。
管理告警疲勞 (Alert Fatigue)
PSE 面臨的最大風險之一是 告警疲勞——收到太多的告警以至於開始忽視它們。
- 精確化閾值： 不要對每一次失敗都發出告警。使用「N 次中的 M 次」邏輯（例如：「如果 5 分鐘內發生 3 次失敗，則發出告警」）。
- 分組： 將相關告警分組到單個事件中以減少雜訊。
- 自動關閉： 配置告警在條件自行解決時自動關閉，使您的儀表板保持整潔。
用於監控的基礎設施即代碼 (IaC)
為了保持一致的安全姿態，您應該通過代碼管理監控。
- Terraform： 使用
google_monitoring_alert_policy和google_monitoring_dashboard資源，將您的安全監控與基礎設施一起部署。 - 好處： 這可以確保您創建的每個新專案都自動具備所需的安全告警和儀表板。
監控敏感數據訪問
結合 Cloud DLP，您可以監控對敏感數據的訪問。
- 場景： 為 BigQuery 審計日誌中每次訪問「高敏感性 (High Sensitivity)」標籤的操作創建一個基於日誌的指標。
- 告警： 如果「數據科學 (Data Science)」小組以外的用戶接觸到該數據，則觸發告警。
監控會產生大量數據。請注意 Cloud Monitoring 成本，尤其是在使用高基數 (High-cardinality) 自定義指標或頻繁的運行狀況檢查時。
將監控與 SCC 集成
Cloud Monitoring 和 SCC 是互補的。
- SCC 告訴您「門沒鎖」（發現）。
- Monitoring 告訴您「有人剛剛走進了門」（指標/告警）。
- 集成： 您可以直接在 Cloud Monitoring 儀表板中查看 SCC 發現，從而將安全威脅與系統性能相關聯。
PSE 安全最佳實踐
- 定義「正常」： 如果您不知道「正常」行為是什麼樣的，就無法檢測到異常。花時間為您的環境建立基準。
- 分層告警： 為需要叫醒人的事情（例如 Root 帳戶登錄）創建一個「關鍵」頻道，為日常審查創建一個「標準」頻道。
- 使用錯誤報告： 啟用 Cloud Error Reporting 以自動對應用程序級的安全異常進行分組（例如導致代碼崩潰的 SQL 注入嘗試）。
- 審計監控器： 定期檢查您的告警政策是否仍然有效，以及通知管道是否仍然可用（例如 Slack Webhook 是否已過期）。
PSE 考試場景
若要實作 SOAR 式的自動化響應，PSE 情境預期的管線是 Cloud Monitoring Alert Policy → Pub/Sub 通知管道 → Eventarc → Cloud Run / Cloud Functions 來觸發補救動作（例如在暴力破解告警時自動隔離 VM）。直接把告警送到電子郵件或 Slack 只能讓人員看到，無法滿足「自動化響應」的要求。
長期 SIEM 保存模式：Cloud Logging → Log Sink → Pub/Sub → Dataflow → Chronicle 或 Splunk。Chronicle 攝取 Google 原生遙測資料（Cloud Audit Logs、VPC Flow Logs、DNS）並提供 12 個月熱保存，而 Splunk 或第三方 SIEM 則透過 Splunk Dataflow template 從同一個 Pub/Sub 串流消費。Log-based metrics 留在 Cloud Monitoring 內做告警；要餵 SIEM 走的是 Log Sink 這條路。
場景 1：檢測暴力破解攻擊
「PSE 需要設置一個告警，以檢測是否有人試圖對遺留應用程序的登錄頁面進行暴力破解，該頁面在 Cloud Logging 中將失敗嘗試記錄為『Login Failed』。應該如何實施？」 解答： 創建一個過濾字串「Login Failed」的 基於日誌的計數器指標。然後，根據此指標創建一個 Cloud Monitoring 告警政策，並設置閾值（例如每分鐘 > 100 次）。將通知管道設置為安全團隊的 Slack。
場景 2：監控挖礦活動
「您希望在整個組織中 Compute Engine CPU 使用率突然大幅飆升時收到告警，這可能表示受到了挖礦攻破。最佳方法是什麼？」
解答： 創建一個儀表板，匯總所有專案中的 compute.googleapis.com/instance/cpu/utilization。設置一個 告警政策，其閾值基於與歷史基準相比的百分比增長（例如 10 分鐘內增長 50%）。
總結清單
- 列出安全儀表板的至少三個關鍵指標。
- 解釋如何根據日誌條目創建告警。
- 識別安全語境下運行狀況檢查的目的。
- 描述減少告警疲勞的策略。
- 了解如何使用 Terraform 管理監控資源。