Cloud platform multi-organization data synchronization method and system

By dynamically determining the encryption strength and permission level through differentiated encryption strategies, and combining the association mapping between access permissions and keys, the problem of balancing security and performance in data synchronization among multiple organizations is solved, achieving fine-grained access control and ensuring data security and compliance.

CN122348951APending Publication Date: 2026-07-07江苏元素生物科技有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610678955.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-05-18
Publication Date
2026-07-07

AI Technical Summary

Technical Problem

Existing technologies for data synchronization between multiple organizations suffer from problems such as mismatch of security resources due to coarse-grained encryption strategies and insufficient fine-grained access control. They cannot achieve an optimal balance between security and system performance, and the loose coupling between permission verification and data decryption processes poses a risk of excessive data exposure.

Method used

By extracting the attribute identifiers and access permission information of sensitive data, the encryption strength and permission level are dynamically determined. Differentiated encryption strategies are adopted, and access permissions are associated with key information to build a fine-grained permission-key mapping relationship. This enables the binding of decryption capabilities with access permissions and strictly controls the scope of data access.

Benefits of technology

It achieves secure synchronization and controllable access in multi-organizational environments, avoids the performance bottleneck caused by single high-strength encryption, prevents the security risks of low-strength encryption, ensures the confidentiality and compliance of data transmission and storage, and reduces the risk of data leakage and abuse.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122348951A_ABST
    Figure CN122348951A_ABST
Patent Text Reader

Abstract

The present application relates to the technical field of cloud computing data security, and more particularly to a cloud platform multi-organization data synchronization method and system. The method determines the sensitivity level of sensitive data by extracting the data attribute identifier of the sensitive data, and accordingly selects the encryption strength for encryption to generate encrypted data and a key. The access rights are associated with the key and stored. The encrypted data is stored to the target cloud platform, and when a user requests access, the rights are verified and the corresponding key is obtained, the data is decrypted and the access range is controlled according to the rights, and the result is returned. The present application realizes dynamic encryption according to data sensitivity and fine-grained permission control, and improves the security and accuracy of cross-organization data synchronization.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of cloud computing data security technology, and in particular to a method and system for synchronizing data across multiple organizations on a cloud platform. Background Technology

[0002] In the field of cloud computing, data sharing and synchronization among multiple organizations has become a key technology supporting business collaboration. Especially when multiple independent entities or departments share a single cloud platform, how to securely and efficiently synchronize data containing sensitive information is a core challenge in current technological practices. Common solutions rely on uniform encryption before data transmission and pushing the encrypted data along with corresponding access control policies to the target cloud storage system.

[0003] Existing practices typically employ static or predefined encryption strategies to handle all sensitive data to be synchronized. Specifically, the system uses the same encryption algorithm and key strength for all data marked as "sensitive," without further distinguishing between differences in the sensitivity levels within the data. After encryption, the data is transmitted to the cloud, and access control is implemented through the cloud platform's own identity and access management module. This module determines whether to allow users to access decrypted or stored plaintext data based on pre-defined user roles and permission rules within the system.

[0004] This conventional approach has significant limitations. A major drawback lies in its coarse-grained security handling. Applying uniform encryption strength to all sensitive data can lead to a misallocation of security resources. For highly sensitive data, insufficient encryption strength may pose potential risks; while for less sensitive data, excessively high encryption strength can result in unnecessary computational overhead and performance degradation, impacting the overall efficiency of data synchronization and access. This "one-size-fits-all" strategy fails to achieve an optimal balance between security and system performance.

[0005] Another drawback lies in the insufficient coupling between access control and the data decryption process. In existing solutions, the processes of authorization verification and obtaining decryption keys are often separate or loosely coupled. After a user passes authorization verification, the system typically provides direct access to decrypted or plaintext data, lacking the ability to fine-grained control based on specific, real-time access permissions during the decryption process. This can lead to the generalization of permissions, meaning that once a user gains access to a certain type of data, they can access all information under that data item, making it impossible to achieve differentiated access based on the sensitivity of different content within the same data item, and posing a risk of excessive data exposure. Summary of the Invention

[0006] This invention provides a method and system for synchronizing data across multiple organizations on a cloud platform, which can solve the problems in the prior art.

[0007] A first aspect of the present invention provides a method for synchronizing data across multiple organizations on a cloud platform, comprising: The process involves acquiring sensitive data to be synchronized, extracting its data attribute identifier and associated access permission information, determining its sensitivity level based on the data attribute identifier, selecting a corresponding encryption strength parameter based on the sensitivity level, and encrypting the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The access permission information and the key information are associated and mapped to generate an access permission-key mapping relationship, and the access permission-key mapping relationship is stored in the access permission management module; The encrypted data is transmitted to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permissions corresponding to the identity identifier are verified through the permission management module. Based on the verified access permissions, the key information corresponding to the access permissions is obtained from the permission-key mapping relationship. The encrypted data stored in the target cloud platform is decrypted using the key information, and the access scope of the decrypted sensitive data is controlled according to the access permissions. A data response result that conforms to the access permissions is generated and returned to the user.

[0008] The sensitivity level of the sensitive data is determined based on the data attribute identifier, and a corresponding encryption strength parameter is selected based on the sensitivity level, including: The data type marker, data source marker, and data purpose marker in the data attribute identifier are parsed, the semantic feature vector of each marker is extracted, a multi-dimensional attribute feature matrix is ​​generated, multi-level feature extraction and feature fusion calculation are performed on the multi-dimensional attribute feature matrix, and an initial sensitivity score is output. The system obtains historical access frequency, number of data relationships, and complexity of data flow paths for sensitive data, constructs a dynamic risk factor set, weights and corrects the initial sensitivity score based on the dynamic risk factor set, calculates the comprehensive sensitivity score, and maps the comprehensive sensitivity score to high sensitivity, medium sensitivity, or low sensitivity levels according to a preset score interval threshold. For high sensitivity levels, a first encryption strength parameter is selected that includes parameters for asymmetric encryption key length, encryption rounds, and key derivation iterations. For medium sensitivity levels, a second encryption strength parameter is selected that includes a symmetric encryption key length parameter and an initialization vector generation complexity parameter; For low sensitivity levels, select a third encryption strength parameter that includes the base key length parameter.

[0009] The sensitive data is encrypted using an encryption algorithm that matches the encryption strength parameter, generating encrypted data and corresponding key information, including: Based on the encryption strength parameter, a corresponding encryption algorithm is selected from a preset multi-level encryption algorithm library. The encryption algorithms in the encryption algorithm library are stored hierarchically according to key length and encryption complexity. The encryption strength parameter has a mapping relationship with the key length and encryption complexity of the encryption algorithm. The sensitive data is encrypted using the selected encryption algorithm to generate encrypted data. During the encryption process, key information corresponding to the encryption algorithm is generated. The key information is associated with and stored with the encrypted data. The key information contains metadata that identifies the encryption algorithm type and the encryption strength parameter. The value of the encryption strength parameter is positively correlated with the sensitivity level of the sensitive data. The key length of the encryption algorithm increases with the increase of the encryption strength parameter.

