一、背景

Facebook數(shù)據(jù)泄露事件一度成為互聯(lián)網(wǎng)行業(yè)的焦點，幾百億美元市值瞬間蒸發(fā)贷盲，這個代價足以在地球上養(yǎng)活一支絕對龐大的安全團隊葱蝗，甚至可以直接收購幾家規(guī)模比較大的安全公司了。

雖然媒體上發(fā)表了很多譴責的言論掉伏，但實事求是地講缝呕，F(xiàn)acebook面臨是一個業(yè)界難題，任何一家千億美元的互聯(lián)網(wǎng)公司面對這種問題斧散，可能都沒有太大的抵抗力供常，僅僅是因為全球區(qū)域的法律和國情不同，暫時不被頂上輿論的浪尖罷了鸡捐。但是全球的趨勢是越來越重視隱私栈暇，在安全領域中，數(shù)據(jù)安全這個子領域也重新被提到了一個新的高度箍镜，所以筆者就借機來說一下數(shù)據(jù)安全建設源祈。（按照慣例，本文涉及敏感信息的部分會進行省略處理或者一筆帶過色迂。）

二香缺、概念

這里特別強調(diào)一下，“隱私保護”和“數(shù)據(jù)安全”是兩個完全不同的概念脚草，隱私保護對于安全專業(yè)人員來說是一個更加偏向合規(guī)的事情赫悄，主要是指數(shù)據(jù)過度收集和數(shù)據(jù)濫用方面對法律法規(guī)的遵從性，對很多把自身的盈利模式建立在數(shù)據(jù)之上的互聯(lián)網(wǎng)公司而言馏慨，這個問題特別有挑戰(zhàn)埂淮。有些公司甚至把自己定義為數(shù)據(jù)公司，如果不用數(shù)據(jù)來做點什么写隶，要么用戶體驗大打折扣倔撞，要么商業(yè)價值減半。GDPR即將實施慕趴，有些公司或?qū)㈦x場歐洲痪蝇，就足見這件事的難度不容小覷鄙陡。當然市場上也有一些特別推崇隱私保護的公司，他們很大程度上并不能真正代表用戶意愿躏啰，而只是因為自家沒有數(shù)據(jù)或缺少數(shù)據(jù)趁矾，隨口說說而已。

數(shù)據(jù)安全是實現(xiàn)隱私保護的最重要手段之一给僵。對安全有一定了解的讀者可能也會察覺到毫捣，數(shù)據(jù)安全并不是一個獨立的要素，而是需要連同網(wǎng)絡安全帝际、系統(tǒng)安全蔓同、業(yè)務安全等多種因素，只有全部都做好了蹲诀，才能最終達到數(shù)據(jù)安全的效果斑粱。所以本文盡可能的以數(shù)據(jù)安全為核心，但沒有把跟數(shù)據(jù)安全弱相關的傳統(tǒng)安全體系防護全部列出來脯爪，對于數(shù)據(jù)安全這個命題而言盡可能的系統(tǒng)化则北，又避免啰嗦。另外筆者也打算在夏季和秋季把其他子領域的話題單獨成文披粟，譬如海量IDC下的入侵防御體系等咒锻，敬請期待。

三守屉、全生命周期建設

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

四、數(shù)據(jù)采集

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

流量保護

全站HTTPS是目前互聯(lián)網(wǎng)的主流趨勢，它解決的是用戶到服務器之間鏈路被嗅探耗跛、流量鏡像裕照、數(shù)據(jù)被第三方掠走的問題。這些問題其實是比較嚴重的调塌，比如電信運營商內(nèi)部偶有舞弊現(xiàn)象晋南，各種導流劫持插廣告（當然也可以存數(shù)據(jù)，插木馬）羔砾，甚至連AWS也被劫持DNS請求负间，對于掌握鏈路資源的人來說無異于可以發(fā)動一次“核戰(zhàn)爭”偶妖。即使目標對象IDC入侵防御做的好，攻擊者也可以不通過正面滲透政溃，而是直接復制流量趾访，甚至定向APT，最終只是看操縱流量后達到目的的收益是否具有性價比董虱。

