Data storage method and computer program product

Abstract

The embodiment of the application discloses a data storage method and a computer program product, and belongs to the technical field of storage. The method comprises the following steps: sending a storage request to a server, wherein the storage request carries plaintext data; receiving a storage response sent by the server, wherein the storage response carries a plurality of key parameters and an access link of ciphertext data, the ciphertext data is obtained by encrypting the plaintext data based on a first encryption key, and the first encryption key is generated based on the plurality of key parameters; in response to the access link being clicked, obtaining the ciphertext data from the server based on the access link; generating the first encryption key based on the plurality of key parameters, and decrypting the ciphertext data based on the first encryption key to obtain the plaintext data.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a data storage method and computer program product. Background Technology

[0002] To ensure long-term image preservation and prevent image loss, images from mobile devices and other terminals can be stored on a server using the server's Object Storage Service (OSS). In related technologies, after the server stores the image through OSS, it returns an access link to the image to the terminal, allowing the terminal to subsequently access the image stored in OSS via this link. Summary of the Invention

[0003] This application provides a data storage method and a computer program product. The technical solution is as follows: On one hand, embodiments of this application provide a data storage method, the method comprising: Send a storage request to the server, the storage request carrying plaintext data; The server receives a storage response, which carries multiple key parameters and an access link for encrypted data. The encrypted data is obtained by the server encrypting the plaintext data based on a first encryption key, which is generated by the server based on the multiple key parameters. In response to the access link being clicked, the encrypted data is retrieved from the server based on the access link; Based on the multiple key parameters, a first encryption key is generated, and the ciphertext data is decrypted based on the first encryption key to obtain the plaintext data.

[0004] On the other hand, embodiments of this application provide a data storage method, the method comprising: The terminal receives a storage request, the storage request carrying plaintext data; Based on multiple key parameters of the plaintext data, a first encryption key for the plaintext data is generated; The plaintext data is encrypted using the first encryption key, and the ciphertext data is stored. An access link to the encrypted data is generated, and a storage response is sent to the terminal, the storage response carrying the access link and the plurality of key parameters.

[0005] On the other hand, embodiments of this application provide a data storage device, the device comprising: The first sending module is used to send a storage request to the server, the storage request carrying plaintext data; The first receiving module is used to receive a storage response sent by the server. The storage response carries multiple key parameters and an access link for ciphertext data. The ciphertext data is obtained by the server encrypting the plaintext data based on a first encryption key, which is generated by the server based on the multiple key parameters. The acquisition module is configured to, in response to the access link being clicked, acquire the encrypted data from the server based on the access link; The first generation module is used to generate the first encryption key based on the plurality of key parameters; The first decryption module is used to decrypt the ciphertext data based on the first encryption key to obtain the plaintext data.

[0006] On the other hand, embodiments of this application provide a data storage device, the device comprising: The second receiving module is used to receive a storage request from the terminal, wherein the storage request carries plaintext data; The second generation module is used to generate a first encryption key for the plaintext data based on multiple key parameters of the plaintext data. A storage module is used to encrypt the plaintext data based on the first encryption key and store the ciphertext data; The third generation module is used to generate access links for the encrypted data; The second sending module is used to send a storage response to the terminal, the storage response carrying the access link and the plurality of key parameters.

[0007] On the other hand, embodiments of this application provide a terminal, the terminal including a processor and a memory, the memory storing at least one computer instruction, the at least one computer instruction being loaded and executed by the processor to implement the data storage method as described above.

[0008] On the other hand, embodiments of this application provide a server, the server including a processor and a memory, the memory storing at least one computer instruction, the at least one computer instruction being loaded and executed by the processor to implement the data storage method as described above.

[0009] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one computer instruction, which is executed by a processor to implement the data storage method as described above.

[0010] On the other hand, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the data storage method as described above.

[0011] In this embodiment, when the terminal stores plaintext data in the server, the server returns an access link for the encrypted data and multiple key parameters to the terminal. The terminal generates a first encryption key based on the multiple key parameters and according to an agreed key generation rule. Then, when the terminal requests access to the plaintext data, the server returns the encrypted data to the terminal, allowing the terminal to decrypt the encrypted data based on the first encryption key to obtain the plaintext data. This establishes a "server controls the key, terminal controls the display" implementation path, further improving the security of the plaintext data. Attached Figure Description

[0012] Figure 1 This is a schematic diagram illustrating the implementation environment of a data storage method according to an exemplary embodiment of this application; Figure 2 This is a flowchart illustrating a data storage method in an exemplary embodiment of this application; Figure 3 This is a schematic diagram illustrating a data storage method in an exemplary embodiment of this application; Figure 4 This is a schematic diagram illustrating a data storage method in an exemplary embodiment of this application; Figure 5 This is a flowchart illustrating a data storage method in an exemplary embodiment of this application; Figure 6 This is a flowchart illustrating a data storage method in an exemplary embodiment of this application; Figure 7 This is a schematic diagram illustrating a data storage method in an exemplary embodiment of this application; Figure 8 This is a flowchart illustrating a data storage method in an exemplary embodiment of this application; Figure 9 This is a structural block diagram of a data storage device illustrated in an exemplary embodiment of this application; Figure 10 This is a structural block diagram of a data storage device illustrated in an exemplary embodiment of this application; Figure 11 This is a structural block diagram of a terminal illustrated in an exemplary embodiment of this application; Figure 12 This is a structural block diagram of a terminal shown in an exemplary embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0014] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0015] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0016] Please refer to Figure 1 This diagram illustrates an implementation environment for a data storage method provided in an exemplary embodiment of this application. The implementation environment includes a terminal 101 and a server 102. The terminal 101 has a data storage client installed and running, which can be a photo album or storage client. The terminal 101 can use this client to store data from its internal storage to the server 102. The server 102 includes an OSS 1021, which can store the data. The data can be multimedia data or files; multimedia data can be images or videos, etc.

[0017] Before storing plaintext data through OSS1021, server 102 can also obtain a first encryption key, encrypt the plaintext data with the first encryption key, and then store the ciphertext data through OSS1021; server 102 also includes a Key Management Service (KMS) 1022, which is used to store the first encryption key or to store multiple key parameters that generate the first encryption key.

