Cloud migration security verification method

Abstract

The invention discloses a cloud migration security verification method, and relates to the technical field of information, and the method comprises the steps: inputting a dynamic verification result into a pre-trained anomaly detection model, carrying out the automatic analysis of migration data and the dynamic verification result, generating a re-verification request when an anomaly is detected, and triggering a source end to output the corresponding batch of metadata again, otherwise, generating an increment verification proof; the increment verification proof is analyzed and verified in the audit account book, a consistency report is generated and intact, missing and conflicting segments are marked, rollback and supplementary transmission are triggered and verification is carried out again when conflicts are found, and a final chain root is generated when no conflicts exist; writing the final chain root into an audit account book, generating a final verification certificate, carrying out credible erasure on the migration data, generating an erasure certificate, and combining the final verification certificate with the erasure certificate to generate a security verification result. According to the method, each batch of data is ensured to be subjected to complete verification before archiving, so that the security, data consistency and credibility of cloud migration are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information technology, and in particular to a cloud migration security verification method. BACKGROUND

[0002] With the rapid development of cloud computing technology, the demand for data migration to cloud platforms by enterprises and organizations has significantly increased. Existing cloud migration technologies generally include data transmission, storage management, and access control, among other aspects, with data integrity and security being key issues in the migration process. Traditional data migration verification methods rely on basic verification mechanisms, such as file hash comparison, transmission log recording, and simple transmission retry strategies, to ensure that migrated data is not tampered with or lost during transmission. At the same time, timestamps and sequential numbers are used to perform basic sequence verification on data batches to improve the traceability of the migration process.

[0003] In existing technologies, although hash values, timestamps, and basic sequence verification can achieve partial integrity protection of migrated data, there is still a lack of efficient identification and processing mechanisms for dynamic abnormal situations during the migration process. For example, when migration data encounters an exception or conflict during transmission, traditional solutions often rely on manual intervention or single retries, which cannot achieve continuous incremental verification and automated rollback, resulting in reduced migration efficiency and potential data consistency risks. SUMMARY

[0004] In view of the above existing problems, the present application is proposed.

[0005] Therefore, the present application provides a cloud migration security verification method to solve the problem of insufficient integrity and consistency protection of migrated data.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] The present application provides a cloud migration security verification method, which includes scanning and classifying migration data, attaching a unique number, logical sequence, timestamp, and hash value to each piece of migration data, and recording and organizing them to generate a migration list;

[0008] According to the migration list, the migration data is sequentially processed to construct a time sequence hash chain, generate a serialization plan, and calculate an initial digest snapshot and write it into an audit book;

[0009] According to the serialization plan, the migration data and time sequence hash chain are sent to the target end in batches through an encrypted transmission channel, and the target end receives the migration data and performs hash comparison and verifies the transmission sequence to generate a dynamic verification result;

[0010] The dynamic verification result is input into the pre-trained anomaly detection model, the migration data and the dynamic verification result are automatically analyzed, when an anomaly is detected, a re-verification request is generated and the source end re-outputs the corresponding batch of metadata, otherwise, an incremental verification certificate is generated;

[0011] The incremental verification certificate is parsed and verified in the audit ledger, a consistency report is generated and the intact, missing and conflict segments are marked, when a conflict is found, rollback and retransmission are triggered and re-verification is performed, and when there is no conflict, a final chain root is generated;

[0012] The final chain root is written into the audit ledger, a final verification credential is generated, the migration data is trustedly erased and an erasure certificate is generated, the final verification credential and the erasure certificate are combined to generate a secure verification result.

[0013] As a preferred scheme of the cloud migration security verification method, wherein: the migration data refers to business data records classified by data type, sensitivity level and business attribution.

[0014] As a preferred scheme of the cloud migration security verification method, wherein: the migration list is generated, and the specific steps are as follows,

[0015] The migration data is scanned, the data type, sensitivity level and business attribution are extracted, and a unique number is generated for each migration data to obtain a classified data set;

