A security system for implementing microservice security based on bytecode enhancement

By loading a bytecode-enhanced security plugin at JVM startup, the security status of Java microservices is dynamically detected, solving the problem of malicious code tampering during Java program loading. This achieves high-accuracy security detection and anomaly reporting, ensuring program security in cloud environments.

CN116009991BActive Publication Date: 2026-04-17CHINA ELECTRONICS CLOUD DIGITAL INTELLIGENCE TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
CHINA ELECTRONICS CLOUD DIGITAL INTELLIGENCE TECH CO LTD
Filing Date
2023-02-24
Publication Date
2026-04-17

AI Technical Summary

Technical Problem

In existing technologies, Java microservices in containers have problems with malicious code injection and escape, which can lead to the Java program being illegally tampered with during loading, and existing security monitoring methods are difficult to effectively defend against malicious code evasion.

Method used

A bytecode-enhanced security plugin is adopted, including a scanning and detection module, an executor module, a service authentication module, and a communication module. By loading the security plugin at JVM startup, the security status of the program is dynamically detected, and the preMain method is used to load it first, preventing malicious code from tampering with and escaping.

Benefits of technology

It implements dynamic security detection for Java programs, which can detect illegal tampering during the creation of malicious agent programs, ensuring program security, and report abnormal information through the communication module with high accuracy, accompanying the entire life cycle of the program.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116009991B_ABST
    Figure CN116009991B_ABST
Patent Text Reader

Abstract

This invention discloses a security plugin for microservice security based on bytecode enhancement, relating to the microservice domain. It includes a scanning and detection module, an executor module, a service authentication module, and a communication module. The security plugin is loaded into the program when the JVM starts. The scanning and detection module performs initialization operations after the security plugin is loaded to scan and detect whether the program has been illegally modified. The executor module receives and executes instructions, including basic configuration loading instructions for the scanning and detection module and distribution instruction data generated based on the scanning and detection data. The communication module reports the scanning and detection data to the security control backend and receives distribution instruction data and authorization tokens from the security control backend. The service authentication module obtains the authorization token and updates its cache for service authentication. This invention can dynamically detect the security status of a program with high accuracy.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of microservices, and more specifically to a security plugin for microservices security based on bytecode enhancement. Background Technology

[0002] According to relevant surveys and research, most programmers use the Java language for their work, and the market share of the Java language has remained the largest in recent years. Java source code is compiled into bytecode (Class format) by the compiler, and the bytecode file is loaded and run by the JVM (Java Virtual Machine).

[0003] The JVM provides the JVMTI (JVM Tool Interface, a program interface defined in the Java Virtual Machine for developing and monitoring JVM programs) interface. JPLISAgent (Java Programming Language Instrumentation Services Agent) can be used to modify target code and expose much information about the runtime JVM, such as threads, GC (garbage collection), and memory. The Agent can be loaded either before or during the target JVM's runtime. Loading the Agent during runtime provides dynamic capabilities, retrieving data from the target JVM and then passing it to external processes, making it suitable for scenarios such as feature debugging, hot deployment, online problem diagnosis, and performance analysis. Loading the Agent before JVM startup, without modifying the source code, can enhance the program's capabilities; for example, the popular APM (Application Performance Management) implementation uses this approach. Figure 1 and Figure 2 As shown.

[0004] According to relevant forecasts, digital workloads deployed on cloud-native platforms will grow from 30% to 95% in the future. Cloud-native technologies, represented by containers, microservices, and DevOps (processes, methods, and systems), have been practiced and validated in multiple industries such as finance, telecommunications, and the internet. The demand for digital transformation is strong, and with the implementation of technical concepts such as PaaS (Platform as a Service), FaaS (Function as a Service), and Serverless (the next generation of cloud computing technology and architecture), applications are being handed over to Infrastructure as a Service (IAAS) to maximize the value of the cloud. Therefore, ensuring that cloud service providers enhance services under secure permissions will face challenges, and managing the secure and non-intrusive runtime of Java programs will be a problem that both customers and cloud service providers need to solve.

[0005] With the development of microservices, developing microservices in containers has become an inevitable trend. This approach inherits the advantages of containers, such as rapid startup, elastic scaling, and portability. Furthermore, running microservices in a standalone container eliminates limitations imposed by environment, framework, or language. While container-based microservice development offers numerous benefits, including ease of expansion and management, it also presents security challenges, such as malicious code injection, network vulnerability attacks, and image vulnerability attacks.

