Three-member authority management method and system based on micro-service architecture

Abstract

The invention discloses a three-member authority management method and system based on a micro-service architecture. The system at least comprises a system management module, a security management module, an audit management module and a security agent module. Different from an existing method that a single application architecture and three-member authority management modules are concentrated in the same process, the modules constructed by the method are independent micro-services, and particularly, the micro-services of the modules in the system are managed and controlled more finely through the security agent module. And each management module in the three-member management module is split by adopting a micro-service architecture to serve as an independent micro-service, so that the management modules can be independently deployed and operated and mutually isolated, and the deployment flexibility, service stability, reliability and safety of the system are further improved.

Description

Technical Field

[0001] This application relates to the field of microservices technology, and particularly to a three - member permission management method and system based on a microservice architecture. Background Art

[0002] Currently, for the permission management of application systems, system management, security management, and audit management are implemented in the same module as the business modules. Once security vulnerabilities such as viruses occur, the entire permission management will be paralyzed, resulting in low reliability of permission management. Summary of the Invention

[0003] In view of this, this application provides a three - member permission management method and system based on a microservice architecture to solve the technical problem of low reliability of the existing permission management system in implementing permission management, as follows:

[0004] A three - member permission management system based on a microservice architecture includes at least:

[0005] A system management module, at least used for registering users and roles in an application system, where the application system is used to implement a target service;

[0006] A security management module, at least used for setting the permissions of the users on the target service, setting the permissions of the roles on the target service, and setting the access policy corresponding to the target service, where the access policy corresponding to the target service is used to control the users and the roles to access the target service according to their respective corresponding permissions;

[0007] An audit management module, at least used for auditing the module operation data of the system management module and the security management module;

[0008] A security proxy module, used to implement at least one security proxy service, and each security proxy service is at least used for monitoring a target service implemented by the application system;

[0009] Among them, the system management module, the security management module, the audit management module, and the security proxy module are all implemented as independent microservices, so that the system management module, the security management module, the audit management module, and the security proxy module operate independently.

[0010] For the above - mentioned system, preferably, the system management module, the security management module, and the audit management module are all implemented as independent microservices, including:

[0011] The system management module, the security management module, and the audit management module run on different at least one process respectively.

[0012] Preferably, the above system further includes:

[0013] A security proxy module, which is implemented as an independent microservice. The security proxy module is used to implement at least one security proxy service, and each security proxy service is used to monitor each target service implemented by the application system.

[0014] Preferably, the security proxy service is used to obtain the access policy corresponding to the target service, and control the user and the role to access the target service according to their respective corresponding permissions according to the access policy corresponding to the target service;

[0015] The security proxy service is further used to: obtain the service monitoring information corresponding to the target service, and transmit the service monitoring information to the audit management module, so that the audit management module can obtain at least the data corresponding to the service behavior of the target service.

[0016] Preferably, the audit management module is further used to send an audit alarm message to the security management module when the data corresponding to the service behavior of the target service satisfies the alarm condition;

[0017] Wherein, the audit alarm message at least indicates that there is an abnormality in the target service, so that the security management module can update the access policy corresponding to the target service.

[0018] Preferably, the above system further includes:

[0019] Multiple redundant modules, which respectively correspond to the system management module, the security management module, and the audit management module. The redundant module is used to execute the functions of its corresponding module when its corresponding module fails.

[0020] Preferably, the system management module, the security management module, and the audit management module are respectively encapsulated based on containers.

[0021] Preferably, the module operation data includes: the data corresponding to the user behavior of the target user logged in on the application system, and the data corresponding to the service behavior of the target service implemented by the application system.

[0022] A three - person permission management method based on a microservice architecture, which is applied to a permission management system based on a microservice architecture. The permission management system based on a microservice architecture at least includes a system management module, a security management module, an audit management module, and a security proxy module. The system management module, the security management module, the audit management module, and the security proxy module are all implemented as independent microservices, so that the system management module, the security management module, the audit management module, and the security proxy module operate independently of each other. The security proxy module implements at least one security proxy service, and each security proxy service corresponds to a target service implemented by the application system;

[0023] Among them, the method includes:

[0024] Receive an account login request for an application system. The account login request at least includes a login account, and the application system is used to implement a target service;

[0025] Judge whether the login account exists;

[0026] In the case where the login account does not exist, register the users and roles in the application system through the system management module;

[0027] Set the permissions of the user on the target service, set the permissions of the role on the target service, and set the access policy corresponding to the target service through the security management module; among them, the access policy corresponding to the target service is used to control the user and the role to access the target service according to their respective corresponding permissions;

