CN118133254A - 资源访问控制方法、装置、电子设备、存储介质及产品 - Google Patents

Abstract

本申请提供一种资源访问控制方法、装置、电子设备、存储介质及产品。该方法包括：接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识，根据所述用户标识，确定所述目标用户对应的用户组，根据所述用户组，确定所述目标用户的访问权限，响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。通过基于用户组管理用户访问权限的方法可以实现项目管理系统中用户权限的高效管理。

Description

资源访问控制方法、装置、电子设备、存储介质及产品

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源访问控制方法、装置、电子设备、存储介质及产品。

背景技术

权限控制是项目管理系统访问控制和数据安全的重要组成部分，它可以有效避免未经授权的用户对系统进行访问或操作，从而防止数据泄漏、篡改或破坏等安全威胁。

对于业务内容比较多的企业，项目管理系统中的不同的用户(例如，企业员工)需要拥有不同的权限。如何对用户的权限进行管理，是亟待解决的技术问题。

发明内容

有鉴于此，本申请的目的在于提出一种资源访问控制方法、装置、电子设备、存储介质及产品，以解决或部分解决上述问题。

基于上述目的，本申请第一方面，提供了一种资源访问控制方法，包括：

接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识；

根据所述用户标识，确定所述目标用户对应的用户组；

根据所述用户组，确定所述目标用户的访问权限；

响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

本申请第二方面，提供了一种资源访问控制装置，包括：

接收模块，被配置为接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识；

第一确定模块，被配置为根据所述用户标识，确定所述目标用户对应的用户组；

第二确定模块，被配置为根据所述用户组，确定所述目标用户的访问权限；

返回模块，被配置为响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

本申请第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如第一方面所述的方法。

本申请第四方面，提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行如第一方面所述的方法。

本申请第五方面，提供了一种计算机程序产品，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行如第一方面所述的方法。

从上面所述可以看出，本申请提供的一种资源访问控制方法、装置、电子设备、存储介质及产品。该方法包括：接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识，根据所述用户标识，确定所述目标用户对应的用户组，根据所述用户组，确定所述目标用户的访问权限，响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。通过基于用户组管理用户访问权限的方法可以实现项目管理系统中用户权限的高效管理。

附图说明

为了更清楚地说明本申请或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本申请实施例的示例性系统的示意图。

图2A示出了根据本申请实施例的示例性权限模型的示意图。

图2B示出了根据本申请实施例的示例性权限模型的构建方法的流程示意图。

图2C示出了根据本申请实施例的示例性权限管理方法的流程示意图。

图3A示出了根据本申请实施例的示例性权限模型的示意图。

图3B示出了根据本申请实施例的又一示例性权限模型的示意图。

图4示出了根据本申请实施例的示例性权限授予方法的流程示意图。

图5示出了根据本申请实施例的示例性资源访问控制方法的流程示意图。

图6示出了根据本申请实施例的示例性资源访问控制方法的流程示意图。

图7示出了根据本申请实施例的示例性资源访问控制装置的示意图。

图8示出了根据本申请实施例的示例性电子设备的示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本申请进一步详细说明。

需要说明的是，除非另外定义，本申请实施例使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

可以理解的是，在使用本申请中各个实施例的技术方案之前，均会通过恰当的方式对所涉及的个人信息的类型、使用范围、使用场景等告知用户，并获得用户的授权。

例如，在响应于接收到用户的主动请求时，向用户发送提示信息，以明确的提示用户，其请求执行的操作将需要获取和使用到用户的个人信息。从而，使得用户可以根据提示信息来自主的选择是否向执行本申请技术方案的操作的电子设备、应用程序、服务器或存储介质等软件或硬件提供个人信息。

作为一种可选的但非限定的实现方式，响应于接受到用户的主动请求，向用户发送提示信息的方式例如可以是弹窗的方式，弹窗中可以以文字的方式呈现提示信息。此外，弹窗中还可以承载供用户选择“同意”或者“不同意”向电子设备提供个人信息的选择控件。

可以理解的是，上述通知和获取用户授权过程仅是示意性的，不对本申请的实现方式构成限定，其他满足相关法律法规的方式也可应用于本申请的实现方式中。

访问控制技术是信息技术安全的重要组成部分。利用访问控制技术可以对资源进行保护，防止对所述资源进行未经授权的访问，从而带来安全隐患。在实际应用中，可以利用权限模型对访问主体的权限进行管理。获得权限的访问主体可以对资源进行访问，未获得权限的访问主体无法对资源进行访问。所述访问主体可以包括用户、电子设备等。所述权限可以指对资源进行访问的权力。所述资源可以包括数据、图片等。所述访问可以包括查询、删除、插入、修改等。

所述权限模型可以包括RBAC(Role-Based Access Control，基于角色的权限控制)模型、以及ABAC(Attribute-Based Access Control，基于属性的权限控制)模型等权限模型。所述RBAC模型在访问主体和权限之间引入角色的概念。访问主体可以与一个或多个角色相关联，角色可以与一个或多个权限相关联。通过为访问主体分配角色，可以对访问主体授予权限。所述ABAC模型引入属性信息的概念。根据属性信息和权限的控制策略决定是否对访问主体授予权限。所述属性信息可以包括访问主体属性信息、资源属性信息、以及环境属性信息等。所述访问主体属性信息可以包括用户的身份、用户的年龄、用户的职位、用户的入职年限等，所述资源属性信息可以包括资源的大小、资源的安全级别、资源的敏感性等，所述环境属性信息可以包括时间、地点(例如IP地址等)、设备标识(例如设备的型号等)等。

