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

Abstract

The present disclosure relates to a permission management method, device, readable storage medium and electronic device. The method includes: obtaining permission data of multiple accounts; clustering multiple accounts according to the permission data of multiple accounts; generating permission configuration information of at least one account category according to the clustering results of multiple accounts, so as to clearly and concisely describe the permission structure, better understand the permission requirements of users and systems, and thus achieve more refined and safer permission control. Through the generated permission configuration information, the system administrator can clearly see the permission distribution of each account, so as to quickly discover and handle redundant and excessive permissions, making permission management more refined, which not only brings great convenience to the system administrator, but also greatly improves the security and efficiency of the business system.

Description

Technical Field

[0001] The present disclosure relates to the technical field of permission data management, and in particular, to a permission management method, device, readable storage medium and electronic device. Background Art

[0002] Permission management generally refers to the management of different users' access capabilities or access rules to predetermined resources based on the security rules or security policies set by the business system. Generally speaking, users can access and can only access the resources they are authorized to in a specific way (such as reading, writing, deleting, etc.). In addition, permission management is an important issue faced by business system developers. Any multi-user business system inevitably involves the issue of permission management. The more users there are in the business system, the more complex the attributes or division of labor of the users themselves, and the more complex the permission management issue. Permission management technology is showing a trend of multi-level and multi-dimensional development. Therefore, how to effectively manage the permissions of the business system is crucial to ensuring the security of the business system. Summary of the invention

[0003] This summary is provided to introduce concepts in a brief form 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.

[0004] In a first aspect, the present disclosure provides a rights management method, comprising:

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

[0006] Clustering the multiple accounts according to the permission data of the multiple accounts;

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

[0008] In a second aspect, the present disclosure provides a rights management device, comprising:

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

[0010] A first clustering module, configured to cluster the multiple accounts according to the permission data of the multiple accounts;

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

[0012] In a third aspect, 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 permission management method provided in the first aspect of the present disclosure.

[0013] In a fourth aspect, the present disclosure provides an electronic device, including:

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

[0015] A processing device is used to execute the computer program in the storage device to implement the steps of the permission management method provided in the first aspect of the present disclosure.

[0016] In the above technical solution, after obtaining the permission data of multiple accounts in the business system, the multiple accounts are clustered according to them, and according to the clustering results of the multiple accounts, permission configuration information for at least one account category of the business system is generated, so that the permission structure can be described clearly and concisely, and the permission requirements of users and systems can be better understood, thereby achieving more refined and safer permission control. Through the generated permission configuration information, the system administrator can clearly know the permission distribution of each account, so as to quickly discover and handle redundant and excessive permissions, making permission management more refined, which not only brings great convenience to the system administrator, but also greatly improves the security and efficiency of the business system.

[0017] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale. In the drawings:

[0019] Figure 1 The present invention is a flowchart of a method for rights management according to an exemplary embodiment.

[0020] Figure 2 It is a schematic diagram of a simplified permission graph according to an exemplary embodiment.

[0021] Figure 3 The figure is a schematic diagram of an architecture of permission processing according to an exemplary embodiment.

[0022] Figure 4 The invention is a schematic diagram of an architecture of data collection and processing according to an exemplary embodiment.

[0023] Figure 5The figure is a schematic diagram showing a rights merging according to an exemplary embodiment.

[0024] Figure 6 The figure is a block diagram of a rights management device according to an exemplary embodiment.

[0025] Figure 7 The diagram is a schematic structural diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

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

[0027] 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 worrying about the underlying infrastructure. Kubernetes provides a declarative configuration method that allows users to define the desired state of the application, and the system automatically ensures that the application reaches and remains in this state.

[0028] 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 permission 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 the Kubernetes cluster in a very fine-grained manner, thereby protecting the cluster's security and ensuring compliance.

[0029] Kubernetes log analysis is an important function in the Kubernetes system, which 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 function works by defining log analysis policies. Administrators can configure log analysis policies as needed to determine which types of requests should be logged and how much detail should be recorded. In this way, administrators can customize the log analysis configuration according to their security needs.

