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

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

實際上却桶，如果真正接觸過這方面的工作內容境输，你很快就會發(fā)現，不論是在技術層面還是在產品層面颖系，大數據平臺環(huán)境下的權限管理工作都是一個讓人傷腦筋的燙手山芋嗅剖，它不僅僅是一個技術問題，還是一個業(yè)務問題嘁扼，甚至還可能是一個人際溝通和權衡利益得失的哲學問題信粮。。趁啸。

所以强缘，以下內容分兩部分展開，先談哲學問題不傅，再談技術問題旅掂。

權限管理的目標是什么？

討論問題之前访娶，先討論目標商虐，為什么要做權限管理，要做到什么程度崖疤？

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

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

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

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

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

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

• 權責明晰震檩，規(guī)范業(yè)務流程

以下分別闡述一下

適度安全琢蛤，降低人為風險

最直觀的目的就是安全，但是抛虏，安全這個目標博其，如果從Security的角度來說，從來都沒有終點迂猴，做到什么程度才算安全慕淡？這顯然和你的業(yè)務環(huán)境有關，如果事關國家最高安全機密沸毁，比如核彈發(fā)射什么的峰髓，當然怎么做都不過分。

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

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

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

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

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

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

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

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

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

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

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

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

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

比如你作為個人测萎，會有自己開發(fā)和負責的業(yè)務，但是你也往往希望一個團隊內部的成員能共同負責部分業(yè)務梁钾，或者團隊的Leader能管理團隊內部所有成員的業(yè)務绳泉。又或者你作為一個業(yè)務的上下游利益相關方，你希望能夠訂閱相關業(yè)務的數據姆泻，作為系統管理員零酪，你希望能夠在必要的時候對任何作業(yè)或數據都能進行干預冒嫡。同一個用戶在不同的場景中可能承擔不同的角色，或者同時擁有這些角色中的多個四苇⌒⒘瑁總之，與用戶相關的小環(huán)境月腋，往往并不那么容易清晰的定義蟀架。

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

權責明晰，規(guī)范業(yè)務流程

權限管理污筷，從一個角度看是禁止用戶做不該做的事工闺，但從另一個角度看是授予用戶能做某件事的權利。如果你認為這是一個權力瓣蛀，那么伴隨著權力的授予斤寂，我們當然希望同時做到責任的明晰。平臺的權限管理如果只能靠系統管理員來承擔揪惦，當規(guī)模小遍搞，業(yè)務環(huán)境簡單的時候問題不大，當系統和業(yè)務都變得復雜的時候器腋，就很難維系了溪猿。

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

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

小結

權限管理的目標荐吉，絕對不是簡單的在技術層面建立起用戶，密碼和權限點的映射關系這么簡單的事口渔，更重要的是要從流程合理性稍坯，業(yè)務隔離，實施代價搓劫，可執(zhí)行性等方面進行考慮。單方面強調安全混巧，結果往往并不理想枪向。

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

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

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

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

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

天生矛盾

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

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

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

再退一步說漫玄，你的用戶也有可能是一個理智的用戶茄蚯，他可能認同安全的重要性，但是在代價方面的看法上睦优，也往往可能會與你相左渗常。用戶很可能希望又安全，又便利汗盘，對他還沒有代價皱碘，如果有，最好是由實施方來承擔代價衡未，簡單來說，就是安全我認同家凯，但別給我來事缓醋。

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

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

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

改變角度，轉移目標

既然天生矛盾荡短，那么丐枉，能否轉移矛盾？有時候掘托，瞞天過菏萸拢或許是一個可行的方案。怎么解釋呢闪盔？如前所說弯院，開發(fā)平臺安全管控目標的達成，各種權限的約束和限制固然是必要的泪掀，但同時听绳，流程的規(guī)范，產品交互設計的改進和業(yè)務的合理規(guī)劃在達成這個目標的過程中其實也是同等重要的异赫，而這些工作椅挣，不光有助于提升安全性，往往也有助于改進和提升用戶在平臺上的產品體驗和工作效率塔拳。

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

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

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

