中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)讀：“權(quán)限控制”是中后臺(tái)的基礎(chǔ)能力，用于管控操作人員在平臺(tái)內(nèi)可做的事項(xiàng)內(nèi)容。即通過權(quán)限控制，可以決定哪些人在平臺(tái)內(nèi)可以做哪些事。本文作者圍繞角色&屬性的權(quán)限設(shè)計(jì)展開分析，希望對你有幫助。

Hello，我是一名交互設(shè)計(jì)師。

隨著3月暖春的即將到來，蘇州的疫情卻似乎沒有好轉(zhuǎn)的跡象，于是被迫居家隔離的我，反而有了更多的時(shí)間來思考復(fù)盤自己參與B端設(shè)計(jì)后的一些收獲。

我現(xiàn)在參與的項(xiàng)目是資源生產(chǎn)中臺(tái)，說白了，就是當(dāng)字節(jié)內(nèi)部的業(yè)務(wù)需要某類資源時(shí)（如教育業(yè)務(wù)需要題目資源、電商業(yè)務(wù)需要競品價(jià)格資源、房產(chǎn)業(yè)務(wù)需要房源數(shù)據(jù)資源等等），它們可以選擇聯(lián)系資源生產(chǎn)中臺(tái)，我們將根據(jù)業(yè)務(wù)的預(yù)算提供合規(guī)的資源采集，當(dāng)然我們都知道，對企業(yè)而言，這類預(yù)算當(dāng)然是越少越好。

那么，為了幫助企業(yè)降低預(yù)算，中臺(tái)便開拓了眾包業(yè)務(wù)（其實(shí)BAT早就開拓了），具備高學(xué)歷的全職奶媽、在校大學(xué)生、兼職老師這批Freelancer群體，可以通過我們的眾包平臺(tái)注冊為生產(chǎn)員進(jìn)行接單，來幫助消化業(yè)務(wù)部門的資源采集訴求，從而也可以為自己賺取一筆額外的收入。

起初，為了快速搭建平臺(tái)，我們在權(quán)限上做了簡單處理，管理員和生產(chǎn)員在平臺(tái)內(nèi)的權(quán)限僅能通過研發(fā)和運(yùn)營進(jìn)行手動(dòng)表格配置（可以參考下文中的ACL模型），然而隨著業(yè)務(wù)的不斷增多和平臺(tái)人員的快速擴(kuò)張，我們發(fā)現(xiàn)了一個(gè)嚴(yán)重的問題：

因?yàn)闄?quán)限設(shè)計(jì)的比較簡單，隨著業(yè)務(wù)需求的定制化或用戶類別的細(xì)分化，已經(jīng)開始大量占用研發(fā)時(shí)間和運(yùn)營人力，這種現(xiàn)象嚴(yán)重違背了中臺(tái)“降本提效“的初衷。

那么為了解決這個(gè)問題，我們需要對眾包平臺(tái)的權(quán)限系統(tǒng)進(jìn)行重構(gòu)設(shè)計(jì)，實(shí)現(xiàn)靈活智能的平臺(tái)權(quán)限配置，減少對研發(fā)和運(yùn)營的人力占用，以下是我在進(jìn)行設(shè)計(jì)時(shí)的一些思考和嘗試：

一、什么是權(quán)限控制

“權(quán)限控制”是中后臺(tái)的基礎(chǔ)能力，用于管控操作人員在平臺(tái)內(nèi)可做的事項(xiàng)內(nèi)容。即通過權(quán)限控制，可以決定哪些人在平臺(tái)內(nèi)可以做哪些事。

1.1 權(quán)限控制的價(jià)值

• 可以讓管理者基于安全規(guī)則和策略，配置不同用戶合理訪問對應(yīng)資源；
• 可以讓用戶能夠在有效的限制范圍內(nèi)訪問被授權(quán)的資源。

在B端場景中，通過權(quán)限控制可以讓工作群組內(nèi)不同的角色專注于自己的工作范圍，可以降低操作風(fēng)險(xiǎn)發(fā)生概率，便于進(jìn)一步管理。

1.2 權(quán)限控制的應(yīng)用場景

權(quán)限控制的應(yīng)用主要有兩種場景：

版本管理場景

基于版本進(jìn)行產(chǎn)品權(quán)限的分配和控制，該場景主要應(yīng)用于有商業(yè)化訴求的B端產(chǎn)品。 通過權(quán)限控制將產(chǎn)品功能切割為普通權(quán)限功能和高級權(quán)限功能，從而衍生出普通版和高級版，甚至更多版本的產(chǎn)品。 這些版本功能范圍基本處于一個(gè)包含關(guān)系，如下圖的企業(yè)版就包含了標(biāo)準(zhǔn)版的功能權(quán)限。

權(quán)限管理場景

基于角色或?qū)傩砸?guī)則進(jìn)行產(chǎn)品權(quán)限的分配和控制，該場景適用于邏輯復(fù)雜模塊繁多需要提升工作效率的B端產(chǎn)品。 通常一個(gè)角色對應(yīng)一組靜態(tài)權(quán)限，而一個(gè)用戶可能有多個(gè)角色，如下圖“分析師”角色便對應(yīng)了一組數(shù)據(jù)權(quán)限。

通常一組屬性規(guī)則對應(yīng)一組動(dòng)態(tài)權(quán)限，如下圖授權(quán)規(guī)則便對應(yīng)了一個(gè)主體的動(dòng)態(tài)資源權(quán)限。

在B端中后臺(tái)的設(shè)計(jì)中，最常見的應(yīng)用場景為“權(quán)限管理”，權(quán)限管理涉及的維度也會(huì)比版本管理更為復(fù)雜。

