https://blog.csdn.net/colorant/article/details/78672404

大數(shù)據(jù)平臺的權(quán)限管理工作，聽起來不就是用戶和密碼管理這點事么？找個數(shù)據(jù)庫存儲一下兩者的映射關(guān)系，然后再找個地方記錄一下每個人可以做什么事，最后在需要的時候驗證一下就好了，如果不討論各種加解密原理和算法，那這個話題有什么值得一談的么？

實際上，如果真正接觸過這方面的工作內(nèi)容，你很快就會發(fā)現(xiàn)，不論是在技術(shù)層面還是在產(chǎn)品層面，大數(shù)據(jù)平臺環(huán)境下的權(quán)限管理工作都是一個讓人傷腦筋的燙手山芋，它不僅僅是一個技術(shù)問題，還是一個業(yè)務(wù)問題，甚至還可能是一個人際溝通和權(quán)衡利益得失的哲學(xué)問題。。。

所以，以下內(nèi)容分兩部分展開，先談?wù)軐W(xué)問題，再談技術(shù)問題。

權(quán)限管理的目標(biāo)是什么？

討論問題之前，先討論目標(biāo)，為什么要做權(quán)限管理，要做到什么程度？

如果要讓你的用戶來回答這個問題，他們多半會說，那還不就是沒事找事，給老子添堵唄？

從技術(shù)的角度來說，用戶說的也沒錯，權(quán)限管理過程的本質(zhì)，就是通過某些技術(shù)手段來限制用戶的可能行為，其結(jié)果就是用戶不能為所欲為 ；）

[圖片上傳失敗...(image-6e8339-1533567574436)]

客觀邏輯上雖然如此，但主觀思想上，如果你僅僅以這個為出發(fā)點來思考問題的話，我相信你早晚是要被人民群眾的汪洋大海所吞沒的 ；）畢竟，限制用戶的行為，只是權(quán)限管理的手段而不是目的。那么目的是什么？個人以為，可以從以下三個角度來討論：

• 適度安全，降低人為風(fēng)險

• 隔離環(huán)境，提高工作效率

• 權(quán)責(zé)明晰，規(guī)范業(yè)務(wù)流程

以下分別闡述一下

適度安全，降低人為風(fēng)險

最直觀的目的就是安全，但是，安全這個目標(biāo)，如果從Security的角度來說，從來都沒有終點，做到什么程度才算安全？這顯然和你的業(yè)務(wù)環(huán)境有關(guān)，如果事關(guān)國家最高安全機密，比如核彈發(fā)射什么的，當(dāng)然怎么做都不過分。

[圖片上傳失敗...(image-241bb8-1533567574436)]

但多數(shù)情況下，對于多數(shù)公司的業(yè)務(wù)環(huán)境來說，現(xiàn)實中最大的問題可能并不是數(shù)據(jù)信息的泄漏，因為其實你并沒有那么多要命的機密數(shù)據(jù)需要保護，即使有一些用戶隱私，金融方面的信息需要保護，通常也只是你的所有數(shù)據(jù)中的一個小小子集。更何況，真的要防止蓄意的竊密行為，通常也不是簡單的通過權(quán)限映射管理就能解決問題的。

那么除了信息安全，還有什么目的和安全這個字眼相關(guān)呢？對，那就是防止誤操作！事實上，誤操作的可能性和導(dǎo)致的傷害可能遠大于信息泄漏帶來的問題，好比每年死于車禍的人遠大于死于謀殺，槍擊，戰(zhàn)爭等惡劣事件的人。從刪庫到跑路問題可能才是日常工作中最有可能煩擾你的問題。

[圖片上傳失敗...(image-5f04c9-1533567574436)]

所以，在實際工作中，從防止信息泄漏這個角度來看，你往往可能只需要做到最低限度的保障就可以了，換句話說，就是防君子不防小人。這當(dāng)然不是說防小人不重要，而是說，防止蓄意的破壞，有時候代價太高，你需要評估投入產(chǎn)出比是否匹配。

但只防君子絕對不代表權(quán)限管理的方案就可以做得很簡單。事實上，防止誤操作這一目標(biāo)，盡管從字面上看起來并不沒有多么高大上，相比于信息泄漏這個字眼，也更容易被忽視，但實際實現(xiàn)起來卻可能更加復(fù)雜，更加困難

因為它不僅僅是簡單的授權(quán)方案方面的技術(shù)問題，實際上收緊權(quán)限和防止誤操作這兩者并不等同，要降低人為的安全風(fēng)險，通常還涉及到系統(tǒng)中權(quán)限點的設(shè)計，業(yè)務(wù)流程的容錯糾錯能力，操作流程的規(guī)范性等等，所以通常需要結(jié)合業(yè)務(wù)知識，在權(quán)限管理體系乃至業(yè)務(wù)系統(tǒng)交互和流程的設(shè)計過程進行針對性的設(shè)計。

隔離環(huán)境，提高工作效率

所謂隔離，從用戶的角度來說，就是將業(yè)務(wù)進行分拆，比如在數(shù)據(jù)平臺整體大環(huán)境中，制造出一個只和當(dāng)前用戶的自身業(yè)務(wù)相關(guān)的小環(huán)境。

這么做的目的也很簡單，一方面在一定程度上，能起到防止誤操作的作用，你看不到別人的業(yè)務(wù)，自然也就無法操作別人的業(yè)務(wù)。此外，因為減少了誤操作非相關(guān)業(yè)務(wù)的可能性，用戶的膽量和自主維護的意愿也能得到提升。

另一方面，將用戶的業(yè)務(wù)環(huán)境進行隔離以后，能讓用戶在使用平臺的過程中，最大程度的減少不必要的信息干擾，降低學(xué)習(xí)成本，提高工作效率。

舉個簡單的例子，你可以將開發(fā)平臺上的所有作業(yè)任務(wù)都展示給用戶，然后提供搜索過濾功能或者層級的目錄樹讓用戶找到自己的任務(wù)。如果用戶對某個任務(wù)沒有權(quán)限，那么就無法打開或執(zhí)行。但是，相比而言如果用戶只能看到自己的作業(yè)任務(wù)，那么上述操作可能都可以省略，他所需要觀察和處理的信息也會更加簡潔，需要做的選擇和判斷也更少，工作效率自然會得到提升。

要做到這點，前提條件自然是做好業(yè)務(wù)的權(quán)限映射管理工作。你可能會說，這也很簡單，就按照任務(wù)owner的關(guān)系進行隔離，大家只能看到自己開發(fā)的作業(yè)和數(shù)據(jù)不就好了么？也不竟然，在實際的業(yè)務(wù)環(huán)境中，哪些是與用戶相關(guān)的作業(yè)或數(shù)據(jù)有時候很難絕對定義。

比如你作為個人，會有自己開發(fā)和負責(zé)的業(yè)務(wù)，但是你也往往希望一個團隊內(nèi)部的成員能共同負責(zé)部分業(yè)務(wù)，或者團隊的Leader能管理團隊內(nèi)部所有成員的業(yè)務(wù)。又或者你作為一個業(yè)務(wù)的上下游利益相關(guān)方，你希望能夠訂閱相關(guān)業(yè)務(wù)的數(shù)據(jù)，作為系統(tǒng)管理員，你希望能夠在必要的時候?qū)θ魏巫鳂I(yè)或數(shù)據(jù)都能進行干預(yù)。同一個用戶在不同的場景中可能承擔(dān)不同的角色，或者同時擁有這些角色中的多個?？傊c用戶相關(guān)的小環(huán)境，往往并不那么容易清晰的定義。

所以，要做到必要且充分的業(yè)務(wù)隔離，還要能夠靈活的滿足各種業(yè)務(wù)關(guān)聯(lián)模型，就要求權(quán)限的映射模型足夠靈活。而光有權(quán)限模型也是不夠的，系統(tǒng)UI的交互設(shè)計也必須結(jié)合業(yè)務(wù)場景進行合理規(guī)劃，但總體的原則，不外乎就是盡量遵循Need to Know原則，不要給用戶過多不必要的信息，進而突出重點，提高效率，降低系統(tǒng)的學(xué)習(xí)和使用成本。

