saas平臺由于其本身“按需購買”的特性，在設計規劃權限時，需要考慮統一配置權限如何規避企業沒有購買的應用，以及如有部分應用存在數據權限不同的問題?，F在，本文簡單總結一下當前saas模式下權限的幾種設計方式。

作為一個B端平臺型產品，系統的權限設計是其中一個非常重要的組成部分，沒有權限管理的系統仿佛一個沒有門的房子，任何人都可以隨意查看甚至調整，對系統的安全性存在非常大的隱患，而saas模式下由于應用基本獨立，隨時可能被企業拆分使用。

這里權限的統一與拆分問題也十分重要，本文簡單總結一下當前saas模式下權限的幾種設計方式。

一、權限管理的重要性

權限管理一般指根據系統設置的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源，權限管理基本是任何一個系統的標配模塊。它的作用不僅在于保護系統數據安全性、防止留下系統漏洞，更能在龐大的系統下進行模塊和數據配置，讓不同的角色進入系統看到不同的模塊和數據，最大程度地提高系統的易用性。

大部分系統中權限管理是作為一個獨立的管理入口，統一設置所有的業務的權限。而saas平臺由于其本身“按需購買”的特性，在設計規劃權限時，需要考慮統一配置權限如何規避企業沒有購買的應用，以及如有部分應用存在數據權限不同的問題。

二、抽象權限組成

權限到底是名詞屬性還是動詞屬性，還是名詞、動詞屬性均包含，這對于權限的含義很重要。如果是名詞屬性的話，那么它應該是有具體的指代物；如果是動詞，則應該具有行為表示。

• 權限的名詞屬性：api接口、頁面、功能點。
• 權限的動詞屬性：可操作、不可操作。

那么我們現在來看，其實權限是名詞、動詞屬性，它一定是表達了兩層含義。即控制的對象、操作。

向上引申可將權限劃分為3個組成部分：

1. 頁面權限：用戶可以看到那些頁面；
2. 操作權限：用戶可以在頁面內進行那些操作，增刪改查等；
3. 數據權限：用戶可以看到那些數據或內容；

三、常見的權限控制模型

（1）自主訪問控制（DAC：Discretionary Access Control）

系統會識別用戶，然后根據被操作對象（object）的權限控制列表（ACL：Access Control List）或者權限控制矩陣（ACL：Access Control Matrix）的信息來決定用戶的是否能對其進行哪些操作，例如讀取或修改。而擁有對象權限的用戶，又可以將該對象的權限分配給其他用戶，所以稱之為“自主（Discretionary）”控制。

DAC最大缺陷就是所有用戶的權限不能統一管理，用戶和用戶的權限比較分散，后期調整只能單個進行調整，不易維護。

（2）強制訪問控制（MAC：Mandatory Access Control）

在MAC的設計中，每一個對象都都有一些權限標識，每個用戶同樣也會有一些權限標識，而用戶能否對該對象進行操作取決于雙方的權限標識的關系，這個限制判斷通常是由系統硬性限制且無法回避的。強制訪問控制多應用于對安全性要求比較高的系統，如多級安全軍事系統；

（3）基于角色的訪問控制（RBAC：Role-Based Access Control)

RBAC是我們當前使用范圍最廣的一種權限設計模型，模型基礎就是用戶和角色，角色和權限做多對多的對應。標準的RBAC模型包括四個部件模型，分別為基本模型RABC0、角色分級模型RABC1、角色限制模型RABC2、統一模型RABC3。

1. RBAC0（基本模型）定義了完全支持RBAC概念的任何系統的最低需求。RBAC0的模型中包括用戶（U）、角色（R）和許可權（P）等3類實體集合，RABC0是權限管理的核心部分，其他的版本都是建立在0的基礎上。
2. RBAC1（角色分級模型）基于RBAC0模型，引入角色間的繼承關系，即角色上有了上下級的區別，角色間的繼承關系可分為一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系，允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構，實現角色間的單繼承。這種模型合適于角色之間的層次明確，包含明確。
3. RBAC2（角色限制模型）引入了角色間的約束關系，主要約束規則包括：角色間的互斥關系，在處理用戶和這些角色之間的關系時，包括靜態分離和動態分離，靜態分離指互斥的角色不能同時賦予同一個用戶；動態分離指用戶不能同時操作兩個互斥的角色進行登錄。
4. RBAC3（統一模型）同時包含了1和2的特性。