在RBAC模型中，角色相对比较固定，不够灵活，无法对访问主体进行细粒度的权限管理。在ABAC模型中，权限控制策略的设计和维护比较复杂，使得权限管理的成本较高。

有鉴于此，本申请提出一种资源访问控制方法、装置、电子设备、存储介质及产品。该方法包括：接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识，根据所述用户标识，确定所述目标用户对应的用户组，根据所述用户组，确定所述目标用户的访问权限，响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。通过基于用户组管理用户访问权限的方法可以实现项目管理系统中用户权限的高效管理。

图1示出了根据本申请实施例的示例性系统100的示意图。

如图1所示，系统100可以包括用户终端102。用户终端102可以为面向用户104(例如，企业的员工)的设备，包括但不限于智能手机、平板电子设备、便携式计算机、台式电脑等。用户终端102可以用于发起权限申请请求和/或资源访问请求。例如，用户104可以通过用户终端102向权限管理服务器发送权限申请请求和/或资源访问请求。

系统100还可以包括权限管理服务器106。权限管理服务器106可以为单个服务器、由多个服务器构成的服务器集群、或者部署在云端的服务器。权限管理服务器106可以根据权限模型对权限进行管理。

系统100还可以包括数据库118。数据库118可以存储用于构成权限模型的数据表。权限管理服务器106可以通过在数据库118中查找相应的数据，以对权限进行管理。例如，权限管理服务器106可以通过在数据库118中查找是否存在与用户标识相匹配的资源标识，以确定用户是否具有资源的访问权限。

系统100还可以包括资源管理服务器108。资源管理服务器108可以为单个服务器、由多个服务器构成的服务器集群、或者部署在云端的服务器。资源管理服务器108可以用于对资源进行管理。

系统100还可以包括鉴权终端110。鉴权终端110可以为面向权限验证人员112(例如，企业的部门领导)的设备，包括但不限于智能手机、平板电子设备、便携式计算机、台式电脑等。鉴权终端110可以用于对用户104的权限进行验证。

系统100还可以包括管理终端114。管理终端114可以为面向权限管理人员116(例如，企业的人力资源人员)的设备，包括但不限于智能手机、平板电子设备、便携式计算机、台式电脑等。管理终端114可以用于发起权限申请请求，以为用户104申请权限。例如，管理人员116可以通过管理终端114向权限管理服务器106发送权限申请请求，权限管理服务器106可以根据权限模型将权限授予用户104。

在一个示例性的应用场景中，用户104可以为企业的员工。企业的员工在入职以后，为了能够开展工作，需要获得一些基础权限。为此，企业的人力资源人员(用户116)可以在员工入职以后，为员工申请基础权限。具体地，员工在入职以后，可以分配有员工标识。员工标识例如可以是员工的账户、员工的工号、或者员工的花名等。用户104和/或用户116可以通过用户终端102向权限管理服务器106发送权限申请请求。权限申请请求可以包括员工标识。

权限管理服务器106可以根据权限模型将权限授予用户104，并将权限申请结果发送至用户终端102和/或管理终端114。用户终端102和/或管理终端114可以接收权限申请结果。这样权限管理服务器106便可以为新入职员工分配基础权限。

图2A示出了根据本申请实施例的示例性权限模型200的示意图。在一些实施例中，权限模型200可以是由元数据构建的模型。

如图2A所示，权限模型200可以包括实体领域202、授权关系领域204、规则领域206和实体组领域208。其中，实体领域202中的元素可以包括权限模型200的实体(例如，主体、客体)、客体操作、操作关联。授权关系领域204中的元素可以包括主客体的授权关系。规则领域206中的元素可以包括实体的扩散规则(例如，用户和用户组)、扩散规则的组合关系、授权路径的合并规则(例如，任一通过就通过或者全部通过才通过)。实体组领域208中的元素可以包括实体的扩散数据(例如，用户和用户组、部门和用户组)。通过将实体之间的关系抽象为扩散规则，降低了实体关系的构建难度。这样，当需要新增实体关系时，只需要编写相应关系的处理；当实体关系发生变化时，只需要调整对应规则的处理逻辑。此外，扩散规则可以随意组合，这样提高了规则的复用度，同时也提高了新权限点为的建设速度。

需要说明的是，实体可以是权限模型的一个元素，用于标识系统中的每一个对象类型，例如，用户、部门、空间、工作项实例等。

实体领域202中的元素可以以数据表的形式存储于数据表。实体领域202中的数据表可以包括实体操作关系表2022、实体操作表2024和实体类型表2026。在一些实施例中，实体类型表2026可以是对象类型的别名，该对象类型可以是需要进行权限管控的对象类型。示例性地，实体类型表2026可以包括用户、部门、空间、工作项实例等。在一些实施例中，实体操作表2024中可以定义实体可支持的操作类型，例如，空间的访问权限、工作项实例的查看权限等。在一些实施例中，实体操作关系表2022可以用于体现操作的组合关系，降低建立授权关系的复杂度，例如，空间的管理权限，自动获得空间的访问权限。示例性地，，当用户A获得空间管理权限时，不需要在存储层面体现用户A对空间访问权限的关系。

实体类型表2026中的数据可以以标识(id)，实体类型编码(code)，类型描述(description)的形式存储，例如，标识为1001，实体类型编码为User，类型描述为员工。

实体操作表2024中的数据可以以标识(id)，操作类型编码(code)，实体类型标识(entity_type_id)的形式存储，例如，标识为2001，操作类型编码为WorkItemView，实体类型标识为WorkItem。

