Permission management method and apparatus, readable storage medium, and electronic device

Abstract

The present application relates to a permission management method and apparatus, a readable storage medium, and an electronic device. The method comprises: acquiring permission data of a plurality of accounts; clustering the plurality of accounts on the basis of the permission data of the plurality of accounts; and on the basis of the clustering result of the plurality of accounts, generating permission configuration information for at least one account category. Thus, permission structures can be clearly and concisely described, and permission requirements of users and systems can be better understood, thereby implementing precise and secure permission control. By means of generated permission configuration information, system administrators can clearly see the permission distribution of each account, so as to quickly discover and deal with redundant and excessive permissions, making permission management more precise, thus bringing great convenience to system administrators, and also greatly improving the security and efficiency of service systems.

Description

Rights management method, device, readable storage medium and electronic device

[0001] This application claims priority to Chinese patent application No. 202311778476.3 filed on December 21, 2023, and the contents of the above-mentioned Chinese patent application disclosure are hereby cited in their entirety as part of this application. Technical Field

[0002] The present disclosure relates to a rights management method, device, readable storage medium and electronic device. Background Art

[0003] Permission management generally refers to the management of access rights or access rules for different users to predefined resources, based on the security rules or policies set by the business system. Generally speaking, users can access and only access authorized resources in specific ways (e.g., read, write, delete, etc.). Permission management is a critical issue for business system developers. Any multi-user business system inevitably involves permissions management. The more users a business system has, and the more complex their attributes or division of labor, the more complex permissions management becomes. Permission management technology is trending towards multi-level and multi-dimensional development. Summary of the Invention

[0004] This summary is provided to briefly introduce concepts that will be described in detail in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] The present disclosure provides a rights management method, comprising:

[0006] Obtain permission data for multiple accounts in the business system;

[0007] clustering the multiple accounts according to the permission data of the multiple accounts;

[0008] According to the clustering result of the multiple accounts, permission configuration information for at least one account category of the business system is generated.

[0009] The present disclosure provides a rights management device, comprising:

[0010] The acquisition module is configured to obtain permission data of multiple accounts in the business system;

[0011] a first clustering module configured to cluster the multiple accounts according to the permission data of the multiple accounts;

[0012] The first generating module is configured to generate permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts.

[0013] The present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the rights management method provided above in the present disclosure.

[0014] The present disclosure provides an electronic device, comprising:

[0015] a storage device having a computer program stored thereon;

[0016] A processing device is used to execute the computer program in the storage device to implement the steps of the rights management method provided above in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are merely embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0018] FIG1 is a flow chart showing a method for rights management according to an exemplary embodiment;

[0019] FIG2 is a schematic diagram showing a simplified permission graph according to an exemplary embodiment;

[0020] FIG3 is a schematic diagram showing an architecture of permission processing according to an exemplary embodiment;

[0021] FIG4 is a schematic diagram showing an architecture of data collection and processing according to an exemplary embodiment;

[0022] FIG5 is a schematic diagram showing a rights merging according to an exemplary embodiment;

[0023] FIG6 is a block diagram showing a rights management apparatus according to an exemplary embodiment; and

[0024] Fig. 7 is a schematic structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0025] Before introducing the specific embodiments of the present disclosure, the terms involved in the present disclosure are first introduced and explained.

[0026] Kubernetes (K8s for short) is an open-source container orchestration system designed to automate, scale, and manage the deployment and operation of containerized applications. With Kubernetes, developers and system administrators can easily deploy, manage, and scale applications running in containers without having to worry about the underlying infrastructure. Kubernetes provides a declarative configuration approach that allows users to define the desired state of an application, and the system automatically ensures that the application reaches and remains in that state.

[0027] Role-Based Access Control (RBAC) is a permission control mechanism in Kubernetes. It allows administrators to control who can access which resources in the Kubernetes Application Programming Interface (API) by defining roles and role bindings. In RBAC, a role contains a set of permissions (such as the ability to read, write, and delete resources), while a role binding assigns a role to a specific user or user group. With RBAC, administrators can control user access to Kubernetes clusters at a very granular level, thereby protecting cluster security and ensuring compliance.

[0028] Kubernetes log analysis is an important feature in the Kubernetes system that provides the ability to record and save cluster activities. Through log analysis, system administrators and security experts can trace back events that occurred in the cluster to ensure the security of the system. In Kubernetes log analysis, the log analysis system captures every request that occurs on the cluster and records it in the log. Each log entry contains detailed information about the request, such as the identity of the requester, the time of the request, the operation performed, the resources affected, and the results of the request. The Kubernetes log analysis feature works by defining log analysis policies. Administrators can configure log analysis policies as needed to determine which types of requests should be recorded and how much detailed information should be recorded. In this way, administrators can customize the log analysis configuration according to their security needs.

