A business system data protection method based on a cloud database

Abstract

This invention relates to the field of data processing technology, specifically to a data protection method for a business system based on a cloud database. The method includes the following steps: acquiring node transaction information of all transaction processing nodes in the business system of the cloud database; classifying the node transaction information of all transaction processing nodes into transaction risk levels to determine the risk level of each transaction processing node; determining a data transaction scheme for each transaction processing node based on its risk level and a preset node data processing model; and establishing a transaction channel for each transaction processing node using its data transaction scheme to complete the data transaction of the node transaction information. The purpose of this invention is to address the problem in cross-border financial payment systems where existing data protection methods suffer from delays in key rotation, leading to inconsistent data encryption and difficulty in ensuring data security.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a data protection method for business systems based on cloud databases. Background Technology

[0002] In a globalized business environment, financial payment systems, when processing cross-border transactions, need to ensure the efficiency and accuracy of fund transfers, and also face the dual challenges of data breaches and illegal tampering. The core business of cross-border financial payment systems is processing global fund transfers and transaction settlements. To meet the stringent data compliance requirements of different countries and regions and to continuously improve the overall security of the system, existing systems periodically rotate the symmetric keys used for encrypting transaction data. When the system needs to rotate keys, the key distribution protocol requires additional adaptation and verification processes when crossing the boundaries of different cloud vendors. Different cloud service providers have their own independent key management services, application programming interfaces, security models, and underlying encryption primitives. Therefore, coordination is required through complex cross-cloud key orchestration layers or cross-vendor key gateways to handle authentication, authorization, key format conversion, and the establishment of secure channels between different key management services.

[0003] However, during the key rotation process, the system struggles to update its local keys in a timely manner within the central key management system. This failure to update the keys for each node results in the continued use of the old symmetric key to encrypt newly generated cross-border transaction data for a period of time. Existing technologies struggle to perform secure and efficient key rotation, leading to delays and inconsistent encryption practices as different nodes use either the new or old keys for encryption, making it difficult to guarantee data security. Summary of the Invention

[0004] The purpose of this invention is to provide a data protection method for business systems based on cloud databases, which solves the problem in cross-border financial payment systems where existing data protection methods suffer from delays in key rotation, leading to inconsistent data encryption and difficulty in ensuring data security.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a data protection method for a business system based on a cloud database, comprising the following steps: Obtain node transaction information for all transaction processing nodes in the cloud database's business system; The transaction risk levels of all transaction processing nodes are classified, and the risk level of each transaction processing node is determined. Based on the risk level of each transaction processing node and the preset node data processing model, a data transaction scheme for each transaction processing node is determined; By utilizing the data transaction scheme of each transaction processing node, a transaction channel is established for each transaction processing node to complete the data transaction of node transaction information of each transaction processing node.

[0006] Preferably, the step of classifying the transaction risk levels of all transaction processing nodes and determining the risk level of each transaction processing node includes: Perform node status analysis on all transaction processing nodes to determine the status of each transaction processing node; Perform data volume analysis on each transaction processing node to determine the transaction data volume of each node; By using the transaction data volume of each transaction processing node, the state of each transaction processing node is adjusted to obtain the updated state of each transaction processing node. By utilizing the updated status of each transaction processing node, the transaction risk levels of all transaction processing nodes are classified, and the risk level of each transaction processing node is determined.

[0007] Preferably, the step of adjusting the state of each transaction processing node using the transaction data volume of each transaction processing node to obtain the updated state of each transaction processing node includes: Based on the transaction status of each transaction processing node, device identification is performed on each transaction processing node to obtain the device operating status of the transaction device of each transaction processing node; By utilizing the operating status of the transaction equipment, the transaction data volume of each transaction processing node is adjusted to obtain the adjusted transaction data volume; Using the adjusted transaction data volume, the status of each transaction processing node is adjusted to obtain the updated status of each transaction processing node.

[0008] Preferably, the step of identifying the device of each transaction processing node based on its transaction status to obtain the device operating status of the transaction device of each transaction processing node includes: The risk sensitivity of each transaction is determined based on the transaction status of each transaction processing node. Based on the risk sensitivity of each transaction, determine the device identification scheme for each transaction processing node; By using a device identification scheme for each transaction processing node, device identification is performed on each transaction processing node to obtain the device operating status of the transaction devices on each transaction processing node.

[0009] Preferably, the step of determining the data transaction scheme for each transaction processing node based on the risk level of each transaction processing node and the preset node data processing model includes: The risk level of each transaction processing node is matched with the preset node data processing model to obtain the initial transaction plan for each transaction processing node. Data transaction simulation is performed on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction; Using the simulation parameters for each transaction, the initial transaction scheme for each transaction processing node is adjusted to obtain the data transaction scheme for each transaction processing node.

[0010] Preferably, the step of matching the risk level of each transaction processing node with a preset node data processing model to obtain an initial transaction plan for each transaction processing node includes: Based on the risk level of each transaction processing node, the transaction key credential for each transaction processing node is determined; Using the transaction key credentials of each transaction processing node, the integrity of the transaction data of each transaction processing node is checked to obtain the data integrity coefficient of each transaction data. Using the data integrity coefficient of each transaction data, the risk level of each transaction processing node is matched with the preset node data processing model to obtain the initial transaction plan for each transaction processing node.

[0011] Preferably, the step of determining the transaction key credential for each transaction processing node based on the risk level of each transaction processing node includes: The risk level of each transaction processing node is verified to obtain the verified risk level for each node. Based on the risk level of each verified transaction, the transaction key credential for each transaction processing node is determined.

[0012] Preferably, the step of performing data transaction simulation on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction includes: Based on each transaction processing node, determine the processing load information for each transaction data; Parameter analysis is performed on the processing load information of each transaction data to determine the security strength parameters and load performance parameters; Using the security strength parameters and load performance parameters, data transaction simulations are performed on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction.

