網際網路企業：如何建設資料安全體系？

　　轉載自，原文作者：趙彥
　　一、背景

　　Facebook資料洩露事件一度成為網際網路行業的焦點，幾百億美元市值瞬間蒸發，這個代價足以在地球上養活一支絕對龐大的安全團隊，甚至可以直接收購幾家規模比較大的安全公司了。

　　雖然媒體上發表了很多譴責的言論，但實事求是地講，Facebook面臨是一個業界難題，任何一家千億美元的網際網路公司面對這種問題，可能都沒有太大的抵抗力，僅僅是因為全球區域的法律和國情不同，暫時不被頂上輿論的浪尖罷了。但是全球的趨勢是越來越重視隱私，在安全領域中，資料安全這個子領域也重新被提到了一個新的高度，所以筆者就藉機來說一下資料安全建設。(按照慣例，本文涉及敏感資訊的部分會進行省略處理或者一筆帶過。)

　　二、概念

　　這裡特別強調一下，“隱私保護”和“資料安全”是兩個完全不同的概念，隱私保護對於安全專業人員來說是一個更加偏向合規的事情，主要是指資料過度收集和資料濫用方面對法律法規的遵從性，對很多把自身的盈利模式建立在資料之上的網際網路公司而言，這個問題特別有挑戰。有些公司甚至把自己定義為資料公司，如果不用資料來做點什麼，要麼使用者體驗大打折扣，要麼商業價值減半。GDPR即將實施，有些公司或將離場歐洲，就足見這件事的難度不容小覷。當然市場上也有一些特別推崇隱私保護的公司，他們很大程度上並不能真正代表使用者意願，而只是因為自家沒有資料或缺少資料，隨口說說而已。

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

　　三、全生命週期建設

　　儘管業內也有同學表示資料是沒有邊界的，如果按照洩露途徑去做可能起不到“根治”的效果，但事實上以目前的技術是做不到無邊界資料安全的。下圖彙總了一個全生命週期內的資料安全措施：

　　

　　資料洩露有一部分原因是使用者會話流量被複制，儘管有點技術門檻，但也是發生頻率比較高的安全事件之一，只是是很多企業沒有感知到而已。下面從幾個維度來說明資料採集階段的資料保護。

　　流量保護

　　全站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能唯一標識一個品牌和店名的時候，這個原本用於程式檢索的資料結構也一下子變成了個體識別資料，也都需要納入保護範疇。

　　五、前臺業務處理

　　鑑權模型

　　在很多企業的應用架構中，只有在業務邏輯最開始處理的部分設定登入態校驗，後面的事務處理不再會出現使用者鑑權，進而引發了一系列的越權漏洞。事實上越權漏洞並不是這種模型的全部危害，還包括各種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為了洩憤，把資料庫拖走或者刪除這種危險動作。通常大型網際網路公司都會有資料庫訪問層元件，透過這個元件，可以審計、控制危險操作。

　　六、資料儲存

　　資料儲存之於資料安全最大的部分是資料加密。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有許可權，漏洞利用也有許可權。

　　七、訪問和運維

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

　　角色分離

　　研發和運維要分離，金鑰持有者和資料運維者要分離，運維角色和審計角色要分離。特權賬號須回收，滿足最小許可權，多權分立的審計原則。

　　運維審計

　　堡壘機(跳板機)是一種針對人肉運維的常規審計手段，隨著大型IDC中運維自動化的加深，運維操作都被API化，所以針對這些API的呼叫也需要被列入審計範疇，數量級比較大的情況下需要使用資料探勘的方法。

　　工具鏈脫敏

　　典型的工具脫敏包括監控系統和Debug工具/日誌。在監控系統類目中，通常由於運維和安全的監控系統包含了全站使用者流量，對使用者Token和敏感資料需要脫敏，同時這些系統也可能透過簡單的計算得出一些運營資料，譬如模糊的交易數目，這些都是需要脫敏的地方。在Debug方面也出過Debug Log帶有CVV碼等比較嚴重的安全事件，因此都是需要注意的資料洩漏點。

