Data access control method and system for data security management

Abstract

The invention relates to the technical field of communication, in particular to a data access control method and system oriented to data security management, and is used for solving the technical problem that the protection accuracy and timeliness of a current access decision are insufficient. The method comprises the following steps: acquiring service call chain data; identifying an abnormal request in the service call chain data, and determining a risk score of the abnormal request; determining the risk association strength between the downstream request of the abnormal request and the abnormal request; the risk association strength is used for representing the influence degree of the downstream request by the abnormal request; determining a basic attenuation factor of risk conduction based on the risk score; the basic attenuation factor is used for quantifying the reference degree of the influence of the abnormal request on the downstream request priority; determining an attenuation factor of the downstream request according to the basic attenuation factor and the risk association strength; the priority of the downstream request is updated based on the attenuation factor.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a data access control method and system for data security management. BACKGROUND

[0002] In the digital era, data continuously flows between data centers, cloud service providers, edge nodes and end users. This open and interconnected environment brings great efficiency improvement, but also faces security incidents such as data leakage, unauthorized access and internal threats. Therefore, data access control is needed to make access decisions when entities request to access data, so that entities can access protected data resources in an allowed manner (read, write, execute, delete, etc.) when certain conditions are met.

[0003] However, current access decisions usually rely on preset and unchanging priorities or rules, lacking real-time perception and dynamic response capability to runtime risks. When an exception or potential threat occurs in the service call chain, the static mechanism cannot intelligently adjust the processing priority of subsequent data access requests according to the propagation and influence range of the threat, resulting in insufficient precision and timeliness of the protection of current access decisions. SUMMARY

[0004] In order to solve the technical problem of insufficient precision and timeliness of the protection of current access decisions, the purpose of the present application is to provide a data access control method for data security management, and the technical solution adopted is as follows: Obtain service call chain data; Identify an abnormal request in the service call chain data and determine a risk score of the abnormal request; Determine a risk association strength between a downstream request and the abnormal request; the risk association strength is used to represent the degree of influence of the downstream request by the abnormal request; Based on the risk score, determine a basic attenuation factor of risk transmission; the basic attenuation factor is used to quantify the benchmark degree of the influence of the abnormal request on the priority of the downstream request; Determine an attenuation factor of the downstream request according to the basic attenuation factor and the risk association strength; Update the priority of the downstream request based on the attenuation factor.

[0005] In a possible implementation, identifying an abnormal request in the service call chain data comprises: determining a historical baseline frequency of a historical request of a same type as the target request and a normal fluctuation range; the target request is any request in the service call chain data; the historical baseline frequency is used to represent a baseline value of a call frequency of the historical request; the normal fluctuation range is used to represent a normal fluctuation range of the call frequency of the historical request; determining a deviation degree of the target request based on a call frequency of the target request, the historical baseline frequency, and the normal fluctuation range; and identifying the target request as the abnormal request when the deviation degree exceeds a preset deviation degree.

[0006] In a possible implementation, determining a risk score of the abnormal request comprises: obtaining the deviation degree of the abnormal request, a service criticality level of the abnormal request, and a duration of the abnormal request; the service criticality level is used to represent importance of a service corresponding to the abnormal request when processing data; and determining the risk score based on the deviation degree of the abnormal request, the service criticality level, and the duration of the abnormal request.

[0007] In a possible implementation, determining a risk association strength between a downstream request and the abnormal request comprises: determining an initial risk association strength between each abnormal request in the plurality of abnormal requests and the downstream request, and a deviation degree of each abnormal request, in a case where services of the plurality of abnormal requests all call the downstream request; determining a risk contribution value of each abnormal request to the downstream request based on the initial risk association strength and the deviation degree corresponding to each abnormal request; and determining the risk association strength of the downstream request based on the risk contribution values of the plurality of abnormal requests.

[0008] In a possible implementation, determining the initial risk association strength between each abnormal request in the plurality of abnormal requests and the downstream request comprises: determining a transmission hop number between each abnormal request and the downstream request; obtaining a historical call frequency between each abnormal request and the downstream request; the historical call frequency is used to represent a number of times that a service calling the abnormal request accumulatively calls the downstream request; and calculating the initial risk association strength of each abnormal request according to the transmission hop number and the historical call frequency of each abnormal request.

[0009] In a possible implementation, determining the risk contribution value of each abnormal request to the downstream request based on the risk association strength and the deviation degree corresponding to each abnormal request comprises: correcting the initial risk association strength of each abnormal request based on a credibility of each abnormal request being identified as the abnormal request on a transmission path to which the abnormal request belongs; wherein the credibility is positively correlated with a proportion of abnormal requests on the transmission path to which the abnormal request belongs; and determining the risk contribution value of each abnormal request to the downstream request based on the corrected initial risk association strength of each abnormal request and the deviation degree of each abnormal request.

