An electronic terminal management and control method and system based on data interaction

Abstract

The application discloses an electronic terminal management and control method and system based on data interaction, and belongs to the technical field of electronic terminal safety management and control. The method comprises the following steps: intercepting a data interaction request of an electronic terminal, extracting five-dimensional features of data type, direction, size, target address and timestamp, and constructing a multi-dimensional behavior feature vector; a multi-dimensional layered management and control rule library containing terminal level, application level, data type level and behavior level rules is constructed; before data interaction is executed, the feature vector is matched with the rule library in multiple dimensions, and a management and control decision is output; and according to the decision result, a blocking, passing, speed limiting or alarm disposal strategy is executed. The application also supports dynamic hot updating of rules and conditional tree matching. The system comprises a feature extraction module, a layered management and control rule library storage module, a rule matching engine and a management and control execution module. The application can realize fine-grained, layered and real-time management and control of data interaction behaviors of electronic terminals.

Description

Technical Field

[0001] This application belongs to the technical field of computer electronic terminal management and control, specifically relating to an electronic terminal management and control method and system based on data interaction. Background Technology

[0002] With the rapid development of information technology, electronic terminals have become core devices for data interaction, and the security and controllability of their data interaction behavior are receiving increasing attention. In application scenarios such as enterprise offices, mobile finance, and smart homes, terminals face security risks such as data leakage and unauthorized transmission. Therefore, effective control over terminal data interaction behavior is of great significance.

[0003] Currently, the control of data interaction behavior on electronic terminals is usually based on the entire application or the overall data type as the basic control unit. For example, it may directly allow or prohibit a certain application from accessing the internet, or allow or block the transmission of a certain type of file. This control method is coarse-grained and cannot distinguish between different data interaction behaviors within the same application. For example, in the same chat application, text message transmission, image file transmission, and video file transmission have different data characteristics and security risks, but existing technologies cannot formulate differentiated control strategies for these behaviors. In addition, existing control rules usually use simple blacklists and whitelists or single-dimensional condition judgments, lacking a hierarchical rule architecture that supports multi-dimensional condition combinations such as data type, data direction, data volume, target address, and time, resulting in insufficient flexibility and granularity of control strategies.

[0004] Therefore, how to achieve fine-grained, multi-dimensional, and layered control over the data interaction behavior of electronic terminals has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this invention is to provide a data interaction-based electronic terminal management and control method and system, which can effectively solve the problems of existing technologies having coarse granularity in controlling terminal data interaction behavior, lacking fine-grained differentiation and control capabilities, and failing to meet the needs of fine-grained control in complex scenarios.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for managing electronic terminals based on data interaction includes the following specific steps: Intercept data interaction requests initiated by electronic terminals, parse and extract data type dimension features, data direction dimension features, data size dimension features, interaction target address dimension features, and interaction timestamp dimension features from the original network data packets, and construct a multi-dimensional behavioral feature vector based on the extracted five dimension features; A multi-dimensional hierarchical management rule base is constructed. The multi-dimensional hierarchical management rule base stores rule data in a tree-like hierarchical structure. The tree-like hierarchical structure includes terminal-level rules, application-level rules, data type-level rules, and behavior-level rules. The terminal-level rules are used to define the overall management strategy for a specific electronic terminal. The application-level rules are used to define the management strategy for a specific application. The data type-level rules are used to define the management strategy for interaction behavior of a specific data type. The behavior-level rules are used to define the refined management strategy for data interaction behavior that meets a specific combination of multi-dimensional conditions. Before the data interaction behavior is executed, the multi-dimensional behavior feature vector is matched with the rules in the multi-dimensional hierarchical control rule base in a multi-dimensional condition, and the control decision judgment result is output based on the matching result. Based on the control decision judgment results, the data interaction behavior is handled by blocking, allowing, limiting or alarming strategies.

[0007] Furthermore, the multi-dimensional behavioral feature vector is matched with the rules in the multi-dimensional hierarchical management rule base using multi-dimensional conditional matching, specifically including: The matching process is executed using a pipelined processing mechanism, which includes a feature parsing stage and a rule matching stage. In the feature parsing stage, the multidimensional behavioral feature vector is converted into a feature index structure that can be recognized by the real-time data interaction behavior parsing and rule matching engine. According to the numerical type and distribution range of each dimension feature, the original values ​​of each dimension are mapped to the index key values ​​in the feature index structure. During the rule matching stage, based on the feature index structure, multi-dimensional condition retrieval is performed layer by layer from top to bottom in the multi-dimensional hierarchical management rule base according to the hierarchical order of terminal-level rules, application-level rules, data type-level rules, and behavior-level rules.

[0008] Furthermore, the method also includes a hot update step for control rules: An incremental rule distribution protocol is established, which adopts a differential update mechanism. The rule update request only carries the difference data of adding, modifying and deleting rules, and does not carry the complete rule base data. Establish a rule version control mechanism to assign a globally unique version number to each rule change. The version number is generated in ascending order according to the time sequence of the rule change and is managed uniformly by the management and control backend. A two-phase commit protocol is adopted to ensure the atomicity and consistency of rule base updates. The two-phase commit protocol includes a pre-commit phase and a formal commit phase. During the pre-submission phase, the management and control backend sends the new version rule data to the electronic terminal. The electronic terminal writes the new version rule data into the pre-loading area, maintains two sets of rule data, namely the currently effective version and the pre-loaded version, and enters the trial operation state. After the trial operation verification is successful, it sends a pre-submission confirmation message to the management and control backend. During the formal submission phase, after receiving the pre-submission confirmation message, the management backend sends a formal submission instruction to the electronic terminal. The electronic terminal switches the new version rule data in the pre-loaded area to the currently effective version and updates the version number identifier.

[0009] Furthermore, the rule condition field of the behavior level rule is expressed in the form of a structured condition tree. Each condition tree consists of a root condition and multiple child condition nodes, which are connected by logical operators AND, OR, or NOT. During the behavior-level rule matching process, a recursive algorithm is used to calculate the condition tree, with nodes as input parameters. When a node is a leaf node, the matching result between the dimensional condition corresponding to the node and the multidimensional behavior feature vector is directly calculated, and a Boolean calculation result is returned. When a node is not a leaf node, the matching results of each child node are recursively calculated. The matching results of each child node are combined according to the logical operator type corresponding to the node. For the combination operation of the logical operator AND, a short-circuit evaluation strategy is adopted. When the matching result of any child node is false, the subsequent child nodes are not calculated and the value is returned as false. For the combination operation of the logical operator OR, a short-circuit evaluation strategy is adopted. When the matching result of any child node is true, the subsequent child nodes are not calculated and the value is returned as true.

