編輯導(dǎo)讀：權(quán)限設(shè)計對于大多數(shù)產(chǎn)品經(jīng)理來說都不陌生，本篇文章討論一個系統(tǒng)的權(quán)限設(shè)計有哪些機制，并重點介紹RBAC的機制，一起來看看吧。

在前文「CRM02-銷售域系統(tǒng)設(shè)計與實施中，講解到了權(quán)限的劃分」，本篇文章討論一個系統(tǒng)的權(quán)限設(shè)計有哪些機制，并重點介紹RBAC的機制。

一、基本邏輯

首先我來拆解下訪問的邏輯，一次完整的訪問，有如下組成：

• 用戶：發(fā)起訪問的主體（這個用戶還可以是用戶組的概念，即一組用戶，對應(yīng)了組織機構(gòu)）
• 權(quán)限：被訪問的客體
• 對象：記錄用戶是否可以訪問某個對象。其實還能拆出給權(quán)限控制表的，為了好理解就簡化了

基于這個邏輯，訪問過程可以有不同的機制來控制。

二、訪問機制

當前市面上流傳比較廣的權(quán)限控制機制，如下3種：

• ABAC：基于屬性的訪問控制(Attribute Based Access Control)
• RBAC：基于角色的訪問控制(Role Based Access Control)
• PBAC：基于策略的訪問控制(Policy Based Access Control)

一瞬間甩出3個訪問控制機制，會讓人找不到抓手，我先從我的角度來介紹下，如果有說錯的歡迎老司機來斧正。

首先，這3個機制沒有好與壞，只有是否合適，每個機制下的擁護者都會說自己的機制代表了未來。

1. ABAC

是基于用戶上的某個屬性來控制訪問的，比如基于年齡屬性限制，某用戶18歲以下，就不能訪問某些頁面，這種就是ABAC。

優(yōu)點：集中化管理，一刀切

缺點：如果權(quán)限需求靈活多變，配置會死人，也無法看到某個用戶能否訪問具體某個對象

2. RBAC

基于角色的權(quán)限控制，增加了一層角色的抽象，這也是在設(shè)計CRM結(jié)構(gòu)中介紹的方法《引用第二篇文章》。通過不同的頁面授權(quán)，把不同對象的權(quán)限集合成角色，達到靈活的配置。

優(yōu)點：用戶和對象的關(guān)系可直觀追溯，調(diào)整與配置很靈活。

缺點：如果公司業(yè)務(wù)規(guī)模較大，角色分工出現(xiàn)模糊，比如一個人有記賬的角色又有了監(jiān)管的角色，這種分工是極不合理的。按照這個層級模型，理論上對象越多，能排列出的權(quán)限組合越多，角色就越多。這種現(xiàn)象叫做

角色爆炸。基于角色爆炸，又引出了后面的PBAC。

3. PBAC

如果一個大的系統(tǒng)會有很多關(guān)聯(lián)子系統(tǒng)，子系統(tǒng)中又有不同的權(quán)限配置，等級也不同，菜單也不同。

這個場景就更適合PBAC，基于策略的角色控制，這個機制下的配置邏輯，就是“按照原則去設(shè)計一條權(quán)限限制”，這個原則就組成了策略，如只要是某個部門的人都不需要打卡。舉例：當“部門屬性”=“運維組”，訪問頁面包含“系統(tǒng)配置”這類。

優(yōu)點：PBAC 支持環(huán)境和上下文控制，因此可以設(shè)置策略以在特定時間和特定位置授予對資源的訪問權(quán)限，甚至評估身份和資源之間的關(guān)系。策略可以快速調(diào)整，并在給定的時間段內(nèi)設(shè)置（例如響應(yīng)違規(guī)或其他緊急情況）。可以輕松添加、刪除或修改用戶組，單擊即可撤銷過時的權(quán)限。

缺點：配置的操作難度，不適用于一般的商業(yè)公司，對配置人員操作要求較高。

三、RBAC核心設(shè)計

介紹完不同的機制，我重點說下RBAC。

RBAC認為權(quán)限的過程可以抽象概括為：判斷【W(wǎng)ho是否可以對What進行How的訪問操作（Operator）】這個邏輯表達式的值是否為True的求解過程。

即將權(quán)限問題轉(zhuǎn)換為Who、What、How的問題。who、what、how構(gòu)成了訪問權(quán)限三元組。

RBAC支持公認的安全原則：最小特權(quán)原則、責任分離原則和數(shù)據(jù)抽象原則。

