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

編輯導(dǎo)語(yǔ)：B端產(chǎn)品的權(quán)限管理是衡量產(chǎn)品商業(yè)模式以及用戶價(jià)值高低的一桿標(biāo)尺，那么我們?cè)撊绾芜M(jìn)行權(quán)限系統(tǒng)的設(shè)計(jì)呢？作者分享了一些自己的經(jīng)驗(yàn)，我們一起來(lái)看看吧。

現(xiàn)代經(jīng)濟(jì)學(xué)理論認(rèn)為，企業(yè)本質(zhì)上是“一種資源配置的機(jī)制”，其能夠?qū)崿F(xiàn)整個(gè)社會(huì)經(jīng)濟(jì)資源的優(yōu)化配置，降低整個(gè)社會(huì)的“交易成本”。

權(quán)限管理系統(tǒng)的本質(zhì)是企業(yè)內(nèi)部或企業(yè)之間的資源在B端產(chǎn)品上以特定機(jī)制配置的映射；所以權(quán)限管理系統(tǒng)的貼身情況也是衡量產(chǎn)品商業(yè)模式好壞、用戶價(jià)值高低的一桿標(biāo)尺。

權(quán)限管理系統(tǒng)的設(shè)計(jì)中常遇到的問題有：

• 配置不規(guī)范，系統(tǒng)基礎(chǔ)不穩(wěn)，拓展性差；
• 配置不靈活，用戶需求難滿足，體驗(yàn)差；
• 配置太靈活，邏輯會(huì)復(fù)雜，實(shí)施成本高；

那么，如何設(shè)計(jì)一款貼身并能隨著產(chǎn)品一起生長(zhǎng)的權(quán)限管理系統(tǒng)呢？

在古代，沒有互聯(lián)網(wǎng)、沒有軟件時(shí)，泱泱中華在中央集權(quán)的帝制制度、“君君臣臣、父父子子”的角色說(shuō)明書等管理系統(tǒng)中正常運(yùn)轉(zhuǎn)。

皇帝把資源下發(fā)給特定的人、崗位角色、宦官集團(tuán)等以促進(jìn)農(nóng)業(yè)生產(chǎn)、稅收、戶籍管理、治安維護(hù)等。

資源包括權(quán)力、辦事流程等抽象資源，也包括錢財(cái)、糧食、鹽、礦等實(shí)物資源，同時(shí)包括印章、信紙、官服、轎子、馬等承載資源、象征權(quán)力、代表等級(jí)的工具。

而管理機(jī)制除了帝制和角色說(shuō)明書，還有子承父業(yè)的繼承機(jī)制、藩王行為規(guī)范、文官武官的互斥監(jiān)督、官職逐級(jí)遞升約束、虎符口令雙向驗(yàn)證等等。

在盛世時(shí)期百姓人口增加、戰(zhàn)爭(zhēng)時(shí)期軍隊(duì)數(shù)量增加要在基礎(chǔ)機(jī)制上做適應(yīng)性的調(diào)整。

權(quán)限管理的本質(zhì)也大致如此，管理的是主體對(duì)客體遵循特定機(jī)制做出的行為。

• 權(quán)限管理系統(tǒng)的組成要素有哪些？
• 常見的權(quán)限模型有哪些？
• Oracle和Salesforce的權(quán)限模型是啥樣的？
• 實(shí)操案例中如何應(yīng)用的？
• 有哪些經(jīng)驗(yàn)及建議？

一、4個(gè)基本要素

權(quán)限是主體對(duì)客體遵循特定機(jī)制做出的行為。所以，權(quán)限的4個(gè)基本要素就是主體、客體、行為、機(jī)制。

1. 主體

指行為的行使者，是操作的發(fā)起者。主體的類型有很多種，常見的有：

