Sensitive information desensitization processing method and device based on version snapshot, equipment and medium

Abstract

The application provides a sensitive information desensitization processing method and device based on version snapshots, equipment and medium, comprising: determining a rule version based on the scene identification of the request in the version center, taking the version identification as the rule version snapshot identification; encapsulating the identification of the request as a context object, and storing the context object in the context manager of the current thread; extracting the rule version snapshot identification of the context object in the current thread and passing it to the target thread, and restoring before executing the target thread, so that the target thread and the main thread share the same rule version snapshot identification; in the desensitization execution entrance, based on the rule version snapshot identification of the desensitization context object, the desensitization strategy corresponding to the rule version snapshot identification is used to execute the desensitization operation on the data field to be processed; and the request identification is taken as the primary key record for audit record. To solve the technical problem that the desensitization results are inconsistent in the same request life cycle under the conditions of rule hot update, asynchronous thread propagation and multi-serialization link output in the existing dynamic desensitization scheme.

Description

Technical Field

[0001] This application relates to the technical field of Java application data security, and in particular to methods, apparatus, devices and media for desensitizing sensitive information based on version snapshots. Background Technology

[0002] Existing Java data masking solutions typically employ methods such as custom annotations, AOP / interceptors, field type identification, JSON key extraction, dynamic rule matching in configuration centers, and serializer modifications to achieve data masking for different field types and access scenarios. While these solutions are relatively mature in terms of "how to identify fields and perform data masking," they still have significant shortcomings in runtime consistency control.

[0003] In modern Java applications, a single request often passes through multiple nodes, including the control layer, service layer, thread pool asynchronous tasks, logging aspects, unified return serializers, and gateway filters. Meanwhile, operations teams typically require rules to support real-time hot updates to quickly adjust rules based on compliance requirements, third-party agreements, internal audit requirements, or unexpected risks. If each execution node directly reads the "latest rule" during execution, it's highly likely that the main thread will use the old rules, asynchronous threads will use the new rules, API responses will use one set of rules, and log outputs will use another. Once this happens, the same request will output different anonymized results for the same sensitive field on different processing nodes, leading to difficulties in auditing and tracing, troubleshooting, inconsistent external API results, and escalating compliance risks. Therefore, how to anonymize sensitive information has become a significant technical challenge. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, apparatus, device and medium for sensitive information desensitization processing based on version snapshots. Through a closed-loop mechanism of request-level snapshot freezing, context pass-through, unified entry constraints and full-link audit restoration, it solves the technical problems of inconsistent desensitization results and untraceable rule versions within the life cycle of the same request under the conditions of rule hot update, asynchronous thread propagation and multi-serialization link output.

[0005] This application provides a method for de-identifying sensitive information based on version snapshots. The method includes: When an external request enters the system, the corresponding rule version is determined in the version center that has been established and maintains the de-identification rules based on the scenario identifier of the current request. The version identifier of the rule version is used as the snapshot identifier of the rule version of the current request. The version center generates a unique rule version identifier for each set of de-identification rules and divides the rules into candidate versions, gray versions and official versions according to the version status. The current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier are encapsulated into a de-identification context object. The de-identification context object is stored in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identification context object and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task. When submitting an asynchronous task, the de-identified context object is copied from the context manager of the current thread to form an immutable read-only copy of the de-identified context. The read-only copy of the de-identified context is then passed to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identified context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier. Before each data field output node, the rule version snapshot identifier is read from the current thread's desensitization context object in the desensitization execution entry point. Based on the rule version snapshot identifier, the corresponding version of the desensitization rule is obtained from the version center or read-only rule cache. The desensitization operation is then performed on the data field to be processed based on the desensitization rule. The system uses the request identifier as the primary key to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node.

[0006] In one possible implementation, the scenario identifier based on the current request determines the corresponding rule version in a version center that pre-establishes and maintains de-identification rules, and uses the version identifier of this rule version as the snapshot identifier of the rule version for the current request, including: Identify the application scenario to which the current request belongs, and generate a request identifier, scenario token, and request entry sequence number that uniquely correspond to the current request; The request entry sequence number is compared with the effective start timestamp associated with each rule version to determine the rule version that the current request should use, and the read version pointer is frozen as a rule version snapshot identifier; wherein, the rule version snapshot identifier remains unchanged during the processing of this request, and once frozen, subsequent rule version change operations shall not modify the snapshot.

[0007] In one possible implementation, the step of reading the rule version snapshot identifier from the current thread's desensitization context object at the desensitization execution entry point, and obtaining the corresponding version of the desensitization rule from the version center or read-only rule cache based on the rule version snapshot identifier, and performing desensitization operation on the data field to be processed based on the desensitization rule, includes: For each data field to be processed, the de-identification strategy is determined by matching the corresponding version of the rule set, based on the application scenario identifier, field name, and rule version snapshot identifier in the context object. The data fields are processed according to the matched de-identification strategy, and information about the processing is recorded. If no de-identification strategy is found, the preset processing strategy will be used to perform de-identification processing within the rule set range defined by the same rule version snapshot identifier.

