A method and system for managing customer information lifecycle with data security

Abstract

The application relates to a customer information lifecycle management method and system for guaranteeing data security, which comprises the following steps: acquiring customer information and splitting the customer information into multiple data shards, independently encrypting the data shards and storing the data shards into a lifecycle storage area; constructing a lifecycle state machine instance, binding a security policy set to each lifecycle state; collecting access behavior features and environment context features, combining a current lifecycle state and attribute dimensions to generate a risk feature vector and output a risk level score, and migrating to a target lifecycle state and re-encrypting according to the risk level score; receiving a data sharing request, analyzing a sharing purpose label and a target attribute set, extracting and desensitizing the attribute set after screening through a purpose attribute mapping table, combining the attribute set into a shared data package, and sending the shared data package after adding a purpose constraint contract; erasing the data shards after the effective time period expires, calculating summary values of the lifecycle storage areas, generating a destruction proof chain by sequentially hashing and linking the summary values, and writing the destruction proof chain into a ledger. The application realizes safe and controllable customer information lifecycle management.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a method and system for managing the customer information lifecycle to ensure data security. Background Technology

[0002] With the advancement of enterprise digital transformation and the popularization of data-driven business, customer information, as a core data asset, is widely collected and stored in business scenarios such as enterprise operations, marketing promotion, risk control analysis, and compliance auditing. Customer information typically includes various types of data such as customer identity information, transaction records, behavioral preferences, and contact information. While providing business value to enterprises, this data also faces severe security challenges. Currently, enterprises generally adopt a centralized storage architecture in customer information management, storing customer information as a complete data block in a single storage area, using a unified encryption strategy to protect the overall data. In the data sharing stage, the original customer information data or anonymized data is directly provided to the requesting party, and in the data destruction stage, a simple deletion operation is performed to consider the data destroyed.

[0003] However, in practical applications, customer information is stored as a whole in a single storage area. Once this storage area is accessed without authorization, the entire customer information will be leaked. Furthermore, using the same encryption strength for all data means that some high-value data cannot receive protection commensurate with its security requirements. Moreover, security policies are fixed after configuration. When data faces risks such as abnormal access patterns or changes in the external security environment during storage, the security protection level cannot match the real-time risk situation; the data maintains the original protection level even when the risk increases. This static protection model becomes even more problematic after data enters the sharing stage. The scope of data requested by the requester is usually determined by manual approval or simple rules, failing to precisely limit the sharing scope based on the purpose of data use. Requesters may obtain data beyond actual business needs, and shared data lacks usage period constraints and secondary circulation controls; the sharing recipient can retain and forward the data to third parties indefinitely. When data reaches the end of its lifecycle, the simple deletion operation usually used only removes the storage index and cannot completely erase the data content in the storage area. The data can still be read through data recovery methods, and the destruction results lack auditable verification methods, so it cannot be proven that the data has been completely destroyed. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a customer information lifecycle management method and system for ensuring data security.

[0005] Firstly, this application provides a customer information lifecycle management method and system to ensure data security, employing the following technical solution: A method for customer information lifecycle management to ensure data security, the method comprising: Customer information is obtained, split into multiple data shards according to attribute dimensions, each data shard is independently encrypted and stored in the corresponding lifecycle storage area, and a mapping index table between the data shards is generated. A lifecycle state machine instance is constructed based on the mapping index table. The data shards are bound to the lifecycle state machine instance and the lifecycle states are initialized. A set of security policies is bound to each lifecycle state. The access behavior characteristics and environmental context characteristics of the data shards are collected in the lifecycle storage area, and a risk feature vector is generated by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The risk feature vector is input into a preset risk assessment model, and a risk level score is output. The data shards are migrated to the target lifecycle state based on the risk level score, and the data shards are re-encrypted and stored according to the security policy set bound to the target lifecycle state. Receive a data sharing request, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and the preset purpose attribute mapping table; Based on the filtered target attribute set, the corresponding data fragments are extracted from the currently stored data fragments according to the mapping index table and desensitization processing is performed to obtain the desensitized data fragments; The de-identified data fragments are combined into a shared data packet, a usage constraint contract including a valid duration field is constructed and attached to the shared data packet, and then sent to the sharing target party; When the validity period field expires, the data fragments currently stored are wiped according to the mapping index table, and the digest value of each wiped lifecycle storage area is calculated. The digest values ​​are then hashed and linked sequentially to generate a destruction proof chain, which is written into the destruction record ledger.

[0006] By adopting the above technical solutions, customer information is split into independently encrypted data fragments according to attribute dimensions and stored in a distributed manner, reducing the risk of complete customer information leakage when a single storage area is attacked; based on the lifecycle state machine instance binding security policy set, the data fragments have differentiated protection levels at different stages, and the protection level is dynamically adjusted with threats through risk assessment-driven state migration and re-encryption; in the sharing stage, the scope of information exposure is controlled by using usage tags for filtering and de-identification, and the usage period of shared data is constrained by the effective duration field; in the destruction stage, all data fragments are located by mapping index table, erased, and a destruction proof chain is generated and written to the ledger, providing tamper-proof destruction evidence.

[0007] Secondly, this application provides a customer information lifecycle management system to ensure data security, which adopts the following technical solution: The sharded encrypted storage module is used to obtain customer information, split it into multiple data shards according to attribute dimensions, encrypt each data shard independently and store it in the corresponding lifecycle storage area, and generate a mapping index table between the data shards. The state machine construction module is used to construct a lifecycle state machine instance based on the mapping index table, bind the data shards to the lifecycle state machine instance and initialize the lifecycle state, and bind a set of security policies to each lifecycle state. The risk feature generation module is used to collect access behavior features and environmental context features of the data shards in the lifecycle storage area, and generate a risk feature vector by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The risk assessment module is used to input the risk feature vector into a preset risk assessment model and output a risk level score. The state transition encryption module is used to migrate the data fragments to the target lifecycle state according to the risk level score, and to re-encrypt and store the data fragments according to the security policy set bound to the target lifecycle state. A data sharing request processing module is used to receive data sharing requests, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and a preset purpose attribute mapping table; The data extraction and desensitization module is used to extract the corresponding data fragments from the currently stored data fragments based on the filtered target attribute set and according to the mapping index table, and perform desensitization processing to obtain the desensitized data fragments. The shared data sending module is used to combine the de-identified data fragments into a shared data packet, construct a usage constraint contract including a valid duration field and attach it to the shared data packet, and send it to the sharing target party; The data destruction proof module is used to perform an erasure operation on the currently stored data fragments according to the mapping index table when the effective duration field expires, calculate the digest value of each erased lifecycle storage area, hash and link the digest values ​​in sequence to generate a destruction proof chain, and write it into the destruction record ledger.

[0008] Thirdly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect.

[0009] In summary, this application offers at least one of the following beneficial technical effects: Customer information is fragmented and independently encrypted according to attribute dimensions and stored in a distributed lifecycle storage area, preventing overall data leakage when a single storage area is attacked; state migration and re-encryption are driven by a risk assessment model, allowing security policies to dynamically adjust with changing risks; usage constraint contracts containing a valid duration field are constructed for shared data to prevent data from being accessed beyond its scope and forwarded without restriction; multiple rounds of overwrite erasure are performed during the destruction phase, generating a hash link proof chain, making the destruction results verifiable and auditable. In practical applications, this solution addresses the security protection and compliance traceability issues of customer information in storage, operation, sharing, and destruction, helping to meet regulatory requirements in the data security field for data security, including data remaining on-site, verifiable destruction, and traceable sharing. Attached Figure Description

[0010] Figure 1 This is a first flowchart illustrating a customer information lifecycle management method for ensuring data security, according to one embodiment of this application.

[0011] Figure 2 This is a second flowchart illustrating a customer information lifecycle management method for ensuring data security, according to one embodiment of this application.

[0012] Figure 3 This is a schematic diagram of the third process of a customer information lifecycle management method for ensuring data security, which is one embodiment of this application.

[0013] Figure 4 This is a schematic diagram of the fourth process of a customer information lifecycle management method for ensuring data security, according to one embodiment of this application.

[0014] Figure 5 This is a schematic diagram of the fifth process of a customer information lifecycle management method for ensuring data security, according to one embodiment of this application.

[0015] Figure 6This is a schematic diagram of the sixth process of a customer information lifecycle management method for ensuring data security, according to one embodiment of this application.

[0016] Figure 7 This is a schematic diagram of the seventh process of a customer information lifecycle management method for ensuring data security, according to one embodiment of this application. Detailed Implementation

[0017] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figures 1-7 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0018] This application discloses a method for managing the customer information lifecycle to ensure data security.

[0019] Reference Figure 1 A customer information lifecycle management method to ensure data security, specifically including: Step S101: Obtain customer information, split it into multiple data shards according to attribute dimensions, encrypt each data shard independently and store it in the corresponding lifecycle storage area, and generate a mapping index table between the data shards. Customer information refers to the entire set of customer-related data collected and processed by an enterprise during its business operations, including customer identity information, transaction records, behavioral preferences, and contact information. Attribute dimensions refer to the criteria for classifying data according to its business attributes, such as categorizing customer information by identity attributes, transaction attributes, behavioral attributes, and contact attributes. Data shards refer to the independent subsets of data obtained by splitting a complete dataset according to attribute dimensions; each shard contains only data content within the same attribute dimension. Lifecycle storage areas refer to independent physical or logical storage spaces allocated to data shards at different lifecycle stages, with each storage area isolated from the others. The mapping index table is an index structure that records the correspondence between each data shard and the lifecycle storage area, allowing the location of any data shard within its storage area.

[0020] Specifically, after acquiring customer information, it is split into multiple data shards according to attribute dimensions. Each data shard contains only data content of the same attribute dimension. Each data shard is then independently encrypted using symmetric encryption algorithms such as AES-256 or SM4. Each data shard uses a separate encryption key, ensuring that a leak of a single key will not affect the security of other data shards. The encrypted data shards are stored in their respective lifecycle storage areas, with independent access permissions between each storage area. After storage, a mapping index table is generated between the data shards, recording the identifier of each data shard, its attribute dimension, its storage area location, and the relationships between shards.

[0021] For example, in a bank customer information management scenario, customer information includes identity information (name, ID number), account information (account number, balance), transaction information (transaction history, records), and contact information (telephone number, address). The system splits this into four data shards and encrypts them independently before storing them in four lifecycle storage areas. The mapping index table records the identifier, attribute dimensions, storage location, and relationships of the four shards, so that subsequent operations can accurately locate each shard through the mapping index table.

