Terminal security management method and system based on unified strategy

Abstract

The invention discloses a terminal security management method and system based on a unified strategy, and the method comprises the steps: a management center generates a unified strategy description file, and generates a strategy version identifier corresponding to the unified strategy description file; the unified strategy description file is used for expressing strategy content needing to be executed by the terminal; the management center issues the unified policy description file to a target terminal, and generates a session identifier for the current policy issuing and certification process for marking the current policy issuing and certification process; after receiving the unified strategy description file, the target terminal verifies the unified strategy description file; when verification is passed, strategy content is loaded in a session corresponding to the session identifier and takes effect; and the target terminal collects strategy proof data after the strategy content takes effect, and calculates a strategy proof abstract based on the strategy proof data. According to the method, unified strategy verifiable issuing and effective closed loop is realized, and traceable protection is formed for fallback and tampering.

Description

Technical Field

[0001] This application relates to the field of endpoint security technology, and in particular to endpoint security management methods and systems based on unified policies. Background Technology

[0002] With the continuous advancement of school informatization, the number of computers in teaching labs, teacher office terminals, dedicated laboratory hosts, and various servers is rapidly increasing. The diversity of terminal types and frequent changes in users pose significant challenges to the security management of terminals and servers. Current technologies typically involve deploying a terminal security management system to centrally manage terminal assets, operational status, software installation, and user permissions, and to achieve secure control of terminals and servers through a unified security policy.

[0003] However, in practical applications, the existing methods still have some easily overlooked problems. First, during the configuration of unified security policies, administrators often grant temporary or additional permissions to specific terminals or users to meet temporary needs such as teaching and experiments. Due to the implicit inheritance and dependency relationships between different permissions, in a school environment where multiple terminals and roles share the same space, it is easy to form implicit over-authorization chains. This causes the unified policy to violate the principle of least privilege while appearing compliant, bringing potential security risks. Existing methods usually cannot identify and eliminate such hidden problems in a timely manner.

[0004] Secondly, school computer labs commonly use system image restoration, restore cards, or virtualization snapshots to quickly restore terminals. These technologies can cause terminals to revert to a historical state at the physical or logical level, overwriting or losing previously issued security policies, patch status, and local audit information. This results in a discrepancy between the actual terminal state and the state perceived by the management center, creating a time gap in policy execution and security auditing. Existing terminal security management methods are largely based on the assumption of continuous terminal state evolution, making it difficult to address the aforementioned state rollback scenarios. Consequently, under unified policy management, this creates long-term and difficult-to-detect security blind spots. Summary of the Invention

[0005] To address the aforementioned problems, embodiments of the present invention provide a terminal security management method based on a unified policy, the method comprising: A unified policy-based endpoint security management method, characterized in that the method includes: The management center generates a unified policy description file and a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. The management center sends the unified policy description file to the target terminal and generates a session identifier for this policy issuance and verification process. After receiving the unified policy description file, the target terminal verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. After the policy content takes effect, the target terminal collects policy proof data and calculates the policy proof summary based on the policy proof data. The target terminal generates a terminal policy proof record, which includes a previous record summary, a current policy proof summary, a policy version identifier, a session identifier, and a monotonic sequence. The previous record summary is used to form a chain association with the previous terminal policy proof record, and the monotonic sequence is used to characterize the order of terminal policy proof records within the same session.

[0006] The target terminal reports the terminal policy proof record to the management center; the management center performs a consistency check on the terminal policy proof record based on the policy version identifier and the session identifier, and checks the chain association and the monotonic sequence; when the check fails, the management center triggers a rollback protection measure to prevent the abnormal policy state from continuing to take effect.

[0007] Furthermore, the unified policy description file includes a policy content area and a metadata area; the metadata area includes a policy version identifier, a session identifier generation rule marker, a file generation timestamp, and a signature field; the management center performs a hash calculation on the policy content area and the metadata area to obtain a file digest, and signs the file digest using the management center's private key, writing the signature result into the signature field, thereby enabling the terminal to verify the source and integrity of the unified policy description file.

[0008] Further, the verification includes: the terminal extracts the signature field and file digest calculation rules of the unified policy description file, recalculates the file digest, and verifies the signature using the management center's public key; after successful verification, the terminal further verifies the format validity of the policy version identifier and the session identifier, and verifies whether the policy version identifier meets the terminal's version update direction rules; when the verification fails, the terminal refuses to load the policy content and generates a failure proof record to report to the management center. The policy proof digest of the failure proof record is calculated jointly by the failure reason code and the file digest.

[0009] Furthermore, the policy proof data is collected by the terminal at the time the policy takes effect and during the subsequent operating cycle. The policy proof data includes: a file digest of the unified policy description file, a policy loading result code on the terminal side, a policy effective status flag, and a snapshot of the status of controlled objects related to policy execution. The terminal concatenates and encodes the policy proof data according to a preset field order and then calculates a hash to obtain the current policy proof digest. This allows the management center to determine whether the policy has been loaded on the terminal side and entered the effective state according to the content expressed in the unified policy description file based on the current policy proof digest.

[0010] Furthermore, the preceding record digest is calculated from the record digest of the previous terminal policy proof record. The record digest is calculated by combining the current policy proof digest, policy version identifier, session identifier, and monotonic sequence from the previous terminal policy proof record. When generating the current terminal policy proof record, the terminal writes the preceding record digest into the current record and performs hash calculation on the preceding record digest, the current policy proof digest, the policy version identifier, the session identifier, and the monotonic sequence to obtain the current record digest. The management center uses the correspondence between two adjacent records to verify the continuity of the digest chain, which is used to detect record insertion, deletion, replacement, and replay.