[0006] Current security monitoring for Java microservices primarily involves passing a JVM PID (thread ID) to the `attach` method (which utilizes Unix DomainSocket principles to implement inter-process communication in Linux). This remotely connects to the target JVM and dynamically injects a security detection agent to match suspicious characteristics in the program, such as common memory malware. However, this method has a significant drawback: programs already injected with malicious code can evade and bypass the newly injected security detection agent, leading to unauthorized modification of the Java program during loading. Escape refers to the malicious code changing its characteristics after successful detection, while bypassing detection means the malicious code prevents the normal injection of the security detection agent or deletes the socket file corresponding to the exposed PID. Summary of the Invention

[0007] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a security plugin for microservice security based on bytecode enhancement, which can dynamically detect the security status of the program with high accuracy.

[0008] To achieve the above objectives, the technical solution adopted by the present invention includes a scanning and detection module, an executor module, a service authentication module, and a communication module, wherein the security plugin is loaded into the program when the JVM starts.

[0009] The scanning and detection module is used to perform initialization operations after the security plugin is loaded, in order to scan and detect whether the program has been illegally modified;

[0010] The actuator module is used to receive and execute instructions, including basic configuration loading instructions for the scanning and detection module and instruction data generated based on the scanning and detection data.

[0011] The communication module is used to report scan detection data to the security control backend, and to receive the command data and authorization token issued by the security control backend;

[0012] The service authentication module is used to obtain the authorization token and update the cache for service authentication.

[0013] Based on the above technical solutions,

[0014] The initialization operation includes loading the basic configuration and whitelist configuration for scanning and detection;

[0015] The security control backend generates and issues command data based on the scan detection data obtained by the scan detection module.

[0016] The communication module is also used to communicate with the security control backend to keep the security plugin active via heartbeat.

[0017] The service authentication module is specifically used to configure appId and appSecert in the security control backend so that the security plugin can obtain the authorization token, and to inject application configuration to perform token caching, token updating, caching public key and updating public key when the service caller and service provider start.

[0018] Based on the above technical solutions,

[0019] The basic configuration includes methods for handling unauthorized Agent plugins, cleanup scripts, and execution strategies;

[0020] The whitelist is configured as a list of authorized Agent plugins.

[0021] Based on the above technical solution, the specific process of the scanning and detection module scanning and detecting the program is as follows:

[0022] Start the JVM, load the security plugin, and perform initialization operations on the scanning and detection module;

[0023] The scanner executes the `check` method, recursively checking the `ClassFileTransformer` interface to determine if any Agent plugins not in the whitelist are loaded.

[0024] If so, the Agent plugins not in the whitelist will be cleaned up based on the configured processing logic, and then the main program will continue to run.

[0025] If not, continue running the main program.

[0026] Based on the above technical solution, the configuration-based processing logic cleans up Agent plugins not in the whitelist and then continues to run the main program. The specific steps include:

[0027] Based on the configuration-based processing logic, determine whether to clean up immediately:

[0028] If so, execute the cleanup script and then continue running the main program;

[0029] If not, determine whether to terminate the program's execution:

[0030] - If the program is to be terminated, then the program will be terminated.

[0031] - If the program is not terminated, the main program will continue to run.

[0032] Based on the above technical solutions,

[0033] The issued instruction data includes the execution target, execution timing, and execution method;

[0034] After the instruction data is sent to the executor module, it is parsed by the executor module and then loaded into the executor.

[0035] The executors include SimpleAsyncTaskExecutor and SchedulerTaskExecutor;

[0036] The SimpleAsyncTaskExecutor is a one-time asynchronous executor, and the executor module exits after the instruction is executed;

[0037] The SchedulerTaskExecutor is a task executor used to execute instructions according to the execution timing in the issued instruction data. After execution, the execution result is reported to the security control backend through the communication module. The security control backend stores and displays the execution result.

[0038] Based on the above technical solution, the specific workflow of the actuator module is as follows:

[0039] Upon entering the executor module, determine whether there is newly issued command data. If so, overwrite the basic configuration based on the issued command data and instantiate the executor. If not, instantiate the executor based on the original basic configuration.

[0040] Determine whether the currently issued instruction data is executed asynchronously in a single operation:

[0041] If so, it will drive SimpleAsyncTaskExecutor to work, obtain the execution result, and report it to the security control backend;

[0042] If not, then the SchedulerTaskExecutor will be activated to obtain the execution results and report them to the security control backend.

[0043] Based on the above technical solution, the specific workflow of the service authentication module is as follows:

[0044] After the service provider starts its service, it calls the service authentication module to obtain the public keys of all services from the security control backend and caches the obtained public keys and public key timestamps locally.

[0045] When a service call occurs, the service caller invokes the token acquisition interface to request and obtain the service provider's token;

[0046] The service caller places the obtained token in the header and sends a verification request to the service provider;

[0047] The service provider verifies the token information in the verification request and returns the interface request result to the service caller after the verification is successful, thus completing the two-way authentication.

[0048] Based on the above technical solution, the service provider verifies the token information in the verification request. The verification process includes: verifying whether the token exists, reading the token and parsing the authType field, verifying the local public key, verifying the signature, verifying the expiration time, and verifying permissions.

[0049] Based on the above technical solutions,

[0050] If the token does not exist, the interface authentication is skipped.

[0051] When reading the token and parsing the authType field, when the authType field is 0, it means that access permissions are verified based on the authorities in the token; when the authType field is -1, it means that the interface authentication is skipped.

[0052] The verification of the local public key involves reading the pubkey in the payload and comparing it with the local public key timestamp. If the two do not match, the public key is updated.

[0053] The signature verification is performed by using a public key to verify the token. If the verification fails, an invalid token message is returned.

[0054] The verification permission is to read the expired value to determine if the token has expired. If the token has expired, an expired token prompt will be returned.

[0055] The permission verification is based on the service's permissions to determine whether the current interface request method and URL permissions are valid.

[0056] Compared with existing technologies, the advantages of this invention are as follows: it solves the problem of Java programs being illegally tampered with during the loading process, and can grant deployment permissions to programs through authorization, enabling legitimate enhancements to objects within the program. The security plugin in this invention is loaded before JVM startup via the preMain method, ensuring that the security plugin is loaded first, thus avoiding the possibility of being counter-attacked by malicious programs. It can dynamically detect the security status of the program, and can detect malicious agents (plugins) during their creation process. If there is any illegal tampering or unauthorized modification, the program will automatically exit and report the abnormal information through the communication module of the security plugin, with extremely high accuracy, and it accompanies the entire lifecycle of the program. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 The flowchart is loaded before the JVM starts using the premain method;

[0059] Figure 2 The flowchart is loaded after the JVM starts using the agentmain method;

[0060] Figure 3 This is a schematic diagram of the security plugin structure in an embodiment of the present invention;

[0061] Figure 4 This is a flowchart of the scanning and detection module's workflow.

[0062] Figure 5 This is a flowchart of the actuator module's workflow. Detailed Implementation

[0063] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Conventional security testing methods can only perform static checks, not dynamic checks, and lack the ability to handle such situations. The security plugin of this invention can dynamically detect the security status of a program, even during the creation of a malicious agent program (plugin). If unauthorized tampering or modifications are found, the program will automatically exit and report the anomaly information through the security plugin's communication module. This process is highly accurate and persists throughout the entire program lifecycle.

[0065] A key characteristic of microservices is the frequent and complex inter-service calls. Numerous microservice frameworks and middleware are used, inevitably leading to numerous potential vulnerabilities and dependencies. At its core, services register via a registration interface. All microservices registered to the registry can call each other, but these calls lack security guarantees. For example, the registry address can be viewed through the startup configuration. Malicious registration of a target service with the same name (such as a billing service) to that registry could alter fees. This invention's security plugin provides tag-based routing filtering, simple target service authentication, and two-way authentication between service consumers and providers.

[0066] See Figure 3 As shown in the illustration, this invention provides a security plugin for microservice security based on bytecode enhancement, comprising a scanning and detection module, an executor module, a service authentication module, and a communication module. These modules collaborate to complete their tasks. The security plugin is implemented through bytecode enhancement and is loaded into the program when the JVM starts. This invention uses the `preMain` method (a loading method) to load the security plugin, resulting in an early loading time that allows it to detect unexpected operations and malicious intrusions during the program's lifecycle.

[0067] In this invention, the scanning and detection module is used to perform an initialization operation after the security plugin is loaded, in order to scan and detect whether the program has been illegally modified. That is, after the initialization operation is completed, the program is scanned and detected to ensure that the program is not illegally modified. The initialization operation includes loading the basic configuration and whitelist configuration for scanning and detection.

[0068] Specifically, the basic configuration includes how to handle unauthorized Agent plugins, cleanup scripts, and execution strategies; the whitelist configuration is a list of authorized Agent plugins, such as Apm Agent.

