An API interface behavior characterization and dynamic updating method, system, device and medium supporting continuous evolution

Abstract

This invention discloses a method, system, device, and medium for supporting continuously evolving API interface behavior representation and dynamic updating, belonging to the field of API interface behavior analysis technology. It includes: standardizing and parsing access records within a time window and extracting multi-dimensional behavioral features to generate a behavior representation vector; constructing an interface behavior prototype based on time-decay weighted aggregation of historical reliable windows; determining whether the current window participates in the profile update through dual gating of accumulated behavior drift and profile update risk cost; and performing incremental updates on windows that meet the conditions according to a controlled update rate. This invention solves the problem of API interface behavior baseline mismatch due to business evolution and detection failure due to abnormal access pollution, achieving continuous dynamic updating of the interface behavior prototype in normal evolution scenarios and baseline integrity protection in abnormal disturbance scenarios.

Description

Technical Field

[0001] This invention relates to the field of API interface behavior analysis technology, specifically to a method, system, device, and medium for representing and dynamically updating API interface behavior that supports continuous evolution. Background Technology

[0002] During the long-term operation of enterprise information systems, the composition of API users, the structure of request parameters, the distribution of return statuses, and the call chain relationships continuously change with adjustments in business needs, version iterations, and system reconstructions. These changes can be categorized into gradual migrations caused by normal business evolution and occasional deviations caused by abnormal access, attack traffic, or short-term disturbances. These two types of deviations differ fundamentally in their statistical characteristics. Existing API behavior modeling methods typically construct static behavioral baselines based on historical access records, using single-dimensional indicators such as access frequency, error rate, or field sets to characterize interface behavior. This fails to comprehensively consider multi-dimensional behavioral signals such as shifts in call user distribution, changes in parameter structure, return status migrations, and adjustments in the call chain context. Consequently, there is a lack of accurate quantification of the degree to which the interface continuously deviates from its historical behavioral prototype within a time window. Regarding profile update strategies, existing methods either employ periodic full reconstruction, which cannot respond promptly to normal business evolution of the interface; or they use simple incremental accumulation, lacking credibility screening to determine whether the current window's access records are suitable for profile updates. This allows abnormal requests and attack traffic to directly pollute the interface behavior prototype, leading to baseline distortion. Summary of the Invention

[0003] In view of the above-mentioned problems, the present invention provides a method, system, device and medium for representing and dynamically updating API interface behavior that supports continuous evolution.

[0004] Therefore, the technical problem solved by this invention is: during the long-term operation of an API interface, how to quantify the degree of continuous deviation and update risk of interface behavior based on multi-dimensional behavioral characteristics within a time window, and how to perform controlled incremental updates on the interface behavior prototype under the premise of distinguishing between normal business evolution and abnormal disturbances, so that the behavior prototype can be continuously updated with the normal evolution of the interface while resisting abnormal sample contamination.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: a method for representing and dynamically updating API interface behavior that supports continuous evolution, comprising, Obtain the access records of the API interface within the current time window, and parse the access records into standardized records; Feature extraction is performed on the standardized records to obtain the behavior representation vector of the current time window; The behavior prototype of the API interface is constructed based on the behavior representation vector of a trusted historical time window. The cumulative amount of behavioral drift is determined based on the degree of continuous deviation between the behavioral representation vector of the current time window and the behavioral prototype; the risk cost of profile update is determined based on the degree of deviation of the standardized record of the current time window from the behavioral prototype. When both the cumulative amount of behavior drift and the risk cost of updating the profile meet the preset update conditions, the behavior prototype is incrementally updated based on the behavior representation vector of the current time window; when neither the cumulative amount of behavior drift nor the risk cost of updating the profile meets the preset update conditions, no update operation is performed on the behavior prototype.

[0006] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, the feature extraction includes: Calculate the cumulative intensity of behavioral changes in the current time window based on the standardized records; When the cumulative intensity of the behavior change is greater than the preset behavior change threshold, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window; When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is an adjacent preceding time window, the fusion ratio is determined based on the cumulative intensity of the behavior change and the preset behavior change threshold. The behavior representation vectors of the adjacent preceding time windows and the behavior features of the current time window are weighted and fused according to the fusion ratio to obtain the behavior representation vector of the current time window. When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is no adjacent preceding time window, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window.

[0007] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, the incremental update includes: The single update magnitude of the behavior prototype is determined by the difference between the risk cost of updating the profile in the current time window and the preset risk cost threshold. Based on the single update magnitude, the behavior prototype is incrementally updated according to the behavior representation vector of the current time window to obtain the updated behavior prototype.

[0008] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, wherein: determining the cumulative amount of behavior drift includes: The current time window is divided into multiple sub-time periods, and the standardized records are assigned to the corresponding sub-time periods according to the request time to obtain a subset of access records for each sub-time period. Feature extraction is performed on the subset of access records to obtain the behavioral representation vector of the sub-time period; The deviation between the behavior representation vector of the sub-time period and the behavior prototype is calculated, and the deviation is accumulated over time decay within the current time window to obtain the cumulative behavior drift.

[0009] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, the determination of the risk cost of profile update includes: Access anomaly features, parameter structure offset features, and link context offset features are extracted from the standardized records, and the degree of offset of the access anomaly features, parameter structure offset features, and link context offset features relative to the corresponding historical feature set is quantified. The risk cost of updating the profile is obtained by taking the degree of offset and the behavioral deviation between the behavioral representation vector of the current time window and the behavioral prototype as input.

[0010] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, the preset update conditions must simultaneously satisfy: The number of access records in the current time window is greater than or equal to the preset minimum sample size threshold; The ratio of the number of abnormal access records returned in the current time window to the total number of access records is less than or equal to the preset abnormal ratio threshold. The cumulative amount of behavioral drift is less than or equal to a preset drift upper limit threshold; The risk cost of updating the portrait is less than or equal to a preset risk cost threshold; The trusted historical time window is a time window that simultaneously meets the preset update conditions within a historical time window. When no reliable historical time window exists, the historical time window that simultaneously meets the preset minimum sample size threshold and the preset anomaly ratio threshold is used as the initial reliable historical time window.

[0011] As a preferred embodiment of the API interface behavior representation and dynamic update method supporting continuous evolution described in this invention, the parsing includes: Identify the dynamic parameter segment of the interface path in the access record, replace the dynamic parameter segment with a preset placeholder, and obtain the path template corresponding to the interface path; The path template is used as the path identifier for the API interface in the standardized record.

[0012] This invention provides an API interface behavior representation and dynamic update system that supports continuous evolution.

[0013] To solve the above technical problems, the present invention provides the following technical solution: an API interface behavior representation and dynamic update system that supports continuous evolution, comprising: a record acquisition module, used to acquire API interface access records within the current time window, and parse the access records into standardized records; The feature extraction module is used to extract features from the standardized records to obtain the behavior representation vector of the current time window; The prototype building module is used to construct the behavioral prototype of the API interface based on the behavioral representation vector of a trusted historical time window. The drift determination module is used to determine the cumulative amount of behavior drift based on the degree of continuous deviation between the behavior representation vector of the current time window and the behavior prototype, and to determine the risk cost of profile update based on the degree of deviation of the standardized record of the current time window from the behavior prototype. The profile update module is used to incrementally update the behavior prototype based on the behavior representation vector of the current time window when both the cumulative behavior drift and the risk cost of profile update meet the preset update conditions; when the cumulative behavior drift or the risk cost of profile update does not meet the preset update conditions, no update operation is performed on the behavior prototype.

[0014] The present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method for representing and dynamically updating API interface behavior that supports continuous evolution.

[0015] The present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method for representing and dynamically updating API interface behavior that supports continuous evolution.

[0016] The beneficial effects of the present invention are as follows: The present invention performs time-attenuation weighted accumulation on the distribution of calling subjects, parameter field structure, return status distribution and link adjacency relationship changes in multiple sub-time periods within a time window, so that behavioral anomalies such as slow scanning and low-frequency overriding attempts that accumulate continuously across sub-time periods can be accurately captured, overcoming the defect that relying solely on window-level statistical snapshots cannot detect the continuous deviation process within the window.

[0017] This invention constructs an interface behavior prototype by assigning time decay weights to historical trusted windows, enabling the interface behavior baseline to be continuously updated with normal evolution scenarios such as business version iteration and call chain adjustment. This avoids the behavior baseline pointing to obsolete historical behavior patterns for a long time and prevents normal business requests from being misidentified as abnormal accesses due to outdated baselines.

[0018] This invention uses dual gating of behavior drift accumulation and profile update risk cost to prevent window access records in attack scenarios such as DDoS attacks, unauthorized batch brute-force attacks, and signature field bypass from being written into the behavior prototype, thereby preventing attack traffic from reshaping the interface behavior baseline and ensuring the reliability of the API security detection baseline.

