An API collaborative calling analysis method, system, device and medium based on functional role division

Abstract

This invention discloses an API collaborative call analysis method, system, device, and medium based on functional role division, belonging to the field of application system interface behavior analysis technology. It includes: aggregating API call information by link tracing identifiers to form a call sequence set; obtaining functional role affiliation through role prototype matching and determining the main functional role; constructing a role collaboration graph with functional role affiliation as weight; calculating the process deviation by comparing it with the role transfer baseline; calculating the propagation impact value to generate collaborative anomaly events; and determining and updating the role transfer baseline according to preset verification rules. This invention elevates API call analysis to the functional role dimension, enabling the quantitative identification of collaborative anomalies in scenarios such as authentication bypass and missing verification, where interfaces respond normally but the call process involves functional role jumps. Role affiliation is automatically recalculated as the interface set is updated, and the role transfer baseline is automatically updated after compliance changes in the business process.

Description

Technical Field

[0001] This invention relates to the field of application system interface behavior analysis technology, specifically to an API collaborative call analysis method, system, device, and medium based on functional role division. Background Technology

[0002] In application system interface security monitoring, existing methods often use individual API interfaces as the analysis unit, judging whether an interface is abnormal by statistically analyzing call frequency, response latency, and abnormal return rate. Because log systems record at the single request granularity, access records for each interface are independent, and the call order relationship across interfaces cannot be directly read from a single log entry. Therefore, in scenarios such as authentication bypass or missing verification, when attackers skip authentication or verification interfaces and directly trigger write or payment interfaces, the response status codes of the involved interfaces all appear normal, and single-interface statistical indicators cannot detect the process structure deviation formed by the coordinated calls of multiple interfaces. Regarding interface function classification, existing methods typically rely on manually configured naming rules or fixed tags, stored in the form of static rule files. When business systems continuously iterate and interface paths or parameter structures change with version upgrades, the original configuration cannot be automatically updated, and the functional role definition of the interface lags behind the actual operating state. Existing detection baselines are usually configured once based on historical data. When compliance changes occur in the business process, the baseline cannot be adjusted accordingly, and the new compliant call patterns are continuously falsely reported as abnormal. Restoring normal detection requires manual intervention and baseline reconstruction. Summary of the Invention

[0003] In view of the above-mentioned problems, the present invention provides an API collaborative call analysis method, system, device and medium based on functional role division.

[0004] Therefore, the technical problem solved by the present invention is that existing API security detection methods use the statistical characteristics of a single interface as the analysis unit, treat all API call behaviors as homogeneous objects, lack the ability to model the functional roles of APIs in business processes and their cross-interface collaborative relationships, and cannot identify collaborative call anomalies formed by multiple interfaces in terms of functional roles.

[0005] To address the aforementioned technical problems, this invention provides the following technical solution: an API collaborative call analysis method based on functional role division, comprising, API call information is aggregated from API access logs and call chain records based on the link tracing identifier to form a call sequence set; Match the features of each API with the role prototype vector of the functional role category to obtain the functional role affiliation degree, and take the role category with the highest affiliation degree as the main functional role; By using the functional role affiliation degree as the weight, the collaborative associations of adjacent API pairs are aggregated to the role pairs to which they belong, and a role collaboration graph is constructed. The role transfer baseline is constructed by statistically analyzing the transfer frequency of roles in the historical normal call sequence. The deviation of the process is calculated by replacing the APIs in the call sequence set with the main function roles and comparing them with the role transfer baseline. When the deviation of the process is greater than the deviation threshold, the propagation impact value from the risk source role to the risk target role is calculated in the role collaboration diagram. When the propagation impact value is greater than the propagation threshold, a collaboration anomaly event is generated. Role transfers involved in collaborative anomalies are determined according to preset verification rules. If the determination is successful, the frequency of the involved role transfers is included in the role transfer baseline; otherwise, it is recorded in the abnormal role transfer rule set.

[0006] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the method for obtaining functional role affiliation includes: The center position of the feature vector of APIs that have completed role labeling and belong to the same functional role category is established as the role prototype vector, and the degree of dispersion of the feature vectors of APIs within the same category around the role prototype vector is established as the prototype distribution scale. Based on the distance relationship between each API's own feature vector and the role prototype vector, as well as the prototype distribution scale, the position of each API in the functional role category is located, and the matching value is obtained. The normalized matching value of each API across all functional role categories is used as the functional role attribution degree.

[0007] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the step of selecting the role category with the highest affiliation degree as the main functional role includes: When the highest functional role affiliation degree is greater than or equal to the main role threshold, the functional role category with the highest affiliation degree will be determined as the main functional role. When the highest functional role affiliation is less than the primary role threshold, the API to be judged will be marked as an API with uncertain role and included in the manual confirmation queue. When there is a matching value in the functional role attribution degree that is greater than or equal to the auxiliary role threshold and less than the main role threshold, the functional role category to which the matching value belongs is recorded as the auxiliary functional role of the API to be determined.

[0008] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the time decay call intensity, parameter transmission intensity, and business object consistency intensity of the adjacent API pairs are fused according to a preset weight to form the collaborative association of the adjacent API pairs. The time decay call strength is established by accumulating the call records of the adjacent API pairs after applying decay weights according to the time interval from the end of the time window; The parameter transmission strength is determined by identifying the transmitted fields from the previous API output field set and the subsequent API input field set, and is established by the coverage of the transmitted fields in both field sets. The consistency strength of the business object is established by identifying calls with consistent business object identifiers from the call records of adjacent API pairs, based on the proportion of consistent calls in the total number of calls.

[0009] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the calculation process deviation includes: Identify functional roles that do not appear in the current call sequence from the preset set of key functional roles, and establish key role missing items based on the proportion of missing functional roles in the preset set of key functional roles; APIs in the current call sequence whose calling entity's permission level is lower than the required permission level of the API being called are identified, and unauthorized call items are established based on the proportion of the identified number in the sequence length; The number of times that the writing, approval, payment and management function roles appear in the current call sequence is greater than or equal to the normal allowed number of times, and the excess number of sensitive roles is established based on the proportion of the accumulated amount in the sequence length; The deviation term of the role transfer probability is aggregated with the missing key role term, the unauthorized call term, and the sensitive role over-limit term to form the bounded process deviation.

[0010] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the calculation of the propagation impact value from the risk source role to the risk target role includes: Starting from the risk source role in the role collaboration graph, the graph extends gradually along the directed edges to collect all directed paths whose path length is less than or equal to the preset path length upper limit. For each edge on the directed path, the edge propagation ratio is determined by the proportion of the edge's collaboration strength to the total collaboration strength of all outgoing edges of the starting role. The path propagation probability is obtained by passing the edge propagation ratios on the directed path in sequence. The path length attenuation factor is determined by using the attenuation function as input; The risk intensity is established based on the process deviation of the deviation sequence in which the risk source role participates within the current time window; The risk intensity, the path propagation probability, and the path length attenuation factor are transmitted along all the directed paths and converged into the propagation impact value.

[0011] As a preferred embodiment of the API collaborative call analysis method based on functional role division described in this invention, the preset verification rules include: Retrieve the associated records of the role transfer from the business change records, approval work orders and business rule configurations, and establish a business change verification record based on whether the associated records exist; Within the observation window after the collaborative anomaly event is generated, the interface error rate, alarm trigger count, and process deviation of the involved role transfer are collected. An access status verification record is established by comparing the interface error rate, alarm trigger count, and process deviation with a preset threshold. The number of times the role transfer involved occurs in the deviation sequence, the number of times it participates in the collaborative anomaly event, and the total number of observations are counted. A risk participation verification record is established based on the number of occurrences, the number of participations, and the total number of observations. The system is considered passed when the business change verification record, access status verification record, and risk participation verification record all meet the preset conditions.

