Authority control method and device, electronic equipment and storage medium

Abstract

The invention discloses an authority control method and device, electronic equipment and a storage medium, and relates to the technical field of distributed storage, the two dimensions of a user and a tenant are considered at the same time, object storage authority is dynamically adjusted through tenant strategy inheritance, dynamic authority judgment and reverse authority indexing, and the user experience is improved. The security, compliance and flexibility of the object storage system can be improved, and the authority management efficiency is improved and the operation and maintenance management cost is reduced under the condition of meeting data storage and management requirements in a multi-tenant environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed storage, and particularly relates to a permission control method and device, electronic equipment and a storage medium. BACKGROUND

[0002] Object storage is a widely used data storage method at present, which can efficiently store and manage a large amount of unstructured data. However, with the continuous growth of data volume and the requirement of data security, the related object storage permission control mechanism cannot meet the current needs. The related object storage adopts a resource center permission model, and the permission needs to be bound by resource. The related object storage lacks consideration of the tenant dimension. When the number of tenants is greater than a certain number, the complexity of policy management increases exponentially, which makes the permission control complex and difficult in a multi-tenant environment. In addition, the related permission control mechanism usually does not consider the isolation and security between tenants, which makes the data possibly be accessed or leaked without authorization in a multi-tenant environment. SUMMARY

[0003] The present application provides a permission control method and device, electronic equipment and a storage medium to at least solve the problem that the user and tenant dimensions are not considered simultaneously in the related art, which leads to the inability to ensure data security and compliance.

[0004] The present application provides a permission control method, comprising: configuring a first permission policy at a tenant level, the first permission policy comprising at least a cross-tenant access control mechanism; configuring a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; receiving an access request of a user, and determining a target first permission policy of a tenant to be accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; merging the target first permission policy and the target second permission policy, and making a permission decision on the access request based on a merging result to obtain an access allowed or denied result.

[0005] The present application also provides a permission control device, comprising: a first configuration module configured to configure a first permission policy at a tenant level, the first permission policy comprising at least a cross-tenant access control mechanism; a second configuration module configured to configure a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; a permission policy determination module configured to receive an access request of a user, and determine a target first permission policy of a tenant to be accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; A result generation module is configured to merge the target first permission policy and the target second permission policy, make a permission decision on the access request based on the merging result, and obtain a result of allowing or rejecting the access.

[0006] The application further provides an electronic device, including a memory configured to store a computer program, and a processor configured to implement the following steps of the permission control method when executing the computer program. A first permission policy at a tenant level is configured, and the first permission policy at least includes a cross-tenant access control mechanism. A second permission policy at a user level is configured, and the second permission policy supports inheritance and / or overriding of the first permission policy. An access request of a user is received, and a target first permission policy of a tenant that the user needs to access and a target second permission policy corresponding to the user are determined according to the access request of the user. The target first permission policy and the target second permission policy are merged, a permission decision on the access request is made based on the merging result, and a result of allowing or rejecting the access is obtained.

[0007] The application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the following steps of the permission control method. A first permission policy at a tenant level is configured, and the first permission policy at least includes a cross-tenant access control mechanism. A second permission policy at a user level is configured, and the second permission policy supports inheritance and / or overriding of the first permission policy. An access request of a user is received, and a target first permission policy of a tenant that the user needs to access and a target second permission policy corresponding to the user are determined according to the access request of the user. The target first permission policy and the target second permission policy are merged, a permission decision on the access request is made based on the merging result, and a result of allowing or rejecting the access is obtained.

[0008] The application further provides a computer program product, including a computer program, and the computer program is executed by a processor to implement the following steps of the permission control method. A first permission policy at a tenant level is configured, and the first permission policy at least includes a cross-tenant access control mechanism. A second permission policy at a user level is configured, and the second permission policy supports inheritance and / or overriding of the first permission policy. An access request of a user is received, and a target first permission policy of a tenant that the user needs to access and a target second permission policy corresponding to the user are determined according to the access request of the user. Merge the target first permission policy and the target second permission policy, and make a permission decision on the access request based on the merging result to obtain an access-allowed or access-rejected result.