[0016] The classified data set is sequentially processed according to the logical relationship and the time attribute, and a corresponding timestamp and hash value are generated for each migration data to obtain a verifiable data set;

[0017] The verifiable data set is recorded and arranged to generate a migration list.

[0018] As a preferred scheme of the cloud migration security verification method, wherein: the migration data is sequentially processed according to the migration list, a time sequence hash chain is constructed, a serialization plan is generated, and an initial digest snapshot is calculated and written into the audit ledger, and the specific steps are as follows,

[0019] The migration data is normalized and sequentially rearranged according to the migration list to generate an ordered record stream;

[0020] The ordered record stream is calculated and concatenated to construct a time sequence hash chain, and the record order, number and timestamp information are extracted to generate a serialization plan;

[0021] The initial digest value of the serialization plan is calculated, and a digital signature is attached and written into the audit ledger.

[0022] As a preferred scheme of the cloud migration security verification method, the encryption transmission channel is dynamically negotiated by the source end and the target end based on batch metadata and a time sequence hash chain before migration, and a session key is generated through remote proof by a trusted component, and the session key is used to drive the establishment of a transmission tunnel.

[0023] As a preferred scheme of the cloud migration security verification method, the encryption transmission channel is dynamically negotiated by the source end and the target end based on batch metadata and a time sequence hash chain before migration, and a session key is generated through remote proof by a trusted component, and the session key is used to drive the establishment of a transmission tunnel.

[0024] According to the serialization plan, the migration data is aggregated by batch and batch metadata is generated, the hash is calculated record by record and the batch Merkle root is constructed, the temporary key is derived by using the batch random number to encrypt and sign the batch metadata, and the encrypted batch metadata is generated;

[0025] The encrypted batch metadata and the batch metadata are sent to the target end in batches through the encryption transmission channel, the integrity of the batch metadata is verified by using the reliable transmission and the forward error correction mechanism, and the batch data queue is generated;

[0026] The target end decrypts and verifies the signature of the batch data queue one by one, reconstructs the hash and compares the batch Merkle root, checks the logical number and the timestamp, and generates the batch verification state;

[0027] The target end generates a receipt proof according to the batch verification state, writes it into an audit book and returns it to the source end, the source end updates the proof cache and the retransmission plan, and the target end summarizes all the confirmed verification states to generate a dynamic verification result.

[0028] As a preferred scheme of the cloud migration security verification method, the pre-trained anomaly detection model is obtained by collecting the dynamic verification result of the migration data, the hash comparison record and the transmission order log, constructing a multi-dimensional feature vector set and labeling, pre-training by using a deep learning model, and incrementally optimizing based on the dynamic verification result in the actual migration process.

[0029] As a preferred scheme of the cloud migration security verification method, the dynamic verification result is input into the pre-trained anomaly detection model, and the migration data and the dynamic verification result are automatically analyzed, 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 correction proof is generated, and the specific steps are as follows,

[0030] The migration data and the dynamic verification result are input into the pre-trained anomaly detection model, feature comparison and pattern recognition are performed, and an anomaly score and a confidence are generated.

[0031] According to the anomaly score and the confidence, an anomaly mark is generated for each batch metadata to form a batch-level anomaly analysis table.

[0032] According to the batch-level anomaly analysis table, the anomaly score corresponding to the anomaly mark is judged with the anomaly score threshold value and the corresponding confidence and the confidence threshold value, when the anomaly score is higher than the anomaly score threshold value and the confidence is lower than the confidence threshold value, a re-verification request and a retransmission plan are generated, when the anomaly score is lower than the anomaly score threshold value and the confidence is higher than the confidence threshold value, the batch metadata mark is verified and the state is recorded;

[0033] The re-verification request triggers the source end to re-output the corresponding batch metadata, and the corresponding batch metadata is again subjected to hash comparison and sequence verification at the target end, and an incremental verification certificate is generated.