如圖所示，每個用戶關聯一個或多個角色，每個角色關聯一個或多個權限，從而可以實現了非常靈活的權限管理。角色可以根據實際業務需求靈活創建，這樣就省去了每新增一個用戶就要關聯一遍所有權限的麻煩。

簡單來說RBAC就是：用戶關聯角色，角色關聯權限。并且在產品和數據設計層面，有更好的擴展性，可控制到任意的粒度。

（4）基于屬性的權限驗證（ABAC：Attribute-Based Access Control）

ABAC則是通過動態計算一個或一組屬性，來是否滿足某種條件來進行授權判斷（可以編寫簡單的邏輯）。屬性通常來說分為四類：用戶屬性（如用戶年齡），環境屬性（如當前時間），操作屬性（如讀?。┖蛯ο髮傩裕ㄈ缫黄恼?，又稱資源屬性），所以理論上能夠實現非常靈活的權限控制，幾乎能滿足所有類型的需求。該設計過于復雜，暫未參透。

四、基于RBAC權限模型的SAAS平臺權限系統設計

對于SAAS平臺這樣龐大復雜的平臺來說，權限系統設計得越全面、精細、后期的系統擴展性就越高，所以這里采用RBAC權限模型，RBAC權限模型是現有比在這方面比較成熟的權限設計模型，應用這個模型能解決常規的系統權限配置問題，其基本原理也能適用于平臺權限設計。

RBAC對權限抽象概括：判斷【Who是否可以對What進行How的訪問操作（Operator）】

RBAC支持三個著名的安全原則：最小權限原則，責任分離原則和數據抽象原則。

1. 最小權限原則之所以被RBAC所支持，是因為RBAC可以將其角色配置成其完成任務所需要的最小的權限集。
2. 責任分離原則可以通過調用相互獨立互斥的角色來共同完成敏感的任務而體現，比如要求一個計帳員和財務管理員共參與同一過帳。
3. 數據抽象可以通過權限的抽象來體現，如財務操作用借款、存款等抽象權限，而不用操作系統提供的典型的讀、寫、執行權限。然而這些原則必須通過RBAC各部件的詳細配置才能得以體現。

——來自百度百科

以某物業公司內部信息平臺為例，該物業公司平臺分為客戶檔案、房產檔案、收費系統、客服工單等多應用結構，其中物業公司組織架構為多層級，基本樣式如下如。

組織架構

應用入口

功能頁面

以上我們可以將：

• 組織架構=數據權限
• 應用入口以及應用菜單=頁面權限
• 功能操作點=操作權限

1. 基本模型：RBAC0

抽取角色，建立角色與用戶的關系。

這里的角色主要是指在組織內承擔特定的業務活動，并和別的業務角色進行交互的業務角色。業務角色的抽取主要有兩種方式：一種是直接和崗位對應，另外一種是根據流程的本質和需要定義角色。

確定各角色的用例圖，如下圖（簡單示例）：

根據業務復雜度、用戶特點進行原型草圖設計，在進行權限分配時，可以從增加角色維度以及增加用戶維度。如下圖：

新建角色維度

新建用戶維度

使用此模型時，我們需要注意的問題有：

1. 用戶和角色為多對一的關系，如果需要用到多對多的關系，將涉及到角色關系的處理，此模型并不適用。
2. 權限一定是動態可配置的，不是靜態的，這點一定要在著手開發前進行說明，一般情況，權限的數據結構為樹形，合理的數據結構，便于前端根據實際需求進行解析；
3. 人員在選擇角色獲取到對應的權限數據后，最好可以提供一個二次編輯界面，權限會更加靈活。

2. 角色分級模型：RBAC1

