隨著大數據時代的來臨，企業數據開始激增，各種數據在云端、移動設備、關系型數據庫、大數據庫平臺、pc端、采集器端等多個位置分散。對數據安全來說，挑戰也更大了。在大型互聯網企業里，傳統方法已經很難繪制出一張敏感數據流轉圖了。因此在新的形勢下，一是在工具層面要有新的手段支撐，包括完整的敏感數據視圖、高風險場景識別、數據違規/濫用預警、數據安全事件的發現檢測和阻止等。二是目前企業也存在著合規的問題了，以往合規對于互聯網來說沒那么重要，但隨著網安法的出臺，數據安全也擺上了日程。另外對于跨境企業來說，還面臨著海外的數據安全法規。

所以，面臨的挑戰也是顯而易見的。

1、 在策略層面：由于海量的數據類型，已經很難明確定義什么是高敏感數據了。同時也存在著多個低敏感數據關聯后形成高敏感數據的普遍情況，甚至到最后，很難說清楚一個數據究竟有多少來源。而在一個大型互聯網集團里，數據之間的交互也異常復雜，數據是否經過審批，下游如何使用也可能是混亂的。

2、 準確性：在混沌的組織結構、超級復雜且不斷變化的系統里，要想實現數據安全的保護，其中一個重點是準確性的考慮。而準確性考慮按照現在的技術，也到了數據上下文、用戶行為分析的階段了，沒有這些方法，誤報將會很多甚至于不可用。

3、 及時性：很多業務都面臨著迅速上線的壓力，這時候安全就要能拿出一個快速低成本、可擴展的解決方案來，有些方法可能很土，有些方法可能需要人肉，但總體上衡量，應該是保護成本小于數據成本的可用解決方案。理想情況下，應該有工作流、機器學習、自動化來協助實現。

4、 可擴展性：也要考慮可擴展性，互聯網行業里，說不準某個業務就突然爆發，原有的解決方案要能夠對爆發后的架構進行支持，包括傳統關系型數據庫、大型數據倉庫、云環境等。

還要多說一句，一個有理想的安全人員，不會止步于基礎的保護能力，需要從不同項目中的經驗提煉出更多價值和方法。任何數據保護方法，最后都應形成安全能力組件，為整體能力提供基礎服務。按照國外某些公司的提法，應具備以API為驅動的安全能力。

業界也在不斷探索新的方法來解決問題，forreste的報告，描述了這些年在數據安全上的各種防范的探索，假定大家都看得懂英文。

　　算了，我來解釋下吧。橫軸表示各技術的成長性，縱軸表示技術的價值。

紅色這條線看起來是最失敗的，既沒有技術價值，也沒有可以炒作的概念，分別對應了安全管理和企業權限管理。

灰色這條線上，有區塊鏈、安全通信、應用層加密、密鑰管理、數據分類、各種文件磁盤加密，再到DLP。這一部分價值還是有的，很多都已經成為企業標配技術，大家都耳熟能詳，冷飯熱炒也炒不出新花樣了。

藍色都是眼下炙手可熱的技術，包括數據分類和flow mapping，數據隱私管理、數據主體權利管理、數據訪問治理、大數據加密、令牌化技術、云數據保護。這一階段的很多解決方案還在摸索實踐中，相對于前面兩條線，藍色線技術更順應大數據、云時代的潮流。

一、CASB（云安全接入代理）

CASB的出現是為了解決企業上云的問題，企業上云后，數據和業務系統都不在自己掌握中，為了保證企業的控制權，CASB出現了。在企業和云端之間部署一個代理網關，對上云的數據進行加密，反向則解密，這樣保證了在云端的數據都是加密存儲，防止未授權、黑客、云服務商獲取數據。而負責加解密的KMS功能則獨立管理。

粗暴一點的理解，可以認為是一些傳統技術的合集，從功能上來說，一般包括DLP、身份認證、堡壘機、加解密。如果僅僅是這樣，就成了一個UTM，也未免太沒意思了。因此還有一些新技術也加入了進去，例如在身份認證上，還包括了基于設備、基于內容、基于應用的相關上下文理解的認證方式。同時也大量使用了機器學習算法在各模塊中進行保護。

CASB解決的核心是上云的安全，從身份、權限、審計、防泄漏等角度出發。由于KMS的中立性，對于中小企業來說，算是一個可以接受的解決方案。但安全管理本質上是一個運營的管理，就像企業里之前買的各種安全產品，最終能否發揮作用，還依靠日常運維。

二、tokenization（令牌化）

tokenization最早應用于支付行業，將敏感數據（例如銀行卡信息）替換成隨機生成的數據，在替換之后，原始數據和令牌的映射關系單獨存放在另一個數據庫中。和加密不同的是，原始數據和隨機數據之間沒有數學關系，對于黑客來說，必須拿到映射關系表，才有可能拿到原始數據。

