Hierarchical access authority management method of behavior monitoring system

Abstract

The invention discloses a hierarchical access authority management method of a behavior monitoring system, which relates to the technical field of authority management, and comprises the following steps: generating situation nodes according to multi-dimensional characteristics of behavior events, packaging changes into a traceability log, and incrementally updating affected sub-graphs; abstracting multi-level element roles according to activity and sensitivity threshold domains, maintaining a sorting double linked list and constructing a skip list index; mapping the element role into a fuzzy cognitive node, establishing a bidirectional fuzzy edge weight, and dynamically adjusting to generate a credible factor; constructing a cross authorization matrix storage basic permission set; and mapping an authorization request to a situation node, retrieving a latest state, positioning a user element role level, extracting a matrix basic permission set through a skip list index, and generating and issuing an authorization result after cutting based on a credible factor. Incremental maintenance is realized by updating a local sub-graph and a skip list index through a traceability log, and authorization efficiency, flexibility and security are improved by combining fuzzy cognitive mapping and dynamic credible factor fine permission through context mapping of a cross authorization matrix.

Description

Technical Field

[0001] The present invention relates to the technical field of authority management, and in particular to a hierarchical access authority management method for a behavior monitoring system. Background Art

[0002] With the widespread adoption of information technology and mobile devices, various behavior monitoring systems have been widely deployed in scenarios such as finance, security, and enterprise intranets. Existing behavior monitoring systems primarily focus on collecting and storing user operation logs and implementing static policy-based access control, such as traditional role-based access control (RBAC) and attribute-based access control (ABAC).

[0003] While traditional RBAC models can bind permissions to predefined roles based on users, they struggle to meet the fine-grained authorization requirements of dynamic business environments. Furthermore, updating role permissions often requires restructuring global policies, leading to system performance bottlenecks. ABAC models can incorporate environmental attributes to make decisions, but increasing the number of contextual attributes can lead to a high-dimensional policy space, resulting in significantly increased decision delays and management complexity.

[0004] Some existing solutions introduce context-awareness or delegated trust mechanisms to enhance access control flexibility, but they mostly rely on fixed thresholds or simple scoring rules and lack online adaptability. Their full updates of graph structures and policy recalculations cannot maintain real-time performance in high-concurrency scenarios.

[0005] In addition, traditional audit systems mostly use offline log analysis, which makes it difficult to respond to unauthorized risks in a timely manner. They also lack closed-loop feedback with real-time authorization policies, making it impossible to achieve continuous optimization and adaptive adjustment of policies.

[0006] Therefore, there is an urgent need for a hierarchical access rights management method that takes into account efficiency, flexibility and intelligence, and can achieve dynamic trust correction, incremental graph maintenance and real-time audit closed loop in multi-dimensional scenarios to meet the security and performance requirements of modern behavior monitoring systems. Summary of the Invention

[0007] Based on the above-mentioned shortcomings of the prior art, the purpose of the present invention is to provide a hierarchical access rights management method for a behavior monitoring system to solve the above-mentioned technical problems.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a hierarchical access rights management method for a behavior monitoring system, comprising:

[0009] S1: Generate context nodes based on the multi-dimensional characteristic attributes of behavioral events, encapsulate changes in context nodes as traceability events, and record them in the traceability log;

[0010] S2: Perform local incremental updates on the affected context subgraph based on the provenance log;

[0011] S3: Abstract business roles according to activity thresholds and sensitivity thresholds, dividing them into multiple levels of meta-roles. For each level of meta-role, maintain a bidirectional linked list sorted by permission sensitivity, and construct a skip list index on the bidirectional linked list.

[0012] S4: Set multi-level meta-roles as fuzzy cognitive mapping nodes, establish bidirectional fuzzy edge weights based on the trust relationship between roles, and dynamically adjust the edge weights according to audit feedback and historical behavior sequences to obtain dynamic trust factors;

[0013] S5: Construct a cross-authorization matrix with context nodes and meta-role levels as row and column labels, and store the basic permission set in each cross unit;

[0014] S6: Map the behavior to be authorized to the corresponding context node, retrieve the node status after the latest incremental update, locate the meta-role level of the target user, quickly extract the corresponding basic permission set in the cross-authorization matrix through the skip table index, tailor the basic permission set based on the dynamic trust factor, generate the authorization result and issue it for execution.

[0015] The present invention is further configured such that the multi-dimensional characteristic attributes include operation type, spatiotemporal information, device attributes, and security level;

[0016] Changes include additions, modifications or deletions;

[0017] Step S1 includes: obtaining multidimensional feature attributes of the behavior event, generating a context node identifier based on the multidimensional feature attributes; creating or updating the context node in the graph database according to the context node identifier, encapsulating the creation or update operation as a traceability event, and recording the traceability event in the traceability log.

[0018] The present invention is further configured such that step S2 includes:

[0019] Monitor the tracing logs and obtain new tracing events in sequence;

[0020] Based on the context node identifiers and change details recorded in the traceability event, the vertices and edges directly associated with the context are obtained from the graph database to generate the affected context subgraph;

[0021] Generate change map entries for nodes and edges in the affected subgraph based on the change details;

[0022] Perform localized update operations on contextual nodes and edges in the affected subgraph within the graph database transaction context;

[0023] After the update is completed, a synchronization refresh notification is sent to the cross-level indexing service and the context fusion cache layer to record the processing status of the processed traceability events.

[0024] The present invention is further configured such that step S3 includes:

[0025] Obtain activity and sensitivity indicators of business roles;

[0026] Based on the activity threshold and sensitivity threshold predefined in the configuration center, business roles are mapped to corresponding meta-role levels, and the correspondence between role IDs and meta-role IDs is recorded in the role mapping table.

[0027] Initialize a bidirectional linked list for each meta-role group, encapsulate the corresponding business roles as linked list nodes, and insert them in order according to the sensitivity index;

[0028] An index layer is set at a fixed node interval on the bidirectional linked list to form a multi-layer skip list structure. Each index node maintains a jump pointer to the next layer node.

[0029] Persist the skip list structure and linked list node pointer information to the index metadata storage;

[0030] For activity or sensitivity change events of business roles, the corresponding linked list node is located based on the role mapping table, local node movement is performed, and the jump pointer information of the node in the jump table index layer is synchronously updated.

[0031] The present invention is further configured such that step S4 includes:

[0032] Obtain meta-role trust metrics, including compliance rate, number of abnormal accesses, and audit pass rate;

[0033] Multi-level meta-roles are mapped into fuzzy cognitive mapping nodes, and bidirectional fuzzy edge weights are established between nodes according to the preset trust strategy and stored in the form of membership function parameters;

[0034] Build a fuzzy reasoning rule base, including IF-THEN rules based on audit feedback and historical behavior indicators;

[0035] The trust indicators are mapped to membership degrees and input into the fuzzy reasoning engine, which generates adjustment suggestions for each bidirectional fuzzy edge weight based on the rule base;

