A cloud migration security verification method

Abstract

The application discloses a cloud migration security verification method, and relates to the field of information technology, comprising: inputting a dynamic verification result into a pre-trained anomaly detection model, automatically analyzing the migration data and the dynamic verification result, generating a re-verification request and triggering the source end to re-output corresponding batch metadata when an anomaly is detected, and generating an incremental verification certificate otherwise; analyzing and checking the incremental verification certificate in an audit ledger, generating a consistency report and marking intact, missing and conflict sections, triggering rollback and retransmission and re-verification when a conflict is found, and generating a final chain root when there is no conflict; writing the final chain root into the audit ledger, generating a final verification certificate, performing trusted erasure on the migration data and generating an erasure certificate, combining the final verification certificate and the erasure certificate, and generating a security verification result. The application ensures that each batch of data is completely verified before being archived, thereby improving the security, data consistency and credibility of cloud migration.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a cloud migration security verification method. Background Technology

[0002] With the rapid development of cloud computing technology, enterprises and organizations have seen a significant increase in their demand for data migration to cloud platforms. Existing cloud migration technologies typically include data transmission, storage management, and access control, among which data integrity and security have become critical issues in the migration process. Traditional data migration verification methods largely rely on basic verification mechanisms, such as file hash comparison, transmission log recording, and simple transmission retry strategies, to ensure that migrated data has not been tampered with or lost during transmission. Simultaneously, timestamps and sequence numbers are used to perform basic sequential verification of data batches to improve the traceability of the migration process.

[0003] While existing technologies can provide partial integrity assurance for migrated data through hash values, timestamps, and basic sequence verification, they lack efficient mechanisms for identifying and handling dynamic anomalies during the migration process. For example, when migration data encounters anomalies or conflicts during transmission, traditional solutions often rely on manual intervention or single retries, failing to achieve continuous incremental verification and automated rollback. This leads to reduced migration efficiency and potential data consistency risks. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a cloud migration security verification method to address the problem of insufficient protection of migration data integrity and consistency.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a cloud migration security verification method, which includes scanning and classifying migration data, attaching a unique number, logical order, timestamp and hash value to each piece of migration data, and recording and organizing the data to generate a migration list.

[0008] The migration data is processed sequentially according to the migration list, a time-series hash chain is constructed, a serialization plan is generated, and an initial summary snapshot is calculated and written to the audit ledger.

[0009] According to the serialization plan, the migration data and the time sequence hash chain are sent to the target end in batches through the encrypted transmission channel. After receiving the data, the target end performs hash comparison on the migration data and verifies the transmission order, and generates dynamic verification results.

[0010] The dynamic verification results are input into the pre-trained anomaly detection model to automatically analyze the migration data and dynamic verification results. When an anomaly is detected, a re-verification request is generated and the source end is triggered to re-output the corresponding batch metadata. Otherwise, an incremental verification proof is generated.

[0011] In the audit ledger, the incremental verification proof is parsed and verified, a consistency report is generated and marked as intact, missing and conflicting segments. When a conflict is found, a rollback and retransmission are triggered and re-verification is performed. When there is no conflict, the final chain root is generated.

[0012] Write the final root link into the audit ledger, generate the final verification credential, perform trusted erasure of the migrated data and generate an erasure certificate, combine the final verification credential with the erasure certificate to generate a security verification result.

[0013] As a preferred embodiment of the cloud migration security verification method of the present invention, the migration data refers to business data records classified according to data type, sensitivity level and business affiliation.

[0014] As a preferred embodiment of the cloud migration security verification method of the present invention, the specific steps for generating the migration list are as follows:

[0015] The migration data is scanned to extract data type, sensitivity level and business affiliation, and a unique number is generated for each piece of migration data to obtain a classified dataset;

[0016] The classified datasets are processed sequentially according to logical relationships and time attributes, and a corresponding timestamp and hash value are generated for each migration data to obtain a verifiable dataset.

[0017] Record and organize the verifiable dataset to generate a migration list.

[0018] As a preferred embodiment of the cloud migration security verification method of the present invention, the steps of sequentially processing migration data according to the migration list, constructing a time-series hash chain, generating a serialization plan, and simultaneously calculating an initial digest snapshot and writing it to the audit ledger are as follows.

[0019] The migration data is standardized and rearranged sequentially based on the migration list to generate an ordered record stream;

[0020] The hash of each record in the ordered stream is calculated and concatenated to build a time-series hash chain. At the same time, the record order, number and timestamp information are extracted to generate a serialization plan.

[0021] Calculate an initial digest value for the serialization plan and attach a digital signature to write it into the audit ledger.

[0022] As a preferred embodiment of the cloud migration security verification method of the present invention, the encrypted transmission channel is obtained by the source end and the target end performing dynamic key negotiation based on batch metadata and time-series hash chain before migration, and remotely proving through a trusted component to generate a session key, and then using the session key to drive the establishment of the transmission tunnel.

[0023] As a preferred embodiment of the cloud migration security verification method of the present invention, the specific steps for generating dynamic verification results are as follows:

[0024] According to the serialization plan, the migration data is aggregated in batches and batch metadata is generated. The hash is calculated for each record and a batch Merkle root is constructed. The batch metadata is encrypted and signed using a temporary key derived from the batch random number to generate encrypted batch metadata.

[0025] Encrypted batch metadata and batch metadata are sent to the target end in batches through an encrypted transmission channel. Reliable transmission and forward error correction mechanisms are used to verify the integrity of the batch metadata and generate a batch data queue.

[0026] The target end decrypts and verifies the signature of each batch of data queue, reconstructs the hash and compares it with the batch Merkle root, checks the logical number and timestamp, and generates the batch verification status.

[0027] The target end generates a receipt certificate based on the batch verification status, writes it into the audit ledger and sends it back to the source end. The source end updates the certificate cache and retransmission plan. The target end summarizes all confirmed verification statuses and generates dynamic verification results.

[0028] As a preferred embodiment of the cloud migration security verification method of the present invention, the pre-trained anomaly detection model is obtained by collecting dynamic verification results, hash comparison records and transmission order logs of migration data, constructing a multi-dimensional feature vector set and labeling it, pre-training it using a deep learning model, and incrementally optimizing it based on the dynamic verification results during the actual migration process.

[0029] As a preferred embodiment of the cloud migration security verification method of the present invention, the following steps are taken: The dynamic verification result is input into a pre-trained anomaly detection model to automatically analyze the migration data and the dynamic verification result. When an anomaly is detected, a re-verification request is generated and the source end is triggered to re-output the corresponding batch metadata; otherwise, an incremental verification proof is generated.

[0030] The migration data and dynamic verification results are input into the pre-trained anomaly detection model to perform feature comparison and pattern recognition, and generate anomaly scores and confidence levels.

[0031] Based on the anomaly score and confidence level, anomaly tags are generated for each batch of metadata, forming a batch-level anomaly analysis table;

[0032] Based on the batch-level anomaly analysis table, the anomaly score and anomaly score threshold corresponding to the anomaly mark, as well as the corresponding confidence level and confidence threshold, are judged. When the anomaly score is higher than the anomaly score threshold and the confidence level is lower than the confidence threshold, a re-verification request and retransmission plan are generated. When the anomaly score is lower than the anomaly score threshold and the confidence level is higher than the confidence threshold, the batch metadata is marked as verified and the status is recorded.

[0033] The re-verification request triggers the source end to re-output the corresponding batch metadata, and the target end performs hash comparison and sequence verification on the corresponding batch metadata again to generate incremental verification proof.

[0034] As a preferred embodiment of the cloud migration security verification method described in this invention, the incremental verification proof is parsed and verified in the audit ledger, a consistency report is generated and marked as intact, missing and conflicting segments, a rollback and retransmission are triggered and re-verification is performed when a conflict is found, and the final chain root is generated when there is no conflict. The specific steps are as follows.

[0035] In the audit ledger, the incremental verification proof is parsed and verified to generate basic integrity information;

[0036] Based on the basic integrity information, the hash value, logical number and timestamp of each batch of metadata and record segments are compared and verified to generate a consistency report, and complete segments, missing segments and conflicting segments are marked to form a complete consistency analysis table.

[0037] Based on the complete consistency analysis table, the conflicting segments and reference values ​​are judged. When the conflicting segments and reference values ​​are inconsistent, a rollback and retransmission operation plan is generated.

[0038] According to the rollback and retransmission operation plan, the corresponding batch of metadata is rolled back and retransmitted, and hash comparison and sequence verification are performed again to generate an updated incremental verification certificate, and then the verification is performed in a loop.

[0039] When the conflicting segment and the reference value are consistent, the final chain root is generated.

[0040] As a preferred embodiment of the cloud migration security verification method of the present invention, the specific steps for generating the security verification result are as follows:

[0041] Write the final chain root into the audit ledger, generate the final verification credential, and record the writing timestamp and operation hash.

[0042] Based on the final verification credentials, the migrated data is reliably erased, and an erasure certificate is generated;

[0043] The final verification credentials are associated with and summarized with the erasure proof to generate a security verification result.

[0044] The beneficial effects of this invention are as follows: By inputting the dynamic verification results into the pre-trained anomaly detection model, the migration data and dynamic verification results are automatically analyzed to generate anomaly scores and confidence levels. Based on this, a batch-level anomaly analysis table is generated. Then, a re-verification request is triggered based on the anomaly markers, and the corresponding batch metadata is re-output, or an incremental verification proof is generated. This realizes real-time identification and processing of anomaly data during the migration process, reduces manual intervention, improves verification efficiency, and enables the data verification process to be iterative. It ensures that each batch of data undergoes complete verification before archiving, significantly improves cloud migration security, enhances the credibility and consistency of migration data, and provides dynamic assurance for the formation of security verification results. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart of a cloud migration security verification method.

[0047] Figure 2 A flowchart generated for the migration manifest.

[0048] Figure 3 A flowchart for constructing a time-series hash chain.

[0049] Figure 4 A flowchart generated for dynamic verification results. Detailed Implementation