[0010] Associating the access permission information with the key information to generate an access permission-key mapping relationship, and storing the access permission-key mapping relationship in the access permission management module, including: Extract the authorized user's identity, corresponding permission level, and permission scope from the access permission information to generate a permission feature vector. Decompose the key information into multiple key fragments using a secret sharing algorithm, with each key fragment corresponding to a different recovery threshold and access conditions. A multi-level key access hierarchy is established based on permission levels, and key fragments are allocated to different access levels according to the hierarchy. Higher permission levels can access key fragments of lower permission levels. For each authorized user's identity, calculate the key fragment combinations that the user can access based on their permission level and permission scope, and generate a user-specific key fragment access list; Establish a hash mapping index between authorized user identity identifiers and key fragment access lists, generate a permission-key mapping table, and embed permission grant time, permission expiration time, and permission change audit chain into the permission-key mapping table to form a permission-key mapping relationship that includes time and audit dimensions; The permission-key mapping relationship is homomorphically encrypted to generate encrypted mapping relationship data that supports permission verification in ciphertext state, and the encrypted mapping relationship data is stored in the secure storage area of ​​the permission management module.

[0011] When a user's data access request is received, the user's identity identifier is obtained, and the access permissions corresponding to the identity identifier are verified through the permission management module. Based on the verified access permissions, the key information corresponding to the access permissions is obtained from the permission-key mapping relationship, including: Extract the user's identity, access credentials, and request context information from the data access request. The request context information includes the access time, access source address, and access device fingerprint. The identity identifier and access credential information are transmitted to the access control module, which then queries the access permission records and historical access behavior records corresponding to the identity identifier. Multi-factor authentication is performed on the access credential information to verify the validity of the digital signature, the cryptographic binding relationship between the access credential information and the identity identifier, and the timeliness of the access credential information. Check the access permission record for permission validity period, permission freeze status, and permission usage limit to determine if the current access time is within the permission validity period, the permission is not frozen, and the usage limit has not been exceeded. If the multi-factor authentication and permission status check pass, then the access permission verification corresponding to the identity identifier is confirmed to be successful. Generate a verification result credential containing a verification pass identifier, verification timestamp, and access permission details. Return the verification result credential for subsequent key information acquisition and data decryption processing, and record this verification process in the access audit log.

[0012] Access to decrypted sensitive data is controlled based on access permissions, generating a data response result that conforms to the access permissions, including: The system parses the permission levels, field-level access control lists, and row-level access control policies in the access permissions. It extracts data pattern information from the decrypted sensitive data, matches the data pattern information with the field-level access control lists, and filters out the set of data fields that the user is authorized to access. Based on the conditional expressions in the row-level access control policy, each row of sensitive data is evaluated to determine whether it meets the access conditions. A set of indexes of data rows that meet the row-level access conditions is generated. Based on the set of data fields and the set of data row indexes, the intersection of the data is extracted from the decrypted sensitive data to generate a preliminary filtered subset of data. Based on the de-identification rules configured in the permission level, identify sensitive fields that need to be de-identified in the initially filtered data subset. For fields with different levels of sensitivity, use de-identification methods such as mask replacement, data generalization, or data distortion to generate a de-identified data subset. Then, inject a watermark identifier into the de-identified data subset. The watermark identifier contains the user's identity identifier and access timestamp. The data subset with the injected watermark is encapsulated into a data response result that conforms to the access permissions, and access permission summary information and data integrity verification value are appended to the metadata of the data response result before being returned to the user.

[0013] A second aspect of the present invention provides a cloud platform multi-organization data synchronization system, comprising: An encryption processing unit is used to acquire sensitive data to be synchronized, extract the data attribute identifier and associated access permission information of the sensitive data, determine the sensitivity level of the sensitive data according to the data attribute identifier, select the corresponding encryption strength parameter based on the sensitivity level, and encrypt the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The permission mapping unit is used to associate and map the access permission information with the key information to generate a permission-key mapping relationship, and store the permission-key mapping relationship in the permission management module; The access verification unit is used to transmit the encrypted data to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permission corresponding to the identity identifier is verified through the permission management module. Based on the verified access permission, the key information corresponding to the access permission is obtained from the permission-key mapping relationship. The data response unit is used to decrypt the encrypted data stored in the target cloud platform using the key information, control the access scope of the decrypted sensitive data according to the access permissions, and generate a data response result that conforms to the access permissions and return it to the user.

[0014] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0015] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0016] This method enables secure synchronization and controlled access to sensitive data across multiple organizations on a cloud platform. By extracting the data attribute identifiers of sensitive data and determining its sensitivity level, appropriate encryption strength parameters and algorithms can be matched for different levels of sensitive data, thus achieving a balance between security and processing efficiency during the data encryption phase. This differentiated encryption strategy avoids the performance bottlenecks caused by single high-strength encryption and prevents the security risks that may arise from low-strength encryption, ensuring the confidentiality of data during transmission and storage.

[0017] By associating and centrally managing access permission information with encryption keys, a fine-grained permission-key mapping relationship is established. This design directly binds data access permissions to decryption capabilities, making permission verification a necessary prerequisite for obtaining the decryption key. When a user initiates an access request, the system retrieves and obtains the matching key by verifying the access permissions corresponding to their identity identifier, thus eliminating the possibility of unauthorized access and decryption operations at the source and strengthening the core position of access control.

[0018] During the data usage phase, the system uses the acquired key to decrypt the encrypted data stored on the target cloud platform and strictly controls the access scope of the decrypted sensitive data based on verified access permissions. This process ensures that users can only access and manipulate data content within their authorized scope, ultimately generating and returning data response results that conform to their permissions. The entire process achieves closed-loop security management from data encryption and permission binding to decryption and access, effectively maintaining data privacy and compliance while ensuring the data synchronization and sharing needs among multiple organizations, and reducing the risk of data leakage and misuse. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a method for synchronizing data across multiple organizations on a cloud platform. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0022] Figure 1 This is a flowchart illustrating the multi-organization data synchronization method for a cloud platform according to an embodiment of the present invention. Figure 1 As shown, the methods for multi-organization data synchronization on cloud platforms include: The process involves acquiring sensitive data to be synchronized, extracting its data attribute identifier and associated access permission information, determining its sensitivity level based on the data attribute identifier, selecting a corresponding encryption strength parameter based on the sensitivity level, and encrypting the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The access permission information and the key information are associated and mapped to generate an access permission-key mapping relationship, and the access permission-key mapping relationship is stored in the access permission management module; The encrypted data is transmitted to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permissions corresponding to the identity identifier are verified through the permission management module. Based on the verified access permissions, the key information corresponding to the access permissions is obtained from the permission-key mapping relationship. The encrypted data stored in the target cloud platform is decrypted using the key information, and the access scope of the decrypted sensitive data is controlled according to the access permissions. A data response result that conforms to the access permissions is generated and returned to the user.

[0023] The sensitivity level of the sensitive data is determined based on the data attribute identifier, and a corresponding encryption strength parameter is selected based on the sensitivity level, including: The data type marker, data source marker, and data purpose marker in the data attribute identifier are parsed, the semantic feature vector of each marker is extracted, a multi-dimensional attribute feature matrix is ​​generated, multi-level feature extraction and feature fusion calculation are performed on the multi-dimensional attribute feature matrix, and an initial sensitivity score is output. The system obtains historical access frequency, number of data relationships, and complexity of data flow paths for sensitive data, constructs a dynamic risk factor set, weights and corrects the initial sensitivity score based on the dynamic risk factor set, calculates the comprehensive sensitivity score, and maps the comprehensive sensitivity score to high sensitivity, medium sensitivity, or low sensitivity levels according to a preset score interval threshold. For high sensitivity levels, a first encryption strength parameter is selected that includes parameters for asymmetric encryption key length, encryption rounds, and key derivation iterations. For medium sensitivity levels, a second encryption strength parameter is selected that includes a symmetric encryption key length parameter and an initialization vector generation complexity parameter; For low sensitivity levels, select a third encryption strength parameter that includes the base key length parameter.

