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

作者 ｜ ​杨子国,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 融合模型权限管理方案。,参考了多个系统的权限实现后，总结出公用的权限理论模型，具体到每个系统的实现会有一些改造和优化，本部分介绍工业界广泛使用的权限模型。,主体：一个访问行为的发起方，此处简化理解，假设都是用户,客体：访问行为的施加对象，如页面、功能、数据,,Subject：主体，访问方，可以是人也可以是系统、设备等,Action：访问的具体动作，如 Create、Read、Edit…,Object：客体，被访问方，可以是系统中的某个条目、某个文件等,一种比较基础的权限管控机制，简单直接，常应用于操作系统中的文件系统。,,Subject：主体，访问方，可以是人也可以是系统、设备等,Action：访问的具体动作，如 Create、Read、Edit…,Object：客体，被访问方，可以是系统中的某个条目、某个文件等,Attributes：在 Subject 和 Object 上均可能有多个 Attributes ，用于鉴权判断的元数据,主体和客体会被分别赋予一个机密等级，访问时双向检查主体和客体的等级是否匹配，常被应用于安全要求性高的领域，如军事、金融、政府、计算机系统安全等，双向鉴权时遵循 authorization rule，该 rule 的存储位置和管理通常非常严格。,,Subject：主体，访问方，可以是人也可以是系统、设备等,Action：访问的具体动作，如 Create、Read、Edit…,Object：客体，被访问方，可以是系统中的某个条目、某个文件等,Grant：转授权行为，Subject 1 可对 Object 执行的全部或部分 Action 转授给 Subject 2,自主访问控制简单理解是权限 Subject 可将自己拥有的权限转移给其他主体，通常是为了解决权限分配灵活度的问题，但是在 B 端系统里往往不会仅仅采用 DAC 这一种权限模型（比如会结合 MAC 模型），因为该模型会导致管理员无法掌控的权限扩散。,,RBAC 认为权限的本质是 Who 对 What 进行了 How 操作,User：主体，访问方，代表系统中的用户，但也可以是机器、网络等 – Who,Object：客体，被访问方，可以是系统中的某个菜单、按钮、数据记录、API 等 – What,Operation：系统中用户可执行的某个动作 – How,Permissions：权限，代表可向 RBAC 保护下的 Object 执行 Operation （What + How）,Role：角色，代表组织内一些职责及该职责下的用户拥有某些指定的权限,Session：会话，会话由一个用户触发，同时会话激活会话关联的一个或多个 Role,本文重点介绍被 INCITS（国际信息技术标准委员会） 采纳的标准 RBAC 模型,标准 RBAC 分为 4 个子模型：,,,一般继承：角色之间的是一个绝对偏序的继承关系（有向无环，成环的角色继承无意义），这个设计比单一的树状继承更自由，适用于角色权限有继承需求但又不是严格的上下层级关系的权限场景。,,,,RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色继承也包含了相关约束。,优点：能力最强大。,缺点：4 种模型中最复杂的模型，管理成本较高。,总体上，RBAC 被认为满足了三个重要权限原则：,对标准 RBAC 的扩展,Subject：主体，访问方，代表系统中的用户，但也可以是机器、网络等,Object：客体，被访问方，可以是系统中的某个文件、设备、数据库记录等,Operation：系统中主体对客体请求执行的功能/行为，可包括 read、write、edit、delete 等,Attributes：属性，Subject、Object、Operation 和 Environment Condition 都有属性，属性是一对键值,Policy：一系列由属性和属性值构成的规则或关系，通过该规则/关系可判断一个访问能否被允许,Environment Conditions：可被识别的环境条件，访问行为发生的环境，通常可以是时间、地点、IP、设备、操作系统、风险级别等,ABAC 是建立在 Subject 属性、Object 属性、环境属性及访问 Policy 之上的细粒度权限管控，ABAC 能做到只有符合特定属性的 Subject 在特定条件下可以对符合特定属性的 Object 执行某权限行为。,,在 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 权限管理采用 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 需要鉴权，通过三种方式进行鉴权,Table 的增删改查、字段的增删改查都可以通过 ACL 来配置,ServiceNow 对 Table、Column 的 ACL 控制大部分都是 ReadOnly,,可借鉴设计,缺点,基本功能,权限基本功能开发，解决上述问题 1-5。,字段编辑权限,当前用户对字段无编辑权限时，前端展示控件做禁用处理。,​身份代理,用户请假或者工作岗位调动，会存在把系统权限临时或永久转移给交接的人。该功能在设计上支持，后续通过版本迭代实现，MVP 版本不实现。,本方案设计上采用 RBAC+ABAC 融合方式实现权限管理，即 NGAC。兼容 RBAC、ABAC 的优点，同时在实现方案上预留扩展点，整个方案在实施过程中可以通过“大设计、小实现”的方式迭代式开放，在保持整体架构不变的情况下，可以先实现 MVP 版本，然后逐步迭代实现设计方案中的功能。,,,从用户视角划分业务应用，应用的粒度可探讨,例如，定义 ITSM 里的 ITAM 作为一个业务应用，或者定义 ITAM 里的台账(Account)作为一个业务应用；,业务应用下面可划分 1-N 个工程应用，工程应用可包括前端工程、后端微服务工程。,目的：权限项和业务应用绑定，方便用户从用户视角设置设置某个业务的角色、权限；,工程应用隶属于某一个业务应用，例如 ITAM 下有 ITAM-A，ITAM-B 等工程应用，每个工程应用管理自己的权限（菜单、按钮、HTTP 接口、RPC 接口等）,目的：工程应用和业务应用绑定，工程资源和工程应用绑定，权限项和工程资源绑定，方便开发人员按需设置访问策略。,用户定义为系统资源访问者，广义范围的用户定义，不仅包括租户内的自然人，还包括应用内子系统、第三方系统等，不同类型的用户有不同的基本属性，用户属性可扩展；,高效圈定用户,一个用户属于多个用户组，一个用户组包含多个用户，用户和用户组的关联关系可静态指定、可通过 Condition 组成的 Expression Language 表达式来动态匹配，动态匹配需监听主数据的用户属性变化，实现较复杂，可迭代实现,用户组没有实现关系继承，在具体使用中，用户组继承增加权限溯源复杂度，对高效圈定用户用处不大。,工程应用下面的资源管理，不同的用户类型可以访问不同的工程资源，,例如，自然人访问的资源就是菜单、界面、按钮已经按钮对应的网关接口；,系统访问的资源是 API 接口(HTTP、RPC)。,权限项是管理员在给角色授权时看到的权限信息，包括功能权限项和数据权限项；权限项是工程资源和主数据在权限业务域的定义，并定义权限业务的对应配置。,例如主数据 资产(Asset)有属性 型号(Model)，对应权限项配置,工程资源如果需要鉴权，要和对应的权限项进行绑定,例如应用业务 ITAM 的前端工程 athena.node 的 HTTP 接口 GetAssetList 需要鉴权，需要的权限项 ITAM 应用下的权限项配置是 asset:view_list,ACL 配置如下：,角色新增时，绑定一个用户类型，类型可以是 Global，Global 角色不区分用户类型；,角色权限设置内容：设置角色的功能权限项，数据权限项,数据字段权限项可设置允许、禁用两种策略(参考 PeopleSaas 鉴权),数据行范围权限通过用户类型属性和主数据字段属性匹配圈定范围，,例如，角色 A 的用户类型关联：Employee，对资产的访问范围是只能访问所在区域的闲置资产，表达式：,单个用户可直接关联一个用户组，用户组关联角色，从而获得权限；,单个用户可通过条件匹配到动态用户组，用户组关联角色，从而获得权限；,单个用户可直接设置角色，从而获得角色设置的权限。,用户从不同途径获取的权限会存在冲突重叠，定义优先级如下,,IT 部门引入第三方公司 A 的员工，其工作职责是在 ITAM 后台负责所在区域的资产回购确认支付主体，只能看到所在区域的状态为代确认主体的回购流程单，每一行记录只能看到资产编号和申请时间。,,itam-flow 只有主数据 Employee 的 UserName、Logo、Department、Sequence 查询权限,