權限管理，就是解決 “Who對What(Which)進行How的操作” 問題。
在 2B產品的用戶角色設計思路 一文中，著重探討了在整個系統(tǒng)中，用戶和角色的關系，并基于業(yè)務過程對角色進行了場景的細分，并詳細的解釋了為什么要在做產品原型設計之前分析業(yè)務角色，設計各個角色的關系。
本文則討論如何基于用戶角色進行權限管理。
權限管理的基本概念
系統(tǒng)的權限管理，簡單的說就是針對不同身份的用戶設置不同級別的訪問、請求和處理數(shù)據(jù)的范圍級別。考慮的是企業(yè)的數(shù)據(jù)安全和信息隱私問題。
對2B的產品而言，必須充分考慮到業(yè)務的復雜性和擴展性，使得產品的業(yè)務管理和控制權限能夠隨著業(yè)務和組織架構的發(fā)展而快速部署，需要特別注意的是，不同的業(yè)務形態(tài)、不同的管理機制，都會給權限系統(tǒng)的設計帶來重要影響。
這也是為什么2B的產品難以標準化的一個因素——業(yè)務的獨特性和（管理）文化的獨特性。
權限管理，本質上是對用戶，以及用戶的行為的范圍控制，通過一種巧妙的設計，約束不同身份的用戶在系統(tǒng)上的操作路徑和操作權限。這里涉及到三個關鍵問題：
1、用戶與角色
用戶，指的是真實“人”，是系統(tǒng)上每一個具體的操作實體(系統(tǒng)的一個賬號)，而角色這是一個抽象概念。比如管理員是一個角色，一個系統(tǒng)可以配置多個管理員賬戶。
這里還需要區(qū)別一個概念：業(yè)務角色和權限角色。
業(yè)務角色是針對業(yè)務過程的抽象，而權限系統(tǒng)的角色，則是對管理過程的抽象。兩種之間存在一定的相關性，多數(shù)情況下業(yè)務角色是可以直接對應為系統(tǒng)的權限角色。
2、行為與資源
用戶在系統(tǒng)上的行為，可歸納為兩類：
- 數(shù)據(jù)權限：可以查看、操作的數(shù)據(jù)范圍，比如部經理可以查看整個部門的業(yè)務數(shù)據(jù)，而員工只可以查看個人的數(shù)據(jù)
- 功能權限：對系統(tǒng)資源（頁面、菜單、按鈕等）的查看、操作權限，比如某個菜單的可見性
3、關系管理
考慮的是整個組織的管理架構，是一對一還是一對多關系，是否有層級劃分，是否有繼承關系等。
從這三個關鍵詞中，我們就能理解整個權限管理，解決的就是某個用戶在訪問系統(tǒng)時，可以查看什么內容，執(zhí)行什么操作，得到什么結果。
也就是權限控制系統(tǒng)，管理的是用戶行為的集合，也就是建立一套用戶使用資源的規(guī)則。
這個集合來自于產品的“用戶畫像”，用戶擁有的系統(tǒng)資源即可通過標簽系統(tǒng)來進行分類管理。
在實際應用中，特別是平臺型產品，權限的管理非常嚴格，同時也非常復雜。比如一個O2O平臺有1000個門店就很難通過創(chuàng)建1000個用戶分別來分配權限的方式進行管理和維護。
必須要有一個高效的模型解決這種復雜的業(yè)務，這個模型就是RBAC。
RBAC設計實踐
RBAC的思想，即用角色來解耦權限和用戶的關系，其目的是解決日益增長的業(yè)務所帶來的快速增長的用戶和權限數(shù)量。
傳統(tǒng)（早期）的直接為用戶配置權限的設計模型，由于其耦合性太高，必然導致維護性和擴展性隨業(yè)務增長來極速降低，無法支持大型業(yè)務平臺的運轉。
在RBAC模型中，一個用戶可以有多個角色，一個角色可以有多個權限，通過將角色和權限分離開來提高設計的可擴展性，通常一個用戶有多個角色，一個角色也會屬于多個用戶（多對多），一個角色有多個權限，一個權限也會屬于多個角色（多對多）。
如下圖所示：
用戶和角色、權限之間，是松散的一對一、一對多甚至多對對的關系，而且這個關系是物理結構上的上下層級關系，帶來的好處就是降低平臺的耦合性，極大的提高了系統(tǒng)的可操作性和易維護性，數(shù)據(jù)的安全性也非常具有保障，極大的降低了管理的開銷。
回到上文我們設計的用戶角色，不管是坐席，門店還是工程師，都可以依據(jù)其業(yè)務范圍和標簽屬性，就可以輕松的實現(xiàn)對權限的指派和回收。
RBAC認為，權限授權實際上是Who、What、How的問題。who、what、how構成了訪問權限三元組，權限的管理用一句話來表達就是：Who （用戶） 對 What (資源) 進行 How （行為）的操作 。
Who：權限的擁用者或主體，也就是用戶實體。
What：權限針對的對象或資源，可以直接理解為產品界面上的菜單、按鈕等
How：具體的權限，查看、操作資源和數(shù)據(jù)的具體操作。
這個過程可以分解為兩個步驟：
我們只需要通過給角色授權，分配每個角色可以查看、操作的功能和數(shù)據(jù)范圍，然后將附有權利的角色施加到某個用戶賬號，就使得該用戶獲取了相應系統(tǒng)權限了。
通過“角色”這一層抽象的中間身份，整個系統(tǒng)就變得更為靈活：角色的權限可以隨時調整或者被系統(tǒng)回收，每個用戶賬號的操作權限可以隨業(yè)務場景的不同而發(fā)生改變。
比如，一個工程師登錄工程師的界面，則擁有工程師的權限，登錄到門店系統(tǒng)，則擁有該門店授權的操作范圍。
下圖即為一個完整的用戶授權實例：
這種設計下，任意一個賬號，都可以根據(jù)實際業(yè)務需要，隨時調整權限范圍，對大型平臺產品而言，這種靈活性非常重要(RBAC模型還可以進一步擴展，比如用戶組、角色互斥等)。
從上圖，我們也可以發(fā)現(xiàn)權限管理必須具備的兩項基本原則：
1、職責分離：不同的角色完成不同的業(yè)務分工，通過分配不同的角色實現(xiàn)責任的互相約束實現(xiàn)對組織業(yè)務和數(shù)據(jù)的安全管理
2、最小特權：系統(tǒng)可以限制分配給角色的權限多數(shù)、大小，為任意賬號分配權限，只要不超過該用戶完成任務的基本需要即可
也正是因為RBAC的特性，我們在做產品設計時，更應該把精力集中于“用戶實體”的實際業(yè)務流轉過程，關注其行為背后的動機和邏輯，才能夠設計一個高效的后臺系統(tǒng)。
但，RBAC有一個“缺陷”——沒有提供操作順序控制機制，無法進行嚴格的操作次序控制，沒有辦法要求用戶先做什么，后做什么，必須借助外部機制來進行控制。
當然，對于權限管理而言，既要充分考慮到系統(tǒng)的靈活性，也要考慮實際的應用程度和研發(fā)成本的投入，越是靈活的系統(tǒng)，也就必然帶來更多的成本投入，其結果是帶來管理開銷的節(jié)約。
所有優(yōu)秀的設計，都基于對業(yè)務、規(guī)則的深刻理解。
越早進行系統(tǒng)的考慮，成本越低，效果也越好。
作者：?杜松2021
首席增長官CGO薦讀：
更多精彩，關注：增長黑客（GrowthHK.cn）
增長黑客（Growth Hacker）是依靠技術和數(shù)據(jù)來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度，梳理整合產品發(fā)展的因素，實現(xiàn)低成本甚至零成本帶來的有效增長…
本文經授權發(fā)布，不代表增長黑客立場，如若轉載，請注明出處：http://allfloridahomeinspectors.com/quan/15781.html
微信掃一掃 
支付寶掃一掃 