[0011] Furthermore, the monotonic sequence is generated by a terminal-side monotonic counter, which provides a sequence value retrieval interface that only increases and never decreases. Within the same session corresponding to the same session identifier, the terminal calls the sequence value retrieval interface to obtain a new monotonic sequence and writes it into the record for each terminal policy proof record generated. When the terminal detects that the monotonic counter is reset, wrapped around, or unavailable, it encodes the abnormal status into the current policy proof summary and reports it to the management center.

[0012] Furthermore, the consistency check includes: verifying whether the policy version identifier reported by the terminal is consistent with the policy version identifier in the record issued by the management center; verifying whether the session identifier is consistent with the session identifier generated by the management center for this issuance; verifying that the monotonic sequence is strictly increasing within the same session identifier range; and verifying that the previous record summary matches the previous record summary already stored by the management center. When any of the following situations occur, such as policy version identifier matching but session identifier not matching, session identifier matching but summary chain broken, or monotonic sequence not increasing, the management center outputs an abnormal check result.

[0013] Furthermore, the rollback protection process includes the following actions: the management center issues a rollback blocking command to the terminal, causing the terminal to stop executing the current policy content and switch to the policy corresponding to the policy version identifier specified by the management center; the management center marks the terminal as restricted and narrows its accessible resource range; the management center requires the terminal to re-fetch the unified policy description file and regenerate the terminal policy proof record; the management center appends the anomaly verification result and the corresponding terminal policy proof record to the audit storage, and in subsequent verifications, uses the last verified record digest in the audit storage as the starting point of the chain for the new session, so as to achieve traceable proof continuity across sessions.

[0014] The terminal security management method based on a unified strategy also includes: session anchoring and monotonic sequence anti-wrap-up; layered summary of evidence data and on-demand evidence index; session recovery and sampling review for anomaly verification.

[0015] A unified policy-based endpoint security management system includes: Unified Policy Module: The management center generates a unified policy description file and a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. Policy delivery module: The management center delivers the unified policy description file to the target terminal and generates a session identifier for this delivery, which is used to mark this policy delivery and verification process; Policy verification module: After the target terminal receives the unified policy description file, it verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. Policy acquisition module: After the policy content takes effect, the target terminal acquires policy proof data and calculates the policy proof summary based on the policy proof data; Proof Record Module: The target terminal generates a terminal policy proof record, which includes a previous record summary, a current policy proof summary, a policy version identifier, a session identifier, and a monotonic sequence. The previous record summary is used to form a chain association with the previous terminal policy proof record, and the monotonic sequence is used to characterize the order of terminal policy proof records within the same session.

[0016] Consistency verification module: The target terminal reports the terminal policy proof record to the management center; the management center performs consistency verification on the terminal policy proof record based on the policy version identifier and the session identifier, and verifies the chain association and the monotonic sequence; when the verification fails, the management center triggers rollback protection to prevent the abnormal policy state from continuing to take effect.

[0017] The technical effects and advantages of the unified policy-based endpoint security management method provided by this invention are as follows: This invention achieves a unified strategy that verifies the closed loop of issuance and effectiveness, and provides traceable protection against rollback and tampering. This invention ensures the reliability and integrity of the policy's source during transmission and deployment by using a unified policy description file digest signature and terminal-side signature verification, preventing policy replacement or silent tampering. After the policy is loaded and takes effect, the terminal collects policy proof data and calculates the current policy proof digest, enabling the management center to verify the terminal's actual effective status based on the proof digest and corresponding proof data. Through a chain-like association of "preceding record digest - record digest," the terminal's policy proof records are linked into a verifiable continuous link, allowing the management center to identify anomalies such as record insertion, deletion, and replacement based on adjacent record relationships. A monotonic counter on the terminal side outputs a monotonic sequence and writes it into the proof record, forming an order constraint with the session identifier, enabling behaviors such as replay, out-of-order reporting, and session mismatch to be identified and recorded during the consistency verification phase. When the consistency verification fails, a fallback protection process is triggered, which involves blocking the execution of the current policy, switching to a specified policy version, entering a restricted state, and re-fetching the policy and rebuilding the proof chain, forming a closed loop of "anomaly detection - blocking - recovery - re-verification." Attached Figure Description

[0018] Figure 1 This is a flowchart of the terminal security management method based on a unified policy in Example 1; Figure 2 This is a flowchart of the terminal security management method based on a unified policy in Example 2; Figure 3 This is a connection diagram of the terminal security management system based on a unified policy in Example 3. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example

[0020] Please see Figure 1 As shown, embodiments of the present invention provide a terminal security management method based on a unified policy, comprising the following steps: S1: The management center generates a unified policy description file and generates a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. S2: The management center sends the unified policy description file to the target terminal and generates a session identifier for this policy issuance and verification process. S3: After receiving the unified policy description file, the target terminal verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. S4: After the policy content takes effect, the target terminal collects policy proof data and calculates the policy proof summary based on the policy proof data; S5: The target terminal generates a terminal policy proof record, which includes a previous record summary, a current policy proof summary, a policy version identifier, a session identifier, and a monotonic sequence; wherein, the previous record summary is used to form a chain association with the previous terminal policy proof record, and the monotonic sequence is used to characterize the order of terminal policy proof records within the same session.

[0021] S6: The target terminal reports the terminal policy proof record to the management center; the management center performs a consistency check on the terminal policy proof record based on the policy version identifier and the session identifier, and checks the chain association and the monotonic sequence; when the check fails, the management center triggers a rollback protection measure to prevent the abnormal policy state from continuing to take effect.

[0022] In this embodiment, the management center is a functional term, referring to the end of the system responsible for unified management and coordination control, such as a server or server cluster, a platform-side backend system (Web management backend + server), and control center equipment.

[0023] In this embodiment, the management center generates a unified policy description file in step S1. The file is divided into a policy content area and a metadata area in a structured organization. The policy content area is used to carry the expression content of the unified policy, which is used to constrain the executable behavior of the terminal, the set of allowed / denied objects, and the scope of policy application, etc. The metadata area is used to carry information related to file generation, distribution and verification. The metadata area contains the policy version identifier, session identifier generation rule mark, file generation timestamp and signature field.

