權限的本質(zhì)是人與人之間的信任建立和打散，權限管控的是人與權限的關系，本文以應用層數(shù)據(jù)安全管控實踐為例，探討權限模型的迭代歷程和應用實踐，希望對你有所啟發(fā)。

一、權限模型迭代概覽

權限的本質(zhì)其實是人與人之間信任關系的建立和打散，權限管控的核心是聲明人和權限的關系?？v觀行業(yè)發(fā)展，權限管控模型先后經(jīng)歷了以ACL模型為代表的1.0時代和以RBAC模型為代表的2.0時代，現(xiàn)在正式邁入以TRFAC模型為代表的3.0代。

圖表1：基礎權限模型示意圖

【基礎權限模型介紹】注釋：

[1] ACL模型：即Access Control List，訪問控制列表，用戶與權限直接關聯(lián)，直接維護列表中用戶與資源的關系從而達到權限管控的目的。

[2] RBAC模型：即Role-Based Access Control，基于角色的訪問控制，RBAC模型則是角色與權限進行關聯(lián)，用戶成為相應的角色而獲得對應的權限。

[3] TRFAC模型：即target-resource-factor-act Control，基于“對象-資源-條件-行為”的權限控制，TRFAC模型描述了“XX對象（人/應用/組織/角色等）對 XX資源（頁面/菜單/按鈕/數(shù)據(jù)等）在 XX條件/因素（城市=北京等）下?lián)碛?XX行為類型（增刪改查等）的權限”。

二、權限模型在產(chǎn)品設計中的應用

圖表2：基于權限模型設計的XX權限產(chǎn)品DEMO

三、TRFAC模型實踐

數(shù)據(jù)產(chǎn)品天然存在人和資源之間的復雜關系，傳統(tǒng)權限模型，無論是ACL模型還是RBAC模型，都不能很好地聲明人和權限的關系。以下就以兩個典型案例的解決方案，來闡述TRFAC模型的應用實踐。

[ 案例1 ]

某業(yè)務團隊需要實現(xiàn)報表權限控制（維度權限）需求。業(yè)務邏輯并不復雜，但是人和資源的權限關系比較細，傳統(tǒng)ACL模型和RBAC模型均不能滿足，因此，我們采用TRFAC模型來實現(xiàn)。

首先，鑒權主體是人，資源為報表；然后，行級別權限控制，可以理解為在正常資源關系中，新增了“維度值”附屬條件，比如，當報表資源滿足“城市=北京”的條件時，用戶XX擁有對該報表的權限。所以我們實現(xiàn)路徑如下：

圖表3：行級別權限實現(xiàn)邏輯圖

圖表4：行級別權限鑒權流程示意圖

思考：為什么不把報表中每一行數(shù)據(jù)都當作是資源注冊到權限中心，這樣行級別權限其實只是一次更細粒度的資源鑒權，為什么要把維度值當作是條件呢？

[ 案例2 ]

某某智能數(shù)倉平臺（其實就是指標/維度生產(chǎn)維護服務平臺），需要權限中心幫助實現(xiàn)功能和數(shù)據(jù)權限控制。系統(tǒng)簡易架構圖如下：

圖表5：XX智能數(shù)倉平臺系統(tǒng)架構圖

該智能數(shù)倉平臺兼具功能和數(shù)據(jù)權限管控需求，其中功能權限包括業(yè)務線/業(yè)務域/業(yè)務過程的管理和維護，修飾詞的管理和維護，指標/維度的錄入和管理維護；數(shù)據(jù)權限包括“指標+維度”的數(shù)據(jù)探查權限，底層庫表的數(shù)據(jù)讀取權限，具體組織形式如下圖所示：

圖表6：XX智能數(shù)倉平臺功能權限管理體系設計

圖表7：XX智能數(shù)倉平臺角色管控體系

在業(yè)務邏輯上比較復雜，既有功能權限，又有數(shù)據(jù)權限，同時資源之間還有歸屬和繼承關系，同時還有較為豐富的角色體系，這時候單純用ACL或者RBAC模型都無法全部滿足需求，因此我們采用TRFAC模型來實現(xiàn)：

圖表8：角色-權限實現(xiàn)邏輯圖

案例2小結

• 業(yè)務線、業(yè)務域、業(yè)務過程在TRFAC模型看來都是“資源”：平臺超管角色對業(yè)務線擁有管理維護權限，業(yè)務線管理員對業(yè)務域擁有管理維護權限，業(yè)務域管理員對業(yè)務過程擁有管理維護權限
• 指標/維度的探查權限屬于數(shù)據(jù)權限，既能以角色-權限的方式來管控，也能以人-資源-權限的方式管控
• 資源需要依附對象，也就是觸發(fā)鑒權動作的對象
• 以系統(tǒng)為依附對象，即進入系統(tǒng)時對所有資源都觸發(fā)一遍鑒權詢問。優(yōu)點是業(yè)務邏輯簡單，不用設計復雜的權限關系；缺點是鑒權響應速度和性能較差
• 以菜單/模塊/頁面為依附對象，即進入相應模塊或者頁面時觸發(fā)鑒權詢問。優(yōu)點是無論是權限關系復雜度還是鑒權速度和性能都比較均衡；缺點是復雜或者細粒度業(yè)務需求滿足不了
• 以具體的觸發(fā)按鈕為依附對象，即點擊XX按鈕時觸發(fā)鑒權詢問。優(yōu)點是自由度和靈活性高，復雜業(yè)務需求容易滿足，且性能優(yōu)異；缺點是管理維護成本高，不通用，迭代更新成本高