在企業(yè)的日常運(yùn)營(yíng)中，數(shù)據(jù)泄漏在廣義上是指未經(jīng)授權(quán)或已被授權(quán)的人員，錯(cuò)誤或惡意地訪問(wèn)、刪除、修改或傳輸企業(yè)或個(gè)人數(shù)據(jù)，而引發(fā)的各種安全事件。除了系統(tǒng)自身軟硬件錯(cuò)誤、以及源自外部的攻擊，由組織內(nèi)部人員造成的數(shù)據(jù)泄漏，在頻次和財(cái)務(wù)影響等方面都呈上升趨勢(shì)。

根據(jù)最近的一份報(bào)告顯示，全球60%的數(shù)據(jù)泄漏主要是由內(nèi)部威脅造成，而且平均每年會(huì)給企業(yè)造成約1150萬(wàn)美元的損失。究其根源，內(nèi)部威脅源于組織內(nèi)部人員擁有對(duì)網(wǎng)絡(luò)、應(yīng)用、數(shù)據(jù)庫(kù)授權(quán)訪問(wèn)權(quán)限，以及全面的背景知識(shí)。

困境

內(nèi)部數(shù)據(jù)泄漏之所以難以被發(fā)現(xiàn)，主要在于內(nèi)部攻擊者有能力更改登錄記錄、操作日志，進(jìn)而銷毀證據(jù)。有時(shí)，一些內(nèi)部攻擊在發(fā)生數(shù)月后被發(fā)現(xiàn)時(shí)，已造成了巨大損失。同時(shí)，根據(jù)歐洲《通用數(shù)據(jù)保護(hù)條例（GDPR）》，數(shù)據(jù)控制者必須在發(fā)生數(shù)據(jù)泄漏時(shí)，及時(shí)通知數(shù)據(jù)保護(hù)機(jī)構(gòu)和受影響的數(shù)據(jù)所有者。如果組織未能在一定時(shí)間內(nèi)通報(bào)違規(guī)情況，則將面臨高額的罰款。面對(duì)內(nèi)外部的安全壓力，企業(yè)亟待開(kāi)發(fā)出一套能快速檢測(cè)到數(shù)據(jù)泄漏的系統(tǒng)。

引入?yún)^(qū)塊鏈

近年來(lái)，隨著區(qū)塊鏈技術(shù)的成熟，以及在數(shù)據(jù)安全方面的優(yōu)勢(shì)，業(yè)界已有專家提出并實(shí)現(xiàn)了利用智能合約和區(qū)塊鏈網(wǎng)絡(luò)構(gòu)建的、滿足GDPR的實(shí)時(shí)檢測(cè)系統(tǒng)。下面，我們將以太坊區(qū)塊鏈網(wǎng)絡(luò)為例，介紹一個(gè)典型的數(shù)據(jù)泄漏檢測(cè)模型。

首先，我們討論一下檢測(cè)過(guò)程所涉及到的實(shí)體。GDPR規(guī)定了典型的四種實(shí)體，即：數(shù)據(jù)控制者、數(shù)據(jù)所有者、數(shù)據(jù)保護(hù)機(jī)構(gòu)和數(shù)據(jù)處理者。其中：

收集數(shù)據(jù)的實(shí)體被稱為數(shù)據(jù)控制者，他們負(fù)責(zé)針對(duì)數(shù)據(jù)收集原因和目的決定處理的方式。

數(shù)據(jù)所有者是（個(gè)人）數(shù)據(jù)的屬主。

數(shù)據(jù)保護(hù)機(jī)構(gòu)是指導(dǎo)數(shù)據(jù)控制者履行職責(zé)的實(shí)體。

代表（代替）數(shù)據(jù)控制者實(shí)際處理數(shù)據(jù)的實(shí)體則被稱為數(shù)據(jù)處理者或數(shù)據(jù)消費(fèi)者。

為了說(shuō)明問(wèn)題，我們來(lái)看一個(gè)典型的醫(yī)患場(chǎng)景。如下圖所示，在獲得數(shù)據(jù)所有者（患者）的同意后，其醫(yī)療數(shù)據(jù)將存儲(chǔ)在區(qū)塊鏈上。數(shù)據(jù)處理者（醫(yī)生）可以通過(guò)向數(shù)據(jù)控制者發(fā)出請(qǐng)求，從患者數(shù)據(jù)庫(kù)中獲取所需的患者數(shù)據(jù)。數(shù)據(jù)控制者使用泄漏檢測(cè)系統(tǒng)執(zhí)行必要檢測(cè)的任務(wù)，如患者同意驗(yàn)證和數(shù)據(jù)驗(yàn)證等。也就是說(shuō)，該系統(tǒng)要求數(shù)據(jù)控制者在與數(shù)據(jù)處理者共享數(shù)據(jù)前，需檢測(cè)數(shù)據(jù)庫(kù)記錄中的任何更改，并驗(yàn)證記錄的真實(shí)性。