權(quán)責(zé)明晰，規(guī)范業(yè)務(wù)流程

權(quán)限管理，從一個角度看是禁止用戶做不該做的事，但從另一個角度看是授予用戶能做某件事的權(quán)利。如果你認為這是一個權(quán)力，那么伴隨著權(quán)力的授予，我們當(dāng)然希望同時做到責(zé)任的明晰。平臺的權(quán)限管理如果只能靠系統(tǒng)管理員來承擔(dān)，當(dāng)規(guī)模小，業(yè)務(wù)環(huán)境簡單的時候問題不大，當(dāng)系統(tǒng)和業(yè)務(wù)都變得復(fù)雜的時候，就很難維系了。

所以，權(quán)限管理的理想的模式是，能夠?qū)?quán)力和責(zé)任同時下放到相關(guān)的責(zé)任團隊中去，實現(xiàn)業(yè)務(wù)的自治管理。一方面是為了降低平臺的日常管理代價，另一方面，更重要的是通過授權(quán)，明確責(zé)任人，讓每個任務(wù)，每個數(shù)據(jù)都有明確的業(yè)務(wù)和團隊歸屬。

反過來說，也只有責(zé)任明晰了，才能敦促每個相關(guān)負責(zé)同學(xué)，認真的思考和對待手中的權(quán)力，充分發(fā)揮自身的主觀能動性，合理規(guī)劃業(yè)務(wù)的歸屬關(guān)系，權(quán)限的管理也才有可能做到能收能放，而不至流于形式或者成為妨害工作效率的攔路虎。

小結(jié)

權(quán)限管理的目標(biāo)，絕對不是簡單的在技術(shù)層面建立起用戶，密碼和權(quán)限點的映射關(guān)系這么簡單的事，更重要的是要從流程合理性，業(yè)務(wù)隔離，實施代價，可執(zhí)行性等方面進行考慮。單方面強調(diào)安全，結(jié)果往往并不理想。

[圖片上傳失敗...(image-c8935a-1533567574436)]

重要的通過適度的安全管理手段，降低業(yè)務(wù)誤操作的風(fēng)險，結(jié)合業(yè)務(wù)流程和系統(tǒng)交互設(shè)計，實現(xiàn)業(yè)務(wù)的合理分隔，提高工作效率，同時將權(quán)限管理工作分級授權(quán)下放到業(yè)務(wù)負責(zé)人和團隊，實現(xiàn)業(yè)務(wù)自治管理，明晰責(zé)任歸屬，讓權(quán)限管理充分發(fā)揮其促進業(yè)務(wù)健康安全發(fā)展的作用，而不是相反。

所以在實現(xiàn)過程中，要爭取在可接受的安全范圍內(nèi)，保持相對較低的開發(fā)，管理和維護代價，做到真正有效的實施，否則再完美的系統(tǒng)也會因為人的因素而大打折扣。舉個例子，比如美國的核彈發(fā)射密碼箱，一天24小時由將軍以上級別的專人隨身攜帶看管，安全措施可謂嚴(yán)格了吧，但據(jù)坊間謠言傳聞，由于害怕復(fù)雜的密碼總統(tǒng)記不住，核彈發(fā)射安全箱的密碼一度是8個0...

安全與便利的矛盾，有解么？

談完目標(biāo)談問題，如果你不幸做過相關(guān)工作，你應(yīng)該會有體會，在權(quán)限管控方案的實施過程中，最棘手的問題絕對不是單純的技術(shù)問題，而是在當(dāng)前技術(shù)條件水平下，安全與便利，代價與風(fēng)險，平臺與用戶，全體與個體，乃至訴求不同的個體相互之間的利益平衡問題。

天生矛盾

通常來說既然是安全管控，那么顯然得依靠一定的約束條件和規(guī)范來實現(xiàn)，那么客觀上必然給用戶帶來某種不便利性。雖然在實現(xiàn)的過程中，可能可以通過各種方式去自動化或者智能化，但毫無疑問，在同等技術(shù)條件水平下，越安全通常也就意味著越不方便，安全與便利，兩者天生就是矛盾的。

而風(fēng)險，在落到自己身上之前，通常很少有人會真的給予足夠的重視，好比明知道得肺癌的概率很高，也很難下定決心戒煙一樣，更何況有時候得到便利和承受風(fēng)險的對象還有可能是不同的人群。好比丟個香蕉皮，放倒的是過馬路的老奶奶，排放污水，遭殃的是下游吃瓜群眾。。。

因此，不用懷疑，絕大多數(shù)情況下，你的用戶一定不會贊美你在權(quán)限管控方面所做的工作。因為客觀上，用戶的唯一感受就是，你在沒事找事，給他添麻煩了。萬一你還需要他們配合完成改造，那簡直就是作死，如果他們沒有過來PK你，只是冷嘲熱諷幾句，就已經(jīng)是萬幸了，想要用戶真心積極配合？沒有的事。

再退一步說，你的用戶也有可能是一個理智的用戶，他可能認同安全的重要性，但是在代價方面的看法上，也往往可能會與你相左。用戶很可能希望又安全，又便利，對他還沒有代價，如果有，最好是由實施方來承擔(dān)代價，簡單來說，就是安全我認同，但別給我來事。

這其實也是人之常情，但在評估具體的方案和代價收益的時候，就必然影響各方的認知和判斷。

那這種苦差事，該怎么辦？？？說實話，我也沒有太好的實踐，不論如何換位思考，大家的關(guān)注點天生就不一致，所以，矛盾一定會有，只是因時因事，程度輕重不同而已。我要說，橫眉冷對千夫指，俯首甘為孺子牛，你會不會很絕望 ；）

好吧，雖然如此，還是要想想變通的辦法的，以下姑且讓我暢想一下可能的做法

改變角度，轉(zhuǎn)移目標(biāo)

既然天生矛盾，那么，能否轉(zhuǎn)移矛盾？有時候，瞞天過海或許是一個可行的方案。怎么解釋呢？如前所說，開發(fā)平臺安全管控目標(biāo)的達成，各種權(quán)限的約束和限制固然是必要的，但同時，流程的規(guī)范，產(chǎn)品交互設(shè)計的改進和業(yè)務(wù)的合理規(guī)劃在達成這個目標(biāo)的過程中其實也是同等重要的，而這些工作，不光有助于提升安全性，往往也有助于改進和提升用戶在平臺上的產(chǎn)品體驗和工作效率。

所以，如果有可能，就不要讓用戶在安全性和便利性這兩者之間進行PK，而是盡可能在提升安全的同時，為用戶創(chuàng)造一些他們更加關(guān)心的附加收益，讓用戶在這些他們關(guān)心的收益和安全手段帶來的麻煩之間進行PK。如果這些收益大于便利性上的損失，那么相信你的工作也就能推進得更加順利一些。說直白一點就是，如果有可能，換個角度驅(qū)動這件事的開展。

[圖片上傳失敗...(image-70c3cd-1533567574436)]

舉個簡單的例子，如果你要加強數(shù)據(jù)的權(quán)限管控，要求用戶必須遵守特定的用戶名規(guī)范，登記IP地址并且申請對應(yīng)的表權(quán)限才能讀寫數(shù)據(jù)，那么或許你可以通過為他提供配置化的建表工具，查詢工具，并提供相關(guān)數(shù)據(jù)的負載，血緣，流量監(jiān)控等服務(wù)。將對用戶的安全約束條件轉(zhuǎn)變成，為了能夠使用對應(yīng)的服務(wù)，用戶所必須提供的基礎(chǔ)信息，這樣依賴，大概用戶配合的意愿度就會有很大的提升。

把握尺度

多數(shù)情況下，你和用戶的矛盾不是安全管控這件事要不要做，而是做到什么程度，也就是尺度的把握。但尺度的把握是個哲學(xué)問題，什么樣的尺度才是合理的，現(xiàn)實中，你很難找到一個可以絕對客觀衡量的標(biāo)準(zhǔn)。

