A Dynamic Control Method and System for Network Access Permissions Based on Behavior Analysis

Abstract

The present invention discloses a method and system for dynamically controlling network access permissions based on behavior analysis, specifically related to the field of network security technology, and is used to solve the problem of systematic service interruption caused by existing dynamic permission policies ignoring the implicit association between permissions and business logic; by collecting real-time behavior data of users and devices in real time to construct a permission dependency graph, identifying hidden dependency nodes that have indirect data flows with the target interface but are not explicitly called, and generating hidden path weight coefficients in combination with historical behavior logs; quantifying the interruption probability of permission adjustment to explicit and hidden dependency paths based on real-time behavior characteristics and the topological structure of the graph, and dynamically generating alternative access interfaces and data transfer interfaces; when detecting abnormal operations on alternative paths, backtracking to the original path through the permission dependency graph and iteratively optimizing the permission configuration; ensuring the dynamic contraction of permissions while maintaining the coherence of business data flows, and avoiding the interruption of associated services caused by local permission changes.

Description

Technical Field

[0001] The present invention relates to the field of network security technology. More specifically, the present invention relates to a method and system for dynamically controlling network access permissions based on behavior analysis. Background Art

[0002] Currently, the prior art usually dynamically adjusts network access permissions by real-time monitoring of user or device behavior characteristics such as access frequency, operation sequence, etc., and combines predefined security rules or statistical models. To a certain extent, it can identify abnormal behaviors and automatically implement permission restrictions. For example, when detecting an abnormal login of an account, it temporarily bans high-risk operations, or triggers an access downgrade mechanism when the traffic surges, so as to enhance the proactive defense ability of the system. Existing dynamic permission policies mostly focus on the direct mapping between the behaviors and permissions of a single user or device, lacking a global consideration of the systematic impacts caused by permission adjustments.

[0003] The limitations of the prior art are that the implicit correlation between permissions and business logics is not fully identified during the dynamic permission adjustment process, resulting in an irreconcilable contradiction between permission changes and system function stability. Specifically, when the permission control system implements dynamic policies based on local behavior data, it may disrupt legitimate business processes due to ignoring the permission dependency chain. For example, after restricting the access permission of an interface, its associated service may accidentally interrupt because it cannot obtain the necessary data, forcing the administrator to make a passive trade-off between security and business continuity. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a method and system for dynamically controlling network access permissions based on behavior analysis to solve the problems raised in the above background art.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] A method for dynamically controlling network access permissions based on behavior analysis, comprising the following steps:

[0007] S1. Collect real-time behavior data and extract real-time behavior characteristics;

[0008] S2. Construct a permission dependency graph based on the real-time behavior data and historical behavior logs, and identify the hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph;

[0009] S3. Generate a hidden path weight coefficient according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior logs;

[0010] S4. Determine the interruption probability of adjusting the permissions of the target interface to the explicit and hidden dependency paths through the real-time behavior characteristics, permission dependency graph, and hidden path weight coefficient;

[0011] S5. When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency hierarchy of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path;

[0012] S6. When detecting an abnormal operation of the alternative access path, update the permission dependency graph to trace back to the original path and iteratively optimize the permission level of the target interface.

[0013] In a preferred embodiment, S1 includes:

[0014] S1a. Synchronously collect real-time behavior data from the log server and interface call link of the target network system;

[0015] S1b. Classify and store the real-time behavior data according to the operation type, access interface identifier, and associated service identifier;

[0016] S1c. Filter abnormal formats of the classified and stored real-time behavior data, and eliminate data entries containing missing fields or illegal characters;

[0017] S1d. Convert the operation timestamps of the filtered real-time behavior data into a unified time zone format, and map the access interface identifier to a globally unique identifier;

[0018] S1e. Based on the preprocessed real-time behavior data, count the number of operations, interface call sequences, and service identifier correlation degrees within a unit time, and generate real-time behavior characteristics.

[0019] In a preferred embodiment, S2 includes:

[0020] S2a. Integrate the real-time behavior data with the historical behavior logs according to the access interface identifier and associated service identifier to generate an interface call relationship set and a service component data flow set;

[0021] S2b. Build the call dependency relationship of the access interface based on the interface call relationship set, and build the data transfer relationship of the service component based on the service component data flow set to form the nodes and edges of the permission dependency graph;

[0022] S2c. Traverse the reachable paths of the target interface in the permission dependency graph, and extract the nodes that have an indirect data flow with the associated service and no explicit call relationship as hidden dependency nodes.

[0023] In a preferred embodiment, S3 includes:

[0024] S3a. Extract the operation records associated with the hidden dependency nodes from the historical behavior logs, and filter out the historical log entries containing data transfer path trigger events;

[0025] S3b. Statistically count the number of trigger times of hidden dependent nodes within a preset time period, and calculate the trigger frequency as the ratio of the number of trigger times to the total duration of the time period;

[0026] S3c. Assign a business impact level value to the hidden dependent node according to the level of the associated service interruption event recorded in the historical log;

[0027] S3d. Generate a hidden path weight coefficient by weighted summation of the trigger frequency and the business impact level value.

[0028] In a preferred embodiment, the interruption event level is positively correlated with the criticality of the service function; the weight ratio for generating the hidden path weight coefficient is adjusted according to the preset security policy configuration.

[0029] In a preferred embodiment, S4 includes:

[0030] S4a. Generate a real-time behavior risk level of the explicit dependent path based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior characteristics;

[0031] S4b. Calculate the static topology risk level of the explicit dependent path according to the interface call edge weight and the service data dependency edge weight of the explicit dependent path in the permission dependency graph;

[0032] S4c. Cross-validate the real-time behavior risk level and the static topology risk level. If the difference between the two exceeds the preset fault tolerance threshold, select the higher level as the interruption probability of the explicit dependent path;

[0033] S4d. Traverse the service data dependency edge weight and the hidden path weight coefficient in the hidden dependent path. If the service data dependency edge weight is greater than the hidden path weight coefficient, determine the interruption probability of the hidden dependent path as the difference between the service data dependency edge weight and the hidden path weight coefficient;

[0034] S4e. Combine the interruption probabilities of the explicit dependent path and the hidden dependent path, and take the maximum value of the two as the interruption probability for adjusting the permissions of the target interface.

[0035] In a preferred embodiment, the explicit dependent path is a data flow path directly connected by interface call edges and having an explicit call relationship in the permission dependency graph; the hidden dependent path is a data flow path indirectly connected by service data dependency edges and containing at least one hidden dependent node in the permission dependency graph.

[0036] In a preferred embodiment, S5 includes:

[0037] S5a. When the interruption probability exceeds a preset threshold, traverse the data input nodes layer by layer from the root node to the leaf node according to the dependency levels of the explicit dependency paths and hidden dependency paths in the permission dependency graph;

[0038] S5b. Generate an alternative access path based on the traversal result. The alternative access path includes an alternative interface covering the explicit dependency path and a data transfer interface covering the hidden dependency path;

[0039] S5c. Verify the compatibility between the interface permissions of the alternative access path and the target interface permissions. If there is a conflict, dynamically downgrade the target interface permissions to a preset minimum compatible permission level;

[0040] S5d. Adjust the weights of the interface call edges and service data dependency edges in the permission dependency graph according to the dynamically downgraded target interface permission level.

[0041] In a preferred embodiment, S6 includes:

[0042] S6a. Detect abnormal operation types based on the comparison between the real-time behavior characteristics of the alternative access path and the historical behavior logs. The abnormal operation types include high-frequency calls, non-continuous interface accesses, and cross-service privilege escalation operations;

[0043] S6b. Adjust the attenuation factors of the interface call edge weights and service data dependency edge weights according to the permission dependency graph nodes associated with the abnormal operation types. The attenuation factor is an inverse proportional function of the weight value and the number of abnormal operations;

[0044] S6c. Trace back the interface call edge weights of the explicit dependency path and the service data dependency edge weights of the hidden dependency path to the pre-adjustment state according to the original path topological order of the permission dependency graph;

[0045] S6d. Combine the traced-back permission dependency graph with the real-time behavior characteristics, and iteratively execute the dynamic adjustment of the target interface permission level.

[0046] On the other hand, the present invention provides a dynamic network access permission control system based on behavior analysis, including:

[0047] Real-time behavior collection module: Collect real-time behavior data and extract real-time behavior characteristics;

[0048] Permission graph construction module: Construct a permission dependency graph based on real-time behavior data and historical behavior logs, and identify the hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph;

[0049] Hidden weight generation module: Generate a hidden path weight coefficient according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior logs;

[0050] Interruption Probability Evaluation Module: Determine the interruption probability of adjusting the permissions of the target interface for explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graph, and hidden path weight coefficients;

[0051] Dynamic Permission Adjustment Module: When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency levels of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path;

[0052] Path Backtracking and Optimization Module: When detecting abnormal operations on the alternative access path, update the permission dependency graph to backtrack the original path and iteratively optimize the permission level of the target interface.

[0053] Compared with the prior art, the present invention has the following beneficial effects:

[0054] 1. By constructing a dynamic recognition mechanism for permission dependency graphs and hidden dependency nodes, the global security of the permission adjustment strategy is significantly improved. The permission dependency graph depicts the explicit call relationships between interfaces and the data flow paths between service components, and combines the hidden dependency node recognition technology to reveal the indirect data flow associations that are easily overlooked in traditional permission control. Through the quantitative analysis of hidden path weight coefficients and real-time behavior characteristics, the potential impact of permission adjustment on the business link is accurately evaluated. When implementing dynamic permission downgrading or access path replacement, the risk of data breakage in associated services caused by permission contraction is effectively avoided, ensuring a high degree of coordination between security policy adjustment and system function stability;

[0055] 2. Through the dynamic permission iteration and optimization mechanism, a long-term balance between security control and business continuity is achieved. Based on the dependency level traversal and alternative path generation technology of the permission dependency graph, a compatible access channel is constructed synchronously during the permission adjustment process to ensure the seamless connection of key data flows; at the same time, the path backtracking and graph update mechanism triggered by abnormal operations can quickly restore the permission configuration deviation caused by policy misjudgment, forming a closed-loop feedback; by combining the real-time nature of dynamic policies with the experience of historical data, the problem of system oscillation caused by frequent permission changes is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 It is a flowchart of a method for dynamically controlling network access permissions based on behavior analysis according to the present invention;

[0057] Figure 2 It is a schematic structural diagram of a system for dynamically controlling network access permissions based on behavior analysis according to the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0058] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0059] Embodiment 1: Figure 1 A dynamic network access permission control method based on behavior analysis according to the present invention is provided, which includes the following steps:

[0060] S1. Collect real-time behavior data and extract real-time behavior features;

[0061] S2. Construct a permission dependency graph based on the real-time behavior data and historical behavior logs, and identify the hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph;

[0062] S3. Generate a hidden path weight coefficient according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior logs;

[0063] S4. Determine the interruption probability of adjusting the target interface permission for the explicit and hidden dependency paths through the real-time behavior features, permission dependency graph, and hidden path weight coefficient;

[0064] S5. When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency level of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path;

[0065] S6. When an abnormal operation of the alternative access path is detected, update the permission dependency graph to trace back to the original path and iteratively optimize the permission level of the target interface.

[0066] S1. Collect real-time behavior data and extract real-time behavior features, including:

[0067] S1a. Synchronously collect real-time behavior data from the log server and interface call link of the target network system;

[0068] S1b. Classify and store the real-time behavior data according to the operation type, access interface identifier, and associated service identifier;

[0069] S1c. Filter abnormal formats of the classified and stored real-time behavior data, and eliminate data entries containing missing fields or illegal characters;

[0070] S1d. Convert the operation timestamps of the filtered real-time behavior data into a unified time zone format, and map the access interface identifiers to globally unique identifiers;

[0071] S1e. Based on the preprocessed real-time behavior data, count the number of operations, interface call sequences, and service identifier association degrees within a unit time, and generate real-time behavior features.

[0072] In step S1a, the log server is used to store the operation records of users or devices in the system, and the interface call link intercepts network requests to obtain access information at the interface level. The real-time behavior data includes the operation types of users or devices in the system, access interface identifiers, and associated service identifiers. Among them, the operation types include three basic types: data reading, data writing, and service invocation. The access interface identifier is the unique resource locator of the interface, and the associated service identifier is the globally unique name of the service component.

[0073] In step S1b, the specific method of classified storage is as follows: divide the operation types into three independent data sets: data reading, data writing, and service invocation. Each data set is sharded and stored according to the hash value of the access interface identifier. At the same time, associate each access interface identifier with the corresponding service identifier to form a two-level storage structure indexed by the service identifier.

[0074] In step S1c, the determination criteria for abnormal formats include: any field of the operation type, access interface identifier, or associated service identifier is missing in the data entry; the data entry contains non-ASCII characters or illegal characters exceeding the preset length limit; the timestamp format of the data entry does not conform to the ISO 8601 standard. For abnormal data entries that meet any of the above conditions, directly eliminate them and record them in an independent abnormal log file.

[0075] In step S1d, the preprocessing includes the following operations: convert the operation timestamp to a unified time zone format based on Coordinated Universal Time. The specific conversion method is to parse the time zone offset of the original timestamp and recalculate it to Coordinated Universal Time; map the access interface identifier to a globally unique identifier. The mapping rule is to perform a SHA-256 hash operation on the complete path string of the interface identifier to generate a fixed-length hexadecimal encoded string as the globally unique identifier.

[0076] In step S1e, the generation process of real-time behavior features is as follows: count the number of operations within a unit time window. The length of the unit time window is preset to 5 minutes or 1 hour according to the business scenario; extract the interface call sequence, which is the sequential arrangement of access interface identifiers by users or devices within consecutive time windows; calculate the service identifier association degree, which is the frequency ratio of different service identifiers co-occurring within the same time window. The calculation method of the frequency ratio is the number of co-occurrences divided by the total number of operations. The real-time behavior features are finally output in a structured data format, including numerical values in three dimensions: the number of operations, the interface call sequence, and the service identifier association degree.

[0077] S2. Construct a permission dependency graph based on real-time behavior data and historical behavior logs, and identify hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph, including:

[0078] S2a. Integrate the real-time behavior data and historical behavior logs according to the access interface identifier and associated service identifier to generate an interface call relationship set and a service component data flow set;

[0079] S2b. Construct the call dependency relationship of the access interface based on the interface call relationship set, and construct the data transfer relationship of the service component based on the service component data flow set to form the nodes and edges of the permission dependency graph;

[0080] S2c. Traverse the reachable paths of the target interface in the permission dependency graph, and extract the nodes that have an indirect data flow with the associated service and no explicit call relationship as hidden dependency nodes.

[0081] In step S2a, the interface call records in the real-time behavior data are classified according to the access interface identifier. The classification method is to merge the operation type, call timestamp, and associated service identifier corresponding to the same access interface identifier into a call record set. The data transfer records in the historical behavior logs are matched according to the associated service identifier. The matching method is to extract the input data field, output data field, and transmission protocol type under the same associated service identifier. After data integration, an interface call relationship set and a service component data flow set are generated. The interface call relationship set includes the call order, call time interval, and concurrent call times within the same session between access interface identifiers. The service component data flow set includes the data input / output relationship, data field mapping rule, and transmission protocol type between service component identifiers.

[0082] In step S2b, the nodes of the permission dependency graph are divided into two categories: access interface nodes and service component nodes. The attributes of the access interface nodes include the access interface identifier, interface type, and the identifier of the service component to which the interface belongs; the attributes of the service component nodes include the service component identifier, service function description, and data sensitivity level. The edges of the permission dependency graph are divided into two categories: interface call edges and service data dependency edges. The generation method of the interface call edge is that if there is a record in the interface call relationship set that access interface identifier A calls access interface identifier B, then a directed edge is created in the graph from node A to node B, and the edge weight is the call count divided by the maximum call count within the preset time period; the generation method of the service data dependency edge is that if there is a record in the service component data flow set that service component identifier X transfers data to service component identifier Y, then a directed edge is created in the graph from node X to node Y, and the edge weight is the data volume divided by the maximum data volume within the preset time period.

