Method and device for protecting privileged operation of terminal equipment

Abstract

The invention discloses a method and a device for protecting privileged operation of terminal equipment. The method comprises the following steps: monitoring a privileged operation event based on a security agent program deployed on the terminal equipment; acquiring a feature parameter set of the privileged operation event; sending the feature parameter set to a verification server, and receiving a verification token which is generated by the verification server and is dynamically bound with the feature parameter set; receiving an input verification code through the security agent program, and verifying whether the input verification code is matched with a verification token returned by the verification server; if verification is matched, operation corresponding to the privileged operation event is allowed to be executed, and if verification fails, execution of the privileged operation event is blocked. An accurate verification token is generated by dynamically binding an operation context (file hash, a process identifier and an operation source terminal equipment network address), and a network layer firewall tool is linked to realize full-link real-time interception, so that the problems of token replay risk, underlying operation protection deficiency and verification and execution decoupling in a traditional scheme are thoroughly solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of terminal security protection, and in particular to a terminal device privilege operation protection method and device. BACKGROUND

[0002] With the acceleration of enterprise digital transformation process, terminal devices have become the key nodes for storing and processing core business data. However, terminal privilege operations (such as system file deletion, permission modification, and high-risk command execution) are facing increasingly severe security challenges. Traditional static verification mechanisms (including fixed passwords, biometric identification, etc.) have significant vulnerabilities: attackers can fake biometric features through AI face-swapping technology, or steal credentials through phishing attacks, causing the verification link to be easily bypassed. More seriously, solutions that rely on front-end behavior analysis (such as collecting mouse tracks and click rhythms) can only intercept application layer requests and cannot prevent bottom-layer operations initiated through SSH, RDP, and other protocols, forming a huge security blind spot.

[0003] Dynamic token technology has improved the verification strength to some extent, but it still has inherent flaws. The mainstream solution only relies on time factors or device fingerprints to generate tokens, without deep binding with operation context information. This results in hijacked tokens being reused by attackers for sensitive operations on other terminals, causing cross-domain security risks.

[0004] Existing technologies also face the sharp contradiction between compliance and efficiency. Current regulations require fine-grained auditing and real-time interception of privilege operations, but traditional solutions are difficult to reconcile: static verification cannot cover interfaceless script operations, and decoupling of front-end behavior analysis and bottom-layer execution leads to the fatal flaw of "passing verification but still performing high-risk operations". For example, relying on dynamic interference images and behavior trajectory analysis still cannot intercept SSH command-line attacks; although the zero-trust architecture achieves continuous verification, the average 500ms delay caused by the complexity of the policy engine makes it difficult to meet the needs of millisecond-level response scenarios in industrial control. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a terminal device privilege operation protection method and device, which generates accurate verification tokens by dynamically binding operation context (file hash, process identifier, operation source terminal device network address), and realizes real-time interception of the whole link by linking with the network layer firewall tool, completely solving the token replay risk, bottom-layer operation protection deficiency, and decoupling of verification and execution in traditional solutions.

[0006] To solve the above technical problems, the first aspect of the embodiments of the present application provides a terminal device privilege operation protection method, comprising the following steps:

[0007] S100, monitoring a privileged operation event based on a security agent deployed on a terminal device, the privileged operation event comprising: deleting a file or executing a predefined high-risk command;

[0008] S200, obtaining a feature parameter set of the privileged operation event, the feature parameter set comprising at least: a cryptographic hash value of a target file, an operating system identifier of a triggering process, and a network address of a privileged operation source device;

[0009] S300, sending the feature parameter set to a verification server and receiving a verification token generated by the verification server and dynamically bound to the feature parameter set;

[0010] S400, receiving an input verification code through the security agent and verifying whether the input verification code matches the verification token returned by the verification server;

[0011] S500, if the verification matches, allowing execution of an operation corresponding to the privileged operation event, and if the verification fails, blocking execution of the privileged operation event.

[0012] Further, the monitoring of the privileged operation event based on the security agent deployed on the terminal device in S100 comprises:

[0013] S110, registering an event listener to a system audit interface of an operating system through the security agent, so that the system audit interface pushes file system operation requests and command line process execution requests to the event listener in real time;

[0014] S120, receiving operation request data streams through the event listener and matching operation behaviors in the operation request data streams based on a predefined high-risk operation rule library;

[0015] S130, when a file deletion command or a high-risk command execution behavior is matched, generating a privileged operation event identifier containing a timestamp.

[0016] Further, the sending of the feature parameter set to the verification server and the receiving of the verification token generated by the verification server and dynamically bound to the feature parameter set in S300 comprises:

[0017] S310, sending the feature parameter set to the verification server after encryption through the security agent;

[0018] S320, triggering the verification server to perform a cryptographic generation operation of a dynamically bound token based on the cryptographic hash value of the target file, the operating system identifier of the triggering process, and the network address of the privileged operation source device in the feature parameter set;

[0019] S330, receiving, by the security agent, the verification token returned by the verification server, the verification token being an output result of the cryptographic generation operation.

[0020] Further, the cryptographic generation operation of the dynamic binding token in S320 comprises:

[0021] S321, the verification server concatenates, in a preset order, the target file cryptographic hash value in the feature parameter set, the trigger process operating system identifier, the privileged operation source device network address, and the current system time stamp and the cryptographic secure random number to form an input sequence;

[0022] S322, the verification server performs a key-based hash message authentication code operation on the input sequence to generate a fixed-length digest value;

[0023] S323, the verification server converts the digest value into a decimal number sequence, and takes the last 6 digits as the dynamic binding token.

[0024] Further, the operation corresponding to the privileged operation event is allowed to be executed if the verification matches, and the execution of the privileged operation event is blocked if the verification fails in S500, comprising:

[0025] S510, after the privileged operation event is triggered and before the dynamic verification is completed, the security agent dynamically adds a default blocking rule through the network layer firewall tool of the operating system to block the access of the privileged operation source device network address in the feature parameter set to the preset high-risk port, wherein the preset high-risk port is associated with the protocol type of the privileged operation event;

[0026] S520, when the input verification code matches the verification token, the security agent dynamically adds a temporary release rule to the network layer firewall tool, and after the temporary release rule takes effect, the operation corresponding to the privileged operation event is executed through the local system permission;

[0027] S530, when the verification fails or times out without verification, the security agent maintains or updates the network layer firewall tool rule to continuously block the access of the privileged operation source device network address to the preset high-risk port.

[0028] Further, the temporary release rule binds the privileged operation source device network address in the feature parameter set as the release object;

[0029] The temporary release rule binds the preset high-risk port associated with the privileged operation event as the release port;

[0030] The temporary release rule sets a first time limit window as a valid period of performing the privileged operation event according to a preset strategy.

[0031] Further, after the security agent dynamically adds the temporary release rule to the network layer firewall tool in S520, the method further includes:

[0032] After the privileged operation is performed or the valid period of the temporary release rule ends, the security agent deletes the default interception rule through the network layer firewall tool.

[0033] Further, the terminal device privileged operation protection method further includes:

[0034] S610: When the verification server continuously receives a plurality of privileged operation requests sent by the security agent from a pre-defined IP address pool within a preset time window, and all the privileged operation requests meet a preset aggregation condition;

