Access early warning method and device for open application program interface and electronic equipment

Abstract

The invention discloses an access early warning method and device for an open application program interface and electronic equipment. The method comprises the following steps: collecting a user access log of an open application program interface, and extracting multiple types of user access behavior characteristics from the user access log; constructing a user behavior portrait at least according to the multiple types of user access behavior characteristics; predicting a user access behavior of the user to the open application program interface in a future preset time period according to the user behavior portrait; the user access behaviors are scored, risk values of the user access behaviors are obtained, and different risk values correspond to different risk levels; and determining early warning information corresponding to the user access behavior according to the risk level corresponding to the risk value. The technical problem that a manual monitoring method depending on a post-event log auditing mechanism cannot guarantee the operation stability, reliability and continuity of the open application program interface is solved.

Description

Technical Field

[0001] This application relates to the field of network security, and more specifically, to an access warning method, apparatus, and electronic device for an open application programming interface. Background Technology

[0002] In internet service architecture, Open Application Programming Interfaces (Open APIs) have become a crucial bridge connecting front-end and back-end, services, and systems. Especially with the widespread adoption of microservice architectures, the stability, reliability, and continuity of Open APIs directly impact the service quality and user experience of the entire application ecosystem. As service complexity and user volume increase, the probability of Open APIs encountering various anomalies during operation also rises, including but not limited to malicious attacks, network latency, service timeouts, resource shortages, and logical errors.

[0003] With the surge in the number of Open APIs, traditional manual monitoring methods relying on post-event log auditing mechanisms are becoming increasingly difficult to guarantee the stability, reliability, and continuity of Open API operation. Traditional large-scale IT system monitoring methods often focus on infrastructure-level monitoring, such as server CPU and memory usage, and network traffic, while neglecting to monitor key indicators at the Open API level, such as unauthorized access, response latency, and call failures. This makes it difficult to promptly detect and quickly locate problems at the Open API layer. Furthermore, it is difficult to capture user behavior profiles and prevent unauthorized access behaviors, posing significant security risks.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides an access warning method, apparatus, and electronic device for open application programming interfaces (APIs) to at least solve the technical problem that manual monitoring methods relying on post-event log auditing mechanisms cannot guarantee the stability, reliability, and continuity of open application programming interface operation.

[0006] According to one aspect of the embodiments of this application, an access warning method for an open application programming interface (API) is provided, comprising: collecting user access logs of the API and extracting multiple types of user access behavior features from the user access logs; constructing a user behavior profile based on at least the multiple types of user access behavior features; predicting user access behavior of the API for a future preset time period based on the user behavior profile; scoring the user access behavior to obtain a risk value of the user access behavior, wherein different risk values ​​correspond to different risk levels; and determining warning information corresponding to the user access behavior based on the risk level corresponding to the risk value.

[0007] Optionally, multiple types of user access behavior features are extracted from user access logs, including: extracting a first type of feature from user access logs collected in response to user authorization commands, wherein the first type of feature includes at least the following features: access frequency, error rate, response latency, concurrent connections, and queries per second; and extracting a second type of feature from user access logs, wherein the second type of feature includes at least the following features: periodicity intensity, trend deviation, and behavioral inertia, wherein periodicity intensity is used to reflect at least the degree to which user access behavior changes periodically over time, trend deviation is used to reflect at least the degree to which user access behavior in the user access logs deviates from the trend of historical user access behavior, and behavioral inertia is used to reflect at least the order in which users access open application programming interfaces. The frequency and frequency; extract a third type of feature from user access logs, wherein the third type of feature includes at least the following features: geographic information, user device information, and target operation density, wherein the geographic information is used to reflect the user's geographic jump anomaly information, the geographic jump anomaly information includes user information when the physical distance between any two user access requests of the same user is greater than a preset distance threshold, the user device information is used to indicate the changes in user device information accessing the open application programming interface, and the target operation density is used to indicate the frequency of executing target operations per unit time, the target operation includes at least one of the following operations: personal information change, password change, and financial transaction; the first type of feature, the second type of feature, and the third type of feature are determined as multi-type user access behavior features.

[0008] Optionally, a user behavior profile is constructed based on at least multiple types of user access behavior characteristics, including: constructing a first profile and a second profile based on a first type of characteristics, wherein the first profile is constructed based at least on the error rate, access frequency, and response latency of the first type of characteristics, and the second profile is constructed based at least on the number of concurrent connections and queries per second of the first type of characteristics. The first profile is used to capture user access behavior patterns, and the second profile is used to assess the resource status of the open application programming interface (API); constructing a third profile based on the second type of characteristics, wherein the third profile is used to reflect the operating habits of users accessing the open application programming interface; constructing a fourth profile based on the third type of characteristics, wherein the fourth profile is used to mark the risks present in the user access behavior corresponding to the open application programming interface; obtaining the application programming interface permission set and user level corresponding to the user accessing the open application programming interface, and constructing a fifth profile based on the application programming interface permission set and user level, wherein the fifth profile is used to reflect the user information of the user accessing the open application programming interface; and determining the set of the first profile, second profile, third profile, fourth profile, and fifth profile as the user behavior profile.

[0009] Optionally, the method further includes: updating each profile in the user behavior profile according to its corresponding update strategy to obtain the updated user behavior profile, wherein the update strategy corresponding to the first profile is to update through a sliding window, the update strategy corresponding to the second profile is to update by periodic sampling, the update strategy corresponding to the third profile is to update by incrementally updating the Markov state transition matrix, the update strategy corresponding to the fourth profile is to update when a target event is detected, and the update strategy corresponding to the fifth profile is to update in response to the user's change instruction when a change in user permissions is detected, wherein the target event is any one of a predefined plurality of events with access risks.

[0010] Optionally, predicting user access behavior for the Open Application Programming Interface (API) within a preset time period based on user behavior profiles includes: obtaining a sequence of historical access behaviors of users who access the API within a preset historical time period; determining the historical access behavior sequence and user behavior profiles as input data; using the input data as input, predicting user access behavior through a target prediction model to obtain user access behavior, wherein the user access behavior includes the predicted value of user access behavior at each time point in the preset future time period and the corresponding confidence interval of the predicted value.