[0010] In a possible implementation, the basic attenuation factor of risk transmission is determined based on the risk score, including: determining the basic attenuation factor based on the risk score and the proportion of abnormal requests between the time after the first abnormal request is identified and the current time.

[0011] In a possible implementation, the service call chain data includes the calling relationship between services and the calling frequency information of each request; the service call chain data is obtained by: collecting, in the micro-service architecture, request sequence data generated through API calling between each service; and extracting the calling relationship between services and the calling frequency information of each request from the request sequence data to obtain the service call chain data.

[0012] In a possible implementation, the priority of the downstream request is updated based on the attenuation factor, including: adjusting the original priority of the downstream request according to the attenuation factor to obtain an updated dynamic priority; and associating the dynamic priority with the metadata of the downstream request.

[0013] The application further provides a data access control system for data security management, including: The acquisition unit is configured to acquire service call chain data; The processing unit is configured to identify an abnormal request in the service call chain data and determine a risk score of the abnormal request; The processing unit is further configured to determine a risk association strength between a downstream request of the abnormal request and the abnormal request; the risk association strength is used to represent the degree of influence of the abnormal request on the downstream request; The processing unit is further configured to determine a basic attenuation factor of risk transmission based on the risk score; the basic attenuation factor is used to quantify the benchmark degree of the influence of the abnormal request on the priority of the downstream request; The processing unit is further configured to determine an attenuation factor of the downstream request according to the basic attenuation factor and the risk association strength; The update unit is configured to update the priority of the downstream request based on the attenuation factor.

[0014] The application has the following beneficial effects: the application identifies an abnormal request in a service call chain, determines an attenuation factor of a downstream request based on the degree of influence of the abnormal request on the downstream request and the benchmark degree of the influence of the abnormal request on the priority of the downstream request, and finally updates the priority of the downstream request based on the attenuation factor. Based on this, the application can realize dynamic adjustment of the priority of the downstream request, and improve the accuracy and timeliness of protection of the access decision of the downstream request. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions and advantages of the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort.

[0016] Figure 1 A flowchart of a data access control method for data security management provided by an embodiment of the present application Figure 1 ; Figure 2 A flowchart of a data access control method for data security management provided by an embodiment of the present application Figure 2 ; Figure 3 A flowchart of a data access control method for data security management provided by an embodiment of the present application Figure 3 ; Figure 4 A flowchart of a data access control method for data security management provided by an embodiment of the present application Figure 4 ; Figure 5 A system architecture diagram of a data access control system for data security management provided by an embodiment of the present application. DETAILED DESCRIPTION

[0017] In order to further illustrate the technical means and effects adopted by the present application to achieve the predetermined purposes, the specific embodiments, structures, features and effects of the data access control method for data security management according to the present application are described in detail below in combination with the drawings and preferred embodiments. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. In addition, the specific features, structures or characteristics in one or more embodiments can be combined in any suitable form.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs.

[0019] In all division operations and logarithmic operations involved in the present application, in order to prevent computer program crashes or invalid values due to zero denominator or zero input, a smoothing mechanism is adopted. Specifically, in the denominator item of the division operation or the real number item of the logarithmic function, a positive correction factor ε is added, for example, taking the value of 0.001; so as to ensure the robustness and implementability of the algorithm under extreme working conditions.

[0020] The normalization function Norm() mentioned in the present application adopts maximum-minimum value normalization unless otherwise specified. The maximum-minimum value is a preset empirical extreme value based on a large amount of historical experimental data. If the calculation result exceeds the interval [0, 1], it is limited in the interval [0, 1] through a truncation function (i.e. if the result is less than 0, 0 is taken, and if the result is greater than 1, 1 is taken), so as to eliminate the influence of abnormal values on the evaluation index.

[0021] The specific scheme of the data access control method for data security management provided by the present application will be described in detail below with reference to the accompanying drawings.

[0022] Please refer to Figure 1 , which shows a method flowchart of a data access control method for data security management provided by an embodiment of the present application, as Figure 2 shown, the method comprises the following steps: Step 101, obtaining service call chain data.

[0023] In a possible implementation manner, the service call chain data comprises the calling relationship between services and the calling frequency information of each request. In this case, this step comprises: in a microservice architecture, collecting request sequence data generated by API calling between each service. Extracting the calling relationship between services and the calling frequency information of each request from the request sequence data to obtain the service call chain data.

[0024] Specifically, in a cloud-native microservice architecture, services frequently interact through API calling, each specific API calling request (i.e. one data access operation) has its priority, and one API calling request represents a dynamic transient entity with complete context. The present application obtains the conduction path in the service call chain, synchronously obtains the calling frequency when a specific request is issued, and obtains the service call chain data.

