Method and system for automatically generating access control policies between microservices based on blockchain

Abstract

The present invention discloses a method and system for automatically generating access control policies between microservices based on blockchain. The method of the present invention combines the access control policy generation management mechanism based on the request topology diagram and the permission relationship diagram, realizes the permission decision mechanism for service calls separated from the microservice management platform or framework, realizes the permission review of related calling services before service deployment, and the permission decision separated from the service platform, effectively avoiding the service risks brought by the platform and management personnel. The use of blockchain in the present invention guarantees the confidentiality and non-tamperability of the access control policy and the information of related services.

Description

Technical Field

[0001] The present invention belongs to the field of network security, and specifically relates to a method and system for automatically generating access control policies between microservices based on blockchain. Background Art

[0002] Microservices are cloud-native applications, that is, applications designed for the "cloud". After using cloud-native technology, developers do not need to consider the underlying technical implementation, and can give full play to the elasticity and distribution advantages of the cloud platform to achieve rapid deployment, on-demand scaling, and non-stop delivery. It advocates dividing a single application into a group of small services, and the services coordinate and cooperate with each other to provide ultimate value to users. Each service runs in its own independent process, and services communicate with each other using lightweight communication mechanisms. It splits an application into multiple microservices running on different machines (or virtual machines and containers). Each microservice can be independently developed, deployed, upgraded, and expanded. Through lightweight network API calls, multiple services can be combined into service chains to achieve complex functions. Microservices significantly improve the flexibility of cloud applications.

[0003] According to the survey, most microservices are deployed in third-party containers, which brings risks to service deployment and calling. When microservices work together to complete complex functions, their natural mutual trust makes the entire application vulnerable to attacks from a single damaged service. The access control mechanism between services is particularly important.

[0004] Among the existing inter-service access control mechanisms, some use NLP technology based on existing documents, but due to the limitations of NLP, these methods are usually coarse-grained and incomplete; others use collected logs or historical data to infer rule standards and policy structures from traffic. Their effectiveness depends on the granularity and completeness of the tracking, which is difficult to guarantee. In addition, they require the application to run in advance to collect data, which may lead to an attack window; the corresponding security policies are generated through modeling methods, but the modeling process is time-consuming and not suitable for microservices with small scale, low complexity and strong flexibility. Summary of the invention

[0005] The purpose of the present invention is to overcome the above-mentioned shortcomings and provide a method and system for automatically generating access control policies between microservices based on blockchain, so as to solve the risks brought to inter-service calls when microservices are managed by a third-party platform, as well as the problem of determining the calling authority between microservices, and to prevent services from being attacked and infected by malicious microservices.

[0006] In order to achieve the above purpose, a method for automatically generating access control policies between microservices based on blockchain includes the following steps:

[0007] S1, extract the newly added source code;

[0008] S2, statically analyzes the source code, extracts the service request list, and generates a request topology map;

[0009] S3, generates a permission relationship diagram for the corresponding microservices based on the request list and the stored whitelist of access rights for each service provider;

[0010] S4, compares the request topology graph and permission relationship graph of the microservice and generates a decision result;

[0011] S5, deploy services based on source code and decision results.

[0012] In S1, the specific method of extracting source code is as follows:

[0013] S11, determining the programming language included in the newly added source code, and selecting a corpus of the corresponding language;

[0014] S12, identifying the statements containing the request call in the source code through the semantic model in the corpus.

[0015] In S2, the specific method of extracting the service request list is as follows:

[0016] S21, generating static analysis results according to the statement identification;

[0017] S22, based on the static analysis results, obtain program slices of codes related to microservice calls;

[0018] S23, combining program slicing and static analysis results to reverse trace and generate a list of microservices that are called by the request.

[0019] In S4, the specific method for making comparative decisions is as follows:

[0020] S41, generating a calling permission graph between microservices according to the permission relationship on the whitelist;

[0021] S42, compare the permission call graph with the received request topology graph; if it is a subgraph, the permission review is passed and the permission graph is saved; if it is not a subgraph, the microservice cannot be authorized;

[0022] If the service deployed this time is an updated version, the microservice permission graph is called directly according to the service name to make a decision.

[0023] In S5, the specific method of deploying services is as follows:

[0024] S51, generating a service configuration file and a deployment file according to the source code;

[0025] S52, receiving the decision result, if the microservice permission is passed, deploying the microservice according to the service configuration file and deployment file; if the permission is not passed, refusing to deploy.

[0026] A blockchain-based inter-microservice access control policy automatic generation system, including:

[0027] The permission extraction module is used to perform static analysis on the source code of the newly added service and generate a request topology map based on the results;

[0028] The permission decision module is used to determine the request topology and give the decision result;

[0029] Microservice management platform, used to manage microservices and execute the decision results of the permission decision module.

[0030] The permission extraction module includes a static analysis submodule and a topology generation submodule;

[0031] The static analysis submodule includes the tool analysis module, the taint backtracking module, and the list generation module;

[0032] The tool analysis module is used to use static analysis tools of different languages ​​to perform static analysis on the source code of each language and generate static analysis results;

[0033] The taint reverse tracing module is used to perform reverse taint propagation according to the static analysis results to obtain the program slice corresponding to the service call;

[0034] The list generation module is used to generate a list of microservice requests in Json format based on the program slicing results;

[0035] The topology generation submodule includes an information forwarding module and a request topology map generation module;

[0036] The information forwarding module is used to send the request list generated in the static analysis phase to the permission decision module;

[0037] The request topology map generation module is used to generate a request relationship topology map in the microservice according to the request list generated in the static analysis phase, and send the topology map to the permission decision module.

[0038] The permission decision module includes:

[0039] A storage whitelist module is used to store the vendor access permission whitelist of existing services on the platform on the permission blockchain;

[0040] The permission graph generation module is used to extract the service vendor information of the required service call based on the request list list received from the permission extraction module, query the corresponding vendor access permission whitelist, and generate the callable permission relationship graph of the microservice based on the permissions;

[0041] The permission decision submodule is used to compare the request topology map generated by the permission extraction module with the generated permission relationship map. If the request topology is a submap of the permission topology, the microservice will be authorized and the service permission topology map will be stored in the blockchain. If it is not a submap, it means that the permission relationship is not satisfied and the authorization is rejected. The decision result is sent to the microservice management platform;

[0042] The permission update module is used to retrieve the relevant generated permission graph and add corresponding edges or nodes when the whitelist of a service provider is updated.

[0043] The microservice management platform includes:

[0044] Provide a configuration file module to generate the corresponding deployment configuration file. The deployment configuration file contains detailed information and environment variables of the microservice on the platform. The permission extraction module performs program slicing to provide information for generating the request list.

[0045] The permission decision execution module is used to determine whether authorization is obtained based on the received decision results. If authorization is obtained, the microservice is deployed according to the service deployment configuration file. If authorization is not passed, the service deployment is refused.

[0046] Compared with the prior art, the method of the present invention combines the access control policy generation management mechanism based on the request topology diagram and the permission relationship diagram, realizes the permission decision mechanism for service calls separated from the microservice management platform or framework, realizes the permission review of related call services before service deployment, and the permission decision separated from the service platform, effectively avoiding the service risks brought by the platform and management personnel. The use of blockchain in the present invention guarantees the confidentiality and non-tamperability of the access control policy and the information of related services.

[0047] The system of the present invention ensures the immutability and confidentiality of service permissions by storing service permission determination and service permission whitelist in the blockchain of the permission decision module. At the same time, the decision-making mechanism of the permission decision module is separated from the service management platform, effectively avoiding the risks brought by the platform and management personnel. Secondly, the permission determination adopts the service call permission graph determination method, which effectively reduces the permission blockchain and platform data storage scale, and improves the overall operation performance to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 It is a structural diagram of the present invention;

[0049] Figure 2 This is a flowchart of permission extraction in the present invention;

[0050] Figure 3 This is a flowchart of authority decision-making in the present invention;

[0051] Figure 4 This is a flow chart of service update authority determination in the present invention;

[0052] Figure 5 It is a static analysis submodule diagram in the present invention;

[0053] Figure 6 This is a diagram of the authority decision module in the present invention;

[0054] Figure 7 This is a module diagram of the microservice management platform in the present invention. DETAILED DESCRIPTION

[0055] The present invention will be further described below in conjunction with the accompanying drawings.

[0056] See also Figure 1 , a blockchain-based microservice access control policy automatic generation system, including:

[0057] The permission extraction module is used to perform static analysis on the source code of the newly added service and generate a request topology map based on the results;

[0058] The permission decision module is used to determine the request topology and give the decision result;

[0059] Microservice management platform, used to manage microservices and execute the decision results of the permission decision module.

[0060] The permission extraction module includes a static analysis submodule and a topology generation submodule; the permission extraction module consists of a static analysis submodule and a topology generation submodule, the static analysis submodule realizes the extraction of call information attributes in the microservice source code; the topology generation submodule realizes the generation of the microservice call relationship topology map.