• 用戶及用戶組。更準(zhǔn)確地術(shù)語(yǔ)應(yīng)是“系統(tǒng)使用者”，其與系統(tǒng)的賬號(hào)體系相對(duì)應(yīng)，一個(gè)用戶對(duì)應(yīng)一個(gè)唯一賬號(hào)；多個(gè)用戶組成一個(gè)用戶組；
• 角色及角色組。角色是權(quán)限分配的單位與載體，通常與組織架構(gòu)體系相對(duì)應(yīng)。Oracle產(chǎn)品中分為工作角色、職責(zé)角色、數(shù)據(jù)角色和抽象角色四類，后面我們會(huì)說(shuō)到；
• 用戶標(biāo)簽及用戶標(biāo)簽組；
• 設(shè)備及設(shè)備組。HarmonyOS系統(tǒng)首期給Mate40系列開放使用；
• IP地址。限制對(duì)IP地址的訪問；
• 地理位置。如O2O生活平臺(tái)在不同位置展示的店鋪不同；
• 局域網(wǎng)。如公司電腦在內(nèi)網(wǎng)和外網(wǎng)所訪問的資源不同。

2. 客體

指行為的承受者，是操作所針對(duì)的對(duì)象。主要有三大類：

（1）資源

• 基本屬性的數(shù)據(jù)
• 行數(shù)據(jù)
• 個(gè)別的列數(shù)據(jù)（俗稱“某些字段”）

（2）資源的容器

• 頁(yè)面
• 目錄或菜單
• Tab
• 按鈕

（3）操作資源所必須的條件

• 任務(wù)流，也稱工作流。某一資源在任務(wù)流中的狀態(tài)不同，不同狀態(tài)的資源可以分配給不同角色操作；
• 所屬權(quán)。所屬權(quán)包括個(gè)人、個(gè)人及下屬、部門、部門及下屬、全部，通常與組織架構(gòu)體系的組織范圍相對(duì)應(yīng)。

3. 行為

指主體對(duì)客體的活動(dòng)，包括主體在產(chǎn)品中對(duì)客體的一些操作，而我們常說(shuō)的“權(quán)限”一詞則指代了這一操作，例如“查看朋友圈的權(quán)限”。常見的行為有：

• 登入、登出
• 增
• 刪
• 改，包括讀寫
• 查，包括不可見、只讀
• 上傳、下載
• 共享
• ……

4. 機(jī)制

系統(tǒng)機(jī)制包括對(duì)主體、客體和主客體關(guān)系的認(rèn)證，對(duì)主體行為及行為運(yùn)行方式的授權(quán)。常見的機(jī)制有：

• 繼承。父級(jí)可以擁有子級(jí)的權(quán)限，依托于組織架構(gòu)或角色層級(jí)結(jié)構(gòu)；例如銷售部門負(fù)責(zé)人有所有下屬的權(quán)限；
• 互斥。是對(duì)主體之間責(zé)任的強(qiáng)制性規(guī)定，防止同一主體擁有足夠權(quán)限進(jìn)行欺騙行為，防止即當(dāng)運(yùn)動(dòng)員又當(dāng)裁判的行為。責(zé)任分離有靜態(tài)和動(dòng)態(tài)之分：
• 靜態(tài)互斥。一個(gè)用戶不能同時(shí)擁有兩個(gè)互斥的角色。例如銀行內(nèi)部的貸款申請(qǐng)者和貸款審批者不能讓同一個(gè)人承擔(dān)；
• 動(dòng)態(tài)互斥。一個(gè)用戶可以擁有兩個(gè)角色，但在運(yùn)行時(shí)只能激活一個(gè)角色，也成為運(yùn)行互斥機(jī)制。例如銀行內(nèi)部為了靈活放貸，職員張三可以同時(shí)有貸款申請(qǐng)者角色和貸款審批者角色，但對(duì)于同一筆貸款，不能即申請(qǐng)又審批。
• 先決條件。A想成為C，就必須先成為B，C只能從B中產(chǎn)生；
• 基數(shù)限制。是主體與主體、主體與客體、主體與行為間數(shù)量關(guān)系的限制。例如一個(gè)用戶可擁有的角色數(shù)目受限；一個(gè)角色被分配的用戶數(shù)量受限；一個(gè)角色的權(quán)限數(shù)目受限；
• 授予機(jī)制。是主體將自己的權(quán)限授予給其他主體的權(quán)限；
• 雙向驗(yàn)證。系統(tǒng)即驗(yàn)證主體，也驗(yàn)證客體，雙方都通過(guò)驗(yàn)證時(shí)才能允許主體對(duì)客體的行為；
• 共享機(jī)制。