[0028] Audit the module operation data of the system management module and the security management module through the audit management module;

[0029] Monitor the corresponding target service through each security proxy service.

[0030] An electronic device on which the three - person permission management system based on a microservice architecture described in any one of the above is built.

[0031] As can be seen from the above technical solutions, in a three - person permission management method and system based on a microservice architecture disclosed in this application, the system management module, the security management module, the security proxy module, and the audit management module in the system are all implemented as independent microservices, so that these modules operate independently and are isolated from each other, avoiding mutual interference. Even if a security vulnerability such as a virus appears in a certain module, it will not cause the entire system to crash, thereby improving the reliability of permission management.

[0032] Furthermore, in the present application, multiple modules in the three - person permission management system are implemented based on independent microservices, enabling flexible deployment and expansion, thereby improving the flexibility of deployment. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0034] Figure 1 Schematic diagram of the architecture of a three - person permission management system based on a microservice architecture provided in Embodiment 1 of the present application;

[0035] Figure 2 Flowchart of the system management module 101 in the present application for processing accounts or roles;

[0036] Figure 3 Design diagram of the division of role types in the system management module 101 in the present application;

[0037] Figure 4 Relational design diagram of the RBAC model based on the security administrator in the present application;

[0038] Figure 5 Schematic diagram of the main job responsibilities of the audit management module 103 in the present application;

[0039] Figure 6 Design diagram of the working principle of the security proxy module 102 in the present application;

[0040] Figure 7 Principle design diagram of the relationship of the three - person modules in the permission management in the present application;

[0041] Figure 8 Schematic diagram of the relationship between the three - person modules in the present application;

[0042] Figure 9 Corresponding relationship diagram between the services in the present application;

[0043] Figure 10 Schematic diagram of using the multi - replica (redundant module) mechanism to improve the stability of the three - person service in the present application;

[0044] Figure 11 Flowchart of a three - person permission management method based on a microservice architecture provided in Embodiment 2 of the present application;

[0045] Figure 12It is the architecture diagram of the overall system design in the embodiments of the present application;

[0046] Figure 13 It is the schematic diagram of the account management process in the embodiments of the present application;

[0047] Figure 14 It is the schematic diagram of the security service management process in the embodiments of the present application. Detailed implementation manners

[0048] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0049] Refer to Figure 1 As shown, it is the architecture schematic diagram of a three - staff permission management system based on a microservice architecture provided in Embodiment 1 of the present application. This system is used for permission management of application systems. The technical solutions in this embodiment are mainly used to improve the reliability of permission management.

[0050] Specifically, the system in this embodiment may include the following structures:

[0051] The system management module 101 is at least used to register users and roles in the application system, and the application system is used to implement the target service.

[0052] Among them, the system management module 101 can also be called the system administrator module.

[0053] For example, the system management module 101 is controlled by the permissions of the system administrator and is the main functional module for implementing basic service management. Users can enter the permission management system in this embodiment only after having the role of the system administrator and becoming the system administrator. Three functional modules need to be implemented in the system management module 101, such as: role registration, user registration, and basic service management and other functional modules.

[0054] Among them, the system administrator can complete the creation, modification, and deletion of system roles in this module according to the user situation, as well as fill in user information (such as user name, gender, contact information, etc.). To ensure the uniqueness of the identity identifier during the system life cycle, the system management module 101 conducts a uniqueness check on each newly registered identity identifier. For example, when the system administrator creates a user with the identifier NFS through the system management module 101, the system management module 101 queries all user names in the database to determine whether there is a user with the identity identifier NFS in the database users. If such a user exists, the user creation is unsuccessful. This judgment operation can be used to solve the problem of multiple accounts / passwords existing in the database. According to relevant security and confidentiality requirements, the system management module 101 also conducts a uniqueness check on the role name during the role registration process. In terms of basic service management, the system administrator conducts relevant configuration management on the target services implemented by the application system.

[0055] For example, as Figure 2 shown in the figure, on the system management module 101, after the system administrator logs in, a request to create an account (user) or a role is initiated. Then, the system management module 101 conducts a data query verification to determine whether the account or role uniquely exists. If so, the data is encrypted through an encryption algorithm and stored in the database.

[0056] The security management module 102 is at least used to set the permissions of users on the target service, set the permissions of roles on the target service, and set the access policy corresponding to the target service.

[0057] Among them, the access policy corresponding to the target service is used to control users and roles to access the target service according to their respective corresponding permissions. The security management module 102 can also be called the security administrator module.

