Data protection method and device, equipment and storage medium

By using analytical models trained by a single-class classification algorithm in API calls for two-way risk identification, the problem of difficulty in identifying and blocking new attacks in the existing technology is solved, and effective prevention of data leakage risks during API calls is achieved.

CN119538274APending Publication Date: 2025-02-28HANGZHOU HIGH-TECH ZONE (BINJIANG) INSTITUTE OF BLOCKCHAIN & DATA SECURITY
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202411425737.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-12
Publication Date
2025-02-28

Smart Images

  • Figure CN119538274A_ABST
    Figure CN119538274A_ABST
Patent Text Reader

Abstract

The invention is suitable for the technical field of data security, and provides a data protection method and device, equipment and a storage medium. Performing risk identification on the request data by using a request data analysis model to obtain a request data risk value; calling corresponding return data according to the request data; performing risk identification on the return data by using a return data analysis model to obtain a return data risk value, the request data analysis model and the return data analysis model being obtained by training by using a single-class classification algorithm; and when at least one of the request data risk value and the return data risk value meets a preset risk threshold value, performing risk blocking operation on the request data. According to the scheme, bidirectional risk identification is carried out by adopting the request data analysis model and the return data analysis model, and various complex network attacks can be effectively handled.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a data protection method, device, equipment and storage medium. Background Art

[0002] Application Programming Interface (API) is an indispensable part of modern software development. By utilizing API, different applications and services can communicate with each other and share data and functions. However, this interaction method has security risks such as data leakage. Therefore, how to effectively protect data security when calling API services has become a key issue that needs to be solved urgently.

[0003] In traditional solutions, data leakage risks are mainly prevented through static interface constraints and rule settings. For example, rule-based or decision tree-based methods. These methods identify and filter malicious requests through a series of preset rules or decision logic.

[0004] However, these solutions are all based on risk protection against known threats. When new attack methods emerge, it is difficult to effectively identify and block them. Faced with increasingly complex malicious attacks, they cannot fully identify and prevent potential threats in a timely manner when attacks occur. Summary of the invention

[0005] The embodiments of the present application provide a data protection method, apparatus, device and storage medium, which can solve the technical problem of how to timely and comprehensively prevent the risk of data leakage during API calls.

[0006] In a first aspect, an embodiment of the present application provides a data protection method, including:

[0007] Get request data;

[0008] Use the request data analysis model to identify the risks of the request data and obtain the risk value of the request data;

[0009] Retrieve the corresponding return data according to the request data;

[0010] The return data analysis model is used to identify the risk of the return data and obtain the risk value of the return data. Both the request data analysis model and the return data analysis model are trained using a single-class classification algorithm.

[0011] When at least one of the request data risk value and the return data risk value meets a preset risk threshold, a risk blocking operation is performed on the request data.

[0012] In one implementation, the request data analysis model is used to identify the risk of the request data to obtain the risk value of the request data, including:

[0013] Classify and process the request data according to the request type of the request data, where the request type includes at least one of the following: obtain request, submit request, update request, and delete request, and a corresponding request data analysis model is constructed for the request data corresponding to each request type;

[0014] The request data is identified for risk based on the request data analysis model corresponding to each request type to obtain the request data risk value.

[0015] In one implementation, the single-class classification algorithm includes a support vector data description algorithm, and before obtaining the request data, the method further includes:

[0016] Get the request data training set corresponding to each request type;

[0017] Determine the request data training input dimension according to the request data training set corresponding to each request type. The request data training input dimension includes parameter feature coding and parameter abnormality feature coding. The parameter feature coding includes value characteristics and value length. The parameter abnormality feature coding includes the number of abnormal characters, the number of special characters and keyword combinations, and the number of keywords.

[0018] Model training is performed based on the support vector data description algorithm and the request data training input dimension to obtain a request data analysis model corresponding to each request type.

[0019] In one implementation, the return data analysis model is used to identify the risk of the return data to obtain the return data risk value, including:

[0020] The returned data is classified and processed according to the request type of the request data, and a corresponding returned data analysis model is constructed for the returned data corresponding to each request type;

[0021] According to the return data analysis model corresponding to each request type, the risk of the returned data is identified to obtain the risk value of the returned data.

[0022] In one implementation, a training set of returned data corresponding to each request type is obtained;

[0023] Determine the return data training input dimension according to the return data training set corresponding to each request type, where the training input dimension includes at least one of the following: return status code, request data risk value, number of return content types, amount of returned data, and total amount of returned data within a preset time period;

[0024] Model training is performed based on the support vector data description algorithm and the return data training input dimensions to obtain the return data analysis model corresponding to each request type.

[0025] In one implementation, performing a risk blocking operation on the request data includes:

[0026] Obtaining label data of the requesting user, which is used to calculate the user risk value of the requesting user;

[0027] Comparing the risk value of the requested data with a preset risk threshold to obtain a first comparison result;

[0028] Compare the returned data risk value with the preset risk threshold to obtain a second comparison result;

[0029] A risk blocking operation is performed on the request data according to the user risk value, the first comparison result, and the second comparison result.

[0030] In one implementation, the preset risk threshold includes a first preset risk threshold, a second preset risk threshold, and a third preset risk threshold, the first preset risk threshold is greater than the second preset risk threshold, the second preset risk threshold is greater than the third preset risk threshold, and a risk blocking operation is performed on the request data according to the user risk value, the first comparison result, and the second comparison result, including:

[0031] When the first comparison result is that the risk value of the requested data is greater than or equal to the first preset risk threshold, performing a risk blocking operation on the requested data;

[0032] When the first comparison result is that the risk value of the requested data is greater than or equal to the second preset risk threshold and less than the first preset risk threshold, and at the same time, the user risk value is greater than or equal to the preset user risk value, a risk blocking operation is performed on the requested data;

[0033] When the first comparison result is that the risk value of the requested data is greater than or equal to the third preset risk threshold and less than the second preset risk threshold, and at the same time, the second comparison result is that the risk value of the returned data is greater than or equal to the first preset risk threshold, a risk blocking operation is performed on the requested data.

[0034] In a second aspect, an embodiment of the present application provides a data protection device, which has the function of implementing the method in the first aspect or any possible implementation thereof. Specifically, the device includes a unit for implementing the method in the first aspect or any possible implementation thereof.

[0035] In one embodiment, the device comprises:

[0036] An acquisition unit, used for acquiring request data;

[0037] A processing unit, used to identify the risk of the request data by using the request data analysis model to obtain a risk value of the request data;

[0038] The processing unit is also used to retrieve corresponding return data according to the request data;