[0024] The policy version identifier is used to distinguish unified policy description files from different batches or different evolution stages. The management center maintains version management rules. When the policy content area is changed and passes the review or orchestration, a new policy version identifier is generated according to the version management rules and written to the metadata area. The encoding format of the version identifier is not limited, but it must be comparable and traceable within the same management center domain so that the terminal and the management center can reference the same policy in subsequent processes.

[0025] The session identifier generation rule tag is used to declare the generation method of the session identifier issued this time. Since the session identifier can be randomly generated by the management center or generated according to deterministic rules and associated with the batch, target range or file summary, the management center maps the generation method adopted to the rule tag and writes it into the metadata area. This enables the terminal to identify the source attribute of the session identifier when processing files in S3, and participate in the verification or association of records according to the corresponding rules when needed, reducing the ambiguity risk of cross-session splicing of proof records.

[0026] The file generation timestamp is used to record the time when the unified policy description file is finalized on the management center side. Its purpose is to provide a basis for identifying new and old files and judging consistency within the same session, rather than providing precise timing. To avoid ambiguity caused by time zone and format differences, the management center performs format normalization processing on the timestamp before writing and writes the normalization result into the metadata area.

[0027] After writing the aforementioned metadata, the management center calculates the file digest for the policy content area and the metadata area. In this embodiment, the file digest is a fixed-length digest value obtained by hashing the file, used for integrity verification. To ensure that the management center and the terminal obtain consistent digests for the same file, the management center performs deterministic serialization processing on the fields involved in the digest calculation before calculation, including fixed field order, clear field boundaries, consistent character encoding, and whitespace / line break normalization. Since the metadata area contains a signature field and there is no valid signature value before signing, in this embodiment, the signature field is set to a predefined null value placeholder or a fixed placeholder during the digest calculation stage, and this placeholder state is used as part of the metadata area in the digest calculation. After the digest and signature are generated, the actual signature result overwrites the placeholder content of the signature field, so that the terminal can recalculate the digest on the S3 side according to the same rules (restoring the signature field to the placeholder state) and obtain consistent results.

[0028] Subsequently, the management center uses its private key to sign the file digest to obtain the signature result, which is then written into the signature field of the metadata area. The method of storing the private key is not limited; in the implementation, it can be hosted by the key management module and the signature can be executed through a controlled interface to reduce the risk of the private key being exposed in the business process. The corresponding management center public key is provided to the terminal in a trusted manner, such as being written into a trusted public key set when the terminal initializes the management, or being distributed and solidified through a protected channel for terminal-side signature verification.

[0029] After receiving the unified policy description file in step S3, the terminal processes the policy content area and metadata area according to the deterministic serialization rules consistent with the management center, and recalculates the file digest after restoring the signature field to a placeholder state according to the placeholder rules. Then, it uses the management center's public key to verify the signature result in the signature field. If the signature verification is successful, it indicates that the file source is consistent with the management center's identity, and that the policy content area and metadata area have not been tampered with during transmission and disk storage. The terminal only proceeds to the subsequent loading and activation process after the signature verification is successful. If the signature verification fails, the terminal does not load the policy, and uses the reason for failure and the associated identifier to generate subsequent reporting records to prove the continuity of the recording process.

[0030] In this embodiment, the verification in step S3 revolves around two things: the source of the unified policy description file is trustworthy and the content has not been modified. The unified policy description file is generated and distributed by the management center. The file is divided into a policy content area and a metadata area. The metadata area sets a signature field and a file digest calculation rule marker. Here, the file digest refers to the hash digest calculated from the file content according to the established rules. In cryptography, it is a fixed-length result used to characterize data integrity. The file digest calculation rule is used to define the calculation object and calculation method of the digest, so as to avoid the terminal and the management center using different value ranges or different encoding methods for the same file, which would lead to inconsistencies in the digest.

[0031] After receiving the unified policy description file, the terminal first completes parsing and normalization: the terminal reads the rule tags in the metadata area to determine the scope of the digest calculation; in implementation, the digest calculation scope covers the policy content area and metadata fields related to policy semantics, but does not include the signature field itself. Subsequently, the terminal performs deterministic encoding on the fields involved in the calculation according to the rules, such as uniformly processing field order, character encoding, newline and whitespace characters, to obtain the byte sequence used to calculate the digest, and recalculates the file digest accordingly; the terminal extracts the signature field from the file and calls the management center's public key to verify the signature: the management center's public key is written to trusted storage by the terminal during the controlled installation phase, or issued through the management center's certificate chain and solidified after the terminal completes certificate verification; the terminal uses the public key to verify the signature value corresponding to the signature field, and the verification target is the file digest recalculated by the terminal; if the verification fails, it is considered that the file source is unconfirmed or the content may have been tampered with, and the terminal does not enter the policy loading process.

[0032] After signature verification is successful, the terminal continues to perform format and consistency checks on the policy version identifier and session identifier. The policy version identifier is used to identify the policy version corresponding to the unified policy description file; the session identifier is used to identify the unique session of this issuance and verification process, so that subsequent verification records can be bound to a specific issuance action. The terminal's format check usually includes: whether the field type conforms to the convention, whether the length and encoding conform to the convention, and whether there are empty values ​​or illegal characters. Subsequently, the terminal determines whether the policy version is allowed to be loaded according to its own version update direction rules. The version update direction rules here do not depend on precise parameters. The common implementation method in engineering is: the terminal maintains a persistent record of "policy version identifier that has passed verification and been successfully loaded" locally. The new policy version identifier needs to meet the update direction consistent with this record. For example, it is not allowed to go back from the new version to the old version, or it is not allowed to roll back across the established version order relationship. When the terminal is in the state of first access or the local record is empty, the record is established with the initial policy version issued by the management center as the starting point.