[0008] In one possible implementation, after performing a desensitization operation on the data field to be processed based on the desensitization rules, the sensitive information desensitization processing method further includes: In response to a rule version change request, generate a candidate version and perform verification; After the verification is passed, the candidate version is switched to a grayscale version, and the grayscale effective boundary sequence number of the grayscale version is recorded. When the request entry sequence number of a new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the grayscale version of the new request is frozen as its rule version snapshot identifier. When the grayscale version does not trigger the rollback condition within the preset grayscale observation period, the grayscale version is converted into the official version, and the current official version pointer is switched to the official version.

[0009] In one possible implementation, after freezing the grayscale version of the new request to its rule version snapshot identifier when the request entry sequence number of the new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the sensitive information desensitization processing method further includes: When a grayscale anomaly is detected and triggers a rollback, the official pointer or grayscale pointer is switched back, so that new requests arriving after the rollback obtain the rolled-back rule version as a snapshot. Existing requests with frozen rule version snapshots are not affected by the rollback and continue to use their frozen rule version snapshots to complete the processing.

[0010] In one possible implementation, the verification performed on the candidate version includes at least: Syntax validation, conflict validation with existing rules in the same scenario, and output difference validation based on a preset sample set.

[0011] In one possible implementation, the abnormal condition that triggers the rollback includes: If at least one of the following occurs during the grayscale period: the desensitization failure rate, the rule hit missing rate, or the scene recovery failure rate, the failure rate exceeds a preset threshold.

[0012] This application also provides a sensitive information desensitization processing device based on version snapshots, the sensitive information desensitization processing device comprising: The rule version center module is used to determine the corresponding rule version based on the scenario identifier of the current request in the version center that has been established and maintains the de-identification rules when an external request enters the system. The version identifier of the rule version is used as the rule version snapshot identifier of the current request. The version center generates a unique rule version identifier for each set of de-identification rules and divides the rules into candidate versions, gray versions and official versions according to the version status. The context management module is used to encapsulate the current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier into a de-identified context object, and store the de-identified context object in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identified context object, and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task. The cross-thread propagation module is used to copy the de-identified context object from the context manager of the current thread when submitting an asynchronous task, forming an immutable read-only copy of the de-identified context, and pass the read-only copy of the de-identified context to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identified context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier. The unified desensitization execution module is used to read the rule version snapshot identifier from the desensitization context object of the current thread at the desensitization execution entry point before each data field output node, and obtain the corresponding version of the desensitization rule from the version center or read-only rule cache according to the rule version snapshot identifier, and perform desensitization operation on the data field to be processed based on the desensitization rule; The audit log module is used to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node, with the request identifier as the primary key.

[0013] This application also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the sensitive information desensitization processing method based on version snapshots described above are performed.

[0014] This application also provides a computer-readable storage medium storing a computer program, which, when run by a processor, performs the steps of the sensitive information desensitization processing method based on version snapshots as described above.

[0015] This application provides a sensitive information desensitization processing method, apparatus, device, and medium based on version snapshots. The sensitive information desensitization processing method includes: when an external request enters the system, determining the corresponding rule version based on the scenario identifier of the current request in a version center that has pre-established and maintains desensitization rules, and using the version identifier of the rule version as the rule version snapshot identifier of the current request; wherein, the version center generates a unique rule version identifier for each set of desensitization rules, and divides the rules into candidate versions, grayscale versions, and official versions according to the version status; encapsulating the scenario identifier, request identifier, request entry sequence number, and the rule version snapshot identifier of the current request into a desensitization context object, storing the desensitization context object in the context manager of the current thread for access by the current thread, and when a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the desensitization context object, and before the target thread executes the derived execution task, the read-only copy is... The copy is restored to the context manager of the target thread; when submitting an asynchronous task, the de-identification context object is copied from the context manager of the current thread to form an immutable read-only copy of the de-identification context, and the read-only copy of the de-identification context is passed to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identification context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier; before each data field output node, the rule version snapshot identifier is read from the de-identification context object of the current thread at the de-identification execution entry point, and the corresponding version of the de-identification rule is obtained from the version center or read-only rule cache according to the rule version snapshot identifier, and the de-identification operation is performed on the data field to be processed based on the de-identification rule; the current request scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node are recorded with the request identifier as the primary key. By implementing a closed-loop mechanism of request-level snapshot freezing, context pass-through, unified entry constraints, and end-to-end audit restoration, this solution addresses the technical issues of inconsistent desensitization results and untraceable rule versions within the lifecycle of a single request under conditions of hot rule updates, asynchronous thread propagation, and multi-serialization link output.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a sensitive information desensitization method based on version snapshots provided in this application embodiment; Figure 2 This is one of the structural schematic diagrams of a sensitive information desensitization processing device based on a version snapshot provided in an embodiment of this application; Figure 3 This is a second schematic diagram of a sensitive information desensitization processing device based on version snapshots provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0020] First, the applicable application scenarios for this application will be introduced. This application can be applied to the technical field of Java application data security.

