A running state security self-adaptive control method for cloud software service

Abstract

The application discloses a kind of running state security adaptive control methods for cloud software service, it is related to security control technical field, to solve the problem that security control strategy is difficult to match cloud software service running state change in time, by obtaining service instance change record in cloud platform arrangement module and service call connection state in distributed link tracking module, build running state topology migration level, in combination with the resource occupancy rate calculated by the resource monitoring module of cloud output bearing offset calibration quantity, dynamically reconstructs preset security reference features based on bearing offset calibration quantity, generates adaptive security baseline, utilizes interface gateway to obtain request arrival time interval, and generates request deviation level in combination with adaptive security baseline, according to request deviation level Output hierarchical security control instruction, and according to security control response time length, update adaptive security baseline, improve the security control adaptive capacity in the process of cloud software service running state change.

Description

Technical Field

[0001] This invention relates to the field of security control technology, and more specifically, to a runtime security adaptive control method for cloud software services. Background Technology

[0002] As cloud software service architecture evolves towards microservices, distributed deployment, and dynamic orchestration, the number of service instances, service call relationships, and resource carrying capacity in the cloud application runtime environment all exhibit continuous changes. Cloud platforms typically use service orchestration mechanisms to create, migrate, scale up, and recover service instances from failures, and use tracing mechanisms to obtain call relationships between services in order to support runtime status monitoring and service scheduling management.

[0003] The existing technology has the following shortcomings: Currently, existing cloud software service security control processes typically manage access requests based on preset security rules and fixed judgment benchmarks. They lack a mechanism to adaptively adjust security benchmarks by considering dynamic changes in service instances, changes in service call relationships, and changes in resource carrying status. This makes it difficult for security control strategies to keep up with changes in the operational status of cloud software services, and easily leads to lagging security judgments and control responses that are not compatible with the current service status. Therefore, this paper proposes a runtime security adaptive control method for cloud software services.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a runtime security adaptive control method for cloud software services. This method addresses the problems mentioned in the background by employing service runtime topology awareness, resource carrying offset calibration, adaptive security baseline generation, and request timing deviation hierarchical control techniques.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a runtime safety adaptive control method for cloud software services, comprising the following steps: Step S1: Obtain the service instance change records in the cloud platform orchestration module, access the distributed link tracing module to obtain the service call connection status, and set the runtime topology migration level in combination with the service instance change records; Step S2: Collect the resource occupancy rate output by the cloud resource monitoring module, calculate the bearing offset calibration amount based on the comprehensive resource occupancy rate and the running state topology migration level, and generate the adaptive safety baseline corresponding to the current running state after dynamically reconstructing the preset safety reference features based on the bearing offset calibration amount. Step S3: Obtain the request arrival time interval from the interface gateway, evaluate the request timing deviation characteristics by combining the request arrival time interval with the adaptive security baseline, generate the request deviation level, determine the control object based on the request deviation level, and output hierarchical security control instructions; Step S4: When executing the hierarchical security control command, detect the security control response time, generate a baseline callback correction amount based on the request deviation level, and update the adaptive security baseline based on the baseline callback correction amount.

[0007] In a preferred embodiment, in step S1, a topology observation time window is set, and within the topology observation time window, service instance change records are obtained through the event query interface of the cloud platform orchestration module. Analyze each service instance change record and count the total number of instance addition, reduction, migration, and restart events as the instance change count; Within the same topology observation time window, access the distributed link tracing module, read the initiating service identifier, receiving service identifier, and connection persistence status of each service call chain, filter the connection persistence status as valid call chains, and constitute the inter-service call connection status.

[0008] In a preferred embodiment, in step S1, the runtime topology migration level is calculated using the service instance change record and the inter-service call connection status; Compare the runtime topology migration level with the migration trigger threshold; When the running topology migration level is greater than or equal to the migration trigger threshold, it is determined that the current service domain has undergone running migration, the resource collection time window is started and the process proceeds to step S2; Conversely, if the running topology migration level is less than the migration trigger threshold, the running topology migration level is written into the security judgment context of the current running cycle, and the process proceeds to step S2. When the total number of service instances is zero at the start of the topology observation time window, request control for the current service domain is stopped.