[0069] The scanning and detection module executes the check method to recursively detect the java.lang.instrument.ClassFileTransformer interface, preventing bypass of multi-level nested interface structures. Once a non-whitelisted plugin class inheriting from the java.lang.instrument.ClassFileTransformer interface is detected, its bytecode can be modified to null by executing return new byte[0], thereby achieving the purpose of destruction. If it is a whitelisted plugin, it is allowed; otherwise, the program is stopped from continuing to load. The implementation class can also be cleaned up according to the security plugin configuration items.

[0070] In this invention, the specific process by which the scanning and detection module scans and detects the program is as follows:

[0071] Start the JVM, load the security plugin, and perform initialization operations on the scanning and detection module;

[0072] The scanner executes the `check` method, recursively checking the `ClassFileTransformer` interface to determine if any Agent plugins not in the whitelist are loaded.

[0073] If so, the Agent plugins not in the whitelist will be cleaned up based on the configured processing logic, and then the main program will continue to run.

[0074] If not, continue running the main program.

[0075] In this invention, the Agent plugins not on the whitelist are cleaned up based on the configured processing logic, and then the main program continues to run. The specific steps include:

[0076] Based on the configuration-based processing logic, determine whether to clean up immediately:

[0077] If so, execute the cleanup script and then continue running the main program;

[0078] If not, determine whether to terminate the program's execution:

[0079] - If the program is to be terminated, then the program will be terminated.

[0080] - If the program is not terminated, the main program will continue to run.

[0081] The following combination Figure 4The specific workflow of the scanning and detection module of the present invention will be described.

[0082] S101: Start the JVM, then proceed to S102;

[0083] S102: Load security plugin, proceed to S103:

[0084] S103: The security plugin scanning and detection module performs initialization operations, then proceeds to S104;

[0085] S104: The scanner performs a scan, recursively checking the ClassFileTransformer interface, then proceeds to S105;

[0086] S105: Determine if there is an Agent plugin that is not in the whitelist being loaded. If not, proceed to S106; if yes, proceed to S107.

[0087] S106: Continue running the main program and wait for the next scan command;

[0088] S107: Execute the configuration processing logic, then proceed to S108;

[0089] S108: Determine whether immediate cleanup is required. If yes, proceed to S109; otherwise, proceed to S110.

[0090] S109: Execute the cleanup script, proceed to S106;

[0091] S110: Determine whether to terminate the program. If yes, go to S111; otherwise, go to S106.

[0092] S111: Abort the program.

[0093] In this invention, the actuator module is used to receive instructions and execute the received instructions. The instructions include basic configuration loading instructions for the scanning and detection module and instruction data generated based on the scanning and detection data. The security control backend generates instruction data based on the scanning and detection data obtained by the scanning and detection module.

[0094] Specifically, the issued command data includes the execution object, execution timing, and execution method. When the execution method is a script, it also includes encrypted execution script data. After the command data is sent to the executor module, it is parsed and loaded into the executor. The executor includes SimpleAsyncTaskExecutor and SchedulerTaskExecutor. SimpleAsyncTaskExecutor is a one-time asynchronous executor, and it controls the executor module to exit after the command execution is completed. SchedulerTaskExecutor is a task executor used to execute commands according to the execution timing in the issued command data. After execution, it reports the execution result to the security control backend through the communication module. The security control backend stores and displays the execution result and can also be connected to the dashboard and alarm center.

[0095] In this invention, the specific workflow of the actuator module is as follows:

[0096] Upon entering the executor module, determine whether there is newly issued command data. If so, overwrite the basic configuration based on the issued command data and instantiate the executor. If not, instantiate the executor based on the original basic configuration.

[0097] Determine whether the currently issued instruction data is executed asynchronously in a single operation:

[0098] If so, it will drive SimpleAsyncTaskExecutor to work, obtain the execution result, and report it to the security control backend;

[0099] If not, then the SchedulerTaskExecutor will be activated to obtain the execution results and report them to the security control backend.

[0100] The following combination Figure 5 The working process of the actuator module of the present invention will be described.

[0101] S201: Enter the actuator module, then proceed to S202;

[0102] S202: Determine if there is a newly issued instruction data. If yes, proceed to S203; otherwise, proceed to S204.

[0103] S203: Based on the data overriding of issued instructions, proceed to S205;

[0104] S204: Based on the original basic configuration, switch to S205;

[0105] S205: Instantiate the executor, proceed to S206;

[0106] S206: Determine whether it is a one-time asynchronous execution. If yes, go to S207; otherwise, go to S208.