HTTPS是一個表面現(xiàn)象腹缩，它暗示著任何互聯(lián)網(wǎng)上未加密的流量都是沒有隱私和數(shù)據(jù)安全的，同時空扎，也不是說有了HTTPS就一定安全藏鹊。HTTPS本身也有各種安全問題，比如使用不安全的協(xié)議TLS1.0转锈、SSL3盘寡，采用已經(jīng)過時的弱加密算法套件，實現(xiàn)框架安全漏洞如心臟滴血撮慨，還有很多的數(shù)字證書本身導致的安全問題竿痰。

全站HTTPS會帶來的附帶問題是CDN和高防IP。歷史上有家很大的互聯(lián)網(wǎng)公司被NSA嗅探獲取了用戶數(shù)據(jù)砌溺，原因是CDN回源時沒有使用加密影涉，即用戶瀏覽器到CDN是加密的，但CDN到IDC源站是明文的规伐。如果CDN到源站加密就需要把網(wǎng)站的證書私鑰給到CDN廠商蟹倾，這對于沒有完全自建CDN的公司而言也是一個很大的安全隱患，所以后來衍生出了Keyless CDN技術猖闪，無需給出自己的證書就可以實現(xiàn)CDN回源加密鲜棠。

廣域網(wǎng)流量未加密的問題也要避免出現(xiàn)在“自家后院”——IDC間的流量復制和備份同步，對應的解決方案是跨IDC流量自動加密培慌、TLS隧道化豁陆。

業(yè)務安全屬性

在用戶到服務器之間還涉及兩個業(yè)務安全方向的問題。第一個問題是賬號安全吵护，只要賬號泄露（撞庫&爆破）到達一定數(shù)量級盒音，把這些賬號的數(shù)據(jù)匯總一下，就必定可以產(chǎn)生批量數(shù)據(jù)泄露的效果馅而。

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

UUID

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

五、前臺業(yè)務處理

鑒權模型

在很多企業(yè)的應用架構中十气，只有在業(yè)務邏輯最開始處理的部分設置登錄態(tài)校驗励背，后面的事務處理不再會出現(xiàn)用戶鑒權，進而引發(fā)了一系列的越權漏洞砸西。事實上越權漏洞并不是這種模型的全部危害叶眉，還包括各種K/V、RDS（關系型數(shù)據(jù)庫）籍胯、消息隊列等等竟闪，RPC沒有鑒權導致可任意讀取的安全問題。

在數(shù)據(jù)層只知道請求來自一個數(shù)據(jù)訪問層中間件杖狼，來自一個RPC調(diào)用，但完全不知道來自哪個用戶妖爷，還是哪個諸如客服系統(tǒng)或其他上游應用蝶涩，無法判斷究竟對當前的數(shù)據(jù)（對象）是否擁有完整的訪問權限。絕大多數(shù)互聯(lián)網(wǎng)公司都用開源軟件或修改后的開源軟件絮识，這類開源軟件的特點是基本不帶安全特性绿聘，或者只具備很弱的安全特性，以至于完全不適用于海量IDC規(guī)模下的4A模型（認證次舌、授權熄攘、管理、審計）彼念。外面防御做的很好挪圾，而在內(nèi)網(wǎng)可以隨意讀寫浅萧，這可能是互聯(lián)網(wǎng)行業(yè)的普遍現(xiàn)狀了。主要矛盾還是鑒權顆粒度和彈性計算的問題哲思，關于這個問題的解決方案可以參考筆者的另外一篇文章《初探下一代網(wǎng)絡隔離與訪問控制》洼畅，其中提到Google的方法是內(nèi)網(wǎng)RPC鑒權，由于Google的內(nèi)網(wǎng)只有RPC一種協(xié)議棚赔，所以就規(guī)避了上述大多數(shù)安全問題帝簇。

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

