融合模型權限管理設計方案

名詞解釋

ITAM：ITAM 是對 IT 辦公資產 -- 實物資產 (如筆記本電腦)、軟件資產 (如 Office365)-- 進行生命週期管理的系統。

ITAM-Auth：ITAM 系統的鑑權服務。

ITAM-Data：ITAM 系統的數據服務。

SaaS：軟件即服務（英語：Software as a Service，縮寫：SaaS），一種軟件交付模式。在這種交付模式中，軟件僅需通過網絡，不須經過傳統的安裝步驟即可使用，軟件及其相關的數據集中託管於雲端服務。

ServiceNow：ServiceNow 是一家美國軟件公司，總部位於加州聖克拉拉，該公司開發了一個雲計算平臺，幫助企業管理企業 IT 工作流。ServiceNow 由弗雷德 · 盧迪於 2003 年創立，在紐約證券交易所上市，是羅素 1000 指數和標準普爾 500 指數的組成股。2018 年，《福布斯》雜誌將其評爲全球最具創新性公司的第一名。

背景

本方案梳理了業界主流權限模型，IT Saas 化中權限管理要解決的問題，參考了公司內外、國內外的一些權限設計方案，結合 RBAC、ABAC 模型提出了 ITAM 融合模型權限管理方案。

主流權限模型

參考了多個系統的權限實現後，總結出公用的權限理論模型，具體到每個系統的實現會有一些改造和優化，本部分介紹工業界廣泛使用的權限模型。

概述

主體：一個訪問行爲的發起方，此處簡化理解，假設都是用戶

客體：訪問行爲的施加對象，如頁面、功能、數據

ACL (Access-Control List 訪問控制列表)

Subject：主體，訪問方，可以是人也可以是系統、設備等

Action：訪問的具體動作，如 Create、Read、Edit...

Object：客體，被訪問方，可以是系統中的某個條目、某個文件等

一種比較基礎的權限管控機制，簡單直接，常應用於操作系統中的文件系統。

MAC (Mandatory Access Control 強制訪問控制)

Subject：主體，訪問方，可以是人也可以是系統、設備等

Action：訪問的具體動作，如 Create、Read、Edit...

Object：客體，被訪問方，可以是系統中的某個條目、某個文件等

Attributes：在 Subject 和 Object 上均可能有多個 Attributes ，用於鑑權判斷的元數據

主體和客體會被分別賦予一個機密等級，訪問時雙向檢查主體和客體的等級是否匹配，常被應用於安全要求性高的領域，如軍事、金融、政府、計算機系統安全等，雙向鑑權時遵循 authorization rule，該 rule 的存儲位置和管理通常非常嚴格。

DAC (Discretionary Access Control 自主訪問控制)

Subject：主體，訪問方，可以是人也可以是系統、設備等

Action：訪問的具體動作，如 Create、Read、Edit...

Object：客體，被訪問方，可以是系統中的某個條目、某個文件等

Grant：轉授權行爲，Subject 1 可對 Object 執行的全部或部分 Action 轉授給 Subject 2

自主訪問控制簡單理解是權限 Subject 可將自己擁有的權限轉移給其他主體，通常是爲了解決權限分配靈活度的問題，但是在 B 端系統裏往往不會僅僅採用 DAC 這一種權限模型（比如會結合 MAC 模型），因爲該模型會導致管理員無法掌控的權限擴散。

RBAC (Role Based Access Control 角色訪問控制)

RBAC 認爲權限的本質是 Who 對 What 進行了 How 操作

User：主體，訪問方，代表系統中的用戶，但也可以是機器、網絡等 - Who

Object：客體，被訪問方，可以是系統中的某個菜單、按鈕、數據記錄、API 等 - What

Operation：系統中用戶可執行的某個動作 - How

Permissions：權限，代表可向 RBAC 保護下的 Object 執行 Operation （What + How）

Role：角色，代表組織內一些職責及該職責下的用戶擁有某些指定的權限