[0013] Preferably, the step of determining the processing load information of each transaction data based on each transaction processing node includes: For each transaction processing node, perform node device analysis to obtain device status information, runtime information, and initial parameter information for each node device; Using the device status information and running time information of each node device, the initial parameter information of each node device is corrected to obtain the corrected parameter information of each node device. Based on the correction parameter information of each node device, the processing load information of each transaction data is determined.

[0014] Preferably, the steps for obtaining node transaction information of all transaction processing nodes in the cloud database business system include: Obtain the original transaction information of all transaction processing nodes in the cloud database's business system; The original node transaction information is preprocessed to obtain preprocessed original node transaction information; The preprocessed original node transaction information is verified to obtain the node transaction information of all transaction processing nodes.

[0015] Compared with existing technologies, the cloud database-based business system data protection method of the present invention has the following advantages: This invention acquires node transaction information from all transaction processing nodes in a cloud database business system and classifies them into risk levels to determine the risk level of each node. Based on the risk level of each node and a preset node data processing model, a data transaction scheme is determined for each node. Finally, using the data transaction scheme of each node, a transaction channel is established for each node to complete the data transaction of its node transaction information. By classifying each transaction processing node into risk levels, dynamic adjustment and customization of data protection strategies are achieved, avoiding the contradiction between ensuring data security and real-time transaction performance in existing methods. Simultaneously, by determining the data transaction scheme based on the risk level and preset model and establishing a dedicated transaction channel, the challenges posed by the complexity of key management in a multi-cloud architecture can be effectively addressed. This ensures that even with key rotation delays, appropriate protection measures can be taken according to the node's risk level, avoiding data encryption inconsistencies and significantly improving the data protection capabilities and overall security of the cloud database business system. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention, the accompanying drawings used in the specific embodiments will be briefly described below. In all the drawings, the elements or parts are not necessarily drawn to scale.

[0017] Figure 1 This is a flowchart of a data protection method for a business system based on a cloud database, according to the present invention.

[0018] The implementation and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] The following drawings disclose several embodiments of the present invention. For clarity, many practical details will be described in the following description. However, it should be understood that these practical details are not intended to limit the invention. That is, in some embodiments of the invention, these practical details are not essential. Furthermore, for the sake of simplicity, some conventional structures and components will be shown in the drawings in a simple schematic manner.

[0020] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0021] Furthermore, in this invention, the use of terms such as "first" and "second" is for descriptive purposes only and does not specifically refer to any order or sequence, nor is it intended to limit the invention. They are merely used to distinguish components or operations described using the same technical terms, and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but only if they are feasible for those skilled in the art. If a combination of technical solutions is contradictory or impossible to implement, such a combination should be considered nonexistent and not within the scope of protection claimed by this invention.

[0022] To further understand the content, features, and effects of this invention, the following embodiments are provided, and detailed descriptions are given below in conjunction with the accompanying drawings: Please see Figure 1 This invention provides a data protection method for business systems based on cloud databases, comprising the following steps: S100. Obtain node transaction information from all transaction processing nodes in the cloud database's business system. The cloud database's business system refers to a database system deployed in a cloud environment to support commercial transaction activities. Its characteristics include elastically scalable data storage and processing capabilities, and it is typically managed by a third-party cloud service provider. A transaction processing node is a logical or physical unit within the cloud database's business system responsible for executing specific transaction operations, such as a microservice instance, database connection pool, or specific application server. Node transaction information refers to transaction-related data generated or processed by the transaction processing nodes, including but not limited to transaction amount, transaction time, information of both parties, and transaction status. This step can be achieved by the system administrator exporting transaction logs and related data from each transaction processing node and then aggregating this data to a central processing unit for analysis. Alternatively, each transaction processing node can periodically upload its own transaction information to a centralized data lake or data warehouse via Secure File Transfer Protocol (SFTP). Lightweight data acquisition agents can also be deployed on each transaction processing node. These agents monitor and capture transaction data streams in real time, then encrypt the captured data and send it to the data processing center. This achieves the acquisition of node transaction information.

[0023] S200. Classify the transaction risk levels of all transaction processing nodes to determine the risk level of each node. This risk level classification refers to assessing the potential risk level of the transactions processed by each node according to preset rules and algorithms, and categorizing them into different risk levels. This step can be performed manually by a security analyst based on historical transaction data and known risk patterns to assess the risk of each transaction processed by the node and manually assign a risk level. Alternatively, a preset rule engine can be used to match and score specific fields in the node's transaction information (such as transaction amount, transaction frequency, and transaction region), and then classify the nodes into high, medium, and low risk levels based on the total score. For example, if a transaction processing node processes a large number of high-value cross-border transactions in a short period, its risk level may be automatically increased.

[0024] S300. Based on the risk level of each transaction processing node and the preset node data processing model, determine the data transaction scheme for each transaction processing node. The preset node data processing model refers to a predefined set of rules to guide data processing strategies for nodes with different risk levels. For example, higher-risk transactions may require stricter encryption and verification measures. The data transaction scheme refers to a data processing strategy tailored to each transaction processing node, including data encryption methods, key management strategies, data integrity verification methods, and transaction channel establishment methods. This step can predefine a strategy library containing multiple data processing strategies. For example, standard encryption algorithms and periodic key rotation may be used for low-risk transactions, stronger encryption algorithms and more frequent key rotation may be used for medium-risk transactions, and multiple encryption, multi-party authorization, and real-time data integrity verification may be required for high-risk transactions. Once the risk level of a transaction processing node is determined, a preset data processing model matching that risk level is selected from the strategy library and used as the data transaction scheme for that node. For example, transaction processing nodes that are rated as high-risk are assigned a scheme that requires the use of AES-256 encryption, hourly key rotation, and digital signature of all transaction data before transmission.