[0009] The application simultaneously considers two dimensions of users and tenants, dynamically adjusts the object storage permission through tenant policy inheritance, dynamic permission decision, and reverse permission indexing, can improve the security, compliance, and flexibility of the object storage system, improves the permission management efficiency and reduces the operation and management cost under the condition of meeting the data storage and management requirements in a multi-tenant environment. BRIEF DESCRIPTION OF DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0011] Figure 1 An application environment diagram of the permission control method provided by the embodiments of the present application is provided. Figure 2 A whole flowchart of the permission control method provided by the embodiments of the present application is provided. Figure 3 Another whole flowchart of the permission control method provided by the embodiments of the present application is provided. Figure 4 A structure block diagram of the permission control device provided by the embodiments of the present application is provided. Figure 5 An internal structure diagram of the electronic device in an embodiment is provided. DETAILED DESCRIPTION

[0012] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0013] It should be noted that, in the description of the present application, the terms “include”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms “first”, “second” and the like in the present application are used to distinguish similar objects, not to describe a specific order or sequence.

[0014] It should be noted that the terms "S1", "S2" and the like are only used for the purpose of describing the steps and do not particularly indicate the order or sequence, nor are they used to limit the present application, which is merely for the convenience of describing the method of the present application, and cannot be understood as indicating the sequence of the steps. In addition, the technical solutions of various embodiments can be combined with each other, but must be based on the realization of a person skilled in the art, and when the combination of technical solutions contradicts each other or cannot be realized, it should be considered that the combination of technical solutions does not exist and is not within the protection scope required by the present application.

[0015] In order for those skilled in the art to better understand the present application, the present application will be further described in detail below in conjunction with the drawings and specific embodiments.

[0016] The permission control method provided by the present application can be applied to the application environment as shown in Figure 1 . Among them, the terminal 102 communicates with the data processing platform set on the server 104 through the network, wherein the terminal 102 can be but not limited to various personal computers, notebook computers, smart phones, tablet computers and portable wearable devices, and the server 104 can be realized by an independent server or a server cluster composed of multiple servers.

[0017] As shown in Figure 2 , the embodiments of the present application provide a permission control method, which is applied to the terminal in Figure 1 for example, including the following steps: S1: configuring a first permission policy at the tenant level, the first permission policy at least including a cross-tenant access control mechanism.

[0018] It should be noted that the tenant refers to a logical unit of resource isolation in the object storage system, represents an independent customer, organization or business line, and the data thereof is physically or logically isolated from other tenants; the first permission policy at the tenant level refers to a global and mandatory access rule, which is automatically applied to all users and resources (i.e., objects) under a certain tenant, all users under the tenant must comply with the tenant policy, and the personal permission settings of the user cannot bypass the prohibitive provisions of the tenant policy, and the tenant policy is usually used to define the security bottom line, such as whether to allow cross-tenant access, the default access rule of all resources in the tenant (such as everyone can read, but cannot delete), and unified protection of specific sensitive resources (such as prohibiting anyone from deleting financial data buckets), etc.; the cross-tenant access control mechanism refers to configuring the permission policy of the bucket and object of the tenant, and configuring whether the data under the tenant is allowed to access cross-tenants, for example, if the tenant policy of tenant A is configured to not allow cross-tenant access, then the users under other tenants cannot access the buckets and resources in the buckets under tenant A, and if the tenant policy of tenant A is configured to allow cross-tenant access, then the users under other tenants can access the buckets and resources in the buckets under tenant A if they have access rights, so as to achieve isolation and security between tenants.

[0019] S2: Configure a second permission policy at the user level, and the second permission policy supports inheritance and / or overriding of the first permission policy.

[0020] It should be noted that the user is the smallest access entity in the object storage system with an independent identity (such as an account, a key), represents a specific operator (such as a developer, an application), and belongs to a certain tenant, and the permission policy at the user level is a personalized access rule set for a specific user, which further adjusts the permissions of the user on the basis of the global policy of the belonging tenant, for example, further relaxes or restricts the operations of the user on certain resources, and the user policy follows the "deny first" principle, can cover the allowed items in the tenant policy, but cannot bypass the prohibitive provisions of the tenant policy, and thus realizes more fine-grained permission control; in the case where the user policy is not configured, the tenant policy can be completely inherited, and in the case where the user policy is configured, deny (refuse) is given priority; and the user policy can be inherited through a hierarchical policy: the tenant policy organizes the tenants in a tree structure -> user, and the user automatically inherits the tenant policy.

[0021] The tenant policy and the user policy described above have priority in policy taking effect of the bucket ACL, the object ACL, and the bucket policy, that is, deny has the highest priority, and if any policy is set to deny access, the denial is used as the final result, wherein the bucket policy (BucketPolicy) is a set of access control rules for a storage bucket (Bucket) and objects (Object) in the object storage system, which is usually defined in JSON format, and is used to precisely manage the operations (such as reading, writing, and deleting) allowed / denied by a specific user on a bucket or an object; the ACL (Access Control List) is an access policy for granting access permissions to a Bucket and an Object, and the ACL can be configured when a storage space (Bucket) is created or an object (Object) is uploaded, or the ACL can be modified at any time after the Bucket or the Object is created.