二、怎么設(shè)計(jì)權(quán)限控制？

2.1 了解和選擇權(quán)限技術(shù)模型

權(quán)限控制的實(shí)現(xiàn)依賴于技術(shù)實(shí)現(xiàn)，而常見的技術(shù)模型主要分成如下3類：

• 【ACL】Access Control Lists 訪問控制列表
• 【RBAC】Role-based Access Control 基于角色的權(quán)限訪問模型
• 【ABAC】Attribute-Based Access Control 基于屬性的權(quán)限訪問模型

不同體量的權(quán)限系統(tǒng)，我們可以參考不同的權(quán)限模型進(jìn)行梳理和設(shè)計(jì)。 【ACL】訪問控制列表 ACL通常用于配置哪些用戶可以訪問操作哪些資源。當(dāng)權(quán)限系統(tǒng)體量小，用戶有直接對應(yīng)具體功能點(diǎn)即可滿足系統(tǒng)訴求時(shí)，可以考慮使用ACL模型作為參考。 實(shí)現(xiàn)原理：每一項(xiàng)資源，都配有一個(gè)列表，這個(gè)列表記錄的就是哪些用戶可以對這項(xiàng)資源操作。當(dāng)系統(tǒng)試圖訪問這項(xiàng)資源時(shí)，會(huì)首先檢查這個(gè)列表中是否有關(guān)于當(dāng)前用戶的訪問權(quán)限，從而確定當(dāng)前用戶可否執(zhí)行相應(yīng)的操作。 ACL權(quán)限中，只有用戶、資源這兩個(gè)要素：

• 用戶：是發(fā)起操作的主體，可以是1個(gè)人，也可以是1個(gè)用戶群組。例如：后臺(tái)管理系統(tǒng)的用戶、OA系統(tǒng)的內(nèi)部員工、設(shè)計(jì)部門等。
• 資源：用戶可以訪問操作的客體，例如：頁面、文檔、數(shù)據(jù)等。

ACL常用于部門隔離場景，適用資源如人事頁面、客戶頁面。如下圖部門成員配置頁，通過Excel表格來一次性批量導(dǎo)入部門成員信息，使這批成員在提交后自動(dòng)獲取該部門下的數(shù)據(jù)權(quán)限。

拓展：【DAC】自主訪問

DAC在ACL基礎(chǔ)上，增加了權(quán)力下放的能力，允許擁有權(quán)限的用戶再次將權(quán)限授予其他用戶。

DAC常用于文件管理場景，適用資源如培訓(xùn)文檔。如下圖所示，擁有文檔編輯權(quán)限的用戶可以將編輯權(quán)限再次授予其他用戶。

拓展：【MAC】強(qiáng)制訪問

MAC在ACL基礎(chǔ)上，增加了雙重驗(yàn)證的限制，要求用戶和要訪問的資源必須具備相應(yīng)的安全等級關(guān)系才可獲取權(quán)限。

MAC常用于保密信息場景，適用資源如保密數(shù)據(jù)。如絕密級的財(cái)務(wù)數(shù)據(jù)只能被企業(yè)高級用戶查看、訪客級用戶無法查看企業(yè)級的文檔、機(jī)密級的部門架構(gòu)信息僅能被部門負(fù)責(zé)人級別的賬號查看。

ACL模型優(yōu)勢： 研發(fā)實(shí)現(xiàn)快速簡單，不需要耗費(fèi)較多開發(fā)成本。

ACL模型劣勢： 當(dāng)擁有大量用戶和資源時(shí)，維護(hù)成本變得極高，每次有新用戶&新資源加入時(shí)都需要重新挨個(gè)配置每個(gè)用戶與每個(gè)資源的關(guān)系，不適用于頻繁變更用戶權(quán)限的場景。

【RBAC】基于角色的權(quán)限訪問模型

RBAC通常用于配置哪些角色擁有哪些權(quán)限，而哪些用戶可以擁有這些角色。 實(shí)現(xiàn)原理：把用戶按角色進(jìn)行歸類，通過用戶的角色來確定用戶能否針對某項(xiàng)資源進(jìn)行某項(xiàng)操作。 RBAC模型的三要素為：用戶、角色、權(quán)限。

• 用戶：是發(fā)起操作的主體，可以是1個(gè)人，也可以是1個(gè)用戶群組。例如：后臺(tái)管理系統(tǒng)的用戶、OA系統(tǒng)的內(nèi)部員工、設(shè)計(jì)部門等。
• 角色：用于連接了用戶和權(quán)限的橋梁，每個(gè)角色可以關(guān)聯(lián)多個(gè)權(quán)限，同時(shí)一個(gè)用戶也可以關(guān)聯(lián)多個(gè)角色，那么這個(gè)用戶就有了多個(gè)角色的多個(gè)權(quán)限。
• 權(quán)限：用戶可以訪問的資源權(quán)限，包括：頁面權(quán)限、操作權(quán)限、數(shù)據(jù)權(quán)限。

RBAC常用于企業(yè)數(shù)據(jù)和功能管理場景。如下圖當(dāng)某用戶被分配分析師角色時(shí)，則該用戶賬號自動(dòng)獲取了分析師角色下的所有權(quán)限。

拓展：【RBAC1】角色分層

RBAC1模型是在RBAC模型基礎(chǔ)上，引入了角色分層的概念，即角色具有上下級的關(guān)系，每個(gè)等級對應(yīng)不同的權(quán)限組，從而實(shí)現(xiàn)更細(xì)粒度的權(quán)限管理。

