A data isolation method and system for multi-tenant platform

Abstract

The application provides a multi-tenant platform-oriented data isolation method and system, relates to the technical field of data processing, and comprises the following steps: obtaining historical tenant data and to-be-isolated tenant data in a multi-tenant platform; dynamically determining a data isolation strategy mode according to data attributes of the historical tenant data and the to-be-isolated tenant data; constructing a tenant data mixing relationship graph according to the historical tenant data, the to-be-isolated tenant data and the data isolation strategy mode, and calculating a data mixing risk index; performing data isolation branch processing according to the data mixing risk index to obtain a data isolation branch processing scheme; performing data migration, repartitioning and replica synchronization processing according to the scheme to obtain a data isolation execution result; calculating a data residual diffusion coefficient according to the data isolation execution result, and combining the data mixing risk index to judge whether the data isolation requirement is met; if yes, outputting a data isolation result, otherwise, feeding back and adjusting the data isolation strategy mode and the data isolation branch processing flow.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a data isolation method and system for multi-tenant platforms. Background Technology

[0002] With the rapid development of cloud computing, SaaS services, and enterprise-level platform systems, multi-tenant platforms are widely used in government administration, enterprise services, industrial internet, data middleware, and business collaboration systems. Multi-tenant platforms typically provide independent business services to multiple tenants within the same set of hardware and software resources, the same application instance, or the same database system.

[0003] In existing technologies, multi-tenant platforms typically employ methods such as independent databases, independent data tables, shared data tables with tenant identifier fields, access control lists, role-based access control, interface authentication, and data query condition filtering to achieve data isolation. Among these, independent databases or independent data tables can distinguish data from different tenants at the physical or logical level, making them suitable for scenarios with high isolation requirements. The shared data table with tenant identifier fields achieves logical isolation of different tenant data by adding tenant numbers to business data and attaching tenant filtering conditions to query, update, and delete operations. Access control lists and role-based access control primarily restrict the range of data that users can access by binding relationships between user identity, roles, organizational relationships, and resource permissions, thereby reducing the risk of unauthorized access.

[0004] However, existing methods often rely on fixed table structures, tenant identifier filtering, or static access control, making it difficult to dynamically adjust isolation strategies based on tenant data attributes, sharing relationships, and isolation boundaries. This can easily lead to cross-tenant data mixing risks in complex business scenarios. At the same time, existing methods typically lack quantitative evaluation and feedback adjustment mechanisms for isolation execution results, making it difficult to detect data residue and diffusion risks after data migration, repartitioning, or copy synchronization in a timely manner, thus affecting the security and reliability of data isolation. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a data isolation method and system for multi-tenant platforms. This method can solve the problems of existing methods relying on fixed table structures, tenant identifier filtering, or static permission control, which makes it difficult to dynamically adjust isolation strategies according to tenant data attributes, sharing relationships, and isolation boundaries. This leads to the risk of cross-tenant data mixing in complex business scenarios. At the same time, existing methods usually lack quantitative evaluation and feedback adjustment mechanisms for isolation execution results, making it difficult to detect data residue and diffusion risks after data migration, repartitioning, or copy synchronization in a timely manner, thus affecting the security and reliability of data isolation.

[0006] A first aspect of this invention provides a data isolation method for multi-tenant platforms, comprising: S1: Obtain historical tenant data and tenant data to be isolated from the multi-tenant platform; S2: Dynamically determine the data isolation strategy mode corresponding to the tenant data to be isolated based on the data attributes of the historical tenant data and the tenant data to be isolated; S3: Based on the historical tenant data, the tenant data to be isolated, and the data isolation strategy mode, construct a tenant data mixing relationship diagram between the tenant data to be isolated and the existing tenant data in the multi-tenant platform; S4: Based on the tenant data mixing relationship diagram, and combined with the consistency between the actual data sharing relationship and the isolation boundary, calculate the data mixing risk index; S5: Based on the data mixing risk index, perform data isolation branch processing on the tenant data to be isolated to obtain a data isolation branch processing scheme; S6: According to the data isolation branch processing scheme, perform data migration, repartitioning and replica synchronization processing on the tenant data to be isolated to obtain the data isolation execution result; S7: Calculate the data residual diffusion coefficient based on the data isolation execution results; S8: Based on the data residual diffusion coefficient and the data mixing risk index, determine whether the data isolation execution result meets the data isolation requirements; if yes, output the data isolation result; otherwise, adjust the data isolation strategy mode and data isolation branch processing flow accordingly.

[0007] A second aspect of this invention provides a data isolation system for multi-tenant platforms, comprising: a processor and a memory; The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of a data isolation method for a multi-tenant platform as described in the first aspect.

[0008] A third aspect of the present invention provides a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the data isolation method for multi-tenant platforms as described in the first aspect.

[0009] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: In this embodiment of the invention, by acquiring historical tenant data and tenant data to be isolated, and combining data attributes, the isolation strategy mode is dynamically determined. A tenant data mixing relationship diagram is constructed, and a data mixing risk index is calculated. This allows for the dynamic generation of data isolation branch processing schemes based on cross-tenant data sharing relationships and isolation boundaries, improving the dynamic adaptability to complex business scenarios and reducing the risk of data mixing and isolation failure due to fixed isolation strategies. Simultaneously, data migration, repartitioning, and replica synchronization are performed according to the branch processing scheme. By calculating the data residue diffusion coefficient, the isolation execution results are quantitatively judged and feedback adjusted, enhancing the verifiability and closed-loop optimization capabilities of the isolation results. This reduces security risks caused by data residue after isolation, historical replica diffusion, and isolation boundary failure, thereby improving the security and reliability of data isolation on multi-tenant platforms. Attached Figure Description

[0010] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0011] Figure 1 This is a flowchart illustrating a data isolation method for multi-tenant platforms provided in an embodiment of the present invention.

[0012] Figure 2 This is a schematic diagram of the structure of a data isolation system for a multi-tenant platform provided in an embodiment of the present invention. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions 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, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] The following description, in conjunction with the accompanying drawings, details a data isolation method for multi-tenant platforms provided by the present invention through specific embodiments and application scenarios.

[0015] Reference manual attached Figure 1 The diagram illustrates a flowchart of a data isolation method for multi-tenant platforms provided by an embodiment of the present invention.

[0016] This invention provides a data isolation method for multi-tenant platforms, which may include the following steps: S1: Obtain historical tenant data and tenant data to be isolated from the multi-tenant platform.