[0009] In a preferred embodiment, in step S2, within the resource acquisition time window, the processor usage value, memory usage value, and network interface usage value are read respectively using the resource monitoring agent deployed on the computing node where the service instance is located; The average values ​​of each read from the same service instance are calculated to obtain the average processor usage, average memory usage, and average network interface usage, which are then substituted into the calculation to obtain the resource utilization rate. The load offset calibration amount is obtained by multiplying the running topology migration level and the resource occupancy rate.

[0010] In a preferred embodiment, in step S2, the requests received by the interface gateway are classified according to the interface identifier and the caller identifier, and the arrival time interval of each type of request is counted and the median value is taken to obtain the preset security reference feature. The preset safety reference features are dynamically reconstructed using the load offset calibration amount, and the adaptive safety baseline is calculated. Compare the load offset calibration amount with the upper limit of the calibration range; When the load offset calibration amount is greater than the upper limit of the calibration interval, the adaptive safety baseline is limited to the upper quantile boundary of the preset safety reference feature; An adaptive safety baseline is generated when the load offset calibration amount is less than or equal to the upper limit of the calibration interval.

[0011] In a preferred embodiment, in step S3, a request analysis time window is set. Within the request analysis time window, the interface gateway continuously acquires the reception time of each request for requests with the same interface identifier and the same caller identifier. The difference between two adjacent reception times is used to obtain the corresponding request arrival time interval. Calculate request timing deviation characteristics using request arrival time intervals and an adaptive security baseline; Calculate the request deviation level using request timing deviation characteristics.

[0012] In a preferred embodiment, in step S3, a hierarchical security control instruction is generated based on the requested deviation level: When a request deviates from the first level, a hierarchical security control instruction is generated to perform normal access control on the controlled object; When a request deviates from the second level, a hierarchical security control instruction is generated to limit the number of concurrent requests to the controlled object; When a request deviates from the third level, a hierarchical security control instruction is generated to restrict access to the controlled object and isolate the current session. When the same type of request appears only once within the request analysis time window, the request timing deviation feature is recorded as zero, and a hierarchical security control instruction is generated to perform normal release on the controlled object.

[0013] In a preferred embodiment, in step S4, the instruction receiving time is registered as the timing start point, and the security control response duration is obtained by subtracting the timing start point from the timing end point. The baseline callback correction amount is calculated using the security control response time and request deviation level, and the adaptive security baseline is updated using the baseline callback correction amount.

[0014] In a preferred embodiment, in step S4, the security control response time is compared with the upper limit of the response time; When the security control response time is less than or equal to the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and the updated adaptive security baseline is written to the security baseline database. When the security control response time exceeds the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and an execution status verification instruction is sent to the security execution module. If the safety execution module does not return a completion confirmation signal, the safety control response time is set to the upper limit of the response time, and an execution status review instruction is issued to the safety execution module.

[0015] The technical effects and advantages of this invention are as follows: This invention constructs runtime topology migration levels by acquiring service instance change records from the cloud platform orchestration module and service call connection status from the distributed link tracing module. It then calculates bearer offset calibration based on resource occupancy output from the cloud resource monitoring module. Based on this calibration, it dynamically reconstructs pre-set security reference features to generate an adaptive security baseline. The invention utilizes an interface gateway to obtain request arrival time intervals and combines them with the adaptive security baseline to generate request deviation levels. Finally, it outputs tiered security control instructions based on the request deviation levels and updates the adaptive security baseline according to the security control response time. This improves the security control adaptability during changes in the runtime state of cloud software services, achieves dynamic security adjustment based on runtime changes and request behavior characteristics, and reduces the response lag of fixed security policies to service topology changes and request fluctuations. Attached Figure Description

