本文首先引入多利熊業(yè)務介紹，引出多利熊業(yè)務建設權(quán)限系統(tǒng)的痛點，接著分別從權(quán)限系統(tǒng)模型、權(quán)限系統(tǒng)設計以及多利熊業(yè)務業(yè)務應用方面詳細探討了具體的方案和設計，最后對權(quán)限系統(tǒng)設計思考，對數(shù)據(jù)維度建設拋磚引玉，讓大家一起思考解決方案。

GEEK TALK

01

業(yè)務介紹

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

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

多利熊架構(gòu)是如何支撐起整個業(yè)務生態(tài)運轉(zhuǎn)，如下圖所示：

如圖所示，多利熊整個業(yè)務架構(gòu)分位三層。包括：生態(tài)場景層、平臺支撐層、基礎建設層。

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

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

• 多利熊基礎建設：多利熊的基礎建設層，通過集成小程序及百度中臺的眾多沉淀系統(tǒng)，迅速支撐業(yè)務快速迭代。包括：小程序自研的服務化治理方案：天路、天眼、BRCC；小程序沉淀的數(shù)據(jù)多維度分析報表和穩(wěn)定性建設監(jiān)控和治理手段；以及百度豐富的中臺系統(tǒng)：交易中臺、營銷中臺、互動中臺、審核中臺等等。

從圖中可以看到，整個多利熊業(yè)務架構(gòu)中，平臺角色眾多，權(quán)限系統(tǒng)面臨非常多的挑戰(zhàn)。

• 平臺眾多，各個平臺的賬號系統(tǒng)也會存在差異性。權(quán)限系統(tǒng)如何支持各平臺的隔離設置，保證平臺數(shù)據(jù)的合規(guī)性和安全性？

• 多個平臺中存在眾多業(yè)務角色、角色存在上下級關(guān)系，大家需要協(xié)同工作。權(quán)限系統(tǒng)如何支持高效的配置，保障多角色協(xié)同、高效、便利操作？

• 多個平臺基于不同語言開發(fā)。權(quán)限系統(tǒng)如何保證接入的便捷性？

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

GEEK TALK

02

權(quán)限系統(tǒng)介紹

2.1權(quán)限系統(tǒng)模型

RBAC(role-based access control)：基于角色的權(quán)限訪問控制。

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

RBAC四個核心組成部分：

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

2. R（Role）：角色信息，被定義為一個授權(quán)等級的工作職位或職稱

3. SE（Session）：會話級別的身份權(quán)限表達，S，R或P之間的映射關(guān)系

4. P（Permissions）：權(quán)限，一種存取資源的方式

RBAC 定義了三個主要規(guī)則：

1. 角色分配：只有當主體選擇或分配了角色時，主體才能行使權(quán)限

2. 角色授權(quán)：主體的活動角色必須為主體授權(quán)。使用上面的規(guī)則 1，此規(guī)則確保用戶只能承擔他們被授權(quán)的角色

3. 權(quán)限授權(quán)：只有為主體的活動角色授權(quán)了權(quán)限，主體才能行使權(quán)限。對于規(guī)則 1 和 2，此規(guī)則確保用戶只能行使他們被授權(quán)的權(quán)限

RBAC的四個模型：

1. Flat RBAC：基本的 RBAC 模型，基本的概念是 用戶被分配給角色，權(quán)限也被分配給角色，用戶通過角色獲取對應的權(quán)限

2. Hierarchical RBAC：角色被組織成分層結(jié)構(gòu)，其中“較高”層級的角色從的“較低”層級的角色繼承所有權(quán)限

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

4. Symmetric RBAC：添加了權(quán)限角色審查的要求，類似于 Flat RBAC 中描述的用戶角色審查

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

Flat RBAC模型結(jié)構(gòu)：

Hierarchical RBAC模型結(jié)構(gòu)：

Constrained RBAC模型結(jié)構(gòu)：

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

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

2. 基數(shù)約束：一個用戶擁有的角色是有限的，一個角色擁有的許可也是有限的

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

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

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

Symmetric RBAC模型結(jié)構(gòu)：

2.2權(quán)限系統(tǒng)設計

RBAC模型如何在我們的實際場景中選型和改造是一件深入思考的事情。首先我們要基于我們的業(yè)務場景圈定權(quán)限系統(tǒng)核心功能。

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

針對我們以上的業(yè)務場景和需求形態(tài)，我們首先敲定了權(quán)限系統(tǒng)的核心職責：