[0019] This invention dynamically compresses the prototype update amplitude based on the risk cost of profile update, effectively suppressing the impact of residual abnormal access records in the boundary trust window on the behavioral prototype, and preventing the behavioral prototype from shifting in an abnormal direction due to excessive single update amplitude. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 The above is a flowchart of an API interface behavior representation and dynamic update method that supports continuous evolution, as provided in one embodiment of the present invention.

[0022] Figure 2 This is an interaction time sequence diagram of an API interface behavior representation and dynamic update method that supports continuous evolution, provided as an embodiment of the present invention.

[0023] Figure 3 This is an overall structural diagram of an API interface behavior representation and dynamic update system that supports continuous evolution, provided as an embodiment of the present invention. Detailed Implementation

[0024] To make the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0025] Example 1, referring to Figure 1 This is one embodiment of the present invention, which provides a method for representing and dynamically updating API interface behavior that supports continuous evolution, including: S1. Obtain the access records of the API interface within the current time window, and parse the access records into standardized records.

[0026] In some embodiments, API access records are divided according to fixed time windows. A time window is a basic statistical unit for segmenting a continuous access stream according to a preset time length.

[0027] To clarify the statistical scope to which each access record belongs, the first... Each time window is denoted as: in, Indicates the start time of the window. This indicates the window length in minutes and is pre-configured during deployment. Fixed-time window division ensures that behavioral feature calculations within each window have clear statistical boundaries, avoiding distortion of behavioral feature calculation results caused by cross-window mixing of access records.

[0028] For the API interfaces Its window The set of access records within is denoted as: in, express In the window The first Access records, This indicates the total number of access records within the window, calculated from the actual number of records collected within the window. When When this happens, skip all calculation steps in the current window and do not perform an update operation on the behavior prototype.

[0029] It is understandable that the input sources for access records include API access logs, gateway logs, application logs, authentication logs, interface documentation, and call chain records. Specifically, API access logs should at least include the interface path, request method, request time, caller identifier, request parameter structure, return status code, response latency, and returned data size; gateway logs should at least include authentication results, rate limiting results, routing results, and access source; application logs should at least include business processing status, exception stack trace, error codes, and business return codes; authentication logs should at least include authentication method and authentication result; and call chain records should at least include the tracing identifier, upstream interface, downstream interface, call order, and chain duration.

[0030] Furthermore, to eliminate the impact of differences in multi-source log formats on behavioral feature calculation, each access record is uniformly represented as follows standardized structure after parsing: in, This indicates the identifier of the calling entity, which originates from the user account, application identifier, client certificate, or access token. Indicates the request method, with values ​​ranging from GET, POST, PUT, to DELETE; This represents the template for the interface path after template processing; This indicates the returned status code or service return code; This indicates the response latency, measured in milliseconds. Indicates the size of the returned data, in bytes; Indicates the time when the request occurred.

[0031] It should be noted that, This indicates the request parameter structure, to avoid conflicts with subsequent steps involving calls to quality variables. To avoid confusion, this invention uniformly denotes the request parameter structure as follows: Parsed into a collection of parameter fields Field hierarchy relationship and field type collection The structured representation includes field types such as string, numeric, boolean, array, and object.

[0032] The call chain context is represented by the following structured representation to accurately describe the position of an interface in the call chain: in, Indicates the link tracing identifier. Indicates the upstream interface. Indicates the downstream interface. This indicates the order in which the interface is called in the chain. This indicates the link latency. The structured representation of the link context enables subsequent calculations of link adjacency change intensity to accurately track changes in the interface's role within the call chain.

[0033] By unifying the parsing of multi-source log data into the above standardized structure, access records from different log sources have consistent field definitions in four dimensions: caller identifier, request parameter structure, return status information, and link context information, thus eliminating the problem of incomparable behavioral feature calculations caused by differences in log formats.

[0034] After step S1 is completed, output a set of standardized access records. The API interface access records consist of an interface path template set, a parameter field structure table, a call subject table, and a link context table. Through the execution of step S1, the API interface access records form a computable and comparable standardized representation, solving the problem in existing technologies where heterogeneous access record formats and inconsistent path identifiers prevent cross-window continuous modeling of the same interface behavior.

[0035] In some embodiments, step S1 includes steps S11 to S12, wherein: S11. Identify the dynamic parameter segment of the interface path in the access record, replace the dynamic parameter segment with a preset placeholder, and obtain the path template corresponding to the interface path.

[0036] Understandably, dynamic parameter segments refer to the parameter portions of the interface path that change with the request instance, including numeric IDs, UUIDs, timestamps, order numbers, device IDs, and user IDs. Without templated processing of dynamic parameter segments, the same API interface will appear as multiple different paths in the access log due to different request instances carrying different parameter values. This results in a fragmented statistical scope for subsequent caller distribution, parameter structure, and return status, making it impossible to accurately reflect the behavior pattern of a single interface at the correct interface granularity.

[0037] Furthermore, the original interface path of each access record is scanned to identify path segments that conform to numeric sequences, UUID format, timestamp format, or other preset dynamic parameter patterns, and these segments are uniformly replaced with preset placeholders. .

[0038] For example, the original path: After template processing, it is converted into a path template: Through this process, similar requests with different parameter values ​​under different request instances are normalized to a unified path template, and all access records under the same interface can be aggregated and statistically analyzed, ensuring that behavioral characteristics such as the distribution of call subjects, parameter field structure, and return status distribution are calculated on a consistent interface identifier dimension.

[0039] In an API access monitoring scenario for a company's expense reimbursement information system, which includes interfaces for user login, expense report query, expense report submission, attachment upload, and approval workflow, interface access records are collected through an API gateway, application logs, and a tracing system. Interface behavior is analyzed in 10-minute time windows. This is used to query the details of a specific expense report. Its original path contains the expense report number, and different expense reports correspond to different path values. After processing in step S11, all expense report query requests are uniformly normalized to the path template. This enables subsequent behavioral feature extraction to aggregate and statistically analyze all access records of the interface based on a unified interface identifier, ensuring the consistency of interface granularity in cross-window behavioral feature comparison.

[0040] S12. Use the path template as the path identifier for the API interface in the standardized record.

[0041] Understandably, the path template serves as a unique path identifier for the API interface in the standardized record, ensuring that subsequent multi-dimensional behavioral feature extraction and interface behavior prototype construction are based on a consistent interface identifier dimension for statistical analysis and modeling. Within different time windows, access records under the same path template can be accurately attributed to the same API interface, guaranteeing interface consistency in cross-window behavioral feature comparison and drift determination.

[0042] S2. Extract features from the standardized records to obtain the behavior representation vector of the current time window.

[0043] In some embodiments, for In the window Standardized access record set within Behavioral features are extracted from six dimensions: path structure, caller distribution, parameter structure, timing access, return status, and link context, to construct an interface behavior feature vector. in, Indicates the characteristics of the interface path structure. Indicates the distribution characteristics of the calling entities. Indicates the structural characteristics of the parameters. Indicates time-series access characteristics, Indicates the return status characteristics, This represents the contextual characteristics of the link. Six dimensions characterize the behavior of the interface within the current time window from different perspectives. Compared with existing technologies that rely on only a single dimension such as access frequency or error rate, this approach can more comprehensively capture the multi-faceted changes in interface behavior.

[0044] It is understandable that the specific composition of each dimension of features is as follows: Interface path structure features It consists of path hierarchy depth, number of path fragments, number of path variable fragments, and request method encoding; caller distribution characteristics. It consists of the number of calling entities, the distribution of entity access frequency, and the entity access entropy; parameter structure characteristics. It consists of the number of fields, the distribution of field types, the depth of field hierarchy, the field missing rate, and the changes in the field set; the returned status features Composed of status code distribution, error status ratio, and service exception return ratio; link context characteristics It consists of upstream interface set, downstream interface set, link sequence position, and link time statistics.

[0045] Furthermore, to characterize the continuous changing trend of interface access behavior within a time window, access behavior closer to the end of the window contributes more to the current behavior state; therefore, time-series access characteristics are considered. A time decay factor is introduced for weighting. In the window The time decay access strength within is defined as: in, express At any moment The instantaneous access intensity in the vicinity is estimated from the number of accesses per unit time. This represents the time decay coefficient, determined by the preset half-life. (Unit: Number of sub-time periods) Determined: Pre-configured during deployment, those skilled in the art typically select the appropriate timeframe based on the rhythmic cycle of business access. For example, when dividing a 10-minute time window into 5 sub-time periods, one could choose... This makes the access weight of the end of the window approximately twice that of the beginning of the window.