[0010] Furthermore, the multi-dimensional hierarchical management rule base uses an inverted index structure to store rule conditions. Index tables are built according to data type dimension, data direction dimension, data size range, and time window dimension. The key of each index table is the feature value of the dimension, and the value is a list of rules that match the feature value. The real-time parsing and rule matching engine for data interaction behavior is set up with a caching mechanism to cache the rule matching results of a preset number of times to a high-speed cache. The high-speed cache adopts a least recently used eviction policy to manage the cache space. The cache entry consists of three parts: feature vector hash value, matching result, and cache timestamp. The feature vector hash value is generated by calculating the feature values ​​of each dimension of the multi-dimensional behavior feature vector through a hash function.

[0011] Furthermore, based on the control decision judgment result, a rate-limiting strategy is implemented for data interaction behavior, specifically including: The token bucket algorithm is used to limit the data transmission rate of data interaction behavior. The parameters of the token bucket algorithm include the token generation rate and the token bucket capacity. The token generation rate corresponds to the rate limiting threshold, and the token bucket capacity is set to twice the rate limiting threshold. During the rate limiting process, the control and execution module monitors the actual data transmission rate in real time and ensures that the actual transmission rate does not exceed the corresponding rate limit threshold by adjusting the token consumption rate and token replenishment strategy.

[0012] Furthermore, the method also includes a step of recording control decision logs: Record multidimensional behavioral feature vectors of data interaction behaviors, matching control rule information, executed handling strategy types, and processing timestamps of data interaction behaviors; Log data is encrypted and stored using the AES-256 symmetric encryption algorithm, and the content of the log records is signed using a digital signature algorithm for integrity verification and non-repudiation verification of log data. The log data supports combined queries based on time range, data type, application name, and handling strategy type. It also supports aggregated analysis of log data to generate statistical reports on data interaction behavior and allows tracing the complete processing of data interaction behavior based on its unique identifier.

[0013] Furthermore, intercepting data interaction requests initiated by electronic terminals is specifically achieved through system-level Hook mechanisms or kernel-level monitoring mechanisms; The system-level Hook mechanism is implemented by overloading the system call functions of the operating system's network interface layer. These system call functions include the network sending function sendto, the network receiving function recvfrom, the socket sending function send, and the socket receiving function recv. The kernel-level monitoring mechanism embeds a dedicated monitoring module between the data link layer and the network layer of the kernel network protocol stack. The embedding point of the monitoring module is selected between the receive function of the kernel network driver and the upper-layer protocol processing function.

[0014] Furthermore, the data size dimension features are parsed and extracted from the original network data packets, specifically as follows: The total amount of data involved in a single data interaction is recorded in bytes. The payload length of all related data packets of the same data session within a specific time window is accumulated. When the time interval between a new data packet and the data packets of an existing session exceeds the time window threshold, it is determined to be a new data session. The default value of the time window is 5 seconds. The extraction of interaction timestamp dimension features specifically involves: recording the precise time when data interaction occurs, using Coordinated Universal Time (UTC) format, accurate to the millisecond level, and recording the time period classification of data interaction behavior within a day, in order to support the matching of control rules based on time windows.

[0015] An electronic terminal control system based on data interaction, comprising: The feature extraction module is used to intercept data interaction requests initiated by electronic terminals, parse and extract data type dimension features, data direction dimension features, data size dimension features, interaction target address dimension features, and interaction timestamp dimension features from the original network data packets, and construct a multi-dimensional behavioral feature vector based on the extracted five dimension features. The hierarchical management rule base storage module is used to store a multi-dimensional hierarchical management rule base. The multi-dimensional hierarchical management rule base uses a tree-like hierarchical structure to store rule data. The tree-like hierarchical structure includes terminal-level rules, application-level rules, data type-level rules, and behavior-level rules. The real-time data interaction behavior analysis and rule matching engine is used to perform multi-dimensional condition matching between the multi-dimensional behavior feature vector and the rules in the multi-dimensional hierarchical control rule base before the data interaction behavior is executed, and output the control decision judgment result based on the matching result. The control and execution module is used to execute blocking, allowing, rate limiting, or alarm handling strategies on data interaction behaviors based on the control and decision judgment results.

[0016] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention extracts multi-dimensional features such as data type, data direction, data size, interaction target address, and interaction time for each data interaction behavior, and constructs a refined behavior feature vector to achieve fine-grained differentiation of different data interaction behaviors within the same application. For example, it can distinguish different types of data interaction behaviors such as text message transmission, image file transmission, and video file transmission in the same chat application. 2. The real-time data interaction behavior analysis and rule matching engine designed in this invention adopts a pipeline processing mechanism of feature analysis module and rule matching engine to ensure that control decisions are completed before the actual data interaction occurs, and the response delay meets the preset time threshold requirements, thus meeting the performance requirements of real-time control scenarios. 3. The hot update interface for management rules provided by this invention supports dynamic updates of the rule base without restarting the service, enabling real-time adjustment and immediate effect of management policies. The rule update effect time meets the preset time requirements. Compared with the existing technology that requires restarting the application or system for policy changes to take effect, this greatly improves the timeliness of policy adjustment. 4. The hierarchical control strategy model established in this invention supports configuring control rules at multiple levels, such as terminal level, application level, data type level, and behavior level, to achieve progressively refined control from macro to micro. The hierarchical rule inheritance and overriding mechanism makes strategy configuration more flexible and efficient, and supports refining the control granularity layer by layer as needed. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the overall technical solution for an electronic terminal management and control method based on data interaction; Figure 2 This is a schematic diagram illustrating the core principles of a multi-dimensional, layered management rule base. Figure 3 This is a schematic diagram illustrating the core principles of multi-dimensional condition matching and pipelined processing; Figure 4 This is a flowchart illustrating the workflow of the hot update interface and version control for management rules; Figure 5 This is a schematic diagram of the multi-level interaction relationship and data flow between electronic terminals and the control system. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the following description is provided in conjunction with the appendix. Figure 1 To be continued Figure 5 The present invention will be further described in detail below with reference to specific embodiments.

[0019] Firstly, the core of the electronic terminal management and control method based on data interaction proposed in this invention lies in constructing a complete multi-dimensional behavioral feature extraction system, a hierarchical management and control rule base, a real-time rule matching engine, and a hot update interface mechanism. This method is deployed in the operating system layer or security management module of the electronic terminal. Through a system-level monitoring mechanism, it intercepts, analyzes, and matches all data interaction behaviors generated by the terminal in real time, and finally executes corresponding management and control strategies based on the matching results. Specifically, it is implemented according to the following steps.

[0020] The first step, S1, involves intercepting data interaction requests and extracting multi-dimensional behavioral features. This process uses a system-level monitoring mechanism to intercept data interaction requests initiated by electronic terminals. From the original network data packets, five dimensions of features are parsed and extracted: data type, data direction, data size, interaction target address, and interaction timestamp. Finally, a standardized multi-dimensional behavioral feature vector is constructed, providing a data foundation for subsequent refined rule matching. The specific implementation is as follows.

