saas平臺由于其本身“按需購買”的特性，在設(shè)計規(guī)劃權(quán)限時，需要考慮統(tǒng)一配置權(quán)限如何規(guī)避企業(yè)沒有購買的應(yīng)用，以及如有部分應(yīng)用存在數(shù)據(jù)權(quán)限不同的問題?，F(xiàn)在，本文簡單總結(jié)一下當(dāng)前saas模式下權(quán)限的幾種設(shè)計方式。

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

這里權(quán)限的統(tǒng)一與拆分問題也十分重要，本文簡單總結(jié)一下當(dāng)前saas模式下權(quán)限的幾種設(shè)計方式。

一、權(quán)限管理的重要性

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

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

二、抽象權(quán)限組成

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

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

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

向上引申可將權(quán)限劃分為3個組成部分：

1. 頁面權(quán)限：用戶可以看到那些頁面；
2. 操作權(quán)限：用戶可以在頁面內(nèi)進行那些操作，增刪改查等；
3. 數(shù)據(jù)權(quán)限：用戶可以看到那些數(shù)據(jù)或內(nèi)容；

三、常見的權(quán)限控制模型

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

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

DAC最大缺陷就是所有用戶的權(quán)限不能統(tǒng)一管理，用戶和用戶的權(quán)限比較分散，后期調(diào)整只能單個進行調(diào)整，不易維護。

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

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

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

RBAC是我們當(dāng)前使用范圍最廣的一種權(quán)限設(shè)計模型，模型基礎(chǔ)就是用戶和角色，角色和權(quán)限做多對多的對應(yīng)。標(biāo)準(zhǔn)的RBAC模型包括四個部件模型，分別為基本模型RABC0、角色分級模型RABC1、角色限制模型RABC2、統(tǒng)一模型RABC3。

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

如圖所示，每個用戶關(guān)聯(lián)一個或多個角色，每個角色關(guān)聯(lián)一個或多個權(quán)限，從而可以實現(xiàn)了非常靈活的權(quán)限管理。角色可以根據(jù)實際業(yè)務(wù)需求靈活創(chuàng)建，這樣就省去了每新增一個用戶就要關(guān)聯(lián)一遍所有權(quán)限的麻煩。

簡單來說RBAC就是：用戶關(guān)聯(lián)角色，角色關(guān)聯(lián)權(quán)限。并且在產(chǎn)品和數(shù)據(jù)設(shè)計層面，有更好的擴展性，可控制到任意的粒度。

（4）基于屬性的權(quán)限驗證（ABAC：Attribute-Based Access Control）

ABAC則是通過動態(tài)計算一個或一組屬性，來是否滿足某種條件來進行授權(quán)判斷（可以編寫簡單的邏輯）。屬性通常來說分為四類：用戶屬性（如用戶年齡），環(huán)境屬性（如當(dāng)前時間），操作屬性（如讀取）和對象屬性（如一篇文章，又稱資源屬性），所以理論上能夠?qū)崿F(xiàn)非常靈活的權(quán)限控制，幾乎能滿足所有類型的需求。該設(shè)計過于復(fù)雜，暫未參透。

四、基于RBAC權(quán)限模型的SAAS平臺權(quán)限系統(tǒng)設(shè)計

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

RBAC對權(quán)限抽象概括：判斷【W(wǎng)ho是否可以對What進行How的訪問操作（Operator）】

RBAC支持三個著名的安全原則：最小權(quán)限原則，責(zé)任分離原則和數(shù)據(jù)抽象原則。

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

——來自百度百科

以某物業(yè)公司內(nèi)部信息平臺為例，該物業(yè)公司平臺分為客戶檔案、房產(chǎn)檔案、收費系統(tǒng)、客服工單等多應(yīng)用結(jié)構(gòu)，其中物業(yè)公司組織架構(gòu)為多層級，基本樣式如下如。

組織架構(gòu)

應(yīng)用入口

功能頁面

以上我們可以將：

• 組織架構(gòu)=數(shù)據(jù)權(quán)限
• 應(yīng)用入口以及應(yīng)用菜單=頁面權(quán)限
• 功能操作點=操作權(quán)限

1. 基本模型：RBAC0

抽取角色，建立角色與用戶的關(guān)系。

這里的角色主要是指在組織內(nèi)承擔(dān)特定的業(yè)務(wù)活動，并和別的業(yè)務(wù)角色進行交互的業(yè)務(wù)角色。業(yè)務(wù)角色的抽取主要有兩種方式：一種是直接和崗位對應(yīng)，另外一種是根據(jù)流程的本質(zhì)和需要定義角色。

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

根據(jù)業(yè)務(wù)復(fù)雜度、用戶特點進行原型草圖設(shè)計，在進行權(quán)限分配時，可以從增加角色維度以及增加用戶維度。如下圖：

新建角色維度

新建用戶維度

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

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

2. 角色分級模型：RBAC1

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

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

建立角色層級關(guān)系和繼承關(guān)系。

角色層級關(guān)系

一般繼承關(guān)系

受限繼承關(guān)系

給角色賦予權(quán)限（應(yīng)用入口權(quán)限——應(yīng)用頁面權(quán)限、應(yīng)用頁面中操作功能權(quán)限、數(shù)據(jù)查看權(quán)限。）權(quán)限賦予同RBAC0。

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

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

3. 角色限制模型：RBAC2

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

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

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

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

角色權(quán)限配置界面可參照RBAC0。

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

當(dāng)一個用戶配置了多個角色身份時，權(quán)限取并集。

4. 統(tǒng)一模型：RBAC3

統(tǒng)一模型是包括了繼承和分離兩種情況的更為復(fù)雜的模型，即既要定義角色間的的繼承關(guān)系，也要維護好角色間的責(zé)任分離關(guān)系。

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

角色管理

權(quán)限配置

五、總結(jié)

1. 角色數(shù)據(jù)權(quán)限

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

2. 用戶操作體驗

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

3. 默認賬號以及默認權(quán)限的設(shè)置

對于ToB類或者平臺類的產(chǎn)品，正常來講都會有一個默認的超級管理員的角色以及角色對應(yīng)的賬號，否則系統(tǒng)內(nèi)第一個角色誰來添加？

默認權(quán)限的設(shè)置則根據(jù)需要進行設(shè)置，如果是不必要進行控制的權(quán)限，當(dāng)然是可以設(shè)置為默認權(quán)限的。

綜上所述，根據(jù)以上的設(shè)計模式以及解決方案，已經(jīng)能實現(xiàn)大部分企業(yè)90%的問題了，實際上很多企業(yè)并不需要做到這么小粒度的權(quán)限控制。

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

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