[0083] The edge weight calculation formula for the interface call edge is: call count / maximum historical call count, where the maximum historical call count is obtained by counting the highest call count of the same interface in the historical behavior log within a preset time period (such as 24 hours). The edge weight calculation formula for the service data dependency edge is: data volume / maximum historical data volume, where the maximum historical data volume is obtained by counting the maximum transmitted data volume of the same service component in the historical behavior log within the preset time period.

[0084] In step S2c, starting from the target interface node, cross-node type traversal is performed along the interface call edge and the service data dependency edge. The traversal directions include the forward call of the interface call edge and the reverse data traceability of the service data dependency edge. For each service component node in each traversal path, check whether it meets the following conditions: there is at least one data flow path between the service component node and the target interface node, and this path does not contain a direct interface call edge from the target interface node to the service component node; the transmission protocol type in the data flow path is compatible with the interface type of the target interface node; the data sensitivity level of the service component node is not higher than the data sensitivity level of the target interface node. The service component nodes that meet the above conditions are marked as hidden dependency nodes.

[0085] The "call order" in the interface call relationship set refers to the order of interface calls within the same session, which is determined by timestamp sorting; the "concurrent call count" refers to the number of parallel requests for the same interface within the same time window, which is obtained by overlapping calculation of time windows. The "data field mapping rule" in the service component data flow set refers to the correspondence between input fields and output fields. For example, mapping the input field "user ID" to the output field "account ID", which is achieved by matching field names in the log.

[0086] The verification method for the data flow path not containing a direct interface call edge is: check whether there is an interface call edge from the target interface node to the service component node in the path. If not and there is a service data dependency edge, it is determined as a hidden dependency.

[0087] The compatibility of the transmission protocol type means that the interface type of the target interface node (such as REST API) supports the transmission protocol of the service component node (such as HTTP / HTTPS), which is achieved by matching the protocol whitelist.

[0088] The data sensitivity level is divided into three levels: public, internal, and confidential, which are predefined by the system administrator and stored in the metadata of the service component.

[0089] S3. Generate a hidden path weight coefficient according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior log, including:

[0090] S3a. Extract the operation records associated with the hidden dependency nodes from the historical behavior logs, and filter out the historical log entries that contain the data flow path trigger events;

[0091] S3b. Count the number of times the hidden dependency nodes are triggered within a preset time period, and calculate the trigger frequency as the ratio of the number of trigger times to the total duration of the time period;

[0092] S3c. Assign a business impact level value to the hidden dependency nodes according to the level of the associated service interruption events recorded in the historical logs. The level of the interruption event is positively correlated with the criticality of the service function;

[0093] S3d. Weighted sum the trigger frequency and the business impact level value to generate the hidden path weight coefficient, and the weight ratio is adjusted according to the preset security policy configuration.

[0094] In step S3a, each operation recorded in the historical behavior logs includes the operation type, access interface identifier, associated service identifier, and data flow path information. During filtering, according to the service component identifier of the hidden dependency node, match all log entries in the historical behavior logs that contain this service component identifier as the data input or output party. The definition of the data flow path trigger event is: in a single operation, the data is transmitted from the source service component through at least one intermediate service component to the target service component, and the transmission path contains the hidden dependency node. During the filtering process, if the source service component identifier, hidden dependency node identifier, and target service component identifier appear continuously in the data flow path field of the log entry, then it is determined that this entry is a valid trigger event.

[0095] In step S3b, the preset time period is dynamically set according to the business scenario. For example, it is set to 1 hour during the trading peak period and 24 hours during the off-peak period. The method for counting the number of trigger times is: for the valid trigger event log entries filtered in step S3a, group them according to the hidden dependency node identifier, and count the number of log entries in each group as the number of trigger times. The calculation formula for the trigger frequency is: the number of trigger times divided by the total number of seconds corresponding to the preset time period. For example, if the preset time period is 1 hour (3600 seconds) and the number of trigger times is 120 times, then the trigger frequency is 120 / 3600 = 0.033 times / second.

[0096] In step S3c, the business impact level value is divided into levels 1 to 5. The higher the value, the more serious the impact of service interruption. The level allocation rule is as follows: In the historical log, if more than 50% of the associated interface calls fail after a service component associated with a hidden dependency node experiences an interruption event, level 5 is allocated; if 10% - 50% of the interface calls fail, level 3 is allocated; if no interface call fails but data latency exceeds 5 minutes, level 1 is allocated. The criticality of the service function is determined according to the predefined service level agreement. For example, the payment service is a critical service, and the log query service is a non-critical service.

[0097] In step S3d, the weighted summation formula is: Hidden path weight coefficient = Trigger frequency × Frequency weight + Business impact level value × Level weight; For example, the initial values of both the frequency weight and the level weight are 0.5. When the security policy requires giving priority to ensuring business continuity, the level weight is increased to 0.7; when the security policy requires giving priority to preventing high-frequency risks, the frequency weight is increased to 0.7. The adjustment of the weight ratio is achieved by modifying the parameters in the configuration file. The configuration file format is key-value pairs, such as {"frequency_weight":0.7, "level_weight":0.3}.

