API (Application Program Interface) abnormal calling early warning method and system based on service flow base line, medium and product

Abstract

The invention provides an API abnormal call early warning method and system based on a service flow baseline, a medium and a product, and relates to the technical field of API call early warning. The method comprises the following steps: obtaining historical call log data of a plurality of API interfaces in a cross-domain data exchange system, extracting a service flow characteristic value from the historical call log data to determine a baseline flow interval of each API interface; obtaining a security level identifier of each data security domain in the cross-domain data exchange system, and determining a target deviation tolerance threshold value of each API interface according to the data flow direction relationship of each API interface and the security level identifier; and acquiring current service flow data of each API interface in real time, determining a deviation degree numerical value of the current service flow data and the baseline flow interval, and performing comparative analysis on the deviation degree numerical value and a target deviation tolerance threshold to generate API abnormal calling early warning information. The technical problem that the anomaly monitoring accuracy of API cross-different security domain data exchange is low in the related technology is solved.

Description

A method, system, medium, and product for API anomaly call early warning based on business traffic baseline. Technical Field

[0001] This application relates to the field of API call early warning technology, and in particular to an API abnormal call early warning method, system, medium and product based on business traffic baseline. Background Technology

[0002] With the rapid development of the digital economy and the deepening of globalization, cross-domain data exchange is playing an increasingly important role in key areas such as cross-border transaction data processing and data security management of the State Grid. Especially in complex network environments with multiple security domains, ensuring secure data exchange between different security domains in an isolated state has become a core challenge for ensuring data security and business continuity.

[0003] In related technologies, to ensure secure data exchange between different security domains under isolated conditions, a fixed-threshold-based API traffic anomaly monitoring method is typically adopted. Specifically, the system administrator first divides the network into multiple security domains and assigns a fixed security level identifier to each domain. Then, an API gateway is deployed in the cross-domain data exchange system to achieve logical isolation between different security domains. During system initialization, the administrator configures fixed traffic monitoring thresholds for each API interface based on business needs and security policies, including parameters such as maximum call frequency, data transfer volume limit, and response time threshold. When the real-time traffic data of an API interface exceeds the pre-configured fixed threshold, the anomaly monitoring module determines that the API interface has experienced abnormal call behavior and generates an alert; when the real-time traffic data does not exceed the fixed threshold, it is considered a normal call. Simultaneously, the system saves all API call records to the audit log for post-event analysis and compliance checks.

[0004] However, when using the above-mentioned API traffic anomaly monitoring method based on fixed thresholds, since all API interfaces across security domains use the same fixed monitoring threshold, and the actual security risks carried by API interfaces connecting different security domains are significantly different, the unified fixed threshold is difficult to differentiate between different security domains. This may lead to inaccurate monitoring of abnormal API call behavior in high-risk security domain cross-domain scenarios, resulting in low accuracy of anomaly monitoring for API data exchange across different security domains in related technologies. Summary of the Invention

[0005] This application provides a method, system, medium, and product for API abnormal call early warning based on business traffic baseline, which can improve the accuracy of abnormal monitoring of API data exchange across different security domains.

[0006] Firstly, this application provides an API abnormal call early warning method based on a business traffic baseline, applied to the aforementioned API abnormal call early warning system. The method includes: acquiring historical call log data of multiple API interfaces in a cross-domain data exchange system; dividing the historical call log data into multiple time windows; extracting business traffic feature values ​​from each time window to obtain a multi-dimensional traffic feature sequence for each API interface; performing volatility analysis on the multi-dimensional traffic feature sequence; selecting a set of stable time windows from the multiple time windows whose traffic volatility coefficient is less than a preset stable threshold; and using the business traffic feature values ​​in the stable time window set to determine the baseline traffic range for each API interface; acquiring historical call log data of multiple API interfaces in a cross-domain data exchange system; and extracting historical call log data of multiple API interfaces from a cross-domain data exchange system. Each data security domain is identified by a security level identifier. A mapping table is established between each API interface and each data security domain based on the data flow relationship and security level identifier. This mapping table records the source and target security domain levels connected to each API interface. The security level span value for each API interface is determined based on the source and target security domain levels, and the target deviation tolerance threshold for each API interface is determined based on the security level span value. Real-time collection of current business traffic data for each API interface is used to determine the deviation value between the current business traffic data and the baseline traffic range. A differential threshold comparison analysis is performed between the deviation value and the target deviation tolerance threshold to generate API abnormal call warning information.

[0007] By adopting the above technical solution, historical call log data is divided into multiple time windows and business traffic feature values ​​are extracted. The resulting multi-dimensional traffic feature sequence can comprehensively reflect the call patterns of each API interface in different time periods. The stable time window set selected by volatility analysis eliminates interference data during abnormal fluctuation periods, making the baseline traffic range more accurately represent the normal business state. At the same time, by establishing a mapping relationship table between API interfaces and data security domains, the difference between the source security domain level and the target security domain level is quantified as a security level span value. This span value is inversely correlated with the target deviation tolerance threshold, realizing a differentiated strategy of stricter monitoring for high-risk cross-domain interfaces and moderately relaxed monitoring for low-risk interfaces. When the real-time collected business traffic data is compared with the differentiated target deviation tolerance threshold after deviation calculation, real anomalies can be accurately identified while normal business fluctuations are filtered out. This solves the technical problem of low accuracy in anomaly monitoring of API data exchange across different security domains in related technologies, achieving the technical effect of high accuracy in anomaly monitoring of API data exchange across different security domains.

[0008] Optionally, the step of performing volatility analysis on the multidimensional traffic feature sequence, filtering out a set of stable time windows with traffic volatility coefficients less than a preset stability threshold from the multiple time windows, and determining the baseline traffic range of each API interface using the business traffic feature values ​​in the set of stable time windows, specifically includes: determining the first total call frequency, data transmission volume, and response duration of each API interface within each time window; determining the traffic volatility coefficient of each time window based on the first total call frequency, the data transmission volume, and the response duration; and performing a stability comparison analysis between the traffic volatility coefficient of each time window and the preset stability threshold to filter out multiple candidate APIs with traffic volatility coefficients less than the preset stability threshold. A stable window is established; the multiple time windows are converted into a continuous time window sequence, and the time continuity of the multiple candidate stable windows is detected to determine a target stable window group that is continuously distributed on the time window sequence, and the average traffic fluctuation coefficient of the target stable window group is determined; when the average traffic fluctuation coefficient meets a preset continuity condition, the target stable window group is determined as the stable time window set; the service traffic feature values ​​of each stable time window are extracted from the stable time window set; the service traffic feature values ​​are statistically analyzed to determine the upper quartile of the service traffic feature values ​​as the upper limit of the baseline traffic interval, and the lower quartile of the service traffic feature values ​​as the lower limit of the baseline traffic interval.

[0009] By adopting the above technical solution, three dimensions of indicators—the first total call frequency, data transmission volume, and response time—are extracted from the multidimensional traffic feature sequence. The comprehensive calculation of these indicators forms the traffic fluctuation coefficient, which can comprehensively evaluate the stability of the time window. The selected candidate stable windows are formed into a target stable window group after time continuity detection, ensuring that the baseline data comes from a continuous and stable business cycle rather than an occasional stable period. The secondary verification of the average traffic fluctuation coefficient further ensures the reliability of the stable time window set. The business traffic feature values ​​extracted from this set are used to determine the upper and lower limits of the baseline traffic range through quartile statistical analysis, so that the baseline can accommodate normal business fluctuations and effectively define the abnormal range.

[0010] Optionally, the step of determining the security level span value of each API interface based on the source security domain level and the target security domain level, and determining the target deviation tolerance threshold of each API interface based on the security level span value, specifically includes: obtaining the source security domain value corresponding to the source security domain level and the target security domain value corresponding to the target security domain level; determining the absolute deviation value between the source security domain value and the target security domain value; using the absolute deviation value as the initial security level span value; obtaining historical abnormal call records for each API interface; and determining the abnormal call frequency of the security level crossing type from the historical abnormal call records, wherein the abnormal call frequency is the number of abnormal calls that occur when crossing different data security domains; and determining the target deviation tolerance threshold of each API interface based on the abnormal call frequency. A security risk correction factor for the PI interface, wherein the security risk correction factor characterizes the degree of influence of the historical abnormal call records on the security level span value; the security level span value is determined based on the initial security level span value and the security risk correction factor; a reverse mapping relationship between the security level span value and the target deviation tolerance threshold is constructed, and the security level span value is converted into the initial target deviation tolerance threshold based on the reverse mapping relationship; the business importance level identifier of each API interface is obtained, and a business tolerance adjustment coefficient is determined based on the business importance level identifier, wherein the business tolerance adjustment coefficient is used to differentiate the deviation tolerance level according to the business importance level; the target deviation tolerance threshold is determined based on the initial target deviation tolerance threshold and the business tolerance adjustment coefficient.

