CN120017295A

CN120017295A - Access permission management method and cloud management platform

Info

Publication number: CN120017295A
Application number: CN202410277946.6A
Authority: CN
Inventors: 邓仕军; 赵会娟; 傅贵; 徐齐刚
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2023-11-15
Filing date: 2024-03-11
Publication date: 2025-05-16

Abstract

The application provides an access right management method and a cloud management platform. The method comprises the step of establishing a resource model of cloud resources. The resource model is used for indicating the association relation between cloud resources and access operations. Based on the resource model and the access log, access rights are generated, the access rights including rights of at least one user to access the cloud resource. Therefore, the automatic formulation of the access rights in the cloud management platform is realized, and the generation efficiency of the access rights is improved.

Description

Access authority management method and cloud management platform

The present application claims priority from the chinese patent application filed at 2023, 11 and 15, filed at chinese national intellectual property office, application number 202311524179.6, application name "access policy generation method and apparatus", the entire contents of which are incorporated herein by reference.

Technical Field

The embodiment of the application relates to the technical field of clouds, in particular to an access right management method and a cloud management platform.

Background

Along with the development of information technology such as mobile internet, big data, cloud computing and the like, the network risk and threat are increased, and in order to ensure the security of cloud resources, tenants usually adopt a mode of manually setting access rights to carry out rights management and control on access behaviors of users. However, the current access right management method cannot be applied to cloud systems with rapid increase.

Disclosure of Invention

The application provides an access right management method and a cloud management platform, which can realize the automatic management of access rights in the cloud management platform.

In a first aspect, the present application provides an access rights management method. The cloud management platform is used for managing infrastructure for providing cloud services and running cloud resources on the infrastructure. The resource model comprises an association relation between cloud resources and access operation. The cloud management platform acquires an access log of the cloud resource, wherein the access log comprises user information of at least one user, resource information of the cloud resource and historical access operation. And the cloud management platform generates access rights according to the access log and the resource model, wherein the access rights comprise the rights of at least one user to access the cloud resource. Thus, the application can be convenient for setting and managing the access rights by establishing the uniform resource model. Based on the access log in the cloud management platform, the access rights are generated, so that the automatic generation of the access rights of the cloud management platform can be realized, and the formulating efficiency of the access rights is effectively improved. In addition, the automatic generation mode can be applied to a large-scale multi-user cluster system, so that the customization efficiency and rationality of the access authority of the large-scale multi-user cluster system are effectively improved. And the application generates access rights with proper granularity based on the access behavior of the user (namely, the access request to the cloud resource) and the dependency relationship between the access operation and the resource, can realize the association control to the resource with the association relationship, improves the accuracy and rationality of the access rights, and improves the security of the system.

By way of example, cloud resources may include, but are not limited to, hardware resources and software resources. Hardware resources include, but are not limited to, storage resources, network resources, and the like. Software resources include, but are not limited to, business resources, data resources, and the like.

Illustratively, the access log includes at least one user log, which is used for indicating access operation of the user to the cloud resource.

Illustratively, the access operations in the resource model are operations that a user may perform on the cloud resource, such as querying, adding, deleting, and the like. Wherein, the operations that can be executed by different cloud resources can be the same or different. The historical access operation in the access log is an access operation that has been performed by the user on the cloud resource. Illustratively, the historical access operations in the access log are one or more of the access operations in the resource model.

Illustratively, the user information includes, but is not limited to, user name, user ID, user identity information, and the like. The user identity information includes, but is not limited to, departments to which the user belongs, user project groups, and the like.

In one possible implementation, a cloud resource includes a plurality of sub-resources, and establishing a resource model of the cloud resource according to the cloud resource includes acquiring a dependency relationship between the plurality of sub-resources. And establishing a resource model based on the dependency relationship between the cloud resource and the plurality of sub-resources, wherein the resource model comprises access operation, the cloud resource and the incidence relationship of the dependent sub-resources of the sub-resources. Therefore, through the dependency relationship among the carding resources, the omission of the related access rights in the process of formulating the access rights can be avoided, and the accuracy of the access rights is effectively improved. And based on the dependency relationship among the resources, the access of the resources which do not appear in the log can be completely supplemented, so that the coverage of the generated access authority is more comprehensive, the omission of the access authority is avoided, and the accuracy of the access authority is improved.

For example, the dependency relationship in the cloud resource may also be referred to as a resource calling relationship, that is, in the process that the user accesses the cloud resource, if the user accesses one of the sub-resources, the access request also triggers the system to call at least one sub-resource on which the sub-resource depends.

In one possible implementation, the access rights further include rights of the at least one user to access dependent sub-resources of the sub-resource. Thus, the access authority generated by the application can control the access of the resource accessed by the user, and simultaneously control the access of the resource on which the resource depends, thereby effectively improving the accuracy and rationality of the access authority and improving the access security of the cloud resource.

In one possible implementation, the cloud resource is provided with an access interface, and the access interface is used for responding to the target access operation of the target user on the target sub-resource, and the method further comprises determining the authority of the target user on the target access operation of the target sub-resource and the authority of the target user on the target access operation of the target sub-resource dependent on the sub-resource based on the access authority and the target access operation. Thus, the access authority generated by the application can control the access of the resource accessed by the user, and simultaneously control the access of the resource on which the resource depends, thereby effectively improving the accuracy and rationality of the access authority and improving the access security of the cloud resource.

Illustratively, the access interface is an API interface.

In one possible implementation, generating access rights according to the access log and the resource model comprises grouping at least one user with a plurality of sub-resources based on the access log to obtain at least one user group and at least one cloud resource group, generating access rights based on the resource model, the at least one user group and the at least one cloud resource group, wherein the access rights comprise rights of the at least one user group to access the at least one cloud resource group. In this way, users and resources are grouped (in the embodiment, only users can be grouped), so that automatic grouping of access rights is realized, users with similar attributes can be divided into one group, and the users have the same access rights, so that subsequent access rights updating and optimizing are facilitated. And the application is based on the user group and the resource group, and can effectively improve the rationality of granularity of the access right.

In one possible implementation, generating access rights based on the resource model, the at least one user group and the at least one cloud resource group comprises generating initial access rights based on the resource model, the at least one user group and the at least one cloud resource group, wherein the initial access rights comprise rights of access operations of each user group to each resource group, and updating the initial access rights to obtain the access rights in response to the access operations of the at least one user to the cloud resource. In this way, an automated update of access rights can be achieved. The access right which is fit with the access condition of the user and has proper granularity can be generated based on the access condition of the user.

In one possible implementation, the updating of the initial access right to obtain the access right in response to the access operation of at least one user to the cloud resources comprises the updating of the initial access right and the access right preset by the user to obtain the access right in response to the access operation of at least one user to the cloud resources, wherein the access right preset by the user is used for indicating the right of the at least one user to access all or part of the cloud resources in the cloud resources. . In this way, in the scenario that the old access right (i.e. the access right preset by the user) exists in the system, the present application can further optimize the existing access right. For example, the access rights set by the user may not include access rights to some resources with dependency relationships, and by the method of the application, omission of rights can be avoided, and rationality of access rights can be improved.

In one possible implementation, the updating of the initial access rights in response to the access operation of the cloud resource by the at least one user includes determining a weight value of the initial access rights based on a preset rule and the access operation of the cloud resource by the at least one user, and validating the access rights with the weight value greater than a preset threshold. In this way, an automated update of access rights can be achieved. The granularity of access rights can be updated in real time based on the access situation of the user.

Illustratively, the weight value may be a score in an embodiment of the present application.

The preset rule comprises at least one of setting a preset sample, increasing a weight value of access authorities meeting the preset sample, reducing the weight value of access authorities not meeting the preset sample, setting an access duration, increasing the weight value of the access authorities meeting the access duration, reducing the weight value of the access authorities not meeting the access duration, reducing the weight value of the access authorities triggering access alarms, taking each access authority in the access authorities into effect one by one, and adjusting the weight value of the access authorities based on the number of cloud resources which can be accessed by a user under each access authority. Thus, by setting different preset rules, the access rights can be updated in real time or periodically so as to reduce the granularity of the access rights to a proper granularity.

In one possible implementation, the method further comprises the steps of obtaining user information of the new user, adding the new user to a target user group based on the user information of the new user, wherein the target user group is contained in at least one user group, and determining the authority of the new user to access cloud resources based on the access authority corresponding to the target user group. In this way, after the new user is detected to join, the access authority is automatically optimized, so that the new user can correspond to the proper access authority, and the cloud management platform can perform authority management and control on the access operation of the new user based on the access authority of the user group where the new user is located.

In one possible implementation manner, the method further comprises the steps of obtaining user information of the new user, inquiring at least one target user group close to the new user based on the user information of the new user, and determining the authority of the new user for accessing the cloud resource by taking the access authority corresponding to the at least one target user group as the access authority of the new user. In this way, the application gives the access right of the user group similar to the new user, and can realize the automatic generation of the access right of the new user, so that the technical scheme of the application can be applied to dynamically changed environments.

For example, each user group of the at least one target user group may include one or more users.

In one possible implementation, the method further comprises updating access rights of the new user in response to an access operation of the new user to the cloud resource. In this way, in the case that the access right of the new user may not be suitable, the cloud management platform may update the access right in real time according to the access behavior of the user (i.e., the access operation of the user to the resource), so as to reserve (or take effect) the suitable access right, and reject (or disable) the unsuitable access right.

In a second aspect, the present application provides a cloud management platform. The cloud management platform is used for managing an infrastructure providing cloud services, cloud resources are operated on the infrastructure, and comprises a resource model creation module, an acquisition module and an access authority generation module, wherein the resource model creation module is used for creating a resource model of the cloud resources, the resource model comprises an association relation between the cloud resources and access operations, the acquisition module is used for acquiring an access log of the cloud resources, the access log comprises user information of at least one user, resource information of the cloud resources and historical access operations, and the access authority generation module is used for generating access authorities according to the access log and the resource model, and the access authorities comprise authority of the at least one user to access the cloud resources.