[0024] The process of determining the sensitivity level of sensitive data involves identifying core characteristic elements by parsing the data attribute identifiers after acquiring the sensitive data to be synchronized. Data attribute identifiers typically consist of multi-dimensional tagging information, including data type tags, data source tags, and data usage tags. Data type tags identify the specific type of data, such as personal identification information, financial data, medical records, and trade secrets; data source tags record the data's origin, which may be generated by an internal system, obtained through an external interface, or imported from a third party; data usage tags describe the actual application scenario of the data, such as for different purposes like business analysis, report generation, or decision support. When parsing these tags, natural language processing technology is used to perform semantic analysis on each tag, converting the text-based tags into computable numerical vectors. For data type tags, semantic feature vectors are formed by extracting features such as category, sensitivity, and privacy relevance; for data source tags, features such as source credibility, data flow, and transmission link are extracted; and for data usage tags, features such as usage frequency, scope of personnel involved, and business criticality are extracted.

[0025] The extracted semantic feature vectors of each tag are organized according to a unified dimensional specification to construct a multidimensional attribute feature matrix. The rows of this matrix correspond to different types of tags, the columns correspond to the feature dimensions of each tag, and the matrix elements are specific feature values. To extract effective sensitivity information from the multidimensional attribute feature matrix, a multi-layer feature extraction mechanism is used for in-depth analysis of the matrix. In the first layer of feature extraction, local feature aggregation is performed on the feature vectors of each row to capture the feature correlation within a single tag dimension. In the second layer of feature extraction, cross-dimensional feature interaction is performed on the feature vectors of different rows to identify the mutual influence relationships between different tags. In the third layer of feature extraction, a global feature convergence operation is used to integrate the local features and interaction features of all dimensions.

[0026] The feature fusion calculation process employs a weighted fusion strategy, assigning different weight coefficients based on the importance of different labels to the sensitivity assessment. The weight coefficient for data type labels is typically set to 0.5, for data source labels to 0.3, and for data usage labels to 0.2. After applying nonlinear transformations and normalization to the weighted features, an initial sensitivity score is output. This score typically ranges from 0 to 100 as a floating-point number.

[0027] To more accurately reflect the risk profile of sensitive data during actual use, dynamic risk factors need to be introduced to correct the initial sensitivity score. The historical access frequency of sensitive data is obtained by querying data access logs, and the total number of times the data is accessed within a certain time window is counted. A higher access frequency indicates a greater risk of data exposure. The number of data relationships is determined by analyzing data dependency graphs, counting the number of other data entities that are directly or indirectly related to the current sensitive data. A greater number of relationships indicates a wider potential cascading impact from a data breach.

[0028] Data flow path complexity is calculated by tracking the flow of data across different systems, modules, and organizations. Factors such as the number of nodes involved in the flow path, the number of cross-domain operations, and the number of transit links all affect the complexity score. Higher complexity indicates more security risks during data transmission. A dynamic risk factor set is constructed by considering three indicators: historical access frequency, number of data relationships, and data flow path complexity. Each risk factor is then normalized to a value range of 0 to 1.

[0029] When weighting and correcting the initial sensitivity score based on a dynamic set of risk factors, the risk weight for access frequency is set to 0.4, the risk weight for the number of relationships is set to 0.35, and the risk weight for the complexity of the flow path is set to 0.25. The comprehensive risk adjustment coefficient is obtained by summing the results of multiplying each risk factor by its corresponding weight. This coefficient reflects the incremental impact of dynamic risks on sensitivity. The comprehensive sensitivity score is calculated by multiplying the initial sensitivity score by the comprehensive risk adjustment coefficient and then taking a weighted average with the initial score. Specifically, the calculation of the comprehensive sensitivity score considers both static attribute characteristics and dynamic operational risks, preserving the inherent sensitivity of the data while incorporating risk changes in actual usage scenarios.

[0030] Based on pre-defined scoring interval thresholds, the overall sensitivity score is mapped to a specific sensitivity level. The scoring interval thresholds are typically determined based on statistical analysis of extensive historical data and industry security standards. For example, data with an overall sensitivity score between 75 and 100 is classified as highly sensitive, data between 40 and 75 as moderately sensitive, and data between 0 and 40 as low sensitive. High-sensitivity data typically involves core trade secrets, sensitive personal privacy information, or data types strictly protected by laws and regulations; moderately sensitive data may contain information related to business operations but not directly involving core secrets; and low-sensitivity data is routine business data that is either highly public or of low sensitivity.

[0031] For different sensitivity levels, corresponding encryption strength parameters are selected to match data protection requirements. For highly sensitive data, asymmetric encryption algorithms are used to provide stronger security. The first encryption strength parameter includes the asymmetric encryption key length parameter, encryption round parameter, and key derivation iteration number parameter. The asymmetric encryption key length parameter is usually set to 2048 bits or 4096 bits; the longer the key length, the greater the difficulty of cracking and the higher the security. The encryption round parameter specifies the number of iterations in the data encryption process. For highly sensitive data, it can be set to 3 or more rounds, with each round using a different key pair or transformation algorithm, forming multiple layers of encryption protection. The key derivation iteration number parameter is used to generate the derived key used for actual encryption from the master key. A large number of hash iteration operations increase the computational complexity of key derivation; the iteration number can be set to over 10,000 times, effectively resisting brute-force attacks.

[0032] For moderately sensitive data, symmetric encryption algorithms are used to ensure both security and encryption efficiency. The second encryption strength parameter includes the symmetric encryption key length parameter and the initialization vector generation complexity parameter. The symmetric encryption key length parameter is typically set to 256 bits, meeting current mainstream security standards. The initialization vector generation complexity parameter determines the randomness and unpredictability of the initialization vector. By introducing a hardware random number generator or combining it with a hybrid algorithm incorporating multiple elements such as timestamps and system states, a different initialization vector is ensured for each encryption operation, enhancing the randomness and resistance to analysis of the ciphertext.

[0033] For low-sensitivity data, a basic encryption scheme is used to optimize performance while meeting basic security requirements. The third encryption strength parameter includes the basic key length parameter. The basic key length parameter can be set to 128 bits, which is sufficiently secure in most application scenarios. Furthermore, the computational overhead for encryption and decryption is relatively low, making it suitable for the rapid processing of large batches of low-sensitivity data. This tiered encryption strength parameter selection strategy ensures appropriate protection for data of different sensitivity levels while avoiding the waste of computational resources and performance degradation caused by applying uniform high-strength encryption to all data.

[0034] The sensitive data is encrypted using an encryption algorithm that matches the encryption strength parameter, generating encrypted data and corresponding key information, including: Based on the encryption strength parameter, a corresponding encryption algorithm is selected from a preset multi-level encryption algorithm library. The encryption algorithms in the encryption algorithm library are stored hierarchically according to key length and encryption complexity. The encryption strength parameter has a mapping relationship with the key length and encryption complexity of the encryption algorithm. The sensitive data is encrypted using the selected encryption algorithm to generate encrypted data. During the encryption process, key information corresponding to the encryption algorithm is generated. The key information is associated with and stored with the encrypted data. The key information contains metadata that identifies the encryption algorithm type and the encryption strength parameter. The value of the encryption strength parameter is positively correlated with the sensitivity level of the sensitive data. The key length of the encryption algorithm increases with the increase of the encryption strength parameter.