訪問范圍限定機(jī)制。一般有三類依托：

• 組織架構(gòu)
• 角色層級(jí)結(jié)構(gòu)
• 組織范圍/抽象關(guān)系

環(huán)境限制。分為三類：

• 空間限制。例如針對(duì)地理位置、IP地址、局域網(wǎng)的限制；
• 時(shí)間限制。例如考試時(shí)間到了之后，操作權(quán)限有所限制；
• 頻度限制。例如對(duì)輸入密碼的頻率的限制；

二、5種常見的權(quán)限模型

2. ACL模型：訪問控制列表

Access Control List，ACL是最早的、最基本的一種訪問控制機(jī)制，是基于客體進(jìn)行控制的模型，在其他模型中也有ACL的身影。為了解決相同權(quán)限的用戶挨個(gè)配置的問題，后來(lái)也采用了用戶組的方式。

原理：每一個(gè)客體都有一個(gè)列表，列表中記錄的是哪些主體可以對(duì)這個(gè)客體做哪些行為，非常簡(jiǎn)單。

例如：當(dāng)用戶A要對(duì)一篇文章進(jìn)行編輯時(shí)，ACL會(huì)先檢查一下文章編輯功能的控制列表中有沒有用戶A，有就可以編輯，無(wú)則不能編輯。再例如：不同等級(jí)的會(huì)員在產(chǎn)品中可使用的功能范圍不同。

缺點(diǎn)：當(dāng)主體的數(shù)量較多時(shí)，配置和維護(hù)工作就會(huì)成本大、易出錯(cuò)。

2. DAC模型：自主訪問控制

Discretionary Access Control，DAC是ACL的一種拓展。

原理：在ACL模型的基礎(chǔ)上，允許主體可以將自己擁有的權(quán)限自主地授予其他主體，所以權(quán)限可以任意傳遞。

例如：常見于文件系統(tǒng)，LINUX，UNIX、WindowsNT版本的操作系統(tǒng)都提供DAC的支持。

缺點(diǎn)：對(duì)權(quán)限控制比較分散，例如無(wú)法簡(jiǎn)單地將一組文件設(shè)置統(tǒng)一的權(quán)限開放給指定的一群用戶。主體的權(quán)限太大，無(wú)意間就可能泄露信息。

3. MAC模型：強(qiáng)制訪問控制

Mandatory Access Control，MAC模型中主要的是雙向驗(yàn)證機(jī)制。常見于機(jī)密機(jī)構(gòu)或者其他等級(jí)觀念強(qiáng)烈的行業(yè)，如軍用和市政安全領(lǐng)域的軟件。

原理：主體有一個(gè)權(quán)限標(biāo)識(shí)，客體也有一個(gè)權(quán)限標(biāo)識(shí)，而主體能否對(duì)該客體進(jìn)行操作取決于雙方的權(quán)限標(biāo)識(shí)的關(guān)系。

例如：將軍分為上將>中將>少將，軍事文件保密等級(jí)分為絕密>機(jī)密>秘密，規(guī)定不同軍銜僅能訪問不同保密等級(jí)的文件，如少將只能訪問秘密文件；當(dāng)某一賬號(hào)訪問某一文件時(shí)，系統(tǒng)會(huì)驗(yàn)證賬號(hào)的軍銜，也驗(yàn)證文件的保密等級(jí)，當(dāng)軍銜和保密等級(jí)相對(duì)應(yīng)時(shí)才可以訪問。

缺點(diǎn)：控制太嚴(yán)格，實(shí)現(xiàn)工作量大，缺乏靈活性。