如果是大是大非的問題，各方只要理智一些，就不難達成一致，但難就難在有些場景下，大家角色不同，訴求和感受都不一致，可以說評估用的尺子都不是同一把，那么又以誰的尺子為準(zhǔn)來衡量呢？

有沒有辦法做到盡量客觀？

[圖片上傳失敗...(image-bf5d6c-1533567574436)]

盡管沒有絕對客觀的衡量標(biāo)準(zhǔn)，但我們還是可以從權(quán)限管控方案可預(yù)見的執(zhí)行效果（或者不執(zhí)行的風(fēng)險）方面進行一定的評估。大是大非的情況就不討論了，模糊的情況下，或許可以從以下幾個方面來考慮相關(guān)權(quán)限管控方案的制定是否合理，是否必要，是否可以改進。

1\. 相關(guān)權(quán)限管控與否，是否對他人的工作有影響，是否會讓用戶之間可能存在潛在的沖突？

這一條是通常是在資源共享或者系統(tǒng)，平臺，服務(wù)共享的場景下要考慮的基礎(chǔ)判定標(biāo)準(zhǔn)。有權(quán)力就要承擔(dān)責(zé)任，自己方便的同時，要考慮是否對它人可能造成影響。如果權(quán)限不加管控，有很大的可能出現(xiàn)上述問題或者一旦出現(xiàn)風(fēng)險很高，那就需要考慮進行約束，當(dāng)然，如前所述，更理想的方式是通過隔離手段，在產(chǎn)品形態(tài)上就能規(guī)避這類風(fēng)險問題，但這并不是所有的場景都能做到的。

2\. 加上相關(guān)權(quán)限管控后，大部分同學(xué)是不申請權(quán)限了（并且似乎也沒有多少人抱怨），還是依然會申請權(quán)限（且抱怨）？

這條是用來判斷相關(guān)的權(quán)限管控帶來的不便利性，到底是在管控不必要的偽需求，還是僅僅是給剛需帶來了附加的成本。

3\. 是否幾乎全部的權(quán)限申請最終都會通過？

如果相關(guān)權(quán)限申請一百次99次全都通過的，那么基本有三種可能：一是審批者無法判斷相關(guān)申請是否合理，二是相關(guān)申請其實在審批者看來無關(guān)痛癢（通常意味著即使錯誤的漏過了也沒多大危害），最后也有可能大家的申請真的都是合理的

那么怎么判斷是否第三種情況呢？我覺得，可以從申請的數(shù)量上來判斷，如果是很罕見的申請，比如十天半個月才有人申請一次的，那么的確有可能是第三種情況。如果是一天發(fā)生十幾次幾十次的申請，那么很有可能是前兩種情況。

4\. 相關(guān)權(quán)限管控措施，是否只是有利于安全？

這條怎么說呢，就是權(quán)限管控的收益，除了實施者心中認為的安全因素以外，是否還有其它收益。如果沒有，而安全這部分收益大家又不見得意見一致，那么它的權(quán)重可能是要打點折扣的。

大致可以上述幾個方面來判斷當(dāng)前方案合理性。如果上面4條都不滿足，那么很大幾率不是安全的尺度把得過嚴(yán)，應(yīng)該放寬；就是實際實施的方案姿勢有問題，應(yīng)該變革。如果只是其中一兩條不太理想，那么可能我們整體做得還可以，但在具體的實施手段或者規(guī)則制度，流程優(yōu)化，規(guī)范宣導(dǎo)方面還存在改進的空間。

可能的變通措施

客觀，嘴上說容易，實際操作起來，卻很難。不是因為你不想客觀，而是因為事情是復(fù)雜的，正反面因素往往同時都有，你可能堅持其中一面，而忽視另外一面。

那怎么辦？雖說世上無難事，只要肯堅持，但一條路走到黑，相互PK到底，有時也并不是最聰明的做法。畢竟我們最終關(guān)心的只是風(fēng)險能否控制，而非采用何種方式控制風(fēng)險?；蛟S換個方式，大家更容易達成一致。

事前審批 V.S. 事后審計

所謂的事前審批，就是你不申請權(quán)限我就不讓你通過，做任何事情都必須走流程。而所謂的事后審計，就是你先做，我之后加以檢查你的使用是否合理合規(guī)。

你可能會說，權(quán)限管理和審計是兩碼事了，后者的前提是你已經(jīng)有權(quán)限了，然后再審查權(quán)限是否使用恰當(dāng)。把事情簡單化的確如此，但實際具體系統(tǒng)實施過程中，你是主要依托審計還是主要依托審批，可能會將影響到你的權(quán)限模型的規(guī)劃和最終方案的實現(xiàn)。

比如，如果你的某個服務(wù)，相關(guān)權(quán)限在業(yè)務(wù)流程中具備分級授權(quán)管理的可能，那么你就可以考慮將部分操作權(quán)限下放給業(yè)務(wù)組負責(zé)人，如果是業(yè)務(wù)負責(zé)人在業(yè)務(wù)組范圍內(nèi)進行的權(quán)限相關(guān)改動，就可以考慮不走審批流程直接生效，那么，整個系統(tǒng)的權(quán)限點的設(shè)計和業(yè)務(wù)流程都有可能因此而采用不同的方案。

這么做的風(fēng)險，是有時候業(yè)務(wù)和權(quán)限的從屬關(guān)系并沒有那么明晰（還沒做到或者壓更就做不到），如果跳過審批流程，就需要對應(yīng)的業(yè)務(wù)負責(zé)人能夠正確評估自己的行為，因此就可能存在少部分業(yè)務(wù)組負責(zé)人不負責(zé)任瞎授權(quán)，或者授權(quán)范圍大于實際負責(zé)范圍的情況。

但如果你的業(yè)務(wù)場景并不是生死悠關(guān)，需要萬無一失，那么這些風(fēng)險在短期內(nèi)或小范圍內(nèi)，或許也是可以接受的。要保證這一風(fēng)險控制的前提條件，就要求你能夠在事后進行審計，及時的修正錯誤的行為。換句話說，就是舍棄絕對的安全，用審計來保障可控的風(fēng)險，換取便利性和工作效率的提升

最后，事情如果可以做到如此理想，為什么有時候我們不這么做？

一來，因為有時候事前審批的系統(tǒng)實現(xiàn)起來往往更加簡單，因為不需要分場景考慮實現(xiàn)方案了嘛，一刀切就好，技術(shù)成本比較低。

二來，是因為這么做的前提條件是你需要合理規(guī)劃業(yè)務(wù)和權(quán)限模型，并為每個業(yè)務(wù)找到負責(zé)人/代理人，確認有人能對最終的結(jié)果負起責(zé)任，否則放出去的權(quán)限就收不回來了。但有時候，你很可能做不到這點，或者要做到這點需要投入巨大的精力

如何盡量少給用戶大爺們添堵

如果沒法變通，那只好低調(diào)做人，少惹麻煩。

排除權(quán)限管控方案改造過程中需要上下游業(yè)務(wù)方配合改造的工作不說，存粹從最終系統(tǒng)完成后，用戶使用的角度來說，常見的用戶問題包括：

• 不知道有什么權(quán)限可申請？在哪申請？找誰申請？

• 權(quán)限審批流程，響應(yīng)慢，沒人管，不知道進度

• 總感覺流程復(fù)雜，沒必要，影響開發(fā)效率

上述問題，本質(zhì)上不太可能完全徹底解決，因為就算方案本身沒有問題，這里面還涉及到許多人的因素，而人的因素其實你很難完全掌控。不論是立場問題，角度問題，還是信息不對稱問題，很多時候都是要多方共同努力來改進的。

但是，從平臺方案設(shè)計實施的角度來說，做好一些工作還是有希望能減少用戶在上述問題方面的抱怨的，下面就來討論一下。

我是誰？我在哪？我該怎么辦？讓用戶知道何去何從

[圖片上傳失敗...(image-740501-1533567574436)]

