一、背景

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

雖然媒體上發(fā)表了很多譴責(zé)的言論，但實(shí)事求是地講，F(xiàn)acebook面臨是一個(gè)業(yè)界難題，任何一家千億美元的互聯(lián)網(wǎng)公司面對(duì)這種問(wèn)題，可能都沒(méi)有太大的抵抗力，僅僅是因?yàn)槿騾^(qū)域的法律和國(guó)情不同，暫時(shí)不被頂上輿論的浪尖罷了。但是全球的趨勢(shì)是越來(lái)越重視隱私，在安全領(lǐng)域中，數(shù)據(jù)安全這個(gè)子領(lǐng)域也重新被提到了一個(gè)新的高度，所以筆者就借機(jī)來(lái)說(shuō)一下數(shù)據(jù)安全建設(shè)。(按照慣例，本文涉及敏感信息的部分會(huì)進(jìn)行省略處理或者一筆帶過(guò)。 )

二、概念

這里特別強(qiáng)調(diào)一下，“隱私保護(hù)”和“數(shù)據(jù)安全”是兩個(gè)完全不同的概念，隱私保護(hù)對(duì)于安全專業(yè)人員來(lái)說(shuō)是一個(gè)更加偏向合規(guī)的事情，主要是指數(shù)據(jù)過(guò)度收集和數(shù)據(jù)濫用方面對(duì)法律法規(guī)的遵從性，對(duì)很多把自身的盈利模式建立在數(shù)據(jù)之上的互聯(lián)網(wǎng)公司而言，這個(gè)問(wèn)題特別有挑戰(zhàn)。有些公司甚至把自己定義為數(shù)據(jù)公司，如果不用數(shù)據(jù)來(lái)做點(diǎn)什么，要么用戶體驗(yàn)大打折扣，要么商業(yè)價(jià)值減半。GDPR即將實(shí)施，有些公司或?qū)㈦x場(chǎng)歐洲，就足見(jiàn)這件事的難度不容小覷。當(dāng)然市場(chǎng)上也有一些特別推崇隱私保護(hù)的公司，他們很大程度上并不能真正代表用戶意愿，而只是因?yàn)樽约覜](méi)有數(shù)據(jù)或缺少數(shù)據(jù)，隨口說(shuō)說(shuō)而已。

數(shù)據(jù)安全是實(shí)現(xiàn)隱私保護(hù)的最重要手段之一。對(duì)安全有一定了解的讀者可能也會(huì)察覺(jué)到，數(shù)據(jù)安全并不是一個(gè)獨(dú)立的要素，而是需要連同網(wǎng)絡(luò)安全、系統(tǒng)安全、業(yè)務(wù)安全等多種因素，只有全部都做好了，才能最終達(dá)到數(shù)據(jù)安全的效果。所以本文盡可能的以數(shù)據(jù)安全為核心，但沒(méi)有把跟數(shù)據(jù)安全弱相關(guān)的傳統(tǒng)安全體系防護(hù)全部列出來(lái)，對(duì)于數(shù)據(jù)安全這個(gè)命題而言盡可能的系統(tǒng)化，又避免啰嗦。另外筆者也打算在夏季和秋季把其他子領(lǐng)域的話題單獨(dú)成文，譬如海量IDC下的入侵防御體系等，敬請(qǐng)期待。

三、全生命周期建設(shè)

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

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

數(shù)據(jù)泄露有一部分原因是用戶會(huì)話流量被復(fù)制，盡管有點(diǎn)技術(shù)門檻，但也是發(fā)生頻率比較高的安全事件之一，只是是很多企業(yè)沒(méi)有感知到而已。下面從幾個(gè)維度來(lái)說(shuō)明數(shù)據(jù)采集階段的數(shù)據(jù)保護(hù)。

1. 流量保護(hù)

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

HTTPS是一個(gè)表面現(xiàn)象，它暗示著任何互聯(lián)網(wǎng)上未加密的流量都是沒(méi)有隱私和數(shù)據(jù)安全的，同時(shí)，也不是說(shuō)有了HTTPS就一定安全。HTTPS本身也有各種安全問(wèn)題，比如使用不安全的協(xié)議TLS1.0、SSL3，采用已經(jīng)過(guò)時(shí)的弱加密算法套件，實(shí)現(xiàn)框架安全漏洞如心臟滴血，還有很多的數(shù)字證書(shū)本身導(dǎo)致的安全問(wèn)題。

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

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