[0018] The method provided in this application embodiment can be applied to the following scenarios: First application scenario: shooting scenario; The data is multimedia data; when a user captures multimedia data, terminal 101 directly uploads the captured multimedia data to OSS 1021 of server 102 for storage. For example, if a user captures an image, terminal 101 uploads the captured image to OSS 1021 of server 102 for storage.

[0019] The second application scenario: periodic uploads; The data is multimedia data; the user pre-sets an upload cycle, and the terminal 101 uploads the multimedia data captured within that upload cycle to the OSS1021 of the server 102 for storage every time the upload cycle is set. For example, if the upload cycle is 1 day, then the terminal 101 will upload the multimedia data captured on that day to the OSS1021 of the server 102 for storage every day.

[0020] The third application scenario: target multimedia data upload scenario; The data is multimedia data. After the user captures multimedia data, terminal 101 will upload the multimedia data corresponding to the target person to OSS1021 of server 102 for storage; the target person can be a child, parents, or the user themselves, etc. Alternatively, terminal 101 will upload multimedia data of the target type to OSS1021 of server 102 for storage; the target type can be an image, screenshot, QR code image, scanned image, ticket image, ID photo, or card image, etc. Alternatively, terminal 101 can transmit multimedia data of the target scene to OSS1021 of server 102 for storage; the target scene can be a wedding scene or a birthday party scene, etc.

[0021] It should be noted that this application can be applied in any scenario where there is a need for data storage. The above three application scenarios are merely examples and do not limit the application scenarios of the embodiments of this application.

[0022] Terminal 101 can be a device such as a mobile phone, tablet computer, in-vehicle terminal, multimedia playback device, wearable device, VR (Virtual Reality) device, AR (Augmented Reality) device, or MR (Mixed Reality) device. Terminal 101 is connected to server 102 via a wireless network or wired network; server 102 includes at least one of a single server, multiple servers, a cloud computing platform, and a virtualization center. Server 102 is used to provide backend services for the supplementary lighting function application.

[0023] Please refer to Figure 2 The diagram illustrates a flowchart of a data storage method provided in an exemplary embodiment of this application. The method may include the following steps: Step 201: Send a storage request to the server, the storage request carrying plaintext data.

[0024] Plaintext data refers to unencrypted data or decrypted data; and plaintext data can be plaintext files or plaintext multimedia data, which can be plaintext images or plaintext videos. Before the terminal sends a storage request to the server, a session link is established between the terminal and the server. The terminal sends the storage request to the server through this session link. In addition to carrying plaintext data, the storage request may also carry at least one of the following: terminal identifier, user identifier, session link identifier, and session link expiration time.

[0025] In one possible implementation, when a terminal sends a storage request to the server, it can interact with the server through the gateway's cloud encryption capabilities; correspondingly, please refer to... Figure 3 and Figure 4 The steps for sending a storage request to the server can be as follows: encrypt the storage request to obtain an encrypted storage request; send the encrypted storage request to the gateway, so that the gateway decrypts the encrypted storage request and forwards it to the server.

[0026] In this embodiment of the application, when the terminal uploads plaintext data to the server, it does not directly expose the plaintext data to the open link. Instead, it establishes a secure channel with the server through the cloud encryption capability of the gateway to ensure the confidentiality and integrity of the plaintext data during the upload process.

[0027] Step 202: Receive the storage response sent by the server. The storage response carries multiple key parameters and an access link for ciphertext data. The ciphertext data is obtained by the server encrypting plaintext data based on the first encryption key, which is generated by the server based on multiple key parameters.

[0028] The multiple key parameters include at least one first key parameter and at least one second key parameter, wherein the at least one first key parameter is generated randomly and the at least one second key parameter is used to uniquely represent the plaintext data.

[0029] In the embodiments of this application, at least one first key parameter can reflect the independent randomness of plaintext data; at least one second key parameter can reflect the uniqueness of plaintext data; therefore, the first encryption key generated based on at least one first key parameter and at least one second key parameter can have randomness and uniqueness, thereby enhancing the key isolation capability.

[0030] In one possible implementation, the stored response may also carry an initialization vector for the plaintext data, and the ciphertext data is obtained by the server encrypting the plaintext data based on the first encryption key and the initialization vector. The initialization vector is a random or pseudo-random input value used in cryptography to increase security. Its main function is to generate different ciphertext data when encrypting the same plaintext data with the same first encryption key, thereby preventing third parties from deducing the plaintext data through pattern analysis; and the initialization vector generated by the server is different each time.

[0031] In another possible implementation, the storage response may carry an access link to the encrypted data without carrying multiple key parameters; the multiple key parameters are only sent to the terminal when the terminal requests access to the encrypted data based on the access link.

[0032] In another possible implementation, the terminal includes a Trusted Execution Environment (TEE); the terminal can store the access link and multiple key parameters in the TEE. In this embodiment, the mechanism provided by the TEE is used to persistently protect the access link and multiple key parameters, thereby achieving secure system storage.

[0033] Step 203: In response to the access link being clicked, retrieve encrypted data from the server based on the access link.

[0034] In response to the access link being clicked, an access request is sent to the server based on the access link; the server receives the access request, obtains the encrypted data corresponding to the access link based on the access request, and sends the encrypted data to the terminal; the terminal receives the encrypted data.

[0035] In one possible implementation, the step of sending an access request to the server can be: encrypting the access request and sending the encrypted access request to the gateway; the gateway receives the encrypted access request, decrypts the access request, and forwards it to the server.

[0036] In another possible implementation, if the storage response in step 202 carries an access link but not multiple key parameters, then step 203 can be: in response to the access link being clicked, retrieving ciphertext data and multiple key parameters from the server based on the access link. Alternatively, in response to the access link being clicked, retrieving ciphertext data, multiple key parameters, and an initialization vector for plaintext data from the server based on the access link.

[0037] Step 204: Generate a first encryption key based on multiple key parameters, and decrypt the ciphertext data based on the first encryption key to obtain plaintext data.