[0035] S620: The verification server generates a single aggregation token dynamically bound to a target file cryptographic hash value and the pre-defined IP address pool, and sets a second time limit window;

[0036] S630: After the security agent receives the single aggregation token, the security agent dynamically adds a centralized release rule to the network layer firewall tool;

[0037] S640: Within the second time limit window corresponding to the centralized release rule, when any of the privileged operation source devices in the pre-defined IP address pool initiates the same operation, the security agent directly releases the operation execution.

[0038] Further, the preset aggregation condition includes that the cryptographic hash values of the target files in all the feature parameter sets are the same, all the operation type identifiers are consistent, and the IP addresses of the privileged operation source devices initiating the request belong to the same pre-defined IP address pool.

[0039] The centralized release rule includes that the release object is all network addresses of the pre-defined IP address pool, the release port is a preset high-risk port associated with the current privileged operation event, and the valid period is synchronized with the second time limit window.

[0040] Correspondingly, a second aspect of an embodiment of the application provides a terminal device privileged operation protection device for protecting the privileged operation of a terminal device based on the terminal device privileged operation protection method, and the device includes:

[0041] An event monitoring module is configured to monitor a privileged operation event based on a security agent deployed on a terminal device, and the privileged operation event includes deleting a file or executing a pre-defined high-risk command.

[0042] a parameter acquisition module configured to acquire a feature parameter set of the privileged operation event, the feature parameter set comprising at least a cryptographic hash value of a target file, an operating system identifier of a triggering process, and a network address of a privileged operation source device;

[0043] a data exchange module configured to send the feature parameter set to a verification server and receive a verification token generated by the verification server and dynamically bound to the feature parameter set;

[0044] a token verification module configured to receive an input verification code through the security agent and verify whether the input verification code matches the verification token returned by the verification server;

[0045] a policy execution module configured to allow execution of an operation corresponding to the privileged operation event if the verification is successful, and block execution of the privileged operation event if the verification fails.

[0046] Correspondingly, a third aspect of the embodiment of the present application provides an electronic device, comprising at least one processor and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the terminal device privileged operation protection method.

[0047] Correspondingly, a fourth aspect of the embodiment of the present application provides a computer readable storage medium having computer instructions stored thereon, and the instructions are executed by a processor to implement the terminal device privileged operation protection method.

[0048] The above technical solutions of the embodiment of the present application have the following beneficial technical effects:

[0049] 1. By dynamically binding the verification token with the operation context (file hash, process PID, operation source terminal device IP), the generalization risk of the traditional dynamic token is completely solved; the attacker cannot initiate a cross-terminal attack by forging or reusing the token, the success rate of the replay attack is reduced from an industry average of >10% to <0.01%, and the interception success rate is improved by 300% compared with the previous front-end behavior analysis scheme, meeting the compliance requirements of regulations on privileged operation audit;

[0050] 2. Using iptables to directly control the traffic permissions at the network layer, a millisecond-level response of "verification failure to block" is realized; the rule takes effect in <5ms, which is two orders of magnitude higher than the average delay of 500ms of the zero trust architecture, and the terminal Agent memory occupancy is <50MB, supporting large-scale deployment of thousands of servers, and perfectly adapting to low-latency scenarios such as industrial control;

[0051] 3. When multiple legitimate users initiate operations on the same target file, a single aggregated token is generated by binding the file hash with the team IP pool, reducing the verification trigger frequency by 60%; within the time window (such as 5 minutes), pre-defined IP pool members perform the same operation without repeated verification, while the authority range is constrained by the file hash and IP pool, balancing efficiency and security. BRIEF DESCRIPTION OF DRAWINGS

[0052] Figure 1 is a terminal device privilege operation protection method flowchart provided by the embodiment of the present application;

[0053] Figure 2 is a system architecture schematic diagram provided by the embodiment of the present application;

[0054] Figure 3 is a privilege operation interception flowchart provided by the embodiment of the present application;

[0055] Figure 4 is a terminal device privilege operation protection device module block diagram provided by the embodiment of the present application.

[0056] Reference signs:

[0057] 1, event monitoring module, 2, parameter acquisition module, 3, data exchange module, 4, token verification module, 5, policy execution module. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical scheme and advantages of the present application clearer and more intelligible, the present application will be further described in detail below in conjunction with specific embodiments and with reference to the drawings. It should be understood that these descriptions are only exemplary and are not intended to limit the scope of the present application. In addition, in the following description, the description of known structures and technologies is omitted to avoid unnecessary confusion of the concept of the present application.

[0059] Please refer to Figure 1 , Figure 3 and Figure 3 , the first aspect of the embodiment of the present application provides a terminal device privilege operation protection method, comprising the following steps:

[0060] S100, based on the security agent program deployed in the terminal device, monitoring the privilege operation event, the privilege operation event including: deleting a file or executing a pre-defined high-risk command.

[0061] The security agent program captures the privileged operation behavior in real time through the deep integration of the terminal device's operating system kernel monitoring capability. Specifically, when a user or process attempts to execute a predefined high-risk command (such as rm-rf system file deletion operation), the agent program uses the Linux Auditd framework or Windows ETW event tracking technology to intercept the operation request at the system call level. This process does not rely on application layer logs, but directly hooks the file system driver and process management module, ensuring that interfaceless script operations (such as SSH command line attacks) can also be accurately identified, addressing the defect that traditional front-end behavior analysis solutions cannot cover the underlying operations.

[0062] S200, a set of feature parameters of a privileged operation event is obtained, and the set of feature parameters at least includes: a cryptographic hash value of a target file, an operating system identifier of a triggering process, and a network address of a privileged operation source device.

[0063] The construction of the set of feature parameters focuses on operation uniqueness and unforgeability: the cryptographic hash value (such as SHA-256) of the target file ensures that the operation object cannot be tampered with; the operating system identifier (such as PID) of the triggering process prevents malicious processes from disguising as legitimate processes; and the network address (such as bastion host IP) of the privileged operation source device binds the operation initiation source. This three-tuple forms a dynamic context fingerprint, which generates a unique operation identifier through a cryptographic algorithm. For example, when deleting the / etc / nginx.conf file, the agent program calculates the file content hash value in real time, combines the SSH connection process PID and source IP address, and constructs an operation credential substrate that cannot be copied, completely avoiding the generalization risk of static tokens.

[0064] S300, the set of feature parameters is sent to a verification server, and a verification token dynamically bound with the set of feature parameters generated by the verification server is received.

[0065] After the verification server receives the encrypted set of feature parameters, it performs multi-factor dynamic binding operations: concatenates the file hash value, process PID, source device IP, current timestamp, and cryptographic security random salt value in a predetermined order to form an input sequence; performs HMAC-SHA256 key-based hash operation on the sequence to generate a 256-bit digest value; and takes the last 6 decimal numbers as the verification token. This design strongly couples the token with a specific file, a specific device, a specific process, and a time window, so that even if an attacker steals a single parameter, he cannot forge a valid token (replay success rate <0.01%), meeting the identity binding requirements of relevant industry regulations for sensitive operations.

[0066] S400, the input verification code is received through the security agent program, and it is verified whether the input verification code matches the verification token returned by the verification server.