[0039] The processing unit is also used to identify risks of the returned data using the returned data analysis model to obtain a risk value of the returned data, wherein both the request data analysis model and the returned data analysis model are obtained by training using a single-class classification algorithm;

[0040] The processing unit is also used to perform a risk blocking operation on the request data when at least one of the request data risk value and the return data risk value meets a preset risk threshold.

[0041] In a third aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the computer device implements a method according to any one of the implementation modes of the first aspect.

[0042] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a computer device, the computer device implements the method of any one of the implementation methods of the first aspect above.

[0043] In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a computer device, the computer device executes a method of any one of the implementation modes of the first aspect above.

[0044] Compared with the prior art, the embodiments of the present application have the following beneficial effects: by using a request data analysis model trained by a single-class classification algorithm to identify risks in request data, and by using a return data analysis model trained by a single-class classification algorithm to identify risks in return data, legitimate requests and abnormal behaviors can be accurately identified, ensuring low false alarm and missed alarm rates; and the model structure and calculation process are relatively simple, with high real-time performance; the request data analysis model and the return data analysis model are used for two-way risk identification, and compared with the traditional solution of only identifying risks for request data, the security of both the request side and the response side is considered at the same time, so that a stronger defense hierarchy can be formed. Even if an attacker tries to bypass the security measures on the request side, security monitoring can be performed again on the response side. Once a risk is detected on either side, a risk blocking operation can be performed. This method can effectively respond to various complex network attacks and reduce the risk of data leakage. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1It is a scenario diagram of a protection method in a traditional solution provided in an embodiment of the present application.

[0046] Figure 2 It is a flow chart of a data protection method provided in an embodiment of the present application.

[0047] Figure 3 It is a schematic diagram of the principle of a support vector data description algorithm provided in an embodiment of the present application.

[0048] Figure 4 It is a schematic diagram of the overall process of a data protection method provided in an embodiment of the present application.

[0049] Figure 5 It is a structural schematic diagram of a data protection device provided in an embodiment of the present application.

[0050] Figure 6 It is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] When providing API call services to external parties, in order to prevent the API from being maliciously attacked and affecting the company's network business, the company often performs security protection on the API.

[0052] Combine the following Figure 1 Let's explain in detail the application scenario of a protection method when calling an API.

[0053] Figure 1 It is a scenario diagram of a protection method in a traditional solution provided in an embodiment of the present application.

[0054] like Figure 1 As shown in the figure, traditional methods mainly rely on rule-based or decision tree-based methods, which are usually rules written or trained models based on known threat features to match and restrict suspected malicious traffic. However, this method cannot effectively identify new types of attacks and cannot provide comprehensive protection.

[0055] In response to the above problems, this application proposes a data protection method that can timely and comprehensively prevent the risk of data leakage during API calls.

[0056] In order to further illustrate the technical solution of the present application, specific embodiments are provided below.

[0057] Figure 2 It is a flow chart of a data protection method provided in an embodiment of the present application.

[0058] like Figure 2 As shown, the above method includes the following steps S201 to S205.

[0059] S201. Obtain request data.

[0060] Request data refers to the data corresponding to the API request initiated by the caller to the API service.

[0061] The caller is the party that initiates an API request to the API service, including but not limited to browsers, mobile applications, server-side programs, or any other client that can initiate HTTP requests.

[0062] API is a software interface that defines the standards and protocols for how different software components communicate with each other. For example, the protocol for calling the API here can be HTTP.

[0063] As an example but not a limitation, the content of the request data may include the following parts:

[0064] The request method specifies the HTTP method used, such as GET (get data), POST (submit data), PUT (update data), or DELETE (delete data).

[0065] The request URL, that is, the endpoint address of the API, points to a specific resource or service.

[0066] The request header contains a lot of meta information about the request, such as authentication information (such as API key), content type (such as JSON or XML), user agent (browser or application type), etc.

[0067] The request body. In some cases (usually POST and PUT requests), the request body contains the data to be sent, usually in JSON or XML format, such as the resource to be created or updated.

[0068] Query parameters are additional parameters that can be included in the request URL to filter or modify the returned data.

[0069] By obtaining the request data, the API service can identify the caller's intention and make corresponding processing.

[0070] S202: Use the request data analysis model to identify risks of the request data and obtain a risk value of the request data.

[0071] The request data analysis model is an artificial intelligence model built based on the normal request data of each API. The model uses single-class classification technology and can make decisions by identifying whether the request is legitimate, thereby effectively resisting unknown attack methods such as zero-day attacks and ensuring data security.

[0072] First, collect normal request data samples for each API. These samples should cover various normal request types, parameter settings, request headers, and other information. Perform feature extraction on the collected data to identify the most valuable features for risk assessment. For example, analyze the source IP address, request method, request parameters, request frequency, etc.

[0073] Use single-class classification algorithms, such as Gaussian probability density estimation-based methods, autoencoder methods, clustering-based methods, K-nearest neighbor-based methods, one-class support vector machines (One-Class SVM), support vector data description (SVDD), etc., to train with normal request data and identify abnormal requests that are significantly different from these normal patterns. Use normal request data to train the model so that it can learn the characteristics and patterns of normal requests. This training process helps the model establish a baseline of "normal mode".

[0074] Deploy the trained model to the API service, monitor real-time requests, and pass the data of each request to the model for evaluation. The model will generate a request data risk value for each request, which is used to indicate the degree of deviation of the request from a normal request. As an example and not a limitation, the request data risk value can range from 0 to 1. It can be understood that a higher risk value indicates a higher risk of attack.

[0075] S203. Retrieve corresponding return data according to the request data.

[0076] Return data refers to the response data sent back to the caller by the API service after successfully processing the request. It usually contains the result of the request, status information, and related metadata.

[0077] By way of example and not limitation, the returned data may include the following:

[0078] Status code: The returned data usually contains an HTTP status code to indicate the processing result of the request. For example: 200 OK means the request is successful and normal data is returned; 404 Not Found means the requested resource does not exist; 500 Internal Server Error means an error occurred when the server processed the request.

[0079] The response body is usually the specific return data, which contains the result of the request. Depending on the function of the API, the content format of the response body may be JSON, XML or other formats.

[0080] For example, suppose there is a RESTful API for obtaining user information. The API request URL is GET / api / users / 123, where 123 is the user's ID.

[0081] The request code can be expressed as:

[0082] GET / api / users / 123HTTP / 1.1

[0083] Host:example.com

[0084] Accept:application / json

[0085] The content of the response body corresponding to this request can be expressed in code as follows:

[0086] HTTP / 1.1 200OK

[0087] Content-Type:application / json

[0088] {

[0089] "id":123,

[0090] "name":"Alice",

[0091] "email":"alice@example.com",

[0092] "age":30

[0093] }