[0098] S4. Determine the interruption probability of adjusting the permissions of the target interface for the explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients, including:

[0099] S4a. Generate the real-time behavior risk level of the explicit dependency path based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior characteristics;

[0100] S4b. Calculate the static topology risk level of the explicit dependency path according to the interface call edge weight and the service data dependency edge weight in the permission dependency graph;

[0101] S4c. Cross-validate the real-time behavior risk level and the static topology risk level. If the difference between the two exceeds the preset fault tolerance threshold, select the higher level as the interruption probability of the explicit dependency path;

[0102] S4d. Traverse the service data dependency edge weight and the hidden path weight coefficient in the hidden dependency path. If the service data dependency edge weight is greater than the hidden path weight coefficient, determine that the interruption probability of the hidden dependency path is the difference between the service data dependency edge weight and the hidden path weight coefficient;

[0103] S4e. Combine the interruption probabilities of the explicit dependency path and the hidden dependency path, and take the maximum value of the two as the interruption probability of adjusting the permissions of the target interface.

[0104] The explicit dependency path is the data flow path in the permission dependency graph that is directly connected by interface call edges and has an explicit call relationship; the hidden dependency path is the data flow path in the permission dependency graph that is indirectly connected by service data dependency edges and contains at least one hidden dependency node.

[0105] In step S4a, the length of the interface call sequence refers to the number of different interfaces accessed by a user or device within a continuous time window. For example, if interfaces A, B, and C are called in sequence within 5 minutes, the sequence length is 3. The number of operations per unit time is obtained by counting the number of calls to the same interface within a preset time window (such as 1 minute). The real-time behavior risk level is divided into three levels: low, medium, and high. When the length of the interface call sequence exceeds 5 and the number of operations exceeds 100 times per minute, it is marked as a high risk level; when the sequence length is 3 - 5 and the number of operations is 50 - 100 times per minute, it is marked as a medium risk level; in other cases, it is marked as a low risk level. The risk level threshold is set according to the average value of normal operations in the historical behavior log. For example, the high risk threshold = historical average × 2.

[0106] In step S4b, the weight of the interface call edge is the normalized value of the call count generated in step S2, and the weight of the service data dependency edge is the normalized value of the data volume. The calculation method of the static topology risk level is: multiply the weights of all interface call edges in the explicit dependency path, and then multiply by the average value of the weights of the service data dependency edges. For example, an explicit dependency path contains interface call edge weights of 0.8 and 0.6, and the average value of the service data dependency edge weights is 0.7, then the static topology risk level is 0.8 × 0.6 × 0.7 = 0.336. The static topology risk level is divided into three levels: high risk if greater than 0.25, medium risk if 0.1 - 0.25, and low risk if less than 0.1.

[0107] In step S4c, the preset fault tolerance threshold is set according to the deviation range between the real-time and static risk levels in the historical data. For example, if the historical data shows that the maximum deviation between the real-time risk level and the static risk level is 1 level (such as real-time high risk corresponding to static medium risk), then the fault tolerance threshold is set to 1 level. During cross - verification, if the real-time risk level is high risk and the static risk level is medium risk, and the difference between the two is 1 level, exceeding the fault tolerance threshold, the interruption probability of the explicit dependency path adopts the high risk level; if the difference does not exceed the threshold, the average value of the two is taken. The interruption probability is mapped to a numerical value according to the level: low risk = 0.3, medium risk = 0.6, high risk = 0.9.

[0108] In step S4d, the weight of the service data dependency edge is the normalized value of the data volume generated in step S2, and the weight coefficient of the hidden path is the weighted result generated in step S3. The difference calculation rule is as follows: if the weight of the service data dependency edge is 0.8 and the weight coefficient of the hidden path is 0.5, then the interruption probability is 0.8 - 0.5 = 0.3; if the weight of the service data dependency edge is less than or equal to the weight coefficient of the hidden path, the interruption probability directly takes the weight coefficient of the hidden path. This rule is based on the following logic: a high service data flow weight may mask the potential risks of the hidden path, and the real risks need to be exposed through the difference.

[0109] In step S4e, the merging rule is as follows: compare the interruption probability of the explicit dependency path with the interruption probability of the hidden dependency path, and select the larger value as the final interruption probability. For example, if the interruption probability of the explicit path is 0.6 and the interruption probability of the hidden path is 0.3, then the total interruption probability is 0.6; if the explicit path is 0.3 and the hidden path is 0.8, then the total interruption probability is 0.8. This rule ensures that high-risk paths are prioritized for prevention to avoid missed judgments.

[0110] The explicit dependency path is the data transfer path in the permission dependency graph that is directly connected by interface call edges and has an explicit call relationship, such as the continuous call link of interface A → interface B → interface C. The hidden dependency path is the data transfer path in the permission dependency graph that is indirectly connected by service data dependency edges and contains at least one hidden dependency node, such as interface A → service X (hidden dependency node) → interface B, where there is no direct call relationship between interface A and service X but there is data flow transmission.

[0111] S5. When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency level of the permission dependency graph, and dynamically adjust the permission level of the target interface and generate an alternative access path, including:

[0112] S5a. When the interruption probability exceeds the preset threshold, traverse the data input nodes layer by layer from the root node to the leaf node according to the dependency levels of the explicit dependency path and the hidden dependency path in the permission dependency graph;