[0021] Research has revealed that in modern Java applications, a single request often passes through multiple nodes, including the control layer, service layer, thread pool asynchronous tasks, logging aspects, unified return serializers, and gateway filters. Meanwhile, operations teams typically require rules to support real-time hot updates to quickly adjust rules based on compliance requirements, third-party agreements, internal audit requirements, or unforeseen risks. If each execution node directly reads the "latest rule" during execution, it's highly likely that the main thread will use the old rules, asynchronous threads will use the new rules, API responses will use one set of rules, and log outputs will use another. Once this happens, the same request will output different anonymized results for the same sensitive field on different processing nodes, leading to difficulties in auditing and tracing, troubleshooting, inconsistent external API results, and escalating compliance risks. Therefore, how to anonymize sensitive information has become a significant technical challenge.

[0022] Based on this, this application provides a sensitive information de-identification processing method based on version snapshots. Through a closed-loop mechanism of request-level snapshot freezing, context pass-through, unified entry constraints, and full-link audit restoration, it solves the technical problems of inconsistent de-identification results and untraceable rule versions within the lifecycle of the same request under the conditions of rule hot updates, asynchronous thread propagation, and multi-serialization link output in existing dynamic de-identification schemes.

[0023] Please see Figure 1 , Figure 1 This is a flowchart illustrating a sensitive information desensitization method based on version snapshots, provided as an embodiment of this application. Figure 1 As shown in the figure, the sensitive information desensitization processing method provided in this application embodiment includes: S101: When an external request enters the system, the corresponding rule version is determined in the version center that has been established and maintains the de-identification rules based on the scenario identifier of the current request. The version identifier of the rule version is used as the snapshot identifier of the rule version of the current request. The version center generates a unique rule version identifier for each set of de-identification rules and divides the rules into candidate versions, gray versions and official versions according to the version status.

[0024] In this step, when a request arrives at the system entry point, the scenario identifier to which the current request belongs is identified, a unique request identifier and request entry sequence number are generated for the request, the current official version pointer or the version pointer hit by the gray-scale route is read through the version center, and the read version pointer is frozen as a rule version snapshot identifier.

[0025] The rule version snapshot identifier remains unchanged during this request processing, and once the freeze is completed, subsequent version change operations must not modify this snapshot.

[0026] Here, the version center generates a unique rule version identifier for each set of de-identification rules, divides the rules into candidate versions, grayscale versions and official versions according to the version status, and configures effective boundary metadata for each version. The effective boundary metadata is used to identify from which request entry time the version becomes visible to new requests; establishes the previous version association relationship between versions, and maintains the current official version pointer, the current grayscale version pointer and the historical version index.

[0027] It should be noted that for the same scenario identifier, the version center can store multiple rule versions generated in chronological order, but each specific request only freezes and uses one of the rule versions. Candidate status, grayscale status, and official status represent different stages in the release lifecycle of the same rule version, and the same rule version can only have one version status at any given time.

[0028] Here, the process of establishing the version center for masking rules is as follows: The rule center generates a unique `rule_version_id` (rule version identifier) ​​for each set of masking rules, and marks the rule version as `candidate`, `gray` (grayscale state), or `official` (official state) through `version_state` (version status). Each set of rules includes at least `scene_code` (scene identifier), `field_match_rule` (field matching rule), `field_priority` (field priority), `strategy_id` (mask-down strategy identifier), `version_state` (version status), `effective_scope` (effective scope), `create_time` (creation time), `update_time` (update time), `rollback_pointer` (rollback pointer), and `version_epoch` (version generation identifier). Version chain relationship establishment: When the version center receives a request to add, modify, or delete a rule, it does not directly overwrite the official version, but instead generates a new candidate version and saves the association relationship with the previous official version's `predecessor_version` (preceding version identifier) ​​for subsequent grayscale, rollback, and historical restoration. Version Index Maintenance: The system maintains `current_official_pointer` (pointer to the current official version), `current_gray_pointer` (pointer to the current grayscale version), and `historical_version_index` (historical version index) for quick querying of the current official version, the currently effective version for a specified scenario, historical versions, and rollback target versions. Activation Boundary Metadata Maintenance: Each version entering grayscale or official status is marked with `activate_boundary_epoch` (activation boundary time identifier) ​​or `activate_boundary_seq` (activation boundary sequence number) to identify "from which request entry point can new requests read this version." This boundary is crucial for ensuring that subsequent requests "only affect new requests." Candidate Versions Do Not Take Effect Directly: No candidate version may be directly referenced by business requests before passing verification, preventing rule errors from directly impacting online requests.

[0029] In one possible implementation, the scenario identifier based on the current request determines the corresponding rule version in a version center that pre-establishes and maintains de-identification rules, and uses the version identifier of this rule version as the snapshot identifier of the rule version for the current request, including: A: Identify the application scenario to which the current request belongs, and generate a request identifier, scenario token, and request entry sequence number that uniquely correspond to the current request.

[0030] Here, the system identifies the current access scenario (scene_code) in the control layer or unified entry filter, such as production display scenario, third-party interface parameter output scenario, internal log scenario, and cache write scenario. It generates a unique identifier for this request (request_id), a unique scene token (scene_token), and the sequence number or boundary number (request_enter_seq) when this request entered the system.

[0031] B: Based on the comparison between the request entry sequence number and the effective start timestamp associated with each rule version, determine the rule version that the current request should use, and freeze the read version pointer as the rule version snapshot identifier; the rule version snapshot identifier remains unchanged during the processing of this request, and once frozen, subsequent rule version change operations must not modify this snapshot.