In one possible implementation, the cloud resource includes a plurality of sub-resources, and the resource model creation module is configured to obtain a dependency relationship between the plurality of sub-resources. And establishing a resource model based on the dependency relationship between the cloud resource and the plurality of sub-resources, wherein the resource model comprises access operation, the cloud resource and the incidence relationship of the dependent sub-resources of the sub-resources.

In one possible implementation, the access rights further include rights of the at least one user to access dependent sub-resources of the sub-resource.

In one possible implementation, the cloud management platform is provided with an access interface for responding to target access operation of a target user to a target sub-resource, and the cloud management platform further comprises a permission control module for determining permission of the target user to the target access operation of the target sub-resource and permission of the target user to the target access operation of the target sub-resource dependent on the sub-resource based on the access permission and the target access operation.

In one possible implementation, the access right generation module comprises an access right generation unit, an access right generation unit and an access right generation unit, wherein the access right generation unit is used for grouping at least one user and a plurality of sub-resources based on an access log to obtain at least one user group and at least one cloud resource group, the access right generation unit is further used for generating access rights based on a resource model, the at least one user group and the at least one cloud resource group, and the access rights comprise the right of the at least one user group to access the at least one cloud resource group.

In one possible implementation manner, the access right generation module further comprises an access right optimization unit, wherein the access right generation unit is further used for generating initial access rights based on the resource model, at least one user group and at least one resource group, the initial access rights comprise the right of each user group to access operation of each resource group, and the access right optimization unit is used for responding to the access operation of at least one user to cloud resources to update the initial access rights and obtain the access rights.

In one possible implementation, the access right optimizing unit is specifically configured to respond to an access operation of at least one user to the cloud resources, update an initial access right and an access right preset by the user to obtain the access right, where the access right preset by the user is used to indicate a right of the at least one user to access all or part of the cloud resources in the cloud resources.

In one possible implementation, the access right optimizing unit is specifically configured to determine a weight value of the initial access right based on a preset rule and an access operation of at least one user to the cloud resource, and take effect that the weight value is greater than an access right of a preset threshold.

In one possible implementation, the access right generation module is further configured to obtain user information of a new user, add the new user to a target user group based on the user information of the new user, where the target user group is included in at least one user group, and the cloud management platform further includes a right control module configured to control a right of the new user to access the cloud resource based on an access right corresponding to the target user group.

In one possible implementation, the access right generation module is further configured to obtain user information of a new user, query at least one target user group close to the new user based on the user information of the new user, and the cloud management platform further includes a right control module configured to control the right of the new user to access the cloud resource by using the access right corresponding to the at least one target user group as the access right of the new user.

In a possible implementation, the access right optimizing unit is further configured to update the access right of the new user in response to an access operation of the new user to access the cloud resource.

In a third aspect, an embodiment of the present application provides a cluster of computing devices, including at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of the first aspect or any possible implementation of the first aspect.

In a fourth aspect, an embodiment of the application provides a computer program product comprising instructions which, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method of the first aspect or any of the possible implementations of the first aspect.

In a fifth aspect, an embodiment of the application provides a computer readable storage medium, comprising computer program instructions which, when executed by a cluster of computing devices, perform the method of the first aspect or any possible implementation of the first aspect.

Drawings

Fig. 1 is a schematic architecture diagram of a cloud system according to an embodiment of the present application;

FIG. 2 is a flow chart diagram of an exemplary illustrated access rights management method;

FIG. 3 is a schematic diagram illustrating an exemplary resource modeling flow;

FIG. 4 is a schematic diagram of an exemplary resource structure;

FIG. 5 is a schematic diagram of an exemplary resource;

Fig. 6 is a schematic view illustrating the structure of an access right;

Fig. 7 is a schematic structural diagram of an exemplary illustrated cloud management platform;

FIG. 8 is a schematic diagram of a structure of an exemplary computing device;

FIG. 9 is a schematic diagram of a structure of an exemplary computing device;

fig. 10 is a schematic diagram of an exemplary illustrated cluster of computing devices.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B may mean that a exists alone, while a and B exist together, and B exists alone.

The terms first and second and the like in the description and in the claims of embodiments of the application, are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, a plurality of processing units refers to two or more processing units, and a plurality of systems refers to two or more systems.

Before describing the technical scheme of the embodiment of the present application, first, the background technology related to the embodiment of the present application is briefly described:

the public cloud, which can also be called a public cloud system, is a cloud platform provided by public cloud providers of third parties for vast individuals or enterprises. In public clouds, hardware, software, and other structures are owned and managed by third party public cloud providers. Fig. 1 is a schematic structural diagram of an exemplary cloud system, please refer to fig. 1, which specifically includes, but is not limited to, public cloud and clients.

Illustratively, public clouds include, but are not limited to, cloud management platforms and infrastructure.

The cloud infrastructure, which is a hardware device for implementing various cloud services provided by the public cloud system to the outside, may include a plurality of data centers (DATA CENTER, DC) disposed in different geographical areas, each of which includes a plurality of physical servers, and each of which may be used to support various cloud services such as Virtual Machines (VMs), containers (dockers), bare metal servers, cloud hard disks, and the like. In addition, the cloud management platform is in communication connection with the cloud base equipment, so the cloud management platform can provide various cloud services supported by the cloud base setting for tenants to use.

The cloud management platform, which may also be referred to as a cloud platform or simply referred to as a cloud management platform, is a software system of cloud technology (also referred to as cloud computing technology) service provided by a cloud provider, and is used for managing an infrastructure for providing cloud services. Specifically, the cloud management platform provides an interface related to the cloud service for the tenant to remotely access the cloud service. The tenant can log in the cloud management platform on the cloud service access page through the pre-registered account number and password, and after the login is successful, the tenant selects and purchases the corresponding cloud service on the cloud service access page. In an embodiment of the present application, the tenant comprises at least one user. The tenant owns the primary account and the user owns the secondary account. In the following embodiments, the access scenario of the user to the cloud resource and the setting of the access authority (may also be referred to as an access policy) for the scenario of the user to access the cloud resource are all described, and in the embodiments of the present application, the tenant and the user may be replaced at will, and the description will not be repeated.

For example, the cloud management platform may provide various interfaces, such as a login interface and an access interface, for access by a client of the tenant (e.g., a terminal device used by the tenant or a browser on the terminal device used by the tenant, etc.). The terminal of the tenant may be referred to as an electronic device, a user device or a terminal device by way of example, and the present application is not limited thereto. Terminals include, but are not limited to, cell phones (mobilephone), tablet computers (Pad), computers, personal computers (personal computer, PC), devices in internet of things (internet of things, ioT) systems, and the like.

The cloud management platform may receive an account number and a password input by the tenant through the client through the login interface, so as to perform identity authentication on the client of the tenant, and the client of the tenant may be allowed to log in the cloud management platform after the authentication is passed.

Illustratively, the cloud management platform also provides an access interface. The access interface, which may be an API (Application Programming Interface ). The cloud management platform can allow the client of the tenant to send an access request to the cloud management platform through the access interface, wherein the access request is used for requesting to call a specified API. Illustratively, the client of the user accesses the cloud service on the cloud resource by calling the API, essentially the user wants to perform a business action by performing a specific operation (i.e., access operation) on a certain cloud resource. An application program interface is a collection of definitions, functions, procedures and/or protocols. For example, an application program interface of the cloud management platform includes one or more system calls (SYSTEM CALL), each of which is a program that performs a particular function. Accordingly, in the embodiment of the present application, the cloud management platform calls the designated API in response to the access request sent by the client of the tenant and received by the access interface, which may also be understood as that the cloud management platform performs the access operation on the corresponding cloud resource in response to the access request of the tenant.

Cloud services including computing services, storage services, virtual machine services, web services, and the like. The devices or functions that the user device can access through the cloud management platform can be regarded as services provided by public cloud.

Cloud resources, hardware resources (which may also be referred to as cloud infrastructure or infrastructure) and software resources (which may also be referred to as public cloud services) for providing services. For example, the hardware resources corresponding to software resources such as computing services, storage services, or network services include computing resources, storage resources, or network resources. Optionally, the computing resources include central processing unit (CPU, central processing unit) resources, memory resources, and/or hard disk resources, etc. For example, a user (may also be called a tenant) purchases a large amount of virtual machine resources, and a large amount of applications (may also be called cloud applications) are deployed on the virtual machine resources, in this example, the virtual machine and the applications in the virtual machine belong to cloud services (i.e. software resources), and devices such as a server to which the virtual machine belongs are corresponding hardware resources.

In the embodiment of the application, the cloud management platform can be deployed with an access right management system (or can be called as an access right control system, the application is not limited), and the access right management system is used for generating access rights (or can be called as an access policy, the application is not limited) and performing right management on access behaviors (or access requests) of users based on the access rights. Wherein, the access behavior (or access request) of the user is used for indicating the access operation of the user to the cloud resource. Rights management includes allowing or denying a user access to a cloud resource.

By way of example, taking the access rights design in an ECS (Elastic Compute Service, elastic computing service) as an example, suppose a user creates a cloud server to provide a cloud service. An operation and maintenance person (also understood as an employee of an operation and maintenance department) in the tenant needs to have authority to restart the cloud server, while other roles in the tenant (e.g., an employee of a business department or an employee of a personnel part) do not need to have authority to restart the cloud server. Then, the API for restarting the cloud server is called, which may be understood as that the operation of restarting the cloud server is performed, and then permission control is required. That is, in this example, the operation and maintenance personnel have the right to call the API to restart the cloud server, the cloud management platform allows the operation and maintenance personnel to restart the cloud server, while the other personnel do not have the right to call the API, i.e., the cloud management platform does not allow the other personnel to restart the server.

