CN115766100A

CN115766100A - System resource authority management method, electronic device and storage medium

Info

Publication number: CN115766100A
Application number: CN202211308172.6A
Authority: CN
Inventors: 侯心主
Original assignee: Mingri Dream Beijing Technology Co ltd
Current assignee: Mingri Dream Beijing Technology Co ltd
Priority date: 2022-10-25
Filing date: 2022-10-25
Publication date: 2023-03-07

Abstract

The invention discloses a system resource authority management method, electronic equipment and a storage medium. The system resource authority management method comprises the following steps: responding to a policy binding request, binding a preset policy with a user and/or a user group indicated by the policy binding request, wherein the policy comprises a preset condition, and when the preset condition is met, allowing or refusing to access system resources; responding to a resource access request, determining a user initiating the resource access request as a user to be judged, and determining a user group of the user to be judged as a user group to be judged; judging whether the resource access request meets the strategy bound by the user to be judged and/or the user group to be judged to obtain a judgment result, and judging whether the user to be judged is allowed to access the system resource indicated by the resource access request according to the judgment result. The invention simplifies the judgment process and improves the access speed of resources on the basis of ensuring the safety and the flexibility of the authority management.

Description

System resource authority management method, electronic device and storage medium

Technical Field

The present invention relates to the field of system resource management technologies, and in particular, to a method for managing system resource permissions, an electronic device, and a storage medium.

Background

The existing system resource right management methods mainly include two methods, which are respectively Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).

The Role-based access control method authorizes the related authority through the Role (Role) of the user, realizes flexible access control, and is simpler, more efficient and expandable compared with the method of directly authorizing the authority of the user. In role-based access control, a role generally refers to a group of people having certain common characteristics, such as department, location, seniority, level, job duty, and the like. When the system is initialized, an administrator creates a plurality of different roles with different permission combinations according to business needs, for example, the role A has access and editing permissions of all menus, and the role B only has access and editing permissions of the menu A but has no editing permissions of other menus. When a certain user authority needs to be given, the user is assigned to the corresponding role, and the authority meeting the requirement can be given.

Attribute-based access control dynamically determines whether an operation can be permitted or not based on conditions such as attributes of objects, resources, and environments. Attribute-based access control Access control utilizes a set of features called "attributes". Including, for example, user attributes, environment attributes, and resource attributes.

The main difference between role-based access control and attribute-based access control is the way in which the method grants access rights. The role-based access control grants access rights according to roles, and the attribute-based access control can determine the access rights according to attributes such as user characteristics, object characteristics, operation types and the like.

Since both role-based access control and attribute-based access control have advantages and disadvantages, the prior art proposes to merge the two. However, the existing fusion mode of role-based access control and attribute-based access control is only for the control information that the attribute-based rights object and the role-based rights object are respectively associated with different business resource objects, and the subsequent access mode is determined according to different control information.

Therefore, in the fusion mode in the prior art, only role-based access control and attribute-based access control are simply combined, and in an access scene for a large number of users, for a business resource object, not only role-based access control but also attribute-based access control are judged, so that the judgment processes are remarkably increased, and the access speed of the resource is remarkably reduced.

Disclosure of Invention

Therefore, it is necessary to provide a system resource right management method, an electronic device, and a storage medium for solving the technical problem that in the access scene for a large number of users, the combination of the existing fusion mode of role-based access control and attribute-based access control is simple, and the resource access speed is slow due to the fact that the judgment process is too many.

The invention provides a system resource authority management method, which comprises the following steps:

responding to a policy binding request, binding a preset policy with a user and/or a user group indicated by the policy binding request, wherein the policy comprises a preset condition, and when the preset condition is met, allowing or refusing to access system resources;

responding to a resource access request, determining a user initiating the resource access request as a user to be judged, and determining a user group of the user to be judged as a user group to be judged;

judging whether the resource access request meets the strategy bound by the user to be judged and/or the user group to be judged to obtain a judgment result, and judging whether the user to be judged is allowed to access the system resource indicated by the resource access request according to the judgment result.

Further, the system resource is provided with a hierarchical tag, and the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined specifically includes:

for one policy bound by the user to be judged and/or the user group to be judged:

and judging whether the hierarchical label of the system resource indicated by the resource access request meets the preset label condition of the strategy.

Still further, it includes:

in response to the permission application passing information, creating a strategy of grading labels indicated by the permission application passing information as label strategies;

and binding the label strategy to the user and/or user group specified by the permission application through information.

Further, the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined specifically includes:

judging whether the user to be judged meets the preset user condition of the strategy or not; and/or

