後臺產品設計系列：單系統與多系統的使用者許可權設計（五）

上篇，給大家介紹了後臺產品比較通用的五個原型設計要點，此篇，筆者將介紹後臺產品另一個通用設計——使用者許可權設計。

由於保密、體驗、安全等多種因素，使用者許可權設計成為每個後臺產品的必備功能。那麼作為產品經理，面對不同複雜度的系統，又該如何來做呢？

目前，使用者許可權設計最主流的方式是基於RBAC模型的使用者、角色、許可權的設計，這種基於角色的許可權設計能夠非常靈活、高效，並應對更多場景的需求。不過，雖然理論基礎一樣，單系統的使用者許可權與多系統的使用者許可權在實際產品設計中，卻存在較大差異。

本篇，筆者將分享基於RBAC模型的單系統許可權設計和在此基礎上拓展的多系統許可權設計。

一、RBAC模型概述

1。 RBAC是什麼

RBAC模型：Role-Based Access Control，基於角色的訪問控制。

名稱有點拗口，具體怎麼理解呢？

重點就是這個角色。舉個栗子：小王是名財務，能夠審批報銷單和發工資。在這個場景裡，“小王”就是“使用者”，“財務”就是“角色”，“審批報銷單和發工資”就是“許可權”，在沒有引入“角色”前，許可權都是直接指給使用者的，就是“小王能夠審批報銷單和發工資”，那麼這裡就有問題了。

到底什麼樣的人才能審批報銷單和發工資呢？我們需要做一個歸類，比如把這一批人歸為財務，把那一批人歸為領導親戚，就是把擁有同樣許可權的人設定一個“角色”，進行歸類。

如果沒有角色，那麼擁有同樣許可權的人就得每個都配一遍，有人員流動時又要再配一次，很麻煩。引入“角色”後，我們把許可權指派給“角色”，這樣在配許可權時，只需要將“使用者”關聯上角色就可以了。

透過下圖連線條數就可以看出哪種方式更簡單：

整個RBAC的核心就是這個。那麼根據這套模型功能的複雜程度不同，由簡單到複雜又可以分為RBAC-0、RBAC-1、RBAC-2、RBAC-3四個層級。

2。 RBAC的四大模型

RBAC-0

RBAC-0是最基礎的，就是在使用者與角色、角色與許可權間建立關係，每種關係均為多對多。

RBAC-1

RBAC-1是在RBAC-0的基礎上，增加了繼承關係。就是一個角色只能有另一角色的部分許可權，這個角色的許可權大小受另一角色許可權影響。例如：財務主管有三個許可權，那麼財務專員的許可權一定要小於主管的許可權，所以上班就不能扯犢子，只能主管可以。

如果財務主管有需求，我們還應在角色許可權配置頁面，給財務主管自己配置財務專員的的許可權，由財務主管自由設定財務專員的使用者是誰、許可權有哪些，哪天主管自己一個人扯得無聊，就可以自己偷偷在配置頁面給專員也開個“上班扯犢子”許可權，然後兩個人就可以愉快的互扯了，扯完了再自己手動關掉，美滋滋。

RBAC-2

從上面的例子中，我們可以看到，如果使用者、角色、許可權完全自由，隨意配置，會存在很大風險，領導小舅子既當財務主管，又當老闆秘書，財政大權和老闆行程全被掌控。於是，老闆就規定：任何一個人，“財務主管”與“老闆秘書”兩個角色只能二選一。

這種許可權模式就是我們的RBAC-2，在使用者、角色、許可權三者間增加各種限制條件，例如每個使用者角色最多兩種：一個使用者不能同時擁有某兩個有關聯的角色；一個使用者同時只能以一種角色身份登入等等。

RBAC-3

RBAC-3是RBAC-1與RBAC-2的結合，就是既有繼承關係，又有限制條件，基礎都一樣。

介紹完理論基礎，再來分享這套理論在單系統與多系統中的應用

二、單系統的許可權設計

當我們針對一個單一系統做許可權設計時，我們需要在系統中將使用者、角色、許可權三個實體都管理起來，設計對應的配置頁面。

1。 使用者管理

使用者管理模組，主要功能是將此係統使用者進行管理，一般而言，系統中需要做使用者資訊維護的，使用者數都比較小，所以不用做太多其他功能，只需維護幾個簡單欄位就可以了。

對於如何建立使用者這個問題，需區分不同場景。如果是公司內部使用的系統，不需要做註冊功能，直接在系統中由管理員手動新增使用者，而使用者的賬號密碼既可按某一指定規則自動生成，也可以手動錄入。