In the embodiment of the present application, the access rights management system is disposed in a cloud system (specifically, a cloud management platform) as an example. In other embodiments, the technical solutions in the embodiments of the present application may be applied to other system architectures as well, and the present application is not limited thereto.

The following describes the access right management method in the embodiment of the present application in detail. Fig. 2 is a flow chart illustrating an exemplary access rights management method, please refer to fig. 2, which specifically includes, but is not limited to, the following steps:

s201, the cloud management platform establishes a resource model of cloud resources.

For example, in a cloud system, control of access rights is generally uniformly managed, and if an API needs to be authenticated (i.e. whether a user is given access rights to the API), resources corresponding to the API and resources related to the API (i.e. resources on which each resource depends in the embodiment of the present application) need to be carded.

By way of illustration, assume that a user needs to create a virtual machine, and the API that he calls is the API that the "create virtual machine" corresponds to. Wherein "create" is an access operation and "virtual machine" is an access object, that is, the "create virtual machine" API is used to perform "create" operations on "virtual machine" resources. The resource corresponding to the API is the virtual machine, the corresponding access operation is 'creation', and the system creates a virtual machine to allocate network resources and storage resources for the virtual machine, and correspondingly, calls the 'creation virtual machine' API, and also depends on the 'creation network resources' API and the 'creation storage resources' API. That is, in the scenario where a user needs to create a virtual machine, the user needs to have "create virtual machine" rights, and also needs to have "create network resources" rights and "create storage resources" rights, which can also be understood as having the rights to call "create virtual machine" APIs, call "create network resources" APIs, and call "create storage resources" APIs. The cloud management platform performs authentication one by one for all relevant resources, and can only confirm whether the operation of calling the API is feasible, namely, whether the user is allowed to call the 'create virtual machine' API so as to create the virtual machine is judged.

Based on the above, in the embodiment of the application, the cloud resources, the dependency relationship of each resource in the cloud resources and the corresponding access operation are combed, and a unified resource model is established, so that the rationality of the subsequently generated access rights is improved, and the omission of the access rights is avoided. And normalizing cloud resources and corresponding access operations provided by the public cloud so as to facilitate the setting of the access operations on the API, and normalizing subsequently generated access rights so as to facilitate unified management and authentication.

Fig. 3 is a schematic diagram illustrating the establishment of a Resource model, please refer to fig. 3, when the Resource model is established, the cloud management platform uses all cloud resources (including, but not limited to, business applications and data resources, etc.) available to the tenant (i.e., user) in the public cloud as resources (resources). The cloud management platform can acquire the resources on which each resource depends based on the dependency relationship among the resources. Accordingly, the cloud management platform builds a resource model based on the resources (i.e., cloud resources) and the resources on which each resource (which may be referred to as a child resource in the embodiment of the present application) in the cloud resources depends. The resource model comprises the association relation of resources, dependent resources and access operations.

The flow in fig. 3 is described in detail below:

in an embodiment of the present application, a cloud resource in a cloud system (i.e., public cloud) may include a plurality of sub-resources, which are service data or domain objects observed from a client. In an e-commerce system, it may be a customer, an order, and an order details. In a cloud infrastructure system, sub-resources may be resource objects such as computing, networking, and storage. The specific entities of the sub-resources can be set according to actual requirements, the types and the quantity of the resources provided by different scenes and different services are different, and the corresponding resource models are also different, so that the application is not limited.

In the embodiment of the present application, each sub-Resource is regarded as a Resource (Resource). The cloud management platform maps each Resource (Resource) into a standardized common vocabulary. Similarly, for access operations allowed by the cloud management platform to be executed by a user on a cloud Resource (i.e., resource), the cloud management platform maps each access operation to a standardized public vocabulary, so that standardized naming is performed on the Resource and the access operation, and a uniform Resource model is built.

Specifically, the cloud management platform may obtain the resources and the information (including, for example, names, types, etc.) of the resources existing in the public cloud based on traversing the configuration file and the like. Wherein, the configuration file can be preconfigured by an operator. For example, an operator may configure resources that require permission control (or access control) based on the cloud management platform interface described above. The cloud management platform generates a configuration file based on the received user instruction, and at least one resource needing to be subjected to access control is recorded in the configuration file. Optionally, the at least one resource configured by the user may be all resources in the system or may be part of resources, which is not limited by the present application. That is, in the embodiment of the present application, access control may be performed on all resources in the cloud management platform, or only on a portion of resources indicated by the user.

The cloud management platform further obtains access operations corresponding to each resource based on the configuration file and the like, and can also be understood as access operations which the cloud management platform allows tenants (or users) to execute on the resources. Such as Create (also known as add) (Create), delete (Delete), update (Update) (also known as modify), query (Show), list (List), etc. The resources, the access operations, and the correspondence between the resources and the access operations in the embodiments of the present application are merely illustrative examples, and may be set according to actual requirements, which are not limited by the present application.

In the embodiment of the present application, the resource model is used to represent the correspondence between the resource and the access operation (may also be understood as the association relationship, etc., and the present application is not limited thereto). It is also understood that a resource in the resource model contains an authorized object (i.e., access to the resource) and a set of operations (i.e., at least one access operation) defined on the authorized object. After the cloud management platform determines the resources and the access operations corresponding to the resources, naming the resources and the access operations according to preset standardized names, and acquiring the corresponding relation between the resources and the access operations.

By way of illustration, table 1 is a standardized model for a resource for one general "Instance" (Instance) shown by way of example.

TABLE 1

action	List、Show、Create、Update、Delete
		Resource name	Instance

Referring to Table 1, an Instance of the resource name "Instance" on which access operations are defined include, but are not limited to List, show, create, update, delete, it being understood that access operations that the system allows to be performed on the Instance include, but are not limited to, list, show, create, update, delete, etc. Alternatively, the resource name of the Instance is merely an exemplary example, and in other embodiments, the Instance may be named according to a preset name, for example, the resource name may be "address book", the corresponding access operation may be "Create, update, show, delete", etc., which is not limited by the present application.

Next, the cloud management platform obtains the dependency relationship between the resources (which may also be referred to as child resources) to determine the resources on which the resources depend. The cloud management platform further establishes a resource model based on the obtained standardized model based on the resource-dependent resources.

Fig. 4 is a schematic diagram illustrating an exemplary resource structure, please refer to fig. 4, wherein the public cloud provides an "Instance" resource, and the public cloud further provides APIs corresponding to the Instance resource, including but not limited to CREATEINSTANCE, UPDATEINSTANCE, DELETEINSTANCE, SHOWINSTANCE and LISTINSTANCE. The operation objects corresponding to the APIs are Instance. The cloud management platform can characterize the API based on the resource model, namely, the access object and the access operation in the API are mapped, and the standardized representation mode of the API is obtained. Standardized representations include, but are not limited to, API names, access operations, access resources, and the like.

By way of example, table 2 is an exemplary illustrated API:

TABLE 2

Name of the name	Resource (resources, i.e. access to resources)	Action (operation, i.e. access operation)
			CreateInstace1	Instance1	Create
DeleteInstace1	Instance1	Delete
			CreateInstace2	Instance2	Create
ShowInstace2	Instance2	Show
			...	...	...

Referring to table 2, the name of the API is typically named by the resource+operation method of the API, but may be named by other naming methods, which is not limited by the present application. The resource is the resource called by the API (i.e. accessing the object or the resource), and the operation is the access operation executed by the API on the resource.

Wherein table 2 may be considered as part of the resource model or as an initial resource model. In the following flow, the cloud management platform further queries the dependency relationship between each resource (may also be referred to as a child resource), and obtains a resource model based on the obtained dependency relationship. It can also be understood that the initial resource model is supplemented to generate a resource model including the association relationship of the resource, the dependent resource and the access operation, so that the subsequently generated access rights further include the rights of the dependent resource of the at least one user to access the sub-resource.

Specifically, there is an interdependence between resources, and as described above, if the user calls the "create virtual machine" API, the system performs the business action of "create virtual machine", and needs to call other resources, such as network resources and storage resources. Therefore, in the embodiment of the application, after the cloud management platform acquires the resource model, the dependency relationship between the resources is further clarified, and the resource model is built based on the dependency relationship between the resources, so that the cloud management platform can perform association control on the associated API when a user calls a certain API. That is, the access rights further include rights of at least one user to access the dependent resource of the sub-resource, and accordingly, when the cloud management platform responds to the target access operation of the target user to a certain sub-resource (or may be referred to as a target sub-resource), the rights of the target user to the target access operation of the target sub-resource can be determined based on the access rights, and the rights of the target user to the target access operation of the dependent sub-resource of the target sub-resource can be determined, so as to realize associated control on the access operation of the resource on which the sub-resource depends.

In the embodiment of the application, the dependency relationship between different resources (namely sub-resources) can cause the same dependency relationship between corresponding APIs. Correspondingly, the cloud management platform can determine the dependency relationship between APIs based on the dependency relationship between the resources, and obtain a resource model based on the dependency relationship between the APIs. For example, fig. 5 is a schematic diagram of resources shown in an exemplary manner, please refer to fig. 5, in which the cloud management platform may card out a dependency relationship between each Resource based on a configuration file, for example, there is a dependency relationship between Instance1 (which may be a Resource such as a virtual machine, etc., without limitation, and resources such as a network disk, a storage, etc., without limitation, etc.). As shown in table 3:

TABLE 3 Table 3

Referring to table 3, based on the dependency relationship between resources, the cloud management platform may determine that the API of "CreateInstance1" depends on the API of "CreateResource1" and the API of "CreateResource 2". That is, if the cloud management platform needs to call the API of "CreateInstance1", it needs to further call the API of "CreateResource1" and the API of "CreateResource".

Alternatively, in the embodiment of the present application, only one API corresponds to one resource and one access operation is described as an example, and in other embodiments, the API may also correspond to one resource and multiple access operations, which is not limited by the present application.