[0029] Permission modeling is a method for creating and optimizing permission configurations by analyzing the behavior and permission requirements of users or roles within a system. This approach is particularly useful for complex systems and environments with large numbers of users and varying levels of permissions. Through permission modeling, you can better understand user and system permission requirements, enabling more refined and secure permission control.

[0030] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0031] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0032] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0033] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0034] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0035] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0036] The data involved in this technical solution (including but not limited to the data itself, the acquisition, use, storage or deletion of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0037] It is understandable that before using the technical solutions disclosed in the various embodiments of the present disclosure, the type, scope of use, usage scenarios, etc. of the information involved in the present disclosure should be informed to relevant users and authorization should be obtained from relevant users in an appropriate manner in accordance with relevant laws and regulations. The relevant users may include any type of right holders, such as individuals, enterprises, and groups.

[0038] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operations of the disclosed technical solution based on the prompt message.

[0039] As an optional but non-limiting implementation, in response to receiving a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0040] It is understandable that the above notification and user authorization process are merely illustrative and do not limit the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0041] At the same time, it is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions.

[0042] Fig. 1 is a flow chart showing a method for rights management according to an exemplary embodiment. As shown in the figure, the method for rights management may include S101 to S103.

[0043] In S101 , permission data of multiple accounts in the business system is obtained.

[0044] In this disclosure, an account is an existing account in a business system. Multiple accounts may include all existing accounts in the business system, or may include some existing accounts in the business system. The business system may be, for example, the aforementioned Kubernetes system, the aforementioned permission management method is an RBAC-based permission management mechanism, and the system may include multiple Kubernetes clusters.

[0045] Permission data may include, but is not limited to, the account name (Account) of the corresponding account, the accessed namespace (Namespace), the accessed API group (APIGroup), the accessed resource (Resource), the operation on the resource (Verb), etc., which constitute a set of structured data.

[0046] In S102 , the multiple accounts are clustered according to their permission data.

[0047] In S103 , permission configuration information for at least one account category of the business system is generated based on the clustering result of the multiple accounts.

[0048] In the present disclosure, a clustering result of multiple accounts may include at least one account category, where each account category includes at least one account. Multiple accounts may belong to the same account category, in which case the clustering result of multiple accounts includes one account category; multiple accounts may belong to different account categories, in which case the clustering result of multiple accounts includes multiple account categories.

[0049] When clustering multiple accounts, accounts with highly similar access permissions can be grouped into a single account category. Figure 2 shows the complex permission relationships between different roles, accounts, and service accounts in a Kubernetes cluster, as well as their relationships with the cluster, API groups, resources, and operations. The figure simplifies these complex permission relationships. After clustering multiple accounts, we found that the access permissions of Account1, Account2, and Account3 were highly similar, so we grouped them into a single account category, Cluster 1. Similarly, we clustered other accounts to obtain clustering results. As shown in Figure 2, clustering Account1, Account2, Account3, Account4, Service Account1, and Service Account2 yields two account categories, Cluster 1 and Cluster 2. Account1, Account2, and Account3 belong to Cluster 1, while Account4, Service Account1, and Service Account2 belong to Cluster 2.

[0050] In the above technical solution, after obtaining permission data for multiple accounts in a business system, the accounts are clustered based on this data. Based on the clustering results, permission configuration information for at least one account category in the business system is generated. This allows for a clear and concise description of the permission structure, enabling a better understanding of user and system permission requirements, and enabling more refined and secure permission control. Through this generated permission configuration information, system administrators can clearly understand the permission distribution of each account, allowing them to quickly identify and address redundant and excessive permissions, making permission management more refined. This not only brings great convenience to system administrators, but also significantly improves the security and efficiency of business systems.

[0051] The following is a detailed description of the specific implementation method for obtaining the permission data of multiple accounts in the business system in the above S101. Specifically, it can be achieved through a variety of implementation methods. In one implementation method, the above business system may include a large number of clusters. For the collection and processing of a large amount of log data generated by hundreds of clusters, the present disclosure adopts an efficient solution that comprehensively utilizes distributed processing, multi-level cache and synchronization mechanisms. A multi-level cache architecture is used to optimize the collection and processing efficiency of log data. In this architecture, different levels of cache are designed to process different data to ensure the efficient operation of the system. Since the amount of log data is usually large and there is a large amount of duplicate data, the present disclosure customizes a specific cache level based on the characteristics and processing requirements of the log data. Each cache level is optimized for different data processing stages and the characteristics of the log data. Specifically, the following steps (1) and (2) can be used to obtain the permission data of multiple accounts in the business system:

[0052] Step (1): Obtain target resource access records of multiple accounts in the business system from the first cache area.

[0053] In the present disclosure, the above-mentioned permission processing method can be applied to electronic devices, as shown in Figures 3 and 4. The electronic device can collect and process log data through a distributed log collection system, wherein the distributed log system includes multiple distributed clients (i.e., the data processing nodes in Figure 4). Specifically, the log data of the business system can be synchronously collected through multiple distributed clients, and the target resource access records of each account can be extracted from the respective collected log data through multiple distributed clients and stored in a local cache area (i.e., the L1 cache in Figures 3 and 4). The target resource access records in the local cache area are regularly synchronized to the first cache area (i.e., the L2 cache in Figures 3 and 4). Among them, each local cache area and the first cache area constitute a multi-level cache.