[0046] Because access records are stored in discrete form, the window Divided into The integral above is approximated by summing the values ​​over each sub-time period: in, Indicates the first Within each time period The number of visits is obtained by counting the access records within that sub-time period; Indicates the length of the sub-time period, by Calculated; Pre-configured during deployment; For the purpose of preventing the denominator from being zero, a positive number is pre-set during deployment. Those skilled in the art typically choose an extremely small positive number, such as... The introduction of time-decayed access intensity gives higher weight to sudden surges in access behavior at the end of the window, enabling more sensitive capture of short-term abnormal changes in the interface access rhythm.

[0047] In the API access monitoring scenario of a company's expense reimbursement information system, the number of accesses to the interface increases significantly at the end of the window during peak reimbursement periods. The time decay access intensity can accurately reflect this trend, so that it can be fully reflected in the calculation of the cumulative intensity of subsequent behavioral changes.

[0048] Furthermore, to quantify the degree of change in the distribution of callers between adjacent windows, the difference in the proportion of callers accessing the interface between two adjacent windows is used as a benchmark to calculate the intensity of the caller distribution shift. It should be noted that using the difference between adjacent windows as a benchmark here aims to reflect the degree of distribution migration of interface call sources in the short term, and is suitable for calculating the cumulative intensity of behavioral changes. This complements the parameter structure shift risk based on historical feature sets in step S44 in terms of design purpose; the former characterizes short-term dynamic changes, while the latter measures the deviation risk relative to historical stable states.

[0049] set up Display window Internal access The set of callers Indicates the calling body In the window The percentage of visits within the specified area is calculated as follows: in, Indicates the calling body In the window Internal access The number of times is determined by the access log within the window. The number of records was counted. The intensity of the distribution offset of the calling subject was determined. Defined as: The value is 0 when adjacent windows have completely identical call subjects and the same access ratio, and approaches 2 when the call subjects are completely different. This indicator can effectively reflect the degree of distribution migration of interface call sources between adjacent windows, providing a quantitative basis for subsequent judgment on whether behavior changes are caused by abnormal call subjects.

[0050] In an API access monitoring scenario for a company's expense reimbursement information system, when unauthorized users attempt to access the expense report query interface in batches, a large number of new entities will appear in the caller set. This will increase significantly, thus being fully reflected in the cumulative intensity of behavioral changes.

[0051] Furthermore, to quantify the degree of change in parameter field structure between adjacent windows, the differences in parameter field structure are calculated. Let... express In the window The set of parameter fields appearing within are derived from standardized records. The union of the statistics is obtained.

[0052] To differentiate the importance of different fields, the inventors noted that different fields have significantly different impacts on the stability of interface behavior. The absence of identity or permission fields often indicates abnormal access, and the absence of fields that have consistently occurred historically is more alarming. Therefore, a field importance rating system was introduced. Based on field sensitivity level With field historical stability Jointly determined: in, The sensitivity level of a field is determined by whether the field belongs to the categories of identity identifier, account, mobile phone number, address, transaction amount, device number, or permission field. Sensitive fields have higher values. Indicates the historical stability of the field; express The historical field set consists of all fields that have appeared in the historical trust window. The introduction of field importance gives greater weight to the absence or addition of highly sensitive and stable fields in parameter structure differences, enabling accurate identification of key abnormal changes in parameter structure.

[0053] Field historical stability The frequency of a field's occurrence within the historical reliability window is used to quantitatively characterize the field's persistence in historical execution. in, Indicates the end window A collection of historically reliable windows, This indicates an indicator function; a value of 1 indicates a field. The field appears in the history window, with a value of 0 indicating that it has not appeared. The higher the historical stability of a field, the more consistently it appears in the historical reliability window. When the field is missing or added, it contributes more to the differences in the parameter structure, which helps to distinguish between missing key fields and occasional field changes.

[0054] Differences in parameter field structure based on field importance Defined as: The value is 0 when the parameter field sets of adjacent windows are completely identical, and the value approaches 1 when the fields are completely different.

[0055] In an API access monitoring scenario for a company's expense reimbursement information system, the request signature field of the expense report query interface... This field has a high level of sensitivity and historical stability. When attack traffic bypasses the signature verification mechanism to initiate requests, this field will experience batch missing entries. The absence of highly important fields will significantly increase the accuracy of identifying key anomalous changes in the parameter structure.

[0056] Furthermore, to quantify the degree of change in the return state distribution between adjacent windows, the change in the return state distribution is calculated. Let... This represents the set of return status codes. Indicates status code In the window The percentage within is calculated as follows: in, express In the window Internal return status code The number of times is determined by the access log within the window. The number of records was obtained from the statistics. It reflects the proportion of each status code within the current window and is a basic statistic for characterizing the behavior of the interface return status.

[0057] Changes in return status distribution Defined as: It can reflect the degree of distribution migration of error status codes and business exception return codes between adjacent windows of the interface. When the interface experiences batch unauthorized access, service exceptions or parameter errors, this indicator will increase significantly.

[0058] In an API access monitoring scenario for a company's expense reimbursement information system, the proportion of 403 status codes increases significantly when unauthorized access requests increase. This will be increased accordingly, so that the behavioral changes in the returned state dimension are reflected in the calculation of the cumulative intensity of behavioral changes.

[0059] Furthermore, to quantify the degree of change in link context between adjacent windows, the intensity of link adjacency change is calculated. Let... express In the window The set of upstream and downstream interfaces within the window, as recorded in the access logs within the window. and The union of the results is used to obtain the link adjacency change intensity. Defined as: The value is 0 when the upstream and downstream interfaces of adjacent window links are completely identical, and approaches 1 when they are completely different. This indicator can reflect the change of the role of the interface in the call link. When the interface is connected to a new business process or removed from the existing link, this indicator will change significantly, providing a quantitative basis for judging whether the change of interface behavior is caused by the adjustment of the link structure.

[0060] In an API access monitoring scenario for a company's expense reimbursement information system, when the expense report query interface is temporarily connected to a new approval workflow... This will increase accordingly, so that the adjustment of the link structure is reflected in the cumulative intensity of behavioral changes, distinguishing it from other dimensional changes caused by attack traffic.

[0061] In some embodiments, step S2 may include steps S21 to S24, wherein: S21. Calculate the cumulative intensity of behavioral changes in the current time window based on the standardized records.

[0062] It is understandable that the cumulative intensity of behavioral changes is a time-decay-weighted accumulation of multi-dimensional behavioral changes of the interface within the entire time window. Unlike the method of only comparing the statistical differences of adjacent window endpoints, it can characterize the degree of continuous change of interface behavior within the window.

[0063] Therefore, define At any moment Intensity of instantaneous behavioral changes The intensity of change is determined by the calling entity. Intensity of parameter structure change Intensity of return status change Link context change intensity and changes in access intensity Five dimensions weighted composite: in, , , , The differences are calculated from the distribution of the calling entities, the set of parameter fields, the distribution of return status, and the differences between the upstream and downstream sets of the corresponding sub-time period and the previous sub-time period. Calculated from the rate of change in the number of visits: in, Indicates the first The number of visits within a sub-time period is a metric that reflects the relative change in visit intensity between adjacent sub-time periods. For non-negative weights, satisfying: Each weight is pre-configured during deployment based on the sensitivity of the business scenario to changes in different dimensions. Those skilled in the art can adjust it according to business characteristics; for example, it can be increased for high security-sensitive scenarios. (Calling subject) and The weighting of parameters. The five-dimensional weighted synthesis enables the intensity of instantaneous behavioral changes to comprehensively reflect the synchronization anomalies of the interface in multiple dimensions, avoiding misjudgments caused by fluctuations in a single dimension.

[0064] Furthermore, In the window Cumulative intensity of internal behavioral changes Defined as the time decay integral of the intensity of instantaneous behavioral change, to capture the degree of continuous change of the interface throughout the entire time window: in, The time decay factor, representing the intensity of behavioral changes, is pre-configured during deployment. Since access records are stored in discrete form, it is approximated as follows: in, Indicates the first The average intensity of behavioral change within a sub-time period is obtained by weighted synthesis of the intensity of change in five dimensions within that sub-time period.

[0065] The cumulative intensity of behavioral changes expresses the degree of continuous change of the interface throughout the entire window with a single numerical value. It can distinguish between short-term local disturbances and continuous changes throughout the entire window, providing a driving signal for the adaptive generation of behavioral representation vectors in steps S22 to S24.

[0066] S22. When the cumulative intensity of the behavior change is greater than the preset behavior change threshold, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window.