[0058] For example, the security management module 102 is the main functional module for implementing the security administrator's permission control. Users can only enter the permission management system after having the security administrator role and becoming a security administrator. Functions such as user and role authorization, user auditing, and the formulation of security policies, that is, access policies, are completed in the security management module 102. To protect the security of classified information and important information within the system, a strict access control policy, that is, an access policy, is required for the system.

[0059] For example, the role-based access control policy RBAC (Role-Based Access control) can meet the relevant confidentiality permission design requirements. Its main idea is to add roles between users and permissions. By assigning several permissions to roles and several roles to users, users finally have several permissions among several roles to access the corresponding objects. Among them, the assignment relationships between roles and users, and between roles and permissions are both many-to-many relationships. AsFigure 3 As shown in the division design diagram of the role types, Role A and Role B are ordinary roles. Among the ordinary roles, there are three types of roles: system administrator, security administrator, and audit administrator. As Figure 4 As shown in the relationship design diagram of the RBAC model based on the security administrator, the security administrator is responsible for user role and permission management. A user can have Role A, Role B, and Role C, and each role corresponds to one or more permissions respectively. Role A corresponds to Permission Operation A and Permission Operation B, Role B corresponds to Permission Operation B and Permission Operation C, and Role C corresponds to Permission Operation A and Permission Operation C.

[0060] The audit management module 103 is at least used to audit the module operation data of the system management module 101 and the security management module 102. The audit management module 103 can also be called the audit administrator module.

[0061] Among them, only users with the audit administrator role can enter the audit management module 103. The audit management module 103 mainly completes the identification, recording, and analysis of relevant information related to security-related activities, that is, module operation data. The audit management module 103 mainly records user login information and data access information; the user login information should include login time, username, and source location; the data access information is used to determine the events that occurred and their sources and results; and the audit events are associated with the user unique identifier.

[0062] As Figure 5 As shown in the main job responsibilities of the audit management module, the overall framework of the audit management module 103 is for each service module (audit) data source. After the audit information is collected by the audit data collection module, the audit information is converted into a unified format through the formatting processing module and stored on the server. When storing the audit information, it is analyzed according to the audit policy library whether this audit information is abnormal. If there is an abnormality, the audit abnormal information is stored in the abnormal library to facilitate the audit of the audit information and improve the audit efficiency.

[0063] Among them, the module operation data audited by the audit management module 103 includes: the data corresponding to the user behavior of the target users logged in on the application system, and the data corresponding to the service behavior of the target services implemented by the application system. The target users here include both ordinary users and system administrators, security administrators, that is, confidentiality administrators. That is to say, the functions of the audit management module 103 are divided into two directions: the first category is auditing from user behavior, which is to supervise and audit the system user behavior; the second category is auditing from service behavior.

[0064] The security proxy module 104 is implemented as an independent microservice and is used to implement at least one security proxy service. Each security proxy service is used to monitor each target service implemented by the application system.

[0065] Among them, the security proxy service is used to obtain the access policy corresponding to the target service, and control users and roles to access the target service according to their respective corresponding permissions according to the access policy corresponding to the target service. In addition, the security proxy service is also used to: obtain the service monitoring information corresponding to the target service, and transmit the service monitoring information to the audit management module 103, so that the audit management module 103 can obtain at least the data corresponding to the service behavior of the target service.

[0066] Moreover, the audit management module 103 monitors and audits the service behaviors of the target services monitored by the security proxy module 104.

[0067] In addition, the system administrator uses the system management module 101 to perform relevant configuration management on the target services monitored by the security proxy module 104, which can make the functions of the security proxy module 104 normal and ensure the normal operation of the target services and the security proxy module 104.

[0068] Among them, the access policy set in the security management module 102, that is, the designation of the security policy in the previous text, can cooperate with the security proxy module 104 to formulate the security policy for relevant service management.

[0069] In addition, the audit management module 103 is also used to send an audit alarm message to the security management module 102 when the data corresponding to the service behavior of the target service audited meets the alarm condition.

[0070] Among them, the audit alarm message at least indicates that there is an abnormality in the target service, so that the security management module 102 updates the access policy corresponding to the target service. For example, the security administrator uses the security management module 102 to update the access policy corresponding to the target service.

[0071] Such as Figure 6 As shown in the working principle design diagram of the security proxy module, the security proxy module 104 is designed based on the three-person permission management system of this embodiment. The relevant functional services provided by the security proxy module 104 can be collectively referred to as security proxy services, such as Service A and Service B. The security proxy service mainly includes: reporting service monitoring data and executing security policies for microservice modules such as the system management module, the security management module, and the audit management module, playing the role of a monitoring proxy service and a policy execution proxy service. The security proxy module 104 mainly implements corresponding policies on the target service according to the relevant security policies formulated by the security administrator, and at the same time collects relevant monitoring information of the target service for service reporting. The audit administrator can judge whether the target service is running normally, whether it complies with relevant security policies, or whether there are dangerous behaviors, etc. based on the reported information. At the same time, the security administrator can update the security policy in real time according to the audit situation of the audit administrator.