[0054] Log data is collected using distributed clients, each responsible for collecting corresponding log data. This allows for parallel processing of large amounts of data, improving data collection and processing efficiency. This ensures efficient collection and processing of log data in a multi-cluster environment. This not only allows for rapid processing of large volumes of log data, but also ensures the accuracy of recorded access permissions. This provides a solid foundation for subsequent data analysis and rights management.

[0055] Step (2): For each account, generate the permission data of the account based on the target resource access record of the account.

[0056] In the present disclosure, a target resource access record can be extracted from a log data corresponding to an account, wherein the target resource access record includes information such as the account's access to resources, operations performed on resources, etc., which includes but is not limited to the account name (Account) of the corresponding account, the namespace accessed (Namespace), the API group accessed (APIGroup), the resource accessed (Resource), the operation on the resource (Verb), etc., which constitute a structured data. An account may contain multiple target resource access records, and multiple target resource access records contain different resource access information. In this case, the resource access information involved in multiple target resource access records can be integrated to obtain the permission data of the account.

[0057] As shown in Figures 3 and 4, multiple distributed clients collect log data of the business system in parallel. After collecting the log data, each distributed client performs data preprocessing on the collected log data to obtain the target resource access record of the corresponding account, and then stores the target resource access record in the local cache area (i.e., L1 cache) of the distributed client. The data in the local cache area of ​​each distributed client is regularly synchronized to the first cache area (i.e., L2 cache). In this way, the electronic device can asynchronously obtain the target resource access records of multiple accounts in the business system from the first cache area, and then generate the permission data of each account based on these target resource access records. Among them, the first cache area can be a cache area set on the above-mentioned electronic device, or it can be a cache area set on other devices or the cloud.

[0058] The above-mentioned synchronization mechanism may include data synchronization and status synchronization. Among them, data synchronization refers to the regular synchronization of target resource access records from the upstream local cache area to the downstream first cache area. The electronic device can asynchronously obtain data from the first cache area, thereby realizing an asynchronous synchronization mechanism, thereby ensuring the complete transmission of data without affecting the real-time performance of the system. State synchronization refers to the maintenance of a unified state information (i.e., permission-related information of multiple accounts) between multiple levels of cache to track the progress and status of data processing.

[0059] To avoid the problem of a distributed log collection system being unable to process sudden increases in system log data in a timely manner, a second buffer area can be set up to store the log data of the business system. That is, the log data is stored in the second buffer area. In this way, multiple distributed clients can collect log data from the second buffer area respectively. The log data in the second buffer area can be stored in the form of a queue.

[0060] In addition, the distributed client extracts the target resource access records of each account from the log data through the following steps (11) to (14) (i.e., the data preprocessing in Figures 3 and 4):

[0061] Step (11): Extract the original resource access records of each account from the log data.

[0062] In the present disclosure, an original resource access record can be extracted from a log data corresponding to an account, wherein the original resource access record includes information such as the account's access to resources, operations performed on resources, etc., which includes but is not limited to the account name (Account) of the corresponding account, the accessed namespace (Namespace), the accessed API group (APIGroup), the accessed resource (Resource), the operation on the resource (Verb), etc., which constitute an unstructured data.

[0063] Step (12): For each original resource access record, perform structured processing on the original resource access record.

[0064] The collected raw resource access records are organized into a structured format to facilitate subsequent data processing and analysis.

[0065] Step (13): Standardize the resource access records obtained after the structured processing.

[0066] In different raw resource access records, the same attribute may be represented using different forms or parameters. To facilitate subsequent permission analysis and management, the resource access records obtained after structured processing can be standardized. Standardization refers to the standardization of various attributes of permission entities (i.e., accounts) and relationships (such as permission level, resource type, operation type, etc.) to ensure data consistency.

[0067] Step (14): Deduplication is performed on the resource access records obtained after each standardization process to obtain target resource access records of multiple accounts.

[0068] An account may access the same resource multiple times. Therefore, an account may have multiple duplicate original resource access records. Correspondingly, the resource access records obtained after each standardization process may contain duplicate records. Therefore, the resource access records obtained after each standardization process can be deduplicated.

[0069] In addition to collecting and processing log data using distributed log collection, the electronic device can also collect and process log data locally. Specifically, in another embodiment, the electronic device can directly collect log data from the business system and then extract the target resource access records of each account from the collected log data. Finally, for each account, the electronic device generates permission data based on the target resource access records of the account. The electronic device can extract the target resource access records of each account from the collected log data in a manner similar to the above-mentioned distributed client extracting the target resource access records of each account from the log data. This disclosure will not elaborate on this.

