System and method for implementing API call security protection based on API gateway

Abstract

The application discloses an API calling security protection implementation system and method based on an API gateway. The system comprises an API management module, an API caller management module, an API request message detection module, a self-learning engine rule module, an API authorization / authentication module and a log management module. In view of the problem that the API gateway has insufficient protection capability when facing increasingly complex network security threats, the application intercepts malicious requests by detecting API access requests in real time, verifies API callers by adopting a dual-identity authentication mechanism of IP addresses and authorization credentials, and discriminates abnormal access behaviors based on the access behavior baseline of the API callers, so that the overall security protection capability of the API gateway is effectively enhanced.

Description

Technical Field

[0001] This invention belongs to the field of computer program data interaction technology, specifically relating to an API call security protection system and method based on an API gateway. Background Technology

[0002] With the development and popularization of internet technology, more and more application systems are utilizing Application Programming Interfaces (APIs) to provide and access various services and data. APIs, as bridges connecting different systems and applications, play a crucial role in improving the scalability and flexibility of software systems. However, with the widespread use of APIs, the amount of data transmitted and interacted via APIs is growing rapidly, posing significant challenges to API security. In recent years, numerous data security incidents have occurred both domestically and internationally due to malicious attacks on APIs or lax security management, highlighting the increasing importance of API security protection.

[0003] As a core component for managing API calls, the API gateway primarily provides a unified entry point and access authentication, and offers functions such as traffic management, protocol conversion, load balancing, rate limiting, caching, monitoring, and logging. While the API gateway provides basic security measures such as authentication and authorization, rate limiting and traffic control, logging, and monitoring, thus ensuring basic security for API calls to a certain extent, its security capabilities fall short in the face of increasingly complex and diverse attack methods, such as Structured Query Language (SQL) injection, Cross-site scripting (XSS), and other common web application attacks—all common security threats to API calls. Summary of the Invention

[0004] To address the issue of insufficient security protection capabilities of API gateways in the face of increasingly complex network security threats, this invention provides a system and method for API call security protection based on API gateways. Through a multi-layered security protection mechanism, it dynamically detects and defends against various API call security threats, thereby improving the security and reliability of API calls.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] In a first aspect, the present invention provides an API call security protection system based on an API gateway, the system comprising:

[0007] The API management module is used to manage APIs published by API providers to the API gateway;

[0008] The API caller management module is used to generate API caller identifier IDs in response to the Internet Protocol (IP) address registration operation of API callers.

[0009] The API authorization / authentication module is used to assign the target API access key ID (AK) and private access key (SK) to the API caller according to the scope of the requested access permission after receiving the API caller's API call permission request.

[0010] The API request message detection module is used to monitor API access requests sent by the API caller in real time. The API access request includes a Hypertext Transfer Protocol (HTTP) request message and a signature string. The HTTP request message contains the AK of the target API. The signature string is generated by the SK of the target API based on the HTTP request message and the AK of the target API.

[0011] The API request message detection module is also used to detect the content of the HTTP request message when the API access request is detected to arrive, and to allow the API access request if the content of the HTTP request message is normal.

[0012] The API authorization / authentication module is also used to generate an authentication string based on the SK corresponding to the AK in the HTTP request message and the corresponding authentication mechanism after receiving the API access request, compare the authentication string with the signature string, and authorize the API caller to access the target API if the authentication string is the same as the signature string.

[0013] The self-learning engine rules module is used for:

[0014] Based on the identifier ID, determine whether the API caller is accessing the API for the first time through the API gateway;

[0015] If the API caller accesses the API for the first time through the API gateway, the system determines whether the API access request is a normal request based on a preset self-learning behavior detection engine; if the API caller is not accessing the API for the first time through the API gateway, the system determines whether the API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller.

[0016] If the API access request is determined to be a normal request, the API access request is forwarded to the target API endpoint, and the requested data is returned to the API caller.

