基于子圖同構的Hive數據操作合規分析方法

陳 麗 陳興蜀 羅永剛* 楊 露 袁道華

①(四川大學軟件學院 成都 610065)

②(四川大學網絡空間安全研究院 成都 610065)

③(四川大學計算機學院 成都 610065)

1 前言

隨著大數據技術的發展和應用，應用程序(App)和網站利用大數據平臺來存儲和處理收集的個人信息。海量個人信息在大數據平臺上匯聚的同時，數據違規使用導致隱私泄露的風險加劇。近年隱私泄露安全事件頻頻發生，如在未經用戶事先同意及未提供充分信息的情況下，亞馬遜歐洲公司通過Azmazon.fr網頁在用戶電腦中放置用于廣告目的的數據(Cookies)，被法國國家信息自由委員會(France''s National Commission for Information technology and civil Liberties, CNIL)限制委員會處以3.5×106歐元的罰款；以及2018年7月9日至10日，VDAI發現由于立陶宛支付公司 (MisterTango)技術和組織措施不足，支付數據可在網上公開獲得，導致來自不同國家的12家銀行的 9000 筆付款受到了影響。以上案例的隱私泄露不僅對個人造成傷害，也對企業名譽和財產造成了嚴重的損失。所以各個國家出臺法律[1]保障個人信息的安全，如我國的《中華人民共和國網絡安全法》和GB/T 35273–2017《信息安全技術 個人信息安全規范》(以下簡稱《信息安全規范》)、歐洲的《通用數據保護條例》等等，對個人信息的收集使用提出了要求。在大數據環境下，數據使用的合規性分析可以幫助企業滿足國家關于數據安全相關法律的要求和降低個人隱私泄露的風險，因此針對大數據平臺下的數據使用的合規性研究是十分有意義的。

目前大數據審計方法主要分為3類：信息技術(Information Technology, IT)內部審計方法[2,3]、傳統審計方法、基于大數據審計[4–7]的方法以及基于全球萬維網(World Wide Web, WWW)信息的審計方法[8–14]。IT內部審計方法，解決了關系數據庫審計功能相對較弱的問題，通過審計規則來對數據庫操作進行約束，且提供了帶界面的程序方便審計人員操作審計記錄和審計規則，但存在性能較低、對審計人員的關于計算機的專業知識要求較高等問題。傳統的審計方法分為基于觸發器的審計、基于日志的審計[15,16]。其中基于觸發器的審計主要用于關系數據庫，需要開發人員設計并開發相應的審計語句，可重用性較低且只能對部分操作進行記錄，范圍不全。而基于日志的審計方法，存在只能對特定的操作類型進行審計、數據庫日志文件本身存在被篡改的風險以及日志冗余性較高等問題，難以體現審計信息的有效性和公平性?；赪eb信息的審計方法，是將數據溯源機制應用在審計的過程中，對起源事件及其與使用策略的一致性進行建模，將起源記錄建模為離散事件序列，而將使用策略建模為元組，并且考慮了派生、鏈接和時間方面的隱私政策。但是上述方法只適用于Web信息系統，不適用Hive。文獻[14]將結構化查詢語言(Structured Query Language, SQL)解析的邏輯計劃進行簡化，通過數據溯源進行合規分析，但它的審計范圍并不完全，缺乏對數據使用目的和數據最小化的合規驗證。

大數據治理框架主要使用兩大組件 Apache Falcon和Apache Atlas。其中Apache Falcon主要對數據進行生命周期管理，涉及的過程有數據采集、數據處理、數據備份以及數據清洗，但缺乏數據審計。Apache Atlas實現大數據平臺的數據安全和隱私保護，但存在只能對修改元數據的操作進行審計的問題。Apache Ranger提供集中管理的安全策略并監控用戶的訪問，是一個集中式安全管理框架，能夠對數據平臺的數據庫進行細粒度的數據訪問控制，解決了授權問題和審計問題。但存在無法從審計信息中直觀看出數據的來源和整個演變過程，和無法直接根據合規要求對數據進行合規性檢查的問題。

因此，大數據平臺下的審計工作主要存在缺乏對數據使用目的和數據最小化的合規驗證問題。Hibernate查詢語言(Hibernate Query Language,HQL)無法直接進行合規分析，現有的規則(如訪問控制)無法表示數據的使用目的和數據操作是導致這個問題的主要原因。

為了解決以上問題，本文提出一種基于子圖同構的合規驗證。本方法能夠根據具體的業務場景制定滿足其安全需求的審計方案，實現數據倉庫Hive的審計。本文的主要工作及貢獻如下：

(1)提出一種基于有向圖來描述數據使用合規的表示方法，從而可以通過數據溯源圖與子圖同構算法實現數據合規驗證。