授权关系领域204中的元素可以以数据表的形式存储于数据表。授权关系领域204中的数据表可以包括实体授权数据表2042、实体类型授权宽表2044、授权的关联规则表2046和实体类型授权表2048。在一些实施例中，实体类型授权表2048用于定义，例如，主体A拥有客体B的操作权限C。示例性地，空间成员用户组(主体A)拥有空间(客体B)的访问权限(操作权限C)。在一些实施例中，授权的关联规则表2046可以用于定义实体扩散规则可以适用于哪些授权关系，例如，用户B的下属C属于用户组A的扩散规则，用户组A既拥有空间访问权限，也拥有数据权限、操作权限。然而，由于下属C的权限等级低于用户B的权限等级，因此，该扩散规则不适用[用户组A的空间访问权限]，而是适用[用户组A的数据权限、操作权限]，即下属C可以拥有数据权限、操作权限，而无法拥有空间访问权限。在一些实施例中，实体类型授权宽表2044可以用于定义主体到客体操作存在哪些授权路径，例如，用户的空间访问权限可以包括以下授权路径：

用户B→租户管理员(组)E→空间D的访问权限；

用户B→用户组A→空间D的访问权限；

用户B→部门C→用户组A→空间D的访问权限。

在一些实施例中，实体授权数据表2042可以用于定义主体A拥有客体B的操作权限C，例如，空间成员用户组A拥有空间B的访问权限。

其中，实体类型授权表2048中的数据可以以标识(id)，编码(code)，主体类型(subject_entity_type_id)，客体类型(object_entity_type_id)，操作(action_id)，影响(effect)，计算类型(mode)的形式存储，例如，标识为6001，编码为UserGroup_Auth_WorkItemCollectionView，主体类型为UserGroup，客体类型为WorkItemCollection，操作为WorkItemCollectionView，影响为允许(或拒绝)，计算类型为1。其中，计算类型为1表示从主体开始计算，计算类型为2表示从客体开始计算。

规则领域206中的元素可以以数据表的形式存储于数据表。规则领域206中的数据表可以包括规则表2062、规则关系表2064和授权的生效规则表2066。在一些实施例中，规则表2062可以用于定义系统规则的抽象，例如，实体之间的扩散规则。示例性地，实体之间的扩散规则：用户组A获得空间的访问权限时，用户组A的成员用户B自动获得空间的访问权限，此时用户B到用户组A就属于一种实体的扩散规则。在一些实施例中，规则关系表2064可以用于体现规则之间的组合关系，以提高规则的复用。示例性地，用户到用户组的扩散规则，可以包括以下两种：

用户→用户组：用户B被直接加入到用户组A；

用户→部门→用户组：用户B属于上级部门C，部门C被直接加入到用户组。此规则就属于一种组合规则，该组合规则可以包括两个子规则：

用户→部门：用户B的上级部门列表，存在部门C；

部门→用户组：部门C被直接加入到用户组A。

在一些实施例中，授权的生效规则表2066可以用于定义主体到客体操作，存在多个授权路径的情况下，如何判定存在鉴权。判定方式可以包括以下两种：

OR：表示任一授权路径判定通过，则本次请求判定为通过；

AND：表示全部授权路径判定通过，则本次请求才判定为通过。

示例性地，当判定用户B是否具有空间A的访问权限时，可以存在多条授权路径：

用户B→租户管理员(组)E→空间A的访问权限；

用户B→用户组A→空间A的访问权限；

用户B→部门C→用户组A→空间A的访问权限。

当生效规则为[OR]时，即上述授权路径中任一授权路径通过就判定用户具有空间A的访问权限。

规则表2062中的数据可以以标识(id)，规则类型编码(code)，源实体(source_entity_type_id)，目标实体(target_entity_type_id)，规则类型(type)，规则信息(expression)，描述(description)的形式存储。例如，标识为3003，规则类型编码为User_UserGroup，源实体为User，目标实体为UserGroup，规则类型为实体组，规则信息为UserGroup，描述为user->user group。

规则关系表2064中的数据可以以标识(id)，父规则(parent_rule_id)，子规则(sub_rule_id)，子规则的排序(sub_order)的形式存储。例如，标识为4001，父规则为User_Department_UserGroup，子规则为User_Department，子规则的排序为1。

实体组领域208中的元素可以以数据表的形式存储于数据库。实体组领域208中的数据表可以包括实体组表2082、实体组业务属性表2084和实体组成员表2086。在一些实施例中，实体组表2082可以用于将一批实体组合为一个新的实体类型，通过类型区分不同的实体类型。例如，可以将用户和部门组合为用户组：用户组(用户/部门)。在一些实施例中，实体组业务属性表2084可以存储实体组的业务属性，不参与权限计算的部分。实体组的业务属性，例如，可以是用户组的名称。在一些实施例中，实体组成员表2086可以包括实体组的成员列表，例如，实体组为用户组的成员包括用户、部门。

通过利用元数据构建权限模型200以及配置权限模型200的控制逻辑，可以适应不同系统的权限控制需求。如此一来，不同系统可以复用权限模型200，避免了权限模型的重复开发的问题。

图2B示出了根据本申请实施例的示例性权限模型200的构建方法210的流程示意图。以构建[用户查看工作项实例]的权限模型为例，如图2B所示，方法210可以包括如下步骤。

在步骤212，可以创建实体类型表2026。实体类型表2026中存储的实体类型可以包括员工、工作项实例数据、工作项实例数据集合、用户组、空间、部门和空间管理员用户组。

在步骤214，可以创建实体操作表2024。实体操作表2024中存储的数据可以包括与实体类型对应的操作类型。例如，工作项实例数据对应的操作类型可以是工作项实例数据查看操作，空间对应的操作类型可以是空间管理操作，工作项实例数据集合可以是工作项实例数据集合查看操作。