[0035] When encrypting sensitive data, the first step is to select a suitable encryption algorithm from a pre-defined multi-level encryption algorithm library based on a defined encryption strength parameter. This library employs a hierarchical storage architecture, classifying encryption algorithms of different security levels according to their key length and encryption complexity. Specifically, the library is divided into three security levels: low, medium, and high, each corresponding to a different key length range and algorithm complexity. For example, a low security level corresponds to the 128-bit AES algorithm, a medium security level to the 256-bit AES-GCM algorithm, and a high security level to RSA-4096 or higher-strength asymmetric encryption algorithms. A precise mapping relationship is established between the encryption strength parameter and the encryption algorithm. This mapping relationship is maintained through a configuration table, which records the value range of the encryption strength parameter corresponding to different sensitivity levels and the recommended encryption algorithm types.

[0036] When the sensitivity level of sensitive data is determined to be high, the corresponding encryption strength parameter will be increased. At this point, the system will automatically select algorithms with longer key lengths and higher encryption complexity from the encryption algorithm library. Increasing the key length directly increases the difficulty of brute-force attacks, while increasing encryption complexity enhances the algorithm's ability to resist cryptanalysis attacks. The selection process is implemented through an algorithm scoring mechanism. The system calculates the target security score based on the encryption strength parameter, then searches the encryption algorithm library for algorithms with scores not lower than the target value, prioritizing algorithms with the closest scores and relatively lower performance overhead to achieve a balance between security and processing efficiency.

[0037] After selecting an encryption algorithm, it is used to encrypt sensitive data. The encryption process includes data segmentation, padding, encryption operations, and integrity verification. For large datasets, the sensitive data is first segmented according to the block size required by the encryption algorithm. If the last data block is insufficient, the PKCS7 padding scheme is used to pad it to the full block length. After segmentation, the core operations of the encryption algorithm are performed on each data block sequentially. Symmetric encryption algorithms use key derivation functions to generate subkeys for each round from the master key, and convert plaintext into ciphertext through multiple rounds of substitution and permutation operations. Asymmetric encryption algorithms use the public key to encrypt the data, ensuring encryption strength through mathematical problems. After the encryption operations are completed, the ciphertext of each data block is concatenated in its original order to form complete encrypted data.

[0038] During encryption, the system generates key information corresponding to the encryption operation. For symmetric encryption algorithms, the key information includes the randomly generated symmetric key itself and random numbers used for initialization vectors. For asymmetric encryption algorithms, the key information includes a public key and a private key pair, where the public key is used for encryption and the private key is used for decryption; the private key requires additional security protection. The key generation process uses a cryptographically secure pseudo-random number generator to ensure sufficient randomness and unpredictability of the key. The generated key length strictly adheres to the encryption strength parameter requirements. For example, when the encryption strength parameter indicates a 256-bit security strength is required, the symmetric key length is set to 256 bits, while the asymmetric key length is set to at least 3072 bits to achieve an equivalent security strength.

[0039] The generated key information is explicitly associated with the encrypted data. Specifically, a unique data identifier is assigned to each encrypted data item, and this identifier is simultaneously associated with the corresponding key information record. The key information is stored in a separate key management service, physically isolated from the storage location of the encrypted data, thus avoiding the risk of simultaneous leakage of the key and ciphertext. In the data structure of the key management service, each key information record includes basic fields such as data identifier, key value, key generation time, and key validity period, as well as metadata fields containing algorithm type and encryption strength parameters.

[0040] Metadata within the key information plays a crucial identifying role. This metadata is stored in a structured format and includes information such as the algorithm type identifier, encryption strength parameter value, key length, and algorithm version number. The algorithm type identifier follows standard algorithm naming conventions; for example, "AES-256-GCM" explicitly indicates the use of the AES algorithm with a 256-bit key length and GCM authentication encryption mode. The encryption strength parameter is recorded numerically, reflecting the security level of the encryption operation. Its value can be defined as an integer from 1 to 10, where 1 represents the lowest strength and 10 represents the highest strength. The key length field records the actual number of key bits used, facilitating verification of key integrity during decryption. The algorithm version number identifies the specific implementation version of the encryption algorithm, supporting compatibility management after algorithm upgrades.

[0041] A positive correlation is established between the encryption strength parameter and the sensitivity level of the sensitive data. When sensitive data is assessed as having a higher sensitivity level, the corresponding encryption strength parameter value increases accordingly. This positive correlation is achieved through a mapping function; for example, data with a sensitivity level of 1 corresponds to an encryption strength parameter of 2, data with a sensitivity level of 2 corresponds to an encryption strength parameter of 4, data with a sensitivity level of 3 corresponds to an encryption strength parameter of 7, and data with a sensitivity level of 4 corresponds to an encryption strength parameter of 10. This mapping relationship ensures that highly sensitive data receives stronger encryption protection, while less sensitive data uses a relatively lightweight encryption scheme to improve processing efficiency.

[0042] The key length of encryption algorithms increases with the increase of the encryption strength parameter. In practical applications, when the encryption strength parameter is low, the system chooses encryption algorithms with key lengths of 128 bits or 192 bits. These algorithms can meet general security requirements and have low computational overhead. When the encryption strength parameter is increased to a medium level, the key length increases to 256 bits, and the corresponding encryption algorithm uses more encryption rounds and more complex key expansion schemes. When the encryption strength parameter reaches a high value, the system may choose asymmetric encryption algorithms or adopt hybrid encryption schemes, extending the key length to 2048 bits, 3072 bits, or even 4096 bits, providing higher security guarantees through the computational complexity of large number operations.

[0043] In practical deployments, the encryption algorithm library needs to be updated regularly to address emerging cryptanalysis methods. When a security vulnerability is discovered in an encryption algorithm, the system can quickly remove it from the library or downgrade it, and automatically trigger a re-encryption process for the affected data. Simultaneously, the key rotation operation for encrypted data also relies on metadata within the key information. The system determines whether a key update is needed based on the key generation time and a preset rotation cycle. During the update process, the new key is used to re-encrypt the data, and the key information record is updated to ensure the continued security of long-term stored data.

[0044] The entire encryption process also includes an integrity protection mechanism. While generating encrypted data, the hash value or message authentication code of the encrypted data is calculated, and this verification value is stored as part of the metadata in the key information. When the encrypted data is subsequently decrypted, the verification value is first recalculated and compared with the stored verification value to verify that the encrypted data has not been tampered with during storage and transmission. This combination of integrity protection and encryption protection constitutes a multi-layered protection system for data security, effectively resisting security threats such as data theft and unauthorized modification.

[0045] Associating the access permission information with the key information to generate an access permission-key mapping relationship, and storing the access permission-key mapping relationship in the access permission management module, including: Extract the authorized user's identity, corresponding permission level, and permission scope from the access permission information to generate a permission feature vector. Decompose the key information into multiple key fragments using a secret sharing algorithm, with each key fragment corresponding to a different recovery threshold and access conditions. A multi-level key access hierarchy is established based on permission levels, and key fragments are allocated to different access levels according to the hierarchy. Higher permission levels can access key fragments of lower permission levels. For each authorized user's identity, calculate the key fragment combinations that the user can access based on their permission level and permission scope, and generate a user-specific key fragment access list; Establish a hash mapping index between authorized user identity identifiers and key fragment access lists, generate a permission-key mapping table, and embed permission grant time, permission expiration time, and permission change audit chain into the permission-key mapping table to form a permission-key mapping relationship that includes time and audit dimensions; The permission-key mapping relationship is homomorphically encrypted to generate encrypted mapping relationship data that supports permission verification in ciphertext state, and the encrypted mapping relationship data is stored in the secure storage area of ​​the permission management module.

