大數(shù)據(jù)分析的訪問控制需要基于策略的安全性，包括對于環(huán)境的安全管理以及用戶和角色的管理。大數(shù)據(jù)分析的安全性管理是具有挑戰(zhàn)性的。原因就在于：當您無法進行數(shù)據(jù)分析的時候，您可能需要復(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īng)出現(xiàn)的基于策略的方法。為了探索這一方法要如何才能奏效，我們需要重新審視訪問控制的歷史，以及其如何演變，進而產(chǎn)生了基于策略的模型。

回顧訪問控制的歷史

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

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

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

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

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

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

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

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

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

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

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

基于策略的安全性通常存在于一個中央存儲庫，并且依賴于中央認證機制(LDAP、Kerberos等等)。所不同的是，并非保持一個簡單的角色(如可以取錢)，每個用戶都與一組策略相關(guān)聯(lián)。該策略是基于與用戶相關(guān)的一組屬性所制定的，其也被稱為基于屬性的訪問控制(ABAC)。這些政策不能集中強制執(zhí)行，因為他們是完全依賴于應(yīng)用程序的。

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

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

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

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

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

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

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