[0113] S5b. Generate an alternative access path based on the traversal result. The alternative access path includes an alternative interface that covers the explicit dependency path and a data transfer interface that covers the hidden dependency path;

[0114] S5c. Verify the compatibility between the interface permissions of the alternative access path and the permissions of the target interface. If there is a conflict, dynamically downgrade the permissions of the target interface to the preset lowest compatible permission level;

[0115] S5d. Adjust the weights of the interface call edges and the service data dependency edges in the permission dependency graph according to the dynamically downgraded permission level of the target interface.

[0116] In step S5a, the root node of the permission dependency graph is defined as an access interface node without any incoming edges (i.e., not called by other interfaces), and the leaf node is defined as an access interface node without any outgoing edges (i.e., not calling other interfaces). The dependency level is divided according to the path depth from the node to the root node. The smaller the path depth, the higher the level. The traversal order starts from the root node and accesses the nodes of each layer in increasing order of layer depth. For example, root node (level 1) → child node (level 2) → leaf node (level 3). The data input node refers to the node that provides the data source for the current interface in the explicit dependency path, or the service component node that transmits data through the service data dependency edge in the hidden dependency path.

[0117] The preset threshold is set based on the interruption probability distribution of normal operations in the historical behavior log and the risk tolerance of the business scenario. It is calculated by adding twice the standard deviation to the historical interruption probability mean. For example, when the mean is 0.2 and the standard deviation is 0.1, the threshold is set to 0.4. In high-security scenarios (such as payment interfaces), the threshold is set to 0.3, and in high-availability scenarios (such as log interfaces), it is set to 0.6. Dynamic adjustment includes load-sensitive adjustment (the threshold is increased by 10% when the CPU usage rate > 80%) and event-driven adjustment (the threshold is temporarily reduced after a service interruption). When the interruption probability of the payment interface exceeds 0.3, downgrading is immediately triggered, and when the log interface exceeds 0.6, it is triggered to balance security and system availability.

[0118] In step S5b, the alternative interface is an access interface with the same function as the target interface but a lower permission level. For example, if the target interface is the "user data write interface", the alternative interface is the "user data read-only interface". The selection rule for the alternative interface is: search in the permission dependency graph for an interface with the same service component identifier as the target interface and a permission level lower than the current level. The data transfer interface is a newly added temporary data proxy node used to replace the data transfer function of the original service component node in the hidden dependency path. The generation method of the data transfer interface is: create a temporary interface downstream of the service component data dependency edge and split the original data flow into a path of "original service component → data transfer interface → target interface".

[0119] In step S5c, the compatibility verification rule is: check whether the permission level of the alternative interface includes the necessary operation permissions of the target interface. For example, if the target interface requires "read and write" permissions and the alternative interface only supports "read-only" permissions, it is determined to be incompatible. The lowest compatible permission level is preset according to the interface type. For example, the lowest compatible level of the "user data write interface" is "read-only", and the lowest compatible level of the "payment interface" is "query". The permission downgrading operation includes: modifying the permission field in the access control list (ACL) of the target interface to the lowest compatible level and synchronously updating the permission scope of the identity authentication token.

[0120] In step S5d, the adjustment method of the interface call edge weight is as follows: multiply the call edge weight corresponding to the target interface by a downgrading coefficient, which is set according to the difference in permission levels. For example, if the target interface is downgraded from "read-write" to "read-only" and the downgrading coefficient is 0.5, the original weight of 0.8 is adjusted to 0.8 × 0.5 = 0.4. The adjustment method of the service data dependency edge weight is as follows: if the downgrading of the target interface's permission results in a restricted data output range of the associated service component, then reduce the weight of the relevant service data dependency edge proportionally. For example, if the number of data output fields is reduced from 10 to 5, the weight is adjusted from 0.6 to 0.6 × (5 / 10) = 0.3.

[0121] S6. When an abnormal operation of the alternative access path is detected, update the permission dependency graph to trace back to the original path and iteratively optimize the permission level of the target interface, including:

[0122] S6a. Compare the real-time behavior characteristics of the alternative access path with the historical behavior logs to detect the type of abnormal operation. The types of abnormal operations include high-frequency calls, discontinuous interface access, and cross-service privilege escalation operations;

[0123] S6b. According to the nodes of the permission dependency graph associated with the type of abnormal operation, adjust the attenuation factor of the interface call edge weight and the service data dependency edge weight. The attenuation factor is an inverse proportional function of the weight value and the number of abnormal operations;

[0124] S6c. According to the topological order of the original path of the permission dependency graph, trace back the interface call edge weight of the explicit dependency path and the service data dependency edge weight of the hidden dependency path to the state before adjustment;

[0125] S6d. Combine the traced-back permission dependency graph with the real-time behavior characteristics and iteratively perform dynamic adjustment of the permission level of the target interface.

[0126] In step S6a, the interface call frequency threshold in the real-time behavior characteristics is determined by statistically counting the highest frequency value of normal operations in the historical behavior logs and multiplying it by a factor of 1.5. For example, if the historical log shows that the highest frequency of normal operations for a certain interface is 200 times per minute, then the abnormal high-frequency call threshold is 300 times per minute.