Thus, the cloud management platform in the application can acquire a uniform resource model so as to set an access control strategy (namely, access right) for the API. And the dependency relationship between the resources is clarified, and the dependency relationship between the APIs is further clarified, so that the association control between the APIs is realized. In the embodiment of the application, the Resource and the access operation are mapped to obtain the corresponding standardized API (which can be also understood as the characterization processing of the API), so that the complex access authority is converted into the corresponding relation between Resource and Action.

S202, the cloud management platform acquires an access log of cloud resources.

In the embodiment of the application, the cloud management platform collects access logs. The access log comprises user information of a user, resource information of cloud resources and access operation. Specifically, the cloud management platform responds to an access request of a user, acquires information such as user information, an access object, access operation and the like included in the access request, and generates a corresponding access log. It is understood that each of the access logs (which may also be referred to as a log entry) is used to describe a user's one-time access behavior to cloud resources. Optionally, the log cached by the cloud management platform may include multiple types of log information, including, for example, an access log, an alarm log, and the like, which is not limited in the present application, and in the embodiment of the present application, the cloud management platform only obtains the access log.

And S203, the cloud management platform generates access rights according to the access log and the resource model.

In the embodiment of the application, the cloud management platform can group users, resources, access operations (also referred to as historical access operations or user access operations) and the like related in the access log based on the access log. Alternatively, the set of access operations to the resource included in the access log may be less than or equal to the set of access operations corresponding to the resource in the resource model. For example, in the resource model, the access operation to the resource 1 includes access operations a to D, and only access operation a and access operation C to the resource 1 may occur in the access log, that is, in the access log counted by the cloud management platform, the user does not perform access operation B and access operation D to the resource 1.

The cloud management platform may generate access rights based on the grouping results (e.g., user groups and resource groups) and the resource model. Correspondingly, the access rights comprise the rights of the user group to access the resource group. In the embodiment of the application, the group is taken as granularity to generate the access rights, so that the rights of users and resources with the same attribute can be uniformly managed, and the access rights with proper granularity can be provided.

Specifically, the process of generating the access right may be divided into two parts, where the first part is to generate the initial access right according to the access log and the resource model. The second part is to update (also called optimizing) the initial access rights to obtain access rights (also called access policy).

The following description is made of the above two parts:

and the first part is used for generating initial access rights according to the access log and the resource model.

The cloud management platform extracts key information in the access log based on the acquired access log. It may be understood that the access log includes some critical information and some non-critical information, where in the embodiment of the present application, the critical information is defined as information used for generating access rights, and conversely, the non-critical information is some information not used for generating anti-query rights. By way of example, the key information includes, but is not limited to, user information, access operations, access objects, access times, etc.

Optionally, the user information is used for identifying the users, and the user information of each user is different and unique. The user information includes, but is not limited to, at least one of user identification information, user address information, user identity information, and the like.

The user identification information may include, but is not limited to, at least one of a user name, a user ID, a device ID, etc.

The user address information may include, but is not limited to, at least one of device IP address, device MAC address, etc.

The user identity information may include, but is not limited to, at least one of a department in which the user is located, a project group to which the user belongs, a virtual private cloud (Virtual Private Cloud, VPC) ID, and the like. Alternatively, the user identity information may be obtained from a log, or may be obtained from other user files, which is not limited by the present application.

The access object is used for indicating the resource object corresponding to the user behavior (also called as the access behavior) represented by the access log. Alternatively, in the system of the Restful interface, the access object may be a URL or the like in the API information, and the present application is not limited.

And the access operation is used for indicating the access operation corresponding to the user behavior represented by the access log, namely the Action.

The access time is used for indicating the access time or the access duration. The information is mainly used for filtering some accidental traffic at the subsequent stage, and misjudgment of the accidental traffic on the establishment of access permission is avoided.

