編輯導語：B端產(chǎn)品數(shù)據(jù)復雜、業(yè)務流程繁瑣、用戶角色眾多，要保證使用中的安全，就需要一個合理的權(quán)限設計。在這篇文章中，作者以SAAS為例，分享了一些權(quán)限設計的經(jīng)驗，一起看看吧。

B端產(chǎn)品具有數(shù)據(jù)復雜、業(yè)務流程繁瑣、用戶角色眾多的特點，為了保障企業(yè)使用過程中系統(tǒng)數(shù)據(jù)的安全性，一個合理的權(quán)限設計是非常重要的，尤其B端SAAS產(chǎn)品具有多租戶的概念，一個產(chǎn)品需要供眾多客戶使用，其對權(quán)限控制的要求會更高。

一、什么是權(quán)限設計

1. 權(quán)限的定義

權(quán)限一詞在詞典的解釋是行駛權(quán)利的界限與范圍。軟件系統(tǒng)中的權(quán)限通常指的是對用戶在系統(tǒng)中可查看什么數(shù)據(jù)、頁面、可進行什么操作的限定。

2. 權(quán)限的分類

從上述權(quán)限的定義中可以看出，權(quán)限主要可以分為數(shù)據(jù)權(quán)限、頁面權(quán)限、操作權(quán)限三類。

（1）數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限是指用戶能否查看某些數(shù)據(jù)的權(quán)限，用戶能查看的數(shù)據(jù)范圍，就是該用戶的數(shù)據(jù)權(quán)限。在系統(tǒng)中不同的用戶在同一個頁面通常查看的數(shù)據(jù)范圍是不同的，比如診所負責人和診所醫(yī)生都具有查看患者信息的權(quán)利，但是通常情況下診所醫(yī)生只能查看其號源下的患者數(shù)據(jù)，診所負責人可以查看診所下所有的患者數(shù)據(jù)。

實現(xiàn)數(shù)據(jù)權(quán)限隔離的方案有如下幾種：

通過組織機構(gòu)樹控制：該方案根據(jù)賬號所在組織機構(gòu)樹中的節(jié)點位置，來判斷能夠查詢的數(shù)據(jù)范圍。這種方式相對比較復雜，但是最靈活，能夠支持各種復雜的業(yè)務數(shù)據(jù)權(quán)限訴求。

通過客戶地區(qū)控制：該方案根據(jù)賬號所在區(qū)域來判斷允許查看的數(shù)據(jù)范圍。這種方式簡單、容易實現(xiàn)，但是靈活性差，只能滿足非常初級的數(shù)據(jù)權(quán)限管理訴求。

通過將數(shù)據(jù)權(quán)限轉(zhuǎn)化為頁面權(quán)限：該方案是通過將用戶能查看哪些數(shù)據(jù)通過頁面的方式進行隔離，賦予用戶對應的頁面權(quán)限就可以查看相應的數(shù)據(jù)。這方案下同樣的功能界面會被分割成很多個功能相同數(shù)據(jù)不同的頁面。

（2）頁面權(quán)限

頁面權(quán)限指的是用戶登錄系統(tǒng)后可以看到哪些頁面的權(quán)限，通常情況下通過導航欄的功能模塊來控制。以門診醫(yī)生和收費員兩個角色為例，門診醫(yī)生可以進入醫(yī)生工作站模塊不能進入收費站；收費員可以進入收費站但是不能進入醫(yī)生工作站。

（3）操作權(quán)限

操作權(quán)限指的是用戶對頁面內(nèi)功能按鈕的具體操作權(quán)限，如：新增,修改,刪除,審核等。這里的功能按鈕指的是該頁面最大的功能按鈕集合，因為現(xiàn)在的設計通常是所見既能操作，如果用戶不具備某個功能的權(quán)限，頁面內(nèi)不會顯示該功能按鈕，以免造成額外的體驗負擔。從大的方面來說頁面權(quán)限和操作權(quán)限可以統(tǒng)稱為功能權(quán)限。

二、權(quán)限設計

1. 權(quán)限設計的相關步驟

在網(wǎng)上查看大量文章后發(fā)現(xiàn)，權(quán)限設計主要有角色梳理、權(quán)限點梳理、權(quán)限模型設計、相關原型設計等幾個步驟。

2. 權(quán)限模型

元素名次解釋：

• 用戶：權(quán)限的擁有者。
• 角色：用于連接主體（用戶）和權(quán)限的橋梁。
• 權(quán)限：用戶可以訪問的資源。

（1）ACL訪問控制列表