[0025] S400. Utilize the data transaction scheme for each transaction processing node to establish a transaction channel for each node, thereby completing the data transaction of node transaction information for each node. A transaction channel refers to a secure and reliable data transmission path established between two or more transaction processing nodes to complete the data transaction of node transaction information. This step can configure the network connection between each transaction processing node and the target data storage or processing system according to the encryption algorithm and key management strategy specified in the data transaction scheme, ensuring that data is correctly encrypted and decrypted during transmission. Alternatively, existing secure communication protocols (such as TLS / SSL) can be utilized, and corresponding digital certificates and encryption keys can be dynamically generated or loaded according to the requirements of the data transaction scheme to establish a secure transaction channel. For example, if the data transaction scheme specifies the use of the TLS 1.3 protocol and a specific elliptic curve cryptography suite, an encrypted channel is established based on these parameters to ensure the confidentiality and integrity of node transaction information during transmission.

[0026] This invention provides foundational data for subsequent risk assessment by acquiring node transaction information from all transaction processing nodes. Subsequently, the node transaction information is categorized into risk levels, thereby identifying the potential risk differences faced by different transaction processing nodes. For example, nodes handling high-value, high-frequency cross-border transactions naturally have a higher risk level than nodes handling low-value, local transactions. Based on the risk level categorization, a customized data transaction scheme can be determined for each transaction processing node according to a pre-defined node data processing model. Depending on the risk level, each node is configured with data encryption, key management, and data integrity verification measures best suited to its security and performance requirements. For example, for high-risk nodes, stronger encryption algorithms, more frequent key rotations, and stricter access controls can be used; while for low-risk nodes, a relatively lenient strategy that still meets basic security requirements can be adopted to balance security and system performance. Finally, using the customized data transaction scheme, a dedicated transaction channel is established for each transaction processing node to ensure the security and consistency of node transaction information during transmission and processing. This not only improves data security but also optimizes the system's resilience and reliability in complex and changing environments. This ensures that all transaction data is properly protected even during complex operations such as key rotation, thus significantly improving the data protection capabilities of cloud database business systems.

[0027] In some embodiments of this application described above, the step of classifying the transaction risk levels of all transaction processing nodes and determining the risk level of each transaction processing node includes: Node status analysis is performed on all transaction processing nodes to determine the status of each node. Specifically, node status analysis involves real-time or periodic monitoring and evaluation of operational indicators such as hardware resource usage, network connectivity, system load, and error logs for each node to determine its current operational status, such as normal, warning, abnormal, or overloaded. The purpose is to obtain the basic operational health status of the transaction processing nodes.

[0028] Data volume analysis is performed on each transaction processing node to determine the transaction data volume of each node. This analysis involves statistically evaluating data processing-related metrics such as the number of transactions processed, the amount of data transmitted, and the amount of data stored by each node within a specific time period. The aim is to quantify the data processing load of each transaction processing node.

[0029] By utilizing the transaction data volume of each transaction processing node, the state of each node is adjusted to obtain an updated state. This step refers to dynamically correcting the previously determined node state based on the data processing load of each node. For example, if a transaction processing node has normal hardware resource utilization but its transaction data volume far exceeds the average level or reaches a preset threshold, its state may be adjusted from normal to high load risk or potential overload to reflect the potential risks brought about by the increased data volume. The purpose is to enable the node state to more comprehensively reflect its true risk status under the current data processing load.

[0030] By utilizing the update status of each transaction processing node, the transaction risk levels of all transaction processing nodes are classified, thus determining the risk level of each node. This step involves using the node update status after data volume adjustment as the core basis, combined with preset risk assessment rules or models, to evaluate the risk level of each transaction processing node. For example, nodes with a high-risk update status will be assigned a higher risk level, while nodes with a normal update status may be assigned a lower risk level. The purpose is to ensure that the risk level classification accurately and dynamically reflects the actual risk of the transaction processing nodes.

[0031] Specifically, the cloud database business system comprises multiple transaction processing nodes. One node, under routine monitoring, shows normal CPU utilization, memory usage, and network latency, thus its initial node status is determined to be normal. However, during peak periods, this node suddenly receives and processes significantly more data than usual, such as a surge in transactions per second or processing large amounts of high-value, sensitive data. At this point, data volume analysis reveals that its transaction data volume has reached a preset high-load threshold. Based on this high-load transaction data volume, the node's normal status is adjusted, resulting in an updated status of high-load risk. Subsequently, using this high-load risk update status, the node's transaction risk level is classified, raising it from low to medium or high risk. In this way, even if the node's basic operating indicators appear normal, its risk level can be adjusted promptly and accurately due to the significant increase in its data processing load. This prompts the system to implement stricter data protection measures, such as increased encryption strength, tighter access permissions, or transaction rate limiting, to address potential risks.

[0032] This invention addresses the static and one-sided nature of traditional risk assessment methods by introducing node status analysis and transaction data volume analysis, and dynamically adjusting node status based on transaction data volume. First, node status analysis provides basic health information of transaction processing nodes. Second, transaction data volume analysis supplements this with dynamic information on the node's data processing load. By correcting node status using transaction data volume, the updated status more comprehensively and accurately reflects the real-time risk status of transaction processing nodes. Therefore, transaction risk level classification based on the updated status can more effectively identify potential risks and avoid misjudgments or omissions caused by single-dimensional assessments.