RBAC1常用于角色內(nèi)的多級別分層場景。如下圖，通過權(quán)限組的形式對管理員角色進(jìn)行再次權(quán)限分層，例如可以將設(shè)計(jì)師角色分成設(shè)計(jì)師、設(shè)計(jì)主管、設(shè)計(jì)經(jīng)理和設(shè)計(jì)總監(jiān)等多級權(quán)限。

拓展：【RBAC2】 角色限制

RBAC2模型是在RBAC模型基礎(chǔ)上，增加對角色的限制約束。主要包括以下約束:

互斥關(guān)系: 同一用戶只能分配到一組互斥角色集合中至多一個(gè)角色，互斥角色是指各自權(quán)限互相制約的兩個(gè)角色。例如一個(gè)用戶不能同時(shí)具備銷售和財(cái)務(wù)2個(gè)角色，否則就可以自己審批自己的報(bào)銷申請了。

基數(shù)約束:

• 一個(gè)角色被分配的用戶數(shù)量受限，例如一個(gè)部門內(nèi)能只能存在1個(gè)總監(jiān)角色；
• 一個(gè)用戶可擁有的角色數(shù)目受限，例如一個(gè)供應(yīng)商生產(chǎn)員可以同時(shí)最多擁有組長和員工2個(gè)角色；
• 同一個(gè)角色對應(yīng)的訪問權(quán)限數(shù)目受限，例如一個(gè)業(yè)務(wù)職能員工角色最多只能擁有1個(gè)業(yè)務(wù)的數(shù)據(jù)權(quán)限，而中臺(tái)職能員工角色可以擁有多個(gè)業(yè)務(wù)的數(shù)據(jù)權(quán)限。

先決條件: 簡單理解即如果某用戶想獲得上級角色，必須得先獲得其下一級的角色。例如一個(gè)員工角色必須在系統(tǒng)內(nèi)先晉升為主管角色，才能繼續(xù)晉升為經(jīng)理角色。

運(yùn)行互斥：允許一個(gè)用戶具有兩個(gè)角色的資格，但在運(yùn)行中不可同時(shí)激活這兩個(gè)角色。

拓展：【RBAC3】 統(tǒng)一模型

可以單純的理解為RBAC0 + 1 + 2的集合體，在基本模型的基礎(chǔ)上同時(shí)具備了分層能力和限制能力。

RBAC模型優(yōu)勢： 當(dāng)擁有大量用戶和資源時(shí)，維護(hù)成本較低。

RBAC模型劣勢： 無法對單個(gè)用戶、單個(gè)資源進(jìn)行個(gè)體定制。比如，某角色擁有創(chuàng)建、刪除的權(quán)限，當(dāng)我們要對針對擁有該角色的某個(gè)用戶去掉刪除的權(quán)限。那么，我們就必須創(chuàng)建另一個(gè)角色來滿足需求。如果這種情況很頻繁，就會(huì)喪失角色的統(tǒng)一性，降低系統(tǒng)的可維護(hù)性。

【ABAC】基于屬性的權(quán)限訪問模型

ABAC通常用于配置哪些屬性的用戶在哪些屬性的環(huán)境下可以對哪些屬性的資源進(jìn)行哪些操作。 實(shí)現(xiàn)原理：通過各種屬性條件來動(dòng)態(tài)判斷一個(gè)操作是否可以被允許，也可以理解為我們俗稱的“配置規(guī)則”。 我們在配置規(guī)則時(shí)需要定義屬性條件和資源的關(guān)系。其中屬性條件又分成以下3類：

• 用戶屬性：如年齡、部門、職位、性別等；
• 環(huán)境屬性：如時(shí)間、地點(diǎn)、場景等；
• 資源屬性：如資源狀態(tài)、資源創(chuàng)建時(shí)間、資源存放位置、資源保密等級等。

以1個(gè)權(quán)限控制策略為例：

只有設(shè)計(jì)部門內(nèi)職位為視覺設(shè)計(jì)師的用戶，在工作時(shí)間內(nèi)且處于上海辦公區(qū)時(shí)，才可以訪問和編輯草稿狀態(tài)的人物素材庫。

其中“設(shè)計(jì)部門”、“視覺設(shè)計(jì)師”為用戶屬性，“工作時(shí)間”、“上海辦公區(qū)”為環(huán)境屬性，“草稿狀態(tài)”為資源屬性，只有命中符合這些屬性條件時(shí)，該規(guī)則才會(huì)生效，用戶才能具備對相應(yīng)資源的操作權(quán)限。 我們設(shè)置的屬性條件也可以定義“且/或”的關(guān)系，當(dāng)我們定義“且”關(guān)系時(shí)，必須所有屬性條件命中才會(huì)生效規(guī)則；當(dāng)我們定義“或”關(guān)系時(shí)，只需要命中部分屬性條件就可以生效規(guī)則。

ABAC的使用場景較靈活，常用于復(fù)雜多變的策略定制場景。如定制架構(gòu)可見范圍、定制會(huì)話權(quán)限等。

• ABAC模型優(yōu)勢： 能夠根據(jù)上下文動(dòng)態(tài)執(zhí)行，可以發(fā)揮權(quán)限控制最大的靈活性，滿足更細(xì)顆粒度的場景需求。
• ABAC模型劣勢： 學(xué)習(xí)成本比較高，隨著規(guī)則（策略）的不斷增多，管理和維護(hù)成本也會(huì)攀升。

綜合以上3大權(quán)限模型的優(yōu)劣來看：