[0017] Specifically, historical tenant data corresponding to existing tenants in the multi-tenant platform is read from the database management module, object storage management module, access control module, log auditing module, and tenant configuration module. This historical tenant data includes the tenant's identifier, data storage location, database instance, schema, data tables, data partitions, object storage bucket, object storage prefix, access role, encryption key, backup location, access logs, and audit logs. Simultaneously, the data of tenants currently requiring isolation is obtained.

[0018] S2: Dynamically determine the data isolation strategy mode corresponding to the data of the tenant to be isolated based on the data attributes of historical tenant data and the data of the tenant to be isolated.

[0019] In one possible implementation, S2 specifically includes: S201: Based on historical tenant data, establish a set of candidate data isolation strategy patterns.

[0020] The candidate data isolation strategy set includes shared database shared schema mode, shared database independent schema mode, multi-database multi-tenant mode, independent database mode, object storage prefix isolation mode, and object storage bucket isolation mode.

[0021] Specifically, the storage structure and isolation methods in historical tenant data can be statistically analyzed to identify the database sharing method, schema partitioning method, data table or partition isolation method, object storage path partitioning method, access control method, and key management method used by existing tenants. Then, these existing isolation methods are mapped to the platform's pre-supported standard isolation modes to form a set of candidate data isolation strategy modes. For example, when multiple tenants share the same database and schema in historical tenant data, the shared database shared schema mode is added to the set; when different schemas exist within the same database, the shared database independent schema mode is added to the set; and when independent databases, independent buckets, or object storage paths are partitioned by prefix are present, the corresponding modes are added to the candidate set respectively.

[0022] S202: Determine the strategy selection parameters based on the data attributes of the tenant data to be isolated.

[0023] Optionally, data attributes include data sensitivity level, compliance constraint level, data type, access frequency, degree of cross-tenant sharing, tenant-defined isolation requirements, and degree of resource fluctuation.

[0024] Furthermore, based on data attributes, the isolation requirement matching parameters, storage type matching parameters, policy execution parameters, and management cost parameters for the tenant data to be isolated relative to each candidate data isolation strategy mode are determined. Specifically, the isolation requirement matching parameters are determined based on the data sensitivity level, compliance constraint level, cross-tenant sharing degree, and tenant-defined isolation requirements of the tenant data to be isolated. If the isolation strength of a candidate mode can meet the above isolation requirements, a higher value is taken; if a candidate mode allows more dimensions to be shared and has a higher data sensitivity level, a lower value is taken. The storage type matching parameters are determined based on the data type and actual storage form of the tenant data to be isolated. For example, relational data is more suitable for database, schema, or partition isolation modes, while object file data is more suitable for object storage prefix isolation mode or bucket isolation mode. The policy execution parameters are determined based on the existing storage structure in historical tenant data, the platform's current resource reserves, migration difficulty, routing modification difficulty, and permission adjustment difficulty. If the platform already supports the isolation mode and the migration modification is small, a higher value is taken. The management cost parameter is determined based on the number of database instances, schemas, buckets, keys, backup tasks, and audit and maintenance complexity corresponding to the candidate patterns. The lower the management cost, the higher this parameter value. This approach allows each candidate data isolation strategy pattern to form a set of comparable strategy selection parameters, facilitating subsequent calculation of strategy matching values.

[0025] S203: Based on the strategy selection parameters, calculate the strategy matching value of the tenant data to be isolated relative to each candidate data isolation strategy mode.

[0026] Optionally, a strategy matching value is calculated based on the isolation requirement matching parameters, storage type matching parameters, strategy executable parameters, and management cost parameters between the tenant data to be isolated and each candidate data isolation strategy mode. Specifically, the strategy matching value is obtained by weighted summation of the four parameters.

[0027] S204: Determine the data isolation strategy mode corresponding to the tenant data to be isolated based on the strategy matching value.

[0028] Optionally, the strategy matching values ​​of the tenant data to be isolated relative to each candidate data isolation strategy mode are compared, and the candidate data isolation strategy mode with the highest strategy matching value is determined as the data isolation strategy mode corresponding to the tenant data to be isolated.

[0029] In this embodiment of the invention, through the above steps, the appropriate data isolation strategy mode can be dynamically selected based on the actual storage structure of historical tenant data and the data attributes of the tenant data to be isolated, avoiding resource waste or insufficient isolation caused by all tenants adopting a fixed isolation method, thereby improving the accuracy and adaptability of the multi-tenant platform data isolation strategy configuration.

[0030] S3: Based on historical tenant data, tenant data to be isolated, and data isolation strategy modes, construct a tenant data mixing relationship diagram between the tenant data to be isolated and the existing tenant data in the multi-tenant platform.

[0031] Among them, the tenant data mixing relationship graph is a graph structure model used to describe the shared, overlapping, or potentially conflicting relationships between the tenant data to be isolated and the existing tenant data in the platform.

[0032] In one possible implementation, S3 specifically includes: S301: Based on historical tenant data and tenant data to be isolated, extract multiple tenant data carrying units and represent each tenant data carrying unit as a multi-dimensional carrying feature vector.

[0033] Specifically, based on historical tenant data, historical tenant data carrier units corresponding to existing tenant data in the platform are extracted. Based on the tenant data to be isolated, the data carrier units corresponding to the tenant data to be isolated are extracted. The tenant data carrier unit includes database instance, schema, data table, data partition, object storage bucket, object storage prefix, cache space, replica node, backup space, encryption key, access role, and audit log directory, which are combined to form a multi-dimensional carrier feature vector.

[0034] S302: Generate the target isolation boundary vector for the tenant data to be isolated based on the data isolation strategy mode.

[0035] Optionally, the target isolation boundary vector is represented as:

[0036] in, This represents the target isolation boundary vector for the data isolation strategy mode corresponding to the tenant data to be isolated. This indicates the shared license status at the database instance level. Indicates the shared license status at the schema dimension. Indicates the shared permission status of a data table dimension. Indicates the shared permission status of the data partition dimension. This indicates the shared permission status of the object storage Bucket dimension. This indicates the shared permission status of the object storage Prefix dimension. Indicates the shared permission status at the cryptographic key level. Indicates the shared permission status for accessing the role dimension. Indicates the shared license status at the audit log directory level. Indicates the shared license status at the copy or backup location level.

[0037] It should be noted that the value is 1 when sharing is allowed for the corresponding dimension, and 0 when sharing is not allowed for the corresponding dimension. For example, when the data isolation strategy mode is independent database mode, , , When the data isolation strategy is set to object storage Prefix isolation mode, , This indicates that Buckets can be shared, but Prefixes cannot.

