作者：孫玉梅

背景

在現代雲環境中，安全合規與故障溯源面臨着如下問題：

• 控制面與數據面的割裂：雲端的資源變更（如 OpenAPI 調用）與底層的運行時行為天然處於兩個平行的觀測維度。
• 異構數據的孤島效應：K8s 的編排事件、ECS 的系統日誌以及雲產品的操作記錄分散在不同的存儲介質中，缺乏統一的上下文關聯。

這種多維度的碎片化導致運維與安全團隊深陷“數據豐富但信息貧乏”的困境。當異常發生時，僅憑離散的日誌，很難將一個高階的 API 操作精準映射到底層的進程執行或文件讀寫。為了解決這一痛點，雲監控 2.0 日誌審計提供了一套全鏈路的解決方案。它不僅實現了多源數據的統一接入與自動編排，更引入了實體化建模與告警溯源能力，將離散的日誌轉化為可操作的安全洞察，幫助企業構建起“採集-分析-溯源”的閉環體系，大幅提升合規審計與風險響應效率。

總體架構

雲監控 2.0 日誌審計 [ 1] （以下簡稱日誌審計 2.0）打破了傳統的單點日誌查詢模式，通過統一採集基座配合三大核心分析能力，構建完整的審計體系。

• 統一採集基座：整合雲產品日誌與端側運行時數據，屏蔽數據來源的碎片化差異。
• 實體建模：將離散日誌映射到具體的雲資源對象（如 Pod、ECS、AK），建立資產視角的上下文。
• 跨域關聯：打通 acs,infra,k8s 域，實現跨層級鏈路追蹤。
• 告警調查：提供基於實體的風險發現與溯源能力，支持內置與自定義規則。

在此架構下，日誌審計不再是孤立的數據查詢，而是圍繞資源對象的全生命週期行為分析。

數據接入，無感覆蓋

要支撐起這套全鏈路架構，首要任務是多源數據的統一接入。平台提供了雲產品與運行時兩種採集方式，確保數據覆蓋的全面性：

雲產品自動編排

深度集成了操作審計（ActionTrail）、對象存儲（OSS）、專有網絡（VPC）、負載均衡（SLB）等關鍵產品的日誌。用户無需手動配置複雜的投遞規則，只需通過簡單的接入操作即可自動完成底層資源的編排與日誌流轉，實現“一鍵接入”的便捷體驗。

運行時無侵入採集

僅依靠雲產品日誌無法覆蓋主機和容器內部的安全事件。日誌審計 2.0 使用 Loongcollector [ 2] 通過輕量級、無侵入的方式深入 ECS 主機和容器內部，實時採集文件訪問、進程活動等信息：

• 文件審計：監控關鍵文件（如配置文件、敏感數據文件）的創建、修改、刪除、訪問等操作，及時發現未經授權的文件篡改或數據泄露操作。
• 進程審計：記錄進程的啓動、終止、父子關係、執行命令等信息，發現異常進程行為，例如未知進程的運行、權限提升或惡意程序的執行。

UModel，打破數據孤島

面對海量離散的審計日誌，UModel 通過標準化的實體提取與關聯分析，將碎片化的日誌記錄重構為一張跨域互聯的資產圖譜。如圖所示三大核心域的實體關係：

• 雲產品域（ACS）：基於操作審計日誌，還原資源操作鏈路。從 AK（身份憑證）發起，追蹤雲產品接口調用，最終落地到 OSS、VPC、ECS 等具體雲資源，審計“誰在何時動了什麼資源”。
• 主機域（Infra）：基於系統與運行時日誌，還原底層行為。以主機為錨點，向下解析進程活動，並進一步關聯文件讀寫與 IP 網絡連接，為系統層面的異常操作提供精準的審計線索。
• 容器域（K8s）：基於容器事件與運行時日誌，還原微服務編排邏輯。自頂向下解析 K8s 集羣、節點、命名空間，最終通過 Pod 與工作負載關聯至具體的容器內進程與文件，實現容器環境的深層審計。

UModel 基於日誌上下文，自動識別並連接不同層級的同一實體（如 ACS 層的 ECS 實例即 Infra 層的主機，Infra 層的主機即 K8s 層的節點）。這種全維度的拓撲結構，讓審計人員能夠跨越日誌源的邊界，快速完成複雜的溯源任務。

告警監控與安全運營

當離散的日誌被重構為關聯的實體圖譜後，我們便具備了主動發現風險與快速響應的能力。日誌審計 2.0 將數據洞察轉化為可操作的告警體系，並提供閉環的溯源工具。

• 內置告警規則，開箱即用：我們內置了豐富的雲產品、主機、容器安全告警規則，覆蓋常見的風險操作、異常行為和攻擊模式，一鍵開啓即可防護。
• 告警大盤，全局概覽與啓用分析：告警大盤提供了一個直觀、全面的告警概覽界面，包括告警數量、類型、嚴重程度等。同時還能對規則啓用情況進行分析，幫助用户發現未啓用或配置不當的規則，確保防護無遺漏。
• 威脅狩獵，高危風險操作分析：針對高危風險（如高頻失敗登錄、敏感資源集中訪問）提供操作審計與主機狩獵大盤，識別異常行為模式。
• 告警調查，風險溯源，一鍵直達：告警通過調查按鈕直達風險拓撲，快速鎖定風險實體，並提供告警事件的完整調用鏈和實體關聯圖，將複雜的風險關係以拓撲圖的方式直觀呈現，降低理解門檻。