各種后臺服務(wù)的權(quán)限管控方案中，很常見的一類產(chǎn)品設(shè)計問題，就是對新用戶不夠友好，沒有任何引導(dǎo)性的內(nèi)容，如果沒有權(quán)限，相關(guān)功能對用戶就完全不可見了，新用戶上來面對的是一個完全空白的系統(tǒng)，連有哪些權(quán)限可以申請都不知道，更別提找誰申請了。遺憾的是，這類系統(tǒng)的設(shè)計者往往還對自己能管的嚴(yán)特別自豪。。。

舉個簡單的例子，比如一個報表系統(tǒng)，你顯然應(yīng)該通過權(quán)限管控，讓用戶無法看到敏感報表的數(shù)據(jù)。但是我經(jīng)?？吹皆谝恍╊愃葡到y(tǒng)的設(shè)計中，用戶上來連報表列表都沒法查看，給用戶哪些報表權(quán)限，完全由管理員來配置，用戶在這個過程中，能做什么？只能完全靠問啊，有什么報表靠問，報表內(nèi)容是什么靠問，找誰開通權(quán)限靠問，什么時候開通權(quán)限靠問。。。

這種管控方案未必完全不可行，如果你處在一個中央集權(quán)的業(yè)務(wù)環(huán)境中，這么做天然就是正確的。但是多數(shù)情況下，這種方案的效率堪憂，不管是對用戶還是對管理員。而且即使以安全為理由，這種簡單的有和沒有的一刀切方案，本質(zhì)上也是技術(shù)和產(chǎn)品方面懶惰的表現(xiàn)。

更合理的做法，或許應(yīng)該是通過構(gòu)建報表的元數(shù)據(jù)信息管理，將這些非敏感信息透明化，區(qū)別對待。即使沒有權(quán)限，用戶也應(yīng)該能獲取到相關(guān)報表的基本信息。比如能夠查詢到完整的報表列表，能夠查看報表的業(yè)務(wù)描述，字段信息，負責(zé)人，變更記錄，訂閱情況，業(yè)務(wù)歸屬關(guān)系等等，并且能夠直接在系統(tǒng)上對相關(guān)報表主動發(fā)起權(quán)限申請。

總之，就是在各種服務(wù)產(chǎn)品的設(shè)計過程中，要盡可能讓用戶能夠獲取足夠的信息，去驅(qū)動下一步的動作，不光考慮有權(quán)限可以做什么事，更要考慮沒有權(quán)限可以做什么事。而當(dāng)用戶因為權(quán)限問題遇到障礙時，也要引導(dǎo)和提示他下一步去哪里申請，而不是簡單的阻斷操作了事。

相比一刀切的方案，這么做無疑要花費更大的開發(fā)代價，產(chǎn)品形態(tài)上各種權(quán)限的劃分也需要考慮得更加細致，但從改善用戶體驗，降低溝通成本，減少維護代價的角度來說，通常都是值得的。

能否降低權(quán)限申請煩躁指數(shù)？

對于申請了權(quán)限，急著用，但是沒人批，不知道進度如何了等等問題。從過程的角度來說，我們可以采用各種方式來改善過程的體驗，比如通過各種方式提醒審批人（消息，短信，工單等等），設(shè)置代理人，反饋審批進度，諸如此類。

那么這些工作的實際收益如何呢？ 從審批人的角度來看，各種提醒，代理能一定程度上加快響應(yīng)速度，但也有個限度，過度提醒對審批人的工作效率也會造成影響。從申請人的角度來看，反饋審批進度，知道當(dāng)前流程走到哪一步了，能夠在一定程度上緩解申請人的焦慮感（也便于催促審批人）。

[圖片上傳失敗...(image-83bd2f-1533567574436)]

但本質(zhì)上，只要最后依然需要人為審批，上述措施所能起到的成效終歸是有限的，申請和審批之間總會有個系統(tǒng)無法控制的人為響應(yīng)的時間差。

因此，有時候我們會發(fā)現(xiàn)，在一些系統(tǒng)中開發(fā)了相應(yīng)的功能以后，用戶依然有很多的抱怨。所以難道是用戶都這么不耐煩？真的有那么多的事情火急火燎，需要立刻完成，一刻都耽擱不了？

能否減少需要申請的權(quán)限數(shù)量？

我覺得，通常這種情況下，加快審批流程運轉(zhuǎn)的效率可能已經(jīng)不是問題所在了。問題在于你的用戶哪來的那么權(quán)限需要立刻審批通過？

我們回頭來思考一下什么樣的權(quán)限申請需要審批？通常是說你不確定這個用戶是否可以做某項工作，所以由相關(guān)的利益相關(guān)人或負責(zé)人來判斷是否放行。

那么，相比提高審批流轉(zhuǎn)效率，更有效的手段或許是減少需要審批的內(nèi)容的數(shù)量。所以，這就意味著我們犧牲安全性，有一些權(quán)限我們就不審批了么？

是，也不是。事實上即使在不明顯降低安全性的情況下，減少需要審批的內(nèi)容，往往也是可行的

舉個簡單的例子，比如RBAC模型很重要的思想，就是解偶權(quán)限點和具體的人的映射關(guān)系。這一方面固然是為了簡化權(quán)限模型（網(wǎng)狀變星型），但另一方面，如果你側(cè)重審批的內(nèi)容是用戶的業(yè)務(wù)角色身份，而不是具體的權(quán)限點，那么一旦用戶角色確定，很多角色覆蓋范圍內(nèi)同類的權(quán)限，事實上也就無需審批了。

上述例子，RBAC模型只是一個應(yīng)用，很多問題可以合理的套上RBAC模型去簡化，但也不是說RBAC模型就是相關(guān)問題的唯一解。我們要知道，在保證同等安全性的同時，降低申請和審批工作量之所以可行，關(guān)鍵是把一些大同小異的重復(fù)過程，通過抽象，變成一次性的過程。而一個用戶，他的工作職責(zé)和范圍在短期內(nèi)往往是相對固定的，所以這件事通常是可行的。

但這件事的難點在于你怎么挖掘和識別出這個可以抽象的模式，最后在業(yè)務(wù)流程和權(quán)限管控方案的設(shè)計中落地體現(xiàn)出來。所以，具體要實現(xiàn)，往往涉及到對業(yè)務(wù)流程和產(chǎn)品形態(tài)規(guī)劃的深入思考。比如前面我們說的權(quán)限下放業(yè)務(wù)組，組內(nèi)工作去審批化也是一種方式，我們審批的是你做一類事情的權(quán)力，而不是在每件事情上進行審批。

避免火燒眉毛

用戶抱怨影響工作效率的場景，流程的絕對響應(yīng)時間有時往往可能不一定是問題，更多時候，是因為一個開發(fā)流程被打斷，或者一件事情事到臨頭了才來處理，這時候，流程上的等待，可能影響心情，可能影響效率，也可能導(dǎo)致問題無法及時解決?？傊?，抱怨的源頭不在于等待流程本身，問題在于在不能等，不想等的時候，卻需要等。

所以，有時候在系統(tǒng)方案設(shè)計過程中，也應(yīng)該思考一下，能否通過合理的產(chǎn)品和流程設(shè)計，減少或避免火燒眉毛的問題出現(xiàn)？

一方面可以通過前面說的角色和業(yè)務(wù)規(guī)劃，權(quán)限下放等方式，減少權(quán)限申請的必要性，來降低遇到問題的概率。另一方面我們也可以在一些場景下，考慮將權(quán)限申請和審批的過程盡量提前來降低這件事的緊急程度。

比如說，你可以將任務(wù)運行階段的權(quán)限檢測工作，提前到任務(wù)開發(fā)階段來進行，不要在半夜任務(wù)運行時再報權(quán)限錯誤，而是在白天任務(wù)腳本修改保存時就先行檢測和驗證所需權(quán)限。