[0034] As a preferred scheme of the cloud migration security verification method, wherein: the incremental verification certificate is analyzed and verified in the audit ledger, a consistency report is generated and the intact, missing and conflict segments are marked, when a conflict is found, rollback and supplement transmission and re-verification are triggered, when there is no conflict, a final chain root is generated, the specific steps are as follows,

[0035] The incremental verification certificate is analyzed and verified in the audit ledger to generate basic integrity information;

[0036] According to the basic integrity information, the hash value, logical number and timestamp of each batch metadata and record segment are compared and verified to generate a consistency report, and the intact segment, missing segment and conflict segment are marked to form a complete consistency analysis table;

[0037] According to the complete consistency analysis table, the conflict segment and the reference value are judged, when the conflict segment and the reference value are inconsistent, a rollback and supplement transmission operation plan is generated;

[0038] According to the rollback and supplement transmission operation plan, the corresponding batch metadata is rolled back and supplemented, and hash comparison and sequence verification are performed again to generate an updated incremental verification certificate, and the verification is performed again in a loop;

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

[0040] As a preferred scheme of the cloud migration security verification method, wherein: the security verification result is generated, the specific steps are as follows,

[0041] The final chain root is written into the audit ledger to generate a final verification voucher, and the writing timestamp and operation hash are recorded;

[0042] According to the final verification voucher, the migrated data is trusted to be erased to generate an erasure proof;

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

[0044] The application has the beneficial effects that: by inputting the dynamic verification result into the pre-trained anomaly detection model, the migration data and the dynamic verification result are automatically analyzed to generate an anomaly score and a confidence, and a batch-level anomaly analysis table is generated accordingly, and according to the anomaly mark, a re-verification request is triggered and the corresponding batch metadata is re-output, or an incremental verification certificate is generated, the real-time identification and processing of abnormal data in the migration process are realized, the manual intervention is reduced and the verification efficiency is improved, the data verification process can be iterated, the complete verification of each batch of data before archiving is ensured, the cloud migration security is significantly improved, the credibility and consistency of the migration data are enhanced, and dynamic protection is provided for the formation of a safe verification result. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0046] Fig. 1 The flowchart of the cloud migration security verification method.

[0047] Fig. 2 The flowchart for generating the migration list.

[0048] Fig. 3 The flowchart for constructing the time sequence hash chain.

[0049] Fig. 4 The flowchart for generating the dynamic verification result. DETAILED DESCRIPTION

[0050] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the drawings.

[0051] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application, but the present application can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of the present application, therefore the present application is not limited to the specific embodiments disclosed below.

[0052] Secondly, the "one embodiment" or "embodiment" referred to herein means that the specific features, structures or characteristics can be included in at least one implementation of the present application. "In one embodiment" appearing in different places in the specification does not mean the same embodiment, nor is it an independent or alternative embodiment that excludes other embodiments.

[0053] Referring to Figs. 1-4 For an embodiment of the present application, the embodiment provides a cloud migration security verification method, comprising the following steps:

[0054] S1, scanning and classifying the migration data, adding a unique number, a logical order, a timestamp and a hash value to each piece of migration data, and recording and organizing, to generate a migration list.

[0055] S1.1, the migration data refers to the business data records classified by data type, sensitivity level and business attribution.

[0056] Specifically, by scanning each piece of migration data, the type information, the sensitivity level information and the business attribution information of each piece of migration data are extracted, and the migration data is distributed to the corresponding category according to the extracted information, and the data set belonging to the same data type, sensitivity level and business attribution is formed. The business data records classified by data type, sensitivity level and business attribution.

[0057] S1.2, scanning the migration data, extracting the data type, the sensitivity level and the business attribution, and generating a unique number for each piece of migration data to obtain the classified data set.

[0058] Specifically, the migration data is read and parsed piece by piece, and the data type information, the sensitivity level information and the business attribution information are extracted according to the attribute fields recorded in the migration data;

