ClickHouse與威脅日誌分析

　　本文轉載自微信公眾號“新浪安全中心”，原文作者：糖果LUA

　　概要

　　威脅分析現在已經成為日常工作的一部分。基於ELK這種大資料工具已經成為日誌分析的一個很流行的選擇方案，開源免費部署方便，對日誌的檢索及匯聚提供很好的使用者體驗。之前糖果實驗室就介紹過基於Graylog這種類ELK工具的整體日誌處理方案。在經過生產實踐後的體會總結，發現了這種日誌處理方案的好處，也發現了不足。隨著後續系統不斷接入新的安全日誌資料，更多校的日誌分析需求來講，系統變的會越加複雜。針對複雜的策略查詢，有時我們基於ES和REST API的日誌資料提供方式，在處理複雜查詢開發時，開發效率會隨著規模變大而變慢，我們需求一種更高抽象級別，和業務資料的直接關聯的業務性語言，類似於SQL或是DSL一樣的操作指令，讓安全策略實現的落地成本降低。

　　ELK模式回顧

　　為從上層部署更好說明問題，我們用卡通一點的方式來描述系統結構，不涉及到更多的負載均衡和線路保障這種細節點。我們先回憶一下基於類似Graylog的日誌分析方案。日誌的資料的被封裝抽象成Stream流的概念，引用Pipeline管道，把日誌從邏輯上進行更高一級的抽象，這樣我們不對直接面對檔案和索引這些概念，有了Stream、Input、Output、Pipeline、這種概念的模式設計，可以更好的把原生的日誌資料更好的歸類和業務靠近。

　　從日誌的收集、到資料的格式化、到ES儲存、到REST API資料對外提供查詢、到自動化查詢、到資料的視覺化是我們一般的使用套路，我們在這條思路上耕耘了有一段時間，更多的文章可以參考糖果實驗室之前的文章，這裡就是高度的概括一下這種系統的結構。

　　戰鬥民族的武器ClickHouse

　　我們再介紹一下基於ClickHouse的資料採集分析方案。其實從資料的收集、處理、查詢、展示，對使用者來說體驗上大多數也有幾分類似，不同的一點是ClickHouse提供SQL方式的查詢。本身Graylog這種也內含了MongoDB和Kafka等部件，而ClickHouse不是一種整合的解決處理方案。 相對簡化的介紹一下。從系統部署構成來看，很相似。

　　方案間的差異性

　　ClickHouse和ES是兩種不同的資料檢索引擎。ClickHouse提供了基於SQL的查詢功能， ClickHouse對SQL支援和效能如何，在後期我們會給出相關的資料。像Graylog這種整體解決方案，提供了自己的資料查詢DSL，但這種DSL是獨立於Graylog本身的系統，而SQL具有更強的通用性。ES也支援ES SQL，但這點上就是誰用誰知道了。這兩種方案核心的區別在於ES和ClickHouse不同的資料檢索方案，安全業務會針對不同的資料產生不同的安全審計需求。對於資料收集和資料的展示的都是類似，當然ES也有ES SQL,但這不是SQL之間區別，而是兩種生態和設計的不同。

　　我們可以類似使用MySQL的方式來使用ClickHouse的表， 被監控伺服器將自身的資料透過特定的工具推送Kafka上，ClickHouse端去取得推送的資料，然後將資料存到二維資料結構的表中，之後我們就可以使用SQL語名去實現日誌安全自動審計。Graylog這種類ELK的服務我們已經在生產中使用了，基於REST API為核心的設計很方便前端和移動端的審計應用擴充套件。基於威脅資料分析，我們基於ClickHouse實驗出新的解決方案，重要針對的是複雜的資料檢索和業務資料碰撞。有了SQL這種高抽象實現，減少純程式碼對DSL操作依賴，程式碼寫的少了，安全策略都被翻譯成SQL語句，但同時底層的引擎又不一樣。

　　方案間的共性

　　對於使用者來說，這兩個方案總體思路上還把日誌和“流”和“管道”聯絡在一起，邏輯上的日誌資料流向，無論採用什麼樣的工具和儲存，日誌資料聚合模式都類似，只是協議上，是採用syslog協議，還是JSON協議，還是兩者都支援，基於資料匯聚的角度來說，兩種方案都可以達到目標。但對安全策略實現，那種方案更快，更方便，後續我們還會有新實驗記憶體和資料實現。最大的共性，就是資料收集到外放資料的模式類似。

　　上面的圖大大的簡化了實際生產中的服務物理部署，用單點代替叢集。簡化到最後，就可以相對清晰的看到日誌資料的流向。從訪問者在請求服務者時產生的資料，到資料推送到Kafka佇列，再由Kafka消費者消費資料給ClickHouse儲存，然後提供Openresty為基礎的API閘道器，再提供給API使用者作用。　　

　　基於Graylog、ELK的API閘道器是基於ES的資料檢索，閘道器會把安全策略轉換成查詢， 而基於ClickHouse的API閘道器，採用的就是基於ClickHouse的SQL查詢為基礎的安全策略落地執行。我們在設計系統時，讓安全策略和系統不依賴，或者說通用的安全策略不考慮實現的方案到底是ELK還是ClickHouse， 只要是安全分析策略，用一種指令碼或是類似DSL的語言可能解析和執行即可。

　　總結

　　ClickHouse是戰鬥民族的產品，CloudFlare公司已經用於生產分析中，也將繼續探索這些產品的新動向和實踐。將流量分析和日誌分析統計結合起來分析威脅，發現威脅。一些系統形式都是手段，系統可以實現安全人員的策略並行之有效的解決安全問題，是實踐要達成的目標。我們可以基於ClickHouse開發更高階抽象的DSL描述安全的人員的安全策略與其它系統聯動，完成威脅的分析與防護。後續會介紹一些相關的設計和工具及程式碼。