[0033] In some embodiments of this application described above, the step of adjusting the state of each transaction processing node using the transaction data volume of each transaction processing node to obtain the updated state of each transaction processing node includes: Based on the transaction status of each transaction processing node, device identification is performed on each node to obtain the device operating status of the transaction devices within that node. The purpose of this step is to obtain detailed information about the hardware devices directly related to the node's transaction activities. Transaction status includes the activity level, type, and importance of the current transaction. Device identification refers to determining the transaction devices involved in the node's transaction processing, such as servers, storage devices, and network interface cards, through specific mechanisms or protocols, such as querying the node's system logs, hardware monitoring interfaces, or network topology information. This allows us to obtain the device operating status of these transaction devices, such as performance indicators and health status including CPU utilization, memory usage, disk I / O rate, network bandwidth usage, error logs, and temperature.

[0034] By utilizing the operational status of the trading equipment, the transaction data volume of each transaction processing node is adjusted to obtain the adjusted transaction data volume. The purpose of this step is to combine the original transaction data volume with the actual carrying capacity and health status of the equipment, forming an adjusted transaction data volume that is more indicative of risk. For example, if the operational status of the trading equipment indicates excessively high resource utilization and hardware failures or performance bottlenecks, even if the original transaction data volume is not high, it may be considered high-risk, thus requiring an upward adjustment of the transaction data volume; conversely, if the equipment is operating well, the original transaction data volume may be maintained or slightly adjusted. In practical applications, this adjustment can be achieved through preset weighting factors, function models, or machine learning algorithms, quantifying various indicators of the equipment's operational status and comprehensively calculating them with the transaction data volume.

[0035] Using the adjusted transaction data volume, the status of each transaction processing node is adjusted to obtain an updated status for each node. The purpose of this step is to obtain a more accurate and representative updated status. The adjusted transaction data volume comprehensively considers both the data volume and the hardware environment factors processing this data, thus more realistically reflecting the node's current load and potential risks. Therefore, based on the adjusted transaction data volume, the node status can be more accurately assessed and updated, for example, changing its status from normal to warning or abnormal, providing a more reliable basis for subsequent risk level classification.

[0036] Specifically, in a cloud database business system, a transaction processing node processes 1000 transactions within a certain time period, generating 500MB of transaction data. If the node status is adjusted solely based on the transaction data volume, this data volume might be considered within the normal range, and the node's status would be updated to normal. However, according to this invention, the node's primary transaction device is first identified based on its transaction status, revealing it to be a server. Subsequently, the server's operational status is obtained; for example, it is detected that CPU utilization has reached 95%, memory usage has reached 90%, and there is significant disk I / O waiting. Using this operational status information, it is determined that the server is under high load or even overload. Therefore, even if the original 500MB of transaction data is not high in absolute terms, its operational status is used to adjust the status. For example, using a preset risk model, this 500MB of transaction data is equivalent to 1GB of adjusted transaction data in a risk assessment. Finally, using this adjusted transaction data volume, the node's status is adjusted to warning or high-risk, rather than normal. This enables timely detection and response to potential risks caused by underlying hardware performance bottlenecks or failures, allowing for the implementation of corresponding protective measures, such as limiting the transaction volume of the node, performing load balancing, or triggering maintenance alarms, effectively preventing data security issues caused by equipment vulnerabilities.

[0037] This invention addresses the limitations of adjusting node status solely based on transaction data volume by introducing device identification and acquisition of the operational status of transaction processing nodes. Specifically, when a transaction processing node processes a certain amount of transaction data, its risk depends not only on the data volume but also on the health and performance of the underlying hardware processing the data. Acquiring device operational status allows for real-time monitoring of device load, resource consumption, and potential failures. For example, if a node's transaction data volume is within the normal range, but its transaction device's CPU utilization remains excessively high or disk I / O latency increases significantly, it indicates that the node may be overloaded or in a sub-optimal state. In this case, even if the original transaction data volume is not high, it should be considered a higher risk. By utilizing device operational status information, the original transaction data volume can be dynamically adjusted. For instance, when device performance degrades, the actual amount of transaction data processed can be increased during risk assessment, resulting in an adjusted transaction data volume that more accurately reflects the node's true risk. This makes the adjustment of each transaction processing node's status more precise, leading to more valuable updated status information.

[0038] In some embodiments of this application described above, the step of identifying each transaction processing node based on its transaction status to obtain the device operating status of the transaction device of each transaction processing node includes: The risk sensitivity of each transaction is determined based on its transaction status at each transaction processing node. Transaction status can include transaction type, transaction amount, transaction frequency, and information about the initiator and recipient. Risk sensitivity refers to the likelihood and extent of data or asset damage in a specific transaction when faced with potential security threats. For example, high-value transactions, transactions involving sensitive personal information, or transactions from unknown sources typically have higher risk sensitivity. Determining risk sensitivity can employ a pre-defined risk assessment model, which can be dynamically adjusted based on historical transaction data, industry risk standards, and real-time threat intelligence.

[0039] Based on the risk sensitivity of each transaction, a device identification scheme is determined for each transaction processing node. This device identification scheme is a customized device verification and identity confirmation strategy for transactions with different risk sensitivities. For example, for transactions with low risk sensitivity, a simpler device identification method, such as identification based on IP address or device MAC address, can be used; while for transactions with high risk sensitivity, more stringent and complex device identification schemes such as multi-factor authentication, biometrics, device fingerprint analysis, or behavioral pattern analysis may be required. This scheme aims to ensure that device identification matches the actual risk level of the transaction, thereby providing appropriate security protection.

[0040] A device identification scheme is used for each transaction processing node to identify the device's operational status, thus obtaining the operational status of the transaction devices on each node. The device identification scheme guides the specific identification process, ensuring accuracy and security. The operational status of the transaction devices can include information such as the device's health status, security patch update status, presence of abnormal processes, network connection status, and whether the information has been tampered with.