[0012] This invention provides an API collaborative call analysis system based on functional role division.

[0013] To solve the above technical problems, the present invention provides the following technical solution: an API collaborative call analysis system based on functional role division, comprising: a data acquisition module, used to aggregate API call information from API access logs and call link records according to link tracing identifiers to form a call sequence set; The role recognition module is used to match the features of each API in the call sequence set with the role prototype vector of the functional role category to obtain the functional role affiliation degree and determine the main functional role. The collaboration graph construction module is used to aggregate the collaborative associations of adjacent API pairs to the role pairs to which they belong, using the functional role affiliation degree as the weight, and construct a role collaboration graph; The deviation calculation module is used to construct a role transfer baseline by statistically analyzing the role transfer frequency from the historical normal call sequence, and then compares the API in the call sequence set with the main function role and the role transfer baseline to calculate the process deviation. An anomaly identification module is used to calculate the propagation impact value from the risk source role to the risk target role in the role collaboration graph when the process deviation is greater than the deviation threshold, and to generate a collaboration anomaly event when the propagation impact value is greater than the propagation threshold. The baseline update module is used to determine the role transfer involved in the collaborative abnormal event according to the preset verification rules. If the determination is successful, the frequency of the involved role transfer is incorporated into the role transfer baseline; otherwise, it is recorded in the abnormal role transfer rule set.

