作者 | 百度智慧小程式團隊

導讀

本文首先引入多利熊業務介紹，引出多利熊業務建設許可權系統的痛點，接著分別從許可權系統模型、許可權系統設計以及多利熊業務業務應用方面詳細探討了具體的方案和設計，最後對許可權系統設計思考，對資料維度建設拋磚引玉，讓大家一起思考解決方案。

全文5212字，預計閱讀時間14分鐘。

01 業務介紹

多利熊，是百度旗下的本地生活服務平臺。多利熊旨在為使用者提供特低價優惠的品質服務，基於百度的AI和雙引擎能力，以改變市場格局之勢迅速推進，為本地商家提供豐富的營銷渠道，決心成為本地生活市場的重塑性力量。

多利熊覆蓋餐飲、酒店、景區、休閒娛樂、麗人等眾多品類。使用者可以花更少的錢享受多利熊甄選的本地生活品質服務。成為多利熊分銷達人，自購更省錢，分享直賣可賺取佣金，鎖粉政策可讓達人長期賺取使用者自行下單佣金，發展下游達人組建團隊更可賺取團隊佣金。

多利熊架構是如何支撐起整個業務生態運轉，如下圖所示： 如圖所示，多利熊整個業務架構分位三層。包括：生態場景層、平臺支撐層、基礎建設層。

• 多利熊生態場景：多利熊除了在百度的雙引擎、百家號、私域中進行分發外，還擴充套件到了微信生態圈，建設了多利熊微信小程式，用於在微信生態的分發，通過微信群、微信分享、微信達人引流。除了自建外，也通過合作方式引入第三方服務商、自研商家、本地生活服務平臺，從而打造多元化、多型別的本地生活服務生態圈。

• 多利熊平臺支撐：多利熊建設了大量平臺，包括：商戶平臺、運營平臺、稽核平臺、小編平臺、分發平臺、干預平臺、質量平臺等等。通過豐富的平臺，降低運營成本、提升商家接入效率，從而更好的支撐業務的高速發展，快速迭代。

• 多利熊基礎建設：多利熊的基礎建設層，通過整合小程式及百度中臺的眾多沉澱系統，迅速支撐業務快速迭代。包括：小程式自研的服務化治理方案：天路、天眼、BRCC；小程式沉澱的資料多維度分析報表和穩定性建設監控和治理手段；以及百度豐富的中臺系統：交易中臺、營銷中臺、互動中臺、稽核中臺等等。

從圖中可以看到，整個多利熊業務架構中，平臺角色眾多，許可權系統面臨非常多的挑戰。

• 平臺眾多，各個平臺的賬號系統也會存在差異性。許可權系統如何支援各平臺的隔離設定，保證平臺數據的合規性和安全性？

• 多個平臺中存在眾多業務角色、角色存在上下級關係，大家需要協同工作。許可權系統如何支援高效的配置，保障多角色協同、高效、便利操作？

• 多個平臺基於不同語言開發。許可權系統如何保證接入的便捷性？

具體我們是如何建設，解決這些問題的呢？下面將詳細介紹下。

02 許可權系統介紹

2.1 許可權系統模型

RBAC(role-based access control )：基於角色的許可權訪問控制。

RBAC是一種圍繞角色和許可權定義的訪問控制機制，在RBAC中，許可權與角色相關聯，使用者通過成為適當角色的成員而得到這些角色的許可權。這就極大地簡化了許可權的管理。在一個組織中，角色是為了完成各種工作而創造，使用者則依據它的責任和資格來被指派相應的角色，使用者可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的許可權，而許可權也可根據需要而從某角色中回收。角色與角色的關係可以建立起來以囊括更廣泛的客觀情況。

RBAC四個核心組成部分：

1. S（Subject）：主體，一名使用者或自動代理人

2. R（Role）：角色資訊，被定義為一個授權等級的工作職位或職稱

3. SE（Session）：會話級別的身份許可權表達，S，R或P之間的對映關係

4. P（Permissions）：許可權， 一種存取資源的方式

RBAC 定義了三個主要規則：

1. 角色分配：只有當主體選擇或分配了角色時，主體才能行使許可權

2. 角色授權：主體的活動角色必須為主體授權。使用上面的規則 1，此規則確保使用者只能承擔他們被授權的角色

3. 許可權授權：只有為主體的活動角色授權了許可權，主體才能行使許可權。對於規則 1 和 2，此規則確保使用者只能行使他們被授權的許可權

RBAC的四個模型：

1. Flat RBAC：基本的 RBAC 模型，基本的概念是 使用者被分配給角色，許可權也被分配給角色，使用者通過角色獲取對應的許可權

