API (Application Program Interface) data exception identification method and device

Abstract

The invention provides an API (Application Program Interface) data exception identification method and device. Obtaining calling data of a to-be-analyzed target API (Application Program Interface); according to the calling data of the target API, a preset API exception recognition rule base is retrieved, and a matched target API exception recognition rule is determined; wherein the preset API exception identification rule base is constructed by processing historical API exception call data by using a preset large language model in advance; and determining whether the API calling data is abnormal or not by processing the calling data of the target API according to the target API exception identification rule. Based on the above mode, the API exception recognition rule base for exception detection can be quickly and accurately constructed by processing the historical API exception call data by using the preset large language model, and compared with a manual rule making mode, the method has the advantages of being high in efficiency and speed, wide in coverage rate and flexible.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and more particularly to a method and device for identifying anomalies in API data. Background Art

[0002] At present, API data security incidents face many challenges. Due to the large number and variety of API interfaces and the attackers' continuous use of new technical means and attack methods, the identification of API data anomalies has problems of low efficiency and poor accuracy.

[0003] To address the above problems, no effective solution has been proposed yet. Summary of the invention

[0004] This specification provides a method and device for identifying API data anomalies. By using a preset large language model and processing historical API abnormal call data, an API anomaly recognition rule library for anomaly detection can be quickly and accurately constructed. This solves the problem of low efficiency and narrow coverage of identifying API data anomalies through manually formulated rules, and improves the accuracy and efficiency of API call data anomaly recognition.

[0005] This specification provides a method for identifying API data anomalies, including:

[0006] Get the call data of the target API to be analyzed;

[0007] According to the call data of the target API, a preset API exception identification rule library is retrieved to determine a matching target API exception identification rule; wherein the preset API exception identification rule library is pre-constructed by processing historical API exception call data using a preset large language model;

[0008] By processing the call data of the target API according to the target API exception identification rule, it is determined whether the API call data has an exception.

[0009] In one embodiment, the method further comprises:

[0010] Obtain the historical API exception call data;

[0011] Determine a plurality of preset API anomaly identification rules by processing the historical API anomaly call data using the preset large language model;

[0012] According to the plurality of preset API anomaly identification rules, the preset API anomaly identification rule library is constructed.

[0013] In one embodiment, the method of using the preset large language model to process the historical API exception call data to determine a plurality of preset API exception identification rules includes:

[0014] Perform feature extraction processing on the historical API abnormal call data to obtain corresponding API abnormal feature variables;

[0015] The preset large language model is utilized to determine a plurality of preset API anomaly identification rules according to the API anomaly feature variables.

[0016] In one embodiment, the API exception identification rules in the rule base include but are not limited to frequency exception identification rules, authentication exception identification rules, request pattern exception identification rules, parameter exception identification rules, response time exception identification rules, sensitive data access exception identification rules, and dependent service exception identification rules.

[0017] In one embodiment, the determining whether the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule includes:

[0018] Determine a first anomaly detection result according to the target API anomaly identification rule;

[0019] Obtaining API access log data corresponding to the API call data; wherein the API access log data includes but is not limited to the access source, timestamp, request path, parameter content, response status code, IP address, and device type of the API call data;

[0020] Determine access characteristics and request characteristics according to the API access log data, and determine a second anomaly detection result according to the access characteristics and the request characteristics;

[0021] Determine whether the API call data has an abnormality according to the first abnormality detection result and the second abnormality detection result.

[0022] In one embodiment, the method further comprises:

[0023] When it is determined that an abnormality exists in the API call data by processing the call data of the target API according to the target API abnormality identification rule, an abnormality alarm reminder is sent according to the preset alarm rule and based on the preset notification method.

[0024] In one embodiment, the method further comprises:

[0025] When it is determined that the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule, generating an access control policy for the API call data according to the target API abnormality identification rule;

[0026] According to the access control policy, access control processing is performed on the API call data.

[0027] This specification provides an API data anomaly identification device, including:

[0028] A data acquisition module is used to obtain the call data of the target API to be analyzed;

[0029] A rule determination module, used to retrieve a preset API exception identification rule library according to the call data of the target API, and determine a matching target API exception identification rule; wherein the preset API exception identification rule library is pre-constructed by processing historical API exception call data using a preset large language model;

[0030] The abnormality judgment module is used to determine whether there is an abnormality in the API call data by processing the call data of the target API according to the target API abnormality identification rule.

[0031] This specification also provides an electronic device, including a processor and a memory for storing processor executable instructions, wherein the processor implements an API data anomaly identification method when executing the instructions.