[0059] According to the business attribute information, the migration data is classified, and the migration data with the same data type, sensitivity level and business attribution is classified into the same category;

[0060] A unique number is generated for each piece of migration data to form traceable identification information, and the classified migration data set with the unique number is organized to form the classified data set.

[0061] S1.3, the classified data set is sequentially processed according to the logical relationship and the time attribute, and the corresponding timestamp and hash value are generated for each piece of migration data to obtain the verifiable data set.

[0062] Specifically, the classified data set is sorted according to the logical relationship field of the migration data, the order of the migration data is determined according to the business process or the dependency relationship, and the corresponding timestamp is assigned to each piece of migration data in combination with the time attribute field;

[0063] The content of each piece of migration data is hashed to generate a unique hash value, and the expression is:

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

[0065] wherein H i represents the unique hash value of the i-th migration data, D i represents the content of the i-th migration data, Hash(·) represents a hash calculation function, and i represents the index of the migration data;

[0066] The sorted migration data is associated with the corresponding timestamp and hash value to form a verifiable data set.

[0067] S1.4, record and organize the verifiable data set to generate a migration list.

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

[0069] S2, sequentially process the migration data according to the migration list, construct a time sequence hash chain, generate a serialization plan, and calculate an initial digest snapshot and write it into an audit book.

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

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

[0072] S2.2, calculate the hash of each migration data in the ordered record stream and concatenate to construct a time sequence hash chain, and 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 in sequence, 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 time sequence hash chain, while 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 time sequence hash chain and the record order and identification information in the serialization plan correspond one by one.

[0074] S2.3, calculate the initial digest value of the serialization plan and attach a digital signature to the audit book.

[0075] Specifically, all record information in the serialization plan is summarized, and the summarized content is input into an abstract calculation method to generate an initial abstract value, for example, a fixed-length abstract obtained by using an SHA-256 hash algorithm;

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

[0077] It should be noted that the pre-acquired digital signature key is generated by a digital certificate issued by a trusted identity authentication agency. A public-private key pair is generated in the source device, and the public key is submitted to the trusted identity authentication agency for registration and verification. After verification, the trusted identity authentication agency issues a digital certificate containing the public key. The source end saves the private key for signature operation through a secure storage mechanism. The private key is only used for digital signature of the abstract value, and the public key can be used in the audit ledger verification process to verify the authenticity of the signature, thereby ensuring the reliability and tamper resistance of the digital signature.

[0078] S3. According to the serialization plan, the migration data and the time sequence hash chain are sent to the target end in batches through an encrypted transmission channel. The target end receives the migration data and verifies the transmission order by performing hash comparison, and generates a dynamic verification result.

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

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

[0081] The hash value of each record in the batch metadata is calculated, and after the hash value of each record in the batch metadata is calculated, the hash value is paired in order to calculate the parent node hash, and the hash binary tree is constructed in turn until a single root node hash is generated, that is, the batch Merkle root;

[0082] The temporary symmetric encryption key is derived by using the batch random number to encrypt the batch metadata, and the pre-acquired digital signature key is used to generate a signature for the encrypted batch metadata to form the encrypted batch metadata.

[0083] S3.2, the encrypted batch metadata and the batch metadata are sent to the target end in batches through an encrypted transmission channel, and the batch data queue is generated by using reliable transmission and forward error correction mechanism to perform integrity check on the batch metadata.

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

[0085] During transmission, a sequence number and check information are attached to each encrypted batch metadata and batch metadata, and a reliable transmission protocol is used to manage the sending order and reception confirmation, and a forward error correction code is added to the batch metadata to support the reception end to repair the lost or damaged data;

[0086] After the target end receives each batch, it first reorganizes the sequence according to the sequence number, then checks and corrects the batch metadata using the forward error correction code, and generates a complete batch data queue by batch.