[0061] See also Figure 5 ,The static analysis sub-module includes the tool analysis module, the ,taint back-tracing module and the list generation module;

[0062] The tool analysis module is used to use static analysis tools of different languages ​​to perform static analysis on the source code of each language and generate static analysis results;

[0063] The taint reverse tracing module is used to perform reverse taint propagation according to the static analysis results to obtain the program slice corresponding to the service call;

[0064] The list generation module is used to generate a list of microservice requests in Json format based on the program slicing results;

[0065] The workflow of the static analysis submodule is as follows:

[0066] When the microservice source code is submitted to the permission extraction module by the microservice management platform:

[0067] 1) The source code is first submitted to the static analysis module;

[0068] 2) The static analysis module analyzes the programming language used in the source code;

[0069] 3) construct a corpus for the corresponding language;

[0070] 4) Using the semantic model of the corresponding language to identify the statements containing the request call in the source code;

[0071] 5) Use the static analysis tool of the corresponding language to perform static analysis to generate the control flow graph of the corresponding program execution, the call graph of the calling relationship between procedures, and the constant / variable table, etc.;

[0072] 6) Perform taint reverse tracing based on static analysis results and source code and obtain program slices related to service calls;

[0073] 7) Combine program slicing and static analysis results to reversely generate the final request list of relevant information of the called microservices.

[0074] The topology generation submodule includes an information forwarding module and a request topology map generation module;

[0075] The information forwarding module is used to send the request list generated in the static analysis phase to the permission decision module;

[0076] The request topology map generation module is used to generate a request relationship topology map in the microservice according to the request list generated in the static analysis phase, and send the topology map to the permission decision module.

[0077] See also Figure 6 , with the support of blockchain technology, we design the permission decision module between microservices, including:

[0078] A storage whitelist module is used to store the vendor access permission whitelist of existing services on the platform on the permission blockchain;

[0079] The permission graph generation module is used to extract the service vendor information of the required service call based on the request list list received from the permission extraction module, query the corresponding vendor access permission whitelist, and generate the callable permission relationship graph of the microservice based on the permissions;

[0080] The permission decision submodule is used to compare the request topology map generated by the permission extraction module with the generated permission relationship map. If the request topology is a submap of the permission topology, the microservice will be authorized and the service permission topology map will be stored in the blockchain. If it is not a submap, it means that the permission relationship is not satisfied and the authorization is rejected. The decision result is sent to the microservice management platform;

[0081] The permission update module is used to retrieve the relevant generated permission graph and add corresponding edges or nodes when the whitelist of a service provider is updated.

[0082] The workflow of the permission decision module is as follows:

[0083] When the permission decision module receives the request list and request topology from the permission extraction module, the permission decision module first determines whether the service is deployed for the first time. If it is the first time, the service vendor information of the required service is extracted according to the request list, the corresponding vendor access rights whitelist is queried, and the callable permission relationship diagram of the microservice is generated according to the permission. If it is a microservice version update, that is, it is not the first deployment, the access rights diagram of the service is searched in the permission blockchain. The microservice request topology generated by the permission extraction module is determined by an algorithm to see if it is a subgraph of the access rights diagram. If it is a subgraph, the microservice will be authorized and the service permission topology diagram will be stored in the blockchain. If it is not a subgraph, it means that the permission relationship is not satisfied and the authorization is rejected. The decision result is sent to the microservice management platform.

[0084] See also Figure 7 , with the support of cloud native, a Kubernetes cluster is built to manage and run microservices. In the present invention, the main functions of the microservice management platform are to provide configuration files and permission decision execution, including:

[0085] Provide a configuration file module to generate the corresponding deployment configuration file. The deployment configuration file contains detailed information and environment variables of the microservice on the platform. The permission extraction module performs program slicing to provide information for generating the request list.

[0086] The permission decision execution module is used to determine whether authorization is obtained based on the received decision results. If authorization is obtained, the microservice is deployed according to the service deployment configuration file. If authorization is not passed, the service deployment is refused.

[0087] See also Figure 1 , a method for automatically generating access control policies between microservices based on blockchain, comprising the following steps:

[0088] S1, extract the newly added source code;

[0089] S2, statically analyzes the source code, extracts the service request list, and generates a request topology map;

[0090] S3, generates a permission relationship diagram for the corresponding microservices based on the request list and the stored whitelist of access rights for each service provider;

[0091] S4, compares the request topology graph and permission relationship graph of the microservice and generates a decision result;

[0092] S5, deploy services based on source code and decision results.

[0093] See also Figure 2 , the specific method of permission extraction is as follows:

[0094] S11, the permission extraction module receives the source code;

[0095] S12, identifying the programming language included in the microservice and selecting a corpus of the corresponding language;

[0096] S13, using a semantic model of a corresponding programming language to identify statements containing request calls in the source code;

[0097] S14, first generate the corresponding CFGS.cGS and constant / variable table through the static analysis tool of the corresponding language;

[0098] S15, based on the static analysis results, reverse pollution propagation is performed to obtain program slices of codes related to microservice calls;

[0099] S16, generating a request list list by combining program slicing and static analysis results;

[0100] S17, sending the request list to the authority decision module;

[0101] S18, the permission extraction module generates a request topology map according to the request list and sends it to the permission decision module.

[0102] The specific method to extract the service request list is as follows:

[0103] S21, generating static analysis results according to the statement identification;

[0104] S22, based on the static analysis results, obtain program slices of codes related to microservice calls;

[0105] S23, combining program slicing and static analysis results to reverse trace and generate a list of microservices that are called by the request.

[0106] See also Figure 3 , the specific method for making comparative decisions is as follows:

[0107] S41, receiving the request list sent by the permission extraction module;

[0108] S42, if the service is deployed for the first time, extract the vendor permission whitelist of related calling services according to the request list, and generate a calling permission graph between microservices according to the permission relationship on the whitelist;

[0109] S43, comparing the permission call graph with the received request topology graph;

[0110] S44, if it is a subgraph, the permission review is passed and the permission graph is saved; if it is not a subgraph, the microservice cannot be authorized;

[0111] S45, if the service deployed this time is an updated version, the microservice permission graph is directly called according to the service name to make a decision;

[0112] S46, sending the decision result to the microservice management platform.

[0113] The specific method of deploying the service is as follows:

[0114] S51, generating a service configuration file and a deployment file according to the source code;

[0115] S52, receiving the decision result, if the microservice permission is passed, deploying the microservice according to the service configuration file and deployment file; if the permission is not passed, refusing to deploy.

[0116] See also Figure 4 , the service update process includes the following steps:

[0117] S451, the permission extraction module generates a request topology map according to the service source code;

[0118] S452, sending the permission topology map to the permission decision module;

[0119] S453, the permission decision module finds the corresponding microservice permission graph according to the service name, determines and generates the authorization result;

[0120] S454, sending the result to the microservice management platform.

Claims

1. A method for automatically generating access control policies between microservices based on blockchain, characterized in that: The following steps are involved: S1, extract the newly added source code; S2, statically analyzes the source code, extracts the service request list, and generates a request topology map; The specific method is as follows: S21, the permission extraction module receives the source code; S22, identifying the programming language included in the microservice and selecting a corpus of the corresponding language; S23, using a semantic model of a corresponding programming language to identify statements containing request calls in the source code; S24, first generate the corresponding CFGS.cGS and constant / variable table through the static analysis tool of the corresponding language; S25, based on the static analysis results, reverse pollution propagation is performed to obtain program slices of codes related to microservice calls; S26, generating a request list list by combining program slicing and static analysis results; S27, sending the request list to the authority decision module; S28, the permission extraction module generates a request topology map according to the request list and sends it to the permission decision module; S3, generates a permission relationship diagram for the corresponding microservices based on the request list and the stored whitelist of access rights for each service provider; S4, compare the request topology diagram and permission relationship diagram of the microservice and generate a decision result; the specific method is as follows: S41, generating static analysis results according to the statement identification; S42, based on the static analysis results, obtaining program slices of codes related to microservice calls; S43, combining program slicing and static analysis results to reversely trace the source and generate a list of microservices that are called by the request; S44, receiving the request list sent by the permission extraction module; S45, if the service is deployed for the first time, extract the vendor permission whitelist of related calling services according to the request list, and generate a calling permission graph between microservices according to the permission relationship on the whitelist; S46, comparing the call permission graph with the received request topology graph; S47, if it is a subgraph, the permission review is passed and the calling permission graph is saved; if it is not a subgraph, the microservice cannot be authorized; S48, if the service deployed this time is an updated version, the calling permission graph is directly called according to the service name to make a decision; S49, sending the decision result to the microservice management platform; S5, deploy services based on source code and decision results.

2. According to the method for automatically generating access control policies between microservices based on blockchain according to claim 1, it is characterized in that: In S1, the specific method of extracting source code is as follows: S11, determining the programming language included in the newly added source code, and selecting a corpus of the corresponding language; S12, identifying the statements containing the request call in the source code through the semantic model in the corpus.