[0022] Step S102: Construct a lifecycle state machine instance based on the mapping index table, bind data shards to the lifecycle state machine instance and initialize lifecycle states, and bind a security policy set to each lifecycle state; In this context, a lifecycle state machine instance refers to a data lifecycle management model built upon finite state machine theory, used to describe and control the entire state transition of data fragments from creation to destruction. A lifecycle state refers to the current stage of a data fragment's lifecycle, including initial state, active state, dormant state, archived state, and pending destruction state. A security policy set refers to the set of security control rules bound to a specific lifecycle state, including parameters such as encryption strength, access permissions, and audit granularity; different lifecycle states correspond to different security policy sets.

[0023] Specifically, a lifecycle state machine instance is constructed based on the mapping index table. Each data shard recorded in the mapping index table is bound to the lifecycle state machine instance, allowing the lifecycle state machine instance to uniformly manage the state changes of each data shard. After binding, a lifecycle state is initialized for each data shard, with the initial state being the default. Subsequently, a security policy set is bound to each lifecycle state. For example, the security policy set for the initial state is set to standard encryption strength and restricted access, the security policy set for the active state is set to enhanced encryption strength and business access, and the security policy set for the archived state is set to the highest encryption strength and audit-only access.

[0024] For example, a customer identity information shard is initially bound to a lifecycle state machine instance and initialized to the initial state. The security policy set of the initial state adopts AES-256 encryption and internal system access only. When the shard enters the active state, the security policy set is adjusted to AES-256 encryption and business system access, allowing business processes to read the shard data.

[0025] Step S103: Collect access behavior characteristics and environmental context characteristics of data shards in the lifecycle storage area, and generate a risk feature vector by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. Access behavior characteristics refer to behavioral pattern data generated when accessing the lifecycle storage area, including access frequency, access time distribution, access source, and access operation type (read / write / delete). Environmental context characteristics refer to the context information of the operating environment of the data shard, including the current time period (working or non-working time), system load status, and network security level. The risk feature vector is a multi-dimensional feature representation generated by combining access behavior characteristics and environmental context characteristics with the current lifecycle state and attribute dimensions, used to quantify the risk level currently faced by the data shard.

[0026] Specifically, access behavior characteristics and environmental context characteristics of data shards are collected from the lifecycle storage area. Collection methods include reading storage area access logs, monitoring system operating status, and obtaining network environment indicators. Based on the collected access behavior characteristics and environmental context characteristics, a risk feature vector is generated by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The current lifecycle state determines the risk baseline level, which differs under different states; the attribute dimensions determine the data sensitivity, with different attribute dimensions having different sensitivity levels. Access behavior characteristics reflect external threats, and environmental context characteristics reflect the environmental security status. The combination of these four types of information generates a comprehensive risk feature vector.

[0027] For example, when a customer transaction information segment is in an active state, the system collects data showing that the segment is frequently read during non-working hours and the network security level is reduced. The system combines these access behavior characteristics and environmental context characteristics with the risk baseline of the active state and the high sensitivity level of the transaction attributes to generate a risk feature vector representing high risk.

[0028] Step S104: Input the risk feature vector into the preset risk assessment model and output the risk level score; The risk assessment model refers to a pre-trained model that maps risk feature vectors to risk level scores. This model is trained using machine learning algorithms (such as random forests or gradient boosting decision trees) based on historical labeled data. The training data includes labeled samples of different risk feature vectors and their corresponding risk levels. The risk level score is a quantitative score output by the risk assessment model, used to represent the current risk level of a data shard.

[0029] Specifically, the generated risk feature vector is input into a pre-set risk assessment model. The model outputs a risk level score through internal multi-layer feature processing and weight calculation. The risk level score is represented in numerical form, such as a score range of 0 to 100, with higher scores indicating higher risk levels.

[0030] In some embodiments, the training process of the risk assessment model includes: extracting multiple access behavior feature and environmental context feature records from a historical security event database; calculating the behavioral anomaly weight, environmental threat weight, state risk baseline weight, and dimensional sensitivity level weight for each record to generate historical risk feature vector samples; having security analysts label each record with a corresponding risk level score based on whether it is associated with an actual security event and the severity of the event, forming a labeled sample set; using the labeled sample set to train a random forest model, with model parameters including the number of decision trees, maximum depth, and minimum number of samples per leaf node; and selecting the parameter combination that minimizes the mean squared error of the validation set through cross-validation. The trained model is deployed in the system, receiving a four-dimensional risk feature vector input during runtime, and outputting predicted scores from each decision tree within the model, averaging the results to obtain the final risk level score.

[0031] For example, the training dataset contains 5000 historical access records, of which 800 are associated with actual security incidents. Security analysts assign risk level scores ranging from 60 to 95 points based on the severity of the incidents. The remaining 4200 records without security incidents are assigned scores ranging from 10 to 50 points. The random forest model is configured with 100 decision trees, a maximum depth of 8, and a minimum number of samples per leaf node of 5. The final model is obtained through training with 5-fold cross-validation. When the input risk feature vector is (0.8, 0.7, 0.5, 0.8), the model outputs a risk level score of 85.

[0032] Step S105: Migrate the data fragments to the target lifecycle state according to the risk level score, and re-encrypt and store the data fragments according to the security policy set bound to the target lifecycle state. The target lifecycle state refers to the lifecycle state to which the data shards need to be migrated, determined based on the risk level score. A higher risk level score corresponds to a higher security level lifecycle state. Re-encryption involves re-encrypting the data shards using the encryption algorithm and key specified by the security policy set bound to the target lifecycle state, ensuring the data shards' security level matches the target lifecycle state. After re-encryption, the data shards have updated encryption strength and keys to meet the security level required by the target lifecycle state.

[0033] Specifically, the target lifecycle state is determined based on the risk level score. The risk level score range corresponds to different security level lifecycle states, and data shards are migrated from the current lifecycle state to the target lifecycle state. During the migration, the data shards are re-encrypted according to the security policy set bound to the target lifecycle state, replacing the original encryption with the encryption algorithm and key specified in the security policy set. After re-encryption, the data shard is stored as the currently stored data shard, and its security level has been updated to the security level required by the target lifecycle state. Alternatively, if the lifecycle state of a data shard remains unchanged, re-encryption is unnecessary; the originally encrypted data shard can be directly used as the currently stored data shard.

[0034] For example, if a customer transaction information shard is currently in an active state and has a risk level score of 85, the system determines the target lifecycle state to be archived based on the score, migrates the data shard from the active state to the archived state, and specifies that the security policy set of the archived state uses the SM4 algorithm and an independent key for encryption. The system uses this algorithm and key to re-encrypt and store the data shard.

[0035] Step S106: Receive a data sharing request, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and the preset purpose attribute mapping table; A data sharing request is a message initiated by an external system or business unit to this system to share customer information. The request carries a sharing purpose tag and a target attribute set. The sharing purpose tag is identifying information indicating the purpose of data sharing, such as risk control analysis, marketing recommendations, or compliance auditing. The target attribute set is the set of attribute dimensions corresponding to the data required by the requester, specifying which attribute dimensions the requester needs to obtain. The purpose attribute mapping table is a pre-configured mapping table between purposes and attributes, recording the range of attribute dimensions allowed to be shared under each sharing purpose tag.

[0036] Specifically, upon receiving a data sharing request, the sharing purpose tag and target attribute set are parsed from the request. Subsequently, the target attribute set is filtered based on the security policy set bound to the target lifecycle state, the sharing purpose tag, and a pre-defined purpose attribute mapping table. The filtering process is as follows: based on the sharing purpose tag, the allowed attribute dimension range is found in the purpose attribute mapping table; this range is intersected with the target attribute set; and the intersection result is further constrained according to the sharing control rule parameters in the security policy set to obtain the filtered target attribute set.

[0037] For example, if an external system initiates a data sharing request, with the sharing purpose tagged as "risk control analysis" and the target attribute set as {identity information, transaction information, contact information}, and the allowed attribute range corresponding to "risk control analysis" in the purpose attribute mapping table is {identity information, transaction information}, and the security policy set allows sharing transaction information in archived state, then the filtered target attribute set will be {identity information, transaction information}.

[0038] Step S107: Based on the filtered target attribute set, extract the corresponding data fragments from the currently stored data fragments according to the mapping index table and perform de-identification processing to obtain the de-identified data fragments; In this context, data masking refers to masking, replacing, generalizing, or deleting sensitive information in data fragments, ensuring that the processed data no longer contains the original sensitive content without affecting business operations. Data fragments that have undergone data masking are those whose sensitive fields have been masked or replaced with non-original values.

[0039] Specifically, based on the filtered target attribute set, the data fragments corresponding to the filtered target attribute set are located and extracted from the currently stored data fragments according to the mapping index table. During the extraction process, the location of the lifecycle storage area where the data fragments corresponding to each attribute dimension are located is found through the mapping index table, and the data fragments are read from the corresponding storage area. After extraction, the data fragments are subjected to de-identification processing. De-identification methods include masking ID card numbers (keeping the first 6 and last 4 digits and replacing the middle with asterisks), replacing mobile phone numbers (replacing them with virtual numbers), and generalizing addresses (keeping only the province and city level), etc. After the de-identification processing is completed, the de-identified data fragments are obtained.

[0040] For example, if the filtered target attribute set is {identity information, transaction information}, the system extracts the identity information fragment and transaction information fragment from the currently stored data fragments according to the mapping index table, and masks the ID card number in the identity information fragment to "3201". "1234" retains the transaction amount in the transaction information segment but replaces the counterparty's account, resulting in a de-identified data segment.

[0041] Step S108: Combine the de-identified data fragments into a shared data packet, construct a usage constraint contract including a valid duration field and attach it to the shared data packet, and send it to the sharing target party; The shared data packet is a data packet obtained by assembling de-identified data fragments according to a preset format, and is used to transmit to the sharing target party. The usage constraint contract is a usage constraint protocol attached to the shared data packet, which includes a validity period field to specify the usage period of the shared data; after this period, the data should be destroyed. The sharing target party is the external system or business party that receives the shared data packet.

[0042] In one embodiment of this application, the anonymized data fragments are assembled into a shared data packet according to a preset format. During the assembly process, separators and metadata information are added between each data fragment. A usage constraint contract is then constructed, containing a validity period field. The value of the validity period field is determined based on the shared usage tag and security policy set; for example, the validity period for risk control analysis is set to 72 hours, and the validity period for compliance audit is set to 30 days. The usage constraint contract is appended to the header or footer of the shared data packet, forming a complete shared data packet, which is then sent to the sharing target party.

[0043] For example, the de-identified identity information fragments and transaction information fragments are combined into a shared data packet. The system constructs a usage constraint contract, in which the effective duration field is set to 72 hours. The contract is attached to the header of the shared data packet and sent to the receiving address of the risk control system.