[0025] Step 102, identifying an abnormal request in the service call chain data and determining the risk score of the abnormal request.

[0026] Optionally, the present application determines the historical request corresponding to each request in the service call chain data. The historical request is a request of the same type as the request. By comparing the calling frequency of the request and the calling frequency of the historical request, it is determined whether the calling frequency of the request appears abnormal fluctuation. If the calling frequency appears abnormal fluctuation, the request is determined to be an abnormal request. Optionally, the abnormal fluctuation can refer to that the calling frequency of the request is obviously higher than the calling frequency of the historical request, or obviously lower than the calling frequency of the historical request, which is not limited by the present application.

[0027] The risk score of the abnormal request is used to represent the severity of the abnormal request deviating from the normal calling mode, and a risk level determined by the key of the corresponding service in the service calling chain, and the duration of the abnormal state.

[0028] It should be noted that in the data access control system for data security management, the present application monitors the API calling behavior between services in real time, identifies the abnormal deviation phenomenon in service calling by comparing the current request mode with the dynamically established historical behavior baseline, quantifies the deviation as a specific risk score, and then updates the priority of the downstream request of the abnormal request, thereby establishing a smooth and continuous association response between risk identification and access control, and realizing data security management.

[0029] Step 103, determining the risk association strength between the downstream request of the abnormal request and the abnormal request.

[0030] The risk association strength is used to represent the degree of influence of the downstream request on the abnormal request.

[0031] Optionally, a downstream request can be influenced by multiple upstream abnormal requests at the same time. Therefore, the present application can first calculate the degree of influence of the downstream request on each upstream abnormal request, and then integrate the degrees of influence of the multiple upstream abnormal requests to determine the risk association strength of the downstream request.

[0032] Step 104, determining a basic attenuation factor of risk transmission based on the risk score.

[0033] The basic attenuation factor is used to quantify the baseline degree of influence of the abnormal request on the priority of the downstream request.

[0034] In one possible implementation, the present application determines the basic attenuation factor based on the risk score and the proportion of abnormal requests between the identification of the first abnormal request and the current time.

[0035] The proportion can reflect the spread range and influence scale of the risk in the service calling chain. The present application forms the basic attenuation factor quantifying the baseline degree of influence of the abnormal request on the priority of the downstream request by comprehensively considering the severity of the risk itself and the spread situation of the risk, ensuring that the factor not only fits the core features of the source risk, but also adapts to the actual spread situation in the risk transmission process.

[0036] Step 105, determining the attenuation factor of the downstream request according to the basic attenuation factor and the risk association strength.

[0037] Optionally, this application uses the basic attenuation factor as the benchmark for risk transmission and the comprehensive risk correlation strength between downstream requests and abnormal requests as the tuning factor. It combines the benchmark impact of risk with the actual risk impact on downstream requests to obtain the attenuation factor of downstream requests. This allows the determined attenuation factor to quantify the degree of priority attenuation of downstream requests, providing a scientific and accurate basis for subsequent dynamic updates of priorities.

[0038] Step 106: Update the priority of downstream requests based on the decay factor.

[0039] In one possible implementation, this step can be specifically implemented as follows: adjusting the original priority of downstream requests based on a decay factor to obtain an updated dynamic priority. The dynamic priority is then associated with the metadata of the downstream requests. In this way, this application responds to security threats by dynamically adjusting priorities. When a threat is detected, the priority of certain accesses is reduced to ensure that critical business operations are not affected. When a risk is identified and needs to be propagated downstream, the priority of downstream requests is reasonably reduced based on the current risk characteristics to limit potential damage, while simultaneously avoiding excessive restrictions that could impact normal business operations.

[0040] Specifically, the dynamic execution priority of this request can be calculated by multiplying the difference between 1 and the decay factor of the downstream request by the base priority. Based on this, the updated priorities of all downstream requests of the abnormal request in the call chain are obtained. After a request enters the processing queue, the scheduler will allocate computing resources and adjust the processing order according to its dynamic priority, so that high-priority requests can be responded to quickly, while low-priority requests may be delayed or rate-limited. Therefore, when a downstream service receives a request, it can read the priority from the request header (such as the HTTP request header) and process it accordingly (such as entering different processing queues). This decay mechanism can dynamically adjust priorities based on multi-dimensional risks, ensuring both the transmission and control of security risks and minimizing the impact on normal business operations.

[0041] It should be noted that, to prevent the implicit rejection of legitimate requests due to the infinite decay of priority, this application may set up the following protection mechanism: Priority threshold: The system sets a minimum priority threshold for each request. For example, if the minimum priority is set to be no less than 0.1, even if the attenuation factor calculation results in the priority being lower than this threshold, the system will still retain its priority at or above this minimum priority threshold to ensure that the request is not completely rejected.