[0011] Optionally, user access behavior is scored to obtain a risk value for the user access behavior, including: determining the standard deviation and mean of the user access behavior, and determining the volatility based on the standard deviation and mean of the user access behavior, wherein the user access behavior includes the predicted value of the user access behavior at each time point in a future preset time period and the predicted value fluctuation range corresponding to the predicted value; obtaining a preset first weight, and determining a first score based at least on the preset first weight and volatility, wherein the first score is used to quantify the reliability of the user access behavior; determining a second score based on multiple user access behavior characteristics, wherein the second score is used to quantify the behavioral deviation of the user access behavior; obtaining the number of queries per second and the remaining capacity of the target system, wherein the target system is a system that provides open application programming interface services, and the remaining capacity is the maximum query rate that the target system can bear under the condition of ensuring service quality; determining a third score based on the user access behavior, the number of queries per second of the target system, and the remaining capacity, wherein the third score is used to quantify the business impact of the user access behavior; and determining the risk value of the user access behavior based on the first score, the second score, and the third score.

[0012] Optionally, the warning information corresponding to the user access behavior is determined based on the risk level corresponding to the risk value, including: obtaining the risk value ranges corresponding to multiple risk levels respectively; determining the risk level corresponding to the risk value range containing the risk value as the target risk level corresponding to the risk value; obtaining the defense strategy and countermeasures corresponding to the target risk level; and determining the set of risk value, target risk level, defense strategy and countermeasures as the warning information corresponding to the user access behavior.

[0013] According to another aspect of the embodiments of this application, an access warning device for an open application programming interface (API) is also provided, comprising: a collection module for collecting user access logs of the API and extracting multiple types of user access behavior features from the user access logs; a construction module for constructing a user behavior profile based on at least the multiple types of user access behavior features; a prediction module for predicting user access behavior of the API in the future within a preset time period based on the user behavior profile; a scoring module for scoring the user access behavior to obtain a risk value of the user access behavior, wherein different risk values ​​correspond to different risk levels; and a determination module for determining the warning information corresponding to the user access behavior based on the risk level corresponding to the risk value.

[0014] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, wherein a program is stored in the non-volatile storage medium, and the program controls the device where the non-volatile storage medium is located to execute the above-mentioned access warning method for the open application programming interface when it runs.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes the above-described access warning method for the open application programming interface during runtime.

[0016] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the above-described access warning method for the open application programming interface.

[0017] In this embodiment, the method involves collecting user access logs of an Open Application Programming Interface (API) and extracting multiple user access behavior features from these logs. A user behavior profile is constructed based on these features. The user behavior profile is used to predict future access behavior to the API within a preset time period. The user access behavior is scored to obtain a risk value, where different risk values ​​correspond to different risk levels. The warning information corresponding to the user access behavior is determined based on the risk level. This method achieves the goal of predicting user access behavior and providing early warnings for the API. This allows for proactive measures to be taken based on the warning information, ensuring the stability, reliability, and continuity of the API's operation. This solves the technical problem that manual monitoring methods relying on post-event log auditing mechanisms cannot guarantee the stability, reliability, and continuity of the API's operation. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing an access warning method for an open application programming interface, according to an embodiment of this application.

[0020] Figure 2 This is a flowchart of an access warning method for an open application programming interface provided according to an embodiment of this application;

[0021] Figure 3 This is a flowchart illustrating the construction of a user behavior profile according to an embodiment of this application;

[0022] Figure 4 This is a flowchart of another access warning method for an open application programming interface provided according to an embodiment of this application;

[0023] Figure 5 This is an example diagram of abnormal access to an open application programming interface provided in an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of an access warning device for an open application programming interface provided in an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0026] The information collected in this application embodiment is information and data authorized by the user or fully authorized by all parties. The collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, and necessary confidentiality measures have been taken. It does not violate public order and good morals, and provides corresponding operation entry points for users to choose to authorize or reject the automated decision results. If the user chooses to reject, the process will proceed to the expert decision-making process.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0029] Open Application Programming Interface (OpenAPI): An interface specification that provides a way to describe RESTful API interfaces, enabling developers to design, build, document, and use services without having to worry about the details of the underlying implementation or the specific technology stack.

[0030] Representational State Transfer (RESTful): A design and development approach for web applications that can reduce development complexity and improve system scalability.

[0031] Long Short-Term Memory (LSTM) networks are a special type of recurrent neural network that addresses the long-term dependency problem of traditional RNNs by introducing three gating structures (input gate, forget gate, and output gate), enabling them to handle and predict complex correlations in time series data.

[0032] Convolutional Neural Network (CNN): A type of feedforward neural network that automatically extracts local features from input data through a hierarchical structure of convolutional layers, pooling layers, and fully connected layers, gradually compressing information, reducing redundancy, and improving generalization ability.

[0033] Transformer: A deep learning model based on self-attention mechanism, consisting of two parts: an encoder component and a decoder component. Transformer model (Encoder-Decoder architecture pattern).

[0034] In related technologies, with the surge in the number of Open APIs, traditional manual monitoring methods relying on post-event log auditing mechanisms are becoming increasingly difficult, failing to guarantee the stability, reliability, and continuity of Open API operation. Traditional large-scale IT system monitoring methods often focus on infrastructure-level monitoring, such as server CPU, memory usage, and network traffic, but lack sufficient monitoring of key indicators at the Open API level, such as unauthorized access, response latency, and call failures, making it difficult to promptly detect and quickly locate problems at the Open API layer. User behavior profiling is difficult to capture, and preventing and taking preventative measures against unauthorized access behaviors is challenging, posing significant security risks. Therefore, manual monitoring methods relying on post-event log auditing mechanisms cannot guarantee the stability, reliability, and continuity of Open API operation. To address this issue, this application provides relevant solutions, which are detailed below.