[0072] Among them, the system management module 101, the security management module 102, the audit management module 103, and the security agent module 104 are all implemented as independent microservices, so that the system management module 101, the security management module 102, the audit management module 103, and the security agent module 104 can run independently of each other.

[0073] Specifically, the system management module 101, the security management module 102, the audit management module 103, and the security agent module 104 run on different at least one process respectively. For example, the system management module 101 runs on multiple processes a, the security management module 102 runs on multiple processes b, the audit management module 103 runs on one process c, and the security agent module 104 runs on one process d. In this way, the system management module 101, the security management module 102, the audit management module 103, and the security agent module 104 are isolated from each other and will not interfere with each other.

[0074] As can be seen from the above technical solution, in a three-officer permission management system based on a microservice architecture provided by the first embodiment of the present application, the system management module, the security management module, the security agent module, and the audit management module in the system are all implemented as independent microservices, so that these modules can run independently and be isolated from each other, avoiding mutual interference. Even if a security vulnerability such as a virus appears in a certain module, it will not cause the entire system to crash, thereby improving the reliability and security of permission management.

[0075] Furthermore, in the present application, implementing multiple modules in the three-officer permission management system as independent microservices can achieve flexible deployment and expansion, thereby improving the flexibility of deployment.

[0076] The following describes the relationship between the system management module 101, the security management module 102, the audit management module 103, and the security agent module 104:

[0077] As Figure 7 shown in the principle design diagram of the permission management relationship of the three-officer modules in, from the perspective of permission management. The relationship between the various modules in the "three-officer modules" in the microservice system is as follows:

[0078] (1) In the microservice system, the system administrator is mainly responsible for the creation and daily management of users / roles through the system management module.

[0079] (2) The security administrator is mainly responsible for permission management, role permission setting, account role binding setting, etc. through the security management module.

[0080] (3) The audit administrator is mainly responsible for auditing and supervising the behaviors of the system administrator, the security administrator, ordinary users, etc. through the audit management module.

[0081] like Figure 8 The relationship between the three modules in Figure 9 As shown in the corresponding relationship diagram between the services, the relationship between the three-member module and the security proxy module is as follows:

[0082] (1) First of all, it should be explained that: security proxy service refers to the service provided by the security proxy module 104, while business service refers to the service provided by the business module, i.e., the application system. The three-member service is a service provided by the three-member module, wherein the three-member service is jointly provided by the system management module 101, the security management module 102, and the audit management module 103 in the three-member module.

[0083] (2) Based on the characteristics of microservices such as service independence and easy scalability, the introduction of the "security agent module" is mainly to facilitate the management and supervision of business services in the microservice system. The security agent service it provides can better meet the security and confidentiality requirements of the three-member system in conjunction with the three-member service. In addition, in emergency situations, the security agent module 104 can handle corresponding problems according to the policies issued by the security management module 102 in the three-member module.

[0084] (3) The security agent module 104 monitors the relevant behaviors of the target service according to the settings, and reports the business module behavior monitoring information to the audit administrator in the three-member module by reporting the monitoring information. If the target service behavior is abnormal, the audit administrator notifies the security administrator to update the abnormal behavior processing strategy, so that the security agent module 104 can better handle the abnormal or illegal behavior of the target service.

[0085] (4) During the service monitoring process, the security agent service mainly interacts with the security administrator and the audit administrator in the three-member service. The system administrator is mainly responsible for the basic management of the target service.

[0086] Furthermore, the three-member authority management system in this embodiment may also include the following modules:

[0087] The multiple redundant modules correspond to the system management module 101, the security management module 102 and the audit management module 103 respectively. The redundant modules are used to execute the functions of the corresponding modules when the corresponding modules fail.

[0088] For example, the system management module 101 corresponds to one or more redundant modules, so that when the system management module 101 fails, its corresponding redundant module can execute the functions of its corresponding module. The security management module 102 corresponds to one or more redundant modules, so that when the security management module 102 fails, its corresponding redundant module can execute the functions of its corresponding module. The audit management module 103 corresponds to one or more redundant modules, so that when the audit management module 103 fails, its corresponding redundant module can execute the functions of its corresponding module.

