Key management-based service data processing method and device, equipment and medium

Abstract

The application relates to a service data processing method and device based on key management, equipment and a storage medium. The method comprises the following steps: generating a unified service key, and establishing a structured key storage space; respectively encrypting the service key by using a master key preconfigured by each cloud platform, generating platform key ciphertext corresponding to the platform, and storing the platform key ciphertext together with a platform type identifier in the storage space; meanwhile, the service key is used to encrypt service data, and the obtained ciphertext is also stored in the key storage space. When a cloud platform switching instruction is received, the corresponding platform key ciphertext is taken out from the storage space according to the identifier of the target platform, the service key is obtained by decrypting the platform key ciphertext by using the corresponding master key, and the service key is used to decrypt existing service data or encrypt new data.

Description

Technical Field

[0001] This application relates to the field of key management technology, and in particular to a business data processing method, apparatus, device and storage medium based on key management. Background Technology

[0002] In multi-cloud or hybrid cloud architectures, enterprises often need to migrate or synchronize business data across different cloud platforms. Due to differences in key management mechanisms, encryption interfaces, and security policies offered by various cloud service providers, users typically need to maintain a separate set of keys and encryption logic for each platform, resulting in high key management complexity and strong system coupling. Furthermore, if business data is directly encrypted using the platform's native key, switching cloud service providers will render the original ciphertext undecryptable due to key unavailability, posing a data lock risk. Existing technologies, while some solutions achieve cross-platform compatibility through a unified key proxy layer, do not effectively address issues such as key identifier confusion, inconsistent ciphertext structures, and missing terminal feedback paths, making it difficult to achieve seamless and auditable data decryption and delivery while ensuring security. Summary of the Invention

[0003] In view of the above, this application provides a business data processing method, apparatus, device and storage medium based on key management, the purpose of which is to solve the above-mentioned technical problems.

[0004] Firstly, this application provides a business data processing method based on key management, the method comprising: Generate a business key and determine the key storage space; The business key is encrypted using the master keys of multiple cloud platforms that are predetermined, so as to obtain the platform key ciphertext corresponding to each cloud platform. The platform key ciphertext and the platform type identifier of the corresponding cloud platform are stored in the key storage space. The business data is encrypted using the business key to obtain ciphertext of the business data, and the ciphertext of the business data is stored in the key storage space; In response to the cloud platform switching command, based on the platform type identifier of the target cloud platform corresponding to the switching command, the platform key ciphertext corresponding to the target cloud platform is obtained from the key storage space, and the platform key ciphertext corresponding to the target cloud platform is decrypted to obtain the decrypted target business key; The target business key is used to decrypt the ciphertext of business data in the key storage space, or to encrypt new business data.

[0005] Secondly, this application provides a business data processing apparatus based on key management, the business data processing apparatus based on key management comprising: Generation module: Used to generate business keys and determine the key storage space; The first encryption module is used to encrypt the business key using the master keys of multiple cloud platforms in advance, to obtain the platform key ciphertext corresponding to each cloud platform, and to store each platform key ciphertext and the platform type identifier of the corresponding cloud platform in the key storage space. The second encryption module is used to encrypt business data using the business key to obtain ciphertext of the business data, and to store the ciphertext of the business data in the key storage space. Switching module: It is used to respond to the cloud platform switching command, and according to the platform type identifier of the target cloud platform corresponding to the switching command, it retrieves the platform key ciphertext corresponding to the target cloud platform from the key storage space, decrypts the platform key ciphertext corresponding to the target cloud platform, and obtains the decrypted target business key. Decryption module: used to decrypt the ciphertext of business data in the key storage space using the target business key, or to encrypt new business data.

[0006] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the key management-based business data processing method described in any embodiment of the first aspect.

[0007] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the key management-based business data processing method as described in any embodiment of the first aspect.