[0017] The log management module is used to record API access logs; the API access logs include the API caller, the target API, and the request method, request parameters, and request source IP address corresponding to the API access request;

[0018] The self-learning behavior detection engine corresponding to the API caller is established by continuously learning the normal behavior pattern of the API caller through machine learning methods; the normal behavior pattern of the API caller is obtained based on the API access logs corresponding to the API caller.

[0019] Secondly, the present invention provides a method for implementing API call security protection based on an API gateway, applied to the aforementioned API call security protection system based on an API gateway, the method comprising:

[0020] In response to the API caller's IP address registration operation, an API caller identifier ID is generated;

[0021] Receive the API call permission request sent by the API caller, and assign the target API access key identifier AK and private access key SK to the API caller according to the requested permission scope;

[0022] The API access requests sent by the API caller are monitored in real time; the API access request includes an HTTP request message and a signature string; the HTTP request message contains the AK of the target API; the signature string is generated by the SK of the target API based on the HTTP request message and the AK of the target API;

[0023] When the arrival of the API access request is detected, the content of the HTTP request message is inspected. If the content of the HTTP request message is found to be normal, the API access request is received.

[0024] An authentication string is generated based on the SK corresponding to the AK in the HTTP request message and the corresponding authentication mechanism. The authentication string is compared with the signature string. If the authentication string and the signature string are the same, the API caller is granted access to the target API.

[0025] Based on the identifier ID, determine whether the API caller is accessing the API for the first time through the API gateway; if the API caller is accessing the API for the first time through the API gateway, determine whether the API access request is a normal request based on the preset self-learning behavior detection engine; if the API caller is not accessing the API for the first time through the API gateway, determine whether the API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller.

[0026] If the API access request is determined to be a normal request, the API access request is forwarded to the target API endpoint, and the requested data is returned to the API caller.

[0027] Record API access logs; the API access logs include the API caller, the target API, and the request method, request parameters, and request source IP address corresponding to the API access request.

[0028] The self-learning behavior detection engine corresponding to the API caller is established by continuously learning the normal behavior pattern of the API caller through machine learning methods; the normal behavior pattern of the API caller is obtained based on the API access logs corresponding to the API caller.

[0029] The beneficial effects of this invention are as follows:

[0030] This invention enhances the security protection capabilities of API gateways in the following three aspects:

[0031] 1. It can detect HTTP request data packets of API access in real time and block malicious requests such as SQL injection and cross-site scripting attacks.

[0032] 2. It can perform dual authentication of API callers using both IP address and authorization credentials, ensuring the security and trustworthiness of API callers.

[0033] 3. By using machine learning methods to establish a baseline of API caller access behavior, abnormal call behavior can be monitored and intercepted in real time. Attached Figure Description

[0034] Figure 1 This is an architectural diagram of the API call security protection system based on an API gateway according to the present invention.

[0035] Figure 2 This is a flowchart of the API call security protection implementation method based on API gateway of the present invention.

[0036] Figure 3 This is a schematic diagram of the workflow of the self-learning engine rule module according to an embodiment of the present invention. Detailed Implementation

[0037] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0038] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0039] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0040] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0041] Furthermore, to better illustrate the present invention, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that the present invention can be practiced without certain specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order to highlight the spirit of the invention.

[0042] Figure 1 This diagram illustrates the architecture of the API call security protection system based on an API gateway according to the present invention. The system is located within the API gateway, such as... Figure 1 As shown, the system includes an API management module, an API caller management module, an API authorization / authentication module, an API request message detection module, a self-learning engine rules module, and a log management module.

[0043] The API management module is used to manage APIs published by API providers to the API gateway, and to set policies such as traffic management, protocol conversion, load balancing, rate limiting, caching, and monitoring for the APIs.

[0044] The API caller management module is used to manage the identity of API callers. Unlike traditional API gateways that only verify the legitimacy of API callers through credentials, API callers should register their IP address information with the API caller management module before initiating an access request for the corresponding API. By restricting API access to the registered IP address range, it ensures that only trusted API callers can access the APIs managed in the API gateway.

