Network access authority dynamic management and control method and system based on behavior analysis

Abstract

The invention discloses a network access permission dynamic management and control method and system based on behavior analysis, particularly relates to the technical field of network security, and is used for solving the problem of systematic service interruption caused by neglecting implicit association between permission and service logic in the existing dynamic permission strategy. The method comprises the following steps: constructing a permission dependency graph by collecting real-time behavior data of a user and equipment in real time, identifying hidden dependency nodes which have indirect data streams with a target interface but are not explicitly called, and generating a hidden path weight coefficient in combination with a historical behavior log; based on the real-time behavior characteristics and the map topological structure, quantizing the outage probability of permission adjustment on dominant and hidden dependency paths, and dynamically generating an alternative access interface and a data transfer interface; when an alternative path abnormal operation is detected, an original path is traced back through a permission dependency graph, and permission configuration is iteratively optimized; the continuity of the business data flow is maintained while the dynamic contraction of the authority is ensured, and the interruption of the associated service caused by local authority change is avoided.

Description

Technical Field

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

[0002] At present, existing technologies usually monitor the behavioral characteristics of users or devices such as access frequency and operation sequence in real time, and dynamically adjust network access rights in combination with predefined security rules or statistical models. They can identify abnormal behaviors and automatically implement permission restrictions to a certain extent. For example, when abnormal account login is detected, high-risk operations are temporarily blocked, or when traffic surges, access downgrade mechanisms are triggered, thereby improving the system's active defense capabilities. Existing dynamic permission strategies mostly focus on the direct mapping of the behavior and permissions of a single user or device, and lack a global consideration of the systemic impact caused by permission adjustments.

[0003] The limitation of the existing technology is that the implicit correlation between permissions and business logic is not fully identified during the dynamic permission adjustment process, resulting in an irreconcilable contradiction between permission changes and system functional stability. Specifically, when the permission management system implements dynamic policies based on local behavior data, it may destroy legitimate business processes due to ignoring the permission dependency chain. For example, after restricting the access rights of a certain interface, its associated services are unexpectedly interrupted due to the inability to obtain necessary data, forcing administrators to passively choose between security and business continuity. Summary of the invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a method and system for dynamic management of network access rights based on behavior analysis to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions: A method for dynamic control of network access rights based on behavior analysis includes the following steps: S1, collect real-time behavior data and extract real-time behavior features; S2. Build 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; S3, generating a hidden path weight coefficient according to the triggering frequency and business impact level of the hidden dependent node in the historical behavior log; S4. Determine the interruption probability of adjusting the target interface permissions on the explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients; S5. When the interruption probability exceeds a preset threshold, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; S6. When an abnormal operation of the alternative access path is detected, the permission dependency graph is updated to trace back the original path and iteratively optimize the target interface permission level.

[0006] In a preferred embodiment, S1 comprises: 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 abnormal format of the classified and stored real-time behavior data and remove data entries containing missing fields or illegal characters; S1d, converting the operation timestamp of the filtered real-time behavior data into a unified time zone format, and mapping the access interface identifier to a globally unique identifier; S1e. Based on the pre-processed real-time behavior data, the number of operations per unit time, the interface call sequence and the service identification correlation are counted to generate real-time behavior features.

[0007] In a preferred embodiment, S2 includes: S2a, integrating the real-time behavior data and the historical behavior log according to the access interface identifier and the associated service identifier, and generating an interface call relationship set and a service component data flow set; S2b. Construct the call dependency relationship of the access interface based on the interface call relationship set, and construct the data flow relationship of the service component based on the service component data flow set, so as 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 nodes that have indirect data flows with associated services and no explicit call relationships as hidden dependency nodes.

[0008] In a preferred embodiment, S3 includes: S3a, extracting operation records associated with hidden dependent nodes from historical behavior logs, and filtering out historical log entries containing data flow path triggering events; S3b, counting the number of times the hidden dependent nodes are triggered within a preset time period, and calculating the trigger frequency as the ratio of the number of triggers to the total length of the time period; S3c, assigning 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; S3d. The trigger frequency and the service impact level are weighted and summed to generate a hidden path weight coefficient.

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