[0094] Metadata. Sometimes the returned data will also contain other metadata, such as paging information, processing time, etc., for subsequent use by the caller.

[0095] It is understandable that the content of the returned data depends on the design and logic of the API. It provides the caller with necessary information for subsequent processing according to business needs. The content of the returned data corresponding to different API requests is not the same. The specific content can be adjusted according to the actual situation and will not be repeated here.

[0096] S204: Use the returned data analysis model to identify risks of the returned data and obtain a risk value of the returned data.

[0097] Both the request data analysis model and the return data analysis model are trained using a single-class classification algorithm.

[0098] Similar to the principles of the request data analysis model mentioned above, a unique artificial intelligence model is established here based on the normal return data of each API. The return data analysis model also uses single-class classification technology for modeling and threat assessment.

[0099] First, collect samples of returned data under normal circumstances, which can also be understood as the data returned normally after calling the API service. For example, when a product API requests the details of a product, the data returned should be the complete information of the product.

[0100] Use a single-class classification algorithm, for example, Gaussian probability density estimation-based method, autoencoder method, clustering-based method, K-nearest neighbor-based method, one-class support vector machine (One-Class SVM), support vector data description (SVDD) and other algorithms, and use normal return data for training to allow the model to learn the characteristics, structure and pattern of normal returns, thereby forming a "normal return" benchmark.

[0101] The trained return data analysis model is applied to the real-time return data stream. After each API response, the return data is passed into the return data analysis model for evaluation to generate a return data risk value, which is used to indicate the degree of deviation of the return data from the normal mode. As an example and not a limitation, the return data risk value can range from 0 to 1. It can be understood that if the return data exceeds the preset normal range, the corresponding return data risk value is high.

[0102] Establishing a return data analysis model can be effectively combined with the request data analysis model to achieve a two-way risk fusion assessment of request data and return data, and then infer the risk suspicion level of the entire request process, thereby overcoming the limitations of one-way independent risk judgment in traditional solutions.

[0103] S205: When at least one of the risk value of the requested data and the risk value of the returned data meets a preset risk threshold, a risk blocking operation is performed on the requested data.

[0104] The preset risk threshold can be flexibly set according to actual conditions. As an example but not a limitation, combined with the above-mentioned request data risk value / return data risk value, the value range can be 0 to 1, and the preset risk threshold can be set to 0.8.

[0105] By setting a preset risk threshold, it is determined whether the request is within an acceptable normal range. If the risk value of the request data and / or the risk value of the returned data exceeds the preset risk threshold, a risk blocking operation can be performed on the request data.

[0106] Risk blocking operations refer to operations that prevent data leakage.

[0107] As an example and not limitation, risk blocking operations may include, but are not limited to, preventing the execution of a request, issuing a warning or recording a log, sending an alarm notification to a security center, temporarily disabling a user account as needed, etc.

[0108] The specific risk blocking operations can be flexibly set according to the actual situation of the caller and will not be elaborated here.

[0109] By using a request data analysis model trained with a single-class classification algorithm to identify risks in request data, and by using a return data analysis model trained with a single-class classification algorithm to identify risks in return data, legitimate requests and abnormal behaviors can be accurately identified, ensuring low false alarm and missed alarm rates. In addition, the model structure and calculation process are relatively simple, with high real-time performance. Compared with traditional solutions that only identify risks for request data, the request data analysis model and the return data analysis model are used for two-way risk identification. Considering the security of both the request side and the response side at the same time, a stronger defense hierarchy can be formed. Even if an attacker tries to bypass the security measures on the request side, security monitoring can be performed again on the response side. Once risks are detected on either side, risk blocking operations can be performed. This approach can effectively respond to various complex network attacks and reduce the risk of data leakage.

[0110] In one implementation, a request data analysis model is used to identify risks of request data to obtain a risk value of the request data, including: classifying the request data according to the request type of the request data, the request type including at least one of the following: obtain request, submit request, update request, delete request, and each request type corresponding to the request data has a corresponding request data analysis model constructed; according to the request data analysis model corresponding to each request type, the request data is identified for risks to obtain a risk value of the request data.

[0111] In conjunction with the above, the request types for requesting data include GET (getting data), POST (submitting data), PUT (updating data) or DELETE (deleting data).

[0112] In API parsing, different HTTP request methods (such as PUT, GET, etc.) are managed separately, and independent API objects are defined for each API request to model it. In other words, a request data analysis model is independently constructed for GET type request data, a request data analysis model is independently constructed for POST type request data, a request data analysis model is independently constructed for PUT type request data, and a request data analysis model is independently constructed for DELETE type request data.

[0113] Combined with relevant principles, in layman's terms, the core idea of ​​the single-class classification algorithm is to use normal sample data to construct a "normal range" and compare the new data with the "normal range". If the new data belongs to the "normal range", it is considered to be normal data, otherwise it is abnormal data.

[0114] Therefore, by inputting a certain request data into the request data analysis model trained by the single-class classification algorithm, the request data risk value of the request data can be obtained by calculating the distance between the request data and the "normal range". It can also be understood that the closer the distance between the request data and the "normal range", the lower the request data risk value; the farther the distance between the request data and the "normal range", the higher the request data risk value.

[0115] The specific method of calculating the distance between the request data and the "normal range" varies according to different algorithms, and can be calculated according to the actually adopted algorithm, which will not be listed here one by one.

[0116] By separating the management and independently analyzing the request data of different request types according to the HTTP request method, and establishing the corresponding request data analysis model, and using the corresponding request data analysis model to analyze the request data, it is possible to achieve refined risk assessment of the request data. This method not only optimizes the efficiency of threat identification, but also improves the accuracy of security protection, and can respond to various potential security threats in a timely manner.

[0117] In one implementation, the single-class classification algorithm includes a support vector data description algorithm. Before obtaining the request data, the method further includes: obtaining a request data training set corresponding to each request type; determining the request data training input dimension based on the request data training set corresponding to each request type, the request data training input dimension including parameter feature coding and parameter abnormality feature coding, the parameter feature coding including value characteristics and value length, the parameter abnormality feature coding including the number of abnormal characters, the number of special characters and keyword combinations, and the number of keywords; performing model training based on the support vector data description algorithm and the request data training input dimension to obtain a request data analysis model corresponding to each request type.

[0118] In order to improve the quality of training data, the request data training set is the request data of high-credibility users.

[0119] High-confidence users are users with the following characteristics:

[0120] Long registration time: This type of users usually have a long account history, indicating that they have established a long-term trust relationship with the platform and are not hidden users.

[0121] Daily active users: These users frequently use platform services, demonstrate high levels of activity, and avoid illegal hidden user behavior.