[0089] As Figure 10 As shown in the schematic diagram of using the multi-copy (i.e., redundant module) mechanism to improve the stability of the three-staff service in [], in terms of the stability of the three-staff service, the multi-copy mechanism of the microservice system is fully utilized in this embodiment. When deploying the system, the number of copies that meet the requirements can be added according to environmental needs. With the cooperation of the unified gateway load balancing and health detection functions, the high availability and stability of the three-staff service are improved. Compared with the three-staff management system under the traditional monolithic architecture, there are great improvements in stability, reliability, and flexibility:

[0090] Specifically:

[0091] (1) Three copies (instances) of the system management module 101 are deployed, namely: system management module instance A, instance B, and instance C. They are three different application processes in the actual physical application, but they are exactly the same in terms of application functions and external services, and the service data is shared.

[0092] (2) The unified gateway module is a common functional module in the microservice system. Common gateways include kong, apisix, nginx, etc. By configuring load balancing policies and service health detection and other functions in the unified gateway, relevant requests can be forwarded to specific service instances.

[0093] (3) Taking the system management module 101 as an example again, under normal circumstances, system management module instance A provides services normally. However, when instance A fails to start abnormally and cannot provide external services, the unified gateway can forward requests to instance B or instance C according to specific configurations.

[0094] (4) For the entire microservice system, the system management module 101 always provides external services, and the relevant services are not interrupted due to the failure of instance A. Therefore, in this process, the copy mechanism improves the reliability and stability of the three-staff service.

[0095] (5) Similarly, Figure 10 Multiple copies (instances) of the security management module 102 and the audit management module 103 in [] are also deployed. The specific copy switching method can refer to the copy switching method in the system management module 101.

[0096] In addition, the system management module 101, the security management module 102, and the audit management module 103 are respectively encapsulated based on containers.

[0097] Reference Figure 11 , which is a flowchart of a three-person permission management method provided in the second embodiment of the present application based on a microservices architecture. This method can be applied to Figure 1 the three-person permission management system based on the microservices architecture shown in the figure. The permission management system based on the microservices architecture at least includes a system management module 101, a security management module 102, an audit management module 103, and a security proxy module 104. The system management module 101, the security management module 102, the audit management module 103, and the security proxy module 104 are all implemented as independent microservices, so that the system management module 101, the security management module 102, the audit management module 103, and the security proxy module 104 operate independently of each other, and the security proxy module 104 is used to implement at least one security proxy service, and each security proxy service corresponds to a target service implemented by the application system;

[0098] Among them, the method may include the following steps:

[0099] Step 1101: Receive an account login request for the application system. The account login request at least includes a login account, and the application system is used to implement a target service;

[0100] Step 1102: Determine whether the login account exists; in the case where the login account does not exist, execute Step 1103; if the login account exists, further determine whether the input login password is correct. If it is correct, then load the current role and the module corresponding to the role, and then enter the application system, and the application system can provide the target service corresponding to the current role for the login account.

[0101] Step 1103: Register users and roles in the application system through the system management module;

[0102] Step 1104: Set the permissions of the user on the target service, set the permissions of the role on the target service, and set the access policy corresponding to the target service through the security management module;

[0103] Among them, the access policy corresponding to the target service is used to control the user and the role to access the target service according to their respective corresponding permissions;

[0104] Step 1105: Audit the module operation data of the system management module and the security management module through the audit management module.

[0105] Step 1106: Monitor the corresponding target service through each security proxy service.

[0106] It should be noted that the execution order between step 1103 and step 1106 in this embodiment is not limited by the execution order in the accompanying drawings, and they can also be executed synchronously, or there can be other execution orders. Different solutions realized by different execution orders are all within the protection scope of this application.

[0107] As can be seen from the above technical solution, in the three-person permission management system based on the microservice architecture provided in the second embodiment of this application, the system management module, security management module, audit management module, and security proxy module in the system are all implemented as independent microservices, so that these modules run independently and are isolated from each other to avoid interference. Even if a security vulnerability such as a virus appears in a certain module, it will not cause the entire system to crash, thereby improving the reliability of permission management.

[0108] Furthermore, in this application, multiple modules in the three-person permission management system are implemented based on independent microservices, which can achieve flexible deployment and expansion, thereby improving the flexibility of deployment.

[0109] In addition, in the embodiment of this application, an electronic device such as a computer or a server can also be provided, and the three-person permission management system based on the microservice architecture described in the above embodiment is built on this electronic device.

[0110] Taking the application system in a certain field as an example, in this embodiment, a three-person permission management system based on the microservice architecture is configured for it. The following is an example of the three-person permission management method based on the microservice architecture in this application:

