互聯網企業：如何建設數據安全體系？

時間 2019-11-16

原文原文鏈接

1、背景

Facebook數據泄露事件一度成爲互聯網行業的焦點，幾百億美圓市值瞬間蒸發，這個代價足以在地球上養活一支絕對龐大的安全團隊，甚至能夠直接收購幾家規模比較大的安全公司了。html

雖然媒體上發表了不少譴責的言論，但實事求是地講，Facebook面臨是一個業界難題，任何一家千億美圓的互聯網公司面對這種問題，可能都沒有太大的抵抗力，僅僅是由於全球區域的法律和國情不一樣，暫時不被頂上輿論的浪尖罷了。可是全球的趨勢是愈來愈重視隱私，在安全領域中，數據安全這個子領域也從新被提到了一個新的高度，因此筆者就藉機來講一下數據安全建設。（按照慣例，本文涉及敏感信息的部分會進行省略處理或者一筆帶過。）算法

2、概念

這裏特別強調一下，「隱私保護」和「數據安全」是兩個徹底不一樣的概念，隱私保護對於安全專業人員來講是一個更加偏向合規的事情，主要是指數據過分收集和數據濫用方面對法律法規的聽從性，對不少把自身的盈利模式創建在數據之上的互聯網公司而言，這個問題特別有挑戰。有些公司甚至把本身定義爲數據公司，若是不用數據來作點什麼，要麼用戶體驗大打折扣，要麼商業價值減半。GDPR即將實施，有些公司或將離場歐洲，就足見這件事的難度不容小覷。固然市場上也有一些特別推崇隱私保護的公司，他們很大程度上並不能真正表明用戶意願，而只是由於自家沒有數據或缺乏數據，隨口說說而已。數據庫

數據安全是實現隱私保護的最重要手段之一。對安全有必定了解的讀者可能也會察覺到，數據安全並非一個獨立的要素，而是須要連同網絡安全、系統安全、業務安全等多種因素，只有所有都作好了，才能最終達到數據安全的效果。因此本文儘量的以數據安全爲核心，但沒有把跟數據安全弱相關的傳統安全體系防禦所有列出來，對於數據安全這個命題而言儘量的系統化，又避免囉嗦。另外筆者也打算在夏季和秋季把其餘子領域的話題單獨成文，譬如海量IDC下的入侵防護體系等，敬請期待。瀏覽器

3、全生命週期建設

儘管業內也有同窗表示數據是沒有邊界的，若是按照泄露途徑去作可能起不到「根治」的效果，但事實上以目前的技術是作不到無邊界數據安全的。下圖彙總了一個全生命週期內的數據安全措施：安全

4、數據採集

數據泄露有一部分緣由是用戶會話流量被複制，儘管有點技術門檻，但也是發生頻率比較高的安全事件之一，只是是不少企業沒有感知到而已。下面從幾個維度來講明數據採集階段的數據保護。服務器

流量保護

全站HTTPS是目前互聯網的主流趨勢，它解決的是用戶到服務器之間鏈路被嗅探、流量鏡像、數據被第三方掠走的問題。這些問題實際上是比較嚴重的，好比電信運營商內部偶有舞弊現象，各類導流劫持插廣告（固然也能夠存數據，插木馬），甚至連AWS也被劫持DNS請求，對於掌握鏈路資源的人來講無異於能夠發動一次「核戰爭」。即便目標對象IDC入侵防護作的好，攻擊者也能夠不經過正面滲透，而是直接複製流量，甚至定向APT，最終只是看操縱流量後達到目的的收益是否具備性價比。微信

HTTPS是一個表面現象，它暗示着任何互聯網上未加密的流量都是沒有隱私和數據安全的，同時，也不是說有了HTTPS就必定安全。HTTPS自己也有各類安全問題，好比使用不安全的協議TLS1.0、SSL3，採用已通過時的弱加密算法套件，實現框架安全漏洞如心臟滴血，還有不少的數字證書自己致使的安全問題。網絡

全站HTTPS會帶來的附帶問題是CDN和高防IP。歷史上有家很大的互聯網公司被NSA嗅探獲取了用戶數據，緣由是CDN回源時沒有使用加密，即用戶瀏覽器到CDN是加密的，但CDN到IDC源站是明文的。若是CDN到源站加密就須要把網站的證書私鑰給到CDN廠商，這對於沒有徹底自建CDN的公司而言也是一個很大的安全隱患，因此後來衍生出了Keyless CDN技術，無需給出本身的證書就能夠實現CDN回源加密。數據結構

廣域網流量未加密的問題也要避免出如今「自家後院」——IDC間的流量複製和備份同步，對應的解決方案是跨IDC流量自動加密、TLS隧道化。架構

