一、背景
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
五、前臺業務處理
鑑權模型
在很多企業的應用架構中，只有在業務邏輯最開始處理的部分設置登錄態校驗，後面的事務處理不再會出現用戶鑑權，進而引發了一系列的越權漏洞。事實上越權漏洞並不是這種模型的全部危害，還包括各種K/V、RDS（關係型數據庫）、消息隊列等等，RPC沒有鑑權導致可任意讀取的安全問題。
外面防禦做的很好，而在內網可以隨意讀寫，這可能是互聯網行業的普遍現狀了。主要矛盾還是鑑權顆粒度和彈性計算的問題，關於這個問題的解決方案可以參考筆者的另外一篇文章《初探下一代網絡隔離與訪問控制》，其中提到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碼等比較嚴重的安全事件，因此都是需要注意的數據洩漏點。
生產轉測試
生產環境和測試環境必須有嚴格定義和分離，如特殊情況生產數據需要轉測試，必須經過脫敏、匿名化。
八、後臺數據處理
數倉安全
在這種規模下，工具鏈的成熟度會決定數據本地化的需求，工具鏈越成熟數據就越不需要落到開發者本地，這樣就能大幅提升安全能力。同時鼓勵一切計算機器化&程序化&自動化，儘可能避免人工操作。
對於數據的分類標識、分佈和加工，以及訪問狀況需要有一個全局的大盤視圖，結合數據使用者的行為建立“態勢感知”的能力。
因為數倉是最大的數據集散地，因此每家公司對於數據歸屬的價值觀也會影響數據安全方案的落地形態：放逐+檢測型 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員工賬號類都是適用的。具體的策略思想筆者打算在後續文章《入侵防禦體系建設》中詳細描述。
趙彥，現任美團點評集團安全部高級總監，負責集團旗下全線業務的信息安全與隱私保護。加盟美團點評前，曾任華為雲安全首席架構師，奇虎360企業安全技術總監、久遊網安全總監、綠盟科技安全專家等職務。白帽子時代是Ph4nt0m Security Team的核心成員，互聯網安全領域第一代資深從業者。
團隊簡介
美團點評集團安全部的大多數核心人員，擁有多年互聯網以及安全領域實踐經驗，很多同學參與過大型互聯網公司的安全體系建設，其中也不乏全球化安全運營人才，具備百萬級IDC規模攻防對抗的經驗。安全部也不乏CVE“挖掘聖手”，還有很多受邀在Blackhat等國際頂級會議發言的演講者們。團隊成員中有滲透、有Web，有二進制，有內核，有全球合規與隱私保護，有分佈式系統開發者，有大數據分析，有算法，當然，還有很多漂亮的運營妹子。
我們想做的一套百萬級IDC規模和數十萬終端移動辦公網絡的自適應安全體系，包括構建於零信任架構之上，橫跨雲基礎設施[網絡層，虛擬化/容器層，Server 軟件層（內核態/用戶態）、語言虛擬機層(JVM/JS V8)、Web應用層、數據訪問層]的基於大數據+機器學習的全自動安全事件感知系統並努力打造業界前沿的內置式安全架構和縱深防禦體系。藉助美團點評的高速發展和業務複雜度，為業界最佳安全實踐的落地以及新興領域的探索提供安全從業者廣闊的平臺。
Coming Soon
《大型互聯網入侵感知與防禦體系建設》
《企業安全治理體系建設》
《GDPR遵從與隱私保護實踐》
招聘信息
美團點評集團安全部正在招募Web&二進制攻防、後臺&系統開發、機器學習&算法等各路小夥伴。如果你想加入我們，歡迎簡歷請發至郵箱zhaoyan17#meituan.com，具體職位信息可參考鏈接：點擊“這裡查看”
閱讀更多 美團技術團隊 的文章
