電商課題：RBAC許可權控制

@鄭昀匯總  名詞解釋：RBAC：Role-Based Access Control，角色型存取控制  關鍵詞：RBAC，Java Shiro，Spring Security，  一. RBAC 要解決的常見問題問題一： 對某一個使用者只授予一些特殊的許可權描述：既不希望擴大某一個角色的許可權，也不希望因此建立出很多零碎的、只為一個使用者而存在的角色。 問題二： 效能問題描述：B/S 下，菜單、頁面、頁面元素、dataset的列，這些層層許可權判斷過於複雜，容易造成系統訪問非常緩慢。 問題三： 如何減少 HardCode（寫入程式碼）描述：  問題四：系統上線後，某個頁面增加一個新HTML控制項或資料集，這種細粒度許可權控制如何以最快速度添加？描述：對一個 Resource 的 Privilege ，如何快速增加定義？如何快速分配許可權？頁面如何控制？  問題五：系統上線後，增加一個新細粒度許可權控制，運營部門如何最快速度將其應用到已存在角色和帳號上？描述：對於系統中已存在的成百上千角色、成千上萬帳號甚至於無數使用者組，一個運營部門的管理員，如何能以最小代價，通過介面，將此許可權分配出去。  二. 一個在許可權邏輯和商務邏輯之間做切割的設計原則 2.1.細粒度是否算許可權系統的範疇先解釋兩個概念：

• 粗粒度：表示類別級。即僅考慮對象的類別，不考慮對象的某個特定執行個體。譬如，使用者管理中，增刪改查，對所有的使用者都一視同仁，並不區分操作的具體對象執行個體。
• 細粒度：表示執行個體級。即需要考慮具體對象的執行個體，當然，細粒度是在考慮粗粒度的物件類別之後才再考慮特定執行個體。譬如，合約管理中，列表、刪除，需要區分該合約執行個體是否為目前使用者所建立。

許可權邏輯配合商務邏輯。譬如，需求方給出了一個情境：“合約資源只能被它的建立者刪除，與建立者同組的使用者可以修改，所有的使用者能夠瀏覽”，那麼這 既可以認為是一個細粒度的許可權問題，也可以認為是一個商務邏輯問題。如果認為這是一個商務邏輯問題，那麼設計許可權系統時就不需要過多考慮這種情境。當然，許可權系統也必須能支援這樣的控制判斷，或者說，許可權系統提供足夠多但不是完全的控制能力。此時，設計原則歸結為：“ 系統只提供粗粒度的許可權，細粒度的許可權被認為是商務邏輯的職責”。這也是複雜問題簡單化的一種思路。 這些對具體 Resource Instance 的細粒度許可權問題，被留給商務邏輯來解決，這樣的考慮基於以下兩點：

1. 細粒度的許可權判斷必須要在資源上建模許可權分配的支援資訊才可能得以實現。這樣，又引入了 Owner 概念。

• 譬如，如果要求建立者和普通使用者看到不同的資訊內容，那麼資源本身應該有其建立者的資訊。如同 Unix 的每一個檔案（資源），都定義了對 Owner， Group， All 的不同操作屬性。

細粒度的許可權常常具有相當大的商務邏輯相關性。

• 對不同的商務邏輯，常常意味著完全不同的許可權判定原則和策略。相比之下，粗粒度的許可權更具通用性，將其實現為一個架構，更有重用價值；而將細粒度的許可權判斷實現為一個架構層級的東西就顯得繁瑣，而且不是那麼的有必要，用定製的代碼來實現就更簡潔，更靈活。

當然，鄭昀說，許可權系統不可能做成通用，必須就事論事，所以往往在設計時，還是既照顧粗粒度也照顧細粒度。這裡只是提一下有這種一刀切的思路。  2.1.資料集的列許可權是否算許可權系統的範疇

頁面需要展示一個資料集（dataset），那麼對某些列的展示、可讀、可寫的控制，是否要放在許可權系統中解決？

答案是，為了簡化，為了避免過度侵入商務邏輯，列許可權不在許可權系統範疇內。  三. RBAC 是什麼RBAC 認為許可權授權實際上是 Who、What、How 的問題，即可簡單表述為： 判斷“Who 對 What(Which) 進行 How 的操作”的邏輯運算式是否為真。 RBAC 涉及的概念有：