服務化

服務化并不能認為是一個安全機制，但安全卻是服務化的受益者抡柿。我們再來溫習一下當年Bezos在Amazon推行服務化的一紙?zhí)柫睿?/p>

1）所有團隊今后將通過服務接口公開他們的數(shù)據(jù)和功能早处。 2）團隊必須通過這些接口相互通信。 3）不允許使用其他形式的進程間通信：不允許直接鏈接途样，不允許直接讀取其他團隊的數(shù)據(jù)存儲，不支持共享內(nèi)存模式濒憋，無后門何暇。唯一允許的通信是通過網(wǎng)絡上的服務接口調(diào)用。 4）他們使用什么技術并不重要凛驮。HTTP裆站，Corba，Pubsub黔夭，自定義協(xié)議 - 無關緊要宏胯。貝索斯不在乎。 5）所有服務接口無一例外都必須從頭開始設計為可外部化本姥。也就是說肩袍，團隊必須規(guī)劃和設計能夠?qū)⒔涌谡故窘o外部開發(fā)人員。沒有例外婚惫。 6）任何不這樣做的人都會被解雇氛赐。

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

內(nèi)網(wǎng)加密

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

數(shù)據(jù)庫審計

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

除此之外，對數(shù)據(jù)庫的審計還有一層含義鸽照，是指內(nèi)部人員對數(shù)據(jù)庫的操作螺捐，要避免某個RD或DBA為了泄憤，把數(shù)據(jù)庫拖走或者刪除這種危險動作矮燎。通常大型互聯(lián)網(wǎng)公司都會有數(shù)據(jù)庫訪問層組件定血，通過這個組件，可以審計诞外、控制危險操作澜沟。

六、數(shù)據(jù)存儲

數(shù)據(jù)存儲之于數(shù)據(jù)安全最大的部分是數(shù)據(jù)加密峡谊。Amazon CTO Werner Vogels曾經(jīng)總結：“AWS所有的新服務茫虽，在原型設計階段就會考慮到對數(shù)據(jù)加密的支持〖让牵”國外的互聯(lián)網(wǎng)公司中普遍比較重視數(shù)據(jù)加密濒析。

HSM/KMS

業(yè)界的普遍問題是不加密，或者加密了但沒有使用正確的方法：使用自定義UDF啥纸，算法選用不正確或加密強度不合適号杏，或隨機數(shù)問題，或者密鑰沒有Rotation機制斯棒，密鑰沒有存儲在KMS中馒索。數(shù)據(jù)加密的正確方法本身就是可信計算的思路，信任根存儲在HSM中名船，加密采用分層密鑰結構，以方便動態(tài)轉(zhuǎn)換和過期失效旨怠。當Intel CPU普遍開始支持SGX安全特性時渠驼，密鑰、指紋鉴腻、憑證等數(shù)據(jù)的處理也將以更加平民化的方式使用類似Trustzone的芯片級隔離技術迷扇。

結構化數(shù)據(jù)

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

文件加密

對單個文件獨立加密统翩，一般情況下采用分塊加密仙蚜，典型的場景譬如在《互聯(lián)網(wǎng)企業(yè)安全高級指南》一書中提到的iCloud將手機備份分塊加密后存儲于AWS的S3，每一個文件切塊用隨機密鑰加密后放在文件的meta data中厂汗，meta data再用file key包裹委粉，file key再用特定類型的data key（涉及數(shù)據(jù)類型和訪問權限）加密，然后data key被master key包裹面徽。

文件系統(tǒng)加密

文件系統(tǒng)加密由于對應用來說是透明的艳丛，所以只要應用具備訪問權限，那么文件系統(tǒng)加密對用戶來說也是“無感知”的趟紊。它解決的主要是冷數(shù)據(jù)持久化后存儲介質(zhì)可訪問的問題氮双，即使去機房拔一塊硬盤，或者從一塊報廢的硬盤上嘗試恢復數(shù)據(jù)霎匈，都是沒有用的戴差。但是對于API鑒權漏洞或者SQL注入而言，顯然文件系統(tǒng)的加密是透明的铛嘱，只要App有權限暖释，漏洞利用也有權限。