• ACL模型基于資源進(jìn)行配置，適用于用戶量少、更新頻次低、無明確職能劃分的小型組織，開發(fā)成本低但后期管理維護(hù)成本高，適合作為平臺(tái)搭建初期時(shí)的臨時(shí)過渡方案；
• RBAC模型基于角色進(jìn)行配置，適用于用戶量一般、更新頻次一般、有明確職能劃分、較少定制權(quán)限的中型組織，開發(fā)成本高但后期維護(hù)成本低，適合作為平臺(tái)管理少量內(nèi)外部用戶時(shí)的方案；
• ABAC模型基于屬性進(jìn)行配置，適用于用戶量多、更新頻次高、職能劃分復(fù)雜多變、有安全合規(guī)訴求、權(quán)限定制多樣化的大型組織，能夠在保障效率的同時(shí)降低安全風(fēng)險(xiǎn)，適合作為平臺(tái)管理大批量復(fù)雜用戶時(shí)的方案。

2.2 基于業(yè)務(wù)梳理關(guān)鍵信息

第一步：選擇權(quán)限模型

不同的業(yè)務(wù)特點(diǎn)指向不同的使用場景，因此我們需要基于業(yè)務(wù)特點(diǎn)選擇合適的權(quán)限模型。 以眾包平臺(tái)為例，平臺(tái)具備B/C雙端的特點(diǎn)，因此在進(jìn)行權(quán)限設(shè)計(jì)時(shí)需要考慮兩端的使用場景和受眾群體。

基于以上業(yè)務(wù)特點(diǎn)，我們可以發(fā)現(xiàn)B端后臺(tái)管理權(quán)限分配更適合基于“角色”進(jìn)行設(shè)計(jì)，而C端前臺(tái)的生產(chǎn)權(quán)限更適合基于“屬性”進(jìn)行設(shè)計(jì)。

完成模型選擇后，我們需要基于模型進(jìn)一步梳理平臺(tái)內(nèi)所需的角色、屬性和權(quán)限信息。

第二步：明確關(guān)鍵角色和屬性

角色是連接用戶和權(quán)限的橋梁，因此我們需要對平臺(tái)內(nèi)的B端管理角色進(jìn)行窮舉。 角色定義通常取決于崗位職能劃分和任務(wù)流分工。

超級管理員是一種特殊的角色，主要作用是為了添加首批管理人員，通常為隱形狀態(tài)，且該角色不可通過配置進(jìn)行分配。 通過盤點(diǎn)，我們在該步驟可以得出一份「角色列表」。 屬性是觸發(fā)規(guī)則運(yùn)行的基本條件，我們需要將平臺(tái)內(nèi)所有影響規(guī)則運(yùn)行的屬性進(jìn)行整理歸類。 關(guān)鍵屬性通常取決于平臺(tái)用戶數(shù)據(jù)的字段定義、用戶操作環(huán)境的客觀因子和業(yè)務(wù)資源數(shù)據(jù)的標(biāo)簽維度。

通過盤點(diǎn)，我們在該步驟可以得出一份「屬性列表」。

第三步：梳理權(quán)限

權(quán)限是用戶能夠訪問的資源，本步驟需要將平臺(tái)內(nèi)所有權(quán)限點(diǎn)按照類型進(jìn)行整理歸類。權(quán)限點(diǎn)主要有以下幾種類型需要盤點(diǎn)：

頁面權(quán)限即用戶在平臺(tái)內(nèi)可見的頁面，由導(dǎo)航菜單來控制，包括一級導(dǎo)航菜單、二級導(dǎo)航菜單，甚至三級導(dǎo)航菜單，只要用戶有對應(yīng)導(dǎo)航菜單的權(quán)限即可訪問頁面。

操作權(quán)限即頁面內(nèi)的功能按鈕，包括我們常規(guī)認(rèn)知的增刪改查操作。 如下圖眾包平臺(tái)的權(quán)限示例：

在實(shí)際操作場景中，部分操作權(quán)限會(huì)因狀態(tài)而發(fā)生變化，在盤點(diǎn)操作權(quán)限時(shí)，需要梳理狀態(tài)關(guān)聯(lián)性來檢查是否有缺漏，如下圖所示：

一期因時(shí)間問題，我們統(tǒng)一僅基于頁面配置“查看”與“操作”兩類權(quán)限。

數(shù)據(jù)權(quán)限即用戶在同一頁面看到的數(shù)據(jù)，不同數(shù)據(jù)權(quán)限的用戶在同一頁面內(nèi)將看到截然不同的數(shù)據(jù)。

B端后臺(tái)出于數(shù)據(jù)安全性考量，各業(yè)務(wù)會(huì)期望數(shù)據(jù)處于僅自己業(yè)務(wù)管理員可見的狀態(tài)，因此我們發(fā)現(xiàn)站在業(yè)務(wù)角度使用“項(xiàng)目組”的形式來分隔數(shù)據(jù)更加簡單有效，通俗來講就是每個(gè)業(yè)務(wù)對應(yīng)一個(gè)項(xiàng)目，將用戶加入項(xiàng)目內(nèi)即可獲取對應(yīng)業(yè)務(wù)的數(shù)據(jù)權(quán)限。

各業(yè)務(wù)在面向C端生產(chǎn)角色開放數(shù)據(jù)權(quán)限時(shí)，通常需要綜合效率、質(zhì)量和成本等多種目的來進(jìn)行考量選擇，權(quán)限也會(huì)針對相同類型的用戶進(jìn)行集中配置，因此針對生產(chǎn)角色的會(huì)更多基于“用戶群組”的形式來進(jìn)行數(shù)據(jù)分隔，我們將相同類型的用戶進(jìn)行編組，再對整組用戶按照分流規(guī)則授予相應(yīng)的數(shù)據(jù)權(quán)限，群組在命中分流規(guī)則后可在任務(wù)廣場內(nèi)看到相應(yīng)的任務(wù)數(shù)據(jù)。