[0032] This specification also provides a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed, a method for identifying anomalies in API data is implemented.

[0033] Based on an API data anomaly identification method provided in this specification, the call data of the target API to be analyzed is obtained; according to the call data of the target API, the preset API anomaly identification rule library is retrieved to determine the matching target API anomaly identification rule; wherein the preset API anomaly identification rule library is pre-constructed by processing historical API anomaly call data using a preset large language model; according to the target API anomaly identification rule, by processing the call data of the target API, it is determined whether the API call data has an anomaly. In this way, by using the preset large language model and processing the historical API anomaly call data, an API anomaly identification rule library for anomaly detection can be quickly and accurately constructed. Compared with the manual rule-making method, it has the advantages of high efficiency, high speed, wide coverage and flexibility, which reduces labor costs, and then through the API anomaly identification rules in the API anomaly identification rule library, the accuracy and efficiency of API call data anomaly identification can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of this specification, the drawings required for use in the embodiments will be briefly introduced below. The drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0035] Figure 1 It is a flowchart of an API data anomaly identification method provided by an embodiment of this specification;

[0036] Figure 2 It is a schematic diagram of the structure of an electronic device provided by an embodiment of this specification;

[0037] Figure 3 It is a schematic diagram of the structure of an API data anomaly identification device provided by an embodiment of this specification;

[0038] Figure 4 It is a flowchart of another API data anomaly identification method provided by an embodiment of this specification. DETAILED DESCRIPTION

[0039] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0040] See also Figure 1 As shown, the embodiment of this specification provides a method for identifying API data anomalies, wherein the method is specifically applied to the server side. When implemented specifically, the method may include the following contents:

[0041] S101: Obtain call data of the target API to be analyzed;

[0042] S102: According to the call data of the target API, a preset API exception recognition rule library is retrieved to determine a matching target API exception recognition rule; wherein the preset API exception recognition rule library is pre-constructed by processing historical API exception call data using a preset large language model;

[0043] S103: Determine whether there is an abnormality in the API call data by processing the call data of the target API according to the target API abnormality identification rule.

[0044] The target API call data may include request metadata and response metadata. Specifically, the request metadata may include HTTP method, request path, query parameters, path parameters, request header information, and request body content. The response metadata may include HTTP status code, response header information, and response body content (such as returned JSON data or files).

[0045] In some embodiments, the step of retrieving a preset API exception identification rule library based on the call data of the target API to determine a matching target API exception identification rule may include:

[0046] S1: extract key features from the target API call data to obtain key features corresponding to the call data;

[0047] S2: Obtain the matching degree between the key feature and each API exception identification rule in the preset API exception identification rule library, and determine the target API exception identification rule in the API exception identification rule that matches the call data of the target API according to the matching degree.

[0048] Among them, the key features corresponding to the above-mentioned call data may include authentication status features, status code features, response time features, error type features, request frequency features, request path features, etc. Specifically, the authentication status feature may refer to data fields and information related to user identity authentication during the API call process; the status code feature may extract all abnormal status codes and their occurrence frequencies (such as 4xx, 5xx) from the call data; the response time feature may analyze the distribution of response time and identify the abnormal time range (such as response time exceeding 3 seconds) from the call data; the error type feature may extract the occurrence patterns of different error types (such as authentication failure, request overload) from the call data; the request frequency feature may be to count the request frequency per unit time from the call data and identify abnormal situations where the frequency is too high or too low; the request path feature may analyze the URL path of the call from the call data.

[0049] In some embodiments, obtaining the matching degree between the key feature and each API anomaly identification rule in the preset API anomaly identification rule library may include:

[0050] According to the preset corresponding relationship between the key feature and each API anomaly identification rule in the preset API anomaly identification rule library, the matching degree between the key feature and each API anomaly identification rule in the preset API anomaly identification rule library is determined.

[0051] For example, if there is a preset correspondence between the invalid token authentication API exception identification rule and the authentication status feature in the rule base, then correspondingly, the matching degree between the invalid token authentication API exception identification rule and the authentication status feature can be greater than the preset matching degree threshold. If there is a preset correspondence between the suspicious source IP API exception identification rule and the request path feature in the rule base, then correspondingly, the matching degree between the suspicious source IP API exception identification rule and the request path feature can be greater than the preset matching degree threshold. If there is a preset correspondence between the illegal access to restricted resources API exception identification rule and the status code feature in the rule base, then correspondingly, the matching degree between the illegal access to restricted resources API exception identification rule and the status code feature can be greater than the preset matching degree threshold.