[0022] S3: receiving an access request of a user, determining a target first permission policy of a tenant that the user needs to access and a target second permission policy corresponding to the user according to the access request of the user.

[0023] It should be noted that the access request of the user carries a tenant ID, a user ID, an operation type, and a resource path, wherein the operation type is a specific action performed by the user on a storage resource, mainly including data operations such as GetObject (reading an object), PutObject (writing / uploading an object), and DeleteObject (deleting an object), and management operations such as ListBucket (listing objects in a bucket), creating or deleting a storage bucket, and modifying a permission policy; these operation types are basic units controlled in the permission policy, and are used to precisely authorize or deny specific behaviors of the user; the resource path is a string uniquely identifying a resource in the object storage, and usually includes a bucket name: a storage container where the resource is located; an object key: a unique identifier of a specific file in the bucket, which can contain a prefix similar to a directory (such as projects / doc.pdf); and a wildcard: used to match a group of resources (such as * to match all, and confidential / * to match all objects under the confidential directory).

[0024] S4: merging the target first permission policy and the target second permission policy, and making a permission decision on the access request based on the merging result to obtain a result of allowing or denying access.

[0025] It should be noted that the permission decision is made by a permission decision engine.

[0026] In the above embodiments, considering both user and tenant dimensions, object storage permissions are dynamically adjusted through tenant policy inheritance, dynamic permission arbitration, and reverse permission indexing, which can improve the security, compliance, and flexibility of the object storage system. In the case of meeting the data storage and management requirements in a multi-tenant environment, the efficiency of permission management is improved, and the operation and management cost is reduced.

[0027] In some embodiments, configuring the first permission policy at the tenant level includes: Receiving a tenant permission policy configuration request, the tenant permission policy configuration request including at least a tenant identifier and a tenant permission policy rule, wherein the tenant permission policy rule can include a cross-tenant access rule, which includes a global cross-tenant access switch for allowing or denying access to resources of the tenant by users of other tenants, a resource exception rule for defining a "whitelist" indicating which specific resources (such as a certain bucket or directory) can be exempted from the global cross-tenant rule, for example, global cross-tenant access is prohibited, but a bucket named bucket-public is allowed to be accessed by others, a default operation rule for defining the basic access permissions of users in the tenant to the resources (such as default permission to read, denial to delete), as a benchmark when user policy is not configured, and a condition-based rule that can contain more detailed control conditions, such as limiting access source IP, requiring HTTPS encryption, etc. to enhance security, wherein the code is as follows: / / Tenant level policy configuration example { "TenantPolicy": { "CrossTenantAccess": "Deny", / / Global cross-tenant switch "ResourceExceptions": ["bucket-shared / *"] / / Exception resources } } According to the tenant permission policy configuration request, a tenant permission policy document is generated, which includes at least a cross-tenant access control field and a resource exception list field, wherein the cross-tenant access control field is used to describe whether to allow or deny access to resources of the tenant by users of other tenants, and the resource exception list field is used to describe exception resource paths that are not subject to the cross-tenant access control field: The tenant permission policy document is associated with the tenant identifier to generate a first permission policy at the tenant level, and is stored, which can be stored in a permission arbitration engine.

[0028] Wherein, for example, cross-tenant access interception is as follows: (1) Set tenant A to not allow cross-tenant access; (2) User1 under tenant B accesses resources under tenant A; (3) Permission decision engine: detects that the resource belongs to tenant A, and checks that the request user belongs to tenant B, access denied; (4) Trigger the global Deny policy of tenant A to deny access, and generate a deny access result.

[0029] In the above embodiment, by configuring the tenant-level permission policy, efficient and unified global security management and control is realized, which can define the access baseline of all users and resources in the entire tenant through one rule, and forcibly realize security isolation (such as prohibiting cross-tenant access), thereby reducing the management complexity in the multi-tenant environment, ensuring the consistency and security of the permissions, and fundamentally preventing unauthorized access.