通過盤點(diǎn)，我們在該步驟可以得出一份「權(quán)限點(diǎn)列表」。

第四步：關(guān)聯(lián)權(quán)限

關(guān)聯(lián)角色和權(quán)限：結(jié)合「角色列表」、「屬性列表」和「權(quán)限點(diǎn)列表」，我們可以整合出一張完整的權(quán)限對應(yīng)表。在梳理角色和權(quán)限的關(guān)系時(shí)，可以通過“角色行為窮舉”來進(jìn)行權(quán)限點(diǎn)轉(zhuǎn)化和連接。

以眾包B端的幾個(gè)管理角色為例，進(jìn)行“角色行為窮舉”：

關(guān)聯(lián)屬性和權(quán)限：屬性也可以通過同樣的方式來進(jìn)行權(quán)限點(diǎn)轉(zhuǎn)化和連接。

以眾包C端的規(guī)則為例，進(jìn)行“屬性群組行為窮舉”：

通過盤點(diǎn)，我們在該步驟可以得出一份「角色&屬性權(quán)限對應(yīng)表」。

2.3 設(shè)計(jì)賦權(quán)流程

在明確了角色&屬性與權(quán)限的關(guān)系后，需要去設(shè)計(jì)賦權(quán)的交互方式。

B端管理賬號賦權(quán)

眾包B端用戶以產(chǎn)品和運(yùn)營為主，用戶數(shù)量和權(quán)限數(shù)量一般（100以內(nèi)），有明確的管理職能劃分，主要負(fù)責(zé)管理和監(jiān)控平臺(tái)內(nèi)的多個(gè)子模塊進(jìn)展，因此較適用于RBAC基于角色的權(quán)限模型。

第一步：明確流程方案

首先，我們需要確認(rèn)B端數(shù)據(jù)權(quán)限是否需要做分隔處理：

• 通常僅服務(wù)于單個(gè)業(yè)務(wù)的后臺(tái)數(shù)據(jù)權(quán)限，不需要做分隔處理，可以直接通過角色賦權(quán)賬號；
• 涉及到多業(yè)務(wù)的保密數(shù)據(jù)時(shí)，需要做權(quán)限分隔處理，數(shù)據(jù)權(quán)限不可以和角色直接關(guān)聯(lián)綁定。

如下為數(shù)據(jù)權(quán)限不需要隔離的流程方案：

如下為數(shù)據(jù)權(quán)限隔離的流程方案：

考慮到眾包平臺(tái)期望未來接入更多業(yè)務(wù)的愿景，我們選用數(shù)據(jù)權(quán)限隔離的流程方案，之后就可以開始設(shè)計(jì)角色配置方案了。

第二步：創(chuàng)建角色并配置操作權(quán)限

首先，我們需要新增一個(gè)角色管理頁，通過該頁面進(jìn)行角色數(shù)據(jù)的創(chuàng)建和管理，當(dāng)業(yè)務(wù)接入平臺(tái)時(shí)，我們會(huì)提供一些默認(rèn)角色供業(yè)務(wù)使用。

如果提供的默認(rèn)角色無法滿足業(yè)務(wù)訴求，那么業(yè)務(wù)運(yùn)營可以在該頁面內(nèi)編輯默認(rèn)角色或新增角色，為角色自定義頁面權(quán)限和操作權(quán)限。 操作項(xiàng)必然依托于頁面，因此我們在設(shè)計(jì)角色配置交互時(shí)：

• 通過Table設(shè)計(jì)將頁面權(quán)限與操作權(quán)限進(jìn)行關(guān)聯(lián)配置，在用戶提交配置時(shí)將頁面權(quán)限賦予角色，這樣可以保障擁有該角色的賬號能夠查看到相應(yīng)導(dǎo)航頁面并對相關(guān)頁面進(jìn)行操作；
• 以嵌套子表格的設(shè)計(jì)表現(xiàn)一級頁面和二級頁面的父子關(guān)系，當(dāng)勾選一級頁面的操作權(quán)限時(shí)視為勾選其所有子頁面的操作權(quán)限；
• 從系統(tǒng)的運(yùn)行邏輯角度出發(fā)，對查看權(quán)限（可以看到該頁面導(dǎo)航）和操作權(quán)限（可以看到該頁面內(nèi)的操作項(xiàng)）進(jìn)行交互關(guān)聯(lián)，當(dāng)用戶僅勾選某頁面的查看權(quán)限時(shí)，不會(huì)聯(lián)動(dòng)選中操作權(quán)限；當(dāng)用戶勾選操作權(quán)限時(shí)，會(huì)聯(lián)動(dòng)選中查看權(quán)限。

完成角色配置設(shè)計(jì)后，就需要考慮如何將角色權(quán)限與管理員賬號進(jìn)行關(guān)聯(lián)了。

第三步：對賬號配置角色和數(shù)據(jù)權(quán)限

前文提到，考慮到業(yè)務(wù)自有數(shù)據(jù)的私密性訴求和安全性考量，因此不能將數(shù)據(jù)權(quán)限直接賦予多業(yè)務(wù)通用的角色身份，而選擇與私密性更好的賬號進(jìn)行綁定配置，為此我們需要新增一個(gè)賬號管理頁，通過該頁面可以對管理賬號和用戶賬號數(shù)據(jù)進(jìn)行創(chuàng)建和管理。

在設(shè)計(jì)管理賬號配置交互時(shí)：