[0036] Aggregate and normalize the adjustment suggestions and original membership function parameters, and update the bidirectional fuzzy edge weights;

[0037] For each fuzzy cognitive mapping node, the updated bidirectional fuzzy edge weight and input edge membership are fused to generate a dynamic credibility factor.

[0038] The present invention is further configured such that step S5 includes:

[0039] Create a cross-authorization matrix table. The table definition fields include the situation node ID, meta-role level ID, and basic permission set. Set the situation node ID and meta-role level ID as the joint primary key.

[0040] Based on the situation node identifier and the multi-level meta-role level identifier, a Cartesian product insertion operation is performed to generate a matrix unit, and the basic permission set field of the matrix unit is updated according to the preset security policy;

[0041] Create B+ tree joint indexes for the context node identification field and the meta-role level identification field respectively;

[0042] Taking the context node ID and meta-role level ID as input parameters, locate a single matrix record through the joint index and return the corresponding basic permission set;

[0043] Define database triggers or event subscription mechanisms to listen to change events at the context node and meta-role levels, and trigger update operations on affected units in the cross-authorization matrix table.

[0044] The present invention is further configured such that step S6 includes:

[0045] Receive the action request message and obtain the action ID, user ID and action parameters from the message body;

[0046] Map the behavior identifier to the corresponding context node identifier, query the context node table, and obtain the node attributes and associated status after the latest incremental update;

[0047] Access the role mapping table and obtain the meta-role level identifier of the target user based on the user ID;

[0048] Initiate an index query request to the cross-level index service and retrieve the index pointer in the skip list index structure using the meta-role level identifier;

[0049] Based on the index pointer, a joint primary key query is constructed on the cross-authorization matrix table to obtain the corresponding basic permission set;

[0050] Submit the meta-role level identifier and context node identifier to the fuzzy cognitive mapping service, and call the dynamic trust factor to obtain the latest trust factor value;

[0051] Apply dynamic trust factors to the basic permission set, execute screening rules, output a refined permission list, encapsulate it into a permission policy token, and send the permission policy token to the front-end proxy component in a standard message format for execution.

[0052] The present invention is further configured to include:

[0053] S7: Unauthorized or abnormal access events and related audit tasks are added to a weighted priority queue. Dynamic weights are assigned based on event type, risk level, and latency tolerance, and prioritized execution. The root cause is traced back along the context-fusion graph and traceability logs. An audit report is generated based on cross-level index status and dynamic trust factor changes.

[0054] S8: Based on the audit report, cross-level index service performance statistics and dynamic trust factor change information, local incremental adjustments and re-evaluations are made to the context node structure, meta-role hierarchy boundaries and cross-authorization matrix.

[0055] The present invention is further configured such that step S7 includes:

[0056] Monitor unauthorized or abnormal access events, encapsulate the event ID, user ID, context node ID, and audit parameters into an audit task object, and add it to the authorized priority queue;

[0057] Obtain the risk level and delay tolerance policy corresponding to the event type of the audit task object, map them to dynamic weights, and update the order of the audit task in the priority queue;

[0058] Audit tasks are executed sequentially according to the dynamic weight order. Starting from the context node in the audit task in the graph database, the associated edges recorded in the traceability log are traversed in reverse to the initial triggering node, collecting the attributes and associated status of each node along the way.

[0059] Call the cross-level indexing service to obtain the index snapshot of each meta-role node on the backtracking path in the bidirectional linked list and skip list, and call the fuzzy cognitive mapping service to obtain the dynamic trust factor evolution sequence of the corresponding node;

[0060] Based on the backtracking path data, index snapshots, and trust factor evolution information, an audit report is generated in the format of situation backtracking segment, trust evolution segment, and compliance check segment.

[0061] The present invention is further configured such that step S8 includes:

[0062] Gather information on unauthorized paths, compliance anomalies, performance statistics of cross-level indexing services, and dynamic trust factor changes identified in audit reports;

[0063] Based on the aggregated information, identify the context node structure areas, meta-role hierarchy boundaries, and cross-authorization matrix unit sets that need to be adjusted;

[0064] Determine the affected context subgraph node set, meta-role grouping, and corresponding row and column indexes of the cross-authorization matrix;

[0065] Perform local node and relationship updates on the affected situation subgraphs, fine-tune the thresholds of meta-role hierarchy boundaries, and update the basic permission sets for cross-authorization matrix units;

[0066] Ensure the atomicity of local updates within the transaction context, triggering synchronous refreshes of cross-level index services and cache layers;

[0067] The local update results and verification feedback are recorded in the optimization log, and an adjustment completion notification is generated.

[0068] The present invention provides a hierarchical access rights management method for a behavior monitoring system. The method generates a context node based on the multidimensional characteristic attributes of a behavior event, encapsulates the change of the context node as a traceability event, and records it in a traceability log; performs a local incremental update on the affected context subgraph based on the traceability log; abstracts the business role according to the activity threshold and the sensitivity threshold, divides it into multiple levels of meta-roles, maintains a bidirectional linked list sorted by permission sensitivity for each level of meta-role, and constructs a skip table index on the bidirectional linked list; sets the multiple levels of meta-roles as fuzzy cognitive mapping nodes, establishes bidirectional fuzzy edge weights based on the trust relationship between roles, dynamically adjusts the edge weights based on audit feedback and historical behavior sequences, and obtains a dynamic trust factor; constructs a cross-authorization matrix with context nodes and meta-role levels as row and column labels, and stores a basic permission set in each cross unit; maps the behavior to be authorized to the corresponding context node, retrieves the node status after the latest incremental update, locates the meta-role level to which the target user belongs, quickly extracts the corresponding basic permission set in the cross-authorization matrix through the skip table index, tailors the basic permission set based on the dynamic trust factor, generates an authorization result, and issues it for execution. The beneficial effects produced include:

[0069] 1. Efficient incremental maintenance: Leveraging provenance log-driven local subgraph updates and a bidirectional linked list-skip list index structure, we achieve incremental maintenance of the context graph and role index, avoiding full reconstruction and reducing update latency and system load.

[0070] 2. Dynamic Trust Tailoring: Fuzzy cognitive mapping is used to conduct online learning and edge-right adjustment of trust relationships between roles. Dynamic trust factors are then combined to implement refined tailoring of the basic permission set. This not only meets the flexible authorization requirements in changing business scenarios, but also effectively mitigates potential risks of unauthorized access.

[0071] 3. Fine-grained multi-dimensional integration: Context nodes are constructed based on multi-dimensional features such as operation type, spatiotemporal information, device attributes, and security level. A cross-authorization matrix is ​​used to achieve precise mapping of context and role levels. This supports on-demand permission opening in different business scenarios, improving the expressiveness and applicability of policies.

[0072] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without inventive efforts. In the drawings:

[0074] Figure 1 The flowchart of a method for managing hierarchical access rights of a behavior monitoring system is shown as an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0075] The following describes the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art will readily appreciate the other advantages and benefits of the present invention from the disclosure herein. The present invention may also be implemented or applied through various other specific embodiments, and the various details in this specification may be modified or altered based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are intended only to illustrate the present invention and are not intended to limit the scope of protection of the present invention.

