大企业云运维平台权限管理方法、系统、设备和存储介质

摘要

本申请提供一种大企业云运维平台权限管理方法、系统、设备和存储介质，支持云上多SaaS应用的权限元素或对象统一管理，SaaS应用可由此实现运维设备的自动化运维，本方案基于权限模型实现，权限模型包括机构表，用户组表和资源组表；当有新增用户或新增设备时，根据机构表记录的新增用户所属机构，将新增用户添加到用户组表中记录的新增用户所属机构对应的用户组，或者根据新增设备的所在园区和产品类型确定新增设备在资源组表中所属目标资源组；将其设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内用户。本方案通过用户组和资源组，实现了设备权限的分组管理，以及对新增用户和设备的自动授权，提高权限管理效率。

说明书

技术领域

本发明涉及权限管理技术领域，特别涉及一种大企业云运维平台权限管理方法、系统、设备和存储介质。

背景技术

大型企业组织架构、职责较为复杂，需求也多种多样；大企业的运维涉及多种领域，如变更、流程、配置管理，各个领域需通过统一集成和规划；大企业的运维业务繁重，靠传统的手工运维的方式已跟不上时代的步伐，需考虑自动化运维手段，而权限管理是实现自动化运维的基础，同时面对庞大的运维对象，权限管理也需实现自动化。而现有的权限管理系统，一般无法适配上述场景，权限管理本身也一般是针对每一个用户进行单独管理，也就是单独为每一个用户配置权限，且一般均未考虑设备权限的管理，也未实现自动化，管理效率和质量低下，容易发生权限的更新不及时的问题。

发明内容

针对上述现有技术的缺点，本发明提供一种大企业云运维平台权限管理方法、系统、设备和存储介质，以提供一种高效的权限管理方案。

本申请第一方面提供一种大企业云运维平台权限管理方法，包括：

当任意一个SaaS应用有新增用户时，根据预先构建的权限模型的用户表和机构表中所记录的所述新增用户的所属机构，将所述新增用户添加到目标用户组，从而将所述目标用户组对应的权限配置给所述新增用户；其中，所述目标用户组为所述权限模型的用户组表中记录的所述新增用户所属机构对应的用户组；SaaS的全称为Software as aService，中文为软件即服务；

当有新增设备时，获取所述新增设备的设备信息；

至少根据所述新增设备的所在园区和产品类型确定所述新增设备所属的目标资源组；其中，所述目标资源组记录在所述权限模型的资源组表中；

将所述新增设备的设备信息添加到所述目标资源组，使所述新增设备的权限被配置给所述目标资源组对应的用户组内的用户；所述目标资源组对应的用户，根据所述用户组和资源组对应关系确定。

可选的，所述方法还包括：

当有被删除用户时，将所述被删除用户从所述被删除用户所属的用户组中移除。

可选的，所述方法还包括：

当有被删除设备时，从所述被删除设备所属的资源组中，移除所述被删除设备的设备信息。

可选的，所述将所述新增设备的设备信息添加到所述目标资源组，包括：

将所述新增设备的设备信息分配给线程池中的任一线程，从而调用所述线程将所述设备信息添加到所述目标资源组。

本申请第二方面提供一种大企业云运维平台权限管理系统，包括运维用户管理模块，运维资源管理模块，以及用于记录用户组和资源组的对应关系的角色权限管理模块；

所述运维用户管理模块用于：

当任意一个SaaS应用有新增用户时，根据预先构建的权限模型的用户表和机构表中所记录的所述新增用户的所属机构，将所述新增用户添加到目标用户组，从而将所述目标用户组对应的权限配置给所述新增用户；其中，所述目标用户组为所述权限模型的用户组表中记录的所述新增用户所属机构对应的用户组；SaaS的全称为Software as aService，中文为软件即服务；

所述运维资源管理模块管理各类界面元素和运维设备，其中运维设备的管理包括：