And judging whether the user group to be judged meets the preset user group condition of the strategy or not.

judging whether the source address of the resource access request meets the preset address condition of the strategy or not; and/or

And judging whether the access time of the resource access request meets the time condition of the strategy or not.

Further, the policy bound to the user to be determined and/or the user group to be determined includes: an admission policy for admitting access to the system resource when a preset admission condition is satisfied and a denial policy for denying access to the system resource when a preset denial condition is satisfied.

Further, the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result specifically includes:

obtaining a refusing strategy and an allowing strategy bound by the user to be judged and/or the user group to be judged;

judging whether the resource access request meets the rejection condition of the rejection strategy in the strategy to be judged;

and if the resource access request meets the rejection condition of any one of the rejection strategies, rejecting the resource access request.

Further, the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result, specifically includes:

if the resource access requests do not meet the rejection conditions of the rejection strategies, judging whether the resource access requests meet the permission conditions of the permission strategies in the strategies to be judged;

and if the resource access request meets the permission condition of any permission policy, permitting the resource access request.

The present invention provides an electronic device, including:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to at least one of the processors; wherein,

the memory stores instructions executable by at least one of the processors to enable at least one of the processors to perform a method of system resource rights management as previously described.

The present invention provides a storage medium storing computer instructions for performing all the steps of the system resource right management method as described above when the computer executes the computer instructions.

The invention binds the strategy with the users and/or the user groups, thereby realizing role management through the users and the user groups, and managing the system resources through the conditions in the strategy, therefore, the access control based on the role and the access control based on the attribute are deeply integrated, each user or user group only needs to judge according to the strategy thereof, thereby greatly simplifying the judging process, and improving the access speed of the resources on the basis of ensuring the safety and the flexibility of the authority management.

Drawings

FIG. 1 is a flowchart illustrating a method for managing system resource permissions according to an embodiment of the present invention;

FIG. 2 is a flowchart illustrating a method for managing system resource permissions according to another embodiment of the present invention;

FIG. 3 is a schematic diagram illustrating an implementation of a user, a user group, and a policy according to an embodiment of the present invention;

FIG. 4 is a system diagram of a privilege system according to an embodiment of the present invention;

fig. 5 is a schematic diagram of a hardware structure of an electronic device according to the present invention.

Detailed Description

The following further describes embodiments of the present invention with reference to the accompanying drawings. In which like parts are designated by like reference numerals. It should be noted that the terms "front," "back," "left," "right," "upper" and "lower" used in the following description refer to directions in the drawings, and the terms "inner" and "outer" refer to directions toward and away from, respectively, the geometric center of a particular component.

Fig. 1 is a flowchart illustrating a method for managing system resource permissions according to an embodiment of the present invention, including:

step S101, responding to a policy binding request, binding a preset policy with a user and/or a user group indicated by the policy binding request, wherein the policy comprises a preset condition, and when the preset condition is met, allowing or refusing to access system resources;

step S102, responding to the resource access request, determining a user initiating the resource access request as a user to be judged, and determining a user group of the user to be judged as a user group to be judged;

step S103, judging whether the resource access request meets the policy bound by the user to be judged and/or the user group to be judged to obtain a judgment result, and judging whether the user to be judged is allowed to access the system resource indicated by the resource access request according to the judgment result.

Specifically, the present embodiment is applied to an electronic device for system resource Management, for example, as an Identity and Access Management (IAM) server. When, for example, an administrator binds a policy or an applicant applies for a binding policy, a policy binding request is input to the server, where the policy binding request includes a user or a user group to which the policy is to be bound, so as to trigger step S101, and bind a preset policy with the user and/or the user group indicated by the policy binding request.

The rights model of this embodiment includes three entities, namely < user > < user group > < policy >, and all three entities have a many-to-many relationship. The cluster operation and the project level operation are designed by using a role-based access control model through users and user groups, and the fine-grained control of resources is designed by using an attribute-based access control model based on strategies. Table 1 is an illustration of a user group.

TABLE 1 schematic user group table

The system level, the project level and the resource level are decreased in granularity in sequence. Different user groups can bind different strategies, so that the authority control of different user groups is realized.

A policy includes one or more preset conditions that, when satisfied, allow or deny access to a system resource specified by the policy.

Then, when the user accesses the system resource, a resource access request is generated, step S102 is triggered, the user initiating the resource access request is determined to be the user to be judged according to the resource access request, and then the user group of the user to be judged is obtained to be the user group to be judged.