[0052] Furthermore, the above-mentioned preset API anomaly identification rule library may include security rules (such as identity authentication, SQL injection, frequent access restrictions, invalid token authentication, suspicious source IP), data integrity and format rules (such as required field verification, input length limit), access behavior rules (such as too fast access frequency, interface abuse, deviation from normal mode detection), status code rules (such as high proportion of 4xx / 5xx alarms, unauthorized access may be brute force, illegal access to restricted resources or malicious requests causing system crashes), performance rules (such as response time limit exceeded, system load monitoring), resource usage rules (such as bandwidth and file upload restrictions), and response content rules (such as sensitive data detection, return consistency check), etc.

[0053] In some embodiments, the method of retrieving a preset API exception identification rule library based on the call data of the target API to determine a matching target API exception identification rule may also include:

[0054] According to the call data of the target API, a preset API anomaly identification rule library is retrieved to determine a plurality of target API anomaly identification rules;

[0055] According to the multiple target API exception identification rules, a matching target API exception identification rule is determined.

[0056] In some embodiments, the determining whether the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule may include:

[0057] S1: Obtaining request body information of the target API call data;

[0058] S2: determining the target scenario of the call data of the target API according to the request body information;

[0059] S3: Determine whether there is an abnormality in the API call data according to the target scenario and the target API abnormality identification rule.

[0060] For example, taking the ticket type information (ticket_type) contained in the above request body information as an example, assuming that the target API abnormality identification rule is that if the access frequency within the preset detection period is greater than the preset frequency threshold, then the API call data is abnormal. Based on the request body information, it can be determined that the target scenario is a ticket grabbing scenario. At this time, it can be determined whether the API call data is abnormal based on the ticket grabbing scenario and the target API abnormality identification rule. Specifically, due to the particularity of the access frequency in the ticket grabbing scenario, it can be determined that the target API call data is not abnormal.

[0061] Based on the above embodiment, by utilizing the preset large language model and processing historical API exception call data, an API exception recognition rule library for anomaly detection can be quickly and accurately constructed. Compared with the manual rule-making method, it has the advantages of high efficiency, high speed, wide coverage and flexibility, and reduces labor costs. Furthermore, through the API exception recognition rules in the API exception recognition rule library, the accuracy and efficiency of API call data anomaly recognition can be improved.

[0062] In some embodiments, the method may further include the following when implemented:

[0063] S1: Obtain the historical API abnormal call data;

[0064] S2: using the preset large language model to process the historical API exception call data to determine a plurality of preset API exception identification rules;

[0065] S3: Constructing the preset API anomaly identification rule library according to the plurality of preset API anomaly identification rules.

[0066] The above historical API abnormal call data may refer to the abnormal historical API call data obtained within the preset rule construction cycle. Specifically, the historical API abnormal call data may include request-related abnormal data, response abnormal data (such as status code return abnormality), specific error information (such as error type, error description, exception stack information) and other historical API call data.

[0067] Based on the above embodiment, the preset large language model is used to process the historical API exception call data to generate API exception identification rules, which can greatly improve the efficiency and coverage of exception detection, while continuously optimizing the accuracy of API exception identification rules. In addition, the preset large language model can comprehensively analyze multi-dimensional data (such as request frequency, status code combination, user behavior pattern), generate more accurate and complex API exception identification rules, and can effectively cover different types of abnormal scenarios. At the same time, the preset large language model can also be used to dynamically adjust and optimize the API exception identification rules according to incremental data, so that the rule base is always kept up to date and highly applicable, suitable for rapidly changing API call scenarios. Furthermore, using the learning ability of the preset large language model, rules suitable for complex abnormal behaviors can be generated, such as multi-feature combination anomalies (such as high frequency + status code anomalies + specific path access), to improve detection accuracy.

[0068] In some embodiments, the method of using the preset large language model to process the historical API abnormal call data to determine a plurality of preset API abnormality identification rules may include:

[0069] S1: Perform feature extraction processing on the historical API abnormal call data to obtain corresponding API abnormal feature variables;

[0070] S2: Using the preset large language model, according to the API abnormality feature variables, determine a plurality of preset API abnormality identification rules.

[0071] Among them, the above-mentioned API abnormal feature variables can be authentication abnormal state features, status code abnormal features, response time abnormal features, error type abnormal features, request frequency abnormal features, request path abnormal features, etc.

[0072] In some embodiments, the feature extraction process of the historical API abnormal call data to obtain the corresponding API abnormal feature variable may include:

[0073] According to different types of data of the historical API abnormal call data, different feature extraction processing methods are adopted for the different types of data to obtain corresponding API abnormal feature variables.

[0074] Based on the above embodiments, by using a preset large language model, API anomaly identification rules are automatically generated according to API anomaly feature variables, which can significantly improve the efficiency and accuracy of rule generation, reduce labor costs, and dynamically update and optimize rules to cope with changing environments. By comprehensively analyzing multi-dimensional anomaly features, the model can identify complex anomaly patterns, reduce false positives and false negatives, and improve the accuracy of anomaly detection. In addition, the automatically generated rules are structured and easy to expand, which is convenient for application in actual monitoring systems, promoting the intelligence and efficiency of API security detection.

[0075] In some embodiments, the API exception identification rules in the rule base include but are not limited to frequency exception identification rules, authentication exception identification rules, request pattern exception identification rules, parameter exception identification rules, response time exception identification rules, sensitive data access exception identification rules, and dependent service exception identification rules.

[0076] In some embodiments, the method of determining whether the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule may further include the following contents when the method is specifically implemented:

[0077] S1: Determine a first anomaly detection result according to the target API anomaly identification rule;

[0078] S2: Obtaining API access log data corresponding to the API call data; wherein the API access log data includes but is not limited to the access source, timestamp, request path, parameter content, response status code, IP address and device type of the API call data;

[0079] S3: determining access features and request features according to the API access log data, and determining a second anomaly detection result according to the access features and the request features;

[0080] S4: Determine whether there is an abnormality in the API call data according to the first abnormality detection result and the second abnormality detection result.

[0081] Among them, the above-mentioned access characteristics can be an access pattern that describes the API, including the frequency of requests, access source (such as IP address, geographic location), user identity (such as user ID, session ID), and access time (such as access time period, peak access period, etc.), which is used to determine whether there is an abnormal access pattern, such as high-frequency access of a certain IP or abnormal login behavior of a certain user.

[0082] The above request features can focus on specific API request content, such as request path (URL), request method (GET, POST, etc.), request parameters (such as query parameters, request body data), HTTP status code, response time, etc., to reveal whether the API call meets expectations and whether there are any abnormal situations such as request failure and timeout.

[0083] Among them, the above-mentioned first anomaly detection result may be an attribute of the target API anomaly identification rule itself.

[0084] In some embodiments, determining the first anomaly detection result according to the target API anomaly identification rule may include:

[0085] Determine the attribute characteristics of the target API according to the target API exception identification rule;

[0086] A first anomaly detection result is determined according to the intrinsic attribute characteristics of the target API.

[0087] Among them, the above-mentioned inherent attribute characteristics may refer to the static characteristics and dynamic characteristics inherent in the API itself. Specifically, the static characteristics include API name and path, request method, input parameters, permission scope and call restrictions, etc., and the dynamic characteristics include call frequency, response time, traffic pattern and data sensitivity, etc.

[0088] Based on the above embodiment, according to the target API anomaly identification rules, the first anomaly detection result is determined, and the access features and request features extracted from the API access log data are combined, and based on these features, it is judged whether the API call data is abnormal, thereby comprehensively covering multiple anomaly types, improving detection accuracy, and quickly responding to security threats.

[0089] In some embodiments, the method may further include the following when implemented:

[0090] When it is determined that an abnormality exists in the API call data by processing the call data of the target API according to the target API abnormality identification rule, an abnormality alarm reminder is sent according to the preset alarm rule and based on the preset notification method.

[0091] Specifically, according to the type, severity and impact scope of the abnormality, the corresponding preset alarm rules are matched, and then the abnormal alarm reminder is sent based on the preset notification method.

[0092] Among them, the above-mentioned alarm rules may include alarm levels (such as low, medium, high, and urgent) and alarm content templates (describing abnormal situations and possible causes); the above-mentioned preset notification methods may include email, SMS, instant messaging tools (such as Slack, Teams), system log push or dashboard display, etc. In addition, for high-priority alarms, multi-channel notifications can be triggered or automated response actions can be executed, such as temporarily limiting the source of abnormal requests, adjusting system resources, or automatically triggering analysis scripts, thereby effectively reducing risks and impacts.

[0093] In some embodiments, after sending an abnormal alarm reminder according to a preset alarm rule and based on a preset notification method, the specific implementation may also include:

[0094] According to the target API exception identification rule, a target modification policy matching the target API exception identification rule is retrieved from a preset modification policy library; wherein the preset modification policy library is determined according to historical modification policies.

