作者 ｜ ?楊子國
名詞解釋
ITAM：ITAM 是對 IT 辦公資產(chǎn)--實物資產(chǎn) (如筆記本電腦)、軟件資產(chǎn) (如 Office365)--進行生命周期管理的系統(tǒng)。
ITAM-Auth：ITAM 系統(tǒng)的鑒權(quán)服務(wù)。
ITAM-Data：ITAM 系統(tǒng)的數(shù)據(jù)服務(wù)。
SaaS：軟件即服務(wù)（英語：Software as a Service，縮寫：SaaS），一種軟件交付模式。在這種交付模式中，軟件僅需通過網(wǎng)絡(luò)，不須經(jīng)過傳統(tǒng)的安裝步驟即可使用，軟件及其相關(guān)的數(shù)據(jù)集中托管于云端服務(wù)。
ServiceNow：ServiceNow 是一家美國軟件公司，總部位于加州圣克拉拉，該公司開發(fā)了一個云計算平臺，幫助企業(yè)管理企業(yè) IT 工作流。ServiceNow 由弗雷德·盧迪于 2003 年創(chuàng)立，在紐約證券交易所上市，是羅素 1000 指數(shù)和標準普爾 500 指數(shù)的組成股。2018 年，《福布斯》雜志將其評為全球最具創(chuàng)新性公司的第一名。
背景
本方案梳理了業(yè)界主流權(quán)限模型，IT Saas 化中權(quán)限管理要解決的問題，參考了公司內(nèi)外、國內(nèi)外的一些權(quán)限設(shè)計方案，結(jié)合 RBAC、ABAC 模型提出了 ITAM 融合模型權(quán)限管理方案。
主流權(quán)限模型
參考了多個系統(tǒng)的權(quán)限實現(xiàn)后，總結(jié)出公用的權(quán)限理論模型，具體到每個系統(tǒng)的實現(xiàn)會有一些改造和優(yōu)化，本部分介紹工業(yè)界廣泛使用的權(quán)限模型。
概述
主體：一個訪問行為的發(fā)起方，此處簡化理解，假設(shè)都是用戶
客體：訪問行為的施加對象，如頁面、功能、數(shù)據(jù)
ACL (Access-Control List 訪問控制列表)
Subject：主體，訪問方，可以是人也可以是系統(tǒng)、設(shè)備等
Action：訪問的具體動作，如 Create、Read、Edit...
Object：客體，被訪問方，可以是系統(tǒng)中的某個條目、某個文件等
一種比較基礎(chǔ)的權(quán)限管控機制，簡單直接，常應(yīng)用于操作系統(tǒng)中的文件系統(tǒng)。
MAC (Mandatory Access Control 強制訪問控制)
Subject：主體，訪問方，可以是人也可以是系統(tǒng)、設(shè)備等
Action：訪問的具體動作，如 Create、Read、Edit...
Object：客體，被訪問方，可以是系統(tǒng)中的某個條目、某個文件等
Attributes：在 Subject 和 Object 上均可能有多個 Attributes ，用于鑒權(quán)判斷的元數(shù)據(jù)
主體和客體會被分別賦予一個機密等級，訪問時雙向檢查主體和客體的等級是否匹配，常被應(yīng)用于安全要求性高的領(lǐng)域，如軍事、金融、政府、計算機系統(tǒng)安全等，雙向鑒權(quán)時遵循 authorization rule，該 rule 的存儲位置和管理通常非常嚴格。
DAC (Discretionary Access Control 自主訪問控制)
Subject：主體，訪問方，可以是人也可以是系統(tǒng)、設(shè)備等
Action：訪問的具體動作，如 Create、Read、Edit...
Object：客體，被訪問方，可以是系統(tǒng)中的某個條目、某個文件等
Grant：轉(zhuǎn)授權(quán)行為，Subject 1 可對 Object 執(zhí)行的全部或部分 Action 轉(zhuǎn)授給 Subject 2
自主訪問控制簡單理解是權(quán)限 Subject 可將自己擁有的權(quán)限轉(zhuǎn)移給其他主體，通常是為了解決權(quán)限分配靈活度的問題，但是在 B 端系統(tǒng)里往往不會僅僅采用 DAC 這一種權(quán)限模型（比如會結(jié)合 MAC 模型），因為該模型會導(dǎo)致管理員無法掌控的權(quán)限擴散。
RBAC (Role Based Access Control 角色訪問控制)
RBAC 認為權(quán)限的本質(zhì)是 Who 對 What 進行了 How 操作
User：主體，訪問方，代表系統(tǒng)中的用戶，但也可以是機器、網(wǎng)絡(luò)等 - Who
Object：客體，被訪問方，可以是系統(tǒng)中的某個菜單、按鈕、數(shù)據(jù)記錄、API 等 - What
Operation：系統(tǒng)中用戶可執(zhí)行的某個動作 - How
Permissions：權(quán)限，代表可向 RBAC 保護下的 Object 執(zhí)行 Operation （What + How）
Role：角色，代表組織內(nèi)一些職責(zé)及該職責(zé)下的用戶擁有某些指定的權(quán)限
Session：會話，會話由一個用戶觸發(fā)，同時會話激活會話關(guān)聯(lián)的一個或多個 Role
本文重點介紹被 INCITS（國際信息技術(shù)標準委員會） 采納的標準 RBAC 模型
標準 RBAC 分為 4 個子模型：
RBAC0 - Core RBAC
RBAC1 - Hierarchical RBAC
一般繼承：角色之間的是一個絕對偏序的繼承關(guān)系（有向無環(huán)，成環(huán)的角色繼承無意義），這個設(shè)計比單一的樹狀繼承更自由，適用于角色權(quán)限有繼承需求但又不是嚴格的上下層級關(guān)系的權(quán)限場景。
RBAC2 - Constrained RBAC
RBAC3 = RBAC 1 + RBAC 2
RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色繼承也包含了相關(guān)約束。
優(yōu)點：能力最強大。
缺點：4 種模型中最復(fù)雜的模型，管理成本較高。
總體上，RBAC 被認為滿足了三個重要權(quán)限原則：
- 最小權(quán)限：用戶僅在觸發(fā)會話動作時獲取到其所在角色，該角色定義了完成該動作所需的最小權(quán)限。
- 權(quán)限抽象：可結(jié)合業(yè)務(wù)抽象出具體的權(quán)限行為，如發(fā)表評論、上傳附件，而不是簡單的 讀、寫、查。
- 職責(zé)分離：角色本身表征了職責(zé)，加上 RBAC 支持角色和角色間的互斥機制，實現(xiàn)高風(fēng)險動作分治。
對標準 RBAC 的擴展
- 面向單個用戶授權(quán)時的管理成本：可以跳過 Role 直接對用戶授權(quán)
- 面向大批量用戶授權(quán)時的管理成本：Group 也可以被分配到 Role 中
- 面向維護 Role 的管理成本：用戶在 Role 中可進行權(quán)限裁剪（代表這個用戶僅擁有這個 Role 的部分權(quán)限）、可復(fù)制 Role 等等
- 和其他權(quán)限模型的結(jié)合：
- 和 DAC 、MAC 的結(jié)合
- 和 ABAC 的結(jié)合
ABAC (Attribute Based Access Control 屬性訪問控制)
Subject：主體，訪問方，代表系統(tǒng)中的用戶，但也可以是機器、網(wǎng)絡(luò)等
Object：客體，被訪問方，可以是系統(tǒng)中的某個文件、設(shè)備、數(shù)據(jù)庫記錄等
Operation：系統(tǒng)中主體對客體請求執(zhí)行的功能/行為，可包括 read、write、edit、delete 等
Attributes：屬性，Subject、Object、Operation 和 Environment Condition 都有屬性，屬性是一對鍵值
Policy：一系列由屬性和屬性值構(gòu)成的規(guī)則或關(guān)系，通過該規(guī)則/關(guān)系可判斷一個訪問能否被允許
Environment Conditions：可被識別的環(huán)境條件，訪問行為發(fā)生的環(huán)境，通常可以是時間、地點、IP、設(shè)備、操作系統(tǒng)、風(fēng)險級別等
ABAC 是建立在 Subject 屬性、Object 屬性、環(huán)境屬性及訪問 Policy 之上的細粒度權(quán)限管控，ABAC 能做到只有符合特定屬性的 Subject 在特定條件下可以對符合特定屬性的 Object 執(zhí)行某權(quán)限行為。
下一代權(quán)限模型探索 - NGAC
在 DAC、MAC、RBAC、ABAC 這些主流權(quán)限模型之外，還存在大量其他權(quán)限模型（如 LBAC、GBAC、CBAC、OrBAC、RAdAC...），但目前還沒有一種權(quán)限模型得到了工業(yè)界的廣泛采納。
學(xué)術(shù)界已經(jīng)有了一些關(guān)于下一代權(quán)限模型的研究成果。
NIST（美國國家標準技術(shù)研究所）在 2019 年提出了 NGAC(Next Generation Access Control 下一代訪問控制模型)，提出這是區(qū)別于現(xiàn)有權(quán)限模型之外的一種全新模型且可以廣泛兼容當前數(shù)字生態(tài)里的各種權(quán)限場景。
從下圖來看更像是 RBAC 思路和 ABAC 思路的結(jié)合，結(jié)合點是 用戶 —— 角色的關(guān)系不再人為分配，而是根據(jù) Policy 自動分配，用戶以角色身份進行權(quán)限行為時再過一遍 ABAC 的規(guī)則判斷。
典型應(yīng)用場景：Alice 只有在工作日的上午 10:00-18:00 在倫敦的辦公室網(wǎng)絡(luò)下（role-based permission policy）才能以財務(wù)的角色訪問并修改訂單系統(tǒng)里的數(shù)據(jù) （role-based permission policy）
結(jié)論
沒有哪種權(quán)限模型是完美的，重要的是如何和業(yè)務(wù)結(jié)合，考慮安全性、擴展性、靈活性、易用性、管理成本、合規(guī)等因素并取得均衡，這個過程往往是最復(fù)雜的。
方案參考
帶著上述目標，主要看了 ServiceNow 的權(quán)限實現(xiàn)方案，從基本思路、可借鑒設(shè)計、方案缺點三方面做如下分析。
ServiceNow
基本思路
ServiceNow 權(quán)限管理采用 RBAC1+ACL 的方式，ACL 控制 ObjectType 的 Operation 訪問，通過 Role、Condition、Script 進行動態(tài)校驗。
權(quán)限模型
用戶和用戶組
用戶基本信息管理，所屬部門，一個用戶可以加入多個用戶組，一個用戶可通過設(shè)置代理來行使本用戶的系統(tǒng)權(quán)限；
用戶組包含多個用戶，用戶組之間可以繼承，子用戶組繼承父用戶組的權(quán)限。
角色
角色的使用是被動的，Module 在配置時可以關(guān)聯(lián)角色，UI Action 可以關(guān)聯(lián)角色，ACL 配置可以關(guān)聯(lián)角色，角色存在繼承關(guān)系，子角色繼承父角色的權(quán)限。
應(yīng)用和資源
ServiceNow 內(nèi)部區(qū)分不同的應(yīng)用，不同的應(yīng)用有不同的資源、角色、權(quán)限設(shè)置，應(yīng)用(Application)被抽象為一組可安裝的組件資源，資源包括了 Table(數(shù)據(jù)表)、Dictionary(數(shù)據(jù)列)、API 接口(REST_Endpoint)、Menu(菜單)、Module(頁面組件)、UI Page(獨立頁面)、UI Action(頁面按鈕)等，其中菜單、頁面組件、頁面按鈕使用 RBAC 權(quán)限模式；數(shù)據(jù)表、數(shù)據(jù)列、API 接口、獨立頁面使用 ACL 鑒權(quán)。
比較特殊的，Table 在 ACL 鑒權(quán)的同事，有配置 Application Access，即每個 table 按照應(yīng)用來設(shè)置操作權(quán)限。
ACL 鑒權(quán)的 Object 和 Operation 類型如下所示。
組件(Module)有多種訪問方式，以 ListRecord 和 URL 訪問為主，如下圖所示。ListRecord 表示訪問一個表的記錄，URL 訪問方式表示通過 URL-Get 參數(shù)方式訪問數(shù)據(jù)。Module 的鑒權(quán)通過配置關(guān)聯(lián)的 Role 來實現(xiàn)。
Module 的 LinkType(訪問方式)有 13 種，ListRecord 方式可以通過 Filter 指定默認的過濾查詢條件，但不是作為數(shù)據(jù)行范圍權(quán)限來使用的，進入具體頁面后，過濾條件可以清除。
RBAC 鑒權(quán)
需要鑒權(quán)的資源在配置時關(guān)聯(lián)需要的角色，角色的使用是被動的，Module 在配置時可以關(guān)聯(lián)角色，UI Action 可以關(guān)聯(lián)角色，ACL 配置可以關(guān)聯(lián)角色。
用戶或者用戶組在配置時選擇關(guān)聯(lián)的角色。
ACL 鑒權(quán)
ACL 鑒權(quán)指定 Object 的 Operation 需要鑒權(quán)，通過三種方式進行鑒權(quán)
- Role
- Condition
- Script
Table 的增刪改查、字段的增刪改查都可以通過 ACL 來配置
ServiceNow 對 Table、Column 的 ACL 控制大部分都是 ReadOnly
可借鑒設(shè)計
- 資源的管理粒度細，所以權(quán)限的管控粒度、靈活性好；
- 針對不同的鑒權(quán)場景使用不同的鑒權(quán)模型；
- UI 層資源和權(quán)限的數(shù)據(jù)鏈接、各信息的 Link 跳轉(zhuǎn)設(shè)計細致；
缺點
- 用戶和用戶組的關(guān)聯(lián)缺乏靈活性，例如按照用戶屬性圈定一批用戶作為一個組；
- 權(quán)限配置比較分散，使用權(quán)限的地方散落在各個資源管理入口；
- ACL 的 Condition 配置功能簡陋，配置門檻高；
- 沒有考慮開放與集成場景的鑒權(quán)；
- 沒有數(shù)據(jù)范圍鑒權(quán)。
問題
- 權(quán)限管理的本質(zhì)是對用戶訪問系統(tǒng)資源做權(quán)限控制，需要先定義好系統(tǒng)中的用戶、資源、權(quán)限；
- 用戶體量大、崗位流轉(zhuǎn)率高的情況下，要能高效、便捷的圈用戶、授權(quán)；
- 數(shù)據(jù)鑒權(quán)，包括數(shù)據(jù)行鑒權(quán)、列鑒權(quán)，數(shù)據(jù)權(quán)限高效授權(quán)、鑒權(quán)；
- 良好的業(yè)務(wù)擴展性；
- 權(quán)限管理和權(quán)限使用的前后端模塊劃分不一致，業(yè)務(wù)定義和工程定義不一致，例如前端是一個整體服務(wù)，后臺劃分了多個微服務(wù)，在權(quán)限管理、功能鑒權(quán)、數(shù)據(jù)鑒權(quán)時如何劃分和控制；
- 權(quán)限需要的特色功能：角色互斥，身份代理，權(quán)限前置依賴，權(quán)限審批流程，角色授權(quán)設(shè)置有效期，權(quán)限策略優(yōu)先級。
目標
技術(shù)目標
- 工作效率：用戶可以多快獲得應(yīng)當具備的權(quán)限；
- 鑒權(quán)效率：高性能保證鑒權(quán)不影響正常業(yè)務(wù)邏輯處理；
- 安全性：保證不會由于權(quán)限系統(tǒng)誤判導(dǎo)致功能、數(shù)據(jù)泄漏；
- 擴展性：在系統(tǒng)的多個節(jié)點提供擴展性，包括但不限于用戶類型擴展、用戶屬性擴展、資源類型擴展、資源屬性擴展。
功能目標
基本功能
權(quán)限基本功能開發(fā)，解決上述問題 1-5。
字段編輯權(quán)限
當前用戶對字段無編輯權(quán)限時，前端展示控件做禁用處理。
?身份代理
用戶請假或者工作崗位調(diào)動，會存在把系統(tǒng)權(quán)限臨時或永久轉(zhuǎn)移給交接的人。該功能在設(shè)計上支持，后續(xù)通過版本迭代實現(xiàn)，MVP 版本不實現(xiàn)。
設(shè)計方案
本方案設(shè)計上采用 RBAC+ABAC 融合方式實現(xiàn)權(quán)限管理，即 NGAC。兼容 RBAC、ABAC 的優(yōu)點，同時在實現(xiàn)方案上預(yù)留擴展點，整個方案在實施過程中可以通過“大設(shè)計、小實現(xiàn)”的方式迭代式開放，在保持整體架構(gòu)不變的情況下，可以先實現(xiàn) MVP 版本，然后逐步迭代實現(xiàn)設(shè)計方案中的功能。
專用術(shù)語
- User：用戶，可以是租戶內(nèi)的一個自然人用戶、可以是第三方系統(tǒng)、可以是應(yīng)用內(nèi)的子系統(tǒng)，各類用戶有基本屬性，屬性可按照租戶維度自定義；
- UserGroup：在管理平臺指定的一組用戶，用來給這些用戶賦予訪問權(quán)限；
- Role：角色，角色用于配置權(quán)限策略，一個角色關(guān)聯(lián)一個用戶類型，角色策略配置該角色擁有的功能權(quán)限、數(shù)據(jù)列權(quán)限、數(shù)據(jù)行范圍權(quán)限；
- Resource：權(quán)限資源項，例如 flow(流程)，Resource 有層級關(guān)系，對應(yīng)多個 Action，非葉子結(jié)點只有 Read，葉子結(jié)點有 1-N 個 Action；
- Action：動作，比如：管理、查看詳情、修改
- Condition：條件，可以承載 Subject、Object 附帶的屬性，也可以承載業(yè)務(wù)系統(tǒng)傳入的屬性（可以和 Subject、Object 無關(guān)），通過 Expression Language 來實現(xiàn)基于上下文做動態(tài)運算
- Expression Language：表達式語言，根據(jù)上下文參數(shù)、內(nèi)置方法動態(tài)計算結(jié)果
- ALC(Access Contrl) :訪問控制，本文指工程資源訪問策略
權(quán)限模型
應(yīng)用劃分
從用戶視角劃分業(yè)務(wù)應(yīng)用，應(yīng)用的粒度可探討
例如，定義 ITSM 里的 ITAM 作為一個業(yè)務(wù)應(yīng)用，或者定義 ITAM 里的臺賬(Account)作為一個業(yè)務(wù)應(yīng)用；
業(yè)務(wù)應(yīng)用下面可劃分 1-N 個工程應(yīng)用，工程應(yīng)用可包括前端工程、后端微服務(wù)工程。
目的：權(quán)限項和業(yè)務(wù)應(yīng)用綁定，方便用戶從用戶視角設(shè)置設(shè)置某個業(yè)務(wù)的角色、權(quán)限；
工程應(yīng)用隸屬于某一個業(yè)務(wù)應(yīng)用，例如 ITAM 下有 ITAM-A，ITAM-B 等工程應(yīng)用，每個工程應(yīng)用管理自己的權(quán)限（菜單、按鈕、HTTP 接口、RPC 接口等）
目的：工程應(yīng)用和業(yè)務(wù)應(yīng)用綁定，工程資源和工程應(yīng)用綁定，權(quán)限項和工程資源綁定，方便開發(fā)人員按需設(shè)置訪問策略。
用戶和用戶組
用戶定義為系統(tǒng)資源訪問者，廣義范圍的用戶定義，不僅包括租戶內(nèi)的自然人，還包括應(yīng)用內(nèi)子系統(tǒng)、第三方系統(tǒng)等，不同類型的用戶有不同的基本屬性，用戶屬性可擴展；
高效圈定用戶
一個用戶屬于多個用戶組，一個用戶組包含多個用戶，用戶和用戶組的關(guān)聯(lián)關(guān)系可靜態(tài)指定、可通過 Condition 組成的 Expression Language 表達式來動態(tài)匹配，動態(tài)匹配需監(jiān)聽主數(shù)據(jù)的用戶屬性變化，實現(xiàn)較復(fù)雜，可迭代實現(xiàn)
用戶組沒有實現(xiàn)關(guān)系繼承，在具體使用中，用戶組繼承增加權(quán)限溯源復(fù)雜度，對高效圈定用戶用處不大。
資源
工程應(yīng)用下面的資源管理，不同的用戶類型可以訪問不同的工程資源，
例如，自然人訪問的資源就是菜單、界面、按鈕已經(jīng)按鈕對應(yīng)的網(wǎng)關(guān)接口；
系統(tǒng)訪問的資源是 API 接口(HTTP、RPC)。
權(quán)限項
權(quán)限項是管理員在給角色授權(quán)時看到的權(quán)限信息，包括功能權(quán)限項和數(shù)據(jù)權(quán)限項；權(quán)限項是工程資源和主數(shù)據(jù)在權(quán)限業(yè)務(wù)域的定義，并定義權(quán)限業(yè)務(wù)的對應(yīng)配置。
例如主數(shù)據(jù) 資產(chǎn)(Asset)有屬性 型號(Model)，對應(yīng)權(quán)限項配置
- name: 實物資產(chǎn)
key: Asset
attributes:
- name: 資產(chǎn)型號
key: "model"
deny_show: "-888888"
value_type: "int"
資源訪問控制(ACL)
工程資源如果需要鑒權(quán)，要和對應(yīng)的權(quán)限項進行綁定
例如應(yīng)用業(yè)務(wù) ITAM 的前端工程 athena.node 的 HTTP 接口 GetAssetList 需要鑒權(quán)，需要的權(quán)限項 ITAM 應(yīng)用下的權(quán)限項配置是 asset:view_list,ACL 配置如下：
- 接口資源表式格式：{業(yè)務(wù)應(yīng)用}:{工程應(yīng)用}:{接口}
- 功能權(quán)限項格式：{業(yè)務(wù)應(yīng)用}:{resource}:{action}
CheckPermission: true
InterfaceName: itam:node:GetAssetList
RuleList:
- Rule:
- AuthKey: itam:asset:view_list
角色及權(quán)限設(shè)置
角色新增時，綁定一個用戶類型，類型可以是 Global，Global 角色不區(qū)分用戶類型；
角色權(quán)限設(shè)置內(nèi)容：設(shè)置角色的功能權(quán)限項，數(shù)據(jù)權(quán)限項
數(shù)據(jù)字段權(quán)限項可設(shè)置允許、禁用兩種策略(參考 PeopleSaas 鑒權(quán))
數(shù)據(jù)行范圍權(quán)限通過用戶類型屬性和主數(shù)據(jù)字段屬性匹配圈定范圍，
例如，角色 A 的用戶類型關(guān)聯(lián)：Employee，對資產(chǎn)的訪問范圍是只能訪問所在區(qū)域的閑置資產(chǎn)，表達式：
employee.location==asset.location&&asset.status=='idle'
授權(quán)
單個用戶可直接關(guān)聯(lián)一個用戶組，用戶組關(guān)聯(lián)角色，從而獲得權(quán)限；
單個用戶可通過條件匹配到動態(tài)用戶組，用戶組關(guān)聯(lián)角色，從而獲得權(quán)限；
單個用戶可直接設(shè)置角色，從而獲得角色設(shè)置的權(quán)限。
權(quán)限優(yōu)先級
用戶從不同途徑獲取的權(quán)限會存在沖突重疊，定義優(yōu)先級如下
場景流程
場景 1:第三方用戶資產(chǎn)回購-確認支付主體
IT 部門引入第三方公司 A 的員工，其工作職責(zé)是在 ITAM 后臺負責(zé)所在區(qū)域的資產(chǎn)回購確認支付主體，只能看到所在區(qū)域的狀態(tài)為代確認主體的回購流程單，每一行記錄只能看到資產(chǎn)編號和申請時間。
場景 2:工程應(yīng)用 itam-flow 獲得主數(shù)據(jù) Employee 的部分權(quán)限
itam-flow 只有主數(shù)據(jù) Employee 的 UserName、Logo、Department、Sequence 查詢權(quán)限
- itam-flow 作為一個內(nèi)部系統(tǒng)注冊為權(quán)限用戶；
- 設(shè)置一個角色，這個角色可以查詢 itam-data 服務(wù)的 Employee 查詢接口，數(shù)據(jù)列只有 UserName、Logo、Department、Sequence；
- itam-data 的 Employee 查詢接口，識別 itam-flow 系統(tǒng)，按照策略查詢 itam-flow 的數(shù)據(jù)權(quán)限，按權(quán)限配置返回數(shù)據(jù)。
物理架構(gòu)