[0070] In order to meet the needs of more data sources, when obtaining original resource access records, in addition to log data, the data source can also include offline data, as shown in Figure 3, that is, the original resource access records of each account can be extracted from both offline data and log data.

[0071] The following describes in detail the specific implementation of clustering multiple accounts based on the permission data of multiple accounts in the above S102. Specifically, it can be achieved through the following steps [1] and [2].

[0072] Step [1]: For each of the multiple accounts, generate a permission graph corresponding to the account based on the permission data of the account.

[0073] In the present disclosure, in the permission graph, different types of nodes are defined to represent account names (Account), namespaces (Namespace), API groups (APIGroup), resources (Resource), and operations (Verb) respectively; if an account has the right to access a certain namespace, then there is an edge relationship between the account name node of the account and the namespace node accessible to the account; if an account has the right to access a certain API group, then there is an edge relationship between the account name node of the account and the API group node accessible to the account; if an account has the right to access certain resources of a certain API group, then there is an edge relationship between the API group node accessible to the account and the resource node accessible to it; if an account has the right to perform certain operations on a certain resource, then there is an edge relationship between the resource node accessible to the account and the operation node on the resource.

[0074] Step [2]: Cluster the multiple accounts according to the permission graphs corresponding to the multiple accounts.

[0075] After obtaining the permission data of multiple accounts in the business system, a permission graph corresponding to each account is generated based on the permission data of the account. In this way, the complex permission structure can be successfully simplified and visualized, providing a clear and intuitive visual foundation for permission management and subsequent data processing, making permission management more intuitive and easy to understand.

[0076] The following describes in detail the specific implementation method of generating the permission graph corresponding to the account based on the permission data of the account in the above step [1].

[0077] In one embodiment, the account name, namespace, API group, resources, operations, etc. in the account's permission data can be used as nodes; then, based on the account's permissions for the namespace, API group, resources, and operations, edge relationships are constructed between the nodes. Specifically, if an account has access to a certain namespace, an edge relationship is established between the account's account name node and the namespace node; if an account has access to a certain API group, an edge relationship is established between the account's account name node and the API group node; if an account has access to certain resources in an API group, an edge relationship is established between the API group node accessible to the account and the resource node accessible to it; if an account has access to certain operations on a resource, an edge relationship is established between the resource node accessible to the account and the node for its operation on the resource.

[0078] In addition, to improve the readability and comprehensibility of the permission graph, after generating the permission graph, a hierarchical layout algorithm can be used to optimize the arrangement of nodes in the permission graph.

[0079] As shown in Figure 4, after the permission graph is generated, its data can be stored. As shown in Figure 3, the permission graph of each account can be stored in a graph database, which facilitates the subsequent use of visualization tools to visualize the permission graph corresponding to the specified account.

[0080] The following describes in detail the specific implementation method of clustering multiple accounts based on the permission graph corresponding to each of the multiple accounts in step [2]. Specifically, this can be achieved through the following steps (a1) and (a2):

[0081] Step (a1): Determine the similarity between every two accounts in the plurality of accounts based on the permission graphs corresponding to the plurality of accounts.

[0082] As shown in Figure 3, after obtaining the permission graphs corresponding to multiple accounts, the data processing module in the electronic device can be used to calculate the similarity between the permission graphs and perform permission clustering. Specifically, for each of the multiple accounts, a feature vector of the permission graph corresponding to that account can be determined. Then, for every two accounts in the multiple accounts, the similarity between the feature vectors of the permission graphs corresponding to the two accounts can be determined, which serves as the similarity between the two accounts.

[0083] For example, the similarity between the feature vectors of the permission graphs corresponding to two accounts can be measured based on cosine distance, Euclidean distance, etc.

[0084] Step (a2): Cluster multiple accounts based on all similarities.

[0085] In the present disclosure, a corresponding clustering algorithm may be used to cluster multiple accounts according to the characteristics and requirements of the permission data.

[0086] For example, if the business system is Kubernetes, to accurately reflect the structure and characteristics of Kubernetes RBAC permission data, a density-based spatial clustering algorithm (DBSCAN) can be used to cluster multiple accounts. As shown in Figure 3, when using DBSCAN for clustering, the clustering parameters can be dynamically tuned using methods such as the silhouette coefficient and the Davidson-Boulding index to evaluate clustering effectiveness and accuracy.

[0087] The following describes in detail the specific implementation methods for determining the feature vector of the permission graph corresponding to the account. Specifically, this can be achieved through various implementation methods. In one implementation, the feature vector of the permission graph corresponding to the account can be generated based on the connection relationship between the nodes in the permission graph corresponding to the account and the attribute information of each node.

[0088] In another embodiment, a pre-trained feature extraction model can be used to generate feature vectors for the permissions graph corresponding to each account. Specifically, for each account, the permissions graph of that account can be input into the feature extraction model to obtain the feature vector for the permissions graph corresponding to that account. This allows the feature extraction model to quickly and conveniently obtain the feature vector for the permissions graph corresponding to that account.

