“資本只有在流動中才帶來價值，單純存放起來只會貶值”。
在信息化大潮愈演愈烈的當下，數據資產發揮著越來越突出的價值，數據資產的價值在流轉、共享、整合利用中逐漸顯現并越發放大。當數據被分享給不同使用者，如何保障數據的安全？動態脫敏技術讓數據中心和外界使用者之間的安全交互成為可能。
長期以來，提起動態脫敏技術，能力稱霸者非Informatica莫屬，國內外其他廠商在動態脫敏技術領域都難以望其項背，由此可見這一技術的復雜度和成熟產品的研發難度非同一般。2014年，Informatica憑借其DDM產品位居Gartner數據脫敏的領導者象限。
對于國內數據庫安全廠商而言，有了其他安全產品的深厚研發積累，朝著數據動態脫敏技術進發也變成一種發展慣性。
2016年，國內已有廠商開始基于長期的數據庫防火墻產品所積累下來的數據庫協議分析、協議改寫、語法分析、SQL語句改寫等技術，成功推出數據庫動態脫敏產品，并在真實的用戶現場，通過與Informatica DDM產品的多次比拼，積累下豐富的“填坑”經驗，產品也在不斷“填坑”的過程中逐步走向成熟。
那么，面對數據共享場景，合格的數據動態脫敏產品要跨越的技術障礙都有哪些呢？
對于動態脫敏策略，常用做法是指定需要脫敏的字段或字段通配符，如此一來，必然會面臨以下問題：
場景1：配置了字段ABC需要進行脫敏處理，而用戶執行的操作是select *，并沒有在操作中寫明字段名，這種情況還能針對字段ABC成功脫敏嗎？
場景2：配置了字段ABC需要進行脫敏處理，但用戶應用系統“每天自動產生一個包含這個字段的表，并且表中的這個字段的數據也需要脫敏”，應對每天增量產生的表執行select *操作，可以做到及時成功脫敏嗎？
技術應對：動態脫敏產品自動根據用戶發起的SQL命令進行分析，實時檢查select *這一命令操作的表有哪些字段，并根據實時檢查的結果自動對數據進行脫敏。
場景：配置了字段ABC需要進行脫敏處理，用戶執行的操作是select substr(ABC,1,2),field1,field3,substr(ABC,2,5) from table，該操作中敏感字段的數據被“拆開”來使用，能夠成功脫敏嗎？
技術應對：合格的動態脫敏產品，是作用在請求的SQL操作的字段上，而不是對返回的結果集進行變形處理，否則會造成無法適應各種復雜的SQL命令而產生結果集數據。
目前，動態脫敏主流的實現方式是采用網關或代理的方式（Informatica DDM和安華金和DDM正是采用這種實現方式），在客戶端和服務器之間按照策略進行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字段不能進行脫敏。
場景：配置persionid為需要脫敏的字段，用戶在PLSQL客戶端工具中執行下面的語句塊：
declare |
這個語句塊中，關鍵是查詢操作是采用拼接的SQL命令并動態執行SQL操作，其結果是通過語法分析無法準確地對需要脫敏的字段進行處理。
技術應對：即使采用了語法分析，這種動態SQL語句也無法被處理；建議采用的策略是禁止這樣的操作被執行。
場景：用戶配置了persionid字段為敏感字段，執行SQL命令select persionid,datefield from performance_c_1000000 where persionid like '1204581978%';
該操作會面臨一個問題：是否需要對where條件中的persionid字段（紅色字體）進行脫敏處理？
如果脫敏處理，好處是不會造成通過準確查詢進行數據的“猜測”引起的數據泄露；缺點是恐怕很難再通過脫敏字段作為條件進行查詢。
如果不進行脫敏處理，好處是不影響查詢操作，該查詢到的數據依然能夠查到；缺點是頻繁查詢很可能猜測到真實數據，導致數據存在泄漏風險。
技術應對：無論如何選擇，都無法實現最佳效果，相對合理的解決方案是兩種都提供，然后根據實際的需求來配置合理的策略。
數據脫敏技術真正為用戶鑄造安全、可靠、高效的數據使用環境，基于網絡層的動態脫敏技術為實時數據共享開辟了新的前景。
產品咨詢：4000 258 365 