[0038] The terminal and server negotiate key generation rules in advance. Based on the key generation rules and multiple key parameters, a first encryption key is generated. At least one first key parameter includes a randomly generated first string, and at least one second key parameter includes a data identifier for the plaintext data. Correspondingly, the steps for generating the first encryption key based on the multiple key parameters can be as follows: Concatenate the first string and the data identifier to obtain the first encryption key; or, extract a first number of characters from the first string to obtain the second string, determine the hash value of the data identifier, extract a second number of characters from the hash value to obtain the third string, and concatenate the second string and the third string to obtain the first encryption key.

[0039] Extract the first number of characters from the first string; or extract the last number of first characters from the first string. The hash value of the data identifier can be determined using any hash algorithm; for example, using the 256-bit secure hash algorithm (SHA256). Then, extract the first second number of characters from the hash value; or, extract the last second number of characters from the hash value. The concatenation order of the second and third strings can be set and changed as needed. In this embodiment, the concatenation order of the second and third strings is not specifically limited; for example, the second string + the third string yields the first encryption key; or, the third string + the second string yields the first encryption key.

[0040] The first quantity and the second quantity can be the same or different; in this embodiment, the example is given where the first quantity and the second quantity are the same and both are 16. Please refer to [reference needed]. Figure 4 Extract the first 16 characters from the first string to obtain the second string "R16". Perform sha256 calculation on the data identifier and extract the first 16 characters of the sha256(mediaId) result to obtain the third string "H16". Concatenate "R16" and "H16" to obtain the first encryption key. The second encryption key can then be represented as FileKey = UUID[0:16] + sha256(mediaId)[0:16], where UUID represents the first string.

[0041] In this embodiment, the second string can reflect the independent randomness of the plaintext data, and the third string can reflect the uniqueness of the plaintext data; therefore, the first encryption key obtained by concatenating the second string and the third string simultaneously possesses randomness, uniqueness and plaintext data binding, thus enhancing the key isolation capability.

[0042] It should be noted that the key generation rule above, which generates the first encryption key based on multiple key parameters, is just an example and does not impose any limitations on the key generation rule. The key generation rule can be adjusted according to business needs. For example, if the key generation rule is to concatenate multiple key parameters, then the process of generating the first encryption key based on multiple key parameters can be: concatenate multiple key parameters to obtain the first encryption key.

[0043] In another possible implementation, the storage response also carries an initialization vector for the plaintext data, and the ciphertext data is obtained by the server encrypting the plaintext data based on the first encryption key and the initialization vector. Then, the step of decrypting the ciphertext data based on the first encryption key to obtain the plaintext data can be: decrypting the ciphertext data based on the first encryption key and the initialization vector to obtain the plaintext data.

[0044] For example, please continue to refer to Figure 4 The first encryption key and the initialization vector of the plaintext data are concatenated to obtain the fourth encryption key. The ciphertext data is then decrypted based on the fourth encryption key to obtain the plaintext data. The concatenation order of the first encryption key and the initialization vector can be set and changed as needed. In this embodiment, the concatenation order of the first encryption key and the initialization vector is not specifically limited. For example, the fourth encryption key is obtained by combining the first encryption key and the initialization vector; or, the fourth encryption key is obtained by combining the initialization vector and the first encryption key.

[0045] In this embodiment of the application, when encrypting plaintext data, the security of the obtained ciphertext data can be enhanced by introducing an initialization vector for the plaintext data.

[0046] In one possible implementation, in step 202, the server has sent multiple key parameters to the terminal; in step 202, the terminal stores multiple key parameters. In this step, the terminal obtains the stored multiple key parameters, then generates a first encryption key based on the multiple key parameters, and decrypts the ciphertext data based on the first encryption key to obtain plaintext data.

[0047] In another possible implementation, the server has already sent multiple key parameters to the terminal in step 202. In step 202, the terminal can generate a first encryption key based on the multiple key parameters and store the first encryption key. In this step, the stored first encryption key is directly obtained, and then the ciphertext data is decrypted based on the first encryption key to obtain the plaintext data.

[0048] For example, please continue to refer to Figure 3The terminal sends an access request to the server (or the OSS in the server) to request the acquisition of encrypted data; the server (or the OSS in the server) returns the encrypted data to the terminal based on the access request; the terminal generates a first encryption key based on the agreed key generation rules and multiple key parameters, and decrypts the encrypted data based on the first encryption key to obtain plaintext data, and renders the plaintext data.

[0049] Within the TEE, the terminal decrypts the ciphertext data using the first encryption key to obtain plaintext data. It then provides a secure path to transmit the plaintext data to the terminal's display service, which renders and displays the plaintext data. This achieves memory-mode decryption and rendering, thereby improving the security of the plaintext data.

[0050] In this embodiment, when the terminal stores plaintext data in the server, the server returns an access link for the encrypted data and multiple key parameters to the terminal. The terminal generates a first encryption key based on the multiple key parameters and according to an agreed key generation rule. Then, when the terminal requests access to the plaintext data, the server returns the encrypted data to the terminal, allowing the terminal to decrypt the encrypted data based on the first encryption key to obtain the plaintext data. This establishes a "server controls the key, terminal controls the display" implementation path, further improving the security of the plaintext data.

[0051] Please refer to Figure 5 The diagram illustrates a flowchart of a data storage method provided in an exemplary embodiment of this application. The method may include the following steps: Step 501: Receive a storage request from the terminal, the storage request carrying plaintext data.

[0052] The storage request also carries at least one of the following: terminal identifier, user identifier, session link identifier, and session link expiration; the server stores at least one of the following: terminal identifier, user identifier, session link identifier, and session link expiration, so that when the terminal accesses the encrypted data, it can be verified based on at least one of the following: terminal identifier, user identifier, session link identifier, and session link expiration, and the terminal is allowed to access the encrypted data only after the verification is successful.

[0053] Step 502: Generate the first encryption key for the plaintext data based on multiple key parameters of the plaintext data.