2. Hierarchical RBAC：角色被組織成分層結構，其中“較高”層級的角色從的“較低”層級的角色繼承所有許可權

3. Constrained RBAC：向角色新增職責分離 (SOD) 的實施

4. Symmetric RBAC：添加了許可權角色審查的要求，類似於 Flat RBAC 中描述的使用者角色審查

四種模型的等級和功能描述：

Flat RBAC模型結構：

Hierarchical RBAC模型結構：

Constrained RBAC模型結構：

靜態職責分離：

1. 互斥角色：同一個使用者在兩個互斥角色中只能選擇一個

2. 基數約束：一個使用者擁有的角色是有限的，一個角色擁有的許可也是有限的

3. 先決條件約束：使用者想要獲得高階角色，首先必須擁有低階角色

動態職責分離：

1. 會話和角色之間的約束，可以動態的約束使用者擁有的角色，如一個使用者可以擁有兩個角色，但是執行時只能啟用一個角色。

Symmetric RBAC模型結構：

2.2 許可權系統設計

RBAC模型如何在我們的實際場景中選型和改造是一件深入思考的事情。首先我們要基於我們的業務場景圈定許可權系統核心功能。

我們做的是本地服務tob業務，所以對於商家我們會有商家平臺，除了商家的管理平臺之外，我們還需要對於o端建設平臺進行管理，以及我們開發同學的干預平臺等，這些平臺都需要許可權管控。每個系統都有各自的頁面，每個頁面都有自己的功能實現，大到頁面許可權的管控，小到按鈕的管控，在未來的業務發展中都是我們許可權系統所需要考慮的。所以我們的許可權管理相對來說任務也是比較繁重的。

針對我們以上的業務場景和需求形態，我們首先敲定了許可權系統的核心職責：

1. 頁面選單許可權的管控

2. 功能組許可權管控

3. 按鈕功能許可權管控

4. 支援多業務線

我們基於Flat RBAC設計瞭如下的RBAC模型：

基於我們設計的RBAC模型，繼續細節的考量

1. 支援多業務線接入和業務線業務隔離

2. 需要支援選單許可權、功能組許可權、按鈕許可權的管控

首先考量業務線支援問題，對於這個事情我們使用了單獨的表來表達產品線資訊，在設計user，role 和 func 表，都需要與業務線資訊表關聯。

於是我們思考如何支援頁面選單許可權、功能組許可權和按鈕許可權的問題。

選單許可權、功能組許可權和按鈕許可權都隸屬於功能許可權，於是我們使用一張表進行功能許可權的表達，和前端頁面的樹形結構表達相對映，構造一個功能許可權樹，於是我們最終落地的ER圖如下：

業務線

對於不同的系統，各自的使用者體系、角色管理、許可權管理都是有差異的，需要滿足不同的系統的訴求，首先要做的是對各個系統的隔離。

我們設計了業務線資訊的表，核心欄位如下：

該表主要描述業務線的基礎資訊內容，用於更好的管理和配置。

業務線隔離的實質是使用者表、角色表和許可權表都需要指定業務線的prod_id，這樣在BRAC模型的三個核心角色裡都做到了業務線隔離，每個系統在使用自己的資料的時候都需要指定自己的prod_id。

使用者

從業務角度分析來看，商家平臺是對外面向商家登入的使用者賬號體系，對於o端來說，是面向我們運營同學，bd同學使用的場景，使用的內部賬號體系，所以，我們這裡就有這不同的使用者登入體系。

我們面臨著多種使用者體系形態，所以，我們就相容不同的使用者體系設計，由此我們設計的使用者表核心欄位如下：

prod_id、user_type 和 login_id 組成聯合唯一建。

角色

FLAT BRAC模型的角色並沒有涉及角色的繼承關係，我們現在的業務沒有涉及到這麼複雜的角色關係，所以我們用最簡單的方式來表達角色資訊，從而減少對於角色身份的管理和維護。

角色的核心欄位如下：

prod_id 和 en_name組成聯合唯一建。

許可權

許可權這塊是我們思考最多的地方，我們希望可以通過統一的標準將前端頁面的功能許可權進行約定。

我們去了解前端使用的設計，無論是b端還是o端前端，都是我們自己的前端團隊，他們講使用統一的前端框架和風格進行設計，這樣對於我們得許可權系統來說就是最好的情況，我們首先需要面對的就是這樣風格的許可權管控。

首先看下我們b端的前端頁面樣式如下：

這裡左側為頁面選單欄，右側為選單欄對應的頁面，裡面就是涉及到的各個功能模組。

我們這裡要處理的就是:

1. 選單欄的許可權管控：選單是否展示，選單層級結構以及選單設計的頁面許可權內容

2. 頁面許可權：頁面裡涉及到的功能許可權