• 遵循RBAC權(quán)限模型，通過角色配置項(xiàng)實(shí)現(xiàn)對賬號頁面&操作權(quán)限的集中賦予，角色配置項(xiàng)采用映射展示項(xiàng)的Checkboxes+Table設(shè)計(jì)，便于用戶勾選角色后能夠直觀看到對應(yīng)的角色所擁有的頁面權(quán)限和操作權(quán)限；
• 考慮到頻繁請求全量數(shù)據(jù)權(quán)限容易造成接口崩潰，因此在配置管理員權(quán)限時(shí)，將角色配置和數(shù)據(jù)權(quán)限控制拆成了2步，通過增加環(huán)節(jié)數(shù)降低全量數(shù)據(jù)請求的頻次；
• 眾包的數(shù)據(jù)權(quán)限分為項(xiàng)目-車間兩級，因此在配置數(shù)據(jù)權(quán)限時(shí)會(huì)優(yōu)先引導(dǎo)用戶先為賬號選擇項(xiàng)目數(shù)據(jù)權(quán)限，完成項(xiàng)目選擇時(shí)會(huì)在下方展示項(xiàng)目下的子級權(quán)限控制入口，用戶可以在項(xiàng)目下繼續(xù)為賬號選擇車間數(shù)據(jù)權(quán)限（低頻操作）。

完成以上角色配置 + 管理賬號配置的2步操作后，我們完成了對管理賬號的賦權(quán)，之后通過將管理賬號分發(fā)給業(yè)務(wù)運(yùn)營，實(shí)現(xiàn)業(yè)務(wù)接入平臺(tái)后的管理成員就位。

C端生產(chǎn)賬號賦權(quán)

眾包C端的用戶分為Freelancer和供應(yīng)商兩類，用戶數(shù)量大（數(shù)千人），權(quán)限需要依賴多類復(fù)雜的屬性組合因素（任務(wù)類型 x 職能 x 語言 x 學(xué)科 x 年級），且需要根據(jù)不同業(yè)務(wù)要求進(jìn)行調(diào)整（隨著業(yè)務(wù)數(shù)量增多，調(diào)整次數(shù)將持續(xù)翻倍），且部分業(yè)務(wù)仍有跨國合規(guī)訴求和權(quán)限定制訴求，需要根據(jù)變量條件來靈活調(diào)整，因此較適用于ABAC基于屬性的權(quán)限訪問模型。

第一步：明確流程方案

C端用戶的賦權(quán)設(shè)計(jì)可以基于推薦渠道用戶和普通用戶兩個(gè)角度進(jìn)行考量。 我們通常會(huì)通過線下招募、熟人轉(zhuǎn)推薦和供應(yīng)商簽約3種渠道來招募定向的高質(zhì)量用戶，這部分用戶通常會(huì)具備相應(yīng)的基礎(chǔ)生產(chǎn)能力，我們可以直接對這類用戶進(jìn)行批量賦權(quán)。

當(dāng)批量渠道用戶無平臺(tái)賬號時(shí)，我們可以采用如下邀請賦權(quán)的流程：

當(dāng)批量渠道用戶有平臺(tái)賬號時(shí)，我們可以繼續(xù)采用邀請賦權(quán)的方式，但考慮到減少對用戶的干擾，我們也可以采用如下管理員手動(dòng)賦權(quán)的流程：

而針對普通用戶，因?yàn)槲覀儾涣私膺@類用戶是否具備完成任務(wù)生產(chǎn)的能力，所以我們需要面向這類用戶增加培訓(xùn)考試環(huán)節(jié)，因此會(huì)采用如下考試賦權(quán)的流程：

第二步：創(chuàng)建用戶群組

因C端用戶數(shù)量較多，通常我們會(huì)基于某類屬性規(guī)則對用戶進(jìn)行標(biāo)簽分組（如高質(zhì)量數(shù)學(xué)生產(chǎn)組、高效率英語質(zhì)檢組、低成本知識點(diǎn)標(biāo)注組），也就是我們熟稱的“用戶群組”。

角色和用戶群組的概念區(qū)分： 角色賦予的是主體，主體可以是用戶，也可以是用戶群組 ；角色是權(quán)限的集合 ；用戶群組是用戶的集合 。

基于“用戶群組”進(jìn)行批量賦權(quán)可以極大的提升平臺(tái)配置效率。 因此，我們需要新增一個(gè)群組管理頁，通過該頁面進(jìn)行群組數(shù)據(jù)的創(chuàng)建和管理，當(dāng)業(yè)務(wù)接入平臺(tái)時(shí)，業(yè)務(wù)可以通過該頁面將目標(biāo)用戶批量導(dǎo)入對應(yīng)用戶群組內(nèi)。

第三步：對用戶&群組配置操作權(quán)限

完成群組的創(chuàng)建后，我們需要賦予群組相應(yīng)的任務(wù)操作權(quán)限，但C端任務(wù)操作權(quán)限需要依賴于組合復(fù)雜的能力標(biāo)簽（任務(wù)類型 x 職能 x 語言 x 學(xué)科 x 年級），為此我們需要將相應(yīng)任務(wù)的能力標(biāo)簽具象為易于用戶理解的“證書”，而C端用戶要獲得這些“證書”，則需要進(jìn)行相應(yīng)的培訓(xùn)“考試”。

基于“能力證書”的邏輯，我們首先需要新增一個(gè)證書管理頁，證書管理頁用于配置要獲得一個(gè)任務(wù)的操作權(quán)限需要用戶擁有哪些能力證書。為了滿足靈活多變的業(yè)務(wù)場景，通常一個(gè)任務(wù)會(huì)包含多個(gè)屬性變量組（如工作職責(zé) x 學(xué)科 x 學(xué)段 x 人群組），因此證書配置的設(shè)計(jì)也會(huì)以規(guī)則組的形式，來提供用戶對屬性變量條件進(jìn)行設(shè)置的能力。