[0067] Understandably, a threshold for behavioral change is preset to determine the criterion for assessing the cumulative intensity of behavioral change. By interface In a set of historically reliable windows Mean of cumulative intensity of change in the middle class with standard deviation It is confirmed that the number of historical reliable windows during statistical analysis is no less than the minimum statistical sample size. : in, The threshold adjustment coefficient is pre-configured during deployment; The minimum statistical sample size is pre-configured during deployment and is determined by those skilled in the art based on statistical confidence requirements. It typically ranges from 20 to 100 historical confidence windows.

[0068] Furthermore, when This indicates that the degree of change in the interface behavior within the current window exceeds the historical reliability range, and the interface behavior is in a state of continuous evolution. At this point, feature extraction is performed on the standardized records of the current window to create a behavior feature vector. The mean of historical reliable windows with standard deviation Normalization is performed to eliminate differences in the dimensions of different features, resulting in normalized feature vectors. : in, The first characteristic vector represents the behavior feature vector. One portion, and From historical reliable window set Statistics show that the number of historically reliable windows used in the statistical analysis is no less than [number missing]. .

[0069] Furthermore, the normalized feature vector is input into a predefined behavior representation mapping function. This yields a fixed-dimensional behavior representation vector: in, Represents a behavioral representation vector. The dimension representing the representation is pre-configured during deployment. Those skilled in the art typically select it based on the dimension of the behavioral feature vector and the required representation accuracy. For example, it could be chosen as... It is 1 / 4 to 1 / 2 of the feature dimension. Mapping function This is implemented using a feedforward network that includes an input projection layer, a nonlinear transformation layer, and an output normalization layer. in, , , , For model parameters, Represents a non-linear activation function. Indicates the output transformation function. The vector represents the 2-norm. Model parameters can be trained using access records from a historical reliability window, or initialized online using rule encoding and linear mapping. Output normalization ensures that the behavior representation vector has a unit norm, making the physical meaning of the cosine distance calculation in subsequent step S43 consistent.

[0070] When the cumulative intensity of behavioral changes exceeds the preset behavioral change threshold, a behavioral representation vector is directly generated based on the current window features to ensure that the behavioral features in the continuously evolving state can be fully reflected in the representation vector.

[0071] In an API access monitoring scenario for a company's expense reimbursement information system, when the expense report query interface experiences continuous changes across multiple dimensions during peak approval periods, such as a large number of newly added callers, a batch of missing request signature fields, and a sharp increase in unauthorized access,... Exceed Step S22 is triggered, where the behavior characteristics of the current window are fully incorporated into the generation of the behavior representation vector, so that the representation vector can accurately reflect the abnormal behavior state of the interface during this time period.

[0072] S23. When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is an adjacent preceding time window, a fusion ratio is determined based on the cumulative intensity of the behavior change and the preset behavior change threshold. The behavior representation vectors of the adjacent preceding time windows and the behavior features of the current time window are weighted and fused according to the fusion ratio to obtain the behavior representation vector of the current time window.

[0073] Understandably, behavioral features refer to the features extracted from standardized records within the current time window and then mapped using a mapping function. The initial behavioral representation result obtained is the result obtained in step S22 after normalization and calculation by the mapping function. .

[0074] when This indicates that the changes in interface behavior within the current window are within a historically reliable range, and the impact of short-term access fluctuations on behavioral representation should be appropriately suppressed. At this point, a smooth fusion mechanism is introduced, based on... and The relative relationship is used to calculate and smoothly update the weights. : in, This indicates the proportion of the current window behavior representation that contributes to the fusion result. This represents the slope of the weight change, pre-configured during deployment. Those skilled in the art typically use values ​​ranging from 1 to 10, with larger values ​​being preferred. The value makes the weights change more steeply near the threshold, making them more sensitive to changes in behavior. When hour, The contribution ratio of the preceding time window is no less than that of the current window.

[0075] Furthermore, the smoothed fusion of the behavioral representation vector The behavior representation vector of the current window Smooth behavior representation vectors of adjacent preceding time windows The weighted fusion yields: Adjacent preceding time windows Smooth behavior representation vector The output result of step S2 executed by the preceding window is persisted and then read; when the preceding window executes S24 (first run), In other words, the smoothed behavior representation vector of the first effective window is the same as its initial behavior representation vector. The smooth fusion mechanism enables the interface behavior representation to maintain a strong historical memory during the behavior stabilization phase, suppressing drastic changes in representation caused by short-term access fluctuations.

[0076] In an API access monitoring scenario for a company's expense reimbursement information system, the access pattern of the expense report query interface remained relatively stable during off-peak hours of the reimbursement business. Below This triggers step S23, where the historical representation contribution ratio of the preceding time window is higher, enabling the behavior representation vector to maintain strong historical stability, effectively suppressing the interference of occasional access fluctuations on the representation, and avoiding normal business noise being misjudged as behavior drift.

[0077] S24. When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is no adjacent preceding time window, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window.

[0078] Understandably, when the interface is in the initialization phase after its first run or after the history has been cleared, there are no behavioral representation vectors from adjacent preceding time windows available for fusion. In this case, feature extraction is performed directly based on the standardized records of the current window to obtain the initial behavioral representation vector. in, This represents the first valid time window of the interface. It is obtained from the feature extraction and mapping function in step S22. This serves as the first effective and smooth behavior representation vector to be persistently stored for subsequent window execution step S23. This process ensures that the interface can quickly establish a behavioral representation foundation during the initialization phase, and can still execute the behavior prototype construction in subsequent step S3 normally even without historical data support.

[0079] After step S2 is completed, the output interface behavior feature vector is obtained. Time decay access strength , Intensity of the distribution offset of the calling subject Differences in parameter field structure Changes in return status distribution Link adjacency change intensity Cumulative intensity of behavioral changes and the behavior representation vector of the current time window Compared with the existing technology that uses static statistical behavioral features based on fixed time windows, step S2 can amplify the influence of the current window features when the interface behavior continues to evolve, and maintain the memory of historical behavior when the behavior is in a stable state. This allows the behavior representation vector to adapt to changes in real behavior while suppressing the interference of short-term disturbances on the stability of the representation.

[0080] S3. Construct the behavioral prototype of the API interface based on the behavioral representation vector of the trusted historical time window.

[0081] In some embodiments, the interface behavior prototype is a time-decayed weighted center of a smooth behavior representation vector within a historical reliable time window, used to represent the typical behavior state of the interface under long-term stable operating conditions. For the interface Maintain its historical credible window set It consists of time windows that previously met the preset update conditions.

[0082] To ensure that recent behavior contributes more to the behavioral prototype than long-term behavior, the inventors noted that the behavioral characteristics of long-term historical windows may deviate from the current interface state, while recent reliable windows better reflect the current stable behavior of the interface. Therefore, they introduced a time decay weight to assign weights to historical reliable windows. Historical Window Time decay weight Defined as: in, This represents the historical decay coefficient, which controls the decay rate of the historical window weight over time and is pre-configured during deployment. Represents the history window With the current window The time interval between these intervals is expressed in windows. Those skilled in the art typically select this interval based on the business evolution cycle. The value can be set to a larger value, for example, for scenarios where business evolution is rapid. The time decay weight is used to make the behavior prototype more focused on the behavioral characteristics of recent windows. The introduction of time decay weight allows the behavior prototype to be updated gradually as the interface evolves normally, avoiding excessive interference from distant historical windows in the judgment of current behavior.

[0083] Furthermore, interface behavior prototype Defined as the time decay weighted center of the historical reliable smooth representation vector: in, express In a credible historical window The corresponding smooth behavior representation vector is obtained by step S2 in the window. The output results during execution are persisted and then read. The behavior prototype serves as a reference benchmark for the stable historical behavior of the interface, is the comparison center for calculating the cumulative amount of behavior drift in subsequent step S4, and is also the target object for incremental updates in step S5.

[0084] In the API access monitoring scenario of a company's expense reimbursement information system, the behavioral prototype formed by the expense report query interface during its historical stable operation will be combined with the behavioral characteristics of the recent trusted window in a time decay weighted manner. This will enable the behavioral prototype to accurately reflect the current stable behavioral state of the interface as the business gradually evolves, providing a reliable reference benchmark for drift determination.

[0085] It is understandable that when the interface If no reliable historical window exists, the behavioral prototype needs to be initialized. The first time window that simultaneously meets the preset minimum sample size threshold and the preset anomaly ratio threshold should be used as the initialization window. ,make: in, Step S2 initializes the window The output results during execution are obtained. The initialization phase only relies on two basic conditions: sample size and the proportion of abnormal returns. This avoids the circular dependency problem that could prevent initialization from being triggered due to the lack of historical benchmarks for the accumulated amount of behavioral drift and the risk cost of profile updates.

[0086] It is easy to understand that when behavioral representations are generated only at the window level and not at the sub-time period level, the behavioral deviation of each sub-time period can be approximated by the window-level deviation, that is, let ,in Window-level smooth behavior representation vector With behavioral prototypes The cosine distance is calculated from this.