[0050] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0051] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0052] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0053] Reference Figures 1-4 As one embodiment of the present invention, this embodiment provides a cloud migration security verification method, including the following steps:

[0054] S1. Scan and classify the migration data, attach a unique number, logical order, timestamp and hash value to each migration data, and record and organize it to generate a migration list.

[0055] S1.1 Migrating data refers to business data records classified according to data type, sensitivity level, and business affiliation.

[0056] Specifically, by scanning each piece of migration data, the type information, sensitivity level information, and business affiliation information of each piece of migration data are extracted. Based on the extracted information, the migration data is assigned to the corresponding category, and data sets belonging to the same data type, sensitivity level, and business affiliation are formed into business data records classified by data type, sensitivity level, and business affiliation.

[0057] S1.2 Scan the migration data, extract the data type, sensitivity level and business affiliation, and generate a unique number for each piece of migration data to obtain the classified dataset.

[0058] Specifically, the migration data is read and parsed one by one, and data type information, sensitivity level information and business affiliation information are extracted based on the attribute fields recorded in the migration data.

[0059] Migrating data is classified according to business attribute information, and migration data with the same data type, sensitivity level and business affiliation are grouped into the same category;

[0060] A unique number is generated for each piece of migration data to form traceable identification information, and the categorized migration data sets with the added unique numbers are organized into a categorized dataset.

[0061] S1.3. Sequentialize the classified dataset according to logical relationships and time attributes, and generate a corresponding timestamp and hash value for each migration data to obtain a verifiable dataset.

[0062] Specifically, the categorized dataset is sorted according to the logical relationship field of the migration data, the order of migration data is determined based on business processes or dependencies, and a corresponding timestamp is assigned to each piece of migration data in combination with the time attribute field;

[0063] A hash calculation is performed on each piece of migration data to generate a unique hash value. The expression is:

[0064] H i =Hash(D i );

[0065] Among them, H i D represents the unique hash value generated by the i-th migration data. i This represents the content of the i-th migration data, where Hash(·) represents the hash calculation function, and i represents the index of the migration data.

[0066] The sorted migration data is associated with the corresponding timestamps and hash values ​​to form a verifiable dataset.

[0067] S1.4 Record and organize the verifiable dataset to generate a migration list.

[0068] Specifically, for the verifiable dataset, the unique number, timestamp, hash value, and classification information of each migration data are recorded in logical order. The recorded information is summarized into a unified document, and the migration data is sorted and organized according to batch or business affiliation to generate a migration list, ensuring that each migration data has a corresponding record and verifiable information in the migration list.

[0069] S2. Based on the migration list, process the migration data sequentially, construct a time-series hash chain, generate a serialization plan, and simultaneously calculate an initial summary snapshot and write it to the audit ledger.

[0070] S2.1. Standardize the migration data according to the migration list and rearrange it sequentially to generate an ordered record stream.

[0071] Specifically, based on the migration list, the unique number, timestamp, logical order, and classification information of each migration data are read sequentially. The migration data is then standardized in terms of field format, content, and redundant information is removed. It is sorted and rearranged according to timestamp and logical order. The processed migration data is arranged sequentially to form an ordered record stream, ensuring that each migration data has standardized fields and traceable sequence information in the ordered record stream.

[0072] S2.2 Calculate the hash of each record in the ordered stream and concatenate them to build a time-series hash chain. At the same time, extract the record order, number and timestamp information to generate a serialization plan.

[0073] Specifically, each migration data in the ordered record stream is read sequentially, the content of each migration data is input into a hash calculation method to generate a hash value, and the hash value of the previous migration data is concatenated with the hash value of the current migration data to construct a continuous temporal hash chain. At the same time, the logical order, unique number and timestamp information of each migration data are extracted and arranged in order to form a serialization plan, ensuring that the temporal hash chain corresponds one-to-one with the record order and identification information in the serialization plan.

[0074] S2.3 Calculate the initial digest value for the serialization plan and attach a digital signature to write it into the audit ledger.

[0075] Specifically, all record information in the serialization plan is aggregated, and the aggregated content is input into a digest calculation method to generate an initial digest value, such as using the SHA-256 hash algorithm to obtain a fixed-length digest;

[0076] The initial digest value is signed using a pre-acquired digital signature key to generate a digital signature. The initial digest value and the digital signature are then written into the audit ledger in chronological and logical order.

[0077] It should also be noted that the pre-obtained digital signature key is generated through a digital certificate issued by a trusted identity authentication authority. A public-private key pair is generated in the source device, and the public key is submitted to the trusted identity authentication authority for registration and verification. After verification, the trusted identity authentication authority issues a digital certificate containing the public key. The source device stores the private key through a secure storage mechanism for signing operations. The private key is only used to digitally sign the digest value, while the public key can be used to verify the authenticity of the signature during the audit ledger verification process, thereby ensuring the reliability and immutability of the digital signature.

[0078] S3. According to the serialization plan, the migration data and time-series hash chain are sent to the target end in batches through the encrypted transmission channel. After receiving the data, the target end performs hash comparison on the migration data and verifies the transmission order, generating dynamic verification results.