在步骤216，可以创建实体操作关系表2022。实体操作关系表2022中存储的数据可以包括父操作与子操作的对应关系。例如，父操作可以是管理操作，管理操作对应的子操作可以是查看操作，父操作可以是工作项实例数据集合查看操作，工作项实例数据集合查看操作对应的子操作可以是工作项实例数据查看操作。

在步骤218，可以创建规则表2062。规则表2062中存储的规则类型可以包括实体组、规则序列、BQL规则(一种基于实体属性的圈定规则)、预置规则、组合规则和影响规则。规则表2062中的规则信息可以用于描述实体用户组的用户组类型。

在步骤220，可以创建规则关系表2064。规则关系表2064中存储的数据可以包括规则表2062中规则的组合关系。例如，用户可以直接被加入到用户组，用户还可以通过加入到部门，再将部门直接加入到用户组。

在步骤222，可以创建实体类型授权表2048。实体类型授权表2048中存储的数据可以包括用户组拥有工作项实例数据集合的查看操作，空间管理员用户组拥有空间的管理操作。

在步骤224，可以创建授权的关联规则表2046。授权的关联规则表2046中存储的数据可以包括当主体为用户组时，主体拥有工作项实例数据集合的查看操作；当主体为空间管理员用户组时，主体拥有空间的管理操作；当客体为工作项实例数据时，客体拥有工作项实例数据集合的查看操作。

在步骤226，系统可以自动推导出实体类型授权宽表2044。例如，主体为用户，客体为工作项实例数据时，用户拥有工作项实例数据集合的查看操作。用户可以根据主体规则查找到用户所属的用户组，工作项实例数据集合可以根据客体规则查找到工作项实例数据。

在权限模型200中，由于实体领域202中的实体类型表2026中定义了主体与客体之间的权限关系以及客体操作和操作关联，因此，当需要新增用户时(例如，为新入职的员工添加权限)，权限管理人员116只需要在实体组领域208中为用户创建用户组，并将用户标识添加到用户组，权限管理服务器106可以根据权限模型200查找到用户组拥有的访问权限。权限管理人员116根据查找到的访问权限中的目标访问权限授予该用户。这样，在为新增用户授予权限时，通过权限模型200可以自动匹配到可授予的权限，节省了权限管理人员116的操作。

图2C示出了根据本申请实施例的示例性权限管理方法230的流程示意图。

如图2C所示，权限管理人员116在为用户授予权限时，在一些实施例中，管理终端114可以接收用户(例如，待授予权限的用户)发送的权限申请请求。该权限申请请求中可以包括用户标识。权限管理人员116可以通过管理终端114为用户创建实体组表。实体组表中可以定义实体组标识以及实体组标识所属的实体组。例如，可以定义字段为UserGroup1和UserGroup2的实体组标识属于字段为UserGroup的实体组。

在一些实施例中，权限管理人员116可以通过管理终端114创建实体组业务属性表，在实体组业务属性表中可以定义实体组标识的中文名称。例如，可以定义字段为UserGroup1的实体组标识对应的中文名称为用户组1，可以定义字段为UserGroup2的实体组标识对应的中文名称为用户组2。

在创建好实体组表和实体组业务属性表后，在一些实施例中，权限管理人员116可以通过管理终端114，根据用户标识在实体组成员表中添加实体组成员。例如，可以将用户标识添加到字段为UserGroup1和UserGroup2的实体组标识，这样，用户则可以获取字段为UserGroup1和UserGroup2的实体组标识对应的访问权限。

如此一来，实体组领域208可以将实体的聚合关系抽象为实体组，从而降低了为用户授予权限的复杂度。例如，当需要新增用户时，只需要增加用户的实体组的元数据模型即可进行权限管理。

图3A示出了根据本申请实施例的示例性权限模型300的示意图。权限模型300可以是权限模型200。

如图3A所示，在一些实施例中，客体1可以是主体1要访问的资源，客体2可以是主体2要访问的资源。其中，主体(例如，主体1和主体2)可以是权限模型300的一个元素，既可作为鉴权时具体的访问者(用户等)，也可作为授权时被授权的访问者集合(部门/用户组等)；客体(例如，客体1和客体2)可以是权限模型300的一个元素，既可作为鉴权时具体的资源(空间、工作项实例等)，也可作为授权时圈定的资源集合(空间/BQL规则圈定的工作项实例等)。

需要说明的是，用户可以是使用系统的人员，例如，企业的员工。部门可以是，例如，按照一定方式将一批员工进行聚合，形成易于管理的组织单位，是企业管理的基本单元。用户组可以是权限管理的一种角色，例如，按照一定的方式将一批员工/部门进行聚合，是权限管理的一种基本单元。工作项实例可以代表一项工作。空间可以是工作项实例的一种数据隔离维度，按照一定的方式将一批工作项实例进行聚合。

授权路径可以是主体到客体某个操作类型的路径，例如，用户被授予空间的访问权限存在多条授权路径：

授权路径1：用户→租户管理员(组)→空间的访问权限；

授权路径2：用户→用户组→空间的访问权限；

授权路径3：用户→部门→用户组→空间的访问权限；

其中，租户管理员可以是权限管理的一种角色，按照一定的方式将一批员工进行聚合，这个角色具备租户内任一操作的权限。

在权限模型300中，主体1被授予客体1的访问权限的授权路径可以包括：

授权路径1：主体1被授予了客体1的操作1；

授权路径2：主体1通过主体圈定规则获得主体2。由于主体2被授予了客体2的操作2，因此主体1被授予了客体2的操作2。当操作2通过操作关联获得操作1，且客体2通过客体圈定规则获得客体1时，主体1被授予了客体1的操作1。