　　生產轉測試

　　生產環境和測試環境必須有嚴格定義和分離，如特殊情況生產資料需要轉測試，必須經過脫敏、匿名化。

　　八、後臺資料處理

　　數倉安全

　　目前大資料處理基本是每個網際網路公司的必需品，通常承載了公司所有的使用者資料，甚至有的公司用於資料處理的算力超過用於前臺事務處理的算力。以Hadoop為代表的開源平臺本身不太具備很強的安全能力，因此在成為公有云服務前需要做很多改造。在公司比較小的時候可以選擇內部信任模式，不去過於糾結開源平臺本身的安全，但在公司規模比較大，資料RD和BI分析師成千上萬的時候，內部信任模式就需要被拋棄了，這時候需要的是一站式的授權&審計平臺，需要看到資料的血緣繼承關係，需要高敏資料仍然被加密。

　　在這種規模下，工具鏈的成熟度會決定資料本地化的需求，工具鏈越成熟資料就越不需要落到開發者本地，這樣就能大幅提升安全能力。同時鼓勵一切計算機器化&程式化&自動化，儘可能避免人工操作。

　　對於資料的分類標識、分佈和加工，以及訪問狀況需要有一個全域性的大盤檢視，結合資料使用者的行為建立“態勢感知”的能力。

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

　　匿名化演算法

　　匿名化演算法更大的意義其實在於隱私保護而不在於資料安全(關於隱私保護部分筆者打算另外單獨寫一篇)，如果說對資料安全有意義，匿名化可能在於減少資料被濫用的可能性，以及減弱資料洩漏後的影響面。

　　九、展示和使用

　　這個環節泛指大量的應用系統後臺、運營報表以及所有可以展示和看到資料的地方，都可能是資料洩露的重災區。

　　展示脫敏

　　對頁面上需要展示的敏感資訊進行脫敏。一種是完全脫敏，部分欄位打碼後不再展示完整的資訊和欄位，另一種是不完全脫敏，預設展示脫敏後的資訊，但仍然保留檢視明細的按鈕(API)，這樣所有的檢視明細都會有一條Log，對應審計需求。具體用哪種脫敏需要考慮工作場景和效率綜合評估。

　　水印

　　水印主要用在截圖的場景，分為明水印和暗水印，明水印是肉眼可見的，暗水印是肉眼不可見暗藏在圖片裡的識別資訊。水印的形式也有很多種，有抵抗截圖的，也有抵抗拍照的。這裡面也涉及很多對抗元素不一一展開。

　　安全邊界

　　這裡的邊界其實是辦公網和生產網組成的公司資料邊界，由於辦公移動化程度的加深，這種邊界被進一步模糊化，所以這種邊界實際上是邏輯的，而非物理上的，它等價於公司辦公網路，生產網路和支援MDM的認證移動裝置。對這個邊界內的資料，使用DLP來做檢測，DLP這個名詞很早就有，但實際上它的產品形態和技術已經發生了變化，用於應對大規模環境下重檢測，輕阻斷的資料保護模式。

　　除了DLP之外，整個辦公網路會採用BeyondCorp的“零信任”架構，對整個的OA類應用實現動態訪問控制，全面去除匿名化訪問，全部HTTPS，根據角色最小許可權化，也就是每個賬號即使洩露能訪問到的也有限。同時提高賬號洩露的成本(多因素認證)和檢測手段，一旦檢測到洩露提供遠端擦除的能力。

　　堡壘機

　　堡壘機作為一種備選的方式主要用來解決區域性場景下避免操作和開發人員將敏感資料下載到本地的方法，這種方法跟VDI類似，比較厚重，使用門檻不高，不適合大面積普遍推廣。

　　十、共享和再分發

　　對於業務盤子比較大的公司而言，其資料都不會是隻在自己的系統內流轉，通常都有開放平臺，有貫穿整個產業鏈的上下游資料應用。Facebook事件曝光其實就屬於這類問題，不開放是不可能的，因為這影響了公司的核心—–賴以生存的商業價值。