[0122] No suspicious operations have been found in the past: No suspicious behavior or operations have been found in the history of this type of user.

[0123] Request sources from trusted IP addresses: Requests from such users usually come from known trusted IP addresses, reducing the possibility of malicious behavior.

[0124] The principle of the single-class classification algorithm is introduced in detail below.

[0125] Single-class classification is particularly effective when dealing with two types of learning problems, one of which (called the target class) has sufficient samples, while the other (called the anomaly class) has very few samples. This feature is particularly evident in the API threat data scenario, because the proportion of effective threat attack methods is extremely low compared to normal access requests. The goal of single-class classification is to construct a decision boundary that can accurately surround the samples of the target class in order to distinguish normal objects from abnormal objects.

[0126] Commonly used single-class classification methods include methods based on Gaussian probability density estimation, autoencoder method, clustering-based method, K-nearest neighbor-based method, one-class support vector machine (One-Class SVM), support vector data description (SVDD), etc. The core of these methods is to characterize a covering relationship to accurately describe the distribution of normal samples and distinguish them from abnormal samples.

[0127] Combine the following Figure 3 Support Vector Data Description (SVDD) is introduced as the training model algorithm.

[0128] Figure 3 It is a schematic diagram of the principle of a support vector data description algorithm provided in an embodiment of the present application.

[0129] like Figure 3 As shown, SVDD is similar to a one-class support vector machine (One-Class SVM), but it achieves classification by learning a hypersphere instead of a hyperplane.

[0130] Specifically, the goal of SVDD is to find a minimum hypersphere in a given data set so that all normal data points are located inside or on the surface of the hypersphere, while minimizing the number of data points outside the hypersphere. The center and radius of this hypersphere constitute the model parameters of SVDD. If the distance of a data point from the center of the hypersphere exceeds the radius, the point is considered an outlier. Therefore, SVDD can efficiently identify outliers that are outside the normal data distribution.

[0131] After determining the algorithm used to train the model, you also need to determine the input dimension of the requested data training when building the model. This input dimension determines the type and depth of data features that the model can capture, and directly affects the accuracy and effectiveness of the model.

[0132] When building a request model, first determine the maximum number of parameters in the request data training set, and then determine the maximum number of dimensions of the model input (the request data training input dimension). Once the maximum number of parameters is determined, the number will be used as the input dimension of the model during model training. The following is an introduction based on the relevant principles.

[0133] In an API request, a parameter is an element used to pass information, such as a query string in an HTTP request or a key-value pair contained in the request body. Each API may involve multiple parameters, which can be used to configure the behavior of the request or pass data.

[0134] To ensure that the model can handle all situations, you need to find out the maximum number of parameters allowed by the API in the training set of request data. For example, if an API request contains 10 parameters in some cases and only 5 parameters in other cases, then you will focus on the maximum number of parameters for this API, which is 10. In other words, because API requests usually do not contain all possible parameters in each call, you only need to focus on the maximum number of parameters during training.

[0135] Each parameter consists of two parts, which constitute the training dimension and their positions in the vector table are fixed. These two dimensions are parameter feature encoding and parameter anomaly feature encoding.

[0136] The parameter feature code consists of two parts. The first two bytes are used to describe the characteristics of the value composition (which can be simply referred to as value characteristics), and the second two bytes are used to record the length of the value (which can be simply referred to as value length).

[0137] The parameter abnormality feature encoding is divided into three parts: the front, middle and back. The front byte records the number of abnormal characters, the middle byte records the number of special characters and keywords, and the back 2 bytes record the number of keywords.

[0138] The following is a detailed introduction in combination with Table 1 and Table 2.

[0139] Table 1 is a value characteristic coding table provided in an embodiment of the present application.

[0140] Table 1

[0141]

[0142]

[0143] By integrating the parameter feature coding and parameter abnormality feature coding of each parameter, the feature of each parameter can be obtained.

[0144] Table 2 is a schematic table of request data analysis model parameters provided in an embodiment of the present application.

[0145] Table 2

[0146]

[0147] In combination with the above, it can be understood that the request data is preprocessed, including data cleaning, data generalization and other processing, and then the parameter extraction processing is performed. The extracted parameters are encoded according to the encoding rules corresponding to the parameter feature encoding and parameter abnormality feature encoding mentioned above to obtain the features corresponding to each parameter, and the parameter feature encodings and parameter abnormality feature encodings of all parameters are integrated into an array of a fixed format to obtain the request data analysis model parameters. The request data analysis model parameters are trained using the support vector data description (SVDD) algorithm to obtain the calculation result of each parameter, that is, according to the distance from the data corresponding to each parameter to the center of the hypersphere, it is determined whether each parameter is located inside or on the surface of the hypersphere or outside the hypersphere, and the request data risk value of the request data is determined by calculating the distance between the request data and the center of the hypersphere.

[0148] For example, when the distance between the request data and the center of the hypersphere is less than or equal to the radius, the risk value of the request data is 0.

[0149] For another example, when the distance between the request data and the center of the hypersphere is greater than the radius (the radius is represented by R), assuming that the distance is 1.9R, the risk value of the request data is determined to be 0.9.

[0150] It can be understood that the mapping relationship between the specific distance between the request data and the center of the hypersphere and the risk value of the request data can be flexibly set according to the specific situation, and is not limited here.

[0151] In other words, the model will calculate whether the current input value deviates from the value in the training model. During training, the model will calculate and confine the normal data in a sphere. When the model is applied, the abnormal value will be outside the sphere, that is, it deviates from the normal range. The risk value of the request data ranges from 0 to 1. Assuming that the normal value is 0.9, then values ​​greater than 0.9 are abnormal values.

[0152] After training according to the training method above, you can get the trained request data analysis model.

[0153] When an API call is received, the corresponding request data analysis model is selected according to the request type (such as PUT or GET) to perform risk analysis and obtain the corresponding request data risk value.

[0154] It is worth noting that for each type of request data, the construction and training of the request data analysis model are carried out independently. The request data analysis models corresponding to different types of request data have the same training principles but different training parameters. Finally, the request data analysis models obtained through training are different.

[0155] It is understandable that the training focus corresponding to different types of request data can be flexibly set. As an example and not a limitation, in a certain application scenario, PUT / member may focus on the validity of the updated field (such as email format, name length, etc.). GET / member focuses on the existence and format of the user ID.

[0156] Using the support vector data description algorithm as the model algorithm, it is easy to obtain sufficient training data sets required for training, and it can converge quickly on the training data sets; it can accurately identify legitimate requests and abnormal behaviors, ensuring low false alarm rates and missed alarm rates; it can complete request processing and response in a short time, meeting the real-time requirements of API calls; at the same time, the parameter scale is small, which can reduce the consumption of computing resources and is more suitable for deployment in actual application scenarios.