[0021] Step S101: Intercept data interaction requests by intercepting data interaction requests initiated by electronic terminals through system-level Hook mechanisms or kernel-level monitoring mechanisms.

[0022] The system-level hook mechanism is implemented by overriding system call functions of the operating system's network interface layer. When an application initiates a network communication request, the request first enters the processing flow of the operating system's network protocol stack. The system-level hook module intercepts requests by hooking key system calls, including the network send function `sendto`, the network receive function `recvfrom`, the socket send function `send`, and the socket receive function `recv`.

[0023] During the interception process, the system-level Hook module maintains the integrity of the original system call functions, while forwarding a copy of the data interaction request to the feature extraction module for processing.

[0024] Kernel-level monitoring mechanisms involve embedding a dedicated monitoring module within the kernel network protocol stack. This monitoring module resides between the data link layer and the network layer of the kernel protocol stack, enabling direct access to all network packets passing through it.

[0025] Once a data packet enters the kernel network protocol stack, the monitoring module first copies the packet, then performs deep parsing on the copied copy, while the original packet continues to be processed according to the normal protocol flow. The monitoring module is embedded between the kernel network driver's receive function and the upper-layer protocol processing function, ensuring that all incoming and outgoing network data is intercepted.

[0026] Step S102: Parse the data packet and prepare for feature extraction. After intercepting the data interaction request, the feature extraction module parses and extracts multi-dimensional behavioral feature vectors from the original data packet.

[0027] The parsing process first identifies the protocol type of the data packet, and then determines the starting position of the data payload and the parsing method based on the protocol type. For TCP packets, the parsing process first performs transport layer reassembly, that is, reassembles the fragmented data packets into a complete data stream according to their sequence numbers, and then extracts the application layer data from the reassembled data stream. For UDP packets, since reassembly is not required, the parsing process directly extracts the data payload content.

[0028] Step S103: Extract data type dimension features. The feature extraction module extracts features from 5 core dimensions.

[0029] The first dimension is the data type dimension, which identifies the specific category of the data content. The classification criteria combine content recognition and protocol analysis. Content recognition determines the data type by analyzing the header feature bytes of the data payload.

[0030] For example, JPEG image data begins with the byte sequence FFD8FF, PNG image data begins with the byte sequence 89504E47, and MP4 video data is identified by a specific ftyp atomic structure. Protocol analysis determines the application protocol type of the data by analyzing the network layer and transport layer header information of the data packet. For example, HTTP protocol transmits web page content, HTTPS protocol transmits encrypted content, FTP protocol transmits file data, and DNS protocol transmits domain name resolution requests.

[0031] Based on the combined results of content recognition and protocol analysis, the data type dimension is labeled as one of the specific categories such as text, image, audio / video, document, or binary stream.

[0032] Step S104: Extract data direction and data size dimension features. The second dimension is the data direction dimension, used to identify the data flow direction and distinguish between upload and download behaviors. The judgment is based on the positional relationship between the source and destination addresses of the data packets relative to the electronic terminal.

[0033] When the source address of a data packet is the local IP address of the electronic terminal and the destination address is an external network address, it is determined to be an upload behavior; when the source address of a data packet is an external network address and the destination address is the local IP address of the electronic terminal, it is determined to be a download behavior.

[0034] For bidirectional data interaction behaviors that simultaneously involve uploading and downloading, the feature extraction module records data packet statistics for both directions, including the number of bytes uploaded, the number of bytes downloaded, the number of data packets uploaded, and the number of data packets downloaded.

[0035] The third dimension is the data size dimension, which records the total amount of data involved in a single data interaction in bytes. The statistical method is to accumulate the payload length of all relevant data packets for the same data session within a specific time window. The default time window is 5 seconds, but this value is adjusted according to the actual application scenario.

[0036] A new data session is defined as one that occurs when the time interval between a new data packet and an existing session's data packet exceeds a time window threshold. For example, a file transfer session may generate multiple data packets within a few seconds; the sum of the payload lengths of these packets represents the total data volume of this interaction. The range of values ​​for the data size dimension is determined based on the actual data interaction behavior, with no upper limit and a lower limit of 0 bytes.

[0037] Step S105: Extract the interaction target address and interaction timestamp dimensions. The fourth dimension is the interaction target address dimension, which records the peer network identifier of the data interaction, including IP address and port number. For the IPv4 protocol, the network address uses a 32-bit dotted decimal format, such as 192.168.1.100; for the IPv6 protocol, the network address uses a 128-bit colon hexadecimal format.

[0038] The port number record shows the port number the peer service is listening on, ranging from 0 to 65535. The target address dimension also records the local source address information of the electronic terminal, including the local IP address and source port number. If the target address is in the form of a domain name, the feature extraction module extracts the IP address while saving the domain name resolution result, establishing a mapping relationship between the domain name and the IP address.

[0039] The fifth dimension is the interaction timestamp dimension, which records the precise time when the data interaction occurred, using UTC time format, accurate to the millisecond level. The timestamp record includes the start time, end time, and duration of the data interaction.

[0040] The interaction timestamp dimension also records the time periods of the day in which data interaction behavior occurs. For example, the early morning period is from 0:00 to 6:00, the morning period is from 6:00 to 12:00, the afternoon period is from 12:00 to 18:00, and the evening period is from 18:00 to 24:00. This design is to support the matching of control rules based on time windows.

[0041] Step S106: Construct a multi-dimensional behavioral feature vector. After extracting features from the above five dimensions, a multi-dimensional behavioral feature vector is constructed. The feature vector is stored in a structured data format, with each feature dimension corresponding to a component of the vector. The mathematical expression of the vector is: in, The feature values ​​representing the data type dimension The feature values ​​representing the directional dimension of the data. Feature values ​​representing the size dimension of the data. The feature value represents the dimension of the target address in the interaction. This represents the feature value along the interaction timestamp dimension. The multidimensional behavioral feature vector serves as the core input data for subsequent rule matching.

[0042] Step S1 intercepts data interaction requests through system-level hooks or kernel-level monitoring. After protocol parsing, it extracts five dimensions of features: data type, data direction, data size, interaction target address, and interaction timestamp. It then constructs a standardized multi-dimensional behavioral feature vector, making different data interaction behaviors within the same application distinguishable and providing accurate input for subsequent construction of a hierarchical rule base and rule matching.

[0043] The next step, S2, involves constructing a multi-dimensional, hierarchical management rule base. This step establishes a hierarchical rule base that supports combinations of multiple conditions, including data type, data direction, data volume threshold, time window, and target address. A hierarchical rule structure is used for storage, rule priorities are configured, and a conflict resolution mechanism is implemented. Follow the steps below.

[0044] Step S201: Define a tree-like hierarchical structure. The hierarchical management rule base uses a tree-like hierarchical structure to store rule data, with a total of 4 rule levels.