[0054] The process by which the server generates the first encrypted key for the plaintext data based on multiple key parameters of the plaintext data is the same as the process by which the terminal generates the first encrypted key for the plaintext data based on multiple key parameters of the plaintext data, and will not be described again here.

[0055] The multiple key parameters include at least one first key parameter and at least one second key parameter, wherein the at least one first key parameter is randomly generated, and the at least one second key parameter is used to uniquely identify the plaintext data. For example, at least one first key parameter includes a randomly generated first string, and at least one second key parameter includes a data identifier for the plaintext data.

[0056] For example, please refer to Figure 4 The terminal selects plaintext data, which is then encrypted via the gateway cloud and uploaded to the server. The server receives the plaintext data and generates a data identifier for the plaintext data. This data identifier serves as a unique identifier for the plaintext data during subsequent review, encryption, storage, and access stages. Furthermore, if the plaintext data is an image, this data identifier can be a unique image identifier (Media Identifier, mediald). The first string can be a random string. For example, please refer to [reference needed]. Figure 4 The server generates a randomly generated universally unique identifier (UUID).

[0057] Step 503: Encrypt the plaintext data based on the first encryption key and store the ciphertext data.

[0058] The server includes OSS; after encrypting the plaintext data based on the first encryption key, the server sends the ciphertext data to OSS, which stores the ciphertext data; or, the server sends the first encryption key and the plaintext data to OSS, which encrypts the plaintext data based on the first encryption key and then stores the ciphertext data.

[0059] In another possible implementation, the server generates an initialization vector for the plaintext data. In this step, the plaintext data is encrypted based on the first encryption key and the initialization vector, and the ciphertext data is stored.

[0060] Step 504: Generate an access link for the encrypted data and send a storage response to the terminal. The storage response carries the access link and multiple key parameters.

[0061] In one possible implementation, the storage response may also carry an initialization vector for the plaintext data. In another possible implementation, the storage response carries an access link without carrying multiple key parameters; the multiple key parameters are then sent to the terminal when the terminal subsequently accesses the encrypted data based on this access link.

[0062] In one possible implementation, the server includes a Key Management System (KMS). After generating multiple key parameters for plaintext data, the server sends these key parameters to the KMS for safekeeping. In another possible implementation, the multiple key parameters on the server are not persistently stored in plaintext form, but are instead encrypted and stored. Please refer to the relevant documentation for further details. Figure 3 The method also includes: Multiple key parameters are encrypted using the second encryption key of KMS, and the encrypted key parameters are stored. Before sending the storage response to the terminal, the stored encrypted key parameters are decrypted based on the second encryption key.

[0063] The step of storing the encrypted key parameters can be as follows: using the data identifier as an index, store the encrypted key parameters in the database.

[0064] In this embodiment of the application, the server uses the second encryption key in KMS to encrypt and protect multiple key parameters. The database stores the multiple key parameters after KMS encryption and protection, and does not save the plaintext of the multiple key parameters. Therefore, even if the database is accessed, the multiple key parameters cannot be obtained directly, thereby reducing the risk of leakage of multiple key parameters and improving the security of storing multiple key parameters.

[0065] In one possible implementation, the server interacts with the terminal through the gateway's cloud encryption capabilities. Accordingly, the step of sending a storage response to the terminal can be: sending a storage response to the gateway, the storage response carrying an access link and multiple key parameters; the gateway receiving the storage response, encrypting the storage response, and sending the encrypted storage response to the terminal; the terminal receiving the encrypted storage response sent by the gateway, decrypting the encrypted storage response to obtain the storage response, retrieving the access link and multiple key parameters from the storage response, and then storing the access link and multiple key parameters.

[0066] In this embodiment, the gateway-side cloud encryption capability is used to send an access link and multiple key parameters to the terminal, thereby further reducing the risk that the terminal will generalize its decryption capabilities to third parties.

[0067] In another possible implementation, the access link and multiple key parameters can be sent to the terminal via two transmission links. Correspondingly, the step of sending an access storage request to the terminal can be: after obtaining multiple key parameters in step 202, sending the multiple key parameters to the terminal; after generating the access link for the encrypted data in step 204, sending the access link to the terminal. This sends the access link and multiple key parameters to the terminal via two transmission links, ensuring that the multiple key parameters required for the encrypted data are not returned to the terminal along with the access link. This prevents multiple key parameters and the access link from being simultaneously stolen by a third party, further improving the security of the plaintext data.

[0068] In this embodiment, since the access link is used to access encrypted data, even if the access link and multiple key parameters are leaked, the third party will still obtain encrypted data through the access link. The third party cannot know the key generation rules for generating the first encryption key based on multiple key parameters. Therefore, the third party cannot decrypt the encrypted data based on multiple key parameters, thereby significantly reducing the risk of direct leakage of encrypted data.

[0069] Furthermore, since the terminal does not directly obtain plaintext data or long-term universal keys, but generates the first encryption key in real time based on multiple key parameters and key generation rules, it raises the threshold for third-party replay, dissemination and generalization, thereby reducing the possibility of decryption capabilities being directly generalized.

[0070] Please refer to Figure 6 This illustrates a flowchart of data storage provided in an exemplary embodiment of this application. The method may include the following steps: Step 601: Receive a storage request from the terminal, the storage request carrying plaintext data.

[0071] In some embodiments, this step is the same as step 501, and will not be described again here.

[0072] Step 602: Perform compliance verification on the plaintext data.

[0073] For example, please continue to refer to Figure 4 The server includes an auditing service that performs compliance verification on plaintext data. When the plaintext data is an image, the auditing service can be an image review service.

[0074] The server (or the auditing service within the server) pre-stores auditing rule information, which represents the auditing rules for compliance verification. Based on this auditing rule information, the server performs compliance verification on plaintext data. For example, if the auditing rule information indicates a violation, and the plaintext data belongs to that violation, the plaintext data compliance verification is determined to fail; if the plaintext data does not belong to that violation, the plaintext data compliance verification is determined to pass.

[0075] For example, if the review rule information is illegal content, the plaintext data compliance verification is determined to fail if the plaintext data is illegal content; otherwise, the plaintext data compliance verification is determined to pass if the plaintext data is not illegal content.