2. 業(yè)務(wù)安全屬性

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

第二個(gè)問(wèn)題是反爬，爬蟲(chóng)的問(wèn)題存在于一切可通過(guò)頁(yè)面、接口獲取數(shù)據(jù)的場(chǎng)合，大概1小時(shí)爬個(gè)幾百萬(wàn)條數(shù)據(jù)是一點(diǎn)問(wèn)題都沒(méi)有的，對(duì)于沒(méi)有徹底脫敏的數(shù)據(jù)，爬蟲(chóng)的效果有時(shí)候等價(jià)于“黑掉”服務(wù)器。賬號(hào)主動(dòng)地或被動(dòng)地泄露+爬蟲(chóng)技術(shù)，培育了不少黑產(chǎn)和數(shù)據(jù)獲取的灰色地帶。

3. UUID

UUID最大的作用是建立中間映射層，屏蔽與真實(shí)用戶信息的關(guān)系鏈。譬如在開(kāi)放平臺(tái)第三方應(yīng)用數(shù)據(jù)按需自主授權(quán)只能讀取UUID，但不能直接獲取個(gè)人的微信號(hào)。更潛在的意義是屏蔽個(gè)體識(shí)別數(shù)據(jù)，因?yàn)閷?shí)名制，手機(jī)號(hào)越來(lái)越能代表個(gè)人標(biāo)識(shí)，且一般綁定了各種賬號(hào)，更改成本很高，找到手機(jī)號(hào)就能對(duì)上這個(gè)人，因此理論上但凡帶有個(gè)體識(shí)別數(shù)據(jù)的信息都需要“轉(zhuǎn)接橋梁”、匿名化和脫敏。譬如當(dāng)商家ID能唯一標(biāo)識(shí)一個(gè)品牌和店名的時(shí)候，這個(gè)原本用于程序檢索的數(shù)據(jù)結(jié)構(gòu)也一下子變成了個(gè)體識(shí)別數(shù)據(jù)，也都需要納入保護(hù)范疇。

五、前臺(tái)業(yè)務(wù)處理

1. 鑒權(quán)模型

在很多企業(yè)的應(yīng)用架構(gòu)中，只有在業(yè)務(wù)邏輯最開(kāi)始處理的部分設(shè)置登錄態(tài)校驗(yàn)，后面的事務(wù)處理不再會(huì)出現(xiàn)用戶鑒權(quán)，進(jìn)而引發(fā)了一系列的越權(quán)漏洞。事實(shí)上越權(quán)漏洞并不是這種模型的全部危害，還包括各種K/V、RDS(關(guān)系型數(shù)據(jù)庫(kù))、消息隊(duì)列等等，RPC沒(méi)有鑒權(quán)導(dǎo)致可任意讀取的安全問(wèn)題。

在數(shù)據(jù)層只知道請(qǐng)求來(lái)自一個(gè)數(shù)據(jù)訪問(wèn)層中間件，來(lái)自一個(gè)RPC調(diào)用，但完全不知道來(lái)自哪個(gè)用戶，還是哪個(gè)諸如客服系統(tǒng)或其他上游應(yīng)用，無(wú)法判斷究竟對(duì)當(dāng)前的數(shù)據(jù)(對(duì)象)是否擁有完整的訪問(wèn)權(quán)限。絕大多數(shù)互聯(lián)網(wǎng)公司都用開(kāi)源軟件或修改后的開(kāi)源軟件，這類開(kāi)源軟件的特點(diǎn)是基本不帶安全特性，或者只具備很弱的安全特性，以至于完全不適用于海量IDC規(guī)模下的4A模型(認(rèn)證、授權(quán)、管理、審計(jì))。

外面防御做的很好，而在內(nèi)網(wǎng)可以隨意讀寫，這可能是互聯(lián)網(wǎng)行業(yè)的普遍現(xiàn)狀了。

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

2. 服務(wù)化

服務(wù)化并不能認(rèn)為是一個(gè)安全機(jī)制，但安全卻是服務(wù)化的受益者。我們?cè)賮?lái)溫習(xí)一下當(dāng)年Bezos在Amazon推行服務(wù)化的一紙?zhí)柫睿?/p>