[0045] The first level is the terminal-level rule, which defines the overall control policy for a specific electronic terminal and applies to all data interaction behaviors of the electronic terminal. The data structure of the terminal-level rule includes a terminal identifier field, a rule activation status field, a default handling policy field, and a rule validity period field. The terminal identifier field records the unique identification information of the controlled terminal, such as the device serial number or MAC address. The default handling policy field defines the fallback handling method when no lower-level rule matches, which includes three strategies: blocking, allowing, and alarming.

[0046] The second level is application-level rules, which define control policies for specific applications and apply to all data interaction behaviors generated by those applications. The data structure of application-level rules includes an application identifier field, a process name field, a package name field, a rule enablement status field, a default handling policy field, and a rule priority field. The application identifier field records the unique identification information of the controlled application. Application-level rules inherit the settings of terminal-level rules and can override or refine them based on terminal-level rules.

[0047] The third level consists of data type-level rules, which define control strategies for interactions based on specific data types. These strategies apply to all data interactions that conform to the characteristics of the data type. The data structure of data type-level rules includes a data type field, a rule activation status field, a handling strategy field, and a rule priority field. The values ​​of the data type field correspond to the data type dimension in the multi-dimensional behavior feature vector, and the values ​​include type identifiers such as text, image, audio / video, document, and binary stream. Data type-level rules inherit the settings of application-level rules and can override or refine them.

[0048] The fourth level consists of behavior-level rules, which define refined control strategies for specific data interaction behaviors and apply to data interaction behaviors that meet specific combinations of multi-dimensional conditions. The data structure of behavior-level rules includes rule condition fields, rule action fields, rule activation status fields, rule priority fields, and rule validity period fields.

[0049] The rule condition field supports multi-dimensional condition combinations, including data type conditions, data direction conditions, data volume threshold conditions, time window conditions, target address conditions, and any logical combinations thereof. The rule action field specifies the handling strategy to be executed when the rule conditions are met. The handling strategies include four action types: blocking, allowing, rate limiting, and alarm.

[0050] Step S202: Define the rule condition expression method. The rule conditions are expressed in a structured condition tree form. Each condition tree consists of a root condition and several child condition nodes, which are connected by logical operators AND, OR, and NOT.

[0051] Data type conditions support two modes: exact matching and regular expression matching. Exact matching is used to specify a single data type, such as data type equal to image; regular expression matching is used to specify multiple data types that match a specific pattern, such as data type matching video.

[0052] Data direction conditions support exact matching and range matching. Exact matching specifies a single direction, such as data direction equal to upload; range matching specifies a set of directions, such as data direction belonging to the upload and download set.

[0053] The data size threshold condition supports comparison operations such as greater than, less than, equal to, and interval. For example, data size greater than 1048576 means data size greater than 1MB.

[0054] The time window condition supports two modes: absolute time and relative time. Absolute time specifies a specific point in time or time period, such as a timestamp between 08:00:00 and 18:00:00; relative time specifies the time constraint after the data interaction occurs, such as if it occurred within the last 24 hours.

[0055] The target address condition supports three modes: exact matching, CIDR network segment matching, and regular expression matching.

[0056] Step S203: Establish an inverted index structure. The rule base uses an inverted index structure to store rule conditions, thereby improving the retrieval efficiency of the multi-dimensional condition matching algorithm. The index structure establishes index tables according to dimensions such as data type, data direction, data size range, and time window. The key of each index table is the feature value of the dimension, and the value is a list of rules matching the feature value.

[0057] During rule matching, a preliminary search is first performed in the corresponding index table based on the feature values ​​of each dimension in the feature vector to obtain a set of candidate rules. Then, a complete multi-dimensional condition matching verification is performed in the set of candidate rules.

[0058] Step S204: Configure rule priority and conflict resolution mechanisms. The rule priority configuration mechanism is set according to the principle of increasing hierarchical depth. Behavior-level rules have higher priority than data type-level rules, data type-level rules have higher priority than application-level rules, and application-level rules have higher priority than terminal-level rules. Multiple rules within the same level are sorted according to the value of the rule priority field; the larger the priority value, the higher the priority.

[0059] The conflict resolution mechanism has a three-stage workflow.

[0060] The first stage is the rule matching stage. First, the rules of each level are matched sequentially from top to bottom according to the hierarchical order, and the matching results of each level are recorded.

[0061] The second stage is the conflict detection stage, which checks whether there are rule conflicts between different levels, that is, rules at different levels specify contradictory handling strategies.

[0062] The third stage is the conflict resolution stage, which follows the principle of hierarchical priority and uses the handling strategy of the highest level rule as the basis for the final decision.

[0063] Step S2 establishes a four-layer tree-structured rule base, defines the rule expression method of the condition tree, adopts an inverted index to improve retrieval efficiency, and configures hierarchical priority and conflict resolution mechanisms. This rule base supports progressively refined control from the terminal level to the behavior level, providing structured and quickly searchable rule data for subsequent real-time rule matching.

[0064] The next step, S3 in this embodiment, involves parsing the features and matching the control rules in real time. Before the data interaction behavior is executed, the extracted multi-dimensional behavioral feature vector is matched with the hierarchical control rule base under multi-dimensional conditions to retrieve and match the corresponding control rules, and output a fine-grained control decision judgment result. This is specifically implemented according to the following steps.

[0065] Step S301, Feature parsing stage, converts feature vectors into feature index structures. The multi-dimensional condition matching algorithm adopts a pipeline processing mechanism, which includes a feature parsing stage and a rule matching stage.

[0066] The feature parsing stage converts multidimensional behavioral feature vectors into a feature index structure recognizable by the rule matching engine. During this conversion, the feature parsing module first reads the original values ​​of each dimension of the feature vector, and then maps these original values ​​to index keys in the feature index structure based on the numerical type and distribution range of each dimension's features. The mapping rules for these index keys are consistent with the index key generation rules of the rule base's inverted index structure, ensuring that the feature parsing results correctly match the corresponding rule index table.

[0067] The data format of the feature index structure is a set of key-value pairs. The key of each key-value pair is the index dimension identifier, and the value is the index key-value sequence corresponding to the index dimension.

[0068] For the data size dimension, since the values ​​range are large and continuously distributed, the feature index structure uses interval partitioning to generate index keys, mapping continuous data size values ​​to discrete interval identifiers. The granularity of interval partitioning is configured according to the actual application scenario, with the default being a power of 2 interval partitioning method. The default interval partitioning divides the data size into several intervals: 0 to 1KB, 1KB to 1MB, 1MB to 100MB, and above 100MB.

[0069] Step S302, Rule Matching Stage: This stage performs multi-dimensional conditional retrieval within the hierarchical rule base based on the feature index structure. The retrieval process matches rules layer by layer from top to bottom, and after each layer's matching is completed, the decision to continue searching for rules at the next lower level is based on the matching results. The matching process consists of four stages.

