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

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

實際上，如果真正接觸過這方面的工作內容，你很快就會發現，不論是在技術層面還是在產品層面，大數據平臺環境下的權限管理工作都是一個讓人傷腦筋的燙手山芋，它不僅僅是一個技術問題，還是一個業務問題，甚至還可能是一個人際溝通和權衡利益得失的哲學問題。。。

所以，以下內容分兩部分展開，先談哲學問題，再談技術問題。

權限管理的目標是什么？

討論問題之前，先討論目標，為什么要做權限管理，要做到什么程度？

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

從技術的角度來說，用戶說的也沒錯，權限管理過程的本質，就是通過某些技術手段來限制用戶的可能行為，其結果就是用戶不能為所欲為 ；）

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

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

• 適度安全，降低人為風險

• 隔離環境，提高工作效率

• 權責明晰，規范業務流程

以下分別闡述一下

適度安全，降低人為風險

最直觀的目的就是安全，但是，安全這個目標，如果從Security的角度來說，從來都沒有終點，做到什么程度才算安全？這顯然和你的業務環境有關，如果事關國家最高安全機密，比如核彈發射什么的，當然怎么做都不過分。

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

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

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

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

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

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

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

隔離環境，提高工作效率

所謂隔離，從用戶的角度來說，就是將業務進行分拆，比如在數據平臺整體大環境中，制造出一個只和當前用戶的自身業務相關的小環境。

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

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

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

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

比如你作為個人，會有自己開發和負責的業務，但是你也往往希望一個團隊內部的成員能共同負責部分業務，或者團隊的Leader能管理團隊內部所有成員的業務。又或者你作為一個業務的上下游利益相關方，你希望能夠訂閱相關業務的數據，作為系統管理員，你希望能夠在必要的時候對任何作業或數據都能進行干預。同一個用戶在不同的場景中可能承擔不同的角色，或者同時擁有這些角色中的多個。總之，與用戶相關的小環境，往往并不那么容易清晰的定義。

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

權責明晰，規范業務流程

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

所以，權限管理的理想的模式是，能夠將權力和責任同時下放到相關的責任團隊中去，實現業務的自治管理。一方面是為了降低平臺的日常管理代價，另一方面，更重要的是通過授權，明確責任人，讓每個任務，每個數據都有明確的業務和團隊歸屬。

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

小結

權限管理的目標，絕對不是簡單的在技術層面建立起用戶，密碼和權限點的映射關系這么簡單的事，更重要的是要從流程合理性，業務隔離，實施代價，可執行性等方面進行考慮。單方面強調安全，結果往往并不理想。

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

重要的通過適度的安全管理手段，降低業務誤操作的風險，結合業務流程和系統交互設計，實現業務的合理分隔，提高工作效率，同時將權限管理工作分級授權下放到業務負責人和團隊，實現業務自治管理，明晰責任歸屬，讓權限管理充分發揮其促進業務健康安全發展的作用，而不是相反。

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

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

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

天生矛盾

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

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

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

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

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

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

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

改變角度，轉移目標

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

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

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

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

把握尺度

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

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

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

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

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

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

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

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

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

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

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

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

4\. 相關權限管控措施，是否只是有利于安全？

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

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

可能的變通措施

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

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

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

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

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

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

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

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

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

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

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

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

如果沒法變通，那只好低調做人，少惹麻煩。

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

• 不知道有什么權限可申請？在哪申請？找誰申請？

• 權限審批流程，響應慢，沒人管，不知道進度

• 總感覺流程復雜，沒必要，影響開發效率

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

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

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

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

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

舉個簡單的例子，比如一個報表系統，你顯然應該通過權限管控，讓用戶無法看到敏感報表的數據。但是我經常看到在一些類似系統的設計中，用戶上來連報表列表都沒法查看，給用戶哪些報表權限，完全由管理員來配置，用戶在這個過程中，能做什么？只能完全靠問啊，有什么報表靠問，報表內容是什么靠問，找誰開通權限靠問，什么時候開通權限靠問。。。

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

更合理的做法，或許應該是通過構建報表的元數據信息管理，將這些非敏感信息透明化，區別對待。即使沒有權限，用戶也應該能獲取到相關報表的基本信息。比如能夠查詢到完整的報表列表，能夠查看報表的業務描述，字段信息，負責人，變更記錄，訂閱情況，業務歸屬關系等等，并且能夠直接在系統上對相關報表主動發起權限申請。

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

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

能否降低權限申請煩躁指數？

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

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

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

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

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

能否減少需要申請的權限數量？

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

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

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

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

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

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

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

避免火燒眉毛

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

所以，有時候在系統方案設計過程中，也應該思考一下，能否通過合理的產品和流程設計，減少或避免火燒眉毛的問題出現？

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

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

再比如，你可以通過事先規范權限應用規則的方式，讓業務在開發相關工作前，就先申請好與自己相關的權限通道。將權限的申請提前到業務準入階段，而不是業務開發階段，避免在開發過程中實際要測試任務的時候再來補權限。

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