1. 頁面菜單權(quán)限的管控

2. 功能組權(quán)限管控

3. 按鈕功能權(quán)限管控

4. 支持多業(yè)務線

我們基于Flat RBAC設計了如下的RBAC模型：

基于我們設計的RBAC模型，繼續(xù)細節(jié)的考量

1. 支持多業(yè)務線接入和業(yè)務線業(yè)務隔離

2. 需要支持菜單權(quán)限、功能組權(quán)限、按鈕權(quán)限的管控

首先考量業(yè)務線支持問題，對于這個事情我們使用了單獨的表來表達產(chǎn)品線信息，在設計user，role 和 func 表，都需要與業(yè)務線信息表關(guān)聯(lián)。

于是我們思考如何支持頁面菜單權(quán)限、功能組權(quán)限和按鈕權(quán)限的問題。

菜單權(quán)限、功能組權(quán)限和按鈕權(quán)限都隸屬于功能權(quán)限，于是我們使用一張表進行功能權(quán)限的表達，和前端頁面的樹形結(jié)構(gòu)表達相映射，構(gòu)造一個功能權(quán)限樹，于是我們最終落地的ER圖如下：

業(yè)務線

對于不同的系統(tǒng)，各自的用戶體系、角色管理、權(quán)限管理都是有差異的，需要滿足不同的系統(tǒng)的訴求，首先要做的是對各個系統(tǒng)的隔離。

我們設計了業(yè)務線信息的表，核心字段如下：

該表主要描述業(yè)務線的基礎信息內(nèi)容，用于更好的管理和配置。

業(yè)務線隔離的實質(zhì)是用戶表、角色表和權(quán)限表都需要指定業(yè)務線的prod_id，這樣在BRAC模型的三個核心角色里都做到了業(yè)務線隔離，每個系統(tǒng)在使用自己的數(shù)據(jù)的時候都需要指定自己的prod_id。

用戶

從業(yè)務角度分析來看，商家平臺是對外面向商家登錄的用戶賬號體系，對于o端來說，是面向我們運營同學，bd同學使用的場景，使用的內(nèi)部賬號體系，所以，我們這里就有這不同的用戶登錄體系。

我們面臨著多種用戶體系形態(tài)，所以，我們就兼容不同的用戶體系設計，由此我們設計的用戶表核心字段如下：

prod_id、user_type 和 login_id 組成聯(lián)合唯一建。

角色

FLAT BRAC模型的角色并沒有涉及角色的繼承關(guān)系，我們現(xiàn)在的業(yè)務沒有涉及到這么復雜的角色關(guān)系，所以我們用最簡單的方式來表達角色信息，從而減少對于角色身份的管理和維護。

角色的核心字段如下：

prod_id 和 en_name組成聯(lián)合唯一建。

權(quán)限

權(quán)限這塊是我們思考最多的地方，我們希望可以通過統(tǒng)一的標準將前端頁面的功能權(quán)限進行約定。

我們?nèi)チ私馇岸耸褂玫脑O計，無論是b端還是o端前端，都是我們自己的前端團隊，他們講使用統(tǒng)一的前端框架和風格進行設計，這樣對于我們得權(quán)限系統(tǒng)來說就是最好的情況，我們首先需要面對的就是這樣風格的權(quán)限管控。

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

這里左側(cè)為頁面菜單欄，右側(cè)為菜單欄對應的頁面，里面就是涉及到的各個功能模塊。

我們這里要處理的就是:

1. 菜單欄的權(quán)限管控：菜單是否展示，菜單層級結(jié)構(gòu)以及菜單設計的頁面權(quán)限內(nèi)容

2. 頁面權(quán)限：頁面里涉及到的功能權(quán)限

3. 功能組：頁面中某些功能模塊的功能權(quán)限

4. 按鈕：按鈕的權(quán)限

于是我們準備改造權(quán)限表為樹狀結(jié)構(gòu)如圖所示：

基于這樣的樹狀結(jié)構(gòu)，我們就可以描述出前端的整個權(quán)限管控內(nèi)容，權(quán)限的核心字段如下：

整體的核心設計就是這樣，結(jié)合我們的微服務框架理念，我們整體的業(yè)務交互圖如下：

現(xiàn)在我們權(quán)限系統(tǒng)已經(jīng)在支持著多利熊B端平臺和O端平臺的權(quán)限管控，并正在支持小編平臺，后續(xù)我們將繼續(xù)服務更多平臺的權(quán)限管控。