[0030] In some specific embodiments, configuring a second permission policy at the user level includes: Receiving a user permission policy configuration request, the user permission policy configuration request including at least a user identifier, a user belonging tenant identifier, and a user-specific policy rule, wherein the user-specific policy rule is a personalized access control rule set for a single specific user in the object storage system, which finely adjusts the permissions of the user based on the global policy of the belonging tenant, for example, granting special permissions (such as allowing access to a certain sensitive directory) or imposing additional restrictions (such as prohibiting deletion of a specific file), such rules usually exist in the form of policy documents (such as JSON format), which explicitly specify the allowed (Allow) or denied (Deny) operations and resources, the user-specific policy follows the "deny first" principle, and can override the allowed items in the tenant policy, but cannot bypass the prohibitive rules at the tenant level, thereby realizing flexible and secure fine-grained permission management; According to the user permission policy configuration request, a user permission policy document is generated, which is independent of the tenant permission policy rules of its belonging tenant and supports defining allowed or denied access operations for target resources; Associating the user permission policy document with the user identifier and the belonging tenant identifier to generate a second permission policy at the user level, and storing it, the storage location can be the permission decision engine.

[0031] In the above embodiment, by configuring the user-level permission policy, fine-grained permission management can be realized, specific users can be flexibly authorized or restricted in their operations on specific resources within the framework of the tenant global policy, thereby realizing precise matching of permissions and responsibilities, and enhancing the security and flexibility of the system, and avoiding over-allocation of permissions.

[0032] In some embodiments, determining the target first permission policy of the tenant that the user needs to access and the target second permission policy corresponding to the user according to the access request of the user comprises: extracting the user identifier, the tenant identifier, the operation type and the resource path based on the access request of the user; determining the target second permission policy corresponding to the user based on the user identifier, i.e., comparing the user identifier with the pre-stored data to determine the permission policy of the user; determining the tenant that the user needs to access and the target first permission policy of the tenant based on the tenant identifier, i.e., comparing the tenant identifier with the pre-stored data to determine the tenant that the user needs to access and the permission policy of the tenant.

[0033] In some embodiments, merging the target first permission policy and the target second permission policy comprises: detecting whether the target second permission policy is empty, i.e., whether the user policy is configured, if not, it is empty, otherwise, it is not; in response to the target second permission policy being empty, inheriting the request access rule in the target first permission policy to generate a merged result, i.e., in the case that the user policy is not configured, the tenant policy is completely inherited and defined as the merged result; in response to the target second permission policy not being empty, detecting whether there is a deny rule matching the operation type and the resource path in the target first permission policy and the target second permission policy, i.e., in the case that the user policy is configured, deny is prioritized; if there is, defining the request access rule corresponding to the deny rule as deny and merging other allow rules to generate a merged result, i.e., merging the allow rules in the two policies, defining the request access rule with the deny rule as deny, and defining the merged allow rules and deny rules as the merged result; if not, merging the allow rules in the target first permission policy and the target second permission policy to generate a merged result.

[0034] Specifically, the above steps are set in a permission decision engine, which specifically comprises: receiving a user request, extracting a tenant ID, a user ID, an operation type and a resource path, loading corresponding tenant policies and user policies, and executing decision rules: (1) any Deny policy is immediately denied; (2) Allow permissions are merged when there is no conflict; (3) the tenant is inherited by default when the policy is not defined.