通過將用戶與權(quán)限（資源）直接進行關聯(lián)綁定進而實現(xiàn)權(quán)限配置。以實現(xiàn)患者列表頁中刪除功能的權(quán)限配置為例，將刪除功能的權(quán)限直接賦予用戶，被賦予權(quán)限的用戶可執(zhí)行刪除操作。

這種權(quán)限模型的優(yōu)點是可以為用戶提供個性化的權(quán)限配置，缺點是這種方式對權(quán)限的管理比較分散，同一個權(quán)限無法快捷的同時指定給一群用戶，如果需配置的權(quán)限很多，或者用戶基數(shù)很大的時候會非常的費時費力，人工成本極大。

還是以上訴【刪除】功能為例，只有一個人需要【刪除】權(quán)限和有100人需要【刪除】權(quán)限，配置的難度是完全不同的。

（2）DAC自主訪問控制

DAC與ACL的權(quán)限配置方法是相同的，區(qū)別是擁有權(quán)限的用戶可以自主地將權(quán)限賦予給未擁有權(quán)限的用戶。

（3）MAC強制訪問控制

在MAC模型中，用戶與權(quán)限（資源）都具有權(quán)限標識，用戶是否能訪問或執(zhí)行權(quán)限對象取決于雙方關系的對照。以患者列表頁中【刪除】為例，用戶被規(guī)定可以執(zhí)行刪除操作，但是【刪除】的權(quán)限設置中不具有該用戶，則用戶無法執(zhí)行刪除，只有當【刪除】的權(quán)限下同樣具備該用戶時才能執(zhí)行刪除。通常機密強度較高的會采取這種方法。

（4）RBAC基于角色的訪問控制

RBAC認為權(quán)限授權(quán)實際上是 Who What How 的問題, 即 “Who 對 What 進行 How 的操作”。是”用戶”對”資源”的操作, 其中Who是權(quán)限的擁有者 (用戶) , What 是資源（權(quán)限）。

RBAC可以細分為下面四種類型：

• 基本模型 RBAC0 (Core RBAC)
• 角色分層模型 RBAC1 (Hierarchal RBAC)
• 角色限制模型 RBAC2 (Constraint RBAC)
• 統(tǒng)一模型 RBAC3 (Combines RBAC)

RBAC0：

RBAC0是RBAC模型的核心，是支持RBAC模式的任何產(chǎn)品的最低需求，RBAC1、RBAC2、RBAC3都是在其基礎上擴展后得到的。

其主要由用戶、角色、權(quán)限三個元素構(gòu)成，通過將具有權(quán)限集合的角色賦予給用戶，從而使用戶獲得該角色下的權(quán)限。一個用戶可以關聯(lián)多個角色，每個角色可以關聯(lián)多個用戶，同時一個角色也可以關聯(lián)多個權(quán)限，角色通?？梢砸暈橐唤M職能相似的用戶的集合，同時也是一組權(quán)限的集合。

RBAC1：

RBAC1是在RBAC0的基礎上引入了角色繼承的概念，通過繼承使角色之間具有了上下級關系。比如一個父級角色下包括多個子級角色，子級角色的權(quán)限來自于父級角色的一部份。以診所系統(tǒng)醫(yī)師為例，假設將醫(yī)師設定為一個父級角色，普通醫(yī)師、副高級醫(yī)師作為其子級角色，則普通醫(yī)師與副高級醫(yī)師的權(quán)限集合包含于醫(yī)師的權(quán)限集合。

RBAC2：

RBAC2是在RBAC0的基礎上引入角色約束控制（職責分離）。職責分離指的是用戶之間的責任和權(quán)限相互分離，通俗一點說就是同一用戶不能擁有兩種特定的權(quán)限，比如運動員不能是裁判一樣。

系統(tǒng)中職責分離主要有靜態(tài)職責分離和動態(tài)職責分離兩種。

靜態(tài)職責分離：

靜態(tài)職責分離是在用戶和角色的指派階段加入的，主要的約束形式有以下幾種：

• 互斥角色：同一個用戶在兩個互斥角色中只能選擇一個
• 基數(shù)約束：一個用戶擁有的角色是有限的，一個角色擁有的權(quán)限也是有限的
• 先決條件約束：用戶心啊更要活的高級角色，首先必須擁有低級角色

動態(tài)職責分離：

動態(tài)職責分離的表現(xiàn)是一個用戶可以擁有兩個角色，但是運行時只能激活一個角色。

RBAC3：

RBAC3是RBAC1與RBAC2的合集，所以其是既具有角色分層又有約束的模型。

（5）ABAC基于屬性的訪問控制