[0033] If the verification fails at any stage, the terminal refuses to load the policy content and generates a failure proof record to report to the management center. The failure proof record is used by the management center to review the cause and context of the failure without relying on the terminal's local logs. Therefore, the record contains: the session identifier corresponding to this issuance, the policy version identifier, the file digest used by the terminal for calculation, and the failure reason code. The failure reason code is an identifier generated by the terminal according to a predefined enumeration, used to distinguish different failure paths such as signature verification failure, inconsistent digest calculation, unsatisfactory version update direction, and illegal session identifier format. Subsequently, the terminal calculates the policy proof digest based on the failure reason code and the file digest, and writes this digest as the core proof data of the failure proof record. In an implementation consistent with the proof chain, the terminal also writes the record digest of the previous terminal policy proof record as the preceding record digest into the failure proof record, and assigns a monotonic sequence to the failure proof record, so that the failure record also participates in the chain association, which facilitates the management center to verify "when the failure occurred, whether it was inserted or replayed".

[0034] For example: In a distribution session, after receiving the unified policy description file, the terminal recalculates the digest and verifies the signature. However, the version identifier of the loaded policy stored locally on the terminal is "V3", while the version identifier of the policy carried in the file is "V2", which does not meet the version update direction rule configured on the terminal (rollback is prohibited). Based on this, the terminal generates a failure reason code "version direction not satisfied". The terminal calculates the policy proof digest for this time together with the file digest, forms a failure proof record, and reports it to the management center. After receiving it, the management center can locate the corresponding distribution action according to the session identifier and confirm that the object verified by the terminal is consistent with the object distributed by the management center according to the file digest. Thus, the failure is attributed to the triggering of the version direction rule, rather than the transmission of tampered or forged files.

[0035] In this embodiment, step S4 is used to generate proof information that can be verified by the management center, so as to support the management center in determining whether the policy content expressed by the unified policy description file has been loaded and entered the effective state on the terminal side. The unified policy description file is the policy carrier issued by the management center, and the terminal uses it to complete parsing, loading and execution. The policy proof data is a set of evidence data collected by the terminal around the loading and effective process. The current policy proof summary is the result obtained by the terminal concatenating and encoding the policy proof data according to the preset field order and then calculating the hash. It is used to bind multiple pieces of evidence into a whole identifier, so as to facilitate the management center to recalculate and compare and make consistency judgments accordingly.

[0036] The policy proof data is collected by the terminal at the policy's effective time and during the policy's subsequent runtime. The policy's effective time refers to the point at which the terminal's internal policy state changes from "loading complete" to "effective and running." The terminal triggers data collection immediately after this state change to avoid ambiguity caused by the loading result and the effective state being in different contexts. Data collection during the runtime refers to the terminal continuously collecting the state of controlled objects related to policy execution according to a preset period after the policy enters effective and running phase. This is used to cover state drift scenarios during operation, such as configurations being rewritten by other components, rules being overridden, or constraints becoming invalid due to changes in resource states. The length of the runtime is not limited to a specific value and can be configured locally by the terminal or distributed with policy parameters. The terminal can include a set of snapshots formed by multiple collections within the period into the proof data, or form a merged representation, such as using the latest snapshot as the standard or forming a summary of the snapshot set to adapt to communication and storage overhead.

[0037] The policy proof data contains at least four elements: a file digest of the unified policy description file, a policy loading result code on the terminal side, a policy effectiveness status flag, and a snapshot of the controlled object's status related to policy execution. The file digest uniquely identifies the content of the unified policy description file, facilitating the identification of the policy version used by the terminal. The loading result code, returned by the terminal's policy loading module, reflects the results and failure types of the parsing, verification, and attachment processes; the meaning of this result code is pre-agreed upon between the management center and the terminal. The effectiveness status flag, output by the terminal's policy state machine, distinguishes between "received / loaded" and "generated." "Effect" is used to avoid misjudging a state that has not yet taken effect as one that has taken effect; the state snapshot of the controlled object is used to reflect the actual state of the controlled object after the policy takes effect. The controlled object can be the system resources, configuration items, rule sets, processes / services or other controllable objects that the policy is to constrain; to ensure that the snapshot is verifiable, the terminal should generate the association information of "policy rule - controlled object - status item" when loading the policy, so as to prove that the collection module determines the objects and status items to be collected based on this, and adopts a deterministic organization method for object records, such as sorting by object identifier, to avoid inconsistencies in subsequent summaries due to differences in traversal order.

[0038] The terminal concatenates and encodes the aforementioned policy proof data according to a preset field order, then calculates a hash to obtain the policy proof digest. The preset field order and encoding rules are pre-agreed upon by the management center and the terminal and can be versioned and fixed to ensure that different terminals and operating environments obtain a consistent byte sequence for the same proof data. The concatenation encoding should not be limited to simple string concatenation; it should adopt a disambiguating field-based organization method to ensure that the boundaries of each field are clear and reproducible. For fields containing multiple object records, such as controlled object state snapshots, the terminal first performs deterministic sorting and then encodes according to a stable structure to prevent identical state sets from being affected by other data. Changes in arrangement lead to changes in the digest; after hashing, the terminal can carry the policy proof data and the current policy proof digest when reporting. The management center will recalculate and compare them according to the same rules: if the digests are consistent, it means that the proof data has not been spliced ​​incorrectly or tampered with during transmission and storage; on this basis, the management center will make a judgment by combining the loading result code, the effective status mark and the controlled object status snapshot with the requirements of the unified policy description file, so as to determine whether the policy has been loaded on the terminal side and entered the effective state according to the content expressed in the unified policy description file, and can promptly detect the continuous effectiveness anomaly through subsequent snapshot changes during the operating cycle.