[0087] After step S3 is completed, output the interface behavior prototype. Compared with the baseline construction method based on equal weighted average of all historical data in the existing technology, step S3 uses time decay weighted aggregation to give higher weight to the behavioral characteristics of the recent trusted window while reflecting the long-term stable behavior of the interface, effectively dealing with the gradual behavior migration of the interface as it evolves with normal business.

[0088] S4. Determine the cumulative amount of behavior drift based on the degree of continuous deviation between the behavior representation vector of the current time window and the behavior prototype; determine the risk cost of profile update based on the degree of deviation of the standardized record of the current time window from the behavior prototype.

[0089] In some embodiments, in order to determine the cumulative amount of behavioral drift and provide behavioral deviation input for calculating the risk cost of profile update, it is necessary to calculate the deviation between the behavioral representation vector and the behavioral prototype for each sub-time period at the sub-time period granularity.

[0090] Understandably, the percentage of exceptions returned... Defined as: in, Display window The number of access records that return error status codes or business exception return codes is determined by the number of access records within the window. The number of records with values ​​in abnormal states is obtained by counting them. The larger the value, the higher the proportion of abnormal returns in the current window, which is an important input for the preset update condition determination in step S5.

[0091] Furthermore, the calculation purposes of the profile update risk cost and the cumulative behavior drift differ. The cumulative behavior drift is used to determine whether interface behavior has continuously deviated; the profile update risk cost is used to determine whether the current window is suitable for participating in profile updates, reflecting the comprehensive threat level of access behavior within the current window to the stability of the behavior prototype. Definition At any moment instant update risk It is a weighted composite of four dimensions: abnormal return risk, parameter structure offset risk, link context offset risk, and behavior deviation. in, This indicates a risk of abnormal return. Indicates the risk of parameter structure offset. Indicates link context offset risk. Indicates the degree of behavioral deviation; For non-negative weights, satisfying: Each weight is pre-configured during deployment based on the sensitivity of different risk dimensions to the business scenario. The four dimensions comprehensively measure the update risk of the current window from four perspectives: access anomalies, structural deviations, link changes, and representation deviations. This enables the risk cost calculation results to accurately distinguish between behavioral changes caused by normal business evolution and behavioral disturbances caused by abnormal access or attacks.

[0092] In some embodiments, step S4 includes steps S41 to S45, wherein: S41. Divide the current time window into multiple sub-time periods, and assign the standardized records to the corresponding sub-time periods according to the request time to obtain a subset of access records for each sub-time period.

[0093] Understandably, a sub-time period is a time window. Further subdivision of units, Evenly divided into Each sub-time period, the first The time range corresponding to each sub-time period is: ,in , It is pre-configured during deployment.

[0094] Standardized access record set Each record in the database is ordered by its requested time. Substitute it into the corresponding sub-time period to obtain the first... A subset of access records for each time period .

[0095] It should be noted that when the access records within a certain sub-time period are empty, the behavior representation vector of the previous non-empty sub-time period is used as the behavior representation vector for that sub-time period; if all preceding sub-time periods within the window are empty, then the window-level behavior representation vector is used. replace.

[0096] Sub-time period segmentation enables the calculation of behavior deviation within a fine-grained time range, capturing the continuous deviation trend of the interface throughout the entire time window. This differs from the method of making a one-time comparison only at the window endpoints, and can effectively distinguish between short-term local deviation and continuous deviation throughout the entire window.

[0097] In the API access monitoring scenario of a company's expense reimbursement information system, the expense report query interface may only have a small number of abnormal requests at the beginning of the window, while the number of abnormal requests continues to increase at the end of the window. The sub-time period segmentation can capture this deviation trend that gradually accumulates within the window, so that the drift accumulation accurately reflects the continuous evolution of the interface behavior.

[0098] S42. Perform feature extraction on the subset of access records to obtain the behavior representation vector of the sub-time period.

[0099] Understandably, for the first A subset of access records for each time period The feature extraction process is the same as in step S2, and after normalization, the result is input into the mapping function. , obtained the Behavioral representation vectors for each sub-time period .

[0100] It should be noted that, The behavior representation vector at the sub-time period granularity is compared with the window-level smoothed behavior representation vector output in step S2. Using the same feature extraction and mapping process, the two are comparable in the representation space, ensuring that the comparison between the sub-time period deviation calculation results and the behavioral prototype has physical meaning.

[0101] S43. Calculate the deviation between the behavior representation vector of the sub-time period and the behavior prototype, and accumulate the deviation over time within the current time window to obtain the cumulative behavior drift.

[0102] Understandably, to quantify the deviation of the behavior representation vector of a sub-time period from the behavior prototype, cosine distance is used to calculate the behavior deviation of the sub-time period. Cosine distance measures the difference in the direction of two vectors, and its value ranges from [value missing]. The value is 0 when the two vectors are in the same direction and 1 when they are orthogonal. It is not affected by the vector magnitude and is suitable for measuring the similarity of behavioral representation vectors. behavioral deviation in individual time periods Defined as: in, Indicates the first The behavioral representation vectors for each sub-time period are obtained from step S42; The interface behavior prototype is obtained from step S3; The L2 norm of a vector. The larger the value, the higher the value. The greater the directional difference between the interface behavior within a sub-time period and the historical behavior prototype, the higher the sub-time period deviation. Simultaneously, as a risk of instantaneous update in step S45 The fourth input dimension enables the calculation of the cumulative amount of behavioral drift and the risk cost of profile update.

[0103] Furthermore, to characterize the cumulative degree of interface deviation from historical behavioral prototypes throughout the entire time window, a time-decay-weighted accumulation of behavioral deviation in sub-time periods is introduced. This is the cumulative amount of behavioral drift. Defined as: in, Indicates time The behavioral deviation corresponding to the sub-time period and Corresponding in discrete implementation; The time decay factor representing the cumulative drift is pre-configured during deployment. Since access records are stored in discrete form, it is approximated as follows: The sub-time period closer to the end of the window corresponds to a larger time decay weight, making the contribution of recent continuous deviation behavior to the drift accumulation higher than that of early local deviations, thus avoiding the excessive influence of short-term disturbances at the beginning of the window on the drift determination. The behavior drift accumulation expresses the degree of continuous deviation of the interface throughout the entire window with a single numerical value, providing a quantitative input for the behavior deviation dimension of the dual gating judgment in step S5.

[0104] Furthermore, to determine the threshold for behavior drift judgment, when the historical reliable window set... The number of windows in the sample should not be less than the minimum statistical sample size. At that time, the drift threshold is calculated based on the distribution of cumulative drift within the historical reliable window. : in, and They represent The mean and standard deviation of the cumulative drift in the historical reliable window set are given by the historical reliable window. Statistics show that; The threshold adjustment coefficient is pre-configured during deployment, and is typically chosen by those skilled in the art. Larger This value corresponds to a more lenient drift judgment criterion. When At that time, the judgment In the window Behavioral drift occurs within; when At that time, it was determined that no behavioral drift had occurred.

[0105] S44. Extract access anomaly features, parameter structure offset features, and link context offset features from the standardized records, and quantify the degree of offset of the access anomaly features, parameter structure offset features, and link context offset features relative to the corresponding historical feature set.

[0106] Understandably, access anomaly characteristics refer to the percentage of access records that return error status codes or business exception return codes within the current time window. This presents a risk associated with anomaly returns. Defined as time The ratio of the number of exceptions returned to the total number of accesses within the sub-time period: in, Indicates time The number of access records that returned error status codes or business exception return codes within the corresponding sub-time period is determined by the subset of access records for that sub-time period. middle The value is obtained by counting the number of records in abnormal states; This indicates the total number of access records within this sub-time period. The larger the value, the higher the proportion of abnormal returns in the current sub-time period, and the greater the risk of introducing abnormal behavior when the current window participates in the portrait update.

[0107] Furthermore, the parameter structure offset feature refers to the degree of change in the set of parameter fields of the accessed records within the current time window relative to the historical set of parameter fields. It should be noted that, compared to step S2... The difference in the field sets of adjacent windows is used as the comparison benchmark, which poses a risk of parameter structure offset here. With historical parameter field set As a benchmark, it measures the risk of deviation of the current window from its historical stable state, and is suitable for quantifying the risk cost of profile updates. Historical parameter field set. By the end window The parameter structure is constructed by the union of all parameter fields that have appeared in the historical trusted window, persisted, and retrieved during the current window's computation. This mitigates the risk of parameter structure offset. Defined as: in, Indicates time The set of parameter fields for accessed records within the corresponding sub-time period is derived from the subset of accessed records within that sub-time period. The union of the sets is obtained by statistical analysis; The importance of a field is calculated based on the definition in step S2. Parameter structure offset risk is assessed by weighted summation of field changes, giving higher weight to the missing or added high-sensitivity, high-stability fields in the risk metric. This effectively identifies the potential contamination of the interface profile by abnormal changes in parameter fields.