Optionally, condition (Condition) information may be further included in the access log, for indicating the access Condition. It is understood that a user having certain conditions (i.e., a specific user) can perform an access operation on a certain resource. For example, some resources are only accessible when a particular user is under a particular IP (i.e., condition). That is, the same user cannot access the resource if not under a specific IP, and in this example, contains a Condition information, i.e., { ip= $ { IP }. Optionally, the Condition information is usually some keywords preset by the cloud management platform.

The cloud management platform builds a user feature vector based on the acquired user information, wherein the feature vector is as follows:

(user_name,user_id,devide_id,ip,dept_no,project_id,vpc_id)

The user_name is used for indicating a user name, the user_id is used for indicating a user ID, devide _id is used for indicating a device ID, the dept_no is used for indicating a department to which the user belongs, the project_id is used for indicating an item group to which the user belongs, and the vpc_id is used for indicating a VPC ID.

Illustratively, the cloud management platform maps the key information to access vectors based on the resource model. Wherein the access vector represents a correspondence between the user, the resource, and the access operation. It may be understood that, the resource model is used to represent an association relationship between a resource (here, an access resource appearing in a log may not include a dependent resource involved in an access process) and an access operation, and the cloud management platform may map information in the access log into the same form as the resource model based on the access log and the resource model, so as to obtain the association relationship among a user, the resource and the access operation.

Specifically, the cloud management platform may map the user feature vector to a user identifier, e.g., U1, U2, etc. For example, the cloud management platform may map feature vectors (user_name, user_id, devide _id, ip, dept _no, project_id, vpc_id) to U (other identifiers are possible, the present application is not limited) to characterize a user by a standardized user identifier.

Correspondingly, the cloud management platform maps the key information according to the standardized definition of the resource model to obtain a vector (which may also be referred to as an access vector) corresponding to each key information, where the vector is used to represent a corresponding relationship among a user, an access operation, a resource, and other information (such as conditions), and the vector may be expressed as:

<User,Action,Condition,Resource>

That is, the mapped vector may be used to represent the association relationship of the user, the access operation (Action), the Resource (Resource), and the Condition (Condition).

Illustratively, as described above, the resource model further includes an association relationship between the dependent resource of the child resource and the access operation, which may also be understood as an association relationship between each API and the dependent API. The cloud management platform may further generate an access vector based on the dependencies between APIs in the resource model, the access vector having been complemented. It can be understood that the cloud management platform generates an access vector based on the access log, which represents an association relationship among the user, the resource accessed by the user, and the performed access operation. As described above, there is a dependency relationship between resources, assuming that the user desires to access Resource1, and Resource1 depends on Resource2, and accordingly, the user needs to have the right to call the API of Resource1 and the right to call the API of Resource 2. In some scenarios, however, the access log may only record the relevant records of the user accessing Resource1, and not records the records of other APIs called during the call to the API of Resource 1. Thus, to ensure the integrity and coverage of generating access rights, the cloud management platform may further generate an access vector based on the dependencies between APIs in the resource model to obtain a complete access vector including the resources, the dependent resources of the resources, and the associations between the access operations.

Specifically, after the cloud management platform obtains the access vectors corresponding to the access logs (i.e., the key information), the cloud management platform may query whether the vectors corresponding to the APIs with the dependency relationships are absent from the access vectors based on the dependency relationships of the APIs in the resource model (i.e., the association relationships between the dependent resources of the resources and the access operations). If it is missing, the corresponding access vector is supplemented.

Taking the API dependency relationship in table 3 as an example, assume that the access vector currently acquired by the cloud management platform includes:

<U1,Create,Instance1>

<U1,Delete,Instance1>

......

The cloud management platform determines that the API "CreateInstance1" depends on the API as "CreateResour1" and "CreateResource2" based on < U1, create, instance1> in the resource model. The cloud management platform traverses the generated access vectors to detect whether the access vectors corresponding to < Create, resource1> and < Create, resource2> are included. If not, the corresponding vector is supplemented into the access vector. Optionally, the user corresponding to the supplemented access vector may be any user, and the supplementing step mainly avoids omitting related API access rights in the subsequently generated access rights.

In one possible implementation, the cloud management platform may further refine the obtained access vector based on the resource model. As described above, the set of resources and access operations in the access log may be less than or equal to the set of resources and access operations in the resource model. For example, the resource model includes a correspondence of { R3, delete }, i.e., the cloud management platform allows the user to perform Delete operations on R3. Assuming that only a manager in the tenant can execute the Delete operation on the R3 resource, and the manager does not execute the Delete operation on the R3 resource in the access log acquired by the cloud management platform. That is, the cloud management platform does not include the correlation vector of < Delete, R3> in the access vector generated based on the access log. In this example, the cloud management platform may determine a lack of a < Delete, R3> related vector based on the resource model, and the cloud management platform may generate a corresponding vector, e.g., < U1, delete, R3>. Here, only the vector assignment to U1 is taken as an example, and may be assigned to any user, so that the initial access right generated later has < Delete, R3> associated access rights.

The cloud management platform groups at least one user in the tenant and a plurality of sub-resources in the cloud resource based on the access log, so as to obtain at least one user group and at least one cloud resource group (may be simply referred to as a resource group). Specifically, the cloud management platform performs cluster analysis on the access vector based on the access log to obtain a user group and a resource group. For example, the cloud management platform may perform cluster analysis on the access vectors that have been acquired based on the access log (may also be key information) to determine whether there is a common characteristic between users, and whether there is a common characteristic between resources.

In one example, the manner in which the common characteristics between users are found may be based on user information of the users, i.e., the common characteristics are user attributes. For example, users of the same department may be grouped together, users of the same project group may be grouped together, and users of the same IP may be grouped together.

In another example, the way to find common characteristics between users may be based on access behavior, i.e. the common characteristics are the same or similar access behavior. For example, the access behaviors of multiple users are highly similar, e.g., the access records of U1 and U2 each indicate that a "Create" operation is performed on Resource1, and U1 and U2 may be divided into a group.

In one example, the way to find the common characteristic between resources may be based on the dependency of the resources, i.e. the common characteristic is a dependency. For example, resources with dependencies may be partitioned into a group.

In another example, the way to find the common characteristic between resources may be based on the access situation of the resources, i.e. the common characteristic is an access behavior. For example, the same user (or group of users) always has access to the same plurality of resources, which may be divided into a group.

It should be noted that, in the embodiment of the present application, the rule (i.e. the common characteristic) of dividing the user group and the resource group is merely an exemplary example, and in other embodiments, the rule may be set according to actual requirements, and the present application is not limited thereto.

Optionally, the cloud management platform may also group other information such as access operations and conditions, and grouping conditions (i.e. common characteristics) may be set according to actual requirements, which is not limited by the present application.

Alternatively, each user corresponds to a separate group of users, and each resource also corresponds to a separate group of resources. For example, U1 and U2 are divided into the same user groups G1, U1 and U2 each corresponding to a single user group, i.e., user groups including, but not limited to, { U1}, { U2}, G1 = { U1, U2}.

Illustratively, the cloud management platform generates the access rights based on the resource model, the at least one user group, and the at least one resource group. Specifically, the cloud management platform generates an initial access right (may also be referred to as an alternative access right or the like) based on the resource model, at least one user group and at least one resource, and the application is not limited thereto. The initial access right is used to indicate the right of each user group to access each cloud resource group, which can be understood to cover the rights corresponding to all possible combinations among the user groups, the cloud resource groups and the access operations (which may also include other parameters such as conditions).

The embodiment of the application has larger authority control range of the initial access authority, and aims at comprehensively covering the API possibly needing authority control in the system as much as possible. Under the conditions of large authority control range and wide coverage of the initial access authority, the initial access authority is updated (or optimized) to reduce unnecessary access authority, so that the granularity of the access authority is reduced and the missing of the access authority is avoided. It may be understood that the initial access rights generated in the embodiment of the present application may set up corresponding access rights for all resources that may be accessed by each user and all access operations that may be performed, that is, set up access rights for each API that may be called by the user, and especially set up access rights including APIs corresponding to resources with dependencies. The initial access rights are then updated (or optimized) to eliminate unnecessary access rights. The access right with proper granularity can enable the system to accurately control the access behavior of the user based on the access right, the integrity of the access right can reduce the attack area, and the system security is improved.

Illustratively, the access rights may be categorized as identity-based access rights or resource-based access rights. Identity-based access rights are used to control which operations a visitor (e.g., user group, project group, etc. color identity) can perform on those resources under those conditions. Resource-based access rights are rights for granting a specified visitor a specific access operation to a specified resource and define under which conditions this right is used. The above two access rights are only illustrative examples, and other access rights may be used in other embodiments, and the present application is not limited thereto.

In the embodiment of the present application, taking resource-based access rights as an example, it is assumed that the definition of access rights is as follows:

the access rights indicate that the user with (alloy) userID o-xxxxxxxxxxx is allowed to perform operations "ShowInstance" and "LISTINSTANCE" on the resource (ecs: cn-north-1: instance).

In one possible implementation, the cloud management platform may obtain the initial access rights based on the user group and the resource group in a cartesian product manner. Each of the initial access rights is used to represent a correspondence between a user group, a resource group, and an access operation. For example, assume UserGroup includes U1, U2, and an Action includes Create, show. Condition messages include g DomainId and g DomainName, resource Group including R1, R2.Effect includes an Allow, deny (rejection). Based on the set, a Cartesian product is generated, and the resulting initial access rights include, but are not limited to:

(U1,Create,g:DomainId,R1,Allow)

(U1,Create,g:DomainId,R1,Deny)

(U1,Create,g:DomainId,R2,Allow)

(U1,Create,g:DomainId,R2,Deny)

(U1,Create,g:DomainId,R1,Allow)

(U1,Create,g:DomainId,R1,Deny)

(U1,Create,g:DomainId,R2,Allow)

(U1,Create,g:DomainId,R2,Deny)

(U1,Create,g:DomainName,R1,Allow)

(U1,Create,g:DomainName,R1,Deny)

(U1,Create,g:DomainName,R2,Allow)

(U1,Create,g:DomainName,R2,Deny)

......

In another possible implementation, the cloud management platform may generate the initial access rights based on the access log (i.e., key information) and the resource model. Specifically, the cloud access management platform may extract the user based on the key information, and map the user to a specified user identifier, such as U1, U2, and the like. The cloud management platform may generate a corresponding access vector based on the user in combination with each resource in the resource model and the corresponding access operation. For example, assuming that there is a U1 user, the resource model is shown in table 1, and accordingly, the cloud management platform may generate the following access vectors:

<U1,List,Instance>

<U1,Show,Instance>

<U1,Create,Instance>

<U1,Delete,Instance>

<U1,Update,Instance>

the cloud management platform may group users, resources, etc. based on the access log, and the grouping manner may refer to the above, which is not described herein. This way of access rights generation may not refer to API dependencies, that is, all possible APIs are already covered in the resource-based generated vector. Other processing steps are the same as those in the above embodiments, and will not be described here again.

In yet another possible implementation, if access rights already exist in the cloud management platform, for example, the access rights already existing are set by the user, the rights for controlling at least one user to access all or part of the cloud resources (i.e., sub-resources) in the cloud resources. The cloud management platform can acquire the generated access rights, and the generated access rights and the initial access rights which are newly generated based on the mode are subjected to a subsequent optimization step. Optionally, the cloud management platform may skip the step of generating the access right, and directly execute a subsequent optimization procedure on the access right preset by the user, so as to improve accuracy of the preset access right.

And a second part, updating (or optimizing) the initial access rights to obtain access rights (which can also be called access policy).

In the access right optimizing stage, the cloud management platform optimizes the initial access right in real time or periodically so as to reduce the granularity of the access right and obtain the access right with fine granularity.

Specifically, the cloud management platform responds to the access operation (which can be understood as the access behavior of the user) of the user to the cloud resource, and optimizes the initial access right to obtain the access right. Specifically, the cloud management platform evaluates each access right based on the access behavior of the user, reduces unnecessary access rights based on the evaluation result, reduces the range of coarse-granularity access rights, and obtains the range of fine-granularity rights, so as to improve the security of the system and reduce the risk of the system. Moreover, the optimization mode is an automatic mode, and can be applied to a scene of a large-scale multi-user cluster, so that the configuration efficiency of the access right is effectively improved. In addition, in the optimization process, the cloud management platform optimizes and adjusts the access rights in real time according to the access behaviors of the users, so that the access rights can be dynamically adjusted according to the continuously-changing environment and threat, and the safety of the system is effectively improved.

Specifically, the cloud management platform may acquire the access log of the user in real time or periodically, which may also be understood as monitoring the access behavior of at least one user in the tenant. Optionally, based on different optimization modes, the cloud management platform may set different monitoring conditions to extract access logs meeting the monitoring conditions. After the cloud management platform extracts the access log meeting the monitoring condition, corresponding key information can be extracted based on the resource model in the manner described above, including but not limited to user information, access operation, access resource, access time and the like.

The cloud management platform is preset with optimization conditions (which can also be called as optimization rules or preset rules, the application is not limited), the optimization conditions are used for indicating to reserve the access rights meeting the conditions, and the access rights not meeting the conditions are removed. The cloud management platform may obtain a weight value of each access right in the initial access rights based on the optimization condition and the user access behavior (i.e., the access operation of at least one user to the cloud resource), and optimize the initial access rights based on the weight values. Optionally, the cloud management platform may set a scoring standard, add 1 to a weight value (i.e. score) of the access right that satisfies the optimization condition (or other values, which is not limited by the present application), and subtract 1 to a weight value (i.e. score) of the access right that does not satisfy the optimization condition. Then, the cloud management platform evaluates each access right based on the scoring result (i.e. the weight value) of each access right.

In the embodiment of the application, the cloud management platform takes effect (or understands that the access rights of which the scoring result (namely the weight value) is larger than or equal to a preset threshold value are reserved), and takes effect (or understands that the scoring result is removed) and is smaller than or equal to the access rights of which the scoring result is smaller than or equal to the preset threshold value. Optionally, in the embodiment of the present application, the "reserved" access right may be understood as the access right being validated, the "removed" access right may be understood as the corresponding access right being invalidated, the "removed" access right may also exist in the access right, and may be understood as the alternative access right being invalidated (or not validated), where the "removed" access right may be validated in the process of real-time optimization of the present application, and the present application is not limited thereto.

In the following, several optimization modes are provided, and it should be understood that the optimization modes in the embodiments of the present application are only illustrative examples, and in other embodiments, different optimization conditions may be set according to actual requirements, and the present application is not limited thereto.

Optimization mode 1)

For example, the optimization conditions in this approach may be based on an evaluation sample. For example, there are currently 100 users, and an operator may set an evaluation sample, where the evaluation sample optionally sets corresponding access rights for 10 users (10% of the total number of users in the embodiment of the present application, which is merely illustrative and not limiting). For example, A1 can perform a Create operation on R1, and not perform a Delete operation on R1, and the corresponding access rights included in the evaluation sample are < A1, create, R1, allow >, < A1, delete, R1, deny >. The cloud management platform may score each of the current access rights based on the evaluation sample. If it is consistent with the rights required to evaluate the access rights in the sample, then the access rights may be added 1 point (for illustrative purposes only). If it is not consistent with the rights required to evaluate the access rights in the sample, the access rights may be decremented by 1 (for illustrative purposes only). That is, if the user who is originally prohibited from accessing has access rights under the new access rights, the access rights are reduced by 1 point.

For example, the evaluation sample above is still taken as an example. Let A1 belong to G1, G2 and G3 groups in the initial access rights generated by the cloud management platform. The initial access rights include, but are not limited to:

<G1,Create,R1,Allow>

<G1,Create,R1,Deny>

<G1,Delete,R1,Allow>

<G1,Delete,R1,Deny>

<G2,Create,{R1,R2},Allow>

<G2,Create,{R1,R2},Deny>

<G2,Delete,{R1,R2},Allow>

<G2,Delete,{R1,R2},Deny>

<G3,Create,R1,Allow>