根據需求，可選擇是否開放使用者登入後修改自己密碼的許可權；而如果是To B的產品，則需要設計註冊功能，供免費註冊體驗等，而註冊的使用者，則預設為管理員角色，然後由註冊使用者自己新增其他使用者。

2。 角色管理

角色作為使用者與許可權的中間方，無法獨立存在。角色的定義是完全基於業務需求來確定的，很多時候角色容易與公司組織架構中的職位混淆，然後在角色定義時總想著與公司各職位保持一致。但其實這種強行一致是沒有必要的，業務需要定義什麼角色，就定義那個角色就好，職位和角色可能有對應關係，但並不相同，也許稱呼一樣，但分屬不同實體管理。

3。 許可權管理

按用途來分，許可權可以分為資料許可權和操作許可權。

（1）資料許可權

資料許可權是指使用者是否能夠看到某些資料。主要應用在資料有保密要求，或資料量大，需按使用者或角色來進行區分時。例如：財務主管在後臺可以看到公司所有人的工資流水，但普通員工只能看到自己的工資流水。

在這裡，有的同學或許認為，既然我們的許可權是跟角色關聯，為什麼“檢視工資流水”這個許可權精確到每個使用者了呢？

其實這就是RBAC-2的一種，許可權與角色關聯後增加了限制條件，不過這種限制條件無法在頁面上靈活配置。

資料許可權的顆粒度由粗到細可以分為選單級、欄目級、欄位級，一般配置頁面都可以靈活操作。

（2）操作許可權

操作許可權是指使用者是否能夠操作對應按鈕。需要先有資料許可權，才有操作許可權，所以需要增加系統自動校驗：

選擇了操作許可權，就預設勾選了檢視（資料）許可權；

取消了資料許可權，就自動取消了操作許可權

以上就是我們做單系統的許可權設計分享的內容。在多系統的許可權設計中，雖然理論基礎一樣，但因為涉及到多個系統，所以產生了很多其他問題，需要另外解決。

三、多系統的許可權設計

1。 多系統許可權設計場景

場景一：多個子系統共屬於同一母系統，同時每個子系統已微服務化，程式碼不耦合；

場景二：多系統各自獨立，每個系統都要做使用者許可權設計，使用者都是同一批人，例如都是公司所有員工，這種場景在大公司經常可見。

2。 兩種場景下產生的問題

場景一：

Q1：既然每個子系統已分離，那麼是針對母系統做一個許可權管理模組還是每個子系統分別做一個？如果是針對母系統來做，就意味著這個模組需要跟每個子系統對接，而如果每個子系統做一個，業務上使用者、角色會有重複，會導致資源浪費，並讓母系統不再像一個整體的產品。

場景二：

Q1：多個系統，使用者重合時，使用者資訊在一處管理還是多處管理？

Q2：一個角色多個系統要用，是否也可以統一管理？例如：專案經理，在不同的系統中，均有此角色，是否可以複用？

Q3：有的角色下的使用者能否無需配置，跟職位掛鉤，使用者入職時錄入的使用者管理系統就自動在對應系統有了角色？

3。 解決方案

無論是單系統還是多系統，使用者許可權設計都是圍繞使用者、角色、許可權三者間的關係展開的，只是在多系統中，需要增加考慮的是這三者分別在哪裡配置及是否需要跟其他資訊關聯的問題。

場景一

Q1：針對母系統做一個許可權管理模組，一方面對外，母系統才是一個產品，另一方面能節約資源。但是因為子系統間的解耦，我們做的這個許可權管理模組也要當做一個小的子系統來做，然後與其他子系統做對接，如果架構組不因此單獨給資源，可以做到其中一個子系統中，透過這個子系統控制其他子系統的使用者許可權。

場景二

Q1：所有使用者資訊在一處維護。建立一個第三方系統——使用者管理系統，單獨管理使用者資訊，跟其他各個系統對接，而角色和許可權由各個系統自己管理。這種做法的好處不僅可以節省資源，還可以保證資料的一致性，同時需要引入使用者組的概念。使用者組可以是同一崗位的使用者集合，也可以自定義同一類人的集合，這樣在關聯使用者時，就可以批次操作。

Q2：如果一個角色多個系統共用，是不需要有一個類似使用者管理系統那種單獨的管理系統的，因為角色無法獨立存在，角色必須依賴許可權，而許可權一定是在各個系統中獨自管理，即使共用角色有一個統一管理的地方，在各個系統仍需管理，所以沒有這個必要。

Q3：在管理使用者時，可以增加“職位”的資訊管理，由原來的“使用者——角色——許可權”變為“使用者——職位——角色——許可權”，將“職位”與“角色”直接關聯，“使用者”與“角色”就可以透過“職位”間接關聯，每次有新員工入職時，設定好其職位，那麼各個系統的角色也就確定了，快速方便。