再比如，你可以通過事先規(guī)范權(quán)限應(yīng)用規(guī)則的方式，讓業(yè)務(wù)在開發(fā)相關(guān)工作前，就先申請好與自己相關(guān)的權(quán)限通道。將權(quán)限的申請?zhí)崆暗綐I(yè)務(wù)準(zhǔn)入階段，而不是業(yè)務(wù)開發(fā)階段，避免在開發(fā)過程中實際要測試任務(wù)的時候再來補權(quán)限。

總之，能提前搞定的，就不要臨場解決，這一方面，依靠用戶自身的規(guī)劃意識，另一方面，也可以通過產(chǎn)品和流程的設(shè)計來貫徹和強化這種意識。

自動化，智能化

自動化和智能化很容易理解，就是能不需要人手工做的，就應(yīng)該讓系統(tǒng)來幫你完成。

比如你創(chuàng)建的表，自然就應(yīng)該給你賦予對應(yīng)的權(quán)限。說起來很容易，但實際情況下，很多問題并沒有那么簡單。

比如你創(chuàng)建了一個腳本任務(wù)，這個任務(wù)的腳本的讀寫權(quán)限自然應(yīng)該是屬于你的。但是，我們可能還要考慮下列問題：

• 和你同一個業(yè)務(wù)組的同學(xué)是否需要自動授權(quán)，需要授予什么權(quán)限？如果不想自動授權(quán)，流程上又該如何區(qū)別？如果你參與了多個業(yè)務(wù)組，如何判斷該腳本的歸屬關(guān)系？

• 這個腳本創(chuàng)建的表，寫出的數(shù)據(jù)，產(chǎn)生的內(nèi)容，該如何授權(quán)，要不要授權(quán)？這并不簡單，因為任務(wù)權(quán)限的管理和數(shù)據(jù)權(quán)限的管理，可能是由不同的系統(tǒng)負責(zé)的，需要跨系統(tǒng)創(chuàng)建授權(quán)關(guān)系，而各系統(tǒng)的權(quán)限管理體系，業(yè)務(wù)分組等等也可能并不一致。

• 如果相關(guān)數(shù)據(jù)被同步或復(fù)制到其它系統(tǒng)中，又該如何同步權(quán)限？同構(gòu)體系的同步問題不大，比如DB主從，集群備份之類。但異構(gòu)的數(shù)據(jù)匯總，采集。傳輸之后的權(quán)限。比如hive里面的數(shù)據(jù)導(dǎo)出到報表系統(tǒng)展示，業(yè)務(wù)模型都不一樣了，那么任務(wù)，數(shù)據(jù)，報表之間的權(quán)限關(guān)系又該如何映射，能否需要同步，是否能夠同步？

上訴問題只是舉例說明自動化和智能化可能需要解決的問題，在你的系統(tǒng)中，上訴問題可能不重要，或者也并不一定適合自動授權(quán)。但總體來說，自動化和智能化的問題，難點不在于技術(shù)的實現(xiàn)，難點在于業(yè)務(wù)邏輯上如何確定可行的自動化和智能化的規(guī)則。

如果你的業(yè)務(wù)流程沒有明確的規(guī)范，業(yè)務(wù)內(nèi)容缺乏歸屬關(guān)系的梳理，系統(tǒng)之間交互關(guān)系不明晰，數(shù)據(jù)血緣關(guān)系難以梳理，那么自動化，智能化的工作就很難進行。所以，與其說這是一個權(quán)限管控智能化的工作，不如說更多的是一個數(shù)據(jù)治理的工作。

總結(jié)

權(quán)限管理工作，不是簡單的安全問題，更多的時候，它是一個產(chǎn)品設(shè)計和業(yè)務(wù)治理的理念和目標(biāo)問題。實現(xiàn)權(quán)限的管控往往并不難，難的是如何盡量減少人為參與權(quán)限管控的必要性。

你需要通過用戶引導(dǎo)，方案變通，流程規(guī)劃，價值轉(zhuǎn)移等方式來降低實施的成本和代價，提升最終的實際收益，否則，靠“安全最大”這個尚方寶劍來推動工作是沒問題，但用戶的抱怨和不配合也一定也會讓你的頭很大，很大。。。

上篇我們討論了權(quán)限管控方案在目標(biāo)，產(chǎn)品形態(tài)，實施方式方面的哲學(xué)問題，接下來，討論一下技術(shù)方面的問題。你可能會想，如果不需要防止Hack的行為，那應(yīng)該也不是什么很困難的事吧？

從基本的流程來說，確實如此，所以比如早幾年前，我司從內(nèi)部運營系統(tǒng)到到外部業(yè)務(wù)系統(tǒng)，各種大大小小的后臺，一言不合，就會自己實現(xiàn)一套權(quán)限認證管理的方案。說到底，不就是兩張表的事么，這有何難。。。

[圖片上傳失敗...(image-5921a8-1533567574434)]

不過，當(dāng)系統(tǒng)越來越多，環(huán)境越來越復(fù)雜時，你就會發(fā)現(xiàn)這件事并沒有那么簡單。拋開技術(shù)問題不談，單從用戶體驗的角度來說，如果要在每個系統(tǒng)中都單獨管理自己的用戶賬號和密碼，那肯定瘋掉了。所以，最起碼你需要一個統(tǒng)一的用戶賬號體系。

然后，如果各個系統(tǒng)的權(quán)限申請，管理，審批流程都不一樣，系統(tǒng)開發(fā)和用戶學(xué)習(xí)的成本會不會很高？于是，你又會考慮除了賬號密碼以外，各個后臺的權(quán)限管理模型也應(yīng)該統(tǒng)一。

而具體落到大數(shù)據(jù)平臺的環(huán)境下來討論權(quán)限管理問題，相比多數(shù)以功能操作為導(dǎo)向的業(yè)務(wù)系統(tǒng)，通常又會更加復(fù)雜一些。因為大數(shù)據(jù)開發(fā)環(huán)境的特點，除了用戶個人的操作權(quán)限管理，你還需要考慮：

• 用戶協(xié)同工作時的數(shù)據(jù)共享問題

• 各種存儲，計算，查詢框架之間數(shù)據(jù)互通串聯(lián)的能力

• 數(shù)據(jù)的敏感程度不同，對安全等級的區(qū)分和管控粒度的要求

• 分布式的集群場景，海量的數(shù)據(jù)對象，對權(quán)限管控流程的性能，效率，可維護性的要求

• 各種服務(wù)和集群多樣的交互，編程和接入方式，增加了權(quán)限管控的范圍和難度

• 數(shù)據(jù)的流動性本質(zhì)，對權(quán)限的動態(tài)變更能力的需求

• 各個組件自身架構(gòu)在權(quán)限管控這塊的實現(xiàn)可能千差萬別，如何統(tǒng)一和簡化的問題

所有這些因素都會大數(shù)據(jù)平臺環(huán)境下的權(quán)限管控工作變得愈發(fā)的困難和復(fù)雜。

常見開源方案

權(quán)限管理相關(guān)工作可以分為兩部分內(nèi)容，一是管理用戶身份，也就是用戶身份認證（Authentication），二是用戶身份和權(quán)限的映射關(guān)系管理，也就是授權(quán)（Authorization）

前者，用戶身份認證這一環(huán)節(jié)，在Hadoop生態(tài)系中常見的開源解決方案是 Kerberos+LDAP，而后者授權(quán)環(huán)節(jié)，常見的解決方案有Ranger，Sentry等，此外還有像knox這種走Gateway代理服務(wù)的方案。

下面簡單介紹一下這些開源項目，目的不是為了講解這些方案的實現(xiàn)原理，而是從整體架構(gòu)流程的角度來看看他們的目標(biāo)問題和解決思想，以及適用場景等，這樣當(dāng)你在選擇或者開發(fā)適合自己平臺的權(quán)限管理方案時，也可以做到知其然，知其所以然。

至于Hadoop生態(tài)系的各個組件比如HDFS/Hive/HBase自身的權(quán)限管理模型，針對的是單一的具體組件，也是權(quán)限管控體系中的重要組成部分，但限于篇幅原因，本文就不加以討論了

Kerberos