[0076] In one possible implementation, a compliance verification model is deployed on the server. In this step, the server directly inputs plaintext data into the compliance verification model to obtain a compliance verification result, which is either a first verification result or a second verification result. The first verification result is used to indicate that the compliance verification of the plaintext data has passed, and the second verification result is used to indicate that the compliance verification of the plaintext data has failed.

[0077] If the plaintext data passes the compliance verification, proceed to step 603; if the plaintext data fails the compliance verification, send a first failure message to the terminal. The first failure message indicates a failure to store data. The first failure message may also include a reason for failure, which may be that the plaintext data failed the compliance verification.

[0078] In this embodiment, only plaintext data that passes compliance verification is allowed to enter the subsequent encrypted storage process; plaintext data that fails compliance verification is directly terminated from the processing process and is not subject to the subsequent encrypted storage process, thereby reducing risks from the source and improving the server's governance capabilities for plaintext data.

[0079] In another possible implementation, the server pre-stores multiple security audit engines, which are used to perform compliance verification on different types of plaintext data. Accordingly, the steps for performing compliance verification on plaintext data can be: based on the type of plaintext data, obtain the target security audit engine corresponding to that type from the multiple security audit engines, and perform compliance verification on the plaintext data through the target security audit engine.

[0080] Step 603: If the plaintext data passes the compliance verification, obtain multiple key parameters of the plaintext data, and generate the first encryption key of the plaintext data based on the multiple key parameters.

[0081] In some embodiments, the process of obtaining multiple key parameters of plaintext data in step 603 and generating a first encryption key for plaintext data based on the multiple key parameters is the same as in step 502, and will not be repeated here.

[0082] Step 604: Encrypt the plaintext data based on the first encryption key.

[0083] In some embodiments, step 604 is the same as the process of encrypting plaintext data based on the first encryption key in step 503, and will not be described again here.

[0084] Step 605: Determine the sensitivity level of the plaintext data. The sensitivity level is used to characterize the sensitivity of the plaintext data.

[0085] In one possible implementation, the sensitivity level of plaintext data is determined by identifying whether it contains core confidential data, critical sensitive data, or identity information. Core confidential data may include biometric information such as genetic information, fingerprint information, and iris information; critical sensitive data includes information such as identification documents, account numbers, and passwords; and identity information may include names or addresses. Accordingly, the steps for determining the sensitivity level of plaintext data can be as follows: If the plaintext data contains core confidential data, its sensitivity level is determined to be Level 4; if the plaintext data contains key sensitive data, its sensitivity level is determined to be Level 3; if the plaintext data contains identity information, its sensitivity level is determined to be Level 2; if the plaintext data does not contain core confidential data, key sensitive data, or identity information, its sensitivity level is determined to be Level 1.

[0086] After the server determines the sensitivity level of the plaintext data, it determines whether the sensitivity level of the plaintext data is higher than the sensitivity threshold. If the sensitivity level is higher than the sensitivity threshold, step 606 is executed; if the sensitivity level is lower than or equal to the sensitivity threshold, step 608 is executed.

[0087] The level threshold can be set and changed as needed. In this embodiment, the level threshold is not specifically limited. For example, the level threshold can be the second level. Then, if the sensitivity level of the plaintext data is the fourth or third level, the sensitivity level is determined to be higher than the level threshold. If the sensitivity level of the plaintext data is the second or first level, the sensitivity level of the plaintext data is determined to be lower than or equal to the level threshold.

[0088] In one possible implementation, after determining the sensitivity level of the plaintext data, the sensitivity level of the plaintext data is stored in a database, and the sensitivity level of the plaintext data is stored in the database using the data identifier of the plaintext data as an index.

[0089] It should be noted that the sensitivity level of plaintext data can be determined either after the plaintext data has been encrypted using the first encryption key, or during the compliance verification of the plaintext data.

[0090] Step 606: If the sensitivity level is higher than the sensitivity threshold, store the encrypted data in the first storage space.

[0091] The server includes OSS, which stores encrypted data. Different levels of sensitivity data in OSS are stored in different buckets. Accordingly, the first storage space can be the first bucket in OSS. The first bucket can be a private bucket. A private bucket is a bucket with public read access disabled, which can only be accessed through controlled methods such as signed access links.

[0092] Step 607: With the encrypted data stored in the first storage space, the first storage path and expiration time are encrypted based on the third encryption key to obtain the first access link for the encrypted data. The first storage path is the storage path of the encrypted data in the first storage space.

[0093] The first access link can be a signed URL, which is an access link containing signature information and an expiration time. The server allows the terminal to access (or retrieve) encrypted data based on the first access link before that expiration time.

[0094] In related technologies, a first access link controls the terminal to access (or obtain) plaintext data; however, in this embodiment, the plaintext data is stored in encrypted form on the server. Even if the first access link is leaked within the access period, the third party still cannot directly view the plaintext data, thus achieving a dual protection mechanism of access control and encryption.

[0095] Step 608: If the sensitivity level is lower than or equal to the sensitivity threshold, store the encrypted data in the second storage space. The access permission level of the first storage space is higher than that of the second storage space.

[0096] The second storage space can be a second bucket in OSS; the second bucket can be a shared bucket; a shared bucket refers to a bucket with public read permissions enabled, suitable for storing low-sensitivity plaintext data, which can be accessed through a fixed access link to balance access efficiency and cost. A higher access permission level for the first storage space than for the second storage space means that the first storage space allows access via a signed access link, while the second storage space allows access via a fixed access link.

[0097] In this embodiment of the application, plaintext data is partitioned and stored according to its sensitivity level, so that low-sensitivity plaintext data can continue to maintain high access efficiency, while high-sensitivity plaintext data is stored in encrypted form and accessed under controlled conditions, thus achieving a balance between cost and security.

[0098] For example, if the first storage space is a private bucket and the second storage space is a public bucket, then by differentiating between the public and private buckets, plaintext data of different sensitivity levels can be stored using different strategies, ensuring security while also taking into account resource utilization efficiency.