图3B示出了根据本申请实施例的又一示例性权限模型300的示意图。

以用户需要被授予工作项实例数据的访问权限为例，如图3B所示，权限模型300中的主体可以包括用户、部门、自定义用户组和空间管理用户组。客体可以包括空间、工作项实例数据集合和工作项实例数据。

如图3B所示，在一些实施例中，用户可以通过主体扩散规则1直接加入到自定义用户组。作为一可选实施例，用户还可以通过主体扩散规则2，通过用户所在的部门加入自定义用户组。在一些实施例中，用户可以通过主体扩散规则2-1加入到部门，再通过主体扩散规则2-2将部门加入到自定义用户组。当用户为权限等级更高的管理人员时，如图3B所示，在一些实施例中，用户可以通过主体扩散规则3加入空间管理用户组。

如图3B所示，在一些实施例中，当实体类型授权表2048中存储的数据包括空间管理用户组拥有空间的管理操作，自定义用户组拥有工作项实例数据集合的查看操作时，加入到自定义用户组的用户则可以拥有工作项实例数据集合的查看权限，加入到空间管理用户组的用户则可以拥有空间的管理权限。

如图3B所示，在一些实施例中，当实体操作关系表2022中存储的数据包括拥有[空间的管理操作]，自动拥有[工作项实例数据的查看操作]时，加入到空间管理用户组的用户则可以拥有空间的管理权限和工作项实例数据的查看权限。当实体操作关系表2022中存储的数据包括拥有[工作项实例数据集合的查看操作]，自动拥有[工作项实例数据的查看操作]，同时通过客体扩散规则：BQL规则圈定一批工作项实例数据时，加入到自定义用户组的用户则可以拥有工作项实例数据集合的查看权限，同时可以拥有被BQL规则圈定的工作项实例数据的查看权限。

如此一来，用户被授予空间的访问权限的授权路径可以包括：

授权路径1：用户→空间管理用户组→空间的访问权限。

用户被授予工作项实例数据的访问权限的授权路径可以包括：

授权路径1：用户→自定义用户组→工作项实例数据的访问权限；

授权路径2：用户→部门→自定义用户组→工作项实例数据的访问权限；

授权路径3：用户→空间管理用户组→工作项实例数据的访问权限。

图4示出了根据本申请实施例的示例性权限授予方法400的流程示意图。

如图4所示，在将用户标识添加到实体组后，在一些实施例中，权限管理人员116可以通过管理终端114定义需要授予实体组的权限。例如，自定义用户组标识被授予工作项实例数据集合的查看权限，空间管理用户组标识被授予空间的管理权限。

在一些实施例中，管理终端114可以接收用户发送的权限申请请求，权限管理人员116可以通过管理终端114提供的权限服务的授权接口将定义的需要授予实体组的权限的信息发送至权限管理服务器106。权限管理服务器106可以根据权限模型200获取实体类型授权信息。例如，实体类型授权信息可以包括与实体组标识相关的主体与客体之间的授权路径。例如，授权路径1：空间管理用户组→空间的管理权限；授权路径2：自定义用户组→工作项实例数据集合的查看权限。

在一些实施例中，权限管理服务器106根据权限模型200确定存在可以实现授权的授权路径后，可以写入实体授权数据至数据库118。

在一些实施例中，由于权限模型200是通过元数据构建的，这样当权限管理人员116将用户添加到实体组后，管理终端114可以显示如图3B所示的权限关系图。通过将权限关系以可视化的方式呈现，可以使得权限管理人员116知道实体组对应的权限范围，从而权限管理人员116可以清楚地知道可以为用户授予哪些权限。

利用权限模型200，权限管理人员在为用户授予权限时，通过将用户标识添加到用户组，权限管理服务器106可以根据权限模型200中的控制逻辑确定用户组拥有的权限操作，从而可以确定可授予用户权限。这样，实现了权限管理人员对用户权限的高效管理。

图5示出了根据本申请实施例的示例性资源访问控制方法500的流程示意图。资源访问控制方法500可以由鉴权终端110执行。

用户104可以发送针对目标资源的访问请求，该访问请求中可以包括用户104的用户标识、目标操作、目标资源对应的资源标识和权限等级标识等信息。以用户104为管理人员为例，鉴权终端110接收到用户104发送的针对目标资源的访问请求后，在一些实施例中，可以根据权限模型200中的实体操作关系表2022和目标操作确定目标操作的关联操作，并根据关联操作确定目标用户对应的用户组。例如，目标操作可以是工作项实例数据查看操作，鉴权终端110可以根据权限模型200中的实体操作关系表2022确定与查看操作关联的工作项实例数据集合查看操作和空间管理操作。

在一些实施例中，鉴权终端110可以根据权限模型200中的实体类型授权表2048，并根据关联操作确定访问路径。例如，可以包括以下访问路径：

访问路径1：用户组被授予工作项实例数据集合的查看权限；

访问路径2：空间管理组被授予空间的管理权限；

访问路径3：用户通过部门加入到用户组，用户组被授予工作项实例数据集合的查看权限。

其中，访问路径中包括实体组类型标识。

如此一来，通过根据权限模型确定完整的访问路径，可以管理整个系统的权限控制逻辑，避免重复鉴权的问题。此外，从权限模型中确定的访问路径为鉴权提供了依据，当鉴权终端的鉴权过程中出现不属于访问路径中的数据时，可以及时将该数据进行拦截，以及时规避数据安全的风险。

