Software risk resolution method and device based on container, equipment and storage medium

Abstract

The invention relates to a container-based software risk resolution method and device, equipment and a storage medium. When the target software is operated, if the target software is risk software, the trusted terminal operates the mirror image of the target software through the container, and real-time risk monitoring is carried out through the security policy in the operation process of the container; wherein the mirror image and the security policy of the target software are issued by the trusted security management center. According to the scheme, after the risk software is identified, the risk software can be made into the mirror image to be placed in the container to run and isolated from other applications, so that the security threat to the terminal is reduced; and when the target software runs in the container, the running process of the target software can be monitored through the security policy, so that the security and isolation of the running environment of the container are ensured.

Description

Technical Field

[0001] The present application relates to the field of terminal security technology, and in particular to a container-based software risk mitigation method, device, equipment and storage medium. Background Art

[0002] With the maturity of communication technology, the convenience and ease of computing terminals have greatly improved compared to traditional computing terminal devices, and have gradually penetrated into various special industries. The coverage of computing terminals is becoming more and more extensive, but the security status protection technology of computing terminals is relatively backward. At present, if the terminal's software and other key files contain high-risk vulnerabilities, malicious code, or the files are tampered with due to the lack of local security protection, it will cause major security risks to the terminal and may produce serious security accidents. Therefore, how to ensure terminal security is a problem that technicians in this field need to solve. Summary of the invention

[0003] The present application provides a container-based software risk mitigation method, apparatus, device and storage medium to reduce the threat posed by running risky software to a terminal and improve the security of the terminal.

[0004] In a first aspect, the present application provides a container-based software risk mitigation method, the software risk mitigation method is applied to a trusted terminal, and the software risk mitigation method includes:

[0005] Determine the target software to be run;

[0006] Determining whether the target software is risky software;

[0007] If so, the image of the target software is run through a container, and real-time risk monitoring is performed through a security policy during the operation of the container; wherein the image of the target software and the security policy are issued by a trusted security management center.

[0008] Optionally, the image of the target software is run through a container, and real-time risk monitoring is performed through a security policy during the operation of the container, including:

[0009] Running the image of the target software through a container, and during the running process, monitoring the running status of the target software in real time through the security policy;

[0010] If it is monitored that the running state of the target software is an abnormal state, the corresponding processing operation is performed through the disposal strategy in the security strategy.

[0011] Optionally, running the image of the target software through the container, and during the running process, monitoring the running state of the target software in real time through the security policy, includes:

[0012] Loading the image of the target software into the container and performing static measurement according to a trusted policy; the security policy includes the trusted policy and the risk policy;

[0013] Running the image of the target software through the container;

[0014] During operation, dynamic measurement is performed through the trusted strategy, and resource usage, operation of risk points and permission usage are monitored through the risk strategy.

[0015] Optionally, if the running state of the target software is monitored to be an abnormal state, executing a corresponding processing operation through a disposal strategy in the security strategy includes:

[0016] If an abnormality is detected in the static measurement result and / or the dynamic measurement result, a corresponding processing operation is performed according to the untrusted handling strategy in the trusted strategy;

[0017] If an abnormality is detected in at least one of the resource usage, the operation of the risk point, and the permission usage, a corresponding processing operation is performed according to the abnormality handling strategy in the risk strategy.

[0018] Optionally, if it is monitored that the running state of the target software is an abnormal state, the software risk mitigation method further includes:

[0019] A risk report is generated based on the status data and abnormal status of the target software during operation, and the risk report is sent to the trusted security management center so that the trusted security management center can update the security policy based on the risk report.

[0020] Optionally, before determining the target software to be run, the method further includes:

[0021] Send a request to the trusted security management center to download the target software;

[0022] If the target software is risky software, the image of the target software and the corresponding security policy sent by the trusted security management center are received.

[0023] Optionally, the receiving the image of the target software and the corresponding security policy sent by the trusted security management center includes:

[0024] Receiving a risk image package sent by the trusted security management center through a trusted connection channel; wherein the risk image package is generated by the trusted security management center after encrypting the image of the target software and the security policy through a cryptographic mechanism;

[0025] Decrypting the risky image package through the cryptographic mechanism to generate a decrypted image of the target software and a security policy;

[0026] The decrypted target software image and security policy are integrity verified, and after successful verification, the target software image and security policy are stored in a secure storage area.

[0027] In a second aspect, the present application provides a container-based software risk mitigation device, the software risk mitigation device is applied to a trusted terminal, and the software risk mitigation device includes:

[0028] A determination module, used to determine the target software to be run;

[0029] A judgment module is used to judge whether the target software is risky software; if so, trigger the monitoring module;

[0030] The monitoring module is used to run the image of the target software through a container, and perform real-time risk monitoring through a security policy during the operation of the container; wherein the image of the target software and the security policy are issued by the trusted security management center.