七墨吓、訪問和運維

在這個環(huán)節(jié)球匕，主要闡述防止內(nèi)部人員越權的一些措施。

角色分離

研發(fā)和運維要分離帖烘，密鑰持有者和數(shù)據(jù)運維者要分離亮曹，運維角色和審計角色要分離。特權賬號須回收，滿足最小權限照卦，多權分立的審計原則式矫。

運維審計

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

工具鏈脫敏

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

生產(chǎn)轉(zhuǎn)測試

生產(chǎn)環(huán)境和測試環(huán)境必須有嚴格定義和分離情萤，如特殊情況生產(chǎn)數(shù)據(jù)需要轉(zhuǎn)測試，必須經(jīng)過脫敏摹恨、匿名化筋岛。

八、后臺數(shù)據(jù)處理

數(shù)倉安全

目前大數(shù)據(jù)處理基本是每個互聯(lián)網(wǎng)公司的必需品晒哄，通常承載了公司所有的用戶數(shù)據(jù)睁宰，甚至有的公司用于數(shù)據(jù)處理的算力超過用于前臺事務處理的算力。以Hadoop為代表的開源平臺本身不太具備很強的安全能力寝凌，因此在成為公有云服務前需要做很多改造柒傻。在公司比較小的時候可以選擇內(nèi)部信任模式，不去過于糾結開源平臺本身的安全较木，但在公司規(guī)模比較大红符，數(shù)據(jù)RD和BI分析師成千上萬的時候，內(nèi)部信任模式就需要被拋棄了伐债，這時候需要的是一站式的授權&審計平臺预侯，需要看到數(shù)據(jù)的血緣繼承關系，需要高敏數(shù)據(jù)仍然被加密峰锁。在這種規(guī)模下萎馅，工具鏈的成熟度會決定數(shù)據(jù)本地化的需求，工具鏈越成熟數(shù)據(jù)就越不需要落到開發(fā)者本地虹蒋，這樣就能大幅提升安全能力校坑。同時鼓勵一切計算機器化&程序化&自動化拣技，盡可能避免人工操作。

對于數(shù)據(jù)的分類標識耍目、分布和加工，以及訪問狀況需要有一個全局的大盤視圖徐绑，結合數(shù)據(jù)使用者的行為建立“態(tài)勢感知”的能力邪驮。

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

匿名化算法

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

九、展示和使用

這個環(huán)節(jié)泛指大量的應用系統(tǒng)后臺草巡、運營報表以及所有可以展示和看到數(shù)據(jù)的地方守呜，都可能是數(shù)據(jù)泄露的重災區(qū)。

展示脫敏

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

水印

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

安全邊界

這里的邊界其實是辦公網(wǎng)和生產(chǎn)網(wǎng)組成的公司數(shù)據(jù)邊界，由于辦公移動化程度的加深拯杠，這種邊界被進一步模糊化掏婶，所以這種邊界實際上是邏輯的，而非物理上的潭陪，它等價于公司辦公網(wǎng)絡雄妥，生產(chǎn)網(wǎng)絡和支持MDM的認證移動設備最蕾。對這個邊界內(nèi)的數(shù)據(jù)，使用DLP來做檢測老厌，DLP這個名詞很早就有瘟则，但實際上它的產(chǎn)品形態(tài)和技術已經(jīng)發(fā)生了變化，用于應對大規(guī)模環(huán)境下重檢測枝秤，輕阻斷的數(shù)據(jù)保護模式醋拧。

除了DLP之外，整個辦公網(wǎng)絡會采用BeyondCorp的“零信任”架構淀弹，對整個的OA類應用實現(xiàn)動態(tài)訪問控制丹壕，全面去除匿名化訪問，全部HTTPS薇溃，根據(jù)角色最小權限化菌赖，也就是每個賬號即使泄露能訪問到的也有限。同時提高賬號泄露的成本（多因素認證）和檢測手段沐序，一旦檢測到泄露提供遠程擦除的能力琉用。