[0035] When the tenant policy and the user policy are inconsistent, deny is prioritized, for example: (1) tenant A configures a policy: {"Effect": "Allow", "Action": "s3:*", "Resource": "bucket-shared / *"} (2) User user1 (belongs to tenant A) configures the policy: {"Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "bucket-shared / confidential / *"} (3) User (belongs to tenant A) requests to delete bucket-shared / confidential / report.docx: Engine merges policies: inherits the full access of tenant A, but is denied by user1's DeleteObject, so the result is: denied deletion.

[0036] Further, when the tenant policy and the user policy are inconsistent, deny is prioritized, for example: (1) Tenant A configures the policy: {"Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "bucket-shared / confidential / *"} (2) User user1 (belongs to tenant A) configures the policy: {"Effect": "Allow", "Action": "s3:*", "Resource": "bucket-shared / *"} (3) User user1 (belongs to tenant A) requests to delete bucket-shared / confidential / report.docx: Engine merges policies: because tenant A is configured to deny DeleteObject, deny is prioritized, and there is no need to continue to verify user permissions, user1's operation is denied, so the result is: denied deletion.

[0037] In the above embodiments, by dynamically loading and merging tenant policies and user policies, the real-time, flexibility and security of permission management can be achieved, the system can dynamically calculate the most authority according to real-time requests, ensure that policy changes take effect immediately, while supporting fine-grained authorization for users on the premise of following the tenant global security bottom line, balancing unified control and personalized needs, significantly improving the efficiency and security of operation and maintenance in a multi-tenant environment.

[0038] In some embodiments, based on the merging result, the access request is subjected to a permission decision, and a result of allowing or denying access is obtained, including: receiving the merging result; obtaining an operation type and a resource path corresponding to the access request; matching the operation type and the resource path with request access rules in the merging result in sequence, that is, matching the two specific values of "operation type" and "resource path" extracted from the user access request with the two fields of "operation" and "resource" defined in the policy rule, for example, the specific value of the operation type includes s3:GetObject (read object), s3:PutObject (upload object), s3:DeleteObject (delete object), and the like, and the specific value of the resource path includes my-bucket / confidential / project-plan.docx (a specific file) or my-bucket / confidential / * (a wildcard path), and the like, each policy rule contains two core definition fields: Action (operation): defining which operations the rule is effective for, for example, s3:GetObject or s3:*(all S3 operations); Resource (resource): defining which resources the rule is effective for, for example, arn:aws:s3:::my-bucket / confidential / *, for each rule, check whether the operation type of the current request is contained in the Action field of the rule and whether the resource path of the current request is contained in the Resource field of the rule, if yes, the matching is successful, and the like; in response to matching any one of the request access rules as denial, a result of denying access is obtained, for example, a rule stipulates "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::my-bucket / confidential / *", when a request to delete a file my-bucket / confidential / project-plan.docx arrives, the operation type (s3:DeleteObject) and the resource path (my-bucket / confidential / project-plan.docx) completely match the Action and Resource fields of the rule, therefore, the "denial" rule is hit, and the request is denied; in response to not matching the denial rule and matching at least one of the request access rules as permission, a result of allowing access is obtained; In response to the request access rule not being matched, a system default ruling result is output, wherein the system default ruling result is a result obtained by ruling according to a system preset higher-level and more basic security rule (such as "default rejection").

[0039] Specifically, as shown in Figure 3 user1 accesses a resource under tenant A, it is determined whether the tenant to which user1 belongs is tenant A, if yes, it is determined whether the tenant policy allows user1 to access, if yes, it is determined whether the user policy allows user1 to access, if yes, it is determined whether the bucket policy rejects user1 to access, if no, it is determined whether the bucket ACL / object ACL allows user1 to access, if yes, user1 successfully accesses the resource under tenant A, and an access allowed result is obtained, if tenant A does not allow cross-tenant access or other access rejection rules appear in the entire process, it is determined that user1 fails to access the resource under tenant A, and an access rejected result is generated.

[0040] In the above embodiment, ruling the permissions based on the conflict ruling rule can ensure the accuracy, security and efficiency of the permission determination result, avoid unauthorized access by strictly following the explicit rule of "rejection first", and at the same time realize millisecond-level dynamic ruling, thereby guaranteeing the reliability and consistency of access control in a multi-policy environment.

[0041] In some specific embodiments, the method further comprises: triggering a tenant policy update event in response to the tenant-level first permission policy being updated; obtaining a user list of users corresponding to the tenant, i.e., a list of user IDs under the tenant, in response to the tenant policy update event having been triggered; pushing the tenant policy update event to a permission ruling engine, and updating the cached data in the permission ruling engine based on the updated tenant-level first permission policy, the permission ruling engine being used at least to store the tenant-level permission policy.

[0042] Specifically, when the tenant policy is modified, an update event is triggered based on an index service; all users under the tenant are queried through a database; a user list is returned through the index service; policy updates are pushed in batches through the permission engine; and real-time effect notification is realized through an API gateway, i.e., the tenant policy modification is dynamically effective, and automatic reverse indexing batch updates are realized.

[0043] In the above embodiment, when the global policy of a tenant is modified, the system can automatically and quickly make the update effective to all users under the tenant, without manually modifying the permissions of users one by one, and through reverse indexing, the tenant-level policy modification can be quickly and accurately sent to all subordinate users, thereby realizing centralized management and dynamic real-time effect of permissions, and solving the performance bottleneck of permission update for a large number of users.

[0044] In some embodiments, the method further comprises: Real-time acquisition of user access data, extraction of key features (such as access period, operation frequency, resource sensitivity level, deviation from regular behavior index, etc.), generation of time series behavior feature vector; Lightweight neural network model (such as LSTM) is used to model user behavior sequence, generate dynamic behavior portrait, and quantitatively evaluate user risk level and permission requirement tendency, such as identifying users who frequently access sensitive resources to automatically upgrade monitoring level; When abnormal behavior (such as batch downloading of core data at non-working hours) is detected, a temporary Deny rule is automatically injected to intercept access, and an alarm is triggered; for users who are long-term compliant and have stable needs (such as analysts who only need read-only permissions), a minimum permission template is automatically recommended to simplify policy configuration; based on the change of behavior portrait, policy audit is automatically initiated, and it is suggested to revoke idle permissions or extend high-frequency necessary permissions; an anonymous threat intelligence sharing mechanism between tenants is established, when a malicious user pattern is detected in a tenant, the feature fingerprint is synchronized to other tenants in the platform, and the potential threat is blocked in advance across tenants.

[0045] In the above embodiments, the behavior portrait is intelligently adjusted to realize pre-prediction and in-process interception, improve security, and greatly reduce operation and maintenance costs. Based on automatic policy optimization and cross-tenant threat defense, internal and external threats can be effectively prevented, and high-level compliance requirements can be met.

[0046] In the above permission control method, the method comprises: configuring a first permission policy at a tenant level, the first permission policy comprising at least a cross-tenant access control mechanism; configuring a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; receiving an access request of a user, determining a target first permission policy of the user for accessing a tenant and a target second permission policy corresponding to the user according to the access request of the user; merging the target first permission policy and the target second permission policy, and making a permission decision on the access request based on the merging result to obtain an access allowed or denied result. The permission control method based on user-tenant dual dimensions considers the permission control requirements of both user and tenant dimensions, can dynamically adjust the permission control policy, and can update the permission control policy in real time according to the changes of user and tenant, thereby ensuring the isolation between tenants and ensuring the security and compliance of data.

[0047] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and general hardware platform as necessary, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0048] It should be understood that, althoughFigures 2-3 The steps in the flowchart are displayed in sequence according to the arrows, but the steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, the steps are not strictly limited in sequence, and the steps can be executed in other orders. Moreover, Figures 2-3 At least part of the steps in the flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of the sub-steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or sub-steps or stages of other steps.

[0049] Embodiments of the present application also provide a permission control device, as shown in Figure 4 The device comprises a first configuration module, a second configuration module, a permission policy determination module, and a result generation module, wherein: The first configuration module is configured to configure a first permission policy at a tenant level, and the first permission policy comprises at least a cross-tenant access control mechanism; The second configuration module is configured to configure a second permission policy at a user level, and the second permission policy supports inheritance and / or overriding of the first permission policy; The permission policy determination module is configured to receive an access request of a user, and determine a target first permission policy of a tenant accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; The result generation module is configured to merge the target first permission policy and the target second permission policy, make a permission decision on the access request based on the merging result, and obtain a result of allowing or refusing access.

[0050] As a preferred embodiment, in the embodiments of the present application, the first configuration module is specifically configured to: receive a tenant permission policy configuration request, and the tenant permission policy configuration request comprises at least a tenant identifier and a tenant permission policy rule; generate a tenant permission policy document according to the tenant permission policy configuration request, and the tenant permission policy document comprises at least a cross-tenant access control field and a resource exception list field; associate the tenant permission policy document with the tenant identifier, generate the first permission policy at the tenant level, and store the first permission policy.

[0051] As a preferred embodiment, in the embodiments of the present application, the second configuration module is specifically configured to: receive a user permission policy configuration request, and the user permission policy configuration request comprises at least a user identifier, a tenant identifier to which the user belongs, and a user-specific policy rule; According to the user permission policy configuration request, a user permission policy document is generated, the user permission policy document is independent of tenant permission policy rules of a tenant to which the user permission policy document belongs, and the user permission policy document supports defining allowed or denied access operations for a target resource. The user permission policy document is associated with a user identifier and a tenant identifier to which the user permission policy document belongs, a second permission policy at a user level is generated, and the second permission policy is stored.

[0052] As a preferred implementation, in the embodiment of the present application, the permission policy determination module is specifically configured to: Based on the access request of the user, a user identifier, a tenant identifier, an operation type, and a resource path are extracted. Based on the user identifier, a target second permission policy corresponding to the user is determined. Based on the tenant identifier, a tenant to be accessed by the user and a target first permission policy of the tenant are determined.

[0053] As a preferred implementation, in the embodiment of the present application, the result generation module is specifically configured to: Detect whether the target second permission policy is empty. In response to the target second permission policy being empty, request access rules in the target first permission policy are inherited to generate a merged result. In response to the target second permission policy not being empty, it is detected whether there is a denied rule matching the operation type and the resource path in the target first permission policy and the target second permission policy. If there is, the request access rule corresponding to the denied rule is defined as denied, and other allowed rules are merged to generate a merged result. If there is not, allowed rules in the target first permission policy and the target second permission policy are merged to generate a merged result.

[0054] As a preferred implementation, in the embodiment of the present application, the result generation module is specifically further configured to: Receive the merged result. Obtain an operation type and a resource path corresponding to the access request. Match the operation type and the resource path with request access rules in the merged result in sequence. In response to any one of the request access rules being denied, a result of denied access is obtained. In response to no denied rule being matched and at least one of the request access rules being allowed, a result of allowed access is obtained. In response to no request access rule being matched, a system default ruling result is output.

[0055] As a preferred implementation, in the embodiment of the present application, the first configuration module is specifically configured to: In response to the first permission policy at the tenant level being updated, a tenant policy update event is triggered; In response to the tenant policy update event having been triggered, a user list of users corresponding to the tenant is obtained; The tenant policy update event is pushed to a permission adjudication engine, and based on the updated first permission policy at the tenant level, cached data in the permission adjudication engine is updated, the permission adjudication engine being configured to at least store permission policies at the tenant level.

[0056] The description of the features in the embodiments of the permission control apparatus can refer to the related description of the embodiments of the permission control method, which will not be repeated here. Each module in the above permission control apparatus can be realized by software, hardware, and combinations thereof, in whole or in part. Each module described above can be embedded in or independent of the processor in the electronic device in hardware form, or can be stored in the memory in the electronic device in software form, so as to be called and executed by the processor to perform the operations corresponding to each module.

[0057] In one embodiment, an electronic device, which can be a terminal, can have an internal structure diagram as shown in Figure 5 The electronic device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. The processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The network interface of the electronic device is configured to communicate with external terminals through network connections. The computer program is executed by the processor to implement a permission control method. The display screen of the electronic device can be a liquid crystal display screen or an electronic ink display screen. The input device of the electronic device can be a touch layer overlaid on the display screen, or a key, trackball, or touchpad provided on the housing of the electronic device, or an external keyboard, touchpad, or mouse, etc.

[0058] Those skilled in the art can understand that Figure 5 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the electronic device to which the scheme of the present application is applied. The specific electronic device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0059] An electronic device is provided in an embodiment of the present application, including a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in the embodiments of the permission control method, including: S1: configure a first permission policy at a tenant level, the first permission policy including at least a cross-tenant access control mechanism; S2: configure a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; S3: receive an access request of a user, and determine a target first permission policy of a tenant to be accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; S4: merge the target first permission policy and the target second permission policy, make a permission decision on the access request based on a merging result, and obtain an access-allowed or access-denied result.

