访问控制、RBAC和ABAC模型

访问控制、RBAC和ABAC模型

访问控制

访问控制的目的是保护对象（数据、服务、可执行应用该程序、网络设备或其他类型的信息技术）不受未经授权的操作的影响。操作包括：发现、读取、创建、编辑、删除和执行等。

为实现访问控制， 计算机安全架构师定义了访问控制机制ACM（Access Control Mechanism）通过各种方法来前置执行应用于受保护对象的访问控制策略。ACM的定义如下： 用于接收来自主体的访问请求、决定和强制执行访问决策的组件。

ACM的实现主要涉及以下模型：

1. DAC（Discretionary Access Control）自由/自主访问控制， 保护对象的所有者拥有对象和运行程序的全部控制权，所有者包括所有者及其运行的程序。

比如 用户可以删除自己的订单，将订单信息开放出去。

1. MAC（Mandatory Access Control）强制访问控制，由管理员管理访问控制、指定访问策略，用户无法改变。

比如 安全访问等级中的密级概念，一般<秘密<机密<绝密。 对应的密级有事先确定、必须执行的安全策略，即使是数据的所有者也无法改变。

1. IBAC/ACL(Identity Based Access Control/Access Control Lists): 随着网络的发展，受保护对象可以被更多的用户所访问，IBAC基于身份的访问控制使用访问控制列表来定义对象授予访问用户的权限。ACL中保存访问主体的凭证及对应的操作。

比如 Linux文件或目录的ACL形式如下：

在IBAC模型中， 授权决策在任何特定的访问请求之前作出，并添加到ACL中。ACL中的策略是静态的，需要通过一个过程来重新评估ACL中的内容，对ACL重的对象进行移除等。否则会导致用户权限的累积。

1. RBAC（Role Based Access Control）：基于角色的访问控制，详细内容见下章。随着RBAC规范的流行，是的可以对访问控制进行集中管理，减少了对ACL的需求(ACL是作用在受保护对象)
2. ABAC （Attribute Based Access Control）:基于属性的访问控制。基于请求主体的属性，请求对象的属性，环境条件和一系列针对这些属性和条件配置策略来实现的访问控制方法。

RBAC

RBAC背景

基于角色的访问控制（RBAC）的概念始于20世纪70年代开创的多用户和多应用程序在线系统。RBAC的核心概念是权限与角色相关联，用户被分配给适当的角色。这大大简化了权限管理。角色是为组织中的各种工作职能创建的，用户根据其职责和资格分配角色。用户可以轻松地从一个角色重新分配到另一个角色。随着新的应用程序和系统的加入，可以向角色授予新的权限，并且可以根据需要撤销角色的权限。

1. 1992年15th Natinal Computer Security Conference(NCSC), David Ferralolo(NIST)，Richard Kuhn(NIST)提出Role-Baseed Accessed Controls

1. 1996年 RS Sandhu、EJ Coyne、HL Feinstein、CE Youman (1996)，基于角色的访问控制模型，IEEE Computer 29(2)，提出RBAC模型-RBAC96

1. 现行标准（2012）INCITS 359-2012，信息技术——基于角色的访问控制 （2012 年 5 月 29 日）

相关信息见

https://csrc.nist.gov/projects/role-based-access-control

https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/sandhu96.pdf

RBAC96模型

RBAC96定义了一系列4个模型：RBAC0,RBAC1,RBAC2,RBAC3。 RBAC0为最底部的基本模型， RBAC1和RBAC2分别基于RBAC0添加了特性，而RBAC3则等于RBAC1+RBAC2。四者之间的关系：

图一 RBAC96模型关系

图二 RBAC模型图

RBAC0

RBAC0基础模型核心是一个<U(User),R(role),P(permission)>的三元组。通过S（Seesion）来体现User和Role关系的一个活跃状态。

User： 用户的概念是人、应用、机器人、固定计算机，甚至计算机网络。可以先简单理解为人。

Role: 组织内的一种工作职能或职务名称