[0030] Permission modeling is a method of creating and optimizing permission configurations by analyzing the behavior and permission requirements of users or roles in the system. This method is particularly suitable for complex systems and environments with a large number of users and different levels of permission settings. Through permission modeling, you can better understand the permission requirements of users and systems, thereby achieving more refined and secure permission control.

[0031] Embodiments of the present disclosure will be described in more detail below 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 being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0032] 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.

[0033] The term "including" and its variations used herein are open inclusions, 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"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0034] It should be noted that the concepts such as "first" and "second" mentioned in the present 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.

[0035] It should be noted that the modifications of "one" and "plurality" 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, it should be understood as "one or more".

[0036] 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.

[0037] 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.

[0038] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the information involved in the present disclosure should be informed to relevant users and their authorization should be obtained 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.

[0039] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0040] As an optional but non-limiting implementation, in response to receiving an active request from the user, 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. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0041] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0042] 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) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0043] Figure 1 FIG. 1 is a flowchart of a method for managing rights according to an exemplary embodiment. As shown in the figure, the method for managing rights may include S101 to S103.

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

[0045] In the present disclosure, an account is an existing account in a business system, and 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 above-mentioned K8s system, the above-mentioned permission management method is a permission management mechanism based on RBAC, and the system may include multiple K8s clusters.

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

[0047] In S102, the multiple accounts are clustered according to the permission data of the multiple accounts.

[0048] In S103, authority configuration information for at least one account category of the business system is generated according to the clustering result of the multiple accounts.

[0049] In the present disclosure, the clustering result of multiple accounts may include at least one account category, wherein each account category includes at least one account. Among them, multiple accounts may belong to the same account category, in which case the clustering result of multiple accounts includes one account category, and multiple accounts may belong to different account categories, in which case the clustering result of multiple accounts includes multiple account categories.

[0050] When clustering multiple accounts, accounts with highly similar access rights can be grouped into one account category. Figure 2 As shown in the figure, it shows the complex permission relationships between different roles, accounts, service accounts in the K8s cluster and their clusters, API groups, resources, and operations. The figure simplifies the complex permission relationships. After clustering multiple accounts, we found that the access permissions of Account1, Account2, and Account3 are highly similar, so we divide them into one account category, namely Cluster 1. At the same time, cluster other accounts in a similar way to obtain clustering results. Figure 2As shown in the figure, by clustering Account1, Account2, Account3, Account4, Service Account1 and Service Account2, we can get two account categories, namely Cluster 1 and Cluster 2. Among them, Account1, Account2 and Account3 belong to Cluster 1, and Account4, Service Account1 and Service Account2 belong to Cluster 2.

[0051] In the above technical solution, after obtaining the permission data of multiple accounts in the business system, the multiple accounts are clustered according to them, and according to the clustering results of the multiple accounts, permission configuration information for at least one account category of the business system is generated, so that the permission structure can be described clearly and concisely, and the permission requirements of users and systems can be better understood, thereby achieving more refined and safer permission control. Through the generated permission configuration information, the system administrator can clearly know the permission distribution of each account, so as to quickly discover and handle redundant and excessive permissions, making permission management more refined, which not only brings great convenience to the system administrator, but also greatly improves the security and efficiency of the business system.

[0052] 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, 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 caching 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 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 specific cache levels 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 permission data of multiple accounts in the business system can be obtained through the following steps (1) and (2):

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