[0038] S303: Calculate the policy violation mixing strength between the tenant data to be isolated and the existing tenant data based on the multidimensional bearer feature vector and the target isolation boundary vector.

[0039] The existing tenant data refers to other tenant data in the historical tenant data that are different from the tenant data to be isolated.

[0040] Specifically, the multi-dimensional bearer feature vector corresponding to the data bearer unit of the tenant to be isolated is compared one by one with the multi-dimensional bearer feature vector corresponding to the existing tenant data bearer units in the platform. Based on whether the values ​​of the two multi-dimensional bearer feature vectors are the same in dimensions such as database instance, schema, data table, partition, bucket, prefix, key, access role, audit log directory and replica backup location, it is determined whether there is an actual sharing relationship between the two. Then, combined with the target isolation boundary vector, the policy violation mixing strength is calculated.

[0041] Optionally, the specific method for calculating the strategy's violation of the mixing strength is as follows:

[0042] in, This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q The strategy between individual data carrying units violates the mixing strength. Represents a set of mixed dimensions. Indicates the first r Mixed weights for each mixed dimension Indicates that two data bearer units are in the first... rThe value is 1 if the data is actually shared across all dimensions, and 0 otherwise. Represents the first element in the target isolation boundary vector. r Shared license status in each dimension.

[0043] It should be noted that the innovation of this formula lies in the fact that it does not simply count whether two tenants share the same database or the same storage path, but only weights the dimension of "actual sharing but target policy does not allow sharing", thereby identifying the mixed relationship that truly affects the subsequent isolation risk.

[0044] S304: Calculate the data sharing coupling strength based on the actual sharing relationship between the tenant data to be isolated and the existing tenant data:

[0045] in, This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q The data sharing coupling strength between data carrier units This indicates the data of tenants awaiting isolation. x The The set of access subjects corresponding to each data carrying unit This indicates that tenant data already exists. j The q The set of access subjects corresponding to each data carrying unit ∩ The symbol for intersection is ∪, and the symbol for union is ∪. This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q Cross-tenant shared access counts among data carrier units This indicates the data of tenants awaiting isolation. x The Total number of accesses to each data carrier unit This indicates that tenant data already exists. j The q Total number of accesses to each data carrier unit This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q The number of shared business calls between data carrier units This indicates the data of tenants awaiting isolation. x The The total number of business calls corresponding to each data carrier unit This indicates that tenant data already exists. j The q The total number of business calls corresponding to each data carrier unit , , These represent the weight coefficients for overlapping access subjects, shared access frequency, and shared service call items, respectively. This represents a constant to prevent the denominator from being zero.

[0046] It should be noted that the innovation of this formula lies in distinguishing between "whether the storage layer is mixed" and "whether the business layer is truly shared", so that the mixed relationship diagram constructed later reflects not only physical or logical storage relationships, but also real business access relationships.

[0047] S305: Calculate the hybrid edge generation value based on the policy violation hybrid strength and data sharing coupling strength.

[0048] Optionally, the generated values ​​for the mixed edges are specifically as follows:

[0049] in, This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q The mixed edge generation value between data carrying units This indicates the data of tenants awaiting isolation. x The Normalized value of data sensitivity level for each data carrying unit This indicates that tenant data already exists. j The q Normalized value of data sensitivity level for each data carrying unit.

[0050] It's important to note that hybrid edges are not simply determined by whether they are in the same database, table, or bucket. Instead, they consider the degree of policy violation, the actual degree of shared coupling, and the level of data sensitivity. This avoids mechanically classifying all shared relationships as high-risk hybrid edges and can also identify implicit hybrid relationships that are "formally isolated but still share access roles, keys, or logs."

[0051] S306: Construct a tenant data mixing relationship graph based on the mixed edge generation values.

[0052] Specifically, the data carrier units of the tenants to be isolated and the existing data carrier units of the tenants in the platform are used as graph nodes. A mixed edge is established between two data carrier units whose mixed edge generation value is greater than or equal to a preset mixed edge threshold, thus obtaining a tenant data mixed relationship graph.

[0053] The tenant data mix relationship diagram is represented as follows:

[0054] in, This diagram illustrates the mixed relationship between tenant data to be isolated and existing tenant data in the platform. This represents the set of data-bearing unit nodes for tenants to be isolated. This represents the set of nodes that carry historical tenant data. This represents the set of mixed edges between the data carrier unit to be isolated and the existing data carrier units. Represents the set of mixed edge weights. This represents the set of mixed edge attributes.

[0055] It should be noted that the weights in the mixed edge weight set are determined by the generated values ​​of the mixed edges, and the mixed edge attribute set includes policy violation mixing strength, data sharing coupling strength, mixed dimension type, data sensitivity level, and sharing permission status.

[0056] The mixed edge set is determined based on a comparison between the generated mixed edge value and a preset mixed edge threshold. Specifically, any node in the set of nodes of the tenant data carrying unit to be isolated is paired with any node in the set of nodes of the historical tenant data carrying unit. If the generated mixed edge value between the first node and the second node is greater than or equal to the preset mixed edge threshold, a mixed edge is established between the first node and the second node, and this mixed edge is added to the mixed edge set. If the generated mixed edge value is less than the preset mixed edge threshold, no mixed edge is established between the first node and the second node.

[0057] In this embodiment of the invention, the above steps transform the fragmented storage and sharing information between the tenant data to be isolated and the existing tenant data in the platform into a structured graph model, facilitating subsequent unified analysis and risk calculation. This step not only extracts dimensions such as database instance, schema, data table, partition, bucket, prefix, key, access role, audit log directory, and replica backup location, but also uses the target isolation boundary vector to determine which sharing relationships are policy-permitted and which violate the policy. Furthermore, by jointly determining the mixed edge generation value through policy violation mixing strength, data sharing coupling strength, and data sensitivity level, it avoids the problem of mechanically judging risk based solely on whether they are in the same database, table, or bucket, thus more accurately identifying implicit mixed relationships and high-risk sharing relationships.

[0058] S4: Calculate the data mixing risk index based on the tenant data mixing relationship diagram and the consistency between the actual data sharing relationship and the isolation boundary.

[0059] The data commingling risk index is a quantitative indicator used to measure the actual degree of commingling risk between the data of the tenant to be isolated and the data of existing tenants. The higher the value, the more high-weight, strongly coupled, or non-isolation-strategy sharing relationships exist between the data and the existing tenant data.

[0060] In one possible implementation, S4 specifically includes: S401: Extract the set of mixed edges and the generated value of mixed edges from the tenant data mixed relationship graph.