[0041] Specifically, cloud database business systems exhibit two typical transaction scenarios: low-risk transactions where users query product information and high-risk transactions where users make large payments. For low-risk transactions, the risk sensitivity is determined to be low based on the transaction type (query) and transaction amount (zero). Based on this low risk sensitivity, a simple device identification scheme based on IP address and device type (e.g., browser user agent) is adopted. This allows for quick identification of the user's device and acquisition of its basic operational status, such as whether it is a known device and whether the network connection is normal. For high-risk transactions, the risk sensitivity is determined to be high based on the transaction type (payment) and transaction amount (large amount). Based on this high risk sensitivity, a more stringent device identification scheme is generated, such as requiring users to perform multi-factor authentication including SMS verification codes and fingerprint recognition, and conducting more in-depth fingerprint analysis (e.g., operating system version, installed software list, and device sensor data) and behavioral pattern analysis of the device. Through rigorous identification methods, the operational status of trading devices can be assessed more comprehensively and deeply, such as whether there are abnormal login locations, whether the device is jailbroken / rooted, and whether malware is present. Differentiated device identification strategies allow for flexible adjustments to security protection levels based on the actual risks of the transaction, ensuring high-risk transactions are adequately protected without impacting the user experience of low-risk transactions.

[0042] This invention introduces risk sensitivity to transactions, enabling the device identification process to move beyond a single, fixed pattern and dynamically adjust based on the actual risk characteristics of the transaction. By determining the risk sensitivity based on the transaction status, a device identification scheme tailored to that sensitivity can be developed. This customized identification scheme ensures that device identification avoids unnecessary resource waste and user experience impact on low-risk transactions while applying sufficient security verification to high-risk transactions, thus obtaining more accurate and reliable information about the device's operational status. This significantly improves the effectiveness of device identification, providing a more solid and refined foundation for subsequent adjustments to transaction data.

[0043] In some embodiments of this application described above, the step of determining the data transaction scheme for each transaction processing node based on the risk level of each transaction processing node and the preset node data processing model includes: The risk level of each transaction processing node is matched with a pre-defined node data processing model to obtain an initial transaction plan for each node. This step involves comparing and associating the risk level of each transaction processing node with the pre-set node data processing model to initially determine the appropriate transaction plan for that node. The pre-defined node data processing model may include various data processing strategies for different risk levels, such as data encryption strength, access control, and data storage location. Through matching, a preliminary transaction plan that conforms to the risk characteristics of each transaction processing node can be generated.

[0044] For each transaction processing node, an initial transaction scheme is simulated to obtain simulation parameters for each transaction. This step involves simulating the initial transaction scheme after it has been determined to verify its effectiveness and security. During the simulation, real-world data transaction scenarios can be simulated, including data transmission, storage, and processing, and relevant performance and security metrics, such as data transmission latency, resource consumption, and potential security vulnerabilities, are collected. These metrics constitute the transaction simulation parameters.

[0045] Using the simulation parameters for each transaction, the initial transaction scheme for each transaction processing node is adjusted to obtain the data transaction scheme for each node. This step involves optimizing and correcting the initial transaction scheme based on the simulation parameters obtained from the data transaction simulation. For example, if the simulation results show that the initial scheme performs poorly under a specific load or has security vulnerabilities, the encryption algorithm, data sharding strategy, or access control rules can be adjusted to ensure that the final data transaction scheme meets both risk protection requirements and system performance and efficiency. Ultimately, the adjusted and optimized scheme constitutes the data transaction scheme for each transaction processing node.

[0046] This invention generates an initial transaction plan by matching risk levels with a preset model, ensuring the plan's initial applicability. Subsequently, data transaction simulations are used to verify the initial plan in real-world scenarios, identifying potential performance bottlenecks or security risks. Finally, the plan is adjusted based on the simulation results, enabling the final data transaction plan to more accurately adapt to the specific risk level and operating environment of each transaction processing node, thereby improving the robustness and effectiveness of the data transaction plan. This iterative optimization process ensures that the determined data transaction plan not only effectively protects business system data but also considers system operating efficiency and resource utilization.

[0047] In some embodiments of this application described above, the step of matching the risk level of each transaction processing node with a preset node data processing model to obtain an initial transaction plan for each transaction processing node includes: Based on the risk level of each transaction processing node, a transaction key credential is determined for each node. This step involves assigning or generating a unique encrypted credential for the node based on its risk assessment results. The transaction key credential is a digital identity or security token used to subsequently verify the integrity of the node's transaction data. For example, nodes with higher risk levels may be assigned more complex encryption keys or multi-factor authentication credentials to enhance their security.

[0048] Using the transaction key credentials of each transaction processing node, an integrity check is performed on the transaction data of each node to obtain a data integrity coefficient for each transaction. This step involves verifying whether the transaction data has been tampered with or corrupted during transmission or storage using encryption algorithms, hash functions, or other security mechanisms. The transaction key credentials serve as a key element in verifying the authenticity and integrity of the data in this process. For example, the transaction key credentials can be used to digitally sign the transaction data, and the same credentials can be used for signature verification at the receiving end to ensure that the data has not been tampered with. The data integrity coefficient is a quantitative representation of the transaction data integrity check result. This coefficient reflects the degree to which the transaction data passes the integrity check; for example, a value between 0 and 1, where 1 indicates that the data is completely intact and has not been tampered with, while a value below 1 indicates that there are varying degrees of integrity problems. Its purpose is to provide a reliable integrity indicator for subsequent transaction scheme matching.

[0049] Using the data integrity coefficient of each transaction data, the risk level of each transaction processing node is matched with the preset node data processing model to obtain the initial transaction plan for each transaction processing node.