[0108] Furthermore, the link context offset feature refers to the degree of change in the set of upstream and downstream interfaces of an interface within the current time window relative to the historical link context set. Historical link context set By the end window The set is the union of all upstream and downstream interfaces that have appeared in the historical trusted window, persistently stored, and read during the current window calculation. Link context offset risk. Defined as: in, Indicates time The set of upstream and downstream interfaces within a given sub-time period, consisting of a subset of access records for that sub-time period. and The union of the statistics is obtained. The value is 0 when the current upstream and downstream interfaces are completely consistent with the historical set, and the value approaches 1 when they are completely different. This can effectively reflect the potential impact of abnormal changes in the role of the interface in the link on the profile update.

[0109] S45. Using the degree of offset and the behavioral deviation between the behavioral representation vector of the current time window and the behavioral prototype as input, the risk cost of the portrait update is obtained.

[0110] It is understandable that the risk of abnormal returns obtained in step S44 is considered. Parameter structure offset risk Link context offset risk Deviation from the sub-time period behavior calculated in step S43 We obtain the time by weighted synthesis according to the instantaneous update risk formula. instant update risk .

[0111] Furthermore, a time-decay-weighted integral is introduced to account for the instantaneous update risk, resulting in a window... Risks and costs of updating internal portraits : in, The time decay factor representing the risk cost is pre-configured during deployment. Since access records are stored in discrete form, it is approximated as follows: in, Indicates the first The average instantaneous update risk within each sub-time period is obtained by weighted synthesis of the four dimensions of risk within that sub-time period. Sub-time periods closer to the end of the window correspond to larger time decay weights, making the contribution of recent risk behaviors to the risk cost of profile update higher than that of earlier risk behaviors, ensuring that the risk cost can promptly reflect abnormal accesses occurring at the end of the window.

[0112] Furthermore, when the historical reliable window set The number of windows in the sample should not be less than the minimum statistical sample size. At that time, the risk threshold for updating the profile is calculated based on the risk cost distribution within the historical reliable window. : in, and They represent The mean and standard deviation of the risk cost of updating the profile within the historical reliability window are derived from the historical reliability window. Statistics show that; The threshold adjustment coefficient is pre-configured during deployment, and is typically chosen by those skilled in the art. Larger This value corresponds to a relatively lenient risk tolerance standard.

[0113] After step S4 is completed, output the cumulative amount of behavior drift. Drift threshold Drift determination results, risks and costs of profile updates and the risk threshold for profile updates Compared with existing technologies that rely solely on a single anomaly indicator or error rate to determine update reliability, step S4 can comprehensively quantify the update risk of the current window from four dimensions: access anomaly, parameter structure offset, link context offset, and behavior deviation, thus more comprehensively identifying the potential pollution risk of abnormal calls, attack behaviors, and short-term disturbances on the interface profile.

[0114] S5. When both the cumulative amount of behavior drift and the risk cost of the profile update meet the preset update conditions, the behavior prototype is incrementally updated based on the behavior representation vector of the current time window; when the cumulative amount of behavior drift or the risk cost of the profile update does not meet the preset update conditions, no update operation is performed on the behavior prototype.

[0115] In some embodiments, step S5 specifically includes steps S51 to S54, wherein: S51. The preset update conditions must be met simultaneously: the number of access records in the current time window is greater than or equal to the preset minimum sample size threshold; the ratio of the number of abnormally returned access records in the current time window to the total number of access records is less than or equal to the preset abnormal ratio threshold; the cumulative amount of behavior drift is less than or equal to the preset drift upper limit threshold; and the risk cost of the profile update is less than or equal to the preset risk cost threshold.

[0116] It is understandable that a minimum sample size threshold is preset. Pre-configured during deployment based on the access frequency during normal interface operation, this ensures that the windows participating in profile updates have sufficient statistical representativeness. Preset anomaly ratio threshold. Pre-configured during deployment to exclude windows with an excessively high percentage of abnormal returns from directly participating in profile updates, this setting is typically based on the normal error rate of the interface's business operations. For example, for interfaces with low error rates, it may be preferable to... Preset drift upper limit threshold satisfy This ensures that profile updates only occur within windows where the degree of behavioral drift does not exceed the allowable range, preventing drift windows from contaminating the behavioral prototype. A preset risk cost threshold is also implemented. It is obtained from the historical distribution statistics in step S45.

[0117] Furthermore, the four conditions constitute a joint judgment rule based on four dimensions: sample sufficiency, degree of access anomaly, degree of behavioral deviation, and degree of update risk. All four conditions must be met simultaneously for the current window to be deemed to meet the preset update conditions. If any condition is not met, it is judged as an untrustworthy update window, thus preventing single-dimensional abnormal behavior from bypassing the gating system and entering the profile update process at the mechanism level.

[0118] S52. The trusted historical time window is a time window that simultaneously meets the preset update conditions within a historical time window; when there is no trusted historical time window, the historical time window that simultaneously meets the preset minimum sample size threshold condition and the preset abnormal proportion threshold condition is used as the initial trusted historical time window.

[0119] Understandably, a set of historically reliable windows This is composed of all time windows that previously met the preset update conditions, persistently stored, and retrieved when calculating the behavior prototype and threshold in subsequent windows. When the current window... When the preset update conditions are met, add it to the historical trusted window set: It is easy to understand that the set of historical reliable windows is empty during the initialization phase. At this time, the first valid window is initialized only by relying on the preset minimum sample size threshold and the preset abnormal proportion threshold. This avoids the initialization failing to be triggered because the accumulated amount of behavioral drift and the risk cost of profile update have not yet been established as historical benchmarks.

[0120] S53. Determine the single update magnitude of the behavior prototype based on the difference between the risk cost of updating the profile in the current time window and the preset risk cost threshold.

[0121] Understandably, to avoid the boundary trust window causing abrupt changes to the behavioral prototype, the inventors noted that even if the current window passes the four-dimensional joint judgment, the update range should still be compressed when its risk cost approaches the threshold. Therefore, a controlled update rate mechanism based on the risk cost of profile update is introduced. Prototype update rate Risks and Costs of Updating Portraits With preset risk cost threshold The ratio is determined as follows: in, This represents the maximum update rate, which is pre-configured during deployment and is typically chosen by those skilled in the art. Larger The value makes the behavioral prototype respond faster to new behavioral features of the trust window. hour, ;when hour, The behavioral prototype is not updated. The prototype update rate is the magnitude of a single update to the behavioral prototype. The controlled update rate mechanism enables the behavioral prototype to evolve gradually within a trust window, preventing abrupt changes in the behavioral prototype due to the boundary trust window.

[0122] S54. Based on the behavior representation vector of the current time window, incrementally update the behavior prototype according to the single update magnitude to obtain the updated behavior prototype.

[0123] It is understandable that when the current window When the preset update conditions are met, update according to the prototype rate. Perform incremental update: in, This represents the original behavior before the update. This represents the smoothed behavior representation vector of the current window, and is the output result after step S2 is completed. Incremental updates allow the behavior prototype to gradually absorb the behavior features of the current window in a controlled manner, maintaining the overall stability of the behavior prototype while adapting to the normal business evolution of the interface.

[0124] Furthermore, when the current window When the preset update conditions are not met, the behavior prototype remains unchanged: Simultaneously record the cumulative drift amount of the current window. Risks and costs of updating profiles The drift determination results are used to generate a structured dynamic profile of the interface. in, Indicates the interface path template. , , , These represent the historical parameter field set, the historical call subject set, the historical return status set, and the historical link context set, respectively, when the window... When the preset update conditions are met, the corresponding set in the current window is merged and updated; otherwise, it remains unchanged. This represents the updated behavior prototype; and These represent the drift threshold and the profile update risk threshold, respectively.

[0125] After step S5 is completed, output the updated dynamic profile of the interface. Behavioral prototypes The system includes trusted sample screening results, drift records, and abnormal change identification results. Step S5 employs a dual gating mechanism to assess both the cumulative amount of behavioral drift and the risk cost of profile updates. This effectively distinguishes between normal evolution and abnormal disturbances in API interface behavior. Compared to existing technologies that rely on periodic full reconstruction or simple incremental accumulation, this approach allows the interface behavior prototype to continuously absorb new behaviors as normal business evolves. Simultaneously, a controlled update rate mechanism constrains the update magnitude, preventing abnormal access, attack traffic, or short-term disturbances from contaminating the interface behavior prototype and ensuring its stability and reliability during long-term operation.

