金融行業資料實時共享場景下的動态脫敏技術

“資本隻有在流動中才帶來價值，單純存放起來隻會貶值”。

在資訊化大潮愈演愈烈的當下，資料和資訊不啻為一種“新型資本”，尤其對于資料資産量巨大，操作複雜程度高、系統性能要求高的金融領域來說，資料資産發揮着越來越突出的價值，和傳統資本具有的特性相似，資料資産的價值在流轉、共享、整合利用中逐漸顯現并越發放大。

舉例來說：銀行資料部門掌握的使用者儲蓄和消費資訊，對内共享可以完善業務部門的資訊化系統開發；對外則可為政府部門、征信機構等提供有效參考；甚至可以成為零售或制造業制定戰略目标的有效參考依據。

然而資料的共享和流轉帶來的紅利，遠遠無法沖散遮蓋在資料保管者和擁有者心頭的烏雲。這種擔憂來自對敏感資訊在共享環節可能發生的洩密風險，更是來自敏感資料“合理使用”并且“安全防護”兩者之間的沖突。于是，資料脫敏技術和專業脫敏産品應需而生，這類專業産品可以按照不同資料使用場合，對敏感資料進行變形處理，在脫敏處理的同時，不改變資料的類型、格式、含義、分布等使用特征，讓使用者不再因為深陷對安全的顧慮，而不得不割舍掉資料分享和流轉帶來的價值。

目前，脫敏技術中的靜态脫敏技術常見于銀行等金融領域。靜态脫敏技術的應用，其價值在于打造一份全新的、“高度仿真”的資料庫，供非安全環境下使用。憑借着低門檻、易部署等特性，靜态脫敏技術率先被使用者所接受。在近兩年，這種資料處理方式先後被銀行、證券、保險、社保等行業所采納，成為資料共享中的重要工具。

但當面對不同身份的通路者，如何實時提供不同的脫敏資料？

某銀行搭建的資料集中管理平台中，客戶資訊、賬務資訊、銀行卡資訊等全部集中在大資料分析環境中，面向内部提供資料查詢分析服務，面向外部應用端、征信機構、政府部門等則提供資料檢索接口。由于不同通路者的身份、權限差異，同樣的資料對不同通路者的脫敏政策各不相同。為了實時、安全地向各方提供資料，依靠靜态脫敏技術已經不再合适。此時，動态脫敏伺服器便成了連接配接資料中心和外界使用者之間的通道，對不同身份、不同權限的使用者配置實時資料脫敏規則，讓其可以恰如其“份”的通路資料。

資料的動态脫敏遵循着一套與靜态脫敏完全不同的技術路線，今天，我們重點了解一下資料動态脫敏技術，為金融行業未來的技術應用提供一些借鑒思路。

資料動态脫敏，需要滿足一個重要的能力：針對目前各種主流的資料庫中的敏感資料，在使用者使用各種第三方用戶端工具或應用程式實時通路資料過程中，能夠依據使用者角色、職責和其他 IT 定義規則，對敏感資料進行屏蔽、遮蓋、變形處理，來“隐藏”對敏感資料的通路，進而有效的防止敏感資料的洩漏。 

國内動态脫敏技術的演進路線

長期以來，提起動态脫敏技術，能力稱霸者始終逃不過Informatica，國内外其他廠商在動态脫敏技術領域都難以望其項背，由此可見這一技術的複雜度和成熟産品的研發難度非同一般。2014年，Informatica憑借其DDM産品位居Gartner資料脫敏的上司者象限。

對于國内資料庫安全廠商而言，有了其他安全産品的深厚研發積累，朝着資料動态脫敏技術進發也變成一種發展慣性。2016年，國内已經有廠商開始基于長期的資料庫防火牆産品所積累下來的資料庫協定分析、協定改寫、文法分析、SQL語句改寫等技術，成功推出資料庫動态脫敏産品，并在真實的使用者現場，通過與Informatica DDM産品的多次比拼，積累下豐富的“填坑”經驗，産品也在不斷“填坑”的過程中逐漸走向成熟。

那麼，面對金融行業的資料共享場景，合格的資料動态脫敏産品要跨越的技術障礙和必須要填的“坑”都有哪些呢？下面我們将站在技術角度抛磚引玉，希望對業内的廠商、專家、使用者有所幫助，同時也歡迎“拍磚”，共同進步。

Trap1：select * ，一個簡單但是難填的坑。

對于動态脫敏政策，常用做法是指定需要脫敏的字段，或字段通配符，如此一來，必然會面臨以下問題：

場景1：配置了字段ABC需要進行脫敏處理，而使用者執行的操作是select *，并沒有在操作中寫明字段名，這種情況還能針對字段ABC成功脫敏嗎？