業務安全屬性

在用戶到服務器之間還涉及兩個業務安全方向的問題。第一個問題是帳號安全，只要帳號泄露（撞庫&爆破）到達必定數量級，把這些帳號的數據彙總一下，就一定能夠產生批量數據泄露的效果。

第二個問題是反爬，爬蟲的問題存在於一切可經過頁面、接口獲取數據的場合，大概1小時爬個幾百萬條數據是一點問題都沒有的，對於沒有完全脫敏的數據，爬蟲的效果有時候等價於「黑掉」服務器。帳號主動地或被動地泄露+爬蟲技術，培育了很多黑產和數據獲取的灰色地帶。

UUID

UUID最大的做用是創建中間映射層，屏蔽與真實用戶信息的關係鏈。譬如在開放平臺第三方應用數據按需自主受權只能讀取UUID，但不能直接獲取我的的微信號。更潛在的意義是屏蔽個體識別數據，由於實名制，手機號愈來愈能表明我的標識，且通常綁定了各類帳號，更改爲本很高，找到手機號就能對上這我的，所以理論上但凡帶有個體識別數據的信息都須要「轉接橋樑」、匿名化和脫敏。譬如當商家ID能惟一標識一個品牌和店名的時候，這個本來用於程序檢索的數據結構也一會兒變成了個體識別數據，也都須要歸入保護範疇。

5、前臺業務處理

鑑權模型

在不少企業的應用架構中，只有在業務邏輯最開始處理的部分設置登陸態校驗，後面的事務處理再也不會出現用戶鑑權，進而引起了一系列的越權漏洞。事實上越權漏洞並非這種模型的所有危害，還包括各類K/V、RDS（關係型數據庫）、消息隊列等等，RPC沒有鑑權致使可任意讀取的安全問題。

在數據層只知道請求來自一個數據訪問層中間件，來自一個RPC調用，但徹底不知道來自哪一個用戶，仍是哪一個諸如客服系統或其餘上游應用，沒法判斷究竟對當前的數據（對象）是否擁有完整的訪問權限。絕大多數互聯網公司都用開源軟件或修改後的開源軟件，這類開源軟件的特色是基本不帶安全特性，或者只具有很弱的安全特性，以致於徹底不適用於海量IDC規模下的4A模型（認證、受權、管理、審計）。外面防護作的很好，而在內網能夠隨意讀寫，這多是互聯網行業的廣泛現狀了。主要矛盾仍是鑑權顆粒度和彈性計算的問題，關於這個問題的解決方案能夠參考筆者的另一篇文章《初探下一代網絡隔離與訪問控制》，其中提到Google的方法是內網RPC鑑權，因爲Google的內網只有RPC一種協議，因此就規避了上述大多數安全問題。

對於業務流的鑑權模型，本質上是須要作到Data和App分離，創建Data默認不信任App的模型，而應用中的全程Ticket和逐級鑑權是這種思想下的具體實現方法。

服務化

服務化並不能認爲是一個安全機制，但安全倒是服務化的受益者。咱們再來溫習一下當年Bezos在Amazon推行服務化的一紙號令： 1）全部團隊從此將經過服務接口公開他們的數據和功能。 2）團隊必須經過這些接口相互通訊。 3）不容許使用其餘形式的進程間通訊：不容許直接連接，不容許直接讀取其餘團隊的數據存儲，不支持共享內存模式，無後門。惟一容許的通訊是經過網絡上的服務接口調用。 4）他們使用什麼技術並不重要。HTTP，Corba，Pubsub，自定義協議 - 可有可無。貝索斯不在意。 5）全部服務接口無一例外都必須從頭開始設計爲可外部化。也就是說，團隊必須規劃和設計可以將接口展現給外部開發人員。沒有例外。 6）任何不這樣作的人都會被解僱。

服務化的結果在安全上的意義是必須經過接口訪問數據，屏蔽了各類直接訪問數據的途徑，有了API控制和審計就會方便不少。

內網加密

一些業界Top的公司甚至在IDC內網裏也作到了加密，也就是在後臺的組件之間的數據傳輸都是加密的，譬如Goolge的RPC加密和Amazon的TLS。因爲IDC內網的流量比公網大得多，因此這裏是比較考驗工程能力的地方。對於大多數主營業務迭代仍然感受有壓力的公司而言，這個需求可能有點苛刻了，因此筆者認爲用這些指標來衡量一家公司的安全能力屬於哪個檔位是合理的。私有協議算不算？若是私有協議裏不含有標準TLS（SHA256）以上強度的加密，或者只是信息不對稱的哈希，筆者認爲都不算。