[0016] Figure 1 This is an overall architecture diagram of a runtime safety adaptive control method for cloud-based software services according to the present invention.

[0017] Figure 2 This is a schematic diagram illustrating the steps of a runtime safety adaptive control method for cloud-based software services according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] This invention constructs a runtime topology migration level by acquiring service instance change records from the cloud platform orchestration module and service call connection status from the distributed link tracing module. It calculates the bearer offset calibration amount by combining the resource occupancy rate output by the cloud resource monitoring module. Based on the bearer offset calibration amount, it dynamically reconstructs preset security reference features to generate an adaptive security baseline. It uses the interface gateway to obtain the request arrival time interval and combines it with the adaptive security baseline to generate a request deviation level. Based on the request deviation level, it outputs hierarchical security control instructions and updates the adaptive security baseline according to the security control response time. This improves the security control adaptability during changes in the runtime status of cloud software services and realizes dynamic security adjustment based on changes in runtime status and request behavior characteristics.

[0020] Example 1 Please see Figures 1 to 2 A runtime safety adaptive control method for cloud software services includes the following steps: Step S1: Obtain the service instance change records in the cloud platform orchestration module, access the distributed link tracing module to obtain the service call connection status, and set the runtime topology migration level in combination with the service instance change records; Step S2: Collect the resource occupancy rate output by the cloud resource monitoring module, calculate the bearing offset calibration amount based on the comprehensive resource occupancy rate and the running state topology migration level, and generate the adaptive safety baseline corresponding to the current running state after dynamically reconstructing the preset safety reference features based on the bearing offset calibration amount. Step S3: Obtain the request arrival time interval from the interface gateway, evaluate the request timing deviation characteristics by combining the request arrival time interval with the adaptive security baseline, generate the request deviation level, determine the control object based on the request deviation level, and output hierarchical security control instructions; Step S4: When executing the hierarchical security control command, detect the security control response time, generate a baseline callback correction amount based on the request deviation level, and update the adaptive security baseline based on the baseline callback correction amount.

[0021] The specific implementation is as follows: In step S1, a topology observation time window is set. The topology observation time window starts at the beginning of the current orchestration cycle and ends at the moment when the orchestration module completes the writing of the current cycle's events. Within the topology observation time window, service instance change records are obtained through the event query interface of the cloud platform orchestration module.

[0022] Service instance change logs refer to the events of instance addition, reduction, migration, and restart stored with instance identifiers as indexes, which are used to reflect the actual changes in the service instance structure.

[0023] Each service instance change record is parsed to count the total number of instance addition, reduction, migration, and restart events, which is taken as the instance change count.

[0024] Simultaneously, within the same topology observation time window, the distributed link tracing module is accessed to read the initiating service identifier, receiving service identifier, and connection persistence status of each service call chain. Chains with persistent connection status are selected as valid call chains, constituting the inter-service call connection status. The inter-service call connection status represents the actual available service call relationships within the current service domain.

[0025] The runtime topology migration level refers to the degree of comprehensive change in the service instance structure and service call connections relative to the stable runtime state. It is used to determine whether there is a runtime migration that requires calibration of the security judgment reference in the current runtime cycle.

[0026] Calculate runtime topology migration level using service instance change records and inter-service call connection status: in, For runtime topology migration level, For instance change count, This represents the total number of service instances at the start of the topology observation time window. This refers to the set of service call connections that are currently in a valid state. To ensure stable operation, the set of call connections stored within the baseline time window, Change the weight for the instance.

[0027] The stable operation baseline time window consists of historical orchestration periods that have run continuously without triggering security control commands. Within each stable operation baseline time window, the instance change ratio and the call connection change ratio are calculated separately; the variances of the two ratios are calculated separately, and the reciprocal of the variances is normalized to obtain the instance change weight. The higher the running topology migration level, the more concentrated the instance structure changes or the lower the overlap between the current call connection set and the stable operation connection set, and the further the current service operation structure deviates from the stable operation state.