[0045] The API authorization / authentication module, on the one hand, authorizes access permissions for the corresponding API based on the API access request of the API caller; on the other hand, it implements dual authentication of IP address + authorization credential when the API caller initiates the access request for the corresponding API.

[0046] The API request message detection module is used to monitor and intercept malicious requests in real time when API access requests arrive at the API gateway. It analyzes and verifies the HTTP message content of each API access request, effectively preventing malicious attacks such as SQL injection and cross-site scripting attacks, thereby ensuring the security of API calls.

[0047] The self-learning engine rules module continuously learns the normal behavioral patterns of API callers through machine learning methods, establishing a self-learning behavior detection engine for each API caller. This module uses machine learning to continuously learn from API access logs, forming a baseline for each API caller's access behavior to determine if there are any anomalies in API access requests. When an API caller's behavior deviates from the baseline, alerts are issued and the call is blocked.

[0048] The log management module records API access logs, including API caller, target API, request method, request parameters, request source IP address, etc., which serve as input for the machine learning algorithm in the self-learning engine rules module.

[0049] Figure 2 The flowchart illustrates the API call security protection implementation method based on an API gateway according to the present invention. This method is applied to the aforementioned API call security protection implementation system based on an API gateway, such as... Figure 2 As shown, the method includes:

[0050] Step 1: The API caller management module responds to the API caller's IP address registration operation and generates an API caller identifier ID.

[0051] API caller (i.e.) Figure 2 In this context, "API caller" refers to the application system that calls the API through the API gateway. Before calling the API, the API caller needs to register its IP address information with the API gateway's API caller management module to obtain an API caller identifier ID. The API gateway uses this identifier ID to manage the API caller's access permissions and monitor the call process.

[0052] Step 2: After receiving the API call permission request sent by the API caller, the API authorization / authentication module assigns the AK and SK of the target API (i.e. the API that the API caller requests to call) to the API caller according to the scope of the requested permission.

[0053] An API caller submits a request for access to the target API to the API gateway. After the API provider reviews and approves the request, the API authorization / authentication module assigns the corresponding AK / SK to the API caller based on the requested access scope. Here, AK stands for Access Key ID, used to identify the API caller; SK stands for Secret Access Key, used to encrypt the signature string and verify the authentication string, and must be properly stored to prevent leakage.

[0054] Step 3: The API request message detection module monitors the API access request (i.e., API call request) sent by the API caller in real time; the API access request includes an HTTP request message and a signature string; the HTTP request message contains the AK of the target API; the signature string is generated by the SK of the target API based on the HTTP request message and the AK of the target API.

[0055] The API caller constructs an HTTP request message containing an Access Key ID. The Secret Access Key calculates a signature string based on the HTTP request message content and the Access Key ID, and then sends both to the API gateway.

[0056] Step 4: When the API request message detection module detects the arrival of the API access request, it detects the content of the HTTP request message. If the content of the HTTP request message is normal, the API access request is accepted; if the HTTP request message contains attack information, the API access request is blocked and an error code is returned.

[0057] The API gateway's API request message detection module intercepts API access requests initiated by API callers and inspects the content of the HTTP request message. If it identifies attacks such as SQL injection, cross-site scripting, or command / code injection within the message, it blocks the API access request and returns an error code; if the request message content appears normal, it allows the API access request.

[0058] Step 5: The API authorization / authentication module generates an authentication string based on the SK corresponding to the AK in the HTTP request message and the corresponding authentication mechanism. The authentication string is compared with the signature string. If the authentication string and the signature string are the same, the API caller is granted access permission (i.e., call permission) to the target API. If the authentication string and the signature string are different, the API access request is ignored and an error code is returned.