[0089] In one embodiment, the feature extraction model may be a deep learning-based autoencoder, which processes the K8s permission information to generate a feature vector that effectively represents the permission data.

[0090] The following describes in detail the specific implementation method for generating permission configuration information for at least one account category of the business system based on the clustering results of multiple accounts in S103. As shown in Figure 3, after obtaining the clustering results, the clustering results can be further processed to model the permission configuration information. Specifically, for each account category, the permission data of each account in the account category can be merged to obtain the permission configuration information for that account category.

[0091] For example, as shown in Figure 5, multiple accounts are aggregated to obtain two account categories (i.e., permission class 1 and permission class 2). Permission class 1 includes two accounts, ServiceAccount1 and ServiceAccount2 (two account names), and permission class 2 also includes two accounts, ServiceAccount3 and ServiceAccount4. After merging (i.e., merging) the permission data of ServiceAccount1 in permission class 1 with the data of ServiceAccount2, the permission merging result shown in the lower right corner of Figure 5 can be obtained, thereby obtaining the permission configuration information of permission class 1 (i.e., the permission configuration information of ServiceAccountX in Figure 5). After merging (i.e., merging) the permission data of ServiceAccount3 in permission class 2 with the data of ServiceAccount4, the permission merging result shown in the upper left corner of Figure 4 can be obtained, thereby obtaining the permission configuration information of permission class 2 (i.e., the permission configuration information of ServiceAccountY in Figure 5).

[0092] As another example, the permission data of cluster 1 is specifically the ApiGroups and its downstream nodes shown in Figure 2, which are respectively connected to each account in cluster 1 (including Account1, Account2, and Account3); the permission data of cluster 2 is specifically the ApiGroups and its downstream nodes shown in Figure 2, which are respectively connected to each account in cluster 2 (including Account4, Service Account1, and Service Account2).

[0093] In order to quickly obtain the account's authority information, as shown in Figure 3, a corresponding authority file can be pre-generated for each account as the optimal authority that the account should use, thereby converging the risks of existing accounts. Specifically, the above method can also include the following steps:

[0094] For each account, determine the target type of the permission file corresponding to the account based on the namespace access status of the account;

[0095] Generate a permission file corresponding to the account based on the permission configuration information of the account category to which the account belongs and the target type.

[0096] In the present disclosure, if the permission graph corresponding to the account includes multiple namespaces, it indicates that the account has cluster-level namespace access rights. At this time, it can be determined that the target type of the permission file corresponding to the account is cluster role (ClusterRole); if the permission graph corresponding to the account includes one namespace, it indicates that the account has single namespace access rights. At this time, it can be determined that the target type of the permission file corresponding to the account is role (Role).

[0097] For example, as shown in FIG2 , a ClusterRoleA permission file is generated for Account1 and Account2; a ClusterRoleB permission file is generated for Account3 and Account4; and a Role permission file is generated for Service Account1 and Service Account2.

[0098] In addition, in order to simplify the permission management process and improve the security and efficiency of the system, based on the optimization of account permissions, permission configuration templates can be pre-generated according to the current status of the cluster. New accounts can create permission resources based on the templates, thereby simplifying the permission configuration process for new accounts. Specifically, the above method can also include the following steps:

[0099] For each of the plurality of preset permissions, screening a plurality of target accounts having the preset permission from the plurality of accounts based on the permission data of the plurality of accounts;

[0100] Cluster multiple target accounts based on their permission data;

[0101] The permission data of each target account in the target account category are merged to obtain a permission configuration template corresponding to the preset permission, wherein the target account category is the account category containing the most target accounts in the clustering result of multiple target accounts.

[0102] In the present disclosure, the plurality of preset permissions may be the plurality of permissions that are most frequently used in the business system. For example, the plurality of preset permissions include read permission, write permission, delete permission, and the like.

[0103] In addition, a similar method as the clustering of multiple accounts based on the permission data of multiple accounts in S102 above can be used to cluster multiple target accounts based on the permission data of multiple target accounts, which will not be described in detail in this disclosure. In order to ensure that more accounts have the preset permission, the clustering threshold used when clustering multiple target accounts is smaller than the clustering threshold used when clustering multiple accounts.

[0104] In addition, in order to simplify the permission configuration process for newly added accounts, as shown in Figure 3, newly added accounts can create permission resources based on pre-established permission configuration templates. Specifically, the above method can also include the following two steps:

[0105] In response to detecting a creation request for a new account, determining a target permission that matches the creation request from a plurality of preset permissions;

[0106] Generate a permission file for the newly added account based on the permission configuration template corresponding to the target permission.

[0107] In this disclosure, a creation request includes the permissions that the newly added account desires to access, and the target permission that matches the permission request is the permission that the newly added account desires to access. For example, if the multiple preset permissions include read permission, write permission, and delete permission, and the permission that the newly added account desires to access is write permission, then the target permission is write permission.

