国产a一级毛片爽爽影院_欧美日韩亚洲中字二区在线播放_国产在线每日都有更新_日韩中文字幕tv在线看_日韩美女婬乱大片A级网站_韩国无遮免费羞羞漫画_久久亚洲精品无码播放偷妻_国产成人777爽视频_色噜噜狠狠成人中文综合18_国产精品免费高清在线观看

權(quán)限管理是SaaS產(chǎn)品中最基礎(chǔ)卻最容易被忽視的“隱形骨架”。一旦設(shè)計(jì)失誤，輕則引發(fā)客戶操作混亂，重則導(dǎo)致數(shù)據(jù)泄露、信任崩塌。RBAC（基于角色的訪問(wèn)控制）模型之所以成為行業(yè)標(biāo)準(zhǔn)，正是因?yàn)樗谩敖巧边@一中間層，將指數(shù)級(jí)復(fù)雜的用戶-權(quán)限關(guān)系簡(jiǎn)化為可維護(hù)、可擴(kuò)展的結(jié)構(gòu)。對(duì)于從0到1搭建系統(tǒng)的產(chǎn)品經(jīng)理而言，理解并掌握權(quán)限設(shè)計(jì)，是構(gòu)建可信、可擴(kuò)展產(chǎn)品的必修課。

我自己帶過(guò)不少產(chǎn)品經(jīng)理，結(jié)果發(fā)現(xiàn)很少有人做過(guò)權(quán)限管理模塊的設(shè)計(jì)，或者設(shè)計(jì)過(guò)的也比較混亂。我之前覺(jué)得挺詫異的，因?yàn)闄?quán)限管理應(yīng)該是非常核心的模塊，就算沒(méi)設(shè)計(jì)過(guò)也應(yīng)該懂得基本的概念。后來(lái)才想明白，實(shí)際上是很多產(chǎn)品經(jīng)理都是負(fù)責(zé)單個(gè)模塊，沒(méi)有經(jīng)歷過(guò)從0-1的過(guò)程。權(quán)限管理模塊，往往在一開(kāi)始就設(shè)計(jì)好了，所以如果沒(méi)有經(jīng)歷過(guò)從0-1的產(chǎn)品設(shè)計(jì)，是很難有機(jī)會(huì)負(fù)責(zé)權(quán)限管理模塊的設(shè)計(jì)的。

01 權(quán)限管理非常重要

權(quán)限管理模塊一經(jīng)設(shè)計(jì)，要更改是非常麻煩的，對(duì)于 SaaS 產(chǎn)品更是如此。想象一下，如果我們更改了租戶業(yè)務(wù)系統(tǒng)的權(quán)限設(shè)置方式，意味著所有租戶都需要重新去調(diào)整每個(gè)角色，甚至每個(gè)人的權(quán)限（我們也踩過(guò)類似的坑）。

此外，如果權(quán)限設(shè)計(jì)出現(xiàn)紕漏，影響客戶的日常管理的話，會(huì)引發(fā)信任問(wèn)題。這種在不分庫(kù)分表設(shè)計(jì)的 SaaS 平臺(tái)非常常見(jiàn)。比如，我最近用的某個(gè) SaaS 接口服務(wù)平臺(tái)，就發(fā)現(xiàn)某些頁(yè)面刷新后居然能夠看到整個(gè)平臺(tái)的運(yùn)行數(shù)據(jù)。同樣的，如果租戶間的數(shù)據(jù)沒(méi)有做數(shù)據(jù)隔離，那么很可能因?yàn)闄?quán)限設(shè)計(jì)問(wèn)題，導(dǎo)致租戶間能夠看到彼此的數(shù)據(jù)。由于租戶之間很可能是同行競(jìng)爭(zhēng)關(guān)系，這種紕漏引發(fā)的信任度下降很難修復(fù)。

所以我們會(huì)看到，一方面權(quán)限管理是一開(kāi)始就需要設(shè)計(jì)的模塊，是一個(gè)非?；A(chǔ)的模塊；另一方面，如果設(shè)計(jì)出現(xiàn)問(wèn)題對(duì)整個(gè)租戶的業(yè)務(wù)和平臺(tái)的信任度都會(huì)有很大的影響。因此，權(quán)限管理是非常核心的模塊，我們?cè)谠O(shè)計(jì)產(chǎn)品時(shí)必須考慮周全。

02 為什么要用RBAC授權(quán)模型

在早期的企業(yè)信息化系統(tǒng)中，往往使用系統(tǒng)的人并不多，因此授權(quán)可以按用戶賬號(hào)進(jìn)行。