[0087] S3.3, the target end decrypts and signature verifies the batch data queue one by one, reconstructs the hash and compares the batch Merkle root, checks the logical number and timestamp, and generates the batch verification state.

[0088] Specifically, after the target end receives the batch data queue, it decrypts each encrypted batch metadata one by one according to the batch order, and performs signature verification using the corresponding signature;

[0089] According to the record order and hash value in each decrypted batch metadata, the batch Merkle root is reconstructed, and the reconstructed Merkle root is compared with the received batch Merkle root. When checking the logical number and timestamp of each record, the target end 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 the logical number and timestamp are completely matched with the serialization plan, it is determined to be consistent, otherwise it is determined to be inconsistent, and the batch verification state of each batch is generated.

[0090] S3.4, the target end generates a receipt proof according to the batch verification state, and writes it into the audit ledger and returns it to the source end, the source end updates the proof cache and retransmission plan, and the target end summarizes all confirmed verification states to generate a dynamic verification result.

[0091] Specifically, the target end generates a receipt proof according to the batch verification state, writes each receipt proof into the audit ledger and returns it to the source end through an encrypted channel. After receiving the receipt proof, the source end updates the proof 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 states, arranges the verification results in logical order, and generates a dynamic verification result containing the batch verification states.

[0092] S3.5, the encryption transmission channel is dynamically negotiated by the source end and the target end based on the batch metadata and the time sequence hash chain before migration, and is remotely proved by the trusted component to generate a session key, and then the session key is used to drive the establishment of the transmission tunnel.

[0093] Specifically, the source end and the target end extract key identification information including migration task numbers in the migration list, source end and target end identifiers and batch numbers according to the migration list and the batch metadata, and batch metadata unique identifiers, batch metadata hash values, batch timestamps, sequence numbers and previous batch hash values in the batch metadata, and generate initial negotiation parameters using a time sequence hash chain. Both parties verify identity and environmental integrity by performing remote proof through a trusted component. After completing the remote proof, the 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. The target end confirms the tunnel parameters using the same session key after receiving the request. Both parties complete key confirmation and encrypted transmission tunnel establishment, forming an encrypted transmission channel for subsequent migration data batch transmission.

[0094] S4, input the dynamic verification result into the pre-trained anomaly detection model, and 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 certificate is generated.

[0095] S4.1, input the migration data and the dynamic verification result into the pre-trained anomaly detection model, and perform feature comparison and pattern recognition to generate an anomaly score and a confidence.

[0096] Specifically, the migration data and the dynamic verification result are converted into structured feature vectors one by one, and standardized according to the input specification of the pre-trained anomaly detection model, and then input into the pre-trained anomaly detection model.

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

[0098] S4.2, according to the anomaly score and the confidence, an anomaly label is generated for each batch metadata to form a batch-level anomaly analysis table.

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

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

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

[0102] S4.3, according to the batch-level anomaly analysis table, the anomaly score corresponding to the anomaly label is judged with the anomaly score threshold and the confidence corresponding to the confidence threshold, when the anomaly score is higher than the anomaly score threshold and the confidence is lower than the confidence threshold, the re-verification request and the retransmission plan are generated, when the anomaly score is lower than the anomaly score threshold and the confidence is higher than the confidence threshold, the batch metadata is marked as verified and the state is recorded.

[0103] Specifically, read the anomaly label from the batch-level anomaly analysis table, determine whether the batch metadata is abnormal according to the preset anomaly score threshold and confidence threshold;

[0104] When the anomaly score is greater than the score threshold and the confidence is lower than the confidence threshold, generate a re-verification request for the corresponding batch and establish a retransmission plan, record the information of the batch to be retransmitted;

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

[0106] S4.4, the re-verification request triggers the source to re-output the corresponding batch metadata, and the target performs hash comparison and sequence verification on the corresponding batch metadata again to generate an incremental proof of correction.

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