該數(shù)據(jù)泄漏檢測(cè)系統(tǒng)的目標(biāo)是為數(shù)據(jù)控制者提供一個(gè)能夠即時(shí)檢測(cè)數(shù)據(jù)泄漏的自動(dòng)化工具，以協(xié)助識(shí)別惡意活動(dòng)，方便支持?jǐn)?shù)據(jù)控制者對(duì)發(fā)現(xiàn)的個(gè)人數(shù)據(jù)泄漏事件進(jìn)行詳細(xì)分析，形成泄漏報(bào)告，進(jìn)而在其進(jìn)一步升級(jí)之前加以緩解。下面我們來(lái)看看該系統(tǒng)模型及其組成部分。

在上面的流程圖中，我們可以獲悉其詳細(xì)流程為：

1. 數(shù)據(jù)保護(hù)機(jī)構(gòu)指派一名數(shù)據(jù)控制者在其用戶數(shù)據(jù)存儲(chǔ)庫(kù)中進(jìn)行數(shù)據(jù)錄入。數(shù)據(jù)控制者接受數(shù)據(jù)所有者的個(gè)人身份信息（PII），如：姓名、電子郵件、電話號(hào)碼、年齡、地址和符合ERC-20標(biāo)準(zhǔn)的以太坊專用錢包地址。注意，所有這些信息都是必填項(xiàng)。作為提交方，數(shù)據(jù)所有者應(yīng)前往數(shù)據(jù)控制者處進(jìn)行注冊(cè)，并口頭提供這些信息。

2. 數(shù)據(jù)控制者收到PII數(shù)據(jù)后，會(huì)將這些詳細(xì)信息輸入一個(gè)由保護(hù)機(jī)構(gòu)和數(shù)據(jù)控制者集中控制的、使用諸如Node.js和MySQL構(gòu)建的專用應(yīng)用程序（App1 Data Entry）中。

3. 該提交會(huì)創(chuàng)建一個(gè)“同意動(dòng)態(tài)鏈接”，并將其發(fā)送到數(shù)據(jù)所有者的電子郵件或手機(jī)上。該鏈接提供一個(gè)名為“Dapp 2 Data Consent”的同意面板。

4. 數(shù)據(jù)所有者收到該鏈接后，便可以在頁(yè)面上看到自己的詳細(xì)信息。他們需要使用在注冊(cè)時(shí)提交過(guò)的以太坊賬戶，來(lái)驗(yàn)證這些詳細(xì)的信息。同時(shí)，數(shù)據(jù)所有者應(yīng)使用符合以太坊標(biāo)準(zhǔn)的錢包簽署此類信息。由于這些信息使用的是數(shù)據(jù)所有者的私人密鑰進(jìn)行簽名，因此只有他們?cè)阱X包中選擇了與提供給數(shù)據(jù)控制者的相同地址，才能完成簽名操作。

5. “DAPP2 Data Consent”應(yīng)用程序?qū)⒋藬?shù)據(jù)簽名的哈希值，連同所有相關(guān)PII數(shù)據(jù)，以離鏈（off-chain）的方式發(fā)送到MySQL數(shù)據(jù)庫(kù)中。保護(hù)機(jī)構(gòu)的數(shù)據(jù)控制者會(huì)核實(shí)所有已獲得了區(qū)塊鏈網(wǎng)絡(luò)同意的數(shù)據(jù)。

6. 同時(shí)，區(qū)塊鏈網(wǎng)絡(luò)為新的記錄提供了一個(gè)唯一遞增的標(biāo)識(shí)主鍵和一個(gè)時(shí)間戳。

7. 該應(yīng)用程序會(huì)創(chuàng)建一個(gè)新的交易數(shù)據(jù)包，并將其發(fā)送到以太坊區(qū)塊鏈網(wǎng)絡(luò)中。該交易包使用的是前面提到的整個(gè)新記錄的詳細(xì)信息，作為嵌入式字符串，以創(chuàng)建一個(gè)記錄證明的SHA256哈希值。而該加密的SALT正是用戶錢包的公共地址。