2.3多利熊業(yè)務應用

基于上述權(quán)限系統(tǒng)的設計，使得多利熊業(yè)務在面對龐大的人員組織架構(gòu)、復雜的業(yè)務系統(tǒng)時，也能夠高效、靈活地實現(xiàn)權(quán)限的管理。

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

針對該應用場景，系統(tǒng)權(quán)限的分配與管理主要包括以下的步驟：

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

2. 明確角色權(quán)限：針對角色承擔的具體任務，其對應的系統(tǒng)可操作權(quán)限也是不同的，這就需要每一個角色分配具體的操作權(quán)限。例如幫助商戶入駐的角色，可以有錄入、查詢、修改商家信息等接口與按鈕的權(quán)限。

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

4. 為團隊成員分配系統(tǒng)角色：為了將系統(tǒng)內(nèi)的角色權(quán)限與團隊內(nèi)的組織架構(gòu)進行結(jié)合，如上圖3.3所示，管理人員可以通過角色配置的方式，來為崗位的人員賦予對應平臺的權(quán)限。例如商務小編只有商品管理的角色，而商務可以同時有商品管理角色、商家入駐角色等，這樣就實現(xiàn)了基于角色進行權(quán)限管理的實際應用。

GEEK TALK

03

權(quán)限系統(tǒng)思考

有了功能權(quán)限，我們進而應該思考另外一塊領(lǐng)域，就是數(shù)據(jù)權(quán)限。

數(shù)據(jù)權(quán)限，就是有或者沒有對某些數(shù)據(jù)的訪問權(quán)限，具體表現(xiàn)形式就是當某用戶有操作權(quán)限的時候，但不代表其對所有的數(shù)據(jù)都有查看或者管理權(quán)限。數(shù)據(jù)權(quán)限有兩種表現(xiàn)形式：一種是行權(quán)限，另外一種是列權(quán)限。

所謂行權(quán)限，就是限制用戶對某些行的訪問權(quán)限，比如：只能對本人、本部門、本組織的數(shù)據(jù)進行訪問；也可以是根據(jù)數(shù)據(jù)的范圍進行限制，比如：合同額大小來限制用戶對數(shù)據(jù)的訪問。所謂列權(quán)限，就是限制用戶對某些列的訪問權(quán)限，比如：某些內(nèi)容的摘要可以被查閱，但是詳細內(nèi)容就只有VIP用戶才能查看。

通過數(shù)據(jù)權(quán)限，可以從物理層級限制用戶對數(shù)據(jù)的行或列進行獲取，這種方式比把所有數(shù)據(jù)拿到之后再根據(jù)用戶權(quán)限來限制某些行或列有諸多好處。以列表數(shù)據(jù)權(quán)限為例，主要通過數(shù)據(jù)權(quán)限控制行數(shù)據(jù)，讓不同的人有不同的查看數(shù)據(jù)規(guī)則；要實現(xiàn)數(shù)據(jù)權(quán)限，最重要的是需要抽象出數(shù)據(jù)規(guī)則。

但是光有數(shù)據(jù)規(guī)則是不夠的，我們還需要把數(shù)據(jù)規(guī)則跟資源和用戶進行綁定。這樣資源就可以關(guān)聯(lián)上了數(shù)據(jù)規(guī)則。

在設計上我們需要一個單獨的數(shù)據(jù)規(guī)則管理功能，方便我們錄入數(shù)據(jù)規(guī)則，然后在資源管理頁面上就可以選擇內(nèi)置的數(shù)據(jù)規(guī)則進行資源與規(guī)則的綁定。

那么如何讓不同的用戶擁有不同的數(shù)據(jù)規(guī)則呢？

在RBAC模型中，用戶是通過授予不同的角色來進行資源的管理，同理我們可以讓角色在授予權(quán)限的時候關(guān)聯(lián)上數(shù)據(jù)規(guī)則，這樣最終在系統(tǒng)上就體現(xiàn)為不同的用戶擁有不同的數(shù)據(jù)規(guī)則。

基于此，我們可以基本實現(xiàn)RBAC與數(shù)據(jù)規(guī)則的綁定；同時數(shù)據(jù)權(quán)限是一個實現(xiàn)相對比較復雜的功能，除了在RBAC模型基礎上進行擴展，是否還有其他更合理的思路，留給大家進行思考。