供给交付系统，用于当有新增设备时，获取所述新增设备的设备信息；

配置管理系统，用于至少根据所述新增设备的所在园区和产品类型确定所述新增设备所属的目标资源组；其中，所述目标资源组记录在所述权限模型的资源组表中；

基础运维平台，用于将所述新增设备的设备信息添加到所述目标资源组，使所述新增设备的权限被配置给所述目标资源组对应的用户组内的用户；所述目标资源组对应的用户，根据所述用户组和资源组对应关系确定。

可选的，所述运维用户管理模块还包括：

当有被删除用户时，将所述被删除用户从所述被删除用户所属的用户组中移除。

可选的，所述基础运维平台还用于：

当有被删除设备时，从所述被删除设备所属的资源组中，移除所述被删除设备的设备信息。

可选的，所述基础运维平台将所述新增设备的设备信息添加到所述目标资源组时，具体用于：

将所述新增设备的设备信息分配给线程池中的任一线程，从而调用所述线程将所述设备信息添加到所述目标资源组。

本申请第三方面提供一种电子设备，包括存储器和处理器；

其中，所述存储器用于存储计算机程序；

所述处理器用于执行所述计算机程序，所述计算机程序被执行时，具体用于实现本申请第一方面任意一项所提供的大企业云运维平台权限管理方法。

本申请第四方面提供一种计算机存储介质，用于存储计算机程序，所述计算机程序被执行时，具体用于实现本申请第一方面任意一项所提供的大企业云运维平台权限管理方法。

本申请提供一种大企业云运维平台权限管理方法、系统、设备和存储介质，支持云上多SAAS应用的庞大权限元素或对象的统一管理，各SAAS应用可基于此实现对运维设备的自动化运维，本方案基于预先构建的权限模型实现，权限模型至少包括机构表，用户组表和资源组表；当任意一个SaaS应用有新增用户时，根据机构表记录的新增用户的所属机构，将新增用户添加到用户组表中记录的新增用户所属机构对应的用户组；当有新增设备时，至少根据新增设备的所在园区和产品类型确定新增设备在资源组表中所属的目标资源组；将新增设备的设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内的用户。本方案通过设置用户组和资源组，实现了设备权限的分组管理，并在此基础上实现了对新增用户和设备的自动授权，提高了权限管理效率。

附图说明

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

图1为本申请实施例提供的一种权限管理模型的架构示意图；

图2为本申请实施例提供的一种云运维管理平台的架构示意图；

图3为本申请实施例提供的一种大企业云运维平台权限管理系统中数据表的关系示意图；

图4为本申请实施例提供的一种大企业云运维平台权限管理方法的流程图；

图5为本申请实施例提供的一种大企业云运维平台权限管理系统的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于理解本申请的技术方案，首先简要说明本申请可能涉及的部分术语。

角色，界面权限的集合。

界面权限，菜单、页面、按钮、数据等界面元素。

资源组，可理解为一种特殊的角色，是特定运维对象，即设备的集合。

资源，运维对象，如操作系统设备、数据库设备等。

对运维对象有权限，表示可以对运维对象执行运维操作，如更改配置等变更操作，而界面有权限，表示可以使用相关菜单、页面、按钮、数据等。

权限管理解决了允许什么样的用户可以做什么操作的问题。

SaaS，是Software-as-a-Service的缩写，意思为软件即服务，即通过网络提供软件服务。

PaaS是(Platform as a Service)的缩写，是指平台即服务。把服务器平台作为一种服务提供的商业模式。

本发明的有益效果在于：

本发明充分考虑大企业各种复杂用户需求，设计并实现了更加通用的权限模型，助力自动化运维的实现。

本发明可实现多应用的复杂系统的统一集中权限管理，有利于应用的快速迭代。

本发明可对频繁变动的权限进行自动授权，效率更高。