[0111] The technical solution of this application mainly solves some problems existing in the traditional implementation solutions of the three-person management technology and is applied to the container management platform, specifically including: inflexible service deployment, low stability and reliability, and low security, etc. To solve these problems, this application has been optimized through the following technical means:

[0112] 1. In terms of service deployment flexibility: To achieve flexible service deployment, this application adopts a microservices architecture design. The services of the three-person permission management module are split into multiple independent modules, which can self-contain dependent services and be flexibly deployed and extended according to different customer requirements and hardware environments. In addition, due to the characteristics of the microservices architecture itself, this application can be very conveniently combined with container orchestration technology. Through the lightweight virtualization of containers and the flexible deployment function of orchestration services, the deployment flexibility and efficiency are further improved. Compared with traditional monolithic applications, this application can implement a new deployment architecture based on microservices and container technologies, adjust the deployment strategy according to actual needs, achieve independent deployment, upgrade, and maintenance of the three-person permission management module. The three-person permission management module does not depend on other business modules and system operating environments of the system, improving deployment flexibility.

[0113] 2. In terms of stability and reliability: To improve the system stability and service reliability of the user management service in the container management platform, this application combines the characteristics of the "service multi-copy mechanism" in the microservices system and designs a "security proxy module" to provide a "security proxy service" through the "security proxy module". Generally speaking, the "security proxy module" corresponds one-to-one with each functional module (including replicas) in the microservices system in terms of quantity. In terms of service relationship, the business services (or service replicas) generated by each functional module have the "security proxy service" provided by the corresponding security proxy module. Thus, through the "security proxy module", more refined management and control of each functional module in the microservices can be achieved.

[0114] In addition, this application introduces a redundant high-availability mechanism. By deploying multiple equivalent application instances for the same service, when an individual instance fails, it can be switched to other healthy instances in a timely manner, thus ensuring the continuous availability of the service. At the same time, the "security proxy module" can monitor the running status of each instance to achieve real-time detection of service failures. Compared with the monolithic architecture implementation method of the traditional three-person permission management module, this application implements the multi-copy redundancy mechanism of microservices, which can provide higher system stability and service reliability. Even if an individual service instance fails, it will not cause the interruption of the overall service, thereby improving the high availability and stability of the three-person management service.

[0115] 3. In terms of security: To improve the security of the system in the container management platform, this application uses a microservices architecture to split the three-operator permission management module. Each administrator is regarded as an independent microservice so that it can be independently deployed and run, isolated from each other, avoiding interference and the situation that if a single module and a single process are hijacked in the traditional three-operator permission management module as a whole, the entire three-operator permission management module or the system will be paralyzed and unusable. In addition, the security proxy module can monitor each microservice in real time and quickly respond when abnormal situations are found. At the same time, the security proxy module can also issue security policies to control the abnormal behaviors of the target services, enhancing the security management of microservices. Compared with traditional monolithic applications, this application realizes anomaly monitoring and alerting under the microservices structure. Without affecting the functions, through the cooperation of microservices and the security proxy module, this application comprehensively improves the security of the system.

[0116] It can be seen that through the design of three-operator permission management based on the microservices architecture, as well as the application of the newly added "security proxy module" and the service replica mechanism, on the basis of ensuring the three-operator management function, the deployment flexibility, service stability, system reliability and security are improved. Compared with the traditional three-operator management technology implementation solution, the overall design of this application is more optimized and can provide higher-quality and more secure three-operator management services.

[0117] As Figure 12 shown in the architecture diagram of the overall system design in the figure, this application mainly completes the design of three-operator separation of the system and the design of the security proxy module based on the three-operator separation design of the microservices system.

[0118] Among them, the three-operator separation design of the system in this application mainly controls the permissions of the administrators, and assigns system permissions to the three operators of the system according to the principle of minimum authorization, so that the three form a restrictive relationship with each other.

[0119] The following describes the functional process of implementing permission management in this application:

[0120] The main functional features of the three-operator permission management system implemented based on the microservices architecture (i.e., the three-operator permission management system based on the microservices architecture in the previous text) are reflected in two aspects: one is reflected in the internal permission management of the system. Through the three-operator separation design, the system administrator, security administrator and audit administrator are independently split according to different responsibilities and different permissions, and the three are independent and restrictive with each other; the other is reflected in the service management in the microservices system. By introducing the "security proxy module" and cooperating with the "three-operator module" at the same time, service-level management and control can be realized in the microservices system. Through the specification of security policies, the security and compliance of each sub-service in the microservices system are ensured.

