文章從RBAC的基本原理出發，結合案例對權限設計中一個職位對應多個崗位的的情況進行了說明，并分享了相關權限模型，供大家一起參考和學習。

傳統RBAC與現實的距離

傳統的RBAC（基于角色的訪問權限控制）是一個經典的權限管理模型，基本原理是不直接對系統種的用戶賦權，而是通過角色作為系統用戶和系統資源之間的中介，將資源權限綁定到角色，再將角色綁定到用戶，來完成整個賦權的流程，從而簡化賦權和修改權限的過程。（多扯一句，這個理念和計算機軟件體系中，大家談到的，當你覺得一個系統太復雜的時候，就給它加一個中間層的“秘笈”不謀而合，可見“世間萬物皆有相通之理”）

上述的基礎的RBAC（維基上命名為RBAC0）簡單易懂，且容易落地。但是實際工作過程中，人們往往會在基礎的RBAC上疊加更多特性，來滿足現狀的需要。比如從用人制度上，一般都會采取“以崗定人”的用人制度。在權限體系中，當人員調換崗位需要更新此人員的各種權限的時候，只需要更新人員對應的組織關系，那么角色權限會自動進行調整，從而減少了管理人員的工作量，也更符合常見的調崗操作方式。

因此，今天我們來討論兩個方面的問題

1. 組織架構的特點
2. 如何建立組織，崗位和賬戶的關聯模型

先來了解一下組織架構的特點

01 組織架構的特點

組織一般是樹形結構。在同一層的組織里面，有不同的職位，每個職位的權限都不一樣。比如會計和出納擁有不同的權限。

在不同職位之間，存在權限的重合。比如辦公室主任除了擁有辦公室職員的基礎權限，主任還擁有更多的審批管理類權限。

同一個職位會對應多個崗位。同時還會存在一個人身兼多職也就是多個崗位的情況如下圖所示，副總經理這一級組織對應的崗位上，有兩人任職，趙子龍和趙德彪。同時趙子龍除了擔任副總經理的崗位，還擔任了總會計這一級組織里的負責人崗位。

02 組織，崗位，角色，帳號融合后的模型

以上面的組織架構為例，接下來會解密如何設計一個融合了組織和崗位的權限體系。

當然，在此之前需要我們對其一下術語。先來了解一下對每個名詞的定義吧。

• 帳號：每一個真實的人，登錄系統的場景，我們將這個真實的人用【帳號】來代表。
• 資源：系統中的每一個項，比如所有的菜單，所有的數據列表，所有的頁面等。
• 角色：【角色】代表對資源的CRUD控制權限。
• 組織：圖1所示就是一個組織架構
• 崗位：與人相對應，一個崗位只能對應一個人，但一人可以同時擔任多個崗位。
• 職位：同一個類型的崗位，組成一個職位

一般不會直接將【帳號】與【資源】綁定，原因在前言中也說了，這種粒度過細，會讓后期維護的時候非常復雜和耗時。為了方便賦權和后期的維護，可以將【職位】與【角色】綁定。同一個職位下的所有【崗位】擁有同樣的角色。如下圖所示。

說明：副總經理趙德彪，需要對應一個他自己的帳號。這個帳號只代表1個崗位，登陸后，系統檢查這個帳號代表的是崗位C，崗位C在組織架構中的職位是職位B。接下來，系統發現這個職位B對應了4個角色，即角色2~5。每個角色都分別代表了不同的對資源操作的權限，職位B擁有的是這4個角色權限的總和。最終總結起來，趙德彪登陸后，擁有操作資源A，操作資源C和…資源…的權限。

另外一位副總經理趙子龍，需要對應一個他自己的帳號。這個帳號代表了2個崗位，按照上面的邏輯推斷步驟，省略中間過程，最終總結起來就是，趙子龍登陸后，擁有查看資源A，操作資源B和操作資源C的權限。

03 總結

在這篇文章中，首先快速的過了一遍RBAC的基本原理，就是將帳號和角色綁定，角色與資源權限綁定，來實現簡單合理的權限控制。然后介紹了一個真實的“以崗定人”的組織架構，存在一個職位對應多個崗位，一人多崗的特點。最后給出了一個可實際操作的，包含如何設計帶有組織和崗位的權限模型，供參考。

歡迎大家一起討論。

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

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