無管理員許可權怎麼回事
合理的許可權管理方案將有利於處理更多事務，提升操作效率，也降低風險發生的可能性。使用者能夠在有限範圍內使用資源，管理者基於系統進行資源分配。本篇文章講解了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協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。