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

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，并强调这样设计的原因是可扩展性 官方帮助文档

• Kubernetes 一开始只支持 ABAC，但是在 1.6 版本中引入了 RBAC 并提供了迁移方案
• 阿里云的 RAM 访问控制基于 ABAC 模型，为了避免性能问题，RAM 设计了很多使用限制 官方帮助文档
• 从Windows Server 2012 开始，Microsoft 已实施ABAC方法来控制对文件和文件夹的访问 | | 通俗易懂的类比 | 公司的门卫收到一套老板的规则：- 18岁以上的女性可以在任何时间进入 1 号办公室
• 18岁以下的女性仅可在上午10:00-12:00进入 1 号办公室门卫检查每个来访者的性别、年龄、来访时间，来决定他们能否进入 1 号办公室 | | 优缺点 | - 优点：能力最为强大，基于描述主体、客体、动作和环境的属性进行鉴权，可实现非常精细化的权限管控。
• 缺点：无法直观审计用户拥有哪些权限、规则复杂会提高管理成本；性能问题。

下一代权限模型探索 - 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. Condition
2. 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 Business Applications)，目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统，也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎各位加入我们。

扫码发现职位&投递简历

job.toutiao.com/s/YykBX11