權限的游戲:淺談產品權限分析與設計
合理的權限管理方案將有利于處理更多事務,提升操作效率,也降低風險發生的可能性。使用者能夠在有限范圍內使用資源,管理者基于系統進行資源分配。本篇文章講解了4種訪問控制授權方案,一起來看一下。
目前我們使用的訪問控制授權方案,主要有以下4種:
- DAC自主訪問控制
- ACL 訪問控制列表
- MAC強制訪問控制
- RBAC 基于角色的訪問控制
筆者將拆解和分析這4種權限管理方案的邏輯,并告訴你,這4種權限分別可以運用在什么樣的場景中,以及它們應該怎么設計。
一、DAC自主訪問控制
DAC(DiscretionaryAccess Control)自主訪問控制方式:該模型針對每個用戶指明能夠訪問的資源,對于不在指定的資源列表中的對象不允許訪問。
《信息系統系項目管理師教程》(第3版)P656
如上圖所示,我們假設有兩名用戶(用戶1、用戶2)和4個權限(權限1~4),用戶1指明能夠訪問權限1和權限2,用戶2指明能夠訪問權限3和權限4,授權成立之后就會出現如下的情況:
用戶1可以正常訪問權限1和權限2,但是如果想訪問權限3或權限4,由于自身權限列表中沒有這2個權限,所以不允許訪問;用戶2也是相同道理,可以訪問權限3和權限4,但無法訪問權限1和權限2。
這種授權方式適用于用戶少權限多的場景,常見于網盤的資源分享中.
用過網盤的人都知道,網盤的分享功能就是選擇想要分享的文件,點擊分享,這個時候會生成分享鏈接,而這個分享鏈接,其實就是一個“用戶對象”,這個“用戶對象”指定了可以訪問我們所選取的文件,這樣當我們把鏈接分享出去的時候,打開鏈接的人就可以看到我們所選取的文件,但對于我們沒有選取的網盤內的其他文件,是無法看到的。
同理,這個時候如果我選取另外的文件并創建新的分享鏈接,則等同于創建了一個新的“用戶對象”,雖然新的分享鏈接中的文件可能與之前的分享鏈接中的文件重疊甚至完全相同,但是訪問的時候,本質上還是根據不同的“用戶對象”訪問他們被指定允許訪問的資源。
二、ACL 訪問控制列表
ACL(AccessControlList)訪問控制列表方式:該模型是目前應用最多的方式。目標資源擁有訪問權限列表,指明允許哪些用戶訪問。如果某個用戶不在訪問控制列表中,則不允許該用戶訪問這個資源。
《信息系統系項目管理師教程》(第3版)P656
從定義上來看,這種授權方式跟上一種授權方式本質是一樣的,但是授權的邏輯相反。
如上圖,權限1和權限2分別指明允許用戶1訪問,權限3和權限4分別指明允許用戶2訪問。同樣的,如果用戶1想要訪問沒有被授權的權限3和權限4的時候,便訪問不了。
這種授權方式與上一種授權方式適用的場景相反,更適用于權限少用戶多的場景,常用于“抄送”功能中,比如發郵件時候的抄送功能,或者 OA 系統審批后的抄送功能,添加抄送人的過程其實就是針對當前的這個權限(郵件或審批單)指明允許哪些用戶訪問的過程。
三、MAC 強制訪問控制
MAC(MandatoryAccess Control)強制訪問控制方式,該模型在軍事和安全部門中應用較多,?目標具有一個包含等級的安全標簽(如:不保密、限制、秘密、機密、絕密);訪問者擁有包含等級列表的許可,其中定義了可以訪問哪個級別的目標:例如允許訪問秘密級信息,這時,秘密級、限制級和不保密級的信息是允許訪問的,但機密和絕密級信息不允許訪問。
《信息系統系項目管理師教程》(第3版)P656
如上圖,假設有4個標簽,標簽1~4分別對應權限1~4(實際設計中,一個標簽可能對應多個權限),標簽等級為:標簽1 > 標簽2 >標簽3 > 標簽4,如果定義了用戶1為標簽2,用戶2為標簽3,如下:
則有:
如上,用戶1可以訪問標簽2及其等級以下的權限(權限2、3、4),用戶2可以訪問標簽3及其等級以下的權限(權限3、4)。
如上文所述,“該模型在軍事和安全部門中應用較多”,因此在我們平時的產品中比較少接觸到,接下來我隨便畫畫,根據上文的定義嘗試分析一下這個權限在做產品時可以怎么設計。
首先需要有設計一個“標簽管理”頁面:
標簽需要有等級關系,等級可以手動輸入,但注意等級不能相同,保存后如需調整等級,注意調整前需做好二次確認,一旦標簽等級調整,意味著權限也會跟著變化,當標簽從低等級往高等級調整時,會給已關聯的用戶釋放更多的權限;刪除標簽時,如果標簽已關聯了用戶,需要求取消用戶關聯,否則刪除后,所關聯的用戶將失去所有權限,無法正常訪問。
接著需要一個“標簽編輯”頁:
注意這里的等級不能與其他已添加的標簽等級相同,標簽名稱原則上也不能相同,權限中,已經被其他標簽關聯的權限需要隱藏或不允許選擇,否則如果一個高級別的標簽跟一個低級別的標簽都關聯了同一個權限,這樣根據等級授權就沒有意義了;
把關聯用戶也放在標簽管理頁,是因為標簽與用戶是一對多的關系,這樣配置起來效率更高,同樣需要注意,已關聯了標簽的用戶這里需要隱藏或不允許選擇,也可以在用戶管理頁面增加關聯用戶標簽的設計。
四、RBAC 基于角色的訪問控制
RBAC(Role-BasedAccess Control)基于角色的訪問控制方式:該模型首先定義一些組織內的角色,如局長、科長、職員;再根據管理規定給這些角色分配相應的權限,最后對組織內的每個人根據具體業務和職位分配一個或多個角色。
《信息系統系項目管理師教程》(第3版)P656
這種可以說是目前絕大多數系統都在用的一種權限管理方式。
如上圖,假設有兩個角色,角色1分配權限1和權限2,角色2分配權限3和權限4,用戶1、2分別屬于角色1、2:
則:
用戶1可以訪問角色1所擁有的權限1、2。
這種權限管理方式相對于另外3種,更具靈活性,在常規的產品設計中,用戶與角色一般是一對一關系,即一個用戶只能對應一個角色,但為了增加靈活度,也有系統會設計成一對多關系,即一個用戶可以對應多個角色,用戶的權限等于所對應的角色權限的總和,甚至還發展出給用戶單獨授權的設計,就是在用戶繼承了角色所有權限的基礎上,還可以額外再給指定的用戶單獨授權,這樣這個用戶就比其他同角色的用戶擁有更多權限。
還是隨便畫畫,說說這種權限管理怎么設計。
首先需要一個“角色管理”頁面:
系統初始提供一個“超級管理員”角色,該角色擁有所有權限,不可修改,不可刪除。
接著是添加角色并授權:
然后是添加用戶,除了常規的賬號信息,還需要給用戶指定一個角色,由此獲得相應權限:
在用戶列表可以給用戶單獨授權:
好了,以上便是4種權限管理方式的分析和設計,希望對還沒做過權限設計的你有參考價值,感謝閱讀!
公眾號:產品錦李(ID:IMPM996)
本文由 @產品錦李 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
講得很好,對新手有很大啟發
在用戶列表給用戶單獨授權,這個以前沒有考慮過
有所啟迪,說的比較完善啦!感謝。
目前正在有一個權限的規劃等著做,打算用RBAC的方式來做,再學習幾次,然后開始動手!