場景應用

基於上述的實體建模與關聯分析能力，日誌審計 2.0 在實際業務中能夠解決哪些具體的安全痛點？以下是四個核心應用場景的實戰解析。

AK 審計：身份憑證的安全守護

AccessKey (AK) 是阿里雲上重要的身份憑證，AK 泄露往往是嚴重安全事故的開端。區別於傳統日誌查詢，日誌審計 2.0 提供了針對 AK 的全視角洞察。

• 憑證調用鏈路還原：系統不再展示孤立的操作記錄，而是將 AK 的使用軌跡繪製成完整的調用鏈路。管理員可清晰看到該 AK 關聯的角色權限及歷史訪問過的資源，快速釐清“誰持有密鑰，動了什麼數據”。

• 高危行為洞察：通過對控制面（如 API 調用、資源配置變更）和數據面（如 OSS 數據訪問）的操作日誌進行實時分析和可視化展現，無論是控制面的高危操作（如創建高權限用户、刪除關鍵資源），還是數據面的異常訪問行為（如未經授權的 OSS Bucket 下載），都一目瞭然。

關於 AK 審計的詳細介紹可參考：《清理祖傳 AK 不怕炸鍋：基於 UModel 的雲監控 2.0 身份憑證觀測實踐》。

網絡安全觀測：異常網絡流量分析

面對複雜的雲網絡環境，僅靠 IP 地址很難快速定位問題。日誌審計 2.0 集成 VPC 流日誌，讓網絡合規審計變得更加高效。

• 異常公網 IP 訪問：通過地理位置、公網流量等維度，實時監測和分析異常網絡流量的來源，例如攻擊嘗試或突發的不明大流量訪問。

• 受攻擊資產精準定位：當檢測到異常網絡流量時，系統能夠通過 UModel 將這些流量事件與相關的雲資源（如 ECS 實例、容器 Pod、VPC 網絡）關聯起來，並以拓撲圖的形式展現。運維人員無需手動查詢 IP 映射表，即可直接鎖定受影響的業務組件，大幅縮短排查時間。

容器運行時：深入容器內部的威脅感知

在容器化環境中，應用漏洞（如各類 RCE 漏洞）可能導致容器內部被執行未授權命令，此類行為難以通過傳統的流量監控發現。以 Ollama 0.1.34 之前版本暴露未經認證的本地 REST API 為例，它可被濫用寫入任意路徑，甚至覆蓋系統文件。

• 開啓告警規則：創建告警規則時選擇內置的容器審計模板，開啓『容器：不受信任進程讀取敏感文件』，監控對非預期路徑（如 /etc/passwd、/root/.ssh/、/etc/shadow等）寫文件操作，確保此類事件能夠被及時發現。

• 告警調查--進程鏈分析：告警觸發時通過對進程事件以及主機文件操作建模，管理員可以從風險進程順藤摸瓜，找到其上下游調用關係，並明確風險根因。

• 告警調查--全鏈溯源：風險實體分析提供實體級別全鏈路溯源，通過進程鏈路找到風險進程後，將進程所屬的容器建立 K8s 與 Pod 實體關聯，攻擊路徑被清晰地還原為“異常進程-> Pod -> K8s”，從而快速定位存在漏洞的工作負載。

主機暴力破解：系統登錄的風險洞察

主機是企業 IT 資產的核心，暴力破解是常見的攻擊手段。 日誌審計通過 Loongcollector 採集主機系統日誌，開啓針對主機暴力破解的內置告警規則，能夠有效地識別和響應主機暴力破解事件。

• 全局攻防態勢：通過主機獵多維度的儀表盤，聚合展示攻擊源（國家/運營商）、攻擊頻率趨勢，幫助管理員掌握整體的安全水位。
• 入侵影響面評估：一旦檢測到暴力破解告警，系統會自動構建從底層主機到雲端 ECS 的關聯視圖，並展示 VPC、安全組等周邊資產。這種“由點及面”的視角，協助運維人員在發現攻擊的同時，迅速判斷內網橫向移動的風險邊界，制定更精準的封堵策略。

結語

日誌審計 2.0 通過統一的實體模型，它將雲上分散的資源操作與底層運行時行為自動串聯，打破了數據層級之間的壁壘。這不僅讓合規審計能夠快速還原完整的證據鏈，更幫助安全運維人員在複雜的雲環境中，迅速定位風險根源，真正實現從“看日誌”到“懂業務”的安全運營升級。

相關鏈接：

[1] 雲監控 2.0 日誌審計

https://help.aliyun.com/zh/cms/cloudmonitor-2-0/log-audit/

[2] Loongcollector

https://help.aliyun.com/zh/sls/what-is-sls-loongcollector