大企业组织架构、职责较为复杂，需求也多种多样，权限管理模型需要有更强的适配性；大企业的运维涉及多个领域和应用，如变更、流程、配置的管理，各个应用交互关系多样，需通过统一集成和规划，权限管理也需结合多系统和应用的特点被考虑其中；大企业的运维业务繁重，靠传统的手工运维的方式已跟不上时代的步伐，需考虑自动化运维手段，而权限管理是实现自动化运维的基础，同时面对庞大的运维对象，权限管理也需实现自动化。

现有技术更多的是实现小规模系统的权限管理，通过简单的用户信息管理、角色授权管理、用户组管理来实现，具备资源管理模块的，也更多的是管理软件菜单、文件等的资源，权限模型也更多的基于小规模系统的偏简单的业务需求，针对运维领域尤其是自动化运维领域的权限管理较少见，也很少有实现对资源权限的自动配置。

另外，由于现有技术多是针对小规模系统设计的，因而对应的模型和实现方式趋于简单，更多的是站在开发者的角度，对用户需求兼顾不多，无法精准对接用户需求，数据库设计结构简单，无法满足更多场景的需求，不适用于大规模系统；现有技术针对运维对象资源也鲜少管理，多管理软件菜单、文件等；现有技术较少用于运维领域尤其是自动化运维领域，也很少实现对资源权限的自动配置，依赖手工，效率低。

本申请实施例提供的权限管理方案，主要应用于大型的云运维管理平台，云运维管理平台具有应用多、用户类型多、使用场景多的特点，因此权限模型的构建需要对用户的应用使用习惯进行充分调研分析，本申请中，发明人通过分析，发现对云运维管理平台的权限管理，包括软件界面的权限管理，还包括对运维设备(以下简称设备)的资源权限的管理，也就是需要管理哪些用户有权限对哪些设备执行运维操作。

如前文所述，云运维管理平台的规模庞大，采用基于角色的访问控制方法(RBAC)逐一为云运维管理平台中每一运维人员(用户)管理权限，效率很低。

另外还存在一个问题，就是云运维管理平台的权限管理不仅涉及软件界面的权限管理，还涉及实体的设备的权限管理。

针对上述两方面的问题，本申请首先提出一种权限管理模型，请参见图1，为该权限管理模型的架构示意图。

可以看到，本申请提供的权限管理模型，定义了用户组和资源组的概念，其中每一个用户组包括一个或多个具有相同的角色的用户，比如，某运维团队内的多个管理员用户可以属于同一用户组，某运维团队内的多个普通职员用户则属于另一个用户组，而角色又和权限相对应，每一个特定角色均具有特定的一项或多项权限，由此，可以认为每一个用户组内的用户具有相同的权限。

需要说明，一个用户可以有多个角色，比如用户甲在某部门是管理员用户，在上级部门则是普通用户，因此一个用户可以属于至少一个用户组。

角色对应的权限，为云运维管理平台中的软件界面以及界面中的元素的权限，示例性的，假设某个角色具有云运维管理平台中界面1的权限，则具有该角色的用户在登录云运维管理平台后，可以对界面1执行运维操作，包括但不限于更改界面1的信息，布局方式和属性等。

在一些可选的实施例中，特定界面的权限也可以进一步细分为界面中各个菜单的权限。在此基础上，某个角色具有一个界面的权限时，具有该角色的用户可以对该界面上的部分菜单执行对应的操作。

不难看出，基于上述权限管理模型，权限管理系统不需要逐一对每一个用户进行权限管理，只需要在有新用户加入云运维管理平台时将其添加到特定的用户组中，就可以以用户组为单位，批量的管理多个具有相同角色的用户的权限，达到提高权限管理效率的效果。

进一步的，图1所示的权限管理模型还定义了资源组，每一个资源组可以包括至少一个设备，在实际应用中可以按照设备的类型或所在位置(如所在园区)等属性来划分资源组，用户组和资源组之间具有对应关系，一个用户组可以对应多个资源组，一个资源组也可以对应多个用户组。通过在资源组和用户组之间建立对应关系，可以使用户组内的用户具有资源组内的设备的运维权限。

