名詞解釋

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 訪問控制列表 | 許可權客體儲存一個對自己擁有訪問許可權的主體名單，該名單記錄主體及主體可對客體操作的許可權> 公司的門衛拿著一個名單，名單裡記錄了來訪者及其可訪問的樓層房間，必須在名單裡的人才能進入公司相應的樓層房間 | | ----------- | ------------------------------------------------------------------------------------------------------------------------ | | MAC 強制訪問控制 | 許可權主體訪問客體時，雙向檢查主體和客體的訪問等級是否匹配> 公司 1 號辦公室的保密等級是 level 3，辦公室門衛檢查來訪者的等級是否 >= level 3 | | DAC 自主訪問控制 | 許可權主體可將自己對客體（往往是客體的Owner）擁有的許可權傳遞給其他主體，傳遞可以是一級或者多級> 小鳴 有公司很多辦公室的鑰匙，小鳴 可以複製一些鑰匙給 小波 | | RBAC 角色訪問控制 | 主體關聯角色、角色關聯許可權，許可權關聯客體和可對客體執行的動作，主體觸發許可權動作時如果主體在該許可權關聯的角色中則獲得許可權> 公司老闆給了 小鳴 一個通行證，通行證能進入 1，2，3 號辦公室，門衛根據通行證放行小鳴 進入 1 ，2，3號辦公室 | | ABAC 屬性訪問控制 | 許可權主體、許可權客體、訪問行為、訪問環境都可以用屬性描述，通過在系統內定義這些屬性規則來實現 “滿足何種條件下，主體能對客體執行何種動作”> 公司的門衛收到一套老闆的規則：- > 18歲以上的女性可以在任何時間進入 1 號辦公室 |

• 18歲以下的女性僅可在上午10:00-12:00進入 1 號辦公室> 門衛檢查每個來訪者的性別、年齡、來訪時間，來決定他們能否進入 1 號辦公室 |

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

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

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

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

一種比較基礎的許可權管控機制，簡單直接，常應用於作業系統中的檔案系統。

| 定義 | 關聯在 Object 上的一個許可權列表，這個列表裡的每個條目指定一個 Subject 和 該Subject 可對 Object 執行的 Action | | ------- | -------------------------------------------------------------------------- | | 示例 | 某個檔案的ACL為：Alice: read,write; Bob: read則 Alice 可讀可寫該檔案，Bob 可讀該檔案 | | 應用 | 飛書的單個文件、Mac OS 下的某個檔案、Active Directory 裡的某個物件 | | 類比 | 公司的門衛拿著一個名單，必須在名單裡才能進入公司 | | 優缺點 | 優點：表述直觀，易於理解缺點：大使用者量、許可權變動高頻場景下維護成本高，審計時不便於審計主體可以訪問哪些客體 |

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

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

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

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

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

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

| 定義 | 在 Subject 訪問 Object 時，雙向檢查 Subject 和 Object 的 Level ，僅在主體 Level >= 客體Level 時才允許訪問 | | ------- | --------------------------------------------------------------------------------- | | 示例 | Alice with Top Classfication can Read Doc1 with Top Classfication | | 應用 | 美國空軍SACDIN（戰略空軍司令部通訊系統）Window Vista MIC（強制完整性控制） | | 類比 | 辦公室1的訪問等級是 level 3，門衛檢查來訪者的等級是否 >= level 3 | | 優缺點 | 優點：高度安全缺點：不夠靈活、前期規劃成本高、人員 & 資源變動時管理成本高 |

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

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

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

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

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

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

| 定義 | Subject 可將自己擁有的某種訪問許可權直接/間接的傳遞給另一個 Subject傳遞可能是一級、二級或者多級的 | | ------- | ------------------------------------------------------------------------------------------------------ | | 示例 | Alice can read and edit Article 1, Alice grant read Article 1 to bob則 Bob 可讀 Article 1 | | 應用 | Wiki、Unix File Mode、飛書文件 | | 類比 | 小鳴 有公司很辦公室的鑰匙，小鳴 可以複製一些鑰匙給 小波 | | 優缺點 | 優點：許可權分享成本低，授權機制靈活缺點：如果應用於組織內部，缺少組織層面的管控，安全性不夠 |

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

| 定義 | User 被分配給 Role，Permissions 被分配給 Role，User — Role — Permissions 三者之間是多對多的關係 | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 示例 | 小鳴 被分配到 Role SD 中，Role SD 關聯了對 ITAM 系統的 Access 許可權 | | 應用 | Jira：Jira 的專案許可權系統底層是 RBAC，同時又做了一些改造 官方幫助文件Azure：Azure 通過 RBAC 實現 Azure Portal 內的管理許可權 官方幫助文件AWS、阿里雲、百度雲、騰訊雲等等...市面上以 Core RBAC 作為許可權底層模型的系統非常多，飛書裡也有類似設計 | | 優缺點 | - 優點：滿足 最小許可權、職責分離和許可權抽象 原則 |

• 缺點：

  • 無法滿足某個角色下的個別使用者需要特別的許可權定製，如果此類需求高頻出現會導致角色數量暴漲從而管理失控（ITAM中不同區域的SD需要配置不同的許可權）
  • 無法實現動態鑑權，如自動判斷條件進行授權或拒絕授權
  • 無法高效授權，使用者量大、使用者變更頻繁的場景會導致配置工作量暴增 |