[0076] It should be noted that the illustrations provided in the following embodiments are merely schematic illustrations of the basic concept of the present invention. Therefore, the illustrations only show components related to the present invention and are not drawn according to the number, shape, and size of components in actual implementation. In actual implementation, the type, quantity, and proportion of each component may be changed arbitrarily, and the component layout may also be more complex.

[0077] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it will be apparent to those skilled in the art that the embodiments of the present invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring the embodiments of the present invention.

[0078] A hierarchical access rights management method for a behavior monitoring system, such as Figure 1 As shown, including:

[0079] S1: Generate context nodes based on the multi-dimensional characteristic attributes of behavioral events, encapsulate changes in context nodes as traceability events, and record them in the traceability log;

[0080] S2: Perform local incremental updates on the affected context subgraph based on the provenance log;

[0081] S3: Abstract business roles according to activity thresholds and sensitivity thresholds, dividing them into multiple levels of meta-roles. For each level of meta-role, maintain a bidirectional linked list sorted by permission sensitivity, and construct a skip list index on the bidirectional linked list.

[0082] S4: Set multi-level meta-roles as fuzzy cognitive mapping nodes, establish bidirectional fuzzy edge weights based on the trust relationship between roles, and dynamically adjust the edge weights according to audit feedback and historical behavior sequences to obtain dynamic trust factors;

[0083] S5: Construct a cross-authorization matrix with context nodes and meta-role levels as row and column labels, and store the basic permission set in each cross unit;

[0084] S6: Map the behavior to be authorized to the corresponding context node, retrieve the node status after the latest incremental update, locate the meta-role level of the target user, quickly extract the corresponding basic permission set in the cross-authorization matrix through the skip table index, tailor the basic permission set based on the dynamic trust factor, generate the authorization result and issue it for execution.

[0085] The present invention is further configured such that the multi-dimensional feature attributes include operation type, spatiotemporal information, device attributes, and security level. Specifically, the operation type refers to the specific operation category performed by the user or system on the behavior monitoring object, including file download, configuration modification, login verification, data export, etc., which is used to reflect the behavior intention and risk attributes and is a character parameter. The spatiotemporal information includes the specific time and spatial location of the behavior, which is used to determine whether the behavior occurs within the allowed time window or trusted network / geographic area. The device attributes describe the hardware and software characteristics of the device initiating the behavior, including but not limited to the device model, operating system version, client application version, and unique device identifier, which are used to determine the device reputation and compatibility. The security level is a preliminary assessment of the overall risk of this behavior request, including high, medium, and low, which serves as the initial input for subsequent trust reasoning and policy logic.

[0086] Changes include additions, modifications or deletions;

[0087] Step S1 includes: obtaining multidimensional feature attributes of behavioral events, generating situation node identifiers based on the multidimensional feature attributes; creating or updating situation nodes in the graph database according to the situation node identifiers, encapsulating the creation or update operations as traceability events, and recording the traceability events in the traceability logs; specifically, after receiving the original event, the behavior acquisition component parses the event message to obtain four types of features, namely, operation type, occurrence time and location identifier, device model and system version, and security level, and performs standardized verification according to a predefined format; splicing the standardized dimensional features in a predetermined order to form a unique string identifier; in order to control the identifier length, applying hash mapping or preset number mapping to the splicing result to obtain the final situation node identifier; in the graph Search the database for a node with the same identifier; if it does not exist, create the node and mark its attributes; if it already exists, write the newly added or updated attributes in the message into the attribute set of the node in sequence; the above operations are completed in one atomic transaction to ensure consistency; the creation or update action of the node is abstracted into a structured traceability event, the event content includes the operation type, node identifier, snapshots before and after the attribute change, timestamp and source identifier; push this traceability event to the persistent log system in the form of a message, and synchronously notify the incremental update component to start subsequent processing; in a feasible embodiment of the present invention, the terminal user uses a mobile phone with model iPhone12, iOS14 at 2025-06-11 10:30:45 The mobile device initiates a file download operation, and the security level of this operation is assessed as medium. The multi-dimensional feature attributes include: operation type: file download; timestamp: 2025-06-11T10:30:45Z; location identifier: 192.0.2.10; device attribute: iPhone12, iOS14; security level: medium; concatenated string: "file download|20250611T103045Z|192.0.2.10|iPhone12_iOS14|medium"; through hash mapping: context node identifier = SHA256("file download|20250611T103045Z|192.0.2.10|iPhone12_iOS14| Medium") = "a3f5b7c9d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7"; use the hash map identifier to retrieve the corresponding node in the graph database; if the node does not exist, create a new context node and assign the parsed attributes; if the node already exists, only the changed attributes (security level changed from "low" to "medium") are updated; a traceability event is constructed, including fields such as addition or modification, node identifier, comparison of various attributes before and after, time, and source component; the event is written to the log storage, and the incremental update process is triggered to ensure that subsequent updates only perform minimal updates on the node and its associated subgraphs.

[0088] The present invention is further configured such that step S2 includes:

[0089] Monitor the provenance log and obtain new provenance events in sequence. Specifically, the incremental update service subscribes to the provenance log stream and continuously polls for new provenance events. It obtains unprocessed new provenance event objects in the order of the logs.

[0090] Based on the context node identifier and change details recorded in the traceability event, the vertices and edges directly associated with the context are obtained from the graph database to generate the affected context subgraph. Specifically, the context node identifier and change details are read from the traceability event. Using the graph database's neighbor query interface, all directly associated vertices and edges are obtained starting from the node to form the context subgraph to be updated.

[0091] Generate change map entries for the nodes and edges in the affected subgraph based on the change details. Specifically, based on the attribute addition, modification, or deletion information recorded in the event, a change map entry is generated for each affected node and edge in the subgraph. The entry content includes the object identifier, change type, and the before and after attribute snapshots.

[0092] Within the graph database transaction context, localized update operations are performed on contextual nodes and edges in the affected subgraph. Specifically, within the graph database transaction context, corresponding insert, attribute update, or delete operations are performed only on the nodes and edges of the subgraph to be updated. This ensures that transactions are committed atomically to avoid affecting the global graph.