[0035] According to an embodiment of this application, an embodiment of an access warning method for an open application programming interface is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1A hardware block diagram of a computer terminal for implementing an access warning method for an open application programming interface is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0037] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0038] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the access warning method for the open application interface in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned access warning method for the open application interface. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0039] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0040] The display can be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0041] In the above operating environment, this application provides an embodiment of an access warning method for an open application programming interface. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0042] like Figure 2 The diagram shown is a flowchart of an access warning method for an open application programming interface (API) according to an embodiment of this application, comprising:

[0043] Step S202: Collect user access logs from the open application programming interface and extract multiple types of user access behavior features from the user access logs.

[0044] In the technical solution provided in step S202, there are multiple ways to extract multiple types of user access behavior features from user access logs. For example: extracting a first type of feature from user access logs collected in response to user authorization commands, wherein the first type of feature includes at least the following features: access frequency, error rate, response latency, number of concurrent connections, and queries per second; extracting a second type of feature from user access logs, wherein the second type of feature includes at least the following features: periodicity intensity, trend deviation, and behavioral inertia, wherein periodicity intensity is used to reflect at least the degree to which user access behavior changes periodically over time, trend deviation is used to reflect at least the degree to which user access behavior in the user access logs deviates from the trend of historical user access behavior, and behavioral inertia is used to reflect at least the degree to which user access behavior changes periodically over time. The order and frequency of application programming interfaces (APIs) are determined; a third type of feature is extracted from user access logs, wherein the third type of feature includes at least the following features: geographic information, user device information, and target operation density. Geographic information is used to reflect the user's geographic jump anomaly information, which includes user information when the physical distance between any two user access requests of the same user is greater than a preset distance threshold. User device information is used to indicate changes in user device information accessing open APIs. Target operation density is used to indicate the frequency of executing target operations per unit time, and target operations include at least one of the following: personal information change, password change, and financial transaction. The first, second, and third types of features are determined as multi-type user access behavior features.

[0045] In some embodiments of this application, the collection of user access logs from the Open Application Programming Interface (API) is performed continuously in real time. Real-time scanning of user access logs is the foundation for proactive early warning, aiming to capture all API access behavior data with high throughput, low latency, and lossless performance. Lightweight log collection agents (such as Filebeat (a lightweight open-source log collector) or Fluent Bit (a high-performance log processor and forwarder supporting multiple input sources and output targets, capable of processing and sending various types of data streams, including logs, events, and metrics)) can be deployed on each API server to monitor log file changes in real time. The next step is to continuously collect user access logs from the API at preset collection intervals (e.g., every 5 minutes) using the lightweight log collection agent. The collected user access log information is then written to a local memory queue and asynchronously pushed to a central message queue (such as Kafka, an open-source stream processing platform). The log processing module in the system executing the methods of this application receives the user access logs, cleans and processes the messages in the logs, and then stores them. The essential attributes that a user access log must contain are shown in Table 1:

[0046] Table 1

[0047]

[0048] It is important to note that user access logs are collected in response to user authorization commands. After collecting the user access logs, feature extraction is required. This involves extracting multiple types of user access behavior features from the logs collected in response to user authorization commands. The purpose of extracting these features is to transform the raw logs into quantifiable behavioral characteristics. These multiple types of user access behavior features include at least three categories: first, second, and third features. The first category of features can be named real-time statistical features and includes at least the following: access frequency, error rate, response latency, and concurrent connections. The specific methods for extracting the first category of features from the user access logs collected in response to user authorization commands and their significance for subsequent anomaly detection are shown in Table 2.

[0049] Table 2

[0050]

[0051] The second type of feature can be named time-series behavioral features. These features focus on the time-series characteristics of user operations, such as the order of API calls and frequency trends. They should include at least the following features: periodicity intensity, trend deviation, and behavioral inertia. Periodicity intensity reflects the degree to which user access behavior changes periodically over time; trend deviation reflects the degree to which user access behavior in the access logs deviates from historical user access behavior trends; and behavioral inertia reflects the order and frequency of user access to open application programming interfaces (APIs). Table 3 shows the methods and application scenarios for extracting each specific feature from the second type of features in user access logs.

[0052] Table 3

[0053]

