Risk processing method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a risk processing method and device, electronic equipment, a storage medium and a program product. The method comprises the steps of obtaining access metadata of an application programming interface API; determining a first risk level of the current access request based on the access metadata; and performing risk processing on the current access request based on the first risk level. In conclusion, according to the technical scheme provided by the invention, the risk of the API interface can be comprehensively, accurately and effectively managed, and objective requirements in an actual process can be met.

Description

Technical Field

[0001] This disclosure relates to the field of security technology, and in particular to a risk management method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] Currently, most existing security protections for Application Programming Interfaces (APIs) rely on traditional Web Application Firewalls (WAFs) for overall protection. These methods of risk handling are relatively simple and rigid, and they do not take into account all risk factors. They cannot effectively manage the risks of API interfaces in a comprehensive and accurate manner, and thus cannot meet the objective needs in actual processes. Summary of the Invention

[0003] This disclosure provides a risk management method, apparatus, electronic device, storage medium, and program product to address, to some extent, the problems that existing risk management methods are relatively simple and rigid, and that they do not take into account risk factors comprehensively and accurately, thus failing to effectively manage the risks of API interfaces and failing to meet the objective needs of actual processes.

[0004] According to one aspect of this disclosure, a risk handling method is provided, the method comprising: obtaining access metadata of an application programming interface (API); determining a first risk level of a current access request based on the access metadata; and performing risk handling on the current access request based on the first risk level.

[0005] Furthermore, according to one aspect of the method disclosed herein, the access metadata includes at least one of the following: API visitor, API visitor address, API access time, API identifier, and API sensitivity level.

[0006] Furthermore, according to one aspect of the method disclosed herein, determining a first risk level of a current access request based on access metadata includes: determining a second risk level based on access metadata, the second risk level including at least one of the following: data exposure risk level, protection level level, access time risk level, and access region risk level; and obtaining a first risk level by weighting the second risk level and a weighting coefficient.

[0007] Furthermore, according to one aspect of the method of this disclosure, the first risk level and the second risk level satisfy at least one of the following relationships: the weight coefficient corresponding to the second risk level is positively correlated with the first risk level, and the second risk level includes at least one of the following: data exposure risk level, access time risk level, and access area risk level; the weight coefficient corresponding to the second risk level is negatively correlated with the first risk level, and the second risk level includes: protection level level.

[0008] Furthermore, according to one aspect of the method disclosed, the method also includes: adjusting the weighting coefficient based on the second risk level.

[0009] Furthermore, according to one aspect of the method disclosed herein, adjusting the weighting coefficient based on a second risk level includes: reducing the weighting coefficient when the second risk level does not meet a first threshold, wherein the second risk level includes at least one of the following: access time risk level and access region risk level.

[0010] Furthermore, according to one aspect of the method disclosed herein, determining a second risk level based on access metadata includes at least one of the following: determining the data exposure risk level corresponding to the API identifier based on registration data; determining API security protection devices based on API visitors and API sensitivity levels; summing the weights of the security protection devices to obtain a protection level; determining the initial access time risk level and the first number of API accesses within a preset time period based on API access time; determining the target access time risk level using the ratio of the initial access time level, the first number of accesses, and the historical first number of accesses; determining the initial access region risk level and the second number of API accesses within the corresponding region based on the API visitor address; and determining the target access region risk level using the ratio of the initial access region level, the second number of accesses, and the historical second number of accesses.

[0011] Furthermore, according to one aspect of the method disclosed herein, risk processing is performed on the current access request based on a first risk level, including: responding to the current access request when the first risk level meets a second threshold; and rejecting the current access request and issuing a risk warning when the first risk level does not meet the second threshold.

[0012] Furthermore, according to one aspect of the method disclosed, the method also includes: obtaining the access volume of the API; and performing risk handling on the current access request based on the access volume and a third threshold.

[0013] According to another aspect of this disclosure, a risk processing apparatus is provided, comprising: an acquisition unit for acquiring access metadata of an application programming interface (API); a determination unit for determining a first risk level of a current access request based on the access metadata; and a management unit for performing risk processing on the current access request based on the first risk level.

[0014] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory for storing computer-readable instructions; and a processor for executing the computer-readable instructions, causing the electronic device to perform the method as described in any embodiment of one aspect.

[0015] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided for storing computer-readable instructions that, when executed by a processor, cause the processor to perform the method as described in any embodiment of one aspect.

[0016] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method as described in any embodiment of one aspect.

[0017] This disclosure provides a risk management method, apparatus, electronic device, storage medium, and program product. This disclosure determines the first risk level of a current access request by obtaining the API's access metadata, thereby performing risk management on the current request. In this way, this disclosure can dynamically determine the risk level corresponding to an access request directly through its access metadata, and then perform risk management. Compared to existing methods that solely utilize WAF protection, this disclosure can specifically determine the risk level of an access request, thus performing precise risk management. Furthermore, it can consider multiple influencing factors of the access request, flexibly determining the risk level, thus performing comprehensive risk management. In summary, the technical solution provided by this disclosure can comprehensively and accurately manage the risks of API interfaces effectively, meeting the objective needs of practical processes.

[0018] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0019] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0020] Figure 1 An architecture diagram of a risk management system provided in this disclosure embodiment;

[0021] Figure 2 A flowchart illustrating a risk management method provided in an embodiment of this disclosure;

