免責聲明：本文由Hilt投稿。 Hackread.com並未獨立核實所有說法，也不對文中提及的任何特定產品或服務進行背書。
安全團隊很少明確指出，事後檢討中存在著一個反覆出現的模式：在大多數安全漏洞事件中，底層活動並非隱形，數據發生了移動，進程存取了超出其預期範圍的檔案。
網路連線已連線至先前未知的目的地。事後看來，系統事件的順序構成了一條清晰且可追溯的鏈條。故障並非在於訊號的缺失，而在於訊號源頭所在層面的可見性缺失。這反映了現代安全架構的結構性局限性，即大多數監控系統並未部署在資料實際移動發生的層面。
現代基礎設施中的可視性問題
大多數安全組織已經認為他們的環境是「受監控的」。基礎架構通常包括集中式日誌管道、基於主機的代理程式、應用程式遙測、SIEM 系統以及聚合來自多個來源事件的警報層。
然而，一個更精確的操作性問題卻很少能得到可靠的答案：目前哪個主機上的哪個進程正在存取哪些數據，以及這些數據接下來會流向哪裡？在大多數生產環境中，這個問題無法全面解答，並非因為缺乏監控手段，而是因為遙測資料主要是在錯誤的抽象層收集的。現代可觀測性架構主要基於使用者空間程式偵測：應用程式日誌、SDK 級鉤子、運行時庫和 API 級事件擷取。這些機制反映的是應用程式選擇暴露的內容，而不是作業系統實際執行的內容。因此，它們只能提供部分系統行為的可見性，且受限於開發者定義的程式偵測點。相較之下，資料的實際移動發生在作業系統層面。
檔案讀取、網路寫入、進程建立、記憶體映射和進程間通訊等操作均以核心介導的事件形式實現。從應用程式邏輯的角度來看，這些操作並非可選項；它們透過系統呼叫強制執行，並作為標準進程執行的一部分由核心執行。
因此，核心可以觀察到系統層級資料移動的完整記錄，而這並不依賴應用程式偵測或開發人員的日誌記錄決策。
敵方已經利用了哪些漏洞
當攻擊者在生產環境中站穩腳跟時，他們的活動必然會透過核心介導的路徑執行。進程執行、權限提升、持久化機制、檔案系統存取和網路通訊都依賴作業系統強制執行的系統呼叫。即使惡意行為是在使用者空間發起的，其執行最終也由核心調度、驗證和協調。因此，內核會捕獲諸如 `get_remove()`、`get_remove()`、`get_remove()` 等事件 execve以及 openat相關 connect的系統調用，而不管這些事件是如何或在何處觸發的。這種差距並非理論上的。在事後調查中，經常發現惡意活動在系統呼叫層面完全可觀測，但由於核心邊界缺乏偵測手段，更高層級的遙測管道卻從未將其暴露出來。
同樣的限制也適用於非對抗性故障。配置錯誤的服務可能會將敏感資料寫入非預期目標，第三方庫可能會發起意外的網路通信，計劃任務可能會存取未經授權的文件，而不會產生任何應用層日誌。這些行為並非不存在，只是使用者空間可觀測性系統無法捕捉它們。
傳統的資料遺失防護 ( DLP ) 系統試圖透過對預定義資料流強制執行靜態策略來緩解這個問題。然而，靜態規則在動態分散式系統中存在根本性的限制。關鍵問題不在於規則是否被違反，而在於實際執行時間行為是否偏離了預期的系統行為。
為什麼資料遷移才是正確的抽象概念
傳統的安全架構通常圍繞著靜態資產建構：資料庫、API、儲存系統和網路邊界。雖然這種模型直觀易懂，但它無法反映資料在分散式系統中的行為。
在現代基礎設施中，敏感資料會在多個執行上下文中不斷轉換和傳輸。單一查詢結果可能在應用程式記憶體中傳播，被下游服務處理，經過訊息系統傳遞，被緩存，最終透過網路介面傳輸。在每個階段，資料的位置以及與資料互動的進程集合都會改變。
孤立地保護單一資產並不能保證整個系統的安全。系統可能在資料庫層實施了嚴格的保護措施，但仍允許下游服務在合法存取後竊取資料。在這種情況下，安全漏洞並非發生在受保護的邊界，而是在可信任元件之間運行時資料傳輸的過程中。安全性和合規性應該基於資料移動而非靜態資料位置來定義。相關問題變成：
✔  接下來它去了哪裡？
✔  數據來源是什麼？
✔  哪些進程存取過它？
✔  該序列是否符合預期的系統行為？
✔  內核級(Kernel)可見性提供了什麼
要回答資料移動的問題，需要觀察資料實際移動發生的層次。每一次檔案讀取、網路寫入或進程與資源的互動都由作業系統核心協調，核心位於軟體和硬體之間，負責仲裁所有對實體資源的存取。使用者空間進程無法直接存取硬體或記憶體資源；每個操作都必須經過核心控制的執行路徑，該路徑負責強制執行權限、將請求轉換為硬體指令，並最終驅動底層設備。
從系統角度來看，核心是機器內部資料移動的最底層、最完整的觀察點。任何使用者空間進程在存取資源時都無法繞過內核，因為所有此類操作都必須透過內核控制的系統呼叫介面執行。它是資料移動的完整權威記錄。
在 Hilt，我們基於此基礎，利用 eBPF 技術建構了可觀測性架構。 eBPF 允許檢測程式直接在核心中執行，並附加到資料移動發生的系統呼叫和執行點。當進程開啟檔案時，我們可以看到；當資料寫入網路套接字時，我們也可以看到。
當進程產生子進程、建立進程間通訊 (IPC) 通道或映射記憶體區域時，我們都能觀察到這些變化。所有這些操作都不需要對被監控的應用程式進行任何更改。無需 SDK、程式碼修改或開發人員進行任何程式偵測工作。觀察完全在應用程式底層進行。這種設計提供了系統行為的真實表示，反映了跨進程、容器和主機的實際運行時執行。
從內核事件到行為模型
原始內核遙測資料雖然完整，但會產生大量事件流，這些事件流無法直接用於安全性或合規性決策。為了解決這個問題，我們將系統活動建模為一個不斷演化的行為圖：
✔  隨著系統執行情況的變化，圖表會即時更新。
✔  邊代表從核事件中觀察到的交互作用
✔  節點代表進程、檔案、網路端點和進程間通訊通道。
這種架構能夠處理一些基於日誌的系統難以回答的查詢，例如進程是否曾與特定網路目標通信，或者服務的檔案存取模式是否與歷史行為一致。在生產環境中，此架構每秒可處理數百萬個核心級事件，且每個主機的 CPU 開銷低於 0.2%。在許多環境下，與用戶空間檢測方法相比，核心級調度效率能夠降低整體系統延遲。
使用 Hilt 進行資料移動治理
Hilt 將內核層級檢測、時間重構、因果分析和自適應行為檢測整合到單一系統中，該系統可在分散式環境中持續運作。該平台並非將可觀測性、安全監控和合規性審計視為獨立的層，而是將它們統一到一個基於核心的系統行為資料模型中。
在生產環境中，我作為技術長 (CTO) 領導 Hilt 的技術方向。該系統部署在基礎設施環境中，為管理數十億美元資產的組織提供支援。該平台的設計無需對應用程式進行任何修改即可運行，從而能夠跨異質堆疊進行部署，並在主機、容器和服務之間保持一致的可見性。
這些系統背後的核心工程工作是在 Hilt 公司的我的技術領導下開發的，與 David Gu 和 Zin Bitar 等工程師合作，他們為內核程式偵測、分散式資料處理和即時行為管道實現做出了貢獻。

本文作者Alexandre Genest 是 Hilt（17587597 Canada Inc.）的首席技術官，負責領導核心級資料移動可觀測性和治理系統的開發。他的工作重點是作業系統程式偵測、分散式系統設計以及跨異構運算環境建構高效能基礎設施。他擁有豐富的經驗，曾為管理大規模敏感資料工作負載的組織建立可擴展、低延遲的平台。

資料來源：https://hackread.com/kernel-observability-for-data-movement/