[0011] By adopting the above technical solutions, the absolute deviation between the source security domain value and the target security domain value quantifies the static risk level of cross-domain data exchange. The frequency of abnormal calls in the historical abnormal call records reflects the historical risk characteristics of the interface. The security risk correction factor incorporates historical risk experience into the calculation of the security level span value, so that the final security level span value comprehensively reflects the static architecture risk and historical operational risk. Through the reverse mapping relationship, the security level span value is converted into the initial target deviation tolerance threshold, realizing the monitoring logic that the higher the risk, the lower the tolerance. The business tolerance adjustment coefficient introduced by the business importance level identifier makes a secondary adjustment to the initial target deviation tolerance threshold, so that the core business interface is subject to stricter monitoring while the auxiliary interface is appropriately relaxed. This multi-level risk assessment and tolerance adjustment mechanism ensures that the monitoring strategy of each interface is accurately matched with its actual risk characteristics.

[0012] Optionally, determining the security risk correction factor for each API interface based on the abnormal call frequency specifically includes: obtaining a preset historical observation period and determining the second total call frequency of each API interface within the historical observation period; performing a ratio analysis on the second total call frequency and the abnormal call frequency to obtain an abnormal call ratio parameter for each API interface; obtaining abnormal attribute information from the historical abnormal call records and performing hierarchical processing on the historical abnormal call records based on the abnormal attribute information to obtain an abnormal call hierarchical result; using the abnormal call hierarchical result to differentiate the abnormal call frequency to obtain a comprehensive abnormal assessment parameter for each API interface; and mapping the comprehensive abnormal assessment parameter and the abnormal call ratio parameter according to preset mapping requirements to obtain the security risk correction factor.

[0013] By adopting the above technical solution, the second total call frequency provides a baseline reference for the abnormal call frequency. The abnormal call ratio parameter obtained from the ratio analysis of the two reflects the relative abnormality rate of the interface. The hierarchical processing guided by the abnormal attribute information assigns differentiated weights to abnormalities of different severity, so that high-risk abnormalities occupy a larger proportion in the comprehensive abnormality assessment parameters. The differentiated processing of abnormal call classification results and abnormal call frequency avoids the assessment bias caused by simple counting. The comprehensive abnormality assessment parameters and abnormal call ratio parameters are converted into security risk correction factors through preset mapping requirements. This comprehensive quantification of multi-dimensional abnormal characteristics ensures that the correction factor can accurately reflect the historical risk level of the interface, providing a precise risk adjustment basis for determining the subsequent deviation of the target from the tolerance threshold.

[0014] Optionally, the step of using the abnormal call classification results to differentiate the frequency of abnormal calls to obtain the comprehensive abnormal assessment parameters for each API interface specifically includes: extracting the number of abnormal call records corresponding to each abnormal level from the abnormal call classification results, and configuring an impact parameter for each abnormal level, wherein the impact parameter is used to characterize the influence intensity of different abnormal levels on the comprehensive abnormal assessment value; associating the number of abnormal call records with the corresponding impact parameter to obtain the classification impact parameter for each abnormal level; obtaining the occurrence timestamp information of each abnormal call in the historical abnormal call records, and determining the time span of each abnormal call from the current time based on the occurrence timestamp information; configuring a timeliness adjustment parameter for each abnormal call based on the time span; and associating the classification impact parameter with the corresponding timeliness adjustment parameter to obtain the comprehensive abnormal assessment parameters.

[0015] By adopting the above technical solution, the correlation processing between the number of abnormal call records for each abnormal level and the corresponding impact parameter realizes the quantitative expression of the severity of the abnormality. The graded impact parameter reflects the differentiated impact intensity of different levels of abnormalities. The time span of the conversion of the timestamp information reflects the timeliness characteristics of the abnormality. The configuration of the timeliness adjustment parameter makes recent abnormalities receive higher weights while the impact of long-term abnormalities decreases. The comprehensive abnormality assessment parameter generated by the correlation processing of the graded impact parameter and the timeliness adjustment parameter takes into account both the severity and timeliness of the abnormality. This spatiotemporal weighting mechanism ensures that the reference value of historical abnormal data decreases reasonably over time, so that the comprehensive abnormality assessment parameter can accurately reflect the current actual risk status of the interface.

[0016] Optionally, the real-time acquisition of current business traffic data for each API interface and the determination of the deviation value between the current business traffic data and the baseline traffic range specifically includes: performing a numerical range comparison analysis between the real-time acquired current business traffic data and the baseline traffic range to determine whether the current business traffic data is within the baseline traffic range; when it is determined that the current business traffic data is within the baseline traffic range, setting the deviation value to zero; when it is determined that the current business traffic data is less than the lower limit of the baseline traffic range, determining the negative deviation difference between the lower limit of the baseline traffic range and the current business traffic data, and determining the ratio of the negative deviation difference to the lower limit of the baseline traffic range as the lower deviation ratio; when it is determined that the current business traffic data is greater than the upper limit of the baseline traffic range, determining the positive excess difference between the current business traffic data and the upper limit of the baseline traffic range, and determining the ratio of the positive excess difference to the upper limit of the baseline traffic range as the upper deviation ratio; and using the lower deviation ratio or the upper deviation ratio as the deviation value.

[0017] By adopting the above technical solution, the current business traffic data can be compared with the baseline traffic range to quickly determine the traffic status. If the traffic is within the range, the deviation is set to zero to avoid unnecessary calculation overhead. The ratio of the negative deviation difference to the lower limit converts insufficient traffic into relative deviation. The ratio of the positive deviation difference to the upper limit converts overload traffic into relative deviation. This relative ratio calculation method eliminates the evaluation bias caused by the difference in the absolute value of the baseline, making the deviation of interfaces of different magnitudes comparable. The bidirectional detection mechanism of the lower deviation ratio and the upper deviation ratio ensures that the system can simultaneously identify two risk scenarios: abnormal increase and abnormal decrease in traffic, providing a standardized deviation metric for subsequent differential threshold comparison.

[0018] Optionally, the step of performing a differential threshold comparison analysis between the deviation value and the target deviation tolerance threshold to generate API abnormal call warning information specifically includes: obtaining the real-time business scenario identifier of each API interface, and determining the business activity level of the current time period based on the real-time business scenario identifier; differentially adjusting the target deviation tolerance threshold based on the business activity level to obtain a real-time deviation tolerance threshold corresponding to the current business scenario; performing a numerical comparison analysis between the deviation value and the real-time deviation tolerance threshold to determine whether the deviation value is greater than the real-time deviation tolerance threshold; when it is determined that the deviation value is greater than the real-time deviation tolerance threshold, determining the abnormal severity level of each API interface based on the deviation difference between the deviation value and the real-time deviation tolerance threshold; generating abnormal call description information based on the abnormal severity level, the identifier information of each API interface, and the current business traffic data; and using the abnormal call description information, the deviation value, the real-time deviation tolerance threshold, and the abnormal severity level as the API abnormal call warning information.

[0019] By adopting the above technical solution, the business activity level mapped by the real-time business scenario identifier reflects the current business operation status. The differentiated adjustment of the target deviation tolerance threshold generates the real-time deviation tolerance threshold, enabling the monitoring strategy to adapt to the differentiated changes in business scenarios. The comparison and analysis between the deviation value and the real-time deviation tolerance threshold accurately determines the abnormal state. The abnormal severity level quantified by the deviation difference provides a basis for alarm classification. The abnormal call description information generated by the combination of abnormal severity level, interface identification information and current business traffic data provides a complete abnormal context. The API abnormal call early warning information formed by integrating these information elements contains both quantitative deviation indicators and qualitative scenario descriptions, providing comprehensive decision support information for operation and maintenance personnel.

[0020] Secondly, embodiments of this application provide an API abnormal call warning system, which includes: one or more processors and a memory; the memory is coupled to one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the API abnormal call warning system to perform the method described in the first aspect and any possible implementation of the first aspect.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an API abnormal call warning system, cause the API abnormal call warning system to execute the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an API abnormal call warning system, cause the API abnormal call warning system to perform the method described in the first aspect and any possible implementation thereof. Attached Figure Description