[0067] The security agent locally triggers an interactive verification interface, and the user needs to input a dynamic token on the bastion host terminal. The agent compares the input value with the verification token issued by the server, rather than relying on network transmission to verify the result. This offline verification mechanism avoids the risk of man-in-the-middle attacks, and prevents remote malicious triggering through source device IP whitelist verification (such as allowing the bastion host IP to pop up). If the verification fails, the network layer interception is activated immediately, and if the verification succeeds, a one-time execution authorization is generated to ensure the closed-loop security control of "human-machine cooperation".

[0068] S500, if the verification matches, the privileged operation event corresponding operation is allowed to be executed, and if the verification fails, the execution of the privileged operation event is blocked.

[0069] The network layer firewall tool (iptables) is used as the final execution gateway. Default interception rules (such as DROP SSH port access) are dynamically added at the beginning of operation triggering, forming a "default denial" security baseline. After verification matching, the agent adds temporary release rules (such as ACCEPT source IP + high-risk port), and the rule takes effect in <5ms. The user can perform privileged operations without feeling. After operation completion or rule timeout (such as 5 minutes), the firewall state is automatically cleaned up. This linkage mechanism realizes full-link control: strong association between front-end verification and bottom-layer execution, solving the traditional vulnerability of "verification passed but operation still blocked", and the interception efficiency is improved by 300%.

[0070] Through dynamic context binding (file hash / process PID / source device IP), an accurate token is generated to eliminate the risk of replay attacks from the root; using network layer rules for real-time linkage (iptables millisecond-level response), SSH / RDP and other underlying protocol operations are completely covered; for team collaboration scenarios, a batch authorization mechanism is innovated (binding file hash and IP pool), reducing 60% verification interference. Finally, the full life cycle protection of terminal privileged operations is realized, meeting the millisecond-level compliance interception needs of industrial control and other scenarios, and the terminal Agent resource occupation is <50MB, supporting the large-scale deployment of thousands of devices.

[0071] Further, the security agent deployed on the terminal device in S100 monitors the privileged operation event, including:

[0072] S110, an event listener is registered to the system audit interface of the operating system through the security agent, so that the system audit interface pushes the file system operation request and command line process execution request to the event listener in real time.

[0073] The security agent actively registers with the system audit interface (such as the audit subsystem of Linux, ETW of Windows) provided by the operating system kernel after the terminal device is started, and becomes a listener of specific system events (file system operation request and command line process execution request). After successful registration, the operating system kernel continuously pushes the relevant operation requests (such as file creation, read, write, and delete requests, and command and parameters of new process creation and execution) captured in the kernel state to the event listener callback function registered by the security agent in the form of event stream in real time and asynchronously; ensures that the security agent can obtain the operation intention data stream of the operating system at the bottom layer without polling and low delay, and provides a basic data source for subsequent real-time analysis.

[0074] In S120, the operation request data stream is received through the event listener, and the operation behavior in the operation request data stream is matched based on a predefined high-risk operation rule library.

[0075] After the event listener receives the operation request data stream pushed by the operating system, the raw data is immediately parsed and standardized. The parsed operation behavior information (such as operation type: file deletion / execution command, target file path, execution command string, and initiating process PID / PPID) is sent to a predefined high-risk operation rule library for real-time matching. The rule library includes accurate or pattern matching rules, such as: accurate matching of specific high-risk command strings (such as rm-rf / ), matching of file deletion operations under specific key paths (such as deletion under / etc / *), and matching of command patterns containing dangerous parameter combinations. The matching process is a quick comparison of each rule, which accurately filters out operation behaviors that meet the preset high-risk characteristics from massive system operations.

[0076] In S130, when a file deletion command or a high-risk command execution behavior is matched, a privilege operation event identifier including a timestamp is generated.

[0077] When the rule matching engine of step S120 identifies that the behavior in the current operation request data stream meets the preset "file deletion command" or "high-risk command execution behavior", the confirmation of the privilege operation event is triggered. The security agent then generates a unique privilege operation event identifier for the identified high-risk operation. The identifier is not only used to uniquely track the event in the subsequent process, but also forcibly embeds an accurate system timestamp (accurate to milliseconds or microseconds). The addition of the timestamp is crucial for subsequent token dynamic binding, verification timeliness control, and security audit tracing, ensuring the non-repudiation and timeliness of the event.

[0078] Through the cooperative execution process of steps S110-S130, active, real-time and accurate monitoring of key operation behaviors at the terminal operating system kernel level is realized. The security agent program uses the system native audit mechanism to non-invasively capture all file system and command execution operations, and through efficient high-risk rule library filtering, only when the preset privilege operation definition (such as deleting key files or executing high-risk commands) is truly met, the subsequent complex verification process is triggered; effectively avoiding the performance overhead of full monitoring, focusing the protection on high-risk operations, providing accurate and timely event trigger sources and key feature parameters for subsequent dynamic token-based two-factor authentication and network layer cooperative protection, thereby building the first active defense barrier for privilege operations at the system bottom layer, significantly improving the protection capability of terminal devices against malicious or misoperation caused key data loss or system damage.

[0079] Further, the sending of the feature parameter set to the verification server and the receiving of the verification token generated by the verification server and dynamically bound to the feature parameter set in S300 include:

[0080] S310, the feature parameter set is encrypted by the security agent program and sent to the verification server.

[0081] After the security agent program obtains the feature parameter set (including target file cryptographic hash value, trigger process operating system identifier, privilege operation source device network address, and other key information) of the privilege operation event in step S200, it does not transmit these sensitive data in plaintext form; but immediately uses the pre-set, high-strength encryption algorithm (such as AES-256 or RSA-OAEP) and the key shared or asymmetrically paired with the verification server to encrypt the feature parameter set, generating an encrypted data packet. This encryption process ensures the confidentiality and integrity of the data during transmission (usually through HTTPS or other secure channels), effectively preventing key feature parameter leakage or tampering caused by network monitoring and man-in-the-middle attacks. Subsequently, the security agent program sends the encrypted data packet to the remote verification server through a secure network connection.

[0082] S320, the verification server performs a cryptographic generation operation of the dynamically bound token based on the target file cryptographic hash value, trigger process operating system identifier, and privilege operation source device network address in the feature parameter set.

[0083] After receiving the encrypted packet from the security agent, the verification server first decrypts it using the corresponding key to restore the original set of feature parameters. Subsequently, the server initiates a dynamic token generation process, extracting the cryptographic hash of the target file (unique identifier for the file being operated on), the operating system identifier of the triggering process (unique identifier for the local process that initiated the operation), and the network address of the privileged operation source device (identifies the source device of the operation request). Based on these core parameters, the verification server inputs a predefined, irreversible cryptographic generation operation. The core purpose of this operation is to dynamically and strongly associate these feature parameters with a token that will be generated. The operation process typically involves a cryptographic hash function (such as HMAC-SHA256) and a key, ensuring that the token cannot be predicted or reverse-derived from the original feature parameters, and that the same input will always produce the same output (within the validity period).

[0084] S330, receiving the verification token returned by the verification server through the security agent, the verification token being the output result of the cryptographic generation operation.

[0085] After completing the cryptographic generation operation, the verification server obtains the output result of the operation. The output result itself or its form after a specific conversion (such as taking a certain number of digits) is defined as the dynamic binding verification token corresponding to this privileged operation event. This token represents the temporary and conditional authorization credential of the verification server for "operation requests carrying a specific set of feature parameters". The verification server returns this verification token to the security agent on the terminal device that initiated the request through a secure channel (the same as the request or independent). The security agent receives and temporarily stores this token, preparing for the subsequent local verification step. The life cycle of the token is usually limited by the time factor built-in when it is generated or the validity period set by the server.