[0008] The technical solutions provided in this application have the following advantages compared with the prior art: By generating business keys independent of the cloud platform and constructing a structured local key storage space, unified management and secure decryption of encrypted data across multiple platforms are achieved. A key identifier consistency verification mechanism is introduced during the decryption process to effectively prevent data corruption or security vulnerabilities caused by key mismatch. At the same time, the decrypted business data can be securely fed back to the designated terminal according to a preset strategy, and multiple communication protocols and secure transmission channels are supported. With complete audit log recording, the availability and operational reliability of data in cross-cloud environments are improved, the complexity of key management and platform binding risks are reduced, and thus, while ensuring end-to-end security, efficient, traceable and highly compatible multi-cloud data decryption and delivery capabilities are achieved. Attached Figure Description

[0009] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a preferred embodiment of the business data processing method based on key management in this application; Figure 2 This is a schematic diagram of a preferred embodiment of the business data processing apparatus based on key management according to this application; Figure 3 This is a schematic diagram of a preferred embodiment of the electronic device of this application; The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0013] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0014] Reference Figure 1 The diagram shown is a flowchart illustrating an embodiment of the key-management-based business data processing method of this application. The method is executed by an electronic device, which can be implemented by a software system and / or a hardware system. The key-management-based business data processing method includes: Step S10: Generate a business key and determine the key storage space; Step S20: Encrypt the business key using the master keys of multiple cloud platforms in advance to obtain the platform key ciphertext corresponding to each cloud platform, and store each platform key ciphertext and the platform type identifier of the corresponding cloud platform into the key storage space. Step S30: Encrypt the business data using the business key to obtain ciphertext of the business data, and store the ciphertext of the business data in the key storage space; Step S40: In response to the cloud platform switching instruction, according to the platform type identifier of the target cloud platform corresponding to the switching instruction, retrieve the platform key ciphertext corresponding to the target cloud platform from the key storage space, decrypt the platform key ciphertext corresponding to the target cloud platform, and obtain the decrypted target business key; Step S50: Use the target business key to decrypt the ciphertext of business data in the key storage space, or encrypt new business data.

[0015] In multi-cloud or hybrid cloud deployment architectures, business systems typically need to migrate or run in parallel across different cloud platforms. However, these platforms have different key management mechanisms. Directly storing raw business data in plaintext or encrypting it using a single platform key can lead to difficulties in cross-platform access and even data locking. To address this issue, during the initialization phase, the system first generates a high-strength business key using a cryptographically secure random number generator (such as a CSPRNG compliant with NIST SP 800-90A). This key serves as the core credential for all subsequent encryption and decryption of business data. A logically isolated, access-controlled key storage space is then designated. This space can be a dedicated key table in a local database, an encrypted metadata bucket in object storage, or an abstract storage interface provided by a unified key management middleware.

[0016] The key storage space can persistently store key-related data and provide a structured, indexable storage location for platform key ciphertext, business data ciphertext, and their associated identifiers, thereby avoiding management chaos caused by keys and data being scattered across different systems. For example, when a financial-grade application starts, the system generates a 256-bit AES business key and writes all its associated encryption artifacts into a dedicated storage area named "secure_key_vault," which can only be accessed by service modules that have undergone authentication and authorization. By decoupling the business key from the physical cloud environment and centrally managing it through a dedicated key storage space, the entire encryption system achieves platform independence.

[0017] Since different cloud service providers can offer master key services protected by hardware security modules, and these master keys cannot be exported, the same original key cannot be directly shared across platforms. To ensure that business keys can be legally restored on any target cloud platform, the system needs to proactively connect to each planned supported cloud platform during the initial deployment or configuration phase to obtain a reference handle to its master key (e.g., KMS key ARN or Key ID). Then, it needs to call the encryption interface of each platform, using its respective master key to perform encryption operations on the same business key, thereby generating multiple distinct platform key ciphertexts. Each platform key ciphertext is essentially a packaged form of the business key within the trust domain of a specific cloud platform; only the corresponding platform's master key can decrypt it. Finally, each platform key ciphertext, along with the standardized platform type identifier of its respective cloud platform, is combined into a structured record and written into the key storage space.