[0054] The third category of features can be named context-related features. These features emphasize the relationship between user behavior and their environment, such as geographic location and device information. They include the following features: geographic information, user device information, and target operation density. Geographic information at least reflects abnormal geographic jumps, which includes user information (user identifier, geographic location information, etc.) when the physical distance between any two access requests from the same user exceeds a preset distance threshold (e.g., 500 km / h). User device information (e.g., device fingerprint mutation) indicates changes in user device information accessing open application programming interfaces (APIs) (e.g., sudden change in the same user's User-Agent / screen resolution). Target operation density (also known as sensitive operation density) indicates the frequency of executing target operations per unit time. Target operations are high-privilege API operations and include at least one of the following: personal information changes, password changes, and financial transactions. Target operations also include all deletion operations. The specific extraction methods and application scenarios for each feature in this third category are shown in Table 4.

[0055] Table 4

[0056]

[0057] By extracting multiple user access behavior features from user access logs through the above steps, a solid data foundation and analytical capabilities are provided for subsequent construction of user behavior profiles and profile-based early warning and security strategies. This effectively solves the limitations of traditional manual monitoring methods and significantly improves the real-time performance, accuracy, and predictability of Open API monitoring.

[0058] The next step is to transform the features extracted from user behavior logs into meaningful user profiles. This process involves classifying, aggregating, and modeling the raw data. Proceed to step S204 to construct user behavior profiles based on at least multiple types of user access behavior features.

[0059] In the technical solution provided in step S204, there are multiple ways to construct a user behavior profile based on at least multiple types of user access behavior characteristics. For example: constructing a first profile and a second profile based on the first type of characteristics, wherein the first profile is constructed based at least on the error rate, access frequency, and response latency of the first type of characteristics, and the second profile is constructed based at least on the number of concurrent connections and queries per second of the first type of characteristics. The first profile is used to capture the user's access behavior pattern, and the second profile is used to evaluate the resource status of the open application programming interface (API). Constructing a third profile based on the second type of characteristics, wherein the third profile is used to reflect the operating habits of users accessing the open application programming interface (API). Constructing a fourth profile based on the third type of characteristics, wherein the fourth profile is used to mark the risks existing in the user access behavior corresponding to the open application programming interface (API). Obtaining the application programming interface permission set and user level corresponding to the user accessing the open application programming interface (API), and constructing a fifth profile based on the application programming interface permission set and user level, wherein the fifth profile is used to reflect the user information of the user accessing the open application programming interface (API). The set of the first profile, second profile, third profile, fourth profile, and fifth profile is determined as the user behavior profile.

[0060] It's important to note that each profile in the user behavior profile is updated in real time. Specifically, each profile is updated according to its corresponding update strategy to obtain the updated user behavior profile. The update strategy for the first profile is through a sliding window; the second profile is updated using periodic sampling; the third profile is updated by incrementally updating the Markov state transition matrix; the fourth profile is updated when a target event is detected; and the fifth profile is updated in response to the user's change command when a change in user permissions is detected. The target event is any one of a predefined set of events that pose access risks. The following details the process of constructing the user behavior profile.

[0061] The first and second profiles in the user behavior profile are the behavioral baseline profile and the resource profile, respectively. The first profile is used to capture user access behavior patterns, and the second profile is used to assess the resource status of open application programming interfaces (APIs). Both the first and second profiles are constructed based on the first type of features. The error rate, access frequency, and response latency of the first type of features collected in the target time window are smoothed by sliding window aggregation (e.g., set to a sliding window every 5 minutes) and exponentially weighted moving average (EWMA) smoothing. The corresponding average, variance, and other statistics within the target time window are calculated to obtain the first profile. A second profile is constructed based on the number of concurrent connections and queries per second in the first type of features. For example, periodic Top-K sampling is performed on high-water level indicators in the first type of features (such as the peak value of queries per second (QPS) and the maximum number of concurrent connections). Further statistical analysis is performed on the selected Top-K data, such as calculating their mean and variance, to reflect the distribution of resource consumption. Finally, a resource profile for capacity assessment is formed. Here, Top-K sampling refers to selecting the top K (e.g., top 10) data points from the peak value of QPS and the maximum value of concurrent connections in the first type of features.

[0062] The third profile is the user operation habit profile, which reflects the operation habits of users accessing open application programming interfaces (APIs). It is built upon the second type of features: these features focus on the time-series characteristics of user operations, such as the order of API calls and frequency trends. Based on these features, online Markov chains or sequence pattern mining techniques (e.g., sequence modeling methods) can be used to capture user operation habits, thus obtaining the third profile. For example, by analyzing the order of user API calls, certain specific operation sequences can be found to occur frequently, which may represent the user's typical operation flow. Based on this, a user operation habit profile can be built for each user to help understand their behavioral patterns.

[0063] The fourth profile is a risk label profile, used to mark risks in user access behavior corresponding to open application programming interfaces (APIs). This is because the third type of feature emphasizes the relationship between user behavior and its environment, such as geographical location and device information. The fourth profile can be constructed based on the third type of feature. For example, it can obtain abnormal statistical indicators in user access behavior (these indicators include event information corresponding to all target events), where the target event is any one of a predefined set of events with access risks. Analysis of the third type of feature and abnormal statistical indicators identifies potential risk factors (e.g., login attempts suddenly appearing in different geographical locations may be a sign of abnormal behavior). A rule engine can analyze the third type of feature and abnormal statistical indicators to automatically identify and label risks in access behavior and generate risk labels reflecting the user account security status. The generation of risk labels is based on the analysis of abnormal statistical indicators. Each predefined risk event (such as geographical location jumps, device fingerprint mutations, or abnormal density of sensitive operations) corresponds to a set of labeling logic. The rule engine evaluates user behavior data according to this logic, and if it detects behavior that matches the characteristics of a risk event, it automatically assigns the corresponding risk label. For example, if an abnormal geographical location jump is detected, the user's access behavior will be labeled with "geographical jump risk." The fourth portrait was finally obtained.

[0064] The fifth profile is used to reflect user information (e.g., user identity level) of users who access open application programming interfaces (APIs). It is necessary to obtain the application programming interface permission set (API permission set) and user level (user identity level) corresponding to the user who accesses the open application programming interface and construct it based on these. The application programming interface permission set and user level are used to construct the fifth profile.

[0065] It should be noted that the user behavior profiles in this embodiment are dynamically updated user behavior profiles. Each profile in the user behavior profile is updated in real time, and each profile corresponds to an update strategy, and is updated in real time according to the corresponding update strategy. For example, the update strategy corresponding to the first profile is to update it through a sliding window (sliding window mean (rolling update every 5 minutes): after each new 5-minute sliding window, the first profile is updated based on the first type of features obtained by the new sliding window), the update strategy corresponding to the second profile is to update it using a periodic sampling method (for example, every hour as the period, the top K records are collected to update the second profile), the third The update strategy for the first profile is to update it by incrementally updating the Markov state transition matrix (for example, by using online Markov chains or sequence modeling methods to continuously update the user's operating habits, including high-frequency paths and state transition probabilities). The update strategy for the second profile is to update it when a target event is detected (real-time event-driven (labeling is done immediately when the conditions are met, and the fourth profile is updated immediately when a target event is detected)). The update strategy for the third profile is to update it in response to the user's change command when a change in user permissions is detected (manually triggered update (when permissions change), that is, update it in response to the user's change command when a change in user permissions is detected).

[0066] The key dimensions and update strategies for displaying the first to fifth user behavior profiles are shown in Table 5 below:

[0067] Table 5

[0068]

[0069] By constructing a dynamic user behavior profile through the above step S204, it is possible to gain insight into user behavior patterns in advance. This not only captures the regularity of normal access behavior but also predicts future behavioral trends, thereby providing early warning capabilities for potential abnormal access and avoiding manual monitoring through post-event log auditing mechanisms. Furthermore, the user behavior profile can be updated quickly to adapt to changes in user behavior, ensuring the stability, reliability, and continuity of the open application programming interface (API).

[0070] Step S206: Based on user behavior profiles, predict user access behavior to open application programming interfaces (APIs) within a preset time period in the future.

[0071] In the technical solution provided in step S206, predicting user access behavior for the Open Application Programming Interface (API) in the future based on user behavior profiles can be achieved in various ways, such as: obtaining the historical access behavior sequence of users who access the API in the future historical time period; determining the historical access behavior sequence and user behavior profile as input data; using the input data as input, predicting user access behavior through the target prediction model to obtain user access behavior, wherein the user access behavior includes the predicted value of user access behavior at each time point in the future preset time period and the prediction confidence interval corresponding to the predicted value.

[0072] In some embodiments of this application, the target prediction model can be a deep learning model suitable for time series prediction, such as a Long Short-Term Memory (LSTM) network, a Convolutional Neural Network (CNN), or a Transformer. The target prediction model is a model pre-trained using a large amount of historical user access behavior data (including historical access behavior data and historical user behavior profiles). During training, techniques such as cross-validation, early stopping strategies, and learning rate decay can be used to optimize the performance of the target prediction model. The prediction performance of the target prediction model, including prediction accuracy and confidence interval coverage, is evaluated on a validation set. Based on the evaluation results, the parameters of the target prediction model are adjusted to optimize the prediction performance, and the target prediction model is obtained after reaching the convergence condition (e.g., reaching the maximum number of iterations).

[0073] When predicting user access behavior to an Open Application Programming Interface (API) within a preset time period based on user behavior profiles, the system first obtains the historical access behavior sequence of users who accessed the API during the preset historical time period (e.g., the past 24 hours corresponding to the timestamp of the prediction moment). This historical access behavior sequence is composed of user historical access behavior data collected in each collection period (e.g., every 5 minutes) within the preset historical time period, arranged from timestamp to chronological order, such as QPS, error rate, latency, etc., every 5 minutes in the past 24 hours. The historical access behavior sequence and user behavior profiles are then used as input data: the user's historical behavior sequence (e.g., QPS, error rate, latency, etc., every 5 minutes in the past 24 hours) is used as the primary input, and the user behavior profile is integrated as a conditional prior. The user behavior profile contains contextual information for each profile, such as the user's identity level, operating habits, behavioral baseline, and risk tags. These profiles provide a multi-dimensional perspective on user behavior, such as typical access patterns, preferences, geographical location information, and potential risk status. Using the profile as a conditional prior provides a preset behavioral framework for the target prediction model, enabling it to better understand and predict the behavior of specific users. The system uses input data (which can be generated using a conditional generative network, where the profile information is converted into a conditional vector by an independent encoder and then combined with historical behavior sequence data before being input into the target prediction model) to predict user access behavior. The user access behavior includes the predicted value of user access behavior (representing the predicted user access behavior, such as QPS) at each time point (e.g., each minute as a time point) within a future preset time period (e.g., 15 minutes / 30 minutes / 60 minutes after the prediction time timestamp) and the corresponding prediction confidence interval (the prediction confidence interval represents the confidence level of the prediction value, used to reflect the uncertainty of the prediction, which can be estimated by quantile regression or Monte Carlo Dropout to obtain the prediction confidence interval). Monte Carlo Dropout combines the Monte Carlo method and Dropout technology (Dropout technology refers to a regularization technique that prevents overfitting by randomly dropping a portion of neurons during training of a neural network), and the activation of the random dropout layer (Dropout layer) is maintained during the prediction phase. By performing multiple forward propagations (randomly discarding different neurons in each propagation), multiple prediction results can be collected and their distribution analyzed, thereby approximating the confidence interval of the predicted value. For example, the 95% confidence interval of the predicted value. Traditional post-event log auditing mechanisms can only trace and analyze after an anomaly occurs, but cannot predict and prevent it in advance.In contrast, step S206 integrates real-time user behavior profiles with historical access data and uses advanced predictive models to predict future behavior. This enables proactive operation and maintenance by recognizing potential abnormal access patterns in advance.

[0074] Step S208: Score the user's access behavior to obtain the risk value of the user's access behavior.

[0075] In the technical solution provided in step S208, different risk values ​​correspond to different risk levels.

[0076] In the technical solution provided in step S208, there are multiple ways to score user access behavior and obtain the risk value of user access behavior. For example: determining the standard deviation and mean of user access behavior, and determining the volatility based on the standard deviation and mean of user access behavior, wherein user access behavior includes the predicted value of user access behavior at each time point in a future preset time period and the predicted value fluctuation range corresponding to the predicted value; obtaining a preset first weight, and determining a first score based at least on the preset first weight and volatility, wherein the first score is used to quantify the reliability of user access behavior; determining a second score based on multiple types of user access behavior characteristics, wherein the second score is used to quantify the behavioral deviation of user access behavior; obtaining the number of queries per second and the remaining capacity of the target system, wherein the target system is a system that provides open application programming interface services, and the remaining capacity is the maximum query rate that the target system can bear under the condition of ensuring service quality; determining a third score based on user access behavior, the number of queries per second of the target system, and the remaining capacity, wherein the third score is used to quantify the business impact of user access behavior; and determining the risk value of user access behavior based on the first score, the second score, and the third score.

[0077] To score user access behavior, first determine the standard deviation and mean of the user access behavior (the standard deviation and mean of the predicted values ​​of user access behavior at all time points within a preset future time period). The percentage of the quotient of the standard deviation and mean is defined as volatility. This ratio of standard deviation to mean is converted into an easily understandable form, intuitively reflecting the magnitude of the variability of the predicted value relative to its mean. Calculate the coverage ratio (PICP) of the predicted value within its confidence interval. Obtain a preset first weight, and determine a first score based at least on the preset first weight and volatility. For example, the first score can be calculated using the following formula. The first score is used to quantify the reliability of the predicted user access behavior.

[0078]

[0079] in, It is a weighting factor between 0 and 1 (i.e., the preset first weight mentioned above), used to balance the impact of PICP and volatility. μ and μ represent the standard deviation and mean of the predicted values, respectively (i.e., the standard deviation and mean of the user access behavior mentioned above).

[0080] The second score is determined based on multiple user access behavior characteristics (QPS, API sequence, and geographic jump index): Anomaly indices are calculated for metrics such as access frequency, API sequence, and geographic pattern, combining user historical profiles and multiple user access behavior characteristics. A standardized QPS score (Z-score), API sequence likelihood score, and geographic jump index are calculated based on the QPS among the multiple user access behavior characteristics. The geographic jump index is determined by quantifying geographic information within the multiple user access behavior characteristics (by quantifying geographic information and converting it into a comparable and analyzable numerical form, the geographic jump index can more objectively and accurately reflect the degree of anomaly in user access behavior). For example, the second score can be determined using the following formula. The second score is used to quantify the behavioral deviation of the predicted user access behavior:

[0081]

[0082] in, The weights are assigned to each part. The Z-score represents the QPS. This represents the likelihood score of the API sequence. This represents the geographical jump index.

[0083] The next step is to obtain the predicted number of queries per second for the target system from the predicted values ​​of user access behavior. Obtain the number of queries per second and the remaining capacity of the target system. And determine the current actual load based on the number of queries per second of the target system. Based on user access behavior (specifically, the predicted number of queries per second for the target system within the predicted values ​​of user access behavior), The third scoring method is determined by the number of queries per second and the remaining capacity of the target system. The third rating is used to quantify the business impact of predicted user access behavior:

[0084]

[0085] The risk value of user access behavior is determined based on the first score (30% weight), the second score (40% weight), and the third score (30% weight). :

[0086]

[0087] The risk values ​​of user access behavior obtained through the above methods are used to evaluate predicted user behavior from multiple dimensions, ultimately yielding a risk value. The calculation of this risk value is based on real-time analysis of user behavior characteristics and prediction of future behavior, transforming traditional passive log auditing into a proactive monitoring and early warning mechanism. Subsequently, early warning information is determined based on the risk level corresponding to this risk value, ensuring the accuracy of the generated warning information and improving the security and protection capabilities of the Open API.

[0088] Step S210: Determine the warning information corresponding to the user's access behavior based on the risk level corresponding to the risk value.

[0089] There are several ways to determine the warning information corresponding to user access behavior based on the risk level corresponding to the risk value. For example: obtaining the risk value range corresponding to multiple risk levels; determining the risk level corresponding to the risk value range containing the risk value as the target risk level corresponding to the risk value; obtaining the defense strategy and countermeasures corresponding to the target risk level; and determining the set of risk value, target risk level, defense strategy and countermeasures as the warning information corresponding to user access behavior.

[0090] In step S210, the risk level corresponding to the risk value is first determined: Multiple risk value ranges corresponding to different risk levels are obtained, where each risk range is predefined. The risk level corresponding to the risk value range containing the risk value is determined as the target risk level corresponding to the risk value. Then, the pre-set defense strategy and countermeasures corresponding to the target risk level are obtained. The set of risk value, target risk level, defense strategy, and countermeasures is determined as the early warning information corresponding to the user access behavior, and this early warning information is pushed (via message, email, or SMS, etc.) to the operation and maintenance management personnel. The risk level classification, defense strategy, and countermeasures are shown in Table 6 below:

[0091] Table 6

[0092]

[0093] Rate limiting + security scanning refers to limiting the access rate by setting a limit on the number of requests per second or per minute to prevent the target system from overloading. Security scanning refers to a comprehensive security check of the target system, including but not limited to scanning for system vulnerabilities, checking for signs of malicious activity in access logs, and analyzing abnormal behavior in network traffic. API circuit breaking + attack attribution: API circuit breaking refers to automatically stopping or restricting calls to certain APIs until the service returns to a stable state. Attack attribution refers to in-depth analysis of log data, network traffic, and related user information to determine the specific source of abnormal access (such as IP address, abnormal user behavior, etc.). Attack attribution helps to quickly locate attackers, take targeted preventive measures, and provide feedback for subsequent system optimization.

[0094] The method in this application first provides a solid data foundation for accurate early warning of abnormal access to Open APIs through efficient, real-time, and accurate user access log collection. Multimodal user behavior feature engineering is performed, introducing temporal behavior features and contextual features in addition to real-time statistical characteristics, improving the accuracy of user profiling. An adaptive dynamic user profiling model is constructed, dynamically updating user profiles according to changes in user access behavior and user profile types, enhancing adaptability. Fusion prediction of user behavior improves the accuracy of user behavior prediction. The risk of future user access behavior is assessed from the perspectives of prediction reliability, behavior deviation, and business impact, reducing the false alarm rate of abnormal access. A closed-loop process integrating behavior prediction, risk warning, and security protection is established, achieving a paradigm upgrade from passive defense to proactive immunity.

[0095] Figure 3 This is a flowchart illustrating the construction of a user behavior profile according to an embodiment of this application. First, features are extracted from multiple types of user access behavior characteristics. Based on real-time statistical features (first type of features), a behavior baseline and resource profile (i.e., the first profile and the second profile) are constructed. Based on time-series behavior features (second type of features), an operation habit profile (third profile) is constructed. Based on contextual association features (third type of features), a risk label profile (fourth profile) is constructed. Based on the application programming interface permission set and user level, a fifth profile is constructed. Finally, the set of the first profile, second profile, third profile, fourth profile, and fifth profile is determined as the dynamic user behavior profile (i.e., the aforementioned user behavior profile).

[0096] Figure 4This is a flowchart of another access warning method for open application programming interfaces (APIs) provided according to an embodiment of this application. First, user access logs are collected in real time (i.e., the user access logs for the APIs are collected as described above). User access behavior features are extracted (i.e., multiple types of user access behavior features are extracted from the user access logs as described above). User behavior profiles are dynamically constructed (i.e., user behavior profiles are constructed based on at least multiple types of user access behavior features as described above). Future user access behavior is predicted (i.e., user access behavior for the APIs is predicted within a preset time period based on the user behavior profile as described above). Future user access risks are warned, and security protection measures are taken in advance (i.e., warning information corresponding to user access behavior is determined based on the risk level corresponding to the risk value as described above).

[0097] Figure 5 This is an example diagram of abnormal access to an open application programming interface (API) provided according to an embodiment of this application, such as... Figure 5 As shown, the horizontal axis represents time, and the vertical axis represents the number of access requests to the open application programming interface. The blue curve represents the normal access curve, and the orange curve represents the abnormal access curve.

[0098] Figure 6 This is a schematic diagram of an access warning device for an open application programming interface (API) according to an embodiment of this application, comprising:

[0099] The acquisition module 602 is used to collect user access logs of the open application programming interface and extract multiple types of user access behavior features from the user access logs.

[0100] The acquisition module 602 is also used to extract a first type of feature from the user access logs collected in response to user authorization commands, wherein the first type of feature includes at least the following features: access frequency, error rate, response latency, number of concurrent connections, and queries per second; and to extract a second type of feature from the user access logs, wherein the second type of feature includes at least the following features: periodicity intensity, trend deviation, and behavioral inertia, wherein periodicity intensity is used to reflect at least the degree to which user access behavior changes periodically over time, trend deviation is used to reflect at least the degree to which user access behavior in the user access logs deviates from the trend of historical user access behavior, and behavioral inertia is used to reflect at least the order and frequency of user access to open application programming interfaces; and to extract a second type of feature from the user access logs. A third type of feature is extracted from the logs. This third type of feature includes at least the following features: geographic information, user device information, and target operation density. The geographic information is used to reflect the user's geographic jump anomaly information, which includes user information when the physical distance between any two user access requests of the same user is greater than a preset distance threshold. The user device information is used to indicate changes in the user device information accessing the open application programming interface. The target operation density is used to indicate the frequency of executing target operations per unit time. Target operations include at least one of the following: personal information change, password change, and financial transaction. The first, second, and third types of features are identified as multi-type user access behavior features.

[0101] Module 604 is used to build user behavior profiles based on at least multiple types of user access behavior characteristics.

[0102] The construction module 604 is further configured to construct a first profile and a second profile based on the first type of features, wherein the first profile is constructed based at least on the error rate, access frequency, and response latency of the first type of features, and the second profile is constructed based at least on the number of concurrent connections and queries per second of the first type of features. The first profile is used to capture user access behavior patterns, and the second profile is used to assess the resource status of the open application programming interface (API). A third profile is constructed based on the second type of features, wherein the third profile is used to reflect the operating habits of users accessing the open application programming interface. A fourth profile is constructed based on the third type of features, wherein the fourth profile is used to mark the risks present in the user access behavior corresponding to the open application programming interface. The API permission set and user level corresponding to the user accessing the open application programming interface are obtained, and a fifth profile is constructed based on the API permission set and user level, wherein the fifth profile is used to reflect the user information of the user accessing the open application programming interface. The set of the first profile, second profile, third profile, fourth profile, and fifth profile is determined as the user behavior profile.

[0103] The construction module 604 is also used to update each profile in the user behavior profile according to its corresponding update strategy to obtain the updated user behavior profile. The update strategy for the first profile is to update it through a sliding window, the update strategy for the second profile is to update it through periodic sampling, the update strategy for the third profile is to update it through incremental update of the Markov state transition matrix, the update strategy for the fourth profile is to update it when a target event is detected, and the update strategy for the fifth profile is to update it in response to the user's change command when a change in user permissions is detected. The target event is any one of a number of predefined events with access risks.

[0104] The prediction module 606 is used to predict user access behavior to the open application programming interface within a preset time period based on user behavior profiles.

[0105] The prediction module 606 is also used to obtain the historical access behavior sequence of users who access the open application interface within a preset historical time period; determine the historical access behavior sequence and user behavior profile as input data; use the input data as input, predict the user access behavior through the target prediction model, and obtain the user access behavior, wherein the user access behavior includes the predicted value of the user access behavior at each time point in the future preset time period and the prediction confidence interval of the predicted value.

[0106] The scoring module 608 is used to score user access behavior and obtain the risk value of user access behavior, where different risk values ​​correspond to different risk levels.

[0107] The scoring module 608 is also used to determine the standard deviation and mean of user access behavior, and to determine the volatility based on the standard deviation and mean of user access behavior. User access behavior includes the predicted value of user access behavior at each point in time within a preset future time period and the corresponding fluctuation range of the predicted value. It obtains a preset first weight and determines a first score based at least on the preset first weight and the volatility. The first score is used to quantify the reliability of user access behavior. It determines a second score based on multiple user access behavior characteristics. The second score is used to quantify the behavioral deviation of user access behavior. It obtains the number of queries per second and the remaining capacity of the target system. The target system is a system providing open application programming interface services, and the remaining capacity is the maximum query rate that the target system can handle while ensuring service quality. It determines a third score based on user access behavior, the number of queries per second of the target system, and the remaining capacity. The third score is used to quantify the business impact of user access behavior. Finally, it determines the risk value of user access behavior based on the first, second, and third scores.

[0108] The determination module 610 is used to determine the warning information corresponding to the user's access behavior based on the risk level corresponding to the risk value.

[0109] It should be noted that, Figure 6 The access warning device for the open application programming interface shown is used to perform... Figure 2 The access warning method for the open application programming interface shown is therefore Figure 2 The relevant explanations in the access warning method for the open application interface also apply to the access warning device for the open application interface, and will not be repeated here.

[0110] It should be noted that each module in the aforementioned open application programming interface access warning device can be a program module (e.g., a set of program instructions that implements a specific function) or a hardware module. For the latter, it can take the following forms, but is not limited to them: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0111] This application also provides a non-volatile storage medium, which includes a stored program, wherein, during program execution, the device where the non-volatile storage medium is located is controlled to execute the access warning method for the open application programming interface in any of the above embodiments.

[0112] This application also provides an electronic device, which includes a processor for running a program, wherein an access warning method for an open application programming interface is executed during program execution.

[0113] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the access warning method for open application programming interfaces in any of the above embodiments.

[0114] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0116] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0118] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0119] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for early warning of access to an open application programming interface (API), characterized in that, include: Collect user access logs from open application programming interfaces and extract multiple types of user access behavior features from the user access logs; At least based on the aforementioned multiple types of user access behavior characteristics, a user behavior profile is constructed; Based on the user behavior profile, predict the user access behavior of the open application interface in the future within a preset time period; The user access behavior is scored to obtain a risk value for the user access behavior, where different risk values ​​correspond to different risk levels; The warning information corresponding to the user's access behavior is determined based on the risk level corresponding to the risk value.

