轉自訂閱號：新浪安全中心
0×00 概要
基於Openresty+的WEB安全防護系統來講， 對於類似的這種系統來說，對其日誌進行的分析是一種很常見的應用場景，對應安全防護系統來說，產生威脅日誌給安全人員看幾乎是必須的。而平時創建日誌分析系統很多都是同時匯聚很多系統的日誌的， WAF，IDS，網關，很多系統產生日誌都可以用同一系統，匯聚日誌，分析日誌。我們先回顧一下基於Openresty+的WEB防護系統的那張圖。
這張圖上圖的非常抽象概況，只是指明了WAF管理結點直接推送數據給日誌中心，而數據的傳輸靠的就是syslog傳輸的，然後， 通過日誌分析系統對WAF威脅檢查的誤報率和漏報率進行統計，但這個圖上的這個日誌系統圖是高度概括的，只是一個方框，而這篇的目地是把日誌分析系統實現具體化一些，將一個框圖內部通過更細的視圖展示出來。
0×10 系統構成圖
這張圖上的日誌系統比上一張圖更具體的說明了其內部構成，並舉了兩個例子，一個是郵件服務的例子，另一個是移動應用網關的系統例子，實際生產中，我們收集了更多系統的日誌，顯然都畫到一張圖上也畫不下。典型的應用系統都會涉及到負載均衡，集群，應用伺服器，而且是多層級的。我們只用少數的例子說明一上問題。
0×11 郵件網關
上圖的左邊的系統，是一個典型的郵件系統的移動端的網關服務，也是一個多層級的基於負載均衡的系統， 當用戶想通過域名訪問郵件網關時，DNS伺服器會根據有戶的線路，把用戶的請求轉給對應線路的郵件網關的負載均衡的IP，在這之前也可在負載均衡前加一個威脅過濾的服務，如果共享一臺的話過濾服務的，這臺伺服器需要有智能選路的功能。當主請求到達負載均衡服務時，負載均衡把請求轉給後端的郵件網關，郵件網關再做完相關的檢查後，會把請求現轉給exchange郵件服務的負載均衡，由負載均衡決定由具體的那臺伺服器進行處理，如果在網關階段主請求就有問題，就會拒絕請求。
在這個過程中，有多少結點產生日誌，就可以匯聚多少的日誌數據。
郵件網關的日誌（Openresty）。
郵件伺服器的的日誌。（Exchange）
WAF系統日誌。
0×12 移動網關
上圖右邊的系統是一個移動網關，移動服務網關和郵件網關功能類似，讓外網用戶的請求通過網關轉給內網伺服器。圖上畫是基於單層負載均衡，當代入到內部系統時，內網的被請求系統是不是基於負載均衡就不考慮了。這個應用系統，日誌中心只是收集網關上的數據，網關代入到內網服務，並不向日誌中心發數據，應用本身就是代理，可以聚合日誌的地方主要是：
辦公移動網關的日誌（Openresty）。
WAF系統。
0×13 日誌分析系統
日誌分析的內部實現要比圖上畫的複雜，圖只是將日誌中心的基本服務部署畫出來，有些mongo資料庫和kafka隊列沒有體現在圖上。日誌中心分析系統的核心存儲中心就是ES集群，還有管理數據存儲的數據管理結點服務， 到管理節點使用的也是負載均衡技術，因為管理結點有一個以上。並且，日誌分析系統，提供數據檢索的WEB服務，與WEB服務相接關聯的業務：
1.日誌審計系統。
2.可視化大屏幕。
3.自動化分析服務。
0×20 安全日誌處理業務
我們構建日誌中心的目地是為了安全運維工作使用，我們對上一個圖進行了加工，將原畫收集兩個系統的圖，只改成收集郵件系統，把空出來的位置，用於展示日誌中心的三大核心業務。
0×21 日誌審計查詢
我們把分布在各個子系統中的日誌收集起來的一個目地是為了集中查詢，我們通過創建安全審計的WEB服務，通過瀏覽器，對散落各地的日誌進行快速的審計查詢。這樣我們不用一臺臺的登上伺服器去查看各個伺服器上的文本日誌，提高工作效率。
0×22 大屏幕可視化
平時我們會關注很多應用系統的服務狀態，當有了日誌系統，我們可以根據系統的日誌，來判斷系統的服務狀態和安全狀態，我們可以通過對日誌進行分析，來判斷系統是否被掃描攻擊。
0×23 智能自動化任務
我們通過啟動定時任務，去定期的檢查系統的安全狀態，生成安全報告。
0×30 業務系統實現
有進對於安全運維的人員來說，不關心系統的具體實現，只關心是否可以提供相應的服務。對於開發人員來說，就要隱藏一些實現細節，讓安全運維人員把精力集中在安全業務上。下面是一個更具體的日誌中心系統的
這是一個抽象的數據流圖，表示了原始的日誌數據的，從那裡的服務產生的，如何通過Input(輸入監聽)和Stram進行邏輯組織的，存儲到了那裡，通過提供服務，對外提供日誌的查詢操作。這個圖從左向右看是：伺服器產生日誌數據，數據通過代理推送到監聽數服務上，通過日誌中心的管理結點，將數據存到集群裡，然後對外開放了WEB REST服務，提供基於HTTP的查詢服務。然後基於查詢服務，再次開發實現了日誌審計查詢，可視化大屏幕展示，和AI自動化處理。
0×40 日誌中心物理部署
我們通過一個更具象化的部署圖，展現出日誌中心服務都應該由那些服務組成。
為了說明問題，還是簡化了系統的展示圖，實際的項目中的部署圖可能與這張圖可能不太一樣，差別體現在，有的服務是多點，有的的單點服務，更理想的狀態，我們還是希望伺服器都是有備份機的，而且是解耦互不影響的。
0×50 總結
有時考慮到企業的運營成本，構建一個日誌中心可能並不能使用商用的系統，比如說Graylog免費，就不買商用的解決方案splunk。那怎麼辦呢？如果預算不夠就用開源吧。 我們本身也基於graylog做了日誌分析系統。無論我們使有什麼樣的工具，對於安全運維來說，常用需求是固定的，而技術是日新月異，比如現在有新的日誌分析產品Aplace Flink等。這章我們只是給出一個大體的日誌中心的架構圖，之後我們會用具體的軟體來實現圖上的架構。
運維幫提供購買雲主機大優惠
主流雲廠商都已和運維幫達成戰略合作，不管是1臺還是100臺，都可以享受到價格優惠，請聯繫群秘書。
歡迎加入「運維幫地方群」，現在有北京地方群、上海地方群、深圳地方群、成都地方群、廣州地方群、杭州地方群。入群請先加群秘書（長按識別下方二維碼），加群秘書時請告知所在城市及公司。
群秘書微信，掃描下方二維碼