[0059] Upon receiving an API access request, the API gateway's authorization / authentication module calculates an authentication string using the same Secret Access Key and authentication mechanism as the Access Key ID in the request message, and compares it with the signature string included in the API access request. If the authentication string matches the signature string, the API caller is considered to have access to the corresponding API, and access to the corresponding API is authorized to the API caller; if the authentication string differs from the signature string, the operation is ignored and an error code is returned.

[0060] Step 6: The self-learning engine rules module determines whether the API caller is accessing the API for the first time through the API gateway based on the identifier ID. If the API caller is accessing the API for the first time through the API gateway, it determines whether the API access request is a normal request based on the preset self-learning behavior detection engine. If the API caller is not accessing the API for the first time through the API gateway, it determines whether the API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller. If the API access request is determined to be an abnormal request, the API access request is rejected and an error code is returned.

[0061] The self-learning engine rules module identifies the API caller based on the identifier ID. Based on the information corresponding to that identifier ID in the API caller management module, it can determine whether the API caller is accessing the API for the first time through the API gateway. If the API caller is accessing the API for the first time through the API gateway, the pre-defined self-learning behavior detection engine determines whether the API access request is legitimate. The pre-defined self-learning behavior detection is established based on default rules. If the API caller is not accessing the API for the first time, the system uses the API caller's access behavior baseline to determine whether the current access request is a normal request. If it is normal, the API access request is allowed; if it deviates significantly from the access behavior baseline, it is judged as abnormal, the API access request is rejected, and an error code is returned.

[0062] Step 7: If the self-learning engine rules module determines that the API access request is a normal request, forward the API access request to the target API endpoint and return the request data to the API caller.

[0063] After the above steps, if the API access request initiated by the API caller is detected as a normal request, the API gateway will forward the API access request to the corresponding API endpoint in the backend (i.e., the target API endpoint) and return the requested data to the API caller. The log management module records the access behavior log of this API call, including the API caller, the target API, and the request method, request parameters, and request source IP address of the API access request.

[0064] The self-learning behavior detection engine corresponding to the API caller is established by continuously learning the normal behavior pattern of the API caller through machine learning methods; the normal behavior pattern of the API caller is obtained based on the API access logs corresponding to the API caller.

[0065] For example, the training process of the self-learning behavior detection engine corresponding to the API caller includes:

[0066] (1) Obtain the historical API access log data corresponding to the API caller and perform data processing;

[0067] (2) Based on the processed historical API access log data, a time series prediction model is constructed and anomaly thresholds are obtained;

[0068] (3) Based on the processed historical API access log data, construct the first anomaly detection model based on probability density and obtain the historical anomaly score for each data point;

[0069] (4) Based on the processed historical API access log data and the historical anomaly scores, perform time series feature engineering to obtain the training dataset;

[0070] (5) Construct a clustering model, divide the data in the training dataset into k classes according to the clustering model, and determine the cluster center of each class;

[0071] (6) Construct k supervised anomaly detection models and train the k supervised anomaly detection models according to the k types of data respectively.

[0072] For example, determining whether an API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller includes:

[0073] (1) Obtain the new API access log data corresponding to the API caller and perform data processing;

[0074] (2) Using the time-series prediction model, predict the API call frequency of the API caller based on the new API access log data, and compare the predicted API call frequency with the abnormal threshold to obtain a first judgment result based on the comparison result;

[0075] (3) Using the processed new API access log data, construct a second anomaly detection model based on probability density to obtain a new anomaly score for each data point;

[0076] (4) Based on the processed new API access log data and the new anomaly score, perform time series feature engineering to obtain the prediction dataset;

[0077] (5) Use the clustering model to predict the cluster centers of the data in the prediction dataset;

[0078] (6) Based on the predicted cluster center, determine the corresponding supervised anomaly detection model from the k supervised anomaly detection models, and use the corresponding supervised anomaly detection model to make a prediction based on the prediction dataset to obtain the second judgment result;

[0079] (7) The first judgment result and the second judgment result are comprehensively evaluated to obtain the final judgment result.