[0010] In a preferred embodiment, S4 includes: S4a, based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior characteristics, generate the real-time behavior risk level of the explicit dependency path; S4b, calculating the static topological risk level of the explicit dependency path according to the interface call edge weight and the service data dependency edge weight of the explicit dependency path in the permission dependency graph; 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; S4d, traversing 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, then determining the interruption probability of the hidden dependency path as 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 for adjusting the target interface permissions.

[0011] In a preferred embodiment, an explicit dependency path is a data flow path in the permission dependency graph that is directly connected through an interface call edge and has an explicit call relationship; a hidden dependency path is a data flow path in the permission dependency graph that is indirectly connected through a service data dependency edge and contains at least one hidden dependency node.

[0012] In a preferred embodiment, S5 includes: 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 hierarchy of the explicit dependency path and the hidden dependency path in the permission dependency graph; S5b, generating an alternative access path based on the traversal result, the alternative access path including an alternative interface covering the explicit dependency path and a data transfer interface covering the hidden dependency path; S5c, verifying the compatibility of the interface permissions of the alternative access path with the target interface permissions, and if there is a conflict, dynamically downgrading the target interface permissions to a preset minimum compatible permission level; S5d. According to the permission level of the target interface after dynamic downgrade, adjust the interface call edge weight and the service data dependency edge weight in the permission dependency graph.

[0013] In a preferred embodiment, S6 includes: S6a, compare the real-time behavior characteristics of alternative access paths with historical behavior logs to detect abnormal operation types, including high-frequency calls, discontinuous interface access, and cross-service unauthorized operations; S6b. According to the permission dependency graph node associated with the abnormal operation type, 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. S6c, according to the original path topology order 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; S6d. Combine the permission dependency graph after backtracking with the real-time behavior characteristics, and iteratively perform dynamic adjustment of the permission level of the target interface.

[0014] In another aspect, the present invention provides a network access rights dynamic management and control system based on behavior analysis, comprising: Real-time behavior collection module: collects real-time behavior data and extracts real-time behavior features; Permission graph construction module: Builds a permission dependency graph based on real-time behavior data and historical behavior logs, and identifies hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph; Hidden weight generation module: generates hidden path weight coefficients based on the triggering frequency and business impact level of hidden dependent nodes in historical behavior logs; Interruption probability assessment module: Determines the interruption probability of adjusting the target interface permissions 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, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; Path backtracking optimization module: When abnormal operation of alternative access paths is detected, the permission dependency graph is updated to backtrack the original path and iteratively optimize the target interface permission level.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By constructing a permission dependency graph and a dynamic identification mechanism for hidden dependency nodes, the global security of permission adjustment strategies is significantly improved. The permission dependency graph depicts the explicit call relationship between interfaces and the data flow path between service components, and combines hidden dependency node identification technology to reveal indirect data flow associations that are easily overlooked in traditional permission management and control. By quantifying the hidden path weight coefficient and integrating real-time behavior characteristics, the potential impact of permission adjustment on business links is accurately evaluated. When implementing dynamic permission downgrade or access path replacement, the risk of associated service data rupture caused by permission contraction is effectively avoided, ensuring that security policy adjustment and system function stability are highly coordinated; 2. A long-term balance between security management and business continuity is achieved through a dynamic permission iteration optimization mechanism. Based on the dependency hierarchy traversal and alternative path generation technology of the permission dependency graph, a compatible access channel is simultaneously built during the permission adjustment process to ensure seamless connection of key data flows. At the same time, the path backtracking and graph update mechanism triggered by abnormal operations can quickly restore permission configuration deviations caused by policy misjudgments, forming a closed-loop feedback loop. By combining the real-time nature of dynamic policies with the empiricism of historical data, the system shock problem caused by frequent changes in permissions is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 This is a flow chart of a method for dynamically controlling network access rights based on behavior analysis according to the present invention; Figure 2 This is a structural schematic diagram of a network access rights dynamic management and control system based on behavior analysis according to the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0018] Embodiment 1: Figure 1 The present invention provides a method for dynamic management and control of network access rights based on behavior analysis, which includes the following steps: S1, collect real-time behavior data and extract real-time behavior features; S2. Build 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; S3, generating a hidden path weight coefficient according to the triggering frequency and business impact level of the hidden dependent node in the historical behavior log; S4. Determine the interruption probability of adjusting the target interface permissions on the explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients; S5. When the interruption probability exceeds a preset threshold, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; S6. When an abnormal operation of the alternative access path is detected, the permission dependency graph is updated to trace back the original path and iteratively optimize the target interface permission level.