• 所有團(tuán)隊(duì)今后將通過(guò)服務(wù)接口公開(kāi)他們的數(shù)據(jù)和功能。
• 團(tuán)隊(duì)必須通過(guò)這些接口相互通信。
• 不允許使用其他形式的進(jìn)程間通信：不允許直接鏈接，不允許直接讀取其他團(tuán)隊(duì)的數(shù)據(jù)存儲(chǔ)，不支持共享內(nèi)存模式，無(wú)后門。唯一允許的通信是通過(guò)網(wǎng)絡(luò)上的服務(wù)接口調(diào)用。
• 他們使用什么技術(shù)并不重要。HTTP，Corba，Pubsub，自定義協(xié)議 – 無(wú)關(guān)緊要。貝索斯不在乎。
• 所有服務(wù)接口無(wú)一例外都必須從頭開(kāi)始設(shè)計(jì)為可外部化。也就是說(shuō)，團(tuán)隊(duì)必須規(guī)劃和設(shè)計(jì)能夠?qū)⒔涌谡故窘o外部開(kāi)發(fā)人員。沒(méi)有例外。
• 任何不這樣做的人都會(huì)被解雇。

服務(wù)化的結(jié)果在安全上的意義是必須通過(guò)接口訪問(wèn)數(shù)據(jù)，屏蔽了各種直接訪問(wèn)數(shù)據(jù)的途徑，有了API控制和審計(jì)就會(huì)方便很多。

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

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

4. 數(shù)據(jù)庫(kù)審計(jì)

數(shù)據(jù)庫(kù)審計(jì)/數(shù)據(jù)庫(kù)防火墻是一個(gè)入侵檢測(cè)/防御組件，是一個(gè)強(qiáng)對(duì)抗領(lǐng)域的產(chǎn)品，但是在數(shù)據(jù)安全方面它的意義也是明顯的：防止SQL注入批量拉取數(shù)據(jù)，檢測(cè)API鑒權(quán)類漏洞和爬蟲(chóng)的成功訪問(wèn)。

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

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

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

1. HSM/KMS

業(yè)界的普遍問(wèn)題是不加密，或者加密了但沒(méi)有使用正確的方法：使用自定義UDF，算法選用不正確或加密強(qiáng)度不合適，或隨機(jī)數(shù)問(wèn)題，或者密鑰沒(méi)有Rotation機(jī)制，密鑰沒(méi)有存儲(chǔ)在KMS中。數(shù)據(jù)加密的正確方法本身就是可信計(jì)算的思路，信任根存儲(chǔ)在HSM中，加密采用分層密鑰結(jié)構(gòu)，以方便動(dòng)態(tài)轉(zhuǎn)換和過(guò)期失效。當(dāng)Intel CPU普遍開(kāi)始支持SGX安全特性時(shí)，密鑰、指紋、憑證等數(shù)據(jù)的處理也將以更加平民化的方式使用類似Trustzone的芯片級(jí)隔離技術(shù)。

2. 結(jié)構(gòu)化數(shù)據(jù)

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

3. 文件加密

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

4. 文件系統(tǒng)加密

文件系統(tǒng)加密由于對(duì)應(yīng)用來(lái)說(shuō)是透明的，所以只要應(yīng)用具備訪問(wèn)權(quán)限，那么文件系統(tǒng)加密對(duì)用戶來(lái)說(shuō)也是“無(wú)感知”的。它解決的主要是冷數(shù)據(jù)持久化后存儲(chǔ)介質(zhì)可訪問(wèn)的問(wèn)題，即使去機(jī)房拔一塊硬盤，或者從一塊報(bào)廢的硬盤上嘗試恢復(fù)數(shù)據(jù)，都是沒(méi)有用的。但是對(duì)于API鑒權(quán)漏洞或者SQL注入而言，顯然文件系統(tǒng)的加密是透明的，只要App有權(quán)限，漏洞利用也有權(quán)限。

七、訪問(wèn)和運(yùn)維

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

1. 角色分離

研發(fā)和運(yùn)維要分離，密鑰持有者和數(shù)據(jù)運(yùn)維者要分離，運(yùn)維角色和審計(jì)角色要分離。特權(quán)賬號(hào)須回收，滿足最小權(quán)限，多權(quán)分立的審計(jì)原則。