[0023] Figure 1 is a flowchart of an API abnormal call warning method based on business traffic baseline in an embodiment of this application; Figure 2 is a schematic diagram of a physical device structure of an API abnormal call warning system in an embodiment of this application. Detailed Implementation

[0024] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0025] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0026] This application provides an API abnormal call early warning method based on business traffic baseline. Referring to Figure 1, Figure 1 is a flowchart of an API abnormal call early warning method based on business traffic baseline in an embodiment of this application, including the following steps: Step S101, obtain historical call log data of multiple API interfaces in a cross-domain data exchange system, divide the historical call log data into multiple time windows, and extract business traffic feature values ​​from each time window to obtain a multi-dimensional traffic feature sequence for each API interface; Step S102, perform volatility analysis on the multi-dimensional traffic feature sequence, select a set of stable time windows from the multiple time windows whose traffic volatility coefficient is less than a preset stable threshold, and use the business traffic feature values ​​in the stable time window set to determine the baseline traffic range for each API interface; Step S103, Step S104, Step S105, Step S106, Step S107, Step S108, Step S109, Step S10 ... Step S103: Obtain the security level identifier of each data security domain in the cross-domain data exchange system, and establish a mapping relationship table between each API interface and each data security domain based on the data flow relationship and security level identifier of each API interface. The mapping relationship table is used to record the source security domain level and target security domain level connected to each API interface; Step S104: Determine the security level span value of each API interface based on the source security domain level and target security domain level, and determine the target deviation tolerance threshold of each API interface based on the security level span value; Step S105: Collect the current business traffic data of each API interface in real time, determine the deviation value between the current business traffic data and the baseline traffic range, and perform differential threshold comparison analysis between the deviation value and the target deviation tolerance threshold to generate API abnormal call warning information.

[0027] In the above embodiment, a cross-domain data exchange system is applied to a bonded logistics center. This bonded logistics center handles data processing tasks for various trade methods, including bonded business and cross-border e-commerce, requiring secure exchange of business data between different security domains under isolated conditions. Initially, historical call logs of multiple API interfaces in the cross-domain data exchange system are acquired. These API interfaces include interfaces for connecting to a customs system's declaration and verification list, interfaces for connecting to a cross-border e-commerce public service platform's order push, and interfaces for connecting to a bonded warehouse management system's goods in / out system. API call logs are continuously collected for 30 days using a data acquisition front-end, recorded every 5 minutes. The log data includes fields such as call timestamp, source IP address, target interface identifier, request body size, and response time. The collected historical call log data is divided into 1440 time windows according to the time dimension, i.e., 48 30-minute time windows per day, totaling 1440 time windows over 30 days. Business traffic characteristic values ​​are extracted from each time window, including API call frequency, average response time, and data transmission volume, forming a multi-dimensional traffic characteristic sequence for each API interface. A volatility analysis was performed on the multidimensional traffic characteristic sequence, and the ratio of the standard deviation to the mean of the traffic characteristic values ​​within each time window was calculated as the traffic volatility coefficient. When the traffic volatility coefficient was less than 0.2, the time window was considered a stable time window. 936 stable time windows were selected from 1440 time windows to form a stable time window set. Using the business traffic characteristic values ​​from these 936 stable time windows, the mean and standard deviation of traffic for each API interface in different business periods were calculated to determine the baseline traffic range. For example, the baseline traffic range for the verification list application interface was 120 to 180 calls per minute from 9:00 AM to 11:00 AM on weekdays, while it was 5 to 15 calls per minute from 2:00 AM to 4:00 AM.

[0028] In the above embodiments, the security level identifiers of each data security domain in the cross-domain data exchange system are obtained. Based on business characteristics and regulatory requirements, the entire system is divided into four security domains: the customs supervision domain is set to the highest security level of 4, the bonded logistics warehouse domain is set to level 3, the cross-border e-commerce platform domain is set to level 2, and the enterprise declaration system domain is set to level 1. A mapping table between API interfaces and each data security domain is established based on the data flow relationship and security level identifier of each API interface. For example, the source security domain connected to the enterprise declaration data push interface is the enterprise declaration system domain, level 1, and the target security domain is the customs supervision domain, level 4. The source security domain connected to the release order query interface is the bonded logistics warehouse domain, level 3, and the target security domain is the customs supervision domain, level 4. The security level span value of each API interface is determined based on the absolute value of the difference between the source security domain level and the target security domain level. The security level span value of the enterprise declaration data push interface is |1-4|=3, and the security level span value of the release order query interface is |3-4|=1. A larger security level span indicates a higher security risk in cross-domain data exchange involving the interface, requiring more stringent monitoring. The target deviation tolerance threshold for each API interface is determined based on the negative correlation between the security level span value and the target deviation tolerance threshold. This negative correlation can be expressed as: Target Deviation Tolerance Threshold = Baseline Tolerance Threshold - Adjustment Factor × Security Level Span Value, where the baseline tolerance threshold is set to 40% and the adjustment factor is set to 5%. Based on this correlation, the target deviation tolerance threshold for the enterprise declaration data push interface with a security level span of 3 is 40% - 5% × 3 = 25%; the target deviation tolerance threshold for the release order query interface with a security level span of 1 is 40% - 5% × 1 = 35%. Current business traffic data for each API interface is collected in real-time every 30 seconds. The current business traffic data is compared with the baseline traffic range for the corresponding time period to calculate the deviation value. When the current business traffic data is within the baseline traffic range, the deviation value is zero. When the current business traffic data exceeds the upper limit of the baseline traffic range, the deviation value is the ratio of the difference between the current business traffic data and the upper limit of the baseline traffic range to the upper limit of the baseline traffic range. For example, at 10:00 AM on a certain weekday, the current call frequency of the enterprise application data push interface is 260 times per minute, while the upper limit of the baseline traffic range for that period is 180 times. The deviation value is (260-180) / 180=44.4%. The target deviation tolerance threshold for this interface is 25%. Comparing the deviation value of 44.4% with the target deviation tolerance threshold of 25%, since the deviation value is greater than the target deviation tolerance threshold, an API abnormal call warning message containing the abnormal interface identifier, deviation degree, and occurrence timestamp is immediately generated and pushed to the monitoring terminal of the park management platform.

[0029] Through the above steps, historical call log data is divided into multiple time windows, and business traffic feature values ​​are extracted. The resulting multi-dimensional traffic feature sequence can comprehensively reflect the call patterns of each API interface at different times. The stable time window set selected by volatility analysis eliminates interference data during abnormal fluctuation periods, making the baseline traffic range more accurately represent the normal business state. Simultaneously, by establishing a mapping table between API interfaces and data security domains, the difference between the source security domain level and the target security domain level is quantified as a security level span value. This span value is inversely correlated with the target deviation tolerance threshold, enabling a differentiated strategy of stricter monitoring for high-risk cross-domain interfaces and moderately relaxed monitoring for low-risk interfaces. When the real-time collected business traffic data is compared with the differentiated target deviation tolerance threshold after deviation calculation, it can accurately identify real anomalies while filtering out normal business fluctuations. This solves the technical problem of low accuracy in anomaly monitoring for API data exchange across different security domains in related technologies, achieving the technical effect of high accuracy in anomaly monitoring for API data exchange across different security domains.

[0030] The entity performing the above steps may be a system, a device, a controller or processor in a device or system, a standalone controller or processor, or other processing devices or processing units with similar processing functions, but is not limited to these.

[0031] In an optional embodiment, volatility analysis is performed on the multidimensional traffic feature sequence. A set of stable time windows with traffic volatility coefficients less than a preset stability threshold is selected from multiple time windows. The baseline traffic range for each API interface is determined using the business traffic feature values ​​in the stable time window set. Specifically, this includes: determining the first total call frequency, data transmission volume, and response time for each API interface within each time window; determining the traffic volatility coefficient for each time window based on the first total call frequency, data transmission volume, and response time; and performing a stability comparison analysis between the traffic volatility coefficient of each time window and the preset stability threshold to select multiple time windows with traffic volatility coefficients less than the preset stability threshold. Candidate stable windows; convert multiple time windows into a continuous time window sequence, perform time continuity detection on multiple candidate stable windows to determine the target stable window group that is continuously distributed on the time window sequence, and determine the average traffic fluctuation coefficient of the target stable window group; when the average traffic fluctuation coefficient meets the preset continuity condition, the target stable window group is determined as the stable time window set; extract the service traffic feature values ​​of each stable time window from the stable time window set; perform statistical analysis on the service traffic feature values ​​to determine the upper quartile of the service traffic feature values ​​as the upper limit of the baseline traffic interval, and the lower quartile of the service traffic feature values ​​as the lower limit of the baseline traffic interval.