把握尺度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可能的變通措施

客觀藕溅，嘴上說容易，實際操作起來继榆，卻很難巾表。不是因為你不想客觀略吨，而是因為事情是復雜的集币，正反面因素往往同時都有河质，你可能堅持其中一面冀惭，而忽視另外一面。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉個簡單的例子足淆，比如一個報表系統，你顯然應該通過權限管控礁阁，讓用戶無法看到敏感報表的數據巧号。但是我經常看到在一些類似系統的設計中姥闭，用戶上來連報表列表都沒法查看丹鸿，給用戶哪些報表權限，完全由管理員來配置棚品，用戶在這個過程中卜高，能做什么？只能完全靠問啊南片，有什么報表靠問掺涛，報表內容是什么靠問，找誰開通權限靠問疼进，什么時候開通權限靠問薪缆。。。

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

更合理的做法可霎，或許應該是通過構建報表的元數據信息管理魄鸦，將這些非敏感信息透明化，區(qū)別對待癣朗。即使沒有權限拾因，用戶也應該能獲取到相關報表的基本信息。比如能夠查詢到完整的報表列表旷余，能夠查看報表的業(yè)務描述绢记，字段信息，負責人正卧，變更記錄庭惜，訂閱情況，業(yè)務歸屬關系等等穗酥，并且能夠直接在系統上對相關報表主動發(fā)起權限申請护赊。

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

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

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

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

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

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

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

因此颁虐，有時候我們會發(fā)現蛮原，在一些系統中開發(fā)了相應的功能以后，用戶依然有很多的抱怨另绩。所以難道是用戶都這么不耐煩儒陨？真的有那么多的事情火急火燎，需要立刻完成笋籽，一刻都耽擱不了蹦漠？

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

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

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

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

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

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

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

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

避免火燒眉毛

用戶抱怨影響工作效率的場景，流程的絕對響應時間有時往往可能不一定是問題蚁孔，更多時候奶赔，是因為一個開發(fā)流程被打斷，或者一件事情事到臨頭了才來處理杠氢，這時候站刑，流程上的等待，可能影響心情鼻百，可能影響效率绞旅，也可能導致問題無法及時解決°邓危總之玻靡，抱怨的源頭不在于等待流程本身结榄，問題在于在不能等中贝，不想等的時候，卻需要等臼朗。

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

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

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

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

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

自動化淮捆，智能化

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

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

比如你創(chuàng)建了一個腳本任務棘街，這個任務的腳本的讀寫權限自然應該是屬于你的蟆盐。但是光酣，我們可能還要考慮下列問題：

• 和你同一個業(yè)務組的同學是否需要自動授權奋姿，需要授予什么權限？如果不想自動授權秒赤，流程上又該如何區(qū)別险污？如果你參與了多個業(yè)務組痹愚，如何判斷該腳本的歸屬關系？

• 這個腳本創(chuàng)建的表蛔糯，寫出的數據拯腮，產生的內容，該如何授權渤闷，要不要授權疾瓮？這并不簡單，因為任務權限的管理和數據權限的管理飒箭，可能是由不同的系統負責的狼电，需要跨系統創(chuàng)建授權關系蜒灰，而各系統的權限管理體系，業(yè)務分組等等也可能并不一致肩碟。

• 如果相關數據被同步或復制到其它系統中强窖，又該如何同步權限？同構體系的同步問題不大削祈，比如DB主從翅溺，集群備份之類。但異構的數據匯總髓抑，采集咙崎。傳輸之后的權限。比如hive里面的數據導出到報表系統展示吨拍，業(yè)務模型都不一樣了褪猛，那么任務，數據羹饰，報表之間的權限關系又該如何映射伊滋，能否需要同步，是否能夠同步队秩？