[0093] After the update is completed, a synchronization refresh notification is sent to the cross-level index service and the context fusion cache layer to record the processing status of the processed traceability event; specifically, after the transaction is committed, a change notification is sent to the cross-level index service and the context fusion cache layer respectively to refresh the linked list - skip list index and cache entry; the event is marked as processed in the traceability log to prevent repeated consumption; in the above-mentioned feasibility embodiment of the present invention, the following traceability event is received: context node identifier: CTX12345, change details: security level is changed from low to medium; the corresponding processing process is as follows: the incremental update service reads event ID = EVT67890 from the log queue, including the node CTX12345 and the change "securityLevel: low→medium"; in the graph database, directly connected vertices (including CTX12345) are retrieved with CTX12345 as the center. User node U1001, device node D2002) and corresponding edges ("triggered at", "belonging to device"); construct mapping entries: Entry 1: node CTX12345, attribute "securityLevel" was "low" before modification and "medium" after modification; if the associated edges or other attributes have not changed, only this single entry is generated; start a transaction and only update the securityLevel attribute of node CTX12345; commit the transaction to ensure that the update only acts on this node; after the update is completed, send a "CTX12345 security level has changed" notification to the cross-level indexing service to refresh the sensitivity position of the node in the linked list-skip list index; send the same refresh instruction to the cache layer to clear the old cache of CTX12345; mark EVT67890 as "processed" in the log system.

[0094] The present invention is further configured such that step S3 includes:

[0095] Obtain activity and sensitivity indicators for business roles. Specifically, read activity indicators (average number of logins in the past 30 days) and sensitivity indicators (accessible data level score) for all business roles from the user management module or login audit system. Define activity thresholds in the configuration center, including: high ≥ 20 times / week, medium 5–19 times / week, and low < 5 times / week. Define sensitivity thresholds, including: high ≥ 8 points, medium 4–7 points, and low < 4 points.

[0096] According to the activity threshold and sensitivity threshold pre-defined in the configuration center, the business role is mapped to the corresponding meta-role level, and the corresponding relationship between the role identifier and the meta-role identifier is recorded in the role mapping table; specifically, the activity index and sensitivity index of each business role are mapped to the corresponding threshold interval to form a tuple (activity level, sensitivity level); a meta-role level number is assigned to each tuple, and the business role identifier is recorded in the meta-role level. The meta-role level mapping relationship is written into the role mapping table;

[0097] Initialize a bidirectional linked list for each meta-role group, encapsulate the corresponding business roles into linked list nodes, and insert them in order according to the sensitivity index. Specifically, create an empty bidirectional linked list for each meta-role level; insert the business roles belonging to the same meta-role into the linked list nodes from low to high or from high to low according to the sensitivity index. The nodes contain the role identifier and sensitivity value.

[0098] An index layer is set at a fixed node interval on a doubly linked list to form a multi-layer skip list structure. Each index node maintains a jump pointer to the node in the next layer. Specifically, on each doubly linked list, a node is selected as the previous index layer node at a fixed node interval, and downward and right jump pointers are added to it. This process is repeated to form a multi-level index structure. Long chains can be quickly crossed from the top layer, while the bottom layer maintains a complete linked list.

[0099] Persist the skip list structure and linked list node pointer information in the index metadata storage; specifically, serialize the linked list node sequence and skip list hierarchy and pointer information, and store them in the index metadata table for fast loading and querying at runtime;

[0100] For activity or sensitivity change events of business roles, the corresponding linked list node is located based on the role mapping table, local node movement is performed, and the jump pointer information of the node in the jump list index layer is synchronously updated; specifically, for activity or sensitivity change events of business roles, the incremental update service locates the affected linked list node from the role mapping table; the node is moved to the correct position in the linked list according to the new sensitivity value, and the adjacent jump pointer is adjusted in the affected index layer, and finally the index metadata table is updated; in the above-mentioned feasibility embodiment of the present invention, there are three business roles and their indicators: Role A: activity 25 times / week (high), sensitivity 9 points (high); Role B: activity 10 times / week (medium), sensitivity 6 points (medium); Role C: activity 3 times / week (low), sensitivity 2 points (low), role mapping: A's activity level and sensitivity level are (high, high) mapped to meta-role 1; B's activity level and sensitivity level are (medium, medium) mapped to meta-role 2; C's activity level and sensitivity level are (low, low) mapped For meta-role 3; bidirectional linked list initialization: meta-role 1 linked list: A (9 points); meta-role 2 linked list: B (6 points); meta-role 3 linked list: C (2 points), construct skip list index: since each linked list has only a single node, the index layer is the same as the linked list layer; if the newly added role D (sensitivity 5 points) is mapped to meta-role 2, then in the B(6)–D(5) linked list: the bottom linked list is in descending order of sensitivity: B→D, and it is set to establish an upper index every 2 nodes, then the bottom nodes B and D become upper nodes at the same time, both Can jump to each other; index metadata storage: record the linked list structure and jump table level pointer in the following form: Meta role 2: bottom linked list node sequence [B→D]; upper index node is the same [B→D]; role mapping table records B→2, D→2; dynamic adjustment example: if the sensitivity of role D is increased from 5 points to 7 points, D needs to be moved before B in the linked list (7>6); after adjustment, the linked list is D→B, and the front and back relationship of the upper index pointer is updated, and the modified pointer information is overwritten to the index metadata table.

[0101] The present invention is further configured such that step S4 includes:

[0102] Obtain meta-role trust metrics, including compliance rate, number of abnormal accesses, and audit pass rate. Specifically, the audit statistics service regularly or in real time calculates each meta-role's compliance rate (the ratio of successful accesses to total accesses), abnormal accesses (number of unauthorized or abnormal behaviors), and audit pass rate (the ratio of tasks determined to be compliant during the audit). These metrics serve as the basis for role trust.

[0103] Multi-level meta-roles are mapped to fuzzy cognitive mapping nodes, and bidirectional fuzzy edge weights are established between nodes based on a preset trust policy and stored as membership function parameters. Specifically, each meta-role at each level is established as a separate node in the fuzzy cognitive mapping (FCM). Bidirectional association edges are established between nodes based on the system trust policy (including mutual trust between peer roles and audit supervision between superiors and subordinates), and each edge is assigned an initial fuzzy edge weight. The edge weight parameters are stored in the form of membership function parameters (such as trigonometric functions or trapezoidal functions).

[0104] Build a fuzzy inference rule base, including if-then rules based on audit feedback and historical behavior indicators. Specifically, develop several if-then rules based on common audit scenarios, such as: "If role A's compliance rate is high and role B's abnormal access count is low, then the A→B edge weight increases slightly." These rules are aggregated into an inference rule base and deployed to the fuzzy inference engine.

[0105] The trust indicators are mapped to memberships and input into the fuzzy inference engine, which uses the rule base to generate adjustment suggestions for each bidirectional fuzzy edge weight. Specifically, for each role node, the measured compliance rate, number of exceptions, and audit pass rate are mapped to low, medium, and high fuzzy memberships using their corresponding membership functions. The mapping results are loaded as input into the fuzzy inference engine, which evaluates them according to the IF–THEN rules defined in the rule base to generate adjustment suggestions for each bidirectional fuzzy edge weight.

[0106] The adjustment suggestions and the original membership function parameters are aggregated and normalized to update the bidirectional fuzzy edge weights. Specifically, the edge weight adjustment suggestions obtained in the rule evaluation are weighted aggregated with the original membership function parameters, and new membership function parameters are obtained through normalization. The new parameters are written back to the edge weight storage to achieve online update of the fuzzy edge weights.