自動化，智能化

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

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

比如你創建了一個腳本任務，這個任務的腳本的讀寫權限自然應該是屬于你的。但是，我們可能還要考慮下列問題：

• 和你同一個業務組的同學是否需要自動授權，需要授予什么權限？如果不想自動授權，流程上又該如何區別？如果你參與了多個業務組，如何判斷該腳本的歸屬關系？

• 這個腳本創建的表，寫出的數據，產生的內容，該如何授權，要不要授權？這并不簡單，因為任務權限的管理和數據權限的管理，可能是由不同的系統負責的，需要跨系統創建授權關系，而各系統的權限管理體系，業務分組等等也可能并不一致。

• 如果相關數據被同步或復制到其它系統中，又該如何同步權限？同構體系的同步問題不大，比如DB主從，集群備份之類。但異構的數據匯總，采集。傳輸之后的權限。比如hive里面的數據導出到報表系統展示，業務模型都不一樣了，那么任務，數據，報表之間的權限關系又該如何映射，能否需要同步，是否能夠同步？

上訴問題只是舉例說明自動化和智能化可能需要解決的問題，在你的系統中，上訴問題可能不重要，或者也并不一定適合自動授權。但總體來說，自動化和智能化的問題，難點不在于技術的實現，難點在于業務邏輯上如何確定可行的自動化和智能化的規則。

如果你的業務流程沒有明確的規范，業務內容缺乏歸屬關系的梳理，系統之間交互關系不明晰，數據血緣關系難以梳理，那么自動化，智能化的工作就很難進行。所以，與其說這是一個權限管控智能化的工作，不如說更多的是一個數據治理的工作。

總結

權限管理工作，不是簡單的安全問題，更多的時候，它是一個產品設計和業務治理的理念和目標問題。實現權限的管控往往并不難，難的是如何盡量減少人為參與權限管控的必要性。

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

上篇我們討論了權限管控方案在目標，產品形態，實施方式方面的哲學問題，接下來，討論一下技術方面的問題。你可能會想，如果不需要防止Hack的行為，那應該也不是什么很困難的事吧？

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

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

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

然后，如果各個系統的權限申請，管理，審批流程都不一樣，系統開發和用戶學習的成本會不會很高？于是，你又會考慮除了賬號密碼以外，各個后臺的權限管理模型也應該統一。

而具體落到大數據平臺的環境下來討論權限管理問題，相比多數以功能操作為導向的業務系統，通常又會更加復雜一些。因為大數據開發環境的特點，除了用戶個人的操作權限管理，你還需要考慮：

• 用戶協同工作時的數據共享問題

• 各種存儲，計算，查詢框架之間數據互通串聯的能力

• 數據的敏感程度不同，對安全等級的區分和管控粒度的要求

• 分布式的集群場景，海量的數據對象，對權限管控流程的性能，效率，可維護性的要求

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

• 數據的流動性本質，對權限的動態變更能力的需求

• 各個組件自身架構在權限管控這塊的實現可能千差萬別，如何統一和簡化的問題

所有這些因素都會大數據平臺環境下的權限管控工作變得愈發的困難和復雜。

常見開源方案

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

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

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

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

Kerberos

Kerberos是Hadoop生態系中應用最廣的集中式統一用戶認證管理框架。

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

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

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

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

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

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

核心思想

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

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

應用Kerberos的難點在哪

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

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

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

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

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

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

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

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

小結

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

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

Sentry和Ranger

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

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

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

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

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

小結

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

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

Knox

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

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

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

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

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

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

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

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

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

然后談POSIX的權限模型，談這個，當然是因為HDFS的文件權限模型，很長一段時間以來，只支持POSIX標準文件的權限管理模型，即一個文件對應一個OWNER和一個GROUP，對OWNER和GROUP以及其它用戶配置RWAC這樣的讀寫通過管理等權限。

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

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

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

最后所謂的SQL標準的權限模型，從模型的角度來說和ACL模型并沒有什么本質的區別，只不過是在類SQL語法的系統中，模仿了Mysql等傳統數據庫中標準的授權語法來與用戶進行交互。具體的實現例子，比如Hive Server2中支持的SQL標準授權模型

基于開發平臺服務入口的權限管控思路

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

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

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

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

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

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

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

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

再比較一下底層統一權限管控平臺和基于開發平臺進行邊界權限管控的優缺點

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

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

再次，大數據組件自身的權限方案，權限驗證環節通常發生在任務實際執行的過程中，所以流程上基本都是在沒有權限的時候拋出一個異常或返回錯誤，因此不太可能根據業務場景做更加靈活的處理。

而開發平臺服務方式，權限的驗證如果可以做到在執行前階段（比如通過語法分析獲得）進行，那么流程上就可以靈活很多，可以結合業務相關信息提供更豐富的調控手段。

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

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

小結

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

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