大數據處理技術在安全審計系統中的應用

許　杰，冷　冰，李明桂，丁文超

(中國電子科技集團公司第三十研究所，四川 成都 610041)

?

大數據處理技術在安全審計系統中的應用

許杰，冷冰，李明桂，丁文超

(中國電子科技集團公司第三十研究所，四川 成都 610041)

隨著大數據時代的到來，數據出現了爆炸式的增長。這些海量數據的出現，影響了很多現有數據存儲、處理和分析系統，其中就包括在網絡安全中發揮著重要作用的審計系統。目前的審計系統中使用關系數據庫對數據進行存儲和處理，由于關系數據庫的局限性，使得審計系統無法存儲和處理大數據。針對該問題，提出了一種兼容現有系統的大數據存儲方法，能夠有效的解決大數據存儲問題。同時，為了解決大數據(HBase)檢索效率低下的問題，提出了一種使用Solr建立二級索引的方法，大大的提高了檢索效率，滿足了審計系統存儲和處理大數據的需求。

大數據；審計系統；HBase；Solr

0　引　言

計算機網絡安全審計(簡稱為安全審計)是指按照一定的安全策略，利用記錄、系統活動和用戶活動等信息，檢查、審查和檢驗操作事件的環境和活動，從而發現系統漏洞、入侵行為或改善系統性能的過程。審計系統從審計內容上來看主要包括三方面：系統審計、應用審計和用戶審計。

系統審計：主要針對系統的登錄情況、用戶ID、登錄嘗試日期時間、退出日期時間、所使用設備、運行程序等時間進行審查；

應用審計：主要針對應用程序的活動信息，如運行成功或失敗，打開或關閉數據庫或數據文件，讀取、編輯、刪除記錄等特定操作，以及打印等行為；

用戶審計：主要審計用戶的操作活動，如用戶直接啟動命令，用戶所有的認證操作，用戶所訪問的文件和資源等信息。

隨著網絡的繁榮發展及日益普及，各種具有網絡功能的設備越來越多，審計系統開始從內網向外網擴展，從有線網絡向無線網絡覆蓋。由于這種數據從單一到多渠道的變化使得數據量出現了指數級的增長，這就對現有的審計系統提出了新的應用需求，并促使審計系統向具備大數據存儲、處理和分析能力方向發展。

大數據處理的數據包括結構化、半結構化和非結構化數據。半結構化、非結構化數據是相對于結構化數據而言，不方便用數據庫二維邏輯表來表現的數據，如：辦公文檔、文本、圖片、XML、圖像和音頻/視頻等?，F有的審計系統中存儲的數據主要是從各類終端設備上采集的結構化數據，目前并不涉及半結構化、非結構化數據。隨著數據量的海量增長，審計系統中的關系數據庫已不能有效的存儲、檢索和處理這些結構化大數據。這就需要使用大數據技術來解決審計系統對大數據存儲能力不足、檢索效率低下等問題。

本文針對審計系統中大數據存儲能力問題提出了一種有效的存儲方法，同時為了提高大數據的檢索效率，提出了一種建立二級索引的方法。

1　大數據相關技術

大數據是指在所能容忍的處理時間范圍內，數據規模超過常規數據庫工具獲取、存儲、管理和分析能力的數據集。大數據具有5V1C的特征：數據量巨大(Volume)、數據類型繁多(Variety)、生成速度快(Velocity)、數據易變化(Variability)、數據真實性(Veracity)、數據復雜性(Complexity)[1-2]。

目前，圍繞著大數據的獲取、存儲、管理和分析等已經建立了以Hadoop為核心的大數據生態系統，包括Ambari、Avro、Cassandra、Chukwa、HBase、Hive、Mahout、Pig、Spark、Tez、ZooKeeper等[3-5]。這些開源系統被國內外各大廠商和公司使用，或直接使用，或根據業務需要進行修改后使用。由于大數據技術較多，因此僅對本文中使用的相關大數據技術進行介紹：

(1)Hadoop是一個跨計算機集群可以使用簡單編程模式進行大規模數據存儲和分析處理的分布式軟件框架，是專為離線和大規模數據分析而設計的。Hadoop=HDFS+MapReduce，HDFS是文件系統，提供海量數據存儲能力；MapReduce提供數據處理和計算能力。