[0032] Here, the request entry sequence number is read from the version center either the current_official_pointer or the version pointer hit by the canary route, and frozen as a rule_version_snapshot (rule version snapshot identifier). The rule version identifier pointed to by the current_official_pointer (current official version pointer) or the rule version identifier hit by the canary route is read from the version center and frozen as a rule_version_snapshot (rule version snapshot identifier). After freezing, this rule version snapshot identifier remains unchanged until the end of this request. Once the request has completed freezing the rule version snapshot identifier, subsequent version upgrades, canary transitions, and rollbacks must not modify the already frozen rule version snapshot identifier for this request.

[0033] S102: Encapsulate the current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier into a de-identification context object. Store the de-identification context object in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identification context object and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task.

[0034] In this step, the current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier are encapsulated into a de-identification context object. The de-identification context object is stored in the current thread's context manager, so that the main thread and its derived execution tasks can access the de-identification context object.

[0035] Here, the process of constructing the request-level desensitization context object is as follows: Context object encapsulation: The system constructs a unified `DesensitizeContext` (desensitization context object), encapsulating fields such as `scene_code` (scene identifier), `scene_token` (scene token), `request_id` (request identifier), `rule_version_snapshot` (rule version snapshot identifier), `request_enter_seq` (request entry sequence number), `create_time` (creation time), `node_path` (node ​​path), and `tenant_id` (tenant identifier). Immutable snapshot design: In `DesensitizeContext`, the scene identifier, scene token, request identifier, request entry sequence number, rule version snapshot identifier, and tenant identifier, which are directly related to consistency, are set as immutable fields; the creation time is written once when the context is created; the node path is recorded using an append-only, non-overwrite method. This avoids accidental modification of business code during processing. Two-layer binding: The system writes `DesensitizeContext` to both the thread-level context manager and the request scope / chain context container, allowing business processing nodes in the current thread to read it. When submitting an asynchronous task, the context propagation component retrieves a read-only copy of the context object from the current thread's context manager. This ensures convenient access for the main thread while supporting subsequent task wrapping and retrieval. Lifecycle management: The context is initialized at the start of a request and cleaned up uniformly after the request completes. If the request terminates abnormally, a `finally` block must also be executed to prevent subsequent requests from being polluted when threads are reused. The process of passing the desensitized context across threads and asynchronous tasks is as follows: Task packaging trigger conditions: Whenever an asynchronous task is submitted to the thread pool, a parallel subtask is created, a callback task is registered, or a delayed task is delayed during business processing, the task is packaged by an independent context propagation component. The context propagation component extracts a read-only copy of the desensitized context from the context manager of the current thread that submitted the task, and restores this read-only copy to the context manager of the target thread before the target thread executes the task; after the task is executed, the desensitized context in the target thread is cleaned up. Main thread snapshot extraction: During the packaging process, the rule version snapshot identifier of DesensitizeContext is extracted from the current main thread, and asynchronous tasks are not allowed to reread the latest rules before execution. Target thread recovery: Before the asynchronous task is executed, scene_code (scene identifier), request_id (request identifier), scene_token (scene token), and rule_version_snapshot (rule version snapshot identifier) ​​are restored in the target thread to ensure that they are completely consistent with those of the main thread.

[0036] Thread pool reuse and pollution prevention: After an asynchronous task finishes execution, the context in the target thread must be cleaned up to prevent thread pool reuse from causing the next task to read a snapshot and scenario of the previous request. Missing data recovery protection: If the target thread finds that the context is empty or the fields are incomplete during recovery, it should not be allowed to directly degrade to reading the latest rules, but should trigger protective fallbacks, such as outputting audit warnings, using conservative fallback strategies, or refusing to perform data masking. S103: When submitting an asynchronous task, copy the de-identified context object from the current thread's context manager to form an unmodifiable read-only copy of the de-identified context, and pass the read-only copy of the de-identified context to the target thread along with the asynchronous task; before the target thread executes the asynchronous task, restore the read-only copy of the de-identified context to the target thread's context manager, so that the target thread and the main thread hold the same rule version snapshot identifier.

[0037] In this step, when an asynchronous task is triggered during request processing, a read-only copy of the immutable data structure stored in the main thread is extracted, and before the asynchronous task is executed, this read-only copy is fully injected into the target execution environment that executes the asynchronous task. Asynchronous tasks include tasks scheduled by the thread pool, delayed tasks, parallel branch tasks, and tasks triggered by external callbacks.

[0038] S104: Before each data field output node, read the rule version snapshot identifier from the current thread's desensitization context object in the desensitization execution entry point, and obtain the corresponding version of the desensitization rule from the version center or read-only rule cache according to the rule version snapshot identifier, and perform desensitization operation on the data field to be processed based on the desensitization rule.

[0039] In this step: all sensitive information output units in the request processing chain are configured to perform desensitization strategy location and execution only based on the fixed rule version snapshot contained in the immutable data structure, and to prohibit access to the latest dynamically updated rules in the rule version center.