[0046] In the process of associating and mapping access permission information with key information, the access permission information first needs to be structured and parsed. Access permission information typically contains multiple dimensions of control elements. The authorized user identifier uniquely identifies the user entity with data access qualifications; this identifier can be in the form of a user ID, organization code, or role identifier. The permission level quantifies the degree of a user's access to data, usually divided into different levels such as read-only, edit, and administration, with different permission levels corresponding to different data operation scopes. The permission scope defines the applicable boundaries of user permissions, including multiple constraints such as data range restrictions, time range restrictions, and operation type restrictions.

[0047] By extracting and integrating these permission elements, a permission feature vector is constructed, comprising user identifier, permission level, and scope of application dimensions. This permission feature vector uses numerical encoding to map each dimension of information into coordinate points in a vector space, facilitating subsequent permission matching and verification operations.

[0048] In the key information processing stage, a secret sharing algorithm is used to decompose the complete key information. Based on the Lagrange interpolation principle, the secret sharing algorithm uses the original key as a constant term in a polynomial, generating n key fragments by constructing an (n-1)th degree polynomial with a threshold of m. Each key fragment alone cannot recover the original key information; only when at least m key fragments are collected can the complete key be reconstructed using the polynomial interpolation algorithm. During fragment generation, different recovery threshold parameters are set for each key fragment. Key fragments with high security requirements require the cooperation of more other fragments to complete the recovery operation. Simultaneously, access constraints are attached to each key fragment, including multi-dimensional constraints such as the lower limit of the access user's permission level, access time window, and access source restrictions. Access conditions are stored and bound to the key fragments in the form of policy expressions. When a key fragment is invoked, the access conditions are first verified to ensure they are met.

[0049] A multi-level key access hierarchy is established based on different permission levels, forming a tree-like topology. In this structure, permission levels are divided into several access tiers from highest to lowest. The highest tier corresponds to system administrator privileges, the lowest tier to ordinary read-only privileges, and intermediate tiers to different levels of editing and review privileges. Key fragments are assigned to the corresponding access tier nodes according to their data sensitivity and operation permission requirements. The hierarchy follows the principle of permission inheritance, meaning that a user with higher-level permissions can access key fragment resources at their own tier and all tiers below them. For example, if a user has second-level editing privileges, this user can access key fragments assigned at the second tier, as well as key fragments at the third and fourth tiers, but cannot access first-tier administrative key fragments. This hierarchical design ensures permission flexibility while avoiding the risk of lower-privilege users accessing highly sensitive data without authorization.

[0050] For each authorized user identity, a personalized key fragment access list generation process is executed. This process first reads the user's permission level parameters and determines the user's accessible levels based on the multi-level key access hierarchy. Then, it extracts the user's permission scope parameters and filters out a set of key fragments whose scope matches the user's permissions. During the filtering process, only key fragments that simultaneously meet the hierarchical access condition and the scope matching condition are included in the candidate set. Next, the required key fragment combination scheme for the user is calculated. Depending on the needs of different data access scenarios, a user may require the collaboration of multiple key fragments to complete the decryption operation of specific data. The key fragment combination scheme records the key fragment identifiers required for each access scenario and their acquisition order in list form. The final generated user-specific key fragment access list contains complete information such as the key fragment identifier sequence, the acquisition conditions for each fragment, the fragment combination rules, and the access priority order.

[0051] When establishing the mapping relationship between authorized user identifiers and key-sharded access lists, a hash index mechanism is used to achieve fast lookup. The user identifier is taken as input, and a hash value is calculated using a hash function. This hash value points to the specific storage location where the user's key-sharded access list is stored. The hash mapping index uses a chained addressing method to handle hash collisions. When multiple user identifiers calculate the same hash value, the access lists of these users are linked together and stored as a linked list. The permission-key mapping table organizes data in a two-dimensional table structure. The row index corresponds to the hash value of the user identifier, and the column fields contain information such as the user's complete identifier, key-sharded access list, permission level identifier, and scope description.

[0052] Based on the permission-key mapping table, control information with time and audit dimensions is embedded. The permission grant time field records the precise moment the mapping relationship was established, stored in timestamp format with second-level precision. The permission expiration time field defines the effective expiration time of the mapping relationship; when the system time exceeds the expiration time, the mapping relationship automatically expires, and users can no longer obtain key shards through this mapping relationship. The permission change audit chain records all change history of this mapping relationship in a blockchain structure. Each permission level adjustment, scope modification, or key shard redistribution operation generates a new block record in the audit chain. Each block in the audit chain contains a change timestamp, change operation type, a comparison of the state before and after the change, and the identity of the administrator who performed the change operation. Multiple blocks are connected by hash pointers to form an immutable audit trail. Time-dimensional control enables periodic rotation of permissions and temporary authorization management, while audit-dimensional control enables full traceability and compliance verification of permission changes.

[0053] To ensure the security of the permission-key mapping relationship during storage and transmission, homomorphic encryption is applied to this mapping relationship. Homomorphic encryption algorithms allow permission verification operations to be performed directly in the encrypted state without first decrypting the mapping relationship data. The adopted homomorphic encryption scheme supports additive and multiplicative homomorphic operations, enabling verification operations such as permission level comparison, scope matching, and key fragment combination calculation in the encrypted state. During encryption, sensitive fields in the permission-key mapping relationship are homomorphically encrypted one by one, including the user identity ciphertext, the key fragment access list ciphertext, and the permission control parameter ciphertext. The generated encrypted mapping relationship data maintains the original index structure and query interface. The permission verification module can directly perform query operations on the encrypted mapping relationship data, complete permission matching judgment through homomorphic operations, and only after successful verification is the corresponding key fragment information decrypted and returned to the requester.

[0054] The encrypted mapping relationship data is stored in the secure storage area of ​​the access control module, which employs multiple security protection mechanisms. At the physical level, the storage area uses an access control list to allow only authorized system components to access the storage space. At the logical level, the storage content is fragmented, distributing the complete encrypted mapping relationship data across multiple independent storage nodes. Each storage node only stores a portion of the data fragment, ensuring that even if a single node is compromised, the complete mapping relationship information cannot be obtained. The storage area is also configured with a real-time monitoring mechanism that logs all access operations, including access time, access subject, access data range, and operation type. Abnormal access behavior triggers alarms and automatically executes access blocking measures.

[0055] When a user's data access request is received, the user's identity identifier is obtained, and the access permissions corresponding to the identity identifier are verified through the permission management module. Based on the verified access permissions, the key information corresponding to the access permissions is obtained from the permission-key mapping relationship, including: Extract the user's identity, access credentials, and request context information from the data access request. The request context information includes the access time, access source address, and access device fingerprint. The identity identifier and access credential information are transmitted to the access control module, which then queries the access permission records and historical access behavior records corresponding to the identity identifier. Multi-factor authentication is performed on the access credential information to verify the validity of the digital signature, the cryptographic binding relationship between the access credential information and the identity identifier, and the timeliness of the access credential information. Check the access permission record for permission validity period, permission freeze status, and permission usage limit to determine if the current access time is within the permission validity period, the permission is not frozen, and the usage limit has not been exceeded. If the multi-factor authentication and permission status check pass, then the access permission verification corresponding to the identity identifier is confirmed to be successful. Generate a verification result credential containing a verification pass identifier, verification timestamp, and access permission details. Return the verification result credential for subsequent key information acquisition and data decryption processing, and record this verification process in the access audit log.