Permission: 权限是对访问系统中一个或多个对象的操作的批准,权限是一个非常灵活的概念，比如授权、访问权、特权等都是。权限的实现是具体系统相关的，可能是特定部门的文件的读取，可能是多个对象相关的，某个功能的操作许可等。权限的设计决定了系统控制的粒度、灵活性等。以数据为例，限定保护对象可以从全量数据、某条数据的粗粒度到字段的细粒度。

RBAC0中 UR和RP之间的关系都是多对多的关系，Session的概念就是当用户拥有多个角色时，体现当前激活角色的上下文含义， 不同的Session可能激活不同的某个或多个角色从而拥有角色对应的权限。

注 RBAC0中的Session概念类似于Web应用中的用户登录Session概念， 如果设计上将RBAC0-Session等同于Web 用户登录Session，则一个用户登录的Session代表着一个RBAC Session。也可以将RBAC-Session设计为用户Session下一级Session，比如一个用户登录Session中可以同时打开多个RBAC Session（不同窗口的形式），这样用户可以在一个会话登录中同时处理多个RBAC会话，而无需进行切换。

    一个RBAC Session中可以激活单个角色或多个角色。

RBAC1

RBAC1模型基于RBAC0引入角色层次结构。角色的继承代表权限的继承，权限的继承是可传递的，如角色A是B的上级角色， B是C的上级角色，则角色B集成角色C的权限，而角色A也同样集成角色C的权限。

用户会话的权限是直接分配给会话角色的权限以及分配给这些角色的下级角色的权限。

角色继承可以设计约束： 比如限制继承的范围，（类似权限加上修饰符protected,private），有些权限可以被继承，而有限不被继承。角色预先定义等级、排他性等约定，避免同级继承、互斥角色继承等。

RBAC2

RBAC2模型在RBAC0模型的基础上引入了约束的概念。约束本身就是安全管理的主要目的。如：某一个人不被允许担任两个相互分离的角色对应职责分离的原则，用户不能被他同事赋予互斥的角色， 比如审计人员和被审计人员。

约束作用于RBAC模型中的所有元素，如User、 Role、 Permission 、 UA（用户角色分配）、PA（权限角色分配）、Session。

常见的约束示例如下：

1. 同一用户不可同时分配互斥角色
2. 角色用户数量限制：比如主席只有一个， 副主席可以多个
3. 一个用户允许拥有的最多角色数量
4. 先决条件角色：角色对用户的成员资格的要求，比如主席只能从副主席中选出来
5. 层次上的约束，如初级角色的权限也必须分配给所有高级角色，或者是用户属于高级角色则也必须属于初级角色等。
6. 约束同样可以作用再回话上，比如用户能不能同时在两个角色中活动，限制用户可以激活的会话个数等。

RBAC3

RBAC1+RBAC2。

ARBAC

在RBAC模型上补充了RBAC的管理模式：

图三 ARBAC示意图

《The ARBAC97 Model for Role-Based Administration of Roles》定义以下管理模式：

1. URA97:  User和Role的分配管理
2. PRA97： Role和Permission的分配管理
3. RRA97： Role和Role之间的管理。

URA97和PRA97定义了最基本的UR分配和RP分配， RRA97根据实际实施需要定义了三种类型的角色：

1. Abilities： 功能角色， 该类型角色只能与权限或者是其他Abilities之间建立成员关系
2. Groups： 用户组角色，该类型角色只能与用户或其他用户组之间建立成员关系
3. UP-Roles： 没有限制的角色， 该角色可以和成员、权限、groups、 ablilities和其他UP-roles建立关系。

Abilities表现的是对权限的管理，如权限包的概念，某一些权限需要以集合为最小单元进行分配才能满足实际业务需求，如订单业务涉及商品查看、订单编辑、库存检查等很多相关的权限。而Groups相应表现为对用户的分类管理，比如某一类用户需要作为一个整体分配给某个角色。