在完成配置后，C端的用戶在領(lǐng)取任務(wù)時(shí)將基于任務(wù)的屬性條件來確認(rèn)當(dāng)前用戶是否已具備所需的證書，若已具備則進(jìn)入任務(wù)操作界面，若未具備則彈出如下的考試引導(dǎo)，需要用戶通過考試后才能獲得相應(yīng)的證書。

完成能力證書與任務(wù)操作權(quán)限的關(guān)聯(lián)后，我們需要基于用戶類型來展開不同的路徑設(shè)計(jì)，前文提到，C端用戶的賦權(quán)設(shè)計(jì)需要基于推薦渠道用戶和普通用戶兩個(gè)角度來進(jìn)行考量：

推薦渠道用戶指通過線下招募、熟人轉(zhuǎn)推薦和供應(yīng)商簽約等渠道來招募的高質(zhì)量用戶，這部分用戶通常會(huì)具備相應(yīng)的基礎(chǔ)任務(wù)生產(chǎn)能力，我們可以直接對這類用戶進(jìn)行批量賦權(quán)。因此，我們需要新增一個(gè)能力管理頁，能力管理頁用于配置哪些用戶可以通過白名單直接擁有哪些能力證書（任務(wù)操作權(quán)限），當(dāng)業(yè)務(wù)接入平臺(tái)時(shí)，業(yè)務(wù)可以通過該頁面將證書（即任務(wù)操作權(quán)限）分配給對應(yīng)用戶或群組。

而針對普通用戶，我們并不了解這類用戶是否具備完成任務(wù)生產(chǎn)的能力，所以我們需要面向這類用戶增加考試環(huán)節(jié)，為此我們需要新增一個(gè)考試管理頁?？荚嚬芾眄撜怯糜谂渲靡@得一個(gè)能力證書需要進(jìn)行哪些考試。

無論是通過管理員批量授權(quán)還是通過考試獲得授權(quán)，得到授權(quán)的用戶將得到一份證書，并展示在C端用戶的個(gè)人中心內(nèi)。

第四步：對群組配置數(shù)據(jù)權(quán)限

通過能力證書可以賦予用戶對某類任務(wù)的操作權(quán)限，但不會(huì)直接賦予用戶任務(wù)數(shù)據(jù)權(quán)限，因此任務(wù)數(shù)據(jù)僅對群組開放，若用戶不在對應(yīng)群組內(nèi)，則無法看到任務(wù)數(shù)據(jù)。 這么處理的原因在于業(yè)務(wù)生產(chǎn)策略的差異化，同類任務(wù)在不同業(yè)務(wù)考量（如成本、效率、質(zhì)量）下會(huì)傾向于采用不同的生產(chǎn)流程和人員配置。

因此將同類用戶并入群組，再基于不同的屬性變量條件對群組進(jìn)行數(shù)據(jù)權(quán)限的分流配置，更符合復(fù)雜場景下策略自動(dòng)化的訴求。

第五步：將用戶加入群組

將用戶加入群組的方式分為3種：管理員批量導(dǎo)入、活動(dòng)邀請加入和自動(dòng)分群標(biāo)記加入。

1、管理員批量導(dǎo)入：該方式已在“第三步”中有所提及，這里不再贅述。

2、活動(dòng)邀請加入：通過運(yùn)營線下活動(dòng)招募或熟人轉(zhuǎn)介紹的渠道用戶通常沒有平臺(tái)賬號，因此我們傾向于通過活動(dòng)邀請來將這類用戶加入群組。 首先，我們需要新增一個(gè)活動(dòng)管理頁，通過該頁面進(jìn)行邀請活動(dòng)數(shù)據(jù)的創(chuàng)建和管理，當(dāng)業(yè)務(wù)接入平臺(tái)時(shí)，業(yè)務(wù)可以通過該頁面配置群組邀請碼、鏈接或二維碼。

通過邀請活動(dòng)完成注冊或指定操作的用戶將被自動(dòng)加入該活動(dòng)關(guān)聯(lián)的群組，如下為活動(dòng)示例Banner入口，通過該入口完成招募操作的用戶將被自動(dòng)加入框題任務(wù)用戶群組，從而獲得框題任務(wù)的生產(chǎn)操作權(quán)限。

3、自動(dòng)分群標(biāo)記加入：對于已注冊的其他用戶，我們會(huì)基于業(yè)務(wù)對生產(chǎn)策略的訴求，抽象出關(guān)鍵的屬性變量條件，系統(tǒng)將按照特定條件自動(dòng)將符合條件的用戶加入群組，將不符合條件的用戶移出群組。

注意事項(xiàng)：為了確保安全性，邀請活動(dòng)可設(shè)置失效時(shí)間； 完成賦權(quán)/授權(quán)后，需要對用戶進(jìn)行及時(shí)的消息推送。

2.4 提取通用設(shè)計(jì)點(diǎn)

通過以上流程設(shè)計(jì)，我們實(shí)現(xiàn)了B/C端的權(quán)限控制，但為了提升后續(xù)相關(guān)權(quán)限控制的拓展，我們需要抽象提取可以復(fù)用的通用設(shè)計(jì)點(diǎn)，形成設(shè)計(jì)規(guī)范：

頁面權(quán)限設(shè)計(jì)

當(dāng)前用戶無頁面權(quán)限且不可申請時(shí)，在導(dǎo)航內(nèi)隱藏對應(yīng)菜單項(xiàng)；