[0056] Upon receiving a user-initiated data access request, the first step is to extract all key verification elements from the request. Data access requests are typically encapsulated using HTTP or HTTPS protocols, carrying an identity field in the request header. This field may be a JSO6 Web Token, an OAuth 2.0 token, or a custom user identifier. Access credentials can be digital certificates, encrypted tokens, or dynamically generated credentials based on multi-factor authentication. These credentials are signed and protected during transmission to prevent tampering. Extracting request context information involves multiple dimensions. The access time is obtained by parsing the timestamp field of the request message. This timestamp is recorded in UTC standard time format, accurate to the millisecond level for fine-grained time validity verification. The access source address includes the IP address, geographic location information, and network operator information, extracted by parsing the network layer and transport layer information of the request message. The access device fingerprint is a unique identifier generated by hashing multiple parameters such as the user device's hardware characteristics, operating system version, browser type, list of installed plugins, and screen resolution. This fingerprint information is established and stored in the user device's local storage during the first access, and subsequent access requests will carry this fingerprint information for device consistency verification.

[0057] The extracted identity and access credential information is transmitted to the access control module via a secure channel. The secure channel uses the TLS 1.3 protocol to establish an encrypted connection, ensuring that data is not eavesdropped on or tampered with during transmission. Upon receiving the verification request, the access control module immediately performs a query operation in the access permission database, quickly locating the access permission record corresponding to the identity through an indexing mechanism. Access permission records are stored in a structured manner, including a permission type field indicating the user's read, modify, or delete permissions, and a permission scope field limiting the range of data objects the user can access, down to specific data fields or rows. Historical access behavior records are stored in a separate log database, containing the user's past access time series, access frequency statistics, abnormal access markers, and permission usage pattern characteristics. Analyzing historical access behavior records can identify potential account theft, such as sudden access times occurring during periods when the user is typically inactive, or unreasonable jumps in the access source address across geographical locations within a short period.

[0058] Multi-factor authentication of access credentials is a crucial step in ensuring access security. First, the validity of the digital signature on the access credential is verified. The digital signature is generated using either the RSA algorithm or the elliptic curve digital signature algorithm. During verification, the signature field is extracted from the credential, and the signature is decrypted and verified using a pre-stored public key to confirm that the hash value of the signature matches the credential content. Simultaneously, the integrity of the certificate chain used for the signature must be checked, ensuring it has not been revoked. The current validity of the certificate is confirmed by querying the certificate revocation list or using an online certificate status protocol service.

[0059] The cryptographic binding verification of access credentials and identity identifiers ensures that the credential truly belongs to that identity. This verification process involves hashing the identity information embedded in the credential and comparing it with the hash value of that identity stored in the database. A collision-resistant hash algorithm, such as SHA-256, is used to ensure the binding cannot be forged. Timeliness verification is achieved by comparing the issuance and expiration times of the credential with the current system time. Credentials typically have a short validity period, such as 1 hour to 24 hours, after which a new access credential must be applied for. Timeliness verification also needs to consider clock skew, allowing for a certain range of time errors, such as a tolerance window of 5 minutes before or after the expiration date.

[0060] The access permission record contains several key status control fields that need to be checked one by one. The permission validity period field defines the start and end times of the access permission and is stored in timestamp format. During verification, the current access time is extracted and compared with the start and end times of the permission validity period. Only if the current time falls within the validity period range is the time condition considered met. The permission freeze status field is a Boolean flag. When this field is true, it indicates that the permission has been temporarily frozen by the administrator, possibly due to detected abnormal access behavior or the user actively requesting a temporary account lockout.

[0061] The freeze status check is mandatory; any permission in a frozen state will fail verification. Permission usage limits are used to control the frequency of access to certain sensitive operations. For example, a user's access to specific sensitive data must not exceed 10 times within 24 hours. Verification queries the number of times the permission has been used within the current time window using an access counter. This counter employs atomic operations to ensure accuracy in concurrent access scenarios. If the current usage count has not reached the limit threshold, the count check passes, and the counter is incremented by 1 to record this access.

[0062] When all items in the multi-factor authentication pass and all conditions in the permission status check are met, the access permission verification corresponding to the identity is confirmed as successful. Upon successful verification, a verification result credential containing detailed verification information is immediately generated. The successful verification identifier is represented by a unique verification session ID, which is generated using a UUID algorithm to ensure global uniqueness. The verification timestamp records the precise moment the verification was completed, using a high-precision clock source to ensure time accuracy at the nanosecond level. This timestamp will be used for subsequent audit traceability and to determine the timeliness of the verification results.

[0063] Access permission details are stored in a structured format using JSO6 or XML, including a list of specific executable operations for the user, a set of accessible data object identifiers, access control rules at the data field level, and filtering conditions at the data row level. Verification credentials are digitally signed after generation, using the private key of the access control module to ensure the credentials are not tampered with during transmission and use.

[0064] The verification result credential is returned to the next stage of the data access control process to guide subsequent key information retrieval operations. During the key information retrieval stage, the access permission details contained in the verification result credential determine which key information the user is authorized to access. The permission-key mapping table establishes a many-to-many mapping relationship based on the granularity of access permissions. A single access permission may correspond to multiple keys for data with different sensitivity levels, and a single key may be shared by multiple user groups with corresponding permissions. By querying the mapping table for records matching the verified access permissions, the corresponding key identifier is extracted, and then the actual key data is retrieved from the key storage system based on the key identifier. The key data itself undergoes secondary encryption protection, using the master key stored in the hardware security module to encapsulate the user data encryption key. After obtaining the encapsulated key data, the decapsulation interface of the hardware security module must be called to obtain the key that can be used for data decryption.

[0065] Detailed information generated throughout the verification process must be fully recorded in the access audit log. The audit log is stored in an append-only manner to ensure its immutability. Each audit log entry includes a unique identifier for the access request, user identity, access time, access source address, access device fingerprint, execution results of each stage of the verification process, reason codes for successful or failed verification, a list of obtained key identifiers, and information on the scope of data access. The audit log uses a structured storage format to facilitate subsequent log analysis and security auditing, supporting rapid retrieval by time range, user identity, access results, and other dimensions. Before being written to the storage system, the log entries are protected by a hash chain; the hash value of each new log entry depends on the hash value of the previous log entry, forming a blockchain-like tamper-proof structure. Any modification to historical logs will break the hash chain and be detected. Audit logs are periodically archived to a long-term storage system, with the retention period determined according to data compliance requirements, typically 3 to 7 years. Archived logs are stored on read-only storage media and backed up off-site.

[0066] Access to decrypted sensitive data is controlled based on access permissions, generating a data response result that conforms to the access permissions, including: The system parses the permission levels, field-level access control lists, and row-level access control policies in the access permissions. It extracts data pattern information from the decrypted sensitive data, matches the data pattern information with the field-level access control lists, and filters out the set of data fields that the user is authorized to access. Based on the conditional expressions in the row-level access control policy, each row of sensitive data is evaluated to determine whether it meets the access conditions. A set of indexes of data rows that meet the row-level access conditions is generated. Based on the set of data fields and the set of data row indexes, the intersection of the data is extracted from the decrypted sensitive data to generate a preliminary filtered subset of data. Based on the de-identification rules configured in the permission level, identify sensitive fields that need to be de-identified in the initially filtered data subset. For fields with different levels of sensitivity, use de-identification methods such as mask replacement, data generalization, or data distortion to generate a de-identified data subset. Then, inject a watermark identifier into the de-identified data subset. The watermark identifier contains the user's identity identifier and access timestamp. The data subset with the injected watermark is encapsulated into a data response result that conforms to the access permissions, and access permission summary information and data integrity verification value are appended to the metadata of the data response result before being returned to the user.

