編輯導讀：權限設計對于大多數產品經理來說都不陌生，本篇文章討論一個系統的權限設計有哪些機制，并重點介紹RBAC的機制，一起來看看吧。

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

一、基本邏輯

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

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

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

二、訪問機制

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

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

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

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

1. ABAC

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

優點：集中化管理，一刀切

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

2. RBAC

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

優點：用戶和對象的關系可直觀追溯，調整與配置很靈活。

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

角色爆炸?；诮巧?，又引出了后面的PBAC。

3. PBAC

如果一個大的系統會有很多關聯子系統，子系統中又有不同的權限配置，等級也不同，菜單也不同。

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

優點：PBAC 支持環境和上下文控制，因此可以設置策略以在特定時間和特定位置授予對資源的訪問權限，甚至評估身份和資源之間的關系。策略可以快速調整，并在給定的時間段內設置（例如響應違規或其他緊急情況）?？梢暂p松添加、刪除或修改用戶組，單擊即可撤銷過時的權限。

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

三、RBAC核心設計

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

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

即將權限問題轉換為Who、What、How的問題。who、what、how構成了訪問權限三元組。

RBAC支持公認的安全原則：最小特權原則、責任分離原則和數據抽象原則。

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

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

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

RBAC的核心設計如下綠圖：

【圖片來自于Apache Directory】

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

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

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

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

RBAC1?：在0的基礎上，增加角色分層和角色繼承的關系?。如區域經理下方有門店店長這種關系

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

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

RBAC3：

融合了RBAC1和RBAC2的所有特點，把角色關系和角色約束都整合到了一塊，在我們的業務環境中沒必要這么復雜，所以就用了RBAC0。

基于RBAC0的這種機制，落地到業務中，整體的權限配置效果如下：

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

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

角色管理：

角色詳情：

用戶管理：

用戶詳情：

本文核心理論部分來自于互聯網，頁面截圖來自于過往脫敏經歷。

參考資料

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核心設計 http://directory.apache.org/fortress/user-guide/1.3-what-rbac-is.html

感謝大家的閱讀！CRM系統設計的相關內容到這里基本講完了，后面我會繼續出CRM外圍系統的相關內容，歡迎大家追更~~

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

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

本文由 @羅文正雄 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Pexels，基于 CC0 協議