當(dāng)前用戶無頁面權(quán)限但支持申請時(shí)，在導(dǎo)航內(nèi)顯示對應(yīng)菜單項(xiàng)，點(diǎn)擊選中該菜單項(xiàng)后在頁面內(nèi)顯示“抱歉，你無權(quán)訪問該頁面”空態(tài)提示：

若支持用戶線上申請，則顯示“申請權(quán)限”按鈕，點(diǎn)擊后彈出申請理由表單；

若僅支持線下申請，則僅顯示“抱歉，你無權(quán)訪問該頁面，請聯(lián)系XXXX開通權(quán)限”文案提示。

操作權(quán)限設(shè)計(jì)

當(dāng)前用戶無操作權(quán)限且不可申請時(shí)，隱藏對應(yīng)操作；

當(dāng)前用戶無操作權(quán)限但支持申請時(shí)，點(diǎn)擊后彈出引導(dǎo)申請Popover提示；

當(dāng)前用戶有操作權(quán)限但暫時(shí)不可操作時(shí)，按鈕顯示為禁用態(tài)，不支持點(diǎn)擊。

數(shù)據(jù)權(quán)限設(shè)計(jì)：

項(xiàng)目權(quán)限的切換與展示：當(dāng)前賬號具備的項(xiàng)目權(quán)限數(shù)=1時(shí)，僅顯示項(xiàng)目名稱，無交互效果，不支持切換。

當(dāng)前賬號具備的項(xiàng)目權(quán)限數(shù)>1時(shí)，顯示項(xiàng)目名稱和下拉按鈕，支持點(diǎn)擊切換。

無項(xiàng)目權(quán)限的處理 ：當(dāng)前用戶無項(xiàng)目數(shù)據(jù)權(quán)限且不可申請時(shí)，在項(xiàng)目選項(xiàng)列表中隱藏?zé)o權(quán)限的項(xiàng)目；

當(dāng)前用戶無項(xiàng)目數(shù)據(jù)權(quán)限但支持申請時(shí)，在選中對應(yīng)項(xiàng)目后，在頁面內(nèi)展示“抱歉，你無權(quán)訪問該項(xiàng)目”空態(tài)提示：

若支持用戶線上申請，則顯示“申請權(quán)限”按鈕，點(diǎn)擊后彈出申請理由表單；

若僅支持線下申請，則僅顯示“抱歉，你無權(quán)訪問該項(xiàng)目，請聯(lián)系XXXX開通權(quán)限”文案提示。

三、總結(jié)

權(quán)限系統(tǒng)作為中后臺(tái)的基礎(chǔ)能力之一，能夠讓不同組織下的不同人員專注于自己的工作領(lǐng)域，降低數(shù)據(jù)風(fēng)險(xiǎn)，實(shí)現(xiàn)人員和數(shù)據(jù)的高效管理。 在選擇權(quán)限技術(shù)模型時(shí)：

• 面向用戶量和權(quán)限量少、更新頻次低、無明確職能劃分的小型組織進(jìn)行權(quán)限設(shè)計(jì)時(shí)，可以考慮參考開發(fā)成本低的ACL權(quán)限列表權(quán)限設(shè)計(jì)，基于賬號進(jìn)行授權(quán)設(shè)計(jì)；
• 面向用戶量和權(quán)限量多、更新頻次多、有明確職能劃分的中型組織進(jìn)行權(quán)限設(shè)計(jì)時(shí)，可以考慮維護(hù)成本低的RBAC角色權(quán)限設(shè)計(jì)，基于角色進(jìn)行授權(quán)設(shè)計(jì)；
• 面向用戶量和權(quán)限量多、更新頻次高、無明確職能劃分、有安全合規(guī)訴求、權(quán)限定制多樣化的大型組織，可以考慮夠在保障效率的同時(shí)降低安全風(fēng)險(xiǎn)的ABAC屬性權(quán)限設(shè)計(jì)，基于屬性規(guī)則進(jìn)行授權(quán)設(shè)計(jì)。

在權(quán)限設(shè)計(jì)時(shí)需要基于業(yè)務(wù)角度考慮頁面權(quán)限、操作權(quán)限和數(shù)據(jù)權(quán)限等多個(gè)方面：

• 頁面的賦權(quán)設(shè)計(jì)需要注意關(guān)聯(lián)體現(xiàn)頁面間的層級關(guān)系與對應(yīng)操作權(quán)限；
• 操作的賦權(quán)設(shè)計(jì)需要注意數(shù)據(jù)狀態(tài)變化導(dǎo)致的操作變化；
• 數(shù)據(jù)的賦權(quán)設(shè)計(jì)需要注意多業(yè)務(wù)數(shù)據(jù)是否需要基于安全性進(jìn)行分隔處理；
• 注意提取通用設(shè)計(jì)點(diǎn)，以保證平臺(tái)內(nèi)權(quán)限設(shè)計(jì)的統(tǒng)一性。

通過以上基于角色&屬性的權(quán)限設(shè)計(jì)，我們實(shí)現(xiàn)了權(quán)限分配流程的100%線上配置化，將有效的釋放原來用于支持權(quán)限開發(fā)90%以上的研發(fā)人力和運(yùn)營人力，將這部分人力資源更好的應(yīng)用于中臺(tái)能力建設(shè)。

#專欄作家#

愚者秦，微信公眾號：feather-wit，人人都是產(chǎn)品經(jīng)理專欄作家。先后任職于愛奇藝、字節(jié)跳動(dòng)的一枚體驗(yàn)設(shè)計(jì)師，同時(shí)是兼職寫小說的斜杠青年，善于總結(jié)和抽象設(shè)計(jì)方法，熱衷于探索不同用戶場景下的產(chǎn)品策略。

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

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