[0019] S1. Collect real-time behavior data and extract real-time behavior features, including: 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 abnormal format of the classified and stored real-time behavior data and remove data entries containing missing fields or illegal characters; S1d, converting the operation timestamp of the filtered real-time behavior data into a unified time zone format, and mapping the access interface identifier to a globally unique identifier; S1e. Based on the pre-processed real-time behavior data, the number of operations per unit time, the interface call sequence and the service identification correlation are counted to generate real-time behavior features.

[0020] 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 obtains the access information of the interface level by intercepting the network request. The real-time behavior data includes the operation type of the user or device in the system, the access interface identifier and the associated service identifier, where the operation type includes three basic types: data reading, data writing and service calling. 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.

[0021] In step S1b, the specific method of classified storage is: divide the operation type into three independent data sets: data reading, data writing and service call, and store them in segments 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 secondary storage structure indexed by the service identifier.

[0022] In step S1c, the criteria for determining abnormal formats include: the data entry lacks any field of the operation type, access interface identifier, or associated service identifier; the data entry contains non-ASCII characters or illegal characters that exceed the preset length limit; the timestamp format of the data entry does not comply with the ISO 8601 standard. For abnormal data entries that meet any of the above conditions, they are directly removed and recorded in an independent abnormal log file.

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

[0024] In step S1e, the process of generating real-time behavior features is as follows: counting the number of operations within a unit time window, where the length of the unit time window is preset to 5 minutes or 1 hour according to the business scenario; extracting the interface call sequence, which is the order in which the user or device accesses the interface identifier within a continuous time window; calculating the service identifier association, which is the frequency ratio of different service identifiers appearing together within the same time window, and the frequency ratio is calculated by dividing the number of common occurrences by the total number of operations. The real-time behavior features are finally output in a structured data format, including the values ​​of the three dimensions of the number of operations, the interface call sequence, and the service identifier association.

[0025] S2. Build 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: S2a, integrating the real-time behavior data and the historical behavior log according to the access interface identifier and the associated service identifier, and generating an interface call relationship set and a service component data flow set; S2b. Construct the call dependency relationship of the access interface based on the interface call relationship set, and construct the data flow relationship of the service component based on the service component data flow set, so as 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 nodes that have indirect data flows with associated services and no explicit call relationships as hidden dependency nodes.

[0026] In step S2a, the interface call records in the real-time behavior data are classified according to the access interface identifier, and 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 flow records in the historical behavior log are matched according to the associated service identifier, and 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, wherein the interface call relationship set includes the call sequence, call time interval and concurrent call times within the same session between the access interface identifiers, and the service component data flow set includes the data input and output relationship, data field mapping rules and transmission protocol type between the service component identifiers.

[0027] 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 node include the access interface identifier, the interface type, and the identifier of the service component to which the interface belongs; the attributes of the service component node include the service component identifier, the service function description, and the data sensitivity level. The edges of the permission dependency graph are divided into two categories: interface call edges and service data dependency edges. The interface call edge is generated in the following way: if there is a record of access interface identifier A calling access interface identifier B in the interface call relationship set, a directed edge from node A to node B is created in the graph, and the edge weight is the number of calls divided by the maximum number of calls within the preset time period; the service data dependency edge is generated in the following way: if there is a record of service component identifier X transmitting data to service component identifier Y in the service component data flow set, a directed edge from node X to node Y is created in the graph, and the edge weight is the amount of data divided by the maximum amount of data within the preset time period.

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

[0029] In step S2c, starting from the target interface node, a cross-node type traversal is performed along the interface call edge and the service data dependency edge. The traversal direction includes the forward call of the interface call edge and the reverse data tracing of the service data dependency edge. For each service component node in the 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 the 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. Service component nodes that meet the above conditions are marked as hidden dependency nodes.

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