[0080] The first and second judgment results include normal and abnormal results; a normal result indicates that the API access request is a normal request; an abnormal result indicates that the API access request is an abnormal request. If at least one of the first and second judgment results is abnormal, the final judgment result is an abnormal result.

[0081] For example, after manual verification, the final judgment result and its corresponding new API access log data are fed back to the database to update the historical API access log data, so that the self-learning behavior detection engine can continue to learn.

[0082] The API call security protection method of this invention registers API callers before the call, authorizes them, and issues access credentials. During the call, the API request message content is detected by the API request message detection module, the API caller's behavior is identified as normal by the self-learning engine rule module, the API authorization / authentication module is identified as having the necessary access permissions for the API access request, and finally, the log management module records all API call access behavior logs and feeds them back to the database for model self-learning. This invention solves the problem of insufficient protection capabilities of API gateways when facing increasingly complex network security threats by using real-time detection of API access request data packets, dual authentication of IP address and authorization credentials, and real-time monitoring of API caller access behavior by a self-learning behavior detection engine.

[0083] The self-learning engine rules module will be described in detail below with reference to the accompanying drawings and embodiments.

[0084] Figure 3 The self-learning engine rule module of this invention, as shown in an embodiment, is based on API caller behavior data (i.e., API access log data). It uses machine learning algorithms to detect API caller behavior in real time and utilizes data feedback to achieve continuous learning of the machine learning model. Figure 3 As shown, the self-learning engine rules module includes an offline training module and an online prediction module. The offline training module illustrates the training process of the self-learning behavior detection engine, and the online prediction module illustrates the prediction process of the self-learning behavior detection engine (i.e., the process of using the self-learning behavior detection engine to determine whether an API access request is a normal request). The training and prediction processes include:

[0085] Step 1, Data Processing:

[0086] Step 101: Data Acquisition. Acquire API access log data (historical API access log data during the training phase, and new API access log data during the prediction phase), including API caller ID, API endpoint, request time, request method, request parameters, request source IP address, and call frequency. The API caller ID and request source IP address serve as unique identifiers for recording abnormal users and are not used as features.

[0087] Step 102: Data Cleaning. Clean the API access log data, including removing outliers and missing values, for use in subsequent modeling.

[0088] Step 103, Feature Encoding. Label the API endpoint and request method features. Perform vector encoding on the request parameter features using a deep learning pre-trained model.

[0089] Step 2, Time Series Prediction Model:

[0090] Based on the cleaned data from Step 1, a time-series forecasting model is constructed. An initial anomaly threshold is empirically set according to business scenario characteristics and historical data statistics. During actual operation, a dynamic threshold adjustment mechanism is established based on the model's forecasting performance (such as false positive and false negative rates) and the latest changes in data distribution. This mechanism periodically or trigger-based optimization and calibration of the anomaly threshold ensures that it always accurately and adaptively reflects the normal state. In the forecasting phase, the time-series forecasting model predicts new time series and compares them with the anomaly threshold to initially determine whether API access requests are abnormal. The specific implementation steps are as follows:

[0091] Step 201: Time Series Data Feature Engineering. Process the API access log data that needs to be used for time-series prediction. For each metric, store five columns in a CSV file: 'ds', 'y', 'endpoint', 'method', and 'parameter'. The first column represents the timestamp of the time series; the second column represents the value of the time series, i.e., the call frequency. The remaining columns are external variables, representing the API endpoint, request method, and request parameters, respectively. This completes the construction of a time series dataset suitable for time series model training and prediction.

[0092] Step 202: Construct a time series prediction model. The time series data obtained from the time series data feature engineering in the previous step is used to construct the training data for the time series model. Holidays within the time range of this time series are recorded, and the time series prediction model is constructed based on this data.

[0093] Step 203: Predict call frequency and identify anomalies. In the prediction phase, the time-series prediction model predicts the call frequency and anomaly threshold for a future period. Based on the new API access log data, an actual time-series dataset for prediction is constructed. By comparing the actual data with the prediction results and the anomaly threshold, when the actual frequency data points of API calls consistently and significantly fall outside the anomaly threshold range, it is considered a call anomaly.