[0099] In another possible implementation, the server can set up multiple storage spaces (buckets), and data of different sensitivity levels can be stored in different storage spaces; accordingly, steps 606 and 608 can be replaced by: based on the sensitivity level of the plaintext data, obtaining a target storage space that matches the sensitivity level from multiple storage spaces, and storing the ciphertext data in the target storage space.

[0100] In this embodiment of the application, the server divides the data into multiple storage spaces and stores the ciphertext data into the corresponding target storage space based on the sensitivity level of the plaintext data, thereby achieving more granular plaintext data governance.

[0101] In another possible implementation, after the server stores the encrypted data in a storage space (either a first or second storage space), it stores the storage information of the encrypted data (either information in the first or second storage space) in a database using a data identifier as an index.

[0102] Step 609: With the encrypted data stored in the second storage space, generate a second access link for the encrypted data based on the second storage path, where the second storage path is the storage path of the encrypted data in the second storage space.

[0103] The second access link can be a fixed URL, which is a stable address where encrypted data is stored on the server and typically does not change over time or location. Furthermore, fixed URLs usually do not have an expiration time; or their access validity period is indefinite. Since the first access link has an expiration time, while the second access link does not, the access validity period of the second access link is longer than that of the first access link. Also, the first access link is a signed URL with signature information, while the second access link is a fixed URL; therefore, the security level of the second access link is lower than that of the first access link.

[0104] In this embodiment, for plaintext data with high sensitivity level, a first access link with higher security level and shorter access time is generated; for plaintext data with low sensitivity level, a second access link with lower security level and longer access time is generated, so that plaintext data with different sensitivity levels adopt different access strategies, ensuring security while taking into account resource utilization efficiency.

[0105] Step 610: Send an access response to the terminal, which carries a first access link (or a second access link) and multiple key parameters.

[0106] In some embodiments, this step is the same as step 504, and will not be described again here.

[0107] For example, please refer to Figure 7 In this application embodiment, the security issue of plaintext data is expanded from "storage access control" to an integrated design of gateway-side cloud encryption + compliance verification + plaintext data encryption + key encryption protection + hierarchical storage + subsequent terminal decryption of plaintext data, thereby realizing a complete end-to-end security closed-loop architecture for plaintext data.

[0108] Please refer to Figure 8 This illustrates a flowchart of data storage provided in an exemplary embodiment of this application. The method may include the following steps: Step 801: Receive a storage request from the terminal, the storage request carrying plaintext data.

[0109] In some embodiments, this step is the same as step 501, and will not be described again here.

[0110] Step 802: Generate the first encryption key for the plaintext data based on multiple key parameters of the plaintext data.

[0111] In some embodiments, this step is the same as step 502, and will not be described again here.

[0112] Step 803: Encrypt the plaintext data based on the first encryption key and store the ciphertext data.

[0113] In some embodiments, this step is the same as step 503, and will not be described again here.

[0114] Step 804: Generate an access link for the encrypted data and send a storage response to the terminal. The storage response carries the access link and multiple key parameters.

[0115] In some embodiments, this step is the same as step 504, and will not be described again here.

[0116] Step 805: Receive the access request from the terminal, which is triggered based on the access link.

[0117] In step 804, the server sends a storage response to the terminal, carrying an access link for the encrypted data and multiple key parameters. The terminal receives the access link and key parameters from the server and stores them using the plaintext data's identifier as an index. When a user needs to access the plaintext data, the user clicks the access link, and the terminal sends an access request to the server, carrying an access link, which can be either a first access link or a second access link.

[0118] After receiving the access request, the server retrieves the access link from the request. If the access link is the first access link, the server determines whether the current time has exceeded the expiration time of the first access link and whether the signature information contained in the first access link is consistent with the signature information of the stored first access link. If the current time has not exceeded the expiration time of the first access link and the signature information contained in the first access link is consistent with the signature information of the stored first access link, step 806 is executed. If the current time has exceeded the expiration time of the first access link, or if the signature information contained in the first access link is inconsistent with the signature information of the stored first access link, a second failure message is sent to the terminal. The second failure message indicates that the access to plaintext data has failed. The second failure message may also include a reason for failure, which may be that the signature information contained in the first access link is incorrect, or that the access time of the first access link has expired.

[0119] In one possible implementation, the access request also carries at least one of a terminal identifier, a user identifier, a session link identifier, and a session link validity period. Accordingly, the server authenticates the access request based on at least one of the terminal identifier, user identifier, session link identifier, and session link validity period. If the authentication of the access request is successful, step 806 is executed. If the authentication of the access request fails, a third failure message is sent to the terminal. The third failure message is used to indicate that the authentication of the access request has failed. The third failure message may also include a failure reason, which may be an authentication failure of at least one of the terminal identifier, user identifier, session link identifier, and session link validity period.

[0120] When the access request carries a terminal identifier, the server determines whether the terminal identifier carried in the access request is the same as the terminal identifier carried in the storage request. If the terminal identifier carried in the access request is the same as the terminal identifier carried in the storage request, the access request is authenticated; if the terminal identifier carried in the access request is different from the terminal identifier carried in the storage request, the access request is not authenticated.

[0121] When an access request carries a user identifier, the server determines whether the user identifier carried in the access request is the same as the user identifier carried in the storage request. If the user identifier carried in the access request is the same as the user identifier carried in the storage request, the access request is authenticated; if the user identifier carried in the access request is different from the user identifier carried in the storage request, the access request is not authenticated.

[0122] When an access request carries a session link identifier, the server determines whether the session link identifier carried in the access request is the same as the session link identifier carried in the storage request. If the session link identifier carried in the access request is the same as the session link identifier carried in the storage request, the access request is authenticated; if the session link identifier carried in the access request is different from the session link identifier carried in the storage request, the access request is not authenticated.

[0123] When an access request carries a session link validity period, the server determines whether the current time is within the session link validity period. If the current time is within the session link validity period, the access request is authenticated; otherwise, the access request is not authenticated. Alternatively, the access request may not carry a session link validity period, but the terminal sends a storage request to the server that carries the session link validity period. The server stores this session link validity period. Accordingly, after receiving the access request, the server retrieves the stored session link validity period, then determines whether the current time is within the session link validity period. If the current time is within the session link validity period, the access request is authenticated; otherwise, the access request is not authenticated.