這里我們會(huì)發(fā)現(xiàn)，如果有 N 個(gè)用戶，M 個(gè)權(quán)限點(diǎn)，就意味著授權(quán)的組合會(huì)有 N 的 M 次方種。隨著用戶數(shù)的增加或系統(tǒng)的復(fù)雜性增加（權(quán)限點(diǎn)增加），就會(huì)導(dǎo)致整個(gè)授權(quán)的組合呈指數(shù)增長(zhǎng)。這樣帶來(lái)的問(wèn)題是：授權(quán)操作變得復(fù)雜，授權(quán)時(shí)每個(gè)用戶都需要勾選一遍權(quán)限點(diǎn)，很繁瑣。權(quán)限管控很難，每個(gè)用戶具體有什么權(quán)限不清楚。

在企業(yè)管理中，我們會(huì)發(fā)現(xiàn)實(shí)際上大部分情況下，相同崗位、相同職級(jí)的人員的權(quán)限是相同的。對(duì)于這些相同的權(quán)限，就可以引入一個(gè)授權(quán)的中間對(duì)象，來(lái)簡(jiǎn)化去A授權(quán)管理，這個(gè)中間對(duì)象就是角色（Role），由此得到了 RBAC 授權(quán)模型。

RBAC：Role Based Access Control，基于角色的訪問(wèn)控制，訪問(wèn)控制實(shí)際上就是權(quán)限控制。

大部分情況下，用戶和角色是一對(duì)一的關(guān)系，當(dāng)然也存在一人兼任多崗的情況，因此實(shí)際上要支持一個(gè)用戶對(duì)應(yīng)多個(gè)角色。我們來(lái)舉個(gè)例子，假設(shè)有100個(gè)用戶，30個(gè)權(quán)限點(diǎn)，這100個(gè)用戶可以分為10個(gè)角色。我們假設(shè)用戶和角色是一對(duì)一的。授權(quán)時(shí)假設(shè)按逐個(gè)權(quán)限點(diǎn)勾選的方式進(jìn)行，平均權(quán)限點(diǎn)是15個(gè)。那么沒(méi)有增加角色時(shí)，需要操作100×15 = 1500 次勾選操作。增加角色后，用戶勾選角色，只需要100次操作，然后角色勾選權(quán)限點(diǎn)變成了10×15 = 150 次勾選操作。對(duì)比之下，引入角色后的操作次數(shù)是沒(méi)有角色的1/6。這還只是一方面，如果要調(diào)整人員權(quán)限，沒(méi)有角色的話，就需要對(duì)所有涉及到的人員都操作一遍。引入角色后，則只需要調(diào)整角色對(duì)應(yīng)的權(quán)限，角色下人員權(quán)限會(huì)跟隨角色自動(dòng)調(diào)整。

03 預(yù)設(shè)角色

如果 SaaS 產(chǎn)品是針對(duì)某個(gè)業(yè)務(wù)領(lǐng)域或者垂直行業(yè)，比如 CRM，那么很多角色是可以預(yù)設(shè)的，這樣可以簡(jiǎn)化租戶側(cè)的授權(quán)管理。比如在紛享銷客中，就內(nèi)置了 CRM 管理員、CRM 觀察者、市場(chǎng)管理者、市場(chǎng)人員、銷售人員和售后人員等預(yù)設(shè)角色。

預(yù)設(shè)角色推薦是在 SaaS 平臺(tái)去配置，配置好之后同步給各個(gè)租戶。這里需要注意的是，租戶是可以對(duì)預(yù)設(shè)角色的權(quán)限進(jìn)行更改的。因此，預(yù)設(shè)角色對(duì)應(yīng)的權(quán)限點(diǎn)的數(shù)據(jù)需要做到不同租戶間相互隔離。同時(shí)，不建議平臺(tái)去修改預(yù)設(shè)角色的權(quán)限，因?yàn)檫@樣再同步的話，會(huì)導(dǎo)致租戶看到的權(quán)限和他們?cè)O(shè)置的權(quán)限不同。這種情況，會(huì)讓租戶認(rèn)為平臺(tái)操作了他們的數(shù)據(jù)。

因此，對(duì)于預(yù)設(shè)角色，雖然會(huì)簡(jiǎn)化租戶的權(quán)限設(shè)置，但是需要注意兩點(diǎn)：產(chǎn)品不成熟階段（需要到 GTM 階段）不建議設(shè)置，這個(gè)時(shí)候權(quán)限點(diǎn)可能會(huì)調(diào)整。當(dāng)然，如果產(chǎn)品規(guī)劃很詳細(xì)也沒(méi)問(wèn)題。預(yù)設(shè)角色權(quán)限如果進(jìn)行了調(diào)整，對(duì)新客戶可以直接同步，對(duì)于老客戶，建議通知客戶自行處理，或者體驗(yàn)好一點(diǎn)，讓他們確認(rèn)是否按調(diào)整后的更新權(quán)限。這種情況，不要直接對(duì)老客戶的進(jìn)行調(diào)整，可能會(huì)影響客戶的業(yè)務(wù)運(yùn)行。