Session：會話，會話由一個用戶觸發，同時會話激活會話關聯的一個或多個 Role

本文重點介紹被 INCITS（國際信息技術標準委員會） 採納的標準 RBAC 模型

標準 RBAC 分爲 4 個子模型：

RBAC0 - Core RBAC

RBAC1 - Hierarchical RBAC

• 一般繼承：角色之間的是一個絕對偏序的繼承關係（有向無環，成環的角色繼承無意義），這個設計比單一的樹狀繼承更自由，適用於角色權限有繼承需求但又不是嚴格的上下層級關係的權限場景。

RBAC2 - Constrained RBAC

RBAC3 = RBAC 1 + RBAC 2

RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色繼承也包含了相關約束。

優點：能力最強大。

缺點：4 種模型中最複雜的模型，管理成本較高。

總體上，RBAC 被認爲滿足了三個重要權限原則：

• 最小權限：用戶僅在觸發會話動作時獲取到其所在角色，該角色定義了完成該動作所需的最小權限。

• 權限抽象：可結合業務抽象出具體的權限行爲，如發表評論、上傳附件，而不是簡單的 讀、寫、查。

• 職責分離：角色本身表徵了職責，加上 RBAC 支持角色和角色間的互斥機制，實現高風險動作分治。

對標準 RBAC 的擴展

• 面向單個用戶授權時的管理成本：可以跳過 Role 直接對用戶授權

• 面向大批量用戶授權時的管理成本：Group 也可以被分配到 Role 中

• 面向維護 Role 的管理成本：用戶在 Role 中可進行權限裁剪（代表這個用戶僅擁有這個 Role 的部分權限）、可複製 Role 等等

• 和其他權限模型的結合：

• 和 DAC 、MAC 的結合

• 和 ABAC 的結合

ABAC (Attribute Based Access Control 屬性訪問控制)

Subject：主體，訪問方，代表系統中的用戶，但也可以是機器、網絡等

Object：客體，被訪問方，可以是系統中的某個文件、設備、數據庫記錄等

Operation：系統中主體對客體請求執行的功能 / 行爲，可包括 read、write、edit、delete 等

Attributes：屬性，Subject、Object、Operation 和 Environment Condition 都有屬性，屬性是一對鍵值

Policy：一系列由屬性和屬性值構成的規則或關係，通過該規則 / 關係可判斷一個訪問能否被允許

Environment Conditions：可被識別的環境條件，訪問行爲發生的環境，通常可以是時間、地點、IP、設備、操作系統、風險級別等

ABAC 是建立在 Subject 屬性、Object 屬性、環境屬性及訪問 Policy 之上的細粒度權限管控，ABAC 能做到只有符合特定屬性的 Subject 在特定條件下可以對符合特定屬性的 Object 執行某權限行爲。

下一代權限模型探索 - NGAC

在 DAC、MAC、RBAC、ABAC 這些主流權限模型之外，還存在大量其他權限模型（如 LBAC、GBAC、CBAC、OrBAC、RAdAC...），但目前還沒有一種權限模型得到了工業界的廣泛採納。

學術界已經有了一些關於下一代權限模型的研究成果。

NIST（美國國家標準技術研究所）在 2019 年提出了 NGAC(Next Generation Access Control 下一代訪問控制模型)，提出這是區別於現有權限模型之外的一種全新模型且可以廣泛兼容當前數字生態裏的各種權限場景。

從下圖來看更像是 RBAC 思路和 ABAC 思路的結合，結合點是 用戶 —— 角色的關係不再人爲分配，而是根據 Policy 自動分配，用戶以角色身份進行權限行爲時再過一遍 ABAC 的規則判斷。

典型應用場景：Alice 只有在工作日的上午 10:00-18:00 在倫敦的辦公室網絡下（role-based permission policy）才能以財務的角色訪問並修改訂單系統裏的數據 （role-based permission policy）

結論

沒有哪種權限模型是完美的，重要的是如何和業務結合，考慮安全性、擴展性、靈活性、易用性、管理成本、合規等因素並取得均衡，這個過程往往是最複雜的。