[0107] For each fuzzy cognitive mapping node, the updated bidirectional fuzzy edge weight and incoming edge membership are fused to generate a dynamic trust factor. Specifically, for each fuzzy cognitive mapping node, the current membership values ​​of all its incoming edges are collected and synthesized according to a predefined fusion operator (including weighted average). The output result is used as the dynamic trust factor of the node. In the above feasibility embodiment of the present invention, there are two meta-role nodes A and B, whose initial fuzzy edge weights and trust indicators are as follows: Initial membership function parameters: A→B edge: trigonometric function parameters (a=0.2, b=0.5 , c=0.8); B→A side: trigonometric function parameters (a=0.3, b=0.6, c=0.9), real-time trust indicators: A's compliance rate=0.85; A's abnormal access times=2; A's audit pass rate=0.90; B's compliance rate=0.60; B's abnormal access times=5; B's audit pass rate=0.70; membership mapping: map A's compliance rate 0.85 to high compliance membership μ_high_A≈0.9; map B's abnormal access times 5 (low below the threshold 5) to low abnormal membership μ_low_B≈0.8. Rule evaluation: Rule: If compliance is high and anomalies are low, the weight of the A→B edge is increased by 0.05; based on the mapping membership and the rule, the adjustment suggestion is: Δ_AB = +0.05; Δ_AB is aggregated with the original triangular parameters a, b, and c, b_new = b_old + Δ_AB = 0.5 + 0.05 = 0.55; a_new and c_new are fine-tuned accordingly and then normalized to a new set of trigonometric function parameters; all incoming edge memberships of node B are collected, in this case only the A→B edge, and the new membership μ_AB ≈ 0.92; μ_AB is used as the dynamic trust factor of B.

[0108] The present invention is further configured such that step S5 includes:

[0109] Create a cross-authorization matrix table. The table definition fields include the situation node identifier, meta-role level identifier, and basic permission set. Set the situation node identifier and meta-role level identifier as the joint primary key. Specifically, define the cross-authorization matrix table structure in the policy database. The fields include the situation node identifier, meta-role level identifier, and basic permission set. Set the situation node identifier and meta-role level identifier as the joint primary key to ensure that each pair of combinations uniquely corresponds to a permission record.

[0110] Based on the situation node identifiers and multi-level meta-role level identifiers, a Cartesian product insertion operation is performed to generate matrix units, and the basic permission set fields of the matrix units are updated according to the preset security policy. Specifically, a list of all situation node identifiers is derived from the situation fusion graph, and a list of all meta-role level identifiers is derived from the role mapping table. A Cartesian product operation is performed on the two lists to generate all possible situation-role combinations. Based on the predefined security policy template or expert configuration, the "basic permission set" field of each combination is initialized or updated, such as the list of allowed operations and data access scope.

[0111] Establish a B+ tree joint index for the context node identifier field and the meta-role level identifier field respectively; specifically, establish a B+ tree index on the context node identifier and the meta-role level identifier field respectively or jointly to support efficient positioning of single-dimensional or joint conditions;

[0112] Using the context node identifier and meta-role level identifier as input parameters, locate a single matrix record through the joint index and return the corresponding basic permission set; specifically, implement the query function in the permission decision engine, using the context node identifier and meta-role level identifier as input parameters, use the above index to quickly locate the corresponding matrix unit, and return the stored basic permission set;

[0113] Define a database trigger or event subscription mechanism to monitor change events at the context node and meta-role level, and trigger an update operation on the affected units in the cross-authorization matrix table; specifically, define a database trigger or event subscription mechanism to monitor the addition, deletion or update events in the context node table and the meta-role level table; when a change is detected, locate the affected matrix unit and perform corresponding insert, delete or update operations to maintain consistency between the matrix and the business model and security policy; in the above-mentioned feasibility embodiment of the present invention, there are the following context nodes and meta-role levels: context nodes: CTX100 (file download scenario), CTX200 (configuration modification scenario); meta-role levels: R1 (high-authority auditor), R2 (ordinary user); in the cross-authorization matrix table, the field names include context node identifier (context_id), meta-role level (role_lvl) and basic permission set (perm_set); the types are string, integer or enumeration and text or JSON respectively, the context node identifier (context_id) is a joint primary key, examples are CTX100, CTX200, and the meta-role level (role_lvl) is a joint primary key. Key, example is 1,2; the example of basic permission set is ["read"], ["read", "write"]; Cartesian product results generate four matrix records in sequence: scenario CTX100 corresponds to role R1; scenario CTX100 corresponds to role R2; scenario CTX200 corresponds to role R1; scenario CTX200 corresponds to role R2; according to the security policy template, the above four records are filled with basic permission sets in sequence: auditor R1 can perform two types of operations, read and modify, in any scenario; ordinary user R2 can only perform read operations; after establishing the joint index, the permission decision engine When the query "CTX100" + "R2" is received, the record can be located in seconds and its basic permission set "read only" can be returned; if the system adds a new situation node CTX300 (log export scenario), the trigger detects the new event and automatically inserts two empty permission records CTX300+R1 and CTX300+R2 into the matrix table; then the policy management module fills in the "read, modify" and "read" permissions for these two records respectively. If the meta-role level R3 (guest) is added, two insertion operations are also triggered, and the default permission ("read restricted") is filled in according to the visitor policy template.

[0114] The present invention is further configured such that step S6 includes:

[0115] Receive action request messages and obtain action identifiers, user identifiers, and action parameters from the message body. Specifically, the permission decision engine receives action requests sent by the front-end agent through the message bus or RPC interface. It parses the request message body to extract three elements: action identifier (operation type code), user identifier (user account or device ID), and action parameters (target resource ID and request method).

[0116] Map the behavior identifier to the corresponding context node identifier, query the context node table, and obtain the node attributes and associated status after the latest incremental update. Specifically, map the parsed behavior identifier to the context node identifier; use the identifier as the search key in the context node table to obtain the node's latest attribute set (including multi-dimensional features) and its associated status with other nodes, ensuring that the latest data after the incremental update is used.

[0117] Access the role mapping table and query the meta-role level identifier of the target user based on the user ID. Specifically, use the user ID as a query condition in the role mapping table to retrieve the meta-role level identifier of the target user, which represents the user's position in the permission system.

[0118] Initiate an index query request to the cross-level index service, and retrieve the index pointer in the skip list index structure using the meta-role level identifier. Specifically, send a request to the cross-level index service and pass in the meta-role level identifier. The cross-level index service uses the skip list structure to quickly jump to the linked list node at that level and returns the index pointer information of the node in the linked list (or skip list).

[0119] Based on the index pointer, a joint primary key query is constructed for the cross-authorization matrix table to obtain the corresponding basic permission set. Specifically, the obtained index pointer and the context node identifier are used as the joint primary key to call the query interface of the cross-authorization matrix in the policy database. After locating the corresponding matrix unit, the stored basic permission set is read and returned.