數據庫審計

數據庫審計/數據庫防火牆是一個入侵檢測/防護組件，是一個強對抗領域的產品，可是在數據安全方面它的意義也是明顯的：防止SQL注入批量拉取數據，檢測API鑑權類漏洞和爬蟲的成功訪問。

除此以外，對數據庫的審計還有一層含義，是指內部人員對數據庫的操做，要避免某個RD或DBA爲了泄憤，把數據庫拖走或者刪除這種危險動做。一般大型互聯網公司都會有數據庫訪問層組件，經過這個組件，能夠審計、控制危險操做。

6、數據存儲

數據存儲之於數據安全最大的部分是數據加密。Amazon CTO Werner Vogels曾經總結：「AWS全部的新服務，在原型設計階段就會考慮到對數據加密的支持。」國外的互聯網公司中廣泛比較重視數據加密。

HSM/KMS

業界的廣泛問題是不加密，或者加密了但沒有使用正確的方法：使用自定義UDF，算法選用不正確或加密強度不合適，或隨機數問題，或者密鑰沒有Rotation機制，密鑰沒有存儲在KMS中。數據加密的正確方法自己就是可信計算的思路，信任根存儲在HSM中，加密採用分層密鑰結構，以方便動態轉換和過時失效。當Intel CPU廣泛開始支持SGX安全特性時，密鑰、指紋、憑證等數據的處理也將以更加平民化的方式使用相似Trustzone的芯片級隔離技術。

結構化數據

這裏主要是指結構化數據靜態加密，以對稱加密算法對諸如手機、身份證、銀行卡等須要保密的字段加密持久化，另外除了數據庫外，數倉裏的加密也是相似的。好比，在 Amazon Redshift 服務中，每個數據塊都經過一個隨機的密鑰進行加密，而這些隨機密鑰則由一個主密鑰進行加密存儲。用戶能夠自定義這個主密鑰，這樣也就保證了只有用戶本人才能訪問這些機密數據或敏感信息。鑑於這部分屬於比較經常使用的技術，再也不展開。

文件加密

對單個文件獨立加密，通常狀況下采用分塊加密，典型的場景譬如在《互聯網企業安全高級指南》一書中提到的iCloud將手機備份分塊加密後存儲於AWS的S3，每個文件切塊用隨機密鑰加密後放在文件的meta data中，meta data再用file key包裹，file key再用特定類型的data key（涉及數據類型和訪問權限）加密，而後data key被master key包裹。

文件系統加密

文件系統加密因爲對應用來講是透明的，因此只要應用具有訪問權限，那麼文件系統加密對用戶來講也是「無感知」的。它解決的主要是冷數據持久化後存儲介質可訪問的問題，即便去機房拔一塊硬盤，或者從一塊報廢的硬盤上嘗試恢復數據，都是沒有用的。可是對於API鑑權漏洞或者SQL注入而言，顯然文件系統的加密是透明的，只要App有權限，漏洞利用也有權限。

7、訪問和運維

在這個環節，主要闡述防止內部人員越權的一些措施。

角色分離

研發和運維要分離，密鑰持有者和數據運維者要分離，運維角色和審計角色要分離。特權帳號須回收，知足最小權限，多權分立的審計原則。

運維審計

堡壘機（跳板機）是一種針對人肉運維的常規審計手段，隨着大型IDC中運維自動化的加深，運維操做都被API化，因此針對這些API的調用也須要被列入審計範疇，數量級比較大的狀況下須要使用數據挖掘的方法。

工具鏈脫敏

典型的工具脫敏包括監控系統和Debug工具/日誌。在監控系統類目中，一般因爲運維和安全的監控系統包含了全站用戶流量，對用戶Token和敏感數據須要脫敏，同時這些系統也可能經過簡單的計算得出一些運營數據，譬如模糊的交易數目，這些都是須要脫敏的地方。在Debug方面也出過Debug Log帶有CVV碼等比較嚴重的安全事件，所以都是須要注意的數據泄漏點。

生產轉測試

生產環境和測試環境必須有嚴格定義和分離，如特殊狀況生產數據須要轉測試，必須通過脫敏、匿名化。

8、後臺數據處理

數倉安全