[0031] In a third aspect, the present application provides an electronic device, including:

[0032] A processor, a memory, and a computer program stored in the memory and executable on the processor; the processor executes the steps of the software risk mitigation method described above in the present application through the computer program.

[0033] In a fourth aspect, the present application provides a computer storage medium, which stores computer executable instructions; the computer executable instructions are used to execute the steps of the above-mentioned software risk mitigation method of the present application.

[0034] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: when the present application runs the target software, if the target software is risky software, the trusted terminal runs the image of the target software through the container, and performs real-time risk monitoring through the security policy during the operation of the container; wherein the image and security policy of the target software are issued by the trusted security management center. It can be seen that after the present solution identifies the risky software, the risky software can be made into an image and placed in the container for operation, isolated from other applications, and reduce security threats to the terminal; and when the target software is running in the container, the operation process of the target software can be monitored through the security policy, thereby ensuring the security and isolation of the container operation environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0038] Figure 1 A schematic diagram of an overall architecture provided for an embodiment of the present application;

[0039] Figure 2 A flowchart of a container-based software risk mitigation method provided in an embodiment of the present application;

[0040] Figure 3 A schematic diagram of a risky software image download process provided in an embodiment of the present application;

[0041] Figure 4 A schematic diagram of another process flow of a container-based software risk mitigation method provided in an embodiment of the present application;

[0042] Figure 5 A schematic diagram of a dynamic monitoring process of the risk software operation process provided in an embodiment of the present application;

[0043] Figure 6 A security policy management flow chart provided for an embodiment of the present application;

[0044] Figure 7 A schematic diagram of a dynamic monitoring process of risk software running in a container provided in an embodiment of the present application;

[0045] Figure 8 A flowchart of risky software image construction and downloading provided in the embodiment of the present application;

[0046] Fig. 9 A schematic diagram of a system structure provided for an embodiment of the present application;

[0047] Fig.10 A flowchart of risky software image construction and trusted management provided in the embodiment of the present application;

[0048] Fig.11A schematic diagram of the structure of a container-based software risk mitigation device provided in an embodiment of the present application;

[0049] Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0050] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0051] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0052] The present application discloses a container-based software risk mitigation method, device, equipment and storage medium to reduce the threat posed by running risky software to a terminal and improve the security of the terminal.

[0053] See also Figure 1 , Figure 1 A schematic diagram of an overall architecture provided by an embodiment of the present invention; Figure 1 It can be seen that this solution is mainly implemented in the trusted security management center and trusted terminals. Both the trusted security management center and the trusted terminal are trusted computing environments, and the trusted source of all trusted computing is the hardware's trusted root. The trusted security management center mainly implements risk software identification, image building, policy formulation, centralized software management and distribution, etc.; the trusted terminal mainly implements risk software operation, risk software image monitoring, policy execution, status feedback, etc.

[0054] Specifically, when a terminal wants to download risky target software, it needs to identify the risky software and build a container image in the trusted environment of the trusted security management center; download the container image of the risky software to the trusted terminal through a trusted security channel; run the container image of the risky software through a container in the trusted environment of the trusted terminal, and perform dynamic monitoring during the operation. It can be seen that this solution uses trusted computing and container technology to perform trusted monitoring, container isolation, and risk monitoring on risky software applied in trusted terminals, thereby eliminating security risks and protecting the security of the trusted terminal software operating environment and process.

[0055] See also Figure 2 , Figure 2 A flowchart of a container-based software risk mitigation method provided in an embodiment of the present application is provided. The software risk mitigation method is applied to a trusted terminal. The software risk mitigation method includes:

[0056] S101, determining the target software to be run;

[0057] Among them, if the target software to be run by the trusted terminal does not exist locally, it is necessary to send a request to download the target software to the trusted security management center; if the target software is risky software, it receives the image of the target software and the corresponding security policy sent by the trusted security management center.

[0058] In this embodiment, the trusted terminal software is securely managed by centralized downloading of software resources. When a trusted terminal needs a certain software resource, it sends a download request to the trusted security management center. After receiving the download request, the trusted security management center first authenticates the identity and authority of the trusted terminal. If the trusted terminal authentication fails, the software download is rejected; if the trusted terminal authentication passes, it is determined whether there is corresponding software in the resource library; if not, the software source of the target software is obtained. After the software source enters the trusted security management center, the trusted measurement mechanism is used to verify whether the software source is trustworthy; if the software source is trustworthy, the software continues to be identified for risk; if the software source is not risky, it is directly placed in the software resource library; if the software source is risky, the risk of the software source must be evaluated; if the risk of the software source after evaluation is acceptable, the image is constructed through container technology, and a risky software image is made and placed in the risk image library; the problems after the risk assessment are summarized and analyzed to generate a security policy. If there is corresponding software in the resource library, the corresponding software is directly retrieved from the corresponding resource library; if the target software is not risky software, the installation package of the target software is retrieved from the software resource library and sent to the trusted terminal; if the target software is risky software, the image of the target software is obtained from the risk image library, and packaged with the corresponding security policy and sent to the trusted terminal. The software downloaded by the trusted terminal includes software update packages and software installation packages.