4. RBAC模型：基于角色的訪問控制

(Role-Based Access Control)，RBAC模型在目前使用的最廣泛、最普遍。

原理：在主體和權(quán)限之間引入了“角色（Role）”的概念，角色解耦了主體和權(quán)限之間的關(guān)系。，有四個(gè)不同的層次：

• RBAC0：基本模型，相當(dāng)于ACL+角色。權(quán)限被賦予角色，而不是用戶，當(dāng)一個(gè)角色被制定給一個(gè)用戶時(shí)，該用戶就擁有了該角色所包含的權(quán)限。所有的角色都是平級(jí)的，沒有制定角色層級(jí)關(guān)系；所有對(duì)象都沒有附加約束，沒有制定限制；
• RBAC1：角色分級(jí)模型，相當(dāng)于RBAC0+繼承機(jī)制；
• RBAC2：角色限制模型，相當(dāng)于RBAC0+互斥機(jī)制+先決條件機(jī)制+基數(shù)限制機(jī)制；
• RBAC3：統(tǒng)一模型，相當(dāng)于RBAC1+RBAC2。

缺點(diǎn)：需要將某個(gè)權(quán)限單獨(dú)設(shè)置給用戶時(shí)，如果用戶已有的角色中不包含該權(quán)限，就需要重新設(shè)置角色的權(quán)限或者重新創(chuàng)建一個(gè)新的角色，在業(yè)務(wù)和需求變更時(shí)需要維護(hù)大量的角色。

5. ABAC模型：基于屬性的訪問控制

(Attribute-Based Access Control)，能很好地解決RBAC的缺點(diǎn)，在新增資源時(shí)容易維護(hù)。

原理：通過(guò)動(dòng)態(tài)計(jì)算一個(gè)或一組屬性是否滿足某種機(jī)制來(lái)授權(quán)，是一種很靈活的權(quán)限模型，可以按需實(shí)現(xiàn)不同顆粒度的權(quán)限控制。

屬性通常有四類：

• 一是主體屬性，如用戶年齡、性別等；
• 二是客體屬性，如一篇文章等；
• 三是環(huán)境屬性，即空間限制、時(shí)間限制、頻度限制；
• 四是操作屬性，即行為類型，如讀寫、只讀等。

例如：早上9:00~11:00期間A、B兩個(gè)部門一起以考生的身份考試，下午14:00~17:00期間A、B兩個(gè)部門相互閱卷。

缺點(diǎn)：規(guī)則復(fù)雜，不易看出主體與客體之間的關(guān)系，實(shí)現(xiàn)非常難，現(xiàn)在應(yīng)用的很少。

三、Oracle和Salesforce的權(quán)限模型是啥樣的？

1. Oracle

其權(quán)限管理系統(tǒng)基于RBAC模型的基礎(chǔ)發(fā)展，角色分為四類：

• 工作角色：反映了工作頭銜并描述了責(zé)任職位。例如采購(gòu)員；
• 抽象角色：代表個(gè)人與企業(yè)或組織的一般關(guān)聯(lián)，與該人的工作（職位）無(wú)關(guān)。例如臨時(shí)工、員工、直屬經(jīng)理等；
• 職責(zé)角色：將必須在抽象角色或工作角色中執(zhí)行的任務(wù)分組，代表一項(xiàng)工作職責(zé)的一組功能和數(shù)據(jù)權(quán)限。例如文章的審核職責(zé)；
• 數(shù)據(jù)角色：是訪問特定數(shù)據(jù)的權(quán)利。例如HR中的薪資管理員可以看員工薪資，其他HR不能看。

這四種角色之間有什么樣的聯(lián)系呢？

抽象角色和工作角色必須繼承職責(zé)角色。工作角色可以繼承抽象角色和其他工作角色。數(shù)據(jù)角色可以繼承抽象、作業(yè)和其他數(shù)據(jù)角色。職責(zé)角色可以繼承其他職責(zé)角色。該圖顯示了角色類型之間的這些繼承關(guān)系。