場景2：配置了字段ABC需要進行脫敏處理，但使用者的應用系統存在一個功能是“每天自動産生一個包含這個字段的表，并且表中的這個字段的資料也需要脫敏”，應對每天增量産生的表執行select *操作，可以做到及時成功脫敏嗎？

技術應對：動态脫敏産品自動的根據使用者發起的SQL指令進行分析，并且實時的檢查select *這一指令操作的表有哪些字段，并根據實時檢查的結果自動的對資料進行脫敏。

Trap2：使用者執行的SQL指令中對敏感字段執行了函數轉換，是否會造成繞過脫敏的結果？

場景：配置了字段ABC需要進行脫敏處理，使用者執行的操作是select substr(ABC,1,2),field1,field3,substr(ABC,2,5) from table，該操作中敏感字段的資料被“拆開”來使用，能夠成功脫敏嗎？

技術應對：合格的動态脫敏産品，是作用在請求的SQL操作的字段上，而不是對傳回的結果集進行變形處理，因為如果這樣做會造成無法适應各種複雜的SQL指令而産生結果集資料。

Trap3：詞法分析還是文法分析，這是個準确度問題。

目前，動态脫敏主流的實作方式是采用網關或代理的方式（Informatica DDM和安華金和DDM正是采用這種實作方式），在用戶端和伺服器之間按照政策進行SQL操作的改寫，來實作對資料脫敏的效果。這個SQL改寫的過程必然需要對SQL語句進行拆包和分析，可供選擇的技術路線包括正則比對、詞法分析、文法分析；因為正則比對非常不準确，是以首先被淘汰掉；接下來就面臨到底是選擇詞法分析還是文法分析的問題了。

衆所周知，文法分析是非常複雜的，詞法分析則相對簡單很多，二者能夠達到的脫敏準确度也會不同，見典型場景：

場景：配置表TA的字段ABC需要脫敏，表TB的ABC字段不脫敏；使用者執行的SQL操作為select a.ABC,b.ABC from TA a,TB b where a.id=b.id；這個語句需要正确的識别出脫敏對象。

技術應對：通過文法分析，正确的識别a.ABC字段為需要脫敏的字段，b.abc字段不能進行脫敏。

Trap4：執行begin...end語句塊，語句塊中包含動态SQL語句，如何處理？

場景：配置persionid為需要脫敏的字段，使用者在PLSQL用戶端工具中執行下面的語句塊：

這個語句塊中，關鍵是查詢操作是采用拼接的SQL指令并動态執行SQL操作，其結果是通過文法分析無法準确地對需要脫敏的字段進行處理。

技術應對：即使采用了文法分析，這種動态SQL語句也無法被處理；建議采用的政策是禁止這樣的操作被執行。

Trap5：WHERE子句中包含敏感字段作為條件字段，脫敏還是不脫敏？

場景：使用者配置了persionid字段為敏感字段，執行SQL指令select persionid,datefield from performance_c_1000000 where persionid like '1204581978%';

在這個操作中，會面臨一個問題：是否需要對where條件中的persionid字段（紅色字型）進行脫敏處理？

如果選擇脫敏處理，好處是不會造成通過精确查詢進行資料的“猜測”引起的資料洩露；缺點是恐怕很難再通過脫敏字段作為條件進行查詢，因為說不清查詢的結果會如何，很大可能是查不到結果。

如果不進行脫敏處理，好處是不影響查詢操作，該查詢到的資料依然能夠查到；缺點是資料很可能通過頻繁查詢可以猜測到真實資料，導緻資料仍然存在洩漏風險。

技術應對：無論如何選擇，都無法實作最佳效果，相對合理的解決方案是兩種都提供，然後根據實際的需求來配置合理的政策。

此外，金融行業對于業務系統的運作穩定性有着嚴格的要求，而動态脫敏作用于網絡層，脫敏系統串接在通路者和敏感資料之間，是以産品需要兼顧高性能與穩定性，不會因脫敏處理導緻性能的明顯下降，同時相容全系列資料庫協定；另一方面，需要具備高并發條件下的抗壓能力，擁有完善的容災機制；這些都将成為衡量動态脫敏産品成熟度的标準。

在資料安全領域，“禁止”和“防護”固然重要，但是如果背離了資料共享和合理使用的前提，那麼資料的價值将大幅度下降。資料脫敏技術，正是兼顧資料“用”、“護”之道的有效手段。無論動态脫敏還是靜态脫敏，在金融行業資料安全領域，将越發不可替代，真正為金融使用者鑄造安全、可靠、高效的資料使用環境。我們看到基于網絡層的動态脫敏技術為金融行業的實時資料共享開辟了新的前景。