And finally, executing the step S103, judging whether the resource access request meets the policy bound by the user to be judged and/or the user group to be judged to obtain a judgment result, and judging whether the user to be judged is allowed to access the system resource indicated by the resource access request according to the judgment result.

The user to be judged is bound with one or more strategies, the user group to be judged also comprises one or more strategies, the resource access request is judged according to all the strategies to obtain a judgment result, and then whether the user to be judged is allowed to access the system resource indicated by the resource access request is judged according to the judgment result.

Wherein, the user accesses the system resource, including but not limited to viewing, deleting, and the like, the related operation on the system resource.

The invention binds the strategy with the users and/or the user groups, thereby realizing role management through the users and the user groups, and managing the system resources through the conditions in the strategy, therefore, the access control based on the roles and the access control based on the attributes are deeply integrated, each user or user group only needs to judge according to the strategy of the user or user group, the judgment process is greatly simplified, and the access speed of the resources is improved on the basis of ensuring the safety and the flexibility of the authority management.

In one embodiment, the system resource is provided with a hierarchical tag, and whether the resource access request meets a policy bound by a user to be determined and/or a user group to be determined is determined, which specifically includes:

for one strategy bound by the user to be judged and/or the user group to be judged:

Specifically, for a specific resource, the resource may be processed hierarchically, for example, for a data resource, the following may be classified: the public data (C1), the internal data (C2), the secret data (C3), and the secret data (C4) are classified into four levels.

The embodiment introduces the label, and adds the attribute for the resource through the label. When resources are tagged, permission policies/rules can be used to allow or restrict a user's data access behavior.

The label comprises a label key and a label value, the association of the label key and the resource is stored in a label system, an interface of the label system can be called through a tool to label the resource, and the resource in the label system is defined by the resource description.

For example, binding a policy to a user or group of users may allow the user or group of users to read data sets with security levels C1 and C2 in a cluster.

In order to make the use more convenient for users, the system presets some strategies, such as that the public data is bound to all user groups by default.

In one embodiment, the method further comprises the following steps:

step S201, responding to the permission application passing information, and creating a strategy of grading labels indicated by the permission application passing information as a label strategy;

step S202, the label strategy is bound to the user and/or user group specified by the information of the permission application.

Steps S201 and S202 of the present embodiment may be provided before or after the aforementioned steps S101 to S103.

For the access of data with high security level, an application needs to be submitted to the system, and the resource administrator approves the application, and after the approval is passed, the system generates permission application passing information, so that step S201 is triggered, the authentication module is called to create a corresponding permission policy, and step S202 is executed to bind to an applicant (a user or a user group).

The embodiment adds the permission application process so as to facilitate the user to apply for accessing the data with higher security level.

In one embodiment, the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined specifically includes:

judging whether the user to be judged meets preset user conditions of the strategy or not; and/or

In particular, user conditions and/or user group conditions are included in the policy. After binding a policy for a user, the user's group of users may change.

For example, the role of the user a in binding the policy is a system administrator, and the policy of binding is that the user a can access the system resource when the user role is the system administrator. However, when user a changes to the project owner, he would again want to access the same system resources, and would not be able to access it because his user group changed.

Likewise, since policies may also be bound to a user group, for some system resources, only some members of the user group may be allowed access, or some members may be denied access. Some members of the user group may thus be allowed or excluded by user conditions in the policy.

The embodiment provides more flexible access control strategies by adding user conditions and user group conditions.

In one embodiment, the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined specifically includes:

And judging whether the access time of the resource access request meets the time condition of the strategy.

Specifically, the present embodiment adds a policy for limiting the source address and the access time of the resource access request. Thereby avoiding users accessing system resources at insecure addresses or at illegal times.

In one embodiment, the policy bound to the user to be determined and/or the user group to be determined includes: an admission policy for admitting access to the system resource when a preset admission condition is satisfied and a denial policy for denying access to the system resource when a preset denial condition is satisfied.

Specifically, the policy may include an allow/deny identifier for identifying the policy as an allow policy or a deny policy.

As an example, a policy/rule includes:

state element is the description of the authority rules, and can contain a plurality of authority rules.

Effect indicates whether the rule is allowed or rejected, optionally Allow, deny.

Action specifies the list of actions allowed by the rule.

Resource specifies the list of resources to which the rule applies.

Condition specifies under which circumstances the rule takes effect.

Wherein, the Condition syntax is:

"Condition":{"{condition-operator}":{"{condition-key}":"{condition-value}"}}

-condition-operator: the conditional operation method represents the matching rule of the condition key and the condition value, and the following common methods are:

StringEquals restricts access based on key to string value comparison