• Who：許可權的擁用者或主體（如 User、Group、Role 等）；
• What：許可權針對的對象或資源（Resource、Class）；
• How：具體的許可權（Privilege）。
• 正向授權在開始時假定主體沒有任何許可權，然後根據需要授予許可權，適合於許可權要求嚴格的系統。
• 負向授權在開始時假定主體有所有許可權，然後將某些特殊許可權收回。
• Operator：操作。表明對 What 的 How 操作。
• 也就是 Privilege+Resource ；
• 注意，這裡的 Resource 僅包括 Resource Type 不表示 Resource Instance；
• 之所以將 What 和 How 綁在一起作為一個 Operator 概念，而不是分開建模再建立關聯，這是因為很多的 How 對於某個具體 What 才有意義。譬如，發佈動作對新聞對象才有意義，對使用者物件則沒有意義。
• Role：角色，一定數量的許可權的集合。許可權分配的單位與載體，目的是隔離 User 與 Privilege 的邏輯關係；
• Group：使用者組，許可權分配的單位與載體。許可權不考慮分配給特定的使用者而給組。組可以包括組(以實現許可權的繼承)，也可以包含使用者，組內使用者繼承組的許可權。User 與 Group 是多對多的關係。Group 可以層次化，以滿足不同層級許可權控制的要求。
• Session： 會話是使用者與啟用的角色集合之間的映射。每個 Session 和單個的 User 關聯，每個 User 可以關聯到一或多個 Session 。

 RBAC 支援三個安全原則：

1. 最小許可權原則（即細粒度控制原則）：

• RBAC 可將其角色配置成其完成任務所需要的最小許可權集；

責任分離原則

• 通過調用相互獨立互斥的角色來共同完成敏感的任務而體現，如要求一個計帳員和財務管理員一起參與同一個過帳；

資料抽象原則

• 通過許可權的抽象來體現，如財務操作用借款、存款等抽象許可權。

  四. 標準 RBAC 模型NIST （美國國家標準與技術研究院）標準 RBAC 模型由4個組件模型組成，分別是基本模型RBAC0（Core RBAC）、角色分級模型RBAC1（Hierarchal RBAC）、角色限制模型RBAC2（Constraint RBAC）和統一模型RBAC3（Combines RBAC）。RBAC0 模型1所示：

圖1 RBAC 0 模型

RBAC0 定義了能構成一個 RBAC 控制系統的最小的元素集合：

• RBAC 定義了 五個基本資料元素：

1. 使用者 users(USERS)
2. 角色 roles(ROLES)
3. 目標 objects(OBS)
4. 操作 operations(OPS)
5. 許可權 permissions(PRMS)

RBAC0 商務規則有：

• 一個使用者可以對應多個角色，一個角色也可以分配給多個使用者；
• 一個角色可以有多個許可權，一種許可權則只與一個角色對應；
• 使用者可以發起會話，會話中可以啟用多個角色來擷取許可權；
• 使用者、角色、許可權全部由超級管理員建立與指派；
• 一個使用者擁有多個角色時，高優先順序的角色許可權覆蓋低優先順序的角色許可權。

RBAC1（引入角色繼承關係）、RBAC2（引入責任分離關係）、RBAC3 （角色繼承+責任分離）都是先後在 RBAC0 上的擴充。  五. RBAC 核心物件模型授權模型：使用者-角色-許可權 核心動作：

• 創造許可權
• 分配許可權
• 使用許可權

 核心動作的主要參與者：

• Creator 創造許可權：這裡完成的是 Privilege 與 Resource 的對象聲明；
• Administrator 分配許可權：把 Privilege 與 Resource Instance 真正關聯到一起，產生了 Operator （Privilege Instance）。Administrator 利用 Operator 這個基本元素，來創造他理想中的許可權模型，如建立角色，建立使用者組，給使用者組分配使用者，將使用者組與角色關聯等；
• User 使用許可權

  

參考資料：

1）iteye編輯總結，許可權控制討論；2）基於RBAC模型的許可權管理系統的設計和實現3） jackyz@jdon，2002，關於許可權系統的設計