3. 功能組：頁面中某些功能模組的功能許可權

4. 按鈕：按鈕的許可權

於是我們準備改造許可權表為樹狀結構如圖所示：

基於這樣的樹狀結構，我們就可以描述出前端的整個許可權管控內容，許可權的核心欄位如下：

整體的核心設計就是這樣，結合我們的微服務框架理念，我們整體的業務互動圖如下：

現在我們許可權系統已經在支援著多利熊B端平臺和O端平臺的許可權管控，並正在支援小編平臺，後續我們將繼續服務更多平臺的許可權管控。

2.3 多利熊業務應用

基於上述許可權系統的設計，使得多利熊業務在面對龐大的人員組織架構、複雜的業務系統時，也能夠高效、靈活地實現許可權的管理。

如下圖的商務運營系統應用場景所示，該系統是面向內部多個團隊開放的，每個團隊都具有不同的職能，甚至團隊內部也劃分了不同的崗位。

針對該應用場景，系統許可權的分配與管理主要包括以下的步驟：

1. 明確系統角色：如上圖3.1所示，商務運營系統包括商家、商鋪、訂單等在內的多個平臺。針對每個平臺，需要確定好平臺內需要哪些角色，不同角色在平臺內承擔著不同的任務。例如商戶入駐系統包括了幫助商戶入駐的角色、幫助商戶管理成員的角色等。

2. 明確角色許可權：針對角色承擔的具體任務，其對應的系統可操作許可權也是不同的，這就需要每一個角色分配具體的操作許可權。例如幫助商戶入駐的角色，可以有錄入、查詢、修改商家資訊等介面與按鈕的許可權。

3. 明確團隊架構：如上圖3.2所示，稽核管理專案需要有商務、運營、客服等多個團隊，不同團隊下還有相應的崗位來承擔不同的任務。例如商務團隊包括商務小編、商務管理員、商務負責人等崗位。

4. 為團隊成員分配系統角色：為了將系統內的角色許可權與團隊內的組織架構進行結合，如上圖3.3所示，管理人員可以通過角色配置的方式，來為崗位的人員賦予對應平臺的許可權。例如商務小編只有商品管理的角色，而商務可以同時有商品管理角色、商家入駐角色等，這樣就實現了基於角色進行許可權管理的實際應用。

03 許可權系統思考

有了功能許可權，我們進而應該思考另外一塊領域，就是資料許可權。

資料許可權，就是有或者沒有對某些資料的訪問許可權，具體表現形式就是當某使用者有操作許可權的時候，但不代表其對所有的資料都有檢視或者管理許可權。資料許可權有兩種表現形式：一種是行許可權，另外一種是列許可權。

所謂行許可權，就是限制使用者對某些行的訪問許可權，比如：只能對本人、本部門、本組織的資料進行訪問；也可以是根據資料的範圍進行限制，比如：合同額大小來限制使用者對資料的訪問。所謂列許可權，就是限制使用者對某些列的訪問許可權，比如：某些內容的摘要可以被查閱，但是詳細內容就只有VIP使用者才能檢視。

通過資料許可權，可以從物理層級限制使用者對資料的行或列進行獲取，這種方式比把所有資料拿到之後再根據使用者許可權來限制某些行或列有諸多好處。以列表資料許可權為例，主要通過資料許可權控制行資料，讓不同的人有不同的檢視資料規則；要實現資料許可權，最重要的是需要抽象出資料規則。

但是光有資料規則是不夠的，我們還需要把資料規則跟資源和使用者進行繫結。這樣資源就可以關聯上了資料規則。

在設計上我們需要一個單獨的資料規則管理功能，方便我們錄入資料規則，然後在資源管理頁面上就可以選擇內建的資料規則進行資源與規則的繫結。

那麼如何讓不同的使用者擁有不同的資料規則呢？

在RBAC模型中，使用者是通過授予不同的角色來進行資源的管理，同理我們可以讓角色在授予許可權的時候關聯上資料規則，這樣最終在系統上就體現為不同的使用者擁有不同的資料規則。

基於此，我們可以基本實現RBAC與資料規則的繫結；同時資料許可權是一個實現相對比較複雜的功能，除了在RBAC模型基礎上進行擴充套件，是否還有其他更合理的思路，留給大家進行思考。

——END——

參考資料：

[1]http://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf

推薦閱讀：

分散式系統關鍵路徑延遲分析實踐

百度工程師教你玩轉設計模式（裝飾器模式）

百度工程師帶你體驗引擎中的nodejs

揭祕百度智慧測試在測試定位領域實踐

百度工程師帶你探祕C++記憶體管理（ptmalloc篇）

為什麼 OpenCV 計算的視訊 FPS 是錯的