[0032] In the above embodiment, it is assumed that it is necessary to accurately identify stable time periods that can represent normal business patterns from massive historical call data to provide a reliable data foundation for baseline construction. First, an in-depth volatility analysis of the multi-dimensional traffic characteristic sequence is conducted. For the API declaration interface, three core indicators are determined for each time window: the first total call frequency, data transmission volume, and response time. For example, within the time window from 9:00 AM to 9:30 AM on weekdays, the first total call frequency of this interface is 3600 times, the data transmission volume is 1.2GB, and the average response time is 85 milliseconds. The traffic fluctuation coefficient is calculated based on these three indicators. The specific calculation method is as follows: First, calculate the coefficient of variation (the ratio of standard deviation to mean) of each indicator within the time window, obtaining the coefficient of variation for call frequency (CV1) = 0.15, data transmission volume (CV2) = 0.22, and response time (CV3) = 0.18. Then, calculate the traffic fluctuation coefficient using a weighted summation method, where the weight for call frequency is set to 0.5, the weight for data transmission volume is set to 0.3, and the weight for response time is set to 0.2. The traffic fluctuation coefficient for this time window is calculated as: 0.5 × 0.15 + 0.3 × 0.22 + 0.2 × 0.18 = 0.075 + 0.066 + 0.036 = 0.177, approximately 0.18. The traffic fluctuation coefficient for each time window is then compared and analyzed with a preset stability threshold of 0.25.

[0033] In the above embodiment, 436 candidate stable windows with a flow fluctuation coefficient less than 0.25 were selected from 672 time windows over 14 consecutive days. These candidate stable windows are mainly distributed during regular office hours on weekdays and off-peak hours at night, reflecting the cyclical characteristics of bonded business. The 672 time windows were converted into a continuous time window sequence, and the time continuity of the 436 candidate stable windows was detected. By scanning the time sequence, multiple continuously distributed stable window groups were identified. For example, a target stable window group containing 6 continuous windows was formed from 8:30 am to 11:30 am on weekdays. The flow fluctuation coefficients of the 6 windows in this group are 0.14, 0.16, 0.18, 0.15, 0.17, and 0.16, respectively, and the average flow fluctuation coefficient is (0.14+0.16+0.18+0.15+0.17+0.16) / 6=0.16. The preset continuity conditions include two criteria: an average flow fluctuation coefficient less than 0.2 and a number of consecutive windows of no less than 4. The target stable window group has an average flow fluctuation coefficient of 0.16, which is less than 0.2, and a number of consecutive windows of 6, which is greater than 4. Therefore, it is deemed to meet the preset continuity conditions and is included in the stable time window set. The final stable time window set contains 328 time windows, covering 82% of weekday office hours and 65% of holidays.

[0034] In the above embodiment, the business traffic characteristic values ​​of each stable time window are extracted from the stable time window set for statistical analysis. Taking the registration list declaration interface as an example, the system extracts call frequency data from 328 stable time windows to form an ordered dataset. The quartiles are calculated as follows: the 328 call frequency data are arranged in ascending order, the lower quartile Q1 is the interpolation result of the (328+1)×25%=82.25th bit of data, and the upper quartile Q3 is the interpolation result of the (328+1)×75%=246.75th bit of data. The calculated lower quartile Q1 is 45 calls per minute, and the upper quartile Q3 is 165 calls per minute. The Q3 value of 165 calls is determined as the upper limit of the baseline traffic range, and the Q1 value of 45 calls is determined as the lower limit of the baseline traffic range, thus establishing the normal traffic range of the interface under stable business conditions, that is, the baseline traffic range is [45 times / minute, 165 times / minute].

[0035] In an optional embodiment, the security level span value of each API interface is determined based on the source security domain level and the target security domain level, and the target deviation tolerance threshold of each API interface is determined based on the security level span value. Specifically, this includes: obtaining the source security domain value corresponding to the source security domain level and the target security domain value corresponding to the target security domain level; determining the absolute deviation value between the source security domain value and the target security domain value; using the absolute deviation value as the initial security level span value; obtaining historical abnormal call records for each API interface; and determining the frequency of abnormal calls of different security level crossing types from the historical abnormal call records, where the abnormal call frequency is the number of abnormal calls occurring when crossing different data security domains; and determining the target deviation tolerance threshold for each API interface based on the abnormal call frequency. The security risk correction factor for the API interface represents the degree of impact of historical abnormal call records on the security level span value. The security level span value is determined based on the initial security level span value and the security risk correction factor. A reverse mapping relationship is constructed between the security level span value and the target deviation tolerance threshold, and the security level span value is converted into the initial target deviation tolerance threshold based on the reverse mapping relationship. The business importance level identifier for each API interface is obtained, and a business tolerance adjustment coefficient is determined based on the business importance level. This business tolerance adjustment coefficient is used to differentiate the deviation tolerance level according to the business importance level. Finally, the target deviation tolerance threshold is determined based on the initial target deviation tolerance threshold and the business tolerance adjustment coefficient.

[0036] In the above embodiments, in the actual application of bonded logistics centers, different API interfaces carry data exchange tasks with different security levels, requiring corresponding monitoring strategies to be set according to their security risk characteristics. First, the source security domain value corresponding to the source security domain level and the target security domain value corresponding to the target security domain level are obtained. Taking the bonded logistics order declaration interface as an example, the source security domain connected to this interface is the enterprise declaration system domain, with a corresponding source security domain value of 1, and the target security domain is the customs supervision domain, with a corresponding target security domain value of 4. The absolute deviation between the source security domain value 1 and the target security domain value 4 is calculated as |1-4|=3, and this value is used as the initial security level span value for this interface. In contrast, the vehicle card passage information query interface connects to the checkpoint management domain, with a value of 2, and the bonded warehouse domain, with a value of 3. Its initial security level span value is |2-3|=1, reflecting the difference in security risks between different interfaces in cross-domain data exchange.