[0042] Critical business exemption rules: For requests marked as core business or high availability services, the system supports configuring exemption policies. Their priority is not affected by the decay factor and always maintains the original priority or is not lower than the preset protection priority.

[0043] Manual intervention channel: The system provides a management interface that allows security administrators to view the list of downgraded requests in real time and supports manually restoring their priority or adding them to the whitelist.

[0044] Based on the above technical solution, this application identifies abnormal requests in the service call chain, determines a decay factor for downstream requests based on the degree of impact of the abnormal request on its downstream requests and the baseline degree of impact on the priority of downstream requests, and finally updates the priority of downstream requests based on the decay factor. Therefore, this application can achieve dynamic adjustment of downstream request priorities, improving the accuracy and timeliness of protection against access decisions for downstream requests.

[0045] like Figure 3 As shown, in one possible implementation, the process of identifying abnormal requests in the service call chain data in step 102 above can be specifically implemented through the following steps: Step 201: Determine the historical baseline frequency and normal fluctuation range of historical requests of the same type as the target request.

[0046] The target request is any request in the service call chain data. The historical baseline frequency is used to characterize the baseline value of the call frequency of historical requests. The normal fluctuation range is used to characterize the normal fluctuation range of the call frequency of historical requests.

[0047] As an example, the historical baseline frequency is the average call frequency of historical requests, and the normal fluctuation range is the standard deviation of the call frequency of historical requests.

[0048] Specifically, this application analyzes historical service call data and establishes a dynamic baseline for API calls between each pair of services. Any significant deviation is considered a signal of abnormal behavior, indicating that the current request poses an abnormal risk. For the current request, the average call frequency of the same historical period is used as the benchmark, and the standard deviation is used as the normal fluctuation range.

[0049] Optionally, the call frequency in this application refers to the number of times the request is called within one minute.

[0050] Step 202: Determine the deviation of the target request based on the call frequency of the target request, the historical baseline frequency, and the normal fluctuation range.

[0051] As an example, the deviation from the target request satisfies the following formula: in, This indicates the current call frequency of the target request (the number of calls in the last minute). This represents the average call frequency of historical requests corresponding to the target request; The standard deviation representing the frequency of historical requests; This represents a smoothing factor to avoid a denominator of zero.

[0052] In this formula, the greater the difference between the current request's call frequency and the historical baseline, the higher the deviation, indicating that the request may pose a risk in the overall data access control system and requires timely priority updates. For services with low volatility, even a small absolute deviation may indicate an anomaly, while for services with high volatility, the same absolute deviation may simply be normal fluctuation. Therefore, using the standard deviation as the denominator eliminates the impact of volatility differences between different service requests, making the deviation comparable.

[0053] Step 203: When the deviation exceeds the preset deviation, the target request is identified as an abnormal request.

[0054] Specifically, based on the deviation dataset of all requests issued in the current system, the deviations of all requests are sorted in ascending order. The position corresponding to the maximum difference between two adjacent deviations is found. If the deviation of the current request is greater than the larger deviation corresponding to the maximum difference, the request is considered to have a potential anomaly risk. At this time, a control mechanism is automatically triggered to continuously and adaptively adjust the priority of subsequent data access operations initiated by the entity that initiated the request.

[0055] It should be noted that the abnormal requests in this invention do not refer to phenomenal anomalies that would truncate downstream service calls, but rather to unhealthy requests that occur frequently in downstream service calls but have not yet reached the system's circuit breaker threshold. Since such requests occur frequently and continuously consume resources, it is necessary to dynamically update their priorities to achieve adaptive allocation of system resources.

[0056] For example, the preset deviation value rule adopts a method based on the quantile of historical deviation data to better adapt to different call frequency distributions. Specifically, the historical deviation dataset is sorted from smallest to largest value, and its 95th percentile is taken as the threshold. When the deviation of the current request exceeds this threshold, it is identified as an abnormal request. Based on the above technical solution, this application introduces historical baseline frequency and normal fluctuation range as reference standards, and calculates the deviation by combining it with the actual call frequency of the target request, providing an objective and quantifiable basis for the identification of abnormal requests. This identification method based on the comparison of historical data and real-time data can effectively distinguish between normal fluctuations and abnormal deviations in service calls, avoiding the problem of misjudgment or omission caused by a single threshold judgment, making the identification of abnormal requests more in line with the call characteristics of different services, laying a precise foundation for subsequent risk assessment and priority adjustment, and improving the reliability and adaptability of the risk identification link in data access control.

[0057] like Figure 4As shown, in one possible implementation, the process of determining the risk score of abnormal requests in step 102 above can be specifically implemented through the following steps: Step 301: Obtain the deviation of the abnormal request, the service criticality level of the abnormal request, and the duration of the abnormal request.

