Application management system and method based on the idea of mimicry defense

Abstract

The application provides an application management system and method based on the idea of quasi-state defense, comprising: an application initialization deployment module: splitting an application into multiple service components, and forming multiple heterogeneous service component pools and application groups based on the multiple service components; and a scheduling module: providing scheduling services for the application in an initialization creation stage, an application abnormal attack stage, a long-term running state of the application, and an application common mode attack stage based on the multiple heterogeneous service component pools and the application groups.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, in particular to an application management system and method based on the idea of quasi-state defense. BACKGROUND

[0002] Quasi-state defense is an important representative of security technology in cyberspace. After the application introduces the quasi-state idea, it can effectively avoid the application being hacked by hackers due to design defects, unknown vulnerabilities, backdoors, Trojan viruses, etc., and convert "passive" defense into "active" defense.

[0003] The existing quasi-state application management platform mainly designs and implements the resource scheduling function required by the negative feedback scheduling module in the quasi-state DHR architecture and the creation of the application heterogeneous execution body. It lacks consideration of dynamicity. At the same time, the existing quasi-state application management platform mainly considers traditional applications-single architecture, which has poor scalability and is difficult to adapt to front-end and back-end separation architecture, micro-service architecture, and other multi-architecture.

[0004] Patent document CN112153024A (application number 202010955694.X) discloses a quasi-state defense system based on a SaaS platform, including a cloud management module, an image management module, a quasi-state arrangement module, an execution body management module, a quasi-state distribution module, and a quasi-state negative feedback module. The execution body management module provided by the patent is only suitable for quasi-state application creation in a single architecture mode. The quasi-state arrangement module and the quasi-state negative feedback module only support resource initialization scheduling during creation, sending user requests to each execution body through the distribution module, and sending the execution result consistency decision result to the negative feedback module for processing. The application heterogeneous service / component pool management module and the application group module in the present application are suitable for quasi-state applications in different architecture modes. The scheduling module includes application initialization scheduling, negative feedback scheduling, timing scheduling, and forced scheduling. SUMMARY

[0005] In view of the defects in the prior art, the purpose of the present application is to provide an application management system and method based on the idea of quasi-state defense.

[0006] According to the application management system based on the idea of quasi-state defense provided by the present application, it comprises:

[0007] The application initialization deployment module splits the application into multiple service components, and forms multiple heterogeneous service component pools and application groups based on the multiple service components.

[0008] The scheduling module provides scheduling services for the application in the initialization creation stage, the application suffers from abnormal attack stage, the application long-term running state, and the application suffers from common mode attack stage based on the multiple heterogeneous service component pools and application groups.

[0009] Preferably, the application initialization deployment module comprises:

[0010] Module M1.1: initialize the heterogeneous layer, the number of in-use application service components N, the number of standby application service components M, the maximum service component life span Survival, the timing scheduling period Interval, and the number of checks Y in the heterogeneous service component pool;

[0011] Module M1.2: split the application based on the service components to be paratized in the application to obtain a plurality of service components to be paratized;

[0012] Module M1.3: group a plurality of service components into a heterogeneous service component pool based on the same type of service components in different environments;

[0013] Module M1.4: group the plurality of different service components into a heterogeneous application group based on the adaptation of different service components into an application capable of running.

[0014] Preferably, the scheduling module comprises an initialization scheduling module, a negative feedback scheduling module, a timing scheduling module, and a forced scheduling module.

[0015] The initialization scheduling module is to select N+M application service components for each of the X heterogeneous service component pools of the application according to the heterogeneous maximization principle when the application is created; wherein N represents the number of in-use application service components, and M represents the number of standby application service components.

[0016] The negative feedback scheduling module is to initiate negative feedback scheduling to the scheduling module when the scheduling log monitoring module identifies an abnormal decision, to clean and restore the in-use application service components and the standby application service components determined by the initialization scheduling, and to form a new round of existing in-use application service components and standby application service components.

[0017] The timing scheduling module is to perform timing scheduling once every Interval time; when the timing scheduling is initiated, the existing in-use application service components and standby application service components are cleaned and restored to form a new round of in-use application service components and standby application service components.

[0018] The forced scheduling module is to immediately force the current service to be offline when the scheduling log monitoring module monitors the negative feedback scheduling result and identifies that an in-use service is abnormal, to realize the perception and processing of abnormal threats.