[0037] In the above embodiments, historical abnormal call records for each API interface over the past 90 days are obtained, with a focus on analyzing the frequency of abnormal calls across security level ranges. The bonded logistics order declaration interface experienced 12 abnormal calls during the process of crossing the enterprise domain to the customs domain, including 8 unauthorized access attempts and 4 data format mismatches. These abnormal calls mainly occurred during the peak declaration period at the beginning of the month, reflecting the security risk characteristics of this interface under high load. A security risk correction factor is determined based on the frequency of abnormal calls; this factor characterizes the degree of influence of historical abnormal call records on the security level range value. The specific calculation method is as follows: First, obtain the total call frequency of the interface within a 90-day observation period. The total call frequency of the bonded logistics order declaration interface is 86,400 times. Then, calculate the abnormal call ratio, that is, the ratio of abnormal call frequency to total call frequency, which is 12 / 86,400 = 0.000139. Finally, determine the correction factor based on the mapping relationship between the abnormal call ratio and the security risk correction factor. The mapping relationship is: Security risk correction factor = 1 + Abnormal call ratio × Amplification coefficient, where the amplification coefficient is set to 2880 according to the severity of the abnormality (this amplification coefficient can be determined based on the system's historical operating data and security policy requirements). Therefore, the security risk correction factor of this interface = 1 + 0.000139 × 2880 = 1 + 0.4 = 1.4, indicating that historical abnormal records have a significant amplification effect on the security level span value.

[0038] In the above embodiment, the final security level span value is determined based on the initial security level span value and the security risk correction factor. Specifically, the calculation method is: Security Level Span Value = Initial Security Level Span Value × Security Risk Correction Factor. The security level span value of the bonded logistics order declaration interface = 3 × 1.4 = 4.2. This value comprehensively reflects the static security level differences and historical risk characteristics of the interface, providing an accurate basis for determining the subsequent target deviation tolerance threshold. A reverse mapping relationship between the security level span value and the target deviation tolerance threshold is constructed. The larger the security level span value, the higher the security risk of the interface, requiring a more stringent target deviation tolerance threshold. The specific mapping rule adopts a piecewise function form: when the security level span value S∈[0,2), the initial target deviation tolerance threshold T0=45%; when S∈[2,4), T0=35%; when S≥4, T0=25%. The security level span value of the bonded logistics order declaration interface is 4.2, satisfying the condition S≥4, therefore its initial target deviation tolerance threshold is set to 25%.

[0039] In the above embodiments, the business importance level identifier of each API interface is further obtained. The bonded logistics order declaration interface is identified as a core business interface with a business importance level of the highest level, level 3; the vehicle card passage information query interface is an auxiliary business interface with a business importance level of level 2; and the statistical report query interface is a normal business interface with a business importance level of level 1. A business tolerance adjustment coefficient is determined based on the business importance level identifier. This coefficient is used to differentiate the deviation tolerance level according to the business importance level. The mapping rule is: the business importance level and the business tolerance adjustment coefficient are negatively correlated; the higher the level, the smaller the adjustment coefficient. Specifically, the adjustment coefficient for level 3 core business is 0.8, for level 2 auxiliary business is 1.0, and for level 1 normal business is 1.2. The final target deviation tolerance threshold is calculated based on the initial target deviation tolerance threshold and the business tolerance adjustment coefficient as follows: Target deviation tolerance threshold = Initial target deviation tolerance threshold × Business tolerance adjustment coefficient. The target deviation tolerance threshold for the bonded logistics order declaration interface = 25% × 0.8 = 20%. This means that an alert will be triggered when the traffic of this interface deviates from the baseline by more than 20%, reflecting the strict monitoring requirements for core business interfaces with high security risks.

[0040] In an optional embodiment, the security risk correction factor for each API interface is determined based on the frequency of abnormal calls. Specifically, this includes: obtaining a preset historical observation period and determining the second total call frequency for each API interface within that period; performing a ratio analysis between the second total call frequency and the abnormal call frequency to obtain an abnormal call ratio parameter for each API interface; obtaining abnormal attribute information from historical abnormal call records and classifying these records according to the abnormal attribute information to obtain an abnormal call classification result; using the abnormal call classification result to differentiate the abnormal call frequency to obtain a comprehensive abnormal assessment parameter for each API interface; and mapping the comprehensive abnormal assessment parameter and the abnormal call ratio parameter according to preset mapping requirements to obtain the security risk correction factor.

[0041] In the above embodiment, a preset historical observation period is first obtained, assumed to be 90 days. This period can cover sufficient changes in business scenarios while ensuring the timeliness of the data. The second total call frequency of the verification and registration list declaration interface within these 90 days is determined to be 486,000 times, averaging 5,400 calls per day. This basic data provides an important reference for subsequent calculation of the anomaly ratio. A ratio analysis is performed on the second total call frequency and the anomaly call frequency, specifically calculated as follows: Anomaly call ratio parameter = Anomaly call frequency / Second total call frequency × 100%. The anomaly call ratio parameter of the verification and registration list declaration interface = 12 / 486,000 × 100% = 0.00247%. Although this ratio seems small, considering the sensitivity of customs supervision data involved in this interface, even a very low anomaly ratio requires high attention. In contrast, while the ordinary statistical query interface had a higher total call frequency of 720,000, its abnormal call frequency was only 3 times. The abnormal call ratio parameter = 3 / 720,000 × 100% = 0.00042%, reflecting a significant difference in security risk between different interfaces. The system retrieves abnormal attribute information from historical abnormal call records, including abnormal type, occurrence time, source IP address, error code, and other detailed information. Based on this abnormal attribute information, the system performs hierarchical processing on historical abnormal call records, resulting in an abnormal call classification result. The specific classification criteria and corresponding weight coefficients are as follows: unauthorized access attempts are classified as high-risk abnormalities with a weight coefficient of 3; data format errors are classified as medium-risk abnormalities with a weight coefficient of 2; and timeouts or network abnormalities are classified as low-risk abnormalities with a weight coefficient of 1. Of the 12 abnormal calls to the verification list declaration interface, there were 8 high-risk abnormalities of unauthorized access, 3 medium-risk abnormalities of data format errors, and 1 low-risk abnormality of network timeout, forming a complete abnormal call classification result.

[0042] In the above embodiment, the frequency of abnormal calls is differentiated based on the results of the abnormal call classification, and a comprehensive abnormality assessment parameter is calculated for each API interface. The specific calculation method for the differentiated processing is: Comprehensive abnormality assessment parameter = Σ(number of abnormal calls at each level × corresponding weight coefficient) / number of days in the historical observation period. The calculation process for the comprehensive abnormality assessment parameter of the API interface for the verification and registration list is as follows: high-risk abnormality contribution value = 8 × 3 = 24 points, medium-risk abnormality contribution value = 3 × 2 = 6 points, low-risk abnormality contribution value = 1 × 1 = 1 point, weighted total score = 24 + 6 + 1 = 31 points. Comprehensive abnormality assessment parameter = 31 / 90 = 0.344. This parameter not only reflects the number of abnormalities but also the distribution of the severity of abnormalities. The comprehensive abnormality assessment parameter and the abnormal call ratio parameter are mapped according to the preset mapping requirements to obtain the security risk correction factor. The preset mapping requirement adopts a two-condition judgment rule, specifically as follows: when the comprehensive anomaly assessment parameter P ≥ 0.3 and the anomaly call ratio parameter R ≥ 0.002%, the security risk correction factor F = 1.4; when the comprehensive anomaly assessment parameter 0.1 ≤ P < 0.3, the security risk correction factor F = 1.2; when the comprehensive anomaly assessment parameter P < 0.1, the security risk correction factor F = 1.0. The comprehensive anomaly assessment parameter P = 0.344 ≥ 0.3 and the anomaly call ratio parameter R = 0.00247% ≥ 0.002% for the verification list declaration interface meet the first condition; therefore, its security risk correction factor is determined to be F = 1.4.

[0043] In an optional embodiment, the frequency of abnormal calls is differentiated using the abnormal call classification results to obtain comprehensive abnormal assessment parameters for each API interface. Specifically, this includes: extracting the number of abnormal call records corresponding to each abnormal level from the abnormal call classification results, and configuring an impact parameter for each abnormal level. The impact parameter characterizes the strength of the impact of different abnormal levels on the comprehensive abnormal assessment value; associating the number of abnormal call records with the corresponding impact parameter to obtain the classification impact parameter for each abnormal level; obtaining the timestamp information of each abnormal call in historical abnormal call records, and determining the time span of each abnormal call from the current time based on the timestamp information; configuring a timeliness adjustment parameter for each abnormal call based on the time span; and associating the classification impact parameter with the corresponding timeliness adjustment parameter to obtain the comprehensive abnormal assessment parameters.

[0044] In the above embodiment, the number of abnormal call records corresponding to each abnormality level is extracted from the abnormal call classification results. Taking the nuclear release order query interface as an example, within a 90-day observation period, this interface experienced 15 abnormal calls. After classification, there were 6 high-risk abnormalities, 7 medium-risk abnormalities, and 2 low-risk abnormalities. The system configures an impact parameter for each abnormality level to characterize the intensity of the impact of different abnormality levels on the comprehensive abnormality assessment value. The impact parameter for high-risk abnormalities is set to 5.0 because these abnormalities usually involve unauthorized access or data leakage risks; the impact parameter for medium-risk abnormalities is set to 2.5, mainly including data format errors or business logic abnormalities; the impact parameter for low-risk abnormalities is set to 1.0, usually due to occasional problems such as network jitter or timeouts. The number of abnormal call records is correlated with the corresponding impact parameter to obtain the classification impact parameter for each abnormality level. The specific calculation method for the correlation processing is: Classification impact parameter = Number of abnormal call records × Impact parameter. The impact parameters for each anomaly level in the release order query interface are calculated as follows: High-risk level impact parameter = 6 × 5.0 = 30; Medium-risk level impact parameter = 7 × 2.5 = 17.5; Low-risk level impact parameter = 2 × 1.0 = 2. This differentiated treatment ensures that severe anomalies have a greater weight in the comprehensive evaluation.

[0045] In the above embodiment, the timestamp information of each abnormal call in the historical abnormal call record is obtained, accurate to the second. By comparing the occurrence timestamp with the current system time, the time span of each abnormal call from the current time is determined. Taking 15 abnormal calls to the nuclear release order query interface as an example, the time span distribution of each abnormal call is as follows: Of the 6 high-risk abnormalities, 2 occurred within 7 days (time spans of 48 hours and 120 hours respectively), 3 occurred between 7 and 30 days (time spans of 192 hours, 360 hours, and 504 hours respectively), and 1 occurred between 30 and 60 days (time span of 960 hours); Of the 7 medium-risk abnormalities, 1 occurred within 7 days (time span of 96 hours), 4 occurred between 7 and 30 days (time spans of 216 hours, 312 hours, 408 hours, and 528 hours respectively), and 2 occurred between 30 and 60 days (time spans of 840 hours and 1080 hours respectively); Of the 2 low-risk abnormalities, 1 occurred between 30 and 60 days (time span of 1200 hours), and 1 occurred more than 60 days later (time span of 2040 hours). Timeliness adjustment parameters are configured for each abnormal call based on its time span. The mapping rule between the timeliness adjustment parameter and the time span adopts a segmented setting method: for anomalies with a time span of less than 7 days (i.e., within 168 hours), the timeliness adjustment parameter is 1.0; for anomalies with a time span of 7 to 30 days (i.e., 168 to 720 hours), the timeliness adjustment parameter is 0.7; for anomalies with a time span of 30 to 60 days (i.e., 720 to 1440 hours), the timeliness adjustment parameter is 0.4; and for anomalies with a time span of more than 60 days (i.e., more than 1440 hours), the timeliness adjustment parameter is 0.2. This timeliness reflects the actual situation that recent anomalies have a greater impact on the current security status.

[0046] In the above embodiment, the graded impact parameters are correlated with the corresponding timeliness adjustment parameters to obtain the comprehensive anomaly assessment parameters. The specific calculation method of the correlation processing is as follows: First, calculate the single contribution value of each anomaly call = impact parameter × timeliness adjustment parameter; then, summarize the timeliness weighted value of each level according to the anomaly level = Σ(single contribution value); finally, sum the timeliness weighted values ​​of each level to obtain the comprehensive anomaly assessment parameter = Σ(timeliness weighted value of each level). Taking the release order query interface as an example, the timeliness weighted value of each anomaly level is calculated as follows: Timeliness weighted value calculation for high-risk anomalies: contribution value of 2 times within 7 days = 2 × 5.0 × 1.0 = 10; contribution value of 3 times within 7 to 30 days = 3 × 5.0 × 0.7 = 10.5; contribution value of 1 time within 30 to 60 days = 1 × 5.0 × 0.4 = 2; timeliness weighted value of high-risk anomalies = 10 + 10.5 + 2 = 22.5. Calculation of weighted average time-limited values ​​for medium-risk anomalies: Contribution value for one occurrence within 7 days = 1 × 2.5 × 1.0 = 2.5; Contribution value for four occurrences within 7 to 30 days = 4 × 2.5 × 0.7 = 7; Contribution value for two occurrences within 30 to 60 days = 2 × 2.5 × 0.4 = 2; Weighted average time-limited value for medium-risk anomalies = 2.5 + 7 + 2 = 11.5. Calculation of weighted average time-limited values ​​for low-risk anomalies: Contribution value for one occurrence within 30 to 60 days = 1 × 1.0 × 0.4 = 0.4; Contribution value for one occurrence after 60 days = 1 × 1.0 × 0.2 = 0.2; Weighted average time-limited value for low-risk anomalies = 0.4 + 0.2 = 0.6. Comprehensive anomaly assessment parameter = Weighted average time-limited value for high-risk anomalies + Weighted average time-limited value for medium-risk anomalies + Weighted average time-limited value for low-risk anomalies = 22.5 + 11.5 + 0.6 = 34.6.

[0047] In an optional embodiment, the current business traffic data of each API interface is collected in real time, and the deviation value between the current business traffic data and the baseline traffic range is determined. Specifically, this includes: comparing the value range of the real-time collected current business traffic data with the baseline traffic range to determine whether the current business traffic data is within the baseline traffic range; when it is determined that the current business traffic data is within the baseline traffic range, the deviation value is set to zero; when it is determined that the current business traffic data is less than the lower limit of the baseline traffic range, the negative deviation difference between the lower limit of the baseline traffic range and the current business traffic data is determined, and the ratio of the negative deviation difference to the lower limit of the baseline traffic range is determined as the lower deviation ratio; when it is determined that the current business traffic data is greater than the upper limit of the baseline traffic range, the positive excess difference between the current business traffic data and the upper limit of the baseline traffic range is determined, and the ratio of the positive excess difference to the upper limit of the baseline traffic range is determined as the upper deviation ratio; the lower deviation ratio or the upper deviation ratio is used as the deviation value.

[0048] In the above embodiments, the current business traffic data of each API interface is collected in real time, and the collection frequency is once every 30 seconds. Taking the declaration interface of the bonded logistics inventory list as an example, at 10:15 am on a certain working day, the current business traffic data of this interface is collected as 195 calls per minute. The system immediately conducts a numerical range comparison and analysis of this real-time data with the corresponding baseline traffic range for this period. The baseline traffic range of this interface during the period from 10:00 am to 10:30 am on a working day is 120 to 180 calls per minute, where the lower limit value is 120 calls and the upper limit value is 180 calls. The specific judgment logic for the numerical range comparison and analysis is as follows: If the current business traffic data V satisfies the lower limit value L ≤ V ≤ the upper limit value U, it is determined that the current business traffic data is within the baseline traffic range; if V < L, it is determined that the current business traffic data is less than the lower limit value of the baseline traffic range; if V > U, it is determined that the current business traffic data is greater than the upper limit value of the baseline traffic range. For the above-mentioned inventory list declaration interface, the current business traffic data V = 195 calls, the lower limit value L = 120 calls, and the upper limit value U = 180 calls. Since 195 > 180, it is determined that the current business traffic data is greater than the upper limit value of the baseline traffic range. When it is determined that the current business traffic data is greater than the upper limit value of the baseline traffic range, the positive excess difference and the upper deviation ratio are calculated. The calculation method for the positive excess difference is: Positive excess difference = Current business traffic data - Upper limit value of the baseline traffic range = V - U. The calculation method for the upper deviation ratio is: Upper deviation ratio = Positive excess difference / Upper limit value of the baseline traffic range = (V - U) / U. For the inventory list declaration interface, the positive excess difference = 195 - 180 = 15 calls, and the upper deviation ratio = 15 / 180 = 0.083. The upper deviation ratio 0.083 is used as the deviation degree value at this moment, that is, the deviation degree value D = 0.083. This calculation method of relative ratio can more accurately reflect the deviation degree and avoid the evaluation deviation caused by different baseline absolute values.

[0049] In the above embodiments, in another scenario, the current business traffic data of the cross-border e-commerce order query interface at 3:45 am is 8 calls per minute, and the baseline traffic range during this period is 15 to 35 calls per minute, with the lower limit value L = 15 and the upper limit value U = 35. Since the current business traffic data V = 8, which satisfies the condition V < L, it is determined that the current business traffic data is less than the lower limit value of the baseline traffic range. When it is determined that the current business traffic data is less than the lower limit value of the baseline traffic range, the negative deviation difference and the lower deviation ratio are calculated. The calculation method of the negative deviation difference is: negative deviation difference = lower limit value of the baseline traffic range - current business traffic data = L - V. The calculation method of the lower deviation ratio is: lower deviation ratio = negative deviation difference / lower limit value of the baseline traffic range = (L - V) / L. For the cross-border e-commerce order query interface, the negative deviation difference = 15 - 8 = 7, and the lower deviation ratio = 7 / 15 = 0.467. The lower deviation ratio 0.467 is used as the deviation degree value, that is, the deviation degree value D = 0.467. This two-way deviation detection mechanism ensures that both abnormal increases and decreases in traffic can be detected simultaneously. When the current business traffic data of the vehicle passing card information query interface at a certain moment is 85 calls per minute, and the baseline traffic range during this period is 70 to 100 calls per minute, the lower limit value L = 70, the upper limit value U = 100, and the current business traffic data V = 85. Since the condition L ≤ V ≤ U is satisfied (i.e., 70 ≤ 85 ≤ 100), it is determined that the current business traffic data is within the baseline traffic range, and the deviation degree value is directly set to zero, that is, the deviation degree value D = 0, indicating that the current traffic is within the normal range and no alarm needs to be generated.

[0050] In an optional embodiment, a differential threshold comparison analysis is performed on the deviation degree value and the target deviation tolerance threshold to generate API abnormal call warning information, which specifically includes: obtaining the real-time business scenario identifier of each API interface, and determining the business activity level of the current period according to the real-time business scenario identifier; differentially adjusting the target deviation tolerance threshold according to the business activity level to obtain the real-time deviation tolerance threshold corresponding to the current business scenario; performing a numerical comparison analysis on the deviation degree value and the real-time deviation tolerance threshold to determine whether the deviation degree value is greater than the real-time deviation tolerance threshold; when it is determined that the deviation degree value is greater than the real-time deviation tolerance threshold, determining the abnormal severity level of each API interface according to the deviation difference between the deviation degree value and the real-time deviation tolerance threshold; generating abnormal call description information according to the abnormal severity level, the identifier information of each API interface, and the current business traffic data; and using the abnormal call description information, the deviation degree value, the real-time deviation tolerance threshold, and the abnormal severity level as API abnormal call warning information.

[0051] In the above embodiment, the real-time business scenario identifier for each API interface is first obtained. Taking the registration declaration interface as an example, at 10:30 AM on a certain weekday, the real-time business scenario identifier for this interface is determined to be the peak period for daily customs declaration. This identifier is determined by comprehensively analyzing multiple dimensions of information such as the current time, historical business patterns, and real-time traffic flow. Based on the real-time business scenario identifier, the business activity level for the current time period is determined. The mapping relationship between the business activity level and the business scenario identifier is as follows: the peak period for daily customs declaration corresponds to a high activity level with an activity coefficient of 3; the regular weekday period corresponds to a medium activity level with an activity coefficient of 2; and the off-peak period outside of working hours corresponds to a low activity level with an activity coefficient of 1. The current business scenario identifier for the registration declaration interface is the peak period for daily customs declaration, therefore its business activity level is determined to be a high activity level with an activity coefficient of 3. Based on the business activity level, the target deviation tolerance threshold is adjusted differentially to obtain the real-time deviation tolerance threshold corresponding to the current business scenario. The specific calculation method for differentiated adjustment is as follows: Real-time deviation tolerance threshold = Target deviation tolerance threshold × (1 + Activity adjustment factor), where the correspondence between the activity adjustment factor and the activity coefficient is as follows: when the activity coefficient is 3, the activity adjustment factor is 0.25; when the activity coefficient is 2, the activity adjustment factor is 0.10; and when the activity coefficient is 1, the activity adjustment factor is 0. The target deviation tolerance threshold for the verification list declaration interface is 20%, the current activity coefficient is 3, and the corresponding activity adjustment factor is 0.25. Therefore, the real-time deviation tolerance threshold = 20% × (1 + 0.25) = 20% × 1.25 = 25%. This dynamic adjustment mechanism allows the system to tolerate larger traffic fluctuations during peak business periods, avoiding false alarms caused by normal business concentration.

[0052] In the above embodiments, the deviation value is compared with the real-time deviation tolerance threshold to determine whether the deviation value is greater than the real-time deviation tolerance threshold. The judgment logic of the numerical comparison analysis is as follows: if the deviation value D > the real-time deviation tolerance threshold T, it is determined that the deviation value is greater than the real-time deviation tolerance threshold, and an early warning message needs to be generated; if the deviation value D ≤ the real-time deviation tolerance threshold T, it is determined that the deviation value does not exceed the threshold, and no early warning message needs to be generated. The deviation value D of the registration list declaration interface is 28%, and the real-time deviation tolerance threshold T is 25%. Since 28% > 25%, it is determined that the deviation value is greater than the real-time deviation tolerance threshold. When it is determined that the deviation value is greater than the real-time deviation tolerance threshold, the abnormal severity level of each API interface is determined according to the deviation difference between the deviation value and the real-time deviation tolerance threshold. The deviation difference is calculated as follows: Deviation difference = Deviation value - Real-time deviation tolerance threshold = DT. The deviation difference of the registration list declaration interface = 28% - 25% = 3%. The mapping rule between the severity level of an anomaly and the deviation difference is as follows: when the deviation difference ΔD satisfies 0 < ΔD ≤ 5%, the anomaly severity level is mild; when the deviation difference ΔD satisfies 5% < ΔD ≤ 15%, the anomaly severity level is moderate; and when the deviation difference ΔD > 15%, the anomaly severity level is severe. The deviation difference ΔD of the verification list declaration interface is 3%, which satisfies the condition 0 < 3% ≤ 5%, therefore its anomaly severity level is determined to be mild.

[0053] In the above embodiments, abnormal call description information is generated based on the severity level of the anomaly, the identification information of each API interface, and the current business traffic data. The generation rule for the abnormal call description information is as follows: the interface identification information, detection time, anomaly severity level, current business traffic data, baseline upper limit, deviation value, and real-time deviation tolerance threshold are combined according to a preset format. The abnormal call description information generated for the API registration list application interface is as follows: the interface identification information is the API registration list application interface (interface number: API_CUSTOMS_001), the detection time is 10:30 AM on March 15th of a certain year, the anomaly severity level is mild anomaly, the current business traffic data is 231 times per minute, the baseline upper limit is 180 times per minute, the deviation value is 28%, and the real-time deviation tolerance threshold is 25%. The combined abnormal call description information is as follows: The API CUSTOMS_001 API declaration interface (API_CUSTOMS_001) detected a slight abnormality at 10:30 on March 15 of a certain year. The current call frequency is 231 times per minute, which exceeds the baseline limit of 180 times, with a deviation of 28%, exceeding the tolerance threshold of 25% for the current business scenario.

[0054] In the above embodiment, the abnormal call description information, deviation value, real-time deviation tolerance threshold, and abnormal severity level are used as API abnormal call warning information. The data structure of the API abnormal call warning information includes the following fields: abnormal call description information field, the content of which is the description text generated above; deviation value field, the value of which is 28%; real-time deviation tolerance threshold field, the value of which is 25%; and abnormal severity level field, the value of which is mild abnormality. A complete example of API abnormal call warning information is as follows: Abnormal call description information: The verification list declaration interface (interface number: API_CUSTOMS_001) detected a mild abnormality at 10:30 on March 15, 2017. The current call frequency is 231 times per minute, which exceeds the baseline limit of 180 times, the deviation is 28%, and it exceeds the current business scenario tolerance threshold of 25%. Deviation value: 28%, real-time deviation tolerance threshold: 25%, abnormal severity level: mild abnormality.

[0055] It should also be noted that the examples of the specific values ​​of all the above parameters are merely exemplary embodiments, and the specific values ​​of all the above parameters are not limited to the examples given above.

[0056] Through the embodiments of this application, historical call log data is divided into multiple time windows and business traffic feature values ​​are extracted. The resulting multidimensional traffic feature sequence can comprehensively reflect the call patterns of each API interface at different times. The stable time window set selected by volatility analysis eliminates interference data during abnormal fluctuation periods, making the baseline traffic range more accurately represent the normal business state. At the same time, by establishing a mapping relationship table between API interfaces and data security domains, the difference between the source security domain level and the target security domain level is quantified into a security level span value. This span value is inversely correlated with the target deviation tolerance threshold, realizing a differentiated strategy of adopting stricter monitoring for high-risk cross-domain interfaces and moderately relaxing monitoring for low-risk interfaces. When the real-time collected business traffic data is compared with the dynamically adjusted target deviation tolerance threshold after deviation calculation, real anomalies can be accurately identified while normal business fluctuations are filtered out.

[0057] The API abnormal call early warning system in the embodiments of this application is described below from the perspective of hardware processing. Referring to Figure 2, Figure 2 is a schematic diagram of the physical device structure of the API abnormal call early warning system in the embodiments of this application.

[0058] It should be noted that the structure of the API abnormal call warning system shown in Figure 2 is only an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0059] As shown in Figure 2, the API exception call early warning system includes a Central Processing Unit (CPU) 201, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 202 or programs loaded from storage section 208 into Random Access Memory (RAM) 203, such as executing the methods described in the above embodiments. The RAM 203 also stores various programs and data required for system operation. The CPU 201, ROM 202, and RAM 203 are interconnected via bus 204. An Input / Output (I / O) interface 205 is also connected to bus 204.