[0058] Among them, the service criticality level is used to characterize the importance of the service corresponding to the abnormal request when processing data.

[0059] As an example, service criticality level The exemplary values ​​are 1-5 (level 1 is the lowest and level 5 is the highest). The classification rules are determined based on the sensitivity of the service processing data (such as core transaction data corresponding to level 5) and the scope of business interruption impact (such as the entire system depending on level 5). For example, the core database service S=5 and the non-core query service S=2.

[0060] Step 302: Determine the risk score based on the deviation of the abnormal request, the service criticality level, and the duration.

[0061] Specifically, when a request is identified as risky, it's necessary not only to evaluate the request itself but also to simulate the potential propagation path of the risk along the service call chain. For example, if a front-end service is attacked by a suspicious web crawler, then all calls made by that front-end service to downstream data query services, even if the downstream calls themselves are in normal format, should have their associated downstream access priority preemptively lowered. As an example, risk scoring for abnormal requests... Satisfy the following formula: in, This indicates the deviation in the frequency of calls for the current abnormal request; This indicates its service criticality level in the service chain; This indicates the duration of the current abnormal request. In this formula... It quantifies the degree of abnormality of the current request relative to historical normal patterns. The larger the value, the longer the anomaly lasts; This reflects the data sensitivity of the service handling the request and its criticality in the call chain. The higher the value, the higher the risk score of the current abnormal request, and the more severe the risk propagation in the downstream request call chain. Optionally, = An example value for t_max is 60 minutes (i.e., 1 hour), and any time exceeding this duration will be calculated as 60 minutes.

[0062] Optionally, to improve the interpretability and auditability of risk scoring, the system implements the following standardization and visualization measures: Risk level mapping: Mapping the calculated risk score Mapped to a four-level risk label: low risk (0≤ <0.3), medium risk (0.3≤ <0.6), high risk (0.6≤ <0.9), emergency risk ( ≥0.9).

[0063] Automatic assignment of criticality level: The system supports integration with enterprise data classification and grading systems, and automatically assigns the service criticality level S based on the data tags processed by the service (such as: L1-public data, L2-internal data, L3-sensitive data, L4-confidential data), reducing the error of manual configuration.

[0064] Risk visualization dashboard: The system provides a real-time risk situation dashboard, displaying: the current list of active abnormal requests and their risk levels, the affected downstream services and their priority change trends, and a risk transmission path diagram.

[0065] Based on the above technical solution, this application combines the deviation degree of abnormal requests, service criticality level, and duration to conduct risk scoring, breaking through the limitations of single-dimensional risk assessment and enabling risk scoring to comprehensively reflect the actual harm of abnormal requests. Deviation quantifies the degree of abnormality of the current request relative to historical normal patterns, service criticality level takes into account the core needs of the business scenario, and duration reflects the cumulative effect of risk. This multi-dimensional risk quantification method makes risk assessment more aligned with actual business and security needs, providing a scientific and comprehensive risk basis for determining subsequent basic attenuation factors, ensuring that high-risk, high-importance abnormal requests are given priority control, and improving the targeting of data security management.

[0066] like Figure 5 As shown, in one possible implementation, the process of determining the risk association strength between the downstream request and the abnormal request in step 103 above can be specifically implemented through the following steps: Step 401: When multiple abnormal requests all call downstream requests, determine the initial risk association strength between each abnormal request and the downstream request, as well as the deviation of each abnormal request.

[0067] As one possible implementation, this step can be achieved through the following process: Determine the propagation hop count between each abnormal request and downstream requests. Obtain the historical call frequency between each abnormal request and downstream requests. The historical call frequency is used to characterize the cumulative number of times the service that invoked the abnormal request has called downstream requests. Based on the propagation hop count and historical call frequency of each abnormal request, calculate the initial risk association strength of each abnormal request.

[0068] It should be noted that in data access control, it is necessary not only to identify the risks of individual abnormal requests, but also to consider the propagation effect of individual abnormal requests in complex service topologies, spreading outward along the service call chain.

[0069] Specifically, in a service chain call, a current abnormal request may invoke other services; these invoked services are called downstream requests. This application identifies all its downstream requests and lowers the priority of the downstream requests of the abnormal request. The higher the risk of the abnormal request, the lower the priority of its downstream requests should be.

[0070] For any downstream request, obtain the number of hops h from the current abnormal request to the downstream request in the call chain, and each downstream request has an original priority order.