[0019] Preferably, the negative feedback scheduling module comprises: judging whether the abnormal service component is the only architecture in the application heterogeneous service component pool; when the architecture is unique, selecting a service component with the same architecture as the abnormal service component from the standby application heterogeneous service component pool to calculate the other level heterogeneity, and the service component with the largest heterogeneity is selected as the new active service component; at this time, the new standby service component in the application application heterogeneous service component pool is also the same architecture service component, which needs to meet the maximum heterogeneity of other levels except the architecture layer of the current active and standby service components.

[0020] If the architecture is not unique, select an execution body with different architecture from the standby to calculate the other level heterogeneity, and the service component with the largest heterogeneity is selected as the new active service component; the new standby service component should also meet the different architecture of the abnormal service component, and the maximum heterogeneity of other levels except the architecture layer of the current active and standby service components.

[0021] Preferably, the timing scheduling module comprises: when there is a single service component in the active application heterogeneous service component pool whose running time exceeds the allowed maximum survival time, the service component is selected as the service component to be scheduled this time; when there are multiple service components whose running time exceeds the allowed maximum survival time, the service component with the longest running time is selected as the service component to be scheduled this time; when there is no service component whose running time exceeds the allowed maximum survival time, the load information of each active service component is calculated to determine the service component to be scheduled this time; after the timing scheduling module confirms the service component to be scheduled, the same architecture service component as the service component to be scheduled is selected from the standby application heterogeneous service component pool to calculate the other level heterogeneity, and the service component with the largest heterogeneity is selected as the new active service component; at this time, the new standby service component needs to meet the same architecture, and the maximum heterogeneity of other levels except the architecture layer of the current active and standby service components.

[0022] Preferably, the forced scheduling module is the scheduling log monitoring module, which needs to perform Y times of checking when the negative feedback scheduling and timing scheduling signals are monitored. If the same service component with the same serial number is scheduled for Y times, any one of the other N-1 service components is selected as the service component to be scheduled this time.

[0023] Preferably, the arbitration log monitoring module also comprises: monitoring the arbitration log including distribution, database and redis arbitration log, collecting and monitoring the arbitration log, and realizing the safe tracking of the application running process and result.

[0024] Preferably, the scheduling log monitoring module monitors initialization scheduling, negative feedback scheduling, timing scheduling and forced scheduling, traces the triggering time and type of each service component through scheduling log monitoring, collects and monitors each type of scheduling log, and realizes safe tracking of the life cycle of the application.

[0025] According to the application, an application management method based on the mimicry defense idea is provided, which comprises:

[0026] Step S1: The application initialization deployment module splits the application into multiple service components, and forms multiple heterogeneous service component pools and application groups based on the multiple service components;

[0027] Step S2: The scheduling module provides scheduling services for the initialization creation stage, the application suffers from abnormal attack stage, the long-term running state of the application and the application suffers from common mode attack stage of the application based on the multiple heterogeneous service component pools and application groups.

[0028] Preferably, the step S1 comprises:

[0029] Step S1.1: initializing the heterogeneous layer, the number N of in-use application service components, the number M of standby application service components, the maximum life cycle of the service component Survival, the timing scheduling period Interval and the number Y of checks in the heterogeneous service component pool;

[0030] Step S1.2: splitting the application based on the service components to be mimicked in the application to obtain a plurality of service components to be mimicked;

[0031] Step S1.3: grouping the multiple service components into a heterogeneous service component pool based on the same type of service components in different environments;

[0032] Step S1.4: grouping the multiple different service components into a heterogeneous application group based on different service components adapted into an application capable of running;

[0033] The scheduling module comprises an initialization scheduling module, a negative feedback scheduling module, a timing scheduling module and a forced scheduling module;

[0034] The initialization scheduling module selects N+M application service components for each of the X heterogeneous service component pools of the application according to the principle of maximum heterogeneity when creating the application; wherein N represents the number of in-use application service components, and M represents the number of standby application service components;

[0035] The negative feedback scheduling module initiates negative feedback scheduling to the scheduling module when the scheduling log monitoring module identifies an exception decision, cleans and recovers the in-use application service components and standby application service components determined by the initialization scheduling, and forms a new round of existing in-use application service components and standby application service components.

[0036] The timing scheduling module performs a timing scheduling every Interval time; when the timing scheduling is initiated, the existing application service components in use and the backup application service components are cleaned and restored to form a new round of application service components in use and the backup application service components;

[0037] The forced scheduling module is when the scheduling log monitoring module monitors the negative feedback scheduling results. When it identifies that a certain service in use has an abnormality, it immediately forces the current service to be offline, thereby realizing the perception and processing of abnormal threats.