<G3,Create,R1,Deny>

<G3,Delete,R1,Allow>

<G3,Delete,R1,Deny>

Correspondingly, the cloud management platform determines <G1,Create,R1,Allow>、<G1,Delete,R1,Deny>、<G2,Create,{R1,R2},Allow>、<G2,Delete,{R1,R2},Deny>、<G3,Create,R1,Allow>、<G3,Delete,R1,Deny> that the evaluation condition is met based on the evaluation sample, and the score (i.e. the weight value) of each initial access right is increased by 1. And, it is determined <G1,Create,R1,Deny>、<G1,Delete,R1,Allow>、<G2,Create,{R1,R2},Deny>、<G2,Delete,{R1,R2},Allow>、<G3,Create,R1,Deny>、<G3,Delete,R1,Allow> that the evaluation condition is not satisfied, and the score (i.e., the weight value) of each initial access right is subtracted by 1.

Optimization mode 2)

By way of example, the optimization conditions in this approach may be based on the access time duration. For example, the optimization condition includes a preset access duration (for example, may be 1 day or 1 week, and the application is not limited thereto), and if no access behavior corresponding to a certain initial access right is detected within the preset access duration, the access right is removed (the right of Deny may be reserved, the right of alow is removed), which may also be understood as that the access right is redundant.

By way of example, initial access rights include, but are not limited to:

<G1,Create,R1,Allow>

<G1,Create,R1,Deny>

the cloud management platform responds to the access operation of the tenant (i.e. at least one user) to the cloud resource, determines that the Create request of G1 to R1 is not detected within the preset access time, and can also be understood as that the user in G1 is not detected to call the API of 'CreateR 1', and correspondingly, the cloud management platform can consider that the two initial access rights are redundant. Alternatively, the cloud management platform may decrease the score (i.e., weight value) of the access rights for a long miss by 1.

In some instances, the cloud management platform may reject (i.e., disable) both initial access rights. In other examples, the cloud management platform may retain (i.e., validate) < G1, create, R1, deny > initial access rights, and reject (i.e., invalidate) < G1, create, R1, alloy > initial access rights.

Optimization 3)

The optimization conditions for this approach may be based on attack area, for example. The attack area is optionally the number of resources accessible to the user, and the more resources the user can access, the larger the attack area the system receives, and the score (i.e. the weight value) of the corresponding access authority is subtracted by 1 by the cloud management platform. Otherwise, the fewer the resources that the user can access, the smaller the attack area that the cloud management platform receives, and the cloud management platform adds 1 to the score (i.e. the weight value) of the corresponding access right. Specifically, the cloud management platform takes effect of the initial access rights one by one to detect the influence of the initial access rights on the access behavior of the user.

By way of example, assume that initial access rights include, but are not limited to:

<G1,Create,R1,Allow>

<G1,Create,R1,Deny>

The cloud management platform validates the access rights of < G1, create, R1, allow > and invalidates the access rights of < G1, create, R1, deny >. In the process of taking effect of the access authority (the effective time length can be set according to actual requirements, the application is not limited), the cloud management platform acquires key information corresponding to the access log in real time or periodically, and the key information is used for describing the access operation of a user to the cloud resource. The cloud management platform can determine access behaviors executed by all users in the G1 user group, including which access operations are executed on which resources, in the process that the access authority of the current < G1, create, R1, and Allow > takes effect based on the acquired key information, namely the access operations of the users on the cloud resources. The cloud management platform may count the number of resources accessed by the G1 user group, including 10 resources, for example. Then, the cloud management platform disables the < G1, create, R1, alloy > access rights and validates the < G1, create, R1, deny > access rights. In the process of validating the access right (the validation time can be set according to actual requirements, the application is not limited), and the cloud management platform acquires key information corresponding to the access log in real time or periodically. The cloud management platform can determine, based on the obtained key information, access behaviors executed by all users in the G1 user group, including which access operations are executed on which resources, in the process that the access rights of the current < G1, create, R1, deny > take effect. The cloud management platform may count the number of resources accessed by the G1 user group, including 4 resources, for example. Correspondingly, the policy cloud management platform can determine that the number of resources accessed by the G1 user group is larger than that of the < G1, create, R1, deny > under the condition that the < G1, create, R1, allow > is effective. That is, < G1, create, R1, allow > is effective, and the corresponding attack surface is larger. Thus, the cloud management platform subtracts 1 from the score (i.e., weight value) of the < G1, create, R1, alloy > access rights, and adds 1 to the score (i.e., weight value) of the < G1, create, R1, deny > access rights.

In one possible implementation manner, if alarm information is generated in the access log in the process of validating the access rights, the score corresponding to the access rights is subtracted by 1 correspondingly. For example, in some examples, if the attack surface corresponding to the access right is smaller, but an alarm is triggered, that is, the alarm information is included in the access log, and accordingly, the score corresponding to the access right is subtracted by 1.