[0071] For any downstream request i of the current abnormal request x, define the initial risk association strength for risk propagation between requests. This association strength characterizes the likelihood of an abnormal request propagating downstream. Its propagation range is constrained by inter-service dependencies, and the propagation strength decreases with increasing hop count, while the risk impact also decreases over time. The farther the risk propagation distance (i.e., the more hops), the weaker the association strength, and the more priority the downstream request retains during subsequent priority decay. As an example, consider the initial risk association strength between abnormal request x and downstream request i. Satisfy the following formula: in, This represents the number of hops between the abnormal request x and the downstream request i. This indicates the maximum number of effective propagation hops preset, used to limit the scope of risk propagation, especially in scenarios with circular calls or closed-loop dependencies, to prevent risks from accumulating indefinitely. An example value of 5 is given (this can be adjusted based on the complexity of the service call chain topology). The rule for determining this value is: based on the average depth and topology analysis of historical service call chains, take 1.5 times this depth as the maximum effective hop count. It should be noted that the above formula applies to the number of hops. The scenario; when the number of conduction hops At that time, determine the initial risk association strength. =0. This indicates the historical call frequency between abnormal request x and downstream request i. This reflects the decay of the number of hops in the transmission of downstream requests. The closer the request is to the abnormal request (i.e., the fewer the hops), the stronger the initial risk association, the greater the priority decay of the downstream request, and the lower the final priority. Based on the call frequency in historical data, it reflects the degree of correlation between downstream request i and abnormal request x.

[0072] Step 402: Based on the initial risk association strength and deviation of each abnormal request, determine the risk contribution value of each abnormal request to downstream requests.

[0073] As one possible implementation, this step can be achieved through the following process: Based on the credibility of each anomalous request being identified as an anomalous request on its respective propagation path, the initial risk association strength of each anomalous request is corrected. Here, credibility is positively correlated with the proportion of anomalous requests on their respective propagation path. Based on the corrected initial risk association strength of each anomalous request and the deviation of each anomalous request, the risk contribution value of each anomalous request to downstream requests is determined.

[0074] Specifically, as abnormal requests are invoked layer by layer, requests are sent to some downstream services. When a downstream service is invoked, its own requests may still be abnormal. From the occurrence of the risk source request to the current moment, all issued abnormal requests will have a complex cumulative propagation effect on the current priority update. Simultaneously, the cumulative propagation of multiple abnormal requests to the same downstream request needs to be considered: starting from the risk source request, each downstream request may correspond to its own downstream requests, thus there will be a cumulative impact of multiple abnormal requests on the same downstream request. If a downstream request is affected by the propagation of multiple already occurred abnormal requests, its risk needs to be calculated cumulatively, and its corresponding priority should be lower, meaning its attenuation factor needs to be increased accordingly. As time goes on, the risk will naturally attenuate; downstream requests with more propagation hops should ideally have smaller attenuation factors. However, considering that downstream requests themselves may be abnormal, for downstream requests with multiple already occurred abnormal requests upstream, the cumulative risk situation needs to be taken into account, and the attenuation magnitude of their priority should be increased accordingly.

[0075] Furthermore, given the frequent inter-service calls, to more accurately distinguish between normal and abnormal requests: in the downstream request sequence of an abnormal request, the more coherent the transmission path of the abnormal request in the call chain (i.e., supported by preceding and following abnormal signals), the lower the possibility of misjudgment; if an isolated abnormal request judgment appears in the call chain (lacking supporting preceding and following abnormal signals), the reliability of the abnormal identification is lower, and its correlation strength with downstream request i needs to be reduced accordingly to avoid affecting the priority decay logic. Based on this, as an example, the risk contribution value of the issued abnormal request j and the downstream request i is... Satisfy the following formula: in, This represents the risk contribution value between the issued abnormal request j and the downstream request i; This indicates the initial risk correlation strength between the issued abnormal request j and the downstream request i; This represents the proportion of abnormal requests in the transmission path of the risk source request and the already issued abnormal request j. In this formula, the higher the proportion of abnormal requests in the transmission path, the smaller the correction to the initial correlation strength, and the closer the corrected correlation strength is to the original value; while when... The smaller the value, the lower the corrected correlation strength. In the subsequent risk aggregation calculation of downstream requests, the risk aggregation effect of this abnormal request j on downstream request i will be weakened, and the corresponding priority decay will also decrease. Abnormal request j is an abnormal request that can invoke downstream request i.

[0076] Step 403: Determine the risk association strength of downstream requests based on the risk contribution values ​​of multiple abnormal requests.

[0077] Specifically, for any downstream request i, the risk association strength (i.e., risk association strength) caused by all issued abnormal requests to downstream request i needs to be quantified. From the time the risk-originating request occurred up to the current time, all abnormal requests are selected that can invoke the service corresponding to downstream request i (i.e., the set of downstream requests for this type of abnormal request includes downstream request i). As an example, the risk association strength of downstream request i... Satisfy the following formula: In the formula, This indicates the risk correlation strength between the issued abnormal request j and the downstream request i, and n represents the total number of abnormal requests that can invoke the downstream request i. This represents the deviation in the call frequency of the issued request j. In this formula, for downstream request i, the stronger the correlation between the abnormal request and downstream request i, and the greater the deviation of the abnormal request, the greater the call risk of downstream request i, and the stronger the corresponding priority decay should be to avoid affecting normal business operations.