基于上述架构，权限管理系统可以以用户组为单位批量管理多个用户对设备的运维权限。

同时，本申请的权限管理模型将界面的权限和设备的权限分别通过角色和资源组的方式管理，从而将两者的权限管理解耦，避免在实际应用中互相干扰。

请参见图2，为本申请实施例提供的一种云运维管理平台的架构示意图，可以看到，云运维管理平台包括一个PaaS平台，PaaS平台则提供多个SaaS应用，例如图2中提供了三个SaaS应用，记为SaaS应用1至SaaS应用3，本申请提供的自动化权限管理系统则和PaaS平台连接，用于管理PaaS平台和SaaS应用中软件界面的运维权限，以及用于管理运行PaaS平台和SaaS应用的设备的运维权限。云运维管理平台的用户登录PaaS平台后，就可以根据自动化权限管理系统分配的权限，对具有权限的应用的界面，菜单，以及设备执行运维操作。

在具体实现时，上述权限管理模型可以用多个相互对应的数据表来表示。这些数据表具体可以存储在本申请的权限管理系统中并由该系统来维护。

根据图2所示的云运维管理平台的架构示意图可以看出，本方案提供的云运维管理平台可以同时管理平台中的各个SaaS应用中用户的权限，由此，各个SaaS应用无需考虑自身的权限管理，实现了应用的轻量化，使得SaaS应用的版本迭代更新更加便捷。

请参见图3，为本申请实施例提供的一种用于实现上述权限管理模型的云运维管理平台数据表的关系示意图。

可以看到，上述权限管理模型具体可以包括：属于运维用户管理模块的用户组与用户关联表，用户表，用户组表，机构表；属于角色权限管理模块的用户角色关联表，用户组与角色关联表，角色表，角色权限关联表，权限表，权限菜单关联表，权限页面元素关联表，运维资源关联表；属于运维资源管理模块的菜单表，页面元素表和各类运维资源表。

其中用户表用于记录当前云运维管理平台中的用户，用户表中包括用户类型，与机构关系等字段，便于将用户自动分配到用户组，以及自动关联可访问的应用。

用户表支持虚拟用户的创建，以便支持多应用的功能扩展。

用户组表用于记录当前云运维管理平台中有哪些用户组。用户组表中设置所属应用ID、全局/私有属性和类型字段(用于区分处室类，部门类等类别)，从而支持多应用权限的统一高效管理和分类型区别管理。

用户组与用户关联表，则用于记录每一个用户组具体包括哪些用户。

机构表用于记录当前云运维管理平台内划分有哪些机构。

用户角色关联表，用于记录用户和角色的对应关系。

用户组与角色关联表，用于记录用户组和角色的对应关系。

角色表用于记录当前云运维管理平台内设置的角色。

角色权限关联表用于记录角色和权限的对应关系。

权限表用于记录云运维管理平台内设置有哪些权限。

权限菜单关联表，权限页面元素关联表和运维资源关联表，分别用于记录权限和菜单的对应关系，权限和页面(界面)元素的对应关系，以及权限和资源组的对应关系。

菜单表，用于记录云运维管理平台中有哪些菜单。

页面元素表用于记录云运维管理平台中有哪些页面以及这些页面有哪些元素。

各类运维资源表，则用于记录当前云运维管理平台中有哪些实体设备，这些实体设备的设备信息，以及这些实体设备所属的资源组等。

示例性的，各类运维资源表中可以包括一个“所属资源组”字段，该字段的字段值就表示对应的设备属于哪个资源组。

图3中，任意两个数据表之间的连线表示这两个数据表之间存在对应关系。并且，图3中任意两个数据表之间的对应关系均为多对多。

