融合模型权限管理设计方案

动手点关注 干货不迷路 👆

名词解释

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 都有几十年的历史，哪怕国内的用友、金蝶（虽然做的不算一流）也是一样。

2B SaaS 是一个很大赛道，也是一个可以投入几十年的事业，无论是技术还是领域知识都能让我们在四五十岁时都充满竞争力，还在等什么，火速上车吧~扫描下方二维码或点击“阅读原文”发现职位&投递简历!