(2)提出子圖同構的合規驗證方法，實現數據使用合規的自動判斷，相比于其他合規算法，它對圖匹配順序進行了優化且算法復雜度較低，有較高的性能。

(3)針對普遍關注的數據使用范圍合規、處理方式合規、權限合規、目的合規等問題，在Apache Atlas溯源平臺上進行了實驗驗證。

2 Hive的合規驗證模型

為了實現對Hive數據操作的合規驗證，本文首先對《信息安全規范》[1]中的原則和要求進行分析，歸納出數據安全合規規則中包含的合規要求，其中包括數據使用范圍合規、處理方式合規、權限合規、目的合規，然后定義了合規驗證模型來實現Hive的合規驗證。

2.1 合規要求

《信息安全規范》中定義了個人信息安全基本原則和使用個人數據必須滿足的要求，引入了審計私有數據處理。本文對其中原則和要求進行分析，得到以下合規要求并對其功能進行說明如表1所示。

表1 合規要求及其功能說明

安全管理員根據上述合規要求為Hive中個人數據使用創建相應的合規規則。

2.2 合規驗證模型

為了從數據使用范圍合規、處理方式合規、權限合規及目的合規4個方面對Hive數據操作進行合規驗證，本文提出了基于子圖同構的合規驗證方法。Hive的合規驗證模型如圖1所示。

圖1 Hive的合規驗證模型

2.2.1 數據溯源圖

數據溯源圖[17]將需要進行合規驗證的HQL轉化為圖，并描述了數據處理過程。對數據溯源圖定義如定義1所示。

定義1數據溯源圖可以使用4元組表示，G(V,E,R,A)是一個由頂點、邊、邊標簽和屬性構成的有向無環圖，其中各組成元素具體的定義為

V表示點的集合，其中DU, OP, DR分別表示使用數據頂點、操作頂點以及結果頂點的集合，OP表示點的集合。E表示邊的集合，另外R是指邊標簽類型的集合，包含了u sedBy 和 g enerated兩種類型的標簽。其中u sedBy表示對數據執行了某種操作，建立了使用數據與操作之間的關系。g enerated表示一個結果數據產生的過程，建立了操作與結果數據之間的關系。A表示溯源圖中頂點和邊包含的屬性，其中g uid 表 示實體或關系的唯一標識，n ame表示實體的名稱， typeName表示頂點或邊的類型，createTime 表示創建時間，c reateBy表示創建者，version表示創建版本。

2.2.2 合規規則圖

對數據操作的合規性檢查是基于合規要求進行判定的，為此如何表示合規要求是實現合規驗證的前提。本文使用合規規則圖來描述合規規則。下面對合規規則圖中的實體和實體間的關系進行定義。

定義2角色(Role)，表示合規規則中信息主體授權的數據操作參與者，其能出于某種目的、方式、范圍以及規則等對信息主體的數據進行操作。

定義3目的(Purpose)，表示角色執行數據操作的行為意圖。

定義4數據(Data)，表示數據操作過程中的操作實體，并且這種數據操作滿足某種目的。例如在統計目的下，可以對Hive的表、列等進行處理。

定義5操作(Process)，表示數據操作過程中可以對數據使用具有某種目的的運算，例如為了對學生成績進行分析時的求平均值、最大值等操作。

定義6依賴關系(Dependence)，表示各個實體之間的關系。包括目的與使用數據之間的關系、使用數據與操作之間、角色與目的之間的關系。

本文使用有向無環圖來表示合規規則圖，其中頂點表示目的、角色、數據及操作，邊表示目的與使用數據的關系、使用數據與操作的關系及角色與目的的關系。對合規規則圖定義如定義7所示。

VR表 示頂點的集合，其中PR表示目的頂點的集合，DuR表示使用數據頂點的集合，O PR表示操作頂點的集合， R oleR表示用戶角色頂點的集合，VR至少包含R oleR。ER表示邊標簽類型的集合，它可以為空，即不授予用戶權限。RR表示邊標簽類型的集合。圖中邊有兩種類型：一種類型是w asInitiatedBy，表示由特定目的發起的一組操作或某種目的下進行的數據操作，建立了角色和目的、目的與操作之間的關系；另一種類型是u sedBy，表示對數據執行了某種操作，建立了數據與操作之間的關系。AR表示合規規則圖中頂點和邊包含的屬性，其中g uid表示實體或關系的唯一標識， name表示實體的名稱，t ypeName表 示頂點或邊的類型，c reateTime表示創建時間，c reateBy 表示創建者，v ersion表示創建版本。

例如角色被授權在目的A下只能對數據A和數據B執行操作A。產生的合規規則圖如圖2所示。

圖2 合規規則圖示例

2.2.3 基于子圖同構的合規驗證