[0031] The verification method for the data flow path that does not contain a direct interface call edge is to check whether there is an interface call edge from the target interface node to the service component node in the path. If it does not exist and there is a service data dependency edge, it is determined to be a hidden dependency.

[0032] Transport protocol type compatibility means that the interface type of the target interface node (such as REST API) supports the transport protocol of the service component node (such as HTTP / HTTPS), which is achieved through protocol whitelist matching.

[0033] Data sensitivity levels are divided into three levels: public, internal, and confidential, which are pre-defined by the system administrator and stored in the metadata of the service component.

[0034] S3. Generate hidden path weight coefficients based on the triggering frequency and business impact level of hidden dependent nodes in historical behavior logs, including: S3a, extracting operation records associated with hidden dependent nodes from historical behavior logs, and filtering out historical log entries containing data flow path triggering events; S3b, counting the number of times the hidden dependent nodes are triggered within a preset time period, and calculating the trigger frequency as the ratio of the number of triggers to the total length of the time period; S3c, according to the level of the associated service interruption event recorded in the historical log, assign a business impact level value to the hidden dependent node, and the interruption event level is positively correlated with the criticality of the service function; S3d. The trigger frequency and the business impact level are weighted and summed to generate a hidden path weight coefficient. The weight ratio is adjusted according to the preset security policy configuration.

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

[0036] 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 peak trading period and 24 hours during the off-peak period. The number of triggers is counted as follows: the valid trigger event log entries screened out in step S3a are grouped according to the hidden dependent node identifier, and the number of log entries in each group is counted as the number of triggers. The calculation formula for the trigger frequency is: the number of triggers 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 triggers is 120 times, then the trigger frequency is 120 / 3600=0.033 times / second.

[0037] In step S3c, the business impact level is divided into 1 to 5 levels, and the higher the value, the more serious the impact of the service interruption. The level allocation rule is: in the historical log, if the service component associated with the hidden dependent node causes more than 50% of the associated interface calls to fail after the interruption event, then the level 5 is assigned; if it causes 10%-50% of the interface calls to fail, then the level 3 is assigned; if it does not cause the interface call to fail but causes data delays of more than 5 minutes, then the level 1 is assigned. The criticality of service functions 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.

[0038] 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 frequency weight and level weight are both 0.5. When the security policy requires priority to ensure business continuity, the level weight is increased to 0.7; when the security policy requires priority to prevent and control high-frequency risks, the frequency weight is increased to 0.7. The weight ratio adjustment is achieved by modifying the parameters in the configuration file. The configuration file format is a key-value pair, such as {"frequency_weight":0.7, "level_weight":0.3}.

[0039] S4. Determine the interruption probability of adjusting the target interface permissions on the explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients, including: S4a, based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior characteristics, generate the real-time behavior risk level of the explicit dependency path; S4b, calculating the static topological risk level of the explicit dependency path according to the interface call edge weight and the service data dependency edge weight of the explicit dependency path in the permission dependency graph; 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; S4d, traversing 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, then determining the interruption probability of the hidden dependency path as 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 for adjusting the target interface permissions.

[0040] An explicit dependency path is a data flow path in the permission dependency graph that is directly connected through an interface call edge and has an explicit call relationship; a hidden dependency path is a data flow path in the permission dependency graph that is indirectly connected through a service data dependency edge and contains at least one hidden dependency node.

[0041] In step S4a, the interface call sequence length refers to the number of different interfaces accessed by a user or device within a continuous time window. For example, if interface A, interface B, and interface 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 interface call sequence length exceeds 5 and the number of operations exceeds 100 times / 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 / minute, it is marked as a medium risk level; the rest of the cases are marked as low risk levels. 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.

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

[0043] In step S4c, the preset fault tolerance threshold is set according to the deviation range of 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 corresponds to static medium risk), the fault tolerance threshold is set to 1 level. During cross-validation, if the real-time risk level is high risk and the static risk level is medium risk, the difference between the two is 1 level, which exceeds the fault tolerance threshold, then the interruption probability of the explicit dependent path adopts the high risk level; if the difference does not exceed the threshold, the average 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.

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

[0045] In step S4e, the merging rule is: compare the interruption probability of the explicit dependent path with the interruption probability of the hidden dependent 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 to avoid missed judgments.

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