[0028] The running topology migration level is compared with the migration trigger threshold. The migration trigger threshold is obtained by repeatedly calculating the running topology migration level within a stable operating baseline time window and taking its 95th percentile value.

[0029] When the running topology migration level is greater than or equal to the migration trigger threshold, it is determined that the current service domain has undergone running migration, the resource collection time window is started and the process proceeds to step S2; Conversely, if the running topology migration level is less than the migration trigger threshold, the running topology migration level is written into the security judgment context of the current running cycle, and the process proceeds to step S2.

[0030] When the total number of service instances is zero at the start of the topology observation time window, request control for the current service domain is stopped, and service instance change records and service call connection status are retrieved again in the next orchestration cycle.

[0031] By synchronously acquiring and calculating service instance change records and inter-service call connection states, a runtime topology migration level is formed, providing a structural change basis for calibrating the service bearer state in subsequent steps.

[0032] In step S2, the resource acquisition time window starts at the end of the topology observation time window and ends at the moment when the current cloud resource monitoring module completes one round of resource sampling.

[0033] Within the resource collection time window, the resource monitoring agent deployed on the computing node where the service instance is located is used to read the processor usage value, memory usage value, and network interface usage value respectively; The average values ​​of each read from the same service instance are calculated to obtain the average processor usage, average memory usage, and average network interface usage.

[0034] Resource utilization rate refers to the average utilization level of processors, memory, and network interfaces within a resource collection time window, used to characterize the resource carrying capacity of the current service instance. The formula for calculating resource utilization rate is: in, For resource utilization rate, This represents the average processor usage. This represents the average memory usage. This represents the average resource utilization rate of the network interface. A higher resource utilization rate indicates that the current service instance has fewer remaining resources, and the service topology change has a more significant impact on request timing.

[0035] The load offset calibration is a calibration amount formed by associating changes in service operation structure with resource load capacity, and is used to determine the relaxation range of the safety judgment reference.

[0036] Calculate the bearer offset calibration using the running topology migration level and resource utilization: in, To carry the offset calibration amount, For runtime topology migration level, This refers to resource utilization. When both the runtime topology migration level and resource utilization increase simultaneously, the bearer offset calibration amount increases, indicating that the current request timing may be affected by both service structure changes and resource load changes.

[0037] Pre-defined security reference features are stored in the security baseline database. These features are obtained by classifying requests received by the interface gateway according to the interface identifier and the caller identifier within a stable operating baseline time window, and then calculating the median value of the arrival time interval for each type of request.

[0038] The adaptive security baseline serves as a reference for judging the arrival time intervals of various requests generated in the current runtime state, and is used to replace the fixed request timing threshold.

[0039] The pre-set safety reference features are dynamically reconstructed using the load offset calibration amount. The formula for calculating the adaptive safety baseline is as follows: in, For the first Adaptive security baseline for class requests, For the first of the pre-set safety reference features The bit value in the request arrival time interval of the class request. To carry the offset calibration amount, This is the load-bearing adjustment coefficient.

[0040] The larger the load offset calibration amount, the larger the tolerance interval of the adaptive safety baseline relative to the preset safety reference feature, which is used to reduce request misjudgment caused by normal scaling up and down and resource fluctuations.

[0041] It should be noted that the load adjustment coefficient is determined by the ratio of the interquartile range of resource occupancy rate within the stable operation reference time window to the interquartile range of the request arrival time interval.

[0042] The load offset calibration amount is compared with the upper limit of the calibration interval, which is the 99th percentile of the load offset calibration amount within the stable operation reference time window.

[0043] When the load offset calibration amount is greater than the upper limit of the calibration interval, the adaptive safety baseline is limited to the upper quantile boundary of the preset safety reference feature; When the load offset calibration amount is less than or equal to the upper limit of the calibration interval, an adaptive safety baseline is generated according to the above formula.