The cloud management platform may reserve (or take effect of) access rights with a score greater than or equal to a preset threshold (which may be set according to actual needs, without limitation, and reject (or fail) access rights with a score less than or equal to the preset threshold, so as to obtain access rights with appropriate granularity, based on the scoring result (i.e., the weight value of each access right).

Optionally, the cloud management platform may perform weighting processing on the scores of the access rights to obtain corresponding score results (which may also be referred to as evaluation results or evaluation results, which is not limited by the present application). For example, the cloud management platform may obtain a scoring result of the access rights based on the following formula to determine whether the access rights are reasonable:

wherein, α _i is a harmonic coefficient, S _threshold is a threshold for judging sensitive information, which can be set according to actual requirements, and the application is not limited.

After the cloud management platform acquires the access rights, the cloud management platform stores the access rights. And the cloud management platform performs authority control on the access behavior of the user calling the API received each time based on the access authority, namely performs authority control on the access operation of the user accessing the cloud resource each time so as to detect whether the user is allowed to access the corresponding cloud resource or not, and can also be understood as whether the user is allowed to call the corresponding API or not.

In the embodiment of the application, the cloud management platform can optimize the access rights in real time or periodically based on the access log so as to realize dynamic adjustment of the access rights, so that the access rights can cope with the changed environment. The optimization mode can refer to any one of the above, or an operator can set other optimization access rights or optimization conditions, and can be set according to actual requirements, and the application is not limited. In one possible implementation, the cloud management platform may adjust the score (i.e., weight value) of access rights (including validated and invalidated access rights) based on the alert information. For example, due to a change of environmental factors such as resource adjustment, the resource that can be accessed originally becomes a sensitive resource, and in this scenario, when the cloud management platform performs authority control according to the current access authority, alarm information (i.e., the resource that can be accessed originally, the resource that can be accessed currently becomes an inaccessible resource) may be generated. The cloud management platform can adjust the access right score in time based on the alarm information, for example, the score of the possibly-adjusted invalid access right is larger than the score of the access right in a mode of effectiveness (refer to the permission and the Deny right of the same API), and the cloud management platform can re-judge the effective result of the access right based on the adjusted weight value. In another possible implementation, the cloud management platform may update the score of the access rights based on the number of accesses to a certain resource by the user in the access log. For example, due to environmental changes such as department adjustments, it may be that the G1 user group current access rights indicate that the G1 user group may not access the R1 resource, but after the department adjustments, the G1 user group needs to access the R1 resource. Accordingly, each time a user of the G1 user group accesses R1 resources, the user group may be denied, alternatively, the user group may request that the manager grant access to R1. The cloud management platform can adjust the score of the access right based on the times of refusing the G1 user group to access the R1 resource and the times of refusing the G1 group to continue to access the R1 access behavior, so as to realize the dynamic optimization of the access right.

In the embodiment of the application, the newly added user is referred to. The cloud management platform is based on access logs that are implemented or periodically acquired. It may be determined that a new user exists for the system. The cloud management platform may acquire the corresponding user information based on the access log, and the specific acquisition mode may refer to the above, which is not described herein. In one example, the cloud management platform may add a new user to an existing user group based on the obtained user information. For example, the new user belongs to the same project group as the existing at least one user group, the new user is added to the at least one user group. The access rights corresponding to the corresponding at least one user group are also valid for the new user. In another example, the cloud management platform detects that alert information corresponding to a new user exists in the access log after joining the new user to at least one group. The cloud management platform determines that the grouping to which the new user belongs is inaccurate. The cloud management platform may independently create a group for the new user, and generate a new access right for the new user based on the access right generation flow, and the specific generation manner may refer to the above, which is not described herein. In yet another example, the cloud management platform may also separate the new users into groups and, based on the user information of the new users, find at least one user group in the existing user group that is similar to the user information of the new users. The cloud management platform can assign the access right corresponding to at least one user group to the new user group where the new user is located. The cloud management platform may evaluate the new access rights corresponding to the new user group based on the above-mentioned optimization manner, and update (or optimize) the access rights based on the evaluation result, and the specific implementation manner may refer to the above, which is not described herein. In yet another example, the cloud management platform does not find the same or similar grouping of users as the new user based on the user information. The cloud management platform can acquire the access log of the new user and generate corresponding new access rights for the new user based on the access rights generation method.

The following describes the above technical solution in detail with specific embodiments:

Illustratively, the cloud management platform builds an initial resource model based on cloud resources, which may include, but is not limited to:

{Instance,{Create,Delete,query}}

{VPC,{Create,Delete}}

Then, the cloud management platform acquires the dependency relationship between the sub-resources, and establishes a resource model based on the dependency relationship between the cloud resources and the sub-resources, wherein the resource model comprises the association relationship between the cloud resources, the dependent resources of the sub-resources and the access operation. As shown in table 4:

TABLE 4 Table 4

Then, the cloud management platform acquires a user group and a resource group based on the resource model and the access log. Specifically, the cloud management platform extracts key information based on the access log. The cloud management platform collects access logs, and extracts key information corresponding to each access log according to < UserId, IP, action, time and resource >. For example, key information extracted by the cloud management platform includes, but is not limited to:

c607e3b-c1c4-42ae-8b52-62f31e5578b1,10.173.140.3,create,2021-10-01 10:23:45.123,instance

263a38a5-6fb2-453d-b265-12722f6d7a00,10.173.140.3,create,2021-10-01 10:23:45.123,instance

263a38a5-6fb2-453d-b265-12722f6d7a00,10.173.140.3,query,2021-10-01 10:23:45.123,instance

......

In this example 10.173.140.3 is IP address information, i.e. the Condition information described above. In some examples, the IP address may also be a network resource, and the application is not limited.

The cloud management platform may filter the traffic to be happened, for example, only once access behavior occurs, or key information corresponding to an access log with access duration smaller than a threshold (which may be set according to actual requirements, and the application is not limited), based on the access time or the access duration.

The cloud management platform maps the key information into access vectors based on the resource model, and the access vectors represent the corresponding relation among users, resources and access operations. Specifically, the cloud management platform acquires key information. The cloud management platform maps key information corresponding to the access log into a standardized API structure based on the resource model.

For example, the cloud management platform maps 9c607e3b-c1c4-42ae-8b52-62f31e5578b1 to U1,263a38a5-6fb2-453d-b265-12722f6d7a00 to U2, and access vectors derived based on critical information include, but are not limited to:

<U1,Create,Instance,10.173.140.3>

<U1,Delete,Instance,10.173.140.3>

<U1,Create,Instance,10.173.140.16>

<U1,Delete,Instance,10.173.140.16>

<U2,Query,Instance,10.173.140.13>

<U3,Create,Instance,10.173.140.3>

<U3,Delete,Instance,10.173.140.3>

<U3,Create,Instance,10.173.140.16>

<U3,Delete,Instance,10.173.140.16>

......

For example, it is assumed that the key information corresponding to the access log does not have the access operations corresponding to "CREATE VPC" and "DELETEVPC", and accordingly, the access vector generated by the cloud management platform does not include the vector corresponding to the access operation. The cloud management platform may determine that there is a dependency relationship between the resource Instance and the resource VPC, and that the API of "CreateInstance" depends on the API of "CREATEVPC", as shown in table 4, based on the dependency relationship of the APIs included in the resource model (i.e., the dependency relationship of the resource). The API of "DELETEINSTANCE" depends on the API of "DELETEVPC". Accordingly, the cloud management platform supplements the corresponding access vectors, including but not limited to:

<U1,Create,VPC,10.173.140.3>

<U1,Delete,VPC,10.173.140.3>

<U1,Create,VPC,10.173.140.16>

<U1,Delete,VPC,10.173.140.16>

<U3,Create,VPC,10.173.140.3>

<U3,Delete,VPC,10.173.140.3>

<U3,Create,VPC 10.173.140.16>

<U3,Delete,VPC,10.173.140.16>

......

And the cloud management platform performs cluster analysis on the access vector based on the access log to obtain a user group and a resource group. Based on the above classification conditions, the cloud management platform groups the user, the Condition information (i.e., the IP address) and the resource respectively based on the above vectors to obtain a user group, a resource group and a Condition group, including, but not limited to:

User group:

G1={U1,U3}

G2={U2}

G3={U1}

G4={U3}

Resource group:

R1={Instance,VPC}

R2={Instance}

R3={VPC}

condition packets are:

{10.173.140.13} {10.173.140.3,10.173.140.16}

And S404, obtaining initial access rights based on the user group and the resource group.

Specifically, the cloud management platform obtains the initial access right by using a Cartesian product mode based on the grouping.

Assuming that the cloud management platform generates initial access rights through a Cartesian product, the following data exists:

(G1,{Create,Delete},{g:IP,StringEquals{10.173.140.3,10.173.140.16}},{Instance,VPC},Allow)

(G1,{query},{g:IP,StringEquals{10.173.140.3,10.173.140.16}},{Instance,VPC},Deny)

(G2,{query},{g:IP,StringEquals{10.173.140.13}},{Instance,},Allow)

(G2,{Create,Delete},{g:IP,StringEquals{10.173.140.13}},{Instance,},Deny)

......

the cloud management platform may then update (or optimize) the initial access rights based on the optimization described above to reduce the scope of rights control for the access rights.

For example, fig. 6 is a schematic structural diagram of an exemplary access right, and please refer to fig. 6, in the access right, there is an access right for indicating the authority of a user group to which UserA and UserB belong to the specified access operation of Resource1 and Resource2 (specific access operation is not exemplified). There is an access right for indicating rights of the user group to which UserC, userD, userE and UserF belong to a specified access operation (i.e., action) to Resource2 (i.e., a child Resource in a cloud Resource). There is one access right for indicating rights of the user groups to which UserE and UserF belong to the specified access operations of Resource2 and Resource 3. There is an access right indicating UserF the right of the user group to which the access right belongs to the specified access operation of Resource 3.

In the access rights generated in the embodiment of the application, the user information of the user is indirectly acquired in the access log mode, so that proper user grouping and resource grouping are obtained based on the user information, the access behavior and the like. In this way, the cloud management platform can acquire the user information through the access log in real time or periodically so as to adjust the access authority.

The application provides a cloud management platform. The cloud management platform is used for managing an infrastructure for providing cloud services, cloud resources of tenants are operated on the infrastructure, and the tenants comprise at least one user. Fig. 7 is a schematic structural diagram of an exemplary cloud management platform 700, referring to fig. 7, where the cloud management platform includes a resource model creation module 701, an acquisition module 702, and an access right generation module 703. The resource model creating module 701 is configured to create a resource model of a cloud resource, where the resource model includes an access operation and an association relationship of the cloud resource. The obtaining module 702 is configured to obtain an access log of the cloud resource, where the access log includes user information of at least one user, resource information of the cloud resource, and historical access operation. An access right generation module 703, configured to generate an access right according to the access log and the resource model, where the access right is used to indicate a right of at least one user to access the cloud resource.

In one possible implementation, the cloud resource includes a plurality of sub-resources, and the resource model creating module 701 is configured to obtain a dependency relationship between the plurality of sub-resources. And establishing a resource model based on the dependency relationship between the cloud resource and the plurality of sub-resources, wherein the resource model comprises the access operation, the cloud resource and the association relationship of the dependent sub-resources of the sub-resources.

In one possible implementation, the cloud management platform is provided with an access interface for responding to a target access operation of a target user to a target sub-resource, and the cloud management platform further comprises a permission control module 704 for determining permission of the target user to the target access operation of the target sub-resource and permission of the target user to the target access operation of the target sub-resource dependent on the sub-resource based on the access permission and the target access operation.

In a possible implementation manner, the access right generation module 703 includes an access right generation unit, configured to group at least one user with a plurality of sub-resources based on the access log to obtain at least one user group and at least one cloud resource group, and further configured to generate an access right based on the resource model, the at least one user group and the at least one cloud resource group, where the access right includes a right of the at least one user group to access the at least one cloud resource group.

In a possible implementation manner, the access right generating module 703 further includes an access right optimizing unit, and the access right generating unit is further configured to generate an initial access right based on the resource model, the at least one user group, and the at least one resource group, where the initial access right includes a right of an access operation of each user group to each resource group, and the access right optimizing unit is configured to optimize the initial access right in response to an access operation of the at least one user to the cloud resource, to obtain the access right.

In a possible implementation manner, the access right generation module 703 is further configured to obtain user information of a new user, add the new user to a target user group based on the user information of the new user, where the target user group is included in at least one user group, and the cloud management platform further includes a right control module configured to control a right of the new user to access the cloud resource based on an access right corresponding to the target user group.

In a possible implementation manner, the access right generation module 703 is further configured to obtain user information of a new user, query at least one target user group close to the new user based on the user information of the new user, and the cloud management platform further includes a right control module, configured to control the right of the new user to access the cloud resource by using the access right corresponding to the at least one target user group as the access right of the new user.

The modules can be implemented by software or hardware. Modules as an example of a software functional unit may include code that runs on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the probe task sending module may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising one data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.

Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same virtual private cloud (virtual private cloud, VPC) or may be distributed in multiple VPCs. In general, one VPC is disposed in one region, and a communication gateway is disposed in each VPC for implementing inter-connection between VPCs in the same region and between VPCs in different regions.

Modules as an example of hardware functional units, the modules may include at least one computing device, such as a server or the like. Alternatively, the modules may be devices implemented using application-specific integrated circuits (ASIC), programmable logic devices (programmable logic device, PLD), or the like. The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA) GATE ARRAY, a general-purpose array logic (GENERIC ARRAY logic, GAL), or any combination thereof.

The modules described above may include multiple computing devices that are distributed in the same region or may be distributed in different regions. The modules described above may include multiple computing devices distributed among the same AZ or among different AZ. Also, the above modules may include multiple computing devices distributed in the same VPC, or may be distributed in multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.

It should be noted that, in other embodiments, the above modules may be used to perform the corresponding steps in fig. 2 to implement the full functions of the cloud management platform.

The present application also provides a computing device 800. As shown in fig. 8, computing device 800 includes a bus 802, a processor 804, a memory 806, and a communication interface 808. Communication between processor 804, memory 806, and communication interface 808 is via bus 802. Computing device 800 may be a server or a terminal device. It should be understood that the present application is not limited to the number of processors, memories in computing device 800.

