大數(shù)據(jù)分析的訪問控制需要基于策略的安全性，包括對(duì)于環(huán)境的安全管理以及用戶和角色的管理。大數(shù)據(jù)分析的安全性管理是具有挑戰(zhàn)性的。原因就在于：當(dāng)您無法進(jìn)行數(shù)據(jù)分析的時(shí)候，您可能需要復(fù)制數(shù)據(jù)。而一旦數(shù)據(jù)被復(fù)制，所有關(guān)于確保數(shù)據(jù)安全性方面的相應(yīng)的規(guī)定，包括誰有權(quán)限可以查看數(shù)據(jù)；或在什么情況下?lián)碛懈臄?shù)據(jù)的權(quán)限，也應(yīng)該隨著數(shù)據(jù)的復(fù)制一并被復(fù)制。但在今天，這幾乎是不可能的。

在Hadoop/Spark方面，我們只有基于角色的、有限的訪問控制列表(ACL)。但我相信有一條可以更進(jìn)一步的道路：在更廣泛的安全市場(chǎng)采用已經(jīng)出現(xiàn)的基于策略的方法。為了探索這一方法要如何才能奏效，我們需要重新審視訪問控制的歷史，以及其如何演變，進(jìn)而產(chǎn)生了基于策略的模型。

回顧訪問控制的歷史

盡管在最開始的時(shí)候，會(huì)有用戶名和密碼的身份驗(yàn)證，以防止任何人的隨便進(jìn)入訪問，理查德·斯托曼說。

但這樣的訪問身份驗(yàn)證登錄系統(tǒng)存在一個(gè)固有的問題。即我們的用戶/密碼組合的數(shù)量會(huì)隨著新的應(yīng)用程序的不斷增加而趨于出現(xiàn)爆炸似增長(zhǎng)，所以我們最終必須以不同的用戶名/密碼來登錄到每一款不同的應(yīng)用程序。更糟糕的是，一些應(yīng)用程序甚至要求了不同的密碼，以達(dá)到不同級(jí)別的安全性。

我們開始變得更加聰明，通過用戶名來區(qū)分我們的“角色”。例如，我們有一套“用戶名/密碼”，但為了訪問某些管理功能，則需要該用戶名/密碼具有“管理員”的作用。然而，鑒于每一款應(yīng)用程序都傾向于有自己的部署方式，所以您仍然需要記住越來越多的各種密碼列表。

我們甚至變得更聰明，創(chuàng)造了中央系統(tǒng)，最終成為L(zhǎng)DAP、活動(dòng)目錄等等。這些統(tǒng)一的用戶名/密碼被存儲(chǔ)在一個(gè)核心庫(kù)，并建立一個(gè)位置，能夠針對(duì)給定用戶的角色來查找相應(yīng)的用戶名/密碼——但這只是以一個(gè)問題代替了另一個(gè)問題。

在一個(gè)理想的世界中，每一款新的應(yīng)用程序都會(huì)在活動(dòng)目錄中

查看角色列表，并將其映射到應(yīng)用程序角色中，所以便會(huì)有一個(gè)干凈、一對(duì)一的關(guān)系。但在現(xiàn)實(shí)中，大多數(shù)應(yīng)用程序?qū)τ诮巧睦斫舛际遣煌?，這非常簡(jiǎn)單，因?yàn)槟赡苁悄骋豢顟?yīng)用程序的管理員，但這并不意味著您應(yīng)該是另一款應(yīng)用程序的管理員。最終的結(jié)果是，您會(huì)有各種爆炸增長(zhǎng)的角色，來取代爆炸似增長(zhǎng)的用戶名/密碼組合。

這就引出了一個(gè)問題：最終要由誰來負(fù)責(zé)添加新的角色?其往往是承擔(dān)了行政職能或人力資源管理職能的IT管理人員。而由于從事這些諸如負(fù)責(zé)添加新的角色等瑣碎的工作任務(wù)的人員，對(duì)于相關(guān)的應(yīng)用程序并沒有很好的理解，使得這樣的工作往往最終成為了一個(gè)“經(jīng)理審查批準(zhǔn)”或“橡皮圖章”了，而并非如他們所說那樣好。

許多仍然存在角色問題的應(yīng)用程序采用AD進(jìn)行身份驗(yàn)證，并讓應(yīng)用程序處理自己的本地角色的實(shí)現(xiàn)問題。關(guān)于這種方法有很多值得探討的地方，因?yàn)檫@很顯然，應(yīng)用程序的管理員知道誰應(yīng)該有什么權(quán)限級(jí)別的訪問。

同時(shí)，有明確的規(guī)則不適合于用戶/角色系統(tǒng)。在其最簡(jiǎn)單的方面，例如，不能因?yàn)槲沂悄臣毅y行的客戶，就意味著我可以從任何帳戶取錢，即使我有“可以從該銀行取錢”的角色。角色通常需要與數(shù)據(jù)相關(guān)聯(lián)，這就是為什么我們要用ACL映射到我們的數(shù)據(jù)存儲(chǔ)條目的原因所在了。也就是說，帳戶1234需要進(jìn)行一個(gè)關(guān)聯(lián)，確定了我作為該1234帳戶的所有者，同時(shí)我的配偶作為一個(gè)授權(quán)的帳戶管理員。

