一种访问控制方法、装置、电子设备及存储介质与流程

1.本技术实施例涉及工业控制技术领域，尤其涉及一种访问控制方法、装置、电子设备及存储介质。


背景技术：

2.作为保障信息安全的关键技术之一的访问控制技术，自从上世纪面世以来，受到了各路学者的青睐。访问控制技术的主要目的是避免客体受到未授权主体的非法访问，客体往往指代具有价值的数据、资源、服务、技术等，并为某些特定的机构或者人员所享有，拥有客体资源的机构或人员指定了一系列策略来限制某些未授权主体的访问。目前，访问控制技术与其他领域的结合为正在成为新的研究热点。
3.当前，数据起源的研究主要集中在建立起源模型，存储和查询起源数据方面，并已经建立了相当完善的体系，但是在访问控制中利用数据的起源的相关研究还比较少，且基本的模型(例如pbac等)都只是提供了需要与其他访问控制方式结合的基本模型，往往模型里的相关概念过于抽象，难以和现实结合；并且在系统中使用单一的基于起源数据的访问控制模型往往是不够的，因此，利用起源数据的特点将起源数据和传统的访问控制模型结合起来往往能实现更细粒度的访问控制模型，这两者的结合也将为以后的访问控制研究建立新的思路。
4.pbac相比较于传统的访问控制模型在访问控制的精细度上无疑有了很大程度的提升，可以根据起源数据实现访问控制，动态权限划分，基于工作流的控制，版本控制等。但是pbac也存在着一个很大的问题，就是验证阶段会经常性的对起源图进行遍历，导致验证流程变的耗时费力，还有在角色验证阶段很难处理，例如一个系统中单单使用pbac，那么对用户的验证就几乎是不可能的。
5.传统的pbac模型的访问控制过程包括用户授权和行为验证，用户授权明确了该用户是否具有提出该请求的资格，行为验证明确了该请求是否可以在申请访问的资源上操作。但是这种访问控制方式在进行用户验证的时候需要有系统提供面向用户的访问策略，这对于系统的设计无疑是十分不方便的，因为不可能在预先定义所有用户的访问控制策略，这就需要在用户的不断访问中通过提取他们的起源数据来完善相关的策略，这种用户授权的方式在实际的应用中，尤其是在访问控制查询的时候需要不断地从起源数据中获得访问控制策略，这样会对整个访问控制形成负担。


技术实现要素：