[0039] For example: After the management center issues a unified policy description file, the terminal calculates the file digest; when loading is successful, the loading result code is recorded as 0, and the effective status flag is set to 1 when the policy enters the effective runtime; the terminal collects a snapshot of the controlled object's status at the effective time, which includes several key status items of the object, such as the current value of a configuration item, whether a rule set contains a specified entry, and whether the status of a controlled service meets the constraints. The terminal encodes the data according to the agreed field order and calculates the hash to obtain the policy proof digest. After receiving it, the management center recalculates and finds that it is consistent. It can then combine the result code, status flag, and snapshot content to determine that the policy has been loaded and is effective; if the snapshot collected during the runtime shows that the object status has been rewritten, the terminal generates a new proof digest and reports it. The management center uses this to identify the policy's continued effectiveness anomaly and enters the handling process.

[0040] In this embodiment, step S5 is used to organize multiple terminal policy proof records into a verifiable digest chain, which is used by the management center in S6 to verify continuity by using the relationship between adjacent records, thereby discovering record insertion, deletion, replacement and replay. The terminal policy proof record is a record unit that is generated and reported / retained by the terminal in sequence. The record includes: the current policy proof digest obtained in S4 (used to bind policy proof data), policy version identifier (representing the policy version or policy instance on which the terminal is based), session identifier (to distinguish a continuous running context or a chain segment, to avoid confusion with the old chain after restart), monotonic sequence (monotonically increasing within the same session identifier range, used to characterize the order), and two digest fields: the previous record digest written to the current record and the record digest of the current record itself.

[0041] When a terminal generates the current record, it first reads the record digest of the previous terminal policy proof record and writes it as the preceding record digest into the current record. If it is the first record of the session, the preceding record digest takes the protocol-defined starting null value to identify the start of the chain segment. The record digest of the previous record is not a single field, but is calculated from the "current policy proof digest, policy version identifier, session identifier, and monotonic sequence" in the previous record to simultaneously bind the proof content, version attribution, session boundary, and sequence semantics. Subsequently, the terminal performs deterministic concatenation encoding and hash calculation on the "previous record digest + current policy proof digest + policy version identifier + session identifier + monotonic sequence" according to the preset field order to obtain the current record digest and write it into the current record. To ensure recalculation consistency in the management center, the field order and encoding rules must be pre-agreed and remain deterministic. The monotonic sequence should strictly increase within the same session. Session switching is isolated by the session identifier. The terminal can save the session and sequence state in a recoverable manner or generate a new session identifier after restarting to avoid sequence rollback within the same session.

[0042] In S6, the management center verifies two adjacent records: it checks whether the previous record summary in the subsequent record is equal to the record summary of the previous record, and recalculates the record summaries of the two records according to the same rules to confirm that the record content has not been modified; at the same time, it checks for out-of-order, duplicate sequences, or backtracking within the same session by combining the session identifier and monotonic sequence; thus, once an insertion or deletion occurs, the chain will not be able to be connected at the break point; replacement will cause inconsistencies in recalculation or subsequent records will not be able to be connected; replaying old chain segments usually manifests as an inability to connect with the latest record summary already saved by the management center, or an abnormal sequence within the same session.

[0043] In this embodiment, the monotonic sequence used in step S6 is generated by the terminal-side monotonic counter to ensure that the terminal policy proof records have reliable sequential semantics within the session corresponding to the same session identifier. This supports the management center's judgment on the continuity of the digest chain and replay risk in S6. The monotonic sequence is the sequence field written into the terminal policy proof record; the session identifier is used to distinguish between a continuous running context or a proof chain segment; the monotonic counter provides a sequence value that only increases and never decreases; the current policy proof digest is still the digest obtained by deterministically concatenating and encoding the policy proof data and calculating the hash in S4. In this embodiment, it is used to bind the counter's abnormal state so that it can be recalculated and recorded by the management center.

[0044] The monotonic counter is stored in a trusted execution environment, trusted platform module, or secure element, which provides an interface for retrieving values ​​that only increment and never decrement. The terminal's software can only retrieve the value and cannot write to or roll back the counter state. Within the same session corresponding to the same session identifier, the terminal calls this interface to obtain a new monotonic sequence and writes it to the record for each terminal policy proof record generated. The monotonic sequence, along with the session identifier, policy version identifier, and the current policy proof digest, participates in the record digest calculation, ensuring that the order and content of the records are simultaneously locked by the digest chain. To avoid sequence mismatch caused by concurrency, the terminal organizes the "retrieve sequence - write record - calculate record digest - write to disk / report" process into a serialized process unit within the record generation module. If necessary, a queue or mutual exclusion mechanism is used to ensure that only one generation process calls the counter interface at any given time, thereby ensuring a one-to-one correspondence between the monotonic sequence and the record.

[0045] When a terminal detects a monotonic counter reset, wraparound, or unavailability, it not only reports an alarm but also encodes the abnormal state into the current policy proof digest and immediately reports it to the management center. This binds the abnormality and the current policy proof data to the same digest. Reset / wraparound can be determined by comparing the most recently successfully acquired monotonic sequence value with the current return value: if the new value is not greater than the old value, it is considered that there is a risk of reset or wraparound. "Unavailability" is manifested by the trusted environment / secure element interface returning an abnormality, timeout, or inability to provide a valid sequence value. Once the terminal enters an abnormal state, it writes a counter abnormality flag into the subsequent policy proof data, such as distinguishing between reset, wraparound, and unavailability by enumeration, and includes this flag in the concatenation encoding range of S4, thus entering the current policy proof digest. At the same time, it immediately generates and reports the corresponding terminal policy proof record, which is convenient for the management center to mark the session segment as low trust or trigger further verification in S6.