(2)HBase[6]是一個高可靠性、搞性能、面向列、可伸縮的分布式存儲系統，利用HBase技術可以在廉價的PC Server上搭建起大規模結構化存儲集群。它構建在Hadoop基礎設施之上，依托于Hadoop的迅猛發展，HBase在大數據領域應用越來越廣泛，成為目前NoSQL數據庫中表現最耀眼，呼聲最高的產品之一。

(3)ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調器，是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、名字服務、分布是同步、組服務等，是Hadoop和HBase的重要組件。

2　審計大數據存儲

現有的審計系統基本上都采用關系數據庫(MySQL，Oracle，SQL Server等)進行數據存儲，而且系統的數據獲取，數據存儲和數據分析整體架構較成熟，如果直接將關系數據庫存儲部分替換成HBase存儲，不但會對相關的模塊產生影響，而且也會造成系統整體運行不穩定的情況，風險較大。因此，我們采用現有存儲系統與大數據存儲并存的方法，改進現有審計系統無法存儲海量數據的問題。整體架構如圖1所示。

圖1　審計大數據系統整體架構1

從圖1中可以看出，數據存儲部分是關系數據庫和HBase共存的模式，在該模式下可以有兩種策略：

(1)系統從終端接收上報數據后，可以將數據同時存入關系數據庫MySQL和HBase，等整體系統穩定后在慢慢過渡到數據存儲全部由HBase接管，最終放棄關系數據庫。

(2)將數據根據時間段進行分別存儲。實時接收的數據包括近期(三個月或半年)的數據存入關系數據庫， 歷史數據存入HBase，系統根據需要讀取不同存儲系統數據進行分析和處理。

3　HBase二級索引

通過使用大數據存儲技術可以有效的解決審計系統海量數據存儲的問題。這是由于HBase是一個面向列存儲的分布式存儲系統，它的優點在于可以實現高性能的并發讀寫操作，同時HBase還會對數據進行透明的切分，這樣就使得存儲本身具有了水平伸縮性。但HBase也有缺點，它不支持復雜條件查詢，這與它的數據組織方式有著密切的關系，在邏輯上，HBase的表數據按RowKey進行字典排序，RowKey實際上數據表的一級索引(Primary Index)，由于HBase本身沒有二級索引(Secondary Index)機制[4]，基于索引檢索數據只能單純依靠RowKey，為了解決該問題，一種常用的方法是將可能作為查詢條件的字段拼接到RowKey中，但無論如何設計，單一RowKey固有的局限性決定了它不可能有效的支持多條件查詢。因此，我們提出使用一種高效的索引工具Solr[7]來解決HBase二級索引的問題。Solr是一個高性能全文搜索引擎，它提供豐富的查詢語言，同時實現了可配置、可擴展并對查詢性能進行了優化，可實現高效的檢索。使用Solr后的整體架構如圖2所示。

使用Solr提供的API接口可以簡單方便的為HBase建立二級索引，提高檢索效率并支持多條件查詢。但由于Solr并不是專為優化HBase而開發的系統，對于HBase的增量更新，Solr是無法感知的，這就會造成數據和索引之間出現不一致的現象。

HBase在0.92版本后引入了一種協處理器(coprocesser)機制[8]，該協處理器可以實現建立二級索引、復雜過濾器以及訪問控制等。coprocesser機制建立了一個框架，它為用戶提供類庫和運行時環境，使得用戶的代碼能夠在HBase region server和master上處理。coprocesser分兩種類型：系統協處理器可以全局導入region server上的所有數據表；表協處理器是用戶可以指定一張表使用協處理器。協處理器框架為了更好支持其行為的靈活性，提供了兩個不同方面的插件，一個是觀察者(observer)，類似于關系數據庫的觸發器；另一個是終端(endpoint)，動態的終端類似存儲過程。

圖2　審計大數據系統整體架構2

(1)觀察者(observer)允許用戶通過插入代碼來重載協處理器框架的upcall方法，具體事件觸發的callback方法有HBase的核心代碼來執行。協處理器框架處理所有的callback調用細節，協處理器本身只需要插入添加或改變的功能。其工作流程如圖3如所示。

