作者|杨子国ITAM讲解：ITAM是对IT办公资产——物理资产（如笔记本电脑）和软件资产（如Office365）进行生命周期管理的系统。ITAM-Auth：ITAM系统的认证服务。ITAM-Data：ITAM系统的数据服务。SaaS：SoftwareasaService（英文：软件即服务，缩写：SaaS），一种软件交付模式。在这种交付模式下，软件无需经过传统的安装步骤，只需通过网络即可使用，软件及其相关数据集中托管在云服务上。ServiceNow：ServiceNow是一家位于加利福尼亚州圣克拉拉的美国软件公司，开发了一个云计算平台，帮助企业管理企业IT工作流。ServiceNow由FredLudy于2003年创立，在纽约证券交易所上市，是罗素1000指数和标准普尔500指数的成分股。2018年，《福布斯》杂志将其评为全球最具创新力公司第一名。背景本方案梳理了业界主流的权限模型，ITSaas的权限管理需要解决的问题，参考了公司内外的一些权限设计方案，结合RBAC和ABAC模型，提出ITAM融合模型权限管理解决方案。主流权限模型是指多系统的权限实现，总结了通用的权限理论模型。每个系统的实现都将被修改和优化。这部分介绍了业界广泛使用的权限模型。概述Subject：一个访问行为的发起者，这里为了简化理解，假设都是用户对象：访问行为的对象，比如页面，功能，数据ACL（Access-ControlList访问控制列表）Subject：subject,accessparty,可以是一个人或者一个系统,一个设备等。Action:访问的具体动作，比如Create,Read,Edit...Object:对象，被访问方，可以是一个系统中的item，一个文件等。一种比较基本的权限控制机制简单直接，在操作系统中常被应用到文件系统中。MAC（MandatoryAccessControl强制访问控制）Subject：主体，访问方，可以是个人或系统，设备等。Action：访问的具体动作，如Create，Read，Edit...Object：对象，被访问方，可以是系统中的一个入口，一个文件等。指定保密级别，访问时双向检查主客体级别是否匹配，常用于安全要求高的领域，如军事、金融、政府、计算机系统安全等。双向认证遵循授权规则，规则的存储位置和管理通常非常严格。DAC（DiscretionaryAccessControl）Subject：主体，访问方，可以是人或系统、设备等。Action：访问的具体动作，如Create、Read、Edit...Object：对象,被访问方,可以是系统中的一个入口,一个文件等Grant:子授权行为,Subject1可以将对Object执行的Action的全部或部分委托给Subject2自治访问控制简单理解就是权限Subject可以将自己拥有的权限转移给其他Subject，通常是为了解决权限分配的灵活性问题，但是在B端系统中，DAC的权限模型（比如结合MAC模型)通常不被使用，因为这种模式会导致管理员无法控制权限扩散。RBAC(RoleBasedAccessControl)RBAC认为权限的本质是WhoperformsHowoperationsonWhatUser：主体，访问者，代表系统中的一个用户，但也可以是机器，网络等-WhoObject：对象，要访问的Accessor，可以是系统中的菜单、按钮、数据记录、API等-WhatOperation：系统中用户可以执行的操作-HowPermissions：权限，表示能够执行Operation（What+How)Role：角色，代表组织中的某些职责，该职责下的用户具有一定的指定权限信息技术标准委员会采用的模型）标准的RBAC分为4个子模型：RBAC0-CoreRBACRBAC1-HierarchicalRBACGeneralinheritance:角色之间的继承关系是absolutepartialorder（有向无环，循环角色继承无意义），这种设计比单树继承更自由，适用于角色权限有继承需求但又不严格分等级的权限场景。RBAC2-ConstrainedRBACRBAC3=RBAC1+RBAC2RBAC3是RBAC1和RBAC2的集合，包括角色继承和相关约束。优点：最强大。缺点：4个模型中最复杂，管理成本高。一般而言，RBAC被认为满足三个重要的权限原则：最小权限：用户只有在触发会话操作时才获得其角色，它定义了完成该操作所需的最小权限。权限抽象：可以结合业务抽??象出具体的权限行为，比如发表评论、上传附件等，而不是简单的读、写、查。职责分离：角色本身代表职责，RBAC支持角色与角色之间的互斥机制，实现高风险动作。扩展标准RBAC单用户授权管理成本：可以跳过Role，直接授权用户批量用户授权管理成本：Group也可以分配给Role维护Role管理成本：Role中的用户可以结合权限切割（代表该用户只拥有该Role的部分权限）、可复制Role等其他权限模型：结合DAC、MAC、ABAC（AttributeBasedAccessControl属性访问控制）Subject：主体，accessor，代表用户在系统，但也可以是机器、网络等。对象：对象，被访问方，可以是系统中的文件、设备、数据库记录等。要执行的可以包括read、write、edit、delete等。Attributes：attributes，Subject，Object，Operation，EnvironmentCondition都有属性，是一对key-valuesPolicy：一系列的attributes和attributevalues规则或关系，通过这些规则或关系可以确定是否允许访问EnvironmentConditions：可识别的环境条件，访问行为发生的环境，通常是时间，位置，IP，设备，操作系统，风险级别等。ABAC是基于Subject属性、Object属性、环境属性和访问策略的细粒度权限控制。ABAC可以保证只有满足特定属性的Subject才能在一定条件下对满足特定属性的Object进行一定的权限行为。下一代权限模型探索——NGAC除了主流的DAC、MAC、RBAC、ABAC权限模型外，还有大量的其他权限模型（如LBAC、GBAC、CBAC、OrBAC、RAdAC……），但也有目前还没有权限模型被业界广泛采用。学术界已经有一些关于下一代权限模型的研究成果。NIST（美国国家标准技术研究院）于2019年提出NGAC（NextGenerationAccessControl），提出这是一种不同于现有权限模型的全新模型，能够广泛兼容当前的数字生态系统。.中的各种权限场景。从下图看，更像是RBAC和ABAC思想的结合。结合点是用户角色关系不再是手动分配，而是根据Policy自动分配。当用户以角色身份进行权限行为时，会再次经过ABAC。规则判断。典型应用场景：Alice只能在工作日的10:00-18:00在伦敦办公室网络下以财务角色的身份访问和修改订单系统中的数据（基于角色的权限策略））结论没有权限模型是完美的，重要的是如何结合业务，考虑安全性、可扩展性、灵活性、易用性、管理成本、合规性等因素并达到平衡，这个过程往往是最复杂的。方案参考带着以上目标，我们主要看一下ServiceNow的权限实现方案，从基本思路、参考设计、方案不足三个方面做如下分析。ServiceNow基本思路ServiceNow权限管理采用RBAC1+ACL方式，ACL控制ObjectType的Operation访问，通过Role、Condition、Script进行动态验证。权限模型用户和用户组用户基本信息管理，部门，一个用户可以加入多个用户组，一个用户可以通过设置代理行使用户的系统权限；一个用户组包含多个用户，用户组可以继承，子用户组继承父用户组的权限。角色的使用是被动的。Modules配置时可以关联角色，UIActions可以关联角色，ACL配置可以关联角色。角色之间存在继承关系，子角色继承父角色的权限。应用程序和资源ServiceNow在内部区分不同的应用程序。不同的应用程序具有不同的资源、角色和权限设置。应用程序（Application）被抽象成一组可安装的组件资源。资源包括Table（数据表）、Dictionary（数据列）、API接口（REST_Endpoint）、Menu（菜单）、Module（页面组件）、UIPage（独立页面）、UIAction（页面按钮）等，其中菜单、页面组件、页面按钮使用RBAC权限模式；数据表、数据列、API接口、独立页面使用ACL认证。特别是ACL认证中Table的同事配置了ApplicationAccess，即每个表根据应用设置操作权限。ACL认证的Object和Operation类型如下。组件（Module）有多种访问方式，主要有ListRecord和URL访问，如下图所示。ListRecord是访问一个表的记录，URL访问是通过URL-Get参数访问数据。模块认证是通过配置关联的Role来实现的。Module有13种LinkType（访问方法）。ListRecord方法可以通过Filter指定默认的过滤查询条件，但不作为数据行范围权限。进入具体页面后，可以清除过滤条件。RBAC身份验证要求身份验证资源在配置期间与所需的角色相关联。角色的使用是被动的。Modules配置时可以关联角色，UIActions可以关联角色，ACL配置可以关联角色。用户或用户组在配置过程中选择关联的角色。ACL认证ACL认证是指对Object的操作需要认证。有三种验证方法。RoleConditionScriptTable的增删改查，字段的增删改查可以通过ACL进行配置。ServiceNow中Table和Column的ACL控制大多为ReadOnly，可以借鉴设计资源的细粒度管理，因此权限的控制粒度和灵活性好；不同的认证场景使用不同的认证模型；UI层资源和权限的数据链接，每条信息的链接跳转设计都一丝不苟；缺点用户与用户组的关联不灵活，如根据用户属性划定一组用户为一个组；权限配置比较分散，使用权限的地方分散在各个资源管理入口；ACLCondition配置功能简单，配置门槛高；不考虑开放融合场景的认证；没有数据范围验证。问题权限管理的本质是控制用户访问系统资源的权限。需要先定义系统中的用户、资源和权限；授权;数据鉴权，包括数据行鉴权、列鉴权、高效授权和数据权限鉴权；良好的业务扩展性；权限管理和权限使用的前后端模块不一致，业务定义和项目定义不一致，比如前端是一个整体服务，后台分成多个微服务，怎么办在权限管理、功能认证、数据认证方面进行划分和控制；权限所需的特征功能：角色互斥、身份代理、权限前置依赖、权限审批流程、角色授权设置有效期、权限策略优先级。目标技术目标工作效率：用户多快获得应有的权限；认证效率：高性能保证认证不影响正常的业务逻辑处理；安全性：保证功能和数据不会因为权限系统的误判而泄露；expansion可扩展性：提供系统多个节点的可扩展性，包括但不限于用户类型扩展、用户属性扩展、资源类型扩展、资源属性扩展。功能目标基本功能权限基本功能开发，解决以上问题1-5。字段编辑权限当当前用户对该字段没有编辑权限时，前端显示控件将被禁用。如果身份代理用户请假或调动工作，系统权限将临时或永久转移给交接人。该功能是设计支持的，后续会通过版本迭代实现，MVP版本暂不实现。设计方案本方案设计采用RBAC+ABAC融合的方式实现权限管理，即NGAC。兼容RBAC和ABAC的优点，同时在实施方案中预留扩展点，整个方案在实施过程中可以以“大设计，小实施”的方式迭代开启。在保持整体架构不变的情况下，可以先实现MVP版本，然后逐步迭代实现设计中的功能。专用词User：用户，可以是租户中的自然人用户，也可以是第三方系统，也可以是应用中的子系统。各类用户拥有基础属性，可根据租户维度进行自定义；UserGroup：在管理平台上指定一组用户，用于授予这些用户访问权限；Role：角色，角色用于配置权限策略，角色与用户类型关联，角色策略配置角色拥有的功能权限、数据列权限、数据行范围权限；Resource：权限资源项，比如flow（进程），Resource有层级关系，对应多个Action，非叶子节点只有Read，叶子节点有1-N个Action；Action：动作，如：管理，查看详情，ModifyCondition：条件，可以携带Subject和Object附带的属性，也可以是业务系统传入的属性（可以与Subject和Object无关），使用表达式语言实现基于上下文的动态计算。ExpressionLanguage：表达语言，ALC（AccessControl）：访问控制，本文指的是工程资源访问策略权限模型Applicationdivision从用户的角度划分业务应用，可以讨论应用的粒度。例如，将ITSM中的ITAM定义为业务应用，或者将ITAM中的账户（Account）定义为业务应用；业务应用可以分为1-N工程应用，工程应用可以包括前端工程和后端微服务工程。用途：权限项与业务应用绑定，使用户可以从用户的角度设置某个业务的角色和权限；工程应用属于某个业务应用，例如ITAM下有ITAM-A、ITAM-B等工程应用，每个工程应用管理自己的权限（菜单、按钮、HTTP接口、RPC接口等）用途：工程应用与业务应用绑定，工程资源与工程应用绑定，权限项与工程资源绑定，方便开发者设置访问策略。用户和用户组被定义为系统资源访问者。广义的用户定义不仅包括租户内部的自然人，还包括应用内部的子系统、第三方系统等，不同类型的用户具有不同的基本属性，用户属性可以进行扩展；有效地划定用户。一个用户属于多个用户组，一个用户组包含多个用户。用户和用户组之间的关系可以静态指定，也可以通过Conditions组成的ExpressionLanguage表达式动态匹配。动态匹配需要监控主数据用户属性变化，实现比较复杂，用户组的迭代实现没有实现关系继承。在具体使用中，用户组的继承增加了权限溯源的复杂度，对于用户的高效划定作用不是很大。资源工程应用以下资源管理。不同的用户类型可以访问不同的工程资源。例如，自然人访问的资源是菜单、界面、按钮、按钮对应的网关接口等；系统访问的资源是API接口（HTTP、RPC）。权限项权限项是管理员在授权角色时看到的权限信息，包括功能权限项和数据权限项；权限项是权限业务域中工程资源和主数据的定义，定义了权限业务的相应配置。例如主数据资产（Asset）有一个属性模型（Model），对应权限项配置-name：物理资产key：资产属性：-name：资产模型key：“model”deny_show：“-888888”value_type:"int"resource如果访问控制（ACL）项目资源需要认证，则必须绑定相应的权限项。例如应用业务ITAM的前端项目athena.node的HTTP接口GetAssetList需要认证，在ITAM应用下的权限项下配置需要的权限项。是asset:view_list，ACL配置如下：接口资源表格式：{业务应用}:{工程应用}:{接口}功能权限项格式：{业务应用}:{resource}:{action}CheckPermission:trueInterfaceName:itam:node:GetAssetListRuleList:-Rule:-AuthKey:itam:asset:view_list添加新角色和权限设置角色时，绑定一个用户类型，可以是Global，Global角色不区分用户类型；角色权限设置内容：设置角色功能权限项，数据权限项数据字段权限项可以设置允许和禁用两种策略（参考PeopleSaas认证）数据行范围权限匹配用户类型属性和主数据字段属性划定范围，例如角色A的用户类型AAssociation:Employee，访问资产的范围是只访问区域内闲置资产，表达式：employee.location==asset.location&&asset.status=='idle'授权单个用户直接关联一个用户组，用户组关联Roles获取权限；单个用户可以通过条件匹配到动态用户组，用户组与角色关联获得权限；个人用户可以直接设置角色，获取角色设置的权限。权限优先级用户从不同渠道获得的权限会发生冲突和重叠，定义优先级如下场景流程场景一：第三方用户资产回购-确认支付主体IT部门介绍第三方公司员工A、其工作职责在ITAM后台负责区域内的资产回购确认支付主体，只能看到状态为区域内确认主体的回购流程单，只有资产编号和申请时间可以在每一行记录中看到。场景二：工程应用itam-flow获取主数据Employee的部分权限。itam-flow只有主数据Employee的UserName、Logo、Department、Sequence查询权限。itam-flow被注册为内部系统的特权用户；可以查询itam-data服务的Employee查询接口，数据列只有UserName、Logo、Department、Sequence；itam-data的Employee查询接口，识别itam-flow系统，根据策略查询itam-flow的数据权限，根据权限配置数据返回。物理结构