[0046] For example: In a session, the counter returns 100, 101, and 102 in sequence. If it returns 5 next time, the terminal can determine that the new value is not greater than the old value, write an anomaly flag to the counter, and include it in the current policy proof digest before reporting it. When the management center verifies the digest chain, even if the chain structure can still be connected, it can determine that the trust foundation of the chain segment has been affected based on the anomaly flag, thereby taking stricter measures for subsequent records.

[0047] In this embodiment, the management center performs a consistency check on the terminal policy proof record reported by the terminal in step S6. This is to confirm that the record is indeed the policy version and session context issued this time, and that it is continuously connected to the end of the proof chain stored by the management center. This helps to identify the risk of policy rollback, proof replay, or proof chain tampering. The policy version identifier is stored by the management center in the issuance record and is used to represent the policy version that is currently required to take effect. The session identifier is generated and stored by the management center for this issuance and is used to lock the proof chain segment corresponding to this issuance. The monotonic sequence should strictly increase within the same session identifier range. The previous record digest is used to point to the record digest of the previous terminal policy proof record. The management center saves the previous record digest as the chain continuity comparison benchmark.

[0048] To enable operable verification, the management center maintains a minimum state associated with each distribution at the terminal level, including: the policy version identifier, session identifier, and the record summary and monotonic sequence position of the most recently verified record in that session segment. When a terminal reports a record, the management center reads the policy version identifier, session identifier, monotonic sequence, and previous record summary (including the record summary if necessary) and compares them: First, it verifies that the policy version identifier matches the distributed record, ensuring that the terminal is proving the current version rather than a rolled-back version; second, it verifies that the session identifier matches the session identifier generated in this distribution, ensuring that the record belongs to the current distribution session. To prevent the replay of historical session segments, the following measures are taken: First, ensure that the session identifiers are consistent. Second, verify that the monotonic sequence is strictly incremental relative to the previously stored sequence to detect replays of the same session, out-of-order execution, or disruption of sequential semantics. Third, verify that the previous record summary in the record matches the previous record summary stored in the management center to verify the continuity of the summary chain and prevent insertion, deletion, replacement, or segment splicing. The management center can also recalculate the record summary according to agreed rules to confirm that the record summary is indeed calculated from "previous record summary + current policy proof summary + policy version identifier + session identifier + monotonic sequence" to simultaneously cover chain continuity and record content integrity.

[0049] The management center will output an anomaly verification result and determine that there is a risk of policy rollback, proof replay, or proof chain tampering when any of the following situations occur: the policy version identifier matches but the session identifier does not match; the session identifier matches but the previous record digest cannot be connected with the stored previous record digest, resulting in a chain break; or the monotonic sequence is not increasing within the same session. For example: The management center saves the session chain tail digest as H10 and the tail sequence as 10; if the terminal reports the same version but the session identifier is different, it will directly fall into session mismatch; if the session identifier is the same but the preceding record digest is not equal to H10, it is a chain break; if the preceding record digest matches H10 but the sequence is 10 or smaller, it is a non-incrementing session, and the abnormal verification result should be output.

[0050] In this implementation, the rollback protection action is triggered after the management center outputs the anomaly verification result in S6. The processing objects are the terminal corresponding to the anomaly verification result, the unified policy description file, and the terminal policy proof record reported by the terminal. To ensure that subsequent actions can be verified, the management center first associates and solidifies the anomaly verification result with the corresponding terminal policy proof record. The association and solidification includes establishing an anomaly event record for the terminal on the management center side, and writing the policy version identifier, session identifier, verification item that triggered the anomaly, and record summary of the terminal policy proof record into the record, thereby locking the source of the anomaly to a specific record node.

[0051] Subsequently, the management center issues a rollback blocking instruction to the terminal. The rollback blocking instruction includes the target policy version identifier. After receiving the instruction, the terminal enters the blocking process: The terminal first stops executing the policy content that is in effect in the current session and switches the policy execution engine to the blocking state. In the blocking state, the terminal retains only the minimum operational capabilities required for resynchronizing the unified policy description file, generating terminal policy proof records, and interacting with the management center, preventing the terminal from continuing to expand the proof records on the abnormal chain segment. After the terminal completes the blocking, the management center marks the terminal as restricted. The restricted state is written into the terminal management table as a terminal status field on the management center side, and the resource access control module is linked to converge the range of accessible resources of the terminal. The convergence is performed based on the "terminal-resource set" mapping rule. The mapping rule is maintained by the management center and can be applied by terminal grouping or role grouping. After the terminal is set to restricted state, its resource access requests are clipped to the restricted set on the resource side or network side according to the mapping rule.

[0052] After the blocking and restricted states are established, the management center requires the terminal to re-fetch the unified policy description file. This requirement is achieved by issuing a resynchronization command, which carries the binding information of the policy version identifier and the session identifier. This allows the terminal to load the policy content in the new session context and regenerate the terminal policy proof record. After the terminal completes the re-fetching, it regenerates the terminal policy proof record according to the S3, S4, and S5 process and reports it to the management center. The management center performs the S6 consistency check on the newly reported record again. If the check passes, the terminal is switched from the restricted state back to the normal state. If the check fails, the restricted state is maintained and the terminal re-enters the fallback protection process.

[0053] The audit storage uses an append-only method to save rollback-related facts. The append-only write unit includes the anomaly verification result, the corresponding terminal policy proof record, and the anomaly event record identifier generated by the management center. After writing, existing entries are not overwritten or modified in situ, so that the complete sequence of "anomaly occurrence - blocking - restriction - re-pulling - verification" can be restored during subsequent tracing. To ensure the continuity of proof across sessions, the management center uses the "record digest of the last terminal policy proof record that passed verification" in the audit storage as the starting point of the new session chain in subsequent verifications: when the management center generates a new session identifier for the terminal, the starting point of the chain is recorded as the session baseline digest along with the session information; when the terminal generates the first terminal policy proof record in the new session, the session baseline digest is written as the preceding record digest, so that the new session chain segment and the passing node of the previous session form a traceable connection at the digest level.