[0060] The following components are connected to I / O interface 205: input section 206 including audio input devices, push-button switches, etc.; output section 207 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 208 including a hard disk, etc.; and communication section 209 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 209 performs communication processing via a network such as the Internet. Drive 210 is also connected to I / O interface 205 as needed. Removable media 211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 210 as needed so that computer programs read from them can be installed into storage section 208 as needed.

[0061] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 209, and / or installed from removable medium 211. When the computer program is executed by central processing unit (CPU) 201, it performs the various functions defined in the present invention.

[0062] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0063] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0064] Specifically, the API abnormal call early warning system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the API abnormal call early warning method based on the business traffic baseline provided in the above embodiment.

[0065] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the API anomaly call early warning system described in the above embodiments; or it may exist independently and not assembled into the API anomaly call early warning system. The storage medium carries one or more computer programs, which, when executed by a processor of the API anomaly call early warning system, cause the API anomaly call early warning system to implement the API anomaly call early warning method based on a business traffic baseline provided in the above embodiments.

[0066] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0067] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for early warning of abnormal API calls based on business traffic baselines, characterized in that, include: The historical call log data of multiple API interfaces in the cross-domain data exchange system is obtained, the historical call log data is divided into multiple time windows, and business traffic feature values ​​are extracted from each of the multiple time windows to obtain a multi-dimensional traffic feature sequence of each API interface. A volatility analysis is performed on the multidimensional traffic feature sequence, and a set of stable time windows with traffic volatility coefficients less than a preset stable threshold is selected from the multiple time windows. The baseline traffic range of each API interface is determined using the business traffic feature values ​​in the set of stable time windows. Obtain the security level identifier of each data security domain in the cross-domain data exchange system, and establish a mapping relationship table between each API interface and each data security domain based on the data flow relationship of each API interface and the security level identifier. The mapping relationship table is used to record the source security domain level and target security domain level connected to each API interface. The security level span value of each API interface is determined based on the source security domain level and the target security domain level, and the target deviation tolerance threshold of each API interface is determined based on the security level span value. Real-time collection of current business traffic data for each API interface; determination of the deviation value between the current business traffic data and the baseline traffic range; and comparative analysis of the deviation value with the target deviation tolerance threshold to generate API abnormal call warning information.