Kerberos是Hadoop生態(tài)系中應(yīng)用最廣的集中式統(tǒng)一用戶認證管理框架。

[圖片上傳失敗...(image-cc8902-1533567574434)]

其工作流程，簡單的來說，就是提供一個集中式的身份驗證服務(wù)器，各種后臺服務(wù)并不直接認證用戶的身份，而是通過kerberos這個第三方服務(wù)來認證。用戶的身份和秘碼信息在Kerberos服務(wù)框架中統(tǒng)一管理。這樣各種后臺服務(wù)就不需要自己管理這些信息并進行認證了，用戶也不需要在多個系統(tǒng)上登記自己的身份和密碼信息。

原理流程稍微多介紹一點（不想了解細節(jié)的可以跳過）

用戶的身份首先通過密碼向Kerberos服務(wù)器進行驗證，驗證后的有效性會在用戶本地保留一段時間，這樣不要用戶每次連接某個后臺服務(wù)時都需要輸入密碼。

然后，用戶向Kerberos申請具體服務(wù)的服務(wù)秘鑰，Kerberos會把連接服務(wù)所需信息和用戶自身的信息加密返回給用戶，而這里面用戶自身信息進一步是用對應(yīng)的后臺服務(wù)的秘鑰進行加密的，由于這個后臺服務(wù)的秘鑰用戶并不知曉，所以用戶也就不能偽裝或篡改這個信息。

然后，用戶將這部分信息轉(zhuǎn)發(fā)給具體的后臺服務(wù)器，后臺服務(wù)器接收到這個信息后，用自己的秘鑰解密得到經(jīng)過Kerberos服務(wù)認證過的用戶信息，再和發(fā)送給他這個信息的用戶進行比較，如果一致，就可以認為用戶的身份是真實的，可以為其服務(wù)。

核心思想

Kerberos最核心的思想是基于秘鑰的共識，有且只有中心服務(wù)器知道所有的用戶和服務(wù)的秘鑰信息，如果你信任中心服務(wù)器，那么你就可以信任中心服務(wù)器給出的認證結(jié)果。

此外很重要的一點，從流程上來說，Kerberos不光驗證的用戶真實性，實際上也驗證了后臺服務(wù)的真實性， 所以他的身份認證是雙向認證，后臺服務(wù)同樣是通過用戶，密碼的形式登記到系統(tǒng)中的，避免惡意偽裝的釣魚服務(wù)騙取用戶信息的可能性。

應(yīng)用Kerberos的難點在哪

Kerberos從原理上來說很健全，但是實現(xiàn)和實施起來是很繁瑣的

為什么這么說呢，首先所有的后臺服務(wù)必須針對性的接入Kerberos的框架，其次所有的客戶端也必須進行適配，如果具體的后臺服務(wù)提供對應(yīng)的客戶端接入封裝SDK自然OK，如果沒有，客戶端還需要自己改造以適配Kerberos的認證流程。

其次，用戶身份的認證要真正落地，就需要實現(xiàn)業(yè)務(wù)全鏈路的完整認證和傳遞。如果是客戶端直連單個服務(wù)，問題并不大，但是在大數(shù)據(jù)平臺服務(wù)分層代理，集群多節(jié)點部署的場景下，需要做用戶身份認證的鏈路串聯(lián)就沒那么簡單了。

舉個例子，如果用戶通過開發(fā)平臺提交一個Hive腳本任務(wù)，該任務(wù)首先被開發(fā)平臺提交給調(diào)度系統(tǒng)，再由調(diào)度系統(tǒng)提交給Hive Server，Hive Server再提交到hadoop集群上執(zhí)行。那么用戶信息就可能要通過開發(fā)平臺／調(diào)度系統(tǒng)Master節(jié)點／調(diào)度系統(tǒng)Worker節(jié)點／Hive Server／Hadoop 這幾個環(huán)節(jié)進行傳遞，每個上游組件都需要向下游組件進行用戶身份認證工作

就算到了具體的后臺服務(wù)內(nèi)部。比如在Hadoop集群上運行的一個MR任務(wù)，這個認證關(guān)系鏈還需要繼續(xù)傳遞下去。首先客戶端向Yarn的RM節(jié)點提交任務(wù)，客戶端需要和RM節(jié)點雙向驗證身份，然后RM將任務(wù)分配給NM節(jié)點啟動運行，RM就需要把用戶身份信息傳給NM（因為NM節(jié)點上啟動的任務(wù)會需要以用戶的身份去讀取HDFS數(shù)據(jù)）在NM節(jié)點上的任務(wù)以用戶的身份連接HDFS NameNode獲取元數(shù)據(jù)以后，下一步還需要從HDFS Datanode節(jié)點讀取數(shù)據(jù)，也就再次需要驗證用戶身份信息。

上述的每個環(huán)節(jié)如果要支持基于Kerberos的身份驗證，要么要正確處理秘鑰的傳遞，要么要實現(xiàn)用戶的代理機制。而這兩者，實施起來難度都不小，也會帶來一些業(yè)務(wù)流程方面的約束。

雪上加霜的是，這個過程中，還要考慮身份驗證的超時問題，秘鑰信息的保管和保密問題等等，比如MR任務(wù)跑到一半秘鑰或Token過期了該怎么辦，總不能中斷任務(wù)吧？ 所以一套完整的鏈路實現(xiàn)起來絕非易事，這也是很多開源系統(tǒng)遲遲沒有能夠支持Kerberos的原因之一，而自己要在上層業(yè)務(wù)鏈路上完整的傳遞用戶身份信息，也會遇到同樣的問題。

最后是性能問題，集中式管理在某種程度上意味著單點，如果每次RPC請求都要完整的走完Kerberos用戶認證的流程，響應(yīng)延遲，并發(fā)和吞吐能力都會是個比較大的問題，所以比如Hadoop的實現(xiàn)，內(nèi)部采用了各種Token和cache機制來減少對Kerberos服務(wù)的請求和依賴，并不是每一個環(huán)節(jié)步驟都通過Kerberos進行驗證。

小結(jié)

總體來說，Kerberos是當(dāng)前最有效最完善的統(tǒng)一身份認證框架，但是如果真的要全面實施，代價也很高，而從安全的角度來考慮，如果真的要防止惡意破壞的行為，在整個生產(chǎn)環(huán)境流程中，能被突破的環(huán)節(jié)其實也很多，光上Kerberos并不意味著就解決了問題，所以各大互聯(lián)網(wǎng)公司用還是不用Kerberos，大家并沒有一致的做法，即使All in Kerberos的公司，我敢說，除非完全不做服務(wù)化的工作，否則，整體鏈路方面也一定存在很多并不那么Kerberos的環(huán)節(jié) ；）

最后，用戶身份認證只是權(quán)限管理環(huán)節(jié)中很小的一部分，雖然技術(shù)難度大，但是從實際影響來看，合理的權(quán)限模型和規(guī)范的管理流程，通常才是數(shù)據(jù)安全的關(guān)鍵所在。所以，上不上Kerberos需要結(jié)合你的實際場景和安全需求加以考量。

Sentry和Ranger

Sentry和Ranger的目標(biāo)都是統(tǒng)一的授權(quán)管理框架／平臺，不光目標(biāo)，這兩個項目在思想和架構(gòu)方面也大同小異，那么為什么會有兩套如此類似的系統(tǒng)？當(dāng)然是因為Cloudera和Hortonworks兩家互相不鳥，必須各搞一套唄，目前看起來，Sentry借CDH用戶基數(shù)大的東風(fēng)，普通用戶比較容易接受，但Ranger在功能完整性方面似乎略微占點上風(fēng)。

相比用戶身份認證，授權(quán)這件事情和具體服務(wù)的業(yè)務(wù)邏輯關(guān)聯(lián)性就大多了，如果是純SQL交互的系統(tǒng)，通過解析腳本等方式，從外部去管理授權(quán)行為有時是可行的，其它情況，通常都要侵入到具體服務(wù)的內(nèi)部邏輯中才有可能實現(xiàn)權(quán)限的控制邏輯。