[0054] For example: When a terminal reports a terminal policy proof record within a session with session identifier A, an anomaly occurs where "policy version identifier matches but session identifier does not match". After the management center outputs the anomaly verification result, it writes the anomaly verification result and the record summary of the record into the anomaly event record and issues a rollback blocking instruction requiring the terminal to switch to the policy corresponding to policy version identifier V2. At the same time, the terminal is placed in a restricted state and its accessible resource range is narrowed. After the terminal re-fetches the unified policy description file corresponding to V2, it generates a new terminal policy proof record and reports it. After the management center verifies it, it writes the anomaly verification result, the original anomaly record, and the newly passed record into the audit storage in an append-only manner, and uses the record summary of the newly passed record as the chain start point for the next session of the terminal. Example

[0055] like Figure 2 As shown, this embodiment further improves upon the design of Embodiment 1. The difference lies in the fact that, in the actual operation of Embodiment 1, it was found that the session context corresponding to the session identifier of some target terminals may be lost after weak network conditions, offline reconnection, or abnormal restarts. Furthermore, the monotonic sequence may have the risk of wrapping around or resetting, potentially leading to duplicate reporting of terminal policy proof records for old sessions or old policy versions. This results in chain-like association breaks or monotonic sequence anomalies in the consistency verification of S6 by the management center, making it difficult to distinguish between "normal network packet loss / restart recovery" and "malicious replay / rollback," easily triggering false rollbacks or missed detections. It fails to stably achieve strong consistency closed-loop and anti-replay / anti-rollback capabilities for policy-based proofs under complex network and restart scenarios. Therefore, the terminal security management method based on a unified policy provided in this embodiment also includes: Add step S2a after S2: Session challenge confirmation and session key binding; S2a: After the management center sends the unified policy description file to the target terminal and generates a session identifier, it further generates a session challenge value and session validity / replay window parameters for the session. The session challenge value is then bound to the policy version identifier and the digest (e.g., hash) of the unified policy description file and sent to the target terminal. The target terminal generates a session confirmation response based on the local trusted identifier (e.g., device certificate / security chip key) and sends it back to the management center. The management center only marks the session identifier as "confirmed and verifiable session" when it receives the session confirmation response and the verification passes, and records the session binding factor corresponding to the session for subsequent verification of the authenticity and freshness of the proof record.

[0056] Add step S3a after S3: Session anchoring and monotonic sequence anti-wrapback; S3a: After the target terminal passes the verification in S3 and the policy is loaded and taken effect, the policy version identifier, session identifier, and the current monotonic sequence initial value are written into the trusted persistent area, and a session anchoring record corresponding to the session is generated and saved. The initial value of the monotonic sequence is generated by the terminal's trusted monotonic source, such as a monotonic counter or protected counting logic in secure storage, and can still monotonically increase after the terminal restarts. When generating the terminal policy proof record subsequently, the monotonic sequence is incremented based on the trusted monotonic source. If a wrapback / rollback is detected, the terminal refuses to continue generating proof records in the session and triggers an alarm report.

[0057] Add step S4a after S4: Prove the hierarchical summary of data and the index for on-demand forensics; S4a: After collecting policy proof data, the target terminal, in addition to calculating the policy proof summary for this time, also divides the policy proof data into multiple proof fragments according to preset dimensions, calculates fragment summaries for each proof fragment, and further constructs a hierarchical summary structure. For example, it constructs a summary tree with fragment summaries as leaves, and uses the root summary of this hierarchical summary structure as the enhanced policy proof summary for this time. At the same time, the target terminal retains the index relationship between fragment summaries and original proof fragments so that the management center can extract and verify them as needed.

[0058] Add step S6a after S6: Session recovery and sampling review for anomaly verification; S6a: When the consistency check fails in S6, in addition to triggering the rollback protection action, the management center also initiates a session recovery / evidence challenge to the target terminal, requiring the target terminal to report the session anchoring record and the proof fragment corresponding to the fragment summary specified by the management center and its integrity proof; the management center verifies whether the terminal has experienced session wraparound / rollback based on the session anchoring record, and verifies the authenticity of the policy proof data based on the sampled proof fragment; only when the session recovery and sampling verification still fail, the management center executes the rollback protection action to prevent the abnormal policy state from continuing to take effect. Example

[0059] like Figure 3 As shown, based on the same inventive concept as the terminal security management method based on a unified policy in the foregoing embodiments, this application provides a terminal security management system based on a unified policy. The system and method embodiments in this application are based on the same inventive concept. The system includes: Unified Policy Module: The management center generates a unified policy description file and a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. Policy delivery module: The management center delivers the unified policy description file to the target terminal and generates a session identifier for this delivery, which is used to mark this policy delivery and verification process; Policy verification module: After the target terminal receives the unified policy description file, it verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. Policy acquisition module: After the policy content takes effect, the target terminal acquires policy proof data and calculates the policy proof summary based on the policy proof data; Proof Record Module: The target terminal generates a terminal policy proof record, which includes a previous record summary, a current policy proof summary, a policy version identifier, a session identifier, and a monotonic sequence. The previous record summary is used to form a chain association with the previous terminal policy proof record, and the monotonic sequence is used to characterize the order of terminal policy proof records within the same session.

[0060] Consistency verification module: The target terminal reports the terminal policy proof record to the management center; the management center performs consistency verification on the terminal policy proof record based on the policy version identifier and the session identifier, and verifies the chain association and the monotonic sequence; when the verification fails, the management center triggers rollback protection to prevent the abnormal policy state from continuing to take effect.

[0061] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

[0062] The above description is merely a preferred embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present application, based on the technical solution and concept of the present application, should be covered within the scope of protection of the present application.

Claims