[0078] Based on the above technical solution, this application addresses the challenge of assessing the combined risk of multiple abnormal requests in scenarios where multiple abnormal requests jointly invoke the same downstream request. By calculating the risk contribution value of each individual abnormal request and summarizing these contributions to determine the overall correlation strength, this approach effectively solves the problem of assessing the cumulative risk of multiple abnormal requests. This method accurately quantifies the comprehensive risk impact on downstream requests, avoiding insufficient control caused by considering only individual abnormal requests and ignoring the cumulative risk effect. It makes the assessment of risk correlation strength more comprehensive and objective, providing a basis for adjusting the priority of downstream requests that aligns with the actual risk situation. This ensures that downstream services can implement differentiated control based on the comprehensive risk level, thereby improving data security protection capabilities in complex risk scenarios.

[0079] As one possible implementation, the process of determining the basic attenuation factor of risk transmission based on risk scoring in step 104 above can be specifically implemented as follows: The higher the risk score of the initial request, the higher the overall priority attenuation of all its downstream requests should be, i.e., the higher the base attenuation factor. Up to the current moment, within the propagation range originating from the risk source, the base attenuation factor is determined by considering the service calls of all issued requests. As an example, the base attenuation factor satisfies the following formula: in, This represents the average risk score of the request from the source of the risk; This indicates the number of abnormal requests issued up to the current time. This indicates the number of requests issued up to the current time. The value is greater than 0. In this formula, the higher the risk score of the risk source request, the greater the overall attenuation of the priority of all downstream requests in the downstream call chain, and the larger the corresponding basic attenuation factor. This indicates the percentage of abnormal requests out of all issued requests after the risk source request appears. The higher this percentage, the wider and deeper the abnormal impact of the current risk source request on the downstream call chain.

[0080] As one possible implementation, the process of determining the attenuation factor of the downstream request based on the correlation strength between the basic attenuation factor and the risk in step 105 above can be specifically implemented as follows: Risk transmission should not be unlimited; an appropriate attenuation mechanism must be established. Furthermore, considering the risk correlation strength of downstream requests, an attenuation factor for each downstream request is determined based on the base attenuation factor. This reflects the differentiated attenuation levels of different downstream requests under the influence of risk transmission and risk superposition, ultimately resulting in an effective request priority ranking. As an example, the attenuation factor for downstream request i... Satisfy the following formula: In the formula, Indicates the basic attenuation factor; This represents the sum of the risk association strengths of downstream request i. In this formula, the larger the sum of the risk association strengths of downstream request i, the greater the impact of the superposition of risks in the call chain it is affected by, and the larger the attenuation factor calculated based on the basic attenuation factor will be.

[0081] This determines the attenuation factor for each downstream request: the stronger the correlation between downstream request i and the abnormal request, and the stronger the cumulative effect of risk transmission, the more necessary it is to reduce its priority, and therefore assign it a larger attenuation factor; this design can make the attenuation mechanism more in line with actual business scenarios based on the characteristics of different services.

[0082] like Figure 5 The diagram illustrates a system architecture of a data access control system for data security management according to an embodiment of this application. ​ The system shown includes: Acquisition unit 501 is used to acquire service call chain data.

[0083] Processing unit 502 is used to identify abnormal requests in service call chain data and determine the risk score of abnormal requests.

[0084] Processing unit 502 is also used to determine the risk association strength between the downstream request of the abnormal request and the abnormal request itself. The risk association strength is used to characterize the degree to which the downstream request is affected by the abnormal request.

[0085] Processing unit 502 is also used to determine a basic attenuation factor for risk transmission based on the risk score. The basic attenuation factor is used to quantify the baseline degree of impact of abnormal requests on the priority of downstream requests.

[0086] The processing unit 502 is also used to determine the attenuation factor of the downstream request based on the strength of the correlation between the basic attenuation factor and the risk.

[0087] Update unit 503 is used to update the priority of downstream requests based on the decay factor.

[0088] Optionally, the data access control system for data security management provided in this application may further include: Monitoring and Intervention Unit: Used to display in real time the details of requests that are currently downgraded, delayed or restricted, including request ID, service name, original priority, current priority, reason for attenuation (related abnormal request ID), etc.

[0089] The fallback strategy configuration module supports configuring mandatory access policies for specific service or data classification levels (such as finance and HR systems), ensuring that their priority is not reduced even if associated with abnormal requests.

[0090] Priority protection engine: Ensures that the priority of all requests is not lower than the minimum priority threshold set by the system.

[0091] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0092] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

Claims