[0018] For example, when the system is configured to support three cloud platforms, it will sequentially call the KMS encryption APIs of each platform, encrypting the same business key with their respective master keys, resulting in three ciphertexts. These ciphertexts are then labeled with the platform type and stored in the key mapping table of the key storage space. This ensures that the availability of the business key no longer depends on a single cloud service provider. Even if a cloud platform experiences service interruptions, policy changes, or compliance restrictions, the system can still recover the business key through other registered platforms, thereby improving the system's disaster recovery capabilities and deployment flexibility.

[0019] During business operations, all sensitive data (such as user identity information, transaction records, configuration parameters, etc.) must be encrypted before being written to persistent storage to prevent unauthorized access. To this end, the system uses a generated business key to encrypt the original business data using a verified symmetric encryption algorithm (e.g., AES-256-GCM), generating irreversible ciphertext. To ensure that subsequent decryption operations can accurately match the correct key, the system embeds a unique key identifier of the business key (e.g., a SHA-256 hash value calculated based on the key content or a globally unique UUID) in the header of the ciphertext when generating the ciphertext. This identifier does not contain the key itself and is only used for key version or identity verification.

[0020] After encryption, the complete encrypted business data (including the header identifier) ​​is written to the key storage space, coexisting with the platform key encrypted data in the same logical storage domain. For example, when a user submits a payment request, the system concatenates fields such as the transaction amount and card number into a plaintext data block, encrypts it using the business key to form the encrypted business data, writes the key identifier into the first 8 bytes of the encrypted data, and then stores the entire encrypted data in the key storage space at the location bound to the transaction ID. Because the business data always exists in encrypted form, even if the underlying storage is illegally accessed, attackers cannot directly obtain valid information. At the same time, the introduction of the key identifier allows the system to accurately identify which version of the business key should be used for decryption in multi-key rotation scenarios, avoiding data corruption caused by key confusion.

[0021] When switching to a new cloud platform is required, the system receives a cloud platform switching command that explicitly contains the target cloud platform's platform type identifier. This command may be manually triggered by operations personnel or automatically generated by the automated orchestration engine according to preset policies. After parsing the command, the system searches for a platform key ciphertext record in the key storage space that exactly matches the target platform type identifier. The system then calls the key management service interface provided by the target cloud platform, submitting the platform key ciphertext to the target cloud platform. Its internal master key performs decryption operations in a protected HSM environment, ultimately returning the original business key.

[0022] The business key is loaded into the memory of the current runtime environment and marked as the target business key for the current context, for use in subsequent data processing. For example, if the switching command specifies the target platform as "TENCENT_KMS", the system retrieves the platform key ciphertext marked "TENCENT_KMS" from the key storage space and restores the business key through the decryption interface. The entire decryption process is completed within the security boundary of the target cloud platform. The original business key is never transmitted in plaintext over the network, nor is it exposed to application code, thus achieving cross-platform key recovery while adhering to the principles of least privilege and zero trust.

[0023] After successfully acquiring the target business key, business operations can seamlessly continue on the new cloud platform. For historical business data, the system reads the encrypted business data from the key storage space and decrypts and restores it to obtain the original business data for application layer use. For newly generated business data, the target business key is used directly for encryption to generate new encrypted business data. The entire process is transparent to upper-layer applications; regardless of the cloud platform currently running, applications see a unified data access interface. For example, after migrating to the target cloud platform, when the customer service system queries historical work orders, the backend automatically reads the encrypted data, verifies the key identifier, decrypts it, and returns the plaintext content. Simultaneously, newly submitted work order data is also encrypted and stored using the same target business key. Because the business key remains unchanged before and after the switch, all historical and new data can be correctly encrypted and decrypted, avoiding the overhead of data re-encryption or format conversion caused by platform migration in traditional solutions. This achieves a data security architecture that encrypts once and is universally applicable across multiple clouds, meeting the flexibility requirements of multi-cloud deployment while ensuring end-to-end data confidentiality and consistency.

[0024] In one embodiment, the step of encrypting the business key using the pre-determined master keys of multiple cloud platforms to obtain the platform key ciphertext corresponding to each cloud platform includes: Read the pre-configured cloud platform registry, which contains platform type identifiers for multiple cloud platforms and access parameters for the key management service corresponding to each cloud platform; Iterate through each record in the cloud platform registry. For each record, use the platform type identifier and key management service access parameters in the record to call the corresponding cloud platform's key management service encryption interface, and pass the business key as input data to the encryption interface. Receive the encryption result returned by the encryption interface and identify the encryption result as the platform key ciphertext corresponding to the platform type identifier in the current record.