[0047] S5. When the interruption probability exceeds the preset threshold, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted and an alternative access path is generated, 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 hierarchy of the explicit dependency path and the hidden dependency path in the permission dependency graph; S5b, generating an alternative access path based on the traversal result, the alternative access path including an alternative interface covering the explicit dependency path and a data transfer interface covering the hidden dependency path; S5c, verifying the compatibility of the interface permissions of the alternative access path with the target interface permissions, and if there is a conflict, dynamically downgrading the target interface permissions to a preset minimum compatible permission level; S5d. According to the permission level of the target interface after dynamic downgrade, adjust the interface call edge weight and the service data dependency edge weight in the permission dependency graph.

[0048] 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 hierarchy is divided according to the path depth from the node to the root node. The smaller the path depth, the higher the hierarchy. The traversal order starts from the root node and visits each layer of nodes in increasing order according to the hierarchy depth, for example, root node (level 1) → child node (level 2) → leaf node (level 3). A data input node refers to a node that provides a data source for the current interface in an explicit dependency path, or a service component node that transmits data through a service data dependency edge in a hidden dependency path.

[0049] The setting of the preset threshold is 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 the mean of the historical interruption probability plus two standard deviations. For example, when the mean is 0.2 and the standard deviation is 0.1, the threshold is set to 0.4. The threshold for high-security scenarios (such as payment interfaces) is set to 0.3, and the threshold for high-availability scenarios (such as log interfaces) is set to 0.6. Dynamic adjustments include load-sensitive adjustments (the threshold is increased by 10% when the CPU usage rate is >80%) and event-driven adjustments (temporarily lowering the threshold after a service interruption). The downgrade is triggered immediately when the payment interface interruption probability exceeds 0.3, and the log interface is triggered when it exceeds 0.6, balancing security and system availability.

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

[0051] 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 minimum compatible permission level is preset according to the interface type. For example, the minimum compatibility level of the "user data write interface" is "read-only", and the minimum compatibility level of the "payment interface" is "query". The permission downgrade operation includes: modifying the permission field in the access control list (ACL) of the target interface to the minimum compatibility level, and synchronously updating the permission scope of the authentication token.

[0052] In step S5d, the interface call edge weight is adjusted by multiplying the call edge weight corresponding to the target interface by the downgrade coefficient, and the downgrade coefficient 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 downgrade coefficient is 0.5, the original weight of 0.8 is adjusted to 0.8×0.5=0.4. The service data dependency edge weight is adjusted by reducing the weight of the relevant service data dependency edge in proportion if the downgrade of the permission of the target interface results in a limited data output range of the associated service component. For example, if the data output fields are reduced from 10 to 5, the weight is adjusted from 0.6 to 0.6×(5 / 10)=0.3.

[0053] S6. When abnormal operation of the alternative access path is detected, the permission dependency graph is updated to trace back the original path and iteratively optimize the target interface permission level, including: S6a, compare the real-time behavior characteristics of alternative access paths with historical behavior logs to detect abnormal operation types, including high-frequency calls, discontinuous interface access, and cross-service unauthorized operations; S6b. According to the permission dependency graph node associated with the abnormal operation type, 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. S6c, according to the original path topology order 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; S6d. Combine the permission dependency graph after backtracking with the real-time behavior characteristics, and iteratively perform dynamic adjustment of the permission level of the target interface.

[0054] In step S6a, the interface call frequency threshold in the real-time behavior feature is determined by counting the highest frequency value of normal operation in the historical behavior log and multiplying it by a coefficient of 1.5. For example, if the historical log shows that the highest frequency of normal operation of a certain interface is 200 times / minute, then the abnormal high-frequency call threshold is 300 times / minute.

[0055] The basis for determining non-continuous interface access is whether the interface call sequence matches the pre-stored legal continuous pattern library. For example, if the legal pattern is interface A→interface B→interface C, if the real-time sequence is interface A→interface C, it is determined to be non-continuous access. Cross-service unauthorized operations are verified through the role-service permission mapping table. For example, when the user role is "customer service", its permission whitelist only includes the query interface. If the payment interface is accessed, an unauthorized alarm is triggered.