Bus 802 may be a peripheral component interconnect (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one s-line is shown in FIG. 8, but not only one bus or one type of bus. Bus 802 may include a path to transfer information between various components of computing device 800 (e.g., memory 806, processor 804, communication interface 808).

The processor 804 may include any one or more of a central processing unit (central processing unit, CPU), a graphics processor (graphics processing unit, GPU), a Microprocessor (MP), or a digital signal processor (DIGITAL SIGNAL processor, DSP).

The memory 806 may include volatile memory (RAM), such as random access memory (random access memory). The processor 804 may also include non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, mechanical hard disk (HARD DISK DRIVE, HDD), or Solid State Disk (SSD).

The memory 806 has stored therein executable program codes that the processor 804 executes to implement the functions of the aforementioned resource model creation module, acquisition module, access right generation module, and right control module, respectively, thereby implementing the access right management method in fig. 2. That is, the memory 806 has stored thereon instructions for performing the access rights management method.

The communication interface 808 enables communication between the computing device 800 and other devices or communication networks using a transceiver module such as, but not limited to, a network interface card, transceiver, or the like.

The embodiment of the application also provides a computing device cluster. The cluster of computing devices includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop, notebook, or smart phone.

As shown in fig. 9, the cluster of computing devices includes at least one computing device 900. The same instructions for performing the access rights management method shown in fig. 9 may be stored in memory 906 in one or more computing devices 900 in the cluster of computing devices.

In some possible implementations, portions of the instructions for performing access rights management may also be stored separately in the memory 906 of one or more computing devices 900 in the cluster of computing devices. In other words, a combination of one or more computing devices 900 may collectively execute instructions for performing the access rights management method.

It should be noted that, the memory 906 in different computing devices 900 in the computing device cluster may store different instructions for performing part of the functions of the cloud management platform apparatus. That is, the instructions stored by the memory 906 in the different computing devices 900 may implement the functionality of one or more of the resource model creation module, the acquisition module, the access rights generation module, and the rights control module.

In some possible implementations, one or more computing devices in a cluster of computing devices may be connected through a network. Wherein the network may be a wide area network or a local area network, etc. Fig. 10 shows one possible implementation. As shown in fig. 10, two computing devices 1000A and 1000B are connected by a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, instructions to perform the functions of the resource model creation module, the acquisition module, are stored in memory 1006 in computing device 1000A. Meanwhile, instructions to perform the functions of the access rights generation module and the rights control module are stored in the memory 1006 in the computing device 1000B.

It should be appreciated that the functionality of computing device 1000A shown in fig. 10 may also be performed by multiple computing devices 1000. Likewise, the functionality of computing device 1000B may also be performed by multiple computing devices 1000.

The embodiment of the application also provides another computing device cluster. The connection between computing devices in the computing device cluster may be similar to the connection of the computing device cluster described with reference to fig. 9 and 10. In contrast, the same instructions for performing the measurement method may be stored in the memory 1006 in one or more computing devices 1000 in the cluster of computing devices.

In some possible implementations, the memory 1006 of one or more computing devices 1000 in the cluster of computing devices may also each have stored therein a portion of instructions for performing the measurement method. In other words, a combination of one or more computing devices 1000 may collectively execute instructions for performing a measurement method.

It should be noted that the memory 1006 in different computing devices 1000 in the computing device cluster may store different instructions for performing part of the functions of the cloud management platform. That is, the instructions stored by the memory 1006 in the different computing devices 1000 may implement the functionality of one or more devices in the cloud management platform.

Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be software or a program product containing instructions capable of running on a computing device or stored in any useful medium. The computer program product, when run on at least one computing device, causes the at least one computing device to perform the access policy formulation method in the above embodiments.

The embodiment of the application also provides a computer readable storage medium. The computer readable storage medium may be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc. The computer-readable storage medium includes instructions that instruct a computing device to perform the access policy formulation method in the above embodiments.

It should be noted that the above-mentioned embodiments are merely for illustrating the technical solution of the present invention, and not for limiting the same, and although the present invention has been described in detail with reference to the above-mentioned embodiments, it should be understood by those skilled in the art that the technical solution described in the above-mentioned embodiments may be modified or some technical features may be equivalently replaced, and these modifications or substitutions do not make the essence of the corresponding technical solution deviate from the protection scope of the technical solution of the embodiments of the present invention.

Claims

1. An access rights management method, wherein the method is applied to a cloud management platform, the cloud management platform is used for managing an infrastructure for providing cloud services, and cloud resources are operated on the infrastructure, and the method comprises:

Establishing a resource model of the cloud resource, wherein the resource model comprises an association relation between the cloud resource and access operation;

Acquiring an access log of the cloud resource, wherein the access log comprises user information of at least one user, resource information of the cloud resource and historical access operation;

And generating access rights according to the access log and the resource model, wherein the access rights comprise rights of the at least one user to access the cloud resource.

2. The method of claim 1, wherein the cloud resource comprises a plurality of sub-resources, and wherein the building a resource model of the cloud resource comprises:

acquiring the dependency relationship among the plurality of sub-resources;

And establishing a resource model based on the dependency relationship between the cloud resource and the plurality of sub-resources, wherein the resource model comprises the access operation, the cloud resource and the association relationship of the dependent sub-resources of the sub-resources.

3. The method of claim 2, wherein the access rights further comprise rights of the at least one user to access dependent sub-resources of the sub-resource.

4. A method according to claim 3, wherein the cloud management platform is provided with an access interface for responding to a target access operation of a target user to a target child resource, the method further comprising:

based on the access rights and the target access operation, determining rights of the target user to the target access operation of the target sub-resource and rights of the target user to the target access operation of the dependent sub-resource of the target sub-resource.

5. The method of claim 2, wherein generating access rights from the access log and the resource model comprises:

grouping the at least one user and the plurality of sub-resources based on the access log to obtain at least one user group and at least one cloud resource group;

Generating the access rights based on the resource model, the at least one user group and the at least one cloud resource group, wherein the access rights comprise rights of the at least one user group to access the at least one cloud resource group.

6. The method of claim 5, wherein the generating the access rights based on the resource model, the at least one user group, and the at least one resource group comprises:

Generating initial access rights based on the resource model, the at least one user group and the at least one cloud resource group, wherein the initial access rights comprise rights of each user group to the access operation of each cloud resource group;

And responding to the access operation of the at least one user to the cloud resource, and updating the initial access right to obtain the access right.

7. The method of claim 6, wherein updating the initial access rights in response to the at least one user's access to the cloud resource, the access rights comprising:

And responding to the access operation of the at least one user to the cloud resources, and updating the initial access right and the access right preset by the user to obtain the access right, wherein the access right preset by the user is used for indicating the right of the at least one user to access all or part of the cloud resources in the cloud resources.

8. The method of claim 6, wherein updating the initial access rights in response to the at least one user's access to the cloud resource, the access rights comprising:

Determining a weight value of the initial access right based on a preset rule and an access operation of the at least one user to the cloud resource;

the effective weight value is larger than the access right of the preset threshold value.

9. The method of claim 5, wherein the method further comprises:

acquiring user information of a new user;

Adding the new user to a target user group based on the user information of the new user, the target user group being included in the at least one user group;

And determining the right of the new user to access the cloud resource based on the access right corresponding to the target user group.

10. The method of claim 5, wherein the method further comprises:

acquiring user information of a new user;

querying at least one target user group close to the new user based on the user information of the new user;

And taking the access right corresponding to the at least one target user group as the access right of the new user, and determining the right of the new user to access the cloud resource.

11. A cloud management platform for managing an infrastructure providing cloud services, the infrastructure having cloud resources running thereon, the cloud management platform comprising:

The resource model creation module is used for creating a resource model of the cloud resource, and the resource model comprises an association relation between the cloud resource and access operation;

The acquisition module is used for acquiring an access log of the cloud resource, wherein the access log comprises user information of the at least one user, resource information of the cloud resource and historical access operation;

And the access right generation module is used for generating access rights according to the access log and the resource model, wherein the access rights comprise the right of the at least one user to access the cloud resource.

12. The cloud management platform of claim 11, wherein the cloud resources comprise a plurality of sub-resources, the resource model creation module being specifically configured to:

And acquiring the dependency relationship among the plurality of sub-resources.

13. The cloud management platform of claim 12, wherein said access rights further comprise rights of said at least one user to access dependent sub-resources of said sub-resources.

14. The cloud management platform of claim 13, wherein the cloud management platform is provided with an access interface for responding to a target access operation of a target user to a target child resource, the cloud management platform further comprising:

And the permission control module is used for determining the permission of the target user to the target access operation of the target sub-resource and the permission of the target user to the target access operation of the dependent sub-resource of the target sub-resource based on the access permission and the target access operation.

15. The cloud management platform of claim 12, wherein said access rights generation module comprises:

An access authority generating unit, configured to group the at least one user and the plurality of sub-resources based on the access log, to obtain at least one user group and at least one cloud resource group;

the access right generation unit is further configured to generate the access right based on the resource model, the at least one user group, and the at least one cloud resource group, where the access right includes a right of the at least one user group to access the at least one cloud resource group.

16. The cloud management platform of claim 15, wherein said access rights generation module further comprises an access rights optimization unit;

The access right generation unit is further used for generating initial access rights based on the resource model, the at least one user group and the at least one cloud resource group, wherein the initial access rights comprise the rights of each user group to the access operation of each cloud resource group;

The access right optimizing unit is used for responding to the access operation of the at least one user to the cloud resource, updating the initial access right and obtaining the access right.

17. The cloud management platform of claim 16, wherein the access right optimizing unit is specifically configured to:

18. The cloud management platform of claim 16, wherein the access right optimizing unit is specifically configured to:

19. The cloud management platform of claim 15, wherein said access rights generation module is further configured to:

Acquiring user information of the new user;

the cloud management platform further comprises a permission control module for:

and controlling the right of the new user to access the cloud resource based on the access right corresponding to the target user group.

20. The cloud management platform of claim 15, wherein said access rights generation module is further configured to:

Acquiring user information of the new user;

And taking the access right corresponding to the at least one target user group as the access right of the new user, and controlling the right of the new user to access the cloud resource.

21. A cluster of computing devices, comprising at least one computing device, each computing device comprising a processor and a memory;

The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of any one of claims 1 to 10.

22. A computer program product containing instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method of any of claims 1 to 10.

23. A computer readable storage medium comprising computer program instructions which, when executed by a cluster of computing devices, perform the method of any of claims 1 to 10.