[0022] Figure 3 A schematic flowchart illustrating risk handling provided for embodiments of this disclosure;

[0023] Figure 4 A structural block diagram of a risk management device provided in an embodiment of this disclosure;

[0024] Figure 5 A hardware block diagram of an electronic device provided in an embodiment of this disclosure;

[0025] Figure 6 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this disclosure. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0027] Currently, most existing security protections for Application Programming Interfaces (APIs) rely on traditional Web Application Firewalls (WAFs) for overall protection. However, WAFs typically only implement API security protection when they detect sensitive data fields or a large amount of traffic, determining whether the API access is abnormal.

[0028] This shows that the existing risk management methods are relatively simple and rigid, and do not take into account all risk factors. They cannot effectively manage the risks of API interfaces in a comprehensive and accurate manner, and are difficult to meet the objective needs in actual processes.

[0029] Therefore, this application proposes a risk management method that can specifically determine the risk level of access requests, thereby enabling precise risk management. Furthermore, it can consider multiple influencing factors of access requests to flexibly determine the risk level, thus enabling comprehensive risk management. Please refer to... Figure 1 , Figure 1 This is an architecture diagram of a risk management system provided in an embodiment of this disclosure. Figure 1 As shown, the risk management system includes at least an internet application management platform. This internet application management platform can be an industrial internet application management platform, a commercial internet application management platform, or an internet application management platform for IoT scenarios; there are no restrictions here. The internet application management platform includes at least an API security gateway module and an API anomaly analysis module.

[0030] The API security gateway module is primarily responsible for API access security and managing API data and traffic. Specifically, it uses at least one protection method, such as authentication and data encryption, to ensure that only legitimate users or applications can access API services. It also records detailed information about all API interactions to facilitate the detection of abnormal behavior and security risks later.

[0031] The API anomaly analysis module is primarily responsible for monitoring, analyzing, and handling anomalies that occur during API operation. Specifically, the module can analyze API call behavior using at least one of the following: API call patterns, performance metrics, and error logs. It can then identify various abnormal access or attack behaviors and provide detailed risk analysis and security handling recommendations.

[0032] Specifically, in actual use, the API security gateway module can receive access requests from users or applications, thereby obtaining API access data. The API security gateway module forwards the API access data to the API anomaly analysis module. The API anomaly analysis module can analyze and process the received access data to determine whether to respond to the access request by directly accessing the target application or to deny the access request and return the result to the API security gateway module. The specific implementation process is not limited here.

[0033] The embodiments of this application do not impose any particular restrictions on the specific technologies used in the API security gateway module or the API anomaly analysis module.

[0034] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a risk management method provided in an embodiment of this disclosure. Figure 2 As shown, the method includes:

[0035] In step S201, the access metadata of the application programming interface (API) is obtained.

[0036] In this disclosure, access metadata can be understood as all relevant data of the API corresponding to the access request. This information is crucial for understanding API usage and identifying at least one potential security threat. The access metadata in this disclosure includes, but is not limited to, at least one of the following: API visitor, API visitor address, API access time, API identifier, and API sensitivity level. These data can all significantly impact the final risk level assessment. Specifically, an API visitor can be understood as information related to at least one of the user, system, and application that initiated the access request. If the API visitor is a known, reputable user, system, or application, this means the risk level is low, and the access can be allowed directly. Conversely, if the API visitor is from an unknown source, a malicious attacker, or has a history of suspicious behavior, this means the risk level is high, and the access can be restricted or denied to ensure access security. An API visitor address can be understood as the IP address or network location of the user, system, or application that initiated the access request. If the API access address originates from an internal network security zone, this also means the risk level is low, and the access can be allowed directly. However, if the API access address originates from IP address ranges frequently associated with malicious activity (such as known hacker server address ranges, malware common jump server addresses, etc.), or addresses that change frequently and do not conform to normal business logic, this indicates a high risk level for the access. The access can be restricted or denied to ensure security. API access time can be understood as the time period during which the API receives and processes data. If the API access time falls within normal business hours or conforms to business patterns, it indicates a low risk level, and the access can be allowed. However, if a large number of API accesses occur outside of working hours (such as early morning) or during periods with very low business activity, this indicates a high risk level, and the access can be restricted or denied to ensure security. The API identifier can be understood as a unique identifier for the accessed API. If the API identifier is related to ordinary business or non-critical business processes, it indicates a low risk level, and the access can be allowed. If an API is accessed that relates to core business operations or contains important data (such as financial data APIs or user privacy data APIs), it indicates a high level of risk. Access can be restricted or denied to ensure security. API sensitivity level can be understood as the degree of sensitivity of the API operation or the data returned.If the API has a low sensitivity level (such as a public information query API), it means the risk level is low, and access can be granted directly. If the API has a high sensitivity level (such as password modification, account permission change, or critical data deletion), it means the risk level is high, and access can be restricted or denied to ensure access security. Specific access metadata is not limited here and can be flexibly adjusted according to system devices or user needs.

[0037] In this embodiment of the disclosure, an API security gateway module can be used to receive at least one access request for a target application from users, systems, and applications, and then obtain the access metadata of the API corresponding to the access request.