采用上述多个数据表来实现本方案的权限管理模型的效果在于，实现用户与菜单、角色与资源组之间的解耦，当任意一项或多项发生变更时，只需要修改对应的数据表中的信息，而不需要对整个权限管理模型进行修改，缩短了大企业中由员工入职或离职，岗位调动等原因引起的权限变更操作的耗时，提高了大企业权限管理的效率。

结合上述权限管理模型和实现该模型的数据表，本申请实施例提供一种大企业云运维平台权限管理方法，请参见图4，该方法可以包括如下步骤。

S401，当任意一个SaaS应用有新增用户时，根据预先构建的权限模型的用户表和机构表中所记录的新增用户的所属机构，将新增用户添加到目标用户组，从而将目标用户组对应的权限配置给新增用户。

SaaS的全称为Software as a Service，中文为软件即服务。

其中，目标用户组为权限模型的用户组表中记录的新增用户所属机构对应的用户组。

结合图3中的数据表对步骤S301的具体执行方式进行说明。

首先，当云运维管理平台中有新用户注册时，注册时输入的用户信息就会被添加到图3所示的用户表中，因此，是否有新增用户可以根据图3中的用户表中是否有新增记录来确定，当用户表有新增记录时，就可以将用户表新增的记录对应的用户确定为新增用户。

新增用户的所属机构可以根据用户表中与机构关系的字段来确定，比如，用户表中新增用户的与机构关系的字段，字段值为“属于机构A”，则可以确定新增用户的所属机构为机构A。

目标用户组可以根据用户组表中记录的用户组和机构的对应关系来确定，具体的，用户组表中可以记录有每一个用户组对应哪些机构，表示该用户组可以包括哪些机构的用户，由此，在确定新增用户所属机构后就可以从用户组表查找出对应所属机构的用户组，将其确定为目标用户组。

可以理解的，一个机构可以对应至少一个用户组，当有不止一个目标用户组时，本实施例的步骤均对每一个目标用户组执行。

将新增用户添加到目标用户组，具体是指，将新增用户和目标用户组的对应关系添加到用户组与用户关联表中。例如新增用户甲所属的目标用户组为用户组1，于是在步骤S401中，将对应关系“用户甲属于用户组1”添加到用户组与用户关联表中，就相当于将用户甲添加到用户组1。

如图3所示，每一个用户组均对应有至少一个角色，而角色则对应有菜单，页面元素和资源组的权限，因此在将新增用户添加到目标用户组之后，就相当于自动建立了新增用户和目标用户组对应的菜单、页面元素及资源组的权限的对应关系，也就相当于将目标用户组对应的这些权限配置给新增用户，由此，新增用户可以对这些权限关联的菜单，页面元素和资源组中的设备执行运维操作。

S402，当有新增设备时，获取新增设备的设备信息。

当有新设备接入云运维管理平台时，云运维管理平台可以从该新增设备读取得到设备信息。

设备信息可以包括唯一标识、设备名称、设备类型(配置项)、所在园区、操作系统类型、数据库类型、IP地址、增删改标记等。

S403，至少根据新增设备中的所在园区和产品类型确定新增设备所属的目标资源组。

目标资源组记录在权限模型的资源组表中。

结合图3中的数据表，图3中的各类运维资源表中可以包括所在园区和产品类型字段，每一个资源组在这两个字段上都具有特定的字段值，表示该资源组包含对应产品类型的设备或者包含对应园区内的设备，比如资源组2对应的所在园区字段的字段值可以为园区C，由此可以确定资源组2包含位于园区C的设备。

根据上述设置，在步骤S403中，可以在各类运维资源表中查找所在园区字段的字段值和新增设备的所在园区相同的资源组，或者查找产品类型字段的字段值和新增设备的产品类型相同的资源组，将找到的资源组确定为目标资源组。

S404，将新增设备的设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内的用户。

目标资源组对应的用户，根据用户组和资源组对应关系确定。