目前大數據處理基本是每一個互聯網公司的必需品，一般承載了公司全部的用戶數據，甚至有的公司用於數據處理的算力超過用於前臺事務處理的算力。以Hadoop爲表明的開源平臺自己不太具有很強的安全能力，所以在成爲公有云服務前須要作不少改造。在公司比較小的時候能夠選擇內部信任模式，不去過於糾結開源平臺自己的安全，但在公司規模比較大，數據RD和BI分析師成千上萬的時候，內部信任模式就須要被拋棄了，這時候須要的是一站式的受權&審計平臺，須要看到數據的血緣繼承關係，須要高敏數據仍然被加密。在這種規模下，工具鏈的成熟度會決定數據本地化的需求，工具鏈越成熟數據就越不須要落到開發者本地，這樣就能大幅提高安全能力。同時鼓勵一切計算機器化&程序化&自動化，儘量避免人工操做。

對於數據的分類標識、分佈和加工，以及訪問情況須要有一個全局的大盤視圖，結合數據使用者的行爲創建「態勢感知」的能力。

由於數倉是最大的數據集散地，所以每家公司對於數據歸屬的價值觀也會影響數據安全方案的落地形態：放逐+檢測型 or 隔離+管控型。

匿名化算法

匿名化算法更大的意義其實在於隱私保護而不在於數據安全（關於隱私保護部分筆者打算另外單獨寫一篇），若是說對數據安全有意義，匿名化可能在於減小數據被濫用的可能性，以及減弱數據泄漏後的影響面。

9、展現和使用

這個環節泛指大量的應用系統後臺、運營報表以及全部能夠展現和看到數據的地方，均可能是數據泄露的重災區。

展現脫敏

對頁面上須要展現的敏感信息進行脫敏。一種是徹底脫敏，部分字段打碼後再也不展現完整的信息和字段，另外一種是不徹底脫敏，默認展現脫敏後的信息，但仍然保留查看明細的按鈕（API），這樣全部的查看明細都會有一條Log，對應審計需求。具體用哪一種脫敏須要考慮工做場景和效率綜合評估。

水印

水印主要用在截圖的場景，分爲明水印和暗水印，明水印是肉眼可見的，暗水印是肉眼不可見暗藏在圖片裏的識別信息。水印的形式也有不少種，有抵抗截屏的，也有抵抗拍照的。這裏面也涉及不少對抗元素不一一展開。

安全邊界

這裏的邊界實際上是辦公網和生產網組成的公司數據邊界，因爲辦公移動化程度的加深，這種邊界被進一步模糊化，因此這種邊界其實是邏輯的，而非物理上的，它等價於公司辦公網絡，生產網絡和支持MDM的認證移動設備。對這個邊界內的數據，使用DLP來作檢測，DLP這個名詞很早就有，但實際上它的產品形態和技術已經發生了變化，用於應對大規模環境下重檢測，輕阻斷的數據保護模式。

除了DLP以外，整個辦公網絡會採用BeyondCorp的「零信任」架構，對整個的OA類應用實現動態訪問控制，全面去除匿名化訪問，所有HTTPS，根據角色最小權限化，也就是每一個帳號即便泄露能訪問到的也有限。同時提升帳號泄露的成本（多因素認證）和檢測手段，一旦檢測到泄露提供遠程擦除的能力。

堡壘機

堡壘機做爲一種備選的方式主要用來解決局部場景下避免操做和開發人員將敏感數據下載到本地的方法，這種方法跟VDI相似，比較厚重，使用門檻不高，不適合大面積廣泛推廣。

10、共享和再分發

對於業務盤子比較大的公司而言，其數據都不會是隻在本身的系統內流轉，一般都有開放平臺，有貫穿整個產業鏈的上下游數據應用。Facebook事件曝光其實就屬於這類問題，不開放是不可能的，由於這影響了公司的內核—-賴以生存的商業價值。

因此這個問題的解決方案等價於：1）內核有限妥協（爲保障用戶隱私犧牲一部分商業利益）；2）一站式數據安全服務。

防止下游數據沉澱

首先，全部被第三方調用的數據，如非必要一概脫敏和加密。若是部分場景有必要查詢明細數據，設置單獨的API，並對帳號行爲及API查詢作風控。

其次若是自身有云基礎設施，公有云平臺，能夠推進第三方上雲，從而進行（1）安全賦能，避免一些因自身能力不足引發的安全問題；（2）數據集中化，在雲上集中以後利於實施一站式總體安全解決方案（數據加密，風控，反爬和數據泄露檢測類服務），大幅度下降外部風險並在必定程度上下降做惡和監守自盜的問題。

反爬

反爬在這裏主要是針對公開頁面，或經過接口爬取的信息，由於脫敏這件事不可能在全部的環節作的很完全，因此即使經過大量的「公開」信息也能夠進行匯聚和數據挖掘，最終造成一些諸如用戶關係鏈，經營數據或輔助決策類數據，形成過分信息披露的影響。

受權審覈