[0038] Specifically, this can be achieved through the API security gateway module, which listens for and receives access requests from at least one source (such as users accessing services through a web interface, internal system service calls, or inter-application communication). These requests aim to access services provided by the target application, which requires calling the corresponding API. Upon receiving a request, the API security gateway performs protocol parsing. After obtaining the basic information of the request, the API security gateway performs authentication and authorization. Once the access request is authenticated and authorized, the API security gateway can obtain the access metadata.

[0039] In step S202, the first risk level of the current access request is determined based on the access metadata.

[0040] In this disclosure, a first risk level can be used to indicate the risk level of a current access request. The first risk level can be represented in at least one form, such as a numerical value or color. For example, the first risk level can be from 1 to 5 (where 1 represents the lowest risk and 5 represents the highest risk). Another example is that the first risk level can be visually displayed using green, yellow, and red (where green represents the lowest risk, yellow represents the medium risk, and red represents the highest risk).

[0041] In this embodiment, the access metadata received by the API anomaly analysis module from the API security gateway module can be used for risk assessment to determine its corresponding first risk level. The assessment process can involve a comprehensive evaluation of at least one factor of the aforementioned access metadata. In other words, the first risk level considers at least one dimension of influencing factors, representing a comprehensive assessment of multi-dimensional risk, and can take into account multiple aspects. This determination of the first risk level provides a more comprehensive and accurate understanding of API usage, offering a solid foundation for subsequent determination of API risks (also known as anomalous behavior).

[0042] In step S203, the current access request is processed for risk based on the first risk level.

[0043] In this embodiment, the API anomaly analysis module can be used to perform corresponding risk handling on the current access request based on a first risk level. Risk handling methods may include, but are not limited to, at least one of the following: blocking high-risk requests, quickly allowing low-risk requests, requiring additional authentication, and conducting more in-depth review of the request. In this way, based on the dynamically determined first risk level, access requests can be handled accurately and comprehensively.

[0044] In this way, this disclosure can dynamically determine the risk level of an access request directly through its access metadata, and then perform risk management accordingly. Compared to existing methods that rely solely on WAF protection, this disclosure can specifically determine the risk level of an access request, thereby enabling precise risk management. Furthermore, it can consider multiple influencing factors of the access request, flexibly determining the risk level for comprehensive risk management. In summary, the technical solution provided by this disclosure can comprehensively and accurately manage the risks of API interfaces, meeting the objective needs of practical applications.

[0045] In one exemplary preferred embodiment, Figure 3 A schematic flowchart illustrating risk handling provided for embodiments of this disclosure. Figure 3 As shown: The API security gateway module can receive access metadata about API access requests and then send this metadata to the API anomaly analysis module. The API anomaly analysis module receives the access metadata from the API security gateway module, parses the request information, calculates the risk level of the API access, and then performs risk handling based on the risk level.

[0046] As mentioned above, the API anomaly analysis module of this disclosure can determine the first risk level by accessing the API access metadata corresponding to the access request. This determination of the first risk level provides a more comprehensive and accurate understanding of API usage, laying a solid foundation for subsequent API risk handling. The following will specifically explain how this disclosure determines the first risk level; the method includes:

[0047] Based on access metadata, a second risk level is determined. The second risk level includes at least one of the following: data exposure risk level, protection level level, access time risk level, and access region risk level.

[0048] Based on the second risk level and weighting coefficient, the first risk level is obtained through weighted processing.

[0049] In this disclosure, the first risk level can be understood as a multi-dimensional comprehensive risk level. The second risk level can be understood as the initial risk level corresponding to each dimension, obtained based on access metadata. The second risk level of this disclosure includes, but is not limited to, at least one of the following: data exposure risk level, protection level level, access time risk level, and access region risk level. Specifically, the data exposure risk level can be used to assess the degree of data exposure that an access request may cause. For example, if the request involves access to or transmission of sensitive data, the data exposure risk level will be correspondingly higher. The protection level level can be used to assess the current protection level of the system. For example, if the system's protection mechanism is weak, the protection level will be lower, meaning a higher risk. The access time risk level can be used to assess the time when the access request occurs. For example, if the access request occurs during abnormal time periods such as non-working hours or system maintenance time, the access time risk level may be higher. The access region risk level can assess the region from which the access request originates. For example, if the source region does not match the usual access region, or comes from a high-risk region, the access region risk level will be correspondingly higher.

[0050] In this embodiment, the API anomaly analysis module can be used to determine a single second risk level across different dimensions based on access metadata and according to at least one method, such as preset level conditions, system fixed settings, and user needs. This will be explained in detail below with reference to embodiments. Furthermore, after determining the second risk level, a weighted processing can be performed based on the second risk level and its corresponding weight coefficients to ultimately obtain a first risk level considering multiple dimensions. This can be achieved through at least one method, such as weighted summation or weighted averaging. This weighted processing can comprehensively consider multiple risk factors, thereby more comprehensively and accurately determining the overall risk level of the current access request.

[0051] In an exemplary preferred embodiment, the first risk level obtained by this disclosure can satisfy the following formula:

[0052] e = log 10 (a*w+b*x+c*y+d*z)

[0053] Where e represents the first risk level, a represents the data exposure risk level, b represents the protection level, c represents the access time risk level, d represents the access region risk level, w represents the weight coefficient corresponding to the data exposure risk level, x represents the weight coefficient corresponding to the protection level, y represents the weight coefficient corresponding to the access time risk level, and z represents the weight coefficient corresponding to the access region risk level.