[0127] The determination basis for discontinuous interface access is whether the interface call sequence matches the pre-stored legal continuous pattern library. For example, the legal pattern is interface A → interface B → interface C. If the real-time sequence is interface A → interface C, it is determined as discontinuous access. Cross-service privilege escalation operations are verified through the role-service permission mapping table. For example, when the user role is "customer service", the white list of its permissions only includes query interfaces. If a payment interface is accessed, a privilege escalation warning is triggered.

[0128] In step S6b, the attenuation factor is calculated as follows: Attenuation factor = original weight value / (1 + number of abnormal operations), where the statistical period of the number of abnormal operations is the most recent 1 hour, and it is cleared and recounted every hour. For example, if the original weight of the interface call edge is 0.8 and the associated number of abnormal operations is 3 times, then the weight after attenuation = 0.8 / (1 + 3) = 0.2. The weight adjustment logic for the service data dependency edge is the same. For example, if the original weight of the service data dependency edge is 0.6 and the number of abnormal times is 2 times, then the weight after attenuation = 0.6 / (1 + 2) = 0.2. After the weight is adjusted, the edge weight value of the corresponding node in the permission dependency graph is updated in real time.

[0129] In step S6c, the original path topological order is recorded as follows: When constructing the permission dependency graph in step S2, the creation logs of nodes and edges are stored in the generation order of the interface call relationship and the service data flow relationship. When backtracking, the weights are restored in sequence according to the order in the log. For example, the weight of the call edge of interface B is adjusted from 0.8 to 0.4 in step S5d. When backtracking, the original value 0.8 is read from the log and updated to the graph; the weight of the data dependency edge of service Y is adjusted from 0.6 to 0.2 and restored to 0.6 after backtracking.

[0130] In step S6d, the termination conditions for iterative dynamic adjustment are any of the following situations:

[0131] After two consecutive iterations, the interruption probability of the target interface permission is lower than the preset threshold (such as 0.4);

[0132] The maximum number of iterations is reached (such as 3 times) to avoid an infinite loop caused by continuous abnormal triggering.

[0133] In each iteration, steps S4 (interruption probability calculation) and S5 (permission adjustment) are re-executed. For example, the alternative path A is generated in the first iteration, and the alternative path B is generated in the second iteration until the termination condition is met.

[0134] Embodiment 2: Figure 2 A structural schematic diagram of a network access permission dynamic control system based on behavior analysis according to the present invention is given. A network access permission dynamic control system based on behavior analysis includes:

[0135] Real-time behavior acquisition module: Collect real-time behavior data and extract real-time behavior features;

[0136] Permission graph construction module: Construct a permission dependency graph based on real-time behavior data and historical behavior logs, and identify hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph;

[0137] Hidden weight generation module: Generate a hidden path weight coefficient according to the trigger frequency and business impact level of hidden dependency nodes in the historical behavior logs;

[0138] Interruption probability evaluation module: Determine the interruption probability of adjusting the permissions of the target interface for explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients;

[0139] Dynamic permission adjustment module: When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency levels of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path;

[0140] Path backtracking optimization module: When an abnormal operation of the alternative access path is detected, update the permission dependency graph to backtrack the original path and iteratively optimize the permission level of the target interface.

[0141] The above formulas are all dimensionless and take their numerical values for calculation. The formulas are obtained by collecting a large amount of data for software simulation to obtain a formula that is closest to the actual situation. The preset parameters and threshold selection in the formulas are set by those skilled in the art according to the actual situation.

[0142] It should be noted that the present invention can be deployed on the device itself to implement embedded applications, or can also run on a PC or other terminals with a user interface, so as to meet various hardware environments and usage requirements.

[0143] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access, or a data storage device such as a server or data center that contains one or more collections of available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media. The semiconductor media can be a solid-state drive.

[0144] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and modules described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0145] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division. In actual implementation, there can be other division methods. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the couplings, direct couplings, or communication connections shown or discussed with each other can be through some interfaces. The indirect couplings or communication connections of the devices or modules can be in electrical, mechanical, or other forms.

[0146] The modules described as separate components may or may not be physically separated. The components shown as modules may or may not be physical modules. They can be located in one place or distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0147] In addition, in each embodiment of the present application, the functional modules can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module.

[0148] If the function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or a part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes.

[0149] As described above, it is only the specific implementation manner of the present application. However, the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily think of changes or substitutions, which should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