上訴問題只是舉例說明自動化和智能化可能需要解決的問題笑旺，在你的系統中，上訴問題可能不重要馍资，或者也并不一定適合自動授權筒主。但總體來說，自動化和智能化的問題迷帜，難點不在于技術的實現物舒，難點在于業(yè)務邏輯上如何確定可行的自動化和智能化的規(guī)則色洞。

如果你的業(yè)務流程沒有明確的規(guī)范戏锹，業(yè)務內容缺乏歸屬關系的梳理，系統之間交互關系不明晰火诸，數據血緣關系難以梳理锦针，那么自動化，智能化的工作就很難進行置蜀。所以奈搜，與其說這是一個權限管控智能化的工作，不如說更多的是一個數據治理的工作盯荤。

總結

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

你需要通過用戶引導绍哎，方案變通来农，流程規(guī)劃，價值轉移等方式來降低實施的成本和代價崇堰，提升最終的實際收益沃于，否則，靠“安全最大”這個尚方寶劍來推動工作是沒問題海诲，但用戶的抱怨和不配合也一定也會讓你的頭很大繁莹，很大。特幔。蒋困。

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

從基本的流程來說嵌牺，確實如此，所以比如早幾年前龄糊，我司從內部運營系統到到外部業(yè)務系統逆粹，各種大大小小的后臺，一言不合炫惩，就會自己實現一套權限認證管理的方案僻弹。說到底，不就是兩張表的事么他嚷，這有何難蹋绽。。筋蓖。

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

不過卸耘，當系統越來越多，環(huán)境越來越復雜時粘咖，你就會發(fā)現這件事并沒有那么簡單蚣抗。拋開技術問題不談，單從用戶體驗的角度來說瓮下，如果要在每個系統中都單獨管理自己的用戶賬號和密碼翰铡，那肯定瘋掉了设哗。所以，最起碼你需要一個統一的用戶賬號體系两蟀。

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

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

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

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

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

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

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

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

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

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

常見開源方案

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

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

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

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

Kerberos

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

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

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

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

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

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

然后踪旷，用戶將這部分信息轉發(fā)給具體的后臺服務器曼氛，后臺服務器接收到這個信息后，用自己的秘鑰解密得到經過Kerberos服務認證過的用戶信息令野，再和發(fā)送給他這個信息的用戶進行比較舀患，如果一致，就可以認為用戶的身份是真實的气破，可以為其服務聊浅。

核心思想

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

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

應用Kerberos的難點在哪

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

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

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

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

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

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

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

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

小結

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

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

Sentry和Ranger

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

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

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

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

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

小結

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

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

Knox

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

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

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

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

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

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

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

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

而在其它模型中轰坊，也或多或少有組/角色的概念铸董，只是比如：組的涵蓋范圍，是否允許存在多重歸屬肴沫，能否交叉愿卒，能否嵌套搞挣，是否允許用戶和權限直接掛鉤等具體規(guī)則上有所區(qū)別。不過基本上元媚，如果你要宣稱自己是一個RBAC模型的話鹦肿，那么基本上還是要重點強調角色模型和映射關系的建設蜜自。而在其它模型中揽祥，組/角色的概念相對來說可能并沒有那么突出或者重要哪亿。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先疮茄，Ranger等方案滥朱，主要依托大數據組件自身的方案，Hook進執(zhí)行流程中娃豹，所以管控得比較徹底焚虱，而開發(fā)平臺邊界權限管控，前提是需要收攏使用入口懂版，所以論絕對安全性鹃栽，如果入口收不住，那么不如前者來得徹底躯畴。不過通常來說民鼓，為用戶提供統一的服務入口，不光是安全的需要蓬抄，也是開發(fā)平臺提高自身服務化程度和易用性的必要條件丰嘉。

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

再次砰识，大數據組件自身的權限方案，權限驗證環(huán)節(jié)通常發(fā)生在任務實際執(zhí)行的過程中佣渴，所以流程上基本都是在沒有權限的時候拋出一個異潮枥牵或返回錯誤，因此不太可能根據業(yè)務場景做更加靈活的處理观话。

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

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

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

小結

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

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