[0095] The target modification strategy is returned to the user, so that the target user can make targeted modifications and adjustments according to the target modification strategy.

[0096] Based on the above embodiments, rapid response and timely processing can be achieved, which significantly reduces the cost of manual intervention, improves reliability and safety, and can immediately notify relevant personnel when an abnormality occurs, ensuring that the problem can be responded to and handled in a timely manner, avoiding greater losses or safety hazards caused by delays.

[0097] In some embodiments, the method may further include the following when implemented:

[0098] When it is determined that the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule, generating an access control policy for the API call data according to the target API abnormality identification rule;

[0099] According to the access control policy, access control processing is performed on the API call data.

[0100] The access control strategies mentioned above include limiting access to specific IP addresses or users, adjusting access frequency, enabling multi-factor authentication, adding permission verification steps, etc. Specific strategies will be dynamically generated based on the nature and severity of the anomaly. For example, if it is detected that abnormal high-frequency requests come from a single IP address, the system can temporarily block the IP address or enable stricter access verification measures.

[0101] Furthermore, the access control policy can be flexibly adjusted according to the business needs and security level of the API. For example, stricter identity authentication may be required for payment APIs, while more relaxed access permissions can be set for public interfaces. In addition, the access control policy can also be coordinated with other security mechanisms, such as intrusion detection systems (IDS) or firewall rules, to form a multi-level security protection system.

[0102] Based on the above embodiments, the generated access control policy can not only accurately respond to specific anomalies, but also enhance the security protection capabilities of the system and reduce potential attacks or abuses.

[0103] As can be seen from the above, an API data anomaly identification method provided by an embodiment of the present specification obtains the call data of the target API to be analyzed; according to the call data of the target API, retrieves the preset API anomaly identification rule library, and determines the matching target API anomaly identification rule; wherein the preset API anomaly identification rule library is pre-constructed by processing the historical API anomaly call data using a preset large language model; according to the target API anomaly identification rule, by processing the call data of the target API, it is determined whether the API call data has an anomaly. In this way, by using the preset large language model and processing the historical API anomaly call data, an API anomaly identification rule library for anomaly detection can be quickly and accurately constructed. Compared with the method of manually formulating rules, it has the advantages of high efficiency, high speed, wide coverage and flexibility, which reduces labor costs, and then through the API anomaly identification rules in the API anomaly identification rule library, the accuracy and efficiency of API call data anomaly identification can be improved.

[0104] See also Figure 2As shown, the embodiment of this specification also provides a specific electronic device, wherein the electronic device includes a network communication port 201, a processor 202 and a memory 203, and the above structures are connected through internal cables so that each structure can perform specific data interaction.

[0105] The network communication port 201 may be used to obtain the call data of the target API to be analyzed.

[0106] The processor 202 can be specifically used to retrieve a preset API exception identification rule base according to the call data of the target API, and determine a matching target API exception identification rule; wherein the preset API exception identification rule base is pre-constructed by processing historical API exception call data using a preset large language model; and determine whether the API call data has an exception by processing the call data of the target API according to the target API exception identification rule.

[0107] The memory 203 may be specifically used to store corresponding instruction programs.

[0108] Based on the above method, the relevant structural performance of the electronic device can be effectively utilized, the data processing speed of the electronic device can be improved, and the API data anomaly identification method can be efficiently implemented.

[0109] In this embodiment, the network communication port 201 can be a virtual port that is bound to different communication protocols so that different data can be sent or received. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. In addition, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM, CDMA, etc.; it can also be a Wifi chip; it can also be a Bluetooth chip.

[0110] In this embodiment, the processor 202 may be implemented in any appropriate manner. For example, the processor may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. This specification does not limit this.

[0111] In this embodiment, the memory 203 may include multiple levels. In a digital system, anything that can store binary data can be a memory; in an integrated circuit, a circuit with a storage function that has no physical form is also called a memory, such as RAM, FIFO, etc.; in a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0112] The embodiments of the present specification also provide a computer-readable storage medium based on the above-mentioned API data anomaly identification method, wherein the computer-readable storage medium stores computer program instructions, which, when executed, implement the following: obtaining the call data of the target API to be analyzed; retrieving a preset API anomaly identification rule library based on the call data of the target API, and determining a matching target API anomaly identification rule; wherein the preset API anomaly identification rule library is pre-constructed by processing historical API anomaly call data using a preset large language model; and determining whether the API call data has an anomaly by processing the call data of the target API according to the target API anomaly identification rule.

