Method, device and system for adjusting current-limiting degradation strategy in safe operation scene and medium
By dynamically calculating the expected alarm latency and alarm priority weight to generate rate limiting and degradation strategies, the adaptiveness and resource optimization problems of traditional rate limiting strategies are solved, and efficient rate limiting and degradation operations are achieved in security operation scenarios.
Patent Information
- Application Number
- CN202511863470.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-10
- Publication Date
- 2026-03-06
AI Technical Summary
In security operation scenarios, traditional rate limiting and degradation strategies rely on static thresholds and human experience, which cannot adapt to dynamic traffic characteristics. This leads to the accidental blocking of normal requests and the passing of attack traffic. At the same time, in multi-tenant scenarios, it is difficult to guarantee the service level agreement of core businesses, which can easily result in both resource waste and critical service blockage.
By obtaining the average number of backlogged alarm events and the consumption rate, the expected alarm latency is dynamically calculated. A rate limiting and degradation strategy is generated by combining alarm priority weights, and the token bucket algorithm is used for local rate limiting, thereby achieving differentiated processing and resource optimization of alarm events.
It achieves adaptive rate limiting and degradation, avoiding false interception of normal requests and missed detection of attack traffic, ensuring the service level agreement of core businesses in multi-tenant scenarios, and avoiding resource waste and blockage of critical services.
Smart Images
Figure CN121619288A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, system and medium for adjusting rate limiting and degradation strategies in a secure operation scenario. Background Technology
[0002] In scenarios involving massive amounts of alarms during security operations, sudden surges in alarm traffic can easily overload or even crash the processing service.
[0003] However, traditional solutions have significant drawbacks: First, static rate limiting relies on fixed thresholds and cannot adapt to dynamically changing traffic characteristics, making it easy to mistakenly block legitimate requests while also missing attack traffic; second, manual degradation strategies rely on the experience and judgment of operations personnel, resulting in low automation and delayed policy updates and extended fault recovery times; furthermore, in multi-tenant scenarios, the lack of differentiated resource allocation makes it difficult to guarantee the Service Level Agreement (SLA) for core businesses and easily leads to both resource waste and critical service blockage. Summary of the Invention
[0004] The purpose of this application is to provide a method, device, system and medium for adjusting rate limiting and degradation strategies in a secure operation scenario, so as to get rid of the limitations of using traditional static thresholds for static rate limiting, solve the problem of relying on the experience and judgment of operation and maintenance personnel in traditional solutions, ensure that core business in multi-tenant scenarios is not affected, and avoid the problem of resource waste and critical service blockage at the same time.
[0005] To address the aforementioned issues, this application provides a method for adjusting rate limiting and degradation strategies in a security operation scenario, comprising:
[0006] Obtain the number of backlogged alarm events and determine the average consumption rate used to characterize the client's consumption rate level within the target time period; wherein, the number of backlogged alarm events is the number of alarm events that have been generated but not consumed;
[0007] The expected alarm latency is determined based on the number of backlogged alarm events and the average consumption rate.
[0008] The expected alarm duration is mapped to different alarm duration intervals, and a rate limiting and degradation strategy is generated according to the matching rules between the alarm duration intervals and the preset alarm weights; wherein, the rate limiting and degradation strategy includes a degradation ratio and a rate limiting rate.
[0009] The rate limiting and degradation policy is sent to the client so that the client can perform degradation operations on alarm events based on the degradation ratio in the rate limiting and degradation policy, and perform rate limiting operations on alarm events based on the rate limiting rate in the rate limiting and degradation policy.
[0010] Optionally, determining the average consumption rate used to characterize the client's consumption rate level within the target time period includes:
[0011] Obtain the consumption rate data reported by the client through a scheduled task; wherein, the consumption rate data is the rate at which the client consumes and processes alarm events;
[0012] The average consumption rate data within the target time period is calculated using a sliding window to obtain the average consumption rate.
[0013] Optionally, determining the expected alarm latency based on the backlog of alarm events and the average consumption rate includes:
[0014] The expected alarm latency is determined based on the ratio between the backlog of alarm events and the average consumption rate.
[0015] Optionally, mapping the expected alarm duration to different alarm duration intervals and generating a rate limiting and degradation strategy based on the matching rules between the alarm duration intervals and preset alarm weights includes:
[0016] Configure at least two alarm duration intervals and at least two alarm priority types; the alarm priority type is determined based on the service security priority of the alarm event, and different alarm priority types correspond to different preset alarm weights;
[0017] Establish a mapping between the alarm duration interval and the alarm priority type, and configure a corresponding set of degradation ratios for each alarm priority type; different alarm duration intervals under the same alarm priority type correspond to different degradation ratios;
[0018] The expected alarm duration is compared with each of the alarm duration intervals to determine the target alarm duration interval corresponding to the expected alarm duration, and the target alarm priority type and the target degradation ratio corresponding to the target alarm duration interval are determined.
[0019] The target rate limiting rate is calculated based on the real-time resource usage status and matches the target alarm duration interval. The rate limiting and degradation strategy is generated based on the target degradation ratio and the target rate limiting rate. The target rate limiting rate is a parameter required by the client for local rate limiting based on the token bucket algorithm.
[0020] Optionally, the alarm priority types include non-degradable type, degradable-or-non-degradable type, and degradable type;
[0021] Wherein, the non-degradable type is an alarm that is a successful attack and is not vulnerable, or the non-degradable type is the first alarm; the degradable type is a false alarm, an alarm initiated by an external scanner, or an alarm that the attack failed; the degradable-or-non-degradable type is any alarm other than the non-degradable type and the degradable type; wherein, non-vulnerability is a state caused by an external attack that affects the attacked object.
[0022] Optionally, the rate limiting and degradation policy is sent to the client, so that the client performs degradation operations on the alarm event based on the degradation ratio in the rate limiting and degradation policy, and performs rate limiting operations on the alarm event based on the rate limiting rate in the rate limiting and degradation policy, including:
[0023] The rate limiting and degradation policy is sent to the client so that the client can send non-degradable alarm events to the first queue, allowing the first thread to prioritize the processing of alarm events in the first queue. The client can send degradable alarm events and degradable-optional alarm events to the second queue, allowing the second thread to degrade the alarm events in the second queue according to the degradation ratio in the rate limiting and degradation policy. Then, a token generation rate corresponding to the rate limiting and degradation policy is generated based on the token bucket algorithm, allowing the third thread to perform rate limiting operations on the alarm events in the first queue and the second queue based on the token generation rate.
[0024] Optionally, obtaining the number of backlogged alarm events includes:
[0025] The number of alarms stored in each partition of the target queue is queried periodically through the management interface.
[0026] The number of alarms stored in each partition is summarized to obtain the final number of backlogged alarm events.
[0027] This application also provides a device for adjusting rate limiting and degradation strategies in a security operation scenario, including:
[0028] The backlog alarm acquisition module is used to acquire the number of backlog alarm events and determine the average consumption rate used to characterize the consumption rate level of the client within the target time period; wherein, the number of backlog alarm events is the number of alarm events that have been generated but not consumed and processed;
[0029] The time consumption determination module is used to determine the expected alarm consumption time based on the backlog of alarm events and the average consumption rate.
[0030] The strategy determination module is used to map the expected alarm duration to different alarm duration intervals, and generate a rate limiting and degradation strategy according to the matching rules between the alarm duration intervals and the preset alarm weights; wherein, the rate limiting and degradation strategy includes a degradation ratio and a rate limiting rate.
[0031] The policy delivery module is used to send the rate limiting and degradation policy to the client, so that the client can perform degradation operation on the alarm event based on the degradation ratio in the rate limiting and degradation policy, and perform rate limiting operation on the alarm event based on the rate limiting rate in the rate limiting and degradation policy.
[0032] This application also provides a system for adjusting rate limiting and degradation strategies in a security operation scenario, including:
[0033] Memory, used to store computer programs;
[0034] A processor is configured to implement the steps of the rate limiting and degradation strategy adjustment method under the security operation scenario described above when executing the computer program.
[0035] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the rate limiting and degradation strategy adjustment method under the security operation scenario described above.
[0036] This application provides a method for adjusting rate limiting and degradation strategies in a security operation scenario, comprising: obtaining the number of backlogged alarms; wherein the number of backlogged alarms is the number of alarm events that have been generated but not consumed; determining the average consumption rate used to characterize the client's consumption rate level within a target time period; determining the expected alarm latency based on the number of backlogged alarms and the average consumption rate; generating a rate limiting and degradation strategy through the expected alarm latency and alarm priority weight; and distributing the rate limiting and degradation strategy to the client so that the client can perform graded degradation and rate limiting operations on alarms based on the rate limiting and degradation strategy.
[0037] In summary, this application dynamically calculates the expected alarm latency by combining the backlog of alarms with the average consumption rate representing the client's consumption rate level within the target time period. This overcomes the limitations of traditional static thresholds, avoiding false blocking of normal requests under fixed thresholds and reducing missed detections of attacks. Furthermore, this application automatically generates rate limiting and degradation policies based on the expected alarm latency and alarm priority weights, and distributes these policies to clients without manual intervention, solving the problem of traditional solutions relying on the experience of operations personnel. Finally, when generating rate limiting and degradation policies, this application differentiates alarm events based on alarm priority weights, ensuring that the service level agreements of core businesses remain unaffected in multi-tenant scenarios while avoiding both resource waste and critical service blockage.
[0038] This application also provides a device for adjusting rate limiting and degradation strategies in a secure operation scenario, a system for adjusting rate limiting and degradation strategies in a secure operation scenario, and a computer-readable storage medium, which have the above-mentioned beneficial effects, and will not be elaborated here. Attached Figure Description
[0039] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0040] Figure 1 A flowchart illustrating a method for adjusting rate limiting and degradation strategies in a security operation scenario, provided in an embodiment of this application;
[0041] Figure 2 An architecture diagram of a method for adjusting rate limiting and degradation strategies in a security operation scenario provided in this application embodiment;
[0042] Figure 3 A schematic diagram of a rate limiting and degradation strategy adjustment device in a secure operation scenario provided in this application embodiment;
[0043] Figure 4 This is a schematic diagram of a rate limiting and degradation strategy adjustment system in a secure operation scenario, provided as an embodiment of this application. Detailed Implementation
[0044] The core of this application is to provide a method, device, system, and medium for adjusting rate limiting and degradation strategies in a secure operation scenario, so as to get rid of the limitations of using traditional static thresholds for static rate limiting, solve the problem of relying on the experience and judgment of operation and maintenance personnel in traditional solutions, ensure that core businesses in multi-tenant scenarios are not affected, and avoid the problem of resource waste and critical service blockage at the same time.
[0045] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0046] Sudden spikes in alert traffic can easily overload or even crash processing services. Traditional solutions have significant drawbacks: First, static rate limiting relies on fixed thresholds and cannot adapt to dynamically changing traffic characteristics, easily blocking legitimate requests while also missing attack traffic; second, manual degradation strategies rely on the experience and judgment of operations personnel, resulting in low automation, delayed policy updates, and extended fault recovery times; and in multi-tenant scenarios, the lack of differentiated resource allocation makes it difficult to guarantee service level agreements for core businesses, and easily leads to both resource waste and critical service blockage.
[0047] Therefore, this application dynamically calculates the expected alarm latency by combining the backlog of alarms with the average consumption rate representing the client's consumption rate level within the target time period. This overcomes the limitations of traditional static thresholds, avoiding false blocking of normal requests under fixed thresholds and reducing missed detections of attacks. Simultaneously, this application automatically generates rate limiting and degradation policies based on the expected alarm latency and alarm priority weights, and distributes these policies to clients without manual intervention, solving the problem of traditional solutions relying on the experience of operations personnel. Finally, when generating rate limiting and degradation policies, this application differentiates alarm events based on alarm priority weights, ensuring that the service level agreements of core businesses are not affected in multi-tenant scenarios, while avoiding the coexistence of resource waste and critical service blockage.
[0048] The following example illustrates a method for adjusting rate limiting and degradation strategies in a secure operation scenario provided in this application.
[0049] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a method for adjusting rate limiting and degradation strategies in a secure operation scenario, as provided in an embodiment of this application.
[0050] In this embodiment, the method may include:
[0051] S101, obtain the number of backlogged alarm events and determine the average consumption rate used to characterize the consumption rate level of the client within the target time period; wherein, the number of backlogged alarm events is the number of alarm events that have been generated but not consumed.
[0052] In this embodiment, the number of alarms stored in each partition (backlog size) of the target queue is queried periodically through the management interface (Pulsar Admin API), and the number of alarms stored in each partition is summarized to obtain the final backlog of alarm events. The management interface refers to a predefined, standardized interface that enables data interaction between the management terminal and the target queue; the target queue adopts a partitioned storage design, which avoids excessive load on a single partition affecting data read and write efficiency.
[0053] The rate at which a client processes alarm events can fluctuate due to factors such as hardware load and network conditions. Using only the rate of a single report to characterize the client's processing capacity can easily lead to inaccurate results due to momentary fluctuations. Therefore, the client needs to report consumption rate data to the management system at fixed intervals via a scheduled task. This data represents the rate at which the client processes alarm events per unit of time. For the server, it is necessary to first obtain the consumption rate data reported by the target client via a scheduled task, then calculate the average of these consumption rate data over the target time period using a sliding window, and finally obtain the average consumption rate.
[0054] For example, if the target time period is set to the most recent 30 minutes, the sliding window's time range is also set to 30 minutes. Assuming the client's scheduled task reporting cycle is 5 minutes, when calculating the consumption rate for the most recent 30 minutes at any given time, the sliding window will automatically retrieve all consumption rate data reported by the client within the 30 minutes prior to that moment, i.e., 6 sets of data. If these 6 sets of data are 150 messages / minute, 162 messages / minute, 148 messages / minute, 155 messages / minute, 160 messages / minute, and 153 messages / minute respectively, the management system will include these 6 sets of data in the sliding window's calculation range and calculate: (150 + 162 + 148 + 155 + 160 + 153) ÷ 6 = 154.67 messages / minute. This result is the average consumption rate for the most recent 30 minutes. It should be noted that this average consumption rate accurately reflects the target client's processing capacity within 30 minutes.
[0055] S102, determine the expected alarm latency based on the backlog of alarm events and the average consumption rate.
[0056] The expected alarm latency is determined based on the ratio of the backlog of alarm events to the average consumption rate.
[0057] The formula can be expressed as: Expected processing time = Number of backlogged alarm events / Average consumption rate. This expected alarm processing time reflects the estimated time required from the current moment until all backlogged alarms are completely consumed, assuming the client maintains stable processing capacity (i.e., average consumption rate) within the target time period. If the number of backlogged alarm events is 928 and the average consumption rate is 154.67 events / minute, then 928 ÷ 154.67 ≈ 6 minutes, meaning the expected alarm processing time is approximately 6 minutes. This result clearly demonstrates the processing pressure of the backlogged alarms.
[0058] S103, map the expected alarm duration to different alarm duration intervals, and generate a rate limiting and degradation strategy according to the matching rule between the alarm duration interval and the preset alarm weight; the rate limiting and degradation strategy includes a degradation ratio and a rate limiting rate.
[0059] In this embodiment, the expected alarm duration is mapped to different alarm duration intervals, and a rate limiting and degradation strategy is generated based on the matching rules between the alarm duration intervals and preset alarm weights. The above process can be further refined into the following steps:
[0060] S1031, Configure at least two alarm duration intervals and at least two alarm priority types; the alarm priority type is determined based on the service security priority of the alarm event, and different alarm priority types correspond to different preset alarm weights.
[0061] In this embodiment, alarm latency intervals corresponding to backlog times are configured, for example, 30-60 minutes, 60-90 minutes, 90-120 minutes, and over 120 minutes. Simultaneously, three alarm priority types are defined, each directly related to business security priorities: the alarm priority types include non-degradable types, degradable-optional types, and degradable types; the non-degradable type is an alarm that is a successful attack and is not vulnerable, or the first alarm of the non-degradable type; the degradable type is a false alarm, an alarm initiated by an external scanner, or an alarm that has failed to attack; the degradable-optional type is any alarm other than the non-degradable and degradable types; where non-vulnerability refers to a state caused by an external attack that affects the attacked object.
[0062] It should be explained that an external scanner refers to a tool or program deployed by an external entity (such as a network security testing organization) to perform automated vulnerability detection, port scanning, and service identification on a system or device; a false alarm refers to an event in which normal business operations or risk-free behavior are incorrectly identified as a security alarm due to environmental interference, rule misjudgment, or other factors.
[0063] Table 1. Alarm Priority Type Determination Criteria
[0064]
[0065] S1032, Establish a mapping between alarm duration intervals and alarm priority types, and configure a set of degradation ratios for each alarm priority type; different alarm duration intervals under the same alarm priority type correspond to different degradation ratios.
[0066] In this embodiment, a mapping relationship between alarm duration intervals and alarm priority types is established, and a corresponding set of degradation ratios is configured for each alarm priority type. Specifically, alarm durations of 30-60 minutes are mapped to degradeable types, corresponding to a 50% degrade ratio. This means that within this range, 50% of degradeable alarms will be degraded. Similarly, alarm durations of 60-90 minutes are mapped to degradeable types, corresponding to a 100% degrade ratio. This means that all degradeable alarms within this range will be temporarily suspended. Alarm durations of 90-120 minutes are mapped to a type that can be either degraded or not, corresponding to a 50% degrade ratio. This means that within this range, 50% of degradeable alarms will be degraded. Alarm durations exceeding 120 minutes are also mapped to a type that can be either degraded or not, corresponding to a 100% degrade ratio. This means that within this range, all degradeable alarms will be temporarily suspended. For non-degradable alarm types, no degradation ratio is configured across all alarm duration intervals, maintaining a 100% processing ratio at all times to ensure that these alarms are processed first. To clearly illustrate the above configuration logic, the following table illustrates it:
[0067] Table 2. Mapping Table of Alarm Duration Range, Alarm Priority Type, and Degradation Ratio
[0068]
[0069] S1033, compare the expected alarm time with each of the alarm time intervals to determine the target alarm time interval corresponding to the expected alarm time, and determine the target alarm priority type corresponding to the target alarm time interval, and the target degradation ratio corresponding to the target alarm time interval.
[0070] Based on the aforementioned steps that have clarified the mapping relationship between alarm duration intervals, alarm priority types, and degradation ratios, this step only needs to compare the calculated expected alarm duration with each preset alarm duration interval to determine the target alarm duration interval to which it belongs, and at the same time obtain the target alarm priority type and target degradation ratio corresponding to that interval.
[0071] S1034, calculate the target rate limiting rate that matches the target alarm duration interval based on the real-time resource occupancy status, and generate the rate limiting and degradation strategy based on the target degradation ratio and the target rate limiting rate; wherein, the target rate limiting rate is the parameter required by the client for local rate limiting based on the token bucket algorithm.
[0072] First, obtain the real-time resource usage status of the target client. This resource usage status can be determined by indicators such as CPU utilization, memory utilization, and network I / O load. Then, combine the target alarm duration range with the real-time resource status to determine the target rate limiting rate: If the target alarm duration range is 30 to 60 minutes and resources are sufficient, such as CPU utilization not exceeding 55% and memory utilization not exceeding 45%, then the target rate limiting rate is set to 75% to 85% of the client's rated maximum processing capacity. If resource indicators exceed the above thresholds, the rate is appropriately lowered. If the range is 60 to 90 minutes, regardless of resource sufficiency, the rate is controlled at 50% to 60% of the rated maximum processing capacity. If the range is 90 to 120 minutes or more, the rate is strictly limited to 30% to 50% of the rated maximum processing capacity. When resources are scarce, the rate may be further lowered to minimize the resource consumption of new alarms. Finally, a complete strategy is generated by combining the target degradation ratio and the target rate limiting rate: On the one hand, the processing rules for alarms of different priorities are clarified according to the degradation ratio, that is, the degradation type is received and processed proportionally, and the non-degradable type is received in full; on the other hand, the target rate limiting rate is configured as the core parameter of the token bucket algorithm. The algorithm generates tokens according to the target rate limiting rate. Each time the client processes a new alarm, it needs to obtain a token from the bucket. If there is no token, the new alarm will be rejected. In this way, a dynamic balance between alarm processing and resource space is achieved.
[0073] S104, the rate limiting and degradation policy is sent to the client so that the client can perform degradation operation on the alarm event based on the degradation ratio in the rate limiting and degradation policy, and perform rate limiting operation on the alarm event based on the rate limiting rate in the rate limiting and degradation policy.
[0074] In this embodiment, after the rate limiting and degradation policy is sent to the client, the client first implements priority isolation of alarm events through queue division, and then performs degradation and rate limiting operations respectively: On the one hand, alarm events of non-degradable type are sent to the first queue. These alarms are directly related to the core of business security, so the first thread directly prioritizes the alarm events in the first queue to avoid affecting the processing time due to queuing delays; on the other hand, alarm events of degradable type and alarm events of optional degradability type are uniformly sent to the second queue. The second thread strictly performs degradation operations on the alarm events in the second queue according to the degradation ratio specified in the rate limiting and degradation policy (such as 50% for degradable type and 100% for optional degradability type), selects the part that needs to be processed first, and postpones the processing of the remaining low-priority alarms. After completing the queue partitioning and degradation operations, the client also needs to perform rate limiting control on all pending alarms: based on the token bucket algorithm determined above, a token generation rate corresponding to the target rate limiting rate in the rate limiting and degradation strategy is generated. Then, a third thread performs rate limiting operations on alarm events in the first and second queues based on this token generation rate to ensure that the total alarm processing rate of the two types of queues does not exceed the target rate limiting rate and to avoid excessive resource consumption by new alarms.
[0075] It's important to note that the token bucket algorithm is a traffic shaping and rate limiting algorithm. Its core logic involves maintaining a "token bucket." The management end continuously generates tokens into the bucket according to a predetermined target rate limit, with each token corresponding to the processing permission for a new alarm. When a client needs to receive and process a new alarm (regardless of whether it comes from the first or second queue), it must first obtain a token from the bucket. If the bucket has sufficient tokens, it means the current number of new alarms has not exceeded the rate limit, and the alarm can proceed with the processing normally. If the bucket has no tokens, it means the current number of new alarms has reached the rate limit, and the client will directly reject the alarm. This avoids resource overload due to excessive alarm inflow, ensures that the first thread's priority processing of high-priority alarms is not interfered with, and guarantees stable processing of alarms already filtered in the second queue.
[0076] Figure 2The architecture for generating and executing alarm rate limiting and degradation policies is demonstrated. This architecture mainly consists of two modules: a management service and a client. The components interact with each other through data to achieve full-process control from alarm backlog monitoring to policy execution. The backlog acquirer in the management service periodically retrieves alarm backlog data from the target queue, passes it to the sliding window, and calculates information such as consumption rate based on time dimension statistics. Then, the policy calculator generates rate limiting and degradation policies based on these data and preset rules and sends them to the client. After receiving the policies, the grader on the client classifies alarm events according to priority and sends them to the corresponding queues. Finally, the token bucket generates tokens based on the rate limiting rate in the policy and performs rate limiting control on the alarm events waiting to be processed in the queue. At the same time, the client also reports data to the management service to ensure a balance between alarm processing priority and resource efficiency.
[0077] This application provides a method for adjusting rate limiting and degradation strategies in a security operation scenario, comprising: obtaining the number of backlogged alarms; wherein the number of backlogged alarms is the number of alarm events that have been generated but not consumed; determining the average consumption rate used to characterize the client's consumption rate level within a target time period; determining the expected alarm latency based on the number of backlogged alarms and the average consumption rate; generating a rate limiting and degradation strategy through the expected alarm latency and alarm priority weight; and distributing the rate limiting and degradation strategy to the client so that the client can perform graded degradation and rate limiting operations on alarms based on the rate limiting and degradation strategy.
[0078] In summary, this application dynamically calculates the expected alarm latency by combining the backlog of alarms with the average consumption rate representing the client's consumption rate level within the target time period. This overcomes the limitations of traditional static thresholds, avoiding false blocking of normal requests under fixed thresholds and reducing missed detections of attacks. Furthermore, this application automatically generates rate limiting and degradation policies based on the expected alarm latency and alarm priority weights, and distributes these policies to clients without manual intervention, solving the problem of traditional solutions relying on the experience of operations personnel. Finally, when generating rate limiting and degradation policies, this application differentiates alarm events based on alarm priority weights, ensuring that the service level agreements of core businesses remain unaffected in multi-tenant scenarios while avoiding both resource waste and critical service blockage.
[0079] This application also provides a device for adjusting rate limiting and degradation strategies in a secure operation scenario, a system for adjusting rate limiting and degradation strategies in a secure operation scenario, and a computer-readable storage medium, which have the above-mentioned beneficial effects, and will not be elaborated here.
[0080] The following describes the rate limiting and degradation strategy adjustment device for a secure operation scenario provided in the embodiments of this application.
[0081] Please refer to Figure 3 , Figure 3This is a schematic diagram of a device for adjusting rate limiting and degradation strategies in a secure operation scenario, provided in an embodiment of this application.
[0082] In this embodiment, the device may include:
[0083] The backlog alarm acquisition module 100 is used to acquire the number of backlog alarm events and determine the average consumption rate used to characterize the consumption rate level of the client within the target time period; wherein, the number of backlog alarm events is the number of alarm events that have been generated but not consumed and processed.
[0084] The time consumption determination module 200 is used to determine the expected alarm consumption time based on the backlog of alarm events and the average consumption rate.
[0085] The strategy determination module 300 is used to map the expected alarm duration to different alarm duration intervals, and generate a rate limiting and degradation strategy according to the matching rules between the alarm duration intervals and the preset alarm weights; wherein, the rate limiting and degradation strategy includes a degradation ratio and a rate limiting rate.
[0086] The policy distribution module 400 is used to send the rate limiting and degradation policy to the client, so that the client can perform degradation operation on the alarm event based on the degradation ratio in the rate limiting and degradation policy, and perform rate limiting operation on the alarm event based on the rate limiting rate in the rate limiting and degradation policy.
[0087] Figure 4 This is a schematic diagram of the structure of a rate limiting and degradation strategy adjustment system in a secure operation scenario provided in an embodiment of this application.
[0088] This application embodiment also provides a rate limiting and degradation policy adjustment system for a security operation scenario, which may include:
[0089] Memory, used to store computer programs;
[0090] The processor is used to execute the computer program to implement the steps of the rate limiting and degradation strategy adjustment method under the security operation scenario described in the above embodiments.
[0091] like Figure 4 The diagram shows the structural composition of a rate limiting and degradation policy adjustment system for a secure operation scenario. This system may include a processor 10, a memory 11, a communication interface 12, and a communication bus 13. The processor 10, memory 11, and communication interface 12 all communicate with each other via the communication bus 13.
[0092] In this embodiment, the processor 10 may be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic devices.
[0093] The processor 10 can call the program stored in the memory 11. Specifically, the processor 10 can execute the operations in the embodiment of the rate limiting and degradation strategy adjustment method in the security operation scenario.
[0094] The memory 11 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment, the memory 11 stores at least a program for implementing the following functions:
[0095] Obtain the number of backlogged alarm events and determine the average consumption rate used to characterize the client's consumption rate level within the target time period; wherein, the number of backlogged alarm events is the number of alarm events that have been generated but not consumed;
[0096] The expected alarm latency is determined based on the number of backlogged alarm events and the average consumption rate.
[0097] The expected alarm duration is mapped to different alarm duration intervals, and a rate limiting and degradation strategy is generated according to the matching rules between the alarm duration intervals and the preset alarm weights; wherein, the rate limiting and degradation strategy includes a degradation ratio and a rate limiting rate.
[0098] The rate limiting and degradation policy is sent to the client so that the client can perform degradation operations on alarm events based on the degradation ratio in the rate limiting and degradation policy, and perform rate limiting operations on alarm events based on the rate limiting rate in the rate limiting and degradation policy.
[0099] In one possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.
[0100] In addition, memory 11 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.
[0101] Communication interface 12 can be an interface for the communication module, used to connect with other devices or systems.
[0102] Of course, it should be noted that, Figure 4The structure shown does not constitute a limitation on the rate limiting and degradation policy adjustment system in the security operation scenario of this application embodiment. In practical applications, the rate limiting and degradation policy adjustment system in the security operation scenario may include more than Figure 4 More or fewer components as shown, or combinations of certain components.
[0103] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the rate limiting and degradation strategy adjustment method under the security operation scenario described in the above embodiments.
[0104] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0105] For a description of the computer-readable storage medium provided in this application, please refer to the above method embodiments; further details will not be repeated here.
[0106] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.
[0107] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0108] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0109] The foregoing has provided a detailed description of the method, apparatus, system, and medium for adjusting rate limiting and degradation strategies in a secure operation scenario, as provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A method for adjusting a throttling degradation policy in a secure operation scenario, characterized in that, The method comprises the following steps: acquiring the number of backlog alarm events and determining a consumption rate average value for representing the consumption rate level of the client in a target period; wherein the number of backlog alarm events is the number of alarm events that have been generated but not consumed and processed; determining an expected alarm time consumption based on the number of backlog alarm events and the consumption rate average value; mapping the expected alarm time consumption to different alarm time consumption intervals and generating a throttling degradation strategy according to the matching rule of the alarm time consumption intervals and preset alarm weights; wherein the throttling degradation strategy comprises a degradation ratio and a throttling rate; sending the throttling degradation strategy to the client, so that the client performs a degradation operation on the alarm events based on the degradation ratio in the throttling degradation strategy and performs a throttling operation on the alarm events based on the throttling rate in the throttling degradation strategy.
2. The method of claim 1, wherein, The method comprises the following steps: acquiring the consumption rate data reported by the client through a timing task; wherein the consumption rate data is the rate at which the client consumes and processes alarm events; calculating the average value of the consumption rate data in the target period in a sliding window to obtain the consumption rate average value.
3. The method of claim 1, wherein, The method comprises the following steps: determining the expected alarm time consumption based on the ratio between the number of backlog alarm events and the consumption rate average value.
4. The method of claim 1, wherein, The method comprises the following steps: configuring at least two alarm time consumption intervals and at least two alarm priority types; the alarm priority types are determined based on the business security priority of the alarm events, and different alarm priority types correspond to different preset alarm weights; establishing the mapping of the alarm time consumption intervals and the alarm priority types, and configuring a corresponding set of degradation ratios for each alarm priority type; different alarm time consumption intervals under the same alarm priority type correspond to different degradation ratios; comparing the expected alarm time consumption with each alarm time consumption interval to determine the target alarm time consumption interval corresponding to the expected alarm time consumption, the target alarm priority type corresponding to the target alarm time consumption interval, and the target degradation ratio corresponding to the target alarm time consumption interval; calculating a target throttling rate matching the target alarm time consumption interval based on the real-time resource occupation state, and generating the throttling degradation strategy based on the target degradation ratio and the target throttling rate; wherein the target throttling rate is a parameter required when the client performs local throttling based on the token bucket algorithm.
5. The method of claim 4, wherein, The alarm priority types comprise an un-degradable type, a degradable and non-degradable type, and a degradable type. The non-degradable type is an alarm of successful attack and non-vulnerability, or the non-degradable type is the first alarm; the degradable type is a false alarm, an alarm initiated by an external scanner, or an alarm of failed attack; the degradable and non-degradable type is other alarms except the non-degradable type and the degradable type; and the non-vulnerability is a state caused by external attack and affecting the attacked object.
6. The method of claim 5, wherein, The client is sent the traffic limiting and degradation strategy, so that the client performs a degradation operation on the alarm event based on the degradation ratio in the traffic limiting and degradation strategy, and performs a traffic limiting operation on the alarm event based on the traffic limiting rate in the traffic limiting and degradation strategy, including: The client is sent the traffic limiting and degradation strategy, so that the client sends the alarm event of the non-degradable type to a first queue, so that a first thread directly prioritizes the alarm event in the first queue, and sends the alarm event of the degradable type and the alarm event of the degradable and non-degradable type to a second queue, so that a second thread degrades the alarm event in the second queue according to the degradation ratio in the traffic limiting and degradation strategy, and then generates a token generation rate corresponding to the traffic limiting and degradation strategy based on the token bucket algorithm, so that a third thread limits the traffic of the alarm event in the first queue and the alarm event in the second queue based on the token generation rate.
7. The method of claim 1 to 6, wherein, The number of accumulated alarm events is obtained, including: The number of alarms stored in each partition in the target queue is queried at a fixed time through a management interface; The number of alarms stored in each partition is summarized to obtain the final number of accumulated alarm events.
8. A device for adjusting a flow limiting degradation strategy in a secure operation scenario, characterized in that, It includes: An accumulated alarm obtaining module is configured to obtain a number of accumulated alarm events and determine a consumption rate average value representing a consumption rate level of a client in a target period; wherein the number of accumulated alarm events is a number of alarm events that have been generated but not consumed and processed; A time consumption determining module is configured to determine an expected alarm time consumption based on the number of accumulated alarm events and the consumption rate average value; A strategy determining module is configured to map the expected alarm time consumption to different alarm time consumption intervals, and generate a traffic limiting and degradation strategy according to a matching rule between the alarm time consumption intervals and a preset alarm weight; wherein the traffic limiting and degradation strategy includes a degradation ratio and a traffic limiting rate; A strategy issuing module is configured to send the traffic limiting and degradation strategy to the client, so that the client performs a degradation operation on the alarm event based on the degradation ratio in the traffic limiting and degradation strategy, and performs a traffic limiting operation on the alarm event based on the traffic limiting rate in the traffic limiting and degradation strategy.
9. A system for adjusting rate limiting and degradation strategies in a secure operation scenario, characterized in that, It includes: A memory is configured to store a computer program; A processor is configured to execute the computer program to implement the steps of the traffic limiting and degradation strategy adjustment method in the safe operation scenario as claimed in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the traffic limiting and degradation strategy adjustment method in the safe operation scenario as claimed in any one of claims 1 to 7.