IpAddress restricts access based on a comparison of the key with an IPv4 or IPv6 address or IP address range

DateEquals restricts access based on key versus date/time value

Condition-key, common are:

-ResourceTag: resource label

-SourceIp: source address (IP)

-principal ARN requesting an ARN of the subject, the ARN being a subject identifier of the authentication and authorization module, comprising: users and groups of users. By specifying a principal arn, access to a resource by a certain user/user group may be allowed or restricted.

-Condition-value Condition value.

The Condition syntax is very rich, and can be used for matching request sources and matching resources by using tags.

In one embodiment, the determining whether the resource access request meets the policy bound by the user to be determined and/or the user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result specifically includes:

acquiring a refusing strategy and an allowing strategy bound by a user to be judged and/or a user group to be judged;

and if the resource access request meets the rejection conditions of any rejection strategy, rejecting the resource access request.

Specifically, the judgment result includes a compliance policy or a non-compliance policy.

In this embodiment, the denial policies are preferentially determined, and if the resource access request satisfies any one of the denial policies, that is, the determination result of one of the denial policies is a policy according, the access can be directly denied according to the determination result, so that it is not necessary to determine all policies, and the speed of obtaining the determination result is increased.

In one embodiment, the determining whether the resource access request meets a policy bound to a user to be determined and/or a user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result, specifically further includes:

Specifically, if all the denial policies are checked and the determination results of all the denial policies are all non-compliant, it is continuously determined whether the resource access request conforms to the permission conditions of the permission policy in the policy to be determined.

And if the judgment result of any one permission strategy is a conformity strategy, the resource access request is permitted according to the judgment result, and if the judgment results of all the permission strategies are nonconformity strategies, the resource access request is rejected.

According to the method and the device, when the resource access request conforms to any permission policy, the resource access request is passed, so that the resource access speed is improved.

Fig. 3 is a schematic diagram illustrating implementation of a user, a user group, and a policy according to an embodiment of the present invention, including: user vision 31 to the left of the dashed line and an entitlement system 32 to the right of the dashed line.

Project _ a has four user groups 311 built therein, and when a project is created, the privilege system 32 will automatically create corresponding four user groups 321 in the authentication module, and create corresponding privilege policies 322 and bind to the corresponding user groups.

It can also be seen from this example that no matter how the future organization changes, the authentication and authentication module only has three entities of < user, user group, policy > and the association relationship between the three entities, and the organization structure information (such as tenant, department multi-level structure) can be realized by outer layer encapsulation, and the user does not directly call the authentication and authentication module interface except for login. Thus, regardless of the external organizational structure, management of resources is achieved through groups and policies.

It should be noted that fig. 3 is a schematic diagram of binding of user groups, and is used only for illustration. Custom policies can also be bound to users in actual systems.

The above management of users/user groups is mainly implemented based on role-based access control, and with respect to attribute-based access control, the present embodiment proposes a permission policy/rule.

For example, a policy/rule is defined as described below, including:

Effect indicates whether the rule is allowed or rejected, optionally allowed (Allow) or rejected (Deny).

Action specifies the list of actions allowed by the rule.

Resource specifies the list of resources to which the rule applies.

Condition specifies under which circumstances the rule takes effect.

Wherein, the Condition syntax is:

"Condition":{"{condition-operator}":{"{condition-key}":"{condition-value}"}}

StringEquals restricts access based on key to string value comparison

-IPAddress restricts access based on a comparison of keys to IPv4 or IPv6 addresses or IP address ranges

DateEquals restricts access based on key versus date/time value

Condition-key, common are:

-ResourceTag: resource label

-SourceIp: source address (IP)

-principal ARN requesting an ARN of a subject, the ARN being a subject identifier of the authentication and authorization module system, comprising: users and groups of users. By specifying a principal arn, access to a resource by a certain user/user group may be allowed or restricted.

-Condition-value Condition value.

The aforementioned rights policy is then bound to the user or group of users.

For a specific resource, the resource may be processed hierarchically, for example, for a data resource, the following may be classified: the public data (C1), the internal data (C2), the secret data (C3), and the secret data (C4) are classified into four levels. In this embodiment, a tag is introduced, and an attribute is added to a resource through the tag. When resources are tagged, permission policies/rules can be used to allow or restrict a user's data access behavior.

In order to make the use more convenient for users, the system presets some strategies, such as that the public data is bound to all user groups by default. And the data with high security level needs to submit an application to the system, and is approved by a resource manager, after the approval is passed, the system calls an authentication module to create a corresponding authority policy and binds the authority policy to an applicant (a user or a user group).