[0150] Finally: The above are only the preferred embodiments of the present invention and are not used to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A dynamic control method for network access rights based on behavior analysis, characterized in that, It includes the following steps: S1. Collect real-time behavior data and extract real-time behavior features; S2. Construct a permission dependency graph based on the real-time behavior data and historical behavior logs, and identify the hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph; S3. Generate hidden path weight coefficients according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior logs, including: S3a. Extract the operation records associated with the hidden dependency nodes from the historical behavior logs, and filter out the historical log entries containing data transfer path trigger events; S3b. Count the number of times the hidden dependency nodes are triggered within a preset time period, and calculate the trigger frequency as the ratio of the number of trigger times to the total duration of the time period; S3c. Assign a business impact level value to the hidden dependency nodes according to the level of associated service interruption events recorded in the historical logs; S3d. Weightedly sum the trigger frequency and the business impact level value to generate the hidden path weight coefficient; The level of the interruption event is positively correlated with the criticality of the service function; the weight ratio for generating the hidden path weight coefficient is adjusted according to the preset security policy configuration; S4. Determine the interruption probabilities of the explicit and hidden dependency paths by adjusting the permissions of the target interface through the real-time behavior features, permission dependency graph, and hidden path weight coefficients, including: S4a. Generate the real-time behavior risk level of the explicit dependency path based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior features; S4b. Calculate the static topological risk level of the explicit dependency path according to the interface call edge weight and service data dependency edge weight in the permission dependency graph; S4c. Cross-validate the real-time behavior risk level and the static topological risk level. If the difference between the two exceeds the preset fault tolerance threshold, select the higher level as the interruption probability of the explicit dependency path; S4d. Traverse the service data dependency edge weight and the hidden path weight coefficient in the hidden dependency path. If the service data dependency edge weight is greater than the hidden path weight coefficient, determine that the interruption probability of the hidden dependency path is the difference between the service data dependency edge weight and the hidden path weight coefficient; S4e. Combine the interruption probabilities of the explicit dependency path and the hidden dependency path, and take the maximum value of the two as the interruption probability of adjusting the permissions of the target interface; Among them, the explicit dependency path is a data transfer path directly connected by interface call edges and having an explicit call relationship in the permission dependency graph; the hidden dependency path is a data transfer path indirectly connected by service data dependency edges and containing at least one hidden dependency node in the permission dependency graph; S5. When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency level of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path; S6. When an abnormal operation of the alternative access path is detected, update the permission dependency graph to trace back to the original path and iteratively optimize the permission level of the target interface.

2. The dynamic control method for network access rights based on behavior analysis according to claim 1, characterized in that S1 includes: S1a. Synchronously collect real-time behavior data from the log server and interface call link of the target network system; S1b. Classify and store the real-time behavior data according to the operation type, access interface identifier, and associated service identifier; S1c. Filter the abnormally formatted real-time behavior data classified and stored, and eliminate the data entries containing missing fields or illegal characters; S1d. Convert the operation timestamps of the filtered real-time behavior data into a unified time zone format, and map the access interface identifier to a globally unique identifier; S1e. Based on the preprocessed real-time behavior data, count the number of operations, interface call sequences, and service identifier correlation degrees within a unit time, and generate real-time behavior characteristics.

3. A method for dynamically controlling network access permissions based on behavior analysis according to claim 1, characterized in that S2 Including: S2a. Integrate the real-time behavior data and historical behavior logs according to the access interface identifier and associated service identifier to generate an interface call relationship set and a service component data flow set; S2b. Build the call dependency relationship of the access interface based on the interface call relationship set, and build the data transfer relationship of the service component based on the service component data flow set to form the nodes and edges of the permission dependency graph; S2c. Traverse the reachable paths of the target interface in the permission dependency graph, and extract the nodes that have an indirect data flow with the associated service and no explicit call relationship as hidden dependency nodes.

4. A dynamic control method for network access rights based on behavior analysis according to claim 1, characterized in that S5 Including: S5a. When the interruption probability exceeds the preset threshold, traverse the data input nodes layer by layer from the root node to the leaf node according to the dependency levels of the explicit dependency paths and hidden dependency paths in the permission dependency graph; S5b. Generate an alternative access path based on the traversal result. The alternative access path includes an alternative interface covering the explicit dependency path and a data transfer interface covering the hidden dependency path; S5c. Verify the compatibility between the interface permissions of the alternative access path and the target interface permissions. If there is a conflict, dynamically downgrade the target interface permissions to the preset lowest compatible permission level; S5d. Adjust the weights of the interface call edges and service data dependency edges in the permission dependency graph according to the dynamically downgraded target interface permission level.

5. A dynamic control method for network access rights based on behavior analysis according to claim 1, characterized in that S6 Including: S6a. Compare the real-time behavior characteristics of the alternative access path with the historical behavior logs to detect abnormal operation types. The abnormal operation types include high-frequency calls, non-continuous interface accesses, and cross-service privilege escalation operations; S6b. Adjust the attenuation factors of the weights of the interface call edges and service data dependency edges according to the nodes of the permission dependency graph associated with the abnormal operation types. The attenuation factor is an inverse proportional function of the weight value and the number of abnormal operations; S6c. Trace back the weights of the interface call edges of the explicit dependency path and the service data dependency edges of the hidden dependency path to the state before adjustment according to the original path topological order of the permission dependency graph; S6d. Combine the traced-back permission dependency graph and real-time behavior characteristics, and iteratively execute the dynamic adjustment of the target interface permission level.

6. A dynamic control system for network access rights based on behavior analysis, which is used to implement a dynamic control method for network access rights based on behavior analysis according to any one of claims 1-5, characterized in that, Including: Real-time behavior collection module: Collect real-time behavior data and extract real-time behavior characteristics; Permission graph construction module: Construct a permission dependency graph based on real-time behavior data and historical behavior logs, and identify hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph; Hidden weight generation module: Generate a hidden path weight coefficient according to the trigger frequency and business impact level of the hidden dependency nodes in the historical behavior logs; Interrupt probability evaluation module: Determine the interruption probability of adjusting the permissions of the target interface for explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients; Dynamic permission adjustment module: When the interruption probability exceeds the preset threshold, traverse the data input nodes of the explicit and hidden dependency paths based on the dependency levels of the permission dependency graph, dynamically adjust the permission level of the target interface, and generate an alternative access path; Path backtracking and optimization module: When an abnormal operation of the alternative access path is detected, update the permission dependency graph to backtrack the original path and iteratively optimize the permission level of the target interface.

Images