然而，一些企業(yè)有比“這是您的嗎?”或者“您在這方面有什么權(quán)限?”更復(fù)雜的規(guī)則。相反，他們會(huì)使用您可能稱之為“基于環(huán)境”或“基于政策的”安全規(guī)則。換句話說，當(dāng)我在美國(guó)本土的時(shí)候，我可能有取錢的權(quán)限。這在一個(gè)ACL或基于角色的模型是沒辦法表達(dá)的。相反，我們已經(jīng)有了跨基于策略的安全性。

當(dāng)您只能在特定的時(shí)間執(zhí)行一些工作

基于策略的安全性通常存在于一個(gè)中央存儲(chǔ)庫(kù)，并且依賴于中央認(rèn)證機(jī)制(LDAP、Kerberos等等)。所不同的是，并非保持一個(gè)簡(jiǎn)單的角色(如可以取錢)，每個(gè)用戶都與一組策略相關(guān)聯(lián)。該策略是基于與用戶相關(guān)的一組屬性所制定的，其也被稱為基于屬性的訪問控制(ABAC)。這些政策不能集中強(qiáng)制執(zhí)行，因?yàn)樗麄兪峭耆蕾囉趹?yīng)用程序的。

目前已經(jīng)有相應(yīng)的標(biāo)準(zhǔn)對(duì)其進(jìn)行支持了，部分原因是由于國(guó)防業(yè)及其他相關(guān)行業(yè)的選擇所推動(dòng)的。其中的一個(gè)標(biāo)準(zhǔn)便是可擴(kuò)展訪問控制標(biāo)記語言(XACML)，其允許您表達(dá)一組管理政策。執(zhí)行通常是基于應(yīng)用程序的，使用某種算法或規(guī)則系統(tǒng)。XACML是一種相當(dāng)全面的標(biāo)準(zhǔn)化的語言，用于表達(dá)甚至處理諸如政策沖突或兩種算法執(zhí)行一種政策的沖突等異常。

通常這些ABAC驅(qū)動(dòng)的政策，在RBAC的情況下，都是基于數(shù)據(jù)的，而不是單獨(dú)基于應(yīng)用程序功能的(您只能當(dāng)您在美國(guó)為特定企業(yè)工作，并且是一名工作良好、遵紀(jì)守法的信譽(yù)公民時(shí)才可以訪問F-22示意圖)。應(yīng)用該政策的第一個(gè)步驟之一就是身份識(shí)別，并“標(biāo)記”政策規(guī)則應(yīng)適用的數(shù)據(jù)。

為什么要關(guān)心先進(jìn)的安全攻擊問題

顯然，利用ABAC模式的政策和XACML較之RBAC無疑是向前邁進(jìn)了一大步。哪怕僅僅只是為了避免1億美元的高額罰款，您也應(yīng)該有這樣做的動(dòng)機(jī)。我所指的這里的1億美元罰款，那里的1億美元罰款，過不了多久加起來就會(huì)讓您損失慘重。

此外，一些企業(yè)組織有復(fù)雜的規(guī)則和數(shù)據(jù)的所有權(quán)。由于這些公司越來越多地轉(zhuǎn)移到成為數(shù)據(jù)驅(qū)動(dòng)的企業(yè)，但又不能分析一切的數(shù)據(jù)，無需集中，他們所需要的是超越了今天一般性的RBAC模型的系統(tǒng)。此外，為了使其方案是可行的，他們將需要標(biāo)記和庫(kù)，讓他們能夠適用相關(guān)的政策，表達(dá)諸如XACML以及集中管理政策的工具，同時(shí)將其應(yīng)用到局部有意義的地方。

當(dāng)我們來看看今天的大數(shù)據(jù)產(chǎn)品，如Ranger和Sentry時(shí)，沒有哪一款產(chǎn)品能夠很好的解決上述問題。即使是基于關(guān)系數(shù)據(jù)庫(kù)的系統(tǒng)解決方案也往往是專有的、昂貴的，往往是不完整的。制定了高安全性與復(fù)雜的安全規(guī)則的企業(yè)組織必須強(qiáng)制自己實(shí)施這一規(guī)則。但是，諸如大數(shù)據(jù)系統(tǒng)如Hadoop這樣的數(shù)據(jù)標(biāo)注工具仍處于起步階段。

換句話說，對(duì)于供應(yīng)商們而言，有一個(gè)巨大的市場(chǎng)機(jī)會(huì)。顯然，國(guó)防工業(yè)的企業(yè)或?qū)⒊蔀樗麄兊牡谝粋€(gè)客戶，因?yàn)樗麄円呀?jīng)有做這方面的必要性了。隨著越來越多的企業(yè)為大數(shù)據(jù)分析創(chuàng)造中央數(shù)據(jù)倉(cāng)庫(kù)，基于策略的安全需求將會(huì)進(jìn)一步增長(zhǎng)。