[0113] In this embodiment, the storage medium includes, but is not limited to, a random access memory (RAM), a read-only memory (ROM), a cache, a hard disk (HDD), or a memory card. The memory may be used to store computer program instructions. The network communication unit may be an interface for network connection communication set in accordance with the standard specified by the communication protocol.

[0114] In this embodiment, the functions and effects specifically implemented by the program instructions stored in the computer-readable storage medium can be explained in comparison with other implementations and will not be described in detail here.

[0115] See also Figure 3 At the software level, the embodiment of this specification also provides an API data anomaly identification device, which may specifically include the following structural modules:

[0116] The data acquisition module 301 is used to acquire the call data of the target API to be analyzed;

[0117] A rule determination module 302 is used to retrieve a preset API exception identification rule base according to the call data of the target API, and determine a matching target API exception identification rule; wherein the preset API exception identification rule base is pre-constructed by processing historical API exception call data using a preset large language model;

[0118] The abnormality judgment module 303 is used to determine whether there is an abnormality in the API call data by processing the call data of the target API according to the target API abnormality identification rule.

[0119] In some embodiments, during specific implementation, the device also includes: obtaining the historical API exception call data; a rule determination module, used to use the preset large language model to process the historical API exception call data to determine multiple preset API exception identification rules; based on the multiple preset API exception identification rules, construct the preset API exception identification rule library.

[0120] In some embodiments, the above-mentioned rule determination module, when implemented, performs feature extraction processing on the historical API exception call data to obtain corresponding API exception feature variables; utilizes the preset large language model, and determines multiple preset API exception identification rules based on the API exception feature variables.

[0121] In some embodiments, during specific implementation, the API exception identification rules in the rule base include but are not limited to frequency exception identification rules, identity authentication exception identification rules, request pattern exception identification rules, parameter exception identification rules, response time exception identification rules, sensitive data access exception identification rules, and dependent service exception identification rules.

[0122] In some embodiments, the above-mentioned exception judgment module 303, when implemented specifically, determines a first exception detection result according to the target API exception identification rule; obtains API access log data corresponding to the API call data; wherein the API access log data includes but is not limited to the access source, timestamp, request path, parameter content, response status code, IP address and device type of the API call data; determines access characteristics and request characteristics according to the API access log data, and determines a second exception detection result according to the access characteristics and the request characteristics; determines whether the API call data has an exception according to the first exception detection result and the second exception detection result.

[0123] In some embodiments, during specific implementation, the device also includes: when it is determined that there is an abnormality in the API call data by processing the call data of the target API according to the target API abnormality identification rule, sending an abnormal alarm reminder according to the preset alarm rules and based on the preset notification method.

[0124] In some embodiments, during specific implementation, the device also includes: when determining that there is an abnormality in the API call data by processing the call data of the target API according to the target API exception identification rule, generating an access control policy for the API call data according to the target API exception identification rule; and performing access control processing on the API call data according to the access control policy.

[0125] It should be noted that the units, devices or modules described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. For the convenience of description, the above devices are described separately by functions divided into various modules. Of course, when implementing this specification, the functions of each module can be implemented in the same or more software and / or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0126] As can be seen from the above, an API data anomaly identification device provided in an embodiment of this specification utilizes a preset large language model and processes historical API anomaly call data to quickly and accurately construct an API anomaly identification rule library for anomaly detection. Compared with the manual rule-making method, it has the advantages of high efficiency, high speed, wide coverage and flexibility, reduces labor costs, and further, through the API anomaly identification rules in the API anomaly identification rule library, the accuracy and efficiency of API call data anomaly identification can be improved.

[0127] In a specific scenario example, an API data anomaly identification method and device provided in this specification can be applied. By using a preset large language model and processing historical API abnormal call data, a preset API abnormality identification rule library can be quickly and accurately constructed, solving the problem of low efficiency and narrow coverage of identifying API data anomalies by manually formulating rules, and improving the accuracy and efficiency of API call data anomaly identification. The specific implementation process may include the following content.

[0128] As a communication bridge between different software applications, API (Application Programming Interface) plays a vital role in modern software development and system integration. However, with the widespread use of API, its security issues have become increasingly prominent. Security vulnerabilities in API interfaces may lead to the leakage of sensitive data, causing serious losses to enterprises and individuals.

[0129] In some embodiments, through technical means such as sensitive data identification, behavior analysis, real-time monitoring and alarm, sensitive data leakage or abnormal usage behavior that may exist in the API interface can be effectively discovered and handled.