8. 為了在區(qū)塊鏈網(wǎng)絡(luò)上提交這筆新的交易，應(yīng)用程序“App1 Data Entry”會(huì)去檢索智能合約最新的版本地址。從技術(shù)上說(shuō)，要獲取最新的智能合約地址，就必須調(diào)用“主數(shù)據(jù)中繼合約”。它恰好是“主數(shù)據(jù)合約”所有舊版本或最新版本的注冊(cè)表。而由于智能合約是不可變的，因此我們無(wú)法更改任何現(xiàn)有的智能合約，而要想添加新的功能，我們就得創(chuàng)建一個(gè)新的合約。這就是為什么中繼或注冊(cè)模式可以協(xié)助規(guī)整出新的合約，而不必?fù)?dān)心它們的地址問(wèn)題。

9． 一旦應(yīng)用程序收到最新且正確的“主數(shù)據(jù)合約”地址，它就會(huì)向名為 “AddRecordProof”的智能合約函數(shù)發(fā)送包含用戶識(shí)別碼（UID，即“記錄主鍵”）、時(shí)間戳和SHA256哈希值（即記錄證明）的交易數(shù)據(jù)包。該功能應(yīng)受到嚴(yán)格的限制，只能由授權(quán)人（如：數(shù)據(jù)控制者）使用數(shù)據(jù)控制者的錢包密鑰（如：公私鑰對(duì)）進(jìn)行加密調(diào)用。注意，功能性訪問(wèn)控制是在“安全層合約”中被定義的。它具有諸如：可擁有性和斷路器等不同的安全功能。

10. “主數(shù)據(jù)合約”使用名為“數(shù)據(jù)存儲(chǔ)層合約”的存儲(chǔ)庫(kù)合約，將這些數(shù)據(jù)存儲(chǔ)在智能合約中。與其調(diào)用者相比，數(shù)據(jù)存儲(chǔ)層的分離，賦予了在合約內(nèi)添加或更改任何變量或結(jié)構(gòu)的權(quán)限，因此它是一個(gè)獨(dú)立的合約。由于其在部署之后不可能更改任何變量，因此使用動(dòng)態(tài)數(shù)組創(chuàng)建的存儲(chǔ)庫(kù)將有助于控制更改。而在交易成功后，以太坊會(huì)生成一個(gè)新的“交易哈希值”。而保護(hù)機(jī)構(gòu)必須支付gas費(fèi)，才能記錄這些數(shù)據(jù)。

11. 名為“App3 Data Breach Viewer（數(shù)據(jù)泄漏查看器）”的應(yīng)用程序，專用于查看記錄的真實(shí)性。它以網(wǎng)格視圖來(lái)顯示所有的用戶記錄，并帶有“驗(yàn)證”按鈕。該按鈕在被點(diǎn)擊時(shí)，會(huì)向名為“getRecordProof”的“主數(shù)據(jù)合約”函數(shù)發(fā)送請(qǐng)求，該函數(shù)使用新生成的SHA256哈希值，作為鏈外記錄的標(biāo)識(shí)符。同時(shí)，該函數(shù)會(huì)將“記錄證明”的SHA256哈希值返回給應(yīng)用程序。而且該記錄在此前已由數(shù)據(jù)收集者注冊(cè)過(guò)。

12. 該應(yīng)用程序的后臺(tái)會(huì)從MySQL數(shù)據(jù)庫(kù)中檢索那些離鏈的數(shù)據(jù)記錄，并使用SHA256生成新的記錄證明。注意，智能合約中的記錄證明必須和離鏈記錄相同，才能被視為有效。否則，該記錄將被視為無(wú)效或被更改。

13. 那些被更改的記錄將會(huì)被包含在通知中，發(fā)送給數(shù)據(jù)控制者。而被更改的數(shù)據(jù)庫(kù)則可以通過(guò)數(shù)據(jù)中心的備份數(shù)據(jù)庫(kù)予以復(fù)制，或被更新到其原始位置。

模型合規(guī)性

我們可以通過(guò)下表來(lái)了解該模型所滿足的GDPR各項(xiàng)條款：

小結(jié)

通過(guò)重復(fù)利用區(qū)塊鏈技術(shù)的優(yōu)勢(shì)，上述模型提出了一個(gè)滿足GDPR的數(shù)據(jù)泄漏檢測(cè)系統(tǒng)，實(shí)現(xiàn)了數(shù)據(jù)的完整性、機(jī)密性、訪問(wèn)控制、透明度、以及數(shù)據(jù)所有者與同意的真實(shí)性。我們下期見(jiàn)！