堡壘機

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

十刁愿、共享和再分發(fā)

對于業(yè)務盤子比較大的公司而言，其數(shù)據(jù)都不會是只在自己的系統(tǒng)內(nèi)流轉(zhuǎn)到逊，通常都有開放平臺铣口，有貫穿整個產(chǎn)業(yè)鏈的上下游數(shù)據(jù)應用。Facebook事件曝光其實就屬于這類問題觉壶，不開放是不可能的脑题，因為這影響了公司的內(nèi)核—-賴以生存的商業(yè)價值。

所以這個問題的解決方案等價于：1）內(nèi)核有限妥協(xié)（為保障用戶隱私犧牲一部分商業(yè)利益）铜靶；2）一站式數(shù)據(jù)安全服務叔遂。

防止下游數(shù)據(jù)沉淀

首先，所有被第三方調(diào)用的數(shù)據(jù)争剿，如非必要一律脫敏和加密已艰。如果部分場景有必要查詢明細數(shù)據(jù)，設置單獨的API蚕苇，并對賬號行為及API查詢做風控哩掺。

其次如果自身有云基礎設施，公有云平臺涩笤，可以推動第三方上云嚼吞，從而進行（1）安全賦能盒件，避免一些因自身能力不足引起的安全問題；（2）數(shù)據(jù)集中化舱禽，在云上集中之后利于實施一站式整體安全解決方案（數(shù)據(jù)加密炒刁，風控，反爬和數(shù)據(jù)泄露檢測類服務）呢蔫，大幅度降低外部風險并在一定程度上降低作惡和監(jiān)守自盜的問題切心。

反爬

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

授權審核

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

法律條款

所有的第三方接入必須有嚴格的用戶協(xié)議，明確數(shù)據(jù)使用權利盈匾，數(shù)據(jù)披露限制和隱私保護的要求腾务。像GDPR一樣，明確數(shù)據(jù)處理者角色和懲罰條約削饵。

十一岩瘦、數(shù)據(jù)銷毀

數(shù)據(jù)銷毀主要是指安全刪除，這里特別強調(diào)是窿撬，往往數(shù)據(jù)的主實例容易在視野范圍內(nèi)启昧，而把備份類的數(shù)據(jù)忽略掉。 如果希望做到快速的安全刪除劈伴，最好使用加密數(shù)據(jù)的方法密末，因為完整覆寫不太可能在短時間內(nèi)完成，但是加密數(shù)據(jù)的安全刪除只要刪除密鑰即可跛璧。

十二严里、數(shù)據(jù)的邊界

數(shù)據(jù)治理常常涉及到“邊界”問題，不管你承不承認赡模，邊界其實總是存在的田炭，只不過表達方式不一樣，如果真的沒有邊界漓柑，也就不存在數(shù)據(jù)安全一說教硫。

企業(yè)內(nèi)部

在不超越網(wǎng)絡安全法和隱私保護規(guī)定的情況下叨吮，法律上企業(yè)對內(nèi)部的數(shù)據(jù)都擁有絕對控制權，這使得企業(yè)內(nèi)部的數(shù)據(jù)安全建設實際上最后會轉(zhuǎn)化為一項運營類的工作瞬矩，挑戰(zhàn)難度也無非是各個業(yè)務方推動落地的成本茶鉴。但對規(guī)模比較大的公司而言，光企業(yè)內(nèi)部自治可能是不夠的景用，所以數(shù)據(jù)安全會衍生出產(chǎn)業(yè)鏈上閉環(huán)的需求涵叮。

生態(tài)建設

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

十三京髓、ROI和建設次第

