部門角色權限rbac_新人入門：To B 的權限體系設計

文章從權限模型和概念出發，對權限系統的核心進行剖析，抽象出權限系統中的核心要素，并結合案例對權限系統進行介紹。

一個最簡單表達了權限模型的執行個體

小明和小李，分别用自己的帳号和密碼登入了同一個平台頁面。小明登陸上去後，可以看到小說和視訊頁面。小李登陸上去之後，隻能看到小說頁面。

emmm…..他倆有不同的權限。

背景是什麼樣的模型來實作的呢。對于ToB領域的權限控制，産品經理經常用到的是RBAC模型

什麼是RBAC

RBCA是英文role-based access control的縮寫，即基于角色的權限管理系統，用來實作對使用者授權，通路系統的特定部分，實作不同粒度的權限控制。可以了解為一種非功能性的需求，而是一種安全機制。據說一般一個企業超過500名員工，都會需要用到權限控制。至于“安全”這個主題，在對企業打分的時候，不一定會成為一個加分項，但一定可以成為一個扣分項。

RBAC的核心是角色(role)。所有使用者的能夠操作的内容，都是通過角色來進行賦予和禁止，而不是直接通過對使用者本身來繼續賦予和禁止。如軟體行業的行話，當一個系統太複雜了，那麼就為他加一個層吧。同理，這樣一個role層加入是為了簡化複雜度。具體原因可以看RBAC和ACL的差別

下面來看一下，如果使用者要執行一項操作，需要滿足的RBAC的繞密碼似的3原則

1. 角色配置設定：一個使用者必須被配置設定一個角色
2. 角色授權：目前角色必須被授權給目前使用者
3. 權限授權：權限必須被授予給目前使用者的角色，目前使用者才能執行這項權限

RBAC和ACL的差別

傳統的ACL是屬于更底層更基礎的資料對象的權限控制，比如一個檔案可以讀寫的權限控制。RBAC是帶有業務含義的權限控制。比如可以表達出銀行業裡，保險箱需要的開啟需要銀行經理和儲戶的鑰匙同時存在。又比如可以表達出業務流程中不能出現“自己審理自己”的這種荒唐現象。

權限體系與帳号體系的關系

賬号體系包含的内容是使用者帳号的注冊/登入/密碼修改/密碼找回功能。其中使用者帳号登入，就會需要權限系統提供的功能來進行協助校驗。

校驗内容包含：

1. 這個使用者是不是被禁止，是否可以登入系統。
2. 這個使用者登入後，能夠看到哪些頁面
3. 在他能夠通路到的頁面上，能夠執行哪些操作

權限體系與組織架構的關系

組織架構是企業的行政組織架構。企業所使用的系統，都是其組織結構的反應。是以任何一個ToB的系統，如果要獲得客戶的認可，必須符合客戶的組織結構。

大型企業的組織架構會相當複雜，比如國家電網這種重量級選手，有職能部門，地區分部，一級省公司，直屬機關，再往下細分那就更多更複雜了。如果小型公司，可能就隻有公司總體和部門兩個級别，比較簡單。可以想見，對于越複雜的組織結構，所要求的權限控制的精細度，權限限制會更加複雜

權限體系與組織架構能夠一眼所見的，最直接的關系，就是資料。組織與組織之間的資料，應該是隔離的，組織A的人員，不能夠去通路和操作其他組織的資料。這些需要通過權限體系來實作。

簡單權限系統的設計

如前所述，首先需要設計的是角色。

1. 角色分離

一般角色可以按照兩種次元進行分離，管理的次元和業務的次元。

1. 管理角色：一般是企業的運維人員，可以登入系統，進行維護和授權操作。一般通過自定義的方式，可以支援頁面上建立。一般一個賬号可以同時有多個自定義角色
2. 業務角色：按照職責進行确認，比如财務，保潔員，總經理等。一般通過内置角色的方式來實作，不支援頁面上建立。一般一個帳号可以有一個内置角色

上面說的是一般，一般，一般。當然實際情況中總會有新的不同情況

管理角色會發生變化，但是業務角色由于和企業的組織架構，職級，職能相綁定，一般建立好之後是不會發生變化的。

2. 使用者配置設定角色

參考RBAC三原則，當系統中建立一個使用者時，必須為這個使用者配置設定一個對應的角色

3. 角色授權

不管是内置角色還是自定義角色，當建立一個角色時，需要為這個角色進行授權。permission是一個操作，定義了能夠讀取哪些資源，可以認為授權的對象是由角色+資源(resource)+ 操作組成。資源是指菜單，功能，操作是通常含義的CRUD操作，用user story來描述是，這個角色能夠對哪些資源做哪些具體的操作。角色與資源之間是多對多的關系。

一個授權的例子：角色是倉庫保管員，可以通路倉庫頁面，并對倉庫裡的貨物進行出入和入庫操作。系統管理者為小明建立了一個xiaoming的帳号，并給xiaoming綁定了倉庫保管員的角色。結果就是：小明登入系統後，能夠對倉庫的貨物進行操作了。

本文由 @花生草 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協定。