• 最小特權(quán)原則：某用戶對應(yīng)的角色的權(quán)限只要不超過該用戶完成其任務(wù)的需要就可以了。
• 責任分離原則：是指完成敏感任務(wù)過程中需要分配兩個責任上互相約束的兩個角色來實現(xiàn)，例如在清查賬目時，只需要設(shè)置財務(wù)管理員和會計兩個角色參加就可以了。
• 數(shù)據(jù)抽象：如在賬目管理活動中，可以使用信用、借方等抽象許可權(quán)，而不是使用操作系統(tǒng)提供的讀、寫、執(zhí)行等具體的許可權(quán)。

使用RBAC的機制，優(yōu)點對于業(yè)務(wù)環(huán)境來講就是很清晰，可以快速通過角色來識別角色包含的頁面，而且多個角色可以疊加取并集，讓配置的人操作量減少。

至于角色爆炸的問題，在CRM實施之初就提前規(guī)劃好，并約定好原則，這個問題就可以大概率避免。當然不排除后人破掉了這個限制，導(dǎo)致套娃

RBAC的核心設(shè)計如下綠圖：

【圖片來自于Apache Directory】

用戶和角色還有會話相互關(guān)聯(lián)（會話的作用可理解為每次訪問都要檢查用戶和角色的關(guān)系，如果角色沖突，就中斷會話）

角色單獨和權(quán)限管理，是權(quán)限的集合。權(quán)限內(nèi)部又包含了對象和操作。（如果不理解對象和操作，可查看之前的UML文章）

RBAC體系的邏輯可以大體這么理解：

RBAC0：RBAC96家族的核心部分，后面的123都是基于此發(fā)展

RBAC1?：在0的基礎(chǔ)上，增加角色分層和角色繼承的關(guān)系?。如區(qū)域經(jīng)理下方有門店店長這種關(guān)系

RBAC2：在0基礎(chǔ)上增加了角色約束，包含：

• 角色互斥約束，系統(tǒng)的運行中互斥角色只能生效一個，如Boss直聘里的牛人和BOSS，切換以后需要重新登錄
• 角色基數(shù)約束，限制某個用戶最多的角色數(shù)量/權(quán)限數(shù)量，防止濫用
• 先決條件角色約束，指某用戶只有在已經(jīng)擁有某個角色的前提下，才能分配到特定的其他角色，如想擁有線索放棄的權(quán)限，就必須擁有銷售角色的權(quán)限

RBAC3：

融合了RBAC1和RBAC2的所有特點，把角色關(guān)系和角色約束都整合到了一塊，在我們的業(yè)務(wù)環(huán)境中沒必要這么復(fù)雜，所以就用了RBAC0。

基于RBAC0的這種機制，落地到業(yè)務(wù)中，整體的權(quán)限配置效果如下：

• 一個用戶，可以批量關(guān)聯(lián)多個角色。一個角色可以批量授權(quán)給多個用戶
• 一個角色可以配置不同的頁面權(quán)限與操作權(quán)限（操作在我們設(shè)計的時候也抽象成了頁面，更簡單）
• 數(shù)據(jù)權(quán)限與組織樹權(quán)限的顆粒度精細到具體的用戶，只可單獨授權(quán)。同時數(shù)據(jù)的行權(quán)限和列權(quán)限不必單獨授權(quán)，保留了能力

基于RBAC的權(quán)限設(shè)計就講到這里，希望在大家設(shè)計系統(tǒng)的時候有所幫助，如果在設(shè)計過程中卡在了頁面設(shè)計上，把上述的每個圓圈的內(nèi)容分別設(shè)計個列表和詳情頁，就有思路了，如圖。

角色管理：

角色詳情：

用戶管理：

用戶詳情：

本文核心理論部分來自于互聯(lián)網(wǎng)，頁面截圖來自于過往脫敏經(jīng)歷。

參考資料

RBAC https://csrc.nist.gov/projects/role-based-access-control

PBAC VS RBAC https://blog.plainid.com/why-role-based-access-control-is-not-enough

PBAC VS ABAC https://blog.plainid.com/the-advantage-of-pbac-over-the-traditional-abac

RBAC核心設(shè)計 http://directory.apache.org/fortress/user-guide/1.3-what-rbac-is.html

感謝大家的閱讀！CRM系統(tǒng)設(shè)計的相關(guān)內(nèi)容到這里基本講完了，后面我會繼續(xù)出CRM外圍系統(tǒng)的相關(guān)內(nèi)容，歡迎大家追更~~

我這幾篇文章經(jīng)常提到UML，也是給大家實操了一遍，建議大家練習和使用。祝大家在產(chǎn)品的道路上找到自己喜歡的事情。

作者：羅文正雄；公眾號：羅文正雄

本文由 @羅文正雄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pexels，基于 CC0 協(xié)議