[0044] If any of the average processor usage, average memory usage, or average network interface usage values ​​are missing, the most recent valid read value for the corresponding resource within the same resource acquisition time window is read, and then the resource utilization rate is calculated.

[0045] The adaptive security baseline is written to the security baseline database and indexed by request type. Through the above-described processes of resource occupancy acquisition, bearer offset calibration calculation, and adaptive security baseline reconstruction, a dynamic reference matching the current running state is provided for subsequent steps of request timing determination.

[0046] In step S3, a request analysis time window is set. The request analysis time window starts at the moment when the adaptive security baseline is written to the security baseline database and ends at the moment when the interface gateway completes the writing of the current round of request reception logs.

[0047] Within the request analysis time window, the interface gateway continuously acquires the reception time of each request for the same interface identifier and the same caller identifier; it then calculates the difference between two adjacent reception times to obtain the corresponding request arrival time interval, which is used to describe the actual arrival rhythm of similar requests.

[0048] The interface gateway simultaneously parses the caller identifier in the request header and the target interface identifier in the request path, combining the two into a control object. A control object refers to the combination of the request source and target interface that can be directly affected by hierarchical security control instructions.

[0049] The request timing deviation feature is the proportion of the request arrival time interval deviating from the adaptive safety baseline, used to eliminate the dimensional impact caused by differences in request frequencies across different interfaces. The request timing deviation feature is calculated using the request arrival time interval and the adaptive safety baseline: in, For the first Request timing deviation characteristics of class requests For the first The time interval between requests of the same type. For the first Adaptive security baseline for class requests, This is the smallest unit of time for the interface gateway timestamp. The greater the request timing deviation, the more significant the deviation of the request arrival rhythm from the security judgment reference in the current operating state.

[0050] Request deviation level refers to a discrete control level determined based on request timing deviation characteristics, used to invoke different safety control actions under different degrees of deviation. The request deviation level is calculated using request timing deviation characteristics: in, To request a deviation from the hierarchy, The 90th percentile value of the timing deviation characteristic requested within the reference time window for stable operation. This represents the 99th percentile of the request timing deviation characteristics within the stable operation baseline time window. A higher request deviation level indicates a more significant timing deviation of the requested object.

[0051] Generate hierarchical security control instructions based on the requested deviation level: When a request deviates from the first level, a hierarchical security control instruction is generated to perform normal access control on the controlled object; When a request deviates from the second level, a hierarchical security control instruction is generated to limit the number of concurrent requests to the controlled object; When a request deviates from level three, a hierarchical security control instruction is generated to restrict access permissions to the controlled object and isolate the current session.

[0052] When the same type of request appears only once within the request analysis time window, the request timing deviation feature is recorded as zero, and a hierarchical security control instruction is generated to perform normal release on the controlled object.

[0053] The request deviation level and hierarchical security control instructions are passed to the security execution module. By obtaining the request arrival time interval, calculating the request timing deviation characteristics, and determining the request deviation level, the abnormal request timing in the current running state is converted into executable control actions.

[0054] In step S4, after receiving the hierarchical safety control instruction, the safety execution module registers the instruction reception time as the timing start point; After the security execution module completes routine release, concurrent request quantity limit or access permission restriction and session isolation actions, it receives completion confirmation signals from each action execution component and registers the time of receiving the completion confirmation signal as the timing end point.

[0055] The safety control response time is obtained by subtracting the timing start time from the timing end time. The safety control response time is used to characterize the actual lag between the issuance and completion of a hierarchical safety control command.

[0056] The safety execution module continuously stores the safety control response time corresponding to each request deviation level within the stable operation reference time window, and takes the median value for each level to obtain the response time reference. The level correction coefficient increases from low to high according to the request deviation level, and its value is obtained by normalizing the median value of the response time of each level control action by the safety execution module within the stable operation reference time window.