[0157] In one implementation, a return data analysis model is used to identify risks in the return data to obtain a return data risk value, including: classifying the return data according to the request type of the request data, and constructing a corresponding return data analysis model for the return data corresponding to each request type; identifying risks in the return data according to the return data analysis model corresponding to each request type to obtain a return data risk value.

[0158] Corresponding to the request data analysis model above, the request types include GET (get data), POST (submit data), PUT (update data) or DELETE (delete data).

[0159] For GET type return data, an independent return data analysis model is constructed, for POST type return data, an independent return data analysis model is constructed, for PUT type return data, an independent return data analysis model is constructed, and for DELETE type return data, an independent return data analysis model is constructed.

[0160] Combined with the above, we can know that by inputting a certain return data into the return data analysis model trained by the single-class classification algorithm, the return data risk value of the return data can be obtained by calculating the distance between the return data and the "normal range". It can also be understood that the closer the distance between the return data and the "normal range", the lower the return data risk value; the farther the distance between the return data and the "normal range", the higher the return data risk value.

[0161] The specific method of calculating the distance between the returned data and the "normal range" varies according to different algorithms. The calculation can be performed based on the algorithm actually used, and will not be listed here one by one.

[0162] In one implementation, a return data training set corresponding to each request type is obtained; the return data training input dimension is determined based on the return data training set corresponding to each request type, and the training input dimension includes at least one of the following: return status code, request data risk value, number of return content types, amount of returned data, and total amount of returned data within a preset time period; model training is performed based on a support vector data description algorithm and the return data training input dimension to obtain a return data analysis model corresponding to each request type.

[0163] The return status code is the status code returned by the server when responding to a request. It directly reflects the success or failure of the request and the specific response type. For example, 200 means success, 404 means resource not found, etc. By analyzing the return code, the model can identify common abnormal response patterns.

[0164] The request data risk value is the risk score calculated based on the request data analysis model above, which reflects the potential threat level of the request itself. A higher request risk value means that the request may have a higher security risk.

[0165] The number of returned content types refers to the number of different content categories in the response data, which is mainly used to quantify the number of different types of information or data elements contained in the response data. By parsing structured data such as JSON, different content categories can be identified, such as different field names or specific data structures.

[0166] The amount of returned data, also known as the current data volume, refers to the actual size of the response data. Abnormal data volume (too large or too small) is an indicator of abnormal behavior and can enhance the recognition ability of the model.

[0167] The total amount of returned data within a preset time period refers to the total size of the user identification code response data within a preset time period (e.g., within the past 24 hours). By monitoring the data volume trend over a period of time, abnormal access patterns or signs of data leakage can be discovered.

[0168] The following is a detailed introduction in conjunction with Table 3.

[0169] Table 3 is a schematic table of return data analysis model parameters provided in an embodiment of the present application.

[0170] Table 3

[0171]

[0172]

[0173] Taking the first row of data in Table 3 as an example, it can be seen that the return status code is 200, the request data risk value is 0.98, the number of returned content types is 5, the amount of returned data is 20, and the total amount of returned data within the preset time period is 0.

[0174] The support vector data description (SVDD) mentioned above is used as the training model algorithm, and the return status code, request data risk value, number of return content types, amount of returned data, and total amount of returned data within a preset time period are used as input parameters to train the return data analysis model, that is, the return data is preprocessed, including data cleaning, data generalization, etc., and then parameter extraction is performed. The extracted parameters are processed according to Table 3 to obtain the return data analysis model parameters, and the support vector data description (SVDD) algorithm is used to train the return data analysis model parameters to obtain the calculation result of each parameter (that is, according to the distance from the data corresponding to each parameter to the center of the hypersphere, it is determined whether each parameter is located inside or on the surface of the hypersphere or outside the hypersphere), and the return data risk value of the return data is determined by calculating the distance between the return data and the center of the hypersphere.

[0175] For example, when the distance between the returned data and the center of the hypersphere is less than or equal to the radius, the risk value of the returned data is 0.

[0176] For another example, when the distance between the returned data and the center of the hypersphere is greater than the radius (the radius is represented by R), assuming that the distance is 1.5R, the risk value of the returned data is 0.5.

[0177] The principle of specific training model is the same as the principle of requesting data analysis model above, which will not be repeated here. After the training is completed, the trained return data analysis model can be obtained.

[0178] In one implementation, a risk blocking operation is performed on the request data, including: obtaining label data of the requesting user, the label data is used to calculate the user risk value of the requesting user; comparing the risk value of the request data with a preset risk threshold to obtain a first comparison result; comparing the risk value of the returned data with the preset risk threshold to obtain a second comparison result; and performing a risk blocking operation on the request data according to the user risk value, the first comparison result, and the second comparison result.

[0179] Label data includes but is not limited to user registration duration, user daily activity, historical risk operations, whether the IP address is trustworthy, and other data that can represent the user's credibility.

[0180] As an example but not limitation, the user risk value of the requesting user may be determined according to the value of the tag data.

[0181] The following is a detailed introduction in conjunction with Table 4.

[0182] Table 4 is a comparison table of label data and user risk values ​​provided in an embodiment of the present application.

[0183] Table 4

[0184]

[0185]

[0186] The specific user risk value varies according to the actual situation and will not be elaborated here.

[0187] The request data risk value is compared with the preset risk threshold to obtain a first comparison result, that is, by comparing the numerical values ​​of the request data risk value and the preset risk threshold, the request data risk value may be greater than, less than, or equal to the preset risk threshold.

[0188] Similarly, the returned data risk value is compared with the preset risk threshold to obtain a second comparison result, that is, the numerical values ​​of the returned data risk value and the preset risk threshold are compared. The returned data risk value may be greater than, less than, or equal to the preset risk threshold.

[0189] The user risk value, the first comparison result, and the second comparison result are comprehensively considered to determine whether to perform the risk blocking operation.

[0190] In one implementation, the preset risk threshold includes a first preset risk threshold, a second preset risk threshold, and a third preset risk threshold, the first preset risk threshold is greater than the second preset risk threshold, the second preset risk threshold is greater than the third preset risk threshold, and a risk blocking operation is performed on the request data according to the user risk value, the first comparison result, and the second comparison result, including:

[0191] When the first comparison result is that the risk value of the requested data is greater than or equal to the first preset risk threshold, performing a risk blocking operation on the requested data;