方案參考

帶着上述目標，主要看了 ServiceNow 的權限實現方案，從基本思路、可借鑑設計、方案缺點三方面做如下分析。

ServiceNow

基本思路

ServiceNow 權限管理採用 RBAC1+ACL 的方式，ACL 控制 ObjectType 的 Operation 訪問，通過 Role、Condition、Script 進行動態校驗。

權限模型

用戶和用戶組

用戶基本信息管理，所屬部門，一個用戶可以加入多個用戶組，一個用戶可通過設置代理來行使本用戶的系統權限；

用戶組包含多個用戶，用戶組之間可以繼承，子用戶組繼承父用戶組的權限。

角色

角色的使用是被動的，Module 在配置時可以關聯角色，UI Action 可以關聯角色，ACL 配置可以關聯角色，角色存在繼承關係，子角色繼承父角色的權限。

應用和資源

ServiceNow 內部區分不同的應用，不同的應用有不同的資源、角色、權限設置，應用 (Application) 被抽象爲一組可安裝的組件資源，資源包括了 Table(數據表)、Dictionary(數據列)、API 接口 (REST_Endpoint)、Menu(菜單)、Module(頁面組件)、UI Page(獨立頁面)、UI Action(頁面按鈕) 等，其中菜單、頁面組件、頁面按鈕使用 RBAC 權限模式；數據表、數據列、API 接口、獨立頁面使用 ACL 鑑權。

比較特殊的，Table 在 ACL 鑑權的同事，有配置 Application Access，即每個 table 按照應用來設置操作權限。

ACL 鑑權的 Object 和 Operation 類型如下所示。

組件 (Module) 有多種訪問方式，以 ListRecord 和 URL 訪問爲主，如下圖所示。ListRecord 表示訪問一個表的記錄，URL 訪問方式表示通過 URL-Get 參數方式訪問數據。Module 的鑑權通過配置關聯的 Role 來實現。

Module 的 LinkType(訪問方式) 有 13 種，ListRecord 方式可以通過 Filter 指定默認的過濾查詢條件，但不是作爲數據行範圍權限來使用的，進入具體頁面後，過濾條件可以清除。

RBAC 鑑權

需要鑑權的資源在配置時關聯需要的角色，角色的使用是被動的，Module 在配置時可以關聯角色，UI Action 可以關聯角色，ACL 配置可以關聯角色。

用戶或者用戶組在配置時選擇關聯的角色。

ACL 鑑權

ACL 鑑權指定 Object 的 Operation 需要鑑權，通過三種方式進行鑑權

1. Role

2. Condition

3. Script

Table 的增刪改查、字段的增刪改查都可以通過 ACL 來配置

ServiceNow 對 Table、Column 的 ACL 控制大部分都是 ReadOnly

可借鑑設計

1. 資源的管理粒度細，所以權限的管控粒度、靈活性好；

2. 針對不同的鑑權場景使用不同的鑑權模型；

3. UI 層資源和權限的數據鏈接、各信息的 Link 跳轉設計細緻；

缺點

1. 用戶和用戶組的關聯缺乏靈活性，例如按照用戶屬性圈定一批用戶作爲一個組；

2. 權限配置比較分散，使用權限的地方散落在各個資源管理入口；

3. ACL 的 Condition 配置功能簡陋，配置門檻高；

4. 沒有考慮開放與集成場景的鑑權；

5. 沒有數據範圍鑑權。

問題

1. 權限管理的本質是對用戶訪問系統資源做權限控制，需要先定義好系統中的用戶、資源、權限；

2. 用戶體量大、崗位流轉率高的情況下，要能高效、便捷的圈用戶、授權；

3. 數據鑑權，包括數據行鑑權、列鑑權，數據權限高效授權、鑑權；

4. 良好的業務擴展性；

5. 權限管理和權限使用的前後端模塊劃分不一致，業務定義和工程定義不一致，例如前端是一個整體服務，後臺劃分了多個微服務，在權限管理、功能鑑權、數據鑑權時如何劃分和控制；