结合图3中的数据表，在步骤S404中，可以将新增设备的设备信息记录到各类运维资源表中，同时在各类运维资源表将新增设备的“所属资源组”字段的字段值设置为目标资源组，由此实现将新增设备的设备信息添加到目标资源组。

根据前述权限管理模型可以理解，每一个资源组的权限都会被配置给至少一个用户组中的至少一个用户，因此，将新增设备的设备信息添加到目标资源组后，相当于新增设备的权限就被自动配置给目标资源组对应的用户组中的用户。

需要说明的是，本实施例中，尽管按上述顺序进行说明，但是步骤S401所述的管理新增用户的权限的过程，以及步骤S402至S404所述的管理新增设备的权限的过程的先后顺序并不限定。

也就是说，在应用本实施例提供的系统后，任意时刻只要云运维管理平台中有新增用户，本实施例的大企业云运维平台权限管理系统就可以执行步骤S401来为新增用户配置对应的权限；任意时刻云运维管理平台中有新增设备时，本实施例的自动化权限管理系统就可以执行步骤S402至S404所述的过程，从而将新增设备的权限配置给云运维管理平台中对应的用户。

可选的，方法还包括：

当有被删除用户时，将被删除用户从被删除用户所属的用户组中移除。

结合步骤S401，当云运维管理平台中一个用户被删除时，云运维管理平台会删除用户表中记录的该用户的用户信息，因此可以根据用户表中的用户信息是否被删除，来确定是否有被删除用户，如果有一条用户信息被删除，那么这条用户信息对应的用户就是被删除用户。

将被删除用户从被删除用户所属的用户组中移除，具体可以是指，从用户组与用户关联表中，移除包含被删除用户的对应关系。示例性的，假设被删除用户为用户乙，用户组与用户关联表中，有两条包含用户乙的对应关系，分别为“用户乙属于用户组1”和“用户乙属于用户组3”，那么在上述步骤中，从用户组与用户关联表中删除这两条对应关系，就相当于将用户乙从所属的用户组中移除。

可选的，方法还包括：

当有被删除设备时，从被删除设备所属的资源组中，移除被删除设备的设备信息。

上述步骤的具体实施方式可以是：

在发现有设备被从云运维管理平台删除后，从各类运维资源表中删除被删除设备对应的设备信息，以及删除被删除设备在“所属资源组”字段的字段值。

可选的，将新增设备的设备信息添加到目标资源组，包括：

将新增设备的设备信息分配给线程池中的任一线程，从而调用线程将设备信息添加到目标资源组。

线程池可以包括预先创建的多个线程，上述步骤中分配给任一线程的方式可以是，在线程池的多个处于空闲状态的线程中，随机选取一个线程，然后将新增设备的设备信息分配给随机选取的这个线程，使这个线程将设备信息添加到目标资源组。

这样做的好处在于，可以通过线程池内的多个线程，实现新增设备的设备信息的并行处理，在同时有多个新增设备时，可以提高将新增设备的设备信息添加到目标资源组的效率。

本申请提供一种大企业云运维平台权限管理方法，支持云上多SAAS应用的庞大权限元素或对象的统一管理，各SAAS应用可基于此实现对运维设备的自动化运维，本方案基于预先构建的权限模型实现，权限模型至少包括机构表，用户组表和资源组表；当任意一个SaaS应用有新增用户时，根据机构表记录的新增用户的所属机构，将新增用户添加到用户组表中记录的新增用户所属机构对应的用户组；当有新增设备时，至少根据新增设备的所在园区和产品类型确定新增设备在资源组表中所属的目标资源组；将新增设备的设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内的用户。本方案通过设置用户组和资源组，实现了设备权限的分组管理，并在此基础上实现了对新增用户和设备的自动授权，提高了权限管理效率。

进一步的，如步骤S401所述，本实施例提供的方法可以用于管理每一个SaaS应用中用户的权限，支持横向扩展更多应用，避免每个应用单独管理自身的权限而导致的数据重复问题，并且使SaaS应用轻量化，有利于SaaS应用的快速迭代和更新。