[0060] Embodiments of the present application also provide a computer readable storage medium, which stores a computer program. The computer program is configured to execute the steps in the permission control method embodiments when running, including: S1: configure a first permission policy at a tenant level, the first permission policy including at least a cross-tenant access control mechanism; S2: configure a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; S3: receive an access request of a user, and determine a target first permission policy of a tenant to be accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; S4: merge the target first permission policy and the target second permission policy, make a permission decision on the access request based on a merging result, and obtain an access-allowed or access-denied result.

[0061] In an example embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0062] Embodiments of the present application also provide a computer program product, which includes a computer program. The computer program is executed by a processor to implement the steps in the permission control method embodiments, including: S1: configure a first permission policy at a tenant level, the first permission policy including at least a cross-tenant access control mechanism; S2: configure a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; S3: receive an access request of a user, and determine a target first permission policy of a tenant to be accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; S4: merge the target first permission policy and the target second permission policy, and make a permission decision on the access request based on the merging result to obtain a result of allowing or rejecting the access.

[0063] Embodiments of the present application also provide another computer program product, comprising a non-volatile computer readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the steps in the permission control method embodiments, comprising: S1: configure a first permission policy at a tenant level, the first permission policy comprising at least a cross-tenant access control mechanism; S2: configure a second permission policy at a user level, the second permission policy supporting inheritance and / or overriding of the first permission policy; S3: receive an access request of a user, and determine a target first permission policy of a tenant accessed by the user and a target second permission policy corresponding to the user according to the access request of the user; S4: merge the target first permission policy and the target second permission policy, and make a permission decision on the access request based on the merging result to obtain a result of allowing or rejecting the access.