[0130] Among them, the above-mentioned sensitive data identification can identify sensitive data transmitted in the API interface, such as ID card number, bank card number, passport number, etc. Specifically, regular expressions are used to match predefined sensitive data types. Machine learning models can be used to more intelligently identify sensitive data to improve the accuracy and efficiency of identification. It is also possible to register sensitive APIs during the development stage and manually enter sensitive APIs. Continuously update and optimize the sensitive data type library to adapt to new security threats and regulatory requirements.

[0131] The above-mentioned behavior analysis can be to analyze the transmission behavior of sensitive data in the API interface, establish a normal behavior model, and identify abnormal behavior. Specifically, vulnerability rules are established based on the interface access ratio, the number of sensitive data returned by the interface, the amount of data returned by the interface, IP, and other dimensions to warn of abnormal behavior risks. It is also possible to use the intelligent behavior analysis engine for continuous self-learning to improve the user behavior model. Through statistical analysis and machine learning algorithms, normal sensitive behaviors can be separated and abnormal sensitive data behavior risks can be accurately located.

[0132] The above-mentioned real-time monitoring and alarm technologies can monitor the data transmission in the API interface in real time, and trigger the alarm mechanism in time when abnormal behavior is found. Specifically, deploy real-time monitoring components to capture and analyze the data in the API interface in real time. Configure alarm rules, including alarm thresholds, alarm methods, etc. When abnormal behavior is detected, the alarm mechanism is triggered according to the configured alarm rules. Notify relevant personnel through email, SMS, message push, etc., and provide detailed abnormal behavior reports, including the type, time, source, scope of impact, etc. of the abnormal behavior, so that relevant personnel can handle it in time.

[0133] In some embodiments, see Figure 4As shown, based on manual entry of sensitive APIs and flow detection of sensitive APIs, real-time monitoring of sensitive APIs is performed, and the preset large language model is used to process the historical API abnormal call data to determine multiple preset API abnormality identification rules. In fact, the API abnormality identification rules include abnormal increase in interface access ratio, excessive number of sensitive data returned in a single request, excessive amount of data returned in a single request, large amount of data pulled by overseas IP, abnormal number of visits per unit time, abnormal number of page turning / parameter traversal requests per unit time, etc. Further, the vulnerability rules (i.e., API abnormality identification rules) can be adjusted according to the warning situation. In addition, new rules can be added according to the latest threat intelligence to achieve continuous monitoring and early warning.

[0134] In some embodiments, for sensitive data identification and monitoring, keyword identification, regular expressions, file fingerprints, semantic analysis and other technologies can also be used to identify sensitive data. The system has built-in sensitive information identification rules and supports online upgrades and updates to adapt to the ever-changing sensitive data environment. Among them, the sensitive data identification and monitoring can clearly define the scope of sensitive data, such as personal information, commercial sensitive information, financial information, etc. Sensitive data is classified and managed to facilitate subsequent monitoring and analysis.

[0135] In some embodiments, for API behavior monitoring and analysis, it is necessary to fully record the API access log, including request time, requester, request parameters, response results, etc., to achieve comprehensive tracking and backtracking of API access behavior. Through built-in abnormal behavior detection models such as high-frequency access, non-working hours access, excessive downloading of sensitive data, etc. By correlating and analyzing business access logs and sensitive logs, abnormal API access behaviors such as abnormal high-frequency access, batch downloading of files, and batch crawling of sensitive data are discovered.

[0136] In some embodiments, for risk warning and response, a risk warning threshold can be set, and when the API access behavior triggers the warning condition, a risk warning is issued in time. Provide a risk warning report, record the warning information, triggering conditions, recommended measures, etc. in detail. You can also establish a complete emergency response mechanism to ensure that you can respond and deal with API security risks quickly when they occur. Provide emergency response tools and resources, such as emergency response plans, safety isolation measures, etc.

[0137] In some embodiments, for security policies and refined management, API access security policies can be formulated according to business needs and security requirements. This includes allowing or prohibiting specific methods and parameters, client management, etc. It supports fine-grained management of APIs, such as setting blacklists and whitelists based on information such as IP addresses and user IDs. It provides API access rights management, traffic control and other functions to enhance API security.

[0138] In some embodiments, for continuous monitoring and optimization, the access behavior and security status of the API can be monitored and evaluated regularly. Potential security risks and issues can be discovered and handled in a timely manner. Based on the monitoring results and security requirements, the security policies and monitoring measures of the API can be continuously optimized and improved. New security technologies and tools can be introduced to enhance the security protection capabilities of the API.