[0025] During the initialization or key configuration phase, a pre-configured cloud platform registry is read. This registry is structured data containing multiple registration entries. Each entry corresponds to a supported cloud platform, and each entry includes a platform type identifier and access parameters required to interface with the cloud platform's key management service. The platform type identifier uniquely identifies the type of cloud platform, and the access parameters include authentication credentials, master key resource identifier, server endpoint address, region information, and encryption algorithm options required to invoke the cloud platform's key management service.

[0026] The system then iterates through each record in the cloud platform's registry. For each record encountered, the system constructs and initializes a client instance adapted to the cloud platform's key management service, based on the access parameters contained within. The system uses the generated business key as plaintext input data and calls the standard encryption interface provided by the corresponding cloud platform through the client, specifying the use of the master key associated with that record to perform the encryption operation during the call. Because each cloud platform's key management service performs encryption operations within its protected secure execution environment, the plaintext content of the business key is not exposed in the application's runtime environment or network transmission path.

[0027] After the encryption interface completes its execution, the system receives the returned encryption result. This encryption result is the ciphertext data generated by encrypting the business key using the current cloud platform master key. The system directly identifies this encryption result as the platform key ciphertext corresponding to the platform type identifier in the current record.

[0028] After traversing all records in the cloud platform registry, the system obtains a set of platform key ciphertexts, each with a clear correspondence to a specific cloud platform's platform type identifier. The platform key ciphertexts, along with their respective platform type identifiers, are uniformly written into the key storage space, forming a complete key mapping structure. Through an automated processing mechanism based on a pre-configured registry, it can adapt to any number and type of cloud platforms with unified logic, expanding support for new cloud service providers without modifying the core code. Simultaneously, each platform key ciphertext is generated by the corresponding cloud platform within its security boundary, complying with the security policy requirements of each cloud platform and ensuring that business keys can be correctly restored during cross-cloud migration or switching scenarios.

[0029] In one embodiment, encrypting the business data using the business key to obtain ciphertext of the business data includes: Based on preset data segmentation rules, business data is divided into multiple plaintext data blocks of predetermined length; The encryption context of the symmetric encryption algorithm is initialized with the business key, and the encryption operation is performed on each plaintext data block in sequence to generate the ciphertext data block sequence corresponding to the business data. After concatenating the sequence of ciphertext data blocks into a data stream, an identifier for the business key is added to obtain the ciphertext business data.

[0030] The data segmentation rules define a fixed length for each plaintext data block, such as aligning it in units of 16 or 32 bytes. If the total length of the business data is not divisible by this fixed length, padding is applied to the last data block to ensure it meets the segmentation length requirement. Through these segmentation rules, the original business data is divided into an ordered sequence of plaintext data blocks.

[0031] The symmetric encryption algorithm used can be a standard encryption algorithm, such as AES. During initialization, the encryption mode, such as GCM, CBC, or CTR, is specified, and an initialization vector or random number is set as needed. Once the encryption context is established, it is used for the encryption of all subsequent plaintext data blocks.

[0032] Each plaintext data block in the preceding plaintext data block sequence is traversed sequentially, and an encryption operation is performed on that data block within the initialized encryption context. Each encryption operation outputs a ciphertext data block of the same length as the input plaintext data block. All ciphertext data blocks are arranged in the original order of their corresponding plaintext data blocks to form a ciphertext data block sequence.

[0033] After obtaining the complete sequence of ciphertext data blocks, they are sequentially concatenated into a continuous ciphertext data stream. Subsequently, the unique identifier of the business key is appended to the header, footer, or embedded as a metadata field within this ciphertext data stream. This identifier is used to accurately identify the appropriate business key during the subsequent decryption stage, thereby ensuring the correctness of the decryption operation. The resulting overall data structure, containing the ciphertext data stream and the business key identifier, constitutes the business data ciphertext. This structure preserves the integrity and confidentiality of the encrypted data while achieving a traceable association between the ciphertext and the key through the embedded key identifier, providing necessary information support for secure decryption in a multi-key environment.