在确定了访问路径后，在一些实施例中，鉴权终端110可以根据访问路径和用户标识，在再写入数据库的权限数据中查找与访问路径中的实体组类型标识对应的实体组。例如，实体组类型标识可以是用户组类型UserGroup和空间管理组类型ProjectAdminUserGroup，鉴权终端110可以在权限数据中查找到与用户组类型对应的用户组UserGroup1和UserGroup2，可以查找到与空间管理组类型对应的空间管理组ProjectAdminUserGroup1。这样鉴权终端110可以根据访问路径和用户标识，确定目标用户对应的用户组。

当用户组是通过创建目标用户组和目标部门，并将用户标识添加至目标部门，将目标部门添加至目标用户组得到的时，鉴权终端110还可以根据访问路径3，根据用户标识确定用户标识所在的部门，并确定该部门所在的用户组，以根据权限模型200确定的访问路径将所有用户组确定出来，以避免由于信息的遗漏导致的鉴权失败的风险。

在确定了用户组后，在一些实施例中，鉴权终端110可以在数据库中的权限数据中确定用户组的访问权限，用户组的访问权限包括允许用户组访问的资源标识。例如，用户组被授予工作项实例数据集合查看操作，空间管理组被授予空间的管理操作。当用户组未被授予资源的访问权限时，则数据库中的权限数据中无法确定与该用户组对应的资源标识。

根据客体的扩散规则，在一些实施例中，鉴权终端110可以在数据库中的权限数据中确定资源标识是否包括目标资源的资源标识，以确定目标用户的访问权限。用户104被授予权限的资源可能包括多个，鉴权终端110根据资源标识确定出多个可访问的资源后，根据目标资源的资源标识将与该标识对应的资源返回至用户终端102，以使得用户104访问到用户需要访问的资源。

当规则领域206中定义了授权路径的合并规则(例如，任一通过就通过或者全部通过才通过)时，在一些实施例中，鉴权终端110可以根据目标操作、目标资源的资源标识和用户标识，确定目标资源的目标访问路径，响应于存在多条目标访问路径，根据访问策略(例如，授权路径的合并规则)确定目标用户的访问权限是否能够访问目标资源。

例如，当访问策略定义为第一访问策略(例如，任一通过就通过)时，在一些实施例中，鉴权终端110可以根据第一访问策略确定目标用户的访问权限是否能够访问目标资源。鉴权终端110响应于目标用户的访问权限为通过多条目标访问路径中任一条目标访问路径能够访问目标资源，可以确定目标用户的访问权限能够访问所述目标资源。

当访问策略定义为第二访问策略(例如，全部通过才通过)时，在一些实施例中，鉴权终端110可以根据第二访问策略确定目标用户的访问权限是否能够访问目标资源。鉴权终端110响应于目标用户的访问权限为通过多条目标访问路径中每一条目标访问路径能够访问目标资源，可以确定目标用户的访问权限能够访问目标资源。

在一些实施例中，所述目标用户的访问权限是通过创建用户组并将所述用户标识添加至所述用户组，获取授权路径，根据所述用户组和所述授权路径得到的。

鉴权终端利用权限模型200进行权限管理，鉴权终端可以根据权限模型200中的控制逻辑确定用户组拥有的权限操作，从而可以确定数据库中已写入的权限数据是否存在待鉴权用户的权限数据。这样实现了鉴权终端对于权限的高效管理。同时，鉴权终端根据权限模型中确定出的访问路径，可以及时将不属于该访问路径中的数据拦截，提高的系统的安全性和稳定性。

图6示出了根据本申请实施例的示例性资源访问控制方法600的流程示意图。方法600可以由系统100(例如，图1中的系统100)实现。更具体地，方法600可以由鉴权终端110(例如，图1中的鉴权终端110)执行。方法600可以包括如下步骤。

在步骤602，接收目标用户(例如，图1中的用户104)针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识。

在步骤604，根据所述用户标识，确定所述目标用户对应的用户组。

在一些实施例中，所述用户组是通过创建目标用户组和目标部门并将所述用户标识添加至所述目标部门，将所述目标部门添加至所述目标用户组得到的。

在一些实施例中，所述访问请求还包括目标操作，所述确定所述目标用户对应的用户组，包括：确定所述目标操作的关联操作；根据所述关联操作和所述用户标识，确定所述目标用户对应的用户组。

在一些实施例中，根据所述关联操作，确定所述目标用户对应的用户组，包括：根据所述关联操作，确定访问路径；根据所述访问路径和所述用户标识，确定所述目标用户对应的用户组。

在一些实施例中，所述根据所述访问路径和所述用户标识，确定所述目标用户对应的用户组进一步包括：根据所述访问路径和所述用户标识，确定所述目标用户对应的部门或团队；根据所述部门或所述团队，确定所述目标用户对应的用户组。这样可以根据访问路径将所有用户组确定出来，避免由于信息的遗漏导致的鉴权失败的风险。

在步骤606，根据所述用户组，确定所述目标用户的访问权限。

在一些实施例中，所述根据所述用户组，确定所述目标用户的访问权限进一步包括：确定所述用户组的访问权限，所述用户组的访问权限包括允许所述用户组访问的资源标识；确定所述资源标识是否包括所述目标资源的资源标识，以确定所述目标用户的访问权限。

在步骤608，响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

在一些实施例中，所述方法还包括：根据所述目标操作、所述目标资源的资源标识和所述用户标识，确定所述目标资源的目标访问路径；响应于存在多条所述目标访问路径，根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源。

在一些实施例中，所述访问策略包括第一访问策略，所述根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源进一步包括：响应于所述第一访问策略，根据所述第一访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；响应于所述目标用户的访问权限为通过多条所述目标访问路径中任一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