[0121] Regarding the characteristics of the two aspects mentioned above, this application will separately illustrate the working processes and scope of responsibilities of each functional module in terms of permission management and service governance through two processes, namely "account management" and "security service management", respectively. Thus, it reflects the rationality of the three-operator separation design and the security proxy service design, as well as the detailed processes in the application scenarios.

[0122] Among them, the account management process is as Figure 13 shown below:

[0123] Step 1301: Ordinary account login.

[0124] Step 1302: Determine whether the account exists. If the account does not exist, execute Step 1303; if the account exists, execute Step 1306;

[0125] Step 1303: The system administrator creates an account through the system management module, encrypts the user information and stores it in the database. In addition, the system administrator also creates roles through the system management module.

[0126] Step 1304: The security administrator performs security operations through the security management module. For example, the security administrator authorizes the account, and then determines whether there is an authorized role. If there is, the security administrator authorizes the user role; if not, the system administrator first creates a role through the system management module, and then the security administrator authorizes the role through the security management module and authorizes the user role, that is, binds the account to the role.

[0127] Step 1305: The account is activated, and the system is entered using the account, and the process ends.

[0128] Step 1306: Determine whether the password is correct. If the password is correct, execute Step 1307; if the password is incorrect, execute Step 1301;

[0129] Step 1307: Load the role of the current account;

[0130] Step 1308: Load the module corresponding to the role;

[0131] Step 1309: Enter the system, and the process ends.

[0132] Step 1310: During the above process, the audit administrator monitors all user operation behaviors through the audit management module and records and stores relevant audit information.

[0133] It can be seen from the above account management process design that the system administrator is mainly responsible for the creation process of accounts and roles, and the security administrator is mainly responsible for the management and binding of account permissions. By binding the role creation and permissions by the security administrator, the permissions can be implemented on specific accounts, thereby realizing the control of permissions. During the process, the responsibilities of the system administrator and the security administrator are clearly defined, without interference with each other, and the permissions are mutually exclusive. The audit administrator participates in the user behavior audit work throughout the process and does not participate in the specific operation process.

[0134] As Figure 14 shown in the security service management flow chart in

[0135] Step 1401: In the microservice system, run and start the security proxy service in the security proxy module.

[0136] Step 1402: The security proxy service loads the security policies issued by the security administrator and updates the security policies. Based on this, the security proxy service monitors the "target service" according to the security policies within its jurisdiction; and judges whether the "target service" meets or triggers the security policies. If triggered, perform the corresponding security policy operations; if not triggered, the monitoring of this cycle ends and enters the next monitoring cycle.

[0137] Step 1403: After the monitoring information of the "target service" is reported to the audit management module in the three-person permission management system, the audit administrator audits whether the behavior of the "target service" is compliant; if compliant, continue the security audit supervision work; if not compliant, notify the security administrator to take security policy countermeasures.

[0138] Step 1404: After receiving the notice through the security management module, the security administrator sets the security policy and distributes the security policy to the security proxy service.

[0139] In Step 1402, after receiving the new security policy, the security proxy service caches and updates the security policy, and performs a new round of monitoring proxy service work according to the new security policy.

[0140] The above process mainly clarifies the process design of the main work of the security proxy service and the three-person management service in cooperation with the monitoring of the target service. In this process, the security proxy service closely cooperates with the audit management module and the security management module in the three-person management service, so as to achieve real-time monitoring and supervision of the target service, and meet the independent characteristics of each service under the microservice architecture. The security proxy service can accurately monitor each independently running microservice, thereby ensuring the implementation of the relevant security policies of the three-person management system under the microservice architecture, and can meet the finer-grained control of the relevant microservice permissions in a specific environment. Such a design enables the three-person management service to better integrate with the current microservice system architecture in service governance.

[0141] The beneficial effects of this application are summarized as follows:

[0142] (1) This application designs the three-person management function as a microservice module, enabling each module to be independently deployed as a service, which conforms to the characteristics of current microservices such as independent deployment and strong scalability. It can integrate the three-person management concept with the microservice system and can also be well integrated with current container orchestration technologies, enhancing the flexibility of overall service deployment.

[0143] (2) Compared with the traditional three-person design, this application makes full use of the microservice multi-copy mechanism, allowing multiple instances of the same service to run, improving the overall service stability and reliability.

[0144] (3) This application fully considers the deployment characteristics and management features of services in the microservice system and cleverly introduces a "security proxy module" on the basis of the three-person module. Through the cooperation of the "three-person module" and the "security proxy module", it can play a great role in the service management of the microservice system; it can achieve management control at the "service level", and ensure that each sub-service in the microservice system can run legally and compliantly through the formulation of security policies; different security policies can be formulated according to different services, thus realizing flexible customization of management policies between services; it makes up for the deficiencies of the existing three-person management technology in service governance and management in the microservice system, and at the same time, the system security has been improved unprecedentedly.