[0061] It should be noted that the generated values ​​of the mixed edges already include the policy violation mixing strength, data sharing coupling strength, and data sensitivity level, so the shared coupling relationship will not be calculated again in this step.

[0062] S402: Calculate the boundary violation ratio based on the actual shared dimension and the target isolation boundary vector corresponding to the mixed edges in the mixed edge set.

[0063] Specifically, for any mixed edge, the total number of dimensions actually shared within the mixed edge is counted, as well as the number of dimensions actually shared but not allowed to be shared by the target isolation boundary, and the boundary violation ratio is calculated:

[0064] in, This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q The boundaries between data carrying units violate proportions. This represents the number of dimensions that are actually shared in the mixed edges but are not allowed to be shared by the target isolation boundary. This represents the total number of dimensions that are actually shared in the mixed edges.

[0065] It should be noted that the actual shared dimensions include at least one of the following: database instance, schema, data table, data partition, object storage bucket, object storage prefix, encryption key, access role, audit log directory, and replica or backup location. If an actual share exists for a certain dimension, and the sharing permission status for that dimension in the target isolation boundary vector is "not allowed," then that dimension is included. If a certain dimension is actually shared, then that dimension is included. .

[0066] S403: Calculate the data mixing risk index based on the boundary violation ratio and the mixed edge generation value:

[0067] in, This indicates the data contamination risk index corresponding to the tenant data to be isolated. This indicates the data of tenants awaiting isolation. x The Data carrier unit and existing tenant data j The q Mixed edge of data carrying units.

[0068] It should be noted that the innovation of this step is that it does not simply count the number of mixed edges, nor does it simply determine whether there are shared storage resources. Instead, it takes "whether the actual sharing violates the target isolation boundary" as the risk basis and uses the mixed edge generation value obtained in step S3 for weighting, so that mixed edges with higher policy violation degree, business sharing coupling degree and data sensitivity level have a greater impact on the final risk index.

[0069] S5: Based on the data mixing risk index, perform data isolation branch processing on the data of the tenants to be isolated to obtain the data isolation branch processing solution.

[0070] In one possible implementation, S5 specifically includes: S501: Based on the data mix risk index, determine the basic isolation strength level of the tenant data to be isolated. The basic isolation strength level includes the maintenance isolation level, the boundary contraction isolation level, the mode transition isolation level, and the mandatory independent isolation level.

[0071] Specifically, the data mixed risk index obtained in step S4 is used. The basic isolation strength level corresponding to the tenant data to be isolated is determined by comparing it with preset first, second, and third thresholds. Specifically, when... When the value is below the first threshold, the isolation level is maintained. When the threshold is greater than or equal to the first threshold and less than the second threshold, it is determined to be a boundary contraction isolation level. When the threshold is greater than or equal to the second threshold and less than the third threshold, it is determined to be a mode transition isolation level. When the threshold is greater than or equal to the third threshold, it is determined to be a mandatory independent isolation level.

[0072] S502: When the basic isolation strength level is the maintenance isolation level, generate the maintenance data isolation branch processing result.

[0073] Specifically, in the data mixing risk index If the data is less than the first threshold, the established data isolation strategy remains unchanged, and a maintenance-type data isolation branch processing result is generated.

[0074] Optionally, the maintenance-type data isolation branch processing result includes the current data isolation policy mode maintenance instruction, the current data bearer location maintenance instruction, the access control rule synchronization confirmation instruction, the key binding rule synchronization confirmation instruction, the backup rule synchronization confirmation instruction, and the audit rule synchronization confirmation instruction. The maintenance-type data isolation branch processing result is used to instruct step S6 not to change the primary bearer location of the tenant data to be isolated, but only to perform policy consistency confirmation.

[0075] S503: When the basic isolation strength level is the boundary shrinkage isolation level, generate the boundary shrinkage type data isolation branch processing result.

[0076] Specifically, in the data mixing risk index If the threshold is greater than or equal to the first threshold but less than the second threshold, the data isolation strategy mode corresponding to the tenant data to be isolated is not changed. Instead, the allowed shared isolation boundary is shrunk under the current data isolation strategy mode, generating a boundary-shrinking data isolation branch processing result. The boundary-shrinking data isolation branch processing result includes at least one of the following: shared schema separation instruction, shared partition reconstruction instruction, shared object storage prefix adjustment instruction, shared access role splitting instruction, shared key unbinding instruction, shared audit log directory splitting instruction, and shared replica location adjustment instruction.

[0077] S504: When the basic isolation strength level is the mode transition isolation level, generate the data isolation branch processing result of mode transition type.

[0078] Specifically, in the data mixing risk index If the threshold is greater than or equal to the second threshold but less than the third threshold, the data isolation strategy mode determined in step S2 is adjusted to a target data isolation strategy mode with higher isolation strength according to the preset data isolation strategy mode transition chain, generating a mode transition type data isolation branch processing result. The data isolation strategy mode transition chain includes: transition from shared database shared schema mode to shared database independent schema mode, transition from shared database independent schema mode to multi-database multi-tenant mode, transition from multi-database multi-tenant mode to independent database mode, and transition from object storage prefix isolation mode to object storage bucket isolation mode.

[0079] S505: When the basic isolation strength level is mandatory independent isolation level, generate the processing result of mandatory independent data isolation branch.

[0080] Specifically, in the data mixing risk index If the threshold is greater than or equal to the third threshold, the data isolation strategy mode for the tenant data to be isolated will be adjusted to independent database mode or object storage bucket isolation mode, and a forced independent data isolation branch processing result will be generated. The forced independent data isolation branch processing result includes independent database creation instructions, independent schema creation instructions, independent object storage bucket creation instructions, original shared bearer location unbinding instructions, forced data migration instructions, independent key generation instructions, access role reconstruction instructions, original cache clearing instructions, backup isolation instructions, and replica resynchronization instructions.

[0081] S506: Perform action serialization processing on the processing results of each data isolation branch to obtain the data isolation branch processing scheme.

[0082] Specifically, the processing results of each branch are converted into a sequence of data isolation actions arranged in the execution order. The data isolation action sequence includes at least one of the following: bearer location preparation, data migration, partition reconstruction, access route update, key isolation update, backup isolation update, cache cleanup, audit rule update, and replica synchronization.