2. The method according to claim 1, characterized in that, The process of performing volatility analysis on the multidimensional traffic feature sequence, selecting a set of stable time windows with traffic volatility coefficients less than a preset stability threshold from multiple time windows, and determining the baseline traffic range of each API interface using the business traffic feature values ​​in the set of stable time windows, specifically includes: determining the first total call frequency, data transmission volume, and response time of each API interface within each time window; determining the traffic volatility coefficient of each time window based on the first total call frequency, the data transmission volume, and the response time; and performing a stability comparison analysis between the traffic volatility coefficient of each time window and the preset stability threshold to select multiple candidate stable time windows with traffic volatility coefficients less than the preset stability threshold. The process involves defining a window; converting the multiple time windows into a continuous time window sequence; performing time continuity detection on the multiple candidate stable windows to determine a target stable window group continuously distributed on the time window sequence; and determining the average traffic fluctuation coefficient of the target stable window group. When the average traffic fluctuation coefficient meets a preset continuity condition, the target stable window group is determined as the stable time window set. Service traffic feature values ​​for each stable time window are extracted from the stable time window set. Statistical analysis is performed on the service traffic feature values ​​to determine the upper quartile of the service traffic feature values ​​as the upper limit of the baseline traffic interval and the lower quartile of the service traffic feature values ​​as the lower limit of the baseline traffic interval.