在一些实施例中，所述访问策略包括第二访问策略，所述根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源进一步包括：响应于所述第二访问策略，根据所述第二访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；响应于所述目标用户的访问权限为通过多条所述目标访问路径中每一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

在一些实施例中，所述目标用户的访问权限是通过创建用户组并将所述用户标识添加至所述用户组，获取授权路径，根据所述用户组和所述授权路径得到的。

在一些实施例中，所述目标用户的访问权限是通过权限模型控制的，所述权限模型包括实体领域、授权关系领域、规则领域和实体组领域；其中，所述实体领域用于定义所述权限模型的实体、客体操作和操作关联；所述授权关系模型用于定义所述权限模型的主客体的授权关系；所述规则领域用于定义所述权限模型的实体的扩散规则；所述实体组领域用于定义所述权限模型的实体的扩散数据。通过利用元数据构建权限模型以及配置权限模型的控制逻辑，可以适应不同系统的权限控制需求。如此一来，不同系统可以复用权限模型，避免了权限模型的重复开发的问题。

在一些实施例中，所述实体领域包括实体类型表、实体操作表和实体操作关系表，所述规则领域包括规则表和规则关系表，所述授权关系领域包括实体类型授权表、授权的关联规则表和实体类型授权宽表，所述权限模型是根据所述实体类型表、所述实体操作表、所述实体操作关系表、所述规则表、所述规则关系表、所述实体类型授权表、所述授权的关联规则表和所述实体类型授权宽表得到的。通过利用元数据构建权限模型以及配置权限模型的控制逻辑，可以适应不同系统的权限控制需求。如此一来，不同系统可以复用权限模型，避免了权限模型的重复开发的问题。

在一些实施例中，所述实体组领域包括实体组表和实体组业务属性表，所述目标用户访问权限是根据用户标识和所述权限模型得到的，其中，所述权限模型是根据所述实体组表和所述实体组业务属性表得到的。如此一来，实体组领域可以将实体的聚合关系抽象为实体组，从而降低了为用户授予权限的复杂度。例如，当需要新增用户时，只需要增加用户的实体组的元数据模型即可进行权限管理。

本申请提供的一种资源访问控制方法、装置、电子设备、存储介质及产品。该方法包括：接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识，根据所述用户标识，确定所述目标用户对应的用户组，根据所述用户组，确定所述目标用户的访问权限，响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。通过基于用户组管理用户访问权限的方法可以实现项目管理系统中用户权限的高效管理。

需要说明的是，本申请实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本申请实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本申请的一些实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于上述实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一技术构思，与上述任意实施例方法相对应的，本申请还提供了一种资源访问控制装置700。

参考图7，所述资源访问控制装置700，包括：

接收模块702，被配置为接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识。

第一确定模块704，被配置为根据所述用户标识，确定所述目标用户对应的用户组。

其中，所述用户组是通过创建目标用户组和目标部门并将所述用户标识添加至所述目标部门，将所述目标部门添加至所述目标用户组得到的。

所述访问请求还包括目标操作，第一确定模块704，还被配置为确定所述目标操作的关联操作；根据所述关联操作和所述用户标识，确定所述目标用户对应的用户组。

第一确定模块704，还被配置为根据所述关联操作，确定访问路径；根据所述访问路径和所述用户标识，确定所述目标用户对应的用户组。

第一确定模块704，还被配置为根据所述访问路径和所述用户标识，确定所述目标用户对应的部门或团队；根据所述部门或所述团队，确定所述目标用户对应的用户组。

第二确定模块706，被配置为根据所述用户组，确定所述目标用户的访问权限。

第二确定模块706，还被配置为确定所述用户组的访问权限，所述用户组的访问权限包括允许所述用户组访问的资源标识；确定所述资源标识是否包括所述目标资源的资源标识，以确定所述目标用户的访问权限。

返回模块708，被配置为响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

装置700还可以包括判断模块，被配置为根据所述目标操作、所述目标资源的资源标识和所述用户标识，确定所述目标资源的目标访问路径；响应于存在多条所述目标访问路径，根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源。

所述访问策略包括第一访问策略，判断模块，还被配置为响应于所述第一访问策略，根据所述第一访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；响应于所述目标用户的访问权限为通过多条所述目标访问路径中任一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

所述访问策略包括第二访问策略，判断模块，还被配置为响应于所述第二访问策略，根据所述第二访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；响应于所述目标用户的访问权限为通过多条所述目标访问路径中每一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

其中，所述目标用户的访问权限是通过创建用户组并将所述用户标识添加至所述用户组，获取授权路径，根据所述用户组和所述授权路径得到的。

其中，所述目标用户的访问权限是通过权限模型控制的，所述权限模型包括实体领域、授权关系领域、规则领域和实体组领域；其中，所述实体领域用于定义所述权限模型的实体、客体操作和操作关联；所述授权关系模型用于定义所述权限模型的主客体的授权关系；所述规则领域用于定义所述权限模型的实体的扩散规则；所述实体组领域用于定义所述权限模型的实体的扩散数据。

其中，所述实体领域包括实体类型表、实体操作表和实体操作关系表，所述规则领域包括规则表和规则关系表，所述授权关系领域包括实体类型授权表、授权的关联规则表和实体类型授权宽表，所述权限模型是根据所述实体类型表、所述实体操作表、所述实体操作关系表、所述规则表、所述规则关系表、所述实体类型授权表、所述授权的关联规则表和所述实体类型授权宽表得到的。

其中，所述实体组领域包括实体组表和实体组业务属性表，所述目标用户访问权限是根据用户标识和所述权限模型得到的，其中，所述权限模型是根据所述实体组表和所述实体组业务属性表得到的。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的方法600，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一技术构思，与上述任意实施例方法相对应的，本申请还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任意一实施例所述的方法600。