[0059] Among them, the security policy is a policy to ensure the safe operation of the target software on the trusted terminal. When the trusted security management center generates the security policy corresponding to the target software, it needs to set it according to the risk assessment of the target software. In this embodiment, the security policy includes: how to build a container strategy, how to monitor the abnormal behavior of the target software image in the container, etc., which are not specifically limited here.

[0060] S102, determining whether the target software is risky software;

[0061] If yes, execute S103; if no, execute S104 to run the target software;

[0062] S103. Run the image of the target software through the container, and perform real-time risk monitoring through the security policy during the operation of the container; wherein the image of the target software and the security policy are issued by a trusted security management center.

[0063] It should be noted that with the widespread use of cloud computing technology, Docker container technology has been widely used in various computing environments. Docker implements a lightweight operating system and containerized operating environment by sharing the kernel with the host machine, and has the characteristics of second-level startup and large-scale scalability. Docker uses its own mechanism to achieve isolation between containers and hosts, and between containers, which to a certain extent ensures the security of the container operating environment. The trusted terminal contains a large amount of important information and data. In order to monitor and protect the security status of the trusted terminal, this application combines the trusted terminal with the Docker container technology to establish an integrated security protection mechanism based on trust, which greatly improves the security of the terminal operating environment.

[0064] Specifically, if the target software is risky software, a container is used to run the target software. When running the target software, a container is first created according to the container creation policy in the security policy, and then the image of the target software is loaded into the container for operation. In addition, during the entire process of container creation, image loading, and image operation, the trusted policy of the security policy is used to ensure the security and trustworthiness of software operation. During the container operation process, the operating status of the target software is monitored in real time according to the risk policy in the security policy. If an abnormality is detected, the emergency response measures in the security policy are taken in a timely manner to block the communication between the container and the host, isolate the risky software, restore the damaged site, and ensure the safety of the host operating environment.

[0065] From the above, it can be seen that when this application runs the target software, if the target software is risky software, the trusted terminal runs the image of the target software through the container, and performs real-time risk monitoring through the security policy during the operation of the container; the image and security policy of the target software are issued by the trusted security management center. It can be seen that after this solution identifies the risky software, the risky software can be made into an image and placed in the container for operation, isolated from other applications, and reduce security threats to the terminal; and when the target software is running in the container, the operation process of the target software can be monitored through the security policy, thereby ensuring the security and isolation of the container operation environment.

[0066] Based on the above method embodiment, in this embodiment, the process of receiving the image of the target software and the corresponding security policy sent by the trusted security management center specifically includes the following steps:

[0067] Receiving a risk image package sent by a trusted security management center through a trusted connection channel; wherein the risk image package is generated by the trusted security management center after encrypting the image and security policy of the target software through a cryptographic mechanism;

[0068] Decrypt the risky image package through a cryptographic mechanism to generate the decrypted image and security policy of the target software;

[0069] The decrypted target software image and security policy are integrity verified, and after successful verification, the target software image and security policy are stored in a secure storage area.

[0070] Specifically, after the trusted security management center finds the image corresponding to the target software from the software image library, it can encrypt the image and the corresponding security policy through a cryptographic mechanism to obtain a risky image package, which can be transmitted to the trusted terminal through a trusted secure channel; after the trusted terminal receives the risky image package, it separates the software image and security policy through decryption, and performs integrity verification. After passing the verification, it is stored in the secure storage area of ​​the trusted terminal.

[0071] See also Figure 3 , is a schematic diagram of a risk software image download process provided by an embodiment of the present application; through Figure 3 It can be seen that the safe download process of risky software images mainly includes the trusted security mechanism of the trusted security management center, the trusted connection mechanism during software transmission, and the trusted security mechanism of the trusted terminal. Specifically, the whole process includes the following steps:

[0072] 1. Risk software creates risk image packages and distributes them in the Trusted Security Management Center

[0073] When a trusted terminal wants to run a target software that is not available locally, it sends a request to download the target software to the trusted security management center. After receiving the download request, the trusted security management center first authenticates the identity and permissions of the trusted terminal. After the authentication is passed, if the target software is risky software, the image of the target software and the security policy are packaged together through a password mechanism to generate a risky image package and send it through a trusted interface. If the target software is not risky software, the security package of the target software is directly sent to the trusted terminal.