2. The method according to claim 1, characterized in that, The extraction of multiple user access behavior features from the user access logs includes: Extract a first type of feature from the user access logs collected in response to user authorization instructions, wherein the first type of feature includes at least the following features: access frequency, error rate, response latency, number of concurrent connections, and number of queries per second; The second type of features are extracted from the user access logs, wherein the second type of features includes at least the following features: periodicity intensity, trend deviation, and behavioral inertia. The periodicity intensity is used to reflect at least the degree to which user access behavior changes periodically over time, the trend deviation is used to reflect at least the degree to which user access behavior in the user access logs deviates from the trend of historical user access behavior, and the behavioral inertia is used to reflect at least the order and frequency of user access to the open application programming interface. A third type of feature is extracted from the user access log, wherein the third type of feature includes at least the following features: geographic information, user device information, and target operation density. The geographic information is used to reflect the user's geographic jump anomaly information, which includes user information when the physical distance between any two user access requests of the same user is greater than a preset distance threshold. The user device information is used to indicate the changes in the user device information accessing the open application programming interface. The target operation density is used to indicate the frequency of executing target operations per unit time, and the target operations include at least one of the following: personal information change, password change, and financial transaction. The first type of feature, the second type of feature, and the third type of feature are identified as the multi-type user access behavior features.