這樣做的好處是，tokenization請求方可以不必存儲銀行卡信息，而只要存儲隨機數據即可，這樣就不必記錄銀行卡信息，安全上消除了一些風險。而且他信息包括發卡行、有效日期等，也可以在隨機數據中用若干字段實現。雖然這樣風險聚集在了tokenization的服務方，但相對來說，服務方安全保障能力會更強一些。

這個技術用在互聯網公司，也同樣可以借鑒。我記得很早以前看到文章，談到QQ的賬號和密碼保護，就是使用了這個方法，賬號和密碼分別存儲，之間通過一個映射關系表來對應，這也是一種tokenization的用法。

除了賬號和密碼保護，也可以用在其他場景中。例如互聯網企業可能存儲了大量用戶手機號、身份證號信息，通過tokenization，可以把數據形成一個新的隨機數據，原始數據則加密存放。同時，可以對手機號相關信息建立一個緯度，例如標志運營商、地域信息，把這個字段放在隨機數中，既滿足了業務使用要求，也避免了相關人員接觸到原始敏感數據。

Tokenization和Mask的區別也很簡單，假設原始手機號是13911111111，Tokenization后變成13911112987，保持了運營商和歸屬地不變。而Mask后變成1391111****，后面四位不可見。當然mask也分為動態掩碼和靜態掩碼，這里不做展開。

　　三、大數據加密

當大量數據被存放在Hadoop平臺上的時候，這個大數據平臺就成為了風險最集中的位置。Hadoop的生態系統核心是HDFS，從2.6版本開始HDFS支持原生靜態加密，可以理解為一種應用層加密。

Hadoop生產集群通常都有成千上萬的節點，把數據機密到HDFS之外的組件導致了很大的復雜性。另外，大規模加密還有一個難點是對于密鑰的管理，要考慮速度和性能、對Hadoop的支持程度、管理難度問題。好消息是Rhino已經開源，在這之前對于數據的加密只能考慮全盤加密或文件系統加密。

另外，僅僅是對靜態數據加密是不夠的，數據在傳輸時的動態安全也需要加密，Hadoop有一堆的網絡通信方式，RPC、TCP/IP、HTTP，對應到不同的動態加密方法。

夠了么？還不夠。綜合起來來看，敏感數據不僅在HDFS上，還有各種與Hadoop交互的系統上，包括了mysql、oracle甚至臨時文件、日志、元數據等各種地方。比如你要把線上生產數據庫導入到大數據平臺，在從源頭到HDFS的通道中的加密也需要考慮，否則只要通過嗅探就可以獲取。同樣，在數據提取和客戶端訪問上，也需要考慮。

除了這些，還有其它讓人頭疼的各種數據應用場景，比如加密后的搜索、數據脫敏后的聚合隱私泄漏等等，現在都還在研究的概念上，無法落地。

所以目前，并沒有一個完整視圖的解決方案，因此需求很大，但能夠提供完整方案的一個也沒有。還需時日。

四、身份識別與訪問管理

對敏感數據的位置、權限和活動的可視性管理，能夠大規模自動化管理權限和數據，也即是IAM。這個概念出現很久了，之所以又被拿出來說，是因為一些新計入的加速融入，包括云身份管理、欺詐檢測、UEBA、物聯網、機器學習等技術。Gartner估計，到2022年，IAM的三分之一將由AI驅動。

在大型互聯公司里，身份、權限、策略、資源、行為、設備，可能有幾萬億的關系連接，這個世界上唯一不變的就是變化，這么多關系再加上實時動態的變化。如果不動用機器算法，是無法全面管理的。除了關系，IAM還涉及到和內部系統的多種集成，例如SOC、DLP、SSO等繼承。

在新的思路下，可以把以前的場景用另外的方法關聯表達出來。例如，以前的權限梳理，是把用戶配置成不同的組，審查重點是用戶的權限分配屬否合理。在智能驅動下的權限管理，可以有很多不同，比如：張三有權訪問一臺服務器，他是這個部門中唯一有權限的人嗎？又或者：張三整個部門都在訪問一個共享文件夾，但只有李四是在周末訪問的。再比如，有一個高敏感的數據，王二麻子和張三的使用率比其他人高出200%。某天，突然發現客服員工申請vpn急劇增加，調查發現，是由于當地大雪導致交通不暢，因此需要在家辦公。這些具體問題在機器學習里，可以通過異常檢測（或者是離散群分析）分析出來：某幾個人和其他人的不同，從而形成對風險的判斷。當風險點發現，可以通過調查來確認風險，然后再來調整算法。

因此，IAM在新技術的驅動下，會有一個更深刻的變化。

五、數據主體權限管理