[0107] S207: Drive SimpleAsyncTaskExecutor to work, then proceed to S209;

[0108] S208: Drive SchedulerTaskExecutor to work, then proceed to S209;

[0109] S209: Obtain the execution result and report it to the security control backend.

[0110] In this invention, the communication module is used to report scan detection data to the security control backend, and to receive command data and authorization tokens issued by the security control backend. The communication module also communicates with the security control backend to perform heartbeat keep-alive on the security plugin. Furthermore, the communication module of this invention is loaded in an isolated manner, without modifying the original program. Communication between the communication module and the security control backend is based on the gRPC protocol (a communication protocol), thereby saving on the number of server connections and overhead.

[0111] In this invention, the service authentication module is used to obtain the authorization token and update the cache for service authentication. Specifically, the service authentication module is used to configure appId (application identifier) ​​and appSecert (API interface key) in the security control background so that the security plugin can obtain the authorization token, and to inject application configuration when the service caller and service provider start. The service authentication module is also used to perform token caching, token updating, caching public key and updating public key.

[0112] The service authentication module ensures the security of microservice calls. It is designed based on the OAuth 2.0 open protocol – client authorization model. Information transmission uses JSON Web Token (JWT, an open standard), and encryption is performed using the Chinese national cryptographic algorithm SM2. JWT signing uses both SM2 and SM3 cryptographic algorithms.

[0113] In this invention, the specific workflow of the service authentication module is as follows:

[0114] S301: After the service provider starts the service, the service provider calls the service authentication module to obtain the public keys of all services from the security control backend, and caches the obtained public keys and public key timestamps locally;

[0115] S302: When a service call occurs, the service caller calls the token acquisition interface to request and obtain the service provider's token;

[0116] S303: The service caller places the obtained token in the header, in the format Auth-Security:Bearer <token>and initiate a verification request to the service provider;

[0117] S304: The service provider verifies the token information in the verification request and returns the interface request result to the service caller after the verification is successful, thus completing the two-way authentication.

[0118] In this invention, the service provider verifies the token information in the verification request. The verification process includes: verifying whether the token exists, reading the token and parsing the authType (authorization type) field, verifying the local public key, verifying the signature, verifying the expiration time, and verifying permissions.

[0119] In this invention, for verifying the existence of a token, if it does not exist, interface authentication is skipped. For reading the token and parsing the authType field, when the authType field is 0, it indicates that access permissions are verified based on the authorities (permissions) within the token; when the authType field is -1, it indicates that interface authentication is skipped. Verifying the local public key involves reading the pubkey (public key) in the payload and comparing it with the local public key timestamp; if the two do not match, the public key is updated. Verifying the signature involves using the public key to verify the token; if verification fails, an invalid token message is returned. Verifying permissions involves reading expired and determining whether the token has expired; if the token has expired, a token expiration message is returned. Verifying permissions also involves determining whether the current interface request method and URL permissions are valid based on the service's permissions.

[0120] This invention can effectively ensure the security of the program startup process; ensure the security of the program during the operation hosted by the cloud provider; this invention can detect the status of the program in real time; has the ability to respond quickly in insecure states; this invention guarantees the security and reliability of service calls.

[0121] This invention presents a security plugin for microservice security based on bytecode enhancement. It addresses the possibility of unauthorized modification of Java programs during loading, granting deployment permissions to the program through authorization and enabling legitimate enhancements to objects (which may be objects or classes) within the program. The security plugin in this invention uses a preMain method, loading before JVM startup to ensure priority loading and prevent malicious programs from attacking it. It can dynamically detect the program's security status, even during the creation of malicious agents (plugins). If unauthorized modification or tampering is detected, the program automatically exits and reports the anomaly through the security plugin's communication module, achieving extremely high accuracy and persisting throughout the program's entire lifecycle.

[0122] It should be noted that in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0123] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.< / token>

Claims