基于上述數據溯源圖和合規規則圖構建，本文將數據合規驗證問題轉換為圖匹配問題。由于VF3[18]算法能夠解決圖同構問題，且相比VF2[19]算法、Ullmann算法[20]做了圖匹配順序優化，因此本文在VF3算法基礎上提出基于子圖同構的合規驗證。它將數據溯源圖按照使用數據拆分為多個子圖，分別與對應的合規規則圖進行子圖匹配，根據是否對數據溯源圖中的所有節點匹配且目的標簽是由一致，判斷是否合規，最終實現個人信息的合規驗證?；谧訄D同構的合規驗證算法如表2所示：其中 V F3 表示V F3 子圖同構算法，GR表示規則圖，A1表 示查詢出并展示的溯源圖，M(s)表示規則圖與數據溯源圖匹配的部分，O Pi表 示第i個溯源圖中的操作操作 1≤i ≤n，其中n表示溯源子圖的個數，G?A1表 示剩余的數據溯源圖，Ai表示數據溯源子圖， PUMAP 表示圖與目的對應關系。GR1表示涉及當前使用數據相關的規則信息。

表2 基于子圖同構的合規驗證算法

第1步，將數據溯源圖和合規規則圖作為VF3算法的輸入進行子圖匹配，獲得匹配的節點集合M(s) 。第2步、第3步，若M(s)為空說明用戶身份不驗證(第22步)，終止流程；若M(s)為1說明操作和用戶身份驗證不合規(第19步、第20步)，終止流程；若M(s)中包含數據溯源圖中所有節點，則獲得目的A，第(8)步，若溯源圖只使用一個數據，則說明目的合規終止流程，否則繼續。第(6)～(17)步，將其余溯源圖與合規規則圖進行匹配，如果溯源圖中所有圖都能夠被匹配，且目的相同，則說明目的合規，反之說明不合規。

3 Hive合規分析系統

為了驗證本文所提合規驗證方法，本文針對Hive中的數據設計了如圖3所示的合規驗證系統架構。系統主要包含以下模塊。

圖3 合規驗證系統架構

(1) 數據溯源。用戶對Hive中的數據執行操作處理之后，數據溯源模塊收集溯源信息，并通過溯源信息建模轉化為數據溯源圖，然后持久化存儲在圖數據庫中。

(2) 規則建立。安全管理員事先根據合規要求在JS 對象簡譜(JavaScript Object Notation,JSON)文件中制定合規規則，實現規則的批量導入。規則建立模塊對導入的規則進行合規信息建模，轉化為合規規則圖并存儲在圖數據庫中。

(3) 合規驗證。事后當安全管理員查詢數據的審計信息時，合規驗證模塊根據查詢數據獲得數據的溯源圖，利用子圖同構算法對數據溯源圖進行合規分析，最終將合規分析結果以可視化的形式返回給安全管理員，產生審計結果。

圖3顯示了對數據操作的審計及合規管理的實現原理與流程。該架構利用數據溯源實現對數據操作的審計，并且支持安全管理員根據法律法規、行業規范等合規要求制定合規規則。通過合規驗證模塊對數據處理過程進行合規性分析，并將合規結果返回給安全管理員，有助于安全管理員及時發現違規的數據操作并提早解決。

4 實驗與分析

4.1 實驗環境

為了實現基于子圖同構的Hive數據操作合規驗證，實驗中使用了4臺物理服務器搭建海杜普(Hadoop)集群，包含1臺主節點和3臺從節點。另外配置了1臺Mysql服務器作為Hive的元數據存儲庫。5臺服務器配置為Intel(R)Xeon(R)CPU E5-2680 V4 @2.40 GHz的CPU和200 GB內存。

本文使用事務處理性能委員會-決策支持(The Transaction Processing performance Council- Decision Support, TPC-DS)基準對提出的方法進行有效性和性能分析。由于本文所提合規分析方法主要出于保護用戶個人信息的目的，因此只對TPCDS基準中描述用戶個人信息的顧客(Customer)、顧客地址(Customer_address)、顧客人口統計(Customer_demographics) 3張表制定了使用的合規規則，如表3所示。這些規則是TPC-DS所有查詢語句使用這3張表合規性的依據，寫在Json文件中，作為合規驗證實驗的輸入。

4.2 有效性測試分析

為了對本文所提方法進行有效性驗證，分別以用戶root1, root2, root3身份各提交33條查詢語句(query1-33, query396, query67-99)。執行查詢語句查看審計結果就可以得知數據操作的合規性。即是否滿足表3的合規規則。獲得的結果如圖4所示，圖中的合規驗證結果均由人工逐條對查詢語句進行分析驗證，證明系統合規判定結果都是正確的。