[0086] Steps S310-S330 collectively construct a secure and trusted remote authorization credential generation and delivery mechanism. The encrypted transmission of S310 ensures the security of sensitive feature parameters in the network. The core of S320 is to use cryptographic operations to dynamically and unforgeably bind the core feature parameters (file fingerprint, process ID, source address) representing the uniqueness of this privileged operation to a token. This binding ensures that: 1) the token's exclusivity: the token is only valid for this specific operation, specific file, specific source process and device; 2) the token's timeliness and anti-replay: the operation usually contains time factors (such as timestamp, random number), making the token time-limited and unable to be replayed for other operations; 3) the token's unpredictability: relying on cryptographic algorithms and keys, attackers cannot predict or forge valid tokens. S330 securely returns the generated token to the terminal, providing a dynamic credential from a trusted authority (verification server) that is strongly associated with the context of this operation for the local two-factor verification of S400. This realizes the key link of the "remote authorization required" principle of privileged operations, significantly increasing the difficulty of bypassing the protection mechanism for illegal or malicious operations (such as attackers tampering with files and then deleting them, impersonating legitimate processes or IPs).

[0087] Further, the cryptographic generation operation of S320 to execute the dynamic binding token includes:

[0088] S321, the verification server concatenates the target file cryptographic hash value in the feature parameter set, the trigger process operating system identifier, the privileged operation source device network address, and the current system timestamp, cryptographic secure random number in the preset order to form an input sequence.

[0089] After the verification server decrypts and obtains the feature parameter set, to generate a dynamically bound, anti-replay, and unpredictable dynamic token, it first needs to construct an input sequence containing multi-dimensional information. The server strictly follows the preset and fixed parameter concatenation order (for example: [target file cryptographic hash value]+[trigger process operating system identifier]+[privileged operation source device network address]+[current system timestamp]+[cryptographic secure random number]) to combine these elements into a coherent byte sequence. Among them, the target file cryptographic hash value (such as SHA-256) uniquely identifies the content of the operated file; the trigger process operating system identifier (such as process ID or unique process handle) accurately points to the local process instance that initiates the operation; the privileged operation source device network address (such as IP address) identifies the source device of the operation request; the current system timestamp (accurate to milliseconds / seconds) provides a time-limited reference for the token; and the cryptographic secure random number (generated by the operating system or hardware security module) injects high-strength entropy, ensuring the uniqueness of each operation input. The ordered concatenation ensures the determinism of the input sequence structure, which is the basis for the reproducibility of subsequent cryptographic operations.

[0090] S322, the verification server performs a key-based hash message authentication code operation on the input sequence to generate a fixed-length digest value.

[0091] The constructed input sequence is then sent to a key-based hash message authentication code (HMAC) operation engine. The verification server uses a pre-set, highly confidential key (which is only held by the server and stored securely) as the key input for the HMAC operation. The core principle of the HMAC algorithm (such as HMAC-SHA256) is to use a cryptographic hash function (such as SHA-256) to perform multiple rounds of confusion and diffusion processing on the input sequence under the control of the key. This operation process is one-way and irreversible, and any slight change in the input will cause a huge and unpredictable change in the output (avalanche effect). The operation finally outputs a fixed-length, unique binary digest value (e.g. 256 bits). This digest value represents a strong binding of the key and the entire input sequence: only with the same key and exactly the same input sequence can the digest value be reproduced, ensuring the strict dynamic binding of the token to the feature parameter set, timestamp, and random number.

[0092] S323, the verification server converts the digest value to a decimal number sequence and takes the last 6 digits as the dynamic binding token.

[0093] The fixed-length digest value generated by the HMAC operation (usually in binary format) needs to be converted into a token form that is convenient for manual input or terminal processing. The verification server first treats this binary digest value as a very large integer as a whole and converts it into a decimal number sequence (string). Since the decimal sequence is usually long (e.g. the decimal number corresponding to a 256-bit digest has about 78 digits), in order to be user-friendly and convenient for input, the server uses the strategy of taking a certain number of consecutive bits (e.g. 6 bits) at the end of the long sequence to form the final dynamic binding token (such as "824715"). By choosing to take the last bits instead of the first bits, the uniform distribution characteristic of the HMAC output is utilized, making any consecutive bit segment highly random and unpredictable. The 6-digit decimal token is the credential that the user needs to input or the system needs to automatically verify.

[0094] Steps S321-S323 jointly define a highly secure, dynamic binding token generation algorithm. In S321, the operating core features (files, processes, source addresses), precise time stamps, and high-entropy random numbers are spliced in a fixed order to bind the token with the operating context, time effectiveness, and uniqueness. In S322, the HMAC operation (key + hash function) is used to perform cryptographic processing on the input sequence, and the generated digest value has key dependency, collision resistance, one-wayness, and input sensitivity, ensuring that the token cannot be forged, predicted, or tampered with, and is strictly bound to all input elements of the specific operation. In S323, the digest value is converted into a short digital token (e.g., 6 digits) for easy use, ensuring sufficient security strength (due to high-strength digest) while considering user experience and input efficiency, making the generated verification token a one-time use, time-limited effective, and deeply bound to the specific operation context (files, processes, devices, time) strong authentication credential, providing a solid and reliable basis for the subsequent local verification in step S400, effectively resisting token guessing, replay attacks, man-in-the-middle attacks, and fake legitimate operation threats.

[0095] Further, if the verification matches in S500, the privileged operation event corresponding operation is allowed to be executed, and if the verification fails, the execution of the privileged operation event is blocked, including:

[0096] In S510, after the privileged operation event is triggered and before the dynamic verification is completed, the security agent program dynamically adds a default interception rule through the network layer firewall tool of the operating system to block the access of the privileged operation source device network address in the feature parameter set to the preset high-risk port, wherein the preset high-risk port is associated and bound with the protocol type of the privileged operation event.

[0097] After the security agent monitors a privileged operation event (such as a high-risk file deletion or command execution) and generates an event identification in step S100, it realizes that the event needs to be dynamically verified before it can be finally executed. In order to actively prevent possible malicious operations from causing damage before the verification is completed (for example, an attacker tries to immediately execute a high-risk operation using compromised credentials or vulnerabilities), the security agent immediately takes network layer blocking measures, calls the programming interface of the operating system's native network layer firewall tool (such as iptables / nftables for Linux and WFAS for Windows), and dynamically adds a default blocking rule. The core content of this rule is: block all access to a set of pre-set high-risk ports by the privileged operation source device network address (i.e. the IP address of the device initiating the operation request) identified in the feature parameter set. These high-risk ports are pre-associated according to the protocol type of the privileged operation event, for example: if the privileged operation involves executing a high-risk command through SSH, the pre-set high-risk port is 22 (SSH); if it involves deleting a file through SMB, the pre-set high-risk port is 445 (SMB). This rule takes effect immediately after the privileged operation event is triggered and is valid before the verification is completed, physically isolating the operation source device from the server port required to execute the critical operation at the network layer, so that even if the local process is controlled maliciously, it cannot successfully initiate a network connection to execute the operation.