1. A data access control method for data security management, characterized in that, The method includes: Obtain service call chain data; Identify abnormal requests in the service call chain data and determine the risk score of the abnormal requests; Determine the risk association strength between the downstream request and the abnormal request; the risk association strength is used to characterize the degree to which the downstream request is affected by the abnormal request. Based on the risk score, a basic attenuation factor for risk transmission is determined; the basic attenuation factor is used to quantify the baseline degree of impact of the abnormal request on the priority of downstream requests. The attenuation factor of the downstream request is determined based on the strength of the correlation between the basic attenuation factor and the risk. The priority of the downstream request is updated based on the attenuation factor.

2. The data access control method for data security management according to claim 1, characterized in that, Identifying abnormal requests in the service call chain data includes: Determine the historical baseline frequency and normal fluctuation range of historical requests of the same type as the target request; the target request is any request in the service call chain data; the historical baseline frequency is used to characterize the call frequency benchmark value of the historical request; the normal fluctuation range is used to characterize the normal fluctuation range of the call frequency of the historical request. The deviation of the target request is determined based on the call frequency of the target request, the historical baseline frequency, and the normal fluctuation range. When the deviation exceeds a preset deviation, the target request is identified as an abnormal request.

3. The data access control method for data security management according to claim 2, characterized in that, Determining the risk score of the abnormal request includes: Obtain the deviation degree of the abnormal request, the service criticality level of the abnormal request, and the duration of the abnormal request; the service criticality level is used to characterize the importance of the service corresponding to the abnormal request when processing data. The risk score is determined based on the deviation of the abnormal request, the service criticality level, and the duration.

4. The data access control method for data security management according to claim 1, characterized in that, The method for determining the risk association strength between downstream requests of the anomalous request and the anomalous request further includes: When multiple abnormal requests are invoked by the downstream request, determine the initial risk association strength between each abnormal request and the downstream request, as well as the deviation of each abnormal request. Based on the initial risk association strength and deviation of each abnormal request, the risk contribution value of each abnormal request to the downstream request is determined; Based on the risk contribution values ​​of the multiple abnormal requests, the risk association strength of the downstream requests is determined.

5. The data access control method for data security management according to claim 4, characterized in that, Determining the initial risk association strength between each of the multiple anomalous requests and the downstream request includes: Determine the number of hops between each abnormal request and the downstream request; Obtain the historical call frequency between each abnormal request and the downstream request; the historical call frequency is used to characterize the cumulative number of times the service that called the abnormal request has called the downstream request; The initial risk association strength of each abnormal request is calculated based on the number of propagation hops and the historical call frequency.

6. The data access control method for data security management according to claim 5, characterized in that, Based on the initial risk association strength and deviation degree corresponding to each abnormal request, the risk contribution value of each abnormal request to the downstream request is determined, including: The initial risk association strength of each abnormal request is adjusted based on the credibility of each abnormal request being identified as an abnormal request on its respective transmission path; wherein, the credibility is positively correlated with the proportion of abnormal requests on its respective transmission path. Based on the corrected initial risk association strength of each anomalous request and the deviation of each anomalous request, the risk contribution value of each anomalous request to the downstream request is determined.

7. The data access control method for data security management according to claim 1, characterized in that, Based on the risk score, the fundamental attenuation factor for risk transmission is determined, including: Based on the risk score and the proportion of abnormal requests between the identification of the first abnormal request and the current time, the basic attenuation factor is determined.

8. The data access control method for data security management according to claim 1, characterized in that, The service call chain data includes the call relationship between services and the call frequency information of each request; Obtain service call chain data, including: In a microservice architecture, collect request sequence data generated by API calls between various services; The service call chain data is obtained by extracting the call relationships between services and the call frequency information of each request from the request sequence data.

9. The data access control method for data security management according to claim 1, characterized in that, Updating the priority of the downstream request based on the attenuation factor includes: The original priority of the downstream request is adjusted according to the attenuation factor to obtain the updated dynamic priority; The dynamic priority is associated with the metadata of the downstream request.

10. A data access control system for data security management, characterized in that, The system includes: The acquisition unit is used to acquire service call chain data; The processing unit is used to identify abnormal requests in the service call chain data and determine the risk score of the abnormal requests; The processing unit is further configured to determine the risk association strength between the downstream request of the abnormal request and the abnormal request; the risk association strength is used to characterize the degree to which the downstream request is affected by the abnormal request; The processing unit is further configured to determine a basic attenuation factor for risk transmission based on the risk score; the basic attenuation factor is used to quantify the baseline degree of impact of the abnormal request on the priority of downstream requests. The processing unit is further configured to determine the attenuation factor of the downstream request based on the basic attenuation factor and the risk correlation strength; An update unit is used to update the priority of the downstream request based on the decay factor.

Images