[0083] In this embodiment of the invention, the above steps enable different levels of data isolation processing for tenant data to be isolated, based on the risk index of data contamination. This avoids high-cost migrations in low-risk scenarios and avoids simple rule confirmations in high-risk scenarios. Specifically, when the risk is low, the existing isolation mode is maintained and the consistency of access control, keys, backup, and audit rules is confirmed. When the risk increases, shared boundary contraction, isolation mode transitions, or forced independent isolation are gradually implemented, thus matching the isolation actions with the actual risk level. Furthermore, by converting the results of various branch processing into an ordered sequence of data isolation actions, a clear execution basis can be provided for subsequent data migration, partition reconstruction, access route updates, key isolation, cache cleanup, backup isolation, and copy synchronization, improving the accuracy, controllability, and resource utilization efficiency of data isolation processing.

[0084] S6: Based on the data isolation branch processing scheme, perform data migration, repartitioning and replica synchronization on the data of the tenant to be isolated, and obtain the data isolation execution result.

[0085] Specifically, based on the obtained data isolation branch processing plan, the data isolation action sequence is read and executed in the following order: bearer location preparation, data snapshot, data migration, partition reconstruction, access route update, key isolation update, backup isolation update, cache cleanup, audit rule update, and replica synchronization. For maintenance branches, only the consistency of access control rules, key binding rules, backup rules, and audit rules is confirmed. For boundary shrinkage branches, the shared schema, shared partition, or shared object storage prefix is ​​split into independent schemas, independent partitions, or independent prefixes, and access roles, keys, audit log directories, and replica locations are adjusted synchronously. For schema transition branches, the tenant data to be isolated is migrated to a bearer mode with higher isolation strength according to the data isolation strategy schema transition chain. For forced independence branches, an independent database, independent schema, or independent object storage bucket is created, the entire tenant data to be isolated is migrated to an independent bearer location, and the access bindings, key bindings, cache bindings, and backup bindings in the original shared bearer location are released.

[0086] S7: Calculate the data residual diffusion coefficient based on the data isolation execution results.

[0087] The data residual diffusion coefficient is a quantitative indicator used to measure whether the data of the tenant to be isolated continues to remain and be accessed through the original database, original schema, original object storage path, cache, index, copy, backup, shared key or old access role after the isolation is completed.

[0088] In one possible implementation, S7 specifically includes: S701: Based on the data isolation execution results, determine the range of residual data to be detected and generate residual data identification rules.

[0089] The method for determining the range of residual data to be detected is based on the migration mapping relationship between the original bearing position and the target bearing position.

[0090] Optionally, residual data identification rules are generated based on the tenant identifier, data primary key, data hash value, object identifier, object prefix, partition key, schema identifier, key identifier, access role identifier, backup batch identifier, and replica version identifier corresponding to the tenant data to be isolated in step S1. These residual data identification rules include row-level residual identification rules, object-level residual identification rules, cache residual identification rules, index residual identification rules, replica residual identification rules, backup residual identification rules, key binding residual identification rules, and access role residual identification rules.

[0091] S702: Based on the residual data identification rules, perform residual scanning on the range of residual data to be detected to obtain a set of residual data evidence.

[0092] Specifically, a residual scan is performed on the range of residual data to be detected, following the order of database layer, object storage layer, cache layer, index layer, replica layer, backup layer, key layer, and access control layer. In the database layer, residual data is detected in the original database, schema, tables, and partitions based on tenant identifier, primary key range, partition key, and data hash value. In the object storage layer, residual objects are detected in the original object storage path based on object prefix, object metadata, object hash value, and bucket policy. In the cache and index layers, residual data that can still be hit by business services is detected based on cache key, index key, tenant identifier, and business routing identifier. In the replica and backup layers, residual copies or backups formed by data replication before migration are detected based on replica version, backup batch, snapshot identifier, and data hash value. In the key and access control layers, old authorization paths that still point to the data of the tenant to be isolated are detected based on key binding relationships, access role binding relationships, and access policy versions. The residual location, type, amount, sensitivity level, accessibility status, source action, and duration obtained from the scan are combined to form a residual data evidence set.

[0093] S703: Based on the data isolation strategy model and the residual data evidence set, the residual data is classified into compliant residuals and risk residuals to obtain the risk residual set.

[0094] Specifically, the residual data evidence set is compared with the data isolation strategy pattern, isolation strategy record determined in step S2, and data isolation action sequence generated in step S6 to determine whether each piece of residual data belongs to the compliant residual that is allowed to be retained.

[0095] S704: Determine the residual diffusion pathway based on the risk residual set.

[0096] Specifically, starting with each risky residual data item in the risky residual set, path tracing is performed along access routes, cache calls, index references, replica synchronization, backup recovery, key decryption, and access role authorization relationships to determine whether the residual data can still propagate from its original bearer location to the business access link, cache link, replica link, or backup recovery link. When a risky residual data item exists only in its original bearer location and has been blocked by access control, it is determined to be a static residual. When a risky residual data item can still be reached by caching, indexing, access roles, or shared keys, it is determined to be an accessible residual. When a risky residual data item has entered a replica node, backup space, or downstream business call link, it is determined to be a propagated residual. Based on the classification results of static residuals, accessible residuals, and propagated residuals, a set of residual propagation paths is generated.

[0097] S705: Calculate the data residual diffusion coefficient based on the risk residual set and the residual diffusion path set:

[0098] in, This represents the data residual diffusion coefficient corresponding to the tenant data to be isolated. Indicates the percentage of residual data. Indicates residual location coverage. Indicates residual access exposure. Indicates persistence of residue. , , , These represent the weighting coefficients for residual data percentage, residual location coverage, residual access exposure, and residual persistence, respectively.

[0099] It should be noted that the residual data percentage, residual location coverage, residual access exposure, and residual persistence are all normalized to [0,1], and all weight coefficients are greater than 0 and their sum equals 1.

[0100] Specifically, the residual data percentage is determined based on the ratio between the amount of risky residual data and the total amount of data from tenants to be isolated. Residual location coverage is determined based on the number of databases, schemas, partitions, buckets, prefixes, caches, indexes, replicas, backups, and key access locations involved in the risky residual data. Residual access exposure is determined based on whether the risky residual data can still be reached by roles, business routes, cache hits, shared keys, or backup recovery links. Residual persistence is determined based on the duration of the risky residual data from the completion of step S6 to the current detection time.

[0101] It's important to note that the innovation lies not in simply "checking whether the migration was successful," but in proposing a residual diffusion assessment mechanism after isolation. More importantly, S7 doesn't just count "how much data remains," but determines whether residual data can still be reached through access roles, shared keys, cache hits, replica synchronization, backup recovery, or business routing, thus forming a data residual diffusion coefficient. This solves a common, hidden problem in multi-tenant platforms: even though the target database or target bucket has been successfully isolated, old caches, old replicas, old backups, old keys, or old access roles can still cause cross-tenant data residual diffusion.