[0040] In one possible implementation, the step of reading the rule version snapshot identifier from the current thread's desensitization context object at the desensitization execution entry point, and obtaining the corresponding version of the desensitization rule from the version center or read-only rule cache based on the rule version snapshot identifier, and performing desensitization operation on the data field to be processed based on the desensitization rule, includes: a: For each data field to be processed, the de-identification strategy is determined by matching the application scenario identifier, field name, and rule version snapshot identifier in the context object from the rule set of the corresponding version.

[0041] Here, the unified desensitization execution entry point locates the corresponding rule for each field to be processed according to the three-element condition "scene_code + field_key + rule_version_snapshot".

[0042] b: Process the data fields according to the matched desensitization strategy and record the processing information; if no desensitization strategy is matched, perform desensitization processing within the rule set range defined by the same rule version snapshot identifier using the preset processing strategy.

[0043] Here, regardless of whether the field is processed in the main thread or an asynchronous thread, in the interface parameters or log output, as long as the ternary condition is the same, it should be located in the same snapshot version rule set and identified as the same strategy_id (de-identification strategy identifier). If no explicit match is found in the rule set corresponding to rule_version_snapshot (rule version snapshot identifier), then the preset processing strategy is applied, which must still be limited to the current snapshot version.

[0044] In one possible implementation, at the desensitization execution entry point, the rule version snapshot identifier is read from the desensitization context object of the current thread, and based on the rule version snapshot identifier, the corresponding version of the desensitization rule is obtained from the version center or read-only rule cache. After performing desensitization operation on the data field to be processed based on the desensitization rule, the sensitive information desensitization processing method further includes: (1): In response to a rule version change request, generate a candidate version and perform verification.

[0045] Here, when the version center receives a request to add, modify, or delete a rule, it generates a new candidate_rule_version and establishes a version link with the previous official version.

[0046] (2): After the verification is passed, the candidate version is switched to the grayscale version and the grayscale effective boundary sequence number of the grayscale version is recorded.

[0047] Here, the verification performed on the candidate version includes at least: syntax verification, conflict verification with existing rules in the same scenario, and output difference verification based on a preset sample set.

[0048] (3): When the request entry sequence number of a new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing strategy, the grayscale version of the new request is frozen as its rule version snapshot identifier.

[0049] Here, after the candidate version passes verification, it enters the gray (grayscale state) and generates a gray_activate_boundary_seq (grayscale activation boundary sequence number). In implementations using time boundaries, a gray_activate_boundary_epoch (grayscale activation boundary time identifier) ​​can also be generated. This embodiment uses the sequence number as the grayscale activation boundary. When request_enter_seq (request entry sequence number) is greater than or equal to gray_activate_boundary_seq (grayscale activation boundary sequence number), and the request conforms to the grayscale routing policy, the rule version identifier of the grayscale version is frozen as rule_version_snapshot (rule version snapshot identifier); requests that do not reach the grayscale activation boundary or do not match the grayscale routing policy continue to use the original official version.

[0050] (4): When the grayscale version does not trigger the rollback condition within the preset grayscale observation period, the grayscale version is converted into the official version, and the current official version pointer is switched to the official version.

[0051] Here, when a grayscale version does not exhibit any abnormal indicators exceeding thresholds such as desensitization failure rate, rule hit missing rate, or scene recovery failure rate within a preset grayscale observation period, the version_state of that grayscale version is updated from gray to official, and the current_official_pointer is switched to this version, while the original current_gray_pointer becomes invalid. From the effective boundary of this official version, new requests arriving in the same scenario afterward will by default freeze the rule version identifier of this official version as the rule version snapshot identifier; existing requests that have already completed snapshot freezing will continue to use the original rule version snapshot identifier.

[0052] In one possible implementation, after freezing the grayscale version of the new request to its rule version snapshot identifier when the request entry sequence number of the new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the sensitive information desensitization processing method further includes: When a grayscale anomaly is detected and triggers a rollback, the official pointer or grayscale pointer is switched back, so that new requests arriving after the rollback obtain the rolled-back rule version as a snapshot. Existing requests with frozen rule version snapshots are not affected by the rollback and continue to use their frozen rule version snapshot identifiers to complete the processing.

[0053] Here, when an abnormal condition is detected during the operation of the grayscale version, a rollback operation is performed. The rollback operation is constructed to adjust only the version pointed to by the official pointer or the grayscale pointer, without changing the de-identification execution logic of any existing requests for fixed rule version snapshots.

[0054] In a specific implementation, the abnormal triggering conditions are as follows: If, during the gray-scale phase, the anonymization failure rate, rule hit missing rate, scene recovery failure rate, difference rate of the same field in the same scene, or other preset abnormal indicators exceed the threshold, an automatic rollback judgment is triggered. Rollback object limitations: Automatic rollback essentially modifies the "official version pointer or gray-scale version pointer visible at the new request entry point," rather than modifying the rule_version_snapshot (rule version snapshot identifier) ​​already frozen in existing requests. Existing request protection: Any request that enters the system before the gray-scale boundary, or whose snapshot identifier has been frozen during the gray-scale phase, will continue to be processed according to its original rule version snapshot identifier, even if a rollback is triggered; mid-process switching is not allowed. When the system performs a rollback, it records the following fields: rollback_from_version (version identifier before rollback), rollback_to_version (target version identifier for rollback), rollback_reason_code (rollback reason code), rollback_time (rollback time), affected_new_request_scope (scope of new requests affected), and preserved_inflight_request_count (number of requests in transit that retain the original snapshot identifier).