[0070] The first stage is terminal-level rule matching. The terminal identification information in the feature index structure is retrieved from the terminal-level rule index table to obtain the corresponding terminal-level rule. If the terminal-level rule exists and is enabled, a full match verification of the rule conditions is performed. If the match is successful, the handling strategy of the terminal-level rule is recorded as the current optimal strategy, and the process proceeds to the next matching stage. If the match fails or the terminal-level rule does not exist, the default handling strategy of the terminal-level rule is used as the current optimal strategy, and the process proceeds to the next matching stage.

[0071] The second stage is application-level rule matching. The application identifier information in the feature index structure is retrieved from the application-level rule index table to obtain a list of application-level rules corresponding to the application identifier information. The application-level rule list may contain multiple rules, which are matched and verified sequentially according to the value of the rule priority field from highest to lowest.

[0072] If an application-level rule matches successfully and its handling strategy conflicts with the current optimal strategy, the application-level rule's handling strategy overrides the current optimal strategy. If an application-level rule matches successfully but its handling strategy does not conflict with the current optimal strategy, the current optimal strategy remains unchanged. If all application-level rules fail to match, the current optimal strategy remains unchanged. After all application-level rule matching is complete, regardless of whether a match is successful, the process proceeds to the next level of matching.

[0073] The third stage is data type level rule matching. Data type information in the feature index structure is retrieved from the data type level rule index table to obtain the list of data type level rules corresponding to the data type information. Data type level rules are matched and verified sequentially from highest to lowest priority, and the current optimal strategy is updated based on the matching results. After data type level rule matching is completed, the next level of matching begins.

[0074] The fourth stage is behavior-level rule matching. All dimensional information in the feature index structure is retrieved from the behavior-level rule index table to obtain a list of candidate behavior-level rules. The conditions expressed for behavior-level rules are complex and may involve combinations of multi-dimensional conditions; therefore, the matching and verification process requires parsing and calculating the complete condition tree for each rule.

[0075] During the parsing process, each leaf node of the condition tree corresponds to a specific dimension condition. The parser first calculates the condition matching result of each leaf node, and then calculates the final matching result of the entire condition tree based on the combination of logical operators between the leaf nodes.

[0076] Step S303, recursive matching algorithm for condition trees. The calculation of the condition tree is implemented using a recursive algorithm. Taking nodes as input parameters, the calculation process of the algorithm is as follows.

[0077] If the node is a leaf node, the matching result between the dimension condition corresponding to the node and the feature vector is directly calculated, and the calculation result of boolean type is returned.

[0078] If the node is a non-leaf node, the matching results of each child node are first calculated recursively, and then the matching results of each child node are combined according to the logical operator type of the node.

[0079] The logical operator AND uses a short-circuit evaluation strategy: when the matching result of any child node is false, subsequent child nodes are not evaluated and false is returned directly.

[0080] The logical operator OR also employs a short-circuit evaluation strategy: when the matching result of any child node is true, subsequent child nodes are not evaluated, and true is returned directly.

[0081] The combination of the logical operator NOT is a unary operation, which directly negates the matching result of the child node.

[0082] After the behavior-level rules are matched, if a matching behavior-level rule exists, the handling strategy of the highest priority matching rule will be used as the basis for the final control decision; otherwise, the current optimal strategy will be used as the basis for the final control decision. The output of the final control decision includes the handling strategy type, handling strategy parameters, and decision timestamp.

[0083] Step S304: Caching Mechanism. The rule matching engine sets up a caching mechanism to cache the rule matching results of a preset number of times in the cache area. The cache area uses an LRU (Least Recently Used) eviction policy to manage the cache space. When the cache space is insufficient, the least recently used cache entry is automatically evicted.

[0084] A cached entry consists of three parts: a feature vector hash value, a matching result, and a cache timestamp. The feature vector hash value is generated by calculating the feature values ​​of each dimension of the feature vector using a hash function, and is used for fast matching and lookup. The matching result includes the rule identifier that was matched during the rule matching process and the final disposal strategy. The cache timestamp records the creation time of the cached entry and is used for the execution of the LRU eviction policy.

[0085] The cache lookup process is executed before the rule matching phase. First, a feature vector hash value is calculated based on the feature vector to be matched. Then, the cache is searched for a cache entry with the same hash value. If it exists and the cache entry's timestamp is within its validity period, the matching result is directly returned as the final control decision, skipping the subsequent multi-dimensional condition matching algorithm. If it does not exist or the cache entry's timestamp has expired, the multi-dimensional condition matching algorithm continues, and the matching result is written to the cache.

[0086] The effectiveness of caching mechanisms depends on the probability of feature vectors recurring. In real-world applications, the data interaction behavior of electronic terminals exhibits clear regularity and repetitiveness, such as periodic heartbeat detection within the same application and repeated data synchronization operations. Caching mechanisms can reduce the number of repetitive calculations for rule matching, thereby improving the response speed of management and control decisions.

[0087] Step S3 uses a pipelined processing mechanism to convert feature vectors into an index structure, sequentially performing rule matching at four levels: terminal, application, data type, and behavior. A recursive algorithm is used to compute the condition tree, and a caching mechanism is incorporated to improve matching efficiency. This step enables real-time control and decision-making before data interaction, providing a basis for subsequent handling strategies.

[0088] The next step, S4, involves executing control decisions and recording logs. Based on the control decision judgment results, handling strategies such as blocking, allowing, rate limiting, or issuing alarms are implemented for data interaction behaviors, and control decision logs are recorded. The specific implementation is as follows.

[0089] Step S401, blocking handling strategy: When the control decision judgment result is blocking, the control execution module immediately terminates the continued transmission of data interaction behavior.

[0090] For data interaction requests intercepted by the system-level Hook mechanism, the blocking operation is achieved by modifying the return value of the system-level Hook function to inform the upper-layer application that the network connection has failed.

[0091] For data exchange requests intercepted by the kernel-level monitoring mechanism, the blocking operation is achieved by dropping data packets in the kernel network protocol stack.

[0092] For TCP protocol data exchange behavior, blocking operations also include sending TCP reset messages to force the connection to close.

[0093] For UDP protocol data exchange, blocking operations directly discard subsequent related data packets.

[0094] Step S402, Release and Handling Strategy: When the control decision is to release, the control execution module allows data interaction to continue to be transmitted according to the normal process without any intervention.

[0095] The specific implementation of the allow operation is to restore the original function of the system-level hook function, or to skip the packet handling process in the kernel-level monitoring module.

[0096] For scenarios that require recording audit logs, the control execution module writes audit information of data interaction behavior into the log buffer while performing the release operation.

[0097] Step S403, Rate Limiting Strategy: When the control decision determines that the data transmission rate is limited, the control execution module restricts the data transmission rate of data interaction behavior according to a preset rate limiting threshold. The rate limiting threshold is configured in bytes per second, and different rate limiting thresholds can be configured for different data types or different applications.