6.本技术提供一种访问控制方法、装置、电子设备及存储介质，可以进一步提升访问控制的精细度，为访问控制提供了更加精细化的粒度控制。
7.第一方面，本技术实施例提供了一种访问控制方法，所述方法包括：
8.将用户的访问请求输入至tir-pbac模型中；其中，所述访问请求至少包括：代理用户、动作和对象；
9.通过所述tir-pbac模型对所述访问控制请求进行解析，得到所述访问请求对应的访问控制结果；
10.通过所述tir-pbac模型输出所述访问控制结果。
11.第二方面，本技术实施例还提供了一种访问控制装置，所述装置包括：输入模块、解析模块和输出模块；其中，
12.所述输入模块，用于将用户的访问请求输入至tir-pbac模型中；其中，所述访问请求至少包括：代理用户、动作和对象；
13.所述解析模块，用于通过所述tir-pbac模型对所述访问控制请求进行解析，得到所述访问请求对应的访问控制结果；
14.所述输出模块，用于通过所述tir-pbac模型输出所述访问控制结果。
15.第三方面，本技术实施例提供了一种电子设备，包括：
16.一个或多个处理器；
17.存储器，用于存储一个或多个程序，
18.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本技术任意实施例所述的访问控制方法。
19.第四方面，本技术实施例提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现本技术任意实施例所述的访问控制方法。
20.本技术实施例提出了一种访问控制方法、装置、电子设备及存储介质，先将用户的访问请求输入至tir-pbac模型中；其中，该访问请求包括：代理用户、动作和对象；然后通过tir-pbac模型对访问控制请求进行解析，得到访问请求对应的访问控制结果；再通过tir-pbac模型输出访问控制结果。也就是说，在本技术的技术方案中，提出了一种新的访问控制模型tir-pbac，通过引入角色与权限的概念来预先定义一类用户的权限，这样在进行访问时，角色的授权将变得非常简单，只需要查询用户的角色，然后判断访问请求中的权限是否为角色所拥有即可。而在现有技术中，传统的pbac模型的访问控制方式在进行用户验证时需要系统提供面向用户的访问策略，这就需要在用户的不断访问中通过提取他们的起源数据来完善相关的策略，这种用户授权的方式在实际的应用中，尤其是在访问控制查询时需要不断地从起源数据中获得访问控制策略，这样会对整个访问控制形成负担。因此，和现有技术相比，本技术实施例提出的访问控制方法、装置、电子设备及存储介质，可以进一步提升访问控制的精细度，为访问控制提供了更加精细化的粒度控制；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
附图说明
21.图1为本技术实施例提供的访问控制方法的第一流程示意图；
22.图2为现有技术提供的pbac模型的结构示意图；
23.图3为本技术实施例提供的opm 模型的结构示意图；
24.图4为本技术实施例提供的tir-pbac模型的结构示意图；
25.图5为本技术实施例提供的访问控制方法的第二流程示意图；
26.图6为本技术实施例提供的访问控制方法的第三流程示意图；
27.图7为本技术实施例提供的访问控制装置的结构示意图；
28.图8为本技术实施例提供的电子设备的结构示意图。
具体实施方式
29.下面结合附图和实施例对本技术作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本技术，而非对本技术的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本技术相关的部分而非全部结构。
30.实施例一
31.图1为本技术实施例提供的访问控制方法的第一流程示意图，该方法可以由访问控制装置或者电子设备来执行，该装置或者电子设备可以由软件和/或硬件的方式实现，该装置或者电子设备可以集成在任何具有网络通信功能的智能设备中。如图1所示，访问控制方法可以包括以下步骤：
32.s101、将用户的访问请求输入至tir-pbac模型中；其中，访问请求至少包括：代理用户、动作和对象。
33.在访问控制中利用起源数据，本技术提出了新的访问控制模型tir-pbac(transaction and inheritance of role-pbac)，具体解决的问题包括：针对角色访问控制中存在的当角色过多时，角色层次模糊，不易管理，容易产生角色爆炸的问题，本技术在rbac(role-based access control)的基础上提出了一种基于事务和继承的角色访问控制模型(transaction and inheritance
–
rbac，ti-rbac)，将面向对象中继承的思想利用在了角色关系的继承上，将事务抽象为事务类型与权限对应起来。将继承中的公有性继承，保护性继承以及私有性继承方式利用在了角色继承和权限中，使角色的层次更加的分明，将角色的继承机制更加的多样化和简单化；针对传统的opm(open provenance model)模型中无法收集环境信息的问题，本技术提出了opm (open provenance model )模型，增加了属性节点和依赖关系，为tir-pbac模型收集环境信息提供了基础模型；针对pbac模型中角色授权阶段过于复杂的问题上，结合了ti-rbac模型，增加了角色与角色的层次关系，角色与权限的对应关系以及访问发生时的环境信息，提出了tir-pbac模型的体系架构和访问控制算法。
34.s102、通过tir-pbac模型对访问控制请求进行解析，得到访问请求对应的访问控制结果。
35.s103、通过tir-pbac模型输出访问控制结果。
36.本技术实施例中的访问控制是指通过设定一系列的策略达到三个目的：防止恶意的主体访问到受保护的资源；允许授权的用户访问到受保护的资源；防止未被授权的合法的用户访问到受保护的资源。访问控制的流程为：当用户、应用程序、服务或者进程对有价值的客体例如数据、资源、服务、技术等进行访问时，需要客体所有者所指定的规则对用户的身份合法性进行验证，如果验证失败，则拒绝此次访问，如果验证通过，则按照最小授权原则对主体进行授权，保证主体访问到的客体都是在其权限范围内的。
37.本技术实施例中的起源数据是用来描述最终产品生产过程中的任何信息，可以是从数字数据到物理信息对象的任何信息。数据的起源也称为数据的起源、数据的系谱、数据的血统。通过起源数据，人们可以了解到数据在哪里发生了变化，发生了什么变化，发生变化的时间，促使变化发生的因素，谁导致了变化的发生，为什么发生变化，变化是怎么发生
的。
38.本技术实施例中的opm模型用于解决不同系统之间互相兼容并交换起源信息的问题，因为其支持对任何事物的起源的数据化表达并且规定具体实现的技术，因而很多用到起源信息的领域都将opm作为一个基础模型。opm能够描述导致事物发生的原因，即某一个事物如何依赖于其他的事物并导致特定的状态。
39.本技术实施例中的rbac模型将角色的概念引入访问控制中，将用户与权限解耦合，利用角色将用户与角色，角色与权限分别对应起来，其访问控制流程为对一个用户的角色进行判定，然后对需要访问的数据获取其权限，判断用户的角色是否拥有此权限，如果有则同意该访问，如果没有则拒绝该次访问。
40.本技术实施例中的pbac模型主要解决了如何在访问控制时使用起源数据的问题，该模型认为验证一个访问请求能不能被授权需要两个阶段，一个是用户授权阶段，另一个是行为认证阶段。在用户授权阶段会针对用户的历史判断是否具备访客体的权力，而在行为认证阶段会判断是该行为是否符合既定的规则，必须同时通过用户授权和行为认证，相关的访问请求才会被接受。
41.图2为现有技术提供的pbac模型的结构示意图。如图2所示，pbac模型主要包括代理用户(acting users，简称au)、动作(action instances，简称a)，对象(objects，简称o)、起源数据(provenance data，简称pd)、依赖列表(dependency lists，简称dl)、策略(policies，简称p)，访问评估函数(access evaluation，简称ae)组成。
42.代理用户(au)代表了发起访问对象请求的用户，具体来说，起源数据捕获的是来自于访问主体的请求而不是用户，但是一个用户往往会对应很多访问主体，在这里模型假设用户与主体之间有一定的依赖关系，可以从用户映射到主体上，因此为了方便和易读性，在这里拟用用户代指主体。
43.动作(a)代表了用户发起的访问请求的实例，一般将访问请求实例抽象化为动作类型(action type，简称at)。
44.对象(o)代表了将要被用户访问到的资源。
45.起源数据(pd)，又称世系数据，是由基础的起源数据与用户自定义的起源数据组成；其中，基础的起源数据是由系统中的事务数据转化的，在pbac中，事务是由两个实体与一个因果关系组成的，两个实体分别是用户和动作，因果关系是opm中的直接依赖关系组成。
46.依赖列表(dl)是一个依赖名称对应依赖关系路径的二元组。
47.策略(p)包括用户身份验证与行为规则验证，其中，用户身份验证是基于用户之前的行为记录，而行为验证则是根据对象之间的依赖关系决定的。
48.访问评估(ae)则返回一个根据用户身份验证与行为验证的合取值，即布尔值，判断该访问是否被允许。
49.pbac模型的访问控制流程：pbac模型认为验证一个访问请求能不能被授权需要两个阶段，一个是用户授权阶段，另一个是行为认证阶段，在用户授权阶段会针对用户的历史判断是否具备访客体的权力，而在行为认证阶段会判断是该行为是否符合既定的规则，必须同时通过用户授权和行为认证，相关的访问请求才会被接受。
50.pbac模型相比较于传统的访问控制模型在访问控制的精细度上无疑有了很大程
度的提升，可以根据起源数据实现访问控制，动态权限划分，基于工作流的控制，版本控制等。但是pbac模型也存在着一个很麻烦的问题，就是验证阶段会经常性的对起源图进行遍历，导致验证流程变的耗时费力，还有就是在角色验证阶段很难处理，例如一个系统中单单使用pbac模型，那么对用户的验证就几乎是不可能的，因为无法确定一个用户能不能使用某一个权限。
51.针对这一问题，本技术通过引入角色与权限的概念来预先定义一类用户的权限，这样在进行访问的时候，角色的授权将变得非常简单，只需要查询用户的角色，然后判断访问请求中的权限是否为角色所拥有即可。在随后的授权阶段，本技术增加了访问操作的具体环境信息，具体为：在访问请求中找到对应的操作类型，根据操作类型解析出相关的访问控制策略，根据访问策略提取出被访问资源的名称和依赖名称，在依赖列表中根据依赖名称找到对应的依赖路径，随后根据资源的名称和依赖路径找到的相关的节点，读取节点的属性信息，完成相关的访问评估得到答案。例如，在论坛系统中，用户a可以在帖子下面发表评论，但是如果用户a被管理员禁言一个月，那么a在这一个月内都不可以发表任何评论，在访问控制时，a的角色是具有评论功能的，但是在评论帖子c的时候，会根据c找到用户a评论的操作，然后根据这个操作实例解析出“评论”这个操作类型，再找到评论的用户不能是禁言状态的策略，根据该策略找到与c有关的依赖名称，“禁言”，以及相关的依赖路径和当时的环境信息，从c出发经过禁言的依赖路径找到a，判断出用户a出现在禁言这条依赖路径中，这样就得出了a在此时不能对帖子发表评论的结论，完成了此次访问控制。由此可以看出，该模型不仅能够通过用户的角色来快速的完成用户授权，也能够根绝当时的环境信息对访问操作做出更为准确的判断。
52.图3为本技术实施例提供的opm 模型的结构示意图。opm 模型是opm模型的一个拓展，通过增加属性节点以及属性依赖关系以便于更加完整的描述数据是如何变化的。如图3所示，节点一共有四种，分别是实体(artifact)，进程(process)，代理(agent)，属性(attribute)；其中，c、g、u、ha均为依赖关系。进一步地，c表示控制关系；g表示生成关系；u表示使用关系，ha表示具备属性。在opm 模型中，针对细粒度访问控制的需求，即需要捕获更为详细的起源数据，因此添加了属性节点以及具有属性(has attribute of)的依赖关系。opm 模型将含有类型和值的属性节点引入到opm模型中去，例如一个进程具有的属性为{time stamp：3/20/2020；system condition：linux；location：sydney}，通过属性就可以得知进程发生时的上下文信息，丰富起源信息，其中属性又分为三类，分别是与代理相关的属性，与进程相关的属性和与实体相关的属性。
53.1)与实体相关的属性(artifact-attribute)：实体是包括输入信息，输出信息以及源数据的对象。与它们相关的属性可以包括尺寸大小，预先定义并可以实施在该物体上的权限等。
54.2)与进程相关的属性(process-attribute)：进程是连续的施展在物体上并导致其状态发生改变的一个动作或一系列动作。与它们相关的属性一般可以是地点、时间、环境信息等。
55.3)与代理相关的属性(agent-attribute)：代理能够触发或执行进程，与它们相关的属性一般包括id，已经激活的角色等。
56.opm 模型是针对访问控制相关问题所特定产生的一个数据起源模型，在其中抛弃
了prov技术标准中的很多间接依赖关系，只把最基本的4个依赖关系引入进来，既保证了信息收集的丰富性也最大程度的简化了模型，能够很好的利用在访问控制中。
57.图4为本技术实施例提供的tir-pbac模型的结构示意图。如图4所示，该模型中的起源数据主要由两部分组成，一部分是环境因素组成的起源数据，其中环境因素主要是指发生访问时的具体环境条件，包括用户的基本信息，例如名称、年龄、性别等，操作的基本信息包括时间、地点等以及与被操作资源的相关的信息，包括物品的尺寸，是否已经被点亮过等，这三种环境条件往往也会对访问形成制约；另一部分是基础的起源数据，主要是指系统中存储的事务数据，这些事务数据可以根据opm 模型中的因果关系转变而成起源数据，并为以后的访问控制提供相关的参考，例如，系统中的事务数据如下：《u1,replace,o1,o2》可以转变成如下的起源数据：《replace,u1,wascontrolledby》，《o2,replace,wascontrolledby》以及《u1,o1,used》，上面的事务数据可以表示为用户u1将o1替换为o2，后面分别用了三种依赖关系来描述其中的行为，以上描述了事务数据是如何转变成起源数据的，至于环境的起源数据可以描述为三种类别的数据：《u1,ha,attributei》，《o1,ha,attribute
o1
》，《o2,ha,attribute
o2
》，其中，ha指代has attribute of依赖关系，这样在追溯起源数据时就能够得到更加详实的数据，便于对数据的各个版本进行更准确的使用。
58.该模型中的环境信息(environment information)，可以理解为在opm 模型中的属性(attribute)节点，在opm 中定义了三种不同的属性，分别是与实体相关的属性，与代理相关的属性，以及与进程相关的属性，在这里将这三种属性具体的描述为与用户相关的信息，与操作相关的信息以及与对象相关的信息。a)与用户相关的信息(environment information of user，简称eiu)：指代了用户的属性，包括用户的基本信息，例如名称、年龄、性别，以及最常用的用户的id。b)与进程相关的信息(environment information of process，简称eip)：指代了进程的属性，包括进程发生时的时间，地点，操作系统等信息；c)与资源相关的信息(environment information of resource，简称eir)指代了资源的属性，包括资源的固有属性，访问系统时需要访问的资源往往都在服务器中，那么文件的位置就是很好的描述文件固有属性的一个参数。
59.依赖列表(dependency list)：因为依赖关系往往是由一系列权限所形成的，如果系统预定义的依赖列表与用户自定义的依赖列表出现了误差的话，那么就需要额外的策略来解决这种冲突。在这里可以把依赖列表想象成一个二元组，组成的元素分别是依赖名称和依赖路径，由于基本的依赖关系已经定义完毕，那么两个对象之间的依赖关系就可以通过一连串的基本依赖关系来描述，这也就是依赖路径，可以称之为依赖名称，此外可以将依赖名称利用到依赖路径中去，这样就又生成了一个依赖名称，这样就形成了完整的依赖列表，通过依赖列表我们就可以查询到相关的依赖路径，然后通过依赖路径和对象的名称在起源图中寻找到需要的信息。
60.策略(policy)：在进行访问控制时，一共有两个个环节，分别是用户授权和行为认证，在这里可以举一个简单的例子方便理解，用户a想给b的帖子进行点赞，那么首先认为用户a是具有点赞这种权限的角色，然后根据该帖子的点赞用户里查询a是否已经点赞过，最后认同或者否认这种行为，这里面就包含了行为认证。
61.请求(request(u，a，o)：这个请求其实可以理解为未发生的事务，因为该请求一旦发生那么就可以当作是事务数据写入数据库中，如果没有同意则进行回滚操作。
62.本技术实施例提出的访问控制方法，先将用户的访问请求输入至tir-pbac模型中；其中，该访问请求包括：代理用户、动作和对象；然后通过tir-pbac模型对访问控制请求进行解析，得到访问请求对应的访问控制结果；再通过tir-pbac模型输出访问控制结果。也就是说，在本技术的技术方案中，提出了一种新的访问控制模型tir-pbac，通过引入角色与权限的概念来预先定义一类用户的权限，这样在进行访问时，角色的授权将变得非常简单，只需要查询用户的角色，然后判断访问请求中的权限是否为角色所拥有即可。而在现有技术中，传统的pbac模型的访问控制方式在进行用户验证时需要系统提供面向用户的访问策略，这就需要在用户的不断访问中通过提取他们的起源数据来完善相关的策略，这种用户授权的方式在实际的应用中，尤其是在访问控制查询时需要不断地从起源数据中获得访问控制策略，这样会对整个访问控制形成负担。因此，和现有技术相比，本技术实施例提出的访问控制方法，可以进一步提升访问控制的精细度，为访问控制提供了更加精细化的粒度控制；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
63.实施例二
64.图5为本技术实施例提供的访问控制方法的第二流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图5所示，访问控制方法可以包括以下步骤：
65.s501、将用户的访问请求输入至tir-pbac模型中；其中，访问请求至少包括：代理用户、动作和对象。
66.s502、基于访问控制请求分别确定用户在授权阶段的结果和用户在规则收集阶段的结果。
67.在本步骤中，电子设备可以在确定用户在授权阶段的结果时，可以先通过代理用户获取用户的角色；然后根据用户的角色利用tir-pbac模型中的访问控制算法确定用户在授权阶段的结果。在确定用户在规则收集阶段的结果时，可以先通过动作获取用户的行为类型；然后根据行为类型和预先确定的行为类型与访问策略的映射关系，获取用户的访问策略；再根据访问策略获取用户在规则收集阶段的结果。
68.s503、基于访问控制请求和用户在规则收集阶段的结果，确定用户在行为验证阶段的结果。
69.在本步骤中，电子设备可以先在用户在规则收集阶段的结果中提取出一个规则作为当前规则；其中，用户在规则收集阶段的结构包括至少一个规则；然后在当前规则下确定访问请求所关联的节点；若访问请求所关联的节点的环境信息满足预先设置的操作要求，则将用户在当前规则下的验证结果确定为通过验证；重复执行上述操作，直到确定出用户在各个规则下的验证结果。
70.s504、根据用户在授权阶段的结果和用户在行为验证阶段的结果，确定访问请求对应的访问控制结果。
71.在本步骤中，若用户在授权阶段的结果为授权通过并且用户在行为验证阶段的结果为验证通过，则确定访问请求对应的访问控制结果为允许访问；若用户在授权阶段的结果为授权不通过，或者，用户在行为验证阶段的结果为验证不通过，则确定访问请求对应的访问控制结果为不允许访问。
72.s505、通过tir-pbac模型输出访问控制结果。
73.在tir-pbac模型中，u(users，用户)代指访问的主体，既可以是人也可以是代理程序。r(roles，角色)简单来说就是组织内的职务或职能，角色是有限的权限集中的子集，将其抽象概括为角色。p(permissions，权限)是对系统中一个或者多个资源的特定访问方式的批准。权限也可以用授权、访问权力、特权等词语表。访问粒度的粗细往往就体现在权限的划分上，因为，如果一个系统的权限种类很少，甚至时一个权限就能访问系统中的所有资源，那么无疑这个访问控制过于粗糙，不能根据特定的人或者是特定的情况而改变。
74.访问请求，表示了访问请求中的用户(u)，行为实例(action instance)以及访问的资源对象(object)，用户u已经给出过定义，下面分别介绍行为实例ai与o。行为实例(ai)：行为实例描述了访问请求中用户将要对访问的数据做出的具体行为；行为类型(at)：行为类型可以通过具体的行为实例抽象而来，例如用户a提交(submit a)了帖子(post submit)，这里的submit a就是一个具体的行为实例，而submit而表示这种行为的类型。假定系统可以从给定的策略中找到与submit相关的策略。资源对象：代表了要访问的资源种类，在具体的应用场景中，会针对不同行为类型而对资源标注不同的下标，在这里可以理解为资源的角色(object role)。
75.策略集(policy)：针对行为所制定的访问策略，例如帖子不可以被禁言的人评论，这种策略是系统预定义的，并可以根据行为类型at获得。
76.属性集(attribute)：属性分为三种，分别是用户具有的属性，操作具有的属性以及资源具有的属性，三种属性在访问请求的时候会存储相关的信息，并且在访问控制判断的时候提供相关的信息，在这里把属性信息主要加到行为上，因为在访问请求发生时，将用户的信息，行为的信息以及资源的信息保存到行为上可以更加方面的存储以及查询。
77.起源数据(provenance data)：pd＝pdb∪pde；其中，pdb指代请求被执行以后的系统事务转换而来的事务数据，pde指代在具体的操作过程中的环境因素，例如，时间、人员、地点、系统环境等相关的信息，它们也会以事务数据的形式记录下来，被转换成行为(action)所具有的环境信息。
78.起源图(provenance graph)：起源图是由一个三元组构成的，描述了数据的依赖关系的有向无环图，具体可以描述为《ve,ee,de》，其中下标e表明了该起源图是一个pbac基础上扩展的起源图。在上述描述中，ve定义了起源图中的定点的种类，包括用户，行为，资源以及属性节点；de定义了起源图中的基本的依赖关系；ee定义了起源图中的边的类型。
79.本技术实施例提出的访问控制方法，先将用户的访问请求输入至tir-pbac模型中；其中，该访问请求包括：代理用户、动作和对象；然后通过tir-pbac模型对访问控制请求进行解析，得到访问请求对应的访问控制结果；再通过tir-pbac模型输出访问控制结果。也就是说，在本技术的技术方案中，提出了一种新的访问控制模型tir-pbac，通过引入角色与权限的概念来预先定义一类用户的权限，这样在进行访问时，角色的授权将变得非常简单，只需要查询用户的角色，然后判断访问请求中的权限是否为角色所拥有即可。而在现有技术中，传统的pbac模型的访问控制方式在进行用户验证时需要系统提供面向用户的访问策略，这就需要在用户的不断访问中通过提取他们的起源数据来完善相关的策略，这种用户授权的方式在实际的应用中，尤其是在访问控制查询时需要不断地从起源数据中获得访问控制策略，这样会对整个访问控制形成负担。因此，和现有技术相比，本技术实施例提出的访问控制方法，可以进一步提升访问控制的精细度，为访问控制提供了更加精细化的粒度
控制；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
80.实施例三
81.图6为本技术实施例提供的访问控制方法的第三流程示意图。基于上述技术方案进一步优化与扩展，并可以与上述各个可选实施方式进行结合。如图6所示，访问控制方法可以包括以下步骤：
82.s601、将用户的访问请求输入至tir-pbac模型中；其中，访问请求至少包括：代理用户、动作和对象。
83.s602、基于访问控制请求分别确定用户在授权阶段的结果和用户在规则收集阶段的结果。
84.s603、基于访问控制请求和用户在规则收集阶段的结果，确定用户在行为验证阶段的结果。
85.s604、判断用户在授权阶段的结果是否为授权通过并且用户在行为验证阶段的结果是否为验证通过，若是，执行s605；否则，执行s606。
86.s605、确定访问请求对应的访问控制结果为允许访问。
87.在本步骤中，若用户在授权阶段的结果为授权通过并且用户在行为验证阶段的结果为验证通过，则确定访问请求对应的访问控制结果为允许访问。
88.s606、确定访问请求对应的访问控制结果为不允许访问。
89.在本步骤中，若用户在授权阶段的结果为授权不通过，或者，用户在行为验证阶段的结果为验证不通过，则确定访问请求对应的访问控制结果为不允许访问。
90.本技术实施例中的tir-pbac模型采用opm 作为收集起源数据的基本模型，除了能够捕获基本的起源外，还能收集访问发生时的环境信息，提供了更为详细的数据起源信息。在访问控制的时候能够进行更细粒度的控制，满足复杂的需求。tir-pbac模型解释了起源数据的来源，分别是访问请求时的事务数据以及当时的环境信息，并分别介绍了两种起源数据如何应用在访问控制中。tir-pbac模型引入了角色，权限，事务等因素，在角色授权阶段，通过收集用户的角色以及请求对应权限的方式来确定用户是否有权发起该请求，简化了用户授权阶段的查询，在随后的行为验证阶段，将环境信息的因素考虑了进去，将用户的属性，操作的属性，资源的属性作为访问时的环境信息，并且在访问被接受以后以事务的形式记录下来，丰富了起源数据。tir-pbac模型引入角色等概念，增加了相关的映射关系和形式化定义，为基于起源数据的访问控制模型提供了一个可行的方案。
91.结合上面的分析，可以知道，tir-pbac模型是为了解决目前日益复杂的访问需求而提出的一种可行的基于起源数据访问控制模型，结合了角色，角色继承，权限的相关概念，简化访问流程，实现了细粒度的访问控制。
92.本技术实施例提出的访问控制方法，先将用户的访问请求输入至tir-pbac模型中；其中，该访问请求包括：代理用户、动作和对象；然后通过tir-pbac模型对访问控制请求进行解析，得到访问请求对应的访问控制结果；再通过tir-pbac模型输出访问控制结果。也就是说，在本技术的技术方案中，提出了一种新的访问控制模型tir-pbac，通过引入角色与权限的概念来预先定义一类用户的权限，这样在进行访问时，角色的授权将变得非常简单，只需要查询用户的角色，然后判断访问请求中的权限是否为角色所拥有即可。而在现有技术中，传统的pbac模型的访问控制方式在进行用户验证时需要系统提供面向用户的访问策
略，这就需要在用户的不断访问中通过提取他们的起源数据来完善相关的策略，这种用户授权的方式在实际的应用中，尤其是在访问控制查询时需要不断地从起源数据中获得访问控制策略，这样会对整个访问控制形成负担。因此，和现有技术相比，本技术实施例提出的访问控制方法，可以进一步提升访问控制的精细度，为访问控制提供了更加精细化的粒度控制；并且，本技术实施例的技术方案实现简单方便、便于普及，适用范围更广。
93.实施例四
94.图7为本技术实施例提供的访问控制装置的结构示意图。如图7所示，所述访问控制装置包括：输入模块701、解析模块702和输出模块703；其中，
95.所述输入模块701，用于将用户的访问请求输入至tir-pbac模型中；其中，所述访问请求至少包括：代理用户、动作和对象；
96.所述解析模块702，用于通过所述tir-pbac模型对所述访问控制请求进行解析，得到所述访问请求对应的访问控制结果；
97.所述输出模块703，用于通过所述tir-pbac模型输出所述访问控制结果。
98.进一步的，所述解析模块702，具体用于基于所述访问控制请求分别确定所述用户在授权阶段的结果和所述用户在规则收集阶段的结果；基于所述访问控制请求和所述用户在规则收集阶段的结果，确定所述用户在行为验证阶段的结果；根据所述用户在授权阶段的结果和所述用户在行为验证阶段的结果，确定所述访问请求对应的访问控制结果。
99.上述访问控制装置可执行本技术任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本技术任意实施例提供的访问控制方法。
100.实施例五
101.图8为本技术实施例提供的电子设备的结构示意图。图8示出了适于用来实现本技术实施方式的示例性电子设备的框图。图8显示的电子设备12仅仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
102.如图8所示，电子设备12以通用计算设备的形式表现。电子设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
103.总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
104.电子设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
105.系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)30和/或高速缓存存储器32。电子设备12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图8未显示，通常称为“硬盘驱动器”)。尽管图8中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom，dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器
可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本技术各实施例的功能。
106.具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本技术所描述的实施例中的功能和/或方法。
107.电子设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该电子设备12交互的设备通信，和/或与使得该电子设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口22进行。并且，电子设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与电子设备12的其它模块通信。应当明白，尽管图8中未示出，可以结合电子设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
108.处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本技术实施例所提供的访问控制方法。
109.实施例六
110.本技术实施例提供了一种计算机存储介质。
111.本技术实施例的计算机可读存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
112.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
113.计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
114.可以以一种或多种程序设计语言或其组合来编写用于执行本技术操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c ，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以
完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
115.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。