[0055] In one possible implementation, the abnormal condition that triggers the rollback includes: at least one of the following: the desensitization failure rate during grayscale, the rule hit missing rate, or the scene recovery failure rate exceeds a preset threshold.

[0056] S105: Record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node, using the request identifier as the primary key.

[0057] In this step, after the request is processed, audit information is recorded using the request identifier as an index. The audit information includes at least: the business scenario, the fixed rule version snapshot identifier, the identifier of the de-identification strategy used, the node type that performed the de-identification operation, the execution environment identifier, a marker indicating whether it is in a grayscale state, a marker indicating whether a rollback has occurred, and a summary of the result of the de-identification operation.

[0058] In specific implementations, the audit primary key is as follows: For each request, at least the following data is recorded as the primary key: scene_code (scene identifier), scene_token (scene token), rule_version_snapshot (rule version snapshot identifier), strategy_id (de-identification strategy identifier), node_id (node ​​identifier), thread_id (thread identifier), execute_time (execution time), and result_digest (de-identification result summary). If the request hits a grayscale version, gray_flag (grayscale flag) and gray_version_id (grayscale version identifier) ​​are recorded; if the request occurs during a rollback, rollback_flag (rollback flag) and rollback_to_version (rollback target version identifier) ​​are recorded. The system supports restoring the pass-through chain from the main thread to the child thread. Result summary recording: The system does not need to save the plaintext of sensitive information in the audit, but should record the summary before and after de-identification, the hit strategy number, field identifier, exception reason code, and strategy flag.

[0059] This application provides a sensitive information de-identification method based on version snapshots. The method includes: when an external request enters the system, determining the corresponding rule version based on the scenario identifier of the current request in a version center that pre-establishes and maintains de-identification rules, and using the version identifier of this rule version as the rule version snapshot identifier of the current request; wherein, the version center generates a unique rule version identifier for each set of de-identification rules, and classifies the rules into candidate versions, grayscale versions, and official versions according to their version status; encapsulating the scenario identifier, request identifier, request entry sequence number, and the rule version snapshot identifier of the current request into a de-identification context object, storing the de-identification context object in the context manager of the current thread for access by the current thread; when a derived execution task is generated, a cross-thread propagation component extracts a read-only copy of the de-identification context object, and before the target thread executes the derived execution task, restores the read-only copy... The de-identification context object is copied from the current thread's context manager when an asynchronous task is submitted, forming an immutable read-only copy of the de-identification context. This read-only copy is then passed to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identification context is restored to the target thread's context manager, ensuring that the target thread and the main thread hold the same rule version snapshot identifier. Before each data field output node, the rule version snapshot identifier is read from the current thread's de-identification context object at the de-identification execution entry point. Based on the rule version snapshot identifier, the corresponding version of the de-identification rule is retrieved from the version center or read-only rule cache. De-identification operations are then performed on the data fields to be processed based on the de-identification rule. The current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node are recorded using the request identifier as the primary key. By implementing a closed-loop mechanism of request-level snapshot freezing, context pass-through, unified entry constraints, and end-to-end audit restoration, this solution addresses the technical issues of inconsistent desensitization results and untraceable rule versions within the lifecycle of a single request under conditions of hot rule updates, asynchronous thread propagation, and multi-serialization link output.

[0060] Please see Figure 2 , Figure 3 , Figure 2 1. A schematic diagram of one of the structures of a sensitive information desensitization processing device based on a version snapshot provided in this application embodiment; 2. A schematic diagram of another of the structures of a sensitive information desensitization processing device based on a version snapshot provided in this application embodiment. Figure 2 As shown, the sensitive information desensitization processing device 200 based on version snapshots includes: The rule version center module 210 is used to determine the corresponding rule version based on the scenario identifier of the current request in the version center that has been established and maintains the de-identification rules when an external request enters the system, and use the version identifier of the rule version as the snapshot identifier of the rule version of the current request; wherein, the version center generates a unique rule version identifier for each set of de-identification rules, and divides the rules into candidate versions, gray versions and official versions according to the version status; The context management module 220 is used to encapsulate the current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier into a de-identified context object, and store the de-identified context object in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identified context object, and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task. The cross-thread propagation module 230 is used to copy the de-identified context object from the context manager of the current thread when submitting an asynchronous task, forming an immutable read-only copy of the de-identified context, and passing the read-only copy of the de-identified context to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identified context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier. The unified desensitization execution module 240 is used to read the rule version snapshot identifier from the desensitization context object of the current thread in the desensitization execution entry before each data field output node, and obtain the corresponding version of the desensitization rule from the version center or read-only rule cache according to the rule version snapshot identifier, and perform desensitization operation on the data field to be processed based on the desensitization rule; The audit log module 250 is used to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node, with the request identifier as the primary key.