1. A security system for microservice security based on bytecode enhancement, characterized in that, The security system includes a scanning and detection module, an executor module, a service authentication module, and a communication module, and the security system is loaded into the program when the JVM starts. The scanning and detection module is used to perform initialization operations after the security system is loaded, in order to scan and detect whether the program has been illegally modified; The actuator module is used to receive and execute instructions, including basic configuration loading instructions for the scanning and detection module and instruction data generated based on the scanning and detection data. The communication module is used to report scan detection data to the security control backend, and to receive the command data and authorization token issued by the security control backend; The service authentication module is used to obtain the authorization token and update the cache for service authentication. The initialization operation includes loading the basic configuration and whitelist configuration for scanning and detection; the basic configuration includes the handling logic, cleanup script and execution strategy for unauthorized Agent plugins; the whitelist configuration is a list of authorized Agent plugins. The specific process by which the scanning and detection module scans and detects the program is as follows: Start the JVM, load the security system, and perform initialization operations on the scanning and detection module; The scanner executes the `check` method, recursively checking the `ClassFileTransformer` interface to determine if any Agent plugins not in the whitelist are loaded. If so, the Agent plugins not in the whitelist will be cleaned up based on the configured processing logic, and then the main program will continue to run. If not, continue running the main program.

2. A security system for microservice security based on bytecode enhancement as described in claim 1, characterized in that: The security control backend generates and issues command data based on the scan detection data obtained by the scan detection module. The communication module is also used to communicate with the security control backend to keep the security system active via heartbeat. The service authentication module is specifically used to configure appId and appSecret in the security control backend so that the security system can obtain the authorization token, and to inject application configuration to perform token caching, token updating, caching public key, and updating public key when the service caller and service provider start up.

3. The security system for enhancing implementation of microservice security based on bytecode according to claim 2, wherein, The configuration-based processing logic cleans up Agent plugins not on the whitelist and then continues running the main program. Specific steps include: Based on the configuration-based processing logic, determine whether to clean up immediately: If so, execute the cleanup script and then continue running the main program; If not, determine whether to terminate the program's execution: - If the program is to be terminated, then the program will be terminated. - If the program is not terminated, the main program will continue to run.

4. A security system for microservice security based on bytecode enhancement as described in claim 2, characterized in that: The issued instruction data includes the execution target, execution timing, and execution method; After the instruction data is sent to the executor module, it is parsed by the executor module and then loaded into the executor. The executors include SimpleAsyncTaskExecutor and SchedulerTaskExecutor; The SimpleAsyncTaskExecutor is a one-time asynchronous executor, and the executor module exits after the instruction is executed; The SchedulerTaskExecutor is a task executor used to execute instructions according to the execution timing in the issued instruction data. After execution, the execution result is reported to the security control backend through the communication module. The security control backend stores and displays the execution result.

5. The security system for enhancing implementation of microservice security based on bytecode of claim 4, wherein, The specific workflow of the actuator module is as follows: Upon entering the executor module, determine whether there is newly issued command data. If so, overwrite the basic configuration based on the issued command data and instantiate the executor. If not, instantiate the executor based on the original basic configuration. Determine whether the currently issued instruction data is executed asynchronously in a single operation: If so, it will drive SimpleAsyncTaskExecutor to work, obtain the execution result, and report it to the security control backend; If not, then the SchedulerTaskExecutor will be activated to obtain the execution results and report them to the security control backend.

6. A security system for microservice security based on bytecode enhancement as described in claim 2, characterized in that, The specific workflow of the service authentication module is as follows: After the service provider starts its service, it calls the service authentication module to obtain the public keys of all services from the security control backend and caches the obtained public keys and public key timestamps locally. When a service call occurs, the service caller invokes the token acquisition interface to request and obtain the token from the service provider. The service caller places the obtained token in the header and sends a verification request to the service provider; The service provider verifies the token information in the verification request and returns the interface request result to the service caller after the verification is successful, thus completing the two-way authentication.

7. A security system for microservice security based on bytecode enhancement as described in claim 6, characterized in that, The service provider verifies the token information in the verification request. The verification process includes: verifying whether the token exists, reading the token and parsing the authType field, verifying the local public key, verifying the signature, verifying the expiration time, and verifying permissions.

8. A security system for microservice security based on bytecode enhancement as described in claim 7, characterized in that: If the token does not exist, the interface authentication is skipped. When reading the token and parsing the authType field, when the authType field is 0, it means that access permissions are verified based on the authorities in the token; when the authType field is -1, it means that the interface authentication is skipped. The verification of the local public key involves reading the pubkey in the payload and comparing it with the local public key timestamp. If the two do not match, the public key is updated. The signature verification is performed by using a public key to verify the token. If the verification fails, an invalid token message is returned. The verification expiration time is determined by reading the expired value and checking if the token has expired. If the token has expired, an expiration message is returned. The permission verification is based on the service's permissions to determine whether the current interface request method and URL permissions are valid.

Citation Information

Patent Citations

  • Service data real-time monitoring system and method based on Java byte code enhancement technology

    CN110083436A

  • State detection method and system during application starting

    CN115185813A