RBAC1基于RBAC0模型，引入角色間的繼承關系，即角色上有了上下級的區別，角色分級模型適用于平臺業務功能較多，單個角色設置操作過于繁瑣，引用角色分級，可讓角色之間存在繼承或被繼承的關系，比如客服主管可直擁有下級所有員工擁有的權限。

建立角色管理，確定角色跟用戶之間的關系。（要求角色間有明顯的層級關系，所以在沒有其他需求的情況下，這里根據業務部門和崗位進行角色的抽?。?/p>

建立角色層級關系和繼承關系。

角色層級關系

一般繼承關系

受限繼承關系

給角色賦予權限（應用入口權限——應用頁面權限、應用頁面中操作功能權限、數據查看權限。）權限賦予同RBAC0。

增加一個角色管理。如下圖：

通過角色管理即可以將下級角色的權限直接賦值給上級權限，但由于低級角色的權限全部被高級角色繼承，就會導致沒有自己角色的私有權限；也可以為人員提供一個二次編輯權限界面，但是一旦編輯后，若后續所屬角色權限發生變化，會直接覆蓋原有編輯后的權限。

3. 角色限制模型：RBAC2

RBAC2，它是RBAC的約束模型，RBAC2也是建立的RBAC0的基礎之上的，在RBAC0基礎上假如了約束的概念，主要引入了靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic Separation of Duty)。

SSD是用戶和角色的指派階段加入的，主要是對用戶和角色有如下約束:

1. 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個；
2. 基數約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的；
3. 先決條件約束：用戶想要獲得高級角色，首先必須擁有低級角色。

DSD是會話和角色之間的約束，可以動態的約束用戶擁有的角色，如一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

角色權限配置界面可參照RBAC0。

用戶在配置角色或角色下新建添加用戶時，需要根據用戶已有的角色身份進行判斷。示例：用戶A配置角色為客服組長，則可繼續添加角色為客服主管，若客服主管已被分配給他人，則也不能分配給用戶A（遵從最大擁有數原則）。若同時將保安主管分派至用戶A，則操作時，需要選擇操作角色。

當一個用戶配置了多個角色身份時，權限取并集。

4. 統一模型：RBAC3

統一模型是包括了繼承和分離兩種情況的更為復雜的模型，即既要定義角色間的的繼承關系，也要維護好角色間的責任分離關系。

在這里就不做過多的贅述（兩張圖供大家參考），因為只要維護好了角色間的約束關系，其他規則類的處理方式同RABC1和RABC2。

角色管理

權限配置

五、總結

1. 角色數據權限

1. 不同的角色身份查看的角色數據時不相同的，比如物業分公司中深圳區域分公司的管理人員可能就無法管理長沙區域分公司，在給角色分配數據權限時就可以將長沙區域分公司去除。
2. 除數據權限外，我們還會遇到字段權限，比如：分公司C和分公司D都能看到上海區域分公司的客戶情況，但是C看不到客戶聯系方式，D則能看到聯系方式。如果有需要對字段權限進行控制，則可以在設置角色的數據權限或者功能權限時，進行控制。
3. 題前有提到針對saas模式，可能存在一個角色在管理A跟B應用時可操作的數據權限時不一樣的，可以在數據權限中增加一個高級設置權限，為不同的角色針對不用的應用進行分配數據操作。

2. 用戶操作體驗

平臺類或者TO B內部產品，雖然不像C端為了留住用戶追求極致用戶體驗，但是也需要確保在交互以及文字理解上面不會讓用戶產生疑惑情緒，培訓成本也是開發成本的一環，尤其針對權限一塊可能涉及業務功能復雜，如果在文字描述以及操作上在加大操作難度，可能無法估量的后果。

3. 默認賬號以及默認權限的設置

對于ToB類或者平臺類的產品，正常來講都會有一個默認的超級管理員的角色以及角色對應的賬號，否則系統內第一個角色誰來添加？

默認權限的設置則根據需要進行設置，如果是不必要進行控制的權限，當然是可以設置為默認權限的。

綜上所述，根據以上的設計模式以及解決方案，已經能實現大部分企業90%的問題了，實際上很多企業并不需要做到這么小粒度的權限控制。

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

題圖來自Unsplash，基于CC0協議