[0050] Specifically, when a node in the cloud database business system is assessed as having a medium risk level, a specific transaction key credential, such as a digital certificate based on an asymmetric encryption algorithm, is generated for that node according to this medium risk level. When the node is ready to conduct a data transaction, its transaction data is first signed by this digital certificate. Before matching the node's risk level with a preset node data processing model, the integrity of the node's transaction data is verified using this digital certificate. If the verification passes, a high data integrity coefficient (e.g., 0.98) is obtained, indicating good data integrity. Subsequently, the node's medium risk level and the data integrity coefficient of 0.98 are input into the preset node data processing model for transaction scheme matching, thereby obtaining an initial transaction scheme that considers both node risk and data integrity. If the integrity verification fails, for example, if the data integrity coefficient is below a certain threshold (e.g., 0.7), the data transaction will be rejected, or a more stringent review mechanism will be triggered, effectively preventing insecure or incomplete data from entering the transaction process.

[0051] This invention determines the corresponding transaction key credential based on the risk level of each transaction processing node, ensuring that security measures match the node's risk level. Secondly, the transaction key credential is used to perform integrity checks on the transaction data, ensuring the data's authenticity and lack of tampering. Therefore, the reliability of the transaction data can be quantitatively assessed using the obtained data integrity coefficient. Finally, when matching the risk level with the preset node data processing model, the data integrity coefficient is used as an important reference, ensuring that the resulting initial transaction scheme not only considers the node's risk level but also takes into account the integrity of the transaction data itself, avoiding scheme deviations caused by incomplete or tampered data.

[0052] In some embodiments of this application described above, the step of determining the transaction key credential of each transaction processing node based on the risk level of each transaction processing node includes: The risk level of each transaction processing node is verified to obtain a verified risk level. This step involves secondary confirmation or multi-dimensional assessment of the initially determined risk level to ensure its accuracy and reliability. For example, verification can be performed using methods such as cross-validation, historical data comparison, expert system evaluation, or anomaly detection based on machine learning models. The purpose is to eliminate risk level deviations caused by a single assessment dimension or instantaneous state fluctuations, thereby obtaining more realistic and stable risk assessment results. Each verified risk level represents a risk assessment result with higher confidence after the verification process. This verified risk level will serve as a reliable basis for subsequently determining the transaction key credential.

[0053] Based on the verified risk level, the transaction key credential for each transaction processing node is determined. This step involves selecting or generating a key credential with appropriate strength and complexity based on the verified risk level. For example, for nodes verified as high-risk, a longer key length, a more complex encryption algorithm, or a multi-factor authentication mechanism can be assigned; for nodes verified as low-risk, a relatively simple key credential that still meets security requirements can be used.

[0054] Specifically, when a transaction processing node in a cloud database business system is initially assessed as having medium risk, a risk level verification is performed to ensure the accuracy of this assessment. This verification process may include: first, checking the node's recent security logs to analyze for any abnormal logins, changes in data access patterns, or potential malicious behavior; second, comparing the node's current configuration with a preset security baseline to confirm any configuration drift or vulnerabilities; and finally, evaluating the node's performance in similar risk scenarios based on historical transaction data. If the verification results indicate that the node actually has vulnerabilities or abnormal behavior that were not initially detected, its risk level may be adjusted and verified as high risk. In this case, based on the verified high-risk level, a stronger transaction key credential will be generated for the node, such as using a 256-bit encryption key and a two-factor authentication mechanism. Conversely, if the verification results confirm that the node is indeed at medium risk and has no other anomalies, a transaction key credential meeting medium security requirements will be generated for it based on the verified medium-risk level, such as using a 128-bit encryption key and a single-factor authentication mechanism. This approach ensures that the strength of the transaction key certificate is precisely matched to the actual risk status of the node, thereby improving the overall security of data transactions.

[0055] This invention introduces a risk level verification step for each transaction processing node, ensuring that the risk level used to determine the transaction key credential is verified and reliable. This allows subsequently generated transaction key credentials to more accurately match the actual risk status of the nodes. Therefore, it avoids problems such as insufficient security protection or excessive resource consumption caused by inaccurate risk level assessment, thereby improving the robustness and adaptability of the entire data protection mechanism.

[0056] In some embodiments of this application described above, the step of performing data transaction simulation on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction includes: Based on each transaction processing node, the processing load information for each transaction data is determined. Specifically, the processing load information for each transaction data refers to the comprehensive information such as computing resources, storage resources, network bandwidth, and time consumption required to process the transaction data on a specific transaction processing node. This reflects the system resource consumption of the transaction data during processing. Determining the processing load information aims to provide a more realistic and comprehensive input for subsequent data transaction simulations.

[0057] Parameter analysis is performed on the processing load information of each transaction data to determine security strength parameters and load performance parameters. Specifically, this parameter analysis of the processing load information for each transaction data to determine security strength parameters and load performance parameters allows for in-depth analysis of the collected load information, extracting key indicators directly related to the security and performance of the data transaction scheme. Security strength parameters measure the data transaction scheme's ability to resist potential attacks and protect data privacy and integrity, such as the strength of encryption algorithms and the robustness of authentication mechanisms. Load performance parameters evaluate the efficiency, response speed, and resource utilization of the data transaction scheme when processing large amounts of transaction data, such as throughput, latency, and concurrent processing capabilities. The determination of these parameters provides a quantitative evaluation standard for data transaction simulation.

[0058] Using the aforementioned security strength parameters and load performance parameters, data transaction simulations are performed on the initial transaction scheme of each transaction processing node to obtain simulation parameters for each transaction. This step refers to using quantified parameters as important inputs and evaluation indicators in the simulation process. The simulation process runs the initial transaction scheme in a virtual environment based on these parameters and observes its behavior under different security and load conditions, thereby generating a series of transaction simulation parameters reflecting the scheme's performance and security. These parameters may include various performance indicators, the probability of security events, and resource consumption recorded during the simulation, which will be used for subsequent adjustments to the initial transaction scheme.