[0124] Step 806: Based on the access link, obtain the encrypted data and send the encrypted data to the terminal, so that the terminal decrypts the encrypted data based on the first encryption key to obtain the plaintext data. The first encryption key is generated by the terminal based on multiple key parameters.

[0125] In this embodiment, when the terminal stores plaintext data in the server, the server returns an access link for the encrypted data and multiple key parameters to the terminal. The terminal generates a first encryption key based on the multiple key parameters and according to an agreed key generation rule. Then, when the terminal requests access to the plaintext data, the server returns the encrypted data to the terminal, allowing the terminal to decrypt the encrypted data based on the first encryption key to obtain the plaintext data. This establishes a "server controls the key, terminal controls the display" implementation path, further improving the security of the plaintext data.

[0126] Since the data obtained through the access link is encrypted, even if a third party steals the access link and multiple key parameters, the third party can only obtain the encrypted data. Because the third party cannot know the key generation rules for generating the first encryption key based on the multiple key parameters, they cannot decrypt the encrypted data. This ensures that the terminal's decryption capability is not generalized, thus controlling not only "who can obtain the access link" but also "who can truly understand the plaintext data." Furthermore, compared to the simple "signature URL + access validity" technology, the data storage scheme provided in this application extends plaintext data access control to the content control level.

[0127] Please refer to Figure 9 This illustrates a structural block diagram of a data storage device provided in an exemplary embodiment of this application. The device includes: The first sending module 901 is used to send a storage request to the server, the storage request carrying plaintext data; The first receiving module 902 is used to receive a storage response sent by the server. The storage response carries multiple key parameters and an access link for ciphertext data. The ciphertext data is obtained by the server encrypting the plaintext data based on a first encryption key, which is generated by the server based on the multiple key parameters. The acquisition module 903 is configured to, in response to the access link being clicked, acquire the encrypted data from the server based on the access link; The first generation module 904 is used to generate the first encryption key based on the plurality of key parameters; The first decryption module 905 is used to decrypt the ciphertext data based on the first encryption key to obtain the plaintext data.

[0128] In one possible implementation, the plurality of key parameters include at least one first key parameter and at least one second key parameter, wherein the at least one first key parameter is randomly generated and the at least one second key parameter is used to uniquely identify the plaintext data.

[0129] In another possible implementation, the at least one first key parameter includes a randomly generated first string, and the at least one second key parameter includes a data identifier of the plaintext data; The first generation module 904 is used to extract a first number of characters from the first string to obtain a second string; determine the hash value of the data identifier and extract a second number of characters from the hash value to obtain a third string; and concatenate the second string and the third string to obtain the first encryption key.

[0130] In another possible implementation, the storage response also carries an initialization vector for the plaintext data, and the plaintext data is obtained by the server encrypting the plaintext data based on the first encryption key and the initialization vector; The first decryption module 905 is used to decrypt the ciphertext data based on the first encryption key and the initialization vector to obtain the plaintext data.

[0131] In another possible implementation, the first sending module 901 is used to encrypt the storage request to obtain an encrypted storage request; send the encrypted storage request to the gateway, so that the gateway decrypts the encrypted storage request and forwards the storage request to the server.

[0132] In this embodiment, when the terminal stores plaintext data in the server, the server returns an access link for the encrypted data and multiple key parameters to the terminal. The terminal generates a first encryption key based on the multiple key parameters and according to an agreed key generation rule. Then, when the terminal requests access to the plaintext data, the server returns the encrypted data to the terminal, allowing the terminal to decrypt the encrypted data based on the first encryption key to obtain the plaintext data. This establishes a "server controls the key, terminal controls the display" implementation path, further improving the security of the plaintext data.

[0133] It should be noted that the data storage device provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the terminal can be divided into different functional modules to complete all or part of the functions described above. In addition, the data storage device and data storage method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the device embodiments, which will not be repeated here.

[0134] Please refer to Figure 10 This illustrates a structural block diagram of a data storage device provided in an exemplary embodiment of this application. The device includes: The second receiving module 1001 is used to receive a storage request from the terminal, wherein the storage request carries plaintext data; The second generation module 1002 is used to generate a first encryption key for the plaintext data based on multiple key parameters of the plaintext data. Storage module 1003 is used to encrypt the plaintext data based on the first encryption key and store the ciphertext data; The third generation module 1004 is used to generate an access link for the encrypted data; The second sending module 1005 is used to send a storage response to the terminal, the storage response carrying the access link and the plurality of key parameters.

[0135] In one possible implementation, the device further includes: The storage module 1003 is further configured to encrypt the plurality of key parameters using the second encryption key of the key management service, and store the encrypted plurality of key parameters. The device further includes: The second decryption module is used to decrypt the stored encrypted multiple key parameters based on the second encryption key.

[0136] In another possible implementation, the storage module 1003 is configured to store the ciphertext data in a first storage space when the sensitivity level of the plaintext data is higher than a level threshold, wherein the sensitivity level is used to characterize the sensitivity of the plaintext data; and to store the ciphertext data in a second storage space when the sensitivity level of the plaintext data is lower than or equal to the level threshold, wherein the access permission level of the first storage space is higher than the access permission level of the second storage space.

[0137] In another possible implementation, the third generation module 1004 is configured to, when the encrypted data is stored in the first storage space, encrypt the first storage path and expiration time based on a third encryption key to obtain a first access link for the encrypted data, wherein the first storage path is the storage path of the encrypted data in the first storage space; and when the encrypted data is stored in the second storage space, generate a second access link for the encrypted data based on a second storage path, wherein the second storage path is the storage path of the encrypted data in the second storage space.

[0138] It should be noted that the data storage device provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the server can be divided into different functional modules to complete all or part of the functions described above. In addition, the data storage device and data storage method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the device embodiments, which will not be repeated here.