[0034] In one embodiment, the step of responding to a cloud platform switching instruction and retrieving the platform key ciphertext corresponding to the target cloud platform from the key storage space based on the platform type identifier of the target cloud platform corresponding to the switching instruction includes: In response to a cloud platform switching command, the command is parsed to obtain the platform type identifier of the target cloud platform; Based on the platform type identifier of the target cloud platform, construct a structured query statement; Based on the structured query statement, retrieve the platform key ciphertext corresponding to the target cloud platform from the key storage space.

[0035] During operation, a cloud platform switching command is received, triggered by the operation and maintenance management module, configuration center, or user operation. This command is a structured message that explicitly instructs the business system to migrate its current operating environment to the new cloud platform. First, the cloud platform switching command is parsed to extract a platform type identifier that uniquely identifies the target cloud platform. This platform type identifier is a predefined standardized string that corresponds one-to-one with the cloud platform types supported by the system.

[0036] After obtaining the platform type identifier of the target cloud platform, the system constructs a structured query statement based on this identifier. This query statement follows the data access protocol adopted by the key storage space, and its query condition fields precisely match the platform type identifier to locate the encrypted record associated with that identifier stored in the key storage space. The key storage space can be a relational database table, a key-value store system, a configuration file, or a distributed metadata service. Its data model contains at least two key fields: a platform type identifier field and a platform key ciphertext field.

[0037] The system executes the constructed structured query statement and initiates a read request to the key storage space. The key storage space retrieves matching records based on the query conditions and returns the encrypted platform key corresponding to the platform type identifier of the target cloud platform. The system receives this return result and uses it as input data for subsequent calls to the target cloud platform's key management service decryption interface. This achieves accurate acquisition of relevant key information from the target cloud platform, ensuring accurate restoration of business keys during cloud platform switching, thereby guaranteeing the decryptability and continuous availability of business data in the new cloud environment.

[0038] In one embodiment, the step of decrypting the ciphertext of business data in the key storage space using the target business key includes: Parse the key identifier embedded in the encrypted business data and verify its consistency with the key identifier of the target business key; After the verification is passed, the decryption context of the symmetric decryption algorithm is initialized using the target business key, and the business data ciphertext is divided into multiple ciphertext data blocks according to the block structure of the business data ciphertext. The decryption operation is performed sequentially by calling the decryption context for each ciphertext data block, and the resulting plaintext data blocks are then concatenated to obtain the decrypted business data.

[0039] Load the ciphertext of the business data to be decrypted from the key storage space. This ciphertext is structured data generated in the previous encryption stage, and its format consists of two parts: a ciphertext data stream and an embedded business key identifier. This identifier is written into the ciphertext header, footer, or stored as a separate metadata field associated with the ciphertext during encryption.

[0040] The system parses the encrypted business data, extracts the embedded key identifier, and performs a consistency check against the key identifier carried by the currently recovered target business key. This check ensures that the currently held target business key is indeed the original key used to encrypt the ciphertext, preventing decryption failure or data corruption due to key mismatch. If the two do not match, the system immediately terminates the decryption process and returns a key mismatch error; if they match, subsequent decryption steps continue.

[0041] After successful verification, the system initializes the decryption context of the symmetric decryption algorithm using the target business key. The symmetric decryption algorithm used strictly corresponds to the algorithm used in the encryption phase, such as AES, and is configured with the same encryption mode (such as GCM, CBC, or CTR), initialization vector (IV), and padding scheme. The initialization of the decryption context ensures that the parameter environment for the decryption operation is completely consistent with that during encryption.

[0042] According to preset data segmentation rules, the ciphertext data stream in the business data ciphertext is divided into multiple fixed-length ciphertext data blocks. These segmentation rules are the same as those used in the encryption phase, ensuring that each ciphertext data block can be correctly restored to its corresponding plaintext data block. For cases employing authenticated encryption modes (such as GCM), the system also simultaneously processes Additional Authentication Data (AAD) and Authentication Tag to verify ciphertext integrity.