[0054] As can be seen from the above formula, after determining the second risk level, the first risk level can be obtained by processing the weight coefficient corresponding to the second risk level and the second risk level itself. The exponential function used in determining the first risk level in this disclosure can be considered a preferred embodiment; other functions can also be used for calculation, without specific limitations.

[0055] It should be noted that the first and second risk levels described above can satisfy at least one of the following relationships:

[0056] The weighting coefficient for the second risk level is positively correlated with that of the first risk level. The second risk level includes at least one of the following: data exposure risk level, access time risk level, and access region risk level.

[0057] The weighting coefficient for the second risk level is negatively correlated with that for the first risk level. The second risk level includes the protection level.

[0058] In this embodiment of the disclosure, the relationship between the first risk level and the second risk level can be specifically adjusted by a weighting coefficient.

[0059] Specifically, in one embodiment of this disclosure, if at least one of the second risk levels, such as the risk level of data exposure, access time, or access region, becomes higher, the impact on the first risk level will become greater. This can be achieved by increasing the weighting coefficients corresponding to these risk levels to highlight the impact of these second risk levels on the first risk level. Thus, the weighting coefficients of the second risk levels in this disclosure are positively correlated with the first risk level.

[0060] In this disclosure, the weighting coefficient corresponding to the data exposure risk level is positively correlated with the first risk level. Furthermore, the data exposure risk level is positively correlated with the API identifier; therefore, the API identifier is also positively correlated with the first risk level.

[0061] In one exemplary embodiment, when the second risk level is data exposure risk level a, its corresponding weighting coefficient w can satisfy the following formula: w = log 10 (∑a(i)), where a(i) represents the data exposure risk level of the i-th interface, and w represents the weight coefficient corresponding to the data exposure risk level a. 10 This indicates normalization. Therefore, it can be seen that there is a positive correlation between the risk level 'a' of the exposure data and its corresponding weight coefficient 'w', and there is also a positive correlation between the weight coefficient 'w' corresponding to the first risk level 'e'. It should be understood that there can be other possible relationships between 'a' and 'w', which will not be exhaustively listed here.

[0062] In this disclosure, the weighting coefficient corresponding to the access time risk level is positively correlated with the first risk level. Furthermore, the access time risk level is positively correlated with API access time; therefore, API access time is also positively correlated with the first risk level.

[0063] When the second risk level is access time risk level c, its corresponding weight coefficient y can satisfy the following formula: y = log 10 (∑c(i)), where c(i) represents the access time risk level of the i-th interface, and y represents the weight coefficient corresponding to the access time risk level c. 10 This indicates normalization. Therefore, it can be seen that there is a positive correlation between the access time risk level c and its corresponding weight coefficient y, and the weight coefficient y corresponding to access time risk level c is also positively correlated with the first risk level e. It should be understood that there can be other possible relationships between c and y, which will not be exhaustively listed here.

[0064] In this disclosure, the weighting coefficient corresponding to the risk level of the accessed region is positively correlated with the first risk level. Furthermore, the risk level of the accessed region is positively correlated with the API accessed region; therefore, the API accessed region is also positively correlated with the first risk level.

[0065] When the second risk level is the risk level d of the visited area, its corresponding weighting coefficient z can satisfy the following formula: z = log 10 (∑d(i)), where d(i) represents the access region risk level of the i-th interface, and z represents the weight coefficient corresponding to the access region risk level d. 10 This indicates normalization. Therefore, there is a positive correlation between the risk level d of the visited area and its corresponding population coefficient z, and the weight coefficient z corresponding to the risk level d of the visited area is also positively correlated with the first risk level e. It should be understood that there can be other possible relationships between d and z, which will not be exhaustively listed here.

[0066] In another embodiment of this disclosure, when the second risk level relates to the protection level, the weighting coefficient corresponding to that risk level is negatively correlated with the first risk level. This is because if the protection level is higher, the overall risk (i.e., the first risk level) will decrease. This can be achieved by reducing the weighting coefficient corresponding to the protection level, thereby reducing the impact of the second risk level on the first risk level. Thus, the weighting coefficient of the second risk level in this disclosure is negatively correlated with the first risk level.

[0067] In this disclosure, the weighting coefficient corresponding to the protection level is negatively correlated with the first risk level. Furthermore, the protection level is negatively correlated with API visitors and API sensitivity levels; therefore, API visitors, API sensitivity levels, and the first risk level are also negatively correlated.

[0068] For example, when the second risk level is protection level b, its corresponding weighting coefficient x can satisfy the following formula: x = log 10 (100-b), where b(i) represents the protection level of the i-th interface, x represents the weight coefficient corresponding to the protection level b, and long... 10 This indicates normalization. Therefore, it can be seen that there is a negative correlation between the protection level b and its corresponding weight coefficient x, and the weight coefficient x corresponding to protection level b also shows a negative correlation with the first risk level e. It should be understood that there can be other possible relationships between b and x, which will not be exhaustively listed here.

[0069] In summary, by considering the second risk level and its corresponding weighting coefficient, the first risk level can be assessed more comprehensively and accurately, thus providing a strong basis for subsequent risk management. This design enables precise and effective risk management, helping to protect the target application's API from potential security threats.

[0070] As mentioned earlier, the API anomaly analysis module of this disclosure can determine the first risk level through the second risk level and its corresponding weighting coefficient. It should be noted that the weighting coefficient of this disclosure can be a fixed value or dynamically adjusted according to the second risk level. This design makes risk handling more flexible and precise.