[0067] After a user's data access request is authenticated and the decrypted sensitive data is successfully obtained, fine-grained access control of the decrypted data is required to ensure that users can only access data content within their authorized scope. This involves parsing the permission levels within the access permissions. Permission levels define the user's role hierarchy within the organizational structure, such as senior management, department heads, and ordinary employees. Different permission levels correspond to different depths and breadths of data access. Simultaneously, field-level access control lists are extracted. These lists, in whitelist or blacklist format, explicitly specify the specific data fields that users can or cannot access. For example, in an employee information table, some users may only be authorized to access the name and department fields, but not the salary and ID number fields. Further analysis of row-level access control policies is needed. These policies define the visibility rules for data rows through conditional expressions. These expressions may include multi-dimensional filtering conditions such as the data's department, creation time range, and data status. For example, sales department users may only be able to view customer records created within their department.

[0068] Data pattern information is extracted from the decrypted sensitive data, including metadata structure information such as field names, field types, and field positions in the data tables. This extracted data pattern information is then matched against field-level access control lists, determining whether each data field falls within the user's authorized access range through a field-by-field comparison. For whitelist-based access control, only fields appearing in the whitelist are retained; for blacklist-based access control, explicitly prohibited fields are excluded. The matching process considers field inheritance relationships and nested structures. For example, for complex data objects in JSO6 format, nested fields need to be recursively parsed and their permissions matched separately. After the matching calculation is complete, a set of data fields that the user is authorized to access is selected. This set contains the names of all fields that have passed permission verification and their indexes in the original data structure.

[0069] Based on the conditional expressions in the row-level access control policy, sensitive data rows are evaluated row by row. The conditional expressions use logical operators to connect multiple conditions, such as `department` equal to "R&D Department" and `create_time` greater than a specific date, or `data_owner` equal to the current user's identifier. For each row, the field values ​​related to the conditional expression are extracted and substituted into the expression for logical operations. For complex combinations of multiple conditions, the results of operations such as A6D, OR, and 6OT are calculated sequentially according to their priority. Each row is then checked to see if it meets the access conditions. If all conditions for a row are true, the row meets the user's access permissions; otherwise, it is excluded. A set of indexes for data rows that meet the row-level access conditions is generated. This set records the row number or unique identifier of all data rows that have passed row-level permission verification in the original dataset.

[0070] Based on the data field set and data row index set, the intersection of the data is extracted from the decrypted sensitive data. A two-dimensional data filtering operation is performed: columns are filtered horizontally according to the data field set, and rows are filtered vertically according to the data row index set. The data subspace formed by the intersection of these two methods represents the actual data range accessible to the user. The original structure and relationships of the data are preserved during the extraction process to ensure that the extracted data subset is logically complete and usable. A preliminary filtered data subset is generated, which has undergone dual permission filtering at both the field and row levels, but the sensitive information within it still exists in plaintext.

[0071] Based on the de-identification rules configured in the permission levels, sensitive fields requiring de-identification are identified in the initially filtered data subset. The de-identification rule configuration defines the de-identification intensity corresponding to fields of different sensitivity levels. For example, high-sensitivity fields require complete masking, medium-sensitivity fields use partial masking, and low-sensitivity fields may only require data generalization. Appropriate de-identification methods are applied to fields of different sensitivity levels. For highly sensitive fields such as ID card numbers and mobile phone numbers, a mask replacement method is used, replacing several characters in the middle with asterisks or other placeholders. For example: The string "110101199001011234" is processed into "110101******1234", retaining the first six and last four digits to maintain partial data recognizability. For numerically sensitive fields such as age and income, a data generalization method is used to convert precise values ​​into range representations. For example, the specific age 28 is generalized to the "25-30 years old" age group, and the monthly income of 15,000 yuan is generalized to the "10,000-20,000 yuan" income range. For semi-sensitive fields such as addresses and email addresses, a data distortion method is used to obfuscate the original information by adding random noise or reducing data precision. For example, detailed street addresses are simplified to district / county-level administrative regions, and some characters in the username portion of complete email addresses are replaced. A de-identified subset of data is generated to ensure that sensitive information is protected to the greatest extent possible while meeting user business needs.

[0072] Watermarks are injected into the anonymized subset of data, serving as a crucial technique for data traceability and leak detection. Each watermark contains a user identifier, uniquely corresponding to the data accessor. This identifier can be represented by a hash value of a user ID, employee ID, or other unique identifier, avoiding plaintext exposure of user information. Simultaneously, the watermark includes an access timestamp, precisely recording the exact moment the data was accessed and exported. The timestamp uses the UTC standard time format, achieving precision down to the second or millisecond level. The watermark injection employs invisible watermarking technology, embedding the identifier information into the data content without affecting normal data usage. For example, for text data, watermarks can be embedded through zero-width character insertion or synonym replacement; for numerical data, a small perturbation can be introduced into the least significant bit to encode the watermark information. The watermark information is encrypted before embedding to prevent malicious users from removing the watermark through reverse engineering.

[0073] A subset of data with injected watermarks is encapsulated into a data response result that conforms to access permissions. Access permission summary information is appended to the metadata of the data response result. This summary information describes the permission rules followed for this data access in a structured format, including key information such as the application's field-level control lists, row-level filtering conditions, and the scope of de-identification processing, facilitating auditing and traceability. A data integrity check value is calculated by hashing the content of the data response result using a message digest algorithm. After receiving the data, the user can recalculate the hash value and compare it with the appended check value to verify that the data has not been tampered with during transmission. The encapsulated data response result is returned to the user through a secure communication channel, completing the entire access scope control process. Simultaneously with the data return, a detailed log of this data access is recorded, including the accessing user, access time, accessed data scope, and application permission policy, and stored in the audit log system for subsequent security auditing.

[0074] A second aspect of the present invention provides a cloud platform multi-organization data synchronization system, comprising: An encryption processing unit is used to acquire sensitive data to be synchronized, extract the data attribute identifier and associated access permission information of the sensitive data, determine the sensitivity level of the sensitive data according to the data attribute identifier, select the corresponding encryption strength parameter based on the sensitivity level, and encrypt the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The permission mapping unit is used to associate and map the access permission information with the key information to generate a permission-key mapping relationship, and store the permission-key mapping relationship in the permission management module; The access verification unit is used to transmit the encrypted data to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permission corresponding to the identity identifier is verified through the permission management module. Based on the verified access permission, the key information corresponding to the access permission is obtained from the permission-key mapping relationship. The data response unit is used to decrypt the encrypted data stored in the target cloud platform using the key information, control the access scope of the decrypted sensitive data according to the access permissions, and generate a data response result that conforms to the access permissions and return it to the user.

