實戰一. 許可權系統是如何設計的?
許可權系統是每個系統裡面必備的最基本的系統，就像蓋樓房必須先打好地基，許可權系統就像這個樓房的地基一樣，沒有地基就無法蓋好樓房，同樣沒有許可權系統，就不能保證企業內部組織機構分配系統使用的許可權，這樣無法避免因許可權控制缺失或操作不當引發的風險問題，如操作失誤和數據泄露等，無法保證系統設置的安全策略。
一. 什麼是許可權？
目前很多產品經理都會把許可權分為三種：菜單許可權，功能許可權和數據許可權，這種說法也不能說不正確，因為這種分法主要是針對角色管理的許可權系統。但是真正意義上而言，許可權的劃分應該為：許可權=功能許可權/數據許可權 ∩ 資源許可權，這是基於資源管理的許可權系統。
舉個例子說明，設計一套工程師管理雲主機的許可權，那麼如下所示：
二. ACL模型
ACL全稱Access Control List，在ACL中，包含用戶(user)、資源(Resource)、資源操作(Operation)三個關鍵要素。通過將資源以及資源操作授權給用戶而使用戶獲取對資源進行操作的許可權，如下所示：
基於ACL模型的許可權核心在於用戶直接和許可權掛鉤，此時A的許可權=A的功能許可權 ∩ 隱式資源許可權，如下表：
從表格舉例，技術負責人的許可權=技術負責人可以操作的功能許可權(查詢、重啟、登錄、開機、關機、添加和刪除)以及技術負責人對應的資源(1-14號主機)，即是技術負責人A可以對1-14號主機進行查詢、重啟、登錄、開機、關機、添加和刪除。
三. RBAC模型-Role角色
基於角色的許可權系統，目前是絕大多數許可權主流的設計方式。基於角色的許可權系統核心是一個賬號對應多個角色，每個角色對應相應的許可權集(RBAC模型)，這種模型基本可以應對所有的問題。對應的關係模型如下：
此時，A的功能許可權=角色對應的許可權，如下表格：
從表格舉例說明，技術負責人A的功能許可權=技術負責人這個角色對應的功能許可權(查詢、重啟、登錄、開機、關機、添加和刪除)，同時技術負責人A可以通過對應的角色操作資源(1-14號主機)，即是技術負責人的角色可以對1-14號主機進行查詢、重啟、登錄、開機、關機、添加和刪除。
基於角色許可權系統的設計思維為：
(1) 創建組織機構；
(2) 創建角色；
(3) 創建用戶/用戶組；
(4) 將用戶/用戶組關聯組織機構；
(5) 將角色配置相應的許可權；
(6) 將用戶/用戶組關聯相應的角色。
這裡就不一一展現設計流程，如有需要，可以私聊小編。
四. RBAC模型-結合ACL
這種模型是將角色許可權系統的設計思維結合ACL模型的設計思維，也是一種不錯的設計思路，具體模型如下：
此時A的功能許可權=A的功能許可權 ∪ 角色對應的功能許可權，如下表格：
舉例說明，技術負責人A的功能許可權=技術負責人A單獨分配的功能許可權+技術負責人角色對應的功能許可權(查詢、重啟、登錄、開機、關機、添加和刪除)+技術負責人對應的資源(1-14號主機)，即是技術負責人A以對1-14號主機進行查詢、重啟、登錄、開機、關機、添加和刪除以及單獨分給技術負責人A的功能。
五. RBAC模型-Resource資源
這種模型是基於資源的許可權系統。在這裡，我們首先要明白基於角色的許可權體系相對應的缺點：
(1) 角色命名不規範，導致數量過多，比如角色可以用來做功能許可權，做數據許可權的話便會產生很多角色；
(2) 角色是相對獨立的，而組織機構卻是樹形結構，這樣會導致角色很難與組織機構相互映射，在授權的時候，上級會自動獲取下級的許可權；
而基於資源的許可權系統不和任何的實際的業務關聯，只做許可權相關的管理和驗證，一切以資源為核心，對應的模型為：
此時A的許可權 = A的功能許可權 ∩ 顯式資源許可權，如下表格：
舉例說明，技術負責人A的許可權 = 技術負責人角色的功能許可權(查詢、重啟、登錄、開機、關機、添加和刪除) + 技術負責人角色分配的資源(1-14號資源)，即是技術負責人A可以對1-14號主機進行查詢、重啟、登錄、開機、關機、添加和刪除，而研發工程師C只可以對1-5號主機進行查詢和重啟。將1-14號主機作為資源分給了技術負責人A，將1-5號主機分給了研發工程師C，同時A對應的角色為技術負責人，C對應的角色為研發，所以對應的角色功能也不一樣。
推薦閱讀：