[0043] The system iterates through the sequence of encrypted data blocks, performing a decryption operation on each block using the initialized decryption context. Each decryption operation outputs a plaintext data block. All plaintext data blocks are then concatenated in their original order within the ciphertext to form a complete plaintext data stream. If padding exists during the original encryption process, the system performs appropriate padding removal after concatenation to restore the original business data. The system outputs complete and accurate decrypted business data for further processing by upper-layer applications. Through this mechanism, the system can securely and reliably restore business data in multi-cloud switching scenarios. Simultaneously, the key identifier verification mechanism effectively prevents the risk of key misuse, ensuring the correctness and security of data decryption.

[0044] In one embodiment, generating the business key and determining the key storage space includes: A random byte sequence of a predetermined length is generated using a random number generator, and the random byte sequence is used as the business key. Create a structured data table in the local database and use the structured data as a key storage space. The structured data table includes a platform type identifier field, a platform key ciphertext field, and a business data ciphertext field.

[0045] During the initialization phase or when the business key rotation is triggered, a cryptographically secure random number generator is invoked to generate a random byte sequence of a predetermined length. This length is set according to the security requirements of the symmetric encryption algorithm used, such as 128 bits, 192 bits, or 256 bits, corresponding to 16 bytes, 24 bytes, or 32 bytes respectively. The generated random byte sequence serves as the business key used in this business session or data object, possessing high entropy and unpredictability.

[0046] Simultaneously, the system creates a structured data table in a local database (e.g., a relational database such as SQLite, MySQL, or PostgreSQL) to uniformly manage keys and encrypted information related to cloud platform switching. This structured data table is explicitly designated as the key storage space, and its table structure includes the following key fields: Platform type identifier field: Used to store the unique identifier of the target cloud platform. This field serves as a query index, supporting the quick location of the key and ciphertext corresponding to a specific cloud platform; Platform key ciphertext field: Used to store the platform key ciphertext encrypted using the master key or Key Management Service (KMS), which is used to decrypt the business key later; Business data ciphertext field: Used to store business data ciphertext encrypted with the business key, ensuring that sensitive data is in an encrypted state when persisted locally.

[0047] After the table is created, the system can temporarily store the newly generated business key in a secure memory area (such as a locked memory page or hardware security module) and wait for subsequent encryption or encapsulation operations. This structured data table, as a centralized storage carrier for keys and ciphertext, not only supports transactional writes and atomic updates, but also facilitates efficient querying, backup, and auditing through SQL statements, thereby improving system maintainability while ensuring security.

[0048] In one embodiment, the method further includes: The decrypted business data is then fed back to the preset terminal.

[0049] After decrypting the encrypted business data and restoring it to plaintext, the target receiving end is identified based on pre-configured terminal information (e.g., device ID, IP address, API endpoint, etc.). This preset terminal can be a user client, business server, monitoring platform, or third-party interface. According to its supported communication protocol, the decrypted data is encapsulated into a corresponding format (e.g., JSON format), and metadata such as timestamps and checksums can be appended. TLS / SSL encryption is enabled during transmission, and trusted IPC mechanisms (such as Unix domain sockets) are used for local communication. Audit logs can also be recorded synchronously, including the recipient identifier, operation time, operator, and data digest, to meet compliance requirements. If the terminal returns a success confirmation, the feedback is considered complete; if it fails or times out, it will retry according to a preset policy or trigger an alarm.

[0050] Reference Figure 2 The diagram shown is a functional module schematic of the business data processing device 100 based on key management according to this application.

[0051] The key-management-based business data processing device 100 described in this application is installed in an electronic device. Depending on its functions, the key-management-based business data processing device 100 includes a generation module 110, a first encryption module 120, a second encryption module 130, a switching module 140, and a decryption module 150. These modules can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, and are stored in the memory of the electronic device.