[0071] Specifically, when any of the second risk levels changes, either due to periodic settings or automatic adjustments, the system can automatically or manually adjust the corresponding weight coefficient. This disclosure does not specify whether the adjustment of the weight coefficient is triggered by conditions. It should be noted that this adjustment aims to ensure that the first risk level more accurately reflects the overall risk status of the current access request. For example, if the data exposure risk level increases significantly, the system may increase the weight coefficient corresponding to that risk level, thereby increasing the first risk level accordingly. Conversely, if the protection level is improved, the system may decrease the weight coefficient corresponding to that risk level to reduce the first risk level.

[0072] It should be noted that there are multiple ways to adjust the weighting coefficients, which can depend on the actual application scenario and security requirements.

[0073] For example, adjustments can be made based on the relationship between the second risk level and its corresponding weight coefficient (positive / negative correlation, functional correlation, etc.).

[0074] As shown in the formula above, w = log 10In (∑a(i)), a(i) represents the data exposure risk level of the i-th interface, and w represents the weight coefficient corresponding to the data exposure risk level a. 10 This represents normalization. When it is necessary to adjust (increase or decrease) the corresponding coefficient w of the data exposure risk level, since there is a positive correlation between the data exposure risk level a and its corresponding weight coefficient w, it is only necessary to adjust (increase or decrease) the magnitude of the data exposure risk level a to complete the corresponding adjustment of the weight coefficient w. It should be understood that since there may be other possible forms of relationship between a and b, the method of adjusting the weight coefficient according to the form of the corresponding relationship will also change, which is not limited here. In this disclosure, the principle of adjusting the corresponding weight coefficient for different second risk levels is the same, which can be referred to here, and will not be repeated here.

[0075] For example, this disclosure also provides a specific adjustment method, including:

[0076] When the second risk level does not meet the first threshold, the weighting coefficient is reduced. The second risk level includes at least one of the following: access time risk level and access area risk level.

[0077] In this disclosure, the first threshold can be flexibly set according to the needs of the system or the user.

[0078] In this embodiment of the disclosure, when the access time risk level or access region risk level in the second risk level does not meet the first threshold, the weighting coefficients corresponding to these risk levels can be reduced. This means that if the risk level of the second risk level is low, its impact on the first risk level will also be reduced accordingly. In order to more accurately reflect the actual risk status of the access request, the weighting coefficients corresponding to these risk levels can be reduced.

[0079] As shown in the formula above, w = log 10 In (∑a(i)), a(i) represents the data exposure risk level of the i-th interface, and w represents the weight coefficient corresponding to the data exposure risk level a. 10 This indicates normalization. To reduce the weight coefficient w, due to the positive correlation between the risk level a of the exposed data and its corresponding weight coefficient w, w can be reduced in at least one of the following ways, including but not limited to: reducing a, changing the calculation function of w.

[0080] In summary, this disclosure, by adjusting the weighting coefficient based on the second risk level, can more accurately determine the risk level of access requests and provide a more precise basis for subsequent risk handling. This helps to further improve API security and effectively address various potential security threats.

[0081] As mentioned earlier, the API anomaly analysis module can be used to determine the second risk level based on access metadata. The following details how to determine the second risk level, using at least one of the following methods: Example A1, Example A2, Example A3, and Example A4. It should be noted that various different examples can be flexibly selected (in whole or in part) or combined according to the system and user needs, without a strict order, and are not limited here. The following provides a detailed explanation.

[0082] For example, in embodiment A1, the data exposure risk level corresponding to the API identifier can be determined based on the registration data. In simpler terms, if the access metadata includes an API identifier, then the corresponding data exposure risk level can be directly determined from the registration data using that API identifier. Here, the registration data can be understood as the data that is fixedly set when a user registers for an API.

[0083] For example, when registering for an API, users can specify the level of sensitive information exposure: 10 (low security risk, 10-20) for no sensitive information exposure, 30 (medium security risk, 30-50) for one piece of sensitive information exposure, 60 (high security risk, 60-90) for two pieces of sensitive information exposure, and 100 (extremely high security risk) for three or more pieces of sensitive information exposure. Once the APP ID of the access request is known, the corresponding risk level of exposed data can be found in the user's login information through the API ID.

[0084] In embodiment A2, API security protection devices can be determined based on the API visitor and API sensitivity level; the protection level is obtained by adding the weights of the security protection devices. In other words, the number of security protection devices configured in the system can be directly determined based on the API visitor or API sensitivity level. Then, the protection level is obtained by adding the weights of each security protection device.

[0085] For example, the system can automatically scan the status of each security device based on its own system or the sensitivity level settings, calculate the sum of the weight values ​​of each security device in normal state, also known as the protection level, and subsequently scan every fixed time interval (e.g., 10 minutes, 20 minutes, etc.) and update the protection level value based on the scan results. The weight of each security device could be: firewall weight 20, intrusion prevention system weight 10, web application firewall weight 20, database audit weight 20, and host security weight 10. No specific restrictions are imposed here.