所以Sentry和Ranger都是通過Hook具體后臺服務(wù)的流程框架，深度侵入代碼，添加授權(quán)驗證邏輯的方式來實現(xiàn)權(quán)限管控的，只不過具體的權(quán)限管理相關(guān)數(shù)據(jù)的存儲，查詢，管理工作實際是對接到外部獨立的系統(tǒng)中承接實現(xiàn)的，進而實現(xiàn)各種存儲計算集群權(quán)限的統(tǒng)一管理。

要Hook具體后臺服務(wù)的流程框架，最理想的是原系統(tǒng)本身就提供插件式的權(quán)限管理方案可供擴展，否則就需要對原系統(tǒng)進行針對性的改造，另外各個系統(tǒng)自身既有的權(quán)限模型也未必能滿足或匹配Sentry和Ranger所定義的統(tǒng)一權(quán)限管理模型，是否能改造本身就是個問題。

加上權(quán)限驗證流程通過查詢外部服務(wù)實現(xiàn)，因此在權(quán)限的同步，對原系統(tǒng)的性能影響等方面常常也需要小心處理或者針對性的優(yōu)化。因此，統(tǒng)一的授權(quán)管理平臺這一目標(biāo)也是一個浩大的工程。所以至今無論Sentry還是Ranger都未能全面覆蓋Hadoop生態(tài)系中常見的計算存儲框架。

小結(jié)

總體來說，授權(quán)這件事，Hadoop生態(tài)系中的各個組件往往會有自己獨立的解決方案，但是各自方案之間的連通性并不好。而統(tǒng)一的授權(quán)管理框架／平臺的目標(biāo)就是解決這個問題，但它們當(dāng)前也不算很成熟，特別是在開放性和定制性上，往往也有一定局限性。

當(dāng)然，要用一個框架徹底打通所有組件的權(quán)限管理工作，除了插件化，其它其實也沒有特別好的方式，而插件化自然需要框架和具體組件的雙向合作努力。只能說就當(dāng)前發(fā)展階段而言，這一整套方案尚未足夠成熟，沒到完美的程度，也沒有事實統(tǒng)一的標(biāo)準(zhǔn)。所以無論是Sentry還是Ranger，當(dāng)前的實現(xiàn)如果剛好適合你的需求自然最好，如果不適合，那還需要自己再想辦法，且看他們將來的發(fā)展吧。

Knox

最后來說一下Knox項目，它的思想是通過對Hadoop生態(tài)系的組件提供GateWay的形式來加強安全管控，你可以近似的認為他就是一個Rest／HTTP的服務(wù)代理/防火墻。

所有用戶對集群的Rest／HTTP請求都通過Knox代理轉(zhuǎn)發(fā)，既然是代理，那么就可以在轉(zhuǎn)發(fā)的過程中做一些身份認證，權(quán)限驗證管理的工作，因為只針對Rest／HTTP服務(wù)，所以他并不是一個完整的權(quán)限管理框架

使用Gateway的模式有很大的局限性，比如單點，性能，流程等等，不過對于Rest／HTTP的場景倒也算是匹配。它的優(yōu)勢是通過收攏Hadoop相關(guān)服務(wù)的入口，可以隱藏Hadoop集群的拓撲邏輯，另外，對于自身不支持權(quán)限認證管理的服務(wù)，通過Gateway也能自行疊加一層權(quán)限管控。

開源項目中常見的權(quán)限模型概念：RBAC ／ ACL ／ POSIX ／ SQL Standard

如果去閱讀各種開源組件的權(quán)限架構(gòu)相關(guān)文檔，談到權(quán)限模型時，你往往會看到各種各樣的名詞稱謂，比如RBAC，ACL，POSIX， SQL Standard 等等。

嚴(yán)格來說，這些概念的內(nèi)容并不是對等的，或者說他們描述的問題有時候并不是同一個范疇的內(nèi)容，不適合直接拿來對比。

但是，實際環(huán)境中，各個系統(tǒng)在為他們的權(quán)限模型或者思想概念起名的時候，往往也并不真的完全和這些名詞的所謂學(xué)術(shù)或標(biāo)準(zhǔn)上的定義相匹配，所以我在這里討論這些概念的時候，也不打算追求絕對的精確，只是借這些名詞，泛泛的談一下其背后的思想，目標(biāo)以及在平臺建設(shè)過程中值得我們關(guān)注的點。

首先來看RBAC模型，RBAC從標(biāo)準(zhǔn)規(guī)范的角度來看，絕對是一個復(fù)雜的標(biāo)準(zhǔn)，但是實際情況下，各種開源系統(tǒng)在討論RBAC的時候，通常重點指的就是權(quán)限和用戶之間需要通過角色的概念進行一次二次映射，目的是為了對同類權(quán)限或同類用戶進行歸類，減少需要維護的映射關(guān)系的數(shù)量。至于RBAC理論層面上各種層級的約束，條件，規(guī)范等等，其實談得很少。

而在其它模型中，也或多或少有組/角色的概念，只是比如：組的涵蓋范圍，是否允許存在多重歸屬，能否交叉，能否嵌套，是否允許用戶和權(quán)限直接掛鉤等具體規(guī)則上有所區(qū)別。不過基本上，如果你要宣稱自己是一個RBAC模型的話，那么基本上還是要重點強調(diào)角色模型和映射關(guān)系的建設(shè)。而在其它模型中，組/角色的概念相對來說可能并沒有那么突出或者重要。

然后談POSIX的權(quán)限模型，談這個，當(dāng)然是因為HDFS的文件權(quán)限模型，很長一段時間以來，只支持POSIX標(biāo)準(zhǔn)文件的權(quán)限管理模型，即一個文件對應(yīng)一個OWNER和一個GROUP，對OWNER和GROUP以及其它用戶配置RWAC這樣的讀寫通過管理等權(quán)限。

POSIX模型很直白，很容易理解，實現(xiàn)也簡單，但POSIX模型最大的問題是文件的共享很難處理。因為要將權(quán)限賦予一撥人，只能通過單一固定的組的概念，你無法針對不同的人群和不同的文件進行分組授權(quán)，所以很難做到精細化的授權(quán)管理。

為了解決權(quán)限多映射精細管理問題，HDFS又引入了ACL模型，Access Control List，故名思意，就是針對訪問對象，有一個授權(quán)列表。那么對不同對象給不同用戶賦予不同的權(quán)限也就不成問題了。當(dāng)然，HDFS的ACL模型也不是范本，事實上各種系統(tǒng)中所謂的ACL模型，具體設(shè)計都不盡相同，唯一可能共通的地方就是：對訪問對象賦予一個授權(quán)列表這個概念，而不是像POSIX這樣固定分類的授權(quán)模式。

ACL模型理論上看起來很理想，但在HDFS集群這個具體場景中，麻煩的地方在于如果集群規(guī)模比較大，授權(quán)列表的數(shù)量可能是海量的，性能，空間和效率上都可能成為問題，而事實上，ACL對象精細化的管理也并不那么容易。當(dāng)然這些也并不能算是ACL模型自身的問題，更多的是具體的實現(xiàn)和上層業(yè)務(wù)規(guī)劃方面的問題。

最后所謂的SQL標(biāo)準(zhǔn)的權(quán)限模型，從模型的角度來說和ACL模型并沒有什么本質(zhì)的區(qū)別，只不過是在類SQL語法的系統(tǒng)中，模仿了Mysql等傳統(tǒng)數(shù)據(jù)庫中標(biāo)準(zhǔn)的授權(quán)語法來與用戶進行交互。具體的實現(xiàn)例子，比如Hive Server2中支持的SQL標(biāo)準(zhǔn)授權(quán)模型

基于開發(fā)平臺服務(wù)入口的權(quán)限管控思路

了解了相關(guān)的解決方案和思路，在我們自己的大數(shù)據(jù)平臺的權(quán)限管理方案的實施過程中，不管是全面使用開源方案，還是局部混搭，又或者是完全自行構(gòu)建，我們都可以從身份認證與授權(quán)管理，集中式管控與Gateway邊界管理等角度來拆解，思考和分析問題，尋找適合自身業(yè)務(wù)場景的整合方案。