[0120] Submit the meta-role level identifier and situation node identifier to the fuzzy cognitive mapping service, and call the dynamic trust factor to obtain the latest trust factor value; specifically, submit the meta-role level identifier and situation node identifier to the fuzzy cognitive mapping service; the fuzzy mapping service calculates and returns the latest dynamic trust factor based on the current fuzzy edge weight and node activation value; specifically, read all edge weights {w1, w2, ..., w n}; Read the activation degree of the corresponding front meta-role node {a1, a2, ..., a nThree fuzzy sets are defined for edge weights and activation values: Low: triangular membership function parameters (0.0, 0.0, 0.5); Medium: triangular membership function parameters (0.3, 0.5, 0.7); High: triangular membership function parameters (0.5, 1.0, 1.0). For each edge value wi and corresponding activation value ai, the membership μ_w, μ_a of each edge value wi and corresponding activation value ai is calculated, respectively, to determine whether it falls into the low / medium / high fuzzy sets. Fuzzy rule evaluation, the rule base includes: if the edge weight is high and the activation is high, the credibility is high; if the edge weight is medium and the activation is medium, the credibility is medium; if the edge weight is low or the activation is low, the credibility is low. For each pair (wi, ai), the minimum membership value is taken as the trigger strength of the rule. All rule trigger strengths are synthesized into a fuzzy output distribution of credibility using the maximum-union method. The synthesized fuzzy output is defuzzified using the centroid method to calculate a dynamic credibility factor between 0 and 1.

[0121] Apply the dynamic trust factor to the basic permission set, execute the screening rules, output the refined permission list, encapsulate it into a permission policy token, and send the permission policy token to the front-end agent component in a standard message format for execution; specifically, in the policy generation module, combine the dynamic trust factor with the basic permission set, increase or decrease the permission items or reduce their scope according to the predefined screening rules; output the final refined permission list and encapsulate it into a permission policy token in a standard format; send the permission policy token to the front-end agent component through the message bus or direct interface; after receiving the token, the front-end agent performs subsequent permission checks and resource access control based on it; in the above-mentioned feasibility embodiment of the present invention, the request message includes: user identification: U1001; behavior identification: OP_DOWNLOAD; behavior parameter: target file ID = F3002; extract user identification U1001, behavior identification OP_DOWNLOAD, parameter F3002; retrieve context node: OP_DOWNLOAD; LOAD is mapped to the context node CTX100; the context node table is queried to obtain the latest attributes of CTX100, such as the current security level is "medium" and is associated with device D2002; the role mapping table is queried, and U1001 is mapped to the meta-role level R2 (ordinary user); the indexing service is requested for the skip table pointer of R2, and the service returns a fast index pointer pointing to the R2 node in the linked list; (CTX100, R2) is used as the key to query in the cross-authorization matrix and return the basic permission set {"read"}; the fuzzy mapping service is requested, and (R2, CTX100) is passed in, which returns a dynamic trust factor of 0.75; the trust factor clipping rule is applied to the basic permission "read", for example, if the trust factor is <0.8, it is restricted to "read only part of the file", and a refined permission list {"read_partial"} is generated and encapsulated as a token; the token is sent to the front-end agent, and the agent only allows U1001 to read part of the content of file F3002.

[0122] The present invention is further configured to include:

[0123] S7: Unauthorized or abnormal access events and related audit tasks are added to a weighted priority queue. Dynamic weights are assigned based on event type, risk level, and latency tolerance, and prioritized execution. The root cause is traced back along the context-fusion graph and traceability logs. An audit report is generated based on cross-level index status and dynamic trust factor changes.

[0124] The present invention is further configured such that step S7 includes:

[0125] Monitor unauthorized or abnormal access events, encapsulate the event identifier, user identifier, context node identifier, and audit parameters into an audit task object, and add it to a priority queue with authority. Specifically, the audit scheduling module continuously monitors such events in the unauthorized or abnormal access detection channel. Whenever an unauthorized or abnormal access event is captured, the event identifier, user identifier, context node identifier, and audit parameters (including abnormality type and requested resource) are extracted from the event message, the above information is encapsulated into an audit task object, and inserted into a priority queue with authority.

[0126] Obtain the risk level and delay tolerance policy corresponding to the event type of the audit task object, map them to dynamic weights, and update the ranking of the audit task in the priority queue. Specifically, the audit scheduling module loads the risk level (high / medium / low) and delay tolerance policy (seconds / minutes / hours) corresponding to each event type from the configuration center. Based on the mapping rules between the task's risk level and delay tolerance, the dynamic weight of the task in the queue is calculated. The ranking position of the task in the priority queue is updated to ensure that high-risk, low-tolerance tasks are scheduled first.

[0127] Audit tasks are executed sequentially in the order of dynamic weights. Starting from the context node identifier in the audit task, the graph database traverses backwards along the associated edges recorded in the traceability log to the initial triggering node, collecting the attributes and associated status of each node along the way. Specifically, audit tasks are popped up in sequence according to queue priority. Starting from the context node identifier in the task, the graph database service is called, and the event associated edges recorded in the traceability log are traversed backwards until the initial triggering node. During the traversal, the attributes of each node (including security level and timestamp) and the relationship types between nodes are collected.

[0128] Call the cross-level indexing service to obtain the index snapshots of each meta-role node on the backtracking path in the bidirectional linked list and skip list, and call the fuzzy cognitive mapping service to obtain the dynamic trust factor evolution sequence of the corresponding node; specifically, submit the list of all meta-role level nodes appearing on the backtracking path to the cross-level indexing service, and request the current index pointer snapshots of the list in the bidirectional linked list and skip list; submit the same node list to the fuzzy cognitive mapping service to obtain the dynamic trust factor evolution sequence of the corresponding node at each historical audit moment;

[0129] According to the backtracking path data, index snapshots and trusted factor evolution information, an audit report is generated in the format of situational backtracking segment, trust evolution segment and compliance check segment; specifically, the backtracking path data is organized into situational backtracking segment to explain the start and end of the event chain and key attributes; the index snapshot and trusted factor evolution data are arranged into trust evolution segment to reflect the change in the trust of each meta-role during the backtracking process; the access legitimacy of each node is verified according to the policy compliance rules to form a compliance check segment; the three segments are merged to generate a structured audit report; in the above feasibility embodiment of the present invention, the following unauthorized access events are captured: Document ID: EVT9001; User ID: U1001; Context Node ID: CTX100; Audit Parameters: Requested Operation "Delete", Target Resource "F3002"; Audit Scheduling Module Encapsulated Task: {id: EVT9001, user: U1001, context: CTX100, op: delete, resource: F3002}, Added to Priority Queue; Configuration Center Defines "Delete" Operation Risk Level as "High" and Delay Tolerance as "Minutes"; According to the mapping rules, the weight mapping between high risk and minute level is 0.9 Put EVT9001 at the front of the queue; pop EVT9001, call the graph database, and traverse backwards from CTX100: CTX100 is associated with D2002 (device node); D2002 is associated with U1001 (user node); U1001 is associated with the initial trigger node: login event CTX001; request the index pointer snapshot of the node list [R2 (U1001 role level), R1 (administrator role level)] from the index service, and return eg{R2:ptrX,R1:ptrY}; request the historical trust factor sequence of the same list from the fuzzy mapping service, The results show that: the trust factor of R2 in the past three audits is [0.7, 0.65, 0.6]; the trust factor of R1 in the past three audits is [0.9, 0.92, 0.95]; the situational backtracking segment describes that CTX100 (deletion operation) is initiated by device D2002 and ultimately originates from CTX001 (login event); the trust evolution segment shows that the trust factor of R2 drops from 0.7 to 0.6, while R1 remains above 0.9; the compliance check segment verifies whether the "deletion" operation is allowed by the matrix at the R2 level, and confirms that the factor is lower than the threshold and a warning has been triggered; the three segments are merged to form a complete audit report.

[0130] S8: Based on the audit report, cross-level index service performance statistics, and dynamic trust factor change information, perform local incremental adjustments and re-evaluations on the context node structure, meta-role hierarchy boundaries, and cross-authorization matrix;

[0131] The present invention is further configured such that step S8 includes:

[0132] Gather the unauthorized paths, compliance anomaly information, performance statistics of cross-level indexing services, and dynamic trust factor change information identified in the audit report; specifically, extract the unauthorized paths and compliance anomaly records from the latest audit report; obtain performance indicators such as linked list / skip list access latency, hit rate, and rollback frequency from the cross-level indexing service statistics module; and obtain the dynamic trust factor change sequence of each meta-role node in the most recent audits from the fuzzy mapping service;

[0133] Based on the aggregated information, the context node structure areas, meta-role hierarchy boundaries, and cross-authorization matrix unit sets that need to be adjusted are identified. Specifically, based on the overriding paths, sub-graph areas in the context map with abnormally high incidence or concentrated overriding risks are located. Based on roles whose trust factors are consistently below the threshold, the meta-role hierarchy boundaries whose activity / sensitivity thresholds need to be fine-tuned are identified. Based on the context-role combinations that appear to be concentrated with performance bottlenecks, the cross-authorization matrix unit sets that need to have their permissions updated are marked.

[0134] Determine the affected context subgraph node set, meta-role grouping, and corresponding row and column indexes of the cross-authorization matrix. Specifically, in the graph database, collect all affected nodes and associated edges with the identified subgraph region as the root. Filter the meta-role groups and their member roles affected by the boundary change from the role mapping table. Based on the matrix unit set, list the corresponding row (context node) and column (meta-role level) index entries.

[0135] Perform local node and relationship updates on the affected contextual subgraphs, fine-tune the thresholds of the meta-role hierarchy boundaries, and update the basic permission sets of the cross-authorization matrix units. Specifically, within the graph database transaction, perform add, update, or delete operations on the node attributes or relationships of the affected subgraphs. For the meta-role hierarchy that needs fine-tuning, modify the activity / sensitivity threshold configuration and update the role mapping table. For the marked cross-authorization matrix units, update their basic permission set fields.

[0136] Ensure the atomicity of local updates within the transaction context, triggering synchronous refreshes of the cross-level indexing service and cache layer. Specifically, ensure that all the above updates are committed within the same transaction context to maintain data consistency. After the transaction is committed, a refresh notification is sent to the cross-level indexing service and the context-fusion cache layer, respectively, to synchronize the index structure and cache entries to the latest state.

[0137] The local update results and verification feedback are recorded in the optimization log, and an adjustment completion notification is generated. Specifically, the details of this local update (updated object, timestamp, snapshots before and after the update) are written to a dedicated optimization log. An optimization adjustment completion notification is generated and sent. In the above-mentioned feasibility embodiment of the present invention, an audit found that the unauthorized path is concentrated in the context node CTX100 (high-sensitivity operation) and the meta-role level R2 (ordinary user). The index service reports that the average delay of the linked list query of CTX100-R2 is 120m. s, which is greater than the target of 50ms; the dynamic trust factor of R2 has continuously decreased in the last three audits: 0.65→0.60→0.55; the overreach report marks CTX100→R2; index performance statistics show that the CTX100–R2 snapshot is slow; the trust factor change sequence is [0.65, 0.60, 0.55]; CTX100 and its directly related nodes (such as U1001 and D2002) are marked as subgraphs that need adjustment; the sensitivity threshold of R2 is tightened from "4–7" to "5–7", improving Permission group hierarchy; mark the intersection matrix unit (CTX100, R2) to tighten its base permission set; determine the affected objects: subgraph node set: {CTX100, U1001, D2002}; meta-role group R2 members: {role B, role C}; matrix row and column index: CTX100 row × R2 column; update the "low trust" relationship label between CTX100 and U1001 to "under audit" in the graph database; configure the sensitivity threshold of R2 from "4–7" in the role mapping table Change the permission set of (CTX100, R2) from "Read" to "Read Restricted" in the cross-authorization matrix. All changes are bundled and submitted in the same transaction. After the submission is successful, a link-list-skip-list refresh instruction for CTX100 and R2 is sent to the indexing service, and the context cache layer is notified to clear the CTX100 cache. Optimize logging: Updated items: CTX100-R2 matrix permissions, R2 threshold configuration, relationship labels; Time: 2025-06-12T14:05:00Z.

[0138] Send CTX100–R2 permission and threshold adjustment completion notification.

[0139] 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 program 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 can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. 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 via a wired (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can 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 can be a solid-state drive.

[0140] It should be understood that the term "and / or" as used herein simply describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A alone, A and B together, or B alone. A and B can be singular or plural. Furthermore, the character " / " as used herein generally indicates an "or" relationship between the associated objects, but it may also indicate an "and / or" relationship. For specific understanding, please refer to the context.

[0141] In this application, "at least one" means one or more, and "plurality" means two or more. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.

[0142] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

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

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

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

[0146] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

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

[0148] If the functions are implemented in the form of software functional units 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. The computer software product is stored in a storage medium and includes several instructions for enabling 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 method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0149] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A hierarchical access rights management method for a behavior monitoring system, characterized in that: include: S1: Generate context nodes based on the multi-dimensional characteristic attributes of behavioral events, encapsulate changes in context nodes as traceability events, and record them in the traceability log; S2: Perform local incremental updates on the affected context subgraph based on the provenance log; S3: Abstract business roles according to activity thresholds and sensitivity thresholds, dividing them into multiple levels of meta-roles. For each level of meta-role, maintain a bidirectional linked list sorted by permission sensitivity, and construct a skip list index on the bidirectional linked list. S4: Set multi-level meta-roles as fuzzy cognitive mapping nodes, establish bidirectional fuzzy edge weights based on the trust relationship between roles, and dynamically adjust the edge weights according to audit feedback and historical behavior sequences to obtain dynamic trust factors; S5: Construct a cross-authorization matrix with context nodes and meta-role levels as row and column labels, and store the basic permission set in each cross unit; S6: Map the behavior to be authorized to the corresponding context node, retrieve the node status after the latest incremental update, locate the meta-role level of the target user, quickly extract the corresponding basic permission set in the cross-authorization matrix through the skip table index, tailor the basic permission set based on the dynamic trust factor, generate the authorization result and issue it for execution.

2. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Multidimensional feature attributes include operation type, spatiotemporal information, device attributes, and security level; Changes include additions, modifications or deletions; Step S1 includes: obtaining multidimensional feature attributes of a behavior event, and generating a situation node identifier based on the multidimensional feature attributes; In the graph database, a context node is created or updated according to the context node identifier, the creation or update operation is encapsulated as a traceability event, and the traceability event is recorded in the traceability log.

3. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Step S2 includes: Monitor the tracing logs and obtain new tracing events in sequence; Based on the context node identifiers and change details recorded in the traceability event, the vertices and edges directly associated with the context are obtained from the graph database to generate the affected context subgraph; Generate change map entries for nodes and edges in the affected subgraph based on the change details; Perform localized update operations on contextual nodes and edges in the affected subgraph within the graph database transaction context; After the update is completed, a synchronization refresh notification is sent to the cross-level indexing service and the context fusion cache layer to record the processing status of the processed traceability events.

4. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Step S3 includes: Obtain activity and sensitivity indicators of business roles; Based on the activity threshold and sensitivity threshold predefined in the configuration center, business roles are mapped to corresponding meta-role levels, and the correspondence between role IDs and meta-role IDs is recorded in the role mapping table. Initialize a bidirectional linked list for each meta-role group, encapsulate the corresponding business roles as linked list nodes, and insert them in order according to the sensitivity index; An index layer is set at a fixed node interval on the bidirectional linked list to form a multi-layer skip list structure. Each index node maintains a jump pointer to the next layer node. Persist the skip list structure and linked list node pointer information to the index metadata storage; For activity or sensitivity change events of business roles, the corresponding linked list node is located based on the role mapping table, local node movement is performed, and the jump pointer information of the node in the jump table index layer is synchronously updated.

5. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Step S4 includes: Obtain meta-role trust metrics, including compliance rate, number of abnormal accesses, and audit pass rate; Multi-level meta-roles are mapped into fuzzy cognitive mapping nodes, and bidirectional fuzzy edge weights are established between nodes according to the preset trust strategy and stored in the form of membership function parameters; Build a fuzzy reasoning rule base, including IF-THEN rules based on audit feedback and historical behavior indicators; The trust indicators are mapped to membership degrees and input into the fuzzy inference engine, which generates adjustment suggestions for each bidirectional fuzzy edge weight based on the rule base; Aggregate and normalize the adjustment suggestions and original membership function parameters, and update the bidirectional fuzzy edge weights; For each fuzzy cognitive mapping node, the updated bidirectional fuzzy edge weight and input edge membership are fused to generate a dynamic credibility factor.

6. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Step S5 includes: Create a cross-authorization matrix table. The table definition fields include the situation node ID, meta-role level ID, and basic permission set. Set the situation node ID and meta-role level ID as the joint primary key. Based on the situation node identifier and the multi-level meta-role level identifier, a Cartesian product insertion operation is performed to generate a matrix unit, and the basic permission set field of the matrix unit is updated according to the preset security policy; Create B+ tree joint indexes for the context node identification field and the meta-role level identification field respectively; Taking the context node ID and meta-role level ID as input parameters, locate a single matrix record through the joint index and return the corresponding basic permission set; Define database triggers or event subscription mechanisms to listen to change events at the context node and meta-role levels, and trigger update operations on affected units in the cross-authorization matrix table.

7. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Step S6 includes: Receive the action request message and obtain the action ID, user ID and action parameters from the message body; Map the behavior identifier to the corresponding context node identifier, query the context node table, and obtain the node attributes and associated status after the latest incremental update; Access the role mapping table and obtain the meta-role level identifier of the target user based on the user ID; Initiate an index query request to the cross-level index service and retrieve the index pointer in the skip list index structure using the meta-role level identifier; Based on the index pointer, a joint primary key query is constructed on the cross-authorization matrix table to obtain the corresponding basic permission set; Submit the meta-role level identifier and context node identifier to the fuzzy cognitive mapping service, and call the dynamic trust factor to obtain the latest trust factor value; Apply dynamic trust factors to the basic permission set, execute screening rules, output a refined permission list, encapsulate it into a permission policy token, and send the permission policy token to the front-end proxy component in a standard message format for execution.

8. The hierarchical access rights management method for a behavior monitoring system according to claim 1, characterized in that: Also includes: S7: Unauthorized or abnormal access events and related audit tasks are added to a weighted priority queue. Dynamic weights are assigned based on event type, risk level, and latency tolerance, and prioritized execution. The root cause is traced back along the context-fusion graph and traceability logs. An audit report is generated based on cross-level index status and dynamic trust factor changes. S8: Based on the audit report, cross-level index service performance statistics and dynamic trust factor change information, local incremental adjustments and re-evaluations are made to the context node structure, meta-role hierarchy boundaries and cross-authorization matrix.

9. The hierarchical access rights management method for a behavior monitoring system according to claim 8, characterized in that: Step S7 includes: Monitor unauthorized or abnormal access events, encapsulate the event ID, user ID, context node ID, and audit parameters into an audit task object, and add it to the authorized priority queue; Obtain the risk level and delay tolerance policy corresponding to the event type of the audit task object, map them to dynamic weights, and update the order of the audit task in the priority queue; Audit tasks are executed sequentially according to the dynamic weight order. Starting from the context node in the audit task in the graph database, the associated edges recorded in the traceability log are traversed in reverse to the initial triggering node, collecting the attributes and associated status of each node along the way. Call the cross-level indexing service to obtain the index snapshot of each meta-role node on the backtracking path in the bidirectional linked list and skip list, and call the fuzzy cognitive mapping service to obtain the dynamic trust factor evolution sequence of the corresponding node; Based on the backtracking path data, index snapshots, and trust factor evolution information, an audit report is generated in the format of situation backtracking segment, trust evolution segment, and compliance check segment.

10. The hierarchical access rights management method for a behavior monitoring system according to claim 8, characterized in that: Step S8 includes: Gather information on unauthorized paths, compliance anomalies, performance statistics of cross-level indexing services, and dynamic trust factor changes identified in audit reports; Based on the aggregated information, identify the context node structure areas, meta-role hierarchy boundaries, and cross-authorization matrix unit sets that need to be adjusted; Determine the affected context subgraph node set, meta-role grouping, and corresponding row and column indexes of the cross-authorization matrix; Perform local node and relationship updates on the affected situation subgraphs, fine-tune the thresholds of meta-role hierarchy boundaries, and update the basic permission sets for cross-authorization matrix units; Ensure the atomicity of local updates within the transaction context, triggering synchronous refreshes of cross-level index services and cache layers; The local update results and verification feedback are recorded in the optimization log, and an adjustment completion notification is generated.

Images