[0086] In embodiment A3, the initial access time risk level and the first access count of the API within a preset time period can be determined based on the API access time. The target access time risk level is then determined using the ratio of the initial access time level, the first access count, and the historical first access count. In simpler terms, the system can have a default access time risk level (i.e., the initial access time risk level), and the specific time range of this default access time risk level can be flexibly adjusted by business attributes. Once an API access time is detected, the default access time risk level and the number of accesses within a preset time period can be determined. Then, the number of accesses within the preset time period is compared with the relative historical records to obtain the ratio. The default access time risk level is adjusted in a step-wise manner based on the magnitude of the ratio to obtain the final adjusted access time risk level.

[0087] For example, the default access time risk levels can be: 8:00-20:00, set to 10 (low security risk, 10-20); 6:00-8:00, 20:00-22:00, set to 30 (medium security risk, 30-50); 4:00-6:00, 22:00-24:00, set to 60 (high security risk, 60-90); 24:00-4:00, set to 100 (extremely high security risk). The above default access time risk levels are determined based on the API access time. After the default configuration is completed, the access count for each API within the corresponding time period is recorded. If the number of visits during this period shows an abnormal increase relative to the historical record and is not planned (planned visits could include at least one new partner, caller, or API annotation within the system), and the abnormal increase is more than 1 to 2 times, the default access time risk level for this period can be increased by 10; if the abnormal increase is more than 2 to 3 times, the default access time risk level for this period can be increased by 20; if the abnormal increase is more than 3 to 5 times, the default access time risk level for this period can be increased by 30; if the abnormal increase is more than 5 times, the default access time risk level for this period can be increased to 100, thus obtaining the final access time risk level.

[0088] In embodiment A4, the initial access region risk level and the number of second visits to the API within the corresponding region can be determined based on the API visitor's address. The target access region risk level is then determined using the ratio of the initial access region risk level, the number of second visits, and the historical number of second visits. In simpler terms, the system can have a default access region risk level (i.e., the initial access region risk level). Once an API access region is discovered, the default access region risk level and the number of visits within a preset region can be determined. Then, the number of visits within the preset region is compared with the relative historical records to obtain a ratio. The default access region risk level is adjusted in a stepwise manner based on the magnitude of the ratio to obtain the final adjusted access region risk level.

[0089] For example, the default access region risk level can be set to 10 (low security risk, 10-20) for major domestic markets, 30 (medium security risk, 30-50) for other domestic markets and major international markets, 60 (high security risk, 60-90) for non-market international regions, and 100 (extremely high security risk) for special countries or regions. The default access region risk level is determined based on the API access region. After the default configuration is completed, the access count for each API within the corresponding region is recorded. If the number of visits to a particular region shows an abnormal increase relative to historical records and is unplanned (planned increases could include at least one new partner, caller, or API annotation within the system), and the abnormal increase is more than 1 to 2 times the historical record, the default access region risk level for that region can be increased by 10; if the abnormal increase is more than 2 to 3 times the historical record, the default access region risk level for that region can be increased by 20; if the abnormal increase is more than 3 to 5 times the historical record, the default access region risk level for that region can be increased by 30; and if the abnormal increase is more than 5 times the historical record, the default access region risk level for that region can be increased to 100, thus obtaining the final access region risk level.

[0090] In summary, a comprehensive and detailed assessment of the risk level of an API across different dimensions can be achieved, thereby providing strong support for API security protection.

[0091] As mentioned above, the API anomaly analysis module can be used to determine the first risk level, and then risk handling can be carried out based on the first risk level. Below, this disclosure provides a possible implementation method for risk handling based on the first risk level, which includes:

[0092] Respond to the current access request when the first risk level meets the second threshold;

[0093] If the first risk level does not meet the second threshold, the current access request will be rejected and a risk warning will be issued.

[0094] In this disclosure, the second threshold can be flexibly adjusted according to the needs of the system or the user. Preferably, the second threshold can be 2.5, but the specific value of the second threshold is not limited here.

[0095] In this embodiment of the disclosure, when the first risk level meets a preset second threshold, i.e., the risk of the current access request is within an acceptable range, the system can respond to the request. The system can process the request normally and return the corresponding result to the visitor.

[0096] When the first risk level does not meet the second threshold, meaning the current access request has a high risk, the system can reject the request and issue a risk alert, that is, notify relevant personnel or the system of the current security risks, and may take further protective measures, which are not limited here.

[0097] As above Figure 3 In the API anomaly analysis module, if the risk level exceeds a threshold, access can be blocked, an alert issued, and the visitor's risk level updated. If the risk level does not exceed the threshold, access can be granted, and the visitor's risk level updated.

[0098] In one exemplary embodiment, when e < 2.5, the operation is allowed directly. e represents the first risk level. When e ≥ 2.5, the access is blocked, and an access risk alarm message is generated. If three consecutive accesses are blocked, an access risk alarm confirmation message is generated and pushed to the user, who then manually confirms whether to allow the access.

[0099] In summary, by determining whether to respond to or reject API access requests based on the first risk level and issuing risk alerts, the system can accurately and comprehensively protect API security and prevent potential attacks or data breaches.

[0100] As described above, risk management based on a first risk level has been explained in detail. Furthermore, based on any of the preceding embodiments, this disclosure can also utilize API access volume for risk management. The following details this, including:

[0101] Get the API's access count;

[0102] Based on the number of visits and a third threshold, risk management is applied to the current access request.

[0103] In this disclosure, API access volume can be understood as the number of times the API is accessed within a certain time period (such as the past hour, day, or week). The third threshold can be flexibly adjusted based on factors such as the importance of the API, the server's capacity, and historical access data.