[0098] S520, when the input verification code matches the verification token, the security agent dynamically adds a temporary release rule to the network layer firewall tool, and after the temporary release rule takes effect, the privileged operation event corresponding operation is executed through local system privileges.

[0099] When the user or system inputs the verification code at the prompt of the security agent, and the security agent verifies that the input verification code matches the dynamically bound verification token received from the verification service (S330) exactly, it indicates that the privileged operation has been authorized. At this time, the security agent again operates the network layer firewall tool, dynamically adding a temporary release rule while retaining (or processing later) the default blocking rule. The core content of this rule is: allow the privileged operation source device network address in the feature parameter set to access the pre-set high-risk port associated with the current privileged operation event. After adding this rule, the security agent confirms that the release rule has taken effect in the firewall (usually by querying the firewall status or waiting for the rule to refresh). Once it is confirmed to be effective, the security agent immediately executes the specific operation instruction corresponding to the intercepted privileged operation event (for example: actually calls the system API to delete the target file, or creates a process to execute a high-risk command) using its own local system privileges (usually a high-privilege service account). The temporary release rule is usually set with a short first time window (for example, 5-10 minutes) to ensure that the operation has enough time to complete, while limiting the exposure time.

[0100] S530, when the verification fails or the verification is not verified within the timeout, the security agent maintains or updates the network layer firewall tool rule to continue to block the access of the privileged operation source device network address to the preset high-risk port.

[0101] If the verification of step S400 fails (the input verification code is incorrect or does not match) or the user does not make any verification input within a preset timeout time (for example, 2 minutes), the security agent determines that the privileged operation event is not authorized or is at risk. In this case, the security agent does not perform the privileged operation, and the default interception rule added in step S510 is maintained to continue to block the access of the privileged operation source device network address to the preset high-risk port. To deal with potential persistent attacks (for example, repeated attempts by an attacker), the security agent can also update the firewall rule according to a predefined policy, for example: extending the blocking time of the default interception rule, expanding the blocking range (such as a network segment), or recording the source address as a malicious address for a longer-term ban. This persistent network layer blocking is a key part of the defense in depth, even if the attacker bypasses part of the local verification, he cannot implement the final privileged operation through the network connection.

[0102] Steps S510-S530 construct a set of active defense execution mechanisms that deeply couple local verification and network layer control. S510 implements preventive network interception before verification, by dynamically adding blocking rules accurate to source IP and high-risk ports at the operating system underlying firewall, it physically cuts off the possible path of malicious operation before the operation instruction is actually executed, significantly improves the difficulty for the attacker to achieve the goal, and wins a time window for the subsequent verification. S520 implements precise temporary release after verification, only opens the minimum permission for the authorized source IP and necessary port, and executes the operation safely with system permission by the security agent itself (rather than the user process that may be tampered with) after release, ensuring the legality and controllability of the operation. S530 implements persistent network blocking when the verification fails or times out, maintains or strengthens the protection, and effectively suppresses repeated attempts of unauthorized or malicious operations. This mechanism directly translates the authorization result (allowance / rejection) of dynamic token verification into the mandatory access control action of the operating system network layer and the system permission layer, realizes the closed-loop security from authentication authorization to execution control, greatly enhances the protection capability of the terminal device for privileged operations (especially involving critical file deletion or high-risk command execution), and effectively prevents destructive operation execution in various threat scenarios such as misoperation, credential leakage, process hijacking, and network attack.

[0103] Further, the temporary release rule binds the privileged operation source device network address in the feature parameter set as the release object. The temporary release rule binds the preset high-risk port associated with the privileged operation event as the release port. The temporary release rule sets the first time limit window as the valid period of the privileged operation event according to the preset strategy.

[0104] When the security agent dynamically adds the temporary release rule in step S520, the rule precisely allows the specific source device to restore the access ability to the key service at the network layer, and strictly binds the "release object" (i.e., the source address allowed to connect) of the rule as the privileged operation source device network address (usually the IP address of the terminal device initiating the privileged operation request) captured in the feature parameter set, so that the firewall rule is only effective for this specific IP address. The security agent precisely writes the IP address into the source address matching field of the rule by calling the API (such as iptables-A INPUT-s<Source IP>-jACCEPT or equivalent WFAS command) of the operating system firewall tool. This precise binding ensures that: 1) the principle of least privilege: only the device IP initiating this authorization operation is temporarily released, and other devices cannot connect even if they know the port; 2) operation correlation: the release is directly associated with the privileged operation event currently being processed and has passed verification, avoiding accidental release for other unrelated operations or devices; 3) precise defense: even if there are other unauthorized processes or connection attempts on the same device, as long as the target port is correct, the rule only allows network traffic from the authorized operation context to pass through.

[0105] The temporary release rule does not open all ports, but strictly limits the release range to the preset high-risk ports associated with the current privilege operation event. These high-risk ports are explicitly defined in the system pre-configuration according to the protocol type of the privilege operation event. For example, if the privilege operation is to attempt to delete a remote shared file through the SMB protocol, the preset high-risk port is 445 (SMB); if it is to execute a high-risk command through SSH, it is 22 (SSH). When adding the rule, the security agent queries the preset high-risk port list corresponding to the current privilege operation event type, and sets these port numbers (single or multiple) as the target ports of the temporary release rule (such as --dport 445 or --dport 22) accurately. The execution process is also completed through the API of the firewall tool. This binding ensures that: 1) minimal exposure: only the service port absolutely necessary for the execution of the current privilege operation is opened, and all other ports remain in the default security policy (usually blocked or restricted); 2) protocol adaptability: the rule is accurately matched with the underlying network protocol required by the operation, ensuring that the operation instruction can be executed through the correct network service; 3) risk control: even if a specific IP is released, its operation is strictly limited to the necessary minimum port set, greatly reducing the risk of being exploited for other unauthorized operations.

[0106] In order to strictly limit the effective time of the temporary release rule and prevent authorized abuse or long-term exposure of the attack surface, the rule sets a first time-to-live window as its valid period according to the preset policy. This window is a pre-defined time length (e.g. 5 minutes, 10 minutes), and its specific value can be dynamically determined based on the operation type (such as deleting a file may be set shorter than executing a command), risk level or administrator configured policy. When adding the temporary release rule through the firewall tool API, the security agent will explicitly or use the firewall's own function to attach a time-to-live (TTL) or expiration timestamp (such as iptables -m comment --comment "expire$(date +%s-d'+5min')" with a timed cleanup script, or the -Duration parameter of WFAS rule) to the rule. This time-to-live window starts counting down from the time the rule takes effect. Its execution process ensures that: 1) time-to-live: the release is only valid within a reasonable time window required for the privilege operation, and the rule automatically expires or is cleaned up by the system after the time-to-live, restoring the default interception state; 2) operation guarantee: the set time window is usually sufficient for the security agent to complete the privilege operation (execute operation in S520), but is short enough to limit potential risks; 3) automatic cleanup: without user intervention, the system automatically revokes the release permission after the time-to-live, avoiding security risks caused by long-term existence of rules due to forgetfulness. The setting of the time-to-live window is a key embodiment of dynamic security policy, balancing the needs of operation convenience and security.