[0059] Specifically, when a transaction processing node needs to process a large payment transaction, it first determines the processing load information for that transaction, including expected CPU utilization, memory consumption, database read / write operations, and network traffic. Next, it performs parameter analysis on this load information. For example, it determines the required encryption strength (security strength parameter) based on the transaction amount and sensitivity, and determines system throughput and latency metrics (load performance parameters) based on expected transaction concurrency and response time requirements. Then, using the security strength and load performance parameters, it runs an initial transaction scheme in a simulation environment to simulate the processing of the large payment transaction. During this process, it records a series of transaction simulation parameters, such as encryption / decryption time, database transaction processing time, network transmission latency, peak resource utilization, and the probability of potential security events. These parameters are used to evaluate whether the initial transaction scheme can effectively and securely process the large payment transaction, and accordingly, it optimizes and adjusts the initial transaction scheme, such as adjusting the encryption algorithm, optimizing the database query strategy, or increasing resource reservation, to ensure that the expected security and performance requirements are met in actual deployment.

[0060] This invention first determines the processing load information for each transaction data based on each transaction processing node, enabling data transaction simulation to be conducted under conditions closer to the actual operating environment. By performing parameter analysis on the processing load information and extracting security strength and load performance parameters, the simulation process can comprehensively evaluate the security and performance of the initial transaction scheme. By incorporating key parameters into the data transaction simulation, the operational effectiveness of the initial transaction scheme in a real business system can be predicted more accurately, thus providing a more reliable basis for subsequent adjustments to the data transaction scheme and effectively avoiding data protection vulnerabilities or performance bottlenecks caused by insufficient simulation.

[0061] In some embodiments of this application described above, the step of determining the processing load information of each transaction data based on each transaction processing node includes: Each transaction processing node undergoes node device analysis to obtain its device status information, runtime information, and initial parameter information. This step involves a thorough inspection and evaluation of the physical or virtual devices constituting the transaction processing node to obtain its current operating status and configuration. The device status information for each node device can include real-time operating metrics such as device health status, CPU utilization, memory usage, network bandwidth consumption, and disk I / O. Runtime information refers to the continuous operating time of the device since startup, reflecting its stability or potential wear and tear. Initial parameter information refers to the performance parameters preset during the device's design or deployment, such as maximum processing capacity and default latency.

[0062] By utilizing the device status and runtime information of each node device, the initial parameter information of each node device is corrected to obtain corrected parameter information for each node device. This step refers to dynamically adjusting and optimizing the initial parameter information based on the real-time acquired device status and runtime information. For example, if the device status indicates excessively high CPU utilization or excessively long runtime, its initial processing capacity parameters may need to be adjusted downwards to reflect its current actual carrying capacity. Thus, the corrected parameter information for each node device is obtained. This corrected parameter information is the dynamically adjusted device performance parameter, which more accurately reflects the actual processing capacity of the device under current operating conditions.

[0063] Based on the corrected parameter information of each node device, the processing load information for each transaction data is determined. Specifically, based on the corrected parameter information of each node device, the amount of transaction data and processing complexity that each transaction processing node can handle are comprehensively evaluated, thereby determining the processing load information for each transaction data.

[0064] Specifically, when determining its transaction data processing load, a transaction processing node first analyzes its server equipment. This involves real-time data collection of each server's CPU utilization, memory usage, network bandwidth throughput, and runtime since the last restart. For example, the first server might have 80% CPU utilization, 90% memory usage, and 30 days of runtime; the second server might have 30% CPU utilization, 40% memory usage, and 5 days of runtime. Initial parameters might indicate that the first and second servers have the same maximum processing capacity. Using this equipment status and runtime information, the initial parameters for each server are adjusted. For instance, because the first server has higher CPU and memory utilization and a longer runtime, its initial processing capacity parameters are adjusted downwards to reflect that its current available processing capacity is below its peak. Conversely, the second server, with a lower load and shorter runtime, might have its initial processing capacity parameters remain unchanged or slightly adjusted upwards. Finally, based on the adjusted parameters, the total transaction data volume and processing complexity that the entire transaction processing node can handle are comprehensively assessed, thus determining the node's processing load at the current moment. For example, the effective processing capacity of the first server after correction is assessed as 60% of the initial value, and that of the second server as 95% of the initial value. Based on this, the total processing load capacity of the transaction processing node can be calculated more accurately and used for subsequent data transaction simulations.

[0065] This invention introduces node device analysis for each transaction processing node to obtain device status information, runtime information, and initial parameter information. Real-time dynamic information is then used to correct the initial parameters, resulting in more accurate corrected parameter information. This dynamic correction mechanism ensures that the processing load information for each transaction data point more accurately reflects the actual processing capacity and resource availability of the transaction processing node at the current moment. This dynamic adjustment based on real-time device status avoids the inaccurate load information caused by static evaluation, thus providing a more reliable foundation for subsequent data transaction simulation.

[0066] In some of the embodiments described above in this application, the step of obtaining node transaction information of all transaction processing nodes in the business system of the cloud database includes: This involves acquiring the raw transaction information of all transaction processing nodes within the cloud database's business system. Specifically, acquiring this raw transaction information means directly collecting the unprocessed and most original transaction data from the cloud database's business system. This raw information may include transaction time, transaction amount, identities of the transacting parties, and transaction type, with the aim of comprehensively capturing the initial state of the transaction.

[0067] The original node transaction information is preprocessed to obtain preprocessed original node transaction information. This step involves cleaning, formatting, deduplication, and filling in missing values ​​for the acquired raw data. For example, invalid characters can be removed, date formats can be standardized, duplicate records can be merged, or abnormal data can be marked. The purpose is to improve the quality and consistency of the data, laying the foundation for subsequent data verification and risk assessment.