[0098] The rate limiting algorithm is implemented using the token bucket algorithm. The core idea of ​​the token bucket algorithm is: add tokens to the token bucket at a constant rate, and the token bucket has a limited capacity; when a data packet needs to be sent, it needs to obtain the corresponding number of tokens from the token bucket, and if the number of tokens is insufficient, the data packet needs to wait.

[0099] The token bucket algorithm's parameters include the token generation rate and the token bucket capacity. The token generation rate corresponds to the rate limiting threshold; for example, when the rate limiting threshold is 1MB / s, the token generation rate is 1,048,576 tokens per second. The token bucket capacity determines the tolerance for burst traffic; the larger the capacity, the greater the burst traffic it can tolerate. By default, the token bucket capacity is set to twice the rate limiting threshold, meaning it can tolerate a 2-second burst of traffic.

[0100] During the rate limiting process, the control and execution module monitors the actual data transmission rate in real time and ensures that the actual transmission rate does not exceed the corresponding rate limiting threshold by adjusting the token consumption rate and token replenishment strategy.

[0101] Step S404, Alarm Handling Strategy: When the control decision determines an alarm, the control execution module generates an alarm event and reports it to the control backend. The alarm event includes the alarm type, alarm level, alarm time, associated data interaction behavior characteristics, and alarm description information.

[0102] The alarm levels are determined based on the urgency of the alarm event. The alarm levels include four levels: alert, warning, serious, and urgent.

[0103] Alarm reporting can be done in two modes: real-time push and batch reporting. Real-time push mode reports alarm events immediately after they occur; batch reporting mode stores alarm events in a local buffer and reports them all at once when the buffer is full or the reporting cycle is reached.

[0104] Step S405: Record the control decision log. The content of the control decision log includes the multi-dimensional behavioral feature vector of the data interaction behavior, the control rule information of the matching hit, the specific handling strategy executed, and the processing timestamp of the data interaction behavior.

[0105] Log data is stored in an encrypted manner, using the AES-256 symmetric encryption algorithm to encrypt the log content. The encryption key is managed centrally by the control backend.

[0106] Log data supports query, statistics, and tracing functions. The query function supports combined queries based on conditions such as time range, data type, application name, and handling strategy type; the statistics function supports aggregated analysis of log data to generate statistical reports on data interaction behavior and reports on the implementation effect of control strategies; the tracing function supports tracing the complete processing process of data interaction behavior based on the unique identifier of the data interaction behavior.

[0107] The data structure of log data is defined as follows. Log records include a log number field, a timestamp field, a feature vector field, a rule matching result field, a handling strategy field, and a signature field.

[0108] The log number field is a globally unique, ordered, and incrementing number used for indexing and sorting log records.

[0109] The timestamp field records the creation time of the log record, accurate to the millisecond level.

[0110] The feature vector field stores multidimensional behavioral feature vectors of data interaction behavior in JSON format.

[0111] The rule matching result field stores the matched rule information and matching process information in JSON format.

[0112] The disposal strategy field records the type of disposal strategy and strategy parameters to be executed.

[0113] The signature field uses a digital signature algorithm to sign the contents of the log record, which is used for integrity verification and non-repudiation verification of log data.

[0114] Based on the control decision results, this step implements four handling strategies: blocking, allowing passage, speed limiting, and alarming, and provides specific implementation methods for each strategy; at the same time, it records a complete control decision log, which supports encrypted storage, querying, statistics, and traceability, providing data support for subsequent auditing and analysis.

[0115] Finally, in step S5, a hot update interface for management rules is provided, establishing an incremental rule distribution protocol and a rule version control mechanism. This supports dynamic updates to the rule base without restarting the service, enabling real-time adjustments and immediate effects of management policies. The specific implementation is as follows.

[0116] Step S501, Incremental Rule Distribution Protocol: The incremental rule distribution protocol adopts a differential update mechanism. The rule update request only carries the difference data for added, modified, and deleted rules, not the complete rule base data.

[0117] The format of the difference data is defined as follows. A rule update request includes a request type field, a target version number field, a rule difference list field, and a validation field.

[0118] The request type field identifies the type of this update request, which includes two types: full update and incremental update.

[0119] The target version number field identifies the rule base version number after this update.

[0120] The rule difference list field contains several rule difference items. Each rule difference item contains an operation type field and a rule content field. The operation type field identifies the operation type of the rule difference item, which includes three types: add, modify, and delete.

[0121] The incremental update workflow is as follows: When the management backend detects that the rule base needs to be updated, it first compares the differences between the current version number and the target version number to determine the rules that need to be added, modified, or deleted. Then, it generates a rule difference list and sends only the rule data with the differences to the electronic terminal. After receiving the rule update request, the electronic terminal parses the rule difference list and performs the add, modify, or delete operations according to the operation type of the difference item. After the operation is completed, the electronic terminal updates the version number of its local rule base and sends an update confirmation message to the management backend.

[0122] The differential update mechanism reduces the network bandwidth and transmission time required for rule distribution while ensuring the real-time nature of rule updates.

[0123] Step S502: Rule version control mechanism. This mechanism assigns a globally unique version number to each rule change. The version number is a 64-bit unsigned integer, generated sequentially according to the rule change time. Version number allocation is centrally managed by the control backend to ensure the uniqueness and incrementing nature of version numbers globally.

[0124] The core of the rule version control mechanism is to ensure the atomicity and consistency of rule base updates, and to avoid control failures caused by inconsistent rule states during the update process.

[0125] Step S503, Two-phase commit protocol. The two-phase commit protocol is used to ensure the atomicity and consistency of rule base updates. The detailed process of the protocol is as follows.

[0126] The first stage is the pre-submission stage. The management backend sends the new version of the rule data to the electronic terminal. After receiving it, the electronic terminal first writes the new version of the rule data into the pre-loading area. At this time, the electronic terminal maintains two sets of rule data simultaneously: the currently effective version and the pre-loaded version. Then, the electronic terminal enters the trial operation state.

[0127] During the trial operation, the new version of the rule data only applies to specific test traffic and is used to verify the correctness of the new version of the rules. After the trial operation verification is successful, the electronic terminal sends a pre-submission confirmation message to the management and control backend. If the trial operation verification fails, or if the electronic terminal does not receive further instructions from the management and control backend within a preset time, the electronic terminal automatically rolls back to the previous version and deletes the new version of the rule data in the pre-loaded area.

[0128] The second stage is the formal submission stage. After receiving the pre-submission confirmation message from the electronic terminal, the management backend sends a formal submission instruction to the electronic terminal. Upon receiving the formal submission instruction, the electronic terminal switches the new version rule data in the pre-loaded area to the currently effective version and updates the version number identifier.

[0129] After the switch is complete, delete the old version rule data in the preloaded area to free up storage space. Finally, the electronic terminal sends a submission completion message to the management backend. If an exception occurs during the second phase of execution, causing the submission to fail, the electronic terminal immediately rolls back to the previous version, restores the old version rule data in the preloaded area as the current effective version, and sends a rollback notification message to the management backend.