不同角色之間如何訪問功能和數(shù)據(jù)呢？

這四類角色是如何配置在一個(gè)賬號(hào)上的呢？

注意的是數(shù)據(jù)角色、數(shù)據(jù)權(quán)限一般直接配置在用戶身上。

2. Salesforce

是通用型CRM系統(tǒng)中權(quán)限管理靈活配置的先進(jìn)案例。使用簡(jiǎn)檔、權(quán)限集、權(quán)限集組，控制用戶可以訪問的對(duì)象和字段。使用組織范圍的共享設(shè)置、用戶角色和共享規(guī)則，以指定用戶可以查看并編輯的單個(gè)記錄。

簡(jiǎn)檔定義了用戶訪問對(duì)象和數(shù)據(jù)的方式，以及在應(yīng)用程序內(nèi)部執(zhí)行的操作。簡(jiǎn)檔是每個(gè)用戶指定的標(biāo)準(zhǔn)配置文件，在創(chuàng)建用戶時(shí)指定。一個(gè)用戶只能有一個(gè)簡(jiǎn)檔，同一個(gè)簡(jiǎn)檔可以配置給多個(gè)用戶。例如某公司的銷售人員的簡(jiǎn)檔是一樣的。

權(quán)限集是授予用戶對(duì)各種工具和功能的訪問權(quán)限的設(shè)置和權(quán)限集合。無(wú)需更改用戶簡(jiǎn)檔，權(quán)限集即可擴(kuò)展用戶的功能訪問權(quán)限。多個(gè)權(quán)限集可以構(gòu)成一個(gè)權(quán)限集組。一個(gè)用戶可以有多個(gè)權(quán)限集及多個(gè)權(quán)限集組，同一個(gè)權(quán)限集或權(quán)限集組可以配置給多個(gè)用戶。

角色旨在提高數(shù)據(jù)可見性，控制著用戶可以看到的內(nèi)容。角色并非對(duì)每個(gè)用戶都是強(qiáng)制性的。角色/角色層次結(jié)構(gòu)的主要功能是允許層次結(jié)構(gòu)中的較高級(jí)別的用戶訪問層次結(jié)構(gòu)中較低級(jí)別的用戶擁有的記錄。例如：上級(jí)見下級(jí)，平級(jí)之間不可見。

角色層級(jí)衍生于組織架構(gòu)，定義了角色之間的層級(jí)結(jié)構(gòu)，例如銷售副總裁在角色層次結(jié)構(gòu)中，分管不同地區(qū)的銷售經(jīng)理。

而組織范圍定義了數(shù)據(jù)的讀寫等操作所屬范圍，例如閱讀范圍有全部數(shù)據(jù)、本部全部數(shù)據(jù)、本部及子部全部數(shù)據(jù)、本人全部數(shù)據(jù)、本人及下屬全部數(shù)據(jù)等，操作范圍有個(gè)人操作、公共操作。

簡(jiǎn)檔和角色之間的區(qū)別與聯(lián)系是什么？

簡(jiǎn)檔和權(quán)限集之間的區(qū)別與聯(lián)系是什么？一般使用簡(jiǎn)檔分配給用戶最低的權(quán)限集合，然后使用權(quán)限集補(bǔ)充配置的其他權(quán)限。

兩個(gè)聯(lián)合使用，提供了訪問的靈活性。兩者對(duì)權(quán)限點(diǎn)的控制范圍與設(shè)置方式是相同的，包括：

• 用戶可以看到哪些對(duì)象；
• 用戶可以看到哪些對(duì)象的哪些字段；
• 用戶可以對(duì)哪些對(duì)象有什么行為；
• 用戶可以看到哪些應(yīng)用；
• 用戶可以看到對(duì)象在不同的應(yīng)用中的形態(tài)。

簡(jiǎn)檔、權(quán)限集是如何配置在一個(gè)賬號(hào)上的呢？

對(duì)字段權(quán)限的設(shè)置如下：

數(shù)據(jù)共享規(guī)則的設(shè)置如下：