[0102] S8: Based on the data residual diffusion coefficient and the data mixing risk index, determine whether the data isolation execution result meets the data isolation requirements. If yes, output the data isolation result. Otherwise, adjust the data isolation strategy mode and data isolation branch processing flow accordingly.

[0103] In one possible implementation, S8 specifically includes: S801: Determine whether the residual data diffusion coefficient is less than or equal to the diffusion coefficient threshold and the data mixing risk index is less than or equal to the mixing risk threshold. If yes, determine that the data isolation execution result meets the data isolation requirements and proceed to S802. Otherwise, proceed to S803.

[0104] It should be noted that those skilled in the art can set the diffusion coefficient threshold and the mixing risk threshold according to actual needs, and this invention does not limit them.

[0105] S802: Solidify the current data isolation strategy mode, isolation strategy record, target isolation boundary vector, data isolation action sequence and data isolation execution result, and output the data isolation result.

[0106] S803: Determine the feedback adjustment type based on the data mixing risk index and the data residual diffusion coefficient.

[0107] In one possible implementation, S803 specifically includes: S8031: Based on the data mixing risk index, the data residual diffusion coefficient, and the mixing risk threshold, and combined with the diffusion coefficient threshold, calculate the mixing risk exceedance and residual diffusion exceedance respectively.

[0108] Optionally, the risk of exceeding the limit for mixed-use is specifically as follows:

[0109] in, This indicates that the risk of mixed use has exceeded the limit. This indicates the risk threshold for mixed use. This represents the function that takes the maximum value.

[0110] The specific extent of residual diffusion exceeding the limit is as follows:

[0111] in, This indicates that residual diffusion has exceeded the limit. This represents the diffusion coefficient threshold.

[0112] S8032: Calculate the dominant feedback discriminant value based on the exceedance of mixed placement risk and the exceedance of residual diffusion.

[0113] Specifically, the dominant feedback discriminant value is calculated based on the relative magnitudes between the exceedance of mixed-use risk and the exceedance of residual diffusion:

[0114] in, This indicates the dominant discriminant value.

[0115] S8033: Determine the feedback control type based on the feedback dominant discrimination value.

[0116] Specifically, when the feedback-dominant discrimination value is greater than 0, it indicates that the risk exceeding the mixed-use risk limit is greater than the risk exceeding the residual diffusion limit, and the feedback adjustment type is determined to be mixed-use risk-dominant feedback adjustment. When the feedback-dominant discrimination value is less than 0, it indicates that the risk exceeding the residual diffusion limit is greater than the risk exceeding the mixed-use risk limit, and the feedback adjustment type is determined to be residual diffusion-dominant feedback adjustment. When the feedback-dominant discrimination value is equal to 0, it indicates that the risk exceeding the mixed-use risk limit and the risk exceeding the residual diffusion limit are the same, and the feedback adjustment type is determined to be hybrid feedback adjustment. Mixed-use risk-dominant feedback adjustment is used to prioritize adjusting isolation boundaries and data isolation strategy modes. Residual diffusion-dominant feedback adjustment is used to prioritize cleaning up or blocking risk residual diffusion paths. Hybrid feedback adjustment is used to simultaneously perform isolation boundary adjustment and risk residual governance.

[0117] It's important to note that the innovation of this step lies in not simply re-executing isolation after determining whether the data isolation result exceeds the threshold, but rather simultaneously introducing a data contamination risk index and a data residue diffusion coefficient. These factors analyze the main causes of isolation failure from the perspectives of "degree of isolation boundary violation" and "degree of residual data diffusion," respectively. By calculating the contamination risk exceeding limit and the residual diffusion exceeding limit, the extent to which these two types of risks exceed their respective thresholds can be quantified. Then, the feedback-driven discriminant value is used to determine whether the current problem is caused by the unresolved contamination relationship or by residual old caches, old copies, old backups, old keys, or old access paths. This allows subsequent feedback adjustments to be categorized as contamination risk-driven, residual diffusion-driven, and hybrid. This prevents the system from blindly repeating all isolation actions, instead allowing for targeted adjustments to isolation boundaries, upgrades to isolation strategies, cleanup of residual paths, or simultaneous execution of both types of processing based on the source of the risk, thereby improving the accuracy and efficiency of feedback adjustments.

[0118] S804: Based on the feedback adjustment type, combined with the tenant data mix relationship diagram and risk residual set, calculate the feedback adjustment intensity of each isolation dimension.

[0119] Specifically, the degree of contamination risk, residual diffusion degree, and data sensitivity are statistically analyzed for each isolation dimension in database instances, schemas, data tables, data partitions, object storage buckets, object storage prefixes, access roles, keys, caches, replicas, and backups, and the feedback adjustment strength is calculated. For each isolation dimension, the following are statistically analyzed: number of contamination edges, value of contamination edge generation, number of risky residuals, number of accessible residuals, number of diffusion residuals, and data sensitivity level. The results are then comprehensively weighted to obtain the feedback adjustment strength for the corresponding isolation dimension.

[0120] It should be noted that when the feedback adjustment intensity corresponding to a certain isolation dimension is large, it indicates that the isolation dimension has a high risk of misuse, a strong residual diffusion capability, or a high data sensitivity level. Therefore, in the subsequent feedback adjustment process, priority should be given to performing data migration, isolation boundary shrinking, access blocking, key unbinding, cache clearing, replica reconstruction, or backup isolation processing on the isolation dimension.

[0121] S805: Adjust the data isolation strategy mode based on the intensity of each feedback.

[0122] Specifically, the shared permission relationships in the current data isolation strategy are dynamically adjusted based on the feedback adjustment strength corresponding to each isolation dimension. First, the feedback adjustment strengths corresponding to isolation dimensions such as database instance, schema, data table, data partition, object storage bucket, object storage prefix, access role, encryption key, cache, replica, and backup are sorted. Then, isolation dimensions with feedback adjustment strengths greater than a preset adjustment threshold are identified as target adjustment dimensions. For target adjustment dimensions, if the current data isolation strategy allows sharing, the corresponding sharing boundary is shrunk, and the corresponding dimension is adjusted to an independent isolation state. If the current data isolation strategy is already in an independent isolation state, the access control strength, key isolation strength, replica isolation strength, or backup isolation strength of that isolation dimension is further increased. When multiple isolation dimensions simultaneously exceed the preset adjustment threshold, isolation adjustments are prioritized for the isolation dimensions with larger feedback adjustment strengths, based on the magnitude of the feedback adjustment strengths corresponding to each isolation dimension.