2. 運(yùn)維審計(jì)

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

3. 工具鏈脫敏

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

4. 生產(chǎn)轉(zhuǎn)測(cè)試

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

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

1. 數(shù)倉(cāng)安全

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

在這種規(guī)模下，工具鏈的成熟度會(huì)決定數(shù)據(jù)本地化的需求，工具鏈越成熟數(shù)據(jù)就越不需要落到開(kāi)發(fā)者本地，這樣就能大幅提升安全能力。同時(shí)鼓勵(lì)一切計(jì)算機(jī)器化&程序化&自動(dòng)化，盡可能避免人工操作。

對(duì)于數(shù)據(jù)的分類標(biāo)識(shí)、分布和加工，以及訪問(wèn)狀況需要有一個(gè)全局的大盤視圖，結(jié)合數(shù)據(jù)使用者的行為建立“態(tài)勢(shì)感知”的能力。

因?yàn)閿?shù)倉(cāng)是最大的數(shù)據(jù)集散地，因此每家公司對(duì)于數(shù)據(jù)歸屬的價(jià)值觀也會(huì)影響數(shù)據(jù)安全方案的落地形態(tài)：放逐+檢測(cè)型 or 隔離+管控型。

2. 匿名化算法

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

九、展示和使用

這個(gè)環(huán)節(jié)泛指大量的應(yīng)用系統(tǒng)后臺(tái)、運(yùn)營(yíng)報(bào)表以及所有可以展示和看到數(shù)據(jù)的地方，都可能是數(shù)據(jù)泄露的重災(zāi)區(qū)。

1. 展示脫敏

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

2. 水印

水印主要用在截圖的場(chǎng)景，分為明水印和暗水印，明水印是肉眼可見(jiàn)的，暗水印是肉眼不可見(jiàn)暗藏在圖片里的識(shí)別信息。水印的形式也有很多種，有抵抗截屏的，也有抵抗拍照的。這里面也涉及很多對(duì)抗元素不一一展開(kāi)。

3. 安全邊界

這里的邊界其實(shí)是辦公網(wǎng)和生產(chǎn)網(wǎng)組成的公司數(shù)據(jù)邊界，由于辦公移動(dòng)化程度的加深，這種邊界被進(jìn)一步模糊化，所以這種邊界實(shí)際上是邏輯的，而非物理上的，它等價(jià)于公司辦公網(wǎng)絡(luò)，生產(chǎn)網(wǎng)絡(luò)和支持MDM的認(rèn)證移動(dòng)設(shè)備。對(duì)這個(gè)邊界內(nèi)的數(shù)據(jù)，使用DLP來(lái)做檢測(cè)，DLP這個(gè)名詞很早就有，但實(shí)際上它的產(chǎn)品形態(tài)和技術(shù)已經(jīng)發(fā)生了變化，用于應(yīng)對(duì)大規(guī)模環(huán)境下重檢測(cè)，輕阻斷的數(shù)據(jù)保護(hù)模式。

除了DLP之外，整個(gè)辦公網(wǎng)絡(luò)會(huì)采用BeyondCorp的“零信任”架構(gòu)，對(duì)整個(gè)的OA類應(yīng)用實(shí)現(xiàn)動(dòng)態(tài)訪問(wèn)控制，全面去除匿名化訪問(wèn)，全部HTTPS，根據(jù)角色最小權(quán)限化，也就是每個(gè)賬號(hào)即使泄露能訪問(wèn)到的也有限。同時(shí)提高賬號(hào)泄露的成本(多因素認(rèn)證)和檢測(cè)手段，一旦檢測(cè)到泄露提供遠(yuǎn)程擦除的能力。

4. 堡壘機(jī)

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

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

對(duì)于業(yè)務(wù)盤子比較大的公司而言，其數(shù)據(jù)都不會(huì)是只在自己的系統(tǒng)內(nèi)流轉(zhuǎn)，通常都有開(kāi)放平臺(tái)，有貫穿整個(gè)產(chǎn)業(yè)鏈的上下游數(shù)據(jù)應(yīng)用。Facebook事件曝光其實(shí)就屬于這類問(wèn)題，不開(kāi)放是不可能的，因?yàn)檫@影響了公司的內(nèi)核—-賴以生存的商業(yè)價(jià)值。

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

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