我司的整體思路，是盡可能通過構(gòu)建產(chǎn)品化的大數(shù)據(jù)開發(fā)平臺，將各種集群以服務(wù)的形式對外提供，換句話說，類似于上述Gateway的思想（但不是knox這種http代理），盡可能讓用戶通過開發(fā)平臺來提交任務(wù)，管理數(shù)據(jù)，而不是直接通過API連接集群。

當(dāng)所有的用戶都通過開發(fā)平臺來和集群進行交互時，開發(fā)平臺就具備了統(tǒng)一的用戶身份認證和權(quán)限管理的基礎(chǔ)前提條件。當(dāng)然實際情況并沒有那么理想，不管是出于技術(shù)原因，實現(xiàn)代價原因，程序效率性能原因，還是業(yè)務(wù)流程原因，總會有些業(yè)務(wù)流程和任務(wù)無法通過開發(fā)平臺來統(tǒng)一管控。這時候就需要結(jié)合其它方案來彌補了。

以HDFS集群的文件讀寫的權(quán)限認證為例，大部分涉及到HDFS文件讀寫的任務(wù)，比如Hive/Presto/SparkSQL等相關(guān)任務(wù)，如果我們管控了這些任務(wù)作業(yè)的提交入口，相關(guān)的集群由我們提供，那么多數(shù)權(quán)限管控工作我們都是能夠在開發(fā)平臺層面完成管控的。

但還有很大一部分需要讀寫HDFS數(shù)據(jù)的業(yè)務(wù)，自身并不運行在大數(shù)據(jù)開發(fā)平臺提供的服務(wù)上。比如內(nèi)網(wǎng)的簡歷系統(tǒng)需要存取簡歷，商家的證照文件需要備份，廣告的算法模型，特征數(shù)據(jù)需要在各個子系統(tǒng)間傳輸?shù)鹊?，這些業(yè)務(wù)的程序可能是自行開發(fā)的，調(diào)用入口也并不在大數(shù)據(jù)開發(fā)平臺上，所以開發(fā)平臺也就很難對其進行用戶身份認證。

而Hadoop的客戶端，除了Kerberos方案，剩下的Simple認證方案，實際上并不真正識別用戶的身份（比如你只需要通過環(huán)境變量設(shè)置宣稱自己是用戶A，Hadoop就允許你操作用戶A的數(shù)據(jù)）。那么不上Kerberos就沒法處理了么？

也不完全如此，如果用戶的需求是簡單的文件存儲工作，那么我們可以考慮通過對象存儲服務(wù)的方式來支持，用戶身份的認證在對象存儲服務(wù)中實現(xiàn)，由對象存儲服務(wù)代理用戶在HDFS集群上進行文件讀寫操作。但如果用戶就是需要靈活的Posix模式的文件讀寫服務(wù)，那顯然，就要在HDFS自身服務(wù)方面動腦筋了。是封裝客戶端還是改造服務(wù)端，取決于具體的安全需求程度和實現(xiàn)代價

基于服務(wù)端的改造通常對用戶的透明性好一些，安全性也更強一些（因為別人可以不用你封裝好的客戶端。當(dāng)然，也可以在服務(wù)端加上客戶端的ID識別之類的工作來加強防范）。比如，如果我們相信業(yè)務(wù)方自己不會濫用賬號，我們的目的只是防止各個業(yè)務(wù)方之間無意的互相干擾和誤操作，那么在服務(wù)端進行用戶身份和IP來源的綁定鑒定（即特定用戶只能由特定IP的機器使用），結(jié)合Hadoop自身的Posix文件權(quán)限管理模式，基本就能達到目的。當(dāng)然，服務(wù)端的管控還可以想到更多的其它方案，這就需要結(jié)合你的業(yè)務(wù)環(huán)境，運維成本和技術(shù)代價等進行判斷選擇了。

再比較一下底層統(tǒng)一權(quán)限管控平臺和基于開發(fā)平臺進行邊界權(quán)限管控的優(yōu)缺點

首先，Ranger等方案，主要依托大數(shù)據(jù)組件自身的方案，Hook進執(zhí)行流程中，所以管控得比較徹底，而開發(fā)平臺邊界權(quán)限管控，前提是需要收攏使用入口，所以論絕對安全性，如果入口收不住，那么不如前者來得徹底。不過通常來說，為用戶提供統(tǒng)一的服務(wù)入口，不光是安全的需要，也是開發(fā)平臺提高自身服務(wù)化程度和易用性的必要條件。

其次，底層權(quán)限統(tǒng)一管控平臺，因為依托的是大數(shù)據(jù)組件自身的方案，并不收攏用戶交互入口，所以身份認證環(huán)節(jié)還是需要依托類似Kerberos這樣的系統(tǒng)來完成。而開發(fā)平臺服務(wù)方式，收攏了入口，就可以用比較簡單方式自行完成身份認證，如前所述，相比涉及到三方交互的分布式身份認證機制，通常實現(xiàn)代價會更低一些。

再次，大數(shù)據(jù)組件自身的權(quán)限方案，權(quán)限驗證環(huán)節(jié)通常發(fā)生在任務(wù)實際執(zhí)行的過程中，所以流程上基本都是在沒有權(quán)限的時候拋出一個異?；蚍祷劐e誤，因此不太可能根據(jù)業(yè)務(wù)場景做更加靈活的處理。

而開發(fā)平臺服務(wù)方式，權(quán)限的驗證如果可以做到在執(zhí)行前階段（比如通過語法分析獲得）進行，那么流程上就可以靈活很多，可以結(jié)合業(yè)務(wù)相關(guān)信息提供更豐富的調(diào)控手段。

例如，業(yè)務(wù)開發(fā)過程中，在代碼編輯或保存時就可以進行相關(guān)權(quán)限驗證和提示，避免在半夜任務(wù)實際執(zhí)行時才發(fā)現(xiàn)問題。也可以定期批量審計腳本任務(wù)，或者根據(jù)業(yè)務(wù)重要程度對缺乏權(quán)限的情況進行區(qū)別對待：提示，警告，阻斷等等。簡單的說，就是你想怎么做就怎么做。而Ranger等基于底層組件進行Hook的權(quán)限架構(gòu)方案，一來沒有相關(guān)業(yè)務(wù)信息無法做出類似決策，二來考慮通用性，很多平臺環(huán)境相關(guān)業(yè)務(wù)邏輯不可能也不適合綁定進來。

當(dāng)然，這兩種方案并不是互斥的，如何定義你的產(chǎn)品，如何拆分各種需求，對你選擇權(quán)限管控方案也有很大的影響。更常見的情況是，你會需要一個混合體，取長補短，彌補各自的不足之處。

小結(jié)

總體來說，在開發(fā)平臺上進行邊界權(quán)限管控，并不是因為這種方式更安全，而是因為它更靈活，與業(yè)務(wù)和流程的兼容適配性更好，對底層組件自身權(quán)限管控能力的依賴性也更小。甚至還可以根據(jù)業(yè)務(wù)邏輯針對性定制權(quán)限管控策略，但是因為自身通常并不深度Hook具體組件內(nèi)部執(zhí)行邏輯，所以部分場景可能無法有效的進行管控（比如二進制代碼任務(wù)無法從外部解析其讀寫邏輯），就需要和底層組件權(quán)限管控方案結(jié)合起來實施。

換個角度來說，這也是在開發(fā)平臺的產(chǎn)品化過程中，很多任務(wù)我們會希望盡可能SQL化／腳本化／配置化的推動動力之一。一方面SQL化／腳本化／配置化有助于降低用戶的開發(fā)成本，可以做一些系統(tǒng)層面的自動優(yōu)化，沉淀知識和最佳實踐。另一方面，有了可供解析語義的文本，也便于根據(jù)語義進行權(quán)限管理，盡可能完善平臺邊界權(quán)限管控的能力和范圍。