[0064] Those skilled in the art will further appreciate that the functions of the examples described herein-based embodiments can be implemented using electronic hardware, computer software, or any combination thereof. To clearly illustrate the interchangeability of hardware and software, various examples have been described herein-based embodiments in terms of their general functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0065] The above describes in detail a permission control method, device, electronic device and storage medium provided by the present application. The principles and implementation manners of the present application are described herein by applying specific examples. The above description of the examples is only used to help understand the method and core idea of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, some improvements and modifications can be made to the present application. These improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A method for access control, characterized in that, The method includes: Configure a tenant-level first permission policy, which includes at least a cross-tenant access control mechanism. Configure a second permission policy at the user level, which supports inheritance and / or overriding of the first permission policy; Receive user access request, and determine the target first permission policy that the user needs to access the tenant and the target second permission policy corresponding to the user based on the user access request; The target first permission policy and the target second permission policy are merged, and based on the merging result, the access request is adjudicated to obtain a result of allowing or denying access.

2. The access control method according to claim 1, characterized in that, Configuring first-priority policies at the tenant level includes: Receive a tenant permission policy configuration request, wherein the tenant permission policy configuration request includes at least a tenant identifier and a tenant permission policy rule; Based on the tenant permission policy configuration request, a tenant permission policy document is generated. The tenant permission policy document includes at least a cross-tenant access control field and a resource exception list field. Associate the tenant permission policy document with the tenant identifier to generate the first permission policy at the tenant level, and store it.