[0056] In step S6b, the attenuation factor is calculated as follows: attenuation factor = original weight value / (1 + number of abnormal operations), where the statistical period for the number of abnormal operations is the last hour, and the number is reset and recounted every hour. For example, the original weight of the interface call edge is 0.8. If the number of associated abnormal operations is 3 times, the attenuated weight = 0.8 / (1+3) = 0.2. The weight adjustment logic of 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 operations is 2 times, the attenuated weight = 0.6 / (1+2) = 0.2. After the weight adjustment, the edge weight value of the corresponding node in the permission dependency graph is updated in real time.

[0057] In step S6c, the original path topology order is recorded as follows: when building the permission dependency graph in step S2, the creation logs of nodes and edges are stored in the order in which the interface call relationship and the service data flow relationship are generated. When backtracking, the weights are restored in sequence according to the order in the log. For example, the call edge weight 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 data dependency edge weight of service Y is adjusted from 0.6 to 0.2, and restored to 0.6 after backtracking.

[0058] In step S6d, the termination condition of the iterative dynamic adjustment is any of the following situations: After two consecutive iterations, the interruption probability of the target interface permission is lower than a preset threshold (e.g., 0.4); Reach the maximum number of iterations (such as 3) to avoid infinite loops caused by exceptions.

[0059] In each iteration, step S4 (interruption probability calculation) and step S5 (authority adjustment) are re-executed, for example, the first iteration generates alternative path A, and the second iteration generates alternative path B, until the termination condition is met.

[0060] Embodiment 2: Figure 2 A structural schematic diagram of a network access rights dynamic management and control system based on behavior analysis of the present invention is given, and a network access rights dynamic management and control system based on behavior analysis includes: Real-time behavior collection module: collects real-time behavior data and extracts real-time behavior features; Permission graph construction module: Builds a permission dependency graph based on real-time behavior data and historical behavior logs, and identifies hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph; Hidden weight generation module: generates hidden path weight coefficients based on the triggering frequency and business impact level of hidden dependent nodes in historical behavior logs; Interruption probability assessment module: Determines the interruption probability of adjusting the target interface permissions 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, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; Path backtracking optimization module: When abnormal operation of alternative access paths is detected, the permission dependency graph is updated to backtrack the original path and iteratively optimize the target interface permission level.

[0061] The above formulas are all dimensionless and numerical calculations. The formula is a formula that is closest to the actual situation obtained by collecting a large amount of data and performing software simulation. The preset parameters and thresholds in the formula are set by technicians in this field according to actual conditions.

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

[0063] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination thereof. When implemented by software, the above embodiments may 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 process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or may be transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server or data center to another website, computer, server or data center by wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more available media sets. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium may be a solid-state hard disk.

[0064] 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 aforementioned method embodiments and will not be repeated here.

[0065] In the 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 only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

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

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

[0068] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0069] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0070] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for dynamic control of network access rights based on behavior analysis, characterized in that: The steps include: S1, collect real-time behavior data and extract real-time behavior features; S2. Build 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; S3, generating a hidden path weight coefficient according to the triggering frequency and business impact level of the hidden dependent node in the historical behavior log; S4. Determine the interruption probability of adjusting the target interface permissions on the explicit and hidden dependency paths through real-time behavior characteristics, permission dependency graphs, and hidden path weight coefficients; S5. When the interruption probability exceeds a preset threshold, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; S6. When an abnormal operation of the alternative access path is detected, the permission dependency graph is updated to trace back the original path and iteratively optimize the target interface permission level.

2. According to claim 1, a method for dynamic control of network access rights based on behavior analysis is 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 abnormal format of the classified and stored real-time behavior data and remove data entries containing missing fields or illegal characters; S1d, converting the operation timestamp of the filtered real-time behavior data into a unified time zone format, and mapping the access interface identifier to a globally unique identifier; S1e. Based on the pre-processed real-time behavior data, the number of operations per unit time, the interface call sequence and the service identification correlation are counted to generate real-time behavior features.