[0044] Step S109: When the validity period field expires, perform an erasure operation on the currently stored data shards according to the mapping index table, calculate the digest value of each erased lifecycle storage area, hash and link each digest value in sequence to generate a destruction proof chain, and write it into the destruction record ledger.

[0045] The erasure operation refers to the irreversible data deletion of data fragments in the lifecycle storage area, including overwrite erasure and encrypted destruction, ensuring that the data fragments cannot be recovered and read. The digest value is the data obtained by calculating the hash digest of the erased lifecycle storage area, used to verify that the storage area has been completely erased. The destruction proof chain is a chain-like proof structure generated by sequentially hashing and linking the digest values ​​of each storage area. That is, the previous digest value is concatenated with the next digest value and then hashed again to form a chain structure. Any tampering with the erased storage area will result in a digest value mismatch, which will be detected by the destruction proof chain. The destruction record ledger is a persistent storage medium that records the destruction proof chain and related destruction information, used to provide auditable destruction evidence.

[0046] Specifically, the destruction process is triggered after the validity period field expires. An erasure operation is performed on the currently stored data fragments according to the mapping index table. The location of each data fragment in the storage area is located through the mapping index table, and the data fragments in each storage area are overwritten and erased to ensure that the data is unrecoverable. After erasure, the digest value of each erased lifetime storage area is calculated, and the hash digest of the erased storage area content is calculated using the SHA-256 algorithm. Then, the digest values ​​of each storage area are hashed sequentially, that is, the previous digest value is concatenated with the next digest value and the hash is calculated again to generate a destruction proof chain. The destruction proof chain is written to the destruction record ledger, which also records information such as the erasure time, the number of erased storage areas, and the validity period field value that triggered the destruction.

[0047] It's important to note that when the validity period field expires, all data fragments recorded in the mapping index table are erased, not just the data fragments corresponding to the shared attribute dimensions. After customer information is split into multiple data fragments by attribute dimension, each fragment logically constitutes a complete set of the same customer information. Erasing only the shared fragments while retaining the unshared fragments would result in incomplete customer information remaining, which could still be pieced together with other information to reconstruct the customer profile. Therefore, after the validity period field expires, the system locates all lifecycle storage areas based on the mapping index table and uniformly erases the data fragments in each storage area. This ensures that all attribute dimension fragments of the customer information are completely destroyed, and the destruction proof chain also covers all storage areas, making any unerased or tampered fragments detectable during the verification process.

[0048] For example, the validity period field of the shared data packet is set to 72 hours. After 72 hours, the system triggers the destruction process, locates the data fragments in the four lifecycle storage areas according to the mapping index table and performs overwrite erasure. SHA-256 digest values ​​are calculated for the four erased storage areas respectively. The four digest values ​​are hashed and linked in sequence to generate a destruction proof chain, which is written into the destruction record ledger as destruction evidence.

[0049] In the above implementation, customer information is split into independently encrypted data fragments based on attribute dimensions and stored in a distributed manner, reducing the risk of complete customer information leakage when a single storage area is attacked; security policy sets are bound to lifecycle state machine instances to enable data fragments to have differentiated protection levels at different stages, and the protection level is dynamically adjusted with threats through risk assessment-driven state migration and re-encryption; in the sharing stage, the scope of information exposure is controlled by using usage tags for filtering and de-identification, and the usage period of shared data is constrained by the effective duration field; in the destruction stage, all data fragments are located by mapping index table, erased, and a destruction proof chain is generated and written to the ledger, providing tamper-proof destruction evidence.

[0050] In practical applications, the above technical solutions help to address the problems of insufficient security at each stage of the customer information lifecycle, lack of usage constraints in the sharing process, and lack of verifiable evidence in the destruction process, thereby achieving secure and controllable full lifecycle management of information and an auditable destruction closed loop.

[0051] As one implementation of lifecycle states and corresponding security policy sets, lifecycle states include initial state, active state, dormant state, archived state and pending destruction state, and security policy sets include encryption strength parameters, access permission parameters, audit granularity parameters, sharing control rule parameters and sharing time limit parameters; The lifecycle states include five stages: initial state, active state, dormant state, archived state, and pending destruction state. The security level of each state increases sequentially from the initial state to the pending destruction state. The initial state is the starting state after the data shard is bound. The active state is the running state when the data shard is called normally by the business process. The dormant state is the low-activity state that the data shard migrates to under the risk level scoring. The archived state is the high-security state that the data shard migrates to under the risk level scoring. The pending destruction state is the state that the data shard enters before destruction after the validity period field expires.

[0052] The security policy set includes five categories of configuration parameters: encryption strength parameters, access permission parameters, audit granularity parameters, sharing control rule parameters, and sharing time limit parameters. Encryption strength parameters determine the encryption algorithm and key length for data fragments; access permission parameters determine the system scope and operational permissions allowed to access data fragments; audit granularity parameters determine the level of detail in access logs; sharing control rule parameters determine the range of allowed shared attributes and anonymization rules for data fragments in shared scenarios; and sharing time limit parameters determine the upper limit of the effective duration of shared data packets and the automatic destruction trigger conditions after expiration. The five lifecycle states, arranged from lowest to highest security level, are: initial state, active state, dormant state, archived state, and pending destruction state. The parameter configuration values ​​in the security policy set bound to each state gradually increase with the security level.

[0053] It's important to note that the names of the active, dormant, and archived states reflect the decreasing accessibility of data shards, not the decreasing value of the data services. In the active state, data shards can be directly accessed and decrypted by business systems, offering the highest accessibility. In the dormant state, access permissions are restricted, reducing accessibility. In the archived state, data shards are subject to the highest encryption strength and the strictest access restrictions, resulting in the lowest accessibility. When the risk level score increases, the external threats to the data shards intensify. The system migrates it to a lower accessibility state, reducing the exposure surface by restricting access and strengthening encryption. Therefore, the higher the risk level score, the lower the accessibility and the stricter the security restrictions. When the risk level score decreases, the external threats subside, and the system reverts the data shard to a higher accessibility state, restoring normal access capabilities to business systems. In traditional data lifecycle management, the migration from active to archived state is triggered by a decrease in access frequency or the passage of time, indicating that the data is no longer used by the business and is transferred to long-term storage. Therefore, in this embodiment, the migration from active to archived state is triggered by an increase in risk level score, indicating that the data enters the highest security protection state due to facing high risk. The two are fundamentally different in terms of migration motivation and state meaning.

[0054] In some embodiments, the specific configurations corresponding to the five lifecycle states—initial state, active state, dormant state, archived state, and pending destruction state—include: (1) Initialize the lifecycle state: Set the lifecycle state of the data shard to the initial state. The security policy set bound to the initial state is configured as the standard encryption strength parameter, internal system access permission parameter and operation-level audit granularity parameter. The initial state represents the beginning of a data shard's lifecycle management process. At this stage, the data shard has been independently encrypted and stored but has not yet been invoked by any business process. The standard encryption strength parameter indicates that a conventional symmetric encryption algorithm (such as AES-256) is used to protect the data shard. The internal system access permission parameter indicates that only internal components of this system are allowed to access the data shard; external business systems cannot access it. The operation-level audit granularity parameter indicates that access logs are recorded at the operation level, recording basic information for each access operation, including the visitor's identifier, access time, operation type, and operation result. For example, after a customer identity information shard completes independent encryption and storage, the system initializes its lifecycle state to the initial state. At this time, the shard is encrypted and protected using the AES-256 algorithm, accessible only to internal systems, and basic information for each access operation is recorded in the operation log.

[0055] (2) When the data shard is first invoked by the business process, the lifecycle state is migrated from the initial state to the active state. The security policy set bound to the active state is configured as enhanced encryption strength parameter, business system access permission parameter and transaction-level audit granularity parameter. The first business process call refers to the first read or process request initiated by a business system after the data shard is initialized, marking the transition of the data shard from the ready-to-use state to the business operation state. The enhanced encryption strength parameter indicates that a higher encryption algorithm or longer key is used to protect the data shard than the standard level. The business system access permission parameter indicates that authorized business systems are allowed to access the data shard. The transaction-level audit granularity parameter indicates that access logs are recorded at the transaction level, that is, the complete operation chain of each transaction is recorded, including the transaction identifier, operation sequence, associated shard, and transaction context.

[0056] (3) The security policy set bound in the dormant state is configured with enhanced encryption strength parameters, read-only access permission parameters, and operation-level audit granularity parameters; The conditions for transitioning to a dormant state are determined by a risk level score and a risk status mapping table, used to identify when a data shard transitions from a business operation state to a low-activity state. The "Maintain Enhanced Encryption Strength" parameter indicates that the data shard maintains enhanced encryption protection in the dormant state. The "Read-Only Access Permission" parameter indicates that only read operations are allowed, prohibiting write and modification operations. The "Operational-Level Audit Granularity" parameter indicates that the audit granularity has fallen back from the transaction level to the operational level because the access frequency of the data shard is reduced in the dormant state, eliminating the need for detailed transaction-level auditing. For example, when the system migrates the lifecycle state of a customer identity information shard to a dormant state, it maintains enhanced encryption protection, narrows access permissions to allow only read-only operations, and reduces audit granularity to the operational level.

[0057] (4) The security policy set bound to the archive state is configured with the highest encryption strength parameter, the audit-only access permission parameter, and the full audit granularity parameter; Among them, the migration conditions of the archived state are determined by the risk level score and the risk status mapping table. The highest encryption strength parameter indicates that the highest level of encryption algorithm and the longest key supported by the system are used to protect the data fragments. The audit access permission parameter indicates that only the audit system is allowed to access the data fragments for compliance audit purposes, and regular access from business systems and internal systems is denied. The full audit granularity parameter indicates that the access log is recorded at the full level, that is, all access and operation details are recorded, including visitor identification, access time, operation type, operation parameters, operation results and context information.

[0058] For example, after a customer transaction information fragment is migrated to the archived state triggered by the risk level scoring, the system upgrades its encryption algorithm to the highest level, making it accessible only to the audit system for compliance checks, and all access and operation details are recorded in the full audit log.

[0059] (5) When the validity period field expires, the lifecycle state is migrated to the state to be destroyed. The security policy set bound to the state to be destroyed is configured as the highest encryption strength parameter, the access prohibition parameter, and the full audit granularity parameter.

[0060] The "Valid Duration" field indicates that the data usage period of the contract record in the shared data packet has expired, at which point the data fragment enters its final state before destruction. Based on the highest encryption strength and full auditing in the archived state, the "Disallow Access" parameter rejects all external access requests, retaining only internal execution permissions for the destruction process, ensuring no external read operations interfere with the erasure process.