RBAC1 - Hierarchical RBAC

| 定義 | 和 Core RBAC 的核心區別是 Role 有繼承關係，繼承關係又分為兩種：- 樹狀繼承：高級別角色自動繼承直接下級角色的所有許可權，這個設計映射了現實世界裡的層級化結構，典型場景如 CEO 角色有其直接下屬 VP 角色的所有許可權，每個 VP 角色又有其直接下屬 經理 角色的所有許可權，許可權層層從下往上繼承。

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

RBAC2 - Constrained RBAC

| 定義 | 和 Core RBAC 的核心區別是強調了使用者和角色之間關係的一些限制，分為兩類：- SSD (Static Separation of Duty，靜態職責分離) ，主要的約束包括：

- 角色互斥約束：同一個使用者僅能分配到互斥角色中的一個。例如：財務系統中一個使用者不能同時分配會計和審計兩種互斥的角色。 - 基數約束：一個使用者擁有的角色是有限的，一個角色擁有的許可權是有限的。 - 先決條件約束：使用者在獲得某個角色之前需先擁有另一個角色，類似只有副總經理才能成為總經理。

• DSD (Dynamic Separation of Duty，動態職責分離)，主要應用於會話和角色之間動態地限制使用者及其擁有的角色和相應的許可權。如：一個使用者在系統中擁有兩個不同的角色，但在使用系統時只能啟用其中一個角色，如 設計 和 產品 這兩個角色的使用方式和資料會產生衝突，在訪問時需要使用者同一時間只能選擇一個角色登陸。 
• 中通快遞：中通統一許可權安全管控系統 在應用 RBAC 模型時設計了角色互斥機制。
• 用友 NC6 中將角色區分為管理類和業務類兩種互斥的角色

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 執行某許可權行為。

| 定義 | Subject 對 Object 的某些 Operation 能否被允許取決於 Subject 的屬性、Object 的屬性、環境條件以及一個定義這些屬性和條件的 Policy 集 | | ------ | --------------------------------------------------------------------------------------------------------------------- | | 示例 | 1. Subject 請求訪問 Object |

1. Access Control 機制評估 a) Policy b) Subject Attributes, c) Object Attributes, d) Environment Conditions 來計算是否授權

2. 通過授權計算後，Subject 獲得可對 Object 執行的 Operation 許可權 | | 應用 | - AWS 在 RBAC 的基礎之上支援 ABAC，並強調這樣設計的原因是可擴充套件性 官方幫助文件

3. Kubernetes 一開始只支援 ABAC，但是在 1.6 版本中引入了 RBAC 並提供了遷移方案

4. 阿里雲的 RAM 訪問控制基於 ABAC 模型，為了避免效能問題，RAM 設計了很多使用限制 官方幫助文件
5. 從Windows Server 2012 開始，Microsoft 已實施ABAC方法來控制對檔案和資料夾的訪問 | | 通俗易懂的類比 | 公司的門衛收到一套老闆的規則：- 18歲以上的女性可以在任何時間進入 1 號辦公室
6. 18歲以下的女性僅可在上午10:00-12:00進入 1 號辦公室門衛檢查每個來訪者的性別、年齡、來訪時間，來決定他們能否進入 1 號辦公室 | | 優缺點 | - 優點：能力最為強大，基於描述主體、客體、動作和環境的屬性進行鑑權，可實現非常精細化的許可權管控。
7. 缺點：無法直觀審計使用者擁有哪些許可權、規則複雜會提高管理成本；效能問題。

下一代許可權模型探索 - 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）

結論

| 控制模型 | 優點 | 缺點 | | -------- | -------------------- | ------ | | DAC | - 簡單，支援 ACL，便於實時審計許可權 | |

• 支援許可權自擴散，便於傳播 | - 不支援組織層面管控
• 不夠安全 | | MAC | - 高度安全 | - 終端使用者無法修改許可權
• 管理成本高 | | RBAC | - 角色繼承
• 職責分離
• 最小許可權 | - Role 爆炸
• 不支援精細化動態場景
• 修改許可權必須修改 Role | | ABAC | - 條件感知，適應精細化動態場景
• 無需角色概念，許可權修改成本低
• 靈活 | - 邏輯較複雜
• 無法實時審計使用者許可權 | | NGAC | - 條件感知，適應精細化動態場景
• 靈活，同時滿足簡單高效的粗放鑑權和動態鑑權
• 滿足審計需求 | - 邏輯較複雜
• 配置複雜 |

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

方案參考

帶著上述目標，主要看了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)，對應許可權項配置

```go - 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}

```go 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 Business Applications)，目前我們在北京、深圳、上海、武漢、杭州、成都、廣州、三亞都設立了辦公區域。我們關注的產品領域主要在企業經驗管理軟體上，包括飛書 OKR、飛書績效、飛書招聘、飛書人事等 HCM 領域系統，也包括飛書審批、OA、法務、財務、採購、差旅與報銷等系統。歡迎各位加入我們。

掃碼發現職位&投遞簡歷

https://job.toutiao.com/s/YykBX11