[0192] When the first comparison result is that the risk value of the requested data is greater than or equal to the second preset risk threshold and less than the first preset risk threshold, and at the same time, the user risk value is greater than or equal to the preset user risk value, a risk blocking operation is performed on the requested data;

[0193] When the first comparison result is that the risk value of the requested data is greater than or equal to the third preset risk threshold and less than the second preset risk threshold, and at the same time, the second comparison result is that the risk value of the returned data is greater than or equal to the first preset risk threshold, a risk blocking operation is performed on the requested data.

[0194] As an example but not a limitation, assuming that the first preset risk threshold is 0.9, the second preset risk threshold is 0.8, and the third preset risk threshold is 0.7, and the preset user risk value is 1, it can be understood that:

[0195] When the risk value of the requested data is ≥ 0.9, the risk blocking operation is directly performed on the requested data;

[0196] When 0.8≤Request data risk value<0.9 and user risk value≥1, perform risk blocking operation on the requested data;

[0197] When 0.7≤request data risk value<0.8 and return data risk value≥0.9, perform risk blocking operation on the request data.

[0198] In other words, it can also be understood that the request data risk value is greater than or equal to the first preset risk threshold, which is a high risk; the request data risk value is greater than or equal to the second preset risk threshold and less than the first preset risk threshold, which is a medium risk; the request data risk value is greater than or equal to the third preset risk threshold and less than the second preset risk threshold, which is a low risk (or no risk).

[0199] When the risk value of the requested data is high, the request will be blocked directly.

[0200] When the risk value of the requested data is medium risk, the system will further evaluate it based on the user's credibility to decide whether to allow the request to continue.

[0201] When the risk value of the requested data is low risk (or no risk), the system will combine the risk value of the returned data to comprehensively determine whether the returned data should be blocked.

[0202] It can be understood that the preset risk threshold can be appropriately adjusted for different APIs, that is, the range of high risk, medium risk and low risk can be flexibly adjusted.

[0203] As an example but not limitation, the first preset risk threshold of the request data analysis model corresponding to a PUT type request can be set to 0.7, the first preset risk threshold of the request data analysis model corresponding to a GET type request can be set to 0.5, and so on.

[0204] Doing so can provide security managers with more flexible adjustment space, especially for some management APIs that have very little access.

[0205] It can be understood that the specific threshold values ​​can be adjusted according to actual conditions and are not listed here one by one.

[0206] Similarly, the preset risk thresholds of the return data analysis models corresponding to different request types may be different.

[0207] Combine the following Figure 4 Let’s give an overall introduction to the data protection methods mentioned above.

[0208] Figure 4 It is a schematic diagram of the overall process of a data protection method provided in an embodiment of the present application.

[0209] like Figure 4 As shown, Figure 4 The process includes the following steps S401 to S407B.

[0210] S401, performing data analysis according to the request data.

[0211] This step is to parse the request data initiated by the caller. The parsing process will classify different methods (such as GET, POST, etc.) and different URIs (Uniform Resource Identifiers) as independent API calls, and send these calls to the corresponding request model for calculation. This process ensures that each API call can be correctly identified and processed, thereby providing accurate data support for subsequent risk assessment.

[0212] S402: Call the request data analysis model.

[0213] This step receives the parsed request data, calls the pre-trained request model to calculate these parameters, and obtains the request data risk value, which reflects the degree of deviation between the request data and normal behavior, thereby helping to determine whether the request data poses a security risk.

[0214] S403: Perform threat analysis based on the risk value of the request data and the user's tag data.

[0215] Combining the examples above, the threat analysis module makes a comprehensive decision based on the risk value of the request data and the user's label data.

[0216] The threat analysis module can make unified management decisions for discovered threats, such as providing unified error return prompts or executing unified blocking actions.

[0217] S404A: When it is determined that there is no risk, the API service is called to obtain the return data.

[0218] Combining the above examples, for requests with a high degree of match (i.e., low risk or no risk), the system will allow them to enter the next step of the data request process.

[0219] S404B. When a risk is identified, execute risk blocking operations.

[0220] For requests with low matching degree (i.e. high risk), the system will directly block them.

[0221] S405: Call and return the data analysis model.

[0222] This step is performed after receiving the data returned by the API server. First, the system will perform feature extraction on the returned data to obtain the input value. Then, the system will call the pre-trained return data analysis model to calculate and obtain the risk value of the returned data.

[0223] This process aims to identify possible anomalies or potential threats in the returned data. After the calculation is completed, the output results of the returned data analysis model will be pushed to the threat assessment module for further comprehensive analysis and decision-making.

[0224] S406: Conduct threat analysis based on the risk value of the returned data and the user tag data.

[0225] In this step, the system will make a comprehensive judgment based on the user's label data, the output results of the requested data analysis model, and the output results of the returned data analysis model.

[0226] Combined with the examples above, based on this information, the system will assess the risk of the returned data and make corresponding decisions.

[0227] The design of the threat analysis module has a certain degree of flexibility. It can be dynamically adjusted according to the specific situation of each API to control the severity of the blocking, and can be better applied to APIs with insufficient sampling rates.

[0228] S407A: When it is determined that there is no risk, the return data is sent to the caller.

[0229] For data with a high match (low risk or no risk), the system will allow it to pass and send the return data to the caller.

[0230] S407B. When a risk is identified, execute risk blocking operations.

[0231] For data with low matching degree (high risk), the system will directly block it.

[0232] Risk blocking is also an important link, which ensures the effective handling of potential threats. When the system identifies high-risk requests or return data, blocking measures will be taken immediately.

[0233] In order to prevent attackers from detecting and exploiting through error messages, the system will use a consistent prompt method or not provide prompt information at all when blocking risks. This approach helps to hide the system's defense mechanism and reduce the risk of reverse engineering by attackers.

[0234] The above mainly introduces the method of the embodiment of the present application in conjunction with the accompanying drawings. It should be understood that although the various steps in the flowcharts involved in the embodiments described above are shown in sequence, these steps are not necessarily performed in sequence in the order shown in the figure. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and these steps can be performed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the embodiments described above may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a part of the steps or stages in other steps. A device of an embodiment of the present application is introduced below in conjunction with the accompanying drawings. For simplicity, when introducing the device below, it will be appropriately omitted, and the relevant content can refer to the relevant description in the method above, and will not be repeated.

[0235] Figure 5 It is a structural schematic diagram of a data protection device provided in an embodiment of the present application.

[0236] like Figure 5 As shown, the device 1000 includes the following units.

[0237] The acquisition unit 1001 is used to acquire request data.

[0238] The processing unit 1002 is used to identify the risks of the request data by using the request data analysis model to obtain the risk value of the request data.

[0239] The processing unit 1002 is further configured to retrieve corresponding return data according to the request data.