04 角色分組

這個(gè)根據(jù)需要來(lái)確定，如果角色過(guò)多，分組還是有必要的，比如平臺(tái)側(cè)可以分為產(chǎn)品、開(kāi)發(fā)、運(yùn)營(yíng)、市場(chǎng)、管理等等組。當(dāng)然，如果是租戶側(cè)，那么建議是支持租戶自己對(duì)角色進(jìn)行分組，畢竟每家企業(yè)的管理模式不同 —— 作為 SaaS 平臺(tái)，應(yīng)該把業(yè)務(wù)規(guī)則交給客戶去配置。

另一種情形是客戶是全國(guó)性的集團(tuán)企業(yè)，他們?cè)谌珖?guó)各地有分公司?？赡艿那闆r是，每家分公司的管理模式會(huì)有差別，這種差別反映到角色上就是每家分公司需要自己管理自己的角色，以避免其他公司修改影響業(yè)務(wù)。我們就遇到過(guò)這樣的情況，同樣一個(gè)收費(fèi)員崗位，有的分公司支持作廢單據(jù)，有的需要審核由上級(jí)作廢。這個(gè)時(shí)候，角色本身需要作為一個(gè)業(yè)務(wù)對(duì)象進(jìn)行數(shù)據(jù)授權(quán)，來(lái)控制管理范圍（即 A 分公司只能管 A 分公司的角色，B 公司只能管B 分公司的角色）。實(shí)際上，這也是一種角色分組，我們可以按組進(jìn)行數(shù)據(jù)范圍授權(quán)即可。

05 原型設(shè)計(jì)

RBAC 的原型設(shè)計(jì)本身并不復(fù)雜，一個(gè)是角色的管理，另一個(gè)是角色權(quán)限的分配。同時(shí)，為了查看當(dāng)前角色下的有哪些人員，會(huì)有一個(gè)角色成員管理。

角色管理原型如下，左側(cè)按分組展示角色清單，鼠標(biāo)點(diǎn)擊某個(gè)角色時(shí)可以查看該角色權(quán)限（這里是菜單權(quán)限，數(shù)據(jù)權(quán)限后續(xù)再講）和角色成員。鼠標(biāo)停留在角色名稱上時(shí)顯示編輯和刪除按鈕。這里需要注意，如果角色下已有成員，則不能刪除該角色。對(duì)于刪除這類操作，如果存在依賴該條數(shù)據(jù)的關(guān)聯(lián)數(shù)據(jù)，則不允許刪除。編輯角色可以修改分組和角色名稱。

編輯權(quán)限實(shí)際上就是允許勾選授權(quán)的菜單進(jìn)行保存，我們應(yīng)該支持所有菜單都不勾選，也就是將角色的權(quán)限清空。編輯權(quán)限的原型界面如下。

角色成員管理比較簡(jiǎn)單，一般是列出賬號(hào)對(duì)應(yīng)的人員姓名、賬號(hào)、所在部門等信息，然后支持批量添加或移除成員（可以使用穿梭框組件來(lái)做交互）。這里就不再畫相應(yīng)的原型了。公眾號(hào)消息回復(fù)“權(quán)限”可以查看在線原型。

06 抽象設(shè)計(jì)

我們?cè)诋a(chǎn)品設(shè)計(jì)過(guò)程中，需要發(fā)現(xiàn)不同模塊的相通之處，這樣就可以提煉我們自己的產(chǎn)品設(shè)計(jì)模型。以 RBAC 為例，如果回顧我們之前的銷售版本管理和客戶授權(quán)的話，就會(huì)發(fā)現(xiàn)，本質(zhì)上其實(shí)是一樣的。銷售版本就相當(dāng)于是RBAC 里的角色，我們基于版本對(duì)客戶進(jìn)行授權(quán)，從而可以簡(jiǎn)化 SaaS 平臺(tái)的客戶授權(quán)操作。本質(zhì)上，就是將具有共同特性的部分單獨(dú)抽象出來(lái)一個(gè)新的中間業(yè)務(wù)對(duì)象，從而可以簡(jiǎn)化我們業(yè)務(wù)操作，提高效率。