[0068] The preprocessed node transaction information is then validated to obtain the node transaction information for all transaction processing nodes. This step involves checking the integrity, accuracy, and legality of the preprocessed data. For example, hash verification, digital signature verification, and business rule checks can be used to ensure the authenticity and reliability of the data. The purpose is to prevent data tampering, errors, or illegal transaction information from entering subsequent processing flows, thereby ensuring the effectiveness of data protection throughout the entire business system.

[0069] This invention first acquires raw node transaction information, ensuring the comprehensiveness of the data source. Subsequently, preprocessing this raw information effectively removes noise and redundancy, standardizes the data format, and thus improves data usability and processing efficiency. Furthermore, rigorous data verification of the preprocessed data allows for the timely detection and correction of data errors, tampering, or inconsistencies, ensuring the accuracy, completeness, and reliability of the final obtained node transaction information. This phased and refined data acquisition and processing mechanism enables subsequent steps such as transaction risk level classification, data transaction scheme determination, and transaction channel establishment to be based on high-quality and highly reliable data, thereby enhancing the effectiveness and robustness of the entire business system's data protection method.

[0070] 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 the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the present invention specification.

Claims

1. A cloud database-based business system data protection method, characterized by, Includes the following steps: Obtain node transaction information for all transaction processing nodes in the cloud database's business system; The transaction risk levels of all transaction processing nodes are classified, and the risk level of each transaction processing node is determined. Based on the risk level of each transaction processing node and the preset node data processing model, a data transaction scheme for each transaction processing node is determined; By utilizing the data transaction scheme of each transaction processing node, a transaction channel is established for each transaction processing node to complete the data transaction of node transaction information of each transaction processing node.

2. The data protection method for a business system based on a cloud database according to claim 1, wherein, The steps for classifying the transaction risk levels of all transaction processing nodes and determining the risk level of each transaction processing node include: Perform node status analysis on all transaction processing nodes to determine the status of each transaction processing node; Perform data volume analysis on each transaction processing node to determine the transaction data volume of each node; By using the transaction data volume of each transaction processing node, the state of each transaction processing node is adjusted to obtain the updated state of each transaction processing node. By utilizing the updated status of each transaction processing node, the transaction risk levels of all transaction processing nodes are classified, and the risk level of each transaction processing node is determined.

3. The data protection method for a cloud database-based business system according to claim 2, wherein, The steps for adjusting the state of each transaction processing node using the transaction data volume of each node to obtain the updated state of each transaction processing node include: Based on the transaction status of each transaction processing node, device identification is performed on each transaction processing node to obtain the device operating status of the transaction device of each transaction processing node; By utilizing the operating status of the transaction equipment, the transaction data volume of each transaction processing node is adjusted to obtain the adjusted transaction data volume; Using the adjusted transaction data volume, the status of each transaction processing node is adjusted to obtain the updated status of each transaction processing node.

4. The data protection method for a business system based on a cloud database according to claim 3, wherein, The steps for identifying the device operation status of the transaction device of each transaction processing node based on the transaction status of each transaction processing node include: The risk sensitivity of each transaction is determined based on the transaction status of each transaction processing node. Based on the risk sensitivity of each transaction, determine the device identification scheme for each transaction processing node; By using a device identification scheme for each transaction processing node, device identification is performed on each transaction processing node to obtain the device operating status of the transaction devices on each transaction processing node.

5. The data protection method for a business system based on a cloud database according to claim 1, wherein, The steps for determining the data transaction scheme for each transaction processing node based on its risk level and preset node data processing model include: The risk level of each transaction processing node is matched with the preset node data processing model to obtain the initial transaction plan for each transaction processing node. Data transaction simulation is performed on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction; Using the simulation parameters for each transaction, the initial transaction scheme for each transaction processing node is adjusted to obtain the data transaction scheme for each transaction processing node.

6. The data protection method for a cloud database-based business system according to claim 5, wherein, The steps to match the risk level of each transaction processing node with the preset node data processing model to obtain the initial transaction plan for each transaction processing node include: Based on the risk level of each transaction processing node, the transaction key credential for each transaction processing node is determined; Using the transaction key credentials of each transaction processing node, the integrity of the transaction data of each transaction processing node is checked to obtain the data integrity coefficient of each transaction data. Using the data integrity coefficient of each transaction data, the risk level of each transaction processing node is matched with the preset node data processing model to obtain the initial transaction plan for each transaction processing node.

7. The data protection method for a cloud database-based business system according to claim 6, wherein, The steps for determining the transaction key credential for each transaction processing node based on its risk level include: The risk level of each transaction processing node is verified to obtain the verified risk level for each node. Based on the risk level of each verified transaction, the transaction key credential for each transaction processing node is determined.

8. The data protection method for a cloud database-based business system according to claim 5, wherein, The steps for performing data transaction simulation on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction include: Based on each transaction processing node, determine the processing load information for each transaction data; Parameter analysis is performed on the processing load information of each transaction data to determine the security strength parameters and load performance parameters; Using the security strength parameters and load performance parameters, data transaction simulations are performed on the initial transaction scheme of each transaction processing node to obtain the simulation parameters for each transaction.

9. A data protection method for a business system based on a cloud database according to claim 8, characterized in that, The steps for determining the processing load information for each transaction data based on each transaction processing node include: Node device analysis is performed on each transaction processing node to obtain device status information, runtime information, and initial parameter information for each node device; Using the device status information and running time information of each node device, the initial parameter information of each node device is corrected to obtain the corrected parameter information of each node device. Based on the correction parameter information of each node device, the processing load information of each transaction data is determined.

10. A data protection method for a business system based on a cloud database according to claim 1, characterized in that, The steps to obtain node transaction information for all transaction processing nodes in a cloud database business system include: Obtain the original transaction information of all transaction processing nodes in the cloud database's business system; The original node transaction information is preprocessed to obtain preprocessed original node transaction information; The preprocessed original node transaction information is verified to obtain the node transaction information of all transaction processing nodes.

Images