許可權系統設計(0):許可權系統設計基本概念改需-MAC/RBAC引子

此篇主要對許可權系統設計所涉的一些專業術語重點梳理。從我們windows的文件系統自主訪問控制到基於角色訪問控制。

許可權設計基本術語

對後面會用到的辭彙做一個簡要說明

什麼是許可權（許可）

許可權（Privilege/Permission）是指為了保證職責的有效履行，任職者必須具備的，對某事項進行決策的範圍和程度。它常常用「具有批准……事項的許可權」來進行表達。例如，具有批准預算外5000元以內的禮品費支出的許可權。

在電腦系統中，許可權是指某個特定的用戶具有特定的系統資源使用權力。而在我們做的後台管理系統，資源指的是系統中所有的內容，包括模組、菜單、頁面、欄位、操作功能（增刪改查）等等。大致可以將許可權分為：

功能級許可權管理，在作業系統中的任何動作、交互都是功能許可權，如增刪改查等。
數據級許可權管理。一般業務管理系統，都有數據私密性的要求：哪些人可以看到哪些數據，不可以看到哪些數據。

從控制方向來看，也可以將許可權管理分為兩大類：

從系統獲取數據，比如查詢訂單、查詢客戶資料
向系統提交數據，比如刪除訂單、修改客戶資料

許可權管理

許可權管理，一般指根據系統設置的安全規則或者安全策略，用戶可以訪問而且只能訪問自己被授權的資源。

許可權管理幾乎出現在任何系統裡面，只要有用戶和密碼的系統。很多人常將「用戶身份認證」、「密碼加密」、「系統管理」等概念與許可權管理概念混淆。

功能許可權管理技術，一般就使用基於角色訪問控制技術RBAC（Role Based Access Control）。該技術被廣泛運用於各個系統。

許可權控制表 (ACL: Access Control List)

用來描述許可權規則或用戶和許可權之間關係的數據表。

許可權標識

許可權的代號，例如用「ARTICLE_ADD」來指代「添加文章的操作」許可權。如linux文件淺析 rwx代表讀寫執行許可權。

角色

角色是一定數量的許可的集合，許可的載體，一個角色可以包含多個用戶，一個用戶同樣的也可以屬於多個角色，所以角色與用戶的關係為多對多的關係。同樣的一個角色可以包含多個用戶組，一個用戶組也可以屬於多個角色，所以角色和用戶組也是多對多的關係；

一個用戶一個角色：用戶/角色/許可權關係總結

個用戶有一個角色
一個角色有多個操作（菜單）許可權
一個操作許可權可以屬於多個角色

在實際的團體業務中，都可以將用戶分類。比如對於薪水管理系統，通常按照級別分類：經理、高級工程師、中級工程師、初級工程師。也就是按照一定的角色分類，通常具有同一角色的用戶具有相同的許可權。這樣改變之後，就可以將針對用戶賦權轉換為針對角色賦權。

我們可以用下圖中的資料庫設計模型，描述這樣的關係。

一個用戶一個或多個角色：用戶/角色/許可權關係總結

但是在實際的應用系統中，一個用戶一個角色遠遠滿足不了需求。如果我們希望一個用戶既擔任銷售角色、又暫時擔任副總角色。該怎麼做呢？為了增加系統設計的適用性，我們通常設計：

一個用戶有一個或多個角色
一個角色包含多個用戶
一個角色有多種許可權
一個許可權屬於多個角色

我們可以用下圖中的資料庫設計模型，描述這樣的關係。

用戶組

當平台用戶基數增大，角色類型增多時，如果直接給用戶配角色，管理員的工作量就會很大。如果有一類的用戶都要屬於某個角色，我們一個個給用戶授予角色，重複工作特別多，所以我們把這麼一些用戶進行分類，這時候我們可以引入一個概念「用戶組」，就是將相同屬性的用戶歸類到一起。也就是用戶組，這樣的話，我們直接對用戶組賦予角色，減少重複的工作量。

例如：加入用戶組的概念後，可以將部門看做一個用戶組，再給這個部門直接賦予角色（1萬員工部門可能就幾十個），使部門擁有部門許可權，這樣這個部門的所有用戶都有了部門許可權，而不需要為每一個用戶再單獨指定角色，極大的減少了分配許可權的工作量。

同時，也可以為特定的用戶指定角色，這樣用戶除了擁有所屬用戶組的所有許可權外，還擁有自身特定的許可權。

用戶組的優點，除了減少工作量，還有更便於理解、增加多級管理關係等。如：我們在進行組織機構配置的時候，除了加入部門，還可以加入科室、崗位等層級，來為用戶組內部成員的許可權進行等級111111上的區分。

關於用戶組的詳細疑難解答，請查看//wen.woshipm.com/question/detail/88fues.html。在這裡也十分感謝為我解答疑惑的朋友們！

常見設計模式

自主訪問控制（DAC: Discretionary Access Control）

系統會識別用戶，然後根據被操作對象（Subject）的許可權控制列表（ACL: Access Control List）或者許可權控制矩陣（ACL: Access Control Matrix）的資訊來決定用戶的是否能對其進行哪些操作，例如讀取或修改。