[0126] Example 2, refer to Figure 2 This is one embodiment of the present invention, which provides a method for representing and dynamically updating API interface behavior that supports continuous evolution. To verify the beneficial effects of the present invention, scientific demonstration is carried out through experiments.

[0127] The following is an example of API access monitoring for a company's expense reimbursement information system, such as... Figure 2 The following describes the specific execution process of steps S1 to S5 above. This information system includes interfaces for user login, expense report query, expense report submission, attachment upload, and approval workflow. Interface access records are collected through an API gateway, application logs, and a link tracing system, and interface behavior is analyzed in 10-minute time windows. Interface selection... As the monitoring target, its path template is: This interface is used to query details of a specified expense report. It selects two adjacent time windows. and Explanation: In the window Inside, the interface was collected. The access records, whose original paths contain specific expense report numbers, are uniformly converted into path templates after dynamic parameter segment identification and preset placeholder replacement in step S11. and through step S12 as Path identifier in standardized records. Window The standardized access records generated within are shown in Table 1.

[0128] Table 1 In the window Example of standardized access records within

[0129] Understandably, a 403 error indicates that access is denied. and The corresponding callers, user_C and user_D, did not have query permissions. (Window) Total number of internal access records ,window Total number of internal access records .

[0130] In this embodiment, The link context set remains consistent across both windows, i.e. Substituting into the formula for the intensity of link adjacency change, we get The interface's link context remains unchanged within the current window. With the link context remaining stable, The contribution to the intensity of instantaneous behavioral changes in each sub-time period is zero. The driving sources of behavioral changes are concentrated in four dimensions: the calling subject, parameter structure, return status, and access intensity.

[0131] In step S2, multidimensional behavioral feature extraction is performed based on the standardized access records described above. The calculation process for the subject distribution offset intensity is as follows.

[0132] Let the set of calling subjects be .window and The number of accesses by each calling entity is as follows: The first row represents the window. The number of accesses for each calling entity within the window; the second row represents the number of accesses for each calling entity. The number of times each calling entity accesses the content. This yields the following distribution of the percentage of calls made by each calling entity in the two windows: Substituting the formula for the main body distribution offset intensity, we get: This indicates that two new calling entities, user_D and user_E, have appeared in the current window, and the access ratio of the original entities has changed significantly, resulting in a significant shift in the calling entity structure. This result will be used as a measure of the intensity of the instantaneous behavioral change. The computational basis, which in turn affects the cumulative intensity of behavioral changes. The calculation results.

[0133] Furthermore, the calculation process for the differences in parameter field structure is as follows.

[0134] interface The set of historical parameter fields is as follows: in, Indicates an access token. Indicates the expense report number. Indicates the department number. Indicates pagination parameters, This indicates a request for a signature. (Window) and The following are the occurrences of the field: The first row represents the window. The second line indicates the window's behavior when the inner field appears. The occurrence of inner fields can reveal the field's characteristics. and In the window Missing values ​​exist. Let the field importance vector be: Corresponding fields , , , and Substituting the parameter field structure difference formula, we get: Indicates that a signature field is requested in the current window. With department number field Missing items, especially The field importance is 0.25, and its absence significantly contributes to the differences in parameter structure, suggesting a risk of abnormal missing key parameter fields in the current window. Combined with... The current window shows significant changes in both the calling subject and parameter structure, which together drive the increase in the cumulative intensity of behavioral changes.

[0135] Furthermore, the calculation process for the change in the return state distribution is as follows.

[0136] Let the set of returned status codes be... The number of times the two windows returned their statuses is as follows: Therefore, the return status distributions of the two windows are as follows: Substituting into the formula for the change in the return state distribution, we get: This indicates that the proportion of 403 status codes in the current window has significantly increased from 0 to 0.238, while 500 status codes have also appeared. The distribution of returned statuses has changed significantly compared to historical windows, suggesting that there are a large number of unauthorized access requests and service anomalies within the current window. At this point, , , , The offset intensity in the four dimensions constitutes the complete multidimensional input for calculating the cumulative intensity of behavioral changes.

[0137] Furthermore, the calculation process for time-decayed access strength is as follows.

[0138] Window Divided into 5 sub-time periods, each sub-time period is 2 minutes long, interface The number of visits within each sub-time period is as follows: Set time decay coefficient , Substituting into the time decay access strength formula, we get: This reflects an upward trend in interface access towards the end of the current window, with a significant increase in access frequency closer to the window's end. Time decay weighting gives this trend a higher weight in the access intensity feature. The continuous increase in access volume, along with abnormal changes in the calling body, parameter structure, and return status, constitutes a complete signal of multidimensional behavioral anomalies in the current window, providing input for the access intensity dimension in calculating the cumulative intensity of behavioral changes.

[0139] Furthermore, the calculation process for the cumulative intensity of behavioral changes is as follows.

[0140] Window The data is divided into 5 sub-time periods, and the intensity of instantaneous behavioral changes in each sub-time period is as follows: Each row represents a sub-time period, and each column represents... , , , and It can be seen that the intensity of change in each dimension increases significantly in the latter part of the window (the 4th and 5th sub-time periods), which is consistent with... The reflected increase in traffic volume is consistent with the upward trend in the latter part, indicating that the interface behavior continued to deteriorate throughout the entire time window. All columns are 0, and The calculation results are consistent.

[0141] Let the weight vector be: The average intensity of behavioral change in each sub-time period is approximately: Let the time decay coefficient of the intensity of behavioral change be defined. Substituting into the formula for the cumulative intensity of behavioral changes, we get: Set a preset threshold for behavior change. .because This triggers step S22, where feature extraction is performed based on the standardized records of the current window to obtain the initial behavior representation vector. Exceeding The magnitude of 0.352 indicates that the degree of continuous change in interface behavior within the current window far exceeds the historical reliable range, which is consistent with the analysis results showing significant shifts in all three dimensions.

[0142] Let the initial behavior representation vector of the current window be: Adjacent preceding time windows The smooth behavior representation vector is: because Substituting into the smooth update weight formula, let... ,have to: The current window representation contributes a higher proportion than the preceding window representation, reflecting a higher weighting of the current window features when the cumulative intensity of behavioral changes exceeds a threshold. The smoothly fused behavioral representation vector is: Compared to the previous smooth representation vector A significant shift occurred, with the third dimension component increasing most notably from 0.46 to 0.549, mirroring the change in the current window's returned state distribution. The returned status reflects an abnormality. It will serve as the input for calculating the cumulative amount of behavior drift in step S4, and as the basis for incremental updates in step S5.

[0143] In step S3, the behavioral prototype has been calculated using the time-decay weighted center of the smoothed behavioral representation vector within the historical confidence window, and its current value is: This behavioral prototype serves as a reference for calculating the cumulative amount of behavioral drift in step S4.

[0144] In step S4, the calculation process for the cumulative amount of behavioral drift is as follows.

[0145] Window Dividing the data into 5 sub-time periods, after the sub-time period division in step S41 and feature extraction in step S42, the behavior deviation of each sub-time period is calculated by substituting it into the cosine distance formula in step S43: It can be seen that the behavioral deviation degree exhibits a monotonically increasing trend within the window, which is consistent with the instantaneous behavioral change intensity matrix. The pattern of significantly increased intensity of changes in each dimension during the middle and later stages is consistent with this, indicating that the interface behavior continuously deviates from the historical behavior prototype throughout the entire time window. .

[0146] Let the drift accumulation time decay coefficient be set. Substituting into the formula for cumulative behavioral drift, we get: Let the mean and standard deviation of the cumulative drift within the historical confidence window be respectively... , Threshold adjustment coefficient Substituting into the drift threshold formula, we get: because Determine the interface In the window Behavioral drift occurs within the body. Exceeding the drift threshold The magnitude is 0.090, reflecting that the current interface behavior within the window has deviated from the historical behavior prototype beyond the historical stable range.

[0147] Determination of behavioral drift and The conclusions corroborate each other, jointly demonstrating that there are significant and continuous abnormal changes in the interface behavior within the current window. Will be related to the risks and costs of image updates (To be calculated) together serve as the input for the dual-gating judgment in step S5.

[0148] Furthermore, the calculation process for the risk cost of updating the profile is as follows.

[0149] Although This indicates that the interface behavior has drifted, but the behavior drift itself does not directly indicate whether the change was caused by normal business evolution. It is still necessary to further determine whether the current window can be used for profile update by considering the risk and cost of profile update.

[0150] window The number of internal error status codes or business exception return codes is The percentage of exceptions returned is: The instantaneous update risks for each sub-time period are as follows: Each row represents a sub-time period, and each column represents the risk of abnormal returns. Parameter structure offset risk Link context offset risk and behavioral deviation It can be seen that the risk of abnormal returns and the risk of parameter structure offset increase significantly in the later part of the window, compared with step S2. and The calculation results are consistent; The column values ​​are small, and The conclusions are consistent, indicating that the risks mainly stem from abnormal return statuses and missing parameter fields.