首先，所有被第三方調(diào)用的數(shù)據(jù)，如非必要一律脫敏和加密。如果部分場(chǎng)景有必要查詢明細(xì)數(shù)據(jù)，設(shè)置單獨(dú)的API，并對(duì)賬號(hào)行為及API查詢做風(fēng)控。

其次如果自身有云基礎(chǔ)設(shè)施，公有云平臺(tái)，可以推動(dòng)第三方上云，從而進(jìn)行：

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

2. 反爬

反爬在這里主要是針對(duì)公開(kāi)頁(yè)面，或通過(guò)接口爬取的信息，因?yàn)槊撁暨@件事不可能在所有的環(huán)節(jié)做的很徹底，所以即便通過(guò)大量的“公開(kāi)”信息也可以進(jìn)行匯聚和數(shù)據(jù)挖掘，最終形成一些諸如用戶關(guān)系鏈，經(jīng)營(yíng)數(shù)據(jù)或輔助決策類數(shù)據(jù)，造成過(guò)度信息披露的影響。

3. 授權(quán)審核

設(shè)置專門的團(tuán)隊(duì)對(duì)開(kāi)放平臺(tái)的第三方進(jìn)行機(jī)器審核及人工審核，禁止“無(wú)照經(jīng)營(yíng)”和虛假三方，提高惡意第三方接入的門檻，同時(shí)給開(kāi)發(fā)者/合作方公司信譽(yù)評(píng)級(jí)提供基礎(chǔ)。

4. 法律條款

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

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

數(shù)據(jù)銷毀主要是指安全刪除，這里特別強(qiáng)調(diào)是，往往數(shù)據(jù)的主實(shí)例容易在視野范圍內(nèi)，而把備份類的數(shù)據(jù)忽略掉。

如果希望做到快速的安全刪除，最好使用加密數(shù)據(jù)的方法，因?yàn)橥暾矊懖惶赡茉诙虝r(shí)間內(nèi)完成，但是加密數(shù)據(jù)的安全刪除只要?jiǎng)h除密鑰即可。

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

數(shù)據(jù)治理常常涉及到“邊界”問(wèn)題，不管你承不承認(rèn)，邊界其實(shí)總是存在的，只不過(guò)表達(dá)方式不一樣，如果真的沒(méi)有邊界，也就不存在數(shù)據(jù)安全一說(shuō)。

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

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

2. 生態(tài)建設(shè)

為了能讓數(shù)據(jù)安全建設(shè)在企業(yè)內(nèi)部?jī)r(jià)值鏈之外的部分更加平坦化，大型企業(yè)可能需要通過(guò)投資收購(gòu)等手段獲得上下游企業(yè)的數(shù)據(jù)控制權(quán)及標(biāo)準(zhǔn)制定權(quán)，從而在大生態(tài)里將自己的數(shù)據(jù)安全標(biāo)準(zhǔn)推行到底。如果不能掌控?cái)?shù)據(jù)，數(shù)據(jù)安全也無(wú)從談起。在話語(yǔ)權(quán)不足的情況下，現(xiàn)實(shí)選擇是提供更多的工具給合作方，也是一種數(shù)據(jù)控制能力的延伸。

十三、ROI和建設(shè)次第

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

1. 基礎(chǔ)

賬號(hào)、權(quán)限、日志、脫敏和加密這些都是數(shù)據(jù)安全的基礎(chǔ)。同時(shí)還有一些不完全是基礎(chǔ)，但能體現(xiàn)為優(yōu)勢(shì)的部分：基礎(chǔ)架構(gòu)統(tǒng)一，應(yīng)用架構(gòu)統(tǒng)一，如果這兩者高度統(tǒng)一，數(shù)據(jù)安全建設(shè)能事半功倍。

2. 日志收集

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

• 辦公網(wǎng)絡(luò)是否BeyondCorp化，這給數(shù)據(jù)風(fēng)控提供了極大地便利;
• 服務(wù)化，所有的數(shù)據(jù)調(diào)用皆以API的形式，給日志記錄提供了統(tǒng)一的形式。

3. 數(shù)據(jù)風(fēng)控

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