https://www.informationsecurity.com.tw/Seminar/2024_PaloAlto/
https://www.informationsecurity.com.tw/Seminar/2024_PaloAlto/

觀點

Log管理與開源碼工具應用新思維

2012 / 11 / 14
余俊賢
Log管理與開源碼工具應用新思維

現在已經進入了一個資訊爆炸的Big Data時代,企業在規劃Log稽核軌跡管理時,首先要考量建構規劃Log管理的目標,既然名之為稽核記錄,其特性則為提供企業在IT管理方面、商業智慧(Business Intelligent, BI)與應用程式效能優化的基本依據。

一般而言,不外乎留下IT活動的軌跡記錄,從資訊安全的角度來看,則是人事時地物的資訊提供存查,作為日後究責與分析事件的資訊來源之一。從IT管理角度,則可以得知目前軟硬體的使用率(Utilization)與效能,亦可從中發現一些除錯資訊與效能瓶頸,包含應用系統效能分析、除錯等附加價值;從商業智慧與決策角度而言,從資訊系統(包含ERP、POS、CRM、SCM)與電子商務平台中獲得的用戶行為分析、產品銷售分析等均可利用平時所蒐集的Log記錄作為資料來源。

Log 稽核軌跡管理似乎好處多多,但為何以前不做,而現在必須要做,或至少要先規劃?原因是,時候到了!資訊科技發展至今已經累積許多資訊系統與架構,甚至疊床架屋分不清東南西北,需要更好更準確的資訊依據,用在未來改善與發展下一代的資訊環境架構。從資訊安全需求與個資法規遵循的目的上來看,必須留下足夠的證據與軌跡,方可說服與驗證在資訊環境中的個資活動與安全控制之施行。

本文針對Log管理的規劃、導入與可應用之Open Source工具作一介紹,期能在Big Data資料大航海時代下,幫助企業打造符合需求、成本的方案。

 

Log管理常見4大問題

我們先從Log管理常見的問題與挑戰談起,規劃Log管理方案如果沒有一個方向及目標,經常會遇到以下的問題及挑戰,唯有事先了解這些問題,才能走上正確合適的航海方向。

在此用幾個案例說明可能會遭遇的問題與挑戰:
1. 容量爆炸:某企業採購Log管理工具後,將網路、作業系統、網站、資料庫等項目的軌跡資料均集中收納,結果兩個月後,Log管理工具已經無法負荷,容量爆炸而停擺,若欲擴增容量則須加收授權費用與採購硬體設備。

2. 搜尋速度與規則:上面的案例同時也發生了,欲搜尋某天發生之異常網路活動的軌跡記錄時,搜尋上遇到了麻煩,速度非常慢,只好人工從Log管理工具的資料庫中篩選過濾出當天資訊再進行分析。換言之,企業終於等到一天可以讓Log管理工具可以大顯身手時,才發現這個武功高手吃的太撐,根本動不了。 


 
當企業欲搜尋某天發生之異常網路活動的軌跡記錄時,經常會發生搜尋速度很慢、最後改用人工篩選的情形,這通常是因為Log管理工具存放太多資料,才會拖累搜尋速度。

3. 涵蓋範圍不足,沒有集中管理:某資訊人員A規劃IT管理機制與BI專案時,因為預算因素與產品授權限制,將原本應該要放在一起集中處理的軌跡記錄分開而且分散在不同實體環境中,結果第一個月的BI分析報告出來就被打槍中彈,人工分析正確性高於工具產出。

4. 造成新的瓶頸:某企業大張旗鼓推動Log管理機制後,試行期間不夠長、不夠完整,結果真正上線後,發生了很多新的靈異現象,以往是兩三個月才發生一次的問題,通通都在一周內陸續出現,最後經由專家分析後歸責於Log管理機制所造成新的網路瓶頸。

Log管理規劃步驟

從上述案例中可以知道,要完成Log管理規劃的確需要事前有萬全準備,執行有過人毅力,方可輕騎過關。以下為Log管理規劃步驟的建議與分享:

一、確認目的
首先要能夠確認規劃Log管理的主要目的,如管理用途(存取控制記錄)、應用程式效能分析、商業活動之趨勢分析,或是因應稽核的要求,又或者可以因應主管機關檢查與提出數位證據,也就是對於個資安全軌跡管理合規的需求。