[0057] The baseline callback correction amount refers to the proportion of security baseline tightening determined jointly by the request deviation level and the security control response time. It is used to determine the timing of requests that reflect control execution hysteresis to the next runtime cycle. The baseline callback correction amount is calculated using the security control response time and the request deviation level. in, This is the baseline callback adjustment amount. This is the level correction factor corresponding to the requested deviation level. To control response time for safety, This represents the median response time of the safety execution module within a stable operating baseline time window. The higher the request deviates from the hierarchy or the closer the safety control response time is to the upper limit of the response time baseline, the larger the baseline callback correction amount, indicating that subsequent requests need to enter the control branch earlier.

[0058] Update the adaptive safety baseline using baseline callback correction: in, For the updated adaptive safety baseline, For the adaptive security baseline before the update, This represents the baseline callback correction amount. When the baseline callback correction amount increases, the updated adaptive safety baseline decreases, indicating that similar requests with smaller timing deviations can proceed to subsequent hierarchical control judgments.

[0059] The safety control response time is compared with the upper limit of the response time. The upper limit of the response time is determined by the 99th percentile of the safety control response time within the stable operation reference time window.

[0060] When the security control response time is less than or equal to the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and the updated adaptive security baseline is written to the security baseline database. When the security control response time exceeds the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and an execution status review instruction is issued to the security execution module.

[0061] If the safety execution module does not return a completion confirmation signal, the safety control response time is set to the upper limit of the response time, and an execution status review instruction is issued to the safety execution module.

[0062] The security baseline database uses the updated adaptive security baseline as the reference for request timing judgment in the next runtime step S3, thereby achieving runtime security adaptive control in scenarios where service instance changes, service call connection changes, resource consumption changes, and control execution lag all work together.

[0063] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0064] Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0065] In this document, the singular forms “a,” “an,” and “the” may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that terms such as “comprising / including” or “having” specify the presence of the stated features, integrals, steps, operations, components, parts, or combinations thereof, but do not preclude the possibility of the presence or addition of one or more other features, integrals, steps, operations, components, parts, or combinations thereof. Meanwhile, the term “and / or” as used in this specification includes any and all combinations of the associated listed items.

[0066] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0067] The above description of the disclosed embodiments will enable those skilled in the art to make or use various modifications to these embodiments. It will be readily apparent to those skilled in the art that the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A runtime safety adaptive control method for cloud-based software services, characterized in that, Includes the following steps: Step S1: Obtain the service instance change records in the cloud platform orchestration module, access the distributed link tracing module to obtain the service call connection status, and set the runtime topology migration level in combination with the service instance change records; Step S2: Collect the resource occupancy rate output by the cloud resource monitoring module, calculate the bearing offset calibration amount based on the comprehensive resource occupancy rate and the running state topology migration level, and generate the adaptive safety baseline corresponding to the current running state after dynamically reconstructing the preset safety reference features based on the bearing offset calibration amount. Step S3: Obtain the request arrival time interval from the interface gateway, evaluate the request timing deviation characteristics by combining the request arrival time interval with the adaptive security baseline, generate the request deviation level, determine the control object based on the request deviation level, and output hierarchical security control instructions; Step S4: When executing the hierarchical security control command, detect the security control response time, generate a baseline callback correction amount based on the request deviation level, and update the adaptive security baseline based on the baseline callback correction amount.

2. The runtime safety adaptive control method for cloud software services according to claim 1, characterized in that: In step S1, a topology observation time window is set. Within the topology observation time window, service instance change records are obtained through the event query interface of the cloud platform orchestration module. Analyze each service instance change record and count the total number of instance addition, reduction, migration, and restart events as the instance change count; Within the same topology observation time window, access the distributed link tracing module, read the initiating service identifier, receiving service identifier, and connection persistence status of each service call chain, filter the connection persistence status as valid call chains, and constitute the inter-service call connection status.