3. The method according to claim 2, characterized in that, The construction of a user behavior profile based at least on the multiple types of user access behavior features includes: A first profile and a second profile are constructed based on the first type of features. The first profile is constructed based at least on the error rate, access frequency and response latency of the first type of features. The second profile is constructed based at least on the number of concurrent connections and queries per second of the first type of features. The first profile is used to capture the user's access behavior pattern and the second profile is used to evaluate the resource status of the open application programming interface. A third profile is constructed based on the second type of features, wherein the third profile is used to reflect the operating habits of users accessing the open application programming interface; A fourth profile is constructed based on the third type of features, wherein the fourth profile is used to mark the risks present in the user access behavior corresponding to the open application programming interface; Obtain the application interface permission set and user level corresponding to the user who accesses the open application interface, and construct a fifth profile based on the application interface permission set and the user level, wherein the fifth profile is used to reflect the user information of the user who accesses the open application interface; The set of the first profile, the second profile, the third profile, the fourth profile, and the fifth profile is determined as the user behavior profile.

4. The method according to claim 3, characterized in that, The method further includes: Each user behavior profile in the profile is updated according to its corresponding update strategy to obtain an updated user behavior profile. The update strategy for the first profile is to update it through a sliding window; the update strategy for the second profile is to update it through periodic sampling; the update strategy for the third profile is to update it through incremental update of the Markov state transition matrix; the update strategy for the fourth profile is to update it when a target event is detected; and the update strategy for the fifth profile is to update it in response to the user's change instruction when a change in user permissions is detected. The target event is any one of a predefined set of events that pose an access risk.