[0139] Through the above embodiments, the security of API data can be protected and security incidents such as data leakage and tampering can be prevented. By timely identifying and handling abnormal behaviors, the risk of data leakage can be effectively reduced; further, it can also be used to monitor the compliance of API traffic. By analyzing API traffic, it can ensure that the use of API complies with relevant laws, regulations and standards, such as GDPR, HIPAA, etc.; in addition, abnormal API usage patterns may indicate potential security threats and may also affect the stability of the API system. By timely identifying and handling these abnormal patterns, the stability and availability of the API system can be maintained.

[0140] Although the present specification provides method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps, and does not represent a unique execution order. When the device or client product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, product or device. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or device including the elements. The first, second, etc. words are used to represent the name, and do not represent any particular order.

[0141] Those skilled in the art also know that, in addition to implementing the controller in a purely computer-readable program code, the controller can be made to implement the same function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the devices for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules for implementing the method and structures within the hardware component.

[0142] Through the description of the above embodiments, it can be known that those skilled in the art can clearly understand that the present specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present specification can essentially be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a mobile terminal, a server, or a network device, etc.) to execute the methods described in each embodiment of the present specification or some parts of the embodiments.

[0143] Although the present specification is described through embodiments, those skilled in the art will appreciate that there are many modifications and changes to the present specification without departing from the spirit of the present specification, and it is intended that the appended claims include these modifications and changes without departing from the spirit of the present specification.

Claims

1. A method for identifying API data anomalies, characterized in that: include: Get the call data of the target API to be analyzed; According to the call data of the target API, a preset API exception identification rule library is retrieved to determine a matching target API exception identification rule; wherein the preset API exception identification rule library is pre-constructed by processing historical API exception call data using a preset large language model; By processing the call data of the target API according to the target API exception identification rule, it is determined whether the API call data has an exception.

2. The method according to claim 1, characterized in that The method further comprises: Obtain the historical API exception call data; Determine a plurality of preset API anomaly identification rules by processing the historical API anomaly call data using the preset large language model; According to the plurality of preset API anomaly identification rules, the preset API anomaly identification rule library is constructed.

3. The method according to claim 2, characterized in that The method of using the preset large language model to process the historical API exception call data to determine a plurality of preset API exception identification rules includes: Perform feature extraction processing on the historical API abnormal call data to obtain corresponding API abnormal feature variables; The preset large language model is utilized to determine a plurality of preset API anomaly identification rules according to the API anomaly feature variables.

4. The method according to claim 3, characterized in that The API anomaly identification rules in the rule base include but are not limited to frequency anomaly identification rules, identity authentication anomaly identification rules, request pattern anomaly identification rules, parameter anomaly identification rules, response time anomaly identification rules, sensitive data access anomaly identification rules and dependent service anomaly identification rules.

5. The method according to claim 1, characterized in that The determining whether the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule includes: Determine a first anomaly detection result according to the target API anomaly identification rule; Obtaining API access log data corresponding to the API call data; wherein the API access log data includes but is not limited to the access source, timestamp, request path, parameter content, response status code, IP address, and device type of the API call data; Determine access characteristics and request characteristics according to the API access log data, and determine a second anomaly detection result according to the access characteristics and the request characteristics; Determine whether the API call data has an abnormality according to the first abnormality detection result and the second abnormality detection result.

6. The method according to claim 1, characterized in that The method further comprises: When it is determined that an abnormality exists in the API call data by processing the call data of the target API according to the target API abnormality identification rule, an abnormality alarm reminder is sent according to the preset alarm rule and based on the preset notification method.

7. The method according to claim 6, characterized in that The method further comprises: When it is determined that the API call data is abnormal by processing the call data of the target API according to the target API abnormality identification rule, generating an access control policy for the API call data according to the target API abnormality identification rule; According to the access control policy, access control processing is performed on the API call data.

8. An API data anomaly identification device, characterized in that: include: A data acquisition module is used to obtain the call data of the target API to be analyzed; A rule determination module, used to retrieve a preset API exception identification rule library according to the call data of the target API, and determine a matching target API exception identification rule; wherein the preset API exception identification rule library is pre-constructed by processing historical API exception call data using a preset large language model; The abnormality judgment module is used to determine whether there is an abnormality in the API call data by processing the call data of the target API according to the target API abnormality identification rule.

9. An electronic device, characterized in that: It comprises a processor and a memory for storing processor executable instructions, and when the processor executes the instructions, the steps of the API data anomaly identification method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the instructions are executed by a processor, the steps of the API data anomaly identification method described in any one of claims 1 to 7 are implemented.

Images