6. 權限需要的特色功能：角色互斥，身份代理，權限前置依賴，權限審批流程，角色授權設置有效期，權限策略優先級。

目標

技術目標

• 工作效率：用戶可以多快獲得應當具備的權限；

• 鑑權效率：高性能保證鑑權不影響正常業務邏輯處理；

• 安全性：保證不會由於權限系統誤判導致功能、數據泄漏；

• 擴展性：在系統的多個節點提供擴展性，包括但不限於用戶類型擴展、用戶屬性擴展、資源類型擴展、資源屬性擴展。

功能目標

基本功能

權限基本功能開發，解決上述問題 1-5。

字段編輯權限

當前用戶對字段無編輯權限時，前端展示控件做禁用處理。

身份代理

用戶請假或者工作崗位調動，會存在把系統權限臨時或永久轉移給交接的人。該功能在設計上支持，後續通過版本迭代實現，MVP 版本不實現。

設計方案

本方案設計上採用 RBAC+ABAC 融合方式實現權限管理，即 NGAC。兼容 RBAC、ABAC 的優點，同時在實現方案上預留擴展點，整個方案在實施過程中可以通過 “大設計、小實現” 的方式迭代式開放，在保持整體架構不變的情況下，可以先實現 MVP 版本，然後逐步迭代實現設計方案中的功能。

專用術語

User：用戶，可以是租戶內的一個自然人用戶、可以是第三方系統、可以是應用內的子系統，各類用戶有基本屬性，屬性可按照租戶維度自定義；

UserGroup：在管理平臺指定的一組用戶，用來給這些用戶賦予訪問權限；

Role：角色，角色用於配置權限策略，一個角色關聯一個用戶類型，角色策略配置該角色擁有的功能權限、數據列權限、數據行範圍權限；

Resource：權限資源項，例如 flow(流程)，Resource 有層級關係，對應多個 Action，非葉子結點只有 Read，葉子結點有 1-N 個 Action；

Action：動作，比如：管理、查看詳情、修改

Condition：條件，可以承載 Subject、Object 附帶的屬性，也可以承載業務系統傳入的屬性（可以和 Subject、Object 無關），通過 Expression Language 來實現基於上下文做動態運算

Expression Language：表達式語言，根據上下文參數、內置方法動態計算結果

ALC(Access Contrl) : 訪問控制，本文指工程資源訪問策略

權限模型

應用劃分

從用戶視角劃分業務應用，應用的粒度可探討

例如，定義 ITSM 裏的 ITAM 作爲一個業務應用，或者定義 ITAM 裏的臺賬 (Account) 作爲一個業務應用；

業務應用下面可劃分 1-N 個工程應用，工程應用可包括前端工程、後端微服務工程。

目的：權限項和業務應用綁定，方便用戶從用戶視角設置設置某個業務的角色、權限；

工程應用隸屬於某一個業務應用，例如 ITAM 下有 ITAM-A，ITAM-B 等工程應用，每個工程應用管理自己的權限（菜單、按鈕、HTTP 接口、RPC 接口等）

目的：工程應用和業務應用綁定，工程資源和工程應用綁定，權限項和工程資源綁定，方便開發人員按需設置訪問策略。

用戶和用戶組

用戶定義爲系統資源訪問者，廣義範圍的用戶定義，不僅包括租戶內的自然人，還包括應用內子系統、第三方系統等，不同類型的用戶有不同的基本屬性，用戶屬性可擴展；

高效圈定用戶

一個用戶屬於多個用戶組，一個用戶組包含多個用戶，用戶和用戶組的關聯關係可靜態指定、可通過 Condition 組成的 Expression Language 表達式來動態匹配，動態匹配需監聽主數據的用戶屬性變化，實現較複雜，可迭代實現

用戶組沒有實現關係繼承，在具體使用中，用戶組繼承增加權限溯源複雜度，對高效圈定用戶用處不大。

資源