[0075] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0076] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0077] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for synchronizing data across multiple organizations on a cloud platform, characterized in that: include: The process involves acquiring sensitive data to be synchronized, extracting its data attribute identifier and associated access permission information, determining its sensitivity level based on the data attribute identifier, selecting a corresponding encryption strength parameter based on the sensitivity level, and encrypting the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The access permission information and the key information are associated and mapped to generate an access permission-key mapping relationship, and the access permission-key mapping relationship is stored in the access permission management module; The encrypted data is transmitted to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permissions corresponding to the identity identifier are verified through the permission management module. Based on the verified access permissions, the key information corresponding to the access permissions is obtained from the permission-key mapping relationship. The encrypted data stored in the target cloud platform is decrypted using the key information, and the access scope of the decrypted sensitive data is controlled according to the access permissions. A data response result that conforms to the access permissions is generated and returned to the user.

2. The method according to claim 1, characterized in that... The sensitivity level of the sensitive data is determined based on the data attribute identifier, and a corresponding encryption strength parameter is selected based on the sensitivity level, including: The data type marker, data source marker, and data purpose marker in the data attribute identifier are parsed, the semantic feature vector of each marker is extracted, a multi-dimensional attribute feature matrix is ​​generated, multi-level feature extraction and feature fusion calculation are performed on the multi-dimensional attribute feature matrix, and an initial sensitivity score is output. The system obtains historical access frequency, number of data relationships, and complexity of data flow paths for sensitive data, constructs a dynamic risk factor set, weights and corrects the initial sensitivity score based on the dynamic risk factor set, calculates the comprehensive sensitivity score, and maps the comprehensive sensitivity score to high sensitivity, medium sensitivity, or low sensitivity levels according to a preset score interval threshold. For high sensitivity levels, a first encryption strength parameter is selected that includes parameters for asymmetric encryption key length, encryption rounds, and key derivation iterations. For medium sensitivity levels, a second encryption strength parameter is selected that includes a symmetric encryption key length parameter and an initialization vector generation complexity parameter; For low sensitivity levels, select a third encryption strength parameter that includes the base key length parameter.

3. The method according to claim 2, characterized in that, The sensitive data is encrypted using an encryption algorithm that matches the encryption strength parameter, generating encrypted data and corresponding key information, including: Based on the encryption strength parameter, a corresponding encryption algorithm is selected from a preset multi-level encryption algorithm library. The encryption algorithms in the encryption algorithm library are stored hierarchically according to key length and encryption complexity. The encryption strength parameter has a mapping relationship with the key length and encryption complexity of the encryption algorithm. The sensitive data is encrypted using the selected encryption algorithm to generate encrypted data. During the encryption process, key information corresponding to the encryption algorithm is generated. The key information is associated with and stored with the encrypted data. The key information contains metadata that identifies the encryption algorithm type and the encryption strength parameter. The value of the encryption strength parameter is positively correlated with the sensitivity level of the sensitive data. The key length of the encryption algorithm increases with the increase of the encryption strength parameter.

4. The method according to claim 1, characterized in that... The access permission information is associated and mapped with the key information to generate an access permission-key mapping relationship, and the access permission-key mapping relationship is stored in the access permission management module, including: Extract the authorized user's identity, corresponding permission level, and permission scope from the access permission information to generate a permission feature vector. Decompose the key information into multiple key fragments using a secret sharing algorithm, with each key fragment corresponding to a different recovery threshold and access conditions. A multi-level key access hierarchy is established based on permission levels, and key fragments are allocated to different access levels according to the hierarchy. Higher permission levels can access key fragments of lower permission levels. For each authorized user's identity, calculate the key fragment combinations that the user can access based on their permission level and permission scope, and generate a user-specific key fragment access list; Establish a hash mapping index between authorized user identity identifiers and key fragment access lists, generate a permission-key mapping table, and embed permission grant time, permission expiration time, and permission change audit chain into the permission-key mapping table to form a permission-key mapping relationship that includes time and audit dimensions; The permission-key mapping relationship is homomorphically encrypted to generate encrypted mapping relationship data that supports permission verification in ciphertext state, and the encrypted mapping relationship data is stored in the secure storage area of ​​the permission management module.

5. The method according to claim 1, characterized in that... When a user's data access request is received, the system obtains the user's identity identifier and verifies the access permissions corresponding to the identity identifier through the permission management module. Based on the verified access permissions, the system retrieves the key information corresponding to the access permissions from the permission-key mapping relationship, including: Extract the user's identity, access credentials, and request context information from the data access request. The request context information includes the access time, access source address, and access device fingerprint. The identity identifier and access credential information are transmitted to the access control module, which then queries the access permission records and historical access behavior records corresponding to the identity identifier. Multi-factor authentication is performed on the access credential information to verify the validity of the digital signature, the cryptographic binding relationship between the access credential information and the identity identifier, and the timeliness of the access credential information. Check the access permission record for permission validity period, permission freeze status, and permission usage limit to determine if the current access time is within the permission validity period, the permission is not frozen, and the usage limit has not been exceeded. If the multi-factor authentication and permission status check pass, then the access permission verification corresponding to the identity identifier is confirmed to be successful. Generate a verification result credential containing a verification pass identifier, verification timestamp, and access permission details. Return the verification result credential for subsequent key information acquisition and data decryption processing, and record this verification process in the access audit log.

6. The method according to claim 1, characterized in that... Access to decrypted sensitive data is controlled based on access permissions, and a data response result conforming to the access permissions is generated, including: The system parses the permission levels, field-level access control lists, and row-level access control policies in the access permissions. It extracts data pattern information from the decrypted sensitive data, matches the data pattern information with the field-level access control lists, and filters out the set of data fields that the user is authorized to access. Based on the conditional expressions in the row-level access control policy, each row of sensitive data is evaluated to determine whether it meets the access conditions. A set of indexes of data rows that meet the row-level access conditions is generated. Based on the set of data fields and the set of data row indexes, the intersection of the data is extracted from the decrypted sensitive data to generate a preliminary filtered subset of data. Based on the de-identification rules configured in the permission level, identify sensitive fields that need to be de-identified in the initially filtered data subset. For fields with different levels of sensitivity, use de-identification methods such as mask replacement, data generalization, or data distortion to generate a de-identified data subset. Then, inject a watermark identifier into the de-identified data subset. The watermark identifier contains the user's identity identifier and access timestamp. The data subset with the injected watermark is encapsulated into a data response result that conforms to the access permissions, and access permission summary information and data integrity verification value are appended to the metadata of the data response result before being returned to the user.

7. A cloud platform multi-organization data synchronization system, used to implement the method as described in any one of claims 1-6, characterized in that, include: An encryption processing unit is used to acquire sensitive data to be synchronized, extract the data attribute identifier and associated access permission information of the sensitive data, determine the sensitivity level of the sensitive data according to the data attribute identifier, select the corresponding encryption strength parameter based on the sensitivity level, and encrypt the sensitive data using an encryption algorithm that matches the encryption strength parameter to generate encrypted data and corresponding key information. The permission mapping unit is used to associate and map the access permission information with the key information to generate a permission-key mapping relationship, and store the permission-key mapping relationship in the permission management module; The access verification unit is used to transmit the encrypted data to the target cloud platform for storage. When a user's data access request is received, the user's identity identifier is obtained, and the access permission corresponding to the identity identifier is verified through the permission management module. Based on the verified access permission, the key information corresponding to the access permission is obtained from the permission-key mapping relationship. The data response unit is used to decrypt the encrypted data stored in the target cloud platform using the key information, control the access scope of the decrypted sensitive data according to the access permissions, and generate a data response result that conforms to the access permissions and return it to the user.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.