圖3　Region Observer工作流程

(2)終端(EndPiont)是動態RPC插件的接口，它的實現代碼被安裝在服務器端，從而能夠通過HBase RPC喚醒?？蛻舳祟悗焯峁┝朔奖愕姆椒▉碚{用這些動態接口，它們可以在任意時候調用一個終端，其實現代碼會被目標region遠程執行，結果會返回給終端。其整體流程如圖4所示。

圖4　終端(EndPoint)工作流程

本文中需要解決的問題是當HBase中的表出現插入，添加，修改和刪除數據的情況下，更新相應的Solr二級索引，從而達到增量更新的目的。因此，結合上述的HBase協處理器的功能，采用觀察者的方法，將編寫好的更新Solr二級索引代碼加載到相應的HBase中的數據表上，當該表出現數據變化時，通過coprocesser機制將該變化更新到相應的Solr索引中。

4　效果評價及分析

4.1環境搭建

為驗證本文方法的改善效果，采用一臺服務器，8臺虛擬機搭建大數據存儲及二級索引試驗環境，具體配置如表1所示。

表1　大數據試驗環境配置

在安裝和配置大數據環境的過程中，首先，有以下幾點需要注意：

(1)關閉各機器的防火墻。

(2)時間同步。

(3)配置ssh無密鑰訪問。

其次，需要配置Hadoop的slaves、core-site.xml、hdfs-site.xml、mapre-site.xml和yarn-site.xml四個配置文件，配置完成后將Hadoop發布到各節點。其中，master為namenode，slave1～slave8為datanode。配置完成后的Hadoop的節點集群和datanode信息如圖5和圖6所示。

圖5　Hadoop節點集群

圖6　數據節點(datanode) 信息

HBase集群的部署需要修改hbase-env.sh、regionservers和hbase-site.xml三個配置文件，配置完后發布至各節點，同時添加HBase環境變量。配置及發布完成后，通過地址http://master:16010/master-status可以在瀏覽器中查看master及各region server的情況。如圖7所示。

圖7　HBase集群

ZooKeeper對于HBase和Solr來說是必不可少的組件，它提供了分布式系統的高效協調服務。HBase有內置的ZooKeeper，但不太穩定。因此在驗證中采用獨立安裝模式進行配置。ZooKeeper的配置相對較簡單，首先，在zoo.cfg文件中添加各機器節點信息，發布各機器節點；然后，根據zoo.cfg中的設置修改各機器節點上myid文件中的id號；修改完畢后，在各個機器節點啟動ZooKeeper即可。

Solr索引服務需要結合tomcat進行安裝和配置。首先，安裝tomcat；然后，修改solrcongif.xml配置文件。修改完后發布各節點，通過啟動tomcat即可啟動Solr服務，通過地址http://slave1:8080/solr/在瀏覽器中可查看Solr的相關配置信息及查詢結果。如圖8所示。

圖8　Solr Web界面

在界面上可以通過選擇相應的Core來查看索引，也可以通過Solr提供的API接口來查詢。

4.2效果驗證

驗證使用現有審計系統中的關系數據庫MySQL和大數據存儲系統進行對比。效果從兩方面進行驗證：存儲能力和數據檢索能力。

4.2.1存儲能力

系統將收集到的數據同時存入MySQL和HBase，收集數據包括字段有：ID、用戶ID、登錄時間、退出時間、登錄類型、登錄機器、行為類型、行為描述等。數據寫入時間為48小時。

從表2中可以看出，MySQL的存儲量為1億條數據，而HBase是2億條。實際上，在試驗中隨著存入數據量不斷增大時，MySQL寫入性能開始劣化，越來越慢。而HBase的寫入性能沒有任何影響，最終，在規定時間內寫入了2億條數據，是MySQL的兩倍。

表2　數據存儲量

從理論上來說，HBase的存儲能力是無限大的，它的存儲能力與集群的存儲空間相關。當集群的存儲空間不足時，可以通過簡單的添加機器即可，而且是廉價的PC機。但如果MySQL出現存儲能力不足時，就需要提高機器的整體存儲能力和性能，無法通過簡單的添加機器來實現，而且還存在數據遷移的問題，成本較高，難度較大。

4.2.2數據檢索能力

HBase由于在檢索時，僅依靠RowKey實現，而RowKey不支持二級索引，檢索效率非常不理想。通過Solr建立二級索引后，檢索效率得到了極大的提升。以1千萬條數據建立的索引為例，提升后的效率與MySQL的對比結果如表3所示。

表3　檢索效率

從表3可以看出HBase改善后的檢索能力是MySQL的17～35倍左右。該檢索效率是在單個檢索條件下的測試結果，如果是多條件檢索的情況下，MySQL會出現無法響應的情況。

從上述驗證結果可以看出，本文提出的方法能夠有效的解決現有審計系統處理大數據存儲和檢索問題。

5　結　語

隨著大數據時代的到來，現有審計系統在存儲和檢索能力上都出現了不能滿足應用需求的問題。針對這些問題，從大數據的角度出發，利用大數據技術，并結合現有審計系統的架構，提出了使用大數據系統對海量數據進行存儲和處理的方法，有效的解決的審計大數據存儲問題。同時，針對HBase檢索效率低下的問題，提出了使用Solr建立二級索引的方法，使得檢索效率得到了大大的提升。本文提出的方法在兼容現有系統的同時，有效的解決了審計系統在大數據存儲和檢索上的問題。

[1]Wikipedia. Big Data [EB/OL]. https://en.wikipedia.org/wiki/Big_data. 2016.01.31.

[2]孟小峰，慈祥．大數據管理：概念、技術與挑戰 [J]．計算機研究與發展，2013,50(01):146-169.

MENG Xiao-feng and CI Xiang. Big Data Management: Concepts, Techniques and Challenges [J]. Journal of Computer Research and Development, 2013, 50(01): 146-169.

[3]Apache Hadoop. Home Page [EB/OL]. https:// hadoop.apache.org/. 2016.01.25.

[4]張鋒軍.大數據技術研究綜述 [J]. 通信技術，2014,47(11): 1240-1248. ZHANG Feng-jun.Overview on Big Data Technology[J]. Communications Technology,2014,47(11):1240-1248.

[5]李明桂，肖毅，陳劍鋒等. 基于大數據的安全事件挖掘框架[J].通信技術，2015,48(03): 346-350.

LI Ming-gui, XIAO Yi, CHEN Jian feng,et al. Big Data-based Framework for Security Event Mining[J].Communications Technology, 2015, 48(03): 346-350.

[6]HBase RowKey Design. HBase Reference Guide [EB/OL]. http://abloz.com/hbase/book.html # rowkey. design. 2013.04.07.

[7]Solr. Solr Home Page [EB/OL]. http://lucene. apache.org/solr/. 2016.01.01.

[8]HBase Coprocesser Introduction. Apache HBase Blog [EB/OL]. https://blogs.apache.org/hbase/ entry/coprocessor_introduction. 2015.12.17.

許杰(1978—)，男，博士，工程師，主要研究方向為信息安全與大數據；

冷冰(1976—)，男，碩士，高級工程師，主要研究方向為通信網絡與信息安全；

李明桂(1989—)，男，碩士，主要研究方向為信息安全與大數據；

丁文超(1991—)，男，碩士研究生，主要研究方向為信息安全與大數據。

Application of Big Data Processing Technology in Audit System

XU Jie, LENG Bing, LI Ming-gui, DING Wen-chao

(No.30 Institute of CETC, Chengdu Sichuan 610041, China)

With the advent of big data era, there is an explosive growth in data volume. The emergence of massive data directly affects storage, processing and analysis systems of the existing data, including audit system,which plays an important role in network security. The current audit system implements data storage and processing with relational databases. Due to the limitations of relational databases, the audit system is unable to store and process big data. To solve this problem, a big data storage method compatible with the existing system is proposed, thus to effectively solve the problem of big data storage. Meanwhile, in order to solve the low efficiency of HBase retrieval, the method using Solr to establish secondary index is presented,which could greatly raise the retrieval efficiency and satisfy the needs of audit system in storing and processing big data.

big data; audit system; HBase; Solr

10.3969/j.issn.1002-0802.2016.03.018

2015-10-15；

2016-01-26Received date:2015-10-15；Revised date：2016-01-26

TP309

A

1002-0802(2016)03-0346-06