[0108] The target end calculates the hash value of each record after receiving and compares the batch Merkle root, checks the logical number and the time stamp sequence, confirms that the sequence and integrity are correct, and then generates the incremental verification proof by summarizing each record and batch information.

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

[0110] Specifically, the dynamic verification results of the migration data, the hash comparison records and the transmission sequence logs are collected, the feature vector of each migration data is generated, including the logical number, the time stamp, the hash value, the transmission sequence and the abnormal mark, a multi-dimensional feature vector set is constructed, and the multi-dimensional feature vector set is labeled, for example, normal or abnormal state;

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

[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 the pre-trained anomaly detection model that can be used for anomaly scoring and confidence evaluation is obtained.

[0113] Preferably, the dynamic verification results generated by the target end are deeply combined with the pre-trained anomaly detection model, and the real-time identification and automatic processing of abnormal behaviors of the migration data in the transmission process are realized. In the prior art, cloud migration data verification usually relies on static rules or manual checking, and the discovery of abnormal situations is mostly post-processing, lacking real-time judgment and intelligent response to abnormalities. By constructing a multi-dimensional feature vector including dynamic verification results, hash comparison records and transmission sequence logs, and using a deep learning model for pattern recognition, not only can the presence of abnormal migration data be automatically judged, but also the source can be triggered to output the corresponding batch of metadata according to the abnormal mark, realizing incremental and cyclic verification. The identification accuracy and processing efficiency of abnormal data in the migration process are significantly improved, manual intervention is reduced, and each batch of data is verified completely before archiving, thereby improving the security, data consistency and credibility of cloud migration.

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

[0115] S5.1, parse and verify the incremental proof of audit in the audit ledger, and generate basic integrity information.

[0116] Specifically, the record content of the incremental proof of audit is read in the audit ledger, and the logical number, timestamp, hash value and signature information of each record are parsed one by one. The signature is verified to confirm the validity of the source. The hash value is compared to verify the integrity and sequence consistency of the record. The records that do not pass the verification are counted and marked as abnormal. The analysis results are summarized to generate basic integrity information, including the total number of records, the number of records that pass the verification, the number of abnormal records and the sequence integrity identifier. For example, the basic integrity information including the total number of records is 1000, the number of records that pass the verification is 980 and the number of abnormal records is 20 is generated.

[0117] S5.2, according to the basic integrity information, the hash value, logical number and timestamp of each batch of metadata and record segment are compared and verified, a consistency report is generated, and the intact segment, missing segment and conflict segment are marked to form a complete consistency analysis table.

[0118] Specifically, according to the basic integrity information, each batch of metadata and corresponding record segment is read one by one. The hash value, logical number and timestamp of the record segment are extracted, and the reference hash value, logical number and timestamp of the corresponding record segment are obtained from the serialization plan and batch Merkle root. The extracted values and reference values are compared one by one: the hash values are compared bit by bit to see if they are exactly the same, the logical numbers are compared in sequence to see if they are continuous and consistent with the reference number, and the timestamps are compared to see if they are consistent with the reference timestamp. When the hash value, logical number and timestamp are completely matched, it is determined as an intact segment. When the logical number is missing or discontinuous, it is determined as a missing segment. When the hash value or timestamp is inconsistent, it is determined as a conflict segment. The comparison results of each record segment are summarized to generate a consistency report, and a complete consistency analysis table including intact segment, missing segment and conflict segment mark is formed.

[0119] For example, the total number of record segments in the complete consistency analysis table is 500, of which 480 are intact segments, 10 are missing segments and 10 are conflict segments.

[0120] S5.3, according to the complete consistency analysis table, the conflict segment and the reference value are judged, and when the conflict segment and the reference value are inconsistent, the rollback and retransmission operation plan is generated.

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

[0122] For example, the conflict segment number is 101 to 110, the corresponding batch metadata number is 5 to 6, and the start and end numbers and target operation order are marked in the rollback and supplement operation plan.

[0123] S5.4, according to the rollback and supplement operation plan, the corresponding batch metadata is rolled back and supplemented, and the hash comparison and order verification are performed again to generate an updated incremental verification certificate, and the verification is repeated.

[0124] Specifically, according to the rollback and supplement operation plan, the batch metadata number and logical number are read piece by piece, the corresponding batch metadata is rolled back and recovered at the source end according to the rollback start and end range, and the corresponding batch metadata is output to the target end again according to the supplement plan;

[0125] The target end calculates the hash value of each rolled back or supplemented batch metadata and performs logical number and timestamp comparison, reconstructs the batch Merkle root and verifies the sequence consistency, and generates an updated incremental verification certificate;

[0126] When the updated incremental verification certificate still has conflicts or exceptions, the rollback and supplement steps are repeated until all batch metadata completes hash comparison and order verification and is marked as verified.

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

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

[0129] Preferably, the incremental verification proof is deeply combined with the audit ledger to realize dynamic management of the integrity and consistency of the migrated data. In the prior art, data migration verification usually only relies on single verification or static comparison, which is difficult to discover and correct data conflicts or omissions in a timely manner, and the rollback and supplement operations are mostly manually intervened or processed in batches, which is low in efficiency and difficult to guarantee the integrity of each batch of data. By analyzing and verifying the incremental verification proof, a consistency report is generated in the audit ledger, and each batch and record segment is marked as a perfect segment, a missing segment and a conflict segment to realize fine management of the data state; when a conflict is found, the rollback and supplement operations are automatically triggered and verified in a loop until all conflicts are resolved, and a chain root is finally generated to form a trusted record. Not only does it realize closed-loop management of migration data verification, improve the automation and accuracy of conflict processing, but also guarantees that each piece of migrated data is completely verified before archiving, which significantly improves the security and credibility of data migration compared with the prior art which only relies on single verification or static comparison.

[0130] S6.1, write the final chain root into the audit ledger to generate a final verification voucher, record the write timestamp and operation hash at the same time.

[0131] S6.1, write the final chain root into the audit ledger to generate a final verification voucher, record the write timestamp and operation hash at the same time.

[0132] Specifically, the final chain root is taken as the record content, the write operation is performed according to the audit ledger write rule, the operation hash is generated to uniquely identify this write in the write process, 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 voucher.

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

[0134] S6.2, according to the final verification voucher, the migrated data is trusted to be erased to generate an erasure proof.

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

[0136] For example, perform trusted erasure on the migration data number "Batch001-Record05", generate the hash digest "0xEFA123" and record the erasure time "2025-08-26T09:15:00", form the corresponding erasure proof.

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

[0138] Specifically, the final verification credentials are associated with the erasure proof one by one, including extracting the batch metadata logical number, hash value and timestamp in the final verification credentials, matching the logical number, erasure hash digest and erasure time in the erasure proof, and summarizing the matching results to form a security verification result table.

[0139] The embodiment also provides a computer device suitable for 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 realize the cloud migration security verification method proposed in the above embodiment.

[0140] The computer device can be a terminal, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the computer device is used to communicate with external terminals in a wired or wireless manner. The wireless manner can be achieved through WIFI, operator network, NFC (near field communication) or other technologies. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the computer device. In addition, the input device can also be an external keyboard, touchpad or mouse, etc.

[0141] The embodiment also provides a storage medium on which a computer program is stored, the computer program being executed by a processor to implement the cloud migration security verification method proposed in the above embodiment; the storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0142] To sum up, the present application realizes real-time identification and processing of abnormal data in the migration process, reduces manual intervention and improves verification efficiency, makes the data verification process iteratively, ensures that each batch of data is verified completely before archiving, significantly improves the cloud migration security, enhances the credibility and consistency of the migration data, and provides dynamic protection for the formation of the security verification result.

[0143] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application but not limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application can be modified or replaced equivalently without departing from the spirit and scope of the technical solutions of the present application, and all of them should be covered in the scope of the claims of the present application.

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