一、背景

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

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

二、概念

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

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

三、全生命周期建設

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

四、數據采集

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

1. 流量保護

全站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隧道化。

2. 業務安全屬性

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

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

3. UUID

UUID最大的作用是建立中間映射層，屏蔽與真實用戶信息的關系鏈。譬如在開放平臺第三方應用數據按需自主授權只能讀取UUID，但不能直接獲取個人的微信號。更潛在的意義是屏蔽個體識別數據，因為實名制，手機號越來越能代表個人標識，且一般綁定了各種賬號，更改成本很高，找到手機號就能對上這個人，因此理論上但凡帶有個體識別數據的信息都需要“轉接橋梁”、匿名化和脫敏。譬如當商家ID能唯一標識一個品牌和店名的時候，這個原本用于程序檢索的數據結構也一下子變成了個體識別數據，也都需要納入保護范疇。

五、前臺業務處理

1. 鑒權模型

在很多企業的應用架構中，只有在業務邏輯最開始處理的部分設置登錄態校驗，后面的事務處理不再會出現用戶鑒權，進而引發了一系列的越權漏洞。事實上越權漏洞并不是這種模型的全部危害，還包括各種K/V、RDS(關系型數據庫)、消息隊列等等，RPC沒有鑒權導致可任意讀取的安全問題。

在數據層只知道請求來自一個數據訪問層中間件，來自一個RPC調用，但完全不知道來自哪個用戶，還是哪個諸如客服系統或其他上游應用，無法判斷究竟對當前的數據(對象)是否擁有完整的訪問權限。絕大多數互聯網公司都用開源軟件或修改后的開源軟件，這類開源軟件的特點是基本不帶安全特性，或者只具備很弱的安全特性，以至于完全不適用于海量IDC規模下的4A模型(認證、授權、管理、審計)。

外面防御做的很好，而在內網可以隨意讀寫，這可能是互聯網行業的普遍現狀了。

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

2. 服務化

服務化并不能認為是一個安全機制，但安全卻是服務化的受益者。我們再來溫習一下當年Bezos在Amazon推行服務化的一紙號令：

• 所有團隊今后將通過服務接口公開他們的數據和功能。
• 團隊必須通過這些接口相互通信。
• 不允許使用其他形式的進程間通信：不允許直接鏈接，不允許直接讀取其他團隊的數據存儲，不支持共享內存模式，無后門。唯一允許的通信是通過網絡上的服務接口調用。
• 他們使用什么技術并不重要。HTTP，Corba，Pubsub，自定義協議 – 無關緊要。貝索斯不在乎。
• 所有服務接口無一例外都必須從頭開始設計為可外部化。也就是說，團隊必須規劃和設計能夠將接口展示給外部開發人員。沒有例外。
• 任何不這樣做的人都會被解雇。

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

3. 內網加密

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

4. 數據庫審計

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

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

六、數據存儲

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

1. HSM/KMS

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

2. 結構化數據

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

3. 文件加密

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

4. 文件系統加密

文件系統加密由于對應用來說是透明的，所以只要應用具備訪問權限，那么文件系統加密對用戶來說也是“無感知”的。它解決的主要是冷數據持久化后存儲介質可訪問的問題，即使去機房拔一塊硬盤，或者從一塊報廢的硬盤上嘗試恢復數據，都是沒有用的。但是對于API鑒權漏洞或者SQL注入而言，顯然文件系統的加密是透明的，只要App有權限，漏洞利用也有權限。

七、訪問和運維

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

1. 角色分離

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

2. 運維審計

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

3. 工具鏈脫敏

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

4. 生產轉測試

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

八、后臺數據處理

1. 數倉安全

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

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

對于數據的分類標識、分布和加工，以及訪問狀況需要有一個全局的大盤視圖，結合數據使用者的行為建立“態勢感知”的能力。

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

2. 匿名化算法

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

九、展示和使用

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

1. 展示脫敏

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

2. 水印

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

3. 安全邊界

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

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

4. 堡壘機

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

十、共享和再分發

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

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

1. 防止下游數據沉淀

首先，所有被第三方調用的數據，如非必要一律脫敏和加密。如果部分場景有必要查詢明細數據，設置單獨的API，并對賬號行為及API查詢做風控。

其次如果自身有云基礎設施，公有云平臺，可以推動第三方上云，從而進行：

• 安全賦能，避免一些因自身能力不足引起的安全問題;
• 數據集中化，在云上集中之后利于實施一站式整體安全解決方案(數據加密，風控，反爬和數據泄露檢測類服務)，大幅度降低外部風險并在一定程度上降低作惡和監守自盜的問題。

2. 反爬

反爬在這里主要是針對公開頁面，或通過接口爬取的信息，因為脫敏這件事不可能在所有的環節做的很徹底，所以即便通過大量的“公開”信息也可以進行匯聚和數據挖掘，最終形成一些諸如用戶關系鏈，經營數據或輔助決策類數據，造成過度信息披露的影響。

3. 授權審核

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

4. 法律條款

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

十一、數據銷毀

數據銷毀主要是指安全刪除，這里特別強調是，往往數據的主實例容易在視野范圍內，而把備份類的數據忽略掉。

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

十二、數據的邊界

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

1. 企業內部

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

2. 生態建設

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

十三、ROI和建設次第

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

1. 基礎

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

2. 日志收集

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

• 辦公網絡是否BeyondCorp化，這給數據風控提供了極大地便利;
• 服務化，所有的數據調用皆以API的形式，給日志記錄提供了統一的形式。

3. 數據風控

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