[0052] In this embodiment, the functions of each module / unit are as follows: Generation module 110: Used to generate business keys and determine key storage space; First encryption module 120: used to encrypt the business key using the master keys of multiple cloud platforms in advance, to obtain the platform key ciphertext corresponding to each cloud platform, and to store each platform key ciphertext and the platform type identifier of the corresponding cloud platform into the key storage space. The second encryption module 130 is used to encrypt business data using the business key to obtain ciphertext of business data, and store the ciphertext of business data in the key storage space. Switching module 140: In response to a cloud platform switching command, it retrieves the platform key ciphertext corresponding to the target cloud platform from the key storage space according to the platform type identifier of the target cloud platform corresponding to the switching command, decrypts the platform key ciphertext corresponding to the target cloud platform, and obtains the decrypted target business key. Decryption module 150: used to decrypt the ciphertext of business data in the key storage space using the target business key, or to encrypt new business data.

[0053] The specific implementation of the business data processing device based on key management in this application is largely the same as the specific implementation of the business data processing method based on key management described above, and will not be repeated here.

[0054] Reference Figure 3 The diagram shown is a schematic representation of a preferred embodiment of the electronic device of this application.

[0055] The electronic device includes a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114. Memory 113 is used to store computer programs, such as key-based business data processing programs; Figure 3Only an electronic device with components 111-114 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0056] In one embodiment of this application, when the processor 111 executes the program stored in the memory 113, it implements the key management-based business data processing method provided in any of the foregoing method embodiments, including: Generate a business key and determine the key storage space; The business key is encrypted using the master keys of multiple cloud platforms that are predetermined, so as to obtain the platform key ciphertext corresponding to each cloud platform. The platform key ciphertext and the platform type identifier of the corresponding cloud platform are stored in the key storage space. The business data is encrypted using the business key to obtain ciphertext of the business data, and the ciphertext of the business data is stored in the key storage space; In response to the cloud platform switching command, based on the platform type identifier of the target cloud platform corresponding to the switching command, the platform key ciphertext corresponding to the target cloud platform is obtained from the key storage space, and the platform key ciphertext corresponding to the target cloud platform is decrypted to obtain the decrypted target business key; The target business key is used to decrypt the ciphertext of business data in the key storage space, or to encrypt new business data.

[0057] For a detailed explanation of the above steps, please refer to the above. Figure 1 A flowchart illustrating an embodiment of a business data processing method based on key management.

[0058] Furthermore, this application also proposes a computer-readable storage medium that is both non-volatile and volatile. This computer-readable storage medium is any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, etc. The computer-readable storage medium includes a data storage area and a program storage area. The program storage area stores a key-managed business data processing program, which, when executed by a processor, performs the following operations: Generate a business key and determine the key storage space; The business key is encrypted using the master keys of multiple cloud platforms that are predetermined, so as to obtain the platform key ciphertext corresponding to each cloud platform. The platform key ciphertext and the platform type identifier of the corresponding cloud platform are stored in the key storage space. The business data is encrypted using the business key to obtain ciphertext of the business data, and the ciphertext of the business data is stored in the key storage space; In response to the cloud platform switching command, based on the platform type identifier of the target cloud platform corresponding to the switching command, the platform key ciphertext corresponding to the target cloud platform is obtained from the key storage space, and the platform key ciphertext corresponding to the target cloud platform is decrypted to obtain the decrypted target business key; The target business key is used to decrypt the ciphertext of business data in the key storage space, or to encrypt new business data.

[0059] The specific implementation of the computer-readable storage medium in this application is largely the same as the specific implementation of the business data processing method based on key management described above, and will not be repeated here.

[0060] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, apparatus, article, or method. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0061] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware simulation platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0062] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A business data processing method based on key management, characterized in that, The method includes: Generate a business key and determine the key storage space; The business key is encrypted using the master keys of multiple cloud platforms that are predetermined, so as to obtain the platform key ciphertext corresponding to each cloud platform. The platform key ciphertext and the platform type identifier of the corresponding cloud platform are stored in the key storage space. The business data is encrypted using the business key to obtain ciphertext of the business data, and the ciphertext of the business data is stored in the key storage space; In response to the cloud platform switching command, based on the platform type identifier of the target cloud platform corresponding to the switching command, the platform key ciphertext corresponding to the target cloud platform is obtained from the key storage space, and the platform key ciphertext corresponding to the target cloud platform is decrypted to obtain the decrypted target business key; The target business key is used to decrypt the ciphertext of business data in the key storage space, or to encrypt new business data.