5. The method according to claim 1, characterized in that, The step of predicting user access behavior for the open application interface within a preset time period based on the user behavior profile includes: Obtain the historical access behavior sequence of users who accessed the open application interface within a preset historical time period; The historical access behavior sequence and the user behavior profile are determined as input data; Using the input data as input, the user access behavior is predicted through the target prediction model to obtain the user access behavior, wherein the user access behavior includes the predicted value of the user access behavior at each time point in the future preset time period and the prediction confidence interval of the predicted value.

6. The method according to claim 1, characterized in that, The process of scoring the user's access behavior to obtain a risk value for the user's access behavior includes: Determine the standard deviation and mean of the user access behavior, and determine the volatility based on the standard deviation and mean of the user access behavior, wherein the user access behavior includes the predicted value of the user access behavior at each time point in the future preset time period and the predicted value fluctuation range corresponding to the predicted value. A preset first weight is obtained, and a first score is determined based at least on the preset first weight and the volatility, wherein the first score is used to quantify the reliability of the user access behavior; A second score is determined based on the aforementioned multiple user access behavior characteristics, wherein the second score is used to quantify the behavioral deviation of the user access behavior; Obtain the number of queries per second and the remaining capacity of the target system, wherein the target system is the system that provides the open application programming interface service, and the remaining capacity is the maximum query rate that the target system can bear under the condition of ensuring service quality; A third score is determined based on the user access behavior, the number of queries per second of the target system, and the remaining capacity, wherein the third score is used to quantify the business impact of the user access behavior; The risk value of the user's access behavior is determined based on the first score, the second score, and the third score.