[0107] The temporary release rule realizes the refinement, dynamic and minimum permission of network layer access control by precisely binding the privilege operation source device network address (release object), preset high-risk port (release port) and first time limit window (validity period). Instead of simply opening the entire IP or all ports, a highly restricted and temporary network channel is constructed: only the specific source device (IP) of this authorized operation is allowed to access the specific service port (high-risk port) absolutely necessary for the execution of this operation within a specific time window (time limit). This "three-element binding" design accurately converts the authorization result of dynamic token verification (S400) into a network layer, restricted and temporary execution permission, effectively preventing the authorization from being abused horizontally (limiting source IP), preventing the permission from being used to perform unauthorized operations (limiting port), and preventing the release state from being maintained for a long time (limiting time limit). Thus, a dynamic, accurate and self-destroying security barrier is built for the actual execution of privileged operations at the network level, greatly reducing the residual risks that may be introduced after the operation is authorized. It is a key security control link that connects authentication and authorization with actual operation execution in the in-depth defense system.

[0108] Further, after the security agent program in S520 dynamically adds a temporary release rule to the network layer firewall tool, it further includes: after the privileged operation is completed or the validity period of the temporary release rule ends, the security agent program deletes the default blocking rule through the network layer firewall tool.

[0109] After the security agent program successfully dynamically adds a temporary release rule to the network layer firewall tool and performs the corresponding privileged operation, or when the first time limit window set for the temporary release rule naturally expires (whether the operation is performed or not or whether it is successful), the security agent program will further perform rule cleaning operation. By calling the programming interface of the network layer firewall tool (such as iptables / nftables, WFAS) of the operating system again, the default blocking rule dynamically added in step S510 for this privileged operation event is accurately deleted. The default blocking rule is characterized by blocking access to the preset high-risk port associated with this privileged operation event for the network address of the source device of this privileged operation. The security agent program locates and removes this specific rule through rule matching mechanism (such as matching source IP, target port and possibly adding specific rule annotations or labels). This step ensures that after the processing period (from triggering to verification execution or timeout end) of this privileged operation event is completed, the firewall rule set can return to the baseline state before the event occurs, and the blocking control temporarily added for this event is removed.

[0110] The introduction of step S540 (rule cleanup) perfects the dynamic life cycle management of firewall rules, solves the problem that a large number of default interception rules added by S510 may be accumulated for a long time, causing the firewall rule set to be bloated and even performance to be degraded in the scenario of frequent occurrence of privilege operation request. More importantly, it avoids unnecessary network blocking (i.e. "mistaken injury") caused by old rules remaining to the subsequent new and legal privilege operation request initiated by the same source device. By timely removing the default interception rules for this specific event after the execution is completed or the rule validity period ends, the system ensures that: 1) resource efficiency: the firewall rule set remains simple, maintaining system performance and manageability; 2) operation continuity: when the same legal source device initiates a new and independent privilege operation request subsequently, it will trigger the complete monitoring-verification-control process again, and the initial network state will not be incorrectly blocked by the residual rules of the previous event, ensuring the smoothness of legal operations; 3) state clarity: the firewall state always reflects the current effective security policy, avoiding policy confusion or unpredictable access control behavior caused by historical rules. This step, together with the dynamic addition of S510 and the dynamic adjustment of S520 / S530, constitutes a closed-loop, self-cleaning network layer access control mechanism, which is an important guarantee link for efficient and accurate implementation of dynamic security policies on terminal devices.

[0111] Further, the terminal device privilege operation protection method further comprises:

[0112] S610: When the verification server continuously receives privilege operation requests sent by multiple security agents from a pre-defined IP address pool within a pre-set time window, and all privilege operation requests meet pre-set aggregation conditions.

[0113] The verification server continuously monitors the received privilege operation requests from the security agent programs of various terminal devices. When the server continuously receives multiple (e.g., more than a threshold number) privilege operation requests within a preset, relatively short time window (e.g., 30 seconds or 1 minute), and finds that all the requests meet the preset aggregation conditions through analysis, the aggregation token mechanism is triggered. The preset aggregation conditions include three key elements: 1) the feature parameter set in all requests contains the same cryptographic hash value of the target file, meaning that all operations are performed on the same file (or files with the same content) on the disk; 2) the operation type identifiers (e.g., "file deletion" or specific high-risk command IDs) of all requests are completely consistent; 3) all the network addresses (IP addresses) of the source devices initiating the requests belong to the same predefined IP address pool (e.g., the operation and maintenance network segment 10.1.1.0 / 24 or a specific server cluster IP list). Such a concentrated burst of requests for the same operation on the same file and from a trusted IP address pool usually indicates an automated operation and maintenance task (such as batch updating or cleaning) rather than a single manual operation or malicious attack.

[0114] S620: The verification server generates a single aggregation token dynamically bound to the cryptographic hash value of the target file and the predefined IP address pool, and sets a second time-to-live window.

[0115] When the conditions of step S610 are met, the verification server no longer generates an independent token for each individual request, but performs aggregated authorization. The server generates a single aggregation token using a similar cryptographic mechanism as generating a single token (possibly with simplified or adjusted inputs). The core binding elements of this token are: the cryptographic hash value of the target file (identifying the file being operated on) and the predefined IP address pool (identifying the group of source devices authorized to perform this operation). At the same time, the server sets a relatively long second time-to-live window (e.g., 10-30 minutes, much longer than the first time-to-live window of a single token) for this aggregation token to accommodate the execution time that batch operations may require. After generating this aggregation token, the verification server pushes or broadcasts it to all security agent programs from the predefined IP address pool that have initiated qualified requests within the preset time window (or notifies the relevant management node to issue).

[0116] S630: After receiving the single aggregation token, the security agent program dynamically adds a centralized release rule to the network layer firewall tool.

[0117] The security agent (usually in the case that the IP of the device it belongs to belongs to the predefined IP address pool, and its request meets the aggregation condition) receives the single aggregation token issued by the verification service, and understands that the specific operation (type) for the specific file (hash value) has obtained the batch authorization for the IP address pool where the device is located. At this time, the security agent no longer waits or needs to input the local verification code for subsequent same operation requests (S400). Instead, the network layer firewall tool of the local machine is immediately operated to dynamically add a centralized release rule to allow the entire predefined IP address pool (as the release object, such as the source IP range 10.1.1.0 / 24) to access the preset high-risk port (as the release port) associated with the current privilege operation event (i.e. the specific operation type for the specific file hash). The validity period of the centralized release rule is strictly synchronized with the second time window of the aggregation token.

[0118] S640: Within the second time window of the centralized release rule, when any privilege operation source device in the predefined IP address pool initiates the same operation, the security agent directly releases the operation execution.

[0119] After the centralized release rule added in step S630 takes effect, as long as the rule is within the validity period of its second time window, any privilege operation source device in the predefined IP address pool (i.e. any terminal in the IP pool) will be directly released by the security agent if the security agent monitors the same operation type privilege operation event (such as attempting to delete the file again or executing the same high-risk command) for the same target file cryptographic hash value (i.e. the same file). The security agent will perform direct release, which achieves: 1) the security agent no longer triggers the remote token request and local verification process of S300-S400; 2) the security agent directly executes the operation instruction corresponding to the privilege operation (such as deleting the file or executing the command) using local system privileges. This release greatly improves the efficiency of batch operations, and the execution of the released operation is still protected by the network layer centralized release rule (only allows authorized IP pool to access necessary ports).