對于很多規(guī)模不大的公司而言，上述數(shù)據(jù)安全建設手段可能真的有點多商架，對于小一點公司即便什么事不干可能也消化不了那么多需求堰怨，因為開源軟件和大多數(shù)的開發(fā)框架都不具備這些能力，需要DIY的成分很高蛇摸，所以我們梳理一下前置條件备图，優(yōu)先級和ROI，讓數(shù)據(jù)安全這件事對任何人都是可以接受的皇型，當然這種情況其實也對應了一些創(chuàng)業(yè)空間诬烹。

基礎

賬號、權限弃鸦、日志绞吁、脫敏和加密這些都是數(shù)據(jù)安全的基礎。同時還有一些不完全是基礎唬格，但能體現(xiàn)為優(yōu)勢的部分：基礎架構統(tǒng)一家破，應用架構統(tǒng)一，如果這兩者高度統(tǒng)一购岗，數(shù)據(jù)安全建設能事半功倍汰聋。

日志收集

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

辦公網(wǎng)絡是否BeyondCorp化喊积，這給數(shù)據(jù)風控提供了極大地便利烹困。

服務化，所有的數(shù)據(jù)調(diào)用皆以API的形式乾吻，給日志記錄提供了統(tǒng)一的形式髓梅。

數(shù)據(jù)風控

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

作者簡介

趙彥，現(xiàn)任美團集團安全部高級總監(jiān)鹊奖，負責集團旗下全線業(yè)務的信息安全與隱私保護场绿。加盟美團前，曾任華為云安全首席架構師嫉入，奇虎360企業(yè)安全技術總監(jiān)、久游網(wǎng)安全總監(jiān)璧尸、綠盟科技安全專家等職務咒林。白帽子時代是Ph4nt0m Security Team的核心成員，互聯(lián)網(wǎng)安全領域第一代資深從業(yè)者爷光。

關于美團安全

美團安全部的大多數(shù)核心人員垫竞，擁有多年互聯(lián)網(wǎng)以及安全領域?qū)嵺`經(jīng)驗，很多同學參與過大型互聯(lián)網(wǎng)公司的安全體系建設蛀序，其中也不乏全球化安全運營人才欢瞪，具備百萬級IDC規(guī)模攻防對抗的經(jīng)驗。安全部也不乏CVE“挖掘圣手”徐裸，有受邀在Black Hat等國際頂級會議發(fā)言的講者遣鼓，當然還有很多漂亮的運營妹子。

目前重贺，美團安全部涉及的技術包括滲透測試骑祟、Web防護、二進制安全气笙、內(nèi)核安全次企、分布式開發(fā)、大數(shù)據(jù)分析潜圃、安全算法等等缸棵，同時還有全球合規(guī)與隱私保護等策略制定。我們正在建設一套百萬級IDC規(guī)模谭期、數(shù)十萬終端接入的移動辦公網(wǎng)絡自適應安全體系堵第，這套體系構建于零信任架構之上吧凉，橫跨多種云基礎設施，包括網(wǎng)絡層型诚、虛擬化/容器層客燕、Server 軟件層（內(nèi)核態(tài)/用戶態(tài)）、語言虛擬機層（JVM/JS V8）狰贯、Web應用層也搓、數(shù)據(jù)訪問層等，并能夠基于“大數(shù)據(jù)+機器學習”技術構建全自動的安全事件感知系統(tǒng)涵紊，努力打造成業(yè)界最前沿的內(nèi)置式安全架構和縱深防御體系傍妒。

隨著美團的高速發(fā)展，業(yè)務復雜度不斷提升摸柄，安全部門面臨更多的機遇和挑戰(zhàn)颤练。我們希望將更多代表業(yè)界最佳實踐的安全項目落地，同時為更多的安全從業(yè)者提供一個廣闊的發(fā)展平臺驱负，并提供更多在安全新興領域不斷探索的機會嗦玖。

————————————————

版權聲明：本文為CSDN博主「liuhuiteng」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議跃脊，轉(zhuǎn)載請附上原文出處鏈接及本聲明宇挫。

原文鏈接：https://blog.csdn.net/liuhuiteng/article/details/106954648