Abilities和Groups本身是对权限和用户单独管理的需求，将其定义为角色的某一种类型，结合角色继承和约束统一纳入到RBAC模型中。为UP角色分配能力（abilities）等同于使UP-Roles中的角色成为Abilities中的角色的直接上级，这样UP-Roles角色中的用户就具备了Abilities角色的权限。而将一个团队分配给UP-Roles等同于将UP-Roles中的角色作为Groups中角色的直接下级，这样Groups中的用户就具备了UP-Roles的中关联的权限。

如有采购角色对应了采购人员和采购权限， 而当审计人员需要具备拥有采购权限进行信息查看是，一种直观的方式是直接将审计人员加入采购角色，另外则是定义专门的采购审计角色，只针对审计人员进行管理，不需要针对审计角色进行权限的分配，而是将采购审计角色继承为采购角色的上级集成。

ABAC

ABAC（Attribute Based Access Control）基于请求主体，请求对象的属性，环境条件和基于这些属性和条件配置的访问策略来实现的访问控制方法。

ABAC中的属性是主体、对象或则环境条件的特性，属性通常是键值对的形式存在。

主体：放出访问请求以对对象进行执行操作。

对象：可以是系统资源，如文件、记录、表、进程、网络等，可以由主体进行操作的对象，包括数据、应用程序、服务、设备和网络。

操作：根据主体请求对对象执行的函数。包括读、写、编辑、删除、复制、执行和修改等。

策略：规则或则关系的标识，基于主体、对象和环境条件的属性值决定是否允许请求的访问。

环境条件： 访问请求发生的操作或情境上下文。环境条件是可检测的环境特征，独立于主体或对象，比如时间、地点、当前威胁级别。

可以将RBAC或则ACLs认为是ABAC的特定场景：基于访问主体、目标对象的角色属性来进行访问控制。

图 企业级ABAC访问控制示意图

ABAC主要包括核心组件：

Subject Attribute Repository：主体属性仓库。

Object Attribute Repository: 对象属性仓库。

Local Access Control Policy Repository: 访问控制策略仓库。

ABAC ACM：策略执行引擎，基于主体、对象、环境条件相关的属性值，执行预先定义的访问控制策略以控制对目标对象的访问。

微服务中的访问控制和授权

微服务中，授权服务通常作为用户管理的一部分存在，提供关于用户、角色以及权限关系的管理功能。

授权（访问规则执行）通常和认证服务一起在网关节点中进行执行，在用户成功认证后以过滤器模式或AOP切面的方式实现，在请求处理之前进行访问控制校验，通过授权服务获取用户的角色信息以及角色先关的权限配置，针对当前请求进行校验或则将权限配置转换为对应的请求参数，如角色中只允许查看用户创建的表单转换为查询创建者为当前用户的表单查询参数。 具体转换依据实现如SQL、ES等。

    授权可以基于Spring Security框架的授权API和注解编程实现，但需要在请求处理方法上进行相应的配置，更常见自主实现访问控制检查，将请求及用户信息映射为权限信息与当前用户的角色权限进行比对，如将请求URL映射为某个功能来检查等。

    用户、角色、权限以及三者之间的关系可以使用本地缓存或redis缓存提升访问控制性能。使用缓存是需要仔细考虑和实现刷新机制，避免错误。

总结

ABAC 的思想基于属性的、可扩展的、可灵活定制的一种访问控制规则引擎、类似如groovy、drools、js等执行引擎可以作为规则引擎的一种实现方式。而基于关系型数据库的数据控制可以将访问策略转换为SQL的属性查询条件， 如对象A的创建者可读策略对应的检查条件可能为：where A.creatorId=Subject.id。

RBAC模型是项目实施中的访问控制主流模型，实施中通常是基于RBAC进行访问控制管理，基于用户所分配的角色，及给角色分配的权限进行访问控制，这其中可以将角色定义为关键属性输入，实际的访问控制还会在数据上定义用于数据权限校验的属性： 如数据的创建者、数据所属团队、数据所属公司等属性，并同时将这些属性规则绑定到角色上。可以将ABAC模型属性以及基于属性的控制等相关理念作为RBAC的补充，应用到特定业务数据的权限控制以满足实际业务需求。