[0130] Step S504, Hot Update API Interface: The hot update interface provides a RESTful API call interface, supporting operations such as rule query, rule addition, rule modification, rule deletion, and version query.

[0131] The rule query interface returns a list of rules that match the specified conditions, and supports pagination and condition filtering.

[0132] The rule addition interface receives JSON data containing the rule content, performs validity checks, writes it to the rule library, and assigns a rule identifier.

[0133] The rule modification interface receives JSON data containing the rule identifier and rule content, performs a validity check, and then updates the corresponding rule content.

[0134] The rule deletion interface receives a list of rule identifiers, performs the deletion operation, and returns the deletion result.

[0135] The version query interface returns the version number and release time of the current rule base.

[0136] In summary, step S5 reduces the amount of data transmitted through an incremental rule distribution protocol, ensures the atomicity and consistency of rule updates by utilizing version control mechanisms and two-phase commit protocols, and provides a RESTful API interface to enable hot updates, thereby adjusting management strategies in real time without restarting the service.

[0137] To facilitate understanding, the complete workflow of the method of the present invention will be described in detail below using a specific application scenario as an example.

[0138] The scenario is described as follows: A company needs to manage data interaction on the mobile devices used by its employees. It requires allowing ordinary chat messages from social applications, limiting the transmission rate of images and videos from social applications during working hours, and blocking the transmission of executable files from social applications.

[0139] In this scenario, the rule base configuration is performed first. Configure terminal-level rules to set the default handling policy for all employee terminals within the enterprise to block, ensuring that data interaction without explicit permission is blocked by default. Configure application-level rules to set social applications as an allow policy, overriding the default blocking policy of the terminal-level rules. Configure data type-level rules to set text data types under social applications as an allow policy, inheriting the allow policy of the application-level rules; for image and video data types under social applications, set a rate-limiting policy with a rate-limiting threshold of 512KB / s during working hours, and set a allow policy during non-working hours. Configure behavior-level rules to set blocking policies for data interaction behavior involving the transmission of executable files under social applications, overriding the rate-limiting or allow policy of the data type-level rules.

[0140] After the rule base configuration is completed, when employees use social applications for data interaction, the method of this invention processes the data according to the following process: First, the system-level monitoring mechanism intercepts data interaction requests initiated by social applications and extracts multi-dimensional behavioral feature vectors. The values ​​of each dimension of the feature vector are determined based on the actual data interaction behavior. Then, the rule matching engine parses and matches the feature vectors according to a pipeline processing mechanism, matching rules at each level in the order of terminal level, application level, data type level, and behavior level.

[0141] When an employee sends a regular text chat message, the data type dimension is text. It matches the text type rule in the data type level rules. This rule is configured as the release policy. The rule matching engine outputs the release decision, the control execution module executes the release operation, and the text chat message is sent normally.

[0142] When employees send image files via social media applications during work hours, the data type is "image," the data size is 2MB, the data direction is "upload," and the interaction timestamp is within the work time window. First, the system matches behavior-level rules, but no matching rules for image file transmission are found. Then, it matches data type-level rules. The image type rule is configured with a rate-limiting policy within the work time window, and a match is found. The rule matching engine outputs a rate-limiting decision, setting the rate-limiting threshold to 512KB / s. The management execution module then executes the rate-limiting operation, using a token bucket algorithm to restrict the image file transmission rate to below 512KB / s.

[0143] When an employee sends an executable file via a social application during work hours, the data type is binary stream and the file extension is .exe. First, a behavior-level rule is matched. Rules for binary stream data types with executable file extensions are configured as blocking policies. If a match is successful, the rule matching engine outputs a blocking decision, and the management execution module executes the blocking operation, terminating the transmission of the executable file.

[0144] Through the description of the specific application scenarios above, it can be understood how the method of the present invention achieves fine-grained hierarchical control over terminal data interaction behavior by extracting multi-dimensional features of data interaction behavior, configuring hierarchical rule bases, matching rules in real time, and executing differentiated handling strategies.

[0145] On the other hand, the electronic terminal control system based on data interaction proposed in this invention includes: The feature extraction module is used to intercept data interaction requests initiated by electronic terminals, parse and extract data type dimension features, data direction dimension features, data size dimension features, interaction target address dimension features, and interaction timestamp dimension features from the original network data packets, and construct a multi-dimensional behavioral feature vector based on the extracted five dimension features. The hierarchical management rule base storage module is used to store a multi-dimensional hierarchical management rule base. The multi-dimensional hierarchical management rule base uses a tree-like hierarchical structure to store rule data. The tree-like hierarchical structure includes terminal-level rules, application-level rules, data type-level rules, and behavior-level rules. The real-time data interaction behavior analysis and rule matching engine is used to perform multi-dimensional condition matching between multi-dimensional behavior feature vectors and rules in the multi-dimensional hierarchical management rule base before the execution of data interaction behavior, and output management decision judgment results based on the matching results. The control and execution module is used to implement blocking, allowing, rate limiting, or alarm handling strategies for data interaction based on the control and decision-making results.

[0146] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0147] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for managing electronic terminals based on data interaction, characterized in that, Includes the following steps: Intercept data interaction requests initiated by electronic terminals, parse and extract data type dimension features, data direction dimension features, data size dimension features, interaction target address dimension features, and interaction timestamp dimension features from the original network data packets, and construct a multi-dimensional behavioral feature vector based on the extracted five dimension features; A multi-dimensional hierarchical management rule base is constructed. The multi-dimensional hierarchical management rule base stores rule data in a tree-like hierarchical structure. The tree-like hierarchical structure includes terminal-level rules, application-level rules, data type-level rules, and behavior-level rules. The terminal-level rules are used to define the overall management strategy for a specific electronic terminal. The application-level rules are used to define the management strategy for a specific application. The data type-level rules are used to define the management strategy for interaction behavior of a specific data type. The behavior-level rules are used to define the refined management strategy for data interaction behavior that meets a specific combination of multi-dimensional conditions. Before the data interaction behavior is executed, the multi-dimensional behavior feature vector is matched with the rules in the multi-dimensional hierarchical control rule base in a multi-dimensional condition, and the control decision judgment result is output based on the matching result. Based on the control decision judgment results, the data interaction behavior is handled by blocking, allowing, limiting or alarming strategies.

2. The electronic terminal control method based on data interaction according to claim 1, characterized in that, The multidimensional behavioral feature vector is matched with the rules in the multidimensional hierarchical management rule base using multidimensional conditions, specifically including: The matching process is executed using a pipelined processing mechanism, which includes a feature parsing stage and a rule matching stage. In the feature parsing stage, the multidimensional behavioral feature vector is converted into a feature index structure that can be recognized by the real-time data interaction behavior parsing and rule matching engine. According to the numerical type and distribution range of each dimension feature, the original values ​​of each dimension are mapped to the index key values ​​in the feature index structure. During the rule matching stage, based on the feature index structure, multi-dimensional condition retrieval is performed layer by layer from top to bottom in the multi-dimensional hierarchical management rule base according to the hierarchical order of terminal-level rules, application-level rules, data type-level rules, and behavior-level rules.