不同于上面幾種用戶通過某種方式關聯(lián)到權(quán)限的方式，ABAC是通過動態(tài)計算一個或一組屬性是否滿足某種條件而進行授權(quán)判斷。（該模型相對比較復雜，相較于RBAC目前的運用也不廣泛，所以這里就不詳細介紹了，不過有的人稱ABAC是權(quán)限的未來，因為它能夠適應更加復雜的權(quán)限分配場景）

三、SAAS權(quán)限設計（案例）

根據(jù)業(yè)務情況選擇通過RBAC模型與系統(tǒng)的組織架構(gòu)進行權(quán)限設計。

1. 角色關系梳理

權(quán)限設計的前提是合理的角色設計，由于考慮到部分數(shù)據(jù)權(quán)限需要通過組織結(jié)構(gòu)來進行控制，所以在梳理角色時也分為了組織架構(gòu)角色梳理和診所內(nèi)部角色梳理兩個階段。

（1）組織架構(gòu)角色梳理

組織架構(gòu)：

組織架構(gòu)解釋說明：

整個架構(gòu)通過賬號、員工、組織部門來完成搭建?？蛻糁傅氖荢AAS系統(tǒng)的租戶；圖中每一層都設有一個賬號，該賬號可以管理同層的組織；賬號0是SAAS系統(tǒng)根賬號即平臺管理員賬號；賬號1是客戶1的根賬號，是公司負責人擁有，具有新增診所等功能；賬號2代表診所的根賬號，一般被診所負責人擁有；賬號3則是部門科室的負責人賬號；賬號4則是部門其他員工擁有。

角色梳理：

組織架構(gòu)通常在產(chǎn)品初期就已被確定，權(quán)限設計階段只需要抽象角色即可。通過組織架構(gòu)梳理出的角色大都具有向下管理的權(quán)限，即管理員屬性。角色與現(xiàn)實中的職位以及業(yè)務有緊密的關系，可以將角色與職位進行關聯(lián)，然后通過某個職位的工作職責進而確定對應角色在系統(tǒng)中的核心動作有哪些，最后將信息進行整理。

如下：（表中信息僅用來舉例）

（2）診所內(nèi)部角色梳理

診所內(nèi)部的角色即組織架構(gòu)中的員工層，通常在項目前期中的業(yè)務調(diào)研階段就已經(jīng)被確定好，在權(quán)限設計階段同樣可以直接使用。相較于組織架構(gòu)中的角色，診所內(nèi)部角色和患者業(yè)務的關系更加緊密。如下：（表中信息僅用來舉例）

2. 系統(tǒng)權(quán)限點梳理

系統(tǒng)權(quán)限點梳理主要針對頁面權(quán)限和操作權(quán)限。頁面權(quán)限可以通過導航菜單進行梳理，將所有的菜單都列舉出來（包括一級菜單和二級菜單）；操作權(quán)限則是需要梳理出頁面下的所有可操作點，這里要注意有的操作點會應狀態(tài)改變發(fā)生變化，在列舉時也要加上。這一步會得到初步的權(quán)限列表，如下：

3. 權(quán)限方案設計

由于不同企業(yè)、不同診所中對員工職位內(nèi)容的界定不一樣，因此在系統(tǒng)中我們需要提供用戶自定義權(quán)限配置的功能，并將該功能的權(quán)限默認開通給租戶對應的根賬號，通過這個功能用戶可以自定義角色，自定義角色擁有的權(quán)限。大多數(shù)SAAS產(chǎn)品都提供權(quán)限自定義配置的功能。

這里有個問題，既然用戶可以自己進行權(quán)限配置，為什么我們還要花大量時間整理角色和權(quán)限呢？

這是因為用戶并不像我們對權(quán)限非常了解，權(quán)限配置相對用戶來說是一個比價復雜的工作，配置成本高，通常情況下SAAS產(chǎn)品提供者需要對用戶進行這方面的培訓，所以為了減輕權(quán)限配置負擔，我們可以將一部分通用的角色抽象出來，比如租戶根賬號負責人、診所負責人、醫(yī)師、理療師等，為這些角色配置默認權(quán)限供用戶直接使用。

組織架構(gòu)角色通常情況下都可以定義為通用角色。（模型圖省略）

（1）頁面、操作權(quán)限

用戶的頁面權(quán)限和操作權(quán)限通常在權(quán)限配置界面進行勾選即可。

數(shù)據(jù)權(quán)限：