設置專門的團隊對開放平臺的第三方進行機器審覈及人工審覈，禁止「無照經營」和虛假三方，提升惡意第三方接入的門檻，同時給開發者/合做方公司信譽評級提供基礎。

法律條款

全部的第三方接入必須有嚴格的用戶協議，明確數據使用權利，數據披露限制和隱私保護的要求。像GDPR同樣，明確數據處理者角色和懲罰條約。

11、數據銷燬

數據銷燬主要是指安全刪除，這裏特別強調是，每每數據的主實例容易在視野範圍內，而把備份類的數據忽略掉。若是但願作到快速的安全刪除，最好使用加密數據的方法，由於完整覆寫不太可能在短期內完成，可是加密數據的安全刪除只要刪除密鑰便可。

12、數據的邊界

數據治理經常涉及到「邊界」問題，無論你承不認可，邊界其實老是存在的，只不過表達方式不同，若是真的沒有邊界，也就不存在數據安全一說。

企業內部

在不超越網絡安全法和隱私保護規定的狀況下，法律上企業對內部的數據都擁有絕對控制權，這使得企業內部的數據安全建設實際上最後會轉化爲一項運營類的工做，挑戰難度也無非是各個業務方推進落地的成本。但對規模比較大的公司而言，光企業內部自治多是不夠的，因此數據安全會衍生出產業鏈上閉環的需求。

生態建設

爲了能讓數據安全建設在企業內部價值鏈以外的部分更加平坦化，大型企業可能須要經過投資收購等手段得到上下游企業的數據控制權及標準制定權，從而在大生態裏將本身的數據安全標準推行到底。若是不能掌控數據，數據安全也無從談起。在話語權不足的狀況下，現實選擇是提供更多的工具給合做方，也是一種數據控制能力的延伸。

十3、ROI和建設次第

對於不少規模不大的公司而言，上述數據安全建設手段可能真的有點多，對於小一點公司即使什麼事不幹可能也消化不了那麼多需求，由於開源軟件和大多數的開發框架都不具有這些能力，須要DIY的成分很高，因此咱們梳理一下前置條件，優先級和ROI，讓數據安全這件事對任何人都是能夠接受的，固然這種狀況其實也對應了一些創業空間。

基礎

帳號、權限、日誌、脫敏和加密這些都是數據安全的基礎。同時還有一些不徹底是基礎，但能體現爲優點的部分：基礎架構統一，應用架構統一，若是這二者高度統一，數據安全建設能事半功倍。

日誌收集

日誌是作數據風控的基礎，但這裏面也有兩個比較重要的因素：

1.辦公網絡是否BeyondCorp化，這給數據風控提供了極大地便利。
2.服務化，全部的數據調用皆以API的形式，給日誌記錄提供了統一的形式。

數據風控

在數據安全中，「放之四海皆準」的工做就是數據風控，適用於各種企業，結合設備信息、帳號行爲、查詢/爬(讀)取行爲作風控模型。對於面向2C用戶類，2B第三方合做類，OA員工帳號類都是適用的。具體的策略思想筆者打算在後續文章《入侵防護體系建設》中詳細描述。

做者簡介

趙彥，現任美團點評集團安所有高級總監，負責集團旗下全線業務的信息安全與隱私保護。加盟美團點評前，曾任華爲雲安全首席架構師，奇虎360企業安全技術總監、久遊網安全總監、綠盟科技安全專家等職務。白帽子時代是Ph4nt0m Security Team的核心成員，互聯網安全領域第一代資深從業者。

團隊簡介

美團點評集團安所有的大多數核心人員，擁有多年互聯網以及安全領域實踐經驗，不少同窗參與過大型互聯網公司的安全體系建設，其中也不乏全球化安全運營人才，具有百萬級IDC規模攻防對抗的經驗。安所有也不乏CVE「挖掘聖手」，還有不少受邀在Blackhat等國際頂級會議發言的演講者們。團隊成員中有滲透、有Web，有二進制，有內核，有全球合規與隱私保護，有分佈式系統開發者，有大數據分析，有算法，固然，還有不少漂亮的運營妹子。

咱們想作的一套百萬級IDC規模和數十萬終端移動辦公網絡的自適應安全體系，包括構建於零信任架構之上，橫跨雲基礎設施[網絡層，虛擬化/容器層，Server 軟件層（內核態/用戶態）、語言虛擬機層(JVM/JS V8)、Web應用層、數據訪問層]的基於大數據+機器學習的全自動安全事件感知系統並努力打造業界前沿的內置式安全架構和縱深防護體系。藉助美團點評的高速發展和業務複雜度，爲業界最佳安全實踐的落地以及新興領域的探索提供安全從業者廣闊的平臺。