[0061] Furthermore, the rule version center module 210 is used to determine the corresponding rule version based on the scenario identifier of the current request in the version center that has been pre-established and maintains the de-identification rules, and uses the version identifier of the rule version as the snapshot identifier of the rule version of the current request: Identify the application scenario to which the current request belongs, and generate a request identifier, scenario token, and request entry sequence number that uniquely correspond to the current request; The request entry sequence number is compared with the effective start timestamp associated with each rule version to determine the rule version that the current request should use, and the read version pointer is frozen as a rule version snapshot identifier; wherein, the rule version snapshot identifier remains unchanged during the processing of this request, and once frozen, subsequent rule version change operations shall not modify the snapshot.

[0062] Furthermore, the unified de-identification execution module 240 is used to read the rule version snapshot identifier from the de-identification context object of the current thread at the de-identification execution entry point, and obtain the corresponding version of the de-identification rule from the version center or read-only rule cache according to the rule version snapshot identifier, and perform de-identification operation on the data field to be processed based on the de-identification rule: For each data field to be processed, the de-identification strategy is determined by matching the corresponding version of the rule set, based on the application scenario identifier, field name, and rule version snapshot identifier in the context object. The data fields are processed according to the matched de-identification strategy, and information about the processing is recorded. If no de-identification strategy is found, the preset processing strategy will be used to perform de-identification processing within the rule set range defined by the same rule version snapshot identifier.

[0063] Furthermore, such as Figure 3 As shown, the sensitive information desensitization processing device 200 based on version snapshots also includes a candidate version verification module 260, which is used for: In response to a rule version change request, generate a candidate version and perform verification; After the verification is passed, the candidate version is switched to a grayscale version, and the grayscale effective boundary sequence number of the grayscale version is recorded. When the request entry sequence number of a new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the grayscale version of the new request is frozen as its rule version snapshot identifier. When the grayscale version does not trigger the rollback condition within the preset grayscale observation period, the grayscale version is converted into the official version, and the current official version pointer is switched to the official version.

[0064] Furthermore, such as Figure 3 As shown, the sensitive information desensitization processing device 200 based on version snapshots also includes an automatic rollback module 270, which is used for: When a grayscale anomaly is detected and triggers a rollback, the official pointer or grayscale pointer is switched back, so that new requests arriving after the rollback obtain the rolled-back rule version as a snapshot. Existing requests with frozen rule version snapshots are not affected by the rollback and continue to use their frozen rule version snapshots to complete the processing.

[0065] This application provides a sensitive information de-identification processing device based on version snapshots. The device includes: a rule version center module, used to determine the corresponding rule version in a pre-established version center that maintains de-identification rules based on the scenario identifier of the current request when an external request enters the system, and use the version identifier of this rule version as the rule version snapshot identifier of the current request; wherein, the version center generates a unique rule version identifier for each set of de-identification rules, and divides the rules into candidate versions, grayscale versions, and official versions according to their version status; and a context management module, used to encapsulate the scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier of the current request into a de-identification context object, store the de-identification context object in the context manager of the current thread for access by the current thread, and when a derived execution task is generated, a cross-thread propagation component extracts a read-only copy of the de-identification context object, and restores the read-only copy to the target thread before the target thread executes the derived execution task. The process's context manager includes: a cross-thread propagation module, used to copy the de-identification context object from the current thread's context manager when submitting an asynchronous task, forming an immutable read-only copy of the de-identification context, and passing this read-only copy to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identification context is restored to the target thread's context manager, ensuring that the target thread and the main thread hold the same rule version snapshot identifier; a unified de-identification execution module, used to read the rule version snapshot identifier from the current thread's de-identification context object at the de-identification execution entry point before each data field output node, and obtain the corresponding version of the de-identification rule from the version center or read-only rule cache based on the rule version snapshot identifier, and perform de-identification operations on the data fields to be processed based on the de-identification rule; and an audit log module, used to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node, using the request identifier as the primary key. By implementing a closed-loop mechanism of request-level snapshot freezing, context pass-through, unified entry constraints, and end-to-end audit restoration, this solution addresses the technical issues of inconsistent desensitization results and untraceable rule versions within the lifecycle of a single request under conditions of hot rule updates, asynchronous thread propagation, and multi-serialization link output.

[0066] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0067] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430. When the machine-readable instructions are executed by the processor 410, they can perform the operations described above. Figure 1 The steps of the sensitive information desensitization processing method based on version snapshots in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0068] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the sensitive information desensitization processing method based on version snapshots in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0069] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0070] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

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

[0072] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0073] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for desensitizing sensitive information based on version snapshots, characterized in that, The sensitive information desensitization processing method includes: When an external request enters the system, the corresponding rule version is determined in the version center that has been established and maintains the de-identification rules based on the scenario identifier of the current request. The version identifier of the rule version is used as the snapshot identifier of the rule version of the current request. The version center generates a unique rule version identifier for each set of de-identification rules and divides the rules into candidate versions, gray versions and official versions according to the version status. The current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier are encapsulated into a de-identification context object. The de-identification context object is stored in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identification context object and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task. When submitting an asynchronous task, the de-identified context object is copied from the context manager of the current thread to form an immutable read-only copy of the de-identified context. The read-only copy of the de-identified context is then passed to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identified context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier. Before each data field output node, the rule version snapshot identifier is read from the current thread's desensitization context object in the desensitization execution entry point. Based on the rule version snapshot identifier, the corresponding version of the desensitization rule is obtained from the version center or read-only rule cache. The desensitization operation is then performed on the data field to be processed based on the desensitization rule. The system uses the request identifier as the primary key to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node.