[0038] Compared with the prior art, the present invention has the following beneficial effects:

[0039] 1. The present invention constructs an executor pool of N active executors + M standby executors through initialization scheduling, thereby realizing heterogeneous maximum scheduling and dynamic and rapid switching of executors during cleaning and recovery. At the same time, by splitting the application into multiple services / components, the services / components of the application can be arbitrarily mimicked. The services / components required by each application are associated as a group, and when performing cleaning and recovery, the application can be quickly put online and the user's waiting response time can be reduced. The combination of pool and group can be applied to mimic applications under any architectural model, thereby reducing the development cost of application mimicry transformation and increasing the versatility and universality of the platform.

[0040] 2. The present invention is more suitable for application transformation version iteration through the mimicry transformation of application services / components. Except for components such as database, Redis, and ElasiticSearch, the remaining services / components can be put on the platform after mimicry transformation. The platform does not need secondary development, which greatly saves costs.

[0041] 3. Application architectures have evolved from monolithic architectures, front-end and back-end separation, to microservices. Existing application management platforms often cannot manage these three application architectures in a unified manner, let alone support applications with multiple architectures. Application management platforms based on mimicry defense not only support mimicry application management with multiple architectures, such as monolithic architectures, front-end and back-end separation, and microservices, but also add a new forced scheduling function in the scheduling module to prevent common mode attacks, improving the inherent security of applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments with reference to the following drawings:

[0043] Figure 1 A diagram showing the relationship between heterogeneous application service / component pools and application groups.

[0044] Figure 2A schematic diagram of the relationship between the application heterogeneous service / component pool and the application group. DETAILED DESCRIPTION

[0045] The application will be described in detail below with specific embodiments. The following examples will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be noted that for those skilled in the art, without departing from the concept of the application, a number of changes and improvements can be made. These are within the scope of the present application.

[0046] Example 1

[0047] The present application is directed to the problems and deficiencies of the prior art, based on the consideration of the security tracking of the DHR defense, process and result of the application, standardized deployment, convenient management, an application management system and method based on the idea of quasi-state defense are proposed. The applicable quasi-state application architecture includes monolithic architecture, front-end and back-end separation, micro-service and other multi-architecture.

[0048] The application management system based on the idea of quasi-state defense, as shown in Figures 1-2 The application management system based on the idea of quasi-state defense, as shown in

[0049] The application heterogeneous service / component pool module: unlike the ordinary heterogeneous executor pool, the application is split into services / components in the present application, which can well meet the application under various architecture modes, and at the same time, any service / component in the application can be quasi-state transformed, for example, if X services / components in the application need to be quasi-state transformed, then the application has X application heterogeneous service / component pools. When the user uses the management platform to create an application, the number of active application services / components in the pool (denoted as N) and the number of standby application services / components (denoted as M) are customized according to the needs, N is an odd number, and M=N-1. When the application is created, the scheduling module will trigger the initialization scheduling, and during the initialization scheduling, the total number of each application heterogeneous service / component pool of the application is always N+M.

[0050] The application group module: Except for the monolithic architecture model, applications in any architecture will use multiple containers during deployment, and the containers will have corresponding IP and port associations. While heterogeneous application service / component pools manage multiple pools vertically, application groups horizontally associate applications across multiple pools. This allows for rapid decommissioning of a suite of applications in the event of a malicious attack, preventing distribution anomalies caused by applications being unable to find their "family" and preventing users from accessing them properly.

[0051] The scheduling module provides scheduling services for applications during the initial creation phase, when applications are exposed to abnormal attacks, when applications are in long-term operation, and when applications are exposed to common attacks. This module implements DHR defense for applications, ensuring comprehensive security from initialization to actual use. The scheduling module is specifically divided into initialization scheduling, negative feedback scheduling, scheduled scheduling, and forced scheduling. Initialization scheduling is independent of other scheduling mechanisms and only starts after application initialization and deployment. Negative feedback scheduling and scheduled scheduling require a rule-based check before startup to determine whether forced scheduling should be prioritized. Users can enter parameters on the platform interface based on their needs: the maximum lifetime allowed for application services / components, the scheduled scheduling interval (set the scheduled scheduling interval to perform service / component online and offline processing every interval time to achieve application dynamics; set the maximum lifetime survival to prioritize offline processing of services / components whose survival period exceeds the survival limit during scheduled scheduling, ensuring application activity and high availability). Initialization scheduling: When creating an application, based on the principle of maximizing heterogeneity, N+M service components are selected for each of the X heterogeneous service / component pools of the application. Negative feedback scheduling: When the scheduling log monitoring module identifies an anomaly, it initiates a negative feedback scheduling to the scheduling module. Scheduled scheduling: Scheduled online and offline services / components are updated to achieve dynamic application functionality and increase attack resistance. Forced scheduling: The scheduling log monitoring module monitors negative feedback scheduling results. When an anomaly is detected in a service / component in use, it is immediately forced offline to detect and address the threat.