[0094] Step 3: Anomaly detection based on probability density:

[0095] Based on the cleaned data from step 1, a probability density-based anomaly detection model is constructed to obtain an anomaly score for each data point. The specific implementation steps are as follows:

[0096] Step 301: During the training phase, the historical API access log data is fitted using a probability density-based kernel density estimation method to obtain the probability density of the data, i.e., the historical anomaly score of the data, which is used as a feature for modeling in subsequent steps.

[0097] Step 302: In the prediction phase, the new API access log data is fitted using the probability density-based kernel density estimation method to obtain the probability density of the data, i.e., the new anomaly score of the data, which is used as a feature for model prediction in subsequent steps.

[0098] Step 4: Temporal model feature engineering:

[0099] The data processing results from step 1 are combined with the anomaly scores obtained in step 3 to perform time series feature engineering, resulting in a dataset suitable for model training and prediction, thus constructing a machine learning model. The specific implementation steps are as follows:

[0100] Step 401: Extract statistical features based on the access frequency in the API access log data.

[0101] (1) Extract rolling statistics: Calculate statistics within the time window, such as mean, median, standard deviation, minimum and maximum.

[0102] (2) Extracting lagged features: Create past values ​​of the time series as new features to reveal the autocorrelation properties of the series. Use data from the previous minute (lagged 1) or the previous hour (lagged 60) as features to predict the current value.

[0103] (3) Extract the difference: Calculate the first difference of the time series (i.e., the difference between the current value and the previous value).

[0104] (4) Calculate window function statistics: Use sliding window operation to calculate moving average and exponential smoothing value.

[0105] Step 402, Feature Selection. Features that contribute to the model are selected based on the recursive feature elimination method.

[0106] Step 403: Fuse the selected feature results from the previous step with the new anomaly score features obtained in step 3 to obtain the complete dataset for the model.

[0107] Step 5: Construct a clustering model:

[0108] Based on the dataset obtained in step 4, a clustering model can be constructed to group similar time series into one class and dissimilar time series into another. The specific implementation steps are as follows:

[0109] Step 501: Construct the DBSCAN model and use the DBSCAN model to classify the dataset obtained in Step 4, determine the number of cluster centers k, that is, determine the cluster center ID corresponding to each class of data.