[0145] (4) In terms of the implementation of the technical route, each functional module of this application conforms to the microservice modular standard, including that each functional module can run and be deployed independently, the RPC communication specifications between modules are consistent, and container encapsulation is supported. In terms of service governance and operation and maintenance, this application can perfectly cooperate with container solutions such as Kubernetes and Docker, making operation and maintenance and governance more convenient and fast. The microservice multi-copy mechanism is also applicable to container platforms. On container platforms such as Kubernetes, the microservice splitting of the three-person permission management can better integrate the replica management mechanism of the container platform and related cloud-native solutions.

[0146] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts between the various embodiments, reference can be made to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and reference can be made to the description in the method part for related parts.

[0147] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application.

[0148] The steps of the methods or algorithms described in combination with the embodiments disclosed herein can be directly implemented by hardware, software modules executed by a processor, or a combination of the two. The software modules can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium well-known in the technical field.

[0149] The above description of the disclosed embodiments enables those skilled in the art to implement or use this application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application will not be limited to these embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A three-person permission management system based on a microservices architecture, characterized in that, At least including: A system management module, at least used for registering users and roles in the application system, and the application system is used to implement the target service; A security management module, at least used for setting the permissions of the user on the target service, setting the permissions of the role on the target service, and setting the access policy corresponding to the target service, and the access policy corresponding to the target service is used to control the user and the role to access the target service according to their respective corresponding permissions; An audit management module, at least used for auditing the module operation data of the system management module and the security management module; A security proxy module, used to implement at least one security proxy service, and each security proxy service is at least used for monitoring a target service implemented by the application system; Wherein, the system management module, the security management module, the audit management module, and the security proxy module are all implemented by independent microservices, so that the system management module, the security management module, the audit management module, and the security proxy module operate independently of each other.

2. The system according to claim 1, wherein The system management module, the security management module, the audit management module, and the security proxy module are all implemented by independent microservices, including: The system management module, the security management module, the audit management module, and the security proxy module respectively run on different at least one process.

3. The system according to claim 1, wherein The security proxy service is used to obtain the access policy corresponding to the target service, and control the user and the role to access the target service according to their respective corresponding permissions according to the access policy corresponding to the target service.

4. The system according to claim 3, wherein The security proxy service is also used to: obtain the service monitoring information corresponding to the target service, and transmit the service monitoring information to the audit management module, so that the audit management module can at least obtain the data corresponding to the service behavior of the target service.

5. The system according to claim 4, characterized in that The audit management module is also used to send an audit alarm message to the security management module when the data corresponding to the service behavior of the target service audited meets the alarm condition; Wherein, the audit alarm message at least characterizes that there is an abnormality in the target service, so that the security management module updates the access policy corresponding to the target service.

6. The system according to claim 1 or 2, characterized in that Also including: Multiple redundant modules, respectively corresponding to the system management module, the security management module, and the audit management module, and the redundant module is used to execute the functions of its corresponding module when its corresponding module fails.

7. The system according to claim 1 or 2, characterized in that, The system management module, the security management module, and the audit management module are respectively encapsulated based on containers.

8. The system according to claim 1 or 2, characterized in that, The module operation data includes: the data corresponding to the user behavior of the target user logged in on the application system, and the data corresponding to the service behavior of the target service implemented by the application system.

9. A three-person permission management method based on a microservices architecture, characterized in that, Applied to a permission management system based on a microservices architecture, the permission management system based on a microservices architecture at least includes a system management module, a security management module, an audit management module, and a security proxy module. The system management module, the security management module, the audit management module, and the security proxy module are all implemented as independent microservices, so that the system management module, the security management module, the audit management module, and the security proxy module operate independently. The security proxy module implements at least one security proxy service, and each security proxy service corresponds to a target service implemented by the application system; Wherein, the method includes: Receiving an account login request for an application system, the account login request at least including a login account, and the application system being used to implement a target service; Determining whether the login account exists; In the case where the login account does not exist, registering users and roles in the application system through the system management module; Setting the permissions of the user on the target service, setting the permissions of the role on the target service, and setting the access policy corresponding to the target service through the security management module; wherein, the access policy corresponding to the target service is used to control the user and the role to access the target service according to their respective corresponding permissions; Auditing the module operation data of the system management module and the security management module through the audit management module; Monitoring the corresponding target service through each security proxy service.

10. An electronic device, characterized in that, The three-person permission management system based on a microservices architecture as claimed in claim 1 is built on the electronic device.

Images