[0108] When generating a permission file for a newly added account, it is necessary to first determine the type of the permission file for the newly added account. The type can be specified by the user when the newly added account is created.

[0109] FIG6 is a block diagram of a rights management device according to an exemplary embodiment. As shown in FIG6 , the rights management device 200 includes:

[0110] An acquisition module 201 is configured to acquire permission data of multiple accounts in a business system;

[0111] A first clustering module 202 is configured to cluster the multiple accounts according to the permission data of the multiple accounts;

[0112] The first generating module 203 is configured to generate permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts.

[0113] In the above technical solution, after obtaining permission data for multiple accounts in a business system, the accounts are clustered based on this data. Based on the clustering results, permission configuration information for at least one account category in the business system is generated. This allows for a clear and concise description of the permission structure, enabling a better understanding of user and system permission requirements, and enabling more refined and secure permission control. Through this generated permission configuration information, system administrators can clearly understand the permission distribution of each account, allowing them to quickly identify and address redundant and excessive permissions, making permission management more refined. This not only brings great convenience to system administrators, but also significantly improves the security and efficiency of business systems.

[0114] Optionally, the first clustering module 202 includes:

[0115] A first generating submodule is configured to generate, for each of the plurality of accounts, a permission graph corresponding to the account according to the permission data of the account;

[0116] The first clustering submodule is configured to cluster the multiple accounts according to the permission graphs corresponding to the multiple accounts.

[0117] Optionally, the first clustering submodule includes:

[0118] a first determining submodule configured to determine a similarity between every two accounts in the plurality of accounts based on the permission graphs corresponding to the plurality of accounts;

[0119] The second clustering submodule is configured to cluster the multiple accounts according to all the similarities.

[0120] Optionally, the first determining submodule includes:

[0121] A second determining submodule is configured to determine, for each of the accounts, a feature vector of the permission graph corresponding to the account;

[0122] The third determining submodule is configured to determine, for each two accounts among the plurality of accounts, a similarity between the feature vectors of the permission graphs corresponding to the two accounts, as the similarity between the two accounts.

[0123] Optionally, the clustering result of the plurality of accounts includes at least one account category, wherein each account category includes at least one account;

[0124] The first generating module 203 is configured to merge the permission data of each account in each account category to obtain the permission configuration information of the account category.

[0125] Optionally, the acquisition module 201 includes:

[0126] an acquisition submodule configured to acquire target resource access records of multiple accounts in a business system from a first cache area, wherein log data of the business system is synchronously collected by multiple distributed clients, and the target resource access records of each account are extracted from the log data collected by each of the multiple distributed clients and stored in a local cache area, and the target resource access records in the local cache area are periodically synchronized to the first cache area;

[0127] The second generating submodule is configured to generate permission data of each account according to the target resource access record of the account.

[0128] Optionally, the log data is stored in a second cache area, and the multiple distributed clients collect the log data from the second cache area respectively.

[0129] Optionally, the distributed client extracts target resource access records of each account from the log data in the following manner:

[0130] Extracting original resource access records of each account from the log data;

[0131] For each of the original resource access records, perform structured processing on the original resource access record; perform standardization processing on the resource access record obtained after the structured processing;

[0132] Deduplication is performed on the resource access records obtained after the standardization process to obtain target resource access records of the multiple accounts.

[0133] Optionally, the apparatus 200 further includes:

[0134] a first determining module configured to determine, for each of the accounts, a target type of the permission file corresponding to the account based on the namespace access status of the account;

[0135] The second generating module is configured to generate a permission file corresponding to the account according to the permission configuration information of the account category to which the account belongs and the target type.

[0136] Optionally, the apparatus 200 further includes:

[0137] a screening module configured to screen, for each of the plurality of preset permissions, a plurality of target accounts having the preset permission from the plurality of accounts based on the permission data of the plurality of accounts;

[0138] a second clustering module, configured to cluster the multiple target accounts according to the permission data of the multiple target accounts;

[0139] The merging module is configured to merge the permission data corresponding to each target account in the target account category to obtain a permission configuration template corresponding to the preset permission, wherein the target account category is the account category that contains the most target accounts in the clustering result of the multiple target accounts.

[0140] Optionally, the apparatus 200 further includes:

[0141] a second determining module configured to, in response to detecting a creation request for a new account, determine a target permission that matches the creation request from the plurality of preset permissions;

[0142] The third generating module is configured to generate a permission file for the newly added account according to the permission configuration template corresponding to the target permission.

[0143] The present disclosure also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the above-mentioned rights management method provided by the present disclosure.

[0144] Reference is now made to FIG7 , which illustrates a schematic diagram of the structure of an electronic device (e.g., a terminal device or server) 600 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. The electronic device illustrated in FIG7 is merely an example and should not limit the functionality or scope of use of the embodiments of the present disclosure.

[0145] As shown in Figure 7, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0146] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 608 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although FIG. 7 shows the electronic device 600 with various devices, it should be understood that not all of the devices shown are required to be implemented or present. More or fewer devices may alternatively be implemented or present.