[0120] Steps S610-S640 collectively construct an efficient aggregation authorization and execution mechanism for a batch-oriented, homogeneous privilege operation scenario. Through the intelligent identification of S610 (same file, same operation, same IP pool), the verification server can distinguish between automated operation and maintenance tasks and sporadic operations or attacks. The aggregation token generation of S620 extends the authorization range from a single device to the entire trusted IP address pool and sets a reasonably extended time window (second time window) for batch operations, significantly reducing the number of frequent interactions and verifications. The centralized release rule of S630 implements a unified release policy for authorized IP pools at the terminal firewall level, opening a network channel for batch operations. The direct release logic of S640 completely bypasses the single operation verification process (S300-S400) under the premise of authorized IP pools, same file, and same operation, achieving automation of operation execution. The core value of this mechanism lies in: while strictly maintaining security control (authorization is still based on file fingerprints and operation types, network access is still precisely limited to high-risk ports and authorized IP pools, and there is a clear time limit), it greatly optimizes the user experience and execution efficiency of legal and high-frequency batch operation (such as configuration updates or log cleaning on a large number of servers), avoiding the delay and operation burden caused by massive single verification, and ensuring the controllability and auditability of batch operations through IP address pool predefinition and centralized authorization. It is a key innovation that balances security and efficiency.

[0121] Further, the preset aggregation condition includes that the cryptographic hash values of the target files in all the sets of feature parameters are the same, all the operation type identifiers are consistent, and the IP addresses of the privilege operation source devices initiating the requests belong to the same predefined IP address pool.

[0122] The core basis for the verification server to determine whether to trigger the aggregation token mechanism (S610) is the preset aggregation condition, which includes three strict elements that must be met simultaneously. First, the cryptographic hash values of the target file in all feature parameter sets must be exactly the same. Within the preset time window, multiple privileged operation requests are received, and the operation targets point to the same file on the disk with exactly the same content (or multiple copies with the same content). The uniqueness and collision resistance of the cryptographic hash value (such as SHA-256) ensure the consistency of the precise object of the operation. Second, all operation type identifiers must be exactly the same, i.e., all requested operation behaviors belong to the same predefined high-risk operation category (for example, all are "file deletion" or all execute the same specific high-risk command such as rm-rf / critical / dir). The operation type identifier is usually a predefined enumeration value or string constant used to accurately distinguish different privileged operations. Finally, all the IP addresses of the privileged operation source devices initiating the request must belong to the same predefined IP address pool; this IP address pool is a set of trusted devices (such as server IP segment 10.0.1.0 / 24 belonging to the same operation VLAN or IP list of a specific application cluster) that are logically associated and pre-configured by the administrator. The verification server confirms the ownership by checking whether the request source IP falls within the predefined CIDR block or matches the predefined IP list. Only when all three conditions (same file hash, same operation type, and same predefined IP pool) are met for multiple requests within the preset time window, does the server determine that these requests represent a legitimate homogeneous operation stream that needs to be processed in bulk (such as an automated operation script executing the same cleaning task on multiple servers), thereby satisfying the aggregation condition to trigger S620.

[0123] The centralized release rule includes: the release object is all network addresses of the predefined IP address pool, the release port is the preset high-risk port associated with the current privileged operation event, and the effective period is synchronized with the second time window.

[0124] When the security agent dynamically adds the centralized release rule according to the received single aggregation token, the rule has three key attributes, which directly determine the network access control policy under the bulk authorization. First, the release object is all network addresses of the predefined IP address pool, which means that the rule is no longer targeted at a single source IP, but the release range is expanded to all IP addresses contained in the entire predefined IP address pool that triggers the aggregation condition (for example, the entire network segment 10.0.1.0 / 24 or all IP addresses in the list). When adding the rule, the security agent sets the CIDR representation or IP list of the entire address pool as the source address matching field of the firewall rule (such as -s 10.0.1.0 / 24), so that connections from any IP in the pool that meet the port condition are allowed, which adapts to the characteristics of the dispersed source IP of the bulk operation. Second, the release port is the preset high-risk port associated with the current privileged operation event, and although it is bulk authorization, the target port range released by the rule still remains accurate and minimized. According to the type of the privileged operation event that triggers this aggregation mechanism (the operation type identifier is unified in the aggregation condition), the security agent queries and binds the corresponding preset high-risk port (such as port 22 for SSH operation and port 445 for SMB operation), and sets these ports as the target port of the rule (such as -dport 22), ensuring that even if it is bulk release, only the ports necessary for performing the specific operation are opened. Third, the validity period is synchronized with the second time window. The validity period of the centralized release rule is not independent, but strictly bound to the second time window set by the verification service side for the aggregation token (S620). When adding the rule, the security agent uses the API of the firewall tool to set a time to live (TTL) or expiration time point for the rule, which is equal to the second time window length set by the service side (or the expiration time stamp calculated by the service side). For example, if the service side sets the aggregation token validity period to 15 minutes, the added centralized release rule will also automatically expire after 15 minutes, ensuring that the bulk authorization has a clear and controllable time boundary, and the release permission is automatically revoked after timeout.

[0125] Accordingly, please refer to Figure 4 The second aspect of the embodiment of the application provides a terminal device privileged operation protection device, which protects the privileged operation of the terminal device based on the terminal device privileged operation protection method, and comprises:

[0126] An event monitoring module 1 is configured to monitor a privileged operation event based on a security agent deployed on the terminal device, and the privileged operation event comprises deleting a file or executing a predefined high-risk command.

[0127] A parameter acquisition module 2 is configured to acquire a feature parameter set of the privileged operation event, and the feature parameter set at least includes a cryptographic hash value of the target file, an operating system identifier of the trigger process, and a network address of the privileged operation source device.

[0128] A data exchange module 3 is configured to send the feature parameter set to a verification server and receive a verification token generated by the verification server and dynamically bound to the feature parameter set.

[0129] A token verification module 4 is configured to receive an input verification code through a security agent and verify whether the input verification code matches the verification token returned by the verification server.

[0130] A policy execution module 5 is configured to allow the execution of an operation corresponding to the privileged operation event if the verification is successful, and block the execution of the privileged operation event if the verification fails.

[0131] Correspondingly, a third aspect of the embodiment of the present application provides an electronic device, including at least one processor and a memory connected with the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the terminal device privileged operation protection method.

[0132] Correspondingly, a fourth aspect of the embodiment of the present application provides a computer readable storage medium having computer instructions stored thereon, and the instructions are executed by a processor to implement the terminal device privileged operation protection method.

[0133] The embodiment of the present application aims to protect a terminal device privileged operation protection method and device, and has the following effects:

[0134] 1. The verification token is dynamically strongly bound to the operation context (file hash, process PID, operation source terminal device IP), which completely solves the generalization risk of the traditional dynamic token. Attackers cannot fake or reuse tokens to launch cross-terminal attacks, the success rate of replay attacks is reduced from an industry average of >10% to <0.01%, the interception success rate is improved by 300% compared to the previous front-end behavior analysis scheme, and the compliance requirements of regulations on privileged operation auditing are met.

[0135] 2. The iptables is used to directly control the traffic permission at the network layer to achieve a millisecond-level response of “blocking upon verification failure”; the rule takes effect in <5ms, which is two orders of magnitude higher than the average delay of 500ms of the zero trust architecture, and the terminal Agent occupies <50MB of memory, supports large-scale deployment of thousands of servers, and perfectly adapts to low-latency scenarios such as industrial control.