[0074] Among them, the cryptographic mechanisms adopted by the trusted security management center include but are not limited to: authentication certificates, signatures, asymmetric encryption, symmetric encryption and other methods.

[0075] 2. Transmit the risk image package in the trusted connection channel between trusted nodes

[0076] In this embodiment, the trusted security management center and the trusted terminal are both trusted nodes. With the support of a trusted computer mechanism, the trusted security management center and the trusted terminal establish a trusted connection channel to ensure secure data transmission between the two.

[0077] 3. Receipt, trusted verification and secure storage of risky software on trusted terminals

[0078] After the risk image package is sent to the trusted terminal through the trusted connection channel, it is decrypted through the cryptographic mechanism and the integrity of the content of the risk software image package is verified. After verification, the image of the risk software and the corresponding security policy are stored in the secure storage area.

[0079] Among them, the cryptographic mechanisms adopted by the trusted terminal include but are not limited to: certificate verification, signature verification, asymmetric decryption, symmetric decryption and other methods, and the security mechanism adopted by the trusted terminal to decrypt the risky software image package must correspond to the security mechanism adopted by the trusted security management center for encryption. For example, if the security mechanism adopted by the trusted security management center for encryption is the authentication certificate, then the security mechanism adopted by the trusted terminal to decrypt the risky software image package is certificate verification, and the security mechanism adopted by the trusted security management center for encryption is asymmetric encryption, then the security mechanism adopted by the trusted terminal to decrypt the risky software image package is asymmetric decryption.

[0080] See also Figure 4 , Figure 4 A flowchart of another method for eliminating software risks based on a container provided in an embodiment of the present application is provided. The method for eliminating software risks is applied to a trusted terminal. The method for eliminating software risks includes:

[0081] S201, determining the target software to be run;

[0082] S202, determining whether the target software is risky software;

[0083] If yes, execute S203; if no, execute S206 to run the target software;

[0084] S203, running the image of the target software through the container, and during the running process, monitoring the running status of the target software in real time through the security policy;

[0085] S204: If the running state of the target software is detected to be abnormal, a corresponding processing operation is performed according to the disposal strategy in the security strategy;

[0086] S205. Generate a risk report based on the state data and abnormal state of the target software during operation, and send the risk report to the trusted security management center so that the trusted security management center can update the security policy based on the risk report.

[0087] In this embodiment, the process of monitoring the running state of the target software and executing the processing operation includes: loading the image of the target software into the container and performing static measurement according to the trusted policy; the security policy includes the trusted policy and the risk policy; running the image of the target software through the container; during the running process, dynamic measurement is performed through the trusted policy, and the resource usage, the running state of the risk point and the permission usage are monitored through the risk policy. If an abnormality is detected in the static measurement result and / or the dynamic measurement result, the corresponding processing operation is performed according to the untrusted disposal policy in the trusted policy; if an abnormality is detected in at least one of the resource usage, the running state of the risk point and the permission usage, the corresponding processing operation is performed according to the abnormal disposal policy in the risk policy.

[0088] It should be noted that the core of this solution is to use the isolation mechanism in the container technology in a trusted environment to eliminate the risks in the operation of risky software. Use the hardware trusted root to establish a trust chain in the trusted terminal and create a trusted and secure operating environment to ensure the security of the image software in the container during operation. Figure 5 , Figure 5 A schematic diagram of a dynamic monitoring process of the risk software operation process provided by the embodiment of the present application; Figure 5 It can be seen that after receiving the risk software running request, the trusted terminal obtains the risk policy issued by the trusted security management center, and uses the trusted control to measure the trustworthiness of the image, and configures the container environment according to the security policy through the container daemon. Among them, this solution configures the container creation process according to the trusted policy and risk policy, including but not limited to access rules and permissions, CPU (Central Processing Unit) and memory usage, data call and storage location, network restrictions, etc.

[0089] When the container is started, the risk image is imported into the container for running, and the components such as processes, file systems and network connections in the container are isolated and run in a trusted environment to ensure the security and isolation within the container. Isolation protection is the core mechanism of container security protection, and its purpose is to ensure the isolation of data and resources between applications in the container and other containers and trusted terminal systems. When the risk software is running on the trusted terminal, risk monitoring and trusted monitoring are used to dynamically monitor the risk image running in the container.