[0123] S806: Update the target isolation boundary vector and isolation strategy record based on the data isolation strategy mode adjusted by feedback.

[0124] Specifically, based on the adjusted data isolation strategy mode reported in step S805, the shared permission status corresponding to isolation dimensions such as database instance, schema, data partition, object storage bucket, object storage prefix, access role, encryption key, replica, and backup is redefined, and the target isolation boundary vector is updated. Then, based on the updated target isolation boundary vector, the corresponding isolation strategy record is regenerated. The isolation strategy record includes the target database, target schema, target object storage path, access control rules, key isolation rules, replica isolation rules, backup isolation rules, and audit rules. Finally, the updated target isolation boundary vector and isolation strategy record serve as the basis for subsequent re-execution of data migration, access route updates, cache cleanup, key unbinding, and replica synchronization.

[0125] S807: Based on the feedback adjustment type, the updated target isolation boundary vector, and the isolation strategy record, perform feedback adjustment on the data isolation branch processing flow, and return the corresponding feedback adjustment results to the data isolation branch processing flow.

[0126] In one possible implementation, S807 specifically includes: S8071: Determine the object to be isolated and processed based on the feedback regulation type and the intensity of each feedback regulation.

[0127] Specifically, the isolation dimension with a feedback adjustment intensity greater than a preset adjustment intensity threshold is determined as the target adjustment dimension, and at least one of the following corresponding to the target adjustment dimension—data carrying unit, residual data location, access role binding relationship, key binding relationship, cache reference relationship, backup reference relationship, and replica synchronization relationship—is determined as the object to be adjusted, forming a set of objects to be adjusted.

[0128] S8072: Based on the updated isolation policy record, match feedback adjustment actions for each isolation processing object in the set of objects to be adjusted.

[0129] Specifically, if the object to be adjusted is a data carrier unit, then the actions to be performed are data migration, schema separation, partition reconstruction, object storage prefix adjustment, or object storage bucket reconstruction. If the object to be adjusted is a residual data location, then the actions to be performed are residual cleanup, residual archiving, residual backup isolation, or residual access blocking. If the object to be adjusted is an access role binding relationship, key binding relationship, cache reference relationship, backup reference relationship, or replica synchronization relationship, then the actions to be performed are access role reconstruction, key unbinding, cache cleanup, backup isolation, or replica resynchronization.

[0130] S8073: Generate a feedback-type data isolation action sequence based on the execution dependencies between various feedback adjustment actions.

[0131] Specifically, the feedback adjustment actions are sorted according to the execution order of bearing location preparation, write freezing, data migration or residual cleanup, access route update, access role reconstruction, key unbinding or reconstruction, cache cleanup, backup isolation, audit rule update and replica synchronization to obtain a feedback-type data isolation action sequence.

[0132] S8074: Performs integrity and execution dependency checks on the isolated action sequence of feedback data and generates feedback adjustment results.

[0133] Specifically, it is determined whether the feedback-type data isolation action sequence covers all objects to be adjusted in the set of objects to be adjusted, and whether the preconditions for each feedback adjustment action are met. If there are uncovered objects to be adjusted, the corresponding feedback adjustment actions are added. If there are feedback adjustment actions with unmet execution dependencies, the order of actions in the feedback-type data isolation action sequence is adjusted.

[0134] S8075: The feedback adjustment results are fed back to the data isolation branch processing flow, and the data isolation branch processing flow is re-executed until the data mixing risk index and data residual diffusion coefficient after isolation both meet the threshold requirements, or the number of feedback adjustments reaches the feedback adjustment number threshold and then the manual review process is initiated.

[0135] Specifically, the set of objects to be adjusted, feedback adjustment actions, action execution order, target bearer location, target access control rules, target key isolation rules, target backup isolation rules, and target audit rules are combined to generate feedback adjustment results. The feedback adjustment results are then used as input for new data isolation branch processing to re-execute data migration, repartitioning, replica synchronization, cache clearing, key unbinding, access role reconstruction, or backup isolation processing.

[0136] It's important to note that the innovation of this step lies in its departure from simply repeating the original data isolation process during feedback adjustment. Instead, it first precisely identifies the specific objects requiring processing based on the type and intensity of feedback adjustment for each isolation dimension. This allows operations such as data migration, schema separation, partition reconstruction, remnant cleanup, access blocking, key unbinding, cache cleanup, backup isolation, and replica resynchronization to be executed precisely according to the source of the problem. Furthermore, this step considers the execution dependencies between actions, generating a feedback-based data isolation action sequence and verifying the action coverage and preconditions to avoid issues such as omitted objects, incorrect action order, or unmet dependencies. Therefore, feedback adjustment is no longer a crude re-isolation but forms a closed-loop processing mechanism of "risk identification - object determination - action matching - sequence generation - verification feedback," improving the targeting, completeness, and reliability of data isolation feedback correction.

[0137] In this embodiment of the invention, this step can distinguish between mixed risk-driven, residual diffusion-driven, and mixed feedback adjustment based on the reasons for exceeding risk limits, and further locate the isolation dimensions and specific processing objects that need to be adjusted. This ensures that actions such as isolation policy updates, isolation boundary contraction, residual cleanup, access blocking, key unbinding, cache cleanup, replica reconstruction, and backup isolation can be executed in an orderly manner. Thus, a closed-loop mechanism of "isolation execution - result detection - risk identification - feedback correction - re-verification" can be formed, improving the reliability, security, and continuous compliance capability of data isolation results on multi-tenant platforms.

[0138] Reference manual attached Figure 2 The diagram shows a structural schematic of a data isolation system for a multi-tenant platform provided by an embodiment of the present invention.

[0139] This invention provides a data isolation system 20 for multi-tenant platforms, including: a processor 201 and a memory 202; The memory 202 stores programs or instructions that can run on the processor 201. When the program or instructions are executed by the processor 201, they implement the steps of the data isolation method for multi-tenant platforms described above and achieve the same technical effect. To avoid repetition, the present invention will not elaborate further.