[0240] The processing unit 1002 is also used to use the return data analysis model to identify risks of the return data and obtain a risk value of the return data. Both the request data analysis model and the return data analysis model are trained using a single-class classification algorithm.

[0241] The processing unit 1002 is further configured to perform a risk blocking operation on the request data when at least one of the request data risk value and the return data risk value meets a preset risk threshold.

[0242] In one implementation, the device 1000 further includes a storage unit 1003, which can be used to store instructions and / or data, so as to implement the method in the above embodiment.

[0243] In one implementation, the processing unit 1002 is also used to use a request data analysis model to identify risks of the request data and obtain a risk value of the request data, including: classifying the request data according to the request type of the request data, the request type including at least one of the following: obtain request, submit request, update request, delete request, and the request data corresponding to each request type is respectively constructed with a corresponding request data analysis model; identifying risks of the request data according to the request data analysis model corresponding to each request type to obtain a risk value of the request data.

[0244] Different types of requests may face different security threats. For example, a submission request may contain malicious data, while a retrieval request may pose a risk of data leakage. By building a dedicated request data analysis model for each request type (retrieve, submit, update, delete), the risk characteristics unique to each type of request can be captured more accurately. This classification process can improve the accuracy of risk assessment and effectively reduce false positives and false negatives. The classified model can process specific types of requests more quickly and improve response speed. When the request type is clear, the model can apply the appropriate recognition algorithm more quickly, assess risks in real time, and improve the overall efficiency of the system.

[0245] In one implementation, the single-class classification algorithm includes a support vector data description algorithm. Before obtaining the request data, the acquisition unit 101 is also used to obtain a request data training set corresponding to each request type; the processing unit 1002 is also used to determine the request data training input dimension according to the request data training set corresponding to each request type, the request data training input dimension includes parameter feature coding and parameter abnormality feature coding, the parameter feature coding includes value characteristics and value length, and the parameter abnormality feature coding includes the number of abnormal characters, the number of special characters and keyword combinations, and the number of keywords; model training is performed according to the support vector data description algorithm and the request data training input dimension to obtain a request data analysis model corresponding to each request type.

[0246] By encoding the input dimension parameter features and parameter anomaly features, the key information required by the model can be provided, thereby improving the accuracy of the request data analysis model. During the model training process, more representative features can help the model better understand and learn the potential patterns in the data. For example, the number of abnormal characters, special characters, and keyword combinations can be used to determine whether a request has potential injection attacks or other security risks.

[0247] In one implementation, the processing unit 1002 is also used to use a return data analysis model to identify risks in the return data and obtain a risk value for the return data, including: classifying the return data according to the request type of the request data, and constructing a corresponding return data analysis model for the return data corresponding to each request type; identifying risks in the return data according to the return data analysis model corresponding to each request type to obtain a risk value for the return data.

[0248] By identifying risks in the returned data, potential security issues can be effectively detected. Different types of requests may result in different returned data. If the returned data contains sensitive information or abnormal structures, malicious behavior can be identified and blocked in a timely manner to further protect system security. The returned data is classified according to the request type, so that each request type has a targeted return data analysis model. This refined processing can more accurately capture the characteristics and risks of each request type, thereby improving the accuracy and sensitivity of risk identification.

[0249] In one implementation, the acquisition unit 1001 is also used to obtain a return data training set corresponding to each request type; the processing unit 1002 is also used to determine the return data training input dimension based on the return data training set corresponding to each request type, and the training input dimension includes at least one of the following: return status code, request data risk value, number of return content types, amount of returned data, and total amount of returned data within a preset time period; model training is performed according to the support vector data description algorithm and the return data training input dimension to obtain a return data analysis model corresponding to each request type.

[0250] By considering multiple training input dimensions, including return status code, request data risk value, number of return content types, etc., the risk of return data can be comprehensively assessed. This comprehensive risk assessment helps to identify potential security threats in a timely manner. By establishing the boundaries of normal data through the support vector data description algorithm, abnormal return data that deviates from the boundaries can be effectively detected.

[0251] In one implementation, the processing unit 1002 is also used to perform a risk blocking operation on the request data, including: obtaining label data of the requesting user, the label data is used to calculate the user risk value of the requesting user; comparing the risk value of the request data with a preset risk threshold to obtain a first comparison result; comparing the risk value of the returned data with the preset risk threshold to obtain a second comparison result; and performing a risk blocking operation on the request data according to the user risk value, the first comparison result, and the second comparison result.

[0252] Combining the user's label data and the risk value of the request can more accurately identify the user's risk level, identify potential malicious requests or abnormal behaviors, and reduce the probability of missed reports and false positives.

[0253] In one implementation, the preset risk threshold includes a first preset risk threshold, a second preset risk threshold and a third preset risk threshold, the first preset risk threshold is greater than the second preset risk threshold, and the second preset risk threshold is greater than the third preset risk threshold. The processing unit 1002 is also used to perform a risk blocking operation on the request data according to the user risk value, the first comparison result and the second comparison result, including: when the first comparison result is that the risk value of the request data is greater than or equal to the first preset risk threshold, performing a risk blocking operation on the request data; when the first comparison result is that the risk value of the request data is greater than or equal to the second preset risk threshold and less than the first preset risk threshold, and at the same time, the user risk value is greater than or equal to the preset user risk value, performing a risk blocking operation on the request data; when the first comparison result is that the risk value of the request data is greater than or equal to the third preset risk threshold and less than the second preset risk threshold, and at the same time, the second comparison result is that the risk value of the returned data is greater than or equal to the first preset risk threshold, performing a risk blocking operation on the request data.

[0254] Setting multiple levels of preset risk thresholds can achieve more detailed risk management. Different thresholds correspond to different risk levels, which can help the system gradually identify and respond to various potential risks, thereby improving the refinement of security management. According to different threshold settings, different levels of risk response measures can be taken for requests. For example, some requests may only require a warning, while others need to be blocked immediately. This multi-level response mechanism can respond to risks more flexibly. Under the multi-level risk determination framework, enterprises can adjust the settings of each threshold according to specific scenarios and actual needs to ensure that risk management strategies always reflect the latest security environment and risk situation.

[0255] It should be noted that the information interaction, execution process and other contents between the above-mentioned units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0256] Figure 6 Schematic diagram of the structure of the computer device provided in the embodiment of the present application. Figure 6 As shown, the computer device 3000 of this embodiment includes: at least one processor 3100 ( Figure 6 Only one) processor, memory 3200, and a computer program 3210 stored in the memory 3200 and executable on at least one processor 3100 are shown. When the processor 3100 executes the computer program 3210, the computer device implements the steps in the above embodiments.