[0090] Among them, risk monitoring refers to focusing on monitoring resource usage, operation of risk points and permission usage according to risk strategies. Resource usage includes: usage of file systems, processes, networks and other resources. In this embodiment, the risk strategy includes but is not limited to the following: implementation methods of network restrictions, controlling communication between containers by setting access rules; limiting internal processes by designing process operation rules; limiting memory resource usage to prevent risk attacks and memory leaks of applications; preventing abnormal CPU usage by limiting CPU usage; reducing the number of child processes and file descriptors by applying resource restrictions; preventing illegal writing to the file system by limiting the file system and resisting risk attacks; preventing attackers from exploiting and obtaining all root permissions of the system by limiting kernel capabilities; and controlling permissions for process and user access to prevent risk behaviors such as overstepping of authority. Trusted monitoring refers to the measurement of the entire life cycle of container establishment, startup, operation, deletion and related data storage according to trusted strategies, including static and dynamic measurements, to protect the safe and reliable operation of the image software in the container.

[0091] If the software in the container is detected to be running abnormally, an alarm will be issued immediately, and emergency measures will be taken through the trusted control mechanism according to the strategy, including but not limited to closing the container network port, terminating the operation of the container process, stopping data call and storage, and on-site recovery. In addition, during the operation of the risk image, it is necessary to generate a risk report for the operation data and abnormal data, and report it to the trusted security management center regularly to update the security policy.

[0092] See also Figure 6 , Figure 6 A security policy management flow chart provided for an embodiment of the present application; Figure 6 It can be seen that the policy mechanism of this solution is jointly completed by the trusted security management center and the trusted terminal, forming a complete closed-loop mechanism. The trusted management security management center detects policy risks, generates security policies, improves and updates policies; the trusted terminal executes policies and feedbacks policy issues, providing data information for the trusted security management center to update and improve policies. The security policy management process mainly includes the following parts:

[0093] 1. Generation of security policies

[0094] Security policies are generated in the trusted security management center. When a new software source enters the trusted security management center, it is processed for trust and risk analysis, and a security policy is generated in combination with the software source information. Among them, security policies include trusted policies and risk policies, which are managed and maintained by trusted mechanisms and risk mechanisms respectively. Trusted policies include but are not limited to: trusted management policies, configuration policies, trusted baseline values, measurement policies, verification policies, access control policies, cryptographic service policies, untrusted disposal policies, etc.; risk policies include but are not limited to: risk management policies, container configuration policies, container resource usage settings, permission configuration, interface control policies, risk point targeted policies, and exception disposal policies.

[0095] 2. Download and storage of security policies

[0096] Security policies are synchronized to trusted terminals when risky software images are downloaded; when security policies are updated but software images do not need to be updated, security policies can be sent to trusted terminals separately and updated synchronously in the policy library. Security policies are stored in secure storage areas in both the trusted security management center and trusted terminals.

[0097] 3. Execution of security policies

[0098] Security policies are executed in trusted terminals, and risky software is dynamically monitored while running in containers. If any abnormality is found, policy handling is immediately carried out through control mechanisms.

[0099] 4. Security policy update

[0100] Security policy updates come from the software source and the report information fed back by the trusted terminal. The trusted security management center obtains policy information updates from the software source, and can also update policy information after evaluating the trusted reports and risk reports uploaded by the trusted terminal.

[0101] See also Figure 7 , Figure 7 A schematic diagram of a dynamic monitoring process of risk software running in a container provided in an embodiment of the present application; Figure 7 It can be seen that the monitoring process of risky software during operation on a trusted terminal includes the following steps:

[0102] 1. The trusted terminal system receives a request to run the software and determines whether it is a marked risky software. If it is a risky software, it runs in a container. If there is no container image locally, a download request is sent to the trusted security management center.

[0103] 2. After receiving the risky software image and security policy issued by the Trusted Security Management Center, create a container, load the image, and run the image according to the security policy. The whole process uses a trusted measurement mechanism to ensure the security and reliability of software operation. The trusted measurement mechanism includes a static measurement process before operation and a dynamic measurement process during container operation. During container operation, real-time risk monitoring is performed according to the risk policy.

[0104] 3. During the static measurement and dynamic measurement process, if the measurement results are detected to be unreliable, they will be processed according to the trusted disposal strategy in the trusted strategy, and the data will be summarized and added to the report; during the risk monitoring process, if an anomaly is detected, it will be processed according to the risk disposal strategy in the risk strategy, and the data will be summarized and added to the report. After the container runs, the running data will also be summarized and added to the report, and the final generated report will be uploaded to the trusted security management center.

[0105] In summary, in this solution, after the trusted security management center identifies risks, generates policies, and builds container images for the target software to be downloaded, the trusted terminal downloads the risky software image and security policy through the trusted security channel and runs it in the container. The running process of the risky software image is dynamically monitored and reports are uploaded through the security policy. In this way, the running process of the risky software can be isolated from other applications, and the threat of risky software to the terminal can be reduced under the dual protection mechanism of trusted computing and container technology.

[0106] See also Figure 8 , Figure 8 The risk software image construction and downloading flow chart provided in the embodiment of the present application; through Figure 8 It can be seen that the risky software image building process includes the following:

[0107] 1.1. After the software source required by the trusted terminal enters the trusted security management center, it is verified through the trusted measurement mechanism to determine whether the software source is trustworthy;

[0108] 1.2. If the software source is trustworthy, a trust policy is generated and risk identification of the software continues; if the software source is risk-free, it is directly placed in the software resource library;

[0109] 1.3. If there are risks in the software source, the risk of the software source must be assessed; if the risk of the software source after assessment is acceptable, the image is built through container technology, and the risk software image is made into a risk image library;

[0110] 1.4. Summarize and analyze the issues after risk assessment to generate risk strategies.

[0111] The risky software image download process includes the following:

[0112] 2.1. The trusted terminal sends a download request for the required software to the trusted security management center;

[0113] 2.2. After receiving the download request, the trusted security management center determines whether the trusted terminal has the authority to download the software;

[0114] 2.3. If the permission review fails, the software download will be rejected; if the permission review passes, the Trusted Security Management Center will determine whether the software to be downloaded is risky software;

[0115] 2.4. If the software to be downloaded is not risky software but safe software, the safe software and trusted policies are obtained from the software resource library, and encrypted through the password mechanism to generate a safe software installation package and send it to the trusted terminal;

[0116] 2.5. If the software to be downloaded is risky software, the risky software image of the software will be retrieved from the risky image library and encrypted with the risk strategy and trusted strategy to form a risky software package;

[0117] 2.6. If the trusted terminal receives a secure software installation package, it will decrypt the secure software installation package and store the secure software and trusted policy in a secure storage area; if the trusted terminal receives a risky software package, it will decrypt the risky software package and store the image of the risky software and security policy in a secure storage area.

[0118] From the above, it can be seen that this application is based on the trusted computing architecture. The software of the trusted terminal is uniformly managed, authenticated and issued by the trusted security management center to ensure the security and reliability of the source of the trusted terminal software. The software of the trusted terminal is identified for risk in the trusted security management center, and a risk strategy is generated. For high-risk software, container images are built through container technology, and the images of risky software are run through containers to isolate them from other applications, reducing security threats to the terminal; and when the target software is running in the container, the running process of the target software can be monitored through the security policy, thereby ensuring the security and isolation of the container operating environment.

[0119] See also Fig. 9 , Fig. 9 A schematic diagram of a system structure provided by an embodiment of the present invention; Fig. 9 It can be seen that this system mainly includes two parts: the trusted security management center and the trusted terminal. The trusted security management center is a platform for security analysis, risk strategy configuration, software distribution, trusted management, and real-time monitoring of trusted terminals. The trusted terminal is a computing node in the trusted computing mechanism, a terminal used by users, and an object of security protection. Here, the trusted security management center and the trusted terminal are described in detail.

[0120] 1. The trusted security management center mainly includes: risk analysis subsystem, risk strategy subsystem, risk report management subsystem, container management subsystem, software resource library, risk image library, and trusted cryptographic subsystem and trusted management subsystem. Among them:

[0121] The risk analysis subsystem is a subsystem that manages the source of software used by trusted terminals. It is responsible for software risk identification, problem analysis, and whether to use container technology to eliminate risks.

[0122] The risk strategy subsystem is a subsystem for analyzing and formulating risk strategies. It mainly formulates management and control strategies for risky software based on information about the source of the software, risk analysis issues, content of risk report feedback, and trusted management strategies.

[0123] The risk report management subsystem is a subsystem that connects to the trusted terminal to upload risk reports and is responsible for receiving risk reports and parsing their contents.

[0124] The container management subsystem is the application subsystem of container technology in the trusted security management center. It is responsible for image building and updating, container repository management, image distribution, and comprehensive container management.

[0125] The trusted cryptographic subsystem is a service subsystem of the cryptographic mechanism, responsible for cryptographic support tasks such as trusted computing measurement, data encryption and transmission.

[0126] The trusted management subsystem is a platform for unified management and services of trusted terminals, responsible for trusted terminal identity authentication, status management, policy management, trusted control and other trust-related tasks.

[0127] The software image library stores risk-free terminal software that has been authenticated as trustworthy; the risk image library stores terminal software images that have been analyzed for security risks and have also been authenticated as trustworthy. Only software that has been authenticated as trustworthy can be distributed to, installed and run in, trusted terminals.

[0128] 2. Trusted terminals mainly include: risk monitoring module, risk reporting module, container module, risk image, trusted related trusted application module, trusted control module and trusted password module, etc. Among them:

[0129] The risk monitoring module is a monitoring module for the running process of risk software in the container. It is mainly responsible for real-time data collection, data interface monitoring, and abnormal behavior alarm during the operation of the risk module.

[0130] The risk reporting module records the status data of the risk software during its operation and is responsible for collecting and collating data on the operating status of the risk software.