[0110] Step 502: During the training phase, the data in the dataset is split into k parts according to the cluster center ID (i.e., Figure 3 Clusters 1 to k in the model are used to build anomaly detection models.

[0111] Step 503: Prediction phase. Predict the cluster center ID corresponding to the new API access log data based on the new data, so that it can be used in subsequent steps to select an anomaly detection model.

[0112] Step 6: Construct a supervised anomaly detection model:

[0113] Based on the classification results obtained in step 5, the dataset obtained in step 4 is divided into corresponding datasets, and then supervised anomaly detection models are trained for each dataset. During the prediction phase, new time series are assigned to the corresponding class, and then anomaly detection algorithms for that class are used for anomaly detection. The specific implementation steps are as follows:

[0114] Step 601: In the training phase, construct k supervised anomaly detection models. Use the k data obtained in step 5 as training data to train the k supervised anomaly detection models respectively. Bind each supervised anomaly detection model to the cluster center ID corresponding to its training data for selection in the prediction phase.

[0115] Step 602: Prediction phase. Based on the cluster center ID predicted in step 5, select the corresponding supervised anomaly detection model to predict whether the API access request is abnormal.

[0116] Step 7, Anomaly Detection:

[0117] The final prediction result is obtained by comprehensively evaluating the results predicted by the anomaly detection model in step 6 and the time series prediction model in step 2. The specific implementation steps are as follows:

[0118] Step 701: Based on the judgment results of whether the time series prediction model in Step 2 and the supervised anomaly detection model in Step 6, the final judgment result is obtained. The judgment rule is: as long as an abnormal result occurs, the final judgment result is abnormal (that is, the final judgment result is normal only when the judgment results obtained by the time series prediction model in Step 2 and the supervised anomaly detection model in Step 6 are both normal).

[0119] Step 702: Manual Review. Output the final judgment result and conduct a manual review, recording whether it is a genuine anomaly. If the prediction is incorrect, correct it manually.

[0120] Step 8, Data Feedback:

[0121] After manual verification, the abnormal results detected by the model are fed back into the database for the offline model to continue learning.

[0122] The final anomaly detection results recorded in step 7 after manual review are fed back into the historical API access log data along with the corresponding API access log data for use in subsequent incremental model training.

[0123] The self-learning engine rule module of this invention cleans API access log data, constructs time-series model feature engineering and clustering models; it detects user access behavior using probability density anomaly detection and supervised anomaly detection methods to determine whether the access behavior is abnormal; simultaneously, the anomaly detection results data, after manual verification, are fed back to the database for continuous learning by the offline model. This invention utilizes machine learning methods to establish a baseline of API caller access behavior, enabling real-time monitoring and interception of abnormal call behavior.

[0124] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0125] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. The above descriptions are exemplary and not exhaustive. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A system for protecting API calls based on an API gateway, characterized in that, The system includes: The API management module is used to manage APIs published by API providers to the API gateway; The API caller management module is used to generate API caller identifier IDs in response to the IP address registration operation of API callers; The API authorization / authentication module is used to assign the target API access key identifier AK and private access key SK to the API caller according to the scope of the requested access permission after receiving the API caller's API call permission request; The API request message detection module is used to monitor API access requests sent by the API caller in real time; the API access request includes an HTTP request message and a signature string; the HTTP request message contains the AK of the target API; the signature string is generated by the SK of the target API based on the HTTP request message and the AK of the target API; The API request message detection module is also used to detect the content of the HTTP request message when the API access request is detected to arrive, and to allow the API access request if the content of the HTTP request message is normal. The API authorization / authentication module is also used to generate an authentication string based on the SK corresponding to the AK in the HTTP request message and the corresponding authentication mechanism after receiving the API access request, compare the authentication string with the signature string, and authorize the API caller to access the target API if the authentication string is the same as the signature string. The self-learning engine rules module is used for: Based on the identifier ID, determine whether the API caller is accessing the API for the first time through the API gateway; If the API caller accesses the API for the first time through the API gateway, the system determines whether the API access request is a normal request based on a preset self-learning behavior detection engine; if the API caller is not accessing the API for the first time through the API gateway, the system determines whether the API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller. If the API access request is determined to be a normal request, the API access request is forwarded to the target API endpoint, and the requested data is returned to the API caller. The log management module is used to record API access logs; the API access logs include the API caller, the target API, and the request method, request parameters, and request source IP address corresponding to the API access request; The self-learning behavior detection engine corresponding to the API caller is established by continuously learning the normal behavior pattern of the API caller through machine learning methods; the normal behavior pattern of the API caller is obtained based on the API access logs corresponding to the API caller.

2. The system according to claim 1, characterized in that, The API request message detection module is also used to block the API access request and return an error code if it detects that the HTTP request message contains attack information.

3. The system according to claim 1, characterized in that, The API authorization / authentication module is also used to ignore the API access request and return an error code if the authentication string is different from the signature string.

4. The system according to claim 1, characterized in that, The self-learning engine rules module is also used to reject the API access request and return an error code if it determines that the API access request is an abnormal request.

5. The system according to claim 1, characterized in that, The training process of the self-learning behavior detection engine corresponding to the API caller includes: Obtain and process the historical API access log data corresponding to the API caller. Based on the processed historical API access log data, a time-series prediction model is constructed, and anomaly thresholds are obtained; Based on the processed historical API access log data, a first anomaly detection model based on probability density is constructed to obtain the historical anomaly score for each data point. Based on the processed historical API access log data and the historical anomaly scores, time series feature engineering is performed to obtain the training dataset. Construct a clustering model, divide the data in the training dataset into k classes based on the clustering model, and determine the cluster center of each class; Construct k supervised anomaly detection models, and train the k supervised anomaly detection models respectively based on the k types of data.