[0104] In this embodiment, the number of visits to the API within a certain time period can be counted and compared with a preset third threshold. If the number of visits exceeds the third threshold, it indicates that the API may be under attack or being overused, and risk management measures can be taken, such as limiting the access frequency, adding authentication steps, or temporarily shutting down the API, at least one of these methods. If the number of visits does not exceed the third threshold, the current access request can be processed according to the normal procedure.

[0105] For example, the system automatically calculates the access volume of the API resource in the most recent hour every hour and compares it with the current maximum hourly access volume. If the current hourly access volume is greater than the maximum hourly access volume, the maximum hourly access volume is updated, and an access risk alert is generated. If the access volume exceeds the maximum hourly access volume for three consecutive hours, an access risk alert confirmation message is generated and pushed to the user, who then manually confirms whether to close the API.

[0106] In this way, by using API access volume as a reference indicator for risk management, we can more comprehensively assess the risk status of APIs and take more precise and effective risk management measures.

[0107] The above can be used flexibly by selecting or combining different risk management methods according to actual needs, and there is no strict order among these methods.

[0108] For example, with Figure 1 For example, the risk management methods disclosed herein will be fully explained below:

[0109] Figure 1 The Internet application management platform in this context can be taken as an example, such as the industrial Internet application management platform.

[0110] The API security gateway module of the industrial internet application management platform can obtain the information metadata (i.e., the access metadata disclosed herein) of the API corresponding to the access request when it receives at least one access request for a target application from users, systems, and applications. It can also parse the API information metadata and forward it to the API abnormal behavior analysis module. The information metadata includes, but is not limited to, the API visitor's risk level, the API access IP address, the API access time, the accessed API, the sensitivity level of the accessed API, and the API risk level, etc., without limitation.

[0111] The API abnormal behavior analysis module of the industrial internet application management platform can perform risk assessment upon receiving parsed metadata from the API security gateway module. It assesses the risk for each dimension of the metadata, obtaining the corresponding risk level for each dimension. Simultaneously, it can intelligently calculate the current API access risk level (i.e., the first risk level disclosed herein) by combining the risk level determined by the system's network security protection level. This automatically identifies various abnormal API risk behaviors, blocking and issuing warnings for high-risk access behaviors, while allowing low-risk access behaviors. This approach provides greater flexibility while satisfying the need for refined API interface security management.

[0112] This disclosure also provides a risk management device. Figure 4 This is a structural block diagram of a risk management device provided in an embodiment of the present disclosure, such as... Figure 4 As shown, the risk management device 400 includes:

[0113] Acquisition unit 401 is used to acquire access metadata of the application programming interface (API).

[0114] Determination unit 402 is used to determine the first risk level of the current access request based on access metadata.

[0115] Processing unit 403 is used to perform risk processing on the current access request based on the first risk level.

[0116] In one exemplary embodiment, the access metadata includes at least one of the following: API visitor, API visitor address, API access time, API identifier, and API sensitivity level.

[0117] In one exemplary embodiment, determining a first risk level of the current access request based on access metadata includes: determining a second risk level based on access metadata, wherein the second risk level includes at least one of the following: data exposure risk level, protection level level, access time risk level, and access region risk level; and obtaining the first risk level by weighting the second risk level and a weighting coefficient.

[0118] In one exemplary embodiment, the first risk level and the second risk level satisfy at least one of the following relationships: the weight coefficient corresponding to the second risk level is positively correlated with the first risk level, and the second risk level includes at least one of the following: data exposure risk level, access time risk level, and access region risk level; the weight coefficient corresponding to the second risk level is negatively correlated with the first risk level, and the second risk level includes: protection level level.

[0119] In one exemplary embodiment, the method further includes: adjusting the weighting coefficient based on the second risk level.

[0120] In one exemplary embodiment, adjusting the weighting coefficient based on the second risk level includes: reducing the weighting coefficient when the second risk level does not meet the first threshold. The second risk level includes at least one of the following: access time risk level and access region risk level.

[0121] In one exemplary embodiment, determining a second risk level based on access metadata includes at least one of the following: determining the data exposure risk level corresponding to the API identifier based on registration data; determining API security protection devices based on API visitors and API sensitivity levels; summing the weights of the security protection devices to obtain a protection level; determining the initial access time risk level and the first number of API accesses within a preset time based on API access time; determining the target access time risk level using the ratio of the initial access time level, the first number of accesses, and the historical first number of accesses; determining the initial access region risk level and the second number of API accesses within the corresponding region based on the API visitor address; and determining the target access region risk level using the ratio of the initial access region level, the second number of accesses, and the historical second number of accesses.

[0122] In one exemplary embodiment, risk processing of the current access request is performed based on a first risk level, including: responding to the current access request when the first risk level meets a second threshold; and rejecting the current access request and issuing a risk alarm when the first risk level does not meet the second threshold.

[0123] In one exemplary embodiment, the method further includes: obtaining the access volume of the API; and performing risk handling on the current access request based on the access volume and a third threshold.

[0124] Figure 5 This is a hardware block diagram of an electronic device provided according to an embodiment of the present disclosure. The electronic device 500 according to an embodiment of the present disclosure includes at least a processor; and a memory for storing computer-readable instructions. When the computer-readable instructions are loaded and executed by the processor, the processor performs the risk handling method described in any of the preceding embodiments of the present disclosure.

