987
金融行業數據實時共享場景下的動態脫敏技術
“資本隻有在流動中才帶來價值，單純存放起來隻會貶值”。
在信息化大潮愈演愈烈的當下，數據和信息不啻為一種“新型資本”，尤其對於數據資產量巨大，操作複雜程度高、係統性能要求高的金融領域來說，數據資產發揮著越來越突出的價值，和傳統資本具有的特性相似，數據資產的價值在流轉、共享、整合利用中逐漸顯現並越發放大。
舉例來說：銀行數據部門掌握的用戶儲蓄和消費信息，對內共享可以完善業務部門的信息化係統開發；對外則可為政府部門、征信機構等提供有效參考；甚至可以成為零售或製造業製定戰略目標的有效參考依據。
然而數據的共享和流轉帶來的紅利，遠遠無法衝散遮蓋在數據保管者和擁有者心頭的烏雲。這種擔憂來自對敏感信息在共享環節可能發生的泄密風險，更是來自敏感數據“合理使用”並且“安全防護”兩者之間的矛盾。於是，數據脫敏技術和專業脫敏產品應需而生，這類專業產品可以按照不同數據使用場合，對敏感數據進行變形處理，在脫敏處理的同時，不改變數據的類型、格式、含義、分布等使用特征，讓用戶不再因為深陷對安全的顧慮，而不得不割舍掉數據分享和流轉帶來的價值。
目前，脫敏技術中的靜態脫敏技術常見於銀行等金融領域。靜態脫敏技術的應用，其價值在於打造一份全新的、“高度仿真”的數據庫，供非安全環境下使用。憑借著低門檻、易部署等特性，靜態脫敏技術率先被用戶所接受。在近兩年，這種數據處理方式先後被銀行、證券、保險、社保等行業所采納，成為數據共享中的重要工具。
但當麵對不同身份的訪問者，如何實時提供不同的脫敏數據？
某銀行搭建的數據集中管理平台中，客戶信息、賬務信息、銀行卡信息等全部集中在大數據分析環境中，麵向內部提供數據查詢分析服務，麵向外部應用端、征信機構、政府部門等則提供數據檢索接口。由於不同訪問者的身份、權限差異，同樣的數據對不同訪問者的脫敏策略各不相同。為了實時、安全地向各方提供數據，依靠靜態脫敏技術已經不再合適。此時，動態脫敏服務器便成了連接數據中心和外界使用者之間的通道，對不同身份、不同權限的用戶配置實時數據脫敏規則，讓其可以恰如其“份”的訪問數據。
數據的動態脫敏遵循著一套與靜態脫敏完全不同的技術路線，今天，我們重點了解一下數據動態脫敏技術，為金融行業未來的技術應用提供一些借鑒思路。
數據動態脫敏，需要滿足一個重要的能力：針對目前各種主流的數據庫中的敏感數據，在用戶使用各種第三方客戶端工具或應用程序實時訪問數據過程中，能夠依據用戶角色、職責和其他 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字段（紅色字體）進行脫敏處理？
如果選擇脫敏處理，好處是不會造成通過精確查詢進行數據的“猜測”引起的數據泄露；缺點是恐怕很難再通過脫敏字段作為條件進行查詢，因為說不清查詢的結果會如何，很大可能是查不到結果。
如果不進行脫敏處理，好處是不影響查詢操作，該查詢到的數據依然能夠查到；缺點是數據很可能通過頻繁查詢可以猜測到真實數據，導致數據仍然存在泄漏風險。
技術應對：無論如何選擇，都無法實現最佳效果，相對合理的解決方案是兩種都提供，然後根據實際的需求來配置合理的策略。
此外，金融行業對於業務係統的運行穩定性有著嚴格的要求，而動態脫敏作用於網絡層，脫敏係統串接在訪問者和敏感數據之間，因此產品需要兼顧高性能與穩定性，不會因脫敏處理導致性能的明顯下降，同時兼容全係列數據庫協議；另一方麵，需要具備高並發條件下的抗壓能力，擁有完善的容災機製；這些都將成為衡量動態脫敏產品成熟度的標準。
在數據安全領域，“禁止”和“防護”固然重要，但是如果背離了數據共享和合理使用的前提，那麼數據的價值將大幅度下降。數據脫敏技術，正是兼顧數據“用”、“護”之道的有效手段。無論動態脫敏還是靜態脫敏，在金融行業數據安全領域，將越發不可替代，真正為金融用戶鑄造安全、可靠、高效的數據使用環境。我們看到基於網絡層的動態脫敏技術為金融行業的實時數據共享開辟了新的前景。
最後更新：2017-09-27 17:33:09