2. The business data processing method based on key management as described in claim 1, characterized in that, The step involves encrypting the business key using the pre-determined master keys of multiple cloud platforms to obtain the platform key ciphertext corresponding to each cloud platform, including: Read the pre-configured cloud platform registry, which contains platform type identifiers for multiple cloud platforms and access parameters for the key management service corresponding to each cloud platform; Iterate through each record in the cloud platform registry. For each record, use the platform type identifier and key management service access parameters in the record to call the corresponding cloud platform's key management service encryption interface, and pass the business key as input data to the encryption interface. Receive the encryption result returned by the encryption interface and identify the encryption result as the platform key ciphertext corresponding to the platform type identifier in the current record.

3. The business data processing method based on key management as described in claim 1, characterized in that, The step of encrypting business data using the business key to obtain ciphertext business data includes: Based on preset data segmentation rules, business data is divided into multiple plaintext data blocks of predetermined length; The encryption context of the symmetric encryption algorithm is initialized with the business key, and the encryption operation is performed on each plaintext data block in sequence to generate the ciphertext data block sequence corresponding to the business data. After concatenating the sequence of ciphertext data blocks into a data stream, an identifier for the business key is added to obtain the ciphertext business data.

4. The business data processing method based on key management as described in claim 1, characterized in that, The step of responding to a cloud platform switching command involves retrieving the platform key ciphertext corresponding to the target cloud platform from the key storage space based on the platform type identifier of the target cloud platform corresponding to the switching command, including: In response to a cloud platform switching command, the command is parsed to obtain the platform type identifier of the target cloud platform; Based on the platform type identifier of the target cloud platform, construct a structured query statement; Based on the structured query statement, retrieve the platform key ciphertext corresponding to the target cloud platform from the key storage space.

5. The business data processing method based on key management as described in claim 1, characterized in that, The step of decrypting the ciphertext of business data in the key storage space using the target business key includes: Parse the key identifier embedded in the encrypted business data and verify its consistency with the key identifier of the target business key; After the verification is passed, the decryption context of the symmetric decryption algorithm is initialized using the target business key, and the business data ciphertext is divided into multiple ciphertext data blocks according to the block structure of the business data ciphertext. The decryption operation is performed sequentially by calling the decryption context for each ciphertext data block, and the resulting plaintext data blocks are then concatenated to obtain the decrypted business data.

6. The business data processing method based on key management as described in claim 1, characterized in that, The generation of the business key and determination of the key storage space include: A random byte sequence of a predetermined length is generated using a random number generator, and the random byte sequence is used as the business key. Create a structured data table in the local database and use the structured data as a key storage space. The structured data table includes a platform type identifier field, a platform key ciphertext field, and a business data ciphertext field.

7. The business data processing method based on key management as described in claim 1, characterized in that, The method further includes: The decrypted business data is then fed back to the preset terminal.

8. A business data processing device based on key management, characterized in that, The device includes: Generation module: Used to generate business keys and determine the key storage space; The first encryption module is used to encrypt the business key using the master keys of multiple cloud platforms in advance, to obtain the platform key ciphertext corresponding to each cloud platform, and to store each platform key ciphertext and the platform type identifier of the corresponding cloud platform in the key storage space. The second encryption module is used to encrypt business data using the business key to obtain ciphertext of the business data, and to store the ciphertext of the business data in the key storage space. Switching module: It is used to respond to the cloud platform switching command, and according to the platform type identifier of the target cloud platform corresponding to the switching command, it retrieves the platform key ciphertext corresponding to the target cloud platform from the key storage space, decrypts the platform key ciphertext corresponding to the target cloud platform, and obtains the decrypted target business key. Decryption module: used to decrypt the ciphertext of business data in the key storage space using the target business key, or to encrypt new business data.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the business data processing method based on key management as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the business data processing method based on key management as described in any one of claims 1 to 7.

Images