工程應用下面的資源管理，不同的用戶類型可以訪問不同的工程資源，

例如，自然人訪問的資源就是菜單、界面、按鈕已經按鈕對應的網關接口；

系統訪問的資源是 API 接口 (HTTP、RPC)。

權限項

權限項是管理員在給角色授權時看到的權限信息，包括功能權限項和數據權限項；權限項是工程資源和主數據在權限業務域的定義，並定義權限業務的對應配置。

例如主數據 資產 (Asset) 有屬性 型號(Model)，對應權限項配置

- name: 實物資產

  key: Asset

  attributes:

    - name: 資產型號

      key: "model"

      deny_show: "-888888"

      value_type: "int"

資源訪問控制 (ACL)

工程資源如果需要鑑權，要和對應的權限項進行綁定

例如應用業務 ITAM 的前端工程 athena.node 的 HTTP 接口 GetAssetList 需要鑑權，需要的權限項 ITAM 應用下的權限項配置是 asset:view_list,ACL 配置如下：

• 接口資源表式格式：{業務應用}:{工程應用}:{接口}

• 功能權限項格式：{業務應用}:{resource}:{action}

CheckPermission: true

InterfaceName: itam:node:GetAssetList

RuleList:

   - Rule:

     - AuthKey: itam:asset:view_list

角色及權限設置

角色新增時，綁定一個用戶類型，類型可以是 Global，Global 角色不區分用戶類型；

角色權限設置內容：設置角色的功能權限項，數據權限項

數據字段權限項可設置允許、禁用兩種策略 (參考 PeopleSaas 鑑權)

數據行範圍權限通過用戶類型屬性和主數據字段屬性匹配圈定範圍，

例如，角色 A 的用戶類型關聯：Employee，對資產的訪問範圍是只能訪問所在區域的閒置資產，表達式：

employee.location==asset.location&&asset.status=='idle'

授權

單個用戶可直接關聯一個用戶組，用戶組關聯角色，從而獲得權限；

單個用戶可通過條件匹配到動態用戶組，用戶組關聯角色，從而獲得權限；

單個用戶可直接設置角色，從而獲得角色設置的權限。

權限優先級

用戶從不同途徑獲取的權限會存在衝突重疊，定義優先級如下

場景流程

場景 1: 第三方用戶資產回購 - 確認支付主體

IT 部門引入第三方公司 A 的員工，其工作職責是在 ITAM 後臺負責所在區域的資產回購確認支付主體，只能看到所在區域的狀態爲代確認主體的回購流程單，每一行記錄只能看到資產編號和申請時間。

場景 2: 工程應用 itam-flow 獲得主數據 Employee 的部分權限

itam-flow 只有主數據 Employee 的 UserName、Logo、Department、Sequence 查詢權限

1. itam-flow 作爲一個內部系統註冊爲權限用戶；

2. 設置一個角色，這個角色可以查詢 itam-data 服務的 Employee 查詢接口，數據列只有 UserName、Logo、Department、Sequence；

3. itam-data 的 Employee 查詢接口，識別 itam-flow 系統，按照策略查詢 itam-flow 的數據權限，按權限配置返回數據。

物理架構

加入我們

我們是字節跳動 Lark-LBA-People C&B 團隊，負責飛書的薪酬、期權、休假、社保、獎金等多個業務系統平臺的開發。今年我們正在從 0 到 1 搭建基礎薪酬和休假的 SaaS 系統，並將開始面向字節和外部租戶使用，極缺人才。

在 HCM 領域，飛書還非常早期。在技術系統和團隊建設上，我們同樣非常早期。所以 C&B 團隊有非常多的機會，能夠讓大家承擔技術、業務、團隊上的更大挑戰，也獲得更快速的成長。

我們會發現 2B SaaS 的佼佼者微軟、Oracle、SAP 都有幾十年的歷史，哪怕國內的用友、金蝶（雖然做的不算一流）也是一樣。

字節跳動技術團隊 字節跳動的技術實踐分享

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zI521RaT9NO4Ng2Vro36zA