[0151] Let the risk weight vector be: The average instantaneous update risk for each sub-time period is approximately: Let the risk cost decay factor be set. Substituting into the formula for the risk cost of updating the profile, we get: Set a risk threshold for image updates .because The risk cost of updating the current window's image exceeds a preset threshold. and Both exceed their respective preset thresholds, and the two gating indicators jointly indicate that the current window is not suitable for participating in the image update, providing a dual basis for the determination in step S5.

[0152] In step S5, the execution process of the trusted update determination is as follows.

[0153] Let the threshold values ​​for the preset update conditions be: Substitute the current window data into the four conditions and verify them one by one: Although the current window sample size The preset minimum sample size threshold is met, but the abnormal return rate is high. Exceeding the preset abnormality threshold cumulative behavioral drift Exceeding the preset drift limit threshold The risks and costs of updating portraits Exceeding the preset risk cost threshold If none of the four conditions are met simultaneously, the judgment window will be activated. This is not a trusted update window.

[0154] The determination result indicates that the interface within the current window... An abnormal increase in the number of callers occurred (user_D and user_E were newly added). Batch missing key parameter fields , Missing A large number of unauthorized accesses (403 errors accounted for 0.238%), The abnormal characteristics, including multiple dimensions, indicate that the behavioral changes originate from abnormal access behavior rather than normal business evolution. A dual gating mechanism ( and It accurately identified the source of this anomaly, prevented the anomalous features from being incorporated into the behavioral prototype, and effectively prevented baseline contamination.

[0155] The current window is not added to the set of trusted historical windows: The interface behavior prototype remains unchanged: The current window's structured interface dynamic profile output is as follows: Among them, due to the window The preset update conditions are not met. , , , All remain unchanged, drift determination result and update the judgment results Recorded in the interface dynamic profile, among which This indicates that the interface behavior has drifted. This indicates that the current window will not participate in the interface profile update, and the relevant abnormal changes will be recorded in the interface dynamic profile for subsequent security governance and risk tracking.

[0156] Example 3, referring to Figure 3This is one embodiment of the present invention, which provides an API interface behavior representation and dynamic update system that supports continuous evolution, including: a record acquisition module, used to acquire API interface access records within the current time window and parse the access records into standardized records; The feature extraction module is used to extract features from the standardized records to obtain the behavior representation vector of the current time window; The prototype building module is used to construct the behavioral prototype of the API interface based on the behavioral representation vector of a trusted historical time window. The drift determination module is used to determine the cumulative amount of behavior drift based on the degree of continuous deviation between the behavior representation vector of the current time window and the behavior prototype, and to determine the risk cost of profile update based on the degree of deviation of the standardized record of the current time window from the behavior prototype. The profile update module is used to incrementally update the behavior prototype based on the behavior representation vector of the current time window when both the cumulative behavior drift and the risk cost of profile update meet the preset update conditions; when the cumulative behavior drift or the risk cost of profile update does not meet the preset update conditions, no update operation is performed on the behavior prototype.

[0157] This embodiment also provides an electronic device applicable to a method for representing and dynamically updating API interface behavior that supports continuous evolution, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the method for representing and dynamically updating API interface behavior that supports continuous evolution as proposed in the above embodiment.

[0158] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements a method for representing and dynamically updating API interface behavior that supports continuous evolution, as proposed in the above embodiments.

[0159] The storage medium proposed in this embodiment and the method for implementing a continuously evolving API interface behavior representation and dynamic update proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0160] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0161] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for representing and dynamically updating API interface behavior that supports continuous evolution, characterized in that, include: Obtain the access records of the API interface within the current time window, and parse the access records into standardized records; Feature extraction is performed on the standardized records to obtain the behavior representation vector of the current time window; The behavior prototype of the API interface is constructed based on the behavior representation vector of a trusted historical time window. The cumulative amount of behavioral drift is determined based on the degree of continuous deviation between the behavioral representation vector of the current time window and the behavioral prototype. The risk cost of updating the profile is determined based on the degree of deviation of the standardized records of the current time window from the behavioral prototype. When both the cumulative amount of behavior drift and the risk cost of updating the profile meet the preset update conditions, the behavior prototype is incrementally updated based on the behavior representation vector of the current time window; when neither the cumulative amount of behavior drift nor the risk cost of updating the profile meets the preset update conditions, no update operation is performed on the behavior prototype.

2. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 1, characterized in that, The feature extraction includes: Calculate the cumulative intensity of behavioral changes in the current time window based on the standardized records; When the cumulative intensity of the behavior change is greater than the preset behavior change threshold, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window; When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is an adjacent preceding time window, the fusion ratio is determined based on the cumulative intensity of the behavior change and the preset behavior change threshold. The behavior representation vectors of the adjacent preceding time windows and the behavior features of the current time window are weighted and fused according to the fusion ratio to obtain the behavior representation vector of the current time window. When the cumulative intensity of the behavior change is less than or equal to the preset behavior change threshold and there is no adjacent preceding time window, the behavior representation vector of the current time window is obtained based on the standardized record of the current time window.

3. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 2, characterized in that, The incremental update includes: The single update magnitude of the behavior prototype is determined by the difference between the risk cost of updating the profile in the current time window and the preset risk cost threshold. Based on the single update magnitude, the behavior prototype is incrementally updated according to the behavior representation vector of the current time window to obtain the updated behavior prototype.

4. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 3, characterized in that, The determined behavioral drift accumulation includes: The current time window is divided into multiple sub-time periods, and the standardized records are assigned to the corresponding sub-time periods according to the request time to obtain a subset of access records for each sub-time period. Feature extraction is performed on the subset of access records to obtain the behavioral representation vector of the sub-time period; The deviation between the behavior representation vector of the sub-time period and the behavior prototype is calculated, and the deviation is accumulated over time decay within the current time window to obtain the cumulative behavior drift.

5. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 4, characterized in that, The costs associated with determining the risks of updating the profile include: Access anomaly features, parameter structure offset features, and link context offset features are extracted from the standardized records, and the degree of offset of the access anomaly features, parameter structure offset features, and link context offset features relative to the corresponding historical feature set is quantified. The risk cost of updating the profile is obtained by taking the degree of offset and the behavioral deviation between the behavioral representation vector of the current time window and the behavioral prototype as input.

6. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 5, characterized in that, The preset update conditions must be met simultaneously: The number of access records in the current time window is greater than or equal to the preset minimum sample size threshold; The ratio of the number of abnormal access records returned in the current time window to the total number of access records is less than or equal to the preset abnormal ratio threshold. The cumulative amount of behavioral drift is less than or equal to a preset drift upper limit threshold; The risk cost of updating the portrait is less than or equal to a preset risk cost threshold; The trusted historical time window is a time window that simultaneously meets the preset update conditions within a historical time window. When no reliable historical time window exists, the historical time window that simultaneously meets the preset minimum sample size threshold and the preset anomaly ratio threshold is used as the initial reliable historical time window.

7. The method for representing and dynamically updating API interface behavior that supports continuous evolution as described in claim 6, characterized in that, The analysis includes: Identify the dynamic parameter segment of the interface path in the access record, replace the dynamic parameter segment with a preset placeholder, and obtain the path template corresponding to the interface path; The path template is used as the path identifier for the API interface in the standardized record.

8. A system for representing and dynamically updating API interface behavior that supports continuous evolution, comprising applying the method for representing and dynamically updating API interface behavior that supports continuous evolution as described in any one of claims 1 to 7, characterized in that, include: The record acquisition module is used to acquire the access records of the API interface within the current time window and parse the access records into standardized records; The feature extraction module is used to extract features from the standardized records to obtain the behavior representation vector of the current time window; The prototype building module is used to construct the behavioral prototype of the API interface based on the behavioral representation vector of a trusted historical time window. The drift determination module is used to determine the cumulative amount of behavior drift based on the degree of continuous deviation between the behavior representation vector of the current time window and the behavior prototype, and to determine the risk cost of profile update based on the degree of deviation of the standardized record of the current time window from the behavior prototype. The profile update module is used to incrementally update the behavior prototype based on the behavior representation vector of the current time window when both the cumulative behavior drift and the risk cost of profile update meet the preset update conditions; when the cumulative behavior drift or the risk cost of profile update does not meet the preset update conditions, no update operation is performed on the behavior prototype.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method for representing and dynamically updating API interface behavior that supports continuous evolution, as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for representing and dynamically updating API interface behavior that supports continuous evolution, as described in any one of claims 1 to 7.

Images