[0052] It also includes a decision log monitoring module: The platform supports monitoring decision logs for distribution, databases, and Redis. The platform is also scalable. If new components with decision log output are developed later, as long as the interface is unified, the platform can support monitoring and display without the need for secondary development. By collecting and monitoring decision logs, the application operation process and results can be securely tracked.

[0053] The scheduling log monitoring module: scheduling log monitoring includes initialization scheduling, negative feedback scheduling, timing scheduling and forced scheduling, and users and platform administrators can trace back to the triggering time and type of each service / component through scheduling log monitoring. Through the collection and monitoring of various types of scheduling logs, the safety tracking of the life cycle of the application is realized.

[0054] The application management method based on the mimetic defense idea comprises:

[0055] Step 1: parameter preprocessing. When creating an application on the platform, the user needs to input the user's attention to the heterogeneous layer (CPU default, OS, WEB, JDK, etc.), the number N of in-use applications in the heterogeneous service / component pool, the number M of in-use applications in the heterogeneous service / component pool, the maximum survival time of the application service / component, the timing scheduling period Interval, and the number of checks Y.

[0056] Step 2: initialization scheduling. Each scheduling is performed on one (application) group service / component, that is, a specified service / component in the application heterogeneous service / component pool is used as the scheduling service / component, and based on the user's attention to the heterogeneous layer, initialization scheduling is performed on all services / components in the application group where the scheduling service / component is located.

[0057] The step 2 comprises the following steps:

[0058] Step 2.1: after the platform creates an application and receives the initialization scheduling request from the management, query the database to find out how many heterogeneous characteristic values each heterogeneous layer has, assuming that the number of each heterogeneous layer is m1, m2, m3, …, then the heterogeneous groups H = h1*h2*h3… can be formed. The scheduling first focuses on the CPU layer, taking x86 and arm as examples. In each application heterogeneous service / component pool, there are usually (N+1) / 2 x86 and (N-1) / 2 arm, and in the heterogeneous group M, there are H / 2 x86 heterogeneous groups and H / 2 arm heterogeneous groups. The x86 heterogeneous group can select a combination of According to the heterogeneity, (N+1) / 2 x86 with the maximum heterogeneity are selected; the arm heterogeneous group can select a combination of According to the heterogeneity, (N-1) / 2 arms with the maximum heterogeneity of the (N+1) / 2 x86 obtained just now are determined to be in-use application services / components;

[0059] Step 2.2: the x86 heterogeneous group can select a combination of According to the heterogeneity, M / 2 x86 with the maximum heterogeneity of the (N+1) / 2 x86 obtained just now are selected; the arm heterogeneous group can select a combination of According to the heterogeneity selection, M / 2 arms with the maximum heterogeneity degree are selected from the (N-1) / 2 arms obtained previously, to determine the standby application service / component.

[0060] Step 3: Negative feedback scheduling. When the abnormality decision is received, the scheduling log monitoring module performs cleaning and recovery on the services / components in the initialized active and standby application groups to form a new round of active and standby application groups.

[0061] The step 3 includes the following steps:

[0062] Step 3.1: Determine whether the abnormal service / component is the only architecture in the application heterogeneity service / component pool (active). If the architecture is unique, select the service / component with the same architecture as the abnormal service / component from the application heterogeneity service / component pool (standby) to perform other-level heterogeneity calculation, and the service / component with the maximum heterogeneity degree is selected as the new active service / component. At this time, the new standby service / component in the application heterogeneity service / component pool is also a service / component with the same architecture, which needs to satisfy the maximum heterogeneity with the current active and standby service / components except the architecture layer.

[0063] Step 3.2: If the architecture is not unique, select the execution body with a different architecture from the abnormal service / component from the standby to perform other-level heterogeneity calculation, and the service / component with the maximum heterogeneity degree is selected as the new active service / component. At this time, the new standby service / component should also satisfy the different architecture with the abnormal service / component, and satisfy the maximum heterogeneity with the current active and standby service / components except the architecture layer.