[0147] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0148] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0149] In some embodiments, the client and server can communicate using any currently known or later developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or later developed network.

[0150] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0151] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: obtains permission data of multiple accounts in the business system; clusters the multiple accounts based on the permission data of the multiple accounts; and generates permission configuration information for at least one account category of the business system based on the clustering results of the multiple accounts.

[0152] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including, but not limited to, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0153] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0154] The modules described in the embodiments of the present disclosure may be implemented in software or hardware. In some cases, the name of a module does not necessarily limit the module itself. For example, an acquisition module may also be described as a "module for acquiring permission data for multiple accounts in a business system."

[0155] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0156] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0157] According to one or more embodiments of the present disclosure, Example 1 provides a rights management method, including:

[0158] Obtain permission data for multiple accounts in the business system;

[0159] clustering the multiple accounts according to the permission data of the multiple accounts;

[0160] According to the clustering result of the multiple accounts, permission configuration information for at least one account category of the business system is generated.

[0161] According to one or more embodiments of the present disclosure, Example 2 provides the method of Example 1, wherein clustering the multiple accounts based on the permission data of the multiple accounts includes:

[0162] For each of the plurality of accounts, generating a permission map corresponding to the account based on the permission data of the account;

[0163] The multiple accounts are clustered according to the permission graphs corresponding to the multiple accounts.

[0164] According to one or more embodiments of the present disclosure, Example 3 provides the method of Example 2, wherein clustering the multiple accounts according to the permission graphs corresponding to the multiple accounts includes:

[0165] determining, based on the permission graphs corresponding to the plurality of accounts, a similarity between every two accounts in the plurality of accounts;

[0166] The multiple accounts are clustered according to all the similarities.

[0167] According to one or more embodiments of the present disclosure, Example 4 provides the method of Example 3, wherein determining the similarity between each two accounts in the plurality of accounts based on the permission graphs corresponding to the plurality of accounts includes:

[0168] For each of the accounts, determining a feature vector of the permission graph corresponding to the account;

[0169] For every two accounts among the multiple accounts, a similarity between the feature vectors of the permission graphs corresponding to the two accounts is determined as the similarity between the two accounts.

[0170] According to one or more embodiments of the present disclosure, Example 5 provides the method of Example 1, wherein the clustering result of the plurality of accounts includes at least one account category, wherein each account category includes at least one account;

[0171] Generating permission configuration information for at least one account category of the business system based on the clustering result of the multiple accounts includes:

[0172] For each of the account categories, the authority data of the accounts in the account category are merged to obtain the authority configuration information of the account category.

[0173] According to one or more embodiments of the present disclosure, Example 6 provides the method of Example 1, wherein obtaining permission data of multiple accounts in a business system includes:

[0174] Obtaining target resource access records of multiple accounts in a business system from a first cache area, wherein log data of the business system is synchronously collected by multiple distributed clients, and the target resource access records of each account are extracted from the collected log data by the multiple distributed clients and stored in a local cache area, and the target resource access records in the local cache area are periodically synchronized to the first cache area;

[0175] For each of the accounts, permission data of the account is generated according to the target resource access record of the account.

[0176] According to one or more embodiments of the present disclosure, Example 7 provides the method of Example 6, wherein the log data is stored in a second cache area, and the multiple distributed clients respectively collect the log data from the second cache area.

[0177] According to one or more embodiments of the present disclosure, Example 8 provides the method of Example 6, wherein the distributed client extracts target resource access records of each account from the log data in the following manner:

[0178] Extracting original resource access records of each account from the log data;

[0179] For each of the original resource access records, perform structured processing on the original resource access record; perform standardization processing on the resource access record obtained after the structured processing;

[0180] Deduplication is performed on the resource access records obtained after the standardization process to obtain target resource access records of the multiple accounts.

[0181] According to one or more embodiments of the present disclosure, Example 9 provides the method of any one of Examples 1-8, further comprising:

[0182] For each of the accounts, determining a target type of the permission file corresponding to the account based on the namespace access status of the account;

[0183] Generate a permission file corresponding to the account based on the permission configuration information of the account category to which the account belongs and the target type.

[0184] According to one or more embodiments of the present disclosure, Example 10 provides the method of any one of Examples 1-8, further comprising:

[0185] For each of the plurality of preset permissions, screening a plurality of target accounts having the preset permission from the plurality of accounts according to the permission data of the plurality of accounts;

[0186] clustering the multiple target accounts according to the permission data of the multiple target accounts;

[0187] The permission data of each target account in the target account category are merged to obtain a permission configuration template corresponding to the preset permission, wherein the target account category is the account category that contains the most target accounts in the clustering result of the multiple target accounts.

[0188] According to one or more embodiments of the present disclosure, Example 11 provides the method of Example 10, further comprising:

[0189] In response to detecting a creation request for a new account, determining a target permission that matches the creation request from the plurality of preset permissions;

