大數據安全保護思考
*本文原創作者：
mcvoodoo
，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載
大數據安全保護思考
隨著大數據時代的來臨，企業數據開始激增，各種數據在雲端、移動設備、關係型資料庫、大資料庫平台、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的報告中還提及了一些其他技術，在前面幾塊內容中我也陸陸續續提到了，包括數據發現、數據分類、企業級密鑰管理、應用層加密這些內容。
對數據安全的綜合治理，核心思路其實就是一個：數據流動地圖，抓住這條主線，也就是以數據為核心的安全保護。大數據時代，基於邊界的方法已經過時了，你無法阻擋數據的流動。而在新的時代，還有很多未能解決的難題，換句話說，作為一個安全人員，你是在挖洞的如雲高手中殺出一條血路，還是在這個需要探索的領域做先頭兵？
*本文原創作者：mcvoodoo，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載
TAG:FreeBuf |