之所以有這么個看起來很奇怪的數據主體權限管理，是由于歐盟GDPR（一般數據保護條例）的出臺，GDPR規定了個人數據的權利，包括被遺忘的權利、刪除權等等。這個條例會產生很大的市場，雖然是歐盟的，但所有和歐盟打交道的公司，都要遵從這一標準，否則會被罰款。看起來只是一個合規要求而已，但實際上在實際應用中，也有很多可借鑒的地方。

要保護個人數據，首先得知道這些數據都在哪，也就是數據發現的能力。可以通過對線上數據庫抽樣掃描、大數據倉庫的元數據分析、dlp的本地掃描等來實現。但在實踐中，還會有幾個方面的問題。一是基于正則表達式的規則不靠譜，比如銀行卡號這種信息，用正則表達式會產生大量的誤報問題。二是在大數據平臺的前提下，缺少快速準確的發現工具。三是很多數據都是非結構化的，比如個人交易金額，很難定義出一個規則。四是按照GDPR，還得有個可索引的系統，能夠迅速從全量數據中找到某個人的信息數據元。

與這些問題相對應，機器學習可以解決的規則不準確、非結構化的問題，通過對上下文分析、語義理解、血緣關系追蹤、元數據來提高。而通過在數據節點上分發搜索，能夠全量感知敏感數據位置，再精細一點，可以使用敏感數據熱力圖進行預采樣。

解決了數據發現的問題，還有數據的訪問跟蹤，每個業務、每個應用、每個用戶對數據的訪問，都要能跟蹤到。說起來有點繞，舉個例子，某客戶投訴個人信息被泄漏，按照GDPR，你必須在72小時內作出響應動作來證明自己是清白的/有污點的。這時候你就要能夠立刻知道，數據在哪里，在什么時間什么地點被誰訪問過，然后根據這些上下游分析異常，完美的情況下，應該直接根據自動的風險規則來查出異常。

根據GDPR，你還要能夠服從客戶的意愿，假設客戶要求你立刻刪除所有與他相關的信息。這就需要強制性的響應措施，從不同節點修改/刪除數據。

最后，通過一個類似于數據資產地圖的形式，展現出來。

簡單一點，可以把這個東西理解為數據資產地圖或者數據態勢感知這種dashboard，在下面有很多組件來支撐。

六、數據隱私管理解決方案

也基于整體的需求，出現這一類服務，幫助建設隱私管理。這不是一個技術，而是一個專項的數據安全風險評估。大體上來說，數據安全風險評估的幾個階段：建立團隊—評估風險—設計和實施控制—維護和加強控制—合規性。

從GDPR的情況來看，未來企業可能需要一個“數據隱私保護官”的崗位，當然實際落地也可能是由信息安全來擔任。這就在原來的信息安全上延伸更為廣義了，隱私保護包括的環節很多，從數據采集到數據輸出都有對應的環節存在，也比以前的信息安全范圍更大。能否利用好GDPR來擴展安全部門在企業內部的影響力，是考驗的時刻。

風險評估階段，重點是圍繞數據安全生命周期來開展。從關鍵崗位開始收集信息，包括了數據采集、存儲、使用、轉移、處理的環節。并且以數據和視覺形式記錄信息，也就是數據移動的地圖。通過風險評估識別出差距，并且根據優先級來考慮解決方案。

設計和實施階段，對數據的保護，一定是從高敏感數據開始的。另外，對數據隱私的保護，在開展中可能會面臨各種阻礙，這就要求數據安全部門能夠有技巧的溝通，比如面向高管，這些數據的泄漏可能造成的后果，競爭對手從我們這里拿到了什么數據。面向技術部門，則可以列出競爭對手公司的對標，以及數據安全責任的歸屬。

而在維護和加強控制階段，以國內的大型互聯網企業來說，拍腦門就可以知道的風險域：系統變更、數據變更、國際業務、大型數據倉庫、兼并收購、新增產品、高敏感數據管理、外包管理等，都是高風險區域。事實上很多公司在數據泄漏后，都無法追責，因為并不知道數據是從哪里泄漏出去的，因為根本不知道數據移動地圖是怎樣的。

合規性還是主要是指GDPR，定期評估、記錄、合規性報告等。

目前國內來說，能幫助進行數據安全評估的公司并不多，設計出符合現狀的低成本解決方案的更不多。隨著國內對隱私立法的逐漸重視，這一塊也會逐漸形成市場。

七、綜述

forreste的報告中還提及了一些其他技術，在前面幾塊內容中我也陸陸續續提到了，包括數據發現、數據分類、企業級密鑰管理、應用層加密這些內容。

對數據安全的綜合治理，核心思路其實就是一個：數據流動地圖，抓住這條主線，也就是以數據為核心的安全保護。大數據時代，基于邊界的方法已經過時了，你無法阻擋數據的流動。而在新的時代，還有很多未能解決的難題，換句話說，作為一個安全人員，你是在挖洞的如云高手中殺出一條血路，還是在這個需要探索的領域做先頭兵？