[0190] Generate a permission file for the newly added account based on the permission configuration template corresponding to the target permission.

[0191] According to one or more embodiments of the present disclosure, Example 12 provides a rights management device, including:

[0192] The acquisition module is configured to obtain permission data of multiple accounts in the business system;

[0193] a first clustering module configured to cluster the multiple accounts according to the permission data of the multiple accounts;

[0194] The first generating module is configured to generate permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts.

[0195] According to one or more embodiments of the present disclosure, Example 13 provides a non-transitory computer-readable storage medium having a computer program stored thereon, which implements the steps of any one of the methods described in Examples 1-11 when executed by a processing device.

[0196] According to one or more embodiments of the present disclosure, Example 14 provides an electronic device, including:

[0197] a storage device having a computer program stored thereon;

[0198] A processing device is used to execute the computer program in the storage device to implement the steps of the method described in any one of Examples 1-11.

[0199] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0200] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details have been included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0201] Although the subject matter has been described using language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims. Regarding the apparatus in the above-described embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method and will not be elaborated upon here.

Claims

1. A rights management method, comprising: Obtain permission data for multiple accounts in the business system; Clustering the multiple accounts according to the permission data of the multiple accounts; According to the clustering result of the multiple accounts, permission configuration information for at least one account category of the business system is generated.

2. The method according to claim 1, wherein: The clustering of the multiple accounts according to the permission data of the multiple accounts includes: For each of the multiple accounts, generating a permission graph corresponding to the account according to the permission data of the account; The multiple accounts are clustered according to the permission graphs corresponding to the multiple accounts respectively.

3. The method according to claim 2, wherein: The clustering of the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively includes: Determining the similarity between every two accounts in the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively; The multiple accounts are clustered according to all the similarities.

4. The method according to claim 3, wherein: The determining, according to the permission graphs corresponding to the multiple accounts, the similarity between every two accounts in the multiple accounts comprises: For each of the accounts, determining a feature vector of the permission graph corresponding to the account; For every two accounts among the multiple accounts, similarity between feature vectors of the permission graphs corresponding to the two accounts is determined as the similarity between the two accounts.

5. The method according to claim 1, wherein: The clustering result of the plurality of accounts includes at least one account category, wherein each of the account categories includes at least one of the accounts; Generating permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts includes: For each of the account categories, the authority data of the accounts in the account category are merged to obtain the authority configuration information of the account category.

6. The method according to claim 1, wherein: The obtaining of permission data of multiple accounts in the business system includes: Obtaining target resource access records of multiple accounts in the business system from the first cache area, wherein log data of the business system is synchronously collected by multiple distributed clients, and target resource access records of each account are extracted from the log data collected by the multiple distributed clients respectively and stored in the local cache area, and the target resource access records in the local cache area are periodically synchronized to the first cache area; For each of the accounts, permission data of the account is generated according to the target resource access record of the account.

7. The method according to claim 6, wherein: The log data is stored in a second cache area, and the multiple distributed clients collect the log data from the second cache area respectively.

8. The method according to claim 6, wherein: The distributed client extracts the target resource access record of each account from the log data in the following manner: Extracting original resource access records of each account from the log data; For each of the original resource access records, performing structured processing on the original resource access record; Standardize the resource access records obtained after structured processing; Deduplication processing is performed on the resource access records obtained after each standardization processing to obtain target resource access records of the multiple accounts.

9. The method according to any one of claims 1 to 8, further comprising: For each of the accounts, according to the namespace access status of the account, determine the target type of the permission file corresponding to the account; A permission file corresponding to the account is generated according to the permission configuration information of the account category to which the account belongs and the target type.

10. The method according to any one of claims 1 to 8, further comprising: For each of the plurality of preset permissions, screening a plurality of target accounts having the preset permission from the plurality of accounts according to the permission data of the plurality of accounts; clustering the multiple target accounts according to the permission data of the multiple target accounts; The permission data of each target account in the target account category are combined to obtain a permission configuration template corresponding to the preset permission, wherein the target account category is the account category that contains the most target accounts in the clustering result of the multiple target accounts.

11. The method according to claim 10, further comprising: In response to detecting a creation request for a new account, determining a target permission that matches the creation request from the plurality of preset permissions; Generate a permission file for the newly added account according to the permission configuration template corresponding to the target permission.

12. A rights management device, characterized in that: include: An acquisition module, configured to obtain permission data of multiple accounts in the business system; a first clustering module, configured to cluster the multiple accounts according to the permission data of the multiple accounts; The first generating module is configured to generate permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts.

13. A non-transitory computer-readable storage medium having a computer program stored thereon, wherein: When the program is executed by a processing device, the steps of the method described in any one of claims 1 to 11 are implemented.

14. An electronic device, comprising: a storage device having a computer program stored thereon; A processing device, configured to execute the computer program in the storage device to implement the steps of the method according to any one of claims 1 to 11.

Images