[0139] See Figure 11 , Figure 11 This is a schematic diagram of the structure of a terminal provided in an exemplary embodiment of this application. The terminal may also include one or more of the following components: processor 1110, memory 1120, and display screen 1130.

[0140] The processor 1110 connects various parts within the terminal 1100 via various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1120, and by calling data stored in the memory 1120. Optionally, the processor 1110 can be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1110 can integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and modem. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required to be displayed on the display screen 1130; the NPU is used to implement Artificial Intelligence (AI) functions; and the modem is used for wireless communication. It is understandable that the aforementioned modem may not be integrated into the processor 1110, but may be implemented separately through a computer program product.

[0141] The memory 1120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1120 may include a non-transitory computer-readable storage medium. The memory 1120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described below, etc.; the data storage area may store data (such as audio data, phone book, etc.) created according to the use of the terminal 1100.

[0142] Display screen 1130 is a display component used to display a user interface. Optionally, the display screen 1130 is a touch-enabled display screen, through which users can use their fingers, styluses, or any suitable object to perform touch operations on the display screen 1130.

[0143] The display screen 1130 is typically located on the front panel of the terminal 1100. The display screen 1130 can be designed as a full-screen, curved screen, irregularly shaped screen, dual-sided screen, or foldable screen. The display screen 1130 can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen, etc., but this embodiment does not limit it in this way.

[0144] In addition, those skilled in the art will understand that the structure of the terminal 1100 shown in the above figures does not constitute a limitation on the terminal 1100. The terminal 1100 may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the terminal 1100 may also include a Wireless Fidelity (WiFi) module, an audio acquisition device, a speaker, a radio frequency circuit, an input unit, a sensor, an audio circuit, a Bluetooth module, a power supply, and other components, which will not be described in detail here.

[0145] See Figure 12 , Figure 12 This is a schematic diagram of the server structure provided in an exemplary embodiment of this application. The server 1200 can vary considerably depending on its configuration or performance, and may include one or more Central Processing Units (CPUs) 1201 and one or more memories 1202. The memories 1202 store at least one hop of computer instructions, which are executed by the processor 1201 to implement the data storage methods provided in the various method embodiments described above. Of course, the server 1200 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input / output. The server 1200 may also include other components for implementing device functions, which will not be elaborated upon here.

[0146] This application provides a chip that includes programmable logic circuits and / or program instructions. When the chip is running on a terminal device, it is used to implement the data storage method described in the above embodiments.

[0147] This application provides a computer-readable storage medium storing at least one computer instruction, which is executed by a processor to implement the data storage method as described in the above embodiments.

[0148] On the other hand, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the data storage method as described in the above embodiments.

[0149] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0150] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A data storage method, characterized in that, The method includes: Send a storage request to the server, the storage request carrying plaintext data; The server receives a storage response, which carries multiple key parameters and an access link for encrypted data. The encrypted data is obtained by the server encrypting the plaintext data based on a first encryption key, which is generated by the server based on the multiple key parameters. In response to the access link being clicked, the encrypted data is retrieved from the server based on the access link; Based on the multiple key parameters, a first encryption key is generated, and the ciphertext data is decrypted based on the first encryption key to obtain the plaintext data.

2. The method according to claim 1, characterized in that, The plurality of key parameters include at least one first key parameter and at least one second key parameter, wherein the at least one first key parameter is generated randomly, and the at least one second key parameter is used to uniquely identify the plaintext data.

3. The method according to claim 2, characterized in that, The at least one first key parameter includes a randomly generated first string, and the at least one second key parameter includes a data identifier of the plaintext data; The step of generating the first encryption key based on the plurality of key parameters includes: Extract a first number of characters from the first string to obtain the second string; Determine the hash value of the data identifier, and extract a second number of strings from the hash value to obtain a third string; By concatenating the second string and the third string, the first encryption key is obtained.

4. The method according to claim 1, characterized in that, The storage response also carries an initialization vector for the plaintext data, and the ciphertext data is obtained by the server encrypting the plaintext data based on the first encryption key and the initialization vector; The step of decrypting the ciphertext data based on the first encryption key to obtain the plaintext data includes: Based on the first encryption key and the initialization vector, the ciphertext data is decrypted to obtain the plaintext data.

5. The method according to any one of claims 1-4, characterized in that, Sending a storage request to the server includes: Encrypt the storage request to obtain the encrypted storage request; The encrypted storage request is sent to the gateway, which then decrypts the encrypted storage request and forwards it to the server.

6. A data storage method, characterized in that, The method includes: The terminal receives a storage request, the storage request carrying plaintext data; Based on multiple key parameters of the plaintext data, a first encryption key for the plaintext data is generated; The plaintext data is encrypted using the first encryption key, and the ciphertext data is stored. An access link to the encrypted data is generated, and a storage response is sent to the terminal, the storage response carrying the access link and the plurality of key parameters.

7. The method according to claim 6, characterized in that, The method further includes: The multiple key parameters are encrypted using the second encryption key from the key management service, and the encrypted multiple key parameters are stored. The method further includes: The stored encrypted key parameters are decrypted based on the second encryption key.

8. The method according to claim 6 or 7, characterized in that, The stored encrypted data includes: If the sensitivity level of the plaintext data is higher than the sensitivity threshold, the ciphertext data is stored in the first storage space, whereby the sensitivity level is used to characterize the sensitivity of the plaintext data. If the sensitivity level of the plaintext data is lower than or equal to the sensitivity threshold, the ciphertext data is stored in a second storage space, where the access permission level of the first storage space is higher than that of the second storage space.

9. The method according to claim 8, characterized in that, The access link that generates the encrypted data includes: When the encrypted data is stored in the first storage space, the first storage path and expiration time are encrypted based on the third encryption key to obtain the first access link of the encrypted data, wherein the first storage path is the storage path of the encrypted data in the first storage space. When the encrypted data is stored in the second storage space, a second access link for the encrypted data is generated based on the second storage path, where the second storage path is the storage path of the encrypted data in the second storage space.

10. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium; a processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions to implement the data storage method as described in any one of claims 1 to 9.

Images