[0061] For example, the effective duration field of the shared data packet is set to 72 hours. After 72 hours, the system will migrate the lifecycle state of the relevant data fragments to the pending destruction state, maintain the highest level of encryption protection, prohibit all external access, record all operation details to the full audit log, and then perform the erasure operation and generate the destruction proof chain.

[0062] In the above implementation, the lifecycle state is refined into five stages with increasing security levels, and different encryption strength, access permissions, and audit granularity parameters are configured for each stage. This ensures that the data fragments are always under a protection level that matches the security requirements of the current stage throughout the entire process from initialization to destruction. The prohibited access permission parameter in the state to be destroyed ensures that there is no external access interference during the erasure period, which helps to achieve layered security control of the entire data lifecycle and isolated execution of the destruction process.

[0063] Reference Figure 2 As one implementation of step S103, the step of collecting access behavior characteristics and environmental context characteristics of data fragments in the lifecycle storage area, and generating a risk feature vector by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data fragments includes: Step S201: Extract access behavior characteristics of data shards from the access logs of the lifecycle storage area and determine the weight of abnormal behavior; wherein, the access behavior characteristics include access frequency, access time distribution, access source and access operation type; The access log is a record of access operations automatically generated by the lifecycle storage area during operation, including information such as the timestamp of each access, access source, and operation type. The behavior anomaly weight is a quantitative weight determined based on access behavior characteristics, reflecting the degree of anomaly in access behavior, and is used to characterize the threat level faced by data shards at the access level.

[0064] Specifically, access frequency represents the number of times a data shard is accessed per unit of time; access time distribution represents the distribution characteristics of access operations on a 24-hour timeline; access source represents the system or user identifier that initiated the access; and access operation type represents the type of operation performed on the data shard, including read, write, delete, and export. The abnormal behavior weight is determined based on these access behavior characteristics, and the criteria include: whether the access frequency exceeds the historical average access value for the data shard; whether the access time distribution is concentrated during non-working hours (e.g., 23:00 to 06:00); whether the access source includes systems or users not on the authorized list; and whether the access operation type includes high-risk operations such as deletion or batch export. The higher the degree of abnormality in each criterion, the greater the abnormal behavior weight.

[0065] For example, the access logs of a customer transaction information shard show that the shard was accessed 12 times between 2:00 AM and 4:00 AM. The access source included an IP address that was not on the authorized list, and the access operation type included a batch export operation. Based on the above abnormal behavior characteristics, the system determined the abnormal behavior weight to be 0.8.

[0066] Step S202: Obtain the environmental context features of data shards from the system operation status data in the lifecycle storage area, and determine the environmental threat weights; wherein, the environmental context features include the current time period identifier, system load status, and network environment security level; Among them, the environmental threat weight is a quantitative weight determined based on the characteristics of the environmental context, reflecting the degree of environmental threat, and is used to characterize the threat level faced by data shards at the operating environment level.

[0067] Specifically, the current time period identifier indicates whether the current time belongs to a working or non-working period; the system load status indicates whether the current system's CPU utilization and memory usage are within the normal range; and the network environment security level indicates the current network environment's security assessment level. Environmental threat weights are determined based on these environmental context characteristics, and the criteria include: whether the current time period is a non-working period, whether the system load is abnormally high (e.g., CPU utilization consistently exceeding 90%), and whether the network environment security level has been downgraded. The higher the threat level of each criterion, the greater the environmental threat weight.

[0068] For example, the system operation status data shows that the current time is 3:00 AM (non-working hours), the CPU utilization rate is 95% (abnormally high), and the network environment security level has been reduced from level 3 to level 2. Based on the above environmental threat characteristics, the system determines the environmental threat weight to be 0.7.

[0069] Step S203: Find the corresponding state risk baseline weight in the preset state risk baseline lookup table according to the current life cycle state; The state risk baseline weight is a quantified weight reflecting the baseline risk level faced by a data shard in its current lifecycle state. Different lifecycle states correspond to different risk baseline weights. In the active state, the data shard is in active use and can be accessed and decrypted by business systems, corresponding to the highest risk baseline weight. In the archived state, the data shard has been subjected to the highest encryption strength and the strictest access restrictions, corresponding to the lowest risk baseline weight. When external threats subside, the lower risk baseline weight corresponding to the archived state helps to reduce the overall risk score, allowing the state to revert from the archived state to the active or dormant state.

[0070] Specifically, the corresponding risk baseline weight is looked up in a pre-defined state risk baseline lookup table based on the current lifecycle state. The risk baseline weight for the initial state is 0.2, for the active state it is 0.5, for the dormant state it is 0.4, and for the archived state it is 0.3.

[0071] Step S204: Determine the dimension sensitivity level weight based on the attribute dimensions of the data shards; The dimension sensitivity level weight is a quantitative weight determined based on the attribute dimensions of the data shards, reflecting the sensitivity of the data in that dimension. Different attribute dimensions correspond to different sensitivity levels because data from different dimensions has varying degrees of impact on customer privacy and security.

[0072] Specifically, the corresponding sensitivity level weight is looked up in a pre-defined dimension sensitivity level lookup table based on the attribute dimensions of the data shards. The sensitivity level weight for the identity attribute dimension is 0.9, for the transaction attribute dimension it is 0.8, for the behavior attribute dimension it is 0.6, and for the connection attribute dimension it is 0.5.

[0073] For example, the attribute dimension of customer transaction information segmentation is transaction attribute. The system looks up the sensitivity level weight corresponding to the transaction attribute dimension in the dimension sensitivity level comparison table. The weight is 0.8. This weight reflects the degree of impact of transaction data on customer privacy and security.

[0074] Step S205: Combine the abnormal behavior weight, environmental threat weight, state risk baseline weight, and dimension sensitivity level weight to generate a risk feature vector.

[0075] Specifically, the four dimensions of a vector—behavioral anomaly weight, environmental threat weight, state risk baseline weight, and dimensional sensitivity level weight—are combined to generate a four-dimensional vector as the risk feature vector, with each dimension corresponding to a weight value. The behavioral anomaly weight and environmental threat weight reflect external dynamic threats, while the state risk baseline weight and dimensional sensitivity level weight reflect internal static attributes. These four types of weights quantify the current risk factors in data segments from different dimensions, providing multi-dimensional input for the risk assessment model.

[0076] For example, the weight of abnormal behavior is 0.8, the weight of environmental threat is 0.7, the weight of state risk baseline is 0.5, and the weight of dimensional sensitivity level is 0.8. The combination of these four weights generates a risk feature vector, which is then input into the risk assessment model to output a risk level score of 85.

[0077] In the above implementation, external dynamic threat information faced by data shards is extracted from two dimensions: access behavior characteristics and environmental context characteristics. The risk baseline of the current life cycle state and the sensitivity level of the attribute dimension are combined as internal static attribute factors. The four types of weights are combined to generate a risk feature vector, which provides multi-dimensional input basis for the risk assessment model to output risk level scores. This helps to make the risk level scores take into account risk factors at both the external threat and internal attribute levels.

[0078] Reference Figure 3 As one implementation of step S105, the steps of migrating data fragments to a target lifecycle state based on risk level scores, and re-encrypting and storing the data fragments according to the security policy set bound to the target lifecycle state include: Step S301: Determine the target lifecycle state based on the risk level score and the preset risk status mapping table, and migrate the data shards from the current lifecycle state to the target lifecycle state; wherein, the risk status mapping table records the correspondence between the risk level score range and the lifecycle state; Specifically, the risk status mapping table is a pre-configured mapping table that records the correspondence between risk level score ranges and lifecycle states. It is used to determine the target lifecycle state to which data shards need to be migrated based on the risk level score. The target lifecycle state is determined based on the risk level score and the pre-configured risk status mapping table.

[0079] In some embodiments, the risk level score ranges and lifecycle states recorded in the risk status mapping table correspond as follows: 0 to 50 points correspond to the active state, 51 to 70 points to the dormant state, and 71 to 100 points to the archived state. The initial state is the starting state after the data shard is created and before it is first invoked by the business process, and it is not used as a risk-driven state migration target; the state to be destroyed is triggered by the expiration of the validity period field and is not migrated through risk scoring. The system matches the risk level score with each score range in the risk status mapping table, determines the lifecycle state corresponding to the range in which the risk level score is located as the target lifecycle state, and then migrates the data shard from the current lifecycle state to the target lifecycle state, updating the state information of the data shard recorded in the lifecycle state machine instance.

[0080] For example, if the risk level score of a customer transaction information shard is 85, the system looks up the range of 71 to 100 in the risk status mapping table, and the corresponding lifecycle status is archived. The system then migrates the data shard from the current active state to the archived state and updates the status record of the shard in the lifecycle state machine instance.

[0081] It should be noted that the risk status mapping table only applies to data shards in the active, dormant, or archived states. Data shards in the initial state have not yet entered the business operation process, lack access behavior data, and do not participate in risk-driven state migration. They only migrate to the active state when first invoked by the business process based on a business event trigger, and only then do they enter the risk-driven state migration cycle. Data shards in the pending destruction state have already entered the destruction process and are also not subject to the risk status mapping table.

[0082] Therefore, the calculation of risk level scores and the migration determination of risk status mapping tables are only performed on data shards that have entered the active, dormant, or archived states. The initial state and the state to be destroyed are respectively triggered by business events and the expiration of the effective duration field to complete the state transition, which does not interfere with the migration mechanism driven by risk scores.

[0083] Step S302: Obtain the target encryption algorithm and target key generation parameters from the security policy set bound to the target lifecycle state, and generate the target encryption key according to the target key generation parameters; The target encryption algorithm is an identifier obtained from the security policy set bound to the target lifecycle state, used to re-encrypt data fragments. The target key generation parameters are configuration parameters obtained from the security policy set, used to generate the key required for re-encryption, including key length, key derivation function identifier, and salt value.

[0084] Specifically, the encryption strength parameters in the security policy set record the encryption algorithm identifier and key generation parameters required for that state. After extracting the target encryption algorithm identifier and target key generation parameters from the security policy set, the system calculates and generates the target encryption key based on the key derivation function identifier and salt value in the target key generation parameters, combined with the data fragment identifier and the current system time as derivation inputs. The key is dynamically generated at runtime rather than directly read from the security policy set, avoiding the security risks of static key storage.

[0085] For example, the target encryption algorithm recorded in the archived security policy is SM4. The target key generation parameters include a key length of 256 bits, a key derivation function identifier of HKDF, and a salt value of the global salt value pre-configured by the system. The system generates a 256-bit target encryption key based on the above parameters, combined with the fragment identifier of the data fragment and the current system time.

[0086] Step S303: Re-encrypt the data fragments using the target encryption algorithm and the target encryption key, and then store them.

[0087] Re-encryption involves re-encrypting the data fragment using the target encryption algorithm and key, replacing the original encryption algorithm and key of the data fragment, and ensuring that the encryption strength and access permissions of the data fragment match the security level required by the target lifecycle state. After the re-encryption operation, the encryption algorithm and key of the data fragment have been updated from the original configuration before migration to the configuration specified by the target lifecycle state.

[0088] For example, when a data fragment is in active state, it is encrypted using the AES-256 algorithm and the original key. After migrating to archive state, the system obtains the target encryption algorithm as SM4 and the target encryption key, and uses the SM4 algorithm and the target encryption key to re-encrypt the data fragment, resulting in a re-encrypted data fragment protected by the SM4 algorithm.

[0089] In the above implementation, a risk status mapping table is used to correspond risk level scoring ranges with lifecycle states, so that the determination of the target state is based on the scoring range rather than a single threshold, covering the entire scoring range; encryption algorithms and key generation parameters are obtained from the security policy set and keys are dynamically generated at runtime, avoiding the security risks of static key storage; re-encryption makes the encryption strength of data fragments updated as the lifecycle state migrates, which helps to realize risk-driven dynamic security level adjustment.

[0090] Reference Figure 4 As one implementation of step S106, the step of parsing the sharing purpose tag and target attribute set from the data sharing request, and filtering the target attribute set based on the security policy set, the sharing purpose tag, and a preset purpose attribute mapping table includes: Step S401: Find the corresponding allowed sharing attribute dimension range in the usage attribute mapping table according to the shared usage tag; The allowed shared attribute dimension range is a set of allowed shared attribute dimensions recorded in the purpose attribute mapping table, corresponding to a specific shared purpose tag. The purpose attribute mapping table is a pre-configured table that reflects the mapping relationship between shared purposes and shareable attribute dimensions. Each shared purpose tag corresponds to an allowed shared attribute dimension range in the table, which is used to limit the range of data attributes that can be shared under that purpose.

[0091] Specifically, the search process is as follows: using the shared purpose label as the query key, the record corresponding to the label is matched in the purpose attribute mapping table, and the range of allowed shared attribute dimensions stored in that record is read. The range of allowed shared attribute dimensions is a set of attribute dimension identifiers that indicate which attribute dimension data fragments can be shared under this purpose.

[0092] For example, if the shared purpose is labeled "risk control analysis", the system will look up the record corresponding to "risk control analysis" in the purpose attribute mapping table. The range of allowed shared attribute dimensions stored in this record is {identity attribute dimension, transaction attribute dimension}, which means that data fragments of the identity attribute dimension and transaction attribute dimension are allowed to be shared under the purpose of risk control analysis.

[0093] Step S402: Find the intersection between the allowed shared attribute dimension range and the target attribute set to obtain the intersection attribute set; The intersection attribute set is the set of attribute dimensions obtained by finding the intersection of the allowed shared attribute dimension range and the target attribute set. It represents the set of attribute dimensions required by the requester and allowed to be shared for this purpose. Finding the intersection is the AND operation in set operations, which takes the common elements from the two sets to form a new set.

[0094] Specifically, the target attribute set is the set of required attribute dimensions specified by the requester in the data sharing request, and the allowed shared attribute dimension range is the range of attribute dimensions that are allowed to be shared under the purpose in the purpose attribute mapping table. The intersection attribute set obtained after finding the intersection only contains attribute dimensions that exist in both the target attribute set and the allowed shared attribute dimension range, excluding attribute dimensions that the requester needs but are not allowed to be shared, as well as attribute dimensions that are allowed to be shared but are not needed by the requester.

[0095] For example, if the target attribute set is {identity attribute dimension, transaction attribute dimension, and connection attribute dimension}, and the allowed shared attribute dimension range is {identity attribute dimension and transaction attribute dimension}, the intersection of the two sets of attributes is {identity attribute dimension and transaction attribute dimension}. The connection attribute dimension is excluded because it is not within the allowed sharing range.

[0096] Step S403: Extract shared control rule parameters from the security policy set, apply constraints to the intersection attribute set based on the shared control rule parameters, and obtain the filtered target attribute set.

[0097] Among them, the sharing control rule parameters are a set of rules centrally configured by the security policy to impose additional constraints on sharing behavior, including control parameters such as the attribute dimension restrictions allowed for sharing in the current lifecycle state, the sharing frequency restrictions, and the sharing data volume restrictions.

[0098] Specifically, the constraint execution process is as follows: The shared control rule parameters bound to the current lifecycle state are read from the security policy set. Based on the allowed shared attribute dimension restrictions in the shared control rule parameters, the intersection attribute set is further filtered, removing attribute dimensions that are not allowed to be shared in the current state. The filtered target attribute set obtained after constraints is the final set of attribute dimensions that can be provided to the sharing target.

[0099] For example, if the intersection attribute set is {identity attribute dimension, transaction attribute dimension}, and the data shard is currently in archive mode, the sharing control rule parameter in the archive mode's security policy set stipulates that only the transaction attribute dimension is allowed to be shared in archive mode, while the identity attribute dimension is prohibited from being shared. The system applies constraints to the intersection attribute set based on this sharing control rule parameter, removing the identity attribute dimension, resulting in the filtered target attribute set being {transaction attribute dimension}.

[0100] In the above implementation, the purpose of sharing is associated with the range of allowed shared attributes by using a purpose attribute mapping table. By finding the intersection, attributes that the requester needs but are not allowed to share are excluded. Then, the sharing control rule parameters in the security policy set are combined with the current lifecycle state to further constrain the intersection result, thereby achieving dual screening driven by purpose and constrained by state. This helps to control the scope of information exposure during the data sharing process.

[0101] Reference Figure 5 As one implementation of step S108, the steps of combining the de-identified data fragments into a shared data packet, constructing a usage constraint contract including a valid duration field, and attaching it to the shared data packet include: Step S501: Add separators and metadata information between each de-identified data fragment, and assemble them into a shared data packet according to the attribute dimension order; The separator is a marker used to distinguish the boundaries of different data fragments in a shared data packet, enabling the receiving party to correctly parse each data fragment according to its boundaries. Metadata information describes the attributes of each data fragment, including fragment identifier, attribute dimension, and data length. The attribute dimension order is the basis for arranging the data fragments in the shared data packet, and can be arranged in a preset order: identity attribute dimension, transaction attribute dimension, behavioral attribute dimension, and connection attribute dimension.

[0102] Specifically, the assembly process is as follows: each de-identified data fragment is arranged in the order of identity attribute dimension, transaction attribute dimension, behavior attribute dimension and contact attribute dimension. A separator and the metadata information of the fragment are inserted between two adjacent fragments to form a shared data packet with a fixed structure, so that the target party can extract and parse the fragments one by one in the same attribute dimension order after receiving it.

[0103] For example, the de-identified identity information fragments and transaction information fragments are arranged in the order of identity attribute dimension first and transaction attribute dimension second. A separator and metadata information of each fragment (including fragment identifier, attribute dimension and data length) are inserted between the two fragments and assembled into a shared data packet.

[0104] Step S502: Obtain the sharing time limit parameter from the security policy set, and determine the value of the effective duration field based on the sharing purpose label and the sharing time limit parameter; The sharing time limit parameter is a parameter centrally configured in the security policy that defines the maximum time limit for data sharing under the current lifecycle state. The value of the valid duration field is the valid usage period of the data in the shared data packet, determined jointly by the sharing purpose label and the sharing time limit parameter.

[0105] Specifically, the sharing duration parameter is determined by the current lifecycle state. Different states allow different sharing durations; for example, the sharing duration parameter is 168 hours for the active state and 24 hours for the archived state. The sharing purpose tag corresponds to different usage requirement durations; for example, the request duration for risk control analysis is 72 hours, and the request duration for compliance audit is 30 days. The system determines the smaller value between the sharing duration parameter and the request duration corresponding to the sharing purpose tag as the value of the effective duration field, ensuring that the sharing period simultaneously meets both state constraints and usage requirements.

[0106] For example, if the data shard is currently in archive state, the sharing time limit parameter in the security policy set is 24 hours, and the request duration corresponding to the sharing purpose label "risk control analysis" is 72 hours, the system takes the smaller value of 24 hours and 72 hours, 24 hours, as the value of the effective duration field.

[0107] Step S503: Generate a purpose restriction field and a re-sharing prohibition field based on the shared purpose label; wherein, the purpose restriction field records the scope of business scenarios in which the shared data packet is allowed to be used, and the re-sharing prohibition field indicates whether the sharing target party is prohibited from forwarding the shared data packet to a third party; Specifically, the content of the usage restriction field is generated by looking up the corresponding business scenario range in the pre-set usage scenario mapping table based on the shared usage tag. For example, the business scenario range corresponding to the "risk control analysis" tag is "risk assessment, anti-fraud detection", and the usage restriction field records this range. The re-sharing prohibition field is generated based on the security level of the shared usage tag. The re-sharing prohibition field corresponding to highly sensitive uses (such as compliance audit) is marked as prohibited, and the re-sharing prohibition field corresponding to low-sensitivity uses (such as marketing recommendation) is marked as permitted.

[0108] For example, if the shared purpose is tagged as "risk control analysis", the system will look up the corresponding business scenario range in the usage scenario mapping table as "risk assessment, anti-fraud detection" and generate a usage restriction field to record this range; the security level of "risk control analysis" is medium sensitive, and the sharing prohibition field is marked as prohibiting the sharing target party from forwarding the shared data packet to a third party.

[0109] Step S504: Assemble the validity duration field, usage restriction field, and re-sharing prohibition field into a usage constraint contract and attach it to the shared data packet.

[0110] The usage constraint contract is a usage constraint protocol attached to the shared data packet. It is composed of an effective duration field, a usage restriction field, and a re-sharing prohibition field. It is used to constrain the sharing target party's usage period, usage scenarios, and forwarding behavior of the shared data packet.

[0111] Specifically, the assembly process is as follows: the three fields are combined into a contract data body according to the preset contract structure, a contract identifier and a contract version number are added to the header of the contract data body, the assembled usage constraint contract is attached to the header or footer of the shared data packet, and the complete shared data packet is sent to the sharing target party.

[0112] For example, the system assembles the validity period field (24 hours), the usage restriction field (risk assessment, anti-fraud detection), and the re-sharing prohibition field (prohibition of forwarding) into a usage constraint contract, and attaches the contract to the header of the shared data packet to form a complete shared data packet containing contract constraints and data content.

[0113] In the above implementation, the data packets are assembled in order of attribute dimensions to make the data structure fixed and parseable. The effective duration is determined by the dual source of the sharing time limit parameter and the sharing purpose label so that the sharing period can simultaneously meet the state constraints and the purpose requirements. The data usage of the sharing target party is constrained from two dimensions, namely the usage scenario and the forwarding behavior, by the purpose restriction field and the re-sharing prohibition field. This helps to realize three-dimensional constraints of duration, scenario and flow in the data sharing process.

[0114] Reference Figure 6 As one implementation of step S109, when the validity period field expires, the following steps are taken: First, an erasure operation is performed on the currently stored data fragments according to the mapping index table. Then, a digest value is calculated for each erased lifetime storage area. Finally, the digest values ​​are hashed and linked sequentially to generate a destruction proof chain, which is then written into the destruction record ledger: Step S601: When the validity period field expires, the lifecycle state is migrated to the pending destruction state, and the access permissions of each lifecycle storage area are locked according to the prohibited access parameters of the security policy set bound to the pending destruction state. The "pending destruction" state is the state a data fragment enters before destruction after its validity period expires. This state is bound to a security policy set configured with the highest encryption strength parameter, a "disallow access" parameter, and a full audit granularity parameter. The "disallow access" parameter, configured in the security policy set, rejects all external access requests and takes effect in the "pending destruction" state to ensure no external read operations interfere with the erasure process. Access lockout is the operation of closing the access entry points for each lifecycle storage area based on the "disallow access" parameter.

[0115] Specifically, the migration process is as follows: the system checks whether the value of the valid duration field has expired. If it has expired, the lifecycle status of the data shard is migrated from the current state to the state to be destroyed. The system reads the prohibited access parameter from the security policy set bound to the state to be destroyed. Based on the parameter, the system sends a locking instruction to the access control module of each lifecycle storage area, rejects all external access requests, and retains only the internal execution permission of the destruction process.

[0116] For example, the validity period field of the shared data packet is set to 24 hours. When the 24 hours expire, the system will migrate the lifecycle status of the data fragment from the archived state to the pending destruction state, read the prohibited access parameters from the security policy set of the pending destruction state, send a locking command to the access control module of the four lifecycle storage areas, and deny all external access requests.

[0117] Step S602: Locate the lifecycle storage area where the currently stored data fragment is located according to the mapping index table, perform multiple rounds of random data overwriting on the currently stored data fragment in each lifecycle storage area to obtain each erased lifecycle storage area, and set each erased lifecycle storage area to read-only locked state; In this process, multiple random data writes are performed on the data fragments in the lifetime storage area. Each write uses different random data to overwrite the original data, making it impossible to recover the original data fragment content in the erased storage area. The erased lifetime storage area is the storage area after multiple rounds of random data overwriting, where the original data has been replaced by random data.

[0118] Specifically, the process of locating each lifecycle storage area is as follows: using the fragment identifier of the currently stored data fragment as the query key, the location of the storage area where each fragment is located is found in the mapping index table to obtain a list of all storage areas to be erased. The overwrite process is as follows: at least three rounds of random data writing are performed on each storage area to be erased. In each round of writing, random data generated by the system's random number generator is used to overwrite the original content in the storage area. After the overwrite is completed, the original data fragment content in the storage area cannot be read by data recovery methods, resulting in each erased lifecycle storage area. After erasure, each erased lifecycle storage area enters a read-only locked state, allowing only hash read operations and prohibiting any write operations to ensure that the recalculated hash digest in the subsequent verification process is not disturbed by new data writing.

[0119] For example, the system locates four lifecycle storage areas based on the mapping index table, which contain identity information fragments, transaction information fragments, behavior information fragments, and contact information fragments, respectively. It performs three rounds of random data overwriting on each of the four storage areas, writing 32 bits of random data in each round to overwrite the original content. After the three rounds of overwriting are completed, the original data fragment content in the four storage areas is no longer recoverable, resulting in four erased lifecycle storage areas.

[0120] Step S603: Calculate hash digests of the contents of each erased lifetime storage area using a hash algorithm to obtain each digest value; The hash algorithm is a cryptographic hash function used to calculate a digest value for the content of the erased lifetime storage area, mapping storage area content of arbitrary length to a digest value of fixed length. The digest value is a hash digest calculated from the erased lifetime storage area content using the hash algorithm, used to verify that the storage area has been completely erased and its content has not been tampered with.

[0121] Specifically, the calculation process is as follows: The entire contents of each erased lifetime storage area (i.e., the contents of the storage area after multiple rounds of random data overwriting) are read sequentially. The contents are input into a hash algorithm, and a fixed-length hash digest is output as the digest value of that storage area. Each erased lifetime storage area corresponds to one digest value, and the order of the digest values ​​is consistent with the order of the storage areas in the mapping index table.

[0122] For example, the system uses a hash algorithm to calculate digest values ​​for the four erased lifetime storage areas. The content of the first storage area is hashed to obtain digest value H1, the second storage area to obtain digest value H2, the third storage area to obtain digest value H3, and the fourth storage area to obtain digest value H4. The four digest values ​​are arranged in the order of the storage areas.

[0123] Step S604: Generate a destruction batch identifier based on the valid duration field value and system time. Use the first digest value as the initial chain node digest. Then, concatenate each subsequent digest value with the previous chain node digest and use a hash algorithm to calculate the current chain node digest. Continue until all digest values ​​have been processed. Connect the chain node digests to generate a destruction proof chain. The destruction batch identifier is a unique identifier used to identify a single destruction operation. It is generated based on the validity duration field value and the system time, making multiple destruction events distinguishable and traceable in the destruction record ledger. The initial chain node digest is the initial node set up with the first digest value as the head of the destruction proof chain. The current chain node digest is the chain node calculated by concatenating each subsequent digest value with the previous chain node digest using a hash algorithm. The destruction proof chain is a chain-like proof structure generated by sequentially connecting the chain node digests. Any tampering with the erased storage area will result in a digest value mismatch, which will be detected by the destruction proof chain.

[0124] Specifically, the generation process is as follows: the valid duration field value is combined with the system time when the valid duration field expires to generate a destruction batch identifier; the first digest value is set as the initial chain node digest as the chain head; the second digest value is concatenated with the initial chain node digest and a hash algorithm is used to calculate the first current chain node digest; the third digest value is concatenated with the previous current chain node digest and a hash algorithm is used to calculate the second current chain node digest; and so on, until all digest values ​​have been processed; the initial chain node digest and each current chain node digest are connected sequentially to generate a destruction proof chain.

[0125] For example, the system generates a destruction batch identifier "DEST-24h-20260725100000" based on the valid duration field value of 24 hours and the system time 2026-07-25T10:00:00; the four digest values ​​are H1, H2, H3, and H4. H1 is set as the initial chain node digest. H2 is concatenated with H1 and hashed to obtain the first current chain node digest L1. H3 is concatenated with L1 and hashed to obtain the second current chain node digest L2. H4 is concatenated with L2 and hashed to obtain the third current chain node digest L3. H1, L1, L2, and L3 are connected in sequence to generate a destruction proof chain.

[0126] Step S605: Write the values ​​of the destruction proof chain, destruction batch identifier, system time at the time of erasure, number of lifecycle storage areas after erasure, and effective duration of triggering destruction into the destruction record ledger.

[0127] The destruction record ledger is a persistent storage medium that records the destruction proof chain and related destruction information, providing auditable evidence of destruction. The system time at the time of erasure is the system timestamp when the erasure operation was executed. The number of lifetime storage areas after each erasure is the total number of storage areas erased in this destruction operation. The effective duration field value for triggering destruction is the original setting value of the effective duration field before the expiration of the destruction process.

[0128] Specifically, the writing process involves assembling the destruction proof chain, destruction batch identifier, system timestamp at the time of erasure, number of storage areas to be erased, and effective duration of the destruction trigger into a ledger record, and then appending this record to the end of the destruction record ledger. The ledger uses an append-only writing method to ensure that the recorded destruction information cannot be tampered with.

[0129] For example, the system assembles the destruction proof chain (H1→L1→L2→L3), the destruction batch identifier "DEST-24h-20260725100000", the system time at the time of erasure 2026-07-25T10:00:05, the number of storage areas to be erased (4), and the effective duration field value of the destruction trigger (24 hours) into a ledger record and appends it to the destruction record ledger.

[0130] In the above implementation, access permissions for each storage area are locked before erasure based on the prohibited access parameter of the state to be destroyed, ensuring that there is no external access interference during the erasure process; multiple rounds of random data overwriting make the original data in the erased storage area unrecoverable; by sequentially hashing and linking each digest value to generate a destruction proof chain, any tampering with the erased storage area can be detected; and by using the destruction batch identifier and the append-only write method of the ledger, multiple destruction events can be distinguished and traced and the records cannot be tampered with, which helps to provide auditable destruction evidence.

[0131] Reference Figure 7 As a further implementation of the customer information lifecycle management method, after hashing and linking each digest value sequentially to generate a destruction proof chain and writing it into the destruction record ledger, in response to scheduled inspection tasks or external audit instructions, the post-destruction verification process is initiated, specifically including: Step S701: Extract the destruction batch identifier and the corresponding latest destruction proof chain from the destruction record ledger; The destruction record ledger serves as the persistent auditing carrier for the data destruction process, recording the proof chain and batch identifier for each destruction operation. The destruction proof chain is a chain-like data structure formed by sequentially concatenating the hash digests of each erased lifecycle storage area through hash operations. Each node in the chain is bound to its predecessor through hash operations; tampering with any node will cause all subsequent nodes to shift. The destruction batch identifier is generated by combining the effective duration field value that triggered the destruction with the system time, used to distinguish different destruction operations performed at different times. When multiple destruction proof chains exist in the ledger for the same destruction batch, the system extracts the destruction proof chain with the most recent timestamp as the latest destruction proof chain for subsequent verification and comparison. During the initial inspection, if the ledger only contains the originally written destruction proof chain, the system directly extracts that chain as the latest destruction proof chain.

[0132] In this embodiment, the verification process is triggered by a scheduled inspection task or an external audit instruction. The system retrieves the latest destruction proof chain corresponding to the destruction batch identifier from the destruction record ledger, and loads the destruction batch identifier and the latest destruction proof chain into memory as benchmark data for subsequent comparison and tracing. During the initial inspection, the latest destruction proof chain is the originally written destruction proof chain; in subsequent inspections, if the previous inspection performed a re-erase and wrote an updated destruction proof chain, the system extracts the updated destruction proof chain as the latest destruction proof chain. For example, when the system performs a monthly destruction integrity inspection, it extracts the latest destruction proof chain and batch identifier for all destruction batches of the current month from the ledger and enters the subsequent verification process one by one.

[0133] Step S702: Locate the erased lifetime storage area according to the mapping index table, and recalculate the hash digest of the current content of each erased lifetime storage area using a hash algorithm to obtain the current digest value; The mapping index table records the mapping relationship between data fragments and lifecycle storage areas, and serves as the index basis for locating the storage area after erasure.

[0134] In this embodiment, the system traverses all erased lifetime storage areas according to the mapping index table, calculates a 256-bit digest value for the current stored content of each storage area using the SHA-256 hash algorithm, and arranges the current digest values ​​in order of storage area number to form a sequence of current digest values ​​that corresponds one-to-one with the digest value list at the time of original destruction. For example, if three digest values ​​were calculated for three erased lifetime storage areas at the time of original destruction, three current digest values ​​are recalculated for these three storage areas during verification, with the arrangement order consistent with that at the time of original destruction.

[0135] Step S703: Take the first current digest value as the initial verification chain node digest, and then concatenate each subsequent current digest value with the previous verification chain node digest in turn. Calculate the current verification chain node digest using a hash algorithm until all current digest values ​​have been processed. Connect the digests of each verification chain node to generate a verification proof chain. The method for constructing the verification proof chain is consistent with that for constructing the destruction proof chain, employing the same chain node concatenation and hash operation logic. Each node in the hash chain depends not only on the digest value of the current input but also on the cumulative hash value of all preceding nodes. Therefore, tampering with any intermediate node will cause all subsequent nodes to shift, forming a detectable chain break.

[0136] Specifically, the chain node digest construction process is as follows: the first current digest value is directly used as the initial verification chain node digest. Starting from the second current digest value, each current digest value is concatenated with the previous verification chain node digest. The concatenation result is calculated using a hash algorithm to obtain the current verification chain node digest. This process is repeated until all current digest values ​​have been processed. The verification chain node digests are then connected in sequence to form a verification proof chain.

[0137] For example, for three current digest values ​​H1, H2, and H3, the initial verification chain node digest is H1, the second verification chain node digest is Hash(H2||H1), and the third verification chain node digest is Hash(H3||Hash(H2||H1)). The three are connected to form a verification proof chain.

[0138] Step S704: Compare the verification proof chain with the latest destruction proof chain node by node. When there are inconsistent verification chain node digests, obtain the position number corresponding to the inconsistent verification chain node digest. The chain-by-chain comparison refers to comparing and verifying the chain node digest one by one in the chain node arrangement order with the chain node digest at the corresponding position in the destruction proof chain to see if they are consistent. Due to the cascading nature of hash chains, if the Nth chain node is inconsistent, then all chain nodes from the Nth to the subsequent chain nodes will be inconsistent. Therefore, the position number of the first inconsistent node during the actual comparison is the starting position of the tampering.

[0139] Specifically, the system compares the verification proof chain and the destruction proof chain node by node in sequence, and records the position number of the first inconsistent verification chain node digest. This position number corresponds to the Nth erased lifetime storage area processed during the original destruction. For example, if the digest of the 3rd verification chain node out of 5 chain nodes is inconsistent with the digest of the 3rd chain node in the destruction proof chain, the position number is 3, pointing to the 3rd erased lifetime storage area.

[0140] Step S705: Determine the corresponding target lifecycle storage area based on the location sequence number and the mapping index table; obtain the target data fragments and their attribute dimensions stored in the target lifecycle storage area from the mapping index table; and query the lifecycle state machine instance to obtain the current lifecycle state of the target data fragments. The attribute dimension of the target data shard identifies the customer information attribute category to which the tampered data belongs, and the current lifecycle state reflects the state record of the data shard at the state machine level. If the content of the storage area has been tampered with but the lifecycle state in the state machine is still in the pending destruction state, it means that the attacker modified the content of the storage area without simultaneously tampering with the state machine; if the lifecycle state in the state machine has deviated from the pending destruction state, it means that the attacker also tampered with the state machine to cover up the data recovery behavior.

[0141] In this embodiment, the system searches for the corresponding lifecycle storage area identifier in the mapping index table based on the location sequence number. Then, it obtains the identifier and attribute dimension of the target data fragment through the mapping relationship between the storage area and the data fragment in the mapping index table. Subsequently, it queries the lifecycle state machine instance using the target data fragment identifier as the key to read the current lifecycle state value of the data fragment. For example, if the location sequence number points to storage area S3, and the mapping index table records data fragment D3 in S3 with the storage attribute dimension "contact information", querying the state machine shows that the current lifecycle state of D3 is "active" rather than "pending destruction". Therefore, it is determined that the data fragment has been tampered with at both the data layer and the state layer.

[0142] Step S706: Perform multiple rounds of random data overwriting on the target lifecycle storage area, recalculate the hash digest of the erased content of the target lifecycle storage area using a hash algorithm to obtain the updated digest value, and reset the current lifecycle state of the target data fragment in the lifecycle state machine instance to the state of pending destruction. Multi-round random data overwriting refers to repeatedly writing randomly generated data into the storage area, making the original data unrecoverable through physical means such as magnetic signal residue. Resetting the state to a pending destruction state ensures that the state machine record matches the actual storage state, eliminating traces of attacker tampering with the state machine.

[0143] In this embodiment, the system performs no less than three rounds of random data overwriting on the target lifecycle storage area, with a different random sequence written in each round. After the overwriting is completed, a hash algorithm is used to calculate a hash digest of the storage area content to obtain an updated digest value. At the same time, the state field value of the target data fragment in the lifecycle state machine instance is updated to the state code corresponding to the state to be destroyed.

[0144] For example, after storage area S3 undergoes 3 rounds of random data overwriting, the updated digest value is calculated to be a new 256-bit hash value. At the same time, the state of data fragment D3 in the state machine is reset from "active state" to "pending destruction state".

[0145] Step S707: Based on the updated digest value replacing the original digest value of the chain node corresponding to the position number in the latest destruction proof chain, recalculate the hash value of each chain node, and write the updated destruction proof chain into the destruction record ledger.

[0146] The updated destruction proof chain is a complete chained data structure obtained by replacing the original digest value of the chain node corresponding to the latest destruction proof chain with the updated digest value recalculated after the re-erasure, and then recalculating the hash values ​​of all subsequent chain nodes starting from that chain node. The updated destruction proof chain serves as the baseline for the next inspection, ensuring that storage areas that have been re-erased and have not been tampered with again will not trigger repeated re-erasure in subsequent inspections. The destruction batch identifier is appended to the updated destruction proof chain record during writing, allowing auditors to retrieve the original destruction proof chain and all updated destruction proof chains within the same destruction batch, tracing the entire destruction-tampering-re-erasure process of that batch.

[0147] In this embodiment, the system uses the latest extracted destruction proof chain as a benchmark, replaces the original digest value of the chain node corresponding to the position number with the calculated updated digest value, and recalculates the hash values ​​of all subsequent chain nodes sequentially from that chain node to obtain the updated destruction proof chain. The system writes the updated destruction proof chain, along with the destruction batch identifier, into the destruction record ledger after the original record of that batch. The ledger uses an append-only writing method, and the original destruction proof chain and each updated destruction proof chain are arranged in the ledger in chronological order of writing time. Auditors can locate the location and processing time of each tampering by comparing the differences between adjacent destruction proof chains.

[0148] For example, the original destruction proof chain contains chain nodes H1, L1, L2, and L3, where position number 3 corresponds to the digest value H3 that chain node L2 depends on. After erasing the third storage area, an updated digest value H3' is calculated. The system replaces H3 with H3' and recalculates the hash values ​​of subsequent chain nodes from this position, resulting in updated chain nodes H1, L1, L2', and L3'. The updated destruction proof chain, along with the batch identifier B20260726-001, is written to the ledger. During the next inspection, this updated destruction proof chain is extracted as the latest destruction proof chain. The current digest value of the third storage area remains H3', consistent with the H3' that L2' depends on in the baseline, and no further erasure is triggered. By comparing the original chain and the updated chain, auditors discovered that the third chain node changed from L2 to L2', thus locating that this position had been tampered with and then erased.

[0149] In the above implementation, a cross-verification mechanism is constructed between the data layer and the state layer using hash chain reconstruction comparison and lifecycle state machine state query, which can identify attacks that only tamper with a single layer. After erasure, an updated destruction proof chain is generated by writing the updated digest value back to the destruction proof chain, so that subsequent inspections use the updated chain as the comparison baseline, avoiding repeated erasure due to hash changes at already erased locations. The original destruction proof chain and the destruction proof chains updated in each iteration are arranged in chronological order in the ledger. Auditors can locate the tampering location and the erasure time by comparing the difference chain nodes of adjacent chains, giving the audit trajectory a time-dimensional traceability capability, which helps to meet the compliance audit requirements of the data destruction process.

[0150] This application also discloses a customer information lifecycle management system that ensures data security.

[0151] A customer information lifecycle management system that ensures data security, specifically including: The sharded encrypted storage module is used to obtain customer information, split it into multiple data shards according to attribute dimensions, encrypt each data shard independently and store it in the corresponding lifecycle storage area, and generate a mapping index table between the data shards. The state machine construction module is used to build lifecycle state machine instances based on the mapping index table, bind data shards to lifecycle state machine instances and initialize lifecycle states, and bind a set of security policies to each lifecycle state. The risk feature generation module is used to collect access behavior features and environmental context features of data shards in the lifecycle storage area, and generate risk feature vectors by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The risk assessment module is used to input risk feature vectors into a pre-set risk assessment model and output a risk level score. The state transition encryption module is used to migrate data fragments to the target lifecycle state based on the risk level score, and to re-encrypt and store the data fragments according to the security policy set bound to the target lifecycle state. The data sharing request processing module is used to receive data sharing requests, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and the preset purpose attribute mapping table; The data extraction and desensitization module is used to extract the corresponding data fragments from the currently stored data fragments based on the filtered target attribute set and according to the mapping index table, and perform desensitization processing to obtain the desensitized data fragments. The shared data sending module is used to combine the de-identified data fragments into a shared data packet, construct a usage constraint contract including a valid duration field and attach it to the shared data packet, and send it to the sharing target party; The data destruction proof module is used to perform an erasure operation on the currently stored data fragments according to the mapping index table when the validity period field expires, calculate the digest value of each erased lifecycle storage area, hash and link the digest values ​​in sequence to generate a destruction proof chain, and write it into the destruction record ledger.

[0152] The customer information lifecycle management system for ensuring data security according to the embodiments of this application can implement any of the above methods, and the specific working process of each module in the system can refer to the corresponding process in the above method embodiments.

[0153] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and in actual implementation there may be other division methods, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed.

[0154] This application also discloses a computer-readable storage medium.

[0155] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above in any of the customer information lifecycle management methods for ensuring data security.

[0156] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0157] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for customer information lifecycle management to ensure data security, characterized in that, The method includes: Customer information is obtained, split into multiple data shards according to attribute dimensions, each data shard is independently encrypted and stored in the corresponding lifecycle storage area, and a mapping index table between the data shards is generated. A lifecycle state machine instance is constructed based on the mapping index table. The data shards are bound to the lifecycle state machine instance and the lifecycle states are initialized. A set of security policies is bound to each lifecycle state. The access behavior characteristics and environmental context characteristics of the data shards are collected in the lifecycle storage area, and a risk feature vector is generated by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The risk feature vector is input into a preset risk assessment model, and a risk level score is output. The data shards are migrated to the target lifecycle state based on the risk level score, and the data shards are re-encrypted and stored according to the security policy set bound to the target lifecycle state. Receive a data sharing request, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and the preset purpose attribute mapping table; Based on the filtered target attribute set, the corresponding data fragments are extracted from the currently stored data fragments according to the mapping index table and desensitization processing is performed to obtain the desensitized data fragments; The de-identified data fragments are combined into a shared data packet, a usage constraint contract including a valid duration field is constructed and attached to the shared data packet, and then sent to the sharing target party; When the validity period field expires, the data fragments currently stored are wiped according to the mapping index table, and the digest value of each wiped lifecycle storage area is calculated. The digest values ​​are then hashed and linked sequentially to generate a destruction proof chain, which is written into the destruction record ledger.

2. The customer information lifecycle management method for ensuring data security according to claim 1, characterized in that, The lifecycle states include initial state, active state, dormant state, archived state, and pending destruction state; the security policy set includes encryption strength parameters, access permission parameters, audit granularity parameters, sharing control rule parameters, and sharing time limit parameters. The initial lifecycle state sets the lifecycle state of the data shard to the initial state, and the security policy set bound to the initial state is configured as standard encryption strength parameters, internal system access permission parameters, and operation-level audit granularity parameters; When the data shard is invoked for the first time by the business process, the lifecycle state is migrated from the initial state to the active state. The security policy set bound to the active state is configured as enhanced encryption strength parameters, business system access permission parameters, and transaction-level audit granularity parameters. The security policy set bound to the dormant state is configured as the enhanced encryption strength parameter, the read-only access permission parameter, and the operation-level audit granularity parameter; The security policy set bound to the archive state is configured with the highest encryption strength parameter, audit-only access permission parameter, and full audit granularity parameter. When the validity period field expires, the lifecycle state is migrated to the state to be destroyed. The security policy set bound to the state to be destroyed is configured as the highest encryption strength parameter, the access restriction parameter, and the full audit granularity parameter.

3. The customer information lifecycle management method for ensuring data security according to claim 1, characterized in that, The steps of collecting access behavior characteristics and environmental context characteristics of the data shards in the lifecycle storage area, and generating a risk feature vector by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards, include: The access behavior characteristics of the data shards are extracted from the access logs of the lifecycle storage area, and the weight of the abnormal behavior is determined; wherein, the access behavior characteristics include access frequency, access time distribution, access source and access operation type; The environmental context features of the data shards are obtained from the system operation status data in the lifecycle storage area, and the environmental threat weights are determined; wherein, the environmental context features include the current time period identifier, system load status, and network environment security level; The corresponding state risk baseline weight is looked up in the preset state risk baseline lookup table based on the current lifecycle state of the lifecycle state machine instance. The dimension sensitivity level weight is determined based on the attribute dimensions of the data shards; The risk feature vector is generated by combining the abnormal behavior weight, environmental threat weight, state risk baseline weight, and dimension sensitivity level weight.

4. The customer information lifecycle management method for ensuring data security according to claim 2, characterized in that, The steps of migrating the data fragments to the target lifecycle state based on the risk level score, and re-encrypting and storing the data fragments according to the security policy set bound to the target lifecycle state include: The target lifecycle state is determined based on the risk level score and a preset risk status mapping table, and the data shards are migrated from the current lifecycle state to the target lifecycle state; wherein, the risk status mapping table records the correspondence between risk level score ranges and lifecycle states; Obtain the target encryption algorithm and target key generation parameters from the security policy set bound to the target lifecycle state, and generate the target encryption key according to the target key generation parameters; The data fragments are re-encrypted and stored using the target encryption algorithm and the target encryption key.

5. A customer information lifecycle management method for ensuring data security according to claim 1, characterized in that, The steps of parsing the sharing purpose tag and target attribute set from the data sharing request, and filtering the target attribute set based on the security policy set, the sharing purpose tag, and a preset purpose attribute mapping table include: Based on the shared purpose tag, look up the corresponding allowed shared attribute dimension range in the purpose attribute mapping table; Find the intersection of the allowed shared attribute dimension range and the target attribute set to obtain the intersection attribute set; Shared control rule parameters are extracted from the security policy set, and constraints are applied to the intersection attribute set according to the shared control rule parameters to obtain the filtered target attribute set.

6. The customer information lifecycle management method for ensuring data security according to claim 1, characterized in that, The steps of combining the de-identified data fragments into a shared data packet, constructing a usage constraint contract including a valid duration field, and attaching it to the shared data packet include: Separator identifiers and metadata information are added between each of the de-identified data fragments, and they are assembled into a shared data packet according to the attribute dimension order; Obtain the sharing time limit parameter from the security policy set, and determine the value of the effective duration field based on the sharing purpose label and the sharing time limit parameter; Based on the shared purpose tag, a purpose restriction field and a re-sharing prohibition field are generated; wherein, the purpose restriction field records the scope of business scenarios in which the shared data packet is allowed to be used, and the re-sharing prohibition field indicates whether the sharing target party is prohibited from forwarding the shared data packet to a third party; The effective duration field, the usage restriction field, and the re-sharing prohibition field are assembled into the usage constraint contract and attached to the shared data packet.

7. A customer information lifecycle management method for ensuring data security according to claim 2, characterized in that, When the validity period field expires, the following steps are taken: First, an erasure operation is performed on the currently stored data shards according to the mapping index table. Then, a digest value is calculated for each erased lifetime storage area. Finally, the digest values ​​are hashed and linked sequentially to generate a destruction proof chain, which is then written into the destruction record ledger. When the validity period field expires, the lifecycle state is migrated to the state to be destroyed, and the access permissions of each lifecycle storage area are locked according to the prohibited access parameter of the security policy set bound to the state to be destroyed; The mapping index table is used to locate the current data fragment in each lifecycle storage area. Multiple rounds of random data overwriting are performed on the current data fragment in each lifecycle storage area to obtain each erased lifecycle storage area. Each erased lifecycle storage area is then set to a read-only locked state. A hash algorithm is used to calculate a hash digest of the contents of each erased lifetime storage area to obtain each digest value; Based on the effective duration field value and the system time, a destruction batch identifier is generated. The first digest value is used as the initial chain node digest. Each subsequent digest value is concatenated with the previous chain node digest and then a hash algorithm is used to calculate the current chain node digest. This process continues until all digest values ​​have been processed. The chain node digests are then connected to generate the destruction proof chain. Write the destruction proof chain, the destruction batch identifier, the system time at the time of erasure, the number of each erased lifecycle storage area, and the effective duration field value that triggers destruction into the destruction record ledger.

8. A customer information lifecycle management method for ensuring data security according to claim 7, characterized in that, After hashing and linking the aforementioned digest values ​​sequentially to generate a destruction proof chain and writing it into the destruction record ledger, in response to scheduled inspection tasks or external audit instructions, the post-destruction verification process is initiated, including: Extract the destruction batch identifier and the corresponding latest destruction proof chain from the destruction record ledger; The erased lifetime storage area is located according to the mapping index table, and the hash digest of the current content of each erased lifetime storage area is recalculated using a hash algorithm to obtain the current digest value. The first current digest value is used as the initial verification chain node digest. Each subsequent current digest value is concatenated with the previous verification chain node digest and then a hash algorithm is used to calculate the current verification chain node digest. This process continues until all current digest values ​​have been processed. The verification chain node digests are then connected to generate a verification proof chain. The verification proof chain is compared with the latest destruction proof chain node by node. When there is an inconsistent verification chain node digest, the position number corresponding to the inconsistent verification chain node digest is obtained. The corresponding target lifecycle storage area is determined based on the location number and the mapping index table. The target data fragments and their attribute dimensions stored in the target lifecycle storage area are obtained from the mapping index table. The current lifecycle state of the target data fragments is obtained by querying the lifecycle state machine instance. The multi-round random data overwrite is re-executed on the target lifecycle storage area. The hash digest of the erased content of the target lifecycle storage area is recalculated using a hash algorithm to obtain an updated digest value. The current lifecycle state of the target data fragment in the lifecycle state machine instance is reset to the state to be destroyed. The hash values ​​of each chain node are recalculated based on the updated digest value replacing the original digest value of the chain node corresponding to the position number in the latest destruction proof chain, and the updated destruction proof chain is written into the destruction record ledger.

9. A customer information lifecycle management system for ensuring data security, characterized in that, The system includes: The sharded encrypted storage module is used to obtain customer information, split it into multiple data shards according to attribute dimensions, encrypt each data shard independently and store it in the corresponding lifecycle storage area, and generate a mapping index table between the data shards. The state machine construction module is used to construct a lifecycle state machine instance based on the mapping index table, bind the data shards to the lifecycle state machine instance and initialize the lifecycle state, and bind a set of security policies to each lifecycle state. The risk feature generation module is used to collect access behavior features and environmental context features of the data shards in the lifecycle storage area, and generate a risk feature vector by combining the current lifecycle state of the lifecycle state machine instance and the attribute dimensions of the data shards. The risk assessment module is used to input the risk feature vector into a preset risk assessment model and output a risk level score. The state transition encryption module is used to migrate the data fragments to the target lifecycle state according to the risk level score, and to re-encrypt and store the data fragments according to the security policy set bound to the target lifecycle state. A data sharing request processing module is used to receive data sharing requests, parse the sharing purpose tag and target attribute set from the data sharing request, and filter the target attribute set based on the security policy set, the sharing purpose tag and a preset purpose attribute mapping table; The data extraction and desensitization module is used to extract the corresponding data fragments from the currently stored data fragments based on the filtered target attribute set and according to the mapping index table, and perform desensitization processing to obtain the desensitized data fragments. The shared data sending module is used to combine the de-identified data fragments into a shared data packet, construct a usage constraint contract including a valid duration field and attach it to the shared data packet, and send it to the sharing target party; The data destruction proof module is used to perform an erasure operation on the currently stored data fragments according to the mapping index table when the effective duration field expires, calculate the digest value of each erased lifecycle storage area, hash and link the digest values ​​in sequence to generate a destruction proof chain, and write it into the destruction record ledger.

10. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 8.

Images