[0131] The container module is the application of container technology in trusted terminals. It is responsible for container creation, image operation and control, container-related configuration and management, etc.

[0132] The trusted application module, trusted control module and trusted cryptographic module are the protection modules of the trusted computing mechanism, responsible for ensuring the security and reliability of the operating environment of the trusted terminal.

[0133] See also Fig.10 , Fig.10 The risk software image construction and trusted management flow chart based on the system structure provided by the embodiment of the present invention. Fig.10 It can be seen that

[0134] When the target software required by the terminal enters the trusted security management center, the risk analysis subsystem identifies risks and performs security testing on the target software, and sends the analysis results to the risk strategy subsystem for policy formulation; software without risks after testing is directly stored in the software resource library, and software that can withstand risks after testing is containerized by the container management subsystem to generate risky software images, which are stored in the risk image library, and software that cannot withstand risks is locally isolated or deleted; all software that enters the library and waits for download must be locally authenticated by the trusted management subsystem before it can be sent to the terminal.

[0135] Each trusted terminal that needs to download the target software needs to send a download request to the trusted security management center. After receiving the download request, the trusted management subsystem of the trusted security management center determines the download permission of the terminal; if the terminal has download permission, it determines whether the downloaded software is risky software; if it is risky software, the corresponding software is called out from the risky software image library, and the corresponding trusted policy and risk policy are made into a risk image package and sent to the terminal; after the trusted terminal installs and runs the risky software, a risk report is generated on the terminal and uploaded to the trusted security management center for use in updating the risk policy. The trusted terminal runs the image of the risky software through the container, isolating it from other applications to reduce security threats to the terminal; and when the target software is running in the container, the target software's running process can be monitored through the security policy, thereby ensuring the security and isolation of the container's operating environment.

[0136] See also Fig.11 , Fig.11 A container-based software risk mitigation device is provided in an embodiment of the present application. The software risk mitigation device is applied to a trusted terminal. The device specifically includes:

[0137] A determination module 11, used to determine the target software to be run;

[0138] The judging module 12 is used to judge whether the target software is risky software; if so, the monitoring module is triggered;

[0139] The monitoring module 13 is used to run the image of the target software through a container, and perform real-time risk monitoring through a security policy during the operation of the container; wherein the image of the target software and the security policy are issued by the trusted security management center.

[0140] As an optional embodiment, the monitoring module includes:

[0141] A monitoring unit, configured to run the image of the target software through a container, and during the running process, monitor the running state of the target software in real time through the security policy; if the running state of the target software is detected to be abnormal, the processing unit is triggered;

[0142] The processing unit is used to execute corresponding processing operations through the handling strategy in the security strategy.

[0143] As an optional embodiment, the monitoring unit includes:

[0144] A loading subunit, used to load the image of the target software into the container;

[0145] A static measurement subunit, used for performing static measurement according to a trusted policy; the security policy includes the trusted policy and the risk policy;

[0146] A running subunit, used to run the image of the target software through the container;

[0147] A dynamic measurement subunit, used for performing dynamic measurement through the trusted strategy during operation;

[0148] The risk monitoring subunit is used to monitor the resource usage, the operation of risk points and the use of permissions through the risk strategy during operation.

[0149] As an optional embodiment, the processing unit is specifically configured to:

[0150] If an abnormality is detected in the static measurement results and / or the dynamic measurement results, the corresponding processing operation is performed according to the untrusted handling strategy in the trusted strategy; if an abnormality is detected in at least one of the resource usage, the operation of the risk point and the permission usage, the corresponding processing operation is performed according to the exception handling strategy in the risk strategy.

[0151] As an optional embodiment, the monitoring module further includes:

[0152] A report generating unit, used for generating a risk report according to the state data and abnormal state of the target software during operation;

[0153] A report sending unit is used to send the risk report to the trusted security management center so that the trusted security management center updates the security policy according to the risk report.

[0154] As an optional embodiment, it also includes:

[0155] A sending module, used for sending a request to download the target software to the trusted security management center;

[0156] The receiving module is used to receive the image of the target software and the corresponding security policy sent by the trusted security management center when the target software is risky software.

[0157] As an optional embodiment, the receiving module includes:

[0158] A receiving unit, configured to receive a risk image package sent by the trusted security management center through a trusted connection channel; wherein the risk image package is generated by the trusted security management center after encrypting the image of the target software and the security policy through a cryptographic mechanism;

[0159] A decryption unit, used to decrypt the risk image package through the cryptographic mechanism to generate a decrypted image of the target software and a security policy;

[0160] A verification unit, used to verify the integrity of the decrypted target software image and security policy, and trigger the storage unit after successful verification;

[0161] The storage unit is used to store the image and security policy of the target software in a secure storage area.