[0125] Figure 5The illustrated electronic device 500 specifically includes a central processing unit (CPU) 501, a graphics processing unit (GPU) 502, and a memory 503. These units are interconnected via a bus 504. The CPU 501 and / or GPU 502 can function as the aforementioned processor, and the memory 503 can function as the aforementioned memory storing computer-readable instructions. Furthermore, the electronic device 500 may also include a communication unit 505, a storage unit 506, an output unit 507, an input unit 508, and an external device 509, all of which are also connected to the bus 504.

[0126] Figure 6 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this disclosure. (As shown...) Figure 6 As shown, a computer-readable storage medium 600 according to an embodiment of the present disclosure stores computer-readable instructions 601 thereon. When the computer-readable instructions 601 are executed by a processor, the risk handling method described with reference to the above-described figures according to any of the embodiments of the present disclosure is performed. The computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, optical disk, magnetic disk, etc.

[0127] This disclosure further provides a computer program product, including a computer program that, when executed by a processor, implements the risk handling method described in any of the preceding embodiments of this disclosure.

[0128] The present disclosure provides a risk management method, apparatus, electronic device, storage medium, and program product. This disclosure determines the first risk level of a current access request by obtaining the API's access metadata, thereby performing risk management on the current request. In this way, the present disclosure can dynamically determine the corresponding risk level of an access request directly through its access metadata, and then perform risk management. Compared to existing methods that solely utilize WAF protection, this disclosure can specifically determine the risk level of an access request, thus performing precise risk management. Furthermore, it can consider multiple influencing factors of the access request, flexibly determining the risk level, thereby performing comprehensive risk management. In summary, the technical solution provided by this disclosure can comprehensively and accurately manage the risks of API interfaces effectively, meeting the objective needs of practical processes.

[0129] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0130] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0131] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0132] Additionally, as used herein, the “or” used in a list of items beginning with “at least one” indicates a separate list, such that a list of, for example, “at least one of A, B, or C” means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word “exemplary” does not imply that the described example is preferred or better than other examples.

[0133] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0134] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0135] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0136] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A risk management method, characterized in that: The method comprises: Get access metadata of the application programming interface API; Determining a first risk level of the current access request based on the access metadata; Based on the first risk level, risk processing is performed on the current access request.

2. The method according to claim 1, characterized in that The access metadata includes at least one of the following: API visitor, API visitor address, API access time, API identifier and API sensitivity level.

3. The method according to claim 1, characterized in that The determining, based on the access metadata, a first risk level of the current access request includes: Determining a second risk level based on the access metadata, the second risk level comprising at least one of the following: a data exposure risk level, a protection level level, an access time risk level, and an access region risk level; Based on the second risk level and the weight coefficient, weighted processing is performed to obtain the first risk level.

4. The method according to claim 3, characterized in that The first risk level and the second risk level satisfy at least one of the following relationships: The weight coefficient corresponding to the second risk level is positively correlated with the first risk level, and the second risk level includes at least one of the following: data exposure risk level, access time risk level, and access area risk level; The weight coefficient corresponding to the second risk level is negatively correlated with the first risk level, and the second risk level includes: a protection level level.

5. The method according to claim 3, characterized in that: The method further comprises: Based on the second risk level, the weight factor is adjusted.

6. The method according to claim 5, characterized in that The adjusting the weight coefficient based on the second risk level includes: When the second risk level does not meet the first threshold, the weight coefficient is reduced, and the second risk level includes at least one of the following: a visit time risk level and a visit area risk level.

7. The method according to claim 3, characterized in that The determining of the second risk level based on the access metadata includes at least one of the following: Based on the registration data, determine the data exposure risk level corresponding to the API identifier; Determine API security protection equipment based on API access and API sensitivity level; use the weights of the security protection equipment to add up and obtain the protection level grade; Based on the API access time, determine the initial access time risk level and the first number of API accesses within a preset time; Determine a target access time risk level by using the initial access time risk level and the ratio of the first access number to the historical first access number; Based on the API visitor's address, determine the initial access region risk level and the number of second API accesses in the corresponding region; The risk level of the target visited area is determined by using the risk level of the initial visited area and the ratio of the second visit times to the historical second visit times.

8. The method according to claim 1, characterized in that The performing risk processing on the current access request based on the first risk level includes: When the first risk level meets a second threshold, responding to the current access request; When the first risk level does not meet a second threshold, the current access request is rejected and a risk warning is issued.

9. The method according to claim 1, characterized in that: The method further comprises: Obtain the number of visits to the API; Based on the access volume and a third threshold, risk processing is performed on the current access request.

10. A risk management device, characterized in that: The device comprises: An acquisition unit, used for acquiring access metadata of an application programming interface API; a determining unit, configured to determine a first risk level of a current access request based on the access metadata; A management unit is used to perform risk processing on the current access request based on the first risk level.

11. An electronic device, characterized in that: include: a memory for storing computer readable instructions; as well as A processor is used to run the computer-readable instructions so that the electronic device executes the method according to any one of claims 1 to 9.

12. A non-transitory computer-readable storage medium for storing computer-readable instructions, characterized in that: When the computer-readable instructions are executed by a processor, the processor is caused to perform the method according to any one of claims 1 to 9.

13. A computer program product, characterized in that The method comprises a computer program, which implements the method according to any one of claims 1 to 9 when the computer program is executed by a processor.

Images