[0064] Step 4: Timing scheduling. The platform performs timing scheduling every Interval time. When the timing scheduling is initiated, the services / components in the existing active and standby application groups are cleaned and recovered to form a new round of active and standby application groups.

[0065] The step 4 includes the following steps:

[0066] Step 4.1: If there is a single service / component in the application heterogeneity service / component pool (active) whose running time exceeds the allowed maximum life cycle Survival, the service / component is selected as the service / component to be scheduled this time;

[0067] Step 4.2: If there are multiple services / components whose running time exceeds the allowed maximum life cycle Survival, the service / component with the longest running time is selected as the service / component to be scheduled this time;

[0068] Step 4.3: If there is no service / component whose running time exceeds the allowed maximum life cycle Survival, the load information of each active service / component is calculated according to the weight formula to determine the service / component to be scheduled this time;

[0069] Step 4.4: After the scheduling module confirms the service / component to be scheduled, the service / component with the same architecture as the service / component to be scheduled is selected from the application heterogeneous service / component pool (standby) to calculate the other level heterogeneity, and the service / component with the largest heterogeneity is selected as the new active service / component. At this time, the new standby service / component needs to meet the same architecture, and the other level heterogeneity of the current active and standby service / component is maximized.

[0070] Step 5: Forced scheduling. In order to prevent common mode attacks, the scheduling log needs to be checked Y times when negative feedback scheduling and timing scheduling signals are monitored. If the same service / component is scheduled for Y times, any one of the other N-1 services / components is selected as the service / component to be scheduled this time, and the scheduling principle remains the same as timing scheduling.

[0071] Those skilled in the art know that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the same program can be realized by logically programming the method steps to form a logic gate, a switch, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing methods and structures within the hardware component.

[0072] The specific embodiments of the present application are described above. It should be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which do not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily without conflict.

Claims

1. An application management system based on the concept of mimicry defense, characterized in that: include: Application initialization and deployment module: splits the application into multiple service components, and then composes multiple heterogeneous service component pools and application groups based on these multiple service components; Scheduling module: Based on multiple heterogeneous service component pools and application groups, it provides scheduling services for applications during initial creation, when applications are attacked by abnormalities, when applications are in long-term operation, and when applications are attacked by common attacks. The application initialization deployment module includes: Module M1.1: Initializes the number of in-use application service components N, the number of standby application service components M, the maximum lifespan Survival allowed for service components, the scheduled scheduling interval Interval, and the number of checks Y in the heterogeneous layer and heterogeneous service component pool; Module M1.2: Split the application into several service components to be mimicked based on the service components to be mimicked in the application; Module M1.3: Group multiple service components into a heterogeneous service component pool based on the same type of service components in different environments; Module M1.4: Adapt different service components into a runnable application, and combine multiple different service components into a heterogeneous application group; The scheduling module includes: an initialization scheduling module, a negative feedback scheduling module, a timing scheduling module and a forced scheduling module; The initialization scheduling module selects N+M application service components for each of the X heterogeneous service component pools of the application according to the principle of maximizing heterogeneity when creating the application; where N represents the number of application service components in use; and M represents the number of standby application service components. The negative feedback scheduling module initiates negative feedback scheduling to the scheduling module when the scheduling log monitoring module identifies an abnormal decision, cleans and recovers the in-use application service components and the backup application service components determined by the initialization scheduling, and forms a new round of existing in-use application service components and the backup application service components; The timing scheduling module performs a timing scheduling every Interval time; when the timing scheduling is initiated, the existing application service components in use and the backup application service components are cleaned and restored to form a new round of application service components in use and the backup application service components; The forced scheduling module is when the scheduling log monitoring module monitors the negative feedback scheduling results. When it identifies that a certain service in use has an abnormality, it immediately forces the current service to be offline, thereby realizing the perception and processing of abnormal threats.