3. According to the method for automatically generating access control policies between microservices based on blockchain according to claim 1, it is characterized in that: In S5, the specific method of deploying services is as follows: S51, generating a service configuration file and a deployment file according to the source code; S52, receiving the decision result, if the microservice permission is passed, deploying the microservice according to the service configuration file and deployment file; If the permission is not granted, the deployment is rejected.

4. A blockchain-based microservice access control policy automatic generation system, characterized in that: include: The permission extraction module is used to extract the newly added source code; perform static analysis on the source code, extract the service request list, and generate a request topology map; The specific method of extracting permissions is as follows: S11, the permission extraction module receives the source code; S12, identifying the programming language included in the microservice and selecting a corpus of the corresponding language; S13, using a semantic model of a corresponding programming language to identify statements containing request calls in the source code; S14, first generate the corresponding CFGS.cGS and constant / variable table through the static analysis tool of the corresponding language; S15, based on the static analysis results, reverse pollution propagation is performed to obtain program slices of codes related to microservice calls; S16, generating a request list list by combining program slicing and static analysis results; S17, sending the request list to the authority decision module; S18, the permission extraction module generates a request topology map according to the request list and sends it to the permission decision module; The specific method to extract the service request list is as follows: S21, generating static analysis results according to the statement identification; S22, based on the static analysis results, obtain program slices of codes related to microservice calls; S23, combining program slicing and static analysis results to reversely trace the source and generate a list of microservices that are called by the request; The permission decision module is used to generate a permission relationship diagram for the corresponding microservice based on the request list and the stored whitelist of access rights of each service provider; compare the request topology diagram of the microservice with the permission relationship diagram and generate a decision result; the specific method for making a comparison decision is as follows: S41, receiving the request list sent by the permission extraction module; S42, if the service is deployed for the first time, extract the vendor permission whitelist of related calling services according to the request list, and generate a calling permission graph between microservices according to the permission relationship on the whitelist; S43, comparing the call permission graph with the received request topology graph; S44, if it is a subgraph, the permission review is passed and the calling permission graph is saved; if it is not a subgraph, the microservice cannot be authorized; S45, if the service deployed this time is an updated version, the calling permission graph is directly called according to the service name to make a decision; S46, sending the decision result to the microservice management platform; A microservice management platform for deploying services based on source code and decision results.

5. According to claim 4, a blockchain-based microservice access control strategy automatic generation system is characterized in that: The permission extraction module includes a static analysis submodule and a topology generation submodule; The static analysis submodule includes the tool analysis module, the taint backtracking module, and the list generation module; The tool analysis module is used to use static analysis tools of different languages ​​to perform static analysis on the source code of each language and generate static analysis results; The taint reverse tracing module is used to perform reverse taint propagation according to the static analysis results to obtain the program slice corresponding to the service call; The list generation module is used to generate a list of microservice requests in Json format based on the program slicing results; The topology generation submodule includes an information forwarding module and a request topology map generation module; The information forwarding module is used to send the request list generated in the static analysis phase to the permission decision module; The request topology map generation module is used to generate a request relationship topology map in the microservice according to the request list generated in the static analysis phase, and send the topology map to the permission decision module.

6. According to the blockchain-based microservice access control strategy automatic generation system according to claim 4, it is characterized in that: The permission decision module includes: A storage whitelist module is used to store the vendor access permission whitelist of existing services on the platform on the permission blockchain; The permission graph generation module is used to extract the service vendor information of the required service call based on the request list list received from the permission extraction module, query the corresponding vendor access permission whitelist, and generate the callable permission relationship graph of the microservice based on the permissions; The permission decision submodule is used to compare and determine the request topology map generated by the permission extraction module with the generated permission relationship map. If the request topology is a submap of the permission topology, the microservice will be authorized and the request topology map will be stored in the blockchain. If it is not a submap, it means that the permission relationship is not satisfied and the authorization is rejected. The decision result is sent to the microservice management platform; The permission update module is used to retrieve the relevant generated permission relationship graph and add corresponding edges or nodes when the whitelist of a service provider is updated.

7. According to claim 4, a blockchain-based microservice access control strategy automatic generation system is characterized in that: The microservice management platform includes: Provide a configuration file module to generate the corresponding deployment configuration file. The deployment configuration file contains detailed information and environment variables of the microservice on the platform. The permission extraction module performs program slicing to provide information for generating the request list. The permission decision execution module is used to determine whether authorization is obtained based on the received decision results. If authorization is obtained, the microservice is deployed according to the service deployment configuration file. If authorization is not passed, the service deployment is refused.

Images