二、符合政策
規劃時應該依照企業對於軌跡記錄的政策進行,如果沒有相關政策,則需要得到管理階層對此之意見與方向,例如:哪些軌跡記錄需要保存?保存多久?過了保存期限的記錄如何處理。這是在政策與原則設定時必須要確認的方向,如果以個資安全角度來看,可能需要包含對於不同個資類型(員工、客戶、股東、供應商等)要做基本的分類標示,方可在未來進行搜尋與產出報告時,有足夠的資訊應用於法規遵循報告,最終可達成政策要求,才算是一個合格的Log管理機制規畫。

三、確認範圍並進行評估
根據上述之方向與規則,進行方案評估,一般評估項目與方式可以分為功能面與管理面。根據保存政策、範圍,您應該可以計算出每天容量(volume per day)及保存期限(retention duration),據此估算出所需容量與處理能力。可以衡量的指標如下:
1. 處理能力:每分鐘可以處理的Log數量、每分鐘可以處理的Event數量、即時或批次傳送。
2. 容量:總容量、每日容量、備份容量,包含管理政策中對於線上保存期限、離線保存期容量之需求是否滿足。
3. 擴充能力與可靠度要求:包含發生錯誤的應變機制、備援機制與擴充方式。Log儲存是否需要備份,可視其關鍵程度而定。另外可以透過系統機制原生的擴充性與高可用性達成,加上儲存機制的考量,目前應該以NoSQL資料庫為主要發展方向。

導入評估時可以考量下列事項,是否集中化、是否整合現有的儲存與Log管理機制,其實許多企業已經有建置部分的管理機制,或者有資安事件管理(SIEM)的環境,要如何與現有環境整合也是一個必須要考量的項目。

最怕的就是片面的Log管理,會造成資料涵蓋面不足或未來擴充時的成本,包含範圍的確認:是否跨外部機房、DMZ區與內部網路,是否包含網路、對外服務、系統、應用程式、用戶端點等,尚可以再區分更細緻到各種類型Log中的不同等級與用途。

圖1、Log管理規劃步驟

 

以個資安全為核心的Log記錄來源
- 身分鑑別與授權管理相關(IAM):舉凡系統帳號管理、使用之記錄、權限變更之記錄等。 
- 資料本體安全相關(data oriented):重要資料內容所流經之相關資訊節點,包含外部網站、電子郵件、資料庫、內部應用系統、資料備份、印表機到對外的資訊服務與通訊管道等。 
- 資訊環境相關(IT security):實體安全、端點安全管理、USB管理以及各種安全設備,主要是發現對個資所處環境之危害能夠有記錄可循,很多非故意、非過失的外力原因便是由資訊環境中發酵。 
- 流程相關:這是廣義的記錄,對於上述項目之管理活動。


 

導入Open Source工具應用新思維

開放原始碼專案提供Log管理基本的方案,其中不乏已具備商業水準的專案,規劃評估與導入Log管理方案時,也可列為考慮名單中。利用較低成本的方案先試行,一方面了解企業在這一塊真正的需求,另外也可以從中優化與改進導入方式及指標。

Log管理基本上可以分為三階段來看待,每一個階段各有合適的工具方案可以採用。集中階段的重點在於決定哪些項目要進入LM,是否能支援各種不同的格式,能否採用共通的Log格式,如:syslog,內容是否可以滿足管理及分析需求。至於管理階段,則需要較合適的介面,可以收納並設定各種規則,提供給分析與視覺化產出階段,產出固定報表、視覺化呈現分析結果。各階段可採用的工具方案如表1所列,企業可搭配服用,會有讓您眼睛為之一亮的收穫。

表1、各階段Log管理可採用的Open Source方案表

階段

可採用之Open Source方案

(部分方案已涵蓋各階段)
集中

1.   rsyslog

2.   syslog-ng

3. Post Remote Log
管理\儲存

1. logstash

2.  Kibana

3.  OSSEC

4.  GrayLog2

5.  OpenTSDB

6. Scribe
搜尋\分析\報表\呈現

1.  ElasticSearch

2.  OSSIM

3. Graphite

資料來源:本文作者整理,2012/10。

 

本文作者現為資安顧問。如您對本文有任何感想,歡迎來信交流:isnews@newera.messefrankfurt.com