[0257] The processor 3100 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0258] The memory 3200 may be an internal storage unit of the computer device 3000 in some embodiments, such as a hard disk or memory of the computer device 3000. The memory 3200 may also be an external storage device of the computer device 3000 in other embodiments, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 3000. Further, the memory 3200 may also include both an internal storage unit of the computer device 3000 and an external storage device. The memory 3200 is used to store an operating system, an application program, a boot loader (Boot Loader) data, and other programs, such as a program code of a computer program, etc. The memory 3200 may also be used to temporarily store data that has been output or is to be output.

[0259] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the division of the above-mentioned functional units is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units in the embodiment can be integrated into a processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0260] The embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a computer device, the computer device can implement the steps in the above-mentioned method embodiments.

[0261] The embodiment of the present application provides a computer program product. When the computer program product is executed on a computer device, the computer device can implement the above-mentioned methods.

[0262] If the integrated unit is implemented in the form of 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 present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the computer device can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the camera / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electric carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0263] It should be understood that the size of the sequence number of each step in the above-described embodiment does not mean the order of execution, and the order of execution of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiment of the present application. In the description, for the purpose of explanation rather than for limitation, specific details such as specific system structure, technology and the like are proposed, so as to thoroughly understand the embodiment of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, the detailed description of well-known systems, devices, circuits and methods is omitted to prevent unnecessary details from hindering the description of the present application.

[0264] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0265] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0266] Additionally, in the specification of the present application and the description of the appended claims, the terms “include,” “comprise,” “have,” and their variations all mean “including but not limited to,” unless otherwise specifically emphasized.

[0267] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0268] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0269] In the embodiments provided in the present application, it should be understood that the disclosed devices, computer equipment and methods can be implemented in other ways. For example, the device and computer equipment embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0270] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A data protection method, characterized in that: The method comprises: Get request data; Using the request data analysis model to identify risks of the request data, and obtain a risk value of the request data; Retrieve corresponding return data according to the request data; Using a return data analysis model to identify risks of the return data, and obtaining a return data risk value, wherein both the request data analysis model and the return data analysis model are obtained by training using a single-class classification algorithm; When at least one of the request data risk value and the return data risk value meets a preset risk threshold, a risk blocking operation is performed on the request data.

2. The method according to claim 1, characterized in that The step of using the request data analysis model to identify the risk of the request data to obtain the request data risk value includes: Classify and process the request data according to the request type of the request data, wherein the request type includes at least one of the following: obtain request, submit request, update request, and delete request, and the request data corresponding to each request type is respectively constructed with a corresponding request data analysis model; The request data is subjected to risk identification according to the request data analysis model corresponding to each request type to obtain a risk value of the request data.

3. The method according to claim 2, characterized in that The single-class classification algorithm includes a support vector data description algorithm. Before obtaining the request data, the method further includes: Get the request data training set corresponding to each request type; Determine the request data training input dimension according to the request data training set corresponding to each request type, wherein the request data training input dimension includes a parameter feature code and a parameter abnormality feature code, wherein the parameter feature code includes a value characteristic and a value length, and the parameter abnormality feature code includes the number of abnormal characters, the number of special characters and keyword combinations, and the number of keywords; Model training is performed according to the support vector data description algorithm and the request data training input dimension to obtain a request data analysis model corresponding to each request type.

4. The method according to any one of claims 1 to 3, characterized in that: The step of using the return data analysis model to identify risks of the return data to obtain a risk value of the return data includes: The returned data is classified and processed according to the request type of the request data, and a corresponding returned data analysis model is constructed for the returned data corresponding to each request type; The risk of the returned data is identified according to the returned data analysis model corresponding to each request type to obtain the risk value of the returned data.

5. The method according to claim 4, characterized in that The method further comprises: Get the return data training set corresponding to each request type; Determine the return data training input dimension according to the return data training set corresponding to each request type, wherein the training input dimension includes at least one of the following: return status code, request data risk value, number of return content types, amount of returned data, and total amount of returned data within a preset time period; Model training is performed according to the support vector data description algorithm and the return data training input dimension to obtain a return data analysis model corresponding to each request type.

6. The method according to any one of claims 1 to 3 or 5, characterized in that: The performing a risk blocking operation on the request data includes: Acquire label data of the requesting user, where the label data is used to calculate a user risk value of the requesting user; Comparing the request data risk value with the preset risk threshold to obtain a first comparison result; Comparing the risk value of the returned data with the preset risk threshold to obtain a second comparison result; A risk blocking operation is performed on the request data according to the user risk value, the first comparison result, and the second comparison result.

7. The method according to claim 6, characterized in that The preset risk threshold includes a first preset risk threshold, a second preset risk threshold and a third preset risk threshold, the first preset risk threshold is greater than the second preset risk threshold, the second preset risk threshold is greater than the third preset risk threshold, and the performing a risk blocking operation on the request data according to the user risk value, the first comparison result and the second comparison result includes: When the first comparison result is that the risk value of the request data is greater than or equal to the first preset risk threshold, performing the risk blocking operation on the request data; When the first comparison result is that the risk value of the request data is greater than or equal to the second preset risk threshold and less than the first preset risk threshold, and at the same time, the user risk value is greater than or equal to the preset user risk value, performing the risk blocking operation on the request data; When the first comparison result is that the risk value of the request data is greater than or equal to the third preset risk threshold and less than the second preset risk threshold, and at the same time, the second comparison result is that the risk value of the return data is greater than or equal to the first preset risk threshold, the risk blocking operation is performed on the request data.

8. A data protection device, characterized in that: include: An acquisition unit, used for acquiring request data; A processing unit, configured to identify risks of the request data using a request data analysis model to obtain a risk value of the request data; The processing unit is further used to retrieve corresponding return data according to the request data; The processing unit is further used to identify the risk of the returned data using a returned data analysis model to obtain a risk value of the returned data, wherein both the request data analysis model and the returned data analysis model are obtained by training using a single-class classification algorithm; The processing unit is further configured to perform a risk blocking operation on the request data when at least one of the request data risk value and the return data risk value meets a preset risk threshold.

9. A computer device, characterized in that: The computer device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the computer device implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a computer device, the method according to any one of claims 1 to 7 is implemented.

Citation Information

Patent Citations

  • User behavior analysis method and device, electronic equipment and storage medium

    CN116383812A

  • Crawler identification method and device, computer equipment and storage medium

    CN116955751A

  • Blocking method, device, equipment, medium and system for sensitive data

    CN117436118A

  • Data access method and device, electronic equipment and readable storage medium

    CN117610924A

  • URL attack detection method and apparatus, and electronic device

    US20200195667A1