3. The runtime safety adaptive control method for cloud software services according to claim 2, characterized in that: In step S1, the runtime topology migration level is calculated using service instance change records and inter-service call connection status; Compare the runtime topology migration level with the migration trigger threshold; When the running topology migration level is greater than or equal to the migration trigger threshold, it is determined that the current service domain has undergone running migration, the resource collection time window is started and the process proceeds to step S2; Conversely, if the running topology migration level is less than the migration trigger threshold, the running topology migration level is written into the security judgment context of the current running cycle, and the process proceeds to step S2. When the total number of service instances is zero at the start of the topology observation time window, request control for the current service domain is stopped.

4. The runtime safety adaptive control method for cloud software services according to claim 1, characterized in that: In step S2, within the resource acquisition time window, the resource monitoring agent deployed on the computing node where the service instance is located is used to read the processor usage value, memory usage value, and network interface usage value, respectively. The average values ​​of each read from the same service instance are calculated to obtain the average processor usage, average memory usage, and average network interface usage, which are then substituted into the calculation to obtain the resource utilization rate. The load offset calibration amount is obtained by multiplying the running topology migration level and the resource occupancy rate.

5. The runtime safety adaptive control method for cloud software services according to claim 4, characterized in that: In step S2, the requests received by the interface gateway are classified according to the interface identifier and the caller identifier. The arrival time interval of each type of request is counted and the median value is taken to obtain the preset security reference feature. The preset safety reference features are dynamically reconstructed using the load offset calibration amount, and the adaptive safety baseline is calculated. Compare the load offset calibration amount with the upper limit of the calibration range; When the load offset calibration amount is greater than the upper limit of the calibration interval, the adaptive safety baseline is limited to the upper quantile boundary of the preset safety reference feature; An adaptive safety baseline is generated when the load offset calibration amount is less than or equal to the upper limit of the calibration interval.

6. The runtime safety adaptive control method for cloud software services according to claim 1, characterized in that: In step S3, a request analysis time window is set. Within the request analysis time window, the interface gateway continuously obtains the reception time of each request for the same interface identifier and the same caller identifier. The difference between two adjacent reception times is used to obtain the corresponding request arrival time interval. Calculate request timing deviation characteristics using request arrival time intervals and an adaptive security baseline; Calculate the request deviation level using request timing deviation characteristics.

7. The runtime safety adaptive control method for cloud software services according to claim 6, characterized in that: In step S3, a hierarchical security control instruction is generated based on the requested deviation level: When a request deviates from the first level, a hierarchical security control instruction is generated to perform normal access control on the controlled object; When a request deviates from the second level, a hierarchical security control instruction is generated to limit the number of concurrent requests to the controlled object; When a request deviates from the third level, a hierarchical security control instruction is generated to restrict access to the controlled object and isolate the current session. When the same type of request appears only once within the request analysis time window, the request timing deviation feature is recorded as zero, and a hierarchical security control instruction is generated to perform normal release on the controlled object.

8. The runtime safety adaptive control method for cloud software services according to claim 7, characterized in that: In step S4, the instruction receiving time is registered as the timing start point, and the safety control response duration is obtained by subtracting the timing start point from the timing end point; The baseline callback correction amount is calculated using the security control response time and request deviation level, and the adaptive security baseline is updated using the baseline callback correction amount.

9. The runtime safety adaptive control method for cloud software services according to claim 8, characterized in that: In step S4, the safety control response time is compared with the upper limit of the response time; When the security control response time is less than or equal to the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and the updated adaptive security baseline is written to the security baseline database. When the security control response time exceeds the upper limit of the response time, the adaptive security baseline is updated using the baseline callback correction amount, and an execution status verification instruction is sent to the security execution module. If the safety execution module does not return a completion confirmation signal, the safety control response time is set to the upper limit of the response time, and an execution status review instruction is issued to the safety execution module.

Images