A data analysis-based shared interface security monitoring system and method
Patent Information
- Application Number
- CN202610895133.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-22
- Publication Date
- 2026-09-15
Smart Images
Figure CN122764598A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data security technology, specifically a shared interface security monitoring system and method based on data analysis. Background Technology
[0002] As the core channel for data exchange between systems, the shared interface typically employs a fixed timestamp verification window for clock deviation checking, combined with predefined rules to detect SQL injection, and sets static call volume thresholds for rate limiting based on historical call data. When malicious load or authentication failure is detected, the system records the abnormal event and accumulates the number of failures to assess the requester's reputation.
[0003] Traditional solutions have two limitations. First, the fixed timestamp verification window cannot adapt to the varying network environments of different requesters: legitimate requesters with fluctuating network conditions are prone to false rejections due to occasional jitter, while requesters with stable networks may have an excessively wide window, providing opportunities for timestamp forgery. Second, the static call volume threshold is disconnected from real-time security posture: attacks such as SQL injection only trigger a single blocking, and the number of failures accumulated in the authentication process is not dynamically fed back to resource quota decisions, preventing the system from proactively reducing resources for high-risk requesters.
[0004] Therefore, a method is needed that can dynamically adjust the authentication strictness based on the historical network behavior characteristics of the requester and quantify real-time abnormal events as adaptive correction parameters for resource quotas, so as to form a complete closed loop from threat identification to policy adjustment. Summary of the Invention
[0005] The purpose of this invention is to provide a shared interface security monitoring system and method based on data analysis to solve the problems raised in the prior art.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a shared interface security monitoring system and method based on data analysis. The methods include: Step S1: Obtain historical operation behavior data of the shared interface, perform feature extraction and structured processing on the historical operation behavior data to obtain historical network latency features, historical call volume baseline data and request behavior feature statistics. The historical network latency features include network latency fluctuation parameters and network latency variation coefficients corresponding to different requester identifiers. The request behavior feature statistics include the number of historical authentication failures corresponding to different requester identifiers. Step S2: In response to the shared interface call request, obtain the current requester identifier and request timestamp. Based on the network latency fluctuation parameter and network latency variation coefficient corresponding to the current requester identifier in the historical network latency characteristics obtained in Step S1, dynamically set the effective time deviation range for timestamp verification. After successful verification, perform syntax tree semantic parsing on the SQL statement carried in the call request. If an unexpected change in semantic structure is detected, block the request. Update the historical authentication failure count corresponding to the current requester identifier in Step S1 based on this blocking event. Step S3: Based on the historical call volume baseline data obtained in Step S1, construct a judgment rule to distinguish between normal call mode and abnormal call mode. Use the judgment rule to identify and remove abnormal points in the historical call volume baseline data. Based on the normal business fluctuation samples retained after removing abnormal points, generate the upper limit of the initial call volume confidence interval of the shared interface. Step S4: Using the threshold constraint coefficient calculated by accumulating the historical authentication failure count in step S2 and weighting it by time decay, the upper limit of the initial call volume confidence interval generated in step S3 is corrected. The corrected upper limit of the confidence interval is used as the call volume control threshold for the current requester identifier in the next period. The value of the threshold constraint coefficient decreases as the number of historical authentication failures after time decay weighting increases, so that the upper limit of the corrected confidence interval decreases as the number of recent historical authentication failures increases.
[0007] Furthermore, step S1 includes: Step S1-1: Obtain historical operation behavior data of the shared interface. The historical operation behavior data includes the requester identifier ID and request initiation timestamp T for each call. req Authentication completion timestamp T auth Authentication Result R auth Call response time T resp SQL statement string S sql And extract all the different requester identifiers from the historical operation behavior data to form a requester identifier set U={ID1,ID2,…,ID2} i ,…,ID N}, where ID1, ID2, ..., ID i ,…,ID N These represent the 1st, 2nd, ..., i-th, ..., Nth requester identifiers, respectively, where N is the total number of different requesters; Step S1-2: Divide the historical operation behavior data into segments according to a preset time window Δt, forming a call count sequence C={c1,c2,…,c...} arranged in chronological order. p ,…,c m}, where c1, c2, ..., c p ,…,c m Let C represent the number of calls within the 1st, 2nd, ..., pth, ..., mth time windows, respectively; and let the call count sequence C be used as the baseline data of the historical call volume, where m is the total number of time windows. Step S1-3: For the i-th requester identifier ID in the requester identifier set U i Extract the ID of the i-th requester. i For all corresponding call records, let the ID of the i-th requester be... i The total number of calls is n i Let the ID of the i-th requester be... i The timestamp of the request initiation for the j-th call is T. req,i,j The authentication completion timestamp is T. auth,i,j Where j is the index of the call and its value ranges from 1 to n. i Given an integer, calculate the network latency difference d for the j-th call. i,j =T auth,i,j -T req,i,j , where d i,j Indicates the ID of the i-th requester. i The network latency difference of the j-th call, and the ID of the i-th requester. i The mean of all network latency differences and variance Calculate the ID of the i-th requester. i Network latency variation coefficient The mean μ d,i σ 2 d,i and network latency variation coefficient (CV) i As the ID of the i-th requester i The corresponding historical network latency characteristics; wherein, the network latency variation coefficient CV is introduced. i The reason is that simply relying on the average value to set the verification window cannot distinguish between requesters with "low average latency but drastic fluctuations" and those with "high average latency but extremely stable latency." i As a normalized dispersion index, it can simultaneously characterize the central tendency and volatility of delay, providing a quantitative basis for subsequent differential window setting; Step S1-4: For the i-th requester identifier ID in the requester identifier set U i Let it be within a preset historical time period T. hist The total number of calls within is k i Let the ID of the i-th requester be... i The response time for the q-th call is T.resp,i,q Where q is the index of the call and its value ranges from 1 to k. i An integer, representing the ID of the i-th requester. i During the preset historical time period T hist The authentication result R within auth F is the total number of failures. fail,i The ID of the i-th requester is calculated based on the number of historical authentication failures. i During the preset historical time period T hist The call response time T for each call within the system resp,i,q arithmetic mean As the average response time of historical calls; Step S1-5: Record the historical authentication failure count F fail,i and the average historical call response time μ resp,i Together they serve as statistical measures of the request behavior characteristics corresponding to the i-th requester identifier.
[0008] Furthermore, step S2 includes: Step S2-1: In response to the shared interface call request, obtain the requester identifier ID corresponding to the current call request. req and request timestamp T req_cur Search for the requester's identifier ID from the historical network delay features obtained in steps S1-3. req The matching i-th requester ID i Get the ID of the i-th requester. i The corresponding mean network latency difference μ d,i σ 2 d,i and network latency variation coefficient (CV) i According to the network latency variation coefficient CV i Determine the type of the requester: when CV i ≤CV th The ID of the i-th requester will be displayed at that time. i Marked as stable, when CV i >CV th The ID of the i-th requester will be displayed at that time. i Marked as jittery, where CV th The preset mutation threshold is used; based on the ID of the i-th requester. i The type determines the value of the preset multiple λ: when the i-th requester ID... i When it is stable, λ=λ loose When the i-th requester ID i When it is a jitter type, λ=λ strict , where λ loose>λ strict ; with the mean μ d,i The sum of the square roots of the variances of the i-th requester and the preset multiple λ is used as the ID of the i-th requester. i Network latency fluctuation limit Based on the network latency fluctuation limit L i The valid time deviation range for timestamp verification is set to [-L]. i ,L i ], calculate the request timestamp T req_cur Compared with the current time T when the call request was received cur The absolute value of the deviation Δt=|T req_cur -T cur |, in Δt≤L i The timestamp verification is passed at the time of determination; among them, a larger λ is used for stable requesters. loose To provide a more lenient verification window and avoid falsely rejecting legitimate requests due to occasional network jitter; a smaller λ is used for jittery requesters. strict By tightening the verification window, it increases the difficulty for attackers to forge timestamps, thus achieving a differentiated security strategy of "lenient for stable systems and strict for unstable systems"; Step S2-2: After the timestamp verification is successful, extract the SQL statement string S carried in the call request. sql_cur , will S sql_cur Substitute the original SQL statement template corresponding to the shared interface to generate a complete syntax tree. cur Tree cur With the pre-stored standard syntax tree std Structural comparison is performed to obtain the structural difference degree δ. When δ exceeds the preset difference tolerance threshold δ, th If the SQL statement is identified as causing an unexpected change in the semantic structure of the original SQL statement, the current call request is blocked. Step S2-3: Based on the blocking of this call request in step S2-2, the ID corresponding to the requester identifier in step S1-5 is set. req Historical authentication failure count F fail,i Updated to F fail,i +1, to get the cumulative number of authentication failures F fail,i,new and with F fail,i,new Replace F in steps S1-5 fail,i Record the time T when this failure occurs. fail,t , where t is the sequence number of the failed record; Step S2-4: First, based on the accumulated number of authentication failures F fail,i,new And the time of each failure, calculate the ID for the i-th requester. i Weighted number of failures Where γ is a preset time decay factor and γ>0; then based on the weighted failure count F weighted,i Calculate threshold constraint coefficients Where β is a preset amplitude attenuation factor and β>0, α i The value range is (0,1]; calculate the ID of the i-th requester. i The rate of increase in the number of failures within the most recent preset time period, v fail The most recent preset time period refers to the period from the current time T. cur A historical period of preset length as the endpoint; when v fail >v th When, the threshold constraint coefficient α i Further multiply by the acceleration decay factor ρ, where If θ>0, the corrected threshold constraint coefficient α is obtained. i,final =α i ×ρ, and with α i,final As the identifier ID for the i-th requester i The final threshold constraint coefficient, where v th The preset growth rate threshold is F; where F weighted,i By assigning a time weight to each failure record through a time decay factor γ, the impact of recent failures on the current security posture is made much greater than that of long-term failures, reflecting the timeliness of the threat; the threshold constraint coefficient α i Using an exponential decay function When the number of weighted failures is small, the decay is gradual to tolerate occasional errors; when the number of weighted failures continues to increase, the decay accelerates to impose a non-linear penalty, resulting in the effect of "the more attacks, the heavier the restrictions"; an increase rate v is introduced. fail The reason for the accelerated decay factor ρ is that the weighted failure count has a lag in response to sudden high-frequency attacks, when v fail Exceeding the threshold v th The system determines if an ongoing attack exists by using ρ against α. i Secondary compression is performed to enable the threshold to respond instantly to changes in attack intensity.
[0009] Furthermore, step S3 includes: Step S3-1: Obtain the call count sequence C from the historical call volume baseline data obtained in Step S1-2, perform random subsampling on the call count sequence C, and recursively construct several isolated trees. Each isolated tree performs binary division on the subsample by randomly selecting segmentation features and segmentation values until each isolated tree reaches a preset height limit. The constructed isolated trees are used together as the isolated forest judgment rule. The reason for choosing the isolated forest algorithm is that the call volume sequence contains normal business fluctuations and abnormal surges. Based on the principle that "abnormal points are more easily randomly segmented and isolated", the isolated forest can effectively identify and remove abnormal points without preset data distribution, providing a purer normal business fluctuation sample for subsequent threshold calculation. Step S3-2: Calculate the anomaly score for each data point in the call count sequence C using the isolated forest judgment rule. Identify data points with anomaly scores exceeding a preset isolation threshold as anomalies and remove them. The remaining data points constitute the normal business fluctuation sample set C. normal ={c normal,1 ,c normal,2 ,…,c normal,r ,…,c normal,s}, where c normal,1 ,c normal,2 ,…,c normal,r ,…,c normal,s These represent the number of times the 1st, 2nd, ..., rth, ..., sth data points are called, respectively, where s is the total number of data points to be retained. Step S3-3: Calculate the normal business fluctuation sample set C normal mean and standard deviation , with the mean μ c The sum of the standard deviations of the initial call amount and the preset confidence multiple φ is used as the upper limit of the confidence interval U. init =μ c +φ×σ c , where φ is a positive real number; where μ is used c +φ×σ c The statistical basis for calculating the upper limit of the confidence interval is that, for data that is approximately normally distributed, the value of φ determines the leniency of the initial threshold. The larger the value of φ, the stronger the threshold's tolerance to business fluctuations; the smaller the value of φ, the more sensitive it is to anomalies. It can be flexibly configured according to the characteristics of the interface business.
[0010] Furthermore, step S4 includes: Step S4-1: In step S4-1, obtain the identifier ID for the i-th requester from steps S2-4. i The final threshold constraint coefficient α i,final ; Step S4-2, set the upper limit U of the initial call volume confidence interval generated in step S3-3. init Multiplied by the final threshold constraint coefficient α i,final The upper limit of the corrected confidence interval U is obtained. final,i =α i,final ×U init The reason for using multiplication correction instead of subtraction correction is that the initial threshold U of different interfaces... init The magnitude difference is significant; multiplicative correction uses scaling to make the correction magnitude equal to U. init Automatic adaptation: the absolute number of reductions for high-frequency interfaces is greater than that for low-frequency interfaces, but the relative constraint on both is the same, achieving a unified security policy expression that is independent of the interface traffic volume. Step S4-3, U final,i Dynamically set as the identifier ID for the i-th requester in the next cycle. i The system manages the number of calls to a threshold; by recalculating and updating the threshold based on the latest data each cycle, security parameters can automatically follow business changes and threat evolution, achieving a continuous adaptive, maintenance-free effect.
[0011] The system includes: a feature extraction module, a real-time authentication module, an initial threshold generation module, and a threshold correction module; The feature extraction module is used to extract historical network latency features, historical call volume baseline data, and historical authentication failure counts from historical operation behavior data for different requesters. The real-time authentication module is used to dynamically set the timestamp verification range based on the historical network latency characteristics of the current requester, and to block the request and accumulate the number of authentication failures when abnormal behavior is detected. The initial threshold generation module is used to generate an initial call volume limit based on historical call volume baseline data; The threshold correction module is used to correct the initial call limit using the threshold constraint coefficient obtained by time decay weighting, so as to obtain the call count control threshold.
[0012] The feature extraction module includes: The data acquisition unit is used to acquire historical operation behavior data and extract the requester identifier set; The baseline construction unit is used to statistically generate historical call volume baseline data by segmenting according to a preset time window. The network latency feature statistics unit is used to count the historical network latency features corresponding to each requester identifier; The failure count unit is used to count the number of historical authentication failures of each requester identifier within a preset historical time period; The feature aggregation unit is used to use the number of historical authentication failures as statistical features of the request behavior of the corresponding requester.
[0013] The real-time authentication module includes: The verification window setting unit is used to select the corresponding fluctuation range and set the effective time deviation range according to the network latency variation coefficient of the current requester identifier. The security parsing unit is used to compare the syntax tree of the SQL statement in the request with the standard syntax tree to identify abnormal behavior and block the request; The failure accumulation unit is used to accumulate the number of historical authentication failures of the current requester after the request is blocked and to record the failure time. The constraint coefficient calculation unit is used to obtain the weighted number of failures and determine the threshold constraint coefficient by accumulating the time weights of each failure record.
[0014] The threshold correction module includes: The constraint coefficient secondary correction unit is used to perform secondary compression on the threshold constraint coefficient to obtain the final threshold constraint coefficient when the failure rate exceeds a preset threshold. The multiplication correction unit is used to multiply the initial call volume limit by the final threshold constraint coefficient to obtain the corrected call volume limit; The threshold setting unit is used to dynamically set the corrected call volume limit to the call count control threshold for the current requester identifier in the next cycle.
[0015] The initial threshold generation module includes: The judgment rule construction unit is used to randomly sample historical call volume baseline data and recursively construct judgment rules; The anomaly removal unit is used to identify and remove anomalies in the call count sequence using judgment rules. The upper limit generation unit is used to generate the initial call volume upper limit based on the normal business fluctuation samples retained after removing outliers.
[0016] Compared with the prior art, the beneficial effects of the present invention are: 1. By introducing a network latency variation coefficient and classifying requesters as stable or jittery, this method can differentiate the effective time deviation range for timestamp verification based on the fluctuation of the requester's historical network behavior. A more lenient verification window is used for stable requesters with low historical network latency fluctuations to avoid false rejections due to occasional network jitter; a stricter verification window is used for jittery requesters with high historical network latency fluctuations to increase the difficulty for attackers to forge timestamps. This adaptive adjustment mechanism solves the technical problem that traditional fixed verification windows cannot accommodate requesters in different network environments.
[0017] 2. By recording the occurrence time of each authentication failure when updating historical authentication failure counts, and calculating a weighted failure count using a time-decay weighted method, a threshold constraint coefficient is generated based on this weighted failure count. This method ensures that recent authentication failure events have a far greater impact on the current security posture than long-term failure events, accurately reflecting the timeliness of threats. Simultaneously, when the recent failure rate exceeds a preset threshold, the threshold constraint coefficient is further compressed using an accelerated decay factor. This enables the system to respond instantly to sudden high-frequency attacks, compensating for the lag in responding to changes in attack intensity when relying solely on weighted cumulative values, and achieving rapid tightening of resource quotas for high-risk requesters.
[0018] 3. By employing the Isolation Forest algorithm to identify and remove outliers from historical call volume baseline data, and generating an initial call volume confidence interval upper limit based on the normal business fluctuation samples retained after outlier removal, this method effectively eliminates interference from abnormal surges such as attack traffic or fault retries mixed in with historical data, making the initial threshold more accurately reflect the normal business load level of the shared interface. Furthermore, by multiplying the initial threshold and the final threshold constraint coefficient to correct the output call count control threshold, the correction magnitude automatically adapts to the magnitude of different interfaces, achieving a unified security policy expression independent of the interface's business volume, avoiding the cumbersome operation of configuring parameters individually for each interface in traditional subtraction correction. Attached Figure Description
[0019] Figure 1 This is a flowchart illustrating a data analysis-based shared interface security monitoring method according to the present invention. Figure 2 This is a schematic diagram of the structure of a shared interface security monitoring system based on data analysis according to the present invention. Detailed Implementation
[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] Example: Figures 1-2 As shown, this invention provides a technical solution: a shared interface security monitoring system and method based on data analysis. The methods include: Step S1: Obtain historical operation behavior data of the shared interface, perform feature extraction and structured processing on the historical operation behavior data to obtain historical network latency features, historical call volume baseline data and request behavior feature statistics. The historical network latency features include network latency fluctuation parameters and network latency variation coefficients corresponding to different requester identifiers. The request behavior feature statistics include the number of historical authentication failures corresponding to different requester identifiers. Step S1-1: Obtain historical operation data of a certain shared interface over the past 30 days. Each call record includes the requester ID and the request initiation timestamp T. req Authentication completion timestamp T auth Authentication Result R auth Success is recorded as 1, failure as 0, and the call response time is T. resp Extract all distinct requester identifiers from the above data to form a requester identifier set U={ID1,ID2,ID3}, where ID1 represents requester A, ID2 represents requester B, ID3 represents requester C, and N=3.
[0022] Step S1-2: Set a preset time window Δt = 1 hour, divide the historical operation data into segments of 1 hour, and count the total number of calls within each time window to form a call count sequence C = {c1, c2, c3}. 3, c4, c5} where c1 = 156, c2 = 142, c3 = 203, c4 = 165, c5 = 198; the call count sequence C is used as the baseline data for historical call volume; Steps S1-3: Calculate historical network latency characteristics using ID1; extract all call records corresponding to ID1, assuming the total number of calls n1=5; obtain the request initiation timestamp T of the first call. req,1,1 And authentication completion timestamp T auth,1,1 Calculate the network latency difference d 1,1 =T auth,1,1 -T req,1,1 Get the timestamp of the second call and calculate d. 1,2 Similarly, five network latency differences are obtained, denoted as d. 1,1 =82ms, d 1,2 =91ms, d 1,3 = 88ms, d 1,4 = 79ms, d 1,5 =86ms, calculate the mean of these 5 differences. ,variance Network latency variation coefficient ; will μ d,1 =85.2ms, σ 2 d,1 =196.5ms2 CV1=0.165 is used as the historical network latency feature corresponding to ID1; Similarly, calculate the features of ID2 and ID3: ID2: μ d,2 =120.6ms, σ 2 d,2 =890.3ms 2 CV2≈0.247; ID3: μ d,3 =45.3ms, σ 2 d,3 =48.2ms 2 CV3≈0.153; Step S1-4: Set the preset historical time period T hist =7 days; using ID1, count the total number of calls in the last 7 days, k1=5, authentication result R auth F is the total number of failures. fail,1 =2, the response time for each call is T. resp,1,1 =220ms, T resp,1,2 =245ms, T resp,1,3 =210ms, T resp,1,4 =255ms, T resp,1,5 =230ms, calculate the arithmetic mean of the call response time for each call. ; Similarly: ID2: k2=5, F fail,2 =1, μ resp,2 =312.8ms; ID3: k3=5, F fail,3 =3, μ resp,3 =178.2ms; Steps S1-5: For ID1, its request behavior characteristic statistics are the number of historical authentication failures F. fail,1 =8. Average historical call response time μ resp,1 =232ms; For ID2, its request behavior characteristic statistics are F. fail,2 =1、μ resp,2 =312.8ms; For ID3, its request behavior characteristic statistics are F. fail,3 =3、μ resp,3 =178.2ms.
[0023] Step S2: In response to the shared interface call request, obtain the current requester identifier and request timestamp. Based on the network latency fluctuation parameter and network latency variation coefficient corresponding to the current requester identifier in the historical network latency characteristics obtained in Step S1, dynamically set the effective time deviation range for timestamp verification. After successful verification, perform syntax tree semantic parsing on the SQL statement carried in the call request. If an unexpected change in semantic structure is detected, block the request. Update the historical authentication failure count corresponding to the current requester identifier in Step S1 based on this blocking event. Step S2-1: At a certain moment, the system receives a call request from requester A with ID1, and the request timestamp T. req_cur With current time T cur The absolute value of the deviation Δt1 = 2000 ms; obtain the characteristics of ID1 from step S1-3: μ d,1 =85.2ms, σ 2 d,1 =196.5ms 2 CV1=0.165; Set the preset mutation threshold CV th =0.2; Since CV1=0.165≤0.2, ID1 is marked as stable, and λ=λ is set according to the stable type. loose =3; Calculate the upper limit of network latency fluctuation. Since Δt1 = 2000ms > L1, the timestamp verification fails, and the request is rejected. At another moment, a call request for ID2 is received from requester B, Δt2 = 1000ms; the characteristics of ID2 are obtained from steps S1-3: μ d,2 =120.6ms, σ 2 d,2 =890.3ms 2 CV2 = 0.247; since CV2 = 0.247 > CV th =0.2, mark ID2 as jittery, and set λ=λ strict =1.5; Calculate the upper limit of network latency fluctuation. Since Δt2=1000ms>L2=165.4ms, the timestamp verification fails, and the request is rejected. At another moment, a call request with ID3 is received from requester C, Δt3 = 20ms; the characteristics of ID3 are obtained from steps S1-3: μ d,3 =45.3ms, σ 2 d,3 =48.2ms 2 CV3≈0.153; since CV3=0.153≤0.2, it is marked as stable, λ=3; calculate Since Δt3=20ms≤L3=66.1ms, the verification is successful.
[0024] Step S2-2: After successful verification, extract the SQL statement string S carried in the request. sql_cur :SELECT * FROMusers WHERE user_id='123' OR '1' = '1'; change S sql_cur Substitute the original SQL statement template corresponding to the shared interface to generate a complete syntax tree (Tree). cur With the pre-stored standard syntax tree std Perform structural comparison; after comparison, Tree cur An additional "OR" branch node was added, with a structural difference δ=0.82; a preset difference tolerance threshold δ was set. th =0.3; since δ=0.82>δ th =0.3, indicating that the SQL statement caused an unexpected change in the semantic structure, thus blocking this call request; Step S2-3: Based on this blocking, calculate the historical authentication failure count F corresponding to ID3 in Step S1-5. fail,3 Updated from 3 to 4, i.e., F fail,3,new =4, replace the original value, and record the time T when this failure occurred. fail,4 ; Step S2-4: Calculate the threshold constraint coefficient of ID3; set the time decay factor γ=0.01 and calculate the weighted value. The time distribution of the four failure records is as follows: one failure within the most recent hour, two failures within the last 1-24 hours, and one failure 24 hours ago. The decay weight for each failure is calculated and summed to obtain F. weighted,3 =3.67; Set the amplitude attenuation factor β=0.1, and calculate the threshold constraint coefficient α3=e -0.1×3.67 ≈0.69; Calculate the growth rate v of the number of ID3 failures within the most recent preset time period. fail =1 time / hour, set preset growth rate threshold v th =0.8 times / hour; due to v fail =1>v th =0.8, calculate the acceleration decay factor ρ=e -0.5×(1-0.8) ≈0.9; This yields the final threshold constraint coefficient α. 3,final =α3×ρ≈0.62.
[0025] Step S3: Based on the historical call volume baseline data obtained in Step S1, construct a judgment rule to distinguish between normal call mode and abnormal call mode. Use the judgment rule to identify and remove abnormal points in the historical call volume baseline data. Based on the normal business fluctuation samples retained after removing abnormal points, generate the upper limit of the initial call volume confidence interval of the shared interface. Step S3-1: Obtain the call count sequence C={156,142,203,165,198} from step S1-2, perform random subsampling on sequence C, and recursively construct isolation trees; each isolation tree performs binary division on the subsamples by randomly selecting segmentation features and segmentation values until the preset height limit is reached; a total of 5 isolation trees are constructed, which together serve as the isolation forest determination rule; Step S3-2: Calculate the anomaly score for each data point in sequence C using the Isolation Forest decision rule. Set the preset isolation threshold to 0.65. The anomaly score of the third data point, 203, is 0.72, exceeding the threshold, and is therefore identified as an anomaly and removed. The remaining four data points are retained to form the normal business fluctuation sample set C. normal ={156,142,165,198}, s=4; Step S3-3: Calculate the normal business fluctuation sample set C normal mean times / hour, standard deviation Calls / hour; set the preset confidence multiple φ=2, and calculate the upper limit of the initial call volume confidence interval U. init =μ c +φ×σ c =165.25 + 2 × 20.6 ≈ 206 times / hour; Step S4: Using the threshold constraint coefficient calculated by accumulating the historical authentication failure count in step S2 and weighting it by time decay, the upper limit of the initial call volume confidence interval generated in step S3 is corrected. The corrected upper limit of the confidence interval is used as the call volume control threshold for the current requester identifier in the next period. The value of the threshold constraint coefficient decreases as the number of historical authentication failures after time decay weighting increases, so that the upper limit of the corrected confidence interval decreases as the number of recent historical authentication failures increases. Step S4-1: Obtain the final threshold constraint coefficient α for ID3 from step S2-4. 3,final =0.62; Step S4-2: Set the upper limit U of the initial call confidence interval generated in step S3-3. init =206 multiplied by the final threshold constraint coefficient α 3,final The upper limit of the corrected confidence interval U is obtained. final,3 =α 3,final ×U init=0.62×206≈128 times / hour; Step S4-3: Place U final,3 =128 is dynamically set as the threshold for controlling the number of calls to ID3 in the next cycle.
[0026] The system includes: a feature extraction module, a real-time authentication module, an initial threshold generation module, and a threshold correction module; The feature extraction module is used to extract historical network latency features, historical call volume baseline data, and historical authentication failure counts from historical operation behavior data for different requesters. The real-time authentication module is used to dynamically set the timestamp verification range based on the historical network latency characteristics of the current requester, and to block the request and accumulate the number of authentication failures when abnormal behavior is detected. The initial threshold generation module is used to generate an initial call volume limit based on historical call volume baseline data; The threshold correction module is used to correct the initial call limit using the threshold constraint coefficient obtained by time decay weighting, so as to obtain the call count control threshold.
[0027] The feature extraction module includes: The data acquisition unit is used to acquire historical operation behavior data and extract the requester identifier set; The baseline construction unit is used to statistically generate historical call volume baseline data by segmenting according to a preset time window. The network latency feature statistics unit is used to count the historical network latency features corresponding to each requester identifier; The failure count unit is used to count the number of historical authentication failures of each requester identifier within a preset historical time period; The feature aggregation unit is used to use the number of historical authentication failures as statistical features of the request behavior of the corresponding requester.
[0028] The real-time authentication module includes: The verification window setting unit is used to select the corresponding fluctuation range and set the effective time deviation range according to the network latency variation coefficient of the current requester identifier. The security parsing unit is used to compare the syntax tree of the SQL statement in the request with the standard syntax tree to identify abnormal behavior and block the request; The failure accumulation unit is used to accumulate the number of historical authentication failures of the current requester after the request is blocked and to record the failure time. The constraint coefficient calculation unit is used to obtain the weighted number of failures and determine the threshold constraint coefficient by accumulating the time weights of each failure record.
[0029] The threshold correction module includes: The constraint coefficient secondary correction unit is used to perform secondary compression on the threshold constraint coefficient to obtain the final threshold constraint coefficient when the failure rate exceeds a preset threshold. The multiplication correction unit is used to multiply the initial call volume limit by the final threshold constraint coefficient to obtain the corrected call volume limit; The threshold setting unit is used to dynamically set the corrected call volume limit to the call count control threshold for the current requester identifier in the next cycle.
[0030] The initial threshold generation module includes: The judgment rule construction unit is used to randomly sample historical call volume baseline data and recursively construct judgment rules; The anomaly removal unit is used to identify and remove anomalies in the call count sequence using judgment rules. The upper limit generation unit is used to generate the initial call volume upper limit based on the normal business fluctuation samples retained after removing outliers.
[0031] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.
Claims
1. A method for monitoring security of a shared interface based on data analysis, characterized in that: Includes the following steps: The historical operation behavior data of the shared interface is obtained and its features are extracted and structured to obtain the historical network latency features, historical call volume baseline data and historical authentication failure number corresponding to different requester identifiers; In response to a shared interface call request, the current requester identifier and request timestamp are obtained. The effective time deviation range for timestamp verification is dynamically set according to the historical network latency characteristics corresponding to the current requester identifier. After the verification is successful, security parsing is performed. When abnormal behavior is detected, the request is blocked and the number of authentication failures is accumulated. An initial call volume limit is generated based on the historical call volume baseline data, and the initial call volume limit is corrected using a threshold constraint coefficient obtained by weighting the accumulated authentication failure counts by time decay. The corrected call volume limit is then used as the call count control threshold for the current requester identifier in the next cycle.
2. The shared interface security monitoring method based on data analysis according to claim 1, characterized in that: The effective time deviation range for timestamp verification, dynamically set according to the historical network latency characteristics corresponding to the current requester identifier, includes: The network latency mean, network latency variance, and network latency coefficient of variation (CFR) corresponding to the current requester identifier are obtained from the historical network latency characteristics. The CFR is the ratio of the network latency variance to the network latency mean. The CFR is compared with a preset variation threshold, and the type of the current requester identifier is determined based on the comparison result. When the CFR is less than or equal to the preset variation threshold, the current requester identifier is determined to be stable, and the effective time deviation range is set based on the sum of the network latency mean and a first multiple of the network latency variance. When the CFR is greater than the preset variation threshold, the current requester identifier is determined to be jittery, and the effective time deviation range is set based on the sum of the network latency mean and a second multiple of the network latency variance, wherein the first multiple is greater than the second multiple.
3. The shared interface security monitoring method based on data analysis according to claim 1, characterized in that: The threshold constraint coefficients obtained through time decay weighting include: Obtain the cumulative number of authentication failures and the occurrence time of each failure record; for each failure record, calculate the time interval between the occurrence time of each failure record and the current time; calculate the time weight of each failure record according to the time interval corresponding to each failure record; sum the failure records according to their corresponding time weights to obtain the weighted failure count; and calculate the threshold constraint coefficient based on the weighted failure count using a preset amplitude attenuation factor.
4. The shared interface security monitoring method based on data analysis according to claim 3, characterized in that: The threshold constraint coefficient calculated using the preset amplitude attenuation factor includes: The system obtains the number of failure records of the current requester identifier within the most recent preset time period, where the most recent preset time period represents a historical time period of preset length ending at the current time. Based on the number of failure records within the most recent preset time period and the duration of the most recent preset time period, the system determines the failure count growth rate of the current requester identifier. The system compares the failure count growth rate with a preset growth rate threshold. When the failure count growth rate is greater than the preset growth rate threshold, the threshold constraint coefficient is reduced and corrected, and the reduced and corrected result is used as the final threshold constraint coefficient. When the failure count growth rate is less than or equal to the preset growth rate threshold, the determined threshold constraint coefficient is directly used as the final threshold constraint coefficient.
5. The shared interface security monitoring method based on data analysis according to claim 1, characterized in that: The step of generating the initial call volume limit based on the historical call volume baseline data includes: Obtain a call count sequence arranged in chronological order from the historical call volume baseline data; perform multiple random samplings on the call count sequence, and recursively construct a decision tree based on the subsamples of each sampling. Each decision tree is constructed by repeatedly binary partitioning the subsamples, and the constructed decision trees are used together as the decision rules; calculate the abnormality score for each call count in the call count sequence using the decision rules; identify call counts with abnormality scores exceeding a preset score threshold as anomalies and remove them from the call count sequence; construct a normal business fluctuation sample set from the call counts retained after removing anomalies; and generate the initial call volume upper limit based on the statistical characteristics of each call count in the normal business fluctuation sample set.
6. The shared interface security monitoring method based on data analysis according to claim 1, characterized in that: The step of correcting the initial call volume limit using a threshold constraint coefficient obtained by weighting the accumulated historical authentication failure counts by time decay includes: Obtain the threshold constraint coefficient obtained by time decay weighting; multiply the initial call volume limit by the threshold constraint coefficient, and use the product as the corrected call volume limit.
7. A data analysis-based shared interface security monitoring system, used to execute the data analysis-based shared interface security monitoring method according to any one of claims 1-6, characterized in that: The system includes: The module includes a feature extraction module, a real-time authentication module, an initial threshold generation module, and a threshold correction module. The feature extraction module is used to extract historical network latency features, historical call volume baseline data, and historical authentication failure counts from historical operation behavior data for different requesters. The real-time authentication module is used to dynamically set the timestamp verification range based on the historical network latency characteristics of the current requester, and to block the request and accumulate the number of authentication failures when abnormal behavior is detected. The initial threshold generation module is used to generate an initial call volume limit based on historical call volume baseline data; The threshold correction module is used to correct the initial call limit using the threshold constraint coefficient obtained by time decay weighting, so as to obtain the call count control threshold.
8. A shared interface security monitoring system based on data analysis according to claim 7, characterized in that: The feature extraction module includes: The data acquisition unit is used to acquire historical operation behavior data and extract the requester identifier set; The baseline construction unit is used to statistically generate historical call volume baseline data by segmenting according to a preset time window. The network latency feature statistics unit is used to count the historical network latency features corresponding to each requester identifier; The failure count unit is used to count the number of historical authentication failures of each requester identifier within a preset historical time period; The feature aggregation unit is used to use the number of historical authentication failures as statistical features of the request behavior of the corresponding requester.
9. A shared interface security monitoring system based on data analysis according to claim 7, characterized in that: The real-time authentication module includes: The verification window setting unit is used to select the corresponding fluctuation range and set the effective time deviation range according to the network latency variation coefficient of the current requester identifier. The security parsing unit is used to compare the syntax tree of the SQL statement in the request with the standard syntax tree to identify abnormal behavior and block the request; The failure accumulation unit is used to accumulate the number of historical authentication failures of the current requester after the request is blocked and to record the failure time. The constraint coefficient calculation unit is used to obtain the weighted number of failures and determine the threshold constraint coefficient by accumulating the time weights of each failure record.
10. A shared interface security monitoring system based on data analysis according to claim 7, characterized in that: The threshold correction module includes: The constraint coefficient secondary correction unit is used to perform secondary compression on the threshold constraint coefficient to obtain the final threshold constraint coefficient when the failure rate exceeds a preset threshold. The multiplication correction unit is used to multiply the initial call volume limit by the final threshold constraint coefficient to obtain the corrected call volume limit; The threshold setting unit is used to dynamically set the corrected call volume limit to the call count control threshold for the current requester identifier in the next cycle; The initial threshold generation module includes: The judgment rule construction unit is used to randomly sample historical call volume baseline data and recursively construct judgment rules; The anomaly removal unit is used to identify and remove anomalies in the call count sequence using judgment rules. The upper limit generation unit is used to generate the initial call volume upper limit based on the normal business fluctuation samples retained after removing outliers.