根据本申请提供的大企业云运维平台权限管理方法，本申请实施例还提供一种大企业云运维平台权限管理系统，请参见图5，该系统包括运维用户管理模块501，运维资源管理模块502，以及用于记录用户组和资源组的对应关系的角色权限管理模块503。

运维用户管理模块501用于：

当任意一个SaaS应用有新增用户时，根据预先构建的权限模型的用户表和机构表中所记录的新增用户的所属机构，将新增用户添加到目标用户组，从而将目标用户组对应的权限配置给新增用户。

其中，目标用户组为权限模型的用户组表中记录的新增用户所属机构对应的用户组；SaaS的全称为Software as a Service，中文为软件即服务。

运维资源管理模块502包括：

供给交付系统521，用于当有新增设备时，获取新增设备的设备信息。

配置管理系统522，用于至少根据新增设备的所在园区和产品类型确定新增设备所属的目标资源组。

其中，目标资源组记录在权限模型的资源组表中。

基础运维平台523，用于将新增设备的设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内的用户。

目标资源组对应的用户，根据用户组和资源组对应关系确定。

可选的，运维用户管理模块还包括：

当有被删除用户时，将被删除用户从被删除用户所属的用户组中移除。

可选的，基础运维平台还用于：

当有被删除设备时，从被删除设备所属的资源组中，移除被删除设备的设备信息。

可选的，基础运维平台将新增设备的设备信息添加到目标资源组时，具体用于：

将新增设备的设备信息分配给线程池中的任一线程，从而调用线程将设备信息添加到目标资源组。

本申请实施例提供的大企业云运维平台权限管理系统，其具体工作原理可以参见本申请任一实施例提供的大企业云运维平台权限管理方法中的相关步骤，此处不再赘述。

本申请提供一种大企业云运维平台权限管理系统，系统包括运维用户管理模块501，运维资源管理模块502，以及用于记录用户组和资源组的对应关系的角色权限管理模块503，其中运维资源管理模块502包括供给交付系统521，配置管理系统522和基础运维平台523。

当任意一个SaaS应用有新增用户时，运维用户管理模块501根据预先构建的权限模型的用户表和机构表中所记录的新增用户的所属机构，将新增用户添加到目标用户组，从而将目标用户组对应的权限配置给新增用户；其中，目标用户组为权限模型的用户组表中记录的新增用户所属机构对应的用户组；SaaS的全称为Software as a Service，中文为软件即服务。

当有新增设备时，供给交付系统521获取新增设备的设备信息。配置管理系统522至少根据新增设备的所在园区和产品类型确定新增设备所属的目标资源组；其中，目标资源组记录在权限模型的资源组表中。基础运维平台523将新增设备的设备信息添加到目标资源组，使新增设备的权限被配置给目标资源组对应的用户组内的用户。目标资源组对应的用户，根据用户组和资源组对应关系确定。

本方案通过设置用户组和资源组，实现了设备权限的分组管理，并在此基础上实现了对新增用户和设备的自动授权，提高了权限管理效率。另外，本方案能够支持云上多SaaS应用的权限元素或对象统一管理，SaaS应用可由此实现运维设备的自动化运维。

本申请实施例还提供一种电子设备，请参见图6，包括存储器601和处理器602。

其中，存储器601用于存储计算机程序。

处理器602用于执行计算机程序，计算机程序被执行时，具体用于实现本申请任一实施例所提供的大企业云运维平台权限管理方法。

本申请实施例还提供一种计算机存储介质，用于存储计算机程序，计算机程序被执行时，具体用于实现本申请任一实施例所提供的大企业云运维平台权限管理方法。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

需要注意，本发明中提及的“第一”、“第二”等概念仅用于对不同的系统、模块或单元进行区分，并非用于限定这些系统、模块或单元所执行的功能的顺序或者相互依存关系。

专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。