[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 API collaborative call analysis method based on functional role division.

[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 API collaborative call analysis method based on functional role division.

[0016] The beneficial effects of this invention are as follows: By automatically matching functional role affiliation and constructing a role collaboration graph, this invention elevates the analysis dimension of API call behavior from the interface level to the functional role level. In attack scenarios such as authentication bypass, missing verification, and unauthorized access, the structural offset of the call sequence in the functional role transfer mode is transformed into a quantifiable signal of process deviation. This allows for the identification of collaboration anomalies where each interface response is normal but the overall call process exhibits functional role jumps. Simultaneously, the functional role affiliation is automatically determined based on the distance relationship between the interface's own feature vector and the role prototype vector. When the interface set is updated, the role affiliation is recalculated accordingly, unaffected by changes in interface path or parameter structure versions. The role transfer baseline is automatically updated under the condition of sufficient business confirmation and normal subsequent access, preventing compliant business process changes from triggering continuous false alarms. Attached Figure Description

[0017] 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.

[0018] Figure 1 The above is a flowchart of an API collaborative call analysis method based on functional role division, provided as an embodiment of the present invention.

[0019] Figure 2 The flowchart illustrates the function role attribution determination process for an API collaborative call analysis method based on function role division, as provided in one embodiment of the present invention.

[0020] Figure 3 This is an interactive diagram for checking and judging collaborative abnormal events in an API collaborative call analysis method based on functional role division, provided as an embodiment of the present invention. Detailed Implementation

[0021] 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.

[0022] Example 1, referring to Figures 1-3 This is one embodiment of the present invention, which provides an API collaborative call analysis method based on functional role division, including: S1 aggregates API call information from API access logs and call chain records according to the link tracing identifier to form a call sequence set.

[0023] In some embodiments, the input sources for aggregating API call information in step S1 include five categories: API access logs, gateway logs, application logs, interface documentation, and call chain records.

[0024] Understandably, API access logs should at least include the interface path, request method, request time, caller, request parameters, return status code, and response latency; 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 code, and business return code; interface documentation should at least include the interface name, interface description, input parameters, output parameters, authentication method, and business function description; and call chain records should at least include the chain tracing identifier, upstream interface, downstream interface, API call order, and chain time.

[0025] Furthermore, since API calls are continuously generated in actual business systems, analyzing the entire historical data would result in computational overhead that increases linearly with the data size, and would be difficult to reflect changes in call behavior within the current time period in a timely manner. Therefore, continuous time is divided into periods of length [missing information]. The time window, the Each time window is denoted as .interface In the time window The set of access records within is defined as follows: in, Interface In the time window Number of visits within, Indicates the first time window Access records, For interface indexing, For time window indexing, For access record indexing.

[0026] Time window length It can be configured according to the request frequency and real-time analysis requirements of the business system. For example, in a high-concurrency e-commerce system... It can be configured to 5 minutes, and in low-frequency enterprise intranet systems it can be configured to 30 minutes.

[0027] Furthermore, because API access logs, gateway logs, and application logs have different field formats, direct processing can lead to semantic ambiguity and data alignment difficulties. Therefore, a time window is used... Each access record within is standardized into the following nine-tuple: in, Indicates the interface identifier; Indicates the calling entity; Indicates the request method; This represents the standardized interface path; Indicates the request parameter structure; This indicates the returned status code or service return code; Indicates response delay; Indicates the request time; Indicates the call chain identifier.

[0028] Understandably, the calling entity These can originate from user accounts, application identifiers, client certificates, access tokens, or device identifiers. For example, within the same business system, API access logs record interfaces using URL paths, while application logs record interfaces using internal service names; both are mapped to... This field enables accurate association of call records for the same interface in different log sources, eliminating record omissions caused by inconsistent interface identifiers.

[0029] It should be noted that the request parameter structure in the above nine-tuple... A triple is defined as follows: in, This represents the set of input fields, that is, the set of parameter field names actually carried in this request; This represents a set of input field types, including string, numeric, boolean, array, and object types. It represents a collection of input field hierarchies, describing the hierarchical relationship of each field in the nested parameter object.

[0030] Optionally, the parameter structure is expanded into a triple containing a set of fields, a set of types, and a hierarchical structure because in actual API interactions, fields with the same name but different types or hierarchies are not equivalent in business semantics. For example, the query interface output... The field type is string; if the downstream write interface requires receiving numeric values... If there is no valid parameter passing relationship between the two, recording only the field name while ignoring the type and hierarchy will lead to misjudgment of the passing relationship.

[0031] Furthermore, after the access records are standardized, they are analyzed based on the call chain identifier. Aggregate access records belonging to the same business chain and sort them by request time. Sort in ascending order to get the call sequence: in, Indicates the first A sequence of business calls, This indicates the number of API calls contained in the sequence. Indicates the first position in the sequence One API call, To call the sequence index, This is the index of the call position within the sequence.

[0032] The generation of a call sequence must simultaneously meet the following three constraints: First, access records within the same sequence must have the same or related tracing identifiers; second, the time interval between requests to adjacent APIs within the sequence must not exceed a preset threshold. Third, the calling entity identifier or business object identifier of adjacent APIs are consistent.

[0033] It should be noted that, This can be determined by the statistical distribution of the time intervals between adjacent API requests in a historical normal call sequence. For example, the 95th percentile of all adjacent API request time intervals in a historical normal call sequence is taken as... The reference value is used to ensure that the vast majority of normal business calls are included in the same sequence, while filtering out cross-business associations caused by timeouts or abnormal interruptions.

[0034] In other embodiments, when the link tracing identifier is missing, an approximate call sequence can be generated based on the caller, client address, business object identifier, and time proximity. For example, in a legacy system without a full link tracing component, if two access records have the same caller, identical business object identifier, and a request time interval of [missing information], [missing information]. If both are within the same approximate call sequence, then they will be included in the same approximate call sequence.

[0035] Step S1 outputs a standardized access record set, an interface metadata table, a call subject table, a parameter structure table, a link tracing table, and an API call sequence set.

[0036] In real-world business systems, multiple API access logs generated by the same business request are scattered across different log files. Each record only retains information from the current request, and the order of API calls is not visible at the log level. For example, in an e-commerce order process, the authentication, query, verification, write, and payment interfaces generate five independent access records under the same business request. These records are generated through a log file system. Aggregation and by The arrangement of the five records was restored into a complete call sequence. The order and time interval of API calls within the sequence are preserved.

[0037] S2 matches the features of each API with the role prototype vector of the functional role category to obtain the functional role affiliation degree, and takes the role category with the highest affiliation degree as the main functional role.

[0038] In some embodiments, the set of functional role categories in step S2 is represented as ,in This indicates the number of functional role categories. Functional role categories must include at least authentication, query, validation, write, approval, payment, notification, and management categories. For example, authentication categories correspond to interfaces responsible for identity verification and token issuance, such as login and token refresh interfaces; write categories correspond to interfaces responsible for data persistence, such as order creation and user information update interfaces.

[0039] Understandably, in real-world business systems, the functional responsibilities of an interface cannot always be determined from a single perspective; relying solely on path keywords or request methods can easily lead to misjudgments. Therefore, each interface... its own characteristics It consists of the following five dimensions: in, It represents the characteristics of the interface path, generated by the path hierarchy, path keywords, and resource object name; Indicates the characteristics of the request method; It represents the parameter structure characteristics, generated by input fields, output fields, field types, and field sensitivity levels; This represents the interface description characteristics, generated from the interface name, interface description, and business function description. It represents the characteristics of the historical call context, which are generated by the interface's preceding interface, following interface, and process position in the historical call sequence.

[0040] For example, the path contains The keyword interface could be either a query class (GET / order / list) or a write class (POST / order / create), based solely on path characteristics. Unable to distinguish. (Based on request method characteristics) With parameter structure features Subsequently, the positional differences of the two entities' own feature vectors in the functional role feature space can be distinguished, thereby supporting subsequent role prototype matching.

[0041] In some embodiments, obtaining the functional role affiliation in step S2 includes steps S21 to S23, wherein: S21, establish the center position of the feature vector of the API itself that has been annotated and belongs to the same functional role category as the role prototype vector, and establish the degree of dispersion of the feature vector of the API itself around the role prototype vector as the prototype distribution scale.

[0042] In step S21, the character prototype vector is determined by the set of interfaces for which character annotations have been completed. Let... This indicates that it has been marked as a character. Or identified as a role in a historically stable call process. Interface set, roles Character prototype vector Defined as: in, Represents a set The number of interfaces To prevent the introduction of positive numbers with a denominator of zero.

[0043] Understandably, the character prototype vector Representative roles The central location of all labeled interfaces in the feature space reflects the typical feature distribution of that role category. When the set of labeled interfaces... During the update, The calculation is then recalculated without requiring any changes to the rule configuration.

[0044] After determining the character prototype vector, step S21 further establishes the prototype distribution scale. Character prototype distribution scale. Defined as: in, Interface From its own feature vector to the character prototype vector The square of the Euclidean distance.

[0045] It characterizes the cohesion of interface features within the same role category. When When the size is small, interface features within a role category are highly concentrated in the feature space, with clear boundaries; when... When the value is large, the interface features are more dispersed, corresponding to a wider judgment range in the matching calculation of step S22.

[0046] It should be noted that the main character threshold and support role threshold The threshold can be determined by the matching degree distribution of boundary samples for each role in the historical annotation interface set, and the matching degree value corresponding to the point where the slope of the distribution curve changes the most is taken as the threshold reference. .

[0047] S22. Based on the distance relationship between each API's own feature vector and the role prototype vector, as well as the prototype distribution scale, locate the position of each API in the functional role category and obtain the matching value.

[0048] In step S22, the distance between the feature vector of the interface to be matched and the prototype vector of the role, as well as the scale of the prototype distribution, jointly determine its position in the functional role category. For the interface to be matched... Its relationship with the role Matching value Defined as: in, Interface With the character The matching value, Interface From its own feature vector to the role The squared Euclidean distance between the prototype vectors of the characters Indicates role The prototype distribution scale, To prevent the introduction of positive numbers with a denominator of zero.

[0049] The exponential nonlinear mapping is introduced because the Euclidean distance exhibits uneven numerical distribution as the dimension of the feature space increases. The exponential mapping restricts the distance value to a certain range. Within the range. When Self-feature vector and role prototype vector When they completely overlap, When the distance between the two is much greater than the scale of the prototype distribution, Approaching 0.

[0050] For example, for the path is For interfaces using the POST request method, their own feature vectors are located near the prototype vector of the writing class role. Approaching 1; at the prototype vector of the authentication role, the corresponding Approaching 0.

[0051] S23, the normalized matching value of each API across all functional role categories is used as the functional role affiliation degree.

[0052] In step S23, the matching value of each API across all functional role categories is normalized to obtain the functional role affiliation degree. (Interface) For the role Functional role attribution Defined as: in, The index used for summing is the traversal index of the role category, with a value ranging from 1 to... , Indicates the total number of functional role categories. To prevent the introduction of positive numbers with a denominator of zero.

[0053] This leads to the interface. Functional role attribution vector: After normalization, the functional role affiliation vector The sum of all components is 1, and each component represents the strength of the interface’s affiliation to the corresponding role category.

[0054] In some embodiments, selecting the role category with the highest affiliation degree as the main functional role in step S2 includes steps S24 to S26, wherein: S24. When the highest functional role affiliation degree is greater than or equal to the main role threshold, the functional role category with the highest affiliation degree is determined as the main functional role.

[0055] In step S24, the functional role category with the highest affiliation is determined by the following operation: in, Interface The main functional role, This represents a set of functional role categories. When... At that time, Write interface Main function role record.

[0056] S25, when the highest functional role affiliation degree is less than the main role threshold, the API to be judged is marked as the role uncertain API and included in the manual confirmation queue.

[0057] In step S25, when the functional role affiliation vector All components are less than When the distance between the feature vector of the interface to be judged and the vectors of all character prototypes in the feature space exceeds the normal range, the existing character prototypes cannot accurately cover it.

[0058] For example, if an interface is added after a business system version upgrade, and its function type has not yet appeared in the set of labeled interfaces, then the affiliation vector... All components are less than This triggers a role uncertainty flag, placing the user in a manual confirmation queue. Once the business personnel confirm the user's functional role, they add the user to the corresponding role's... Collection, and thus trigger and Update calculation.

[0059] S26. When there is a matching value in the functional role attribution degree that is greater than or equal to the auxiliary role threshold and less than the main role threshold, the functional role category to which the matching value belongs is recorded as the auxiliary functional role of the API to be determined.

[0060] In step S26, the recording of the auxiliary function role is not mutually exclusive with the role uncertainty marker in step S25. For example, if the query class affiliation degree of a certain interface is 0.45 and the write class affiliation degree is 0.38, then... , If so, the interface is marked as an API with an uncertain role, and both the query class and the write class are recorded as auxiliary function roles for reference during manual confirmation.

[0061] Step S2 outputs the API role affiliation vector, the main function role set, the auxiliary function role set, and the role-uncertain interface set.

[0062] In business scenarios where APIs are constantly evolving, taking an e-commerce system as an example, when the order query interface adds a field to return inventory status, its parameter structure characteristics change. Changes have occurred; the set of labeled interfaces has been updated. Updated accordingly and The new version of the interface automatically recalculates the role affiliation determination without requiring any modification to the rule configuration.

[0063] S3 uses the functional role affiliation degree as weight to aggregate the collaborative associations of adjacent API pairs to the role pairs to which they belong, and constructs a role collaboration graph.

[0064] In some embodiments, the collaborative association of adjacent API pairs in step S3 is jointly determined by the time decay call strength, parameter passing strength, and business object consistency strength. These three strengths reflect the degree of association between interfaces in terms of call timing, parameter dependency, and business object affiliation, respectively. Step S3 includes steps S31 to S34, wherein: S31, the time decay call strength, parameter passing strength and business object consistency strength of adjacent API pairs are merged according to preset weights and used as the collaborative association of adjacent API pairs.

[0065] In step S31, for the interface and Inter-interface coordination strength Defined as: in, This represents the normalized time-decay call strength. Indicates the strength of parameter transfer. Indicates the consistency strength of business objects. , , The weights are non-negative and satisfy the following conditions: .

[0066] The exponential saturation form, instead of linear weighting, is introduced because in high-frequency call scenarios, linear weighting can lead to excessively high coordination strength for interfaces with frequent calls, masking the contribution of parameter passing and business object consistency. The exponential saturation form limits the coordination strength to... Within this range, the coordination strength between interface pairs with different call frequencies is comparable.

[0067] S32, the time decay call strength is accumulated by applying decay weights to the call records of adjacent API pairs according to the time interval from the end of the time window.

[0068] In step S32, establishing the time decay call strength first requires statistical analysis of the time window. Internal interface and The number of consecutive calls. Let... For time window The set of call sequences within the interface, the call frequency between interfaces. Defined as: in, This is an indicator function that takes the value 1 when the condition inside the parentheses is true, and 0 otherwise. Indicates the call sequence The number of API calls included; This is the index of the call position within the sequence.

[0069] statistics Then it appeared The number of times the two interfaces are directly adjacent in the same business call chain reflects the frequency with which they are directly adjacent.

[0070] Furthermore, to reflect that recent calls contribute more to the current coordination strength than historical calls, the time decay of call strength is implemented. Defined as: in, Indicates time window Internal appearance arrive The set of times when events are called consecutively. For set The moment a certain event occurs in the process. Indicates time window At the end of the day, This is the time decay coefficient, which is taken as a positive value.

[0071] It can be configured according to the calling pattern of the business system. For example, for a real-time trading system with a high calling frequency, A larger value can be taken (e.g., 0.5); for batch processing systems with low call frequency, A smaller value can be taken (such as 0.05).

[0072] Furthermore, in order to make and , For calculations to be performed within the same numerical range, it is necessary to... Normalize. Normalize time decay call intensity. By Divide by the maximum value of the time decay call intensity of all interfaces within the time window to obtain, making .

[0073] S33, the parameter passing strength is determined by identifying the passing fields from the previous API output field set and the subsequent API input field set, and establishing the coverage of the passing fields in both field sets.

[0074] In step S33, the parameter transfer intensity Defined as: in, Interface The set of output fields, Interface The set of input fields, Representation field Field weights, To prevent the introduction of positive numbers with a denominator of zero.

[0075] Understandably, parameter passing strength measures the degree of field passing between interfaces by the ratio of the weighted intersection to the weighted union of the field sets, thus introducing field weights. Subsequently, sensitive fields contribute more to the parameter transmission strength than ordinary fields, making the transmission relationship of sensitive fields a key focus in the calculation of collaborative strength.

[0076] Furthermore, field weights It is determined by the field's sensitivity level, field stability, and field transmission frequency: in, Representation field The sensitivity level of the field, with a value range of 100%. This can be determined by data classification and grading strategies; Representation field The degree of stable occurrence in the historical normal call process; Representation field As a frequency-normalized value for fields passed across interfaces; This represents the complete set of fields participating in the current collaborative computation.

[0077] It should be noted that field stability Defined as: in, This represents the set of historical normal call sequences. Representation field Does it appear in the call sequence? In the parameter structure, This indicates the number of normal call sequences in the history.

[0078] Reflection field The degree of consistency that occurs in normal business processes. The closer to 1, the better the field. It appears consistently during normal calls and is a core data transmission field in the business process.

[0079] S34, Business object consistency strength is established by identifying calls with consistent business object identifiers from the call records of adjacent API pairs, based on the proportion of consistent calls in the total number of calls.

[0080] In step S34, the consistency strength of business objects Defined as: in, Indicates time window Internal interface and The number of consecutive calls with the same business object identifier. Interface To the interface In the time window Total number of consecutive calls within, To prevent the introduction of positive numbers with a denominator of zero, business object identifiers include order number, user number, device number, work order number, transaction serial number, or session identifier.

[0081] Furthermore, after completing the interface collaboration strength calculations in steps S31 to S34, step S3 elevates the interface-level collaboration strength to the role-level, constructing a functional role collaboration graph. Role To the role Collaborative edge weights Defined as: in, Indicates time window The set of interfaces invoked by the internal participants; Interface For the role Functional role attribution; Interface For the role Functional role attribution; Interface To the interface The strength of inter-interface collaboration.

[0082] The collaboration strength between interfaces is weighted and aggregated using the functional role affiliation degree as the weight. The same interface contributes more to role pairs with higher affiliation degree and less to role pairs with lower affiliation degree, so that the role collaboration edge weight accurately reflects the overall collaboration strength between interfaces that assume the corresponding roles.

[0083] when Greater than the preset edge weight threshold At that time, in the role With the character Establish collaborative edges between roles to obtain the functional role collaboration graph: in, Represents a collection of functional role nodes. This represents the set of role collaboration edges within the current time window. This represents the role collaboration edge weight matrix.

[0084] It should be noted that, The weights of roles on collaborative edges in the historical normal call sequence can be determined by statistical distribution. For example, the 10th percentile of the weights of all roles on collaborative edges in the historical normal sequence can be taken as... The reference value is used to filter out occasional low-frequency collaborative relationships and retain role collaborative edges with stable business significance.

[0085] Step S3 outputs the functional role collaboration graph, the role collaboration edge weight matrix, and the API collaboration strength table.

[0086] In real-world business systems, interfaces that perform the same functional role may be implemented using different URL paths, and the interface-level call relationships lack a consistent corresponding structure across different business versions. By aggregating the collaboration strength between interfaces to the role collaboration edge using the functional role affiliation degree as the weight in step S3, the cross-interface and cross-version call collaboration relationships can be uniformly expressed at the functional role level. After interface iteration, the collaboration strength between interfaces performing the same functional role can still maintain a consistent structural description in the role collaboration graph.

[0087] S4: Calculate the role transfer baseline by statistically analyzing the role transfer frequency from the historical normal call sequence. Then, replace the APIs in the call sequence set with the main function roles and compare them with the role transfer baseline to calculate the process deviation.

[0088] In some embodiments, in step S4, each API in each call sequence in the call sequence set is replaced with the corresponding main function role to obtain a role call sequence. The role call sequence corresponding to the call sequence Defined as: in, Indicates the call sequence Middle The main functional role corresponding to each API call. This indicates the number of API calls contained in the sequence.

[0089] It is understandable that when the interface When auxiliary function roles exist, the main function role is used to generate the role call sequence, while the auxiliary function role is reserved for explaining the reasons for subsequent exceptions and does not participate in the calculation of process deviation.

[0090] Furthermore, the role transfer baseline is obtained from statistics of historical normal call sequences. Role To the role Normal transition probability Defined as: in, This represents the set of historical normal call sequences. For indicator functions, To prevent the introduction of positive numbers with a denominator of zero.

[0091] It should be noted that when certain role transfers occur very infrequently in the historical normal call sequence, This value tends to approach 0, causing a significant logarithmic penalty in the deviation calculation for call sequences containing this transition, misclassifying normal but low-frequency role transitions as abnormal. Therefore, the normal transition probability is smoothed, resulting in a smoothed role transition probability. Defined as: in, Indicates the role in the historical normal call sequence To the role Number of transfers, For smoothing coefficients, This indicates the total number of functional role categories.

[0092] Take the smaller positive value, for example, It can be configured to 0.01, ensuring that each role transfer contributes at least [amount] to the denominator. The basic count is used to prevent excessive logarithmic penalties for low-frequency normal transitions.

[0093] In some embodiments, calculating the process deviation in step S4 includes steps S41 to S44, wherein: S41, Identify functional roles that do not appear in the current call sequence from the preset set of key functional roles, and establish key role missing items based on the proportion of missing functional roles in the preset set of key functional roles.

[0094] In step S41, let This represents the set of key functional roles pre-configured in the business process. Indicates the current call sequence Role call sequence The actual set of functional roles in the system, and the missing key roles. Defined as: in, This indicates the actual number of key functional roles appearing in the current sequence. This indicates the total number of key functional roles configured in the business process.

[0095] Understandable Determined by business rule configuration, for example, in the e-commerce order process, It can be configured as an authentication class, verification class, write class, and payment class. When the verification class role does not appear in the call sequence, Missing validation class A value greater than 0 indicates that a key role has been skipped in the sequence.

[0096] S42, identify APIs in the current call sequence whose caller privilege level is lower than the required privilege level of the API being called, and establish unauthorized call items based on the proportion of the identified number in the sequence length.

[0097] In step S42, let Indicates the call sequence The calling body, Indicates the calling body Permission levels, Indicates the first in the call sequence Minimum permission level required for each interface, unauthorized calls. Defined as: in, This is an indicator function. It takes the value 1 when the calling entity's permission level is less than the minimum permission level required by the interface, and otherwise takes the value 0.

[0098] It can be determined by the role and permission configuration of the calling subject in the identity authentication system. It can be determined by the authentication method and access control policy of the interface in the interface documentation.

[0099] S43, accumulate the number of times the function roles of writing, approval, payment and management appear in the current call sequence that are greater than or equal to the normal allowed number of times, and establish sensitive role over-limit items based on the proportion of the accumulated amount in the sequence length.

[0100] In step S43, let This represents a set of sensitive functional roles, including writing, approval, payment, and management classes. Indicates role In the role call sequence The number of times it appears in; Indicates role The maximum number of times allowed in a normal call flow, and sensitive roles exceeding the limit. Defined as: It should be noted that, Roles can be called from the historical normal call sequence. The statistical distribution of occurrence frequency was determined, and roles were selected from the historical normal sequence. The 95th percentile of occurrences is used as a reference value. For example, in a normal order process, the payment role typically appears once. If the payment role appears three times in a call sequence, the two instances exceeding the limit are accumulated. .

[0101] S44 aggregates the role transfer probability deviation item with the key role missing item, the unauthorized call item, and the sensitive role over-limit item into a bounded process deviation.

[0102] In step S44, the role transfer probability deviation term, together with the three penalties obtained in steps S41 to S43, constitutes the comprehensive deviation potential function. : in, Indicates the first character in the role call sequence. The smoothed normal transition probability corresponding to the step role transfer. , , It is a non-negative adjustment coefficient, which can be configured according to the sensitivity of the three types of anomalies in the business scenario.

[0103] It is understandable that the overall deviation potential function The first item is the role transfer probability deviation item, which measures the overall deviation of the transfer pattern by the logarithmic probability mean of each role transfer in the current sequence in the historical normal sequence; the latter three items impose additional penalties on specific abnormal behaviors from three dimensions: missing key roles, unauthorized calls, and sensitive roles exceeding limits.

[0104] Furthermore, process deviation The following is obtained from the comprehensive deviation potential function via bounded mapping: in, The range of values ​​is ,when hour ,when When approaching infinity Approaching 1.

[0105] Introduce bounded mappings instead of using them directly This is because the call sequence lengths of different business processes vary greatly, and the absolute value of the overall deviation potential is affected by the sequence length. The process deviation after bounded mapping is comparable between sequences of different lengths.

[0106] when Greater than the deviation threshold At that time, the call sequence is marked as a flow deviation sequence. Defined as: in, This represents the mean deviation of the historical normal call sequence flow. The standard deviation of the historical normal call sequence flow is represented by the standard deviation of the call sequence flow. This is the threshold adjustment coefficient.

[0107] It should be noted that, and Collection of historical normal call sequences Calculate line by line The results were obtained later. Configured according to detection sensitivity requirements, for example, Taking a value of 2 corresponds to approximately a 95% confidence interval for a normal distribution. A value of 3 corresponds to a confidence interval of approximately 99.7%. The larger the value, the higher the deviation from the threshold, the lower the false alarm rate but the higher the false negative rate.

[0108] Step S4 outputs the role call sequence, the comprehensive deviation potential function value, the process deviation degree, and the process deviation sequence set.

[0109] In abnormal call scenarios such as authentication bypass, missing verification, and approval skipping, the response status code and parameter values ​​of a single interface may appear normal, and the anomaly cannot be identified based on the characteristics of a single interface alone. Step S4 converts the call sequence into a role call sequence and compares it with the role transfer baseline. The above scenarios produce observable deviations at the role transfer pattern level. Direct transfer from the authentication class to the write class, the absence of verification roles, and the duplicate appearance of payment roles all contribute to this. Significantly increased, thus making Greater than This triggers a process deviation from the sequence marker.

[0110] S5. When the process deviation is greater than the deviation threshold, calculate the propagation impact value from the risk source role to the risk target role in the role collaboration diagram. When the propagation impact value is greater than the propagation threshold, generate a collaboration anomaly event.

[0111] In some embodiments, step S5 involves checking if the process deviation is greater than a deviation threshold. The call sequence is first determined by identifying the risk source role and the risk target role. The risk source role is the first role in the call sequence to experience an abnormal transfer; if multiple abnormal transfers exist in the sequence, they are selected in the order of lowest transfer probability, priority given to sensitive roles involved, and earliest occurrence time. The risk target role is the functional role in the call sequence that involves write, approval, payment, or management functions.

[0112] In some embodiments, step S5 includes steps S51 to S55, wherein: S51: Starting from the risk source role in the role collaboration graph, gradually extend along the directed edges to collect all directed paths whose path length is less than or equal to the preset path length upper limit.

[0113] In step S51, let Functional Role Collaboration Diagram The role of risk sources To risk target role Path length not exceeding The set of all directed paths, This is the preset maximum path length.

[0114] The maximum number of steps in the business process can be configured. For example, in an e-commerce order process, the complete business process typically involves no more than 5 functional roles. It can be configured to 5 to cover all reasonable cross-role propagation paths while avoiding the computational overhead of enumerating excessively long paths.

[0115] S52, for each edge on the directed path, determine the edge propagation ratio by the proportion of the edge's collaborative strength to the total collaborative strength of all outgoing edges of the initial role, and obtain the path propagation probability by passing the edge propagation ratios on the directed path in sequence.

[0116] In step S52, for directed paths Each directed edge on The side propagation ratio is defined as: in, Indicates role To the role Collaborative edge weights, Starting role All adjacent role indexes, To prevent the introduction of positive numbers with a denominator of zero.

[0117] path The path propagation probability is the product of the propagation proportions of each edge along the path: It is understandable that the edge propagation ratio is expressed in a normalized form, while the path propagation probability reflects the relative likelihood of risk propagating along a path. The higher the synergy strength, the greater the path propagation probability.

[0118] S53 uses the path length as input and determines the path length attenuation factor through an attenuation function.

[0119] In step S53, the path length attenuation factor is defined as: in, Represents a directed path The number of edges is the path length. This is the path length attenuation coefficient, and it is taken as a positive value.

[0120] The path length is negatively correlated with the path length decay factor. The longer the path, the smaller the decay factor, reflecting that the risk passes through more functional roles and the weaker the impact on the target role. The configuration can be based on the actual attenuation level of cross-role propagation in the business system. For example, When the value is 0.2, for every one-step increase in path length, the propagation decays back to its original value. ; When the value is 0.5, the decay is 1 step for each additional step. .

[0121] S54 establishes risk intensity based on the deviation of the process sequence in which the risk source role participates within the current time window.

[0122] In step S54, the role of the source of risk In the time window Risk intensity within Defined as: in, Indicates time window The process deviates from the sequence set within the internal flow. Indicates role Does it appear in the call sequence? Role call sequence middle, Indicates the degree of process deviation from the sequence. To prevent the introduction of positive numbers with a denominator of zero.

[0123] The range of values ​​is molecule as role The weighted mean of the deviations in the participating deviation sequences is converted into risk intensity through a bounded mapping. When the role... When frequently participating in high-deviation sequences within the current time window Approaching 1; when the role When not involved in any off-sequence, .

[0124] S55 transmits the risk intensity, path propagation probability, and path length attenuation factor along all directional paths and converges them into a propagation impact value.

[0125] In step S55, the role of the source of risk Risk target role propagation impact value Defined as: Among them, for the path set The summation of all directed paths in the equation is used, and the contribution of each path is determined by the product of risk intensity, path length decay factor, and path propagation probability.

[0126] when Greater than the deviation threshold and Greater than the propagation threshold When this occurs, a collaborative exception event is generated. A collaborative exception event must include at least the calling entity, the sequence of exception calls, the exception role transfer path, the APIs involved, the role of the source of the risk, the role of the target of the risk, the risk propagation path, the degree of process deviation, and the propagation impact value.

[0127] It should be noted that, The impact of each role on the propagation can be determined by the statistical distribution of the propagation impact value in the historical normal call sequence. The 95th percentile is taken as a reference value to filter out occasional low propagation impact and retain abnormal events with significant risk propagation characteristics.

[0128] Step S5 outputs the set of collaborative abnormal events and the risk propagation path.

[0129] In real-world business systems, attackers might bypass verification roles and directly trigger write and payment roles. Each individual API call might appear to have a normal response, making it impossible to identify the attacker from a single API perspective. When the deviation in the call sequence exceeds a certain threshold... Then, the propagation impact value from query-type roles to payment-type roles is calculated in the role collaboration graph. If the collaboration edge weight between the query-type and write-type roles is... If the weight of the collaborative edge between the write class and the payment class is high, then the propagation impact value will be high. Greater than This triggers the generation of collaborative exception events, enabling cross-role collaborative exceptions to be identified.

[0130] S6: For role transfers involved in collaborative anomalies, a pre-defined verification rule is used to determine the transfer frequency. If the determination is successful, the frequency of the role transfers involved is incorporated into the role transfer baseline; otherwise, it is recorded in the abnormal role transfer rule set.

[0131] In some embodiments, step S6 includes steps S61 to S64, wherein: S61, retrieve the associated records of the role transfer from the business change records, approval work orders and business rule configurations, and establish a business change verification record based on whether the associated records exist.

[0132] In step S61, let Indicates whether there is a role transfer. Relevant business change records, Indicates whether there is a role transfer. Relevant approval forms, release forms, or change orders, Indicates role transfer Whether it is configured to allow transfer by business rules, all three are binary indicators with values ​​of 0 or 1.

[0133] Business confirmation strength Defined as: in, , , The weights are non-negative and satisfy the following conditions: .

[0134] Understandable , , The system can be configured based on the varying levels of trustworthiness among the three sources. For example, approval work orders that have undergone manual review have a higher level of trustworthiness. A value of 0.5 is acceptable; business change records are automatically generated by the system. A value of 0.3 is acceptable; rule configurations are preset by the system. 0.2 is acceptable.

[0135] S62, in the observation window after the collaborative abnormal event is generated, collect the interface error rate, alarm trigger count, and process deviation of the call sequence involved in the role transfer, and establish access status verification records by comparing the interface error rate, alarm trigger count, and process deviation with preset thresholds.

[0136] In step S62, subsequent stability Defined as: in, Indicates role transfer The interface error rate is observed in the observation window after an exception event is generated. This represents the normalized value of the number of alarm triggers within the observation window; This indicates that the observation window contains a role transfer. The average flow deviation of the call sequence; , , The weights are non-negative.

[0137] , , The importance of stability assessment can be configured based on error rate, alarm trigger frequency, and process deviation. For example, if the business scenario is sensitive to interface errors, A larger value can be taken; if more attention is paid to the degree of deviation of the overall process, A larger value can be taken.

[0138] when When the value approaches 1, the error rate, alarm trigger count, and average process deviation are all within the normal range during the subsequent observation window; when any of the above indicators increases, Correspondingly reduce, and reliably update the weight. It then decreases.

[0139] S63, count the number of times the role transfer involved occurs in the deviation sequence, the number of times it participates in collaborative abnormal events, and the total number of observations, and establish a risk participation verification record based on the number of occurrences, the number of participations, and the total number of observations.

[0140] In step S63, the risk intensity of role transfer. Defined as: in, Indicates role transfer Does it appear in the call sequence? Role call sequence middle, Indicates the degree of process deviation from the sequence. Indicates time window The set of processes deviating from the sequence.

[0141] Furthermore, the intensity of participation of anomalous events Defined as: in, Indicates role transfer In the time window The number of times internal participation in collaborative anomalies. Indicates role transfer In the time window The total number of times it was observed inside To prevent the introduction of positive numbers with a denominator of zero.

[0142] S64, when the business change verification record, access status verification record and risk participation verification record all meet the preset conditions, the judgment is passed.

[0143] In step S64, the test is passed when all three of the following conditions are met: in, To confirm the strength threshold for business operations, The threshold for the risk intensity of role transfer. This is the threshold for the intensity of participation in abnormal events.

[0144] It should be noted that, Configure according to business compliance requirements, for example, take 0.6; Based on the risk tolerance configuration, an example value of 0.3 is used; Based on the abnormal participation frequency tolerance configuration, an example value of 0.2 is set.

[0145] When the judgment is passed, the role transfer baseline is updated according to the reliable update weight. First, the time window is calculated. Inner Role To the role Current observed transition probability : in, Indicates time window The collection of call sequences within, This is an indicator function.

[0146] Furthermore, trusted update weights It is determined jointly by the strength of business confirmation, subsequent stability, the strength of role transfer risk, and the strength of participation in abnormal events: in, This represents the Sigmoid function, which maps the input to... scope; , , , As non-negative weights, the strength of business confirmation and subsequent stability contribute positively to the update weight, while the strength of role transfer risk and the intensity of participation in abnormal events contribute negatively to the update weight.

[0147] Understandable , , , Trust weights for the four dimensions can be configured according to business scenarios. For example, if more emphasis is placed on confirming business compliance, A larger value can be chosen; if the stability of subsequent access behavior is of greater importance, A larger value can be taken.

[0148] After determining the reliable update weights, the role transfer baseline is updated as follows: in, This indicates the baseline for character transfer before the update. This indicates the updated character transfer baseline. This represents the observation transition probability within the current time window.

[0149] when When it is large, The trend towards current observations reflects that the role transition has sufficient business compliance support; when When smaller, Maintaining close to historical baselines does not adequately reflect the compliance of role transitions.

[0150] When the three conditions are not met simultaneously, the role transfer involved will not be written into the normal role transfer baseline, but will be recorded in the abnormal role transfer rule set for reference in subsequent abnormal identification.

[0151] Step S6 outputs collaborative anomaly events, risk propagation paths, updated role transfer baselines, and a set of anomaly role transfer rules.

[0152] In real-world business systems, API call behavior continuously evolves with business version upgrades and process adjustments. If a role transfer with a low probability in the original baseline occurs in a newly added legitimate business process, deviation detection alone will continuously mark the transfer as abnormal. Through the three-dimensional verification and trusted update mechanism in step S6, under the conditions that business change records and approval work orders exist and subsequent access is stable, the observed transfer probability of role transfer is based on... Gradually integrate role transfer baselines so that they can automatically adapt to compliant business process changes, while blocking role transfers that are not confirmed by business or still pose a high risk, preventing abnormal calls from being mistakenly absorbed as normal processes.

[0153] like Figure 2 As shown, in the process of steps S1 to S5, step S2 has three branches: main function role determination, auxiliary function role recording, and manual confirmation queue. Steps S4 and S5 each have threshold judgment exits.

[0154] like Figure 3 As shown, in step S6, the interaction process between the verification rule engine and the call sequence set, the role transfer baseline and the abnormal role transfer rule set, as well as the two processing paths corresponding to the judgment results of the three verification records.

[0155] Example 2 is an embodiment of the present invention, which provides an API collaborative call analysis method based on functional role division. In order to verify the beneficial effects of the present invention, scientific demonstration is carried out through experiments.

[0156] Using an e-commerce order system as a verification scenario, the complete operation process of the method of this invention is described. The e-commerce order system operates within a time window. It involves 5 APIs: User Authentication Interface Product query interface Inventory verification interface Order creation interface and payment interface The functional role category set is Each corresponds to an authentication class. Query Class Validation class Write to class and payment .

[0157] According to the time window By aggregating the link tracing identifiers within the API, and counting the number of consecutive calls between each API, an API call count matrix is ​​obtained. : Among them, the Line 1 Column elements Interface To the interface The number of consecutive calls. express Subsequent calls The number of times was 86. express Jump directly to The number of times it was called was 6, which is significantly lower than the number of times the normal path was called. Further analysis is needed in conjunction with historical baselines.

[0158] right Normalize by row to obtain the API call transition matrix. : The main call chain of a normal order process is as follows: ,in The corresponding transition probability is 0.071, which belongs to a low-frequency collaborative relationship and needs to be judged together with the historical baseline at the role level.

[0159] Based on the path characteristics, request method characteristics, parameter structure characteristics, and interface description characteristics of each interface, the matching value between each interface and each functional role category is calculated and normalized to obtain the API-role attribution matrix. : No. Line 1 Column elements represent interfaces Functional role categories degree of belonging . For authentication classes Its attribution score is 0.92, which is greater than the primary role threshold, thus it is classified as an authentication type. For writing class Its affiliation score is 0.84, classifying it as a write class. Therefore, the main functional role mapping relationship is obtained: Using functional role affiliation as the weight, the collaboration strength between interfaces is aggregated to the corresponding role pairs, forming a functional role collaboration matrix. pass The calculation yielded: This indicates a high degree of collaboration between the authentication and query classes. This indicates a high level of collaboration between the query and validation classes, both of which conform to the normal order process. This indicates that there is some coordination between the query class and the write class, but it is significantly smaller than... It is necessary to make a judgment based on the historical role transfer baseline.

[0160] Based on the historical normal call sequence, the role transfer frequency is statistically analyzed and smoothed to obtain the role transfer baseline matrix. : This indicates that the probability of transitioning from the query class to the validation class is relatively high in the historical normal process; This indicates that the probability of a query class being directly transferred to the write class is relatively low, and a corresponding probability penalty term is applied. When the call sequence appears When the role changes, the deviation potential function will increase significantly.

[0161] In the time window Inside, the calling entity Generate API call sequence: Based on the main function role mapping relationship, the role call sequence is obtained: middle This indicates a direct transfer from the query class to the write class, skipping the role of the validation class. ; Calling subject The user's permission level is insufficient to directly access the order creation interface. However, access to the product query interface is allowed. and payment interface .

[0162] Let the set of key functional roles in the order process be: The set of key functional roles appearing in the current sequence is as follows: The key missing roles are: In the call sequence, one of the three interfaces was called without authorization. Unauthorized calls are: Pick , , , , The overall deviation potential function is: Process deviation is: Set deviation threshold , , It was marked as a process deviation sequence.

[0163] right Normalize by rows to obtain the propagation transition matrix. : Take the role of the source of risk as Risk target role is ,path The path length is 2, take , The propagation impact value is: Set the propagation threshold , Generate collaborative exception events: Manual review and confirmation This is not part of the normal business process; it involves a role transfer. Record the abnormal role transfer rule set, and do not update the role transfer baseline.

[0164] If subsequent business version changes confirm the addition of a legitimate and quick order placement process, and the business change record and approval work order both exist, then... , , ,Pick , , The trusted update weight is: Baseline for character transfer before update Current window observation transition probability The updated character transfer baseline is: Updated from 0.04 to 0.175, under the conditions of sufficient business confirmation, stable subsequent access, and low risk intensity, the transition from query-based to write-based operations was incorporated into the normal baseline, and the role transition will take place within the subsequent time window. The contribution of deviation will decrease accordingly. If the business is not confirmed or Greater than ,but Approaching 0, Maintain a level close to the historical value of 0.04, role shift. It will remain in the set of rules for abnormal role transfer.

[0165] Example 3 is an embodiment of the present invention. This embodiment provides an API collaborative call analysis system based on functional role division, including: a data acquisition module, used to aggregate API call information from API access logs and call link records according to link tracing identifiers to form a call sequence set; The role recognition module is used to match the features of each API in the call sequence set with the role prototype vector of the functional role category to obtain the functional role affiliation degree and determine the main functional role. The collaboration graph construction module is used to aggregate the collaborative associations of adjacent API pairs to the role pairs to which they belong, based on the functional role affiliation degree as the weight, and construct a role collaboration graph; The deviation calculation module is used to calculate the deviation of the process by statistically analyzing the role transfer frequency from the historical normal call sequence and then comparing the API in the call sequence set with the main function role and the role transfer baseline. The anomaly identification module is used to calculate the propagation impact value from the risk source role to the risk target role in the role collaboration diagram when the process deviation is greater than the deviation threshold. When the propagation impact value is greater than the propagation threshold, a collaboration anomaly event is generated. The baseline update module is used to determine the role transfer involved in collaborative abnormal events according to preset verification rules. If the determination is successful, the frequency of the role transfer involved will be included in the role transfer baseline; otherwise, it will be recorded in the abnormal role transfer rule set.

[0166] This embodiment also provides an electronic device applicable to an API collaborative call analysis method based on functional role division, 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 API collaborative call analysis method based on functional role division proposed in the above embodiment.

[0167] This embodiment also provides a storage medium on which a computer program is stored. When the program is executed by a processor, it implements an API collaborative call analysis method based on functional role division as proposed in the above embodiment.

[0168] The storage medium proposed in this embodiment and the API collaborative call analysis method based on functional role division 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.

[0169] 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.

[0170] 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 API cooperative invocation analysis based on function role division, characterized in that, include: API call information is aggregated from API access logs and call chain records based on the link tracing identifier to form a call sequence set; Match the features of each API with the role prototype vector of the functional role category to obtain the functional role affiliation degree, and take the role category with the highest affiliation degree as the main functional role; By using the functional role affiliation degree as the weight, the collaborative associations of adjacent API pairs are aggregated to the role pairs to which they belong, and a role collaboration graph is constructed. The role transfer baseline is constructed by statistically analyzing the transfer frequency of roles in the historical normal call sequence. The deviation of the process is calculated by replacing the APIs in the call sequence set with the main functional roles and comparing them with the role transfer baseline. When the deviation of the process is greater than the deviation threshold, the propagation impact value from the risk source role to the risk target role is calculated in the role collaboration diagram. When the propagation impact value is greater than the propagation threshold, a collaboration anomaly event is generated. Role transfers involved in collaborative anomalies are determined according to preset verification rules. If the determination is successful, the frequency of the involved role transfers is included in the role transfer baseline; otherwise, it is recorded in the abnormal role transfer rule set.

2. The API collaborative invocation analysis method based on function role division according to claim 1, wherein, The obtained functional role attribution includes: The center position of the feature vector of APIs that have completed role labeling and belong to the same functional role category is established as the role prototype vector, and the degree of dispersion of the feature vectors of APIs within the same category around the role prototype vector is established as the prototype distribution scale. Based on the distance relationship between each API's own feature vector and the role prototype vector, as well as the prototype distribution scale, the position of each API in the functional role category is located, and the matching value is obtained. The normalized matching value of each API across all functional role categories is used as the functional role attribution degree.

3. The API collaborative invocation analysis method based on function role division according to claim 2, characterized in that, The category with the highest attribution degree is selected as the primary functional role, including: When the highest functional role affiliation degree is greater than or equal to the main role threshold, the functional role category with the highest affiliation degree will be determined as the main functional role. When the highest functional role affiliation is less than the primary role threshold, the API to be judged will be marked as an API with uncertain role and included in the manual confirmation queue. When there is a matching value in the functional role attribution degree that is greater than or equal to the auxiliary role threshold and less than the main role threshold, the functional role category to which the matching value belongs is recorded as the auxiliary functional role of the API to be determined.

4. The API cooperative call analysis method based on function role division according to claim 3, characterized in that, The time decay call strength, parameter passing strength, and business object consistency strength of the adjacent API pairs are fused according to a preset weight to form the collaborative association of the adjacent API pairs; The time decay call strength is established by accumulating the call records of the adjacent API pairs after applying decay weights according to the time interval from the end of the time window; The parameter transmission strength is determined by identifying the transmitted fields from the previous API output field set and the subsequent API input field set, and is established by the coverage of the transmitted fields in both field sets. The consistency strength of the business object is established by identifying calls with consistent business object identifiers from the call records of adjacent API pairs, based on the proportion of consistent calls in the total number of calls.

5. The API cooperative invocation analysis method based on function role division according to claim 4, characterized in that, The deviation in the calculation process includes: Identify functional roles that do not appear in the current call sequence from the preset set of key functional roles, and establish key role missing items based on the proportion of missing functional roles in the preset set of key functional roles; APIs in the current call sequence whose calling entity's permission level is lower than the required permission level of the API being called are identified, and unauthorized call items are established based on the proportion of the identified number in the sequence length; The number of times that the writing, approval, payment and management function roles appear in the current call sequence is greater than or equal to the normal allowed number of times, and the excess number of sensitive roles is established based on the proportion of the accumulated amount in the sequence length; The deviation term of the role transfer probability is aggregated with the missing key role term, the unauthorized call term, and the sensitive role over-limit term to form the bounded process deviation.

6. The API cooperative call analysis method based on function role division according to claim 5, characterized in that, The calculation of the propagation impact value from the risk source role to the risk target role includes: Starting from the risk source role in the role collaboration graph, the graph extends gradually along the directed edges to collect all directed paths whose path length is less than or equal to the preset path length upper limit. For each edge on the directed path, the edge propagation ratio is determined by the proportion of the edge's collaboration strength to the total collaboration strength of all outgoing edges of the starting role. The path propagation probability is obtained by passing the edge propagation ratios on the directed path in sequence. The path length attenuation factor is determined by using the attenuation function as input; The risk intensity is established based on the process deviation of the deviation sequence in which the risk source role participates within the current time window; The risk intensity, the path propagation probability, and the path length attenuation factor are transmitted along all the directed paths and converged into the propagation impact value.

7. The API cooperative call analysis method based on function role division according to claim 6, characterized in that, The preset verification rules include: Retrieve the associated records of the role transfer from the business change records, approval work orders and business rule configurations, and establish a business change verification record based on whether the associated records exist; Within the observation window after the collaborative anomaly event is generated, the interface error rate, alarm trigger count, and process deviation of the involved role transfer are collected. An access status verification record is established by comparing the interface error rate, alarm trigger count, and process deviation with a preset threshold. The number of times the role transfer involved occurs in the deviation sequence, the number of times it participates in the collaborative anomaly event, and the total number of observations are counted. A risk participation verification record is established based on the number of occurrences, the number of participations, and the total number of observations. The system is deemed successful when the business change verification record, access status verification record, and risk participation verification record all meet the preset conditions.

8. An API cooperative call analysis system based on function role division, applying the API cooperative call analysis method based on function role division according to any one of claims 1-7. include: The data acquisition module is used to aggregate API call information from API access logs and call chain records according to the link tracing identifier to form a call sequence set; The role recognition module is used to match the features of each API in the call sequence set with the role prototype vector of the functional role category to obtain the functional role affiliation degree and determine the main functional role. The collaboration graph construction module is used to aggregate the collaborative associations of adjacent API pairs to the role pairs to which they belong, using the functional role affiliation degree as the weight, and construct a role collaboration graph; The deviation calculation module is used to construct a role transfer baseline by statistically analyzing the role transfer frequency from the historical normal call sequence, and then compares the API in the call sequence set with the main function role and the role transfer baseline to calculate the process deviation. An anomaly identification module is used to calculate the propagation impact value from the risk source role to the risk target role in the role collaboration graph when the process deviation is greater than the deviation threshold, and to generate a collaboration anomaly event when the propagation impact value is greater than the propagation threshold. The baseline update module is used to determine the role transfer involved in the collaborative abnormal event according to the preset verification rules. If the determination is successful, the frequency of the involved role transfer is incorporated into the role transfer baseline; otherwise, it is recorded in the abnormal role transfer rule set.

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 API collaborative call analysis method based on functional role division 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 API collaborative call analysis method based on functional role division as described in any one of claims 1 to 7.

Images