全栈工程师?
嗯.....目前并不是!

熟悉這四種權限管理模型,產品迭代才能心裡有數

不管是2C產品經理還是2B產品經理,都要將權限管理法則爛熟於心。只有熟悉權限管理法則,才能更好地理解自己產品的架構,做到每次產品迭代都心裡有數。

從本質來說,無論何種類型的權限管理模型都可以抽象出三個基本的要素——即:用戶(user)、系統/應用(system/application)、策略(policy)。

策略決定了用戶和不同功能應用之間如何交互。反過來,也就是說,無論設計何種權限管理的模型,都是基於這三個基本要素來展開。

本文聚焦於目前應用最廣的RBAC模型,但在這裡提出三個基本要素,主要是為了幫助大家更好的理解權限管理,不至於在眾多權限模型中迷失。

不同的公司或軟件提供商,設計了無數種控制用戶訪問功能或資源的方法。但無論哪種設計,都可歸到四種經典權限模型里——自主訪問控制(DAC,Discretionary Access Control)、強制訪問控制 (MAC,Mandatory Access Control)、基於角色訪問控制 (RBAC,Role-based Access Control) 和基於屬性訪問控制  (ABAC,Attribute-based Access Control).

(我覺得翻譯不好,但也找不到更貼切的。本文下面內容均以英文首字母來代替:DAC,MAC,RBAC,ABAC)。

一、DAC,MAC

本文主要就RBAC展開分析該模型的使用場景,以及如何基於該模型設計出合適的權限管理體系。但從文章便於理解的完整性的角度來考慮,會對DAC,MAC和ABAC進行簡要的介紹。

DAC:被操作對象,根據訪問控制規則,來判斷操作主體可對操作對象做哪些操作,比如只讀或者是可寫的權限。而自主的含義,則是擁有某種權限的用戶,可以把權限賦予其他用戶。

MAC:被操作對象及用戶兩方均有各自的權限標識,用戶能否對對象進行操作,取決於權限標識的對照關係。這種模型多用於等級制度明顯,信息訪問安全性要求高的場景,比如軍事。

ABAC和RBAC有很多相通的地方,而且相比較而言ABAC實際上更靈活,符合未來發展的方向。因此,我們分析完RBAC后,再回過頭來看ABAC。

二、那麼,什麼是RBAC呢?

Role-based Access Control,基於角色的權限控制模型。

顧名思義,給用戶定義角色,通過角色來控制權限。目前來說基於角色權限控制模型是應用較廣的一個。特別是2B方向SAAS領域,應用尤其常見。

如上圖示,用戶擁有角色,且可擁有多個角色,而每個角色對應不同權限。

這樣的好處是:不必為每一個用戶去配置權限,擁有極大的靈活性和便利性。而當用戶及權限的量級又大到另一個級別時,又引入了角色組和權限組概念,此處不做延伸,有興趣的讀者可以去搜些資料來看。

三、怎麼利用RBAC模型來進行權限體系的設計?

我們已經知道什麼是RBAC模型了,在分析怎麼來根據此模型來設計權限體系之前,我們再把這個模型要素進行拆分一下。

首先是:用戶、角色、權限。

而權限,具體到某個軟件來說,實際上包含兩個方面。一個是菜單權限,另一個是數據權限。

不同的行業會有不同的使用場景,用戶角色權限模型也會有不同程度上的變化。但歸到底層來說,還是離不開上面我畫的這個圖。

上面這個圖是從官網看到的,銷售自動化領域十分典型的用戶權限管理設計。

接下來,我們來抽象一個場景或者說案例,來輔助我們理解整個權限管理設計的過程。假設A公司是個中大型的生產製造公司,公司有OA、HR、CRM、ERP一系列管理軟件。公司員工以萬計,不同人員職責不同,體現在管理軟件上,就是會需要使用不同的功能來完成工作。

帳號管理

帳號是人和軟件進行交互時的一個身份的轉化。賬號的背後,代表了這個操作的人。賬號管理應該是所有需要和系統交互的人的統一管理,包含基礎信息,比如:這個人的名字,性別、手機號、部門以及其他屬性。

角色管理

角色管理,就是要從實際場景出發,比如:使用系統的企業或者團體,有哪幾類使用的角色——也就是說,有哪幾類人,是需要有不同的業務菜單和業務數據的。

說到底,角色管理,就是把這個角色對應的人平時工作需要的菜單、功能給劃到一個組裡。給這一個個的操作組定義不同的名稱——即角色名稱。

當然,這個角色管理除了規定了該角色的人平時可對哪些功能進行查看操作,還需規定這個角色,能看到哪些範圍內的數據。也就是前面提到的,權限實際上包含的是菜單權限和數據權限兩部分。

系統內功能控制的顆粒度越細,對使用者來說配置角色便越靈活,但對系統的設計者來說,系統的複雜度自然也會上升,成本也會增加。

因此,到底控制到哪一層級,就要視具體業務場景來定,比如:有些行業的系統,可能控制到一級菜單就可以(某些SAAS工具),但有些系統,不僅需要控制所有的子級菜單,每一個按鈕操作,甚至還會需要控制到不同的字段(比如Salesforce的權限控制系統)。

不過,我們抽象出了基本的模型,根據實際業務再去發散,就不是最困難的事了。

四、看看ABAC,順便暢想下未來的權限模式

至此,我們可以了解到:RBAC模型實際上能解決大部分的權限設計問題了。

那麼,ABAC到底是什麼呢?它存在的意義在哪裡?關於未來的權限設計趨勢,它能帶給我們什麼啟發呢?

帶着這些問題,我們先來看看到底什麼是ABAC模型。

ABAC,Attribute-based Access Control. 基於屬性的訪問控制。而屬性,總的來說有三類:用戶屬性、系統或應用被訪問屬性(數據和操作)、環境屬性。

也就是說,系統根據一組或多組屬性是否滿足預設規則來動態的控制,誰可以訪問哪些功能數據和操作。RBAC模型,其實可以看成是靜態的、單組屬性的ABAC模型。

用例子來理解這個模型就是:只有當用戶角色為Admin,在工作時間內,且處在C棟大樓B實驗室,才可以訪問D文件。

實際上,ABAC是個可以以最細顆粒度來管理權限的模型。它可以讓設計者,利用任何一個用戶屬性、環境屬性,或者多個屬性之間的交集、並集等來組合出動態的權限判斷邏輯。

它是這麼強大,既可以有效的幫助信息辨別能力差的用戶過濾垃圾信息。也可以讓商家用到營銷廣告填滿你生活的每個角落卻不自知。

但我一直堅信,科技絕對是讓生活更美好。

五、總結一下

權限管理,可能是每個2B產品經理需要面對的問題。但無論C端還是B端的產品,了解權限管理的設計法則,讓自己更好的理解產品的架構,讓產品的每次迭代都心裡有數。

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《熟悉這四種權限管理模型,產品迭代才能心裡有數》
文章链接:https://www.pmbear.com/archives/9396
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们