[0054] In the present disclosure, the above permission processing method can be applied to electronic devices, such as Figure 3 and Figure 4 As shown, 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. Figure 4Specifically, the log data of the business system can be collected synchronously through multiple distributed clients, and the target resource access records of each account can be extracted from the collected log data through multiple distributed clients and stored in the local cache area (i.e. Figure 3 and Figure 4 The target resource access records in the local cache area are periodically synchronized to the first cache area (i.e. Figure 3 and Figure 4 The local cache areas and the first cache area constitute a multi-level cache.

[0055] Distributed clients are used to collect log data. Each distributed client is responsible for collecting corresponding log data, so as to process a large amount of data in parallel, improve the efficiency of data collection and processing, and ensure that log data can be efficiently collected and processed in a multi-cluster environment. It can not only quickly process a large amount of log data, but also ensure the accuracy of the recorded permission access information. This provides a solid foundation for subsequent data analysis and permission management.

[0056] Step (2): For each account, generate the permission data of the account according to the target resource access record of the account.

[0057] 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. At this time, the resource access information involved in multiple target resource access records can be integrated to obtain the permission data of the account.

[0058] like Figure 3 and Figure 4As shown, 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.

[0059] The above synchronization mechanism may include data synchronization and state 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.

[0060] In order to avoid the problem that the distributed log collection system cannot process the sudden increase of system log data in time, a second buffer area can be set up to store the log data of the above business system, that is, the log data is stored in the second buffer area, so that multiple distributed clients 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.

[0061] In addition, the distributed client extracts the target resource access records of each account (i.e. Figure 3 and Figure 4 Data preprocessing in ):

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

[0063] 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 namespace accessed (Namespace), the API group accessed (APIGroup), the resource accessed (Resource), the operation on the resource (Verb), etc., which constitute an unstructured data.

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

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

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

[0067] In different original resource access records, the same attribute may be represented by different forms or parameters. In order to facilitate subsequent permission analysis and management, the resource access records obtained after structured processing can be standardized. Standardization refers to standardizing various attributes of permission entities (i.e. accounts) and relationships (such as permission levels, resource types, operation types, etc.) to ensure data consistency.

[0068] Step (14): De-duplicate the resource access records obtained after each standardization process to obtain target resource access records of multiple accounts.

[0069] 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 have duplicate records. Therefore, the resource access records obtained after each standardization process may be deduplicated.

[0070] In addition to collecting and processing log data with the help of distributed log collection, the above-mentioned electronic device can also collect and process log data locally. Specifically, in another embodiment, the above-mentioned electronic device can directly collect log data of the business system, and then extract the target resource access records of each account from the collected log data; finally, for each account, according to the target resource access records of the account, generate the permission data of the account. Among them, the electronic device can extract the target resource access records of each account from the collected log data in a similar way to the above-mentioned distributed client extracting the target resource access records of each account from the log data, and this disclosure will not go into details.

[0071] In order to meet the needs of more data sources, when obtaining original resource access records, the data sources include log data, such as Figure 3 As shown, offline data may also be included, that is, the original resource access records of each account are extracted from both offline data and log data.

[0072] The following is a detailed description of the specific implementation of clustering multiple accounts according to the permission data of multiple accounts in the above S102. Specifically, it can be achieved through the following steps [1] and [2].

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

[0074] 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 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 an 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 an 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 resource, then there is an edge relationship between the resource node accessible to the account and the operation node on the resource.

[0075] Step [2]: Clustering the multiple accounts according to the permission graphs corresponding to the multiple accounts.

[0076] After obtaining the permission data of multiple accounts in the business system, for each account, a permission graph corresponding to the 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.

[0077] 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].

[0078] In one implementation, the account name, namespace, API group, resource, operation, etc. in the permission data of the account can be used as nodes; then, according to the account's permissions for the namespace, API group, resource, and operation, an edge relationship between the nodes is constructed. Specifically, if an account has access to a namespace, an edge relationship is established between the account's account name node and the namespace node; if an account has access to an 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 of 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 where it operates on the resource.

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

[0080] like Figure 4 As shown, after the permission graph is generated, its data can be stored, such as Figure 3 As shown, the permission graph of each account can be stored in a graph database, so that the permission graph corresponding to the specified account can be visualized using a visualization tool in the future.

[0081] The following is a detailed description of the specific implementation method of clustering multiple accounts according to the permission graphs corresponding to the multiple accounts in the above step [2]. Specifically, it can be achieved through the following steps (a1) and (a2):

[0082] Step (a1): Determine the similarity between every two accounts in the multiple accounts according to the permission graphs corresponding to the multiple accounts.

[0083] like Figure 3 As shown, after obtaining the permission graphs corresponding to the 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, the feature vector of the permission graph corresponding to the 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 as the similarity between the two accounts.

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

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

[0086] 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.

[0087] For example, the business system is K8s. In order to ensure that the structure and characteristics of K8s RBAC permission data can be accurately reflected, a density-based clustering algorithm (Density-Based Spatial Clustering of Applications with Noise, DBSCAN) can be used to cluster multiple accounts. Figure 3 As shown in FIG, when DBSCAN is used for clustering, the clustering parameters of DBSCAN can be dynamically tuned by means of silhouette coefficient, Davidson-Boulding index, etc. to evaluate the clustering effect and accuracy.

[0088] The following is a detailed description of the specific implementation method for determining the feature vector of the permission graph corresponding to the account. Specifically, it can be implemented through a variety of implementation methods. In one implementation method, 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.

[0089] In another implementation, a pre-trained feature extraction model can be used to generate a feature vector of the permission graph corresponding to each account. Specifically, for each account, the permission graph of the account can be input into the feature extraction model to obtain the feature vector of the permission graph corresponding to the account. In this way, the feature vector of the permission graph corresponding to the account can be quickly obtained through the feature extraction model, which is convenient and fast.

[0090] In one embodiment, the feature extraction model may be an autoencoder based on deep learning. The autoencoder is used to process the permission information of K8s to generate a feature vector, which can effectively represent the permission data.

[0091] The following is a detailed description of the specific implementation of generating permission configuration information for at least one account category of the business system based on the clustering results of multiple accounts in S103 above. Figure 3 As shown, 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 of the account category.

[0092] For example, Figure 5As shown in the figure, multiple accounts are aggregated to obtain two account categories (i.e., permission category 1 and permission category 2). Among them, permission category 1 includes two accounts, namely, ServiceAccount1 and ServiceAccount2 (two account names), and permission category 2 also includes two accounts, namely, ServiceAccount3 and ServiceAccount4; after the permission data of ServiceAccount1 in permission category 1 and the data of ServiceAccount2 are merged (i.e., combined), the following can be obtained: Figure 5 The permission merging result shown in the lower right corner is used to obtain the permission configuration information of permission class 1 (i.e. Figure 5 After merging the permission data of ServiceAccount3 and ServiceAccount4 in permission class 2, we can get the following: Figure 4 The permission merging result shown in the upper left corner, thus obtaining the permission configuration information of permission class 2 (i.e. Figure 5 Permission configuration information of ServiceAccountY in ).

[0093] As another example, the permission data of cluster 1 is specifically Figure 2 The ApiGroups and their downstream nodes connected to each account in cluster 1 (including Account1, Account2, and Account3) are shown in the figure. The permission data of cluster 2 is as follows: Figure 2 The ApiGroups and their downstream nodes shown in , which are respectively connected to each account in cluster 2 (including Account4, Service Account1, and ServiceAccount2).

[0094] In order to quickly obtain the account's permission information, such as Figure 3 As shown, a corresponding permission file can be pre-generated for each account as the optimal permission that the account should use, so that the risks of existing accounts can be converged.

[0095] Specifically, the above method may further include the following steps:

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

[0097] 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.

[0098] 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 a single namespace access right. At this time, it can be determined that the target type of the permission file corresponding to the account is role (Role).

[0099] For example, Figure 2 As shown in the figure, for Account1 and Account2, a ClusterRoleA permission file is generated; for Account3 and Account4, a ClusterRoleB permission file is generated; for Service Account1 and ServiceAccount2, a Role permission file is generated.

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

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

[0102] Cluster multiple target accounts according to their permission data;

[0103] 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.

[0104] 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 may include a read permission, a write permission, a delete permission, and the like.

[0105] In addition, a method similar to clustering multiple accounts according to the permission data of multiple target accounts in the above S102 can be adopted to cluster multiple target accounts according to the permission data of multiple target accounts, which will not be repeated in this disclosure. In order to make it more likely that more accounts have the preset permission, when clustering multiple target accounts, the clustering threshold used is smaller than the clustering threshold used when clustering multiple accounts.

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

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

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

[0109] In the present disclosure, the creation request includes the permission that the newly added account expects to access, and the target permission that matches the permission request is the permission that the newly added account expects to access. For example, the multiple preset permissions include read permission, write permission, and delete permission, and the permission that the newly added account expects to access is write permission, then the target permission is write permission.

[0110] 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, wherein the type can be specified by the user when the newly added account is created.

[0111] Figure 6 FIG. 1 is a block diagram of a rights management device according to an exemplary embodiment. Figure 6 As shown, the rights management device 200 includes:

[0112] The acquisition module 201 is used to obtain the authority data of multiple accounts in the business system;

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

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

[0115] In the above technical solution, after obtaining the permission data of multiple accounts in the business system, the multiple accounts are clustered according to them, and according to the clustering results of the multiple accounts, permission configuration information for at least one account category of the business system is generated, so that the permission structure can be described clearly and concisely, and the permission requirements of users and systems can be better understood, thereby achieving more refined and safer permission control. Through the generated permission configuration information, the system administrator can clearly know the permission distribution of each account, so as to quickly discover and handle redundant and excessive permissions, making permission management more refined, which not only brings great convenience to the system administrator, but also greatly improves the security and efficiency of the business system.

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

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

[0118] The first clustering submodule is used to cluster the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively.

[0119] Optionally, the first clustering submodule includes:

[0120] A first determination submodule, configured to determine the similarity between every two accounts in the plurality of accounts according to the permission graphs corresponding to the plurality of accounts respectively;

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

[0122] Optionally, the first determining submodule includes:

[0123] A second determination submodule is used to determine, for each of the accounts, a feature vector of the permission graph corresponding to the account;

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

[0125] Optionally, the clustering result of the multiple accounts includes at least one account category, wherein each of the account categories includes at least one of the accounts;

[0126] The first generating module 203 is used for merging the authority data of each account in each account category to obtain the authority configuration information of the account category.

[0127] Optionally, the acquisition module 201 includes:

[0128] 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 target resource access records of each account are extracted from the log data collected by the multiple distributed clients respectively 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;

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

[0130] 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.

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

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

[0133] For each of the original resource access records, the original resource access record is structured; and the resource access record obtained after the structured processing is standardized;

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

[0135] Optionally, the device 200 further includes:

[0136] A first determination module is used to determine, for each of the accounts, a target type of the permission file corresponding to the account according to the namespace access status of the account;

[0137] The second generating module is used 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.

[0138] Optionally, the device 200 further includes:

[0139] A screening module, for screening, for each of the plurality of preset permissions, a plurality of target accounts having the preset permission from the plurality of accounts according to the permission data of the plurality of accounts;

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

[0141] A merging module is used 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 results of the multiple target accounts.

[0142] Optionally, the device 200 further includes:

[0143] A second determination module is 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;

[0144] The third generating module is used to generate the permission file of the newly added account according to the permission configuration template corresponding to the target permission.

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

[0146] Reference below Figure 7 , which shows a schematic diagram of the structure of an electronic device (such as a terminal device or a server) 600 suitable for implementing the embodiment of the present disclosure. The terminal device in the embodiment of the present disclosure may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0147] like Figure 7 As shown, 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. In the RAM 603, various programs and data required for the operation of the electronic device 600 are also stored. 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.

[0148] Typically, the following devices may be connected to the I / O interface 605: an input device 606 including, for example, a touch screen, a touch pad, 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 Figure 7 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0149] 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 contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 609, or installed from a storage device 608, or installed from a 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 executed.