7. The method according to claim 1, characterized in that, The step of determining the warning information corresponding to the user access behavior based on the risk level corresponding to the risk value includes: Obtain the risk value ranges corresponding to multiple risk levels; The risk level corresponding to the risk value range containing the risk value is determined as the target risk level corresponding to the risk value; Obtain the defense strategies and countermeasures corresponding to the target risk level; The set of the risk value, the target risk level, the defense strategy, and the response measures is determined as the early warning information corresponding to the user access behavior.

8. An access warning device for an open application programming interface, characterized in that, include: The data collection module is used to collect user access logs of the open application programming interface and extract multiple types of user access behavior features from the user access logs. The construction module is used to construct user behavior profiles based on at least the multiple types of user access behavior characteristics; The prediction module is used to predict user access behavior of the open application interface in the future within a preset time period based on the user behavior profile. The scoring module is used to score the user's access behavior to obtain a risk value for the user's access behavior, wherein different risk values ​​correspond to different risk levels; The determination module is used to determine the warning information corresponding to the user's access behavior based on the risk level corresponding to the risk value.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device where the non-volatile storage medium is located to execute the access warning method for the open application programming interface as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the access warning method for an open application programming interface as described in any one of claims 1 to 7.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the access warning method for the open application programming interface as described in any one of claims 1 to 7.

Images