[0079] S3.1. According to the serialization plan, the migration data is aggregated in batches and batch metadata is generated. The hash is calculated for each record and the batch Merkle root is constructed. The temporary key is derived using the batch random number to encrypt and sign the batch metadata, generating encrypted batch metadata.

[0080] Specifically, based on the serialization plan, the migration data is aggregated according to the example batch size to generate batch metadata;

[0081] Calculate the hash value for each record in the batch metadata one by one. After calculating the hash value for each record in the batch metadata, pair the hash values ​​in order to calculate the parent node hash. Construct a hash binary tree upwards in sequence until a single root node hash is generated, which is the batch Merkle root.

[0082] A temporary symmetric encryption key is derived using batch random numbers to encrypt the batch metadata. At the same time, a signature is generated on the encrypted batch metadata using a pre-obtained digital signature key, thus forming encrypted batch metadata.

[0083] S3.2. Send the encrypted batch metadata and batch metadata to the target end in batches through the encrypted transmission channel. Use reliable transmission and forward error correction mechanism to verify the integrity of the batch metadata and generate a batch data queue.

[0084] Specifically, according to the serialization plan, the encrypted batch metadata and batch metadata are divided into batches and then sent to the target end in batches through the encrypted transmission channel;

[0085] During transmission, a sequence number and verification information are attached to each encrypted batch metadata and batch metadata. A reliable transmission protocol is used to manage the transmission order and reception confirmation. At the same time, forward error correction codes are added to the batch metadata to support the receiver in repairing lost or damaged data.

[0086] After receiving each batch, the target end first reassembles the data according to the sequence number, then uses forward error correction codes to verify and correct the batch metadata, and generates a complete batch data queue for each batch.

[0087] S3.3 The target end decrypts and verifies the signature of each batch of data in the queue, reconstructs the hash and compares it with the batch Merkle root, checks the logical number and timestamp, and generates the batch verification status.

[0088] Specifically, after receiving the batch data queue, the target end decrypts each encrypted batch metadata in batch order and verifies the signature using the corresponding signature.

[0089] The batch Merkle root is reconstructed based on the record order and hash value in the decrypted batch metadata of each record. The reconstructed Merkle root is then compared with the received batch Merkle root. When the target end checks the logical number and timestamp of each record, it compares the logical number in the record with the logical number at the corresponding position in the serialization plan one by one, and compares the timestamp in the record with the timestamp at the corresponding position in the serialization plan one by one. When both the logical number and timestamp completely match the serialization plan, it is determined to be consistent; otherwise, it is determined to be inconsistent, and the batch verification status of each batch is generated.

[0090] S3.4 The target end generates a receipt certificate based on the batch verification status, writes it into the audit ledger and sends it back to the source end. The source end updates the certificate cache and retransmission plan. The target end summarizes all confirmed verification statuses and generates dynamic verification results.

[0091] Specifically, the target end generates receipts for each batch based on the batch verification status, writes each receipt into the audit ledger, and sends it back to the source end through an encrypted channel. After receiving the receipts, the source end updates the receipt cache and adjusts the retransmission plan to record the batch data that needs to be retransmitted. After receiving the confirmation information from the source end, the target end summarizes all confirmed batch verification statuses, organizes the verification results in logical order, and generates dynamic verification results containing the verification status of each batch.

[0092] S3.5 The encrypted transmission channel is obtained by the source and target ends performing dynamic key negotiation based on batch metadata and time-series hash chain before migration, and remotely verifying through trusted components to generate a session key, and then using the session key to drive the establishment of the transmission tunnel.

[0093] Specifically, the source and target ends extract key identification information based on the migration list and batch metadata, including the migration task number, source and target end identifiers and batch number in the migration list, and the batch metadata unique identifier, batch metadata hash value, batch timestamp, sequence number and previous batch hash value in the batch metadata. Initial negotiation parameters are generated using a time-series hash chain. Both parties perform remote authentication through a trusted component to verify identity and environment integrity. After completing the remote authentication, a session key is calculated based on the negotiation parameters. The source end initializes the transmission tunnel using the session key and sends a tunnel establishment request to the target end. After receiving the request, the target end confirms the tunnel parameters using the same session key. Both parties complete key confirmation and establish an encrypted transmission tunnel, forming an encrypted transmission channel for subsequent batch transmission of migration data.

[0094] S4. Input the dynamic verification results into the pre-trained anomaly detection model to automatically analyze the migration data and dynamic verification results. When an anomaly is detected, a re-verification request is generated and the source end is triggered to re-output the corresponding batch metadata. Otherwise, an incremental verification proof is generated.

[0095] S4.1 Input the migration data and dynamic verification results into the pre-trained anomaly detection model, perform feature comparison and pattern recognition, and generate anomaly scores and confidence levels.

[0096] Specifically, the migration data and dynamic verification results are transformed into structured feature vectors one by one, and then standardized according to the input specifications of the pre-trained anomaly detection model, and then input into the pre-trained anomaly detection model in sequence.

[0097] After pre-training, the anomaly detection model performs feature comparison and pattern recognition on each feature vector with the historical migration behavior and transmission feature library, calculates the anomaly score and generates a confidence value, and outputs the anomaly score and confidence value for each migration data.