[0150] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, 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 containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit 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 of the above.

[0151] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may 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 future developed network.

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

[0153] 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 according to the permission data of the multiple accounts; and generates permission configuration information for at least one account category of the business system according to the clustering results of the multiple accounts.

[0154] 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 separate software package, partially on the user's computer and partially on a remote computer, or entirely on a 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., via the Internet using an Internet service provider).

[0155] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

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

[0157] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, 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 chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0158] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may 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 may 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.

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

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

[0161] Clustering the multiple accounts according to the permission data of the multiple accounts;

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

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

[0164] For each of the multiple accounts, generating a permission graph corresponding to the account according to the permission data of the account;

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

[0166] 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 respectively includes:

[0167] Determining the similarity between every two accounts in the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively;

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

[0169] According to one or more embodiments of the present disclosure, Example 4 provides the method of Example 3, wherein determining the similarity between every two accounts in the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively includes:

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

[0171] 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.

[0172] 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 of the account categories includes at least one of the accounts;

[0173] Generating permission configuration information for at least one account category of the business system according to the clustering result of the multiple accounts includes:

[0174] 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.

[0175] 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:

[0176] 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;

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

[0178] 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 collect the log data from the second cache area respectively.

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

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

[0181] For each of the original resource access records, the original resource access record is structured; and the resource access record obtained after the structured processing is standardized;

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

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

