RBAC權限控制

RBAC權限控制

概念

• RBAC（Role-Based Access Control）基於角色的訪問控制。
• RBAC可以概況爲：判斷【who是否可以對what進行how的訪問操作】這個邏輯表達式的值是否爲true的求解過程，即將問題轉換爲who、what、how的問題，who、what、how構成了訪問權限三元組。
• RBAC支持公認的安全原則：
  1. 最小特權原則
     • 在RBAC模型中可以通過分配給角色權限的多少和大小來實現最小特權原則，即分配給某個用戶對應的角色的權限只要不超過該用戶完成其任務就可以了。
  2. 責任分離原則
     • 通過調用獨立互斥的角色來共同完成敏感的任務，比如轉賬可以通過設立財務和審計兩個角色來完成。
  3. 數據抽象原則
     • 將具體的業務抽象稱爲許可權，而不是使用操作系統提供的讀、寫、執行等具體的許可權。
     • 我的理解是將業務抽象爲一個個的許可權（是否有權限操作，比如轉賬許可權、消費許可權等），而不是增刪改查。

RBAC模型

• 現在比較公認的是RBAC96模型，包括RBAC0~RBAC3四個概念性的模型。
  1. 基本模型RBAC0定義了完全支持RBAC概念的任何系統的最低需求。
  2. 高級模型RBAC1、RBAC2都包含RBAC0，但又各自增加了獨立的特點。
     • RBAC1：增加了角色分級的概念，一個角色可以從另一個角色繼承許可權。
     • RBAC2：增加了一些限制，比如互斥角色的限制，即在一次活動中一個用戶只能被分配其中的一個角色，不能同時獲得兩個角色的使用權，比如在之前的轉賬例子中，一個用戶不能既是財務又是審計。
  3. 統一模型RBAC3，即包含了RBAC1和RBAC2，又根據傳遞性也包含了RBAC0。

RBAC模型簡述

1. RBAC0

• RBAC0模型中包括用戶（U）、角色（R）和許可權集合（P）、會話集合（S）。
• RBAC0是權限管理的核心部分，其他模型都是建立在此基礎上。

2. RBAC1

• 主要是增加了繼承關係（等級關係），也就是說組員的權限，組長可以繼承，這樣組長既有組員的權限又有一些特殊的權限。

3. RBAC2
   *角色互斥，是指一個審批，組員發起，組長審批，那麼一個用戶就不能即是組員又是組長，也就是說同一個活動一個用戶又發起又審批（責任分離），所以也可以看出來RBAC1和RBAC2是互不兼容的。
4. RBAC3

• 將RBAC1和RBAC2組合在一起，提供角色的分級和繼承能力，但這也引起了一些新的問題。
  

數據庫設計

1. RBAC的5張表

• 用戶表、角色表、權限表，一個用戶可以關聯多個角色，一個角色可以對應多個用戶，一個角色可以有多個權限，一個權限可以賦給多個角色，所以用戶表與角色表、角色表與權限表都是多對多的關係，這樣在三張表的基礎上又加上用戶角色關聯表、角色權限關聯表，組成了基礎的5張表。
  
  2. 角色與用戶組

  • 角色是一組權限的集合，當用戶數量非常大的時候，給每一個用戶授權時非常的麻煩，這時我們可以引入用戶組的概念，每個用戶組內有多個用戶，然後通過給用戶組授權來達到給組內用戶授權的目的，這時組內用戶的權限=用戶組的權限+用戶的權限。數據表結構如下：
    

    3. 權限

  • 權限對應於我們系統中一般分爲資源權限、功能權限。資源權限是指按鈕、圖片的可見性等，操作權限是指文件的刪、改，菜單訪問等，兩者界限比較模糊。通常做成“用戶-角色-權限-資源”的授權模型，而在設計數據表時，可把功能操作和資源統一管理，直接與權限表關聯。數據表結構如下：
    

  總結

  • RBAC是目前比較主流的權限設計模型，apache shiro、spring security都是RBAC的權限驗證框架，在權限表中如果僅僅是1:1的對應關係，資源與權限關聯表可以不要，另外在權限表中注意區分資源的類型。