浅谈权限管理的设计与实现
一、權(quán)限管理的意義
保證安全：避免誤操作、人為破壞、數(shù)據(jù)泄露等。
數(shù)據(jù)隔離：不同的權(quán)限能看到及操作不同的數(shù)據(jù)，互不干擾。
職責(zé)明確：不同角色處理不同事務(wù)，細(xì)化職責(zé)，規(guī)范并簡化流程。
二、權(quán)限管理系統(tǒng)的通用設(shè)計思路
某個主體（subject也就是用戶） 對某個 客體（object也就是資源） 需要實施某種操作（operation），系統(tǒng)對這種操作的管理控制就是權(quán)限控制。
1. 權(quán)限分類
- 操作權(quán)限
API 權(quán)限
菜單權(quán)限
按鈕權(quán)限 - 數(shù)據(jù)權(quán)限
所謂操作權(quán)限就是用戶是否有執(zhí)行某項操作的權(quán)限，比方說是否可以審批你的考勤，具體表現(xiàn)形式就是用戶是否可以看到某個菜單或者按鈕，是否能夠調(diào)用某個api(eg.對一些涉及用戶信息的api做用戶的登陸校驗)。
所謂的數(shù)據(jù)權(quán)限就是用戶是否有對某些數(shù)據(jù)的訪問權(quán)限，比方說一個日志菜單，普通用戶只能看到自己的操作記錄，管理員就可以看到所有的用戶操作行為，具體表現(xiàn)形式就是當(dāng)用戶有操作權(quán)限的時候，但不代表其對所有的數(shù)據(jù)都有查看或者修改權(quán)限。
2.訪問控制權(quán)限模型
訪問控制權(quán)限模型有：ACL 、DAC、MAC、RBAC、ABAC
2.1 ACL 訪問控制列表
規(guī)定資源可以被哪些主體進(jìn)行哪些操作
ACL， 訪問控制列表，通過訪問控制列表來維護(hù)用戶和資源之間的映射關(guān)系。在ACL中，包含用戶(User)、資源(Resource)、操作(Operation)三個元素。針對每一項資源，都配置有一個列表，記錄哪些用戶可以對這項資源執(zhí)行哪些操作。當(dāng)系統(tǒng)試圖訪問這項資源時，會檢查這個列表中是否有關(guān)于當(dāng)前用戶的操作權(quán)限。如果有，則可以執(zhí)行操作，否則會被拒絕。
ACL訪問控制列表被廣泛地應(yīng)用于路由器和三層交換機(jī)，它可以根據(jù)設(shè)定的條件對接口上的數(shù)據(jù)包進(jìn)行過濾，允許其通過或丟棄。借助于訪問控制列表，可以有效地控制用戶對網(wǎng)絡(luò)的訪問，從而最大程度地保障網(wǎng)絡(luò)安全。
應(yīng)用場景: 路由器、防火墻、文件系統(tǒng)
2.2 DAC 自主訪問控制
DAC規(guī)定資源可以被哪些主體進(jìn)行哪些操作， 同時，主體可以將資源、操作的權(quán)限，授予其他主體。
DAC是ACL的一種實現(xiàn)，強(qiáng)調(diào)靈活性。純粹的ACL，權(quán)限由中心管理員統(tǒng)一分配，缺乏靈活性。為了加強(qiáng)靈活性，在ACL的基礎(chǔ)上，DAC模型將授權(quán)的權(quán)力下放，允許擁有權(quán)限的用戶，可以自主地將權(quán)限授予其他用戶。
傳統(tǒng)的Linux訪問控制方式就是DAC 自主訪問控制。
DAC思想：進(jìn)程與其執(zhí)行用戶，擁有相同的權(quán)限。
例如：進(jìn)程A，以root用戶執(zhí)行，進(jìn)程A就擁有了root用戶的權(quán)限。
又比如Windows的文件權(quán)限
自主訪問控制是一種比較寬松的訪問控制,一個主體的訪問權(quán)限具有傳遞性。其強(qiáng)調(diào)的是自主，自己來決定訪問策略，但是其安全風(fēng)險也來自自主。
2.3.MAC 強(qiáng)制訪問控制
強(qiáng)制訪問控制模型(MAC, Mandatory Access Control),是為了彌補(bǔ)DAC權(quán)限控制過于分散的問題而誕生的。
a. 規(guī)定資源可以被哪些類別的主體進(jìn)行哪些操作
b. 規(guī)定主體可以對哪些級別的資源進(jìn)行哪些操作
當(dāng)一個用戶執(zhí)行一個操作時，需要同時滿足a與b，才會被允許操作。
在MAC訪問控制中，主體和資源都被賦予一定的安全級別，用戶不能改變自身和資源的安全級別，只有管理員才能夠確定用戶的訪問權(quán)限。和DAC模型不同的是，MAC是一種多級訪問控制策略，它的主要特點是系統(tǒng)對用戶和被訪問資源實行強(qiáng)制訪問控制，系統(tǒng)事先給用戶和資源對象分配不同的安全級別屬性，在實施訪問控制時，系統(tǒng)先對用戶和資源對象的安全級別屬性進(jìn)行比較，再決定用戶能否訪問該資源。
MAC的強(qiáng)制訪問策略為每個用戶、進(jìn)程及文件賦于一個安全訪問級別，即：
- 最高秘密級（Top Secret，一般標(biāo)記為T）
- 秘密級（Secret，一般標(biāo)記為S）
- 機(jī)密級（Confidential，一般標(biāo)記為C）
- 無級別級（Unclassified，一般標(biāo)記為U）
MAC非常適合機(jī)密機(jī)構(gòu)或者其他等級觀念強(qiáng)烈的行業(yè)。但對于類似商業(yè)服務(wù)系統(tǒng)，因為其過重強(qiáng)調(diào)保密性，管理不夠靈活而不太適用。
2.4 RBAC 基于角色的訪問控制
下述圖片來自1.3 - What ANSI RBAC is
目前最為常見的權(quán)限設(shè)計模型大多都是RBAC模型， 基于角色的訪問控制（Role-Based Access Control)。RBAC模型的基本思路是將訪問許可權(quán)分配給一定的角色，用戶通過飾演不同的角色獲得角色所擁有的相應(yīng)權(quán)限。
2.4.1.RBAC0
RBAC0是基于角色的訪問控制的基礎(chǔ)模型，它只包含核心的三要素，用戶，角色，權(quán)限。其他的版本都是在 RBAC0 的基礎(chǔ)上進(jìn)行相應(yīng)的擴(kuò)展。
每個角色會關(guān)聯(lián)一系列資源權(quán)限(多對多)，而每個用戶會關(guān)聯(lián)一些系列角色(多對多)，這樣就可以很方便的控制用戶能夠訪問的資源了
2.4.2.RBAC1
Hierarchical Role，角色繼承。
引入父子角色的概念，所謂的角色繼承就是子角色可繼承父角色的權(quán)限，也就是RBAC1的模型。
2.4.3.RBAC2
Static Separation of Duties 也就是靜態(tài)職責(zé)分離，用于將用戶的權(quán)限限制在正常范圍內(nèi)，會在角色分配時應(yīng)用SSD約束。
因為角色與角色，權(quán)限與權(quán)限之間可能會發(fā)生沖突，比如出納和會計， 運(yùn)動員和裁判。 一個員工是不能既是出納，又是會計， 運(yùn)行員不能既是運(yùn)行員，又是裁判。
靜態(tài)職責(zé)分離是指用戶無法同時被賦予有沖突的角色，避免用戶超出其當(dāng)前職位合理的權(quán)限等級。簡單地說， 就是避免兩個角色間的沖突。如果員工已經(jīng)有了出納的角色，那么在給該員工賦予會計角色時，會提示角色有沖突，無法進(jìn)行該操作。 也就是說在賦予角色時，會進(jìn)行校驗。 無論角色之間是否存在繼承關(guān)系，都需要進(jìn)行校驗。
2.4.4.RBAC3
Dynamic Separation of Duties 也就是動態(tài)職責(zé)分離，強(qiáng)制約束是在任何時間點都可以一起使用的函數(shù)。DSD約束可用于在多步驟審批過程中實施嚴(yán)格控制。一般在角色激活時應(yīng)用DSD約束。
動態(tài)職責(zé)分離，指相互沖突的角色可以同時給一個用戶，但是用戶在一次會話(Session)中，不能同時激活自身所擁有的互相沖突的角色，只能選擇其一。
當(dāng)用戶登錄時，或者登錄成功后，會讓用戶選擇角色，如用戶選擇了出納的角色。 在運(yùn)行會話期間，該用戶是無法選擇會計的角色進(jìn)行操作的，只能先退出，再重新登錄。
2.5 ABAC 基于屬性的訪問控制
不同于常見的將用戶通過某種方式關(guān)聯(lián)到權(quán)限的方式，ABAC則是通過動態(tài)計算一個或一組屬性是否滿足某種條件來進(jìn)行授權(quán)判斷。
屬性通常來說分為四類：
- 用戶屬性（比如用戶名稱）
- 環(huán)境屬性（比如當(dāng)前時間）
- 操作屬性（比如讀取還是寫入）
- 對象屬性（又稱資源屬性，比如一篇文章）
ABAC的控制粒度比RBAC更細(xì)，理論上能夠?qū)崿F(xiàn)非常靈活的權(quán)限控制，幾乎能滿足所有類型的需求。
用戶攜帶自身的屬性值包括主體屬性，資源屬性，環(huán)境屬性，然后向資源發(fā)送請求，授權(quán)引擎 會根據(jù)subject 所攜帶的屬性進(jìn)行判斷，然后會給出拒絕或者同意的結(jié)果給用戶，之后用戶就可以訪問資源或者拒絕訪問了。
例如規(guī)則：“允許所有班主任在上課時間自由進(jìn)出校門”這條規(guī)則，其中，“班主任”是用戶的角色屬性，“上課時間”是環(huán)境屬性，“進(jìn)出”是操作屬性，而“校門”就是對象屬性了。為了實現(xiàn)便捷的規(guī)則設(shè)置和規(guī)則判斷執(zhí)行，ABAC通常有配置文件（XML、YAML等）或DSL配合規(guī)則解析引擎使用
3. 數(shù)據(jù)權(quán)限的實現(xiàn)思路
數(shù)據(jù)權(quán)限是控制用戶可以看到的數(shù)據(jù)，符合某條件的用戶只能看到該條件下對應(yīng)的數(shù)據(jù)資源。
訪問控制權(quán)限是控制用戶能不能訪問某資源
數(shù)據(jù)權(quán)限是在用戶擁有了訪問控制權(quán)限后，對用戶所訪問的數(shù)據(jù)按照一定規(guī)則，進(jìn)一步過濾出用戶能看到的數(shù)據(jù)
常見于需要對某部門下的用戶做數(shù)據(jù)可見性控制，如用戶只能查看其本部門的數(shù)據(jù)。
數(shù)據(jù)權(quán)限主要有兩個方面的作用：
(1)為了解決數(shù)據(jù)安全性問題
用戶在企業(yè)的級別越高，才能看到更多的數(shù)據(jù)內(nèi)容，防止大量機(jī)密數(shù)據(jù)被普通員工查看或者外泄出去。
(2)避免惡性競爭
常見于企業(yè)銷售部門，銷售經(jīng)理辛苦積累的客戶資源，不會輕易共享給其他銷售經(jīng)理。
常見的解決方案有：
- 最簡單 : 直接在SQL代碼中加入相應(yīng)的Where條件來過濾數(shù)據(jù)，適用于項目不大的場景
- 攔截業(yè)務(wù)執(zhí)行的sql，然后自動拼接數(shù)據(jù)過濾條件，但是只適合于單體應(yīng)用，在分布式場景下，很難去過濾跨服務(wù)調(diào)用的數(shù)據(jù)
- 在Controller層，通過AOP的方式，按照給定的數(shù)據(jù)規(guī)則過濾出用戶的可見數(shù)據(jù)，也就是說先查詢出所有的數(shù)據(jù)，然后再按照一定規(guī)則來過濾可見數(shù)據(jù)
這兩篇文章 通用權(quán)限管理設(shè)計 之 數(shù)據(jù)權(quán)限 和 數(shù)據(jù)權(quán)限設(shè)計——基于EntityFramework的數(shù)據(jù)權(quán)限設(shè)計方案：一種設(shè)計思路 也提供了一種較為通用的數(shù)據(jù)權(quán)限設(shè)計思路，感興趣的也可以去看看，大致思路就是通過配置角色的數(shù)據(jù)過濾規(guī)則來更靈活地控制用戶的數(shù)據(jù)權(quán)限。
三、訪問控制權(quán)限的常見解決方案
工作中我們使用的權(quán)限模型主要都是基于 RBAC, 或者在RBAC基礎(chǔ)上進(jìn)行一個擴(kuò)展，常見的做法是在用戶或資源側(cè)添加額外的限制條件
1.標(biāo)準(zhǔn)場景(API、菜單、按鈕)
這是最基礎(chǔ)的場景,也就是RBAC0模型。
一般設(shè)計成5張表：用戶表, 角色表, 權(quán)限(資源)表, 用戶-角色表, 角色-權(quán)限表
API的權(quán)限: 對用戶所有的請求都需要先經(jīng)過API權(quán)限的驗證(可以通過切面或者過濾器實現(xiàn))
1）先獲取用戶的角色集合A,然后根據(jù)請求的API獲取擁有該API權(quán)限的集合B,如果有交集則說明有權(quán)限
2）獲取用戶的角色集合，之后獲取其所有有權(quán)限的API集合A，判斷請求的API是否在集合A中
Menu權(quán)限: 先根據(jù)用戶查詢出其角色集合，再獲得其對應(yīng)的菜單列表，組成菜單樹，然后返回給前端渲染
按鈕權(quán)限: 根據(jù)用戶的角色可以獲取其所有有權(quán)限的按鈕集合B, 在渲染頁面時根據(jù)按鈕是否在集合B中決定按鈕是顯示還是隱藏
2.引入組
為了更好地管理用戶，對用戶進(jìn)行分組歸類，可以引入組的概念。
在實際情況中，我們知道，組也可以具有自己的角色信息、權(quán)限信息。比方說QQ用戶群，一個群可以有多個用戶，一個用戶也可以加入多個群。每個群具有自己的權(quán)限信息。例如查看群共享。QQ群也可以具有自己的角色信息，例如普通群、高級群等。
引入組的概念之后，用戶擁有的角色，即為用戶自身所擁有的角色集合與用戶所屬組擁有的角色集合的并集 ，這樣想要給某一用戶組的所有用戶都加上某角色的權(quán)限，只需要給組賦予相應(yīng)角色就可以了
3. 角色繼承
為了提高授權(quán)的便捷性，我們還可以提供角色復(fù)制、角色繼承的功能，即角色可以被拷貝、繼承，也就是前面提到的RBAC1的模型。
拷貝的角色可以擁有與被拷貝角色相同的權(quán)限；而對于角色繼承，子角色可繼承父角色的權(quán)限(跟java中的繼承類似)。
4. 引入功能模塊
前面的資源分為API, 菜單， 按鈕三類；但是很多資源之前都是有關(guān)聯(lián)性的，可以將關(guān)聯(lián)的資源聚合成功能模塊，更方便我們對資源進(jìn)行分配
我們可以將菜單也視為一種功能模塊，也可以將菜單單獨(dú)授權(quán)
5. 多應(yīng)用授權(quán)中心
如果有多個服務(wù)都需要設(shè)計權(quán)限系統(tǒng)，那么可以權(quán)限服務(wù)獨(dú)立出來，讓其為多個應(yīng)用提供權(quán)限管理。
每個需要進(jìn)行管理的服務(wù)都可視為一個應(yīng)用(Application), 每個應(yīng)用下可以有各自的用戶、角色、資源，同時一個用戶也可屬于多個應(yīng)用。
權(quán)限服務(wù)不單單可以維護(hù)其他應(yīng)用的權(quán)限，還可以維護(hù)權(quán)限服務(wù)自身的權(quán)限。
參考資料:
1.3 - What ANSI RBAC is
權(quán)限系統(tǒng)設(shè)計模型分析（DAC，MAC，RBAC，ABAC）
總結(jié)
以上是生活随笔為你收集整理的浅谈权限管理的设计与实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MarkdownPad安装以及绘制 UM
- 下一篇： 记一次OpenJDK替换java JDK