而擁有對象許可權的用戶，又可以將該對象的許可權分配給其他用戶，所以稱之為「自主（Discretionary）」控制。

這種設計最常見的應用就是文件系統的許可權設計，如微軟的NTFS。

DAC最大缺陷就是對許可權控制比較分散，不便於管理，比如無法簡單地將一組文件設置統一的許可權開放給指定的一群用戶。

強制訪問控制（MAC: Mandatory Access Control）

MAC是為了彌補DAC許可權控制過於分散的問題而誕生的。

在MAC的設計中，每一個對象都都有一些許可權標識，每個用戶同樣也會有一些許可權標識，而用戶能否對該對象進行操作取決於雙方的許可權標識的關係，這個限制判斷通常是由系統硬性限制的。比如在影視作品中我們經常能看到特工在查詢機密文件時，螢幕提示需要「無法訪問，需要一級安全許可」，這個例子中，文件上就有「一級安全許可」的許可權標識，而用戶並不具有。

MAC非常適合機密機構或者其他等級觀念強烈的行業，但對於類似商業服務系統，則因為不夠靈活而不能適用。

因為DAC和MAC的諸多限制，於是誕生了RBAC，並且成為了迄今為止最為普及的許可權設計模型。

RBAC是什麼？

RBAC，Role-based access control，基於角色的訪問控制，通過角色關聯用戶，角色關聯許可權的方式間接賦予用戶許可權。

是資訊安全領域中，一種較新且廣為使用的訪問控制機制，其不同於強制訪問控制以及自由選定訪問控制直接賦予使用者許可權，而是將許可權賦予角色。

1996年，萊威·桑度（Ravi Sandhu）等人在前人的理論基礎上，提出以角色為基礎的訪問控制模型，故該模型又被稱為RBAC96。之後，美國國家標準局重新定義了以角色為基礎的訪問控制模型，並將之納為一種標準，稱之為NIST RBAC。

RBAC認為許可權授權實際上是Who、What、How的問題。在RBAC模型中，who、what、how構成了訪問許可權三元組，也就是「Who對What(Which)進行How的操作，也就是「主體」對「客體」的操作，其中who——是許可權的擁有者或主體（如：User、Role），what——是資源或對象（Resource、Class)

為什麼選擇RBAC進行許可權控制

通常一個系統會存在不同許可權的用戶，而根據業務要求的不同，每個用戶能使用的功能、查看的內容是不同的。舉個最簡單的例子：釘釘後台，普通員工和行政能看到的菜單、使用的功能是不同的，行政可以查看所有員工的出勤記錄而普通員工則不行。

其實是可以直接給用戶分配許可權，只是直接給用戶分配許可權，少了一層關係，擴展性弱了許多，適合那些用戶數量、角色類型少的平台。

對於通常的系統，比如：存在多個用戶擁有相同的許可權，在分配的時候就要分別為這幾個用戶指定相同的許可權，修改時也要為這幾個用戶的許可權進行一一修改。有了角色後，我們只需要為該角色制定好許可權後，將相同許可權的用戶都指定為同一個角色即可，便於許可權管理。

對於批量的用戶許可權調整，只需調整用戶關聯的角色許可權，無需對每一個用戶都進行許可權調整，既大幅提升許可權調整的效率，又降低了漏調許可權的概率。

RBAC定義

在一個組織中，會因為不同的作業功能產生不同的角色，執行某項操作的許可權會被賦予特定的角色。組織成員或者工作人員（抑或其它系統用戶）則被賦予不同的角色，這些用戶通過被賦予角色來取得執行某項電腦系統功能的許可權。

S = 主體 = 一名使用者或自動代理人
R = 角色 = 被定義為一個授權等級的工作職位或職稱
P = 許可權 = 一種存取資源的方式
SE = 會期 = S，R或P之間的映射關係
SA = 主體指派
PA = 許可權指派
RH = 角色階層。能被表示為：≥（x ≥ y 代表 x 繼承 y 的許可權）
一個主體可對應多個角色。
一個角色可對應多個主體。
一個角色可擁有多個許可權。
一種許可權可被分配給許多個角色。
一個角色可以有專屬於自己的許可權。

所以，用集合論的符號：

PA⊆P×R 是一個多對多的許可權分配方式。
SA⊆S×R 是一個多對多的主體指派方式。
RH⊆R×R

參考文章：

RBAC模型：基於用戶-角色-許可權控制的一些思考 www.woshipm.com/pd/1150093.html/comment-page-1

RBAC許可權模型——項目實戰 //blog.csdn.net/zwk626542417/article/details/46726491

許可權系統設計模型分析（DAC，MAC，RBAC，ABAC） //www.jianshu.com/p/ce0944b4a903

圖文詳解基於角色的許可權控制模型RBAC //www.bbsmax.com/A/kvJ3Yl8Ddg/

轉載本站文章《許可權系統設計(0):許可權系統設計基本概念改需-MAC/RBAC引子》,
請註明出處：//www.zhoulujun.cn/html/Operation/PM/2020_0505_8401.html

Tags: Mac MAC、 RBAC 許可權系統控制許可權設計