[0140] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended 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 of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A data isolation method for multi-tenant platforms, characterized in that, include: S1: Obtain historical tenant data and tenant data to be isolated from the multi-tenant platform; S2: Dynamically determine the data isolation strategy mode corresponding to the tenant data to be isolated based on the data attributes of the historical tenant data and the tenant data to be isolated; S3: Based on the historical tenant data, the tenant data to be isolated, and the data isolation strategy mode, construct a tenant data mixing relationship diagram between the tenant data to be isolated and the existing tenant data in the multi-tenant platform; S4: Based on the tenant data mixing relationship diagram, and combined with the consistency between the actual data sharing relationship and the isolation boundary, calculate the data mixing risk index; S5: Based on the data mixing risk index, perform data isolation branch processing on the tenant data to be isolated to obtain a data isolation branch processing scheme; S6: According to the data isolation branch processing scheme, perform data migration, repartitioning and replica synchronization processing on the tenant data to be isolated to obtain the data isolation execution result; S7: Calculate the data residual diffusion coefficient based on the data isolation execution results; S8: Based on the data residual diffusion coefficient and the data mixing risk index, determine whether the data isolation execution result meets the data isolation requirements; if yes, output the data isolation result; otherwise, adjust the data isolation strategy mode and data isolation branch processing flow accordingly.

2. The data isolation method for multi-tenant platforms according to claim 1, characterized in that, S3 specifically includes: S301: Based on the historical tenant data and the tenant data to be isolated, extract multiple tenant data carrying units, and represent each tenant data carrying unit as a multi-dimensional carrying feature vector; S302: Generate the target isolation boundary vector of the tenant data to be isolated according to the data isolation strategy mode; S303: Calculate the policy violation mixing strength between the tenant data to be isolated and the existing tenant data based on the multidimensional bearer feature vector and the target isolation boundary vector; S304: Calculate the data sharing coupling strength based on the actual sharing relationship between the tenant data to be isolated and the existing tenant data; S305: Calculate the mixed edge generation value based on the strategy violation mixing strength and the data sharing coupling strength; S306: Construct the tenant data mixing relationship graph based on the mixed edge generation value.

3. The data isolation method for multi-tenant platforms according to claim 1, characterized in that, S4 specifically includes: S401: Extract the set of mixed edges and the generated value of mixed edges from the tenant data mixed relationship graph; S402: Calculate the boundary violation ratio based on the actual shared dimension and target isolation boundary vector corresponding to the mixed edges in the mixed edge set; S403: Calculate the data mixing risk index based on the boundary violation ratio and the mixed edge generation value.

4. The data isolation method for multi-tenant platforms according to claim 1, characterized in that, S5 specifically includes: S501: Based on the data mixing risk index, determine the basic isolation strength level of the tenant data to be isolated. The basic isolation strength level includes the maintenance isolation level, the boundary contraction isolation level, the mode transition isolation level, and the mandatory independent isolation level. S502: When the basic isolation strength level is the maintenance isolation level, generate the maintenance data isolation branch processing result; S503: When the basic isolation strength level is the boundary contraction isolation level, generate the boundary contraction type data isolation branch processing result; S504: When the basic isolation strength level is the mode transition isolation level, generate the mode transition type data isolation branch processing result; S505: When the basic isolation strength level is the forced independent isolation level, generate the forced independent data isolation branch processing result; S506: Perform action serialization processing on the processing results of each data isolation branch to obtain the data isolation branch processing scheme.

5. The data isolation method for multi-tenant platforms according to claim 1, characterized in that, Specifically, S7 includes: S701: Based on the data isolation execution results, determine the range of residual data to be detected and generate residual data identification rules; S702: According to the residual data identification rules, perform residual scanning on the range of residual data to be detected to obtain a set of residual data evidence; S703: Based on the data isolation strategy mode and the residual data evidence set, classify the residual data into compliant residuals and risk residuals to obtain a risk residual set; S704: Determine the residual diffusion path based on the aforementioned risk residual set; S705: Calculate the data residual diffusion coefficient based on the risk residual set and the residual diffusion path set.

6. The data isolation method for multi-tenant platforms according to claim 1, characterized in that, S8 specifically includes: S801: Determine whether the data residual diffusion coefficient is less than or equal to the diffusion coefficient threshold and the data mixing risk index is less than or equal to the mixing risk threshold; if yes, determine that the data isolation execution result meets the data isolation requirements and proceed to S802; otherwise, proceed to S803. S802: Solidify the current data isolation strategy mode, isolation strategy record, target isolation boundary vector, data isolation action sequence, and data isolation execution result, and output the data isolation result; S803: Determine the feedback adjustment type based on the data mixing risk index and the data residual diffusion coefficient; S804: Based on the feedback adjustment type, combined with the tenant data mixing relationship diagram and risk residual set, calculate the feedback adjustment intensity of each isolation dimension; S805: Adjust the data isolation strategy mode according to the respective feedback adjustment strengths; S806: Update the target isolation boundary vector and isolation strategy record based on the data isolation strategy mode adjusted by feedback; S807: Based on the feedback adjustment type and the updated target isolation boundary vector and isolation strategy record, perform feedback adjustment on the data isolation branch processing flow, and return the corresponding feedback adjustment result to the data isolation branch processing flow.

7. The data isolation method for multi-tenant platforms according to claim 6, characterized in that, Specifically, S803 includes: S8031: Based on the data mixing risk index, the data residual diffusion coefficient, and the mixing risk threshold, and in combination with the diffusion coefficient threshold, calculate the mixing risk exceedance and residual diffusion exceedance respectively. S8032: Calculate the feedback dominant discriminant value based on the aforementioned excessive risk of mixed placement and the aforementioned excessive residual diffusion; S8033: Determine the feedback adjustment type based on the feedback dominant discrimination value.

8. The data isolation method for multi-tenant platforms according to claim 6, characterized in that, Specifically, S807 includes: S8071: Determine the object to be isolated and processed based on the feedback adjustment type and the intensity of each feedback adjustment; S8072: Based on the updated isolation strategy record, match feedback adjustment actions for each of the isolation processing objects to be adjusted in the set of objects to be adjusted; S8073: Generate a feedback-type data isolation action sequence based on the execution dependencies between the various feedback adjustment actions; S8074: Perform integrity and execution dependency checks on the feedback-type data isolation action sequence, and generate feedback adjustment results; S8075: The feedback adjustment result is fed back to the data isolation branch processing flow, and the data isolation branch processing flow is re-executed until the data mixing risk index and data residual diffusion coefficient after isolation both meet the threshold requirements, or the number of feedback adjustments reaches the feedback adjustment number threshold and then the manual review process is initiated.

9. A data isolation system for multi-tenant platforms, characterized in that, include: Processor and memory; The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the data isolation method for a multi-tenant platform as described in any one of claims 1 to 8.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the data isolation method for a multi-tenant platform as described in any one of claims 1 to 8.

Images