通過系統(tǒng)的組織架構(gòu)我們可以看出不同租戶之間的數(shù)據(jù)需要進行隔離；同一個租戶下不同診所的數(shù)據(jù)也需要進行隔離，但是需要滿足租戶查看所有診所的數(shù)據(jù)的需求。

診所內(nèi)部的數(shù)據(jù)權(quán)限主要集中在患者病歷信息，患者病歷的權(quán)限需要根據(jù)病歷的流轉(zhuǎn)發(fā)生變化。比如一個患者掛號后，患者信息流轉(zhuǎn)至掛號醫(yī)生處，該醫(yī)生獲得查看該患者所有病歷的權(quán)限，醫(yī)生開具收費處方后，患者信息流轉(zhuǎn)至收費處，收費員即獲得查看該患者本次病歷信息的權(quán)限。

根據(jù)用戶對數(shù)據(jù)權(quán)限的需求，可以從以下幾個方面進行實現(xiàn)：

方案一：自定義配置

可以將數(shù)據(jù)權(quán)限同頁面權(quán)限一樣放入自定義權(quán)限配置中，比如查看患者病歷信息用戶通過選擇本公司、本診所、本科室、本人幾個選項去進行數(shù)據(jù)控制。

方案二：借助頁面（功能）隔離數(shù)據(jù)

通過控制角色對頁面的訪問實現(xiàn)患者病歷數(shù)據(jù)的隔離。比如將患者病歷數(shù)據(jù)設計成不同的頁面，如：我的患者、科室患者、診所患者、公司患者，具有“我的患者”頁面權(quán)限的即可查看本人下的患者，具有“科室患者”頁面權(quán)限的即可查看科室下的患者。

方案三：組織架構(gòu)

通過角色將賬號與系統(tǒng)組織架構(gòu)進行關聯(lián)，組織架構(gòu)圖中上級賬號可以查看下級賬號的所有數(shù)據(jù)。

最終的的方案需要結(jié)合實際業(yè)務選擇，在這個案例中選擇通過組織架構(gòu)進行數(shù)據(jù)權(quán)限的控制會更加合適。具體的方案可抽象為：用戶在系統(tǒng)增加一個診所，增加診所的同時系統(tǒng)生成一個診所負責人角色，且該角色不支持修改、刪除，被授予該角色的賬號可以查看診所所有數(shù)據(jù)；用戶在系統(tǒng)增加一個科室，系統(tǒng)默認生成一個該科室管理員角色，且該角色不支持修改、刪除，被授予該角色的賬號即是該部門中的上級賬號，可以查看該部門中的所有數(shù)據(jù)。例如用戶在系統(tǒng)中增加了新的科室–“中醫(yī)科”，在科室生成的同時系統(tǒng)生成該科室的默認管理員角色–“中醫(yī)科主任”。

最后提一點通常平臺管理員賬號的權(quán)限僅限于控制客戶的賬號和相關信息，不能夠控制客戶內(nèi)部的業(yè)務。

4. 梳理用戶獲取權(quán)限流程

用戶獲取權(quán)限主要包括以下場景：

場景一：新員工加入系統(tǒng)配置權(quán)限

為新員工配置權(quán)限的常規(guī)流程是：在員工管理模塊添加員工，填寫基礎信息，選擇部門，然后賦予角色，最后完成權(quán)限配置。由于流程較為簡單這里就略過流程圖了。

場景二：老員工需要更改權(quán)限

老員工更改權(quán)限流程是：在員工管理模塊找到目標員工，更改其系統(tǒng)角色，完成權(quán)限更新。

5. 頁面原型設計

由于頁面原型較為簡單這里僅展示角色與權(quán)限配置界面。

（本案例中的組織架構(gòu)角色與診所內(nèi)角色唯一的差別在于數(shù)據(jù)權(quán)限的不同，其他相關的功能權(quán)限兩者都可以通過自定義權(quán)限配置進行編輯）

四、總結(jié)

B端產(chǎn)品的權(quán)限設計主要包括數(shù)據(jù)權(quán)限與功能權(quán)限（頁面權(quán)限與操作權(quán)限）兩個方面，通常情況下采用RBAC模型實現(xiàn)權(quán)限設計，整體步驟包括角色梳理、權(quán)限點梳理、實際方案設計、原型設計幾個步驟。

B端SAAS產(chǎn)品通常會提供自定義權(quán)限配置功能，以滿足各租戶之間的差異化需求，自定義配置可以很靈活的解決功能權(quán)限的配置，在這方面不需要我們費太多精力。在設計過程中，我們的重心應該放在角色的抽象和數(shù)據(jù)權(quán)限的實現(xiàn)方案兩方面。

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

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