[0136] 3. When multiple legitimate users initiate operations on the same target file, a single aggregated token is generated by binding the file hash with the team IP pool, reducing the verification trigger frequency by 60%; within a time window (e.g., 5 minutes), pre-defined IP pool members perform the same operation without repeated verification, while the permission range is constrained by both the file hash and the IP pool, balancing efficiency and security.

[0137] Those skilled in the art will understand that embodiments of the present application can be provided as methods, systems, or computer program products. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0138] The present application is described in reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing system or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks.

[0139] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks.

[0140] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flowchart illustrations and / or block diagrams block or blocks.

[0141] It should be pointed out finally that the above embodiments are only used to illustrate the technical solutions of the present application but not to limit it. Although the present application has been described in detail with reference to the above embodiments, it should be understood by those skilled in the art that the specific embodiments of the present application can be modified or replaced equivalently without departing from the spirit and scope of the present application, and any modification or equivalent replacement without departing from the spirit and scope of the present application should be covered in the protection scope of the claims of the present application.

Claims

1. A method for protecting terminal device privilege operation, characterized in that, The method comprises the following steps: S100, monitoring a privileged operation event based on a security agent program deployed on a terminal device, the privileged operation event comprising: deleting a file or executing a predefined high-risk command; S200, obtaining a feature parameter set of the privileged operation event, the feature parameter set at least comprising: a cryptographic hash value of a target file, an operating system identifier of a triggering process, and a network address of a privileged operation source device; S300, sending the feature parameter set to a verification server and receiving a verification token generated by the verification server and dynamically bound to the feature parameter set; S400, receiving an input verification code through the security agent program and verifying whether the input verification code matches the verification token returned by the verification server; S500, if the verification matches, allowing execution of an operation corresponding to the privileged operation event, and if the verification fails, blocking execution of the privileged operation event.

2. The method of claim 1, wherein, The monitoring of the privileged operation event based on the security agent program deployed on the terminal device in S100 comprises: S110, registering an event listener to a system audit interface of an operating system through the security agent program, so that the system audit interface pushes a file system operation request and a command line process execution request to the event listener in real time; S120, receiving operation request data stream through the event listener and matching operation behaviors in the operation request data stream based on a predefined high-risk operation rule library; S130, generating a privileged operation event identifier comprising a timestamp when a file deletion command or a high-risk command execution behavior is matched.

3. The method of claim 1, wherein the terminal device privilege operation guard is implemented by a trusted platform module (TPM) of the terminal device. The sending of the feature parameter set to the verification server and the receiving of the verification token generated by the verification server and dynamically bound to the feature parameter set in S300 comprise: S310, sending the feature parameter set to the verification server after encryption through the security agent program; S320, triggering the verification server to perform a cryptographic generation operation of a dynamically bound token based on the target file cryptographic hash value, the triggering process operating system identifier, and the privileged operation source device network address in the feature parameter set; S330, receiving the verification token returned by the verification server through the security agent program, the verification token being an output result of the cryptographic generation operation.

4. The method of claim 3, wherein, The cryptographic generation operation of the dynamically bound token in S320 comprises: S321, the verification server concatenates the target file cryptographic hash value, the triggering process operating system identifier, the privileged operation source device network address, and a current system timestamp and a cryptographic secure random number in the feature parameter set in a preset order to form an input sequence; S322, the verification server performs a keyed-Hash Message Authentication Code operation on the input sequence to generate a fixed-length digest value; S323, the verification server converts the digest value into a decimal number sequence and takes the last 6 digits as a dynamically bound token.

5. The method of claim 1, wherein, The allowing of the execution of the operation corresponding to the privileged operation event if the verification matches and the blocking of the execution of the privileged operation event if the verification fails in S500 comprise: S510, after the privileged operation event is triggered and before the dynamic verification is completed, the security agent dynamically adds a default interception rule through a network layer firewall tool of an operating system to block access of a network address of a privileged operation source device in the feature parameter set to a preset high-risk port associated with a protocol type of the privileged operation event; S520, when the input verification code matches the verification token, the security agent dynamically adds a temporary release rule to the network layer firewall tool, and after the temporary release rule takes effect, performs the operation corresponding to the privileged operation event through local system authority; S530, when the verification fails or times out, the security agent maintains or updates the network layer firewall tool rule to continuously block access of the network address of the privileged operation source device to the preset high-risk port.

6. The terminal device privileged operation protection method of claim 5, wherein: the temporary release rule binds the network address of the privileged operation source device in the feature parameter set as a release object; the temporary release rule binds the preset high-risk port associated with the privileged operation event as a release port; the temporary release rule sets a first time-to-live window as an effective period for performing the privileged operation event according to a preset strategy.

7. The method of claim 5, wherein the terminal device privilege operation guard is performed by a trusted platform module (TPM) of the terminal device. After the security agent in S520 dynamically adds the temporary release rule to the network layer firewall tool, the method further includes: after the privileged operation is performed or the effective period of the temporary release rule ends, the security agent deletes the default interception rule through the network layer firewall tool.

8. The method of claim 1-7, wherein, Further comprising: S610: when the verification server continuously receives a plurality of privileged operation requests sent by the security agent from a predefined IP address pool within a preset time window, and all the privileged operation requests meet a preset aggregation condition; S620: the verification server generates a single aggregation token dynamically bound to a cryptographic hash value of a target file and the predefined IP address pool, and sets a second time-to-live window; S630: after the security agent receives the single aggregation token, the security agent dynamically adds a centralized release rule to the network layer firewall tool; S640: within the second time-to-live window corresponding to the centralized release rule, when any of the privileged operation source devices in the predefined IP address pool initiates the same operation, the security agent directly releases the operation for execution.

9. The terminal device privileged operation protection method of claim 8, wherein: the preset aggregation condition includes that the cryptographic hash values of all target files in the feature parameter set are the same, all operation type identifiers are consistent, and the IP addresses of the privileged operation source devices initiating the requests belong to the same predefined IP address pool; the centralized release rule includes that the release object is all network addresses of the predefined IP address pool, the release port is the preset high-risk port associated with the current privileged operation event, and the effective period is synchronized with the second time-to-live window.

10. A terminal device privilege operation protection apparatus characterized by comprising: The terminal device privilege operation protection method based on any one of claims 1-9 is used for terminal device privilege operation protection, and comprises the following steps: An event monitoring module is used for monitoring a privilege operation event based on a security agent deployed on the terminal device, and the privilege operation event comprises deleting a file or executing a predefined high-risk command; A parameter acquisition module is used for acquiring a feature parameter set of the privilege operation event, and the feature parameter set at least comprises a cryptography hash value of a target file, an operating system identifier of a trigger process, and a network address of a privilege operation source device; A data exchange module is used for sending the feature parameter set to a verification server and receiving a verification token dynamically bound with the feature parameter set generated by the verification server; A token verification module is used for receiving an input verification code through the security agent and verifying whether the input verification code matches the verification token returned by the verification server; A policy execution module is used for allowing execution of an operation corresponding to the privilege operation event if the verification is matched, and blocking execution of the privilege operation event if the verification fails.

Images