1. A terminal security management method based on a unified policy, characterized in that, The methods include: The management center generates a unified policy description file and a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. The management center sends the unified policy description file to the target terminal and generates a session identifier for this policy issuance and verification process. After receiving the unified policy description file, the target terminal verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. After the policy content takes effect, the target terminal collects policy proof data and calculates the policy proof summary based on the policy proof data. The target terminal generates a terminal policy proof record; The target terminal reports the terminal policy proof record to the management center; the management center performs a consistency check on the terminal policy proof record based on the policy version identifier and the session identifier, and checks the chain association and the monotonic sequence; when the check fails, the management center triggers a rollback protection measure to prevent the abnormal policy state from continuing to take effect.

2. The terminal security management method based on a unified policy according to claim 1, characterized in that, The unified policy description file includes a policy content area and a metadata area; the metadata area includes a policy version identifier, a session identifier generation rule marker, a file generation timestamp, and a signature field; the management center performs a hash calculation on the policy content area and the metadata area to obtain a file digest, and signs the file digest using the management center's private key, writing the signature result into the signature field, thereby enabling the terminal to verify the source and integrity of the unified policy description file.

3. The terminal security management method based on a unified policy according to claim 1, characterized in that, The verification includes: The terminal extracts the signature field and file digest calculation rules of the unified policy description file, recalculates the file digest, and verifies the signature using the management center's public key. After successful verification, the terminal further verifies the format validity of the policy version identifier and the session identifier, and verifies whether the policy version identifier meets the terminal's version update direction rules. When the verification fails, the terminal refuses to load the policy content and generates a failure proof record to report to the management center. The policy proof digest of the failure proof record is calculated by combining the failure reason code and the file digest.

4. The terminal security management method based on a unified policy according to claim 1, characterized in that, The policy proof data is collected by the terminal at the time the policy takes effect and during the subsequent operating cycle. The policy proof data includes: a file digest of the unified policy description file, a policy loading result code on the terminal side, a policy effective status flag, and a snapshot of the status of controlled objects related to policy execution. The terminal concatenates and encodes the policy proof data according to a preset field order and then calculates a hash to obtain the current policy proof digest. This allows the management center to determine whether the policy has been loaded on the terminal side and entered the effective state according to the content expressed in the unified policy description file based on the current policy proof digest.

5. The terminal security management method based on a unified policy according to claim 1, characterized in that, The preceding record digest is calculated from the record digest of the previous terminal policy proof record. The record digest is calculated from the current policy proof digest, policy version identifier, session identifier, and monotonic sequence in the previous terminal policy proof record. When the terminal generates the current terminal policy proof record, it writes the preceding record digest into the current record and performs a hash calculation on the preceding record digest, the current policy proof digest, the policy version identifier, the session identifier, and the monotonic sequence to obtain the current record digest. The management center uses the correspondence between two adjacent records to verify the continuity of the digest chain, which is used to detect record insertion, deletion, replacement, and replay.

6. The terminal security management method based on a unified policy according to claim 1, characterized in that, The monotonic sequence is generated by a terminal-side monotonic counter, which provides a sequence value retrieval interface that only increases and never decreases. Within the same session corresponding to the same session identifier, the terminal calls the sequence value retrieval interface to obtain a new monotonic sequence and writes it into the record for each terminal policy proof record generated. When the terminal detects that the monotonic counter is reset, wrapped around, or unavailable, it encodes the abnormal status into the current policy proof summary and reports it to the management center.

7. The terminal security management method based on a unified policy according to claim 1, characterized in that, Consistency verification includes: verifying whether the policy version identifier reported by the terminal is consistent with the policy version identifier in the record issued by the management center; verifying whether the session identifier is consistent with the session identifier generated by the management center for this issuance; verifying that the monotonic sequence is strictly increasing within the same session identifier range; and verifying that the previous record summary matches the previous record summary already stored by the management center. When any of the following situations occur, such as policy version identifier matching but session identifier not matching, session identifier matching but summary chain broken, or monotonic sequence not increasing, the management center outputs an abnormal verification result.

8. The terminal security management method based on a unified policy according to claim 1, characterized in that, The rollback protection process includes the following actions: the management center issues a rollback blocking command to the terminal, causing the terminal to stop executing the current policy content and switch to the policy corresponding to the policy version identifier specified by the management center; the management center marks the terminal as restricted and narrows its accessible resource range; the management center requires the terminal to re-fetch the unified policy description file and regenerate the terminal policy proof record; the management center appends the anomaly verification result and the corresponding terminal policy proof record to the audit storage, and in subsequent verifications, uses the last verified record digest in the audit storage as the starting point of the chain for the new session, so as to achieve traceable proof continuity across sessions.

9. The terminal security management method based on a unified policy according to claim 1, characterized in that, Also includes: Session anchoring and monotonic sequence anti-wrap; proof data hierarchical summarization and on-demand forensics indexing; Session recovery and sampling review for anomaly verification.

10. A terminal security management system based on a unified policy, characterized in that, The system includes: Unified Policy Module: The management center generates a unified policy description file and a policy version identifier corresponding to the unified policy description file; the unified policy description file is used to express the policy content that the terminal needs to execute. Policy delivery module: The management center delivers the unified policy description file to the target terminal and generates a session identifier for this delivery, which is used to mark this policy delivery and verification process; Policy verification module: After the target terminal receives the unified policy description file, it verifies the unified policy description file; if the verification passes, the policy content is loaded into the session corresponding to the session identifier and takes effect. Policy acquisition module: After the policy content takes effect, the target terminal acquires policy proof data and calculates the policy proof summary based on the policy proof data; Proof Record Module: The target terminal generates a terminal policy proof record; Consistency verification module: The target terminal reports the terminal policy proof record to the management center; the management center performs consistency verification on the terminal policy proof record based on the policy version identifier and the session identifier, and verifies the chain association and the monotonic sequence; when the verification fails, the management center triggers rollback protection to prevent the abnormal policy state from continuing to take effect.

Images