图8示出了根据本申请实施例的示例性电子设备的示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备、动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入/输出模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的方法600，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一技术构思，与上述任意实施例方法相对应的，本申请还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的方法600。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的方法600，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例所述的方法600相对应的，本申请还提供了一种计算机程序产品，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行如上任一实施例所述的方法600。在一些实施例中，所述计算机程序指令可以由计算机的一个或多个处理器执行以使得所述计算机和/或所述处理器执行所述的方法600。对应于所述的方法600中各实施例中各步骤对应的执行主体，执行相应步骤的处理器可以是属于相应执行主体的。

上述实施例的计算机程序产品用于使所述计算机和/或所述处理器执行如上任一实施例所述的方法600，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本申请的范围(包括权利要求)被限于这些例子；在本申请的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本申请实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本申请实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本申请实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本申请实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本申请的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本申请实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本申请的具体实施例对本申请进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本申请实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本申请实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (17)

1.一种资源访问控制方法，包括：

接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识；

根据所述用户标识，确定所述目标用户对应的用户组；

根据所述用户组，确定所述目标用户的访问权限；

响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

2.如权利要求1所述的方法，其中，所述访问请求还包括目标操作，所述确定所述目标用户对应的用户组，包括：

确定所述目标操作的关联操作；

根据所述关联操作和所述用户标识，确定所述目标用户对应的用户组。

3.如权利要求2所述的方法，其中，根据所述关联操作，确定所述目标用户对应的用户组，包括：

根据所述关联操作，确定访问路径；

根据所述访问路径和所述用户标识，确定所述目标用户对应的用户组。

4.如权利要求3所述的方法，其中，所述根据所述访问路径和所述用户标识，确定所述目标用户对应的用户组进一步包括：

根据所述访问路径和所述用户标识，确定所述目标用户对应的部门或团队；

根据所述部门或所述团队，确定所述目标用户对应的用户组。

5.如权利要求1所述的方法，其中，所述根据所述用户组，确定所述目标用户的访问权限进一步包括：

确定所述用户组的访问权限，所述用户组的访问权限包括允许所述用户组访问的资源标识；

确定所述资源标识是否包括所述目标资源的资源标识，以确定所述目标用户的访问权限。

6.如权利要求2所述的方法，其中，所述方法还包括：

根据所述目标操作、所述目标资源的资源标识和所述用户标识，确定所述目标资源的目标访问路径；

响应于存在多条所述目标访问路径，根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源。

7.如权利要求6所述的方法，其中，所述访问策略包括第一访问策略，所述根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源进一步包括：

响应于所述第一访问策略，根据所述第一访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；

响应于所述目标用户的访问权限为通过多条所述目标访问路径中任一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

8.如权利要求6所述的方法，其中，所述访问策略包括第二访问策略，所述根据访问策略确定所述目标用户的访问权限是否能够访问所述目标资源进一步包括：

响应于所述第二访问策略，根据所述第二访问策略确定所述目标用户的访问权限是否能够访问所述目标资源；

响应于所述目标用户的访问权限为通过多条所述目标访问路径中每一条目标访问路径能够访问所述目标资源，确定所述目标用户的访问权限能够访问所述目标资源。

9.如权利要求1所述的方法，其中，所述目标用户的访问权限是通过创建用户组并将所述用户标识添加至所述用户组，获取授权路径，根据所述用户组和所述授权路径得到的。

10.如权利要求1所述的方法，其中，所述用户组是通过创建目标用户组和目标部门并将所述用户标识添加至所述目标部门，将所述目标部门添加至所述目标用户组得到的。

11.如权利要求1所述的方法，其中，所述目标用户的访问权限是通过权限模型控制的，所述权限模型包括实体领域、授权关系领域、规则领域和实体组领域；

其中，所述实体领域用于定义所述权限模型的实体、客体操作和操作关联；

所述授权关系模型用于定义所述权限模型的主客体的授权关系；

所述规则领域用于定义所述权限模型的实体的扩散规则；

所述实体组领域用于定义所述权限模型的实体的扩散数据。

12.如权利要求11所述的方法，其中，所述实体领域包括实体类型表、实体操作表和实体操作关系表，所述规则领域包括规则表和规则关系表，所述授权关系领域包括实体类型授权表、授权的关联规则表和实体类型授权宽表，所述权限模型是根据所述实体类型表、所述实体操作表、所述实体操作关系表、所述规则表、所述规则关系表、所述实体类型授权表、所述授权的关联规则表和所述实体类型授权宽表得到的。

13.如权利要求11所述的方法，其中，所述实体组领域包括实体组表和实体组业务属性表，所述目标用户访问权限是根据用户标识和所述权限模型得到的，其中，所述权限模型是根据所述实体组表和所述实体组业务属性表得到的。

14.一种资源访问控制装置，包括：

接收模块，被配置为接收目标用户针对目标资源的访问请求，所述访问请求包括所述目标用户的用户标识；

第一确定模块，被配置为根据所述用户标识，确定所述目标用户对应的用户组；

第二确定模块，被配置为根据所述用户组，确定所述目标用户的访问权限；

返回模块，被配置为响应于所述目标用户的访问权限能够访问所述目标资源，返回与所述目标用户的访问权限对应的所述目标资源的信息。

15.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求1至13任意一项所述的方法。

16.一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，其中，所述计算机指令用于使计算机执行如权利要求1至13任意一项所述的方法。

17.一种计算机程序产品，其中，包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机执行如权利要求1至13中任意一项所述的方法。