6. The system according to claim 5, characterized in that, Based on the self-learning behavior detection engine corresponding to the API caller, it is determined whether the API access request is a normal request, including: Obtain the new API access log data corresponding to the API caller and process the data. Using the time-series prediction model, the API call frequency of the API caller is predicted based on the new API access log data, and the predicted API call frequency is compared with the anomaly threshold. A first judgment result is obtained based on the comparison result. Using the processed new API access log data, a second anomaly detection model based on probability density is constructed to obtain a new anomaly score for each data point; Based on the processed new API access log data and the new anomaly score, time series feature engineering is performed to obtain the prediction dataset. The clustering model is used to predict the cluster centers of the data in the prediction dataset; Based on the predicted cluster centers, a corresponding supervised anomaly detection model is determined from the k supervised anomaly detection models. Using the corresponding supervised anomaly detection model, a prediction is made based on the prediction dataset to obtain a second judgment result. The first judgment result and the second judgment result are comprehensively evaluated to obtain the final judgment result.

7. The system according to claim 6, characterized in that, The first and second judgment results include normal and abnormal results; a normal result indicates that the API access request is a normal request; An abnormal result indicates that the API access request is an abnormal request; The first judgment result and the second judgment result are comprehensively evaluated to obtain the final judgment result, including: If at least one of the first and second judgment results is abnormal, the final judgment result is abnormal.

8. The system according to claim 7, characterized in that, After the final judgment result is manually verified, the final judgment result and its corresponding new API access log data are fed back to the database for the self-learning behavior detection engine to continuously learn.

9. A method for implementing API call security protection based on an API gateway, applied to the API call security protection system based on an API gateway as described in any one of claims 1-8, characterized in that, The method includes: In response to the API caller's IP address registration operation, an API caller identifier ID is generated; Receive the API call permission request sent by the API caller, and assign the target API access key identifier AK and private access key SK to the API caller according to the requested permission scope; The API access requests sent by the API caller are monitored in real time; the API access request includes an HTTP request message and a signature string; the HTTP request message contains the AK of the target API; the signature string is generated by the SK of the target API based on the HTTP request message and the AK of the target API; When the arrival of the API access request is detected, the content of the HTTP request message is inspected. If the content of the HTTP request message is found to be normal, the API access request is received. An authentication string is generated based on the SK corresponding to the AK in the HTTP request message and the corresponding authentication mechanism. The authentication string is compared with the signature string. If the authentication string and the signature string are the same, the API caller is granted access to the target API. Based on the identifier ID, determine whether the API caller is accessing the API for the first time through the API gateway; if the API caller is accessing the API for the first time through the API gateway, determine whether the API access request is a normal request based on the preset self-learning behavior detection engine; if the API caller is not accessing the API for the first time through the API gateway, determine whether the API access request is a normal request based on the self-learning behavior detection engine corresponding to the API caller. If the API access request is determined to be a normal request, the API access request is forwarded to the target API endpoint, and the requested data is returned to the API caller. Record API access logs; the API access logs include the API caller, the target API, and the request method, request parameters, and request source IP address corresponding to the API access request. The self-learning behavior detection engine corresponding to the API caller is established by continuously learning the normal behavior pattern of the API caller through machine learning methods; the normal behavior pattern of the API caller is obtained based on the API access logs corresponding to the API caller.

10. The method according to claim 9, characterized in that, The method further includes: If the HTTP request message contains attack information, the API access request will be blocked and an error code will be returned. If the authentication string differs from the signature string, the API access request will be ignored and an error code will be returned. If the API access request is determined to be an abnormal request, the API access request will be rejected and an error code will be returned.

Images