2. The sensitive information desensitization processing method according to claim 1, characterized in that, The scenario identifier based on the current request determines the corresponding rule version in the version center that maintains the pre-established de-identification rules, and uses the version identifier of this rule version as the snapshot identifier of the rule version for the current request, including: Identify the application scenario to which the current request belongs, and generate a request identifier, scenario token, and request entry sequence number that uniquely correspond to the current request; The request entry sequence number is compared with the effective start timestamp associated with each rule version to determine the rule version that the current request should use, and the read version pointer is frozen as a rule version snapshot identifier; wherein, the rule version snapshot identifier remains unchanged during the processing of this request, and once frozen, subsequent rule version change operations shall not modify the snapshot.

3. The sensitive information desensitization processing method according to claim 1, characterized in that, The step of reading the rule version snapshot identifier from the current thread's desensitization context object at the desensitization execution entry point, and obtaining the corresponding version of the desensitization rule from the version center or read-only rule cache based on the rule version snapshot identifier, and performing desensitization operation on the data field to be processed based on the desensitization rule, includes: For each data field to be processed, the de-identification strategy is determined by matching the corresponding version of the rule set, based on the application scenario identifier, field name, and rule version snapshot identifier in the context object. The data fields are processed according to the matched de-identification strategy, and information about the processing is recorded. If no de-identification strategy is found, the preset processing strategy will be used to perform de-identification processing within the rule set range defined by the same rule version snapshot identifier.

4. The sensitive information desensitization processing method according to claim 1, characterized in that, After performing a desensitization operation on the data field to be processed based on the desensitization rules, the sensitive information desensitization processing method further includes: In response to a rule version change request, generate a candidate version and perform verification; After the verification is passed, the candidate version is switched to a grayscale version, and the grayscale effective boundary sequence number of the grayscale version is recorded. When the request entry sequence number of a new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the grayscale version of the new request is frozen as its rule version snapshot identifier. When the grayscale version does not trigger the rollback condition within the preset grayscale observation period, the grayscale version is converted into the official version, and the current official version pointer is switched to the official version.

5. The sensitive information desensitization processing method according to claim 4, characterized in that, When the request entry sequence number of a new request is greater than or equal to the grayscale effective boundary sequence number and conforms to the grayscale routing policy, the grayscale version of the new request is frozen as its rule version snapshot identifier. The sensitive information desensitization processing method further includes: When a grayscale anomaly is detected and triggers a rollback, the official pointer or grayscale pointer is switched back, so that new requests arriving after the rollback obtain the rolled-back rule version as a snapshot. Existing requests with frozen rule version snapshots are not affected by the rollback and continue to use their frozen rule version snapshots to complete the processing.

6. The sensitive information desensitization processing method according to claim 4, characterized in that, The checks performed on candidate versions should include at least the following: Syntax validation, conflict validation with existing rules in the same scenario, and output difference validation based on a preset sample set.

7. The sensitive information desensitization processing method according to claim 5, characterized in that, The abnormal conditions that trigger the rollback include: If at least one of the following occurs during the grayscale period: the desensitization failure rate, the rule hit missing rate, or the scene recovery failure rate, the failure rate exceeds a preset threshold.

8. A sensitive information desensitization processing device based on version snapshots, characterized in that, The sensitive information desensitization processing device includes: The rule version center module is used to determine the corresponding rule version based on the scenario identifier of the current request in the version center that has been established and maintains the de-identification rules when an external request enters the system. The version identifier of the rule version is used as the rule version snapshot identifier of the current request. The version center generates a unique rule version identifier for each set of de-identification rules and divides the rules into candidate versions, gray versions and official versions according to the version status. The context management module is used to encapsulate the current request's scenario identifier, request identifier, request entry sequence number, and rule version snapshot identifier into a de-identified context object, and store the de-identified context object in the current thread's context manager for access by the current thread. When a derived execution task is generated, the cross-thread propagation component extracts a read-only copy of the de-identified context object, and restores the read-only copy to the target thread's context manager before the target thread executes the derived execution task. The cross-thread propagation module is used to copy the de-identified context object from the context manager of the current thread when submitting an asynchronous task, forming an immutable read-only copy of the de-identified context, and pass the read-only copy of the de-identified context to the target thread along with the asynchronous task. Before the target thread executes the asynchronous task, the read-only copy of the de-identified context is restored to the context manager of the target thread, so that the target thread and the main thread hold the same rule version snapshot identifier. The unified desensitization execution module is used to read the rule version snapshot identifier from the desensitization context object of the current thread at the desensitization execution entry point before each data field output node, and obtain the corresponding version of the desensitization rule from the version center or read-only rule cache according to the rule version snapshot identifier, and perform desensitization operation on the data field to be processed based on the desensitization rule; The audit log module is used to record the current request's scenario identifier, rule version snapshot identifier, hit strategy identifier, grayscale marker, rollback marker, and execution summary of each output node, with the request identifier as the primary key.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the sensitive information desensitization processing method based on any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the sensitive information desensitization processing method based on any one of claims 1 to 7.

Images