Fig. 4 is a system diagram of an authorization system according to an embodiment of the present invention, which includes: authentication module 41, project management module 42, label system 43, verification module 44, wherein:

the authentication module 41 has the following main functions:

1. and maintaining the binding relationship among the user, the user group, the authority strategy and the three.

2. A single sign-on (SSO) system is interfaced.

3. Management capabilities of an access Key (AK/SK), a Secure Shell (SSH) Public Key (Public Key) are provided.

4. An authentication interface is provided.

The project management module 42, its main functions are: and managing the project, the members and the member group, and calling an interface of the authentication module 41 to configure a project/member group preset strategy.

The tagging system 43 provides interfaces for tagging resources, querying resource tags, querying tag-associated resources, and the like.

The verification module 44, among other things, has the main functions of:

1. the method includes implementing a container arrangement engine authentication callback (kubernets Auth Webhook) interface, responding to a container arrangement engine authentication request (kubernets objectaccessriew request), and translating the authentication request to the authentication module 41, wherein the container arrangement engine preferably adopts kubernets.

2. The certification interface of the mirror image warehouse certification service (Docker certification auth) is realized, the request is translated into the certification request of the certification and authentication module 41, and the mirror image certification is included in the certification system of the experimental platform.

3. The authentication module 41 is global, which means that in the case of multiple clusters, cross-cluster access is frequent, and if there is no caching mechanism, the availability of the system may be affected.

4. Some information required for some authentication, such as a mirror repository authentication key (Docker registry key) under each project, is synchronized at the container orchestration engine.

Finally, the authority system can also be connected with an auditing system 45 to form a uniform security management platform.

Fig. 5 is a schematic diagram of a hardware structure of an electronic device according to the present invention, which includes:

at least one processor 501; and (c) a second step of,

a memory 502 communicatively coupled to the at least one processor 501; wherein,

the memory 502 stores instructions executable by the at least one processor to enable the at least one processor to perform the method for system resource rights management as previously described.

In fig. 5, one processor 501 is taken as an example.

The electronic device may further include: an input device 503 and a display device 504.

The processor 501, the memory 502, the input device 503, and the display device 504 may be connected by a bus or other means, and are illustrated as being connected by a bus.

The memory 502, which is a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the system resource right management method in the embodiment of the present application, for example, the method flow shown in fig. 1. The processor 501 executes various functional applications and data processing by running nonvolatile software programs, instructions, and modules stored in the memory 502, that is, implements the system resource right management method in the above-described embodiments.

The memory 502 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the system resource right management method, and the like. Further, the memory 502 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 502 optionally includes memory located remotely from processor 501, which may be connected via a network to a device performing the method for system resource rights management. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 503 may receive input of user clicks and generate signal inputs related to user settings and function control of the system resource right management method. The display 504 may include a display device such as a display screen.

The one or more modules stored in the memory 502, when executed by the one or more processors 501, perform the system resource rights management method of any of the method embodiments described above.

An embodiment of the present invention provides a storage medium storing computer instructions for performing all the steps of the system resource right management method as described above when the computer executes the computer instructions.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is specific and detailed, but not to be understood as limiting the scope of the present invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A method for system resource rights management, comprising:

2. The method for managing system resource permissions according to claim 1, wherein the system resource is provided with a hierarchical label, and the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined specifically comprises:

3. The system resource right management method according to claim 2, further comprising:

4. The method for managing system resource permissions according to claim 1, wherein the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined specifically includes:

5. The method for managing system resource permissions according to claim 1, wherein the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined specifically includes:

6. The method for system resource right management according to claim 1, wherein the policy bound to the user to be determined and/or the user group to be determined comprises: an admission policy for admitting access to the system resource when a preset admission condition is satisfied and a denial policy for denying access to the system resource when a preset denial condition is satisfied.

7. The method for system resource right management according to claim 6, wherein the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result specifically includes:

8. The method for system resource right management according to claim 7, wherein the determining whether the resource access request satisfies a policy bound to the user to be determined and/or the user group to be determined to obtain a determination result, and determining whether to allow the user to be determined to access the system resource indicated by the resource access request according to the determination result, specifically further comprises:

9. An electronic device, comprising:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to at least one of the processors; wherein,

the memory stores instructions executable by at least one of the processors to enable the at least one of the processors to perform a method of system resource rights management as claimed in any one of claims 1 to 8.

10. A storage medium storing computer instructions for performing all the steps of the system resource right management method according to any one of claims 1 to 8 when executed by a computer.