[0184] 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;

[0185] 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.

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

[0187] 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;

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

[0189] 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 the multiple target accounts.

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

[0191] 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;

[0192] Generate a permission file for the newly added account according to the permission configuration template corresponding to the target permission.

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

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

[0195] A first clustering module, configured to cluster the multiple accounts according to the permission data of the multiple accounts;

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

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

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

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

[0200] 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.

[0201] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. 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 a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0202] 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 are 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.

[0203] Although the subject matter has been described in language specific to structural features and / or method logic actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims. Regarding the device in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims

1. A rights management method, characterized in that: include: Obtain permission data for multiple accounts in the business system; For each of the multiple accounts, generating a permission graph corresponding to the account according to the permission data of the account; Clustering the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively; Generating permission configuration information for at least one account category of the business system according to the clustering results of the multiple accounts, wherein the clustering results of the multiple accounts include at least one account category, and each account category includes at least one account; Wherein, obtaining the permission data of multiple accounts in the business system includes: Obtaining target resource access records of multiple accounts in the business system from a first cache area, wherein log data of the business system is synchronously collected through multiple distributed clients, and 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, and the first cache area is set on a device other than the distributed client; For each of the accounts, permission data of the account is generated according to the target resource access record of the account.

2. The method according to claim 1, characterized in that 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.

3. The method according to claim 2, characterized in that 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.

4. The method according to claim 1, characterized in that: 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.

5. The method according to claim 1, characterized in that 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.

6. The method according to claim 1, characterized in that 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.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: 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.

8. The method according to any one of claims 1 to 6, characterized in that The method further comprises: 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.

9. The method according to claim 8, characterized in that The method further comprises: 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.

10. A rights management device, characterized in that: include: The acquisition module is used to obtain the 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; A first generating module, 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, wherein the clustering result of the multiple accounts includes at least one account category, and each account category includes at least one account; Wherein, the first clustering module includes: A first generating submodule, configured to generate, for each of the multiple accounts, a permission graph corresponding to the account according to the permission data of the account; A first clustering submodule, configured to cluster the multiple accounts according to the permission graphs corresponding to the multiple accounts respectively; The acquisition module comprises: 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 through multiple distributed clients, and target resource access records of each account are respectively extracted from the log data collected 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, and the first cache area is set on other devices other than the distributed clients; The second generating submodule is used to generate permission data of each account according to the target resource access record of the account.

11. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processing device, the steps of the method described in any one of claims 1 to 9 are implemented.

12. An electronic device, characterized in that: include: 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 9.

Images