3. According to the method of dynamic network access rights management based on behavior analysis in claim 1, it is characterized in that S2 include: S2a, integrating the real-time behavior data and the historical behavior log according to the access interface identifier and the associated service identifier, and generating an interface call relationship set and a service component data flow set; S2b. Construct the call dependency relationship of the access interface based on the interface call relationship set, and construct the data flow relationship of the service component based on the service component data flow set, so as 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 nodes that have indirect data flows with associated services and no explicit call relationships as hidden dependency nodes.

4. According to the method of dynamic control of network access rights based on behavior analysis in claim 1, it is characterized in that S3 include: S3a, extracting operation records associated with hidden dependent nodes from historical behavior logs, and filtering out historical log entries containing data flow path triggering events; S3b, counting the number of times the hidden dependent nodes are triggered within a preset time period, and calculating the trigger frequency as the ratio of the number of triggers to the total length of the time period; S3c, assigning 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; S3d. The trigger frequency and the service impact level are weighted and summed to generate a hidden path weight coefficient.

5. According to claim 4, a method for dynamic control of network access rights based on behavior analysis is characterized in that: The interruption event level is positively correlated with the criticality of the service function; the weight ratio of the generated hidden path weight coefficient is adjusted according to the preset security policy configuration.

6. According to the method of dynamic control of network access rights based on behavior analysis in claim 1, it is characterized in that S4 include: S4a, based on the length of the interface call sequence and the number of operations per unit time in the real-time behavior characteristics, generate the real-time behavior risk level of the explicit dependency path; S4b, calculating the static topological risk level of the explicit dependency path according to the interface call edge weight and the service data dependency edge weight of the explicit dependency path in the permission dependency graph; 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; S4d, traversing 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, then determining the interruption probability of the hidden dependency path as 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 for adjusting the target interface permissions.

7. According to claim 6, a method for dynamic control of network access rights based on behavior analysis is characterized in that: An explicit dependency path is a data flow path in the permission dependency graph that is directly connected through an interface call edge and has an explicit call relationship; a hidden dependency path is a data flow path in the permission dependency graph that is indirectly connected through a service data dependency edge and contains at least one hidden dependency node.

8. According to the method of dynamic control of network access rights based on behavior analysis in claim 1, it is characterized in that S5 include: 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 hierarchy of the explicit dependency path and the hidden dependency path in the permission dependency graph; S5b, generating an alternative access path based on the traversal result, the alternative access path including an alternative interface covering the explicit dependency path and a data transfer interface covering the hidden dependency path; S5c, verifying the compatibility of the interface permissions of the alternative access path with the target interface permissions, and if there is a conflict, dynamically downgrading the target interface permissions to a preset minimum compatible permission level; S5d. According to the permission level of the target interface after dynamic downgrade, adjust the interface call edge weight and the service data dependency edge weight in the permission dependency graph.

9. According to the method of dynamic control of network access rights based on behavior analysis in claim 1, it is characterized in that S6 include: S6a, compare the real-time behavior characteristics of alternative access paths with historical behavior logs to detect abnormal operation types, including high-frequency calls, discontinuous interface access, and cross-service unauthorized operations; S6b. According to the permission dependency graph node associated with the abnormal operation type, 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. S6c, according to the original path topology order 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; S6d. Combine the permission dependency graph after backtracking with the real-time behavior characteristics, and iteratively perform dynamic adjustment of the permission level of the target interface.

10. A network access rights dynamic management and control system based on behavior analysis, used to implement a network access rights dynamic management and control method based on behavior analysis as claimed in any one of claims 1 to 9, characterized in that: include: Real-time behavior collection module: collects real-time behavior data and extracts real-time behavior features; Permission graph construction module: Builds a permission dependency graph based on real-time behavior data and historical behavior logs, and identifies hidden dependency nodes of the target interface based on the topological structure of the permission dependency graph; Hidden weight generation module: generates hidden path weight coefficients based on the triggering frequency and business impact level of hidden dependent nodes in historical behavior logs; Interruption probability assessment module: Determines the interruption probability of adjusting the target interface permissions on 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, the data input nodes of the explicit and hidden dependency paths are traversed based on the dependency hierarchy of the permission dependency graph, the permission level of the target interface is dynamically adjusted, and an alternative access path is generated; Path backtracking optimization module: When abnormal operation of alternative access paths is detected, the permission dependency graph is updated to backtrack the original path and iteratively optimize the target interface permission level.

Images