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

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