3. The access control method according to claim 1, characterized in that, Configuring user-level second-privilege policies includes: Receive a user permission policy configuration request, wherein the user permission policy configuration request includes at least a user identifier, a user's tenant identifier, and a user-specific policy rule; Based on the user permission policy configuration request, a user permission policy document is generated. The user permission policy document is independent of the tenant permission policy rules of its tenant and supports defining allow or deny access operations for target resources. The user permission policy document is associated with the user identifier and the tenant identifier to generate the second permission policy at the user level, and then stored.

4. The access control method according to claim 1, characterized in that, Based on the user's access request, determining the target first access policy and the corresponding target second access policy for the user to access the tenant includes: Based on the user's access request, extract the user identifier, tenant identifier, operation type, and resource path; Based on the user identifier, determine the target second permission policy corresponding to the user; Based on the tenant identifier, determine the tenant that the user needs to access and the target first permission policy of the tenant.

5. The access control method according to claim 4, characterized in that, Merging the target first permission policy and the target second permission policy includes: Check if the target second permission policy is empty; If the target second permission policy is empty, the request access rules in the target first permission policy are inherited to generate a merged result; In response to the target second permission policy not being empty, it is detected whether there is a denial rule in the target first permission policy and the target second permission policy that matches the operation type and the resource path; If it exists, the request access rule corresponding to the denial rule is defined as a denial, and other allow rules are merged to generate a merged result; If it does not exist, then merge the allow rules in the target first permission policy and the target second permission policy to generate a merge result.

6. The access control method according to claim 1, characterized in that, Based on the merged results, the access request is subject to permission adjudication, resulting in either permission granted or denied access. Receive the merge result; Obtain the operation type and resource path corresponding to the access request; The operation type and the resource path are matched sequentially with the request access rules in the merged result; If any request access rule is matched as "deny", the result is "access denied". If no deny rule is found and at least one access rule is matched for the request, the result is "access allowed". If no matching rule is found for the requested access, the system's default decision result is output.

7. The access control method according to claim 1, characterized in that, The method further includes: In response to the update of the first permission policy at the tenant level, a tenant policy update event is triggered; In response to the tenant policy update event being triggered, obtain the user list of the user corresponding to the tenant; The tenant policy update event is pushed to the permission adjudication engine, and the cached data in the permission adjudication engine is updated based on the updated tenant-level first permission policy. The permission adjudication engine is used to store at least the tenant-level permission policy.

8. An access control device, characterized in that, The device includes: The first configuration module is used to configure the first permission policy at the tenant level, and the first permission policy includes at least a cross-tenant access control mechanism. The second configuration module is used to configure a second permission policy at the user level, wherein the second permission policy supports inheritance and / or overriding of the first permission policy; The permission policy determination module is used to receive user access requests and, based on the user access requests, determine the target first permission policy that the user needs to access the tenant and the target second permission policy corresponding to the user. The result generation module is used to merge the target first permission policy and the target second permission policy, and based on the merged result, to make a permission decision on the access request and obtain a result of allowing or denying access.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for implementing the steps of the access control method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the access control method as described in any one of claims 1 to 7.

Images