圖4 合規驗證結果統計

(1)數據使用范圍合規驗證結果。所有的用戶提交的99 條查詢中共有9條查詢存在數據使用范圍不合規的情況，如圖5所示的query35，訪問了表Customer_address，超過了表3的合規規則2定義的數據范圍Customer, Customer_demographics，因此判定為數據使用范圍不合規。

圖5 query35查詢的合規結果

表3 合規規則信息

(2)處理方式合規驗證。所有的用戶提交的99條查詢中共有13條查詢存在處理方式不合規情況。

如圖6所示的query6的對表customer以及customer_address執行了select操作，但合規規則1中授權對表customer以及customer_adderss的操作是rank, avg, sum, count, substr，超過了允許的操作范圍，因此判定為處理方式不合規。

圖6 query6查詢的合規結果

(3)權限合規驗證結果。所有的用戶提交的99條查詢中共有10條查詢存在權限不合規情況。合規規則中只允許了root1和root2訪問和處理3張表，因此由root3用戶提交的query94被判定為權限不合規，如圖7所示。

圖7 query94查詢的合規結果

(4)目的合規驗證結果。所有的用戶提交的99條查詢中共有7條查詢目的合規，如圖8所示，由root提交的query16對customer_address執行count操作，與合規規則1中定義的角色、使用數據范圍和操作都一致，即query16符合StatisticalAnalyse的數據使用目的，因此這條查詢被判定為目的合規。

圖8 query16查詢的合規結果

4.3 性能測試分析

為了測試本文所提基于子圖同構的合規驗證方法對性能的影響，本文首先對合規驗證時間開銷進行測試，然后基于子圖同構的合規驗證與其他的合規驗證方法時間開銷進行對比實驗分析。

4.3.1 合規驗證時間開銷測試

實驗分為6組，單表HQL記錄數據量從500～20000條，數據庫數據量從10000～400000條。對加入合規驗證前后同一數據表進行合規驗證以獲得其審計信息的時間。實驗結果如圖9所示，與未加入審計相比，加入審計所帶來的額外時間消耗較少。經過統計，合規分析時間占整個溯源和合規驗證過程的0.07%左右。對實驗進行分析，相比于原有的系統只是增加了圖算法過程，而圖算法執行效率較高，故加入審計所帶來的額外時間消耗較小。

圖9 加入合規分析前后的溯源時間開銷

4.3.2 不同方法的合規驗證性能對比

首先設置了6組實驗測試不同大小的合規規則圖對同一數據溯源圖的匹配時間的影響，其中合規規則數從100～10000條，數據庫合規規則數從2000～200000條，數據溯源圖中的HQL數為500條。測試本文方法與VF2算法、Ullmann算法以及文獻[10]基于集合的合規驗證的時間開銷對比。實驗結果如圖10所示，隨著合規規則數量增加，合規分析時間也在增加。但本文方法增加速度明顯最低。對4種方法進行分析，可得相比與其他算法，基于子圖同構的合規驗證能夠同時進行數據溯源圖與合規驗證圖的合規分析、對圖匹配順序進行了優化且算法復雜度較低，故性能較高。

圖10 不同合規規則圖大小對合規驗證時間的影響

然后在相同數量的合規規則圖下，測試了不同大小的數據溯源圖對合規分析的時間開銷影響。實驗設置為6組，其中單表HQL記錄數目從20000～2 0 0 0 0 0 條，數 據 庫H Q L 記 錄 數 從4 0 0 0 0 0 ～4000000條，合規規則圖數量為1000條。實驗結果如圖11所示，由于數據溯源圖中頂點增加，則待匹配的查詢圖集合增大，導致合規分析的時間逐漸增長。但可以看出基于子圖同構的合規驗證時間增長的速度較緩慢。原因上文已提到。綜上所述，本文提出的基于VF3的合規驗證比其他合規驗證方法整體性能更優。

圖11 不同數據溯源圖大小對匹配時間的影響

5 結束語

本文為了解決大數據平臺中缺乏對數據使用目的和數據最小化的合規驗證問題，提出了基于子圖同構的合規驗證方法。首先，定義了一種能夠描述數據使用目的的數據合規規則，并由合規規則圖表示，作為合規驗證的依據；然后，使用子圖同構算法實現了對Hive查詢語句的數據使用范圍、處理方式、權限和目的的合規驗證。本文在Apache Atlas中實現了基于子圖同構的Hive數據操作合規分析方法，并在TPC-DS基準數據集上對該方法的功能和性能進行了實驗驗證。實驗結果表明，本文方法能夠對Hive數據操作的數據使用目的進行合規驗證，加入合規分析對整個溯源過程影響較小。且相比于基于集合、VF2以及Ullmann的合規驗證整體性能更優。