2. The application management system based on the mimicry defense concept according to claim 1 is characterized in that: The negative feedback scheduling module includes: determining whether the abnormal service component is the only architecture in the heterogeneous service component pool of the application in use; if the architecture is unique, selecting the service component with the same architecture as the abnormal service component from the heterogeneous service component pool of the backup application to calculate the heterogeneity of other layers, and putting the service component with the highest degree of heterogeneity online as the new service component in use; at this time, the new backup service / component in all heterogeneous service component pools of the application must also be the same architecture service / component, and must meet the maximum heterogeneity with the current in use and backup service components except for the architecture layer; If the architecture is not unique, select the executor with a different architecture from the abnormal service component from the backup to calculate the heterogeneity at other levels, and put the one with the greatest heterogeneity online as the new in-use service component; the new backup service component should also meet the requirement of having a different architecture from the abnormal service component, and maximize the heterogeneity with the currently in-use and backup service components at all levels except the architecture layer.

3. The application management system based on the mimicry defense concept according to claim 1 is characterized in that: The timing scheduling module includes: when there is a single service component in the in-use application heterogeneous service component pool whose running time exceeds the maximum allowed life cycle Survival, then the service component is used as the service / component to be scheduled this time; when there are multiple service components whose running time exceeds the maximum allowed life cycle Survival, the one with the longest running time is selected as the service / component to be scheduled this time; when there is no service component whose running time exceeds the maximum allowed life cycle Survival, it is necessary to calculate the service component to be scheduled this time based on the load information of each in-use service component; after the timing scheduling module confirms the service component to be scheduled, it selects a service component with the same architecture as the service component to be scheduled from the standby application heterogeneous service / component pool to calculate the heterogeneity of other layers, and puts the one with the greatest heterogeneity online as the new in-use service component. At this time, the new standby service component needs to meet the same architecture and maximize the heterogeneity with the current in-use and standby service components except the architecture layer.

4. The application management system based on the mimicry defense concept according to claim 1 is characterized in that: The forced scheduling module is a scheduling log monitoring module that monitors negative feedback scheduling and timing scheduling signals. It needs to perform Y checks first. If the current Y schedules are all service components with the same sequence number, then any one of the other N-1 service components will be selected as the service component to be scheduled for rotation.

5. The application management system based on the mimicry defense concept according to claim 1 is characterized in that: There is also a decision log monitoring module: monitoring includes distribution, database and redis decision logs, and collecting and monitoring the decision logs to achieve safe tracking of application operation process and results.

6. The application management system based on the mimicry defense concept according to claim 1 is characterized in that: The scheduling log monitoring module monitors initialization scheduling, negative feedback scheduling, timed scheduling, and forced scheduling. It traces the scheduling time and type triggered by each service component through scheduling log monitoring, collects and monitors various types of scheduling logs, and implements secure tracking of the application life cycle.

7. An application management method based on the concept of mimicry defense, characterized in that: include: Step S1: The application initialization deployment module splits the application into multiple service components, and forms multiple heterogeneous service component pools and application groups based on the multiple service components; Step S2: The scheduling module provides scheduling services for applications in the initialization creation phase, the phase when the application is attacked by an abnormality, the phase when the application is in a long-term running state, and the phase when the application is attacked by a common mode based on multiple heterogeneous service component pools and application groups; The step S1 comprises: Step S1.1: Initialize the number N of in-use application service components, the number M of standby application service components, the maximum lifespan Survival allowed for service components, the scheduled scheduling period Interval, and the number of checks Y in the heterogeneous layer and heterogeneous service component pool; Step S1.2: Split the application into several service components to be mimicked based on the service components to be mimicked in the application; Step S1.3: Based on the same type of service components in different environments, multiple service components are grouped into a heterogeneous service component pool; Step S1.4: Adapting different service components into a runnable application, and combining the current multiple different service components into a heterogeneous application group; The scheduling module includes: an initialization scheduling module, a negative feedback scheduling module, a timing scheduling module and a forced scheduling module; The initialization scheduling module selects N+M application service components for each of the X heterogeneous service component pools of the application according to the principle of maximizing heterogeneity when creating the application; where N represents the number of application service components in use; and M represents the number of standby application service components. The negative feedback scheduling module initiates negative feedback scheduling to the scheduling module when the scheduling log monitoring module identifies an abnormal decision, cleans and recovers the in-use application service components and the backup application service components determined by the initialization scheduling, and forms a new round of existing in-use application service components and the backup application service components; The timing scheduling module performs a timing scheduling every Interval time; when the timing scheduling is initiated, the existing application service components in use and the backup application service components are cleaned and restored to form a new round of application service components in use and the backup application service components; The forced scheduling module is when the scheduling log monitoring module monitors the negative feedback scheduling results. When it identifies that a certain service in use has an abnormality, it immediately forces the current service to be offline, thereby realizing the perception and processing of abnormal threats.

Images