[0162] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0163] See also Fig.12 , Fig.12 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application, the electronic device specifically includes:

[0164] A processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. The processor 21 executes the steps of the software risk mitigation method described in any of the above method embodiments through the computer program.

[0165] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0166] The memory 22 may include one or more computer-readable storage media, which may be non-transitory. The memory 22 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 22 is at least used to store the following computer program 221, wherein, after the computer program is loaded and executed by the processor 21, it can implement the relevant steps in the software risk mitigation method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 22 may also include an operating system 222 and data 223, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 222 may include Windows, Unix, Linux, etc.

[0167] In some embodiments, the electronic device may further include a display screen 23 , an input / output interface 24 , a communication interface 25 , a sensor 26 , a power source 27 , and a communication bus 28 .

[0168] certainly, Fig.12 The structure of the electronic device shown does not constitute a limitation on the electronic device in the embodiments of the present application. In actual applications, the electronic device may include Fig.12 More or fewer components than shown, or combinations of certain components.

[0169] In another exemplary embodiment, a computer storage medium is also provided, and when the program instructions are executed by a processor, the steps of the software risk mitigation method described in any of the above method embodiments are implemented. The storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and other media that can store program codes.

[0170] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0171] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0172] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be 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 the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A container-based software risk mitigation method, characterized in that: The software risk mitigation method is applied to a trusted terminal, and the software risk mitigation method includes: Determine the target software to be run; Determining whether the target software is risky software; If so, the image of the target software is run through a container, and real-time risk monitoring is performed through a security policy during the operation of the container; wherein the image of the target software and the security policy are issued by a trusted security management center.

2. The software risk elimination method according to claim 1, characterized in that: The image of the target software is run through a container, and real-time risk monitoring is performed through a security policy during the operation of the container, including: Running the image of the target software through a container, and during the running process, monitoring the running status of the target software in real time through the security policy; If it is monitored that the running state of the target software is an abnormal state, the corresponding processing operation is performed through the disposal strategy in the security strategy.

3. The software risk elimination method according to claim 2, characterized in that: Running the image of the target software through the container, and during the running process, monitoring the running status of the target software in real time through the security policy, including: Loading the image of the target software into the container and performing static measurement according to a trusted policy; the security policy includes the trusted policy and the risk policy; Running the image of the target software through the container; During operation, dynamic measurement is performed through the trusted strategy, and resource usage, operation of risk points and permission usage are monitored through the risk strategy.

4. The software risk elimination method according to claim 2, characterized in that: If the running state of the target software is detected to be abnormal, the corresponding processing operation is performed through the disposal strategy in the security strategy, including: If an abnormality is detected in the static measurement result and / or the dynamic measurement result, a corresponding processing operation is performed according to the untrusted handling strategy in the trusted strategy; If an abnormality is detected in at least one of the resource usage, the operation of the risk point, and the permission usage, a corresponding processing operation is performed according to the abnormality handling strategy in the risk strategy.

5. The software risk elimination method according to claim 2, characterized in that: If the running state of the target software is monitored to be an abnormal state, the software risk mitigation method further includes: A risk report is generated based on the status data and abnormal status of the target software during operation, and the risk report is sent to the trusted security management center so that the trusted security management center can update the security policy based on the risk report.

6. The software risk elimination method according to any one of claims 1 to 5, characterized in that: Before determining the target software to be run, the method further includes: Send a request to the trusted security management center to download the target software; If the target software is risky software, the image of the target software and the corresponding security policy sent by the trusted security management center are received.

7. The software risk elimination method according to claim 6, characterized in that: The receiving the image of the target software and the corresponding security policy sent by the trusted security management center includes: Receiving a risk image package sent by the trusted security management center through a trusted connection channel; wherein the risk image package is generated by the trusted security management center after encrypting the image of the target software and the security policy through a cryptographic mechanism; Decrypting the risky image package through the cryptographic mechanism to generate a decrypted image of the target software and a security policy; The decrypted target software image and security policy are integrity verified, and after successful verification, the target software image and security policy are stored in a secure storage area.

8. A container-based software risk mitigation device, characterized in that: The software risk elimination device is applied to a trusted terminal, and the software risk elimination device comprises: A determination module, used to determine the target software to be run; A judgment module is used to judge whether the target software is risky software; if so, trigger the monitoring module; The monitoring module is used to run the image of the target software through a container, and perform real-time risk monitoring through a security policy during the operation of the container; wherein the image of the target software and the security policy are issued by the trusted security management center.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor; the processor executes the steps of the software risk mitigation method described in any one of claims 1 to 7 of the present application through the computer program.

10. A computer storage medium, characterized in that: The computer storage medium stores computer executable instructions; the computer executable instructions are used to execute the steps of the software risk mitigation method described in any one of claims 1 to 7 of the present application.

Images