四、實(shí)操案例中如何應(yīng)用的？

將上文已講的所有機(jī)制及權(quán)限對(duì)應(yīng)的場(chǎng)景放入一個(gè)公司的管理系統(tǒng)中如下展示：

除此之外，也可以有一個(gè)賬號(hào)對(duì)應(yīng)多個(gè)企業(yè)角色，但在使用時(shí)需要選擇其中一個(gè)企業(yè)角色使用；例如我是浙江省銷售經(jīng)理，同時(shí)兼任門店一的店長(zhǎng)，一般來(lái)說(shuō)銷售經(jīng)理只需要查看三個(gè)門店的數(shù)據(jù)即可，而店長(zhǎng)要管理門店的所有操作及數(shù)據(jù)輸入。

那么為了減少工作混亂及權(quán)限的耦合程度，可以給我配置兩個(gè)企業(yè)角色，一個(gè)浙江省銷售經(jīng)理，一個(gè)門店一的店長(zhǎng)，登錄后必須選擇一個(gè)企業(yè)角色再進(jìn)入相應(yīng)產(chǎn)品界面，兩個(gè)企業(yè)角色可以隨時(shí)切換。

五、經(jīng)驗(yàn)及建議

1. 從產(chǎn)品開發(fā)商to企業(yè)客戶，再?gòu)钠髽I(yè)客戶to 使用者的角度來(lái)看

一般產(chǎn)品開發(fā)商要根據(jù)客戶畫像、業(yè)務(wù)模式和行業(yè)標(biāo)準(zhǔn)將權(quán)限劃分，求同存異，相同部分默認(rèn)配置，不同部分根據(jù)業(yè)務(wù)粒度抽象為可配置項(xiàng)。

而企業(yè)內(nèi)部給使用者配置是也需要根據(jù)用戶習(xí)慣及標(biāo)準(zhǔn)化的操作進(jìn)行求同存異，因?yàn)榫€下的靈活性難以把控，所以盡可能將能在線上化的部分標(biāo)準(zhǔn)化，但保證使用者只能用到自己需要的功能和數(shù)據(jù)。

抽象程度越高，配置項(xiàng)越少，開發(fā)成本和實(shí)施成本越低，用戶體驗(yàn)越好，使用起來(lái)越貼身。否則隨著產(chǎn)品的生長(zhǎng)會(huì)衍生出更多權(quán)限點(diǎn)、更多角色，維護(hù)性變差，也極易出錯(cuò)，這也是筆者所親身經(jīng)歷的教訓(xùn)。

2. 從常說(shuō)的功能權(quán)限、數(shù)據(jù)權(quán)限的角度來(lái)看

常說(shuō)的功能權(quán)限也就是資源的容器（即頁(yè)面、目錄或菜單、Tab、按鈕）與行為（增刪改查等）的權(quán)限之和；數(shù)據(jù)權(quán)限及資源本身、行數(shù)據(jù)或個(gè)別列數(shù)據(jù)（字段）。

從各種權(quán)限模型及Oracle和Salesforce的經(jīng)驗(yàn)來(lái)看，更多情況下，功能權(quán)限配置在角色上，數(shù)據(jù)配置在用戶上。

在Oracle中有專門的數(shù)據(jù)角色，但數(shù)據(jù)角色是直接配置給用戶的。在Salesforce的簡(jiǎn)檔將一個(gè)用戶更基礎(chǔ)的對(duì)象及數(shù)據(jù)權(quán)限預(yù)先設(shè)置給用戶。

功能權(quán)限和數(shù)據(jù)權(quán)限一般設(shè)置盡量不要太細(xì)，能到菜單權(quán)限就不到頁(yè)面權(quán)限，能到頁(yè)面權(quán)限就不到按鈕權(quán)限；能到行數(shù)據(jù)權(quán)限就不到列數(shù)據(jù)權(quán)限；盡量避免不同用戶對(duì)相同字段有不同計(jì)算規(guī)則的情況。

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

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