3. The electronic terminal control method based on data interaction according to claim 1, characterized in that, The method also includes a hot update step for control rules: An incremental rule distribution protocol is established, which adopts a differential update mechanism. The rule update request only carries the difference data of adding, modifying and deleting rules, and does not carry the complete rule base data. Establish a rule version control mechanism to assign a globally unique version number to each rule change. The version number is generated in ascending order according to the time sequence of the rule change and is managed uniformly by the management and control backend. A two-phase commit protocol is adopted to ensure the atomicity and consistency of rule base updates. The two-phase commit protocol includes a pre-commit phase and a formal commit phase. During the pre-submission phase, the management and control backend sends the new version rule data to the electronic terminal. The electronic terminal writes the new version rule data into the pre-loading area, maintains two sets of rule data, namely the currently effective version and the pre-loaded version, and enters the trial operation state. After the trial operation verification is successful, it sends a pre-submission confirmation message to the management and control backend. During the formal submission phase, after receiving the pre-submission confirmation message, the management backend sends a formal submission instruction to the electronic terminal. The electronic terminal switches the new version rule data in the pre-loaded area to the currently effective version and updates the version number identifier.

4. The electronic terminal control method based on data interaction according to claim 1, characterized in that, The rule condition fields of behavior-level rules are expressed in a structured condition tree form. Each condition tree consists of a root condition and multiple child condition nodes, which are connected by logical operators AND, OR, or NOT. During the behavior-level rule matching process, a recursive algorithm is used to calculate the condition tree, with nodes as input parameters. When a node is a leaf node, the matching result between the dimensional condition corresponding to the node and the multidimensional behavior feature vector is directly calculated, and a Boolean calculation result is returned. When a node is not a leaf node, the matching results of each child node are recursively calculated. The matching results of each child node are combined according to the logical operator type corresponding to the node. For the combination operation of the logical operator AND, a short-circuit evaluation strategy is adopted. When the matching result of any child node is false, the subsequent child nodes are not calculated and the value is returned as false. For the combination operation of the logical operator OR, a short-circuit evaluation strategy is adopted. When the matching result of any child node is true, the subsequent child nodes are not calculated and the value is returned as true.

5. The electronic terminal control method based on data interaction according to claim 1, characterized in that, The multi-dimensional hierarchical management rule base uses an inverted index structure to store rule conditions. Index tables are built according to data type dimension, data direction dimension, data size range, and time window dimension. The key of each index table is the feature value of the dimension, and the value is a list of rules that match the feature value. The real-time parsing and rule matching engine for data interaction behavior is set up with a caching mechanism to cache the rule matching results of a preset number of times to a high-speed cache. The high-speed cache adopts a least recently used eviction policy to manage the cache space. The cache entry consists of three parts: feature vector hash value, matching result, and cache timestamp. The feature vector hash value is generated by calculating the feature values ​​of each dimension of the multi-dimensional behavior feature vector through a hash function.

6. The electronic terminal control method based on data interaction according to claim 1, characterized in that, Based on the aforementioned control decision judgment results, a rate-limiting strategy is implemented for data interaction behavior, specifically including: The token bucket algorithm is used to limit the data transmission rate of data interaction behavior. The parameters of the token bucket algorithm include the token generation rate and the token bucket capacity. The token generation rate corresponds to the rate limiting threshold, and the token bucket capacity is set to twice the rate limiting threshold. During the rate limiting process, the control and execution module monitors the actual data transmission rate in real time and ensures that the actual transmission rate does not exceed the corresponding rate limit threshold by adjusting the token consumption rate and token replenishment strategy.

7. The electronic terminal control method based on data interaction according to claim 1, characterized in that, The method also includes the step of recording control decision logs: Record multidimensional behavioral feature vectors of data interaction behaviors, matching control rule information, executed handling strategy types, and processing timestamps of data interaction behaviors; Log data is encrypted and stored using the AES-256 symmetric encryption algorithm, and the content of the log records is signed using a digital signature algorithm for integrity verification and non-repudiation verification of log data. The log data supports combined queries based on time range, data type, application name, and handling strategy type. It also supports aggregated analysis of log data to generate statistical reports on data interaction behavior and allows tracing the complete processing of data interaction behavior based on its unique identifier.

8. The electronic terminal control method based on data interaction according to claim 1, characterized in that, Intercepting data interaction requests initiated by electronic terminals is achieved through system-level Hook mechanisms or kernel-level monitoring mechanisms. The system-level Hook mechanism is implemented by overloading the system call functions of the operating system's network interface layer. These system call functions include the network sending function sendto, the network receiving function recvfrom, the socket sending function send, and the socket receiving function recv. The kernel-level monitoring mechanism embeds a dedicated monitoring module between the data link layer and the network layer of the kernel network protocol stack. The embedding point of the monitoring module is selected between the receive function of the kernel network driver and the upper-layer protocol processing function.

9. The electronic terminal control method based on data interaction according to claim 1, characterized in that, Parsing and extracting data size dimension features from raw network packets, specifically: The total amount of data involved in a single data interaction is recorded in bytes. The payload length of all related data packets of the same data session within a specific time window is accumulated. When the time interval between a new data packet and the data packets of an existing session exceeds the time window threshold, it is determined to be a new data session. The default value of the time window is 5 seconds. The extraction of interaction timestamp dimension features specifically involves: recording the precise time when data interaction occurs, using Coordinated Universal Time (UTC) format, accurate to the millisecond level, and recording the time period classification of data interaction behavior within a day, in order to support the matching of control rules based on time windows.

10. An electronic terminal control system based on data interaction, applied to the method described in any one of claims 1-9, characterized in that, include: The feature extraction module is used to intercept data interaction requests initiated by electronic terminals, parse and extract data type dimension features, data direction dimension features, data size dimension features, interaction target address dimension features, and interaction timestamp dimension features from the original network data packets, and construct a multi-dimensional behavioral feature vector based on the extracted five dimension features. The hierarchical management rule base storage module is used to store a multi-dimensional hierarchical management rule base. The multi-dimensional hierarchical management rule base uses a tree-like hierarchical structure to store rule data. The tree-like hierarchical structure includes terminal-level rules, application-level rules, data type-level rules, and behavior-level rules. The real-time data interaction behavior analysis and rule matching engine is used to perform multi-dimensional condition matching between the multi-dimensional behavior feature vector and the rules in the multi-dimensional hierarchical control rule base before the data interaction behavior is executed, and output the control decision judgment result based on the matching result. The control and execution module is used to execute blocking, allowing, rate limiting, or alarm handling strategies on data interaction behaviors based on the control and decision judgment results.

Images