[0098] S4.2. Based on the anomaly score and confidence level, generate anomaly tags for each batch of metadata to form a batch-level anomaly analysis table.

[0099] Specifically, for each batch of metadata, the corresponding anomaly score and confidence value are read. Based on the preset score threshold and confidence threshold, for example, if the anomaly score is higher than 0.7 and the confidence value is lower than 0.8, the batch metadata is marked as abnormal; otherwise, it is marked as normal.

[0100] All batch metadata and anomaly tags are summarized sequentially to generate a batch-level anomaly analysis table containing batch number, record number, anomaly score, confidence level, and anomaly tag.

[0101] It should also be noted that the preset scoring threshold and confidence threshold are derived from statistical analysis and empirical evaluation of historical migration data and known anomalous samples. The specific steps are as follows: collect a certain amount of historical batch metadata and anomalous situation annotations; calculate the anomalous score distribution and corresponding confidence distribution of each batch metadata under the pre-trained anomaly detection model; determine the anomalous scoring threshold and confidence threshold based on statistical characteristics, such as calculating the mean, standard deviation, or quantiles. For example, set the anomalous scoring threshold to 0.7 of the upper quantile of the scoring distribution, and set the confidence threshold to the mean minus a certain multiple of the standard deviation; apply the obtained anomalous scoring threshold and confidence threshold to the anomalous labeling of subsequent batch metadata to determine whether each batch metadata is anomalous.

[0102] S4.3. Based on the batch-level anomaly analysis table, determine the anomaly score and anomaly score threshold corresponding to the anomaly mark, as well as the corresponding confidence level and confidence threshold. When the anomaly score is higher than the anomaly score threshold and the confidence level is lower than the confidence level threshold, a re-verification request and retransmission plan are generated. When the anomaly score is lower than the anomaly score threshold and the confidence level is higher than the confidence level threshold, the batch metadata is marked as verified and the status is recorded.

[0103] Specifically, the batch-level anomaly analysis table is read one by one for anomaly markers, and the batch metadata is judged to be abnormal based on the preset anomaly scoring threshold and confidence threshold.

[0104] When the anomaly score is greater than the score threshold and the confidence level is lower than the confidence threshold, a re-verification request for the corresponding batch is generated and a retransmission plan is established, and the information of the batch to be retransmitted is recorded.

[0105] When the anomaly score is lower than the score threshold and the confidence level is higher than the confidence level threshold, the corresponding batch metadata is marked as verified and the verification status and timestamp are recorded in the verification status record table to form a complete batch verification status record.

[0106] S4.4. Trigger the re-verification request to re-output the corresponding batch metadata on the source end, and perform hash comparison and sequence verification on the corresponding batch metadata again on the target end to generate incremental verification proof.

[0107] Specifically, based on the re-verification request, the source end re-outputs the corresponding batch metadata according to the retransmission plan, generates hash values ​​in the original batch order, and sends them to the target end through an encrypted transmission channel;

[0108] After receiving the data, the target end calculates the hash value of each record and compares it with the batch Merkle root. At the same time, it verifies the logical number and timestamp order. After confirming that the order and integrity are correct, it summarizes each record and batch information to generate an incremental verification certificate.

[0109] S4.5 The pre-trained anomaly detection model is obtained by collecting dynamic verification results, hash comparison records and transmission order logs of migration data, constructing a multi-dimensional feature vector set and labeling it, using a deep learning model for pre-training, and incrementally optimizing it based on the dynamic verification results during the actual migration process.

[0110] Specifically, the dynamic verification results, hash comparison records, and transmission order logs of the migration data are collected. A feature vector is generated for each piece of migration data, including logical number, timestamp, hash value, transmission order, and anomaly marker. A multi-dimensional feature vector set is constructed, and the multi-dimensional feature vector set is labeled, for example, by marking normal or abnormal status.

[0111] The labeled multidimensional feature vector set is input into the deep learning model for pre-training. During the training process, the weights and biases of the anomaly detection model are adjusted to minimize the prediction error.

[0112] In the actual migration process, the new dynamic verification results are input into the pre-trained anomaly detection model, the incremental error is calculated and the anomaly detection model is incrementally optimized, the weights of the anomaly detection model are updated, and a pre-trained anomaly detection model that can be used for anomaly scoring and confidence assessment is obtained.

[0113] Ideally, the dynamic verification results generated at the target end are deeply integrated with the pre-trained anomaly detection model to achieve real-time identification and automated processing of abnormal behavior in migration data during transmission. In existing technologies, cloud migration data verification typically relies on static rules or manual checks, with anomaly detection often being reactive and lacking real-time judgment and intelligent response. By constructing a multi-dimensional feature vector, including dynamic verification results, hash comparison records, and transmission sequence logs, and utilizing a deep learning model for pattern recognition, this approach can not only automatically determine whether migration data contains anomalies but also trigger the source end to re-output corresponding batch metadata based on anomaly markers, achieving incremental and cyclical verification. This significantly improves the accuracy and efficiency of anomaly data identification during migration, reduces manual intervention, and ensures that each batch of data undergoes complete verification before archiving, thereby enhancing the security, data consistency, and reliability of cloud migration.