　　所以這個問題的解決方案等價於：1)核心有限妥協(為保障使用者隱私犧牲一部分商業利益);2)一站式資料安全服務。

　　防止下游資料沉澱

　　首先，所有被第三方呼叫的資料，如非必要一律脫敏和加密。如果部分場景有必要查詢明細資料，設定單獨的API，並對賬號行為及API查詢做風控。

　　其次如果自身有云基礎設施，公有云平臺，可以推動第三方上雲，從而進行(1)安全賦能，避免一些因自身能力不足引起的安全問題;(2)資料集中化，在雲上集中之後利於實施一站式整體安全解決方案(資料加密，風控，反爬和資料洩露檢測類服務)，大幅度降低外部風險並在一定程度上降低作惡和監守自盜的問題。

　　反爬

　　反爬在這裡主要是針對公開頁面，或透過介面爬取的資訊，因為脫敏這件事不可能在所有的環節做的很徹底，所以即便透過大量的“公開”資訊也可以進行匯聚和資料探勘，最終形成一些諸如使用者關係鏈，經營資料或輔助決策類資料，造成過度資訊披露的影響。

　　授權稽核

　　設定專門的團隊對開放平臺的第三方進行機器稽核及人工稽核，禁止“無照經營”和虛假三方，提高惡意第三方接入的門檻，同時給開發者/合作方公司信譽評級提供基礎。

　　法律條款

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

　　十一、資料銷燬

　　資料銷燬主要是指安全刪除，這裡特別強調是，往往資料的主例項容易在視野範圍內，而把備份類的資料忽略掉。

　　如果希望做到快速的安全刪除，最好使用加密資料的方法，因為完整覆寫不太可能在短時間內完成，但是加密資料的安全刪除只要刪除金鑰即可。

　　十二、資料的邊界

　　資料治理常常涉及到“邊界”問題，不管你承不承認，邊界其實總是存在的，只不過表達方式不一樣，如果真的沒有邊界，也就不存在資料安全一說。

　　企業內部

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

　　生態建設

　　為了能讓資料安全建設在企業內部價值鏈之外的部分更加平坦化，大型企業可能需要透過投資收購等手段獲得上下游企業的資料控制權及標準制定權，從而在大生態裡將自己的資料安全標準推行到底。如果不能掌控資料，資料安全也無從談起。在話語權不足的情況下，現實選擇是提供更多的工具給合作方，也是一種資料控制能力的延伸。

　　十三、ROI和建設次第

　　對於很多規模不大的公司而言，上述資料安全建設手段可能真的有點多，對於小一點公司即便什麼事不幹可能也消化不了那麼多需求，因為開源軟體和大多數的開發框架都不具備這些能力，需要DIY的成分很高，所以我們梳理一下前置條件，優先順序和ROI，讓資料安全這件事對任何人都是可以接受的，當然這種情況其實也對應了一些創業空間。

　　基礎

　　賬號、許可權、日誌、脫敏和加密這些都是資料安全的基礎。同時還有一些不完全是基礎，但能體現為優勢的部分：基礎架構統一，應用架構統一，如果這兩者高度統一，資料安全建設能事半功倍。

　　日誌收集

　　日誌是做資料風控的基礎，但這裡面也有兩個比較重要的因素：

　　? 辦公網路是否BeyondCorp化，這給資料風控提供了極大地便利。

　　? 服務化，所有的資料呼叫皆以API的形式，給日誌記錄提供了統一的形式。

　　資料風控

　　在資料安全中，“放之四海皆準”的工作就是資料風控，適用於各類企業，結合裝置資訊、賬號行為、查詢/爬(讀)取行為做風控模型。對於面向2C使用者類，2B第三方合作類，OA員工賬號類都是適用的。具體的策略思想筆者打算在後續文章《入侵防禦體系建設》中詳細描述。