3. The method according to claim 1, characterized in that, The step of determining the security level span value of each API interface based on the source security domain level and the target security domain level, and determining the target deviation tolerance threshold of each API interface based on the security level span value, specifically includes: obtaining the source security domain value corresponding to the source security domain level and the target security domain value corresponding to the target security domain level; determining the absolute deviation value between the source security domain value and the target security domain value; using the absolute deviation value as the initial security level span value; obtaining historical abnormal call records for each API interface; and determining the abnormal call frequency of the security level crossing type from the historical abnormal call records, wherein the abnormal call frequency is the number of abnormal calls that occur when crossing different data security domains; and determining the target deviation tolerance threshold of each API interface based on the abnormal call frequency. A security risk correction factor for the interface, wherein the security risk correction factor characterizes the degree of influence of the historical abnormal call records on the security level span value; the security level span value is determined based on the initial security level span value and the security risk correction factor; a reverse mapping relationship between the security level span value and the target deviation tolerance threshold is constructed, and the security level span value is converted into the initial target deviation tolerance threshold based on the reverse mapping relationship; the business importance level identifier of each API interface is obtained, and a business tolerance adjustment coefficient is determined based on the business importance level identifier, wherein the business tolerance adjustment coefficient is used to differentiate the deviation tolerance level according to the business importance level; the target deviation tolerance threshold is determined based on the initial target deviation tolerance threshold and the business tolerance adjustment coefficient.

4. The method according to claim 3, characterized in that, The step of determining the security risk correction factor for each API interface based on the abnormal call frequency specifically includes: obtaining a preset historical observation period and determining the second total call frequency of each API interface within the historical observation period; performing a ratio analysis on the second total call frequency and the abnormal call frequency to obtain an abnormal call ratio parameter for each API interface; obtaining abnormal attribute information from the historical abnormal call records and performing hierarchical processing on the historical abnormal call records based on the abnormal attribute information to obtain an abnormal call hierarchical result; using the abnormal call hierarchical result to differentiate the abnormal call frequency to obtain a comprehensive abnormal assessment parameter for each API interface; and mapping the comprehensive abnormal assessment parameter and the abnormal call ratio parameter according to preset mapping requirements to obtain the security risk correction factor.

5. The method according to claim 4, characterized in that, The step of differentiating the frequency of abnormal calls using the abnormal call classification results to obtain comprehensive abnormality assessment parameters for each API interface specifically includes: extracting the number of abnormal call records corresponding to each abnormality level from the abnormal call classification results, and configuring an impact parameter for each abnormality level, wherein the impact parameter is used to characterize the influence intensity of different abnormality levels on the comprehensive abnormality assessment value; associating the number of abnormal call records with the corresponding impact parameter to obtain the classification impact parameter for each abnormality level; obtaining the occurrence timestamp information of each abnormal call in the historical abnormal call records, and determining the time span of each abnormal call from the current time based on the occurrence timestamp information; configuring a timeliness adjustment parameter for each abnormal call based on the time span; and associating the classification impact parameter with the corresponding timeliness adjustment parameter to obtain the comprehensive abnormality assessment parameters.

6. The method according to claim 1, characterized in that, The real-time acquisition of current service traffic data for each API interface and the determination of the deviation value between the current service traffic data and the baseline traffic range specifically include: comparing the real-time acquired current service traffic data with the baseline traffic range to determine whether the current service traffic data is within the baseline traffic range; when the current service traffic data is determined to be within the baseline traffic range, setting the deviation value to zero; when the current service traffic data is determined to be less than the lower limit of the baseline traffic range, determining the negative deviation difference between the lower limit of the baseline traffic range and the current service traffic data, and determining the ratio of the negative deviation difference to the lower limit of the baseline traffic range as the lower deviation ratio; when the current service traffic data is determined to be greater than the upper limit of the baseline traffic range, determining the positive excess difference between the current service traffic data and the upper limit of the baseline traffic range, and determining the ratio of the positive excess difference to the upper limit of the baseline traffic range as the upper deviation ratio; and using the lower deviation ratio or the upper deviation ratio as the deviation value.

7. The method according to claim 1, characterized in that, The step of performing a differential threshold comparison analysis between the deviation value and the target deviation tolerance threshold to generate API abnormal call warning information specifically includes: obtaining the real-time business scenario identifier of each API interface, and determining the business activity level of the current time period based on the real-time business scenario identifier; differentially adjusting the target deviation tolerance threshold based on the business activity level to obtain a real-time deviation tolerance threshold corresponding to the current business scenario; performing a numerical comparison analysis between the deviation value and the real-time deviation tolerance threshold to determine whether the deviation value is greater than the real-time deviation tolerance threshold; when it is determined that the deviation value is greater than the real-time deviation tolerance threshold, determining the abnormal severity level of each API interface based on the deviation difference between the deviation value and the real-time deviation tolerance threshold; generating abnormal call description information based on the abnormal severity level, the identifier information of each API interface, and the current business traffic data; and using the abnormal call description information, the deviation value, the real-time deviation tolerance threshold, and the abnormal severity level as the API abnormal call warning information.

8. An API abnormal call early warning system, characterized in that, The API abnormal call warning system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the API abnormal call warning system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on the API abnormal call warning system, it causes the API abnormal call warning system to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the API abnormal call warning system, the API abnormal call warning system performs the method as described in any one of claims 1-7.

Images