[0114] S5. In the audit ledger, the incremental verification proof is parsed and verified, a consistency report is generated and the intact, missing and conflicting segments are marked. When a conflict is found, a rollback and retransmission are triggered and re-verification is performed. When there is no conflict, the final root chain is generated.

[0115] S5.1. In the audit ledger, the incremental verification proof is parsed and verified to generate basic integrity information.

[0116] Specifically, the incremental verification proof records are read from the audit ledger. Each record's logical number, timestamp, hash value, and signature information are parsed one by one. The signature is verified to confirm the source validity. The integrity and sequential consistency of the records are verified based on the hash value comparison. Records that fail the verification are counted and marked as abnormal. The parsing results are summarized to generate basic integrity information, including the total number of records, the number of records that passed the verification, the number of abnormal records, and the sequential integrity identifier. For example, basic integrity information containing a total of 1,000 records, 980 records that passed the verification, and 20 abnormal records is generated.

[0117] S5.2 Based on the basic integrity information, compare and verify the hash value, logical number and timestamp of each batch of metadata and record segments, generate a consistency report, and mark the intact segments, missing segments and conflicting segments to form a complete consistency analysis table.

[0118] Specifically, based on the basic integrity information, each batch of metadata and corresponding record segments are read one by one. First, the hash value, logical number, and timestamp of the record segment are extracted. Then, the reference hash value, logical number, and timestamp of the corresponding record segment are obtained from the serialization plan and the batch Merkle root. The extracted values ​​are compared with the reference values ​​item by item: the hash value is compared digit by digit to see if they are completely identical; the logical number is compared sequentially to see if it is continuous and consistent with the reference number; the timestamp is compared at the precise time point to see if it is consistent with the reference timestamp. When the hash value, logical number, and timestamp all match completely, it is determined to be an intact segment. When the logical number is missing or discontinuous, it is determined to be a missing segment. When the hash value or timestamp is inconsistent, it is determined to be a conflicting segment. The comparison results of each record segment are summarized to generate a consistency report and form a complete consistency analysis table containing intact segments, missing segments, and conflicting segments.

[0119] For example, the total number of records in the complete consistency analysis table is 500, including 480 intact records, 10 missing records, and 10 conflicting records.

[0120] S5.3. Based on the complete consistency analysis table, determine the conflicting segments and reference values. When the conflicting segments and reference values ​​are inconsistent, generate a rollback and retransmission operation plan.

[0121] Specifically, the conflict segment records are read one by one according to the complete consistency analysis table. The hash value, logical number and timestamp of the conflict segment are extracted and compared with the reference value in the serialization plan and batch Merkle root. When the hash value or timestamp is found to be inconsistent with the reference value, the record segment is marked as conflicted. The start and end range of the rollback operation is generated according to the logical number of the conflict segment. The batch metadata number and corresponding order that need to be retransmitted are recorded. The rollback start and end ranges and retransmission batch numbers of all conflict segments are summarized to form the rollback and retransmission operation plan.

[0122] For example, conflicting segments numbered 101 to 110 correspond to batch metadata numbers 5 to 6. The rollback and retransmission operation plans indicate the start and end numbers and the target operation sequence.

[0123] S5.4. According to the rollback and retransmission operation plan, rollback and retransmission of the corresponding batch metadata, re-perform hash comparison and sequence verification, generate updated incremental verification proof, and then perform verification in a loop.

[0124] Specifically, according to the rollback and retransmission operation plan, the batch metadata number and logical number are read one by one. Based on the rollback start and end range, the corresponding batch metadata is rolled back and restored at the source end. Then, according to the retransmission plan, the corresponding batch metadata is re-output to the target end.

[0125] The target end calculates the hash value of each batch metadata that is rolled back or retransmitted, compares the logical number with the timestamp, reconstructs the batch Merkle root and verifies the order consistency, and generates an incremental verification proof after the update.

[0126] If conflicts or anomalies still exist after the incremental verification proof is updated, repeat the rollback and retransmission steps until all batch metadata has completed hash comparison and sequential verification and is marked as verified.

[0127] S5.5 When the conflicting segment and the reference value are consistent, the final chain root is generated.

[0128] Specifically, based on the complete consistency analysis table, each conflict segment record is read, the hash value of the conflict segment is extracted and compared with the reference value, and the hash value is compared with the reference value one by one. When all conflict segment hash values ​​are consistent with the reference values, the hash values ​​of each conflict segment are combined in pairs according to the batch order to calculate the upper-level hash, until the final chain root is generated.

[0129] Ideally, incremental verification proofs should be deeply integrated with the audit ledger to achieve dynamic management of the integrity and consistency of migrated data. In existing technologies, data migration verification typically relies on single-time verification or static comparison, making it difficult to promptly detect and correct data conflicts or omissions. Furthermore, rollback and retransmission operations are often manually intervened or processed in batches, resulting in low efficiency and difficulty in guaranteeing the integrity of each batch of data. By parsing and verifying incremental verification proofs, a consistency report is generated in the audit ledger, and each batch and record segment is marked with intact, missing, and conflicting segments, achieving refined management of data status. When a conflict is detected, rollback and retransmission operations are automatically triggered, and verification is performed cyclically until all conflicts are resolved, ultimately generating a root chain to form a trusted record. This not only achieves closed-loop management of migration data verification, improving the automation and accuracy of conflict handling, but also ensures that each piece of migrated data undergoes complete verification before archiving. Compared to existing technologies that rely solely on single-time verification or static comparison, this significantly improves the security and reliability of data migration.

[0130] S6. Write the final root chain into the audit ledger, generate the final verification certificate, perform trusted erasure on the migrated data and generate an erasure certificate, combine the final verification certificate and the erasure certificate to generate a security verification result.

[0131] S6.1 Write the final chain root into the audit ledger, generate the final verification voucher, and record the writing timestamp and operation hash.

[0132] Specifically, the final chain root is used as the record content, and the write operation is performed according to the audit ledger writing rules. At the same time, an operation hash is generated during the writing process to uniquely identify this write, the current time is extracted as the write timestamp, and the final chain root, operation hash and timestamp are integrated to form the final verification certificate.

[0133] For example, the final chain root "0xABC123" is written into the audit ledger, and an operation hash "0xDEF456" and a writing timestamp "2025-08-26T09:00:00" are generated to form the final verification credential.

[0134] S6.2. Based on the final verification certificate, perform trusted erasure of the migrated data and generate an erasure certificate.

[0135] Specifically, based on the final verification certificate, a trusted erasure operation is performed on each piece of migrated data, including reading the migrated data, overwriting the stored content and writing random numbers or zero values ​​in multiple rounds for erasure, verifying the completion of erasure and generating a hash digest as an erasure identifier, and integrating the erasure identifier, the logical number of the migrated data and the erasure time to form an erasure certificate.

[0136] For example, performing a trusted erasure on the migration data number "Batch001-Record05" generates a hash digest "0xEFA123" and records the erasure time "2025-08-26T09:15:00", thus forming a corresponding erasure proof.

[0137] S6.3. Associate and summarize the final verification credentials with the erasure proof to generate a security verification result.

[0138] Specifically, the final verification certificate is associated with the erasure certificate one by one. This includes extracting the batch metadata logical number, hash value and timestamp from the final verification certificate, matching them with the logical number, erasure hash digest and erasure time in the erasure certificate, and summarizing the matching results to form a security verification result table.

[0139] This embodiment also provides a computer device applicable to the cloud migration security verification method, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the cloud migration security verification method proposed in the above embodiment.

[0140] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0141] This embodiment also provides a storage medium storing a computer program, which, when executed by a processor, implements the cloud migration security verification method proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0142] In summary, this invention achieves real-time identification and processing of abnormal data during migration by: inputting dynamic verification results into a pre-trained anomaly detection model; automatically analyzing migration data and dynamic verification results; generating anomaly scores and confidence levels; generating batch-level anomaly analysis tables based on these scores; triggering re-verification requests based on anomaly markers and re-outputting corresponding batch metadata; or generating incremental verification proofs. This reduces manual intervention and improves verification efficiency, allows for iterative data verification, ensures that each batch of data undergoes complete verification before archiving, significantly enhances cloud migration security, strengthens the credibility and consistency of migration data, and provides dynamic assurance for the formation of security verification results.

[0143] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud migration security verification method, characterized in that: include, The migration data is scanned and classified, and each piece of migration data is assigned a unique number, logical order, timestamp, and hash value. The data is then recorded and organized to generate a migration list. The migration data is processed sequentially according to the migration list, a time-series hash chain is constructed, a serialization plan is generated, and an initial summary snapshot is calculated and written to the audit ledger. According to the serialization plan, the migration data and the time sequence hash chain are sent to the target end in batches through the encrypted transmission channel. After receiving the data, the target end performs hash comparison on the migration data and verifies the transmission order, and generates dynamic verification results. The dynamic verification results are input into the pre-trained anomaly detection model to automatically analyze the migration data and dynamic verification results. When an anomaly is detected, a re-verification request is generated and the source end is triggered to re-output the corresponding batch metadata. Otherwise, an incremental verification proof is generated. In the audit ledger, the incremental verification proof is parsed and verified, a consistency report is generated and marked as intact, missing and conflicting segments. When a conflict is found, a rollback and retransmission are triggered and re-verification is performed. When there is no conflict, the final chain root is generated. Write the final root link into the audit ledger, generate the final verification credential, perform trusted erasure of the migrated data and generate an erasure certificate, combine the final verification credential with the erasure certificate to generate a security verification result.

2. The cloud migration security verification method as described in claim 1, characterized in that: The migration data refers to business data records categorized by data type, sensitivity level, and business affiliation.

3. The cloud migration security verification method as described in claim 1, characterized in that: The specific steps for generating the migration list are as follows: The migration data is scanned to extract data type, sensitivity level and business affiliation, and a unique number is generated for each piece of migration data to obtain a classified dataset; The classified datasets are processed sequentially according to logical relationships and time attributes, and a corresponding timestamp and hash value are generated for each migration data to obtain a verifiable dataset. Record and organize the verifiable dataset to generate a migration list.

4. The cloud migration security verification method as described in claim 1, characterized in that: The steps involve sequentially processing the migration data according to the migration list, constructing a time-series hash chain, generating a serialization plan, calculating an initial digest snapshot, and writing it to the audit ledger. The specific steps are as follows: The migration data is standardized and rearranged sequentially based on the migration list to generate an ordered record stream; The hash of each record in the ordered stream is calculated and concatenated to build a time-series hash chain. At the same time, the record order, number and timestamp information are extracted to generate a serialization plan. Calculate an initial digest value for the serialization plan and attach a digital signature to write it into the audit ledger.

5. The cloud migration security verification method as described in claim 1, characterized in that: The encrypted transmission channel is obtained by the source and target ends performing dynamic key negotiation based on batch metadata and time-series hash chain before migration, and remotely verifying through trusted components to generate a session key, and then using the session key to drive the establishment of the transmission tunnel.

6. The cloud migration security verification method as described in claim 1, characterized in that: The specific steps for generating dynamic verification results are as follows: According to the serialization plan, the migration data is aggregated in batches and batch metadata is generated. The hash is calculated for each record and a batch Merkle root is constructed. The batch metadata is encrypted and signed using a temporary key derived from the batch random number to generate encrypted batch metadata. Encrypted batch metadata and batch metadata are sent to the target end in batches through an encrypted transmission channel. Reliable transmission and forward error correction mechanisms are used to verify the integrity of the batch metadata and generate a batch data queue. The target end decrypts and verifies the signature of each batch of data queue, reconstructs the hash and compares it with the batch Merkle root, checks the logical number and timestamp, and generates the batch verification status. The target end generates a receipt certificate based on the batch verification status, writes it into the audit ledger and sends it back to the source end. The source end updates the certificate cache and retransmission plan. The target end summarizes all confirmed verification statuses and generates dynamic verification results.

7. The cloud migration security verification method as described in claim 1, characterized in that: The pre-trained anomaly detection model is obtained by collecting dynamic verification results, hash comparison records, and transmission order logs of migration data, constructing a multi-dimensional feature vector set and labeling it, pre-training it using a deep learning model, and incrementally optimizing it based on the dynamic verification results during the actual migration process.

8. The cloud migration security verification method as described in claim 1, characterized in that: The dynamic verification results are input into the pre-trained anomaly detection model to automatically analyze the migration data and dynamic verification results. When an anomaly is detected, a re-verification request is generated and the source end is triggered to re-output the corresponding batch metadata; otherwise, an incremental verification proof is generated. The specific steps are as follows. The migration data and dynamic verification results are input into the pre-trained anomaly detection model to perform feature comparison and pattern recognition, and generate anomaly scores and confidence levels. Based on the anomaly score and confidence level, anomaly tags are generated for each batch of metadata, forming a batch-level anomaly analysis table; Based on the batch-level anomaly analysis table, the anomaly score and anomaly score threshold corresponding to the anomaly mark, as well as the corresponding confidence level and confidence threshold, are judged. When the anomaly score is higher than the anomaly score threshold and the confidence level is lower than the confidence threshold, a re-verification request and retransmission plan are generated. When the anomaly score is lower than the anomaly score threshold and the confidence level is higher than the confidence threshold, the batch metadata is marked as verified and the status is recorded. The re-verification request triggers the source end to re-output the corresponding batch metadata, and the target end performs hash comparison and sequence verification on the corresponding batch metadata again to generate incremental verification proof.

9. The cloud migration security verification method as described in claim 1, characterized in that: The process involves parsing and validating the incremental verification proof in the audit ledger, generating a consistency report and marking intact, missing, and conflicting segments. When a conflict is detected, a rollback and retransmission are triggered, and re-verification is performed. When there are no conflicts, the final chain root is generated. The specific steps are as follows. In the audit ledger, the incremental verification proof is parsed and verified to generate basic integrity information; Based on the basic integrity information, the hash value, logical number and timestamp of each batch of metadata and record segments are compared and verified to generate a consistency report, and complete segments, missing segments and conflicting segments are marked to form a complete consistency analysis table. Based on the complete consistency analysis table, the conflicting segments and reference values ​​are judged. When the conflicting segments and reference values ​​are inconsistent, a rollback and retransmission operation plan is generated. According to the rollback and retransmission operation plan, the corresponding batch of metadata is rolled back and retransmitted, and hash comparison and sequence verification are performed again to generate an updated incremental verification certificate, and then the verification is performed in a loop. When the conflicting segment and the reference value are consistent, the final chain root is generated.

10. The cloud migration security verification method as described in claim 1, characterized in that: The specific steps for generating the security verification result are as follows: Write the final chain root into the audit ledger, generate the final verification credential, and record the writing timestamp and operation hash. Based on the final verification credentials, the migrated data is reliably erased, and an erasure certificate is generated. The final verification credentials are associated with and summarized with the erasure proof to generate a security verification result.

Images