詳解頗具挑戰(zhàn)的大數(shù)據(jù)安全分析

面向大數(shù)據(jù)分析的訪問控制技術(shù)需要基于策略的安全機制，這種安全機制不僅包括用戶和角色，還包括上下文。
面向大數(shù)據(jù)分析的安全頗具挑戰(zhàn)性
原因如下：如果你無法當(dāng)場分析，就需要復(fù)制該數(shù)據(jù)。這時候，關(guān)于誰可以在什么樣的情況下，查看或更改各種各樣數(shù)據(jù)的所有規(guī)定也應(yīng)該一并復(fù)制。而如今，這幾乎是不可能完成的任務(wù)。
在hadoop/Spark方面，我們只有基于角色的、有限的訪問控制列表（ACL），這種安全機制可以說很原始。不過我認為倒是有一條出路：采用基于策略的方法，這種方法已出現(xiàn)在更廣泛的安全市場。為了探究這是如何工作的，我們需要回顧訪問控制的歷史，以及它如何演變、推出一種基于策略的模式。
簡述訪問控制的歷史
起初，使用用戶名和密碼將可能想要闖入的每個人拒之門外。
這套系統(tǒng)存在一個固有的問題。隨著新編寫的應(yīng)用程序越來越多，用戶/密碼組合的數(shù)量往往隨之激增，于是我們最后只好為每個應(yīng)用程序使用不同的用戶名/密碼。更糟糕的是，一些應(yīng)用程序需要不同的密碼，以便獲得不同的安全級別。
我們變乖了，使用用戶名劃分了“角色”。比如說，我們會有一個“用戶/密碼”，但是想訪問管理員功能，該用戶/密碼還需要“管理員”角色。然而，每個應(yīng)用程序往往以自己的方式實施這種機制，所以你仍得記住越來越多的密碼。
接下來，我們變得更乖了，設(shè)計出了中央系統(tǒng)，它們最終成為了LDAP和活動目錄等系統(tǒng)。這類系統(tǒng)將用戶/密碼合并在一個核心庫，并設(shè)立了一個地方，以便查詢某個用戶的角色，但是這在解決一個問題的同時帶來了另一個問題。
在理想情況下，每個新的應(yīng)用程序查看活動目錄中的角色列表后，將它們與應(yīng)用程序角色對應(yīng)起來，那樣就有了清楚的一對一關(guān)系。而實際上，大多數(shù)應(yīng)用程序考慮角色的方式不一樣；除此之外，就因為你是某個應(yīng)用程序的管理員，并不意味著你應(yīng)該是另一個應(yīng)用程序的管理員。最后，只不過是將數(shù)量激增的用戶名/密碼組合換成了數(shù)量激增的角色。
這就引出了一個問題：最后誰來負責(zé)增添新的角色？這往往是某種IT管理職能或與人力資源部門共擔(dān)的職能。由于負責(zé)增添角色的那些人很可能并不是非常切實了解應(yīng)用程序，這到頭來通常成了 “經(jīng)理審批”或“橡皮圖章”，這并不好。
許多應(yīng)用程序仍采用這種方法來解決角色問題：使用活動目錄來驗證身份，讓應(yīng)用程序處理自己的本地角色實現(xiàn)。這種方法被人津津樂道，因為顯然是應(yīng)用程序管理員知道誰應(yīng)該有什么樣的訪問級別。
同時，有些明確的規(guī)則并不是很適合用戶/角色這種系統(tǒng)。簡單來說，因為我是個銀行客戶，并不意味著我可以從任何賬戶取錢，哪怕我擁有“能取錢”這一角色。角色常常需要與數(shù)據(jù)關(guān)聯(lián)起來，這就是為什么ACL與數(shù)據(jù)存儲區(qū)中的條目一一對應(yīng)。也就是說，賬戶1234擁有一種關(guān)聯(lián)，可以識別我是賬戶所有者、我的配偶是授權(quán)的賬戶管理員。
然而，一些公司擁有較復(fù)雜的規(guī)則，比“這是你的嗎？”或“你對此記錄擁有什么樣的權(quán)限？”來得復(fù)雜。相反，它們使用所謂的“上下文”或“基于策略”的安全規(guī)則。換句話說，我可能擁有這種權(quán)限：只有在美國境內(nèi)才可以取錢。在ACL或基于角色的模式中無法表示這一點。相反，我們進入到了基于策略的安全。
你有時只能做某些事情
基于策略的安全往往存在于中央庫，依賴中央驗證機制（LDAP和Kerberos等）。區(qū)別在于，每個用戶與一組策略關(guān)聯(lián)起來，而不是維持簡單的角色（比如“能取錢”）。策略基于關(guān)于用戶的一組屬性，又叫基于屬性的訪問控制（ABAC）。那些策略無法集中執(zhí)行，因為它們完全依賴應(yīng)用程序。
已經(jīng)有支持這種方法的標(biāo)準(zhǔn)，一方面來自國防業(yè)及其他個別行業(yè)?？蓴U展訪問控制標(biāo)記語言（XACML）就是這樣一種標(biāo)準(zhǔn)，它讓你可以表示一組組策略。通常基于應(yīng)用程序來完成執(zhí)行，使用某種算法或規(guī)則系統(tǒng)。XACML是一種用于表示策略的相當(dāng)全面的標(biāo)準(zhǔn)，甚至可以處理異常，比如策略沖突，或兩種算法執(zhí)行一個策略。
就像RBAC那樣，ABAC驅(qū)動的這些策略常常基于數(shù)據(jù)，而不是單單基于應(yīng)用程序功能（只有你在美國境內(nèi)為這某一家公司工作，而且是遵紀(jì)守法的公民，才可以訪問F-22戰(zhàn)斗機的圖表）。運用策略的頭一步就是，常常識別策略規(guī)則應(yīng)該適用于哪個數(shù)據(jù)，并“標(biāo)記”該數(shù)據(jù)。
為何要關(guān)注先進安全？
很顯然，使用ABAC式樣的策略和XACML比RBAC邁進了一大步。即使只為了避免遭受巨額罰款，你也應(yīng)該有動機這么做。
此外，有些企業(yè)組織有復(fù)雜的規(guī)則和數(shù)據(jù)所有權(quán)。隨著這些公司日益變得數(shù)據(jù)驅(qū)動型，無法當(dāng)場分析每個數(shù)據(jù)，它們需要一種并不僅限于如今的常見RBAC模式的系統(tǒng)，而不是需要集中。此外，為了讓這切實可行，它們還需要標(biāo)記以及便于運用以XACML等標(biāo)準(zhǔn)表示的策略的庫，另外還需要必要時，在本地運用策略時集中管理策略的工具。
如果我們看一下今天的大數(shù)據(jù)解決方案，比如Ranger和Sentry，沒有一個可以滿足這樣的要求。連面向基于RDBMS的系統(tǒng)的解決方案也往往是專有產(chǎn)品、成本高昂，而且功能不全面。用復(fù)雜安全規(guī)則做好高度安全工作的企業(yè)組織被迫實施這種解決方案。對Hadoop之類的大數(shù)據(jù)系統(tǒng)而言，數(shù)據(jù)標(biāo)記工具仍處于初期階段。
換句話說，如果廠商能切實拿出方案，這方面面臨大好機會。很顯然，國防業(yè)是第一個客戶，因為它已經(jīng)出于需要而在這么做。隨著更多的公司構(gòu)建中央數(shù)據(jù)資料庫用于大數(shù)據(jù)分析，對基于策略的安全的需求只會日益增長。