云原生入侵檢測趨勢觀察
什么是云原生
以下是云原生計算基金會（CNCF）對云原生的定義：
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。
趨勢一：資產多樣化
在IDC時代與企業上云初期，由于企業應用的部署環境均以linux/windows為主，因此反入侵產品多以解決主機安全為主要目標。這一階段入侵檢測方法論是在做"貓捉老鼠"式的單點對抗（一個例子是參照ATT&CK構建入侵檢測模型），作為入侵檢測一線實踐者，我們看到各廠商的檢測點大多圍繞linux/windows的細節攻防點展開。
例如HIDS產品中這樣的模型：
- 檢測/etc/passwd /etc/shadow /etc/crontab的讀寫行為
- 檢測windows注冊表異常操作
- 檢測powershell hidden執行異常指令
- 檢測java應用通過wget/curl指令下載二進制文件并啟動
云原生時代，企業的核心資產除主機(VM)外，還有容器(Docker、K8s)以及諸多云服務，"主機安全"只是其中一部分。例如容器安全廠商 twistlock 的資產管理與可視化維度：
反入侵需要cover的"資產"形態將變得復雜，資產梳理、監控、可視化、ACL將更加困難。
部分資產生命周期大幅縮短，甚至秒級釋放，這些高彈性的環境使攻擊者的持久化更加困難，實時的入侵檢測與響應或變的不再必要。
趨勢二：服務碎片化
自Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念以來，幾乎所有云原生的定義都包含微服務。微服務架構將復雜應用按function切分，使服務解耦，內聚更強，變更更易。
在此場景下，審計與管控邊界由"網關/主機"變成了"服務/API"，系統內部的原子服務間的通信將變得復雜，難以實施管控與審計。主機粒度的"微隔離"技術將不能滿足應用級別的審計需求，安全邊界將由業務定義。
Microservices "Death Star":
NeuVector K8s Pod粒度的流量審計:
趨勢三：中間件井噴
容器作為云原生的基礎設施，已經被各云廠商產品化。在這一過程中，各廠商serverless的實現標準、容器隔離方案、依賴的中間件以及需要用戶承擔的風險各不相同。
CNCF Cloud Native Landscape:
一個常見的攻擊場景：企業在K8s集群中引入了不安全的第三方插件。攻擊者進入Pod后，通過未授權訪問或漏洞攻擊第三方組件，并利用這些組件的高權限賬戶操縱K8s集群。
傳統的入侵檢測方案，從對漏洞和攻擊面的角度出發，梳理出主流中間件及應用的攻擊手法，希望盡可能覆蓋已知漏洞的利用方式。面對云原生中間件的爆發，企業在構建應用時的依賴及其復雜，任何一個組織或廠商所掌握的"漏洞庫"已經難以滿足其客戶需求，這對安全產品的漏洞/攻擊面管理能力提出了更大挑戰。
趨勢四：基礎設施默認安全
下圖簡要描述了企業應用在容器化的不同階段，云上用戶自擔的安全責任區（深藍色）、用戶與廠商共擔區間（淺藍色）以及云廠商默認安全區間（灰色）的變化情況。
從傳統的VM上直接部署業務，到VM+容器、VM自建K8s集群、再到購買云廠商提供的K8s托管服務、云廠商的輕量級容器服務以及serverless，隨著業務容器化的程度加深，用戶的"安全責任區"逐步上移，對基礎設施的安全需求（也是安全產品的價值空間）逐步減小。
一種傳統主機安全的入侵檢測思路是"用底層日志解決上層問題"：
- 當流量層遭遇混淆對抗時，入侵檢測能力下沉到端上用戶態行為審計，這樣就可以避免對每個web漏洞case by case的覆蓋，降低同一維度對抗成本。
- 用戶態行為遭遇對抗時，戰場還可以繼續深入到kernel層（如提權逃逸類的檢測）。
在云廠商提供的服務中，隨著底層基礎設施用戶不可觸達，這種更深層次的對抗逐漸成為服務商的特權，第三方安全廠商將難以向云服務部署自己的探針，相反，云廠商將結合自身的服務架構賦予用戶側更強的安全能力，包括檢測的下沉以及云原生的"檢測-響應-修復"閉環流程。
結論：入侵檢測"業務化"，行為分析將成為核心能力
無論是從云服務的普及還是microservice的復雜程度來看，API通信都行為將成為服務間交互的重要一環，越來越多本地無鑒權的API通信將從轉向有鑒權的服務框架。反入侵對于底層資產的監控趨于復雜的同時，UEBA技術將在業務層發揮更重要的作用。
試想在云原生場景中，攻擊者通過WEB漏洞入侵云廠商的彈性容器服務，容器內部沒有常見的linux命令和依賴庫（甚至在某些serverless場景下無法寫文件），且容器逃逸問題已被云廠商默認解決，攻擊者只能通過服務自身權限或竊取本地API通信憑證進行橫向移動。在此情況下，對API訪問行為的分析將成為反入侵的有效手段，它具有足夠的可行性和通用性，是適合產品化的技術點。
事實上身份認證、鑒權、UEBA以及數據安全是一個整體設計，這一點零信任架構的已經給出了實踐。其嘗試對任何接入系統的人/事/物進行認證，構筑在認證之上的入侵檢測，實體畫像、行為分析會其是必不可少的部分。
從技術成熟度來看，用戶畫像及行為分析已經在搜索推薦和風控領域得到廣泛的驗證。借鑒這些賽道的經驗，我們已經將圖計算落地在檢測和響應階段，實現對安全事件鏈路更長、時間跨度更久的分析。在未來高度API化的場景中，基礎攻防將進一步"業務"化，我們將看到端數據、API日志與威脅情報在更高維度的結合。
