A Data Space Multi-Tenant Isolation Method and System Based on Zero-Trust Architecture

Abstract

This invention discloses a multi-tenant isolation method and system for data spaces based on a zero-trust architecture, specifically relating to the field of multi-tenant access control technology. It addresses the problems of cross-tenant permission conflicts and insufficient resource isolation caused by frequent policy adjustments in existing technologies. The method constructs a policy dependency topology by acquiring dynamic access policy change requests in real time to model the dependency relationships between tenant permission nodes, resource access path nodes, and time-series connections. It dynamically marks resource sensitivity weights based on historical access behavior and filters highly sensitive conflict nodes using logical coupling analysis. It separates directly dependent independent resource access chains through reverse backtracking and generates hierarchical permission correction rules. Finally, it injects rules and triggers blocking conditions to perform hierarchical verification and risk marking on cross-tenant operation requests. This reduces the impact of policy execution on the global system, ensuring clear permission boundaries and resource security in the multi-tenant data space.

Description

Technical Field

[0001] This invention relates to the field of multi-tenant access control technology, and more specifically, to a data space multi-tenant isolation method and system based on a zero-trust architecture. Background Technology

[0002] In the security management of multi-tenant data spaces, dynamic access control policies based on zero-trust architecture are widely used to deal with real-time risks. Typically, by continuously monitoring user behavior, device status, and environmental indicators, the access permissions of tenants are dynamically adjusted. For example, when abnormal logins or data operations are detected, permission downgrades or access blocking are automatically triggered. Such methods rely on the real-time decision-making capabilities of the policy engine to ensure the strict implementation of the principle of least privilege in multi-tenant shared resource scenarios.

[0003] However, in a multi-tenant data space, frequent adjustments to dynamic policies may lead to policy logic coupling between different tenants. That is, when multiple tenants share the same resource pool, a change in the permission of a certain tenant may cause cross-tenant permission state conflicts due to the unclear policy execution sequence or dependency relationship. For example, if a temporary demotion operation does not isolate the access chain of related resources, it may accidentally activate the hidden permission path of other tenants, resulting in blurred permission boundaries and thus threatening the logical isolation of multi-tenant data. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a data space multi-tenant isolation method and system based on a zero-trust architecture to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A data space multi-tenant isolation method based on zero-trust architecture includes the following steps:

[0007] S1. Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships;

[0008] S2. Based on the policy triggering sequence and tenant resource sharing relationship, construct a policy dependency topology structure that includes tenant permission nodes, resource access path nodes and policy triggering sequence connection edges.

[0009] S3. Dynamically assign resource sensitivity weights to resource access path nodes based on tenants' historical access behavior;

[0010] S4. Analyze the logical coupling between the strategy-triggered sequential connection edge and the resource access path node, and filter conflict nodes with sensitivity weights higher than the preset threshold based on the resource sensitivity weight.

[0011] S5. Backtrack the resource access path nodes of the conflicting nodes and separate the independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology.

[0012] S6. Generate permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions;

[0013] S7. Inject permission correction rules and trigger timing blocking conditions to perform hierarchical verification and isolation on cross-tenant operation requests, and add cross-tenant risk flags for failed verifications.

[0014] In a preferred embodiment, the system acquires dynamic access policy change requests from multiple tenants in real time, extracts the policy triggering sequence and tenant resource sharing relationships, including:

[0015] Parse the operation timestamp and policy trigger event type in the dynamic access policy change request, and generate a policy trigger sequence arranged in chronological order;

[0016] Identify tenant identities and associated resource paths from policy-triggered event types, and extract shared resource access dependencies between tenants;

[0017] Based on the timestamp order of the policy trigger sequence, a mapping table is established between policy trigger event types and shared resource access dependencies, generating structured data on policy trigger timing and tenant resource sharing relationships.

[0018] In a preferred embodiment, based on the policy triggering sequence and tenant resource sharing relationships, a policy dependency topology structure is constructed, including tenant permission nodes, resource access path nodes, and policy triggering sequence connection edges, comprising:

[0019] Based on the timestamp order of the policy trigger sequence, create tenant permission nodes and mark the permission level and effective time range;

[0020] Based on the associated resource paths in the tenant resource sharing relationship, generate resource access path nodes and mark the resource storage location and access permission type;

[0021] Tenant permission nodes and resource access path nodes are associated with policy-triggered time-series connection edges to form a policy-dependent topology;

[0022] Store the strategy-dependent topology in a graph database.

[0023] In a preferred embodiment, the policy-triggered timing connection edge includes the trigger time window and the permission change action type; the tenant permission node, resource access path node, and policy-triggered timing connection edge are represented in the form of vertices, vertices, and edges, respectively.

[0024] In a preferred embodiment, dynamically assigning resource sensitivity weights to resource access path nodes based on tenant historical access behavior includes:

[0025] Extract resource access frequency and operation type from tenant's historical access behavior. Operation types include data query, modification, and deletion.

[0026] The basic sensitivity weight is calculated based on the resource access frequency; the higher the resource access frequency, the greater the basic sensitivity weight.

[0027] The basic sensitivity weights are adjusted based on the operation type, with the weighting coefficient for deletion operations being higher than that for modification operations, and the weighting coefficient for modification operations being higher than that for query operations.

[0028] The weighted resource sensitivity weights are dynamically marked to the resource access path nodes and associated with the corresponding tenant identity and resource storage location.

[0029] In a preferred embodiment, the logical coupling between the strategy-triggered sequential connection edge and the resource access path node is analyzed, and conflict nodes with sensitivity weights higher than a preset threshold are filtered based on resource sensitivity weights, including:

[0030] The number of resource access path nodes associated with the timing connection edge triggered by the statistical strategy is counted, and the logical coupling degree between the timing connection edge triggered by the strategy and the resource access path node is calculated.

[0031] The conflict risk value is calculated based on the logical coupling degree and the resource sensitivity weight. The conflict risk value is the product of the logical coupling degree and the resource sensitivity weight.

[0032] Conflict nodes with a conflict risk value greater than a preset threshold are selected. The preset threshold is dynamically adjusted based on historical conflict data.

[0033] The selected conflict nodes are associated with the corresponding policy triggering sequence connection edges and resource access path nodes to generate a set of conflict nodes.

[0034] In a preferred embodiment, the resource access path nodes of the conflicting nodes are traced back in reverse, and independent resource access chains that have a direct dependency relationship with the current policy change request are separated based on the policy dependency topology, including:

[0035] Starting from the conflict node, traverse the policy dependency topology in reverse along the policy triggering sequence connection edge, and count the number of resource access path nodes directly associated with the current policy change request.

[0036] Remove indirect resource access path nodes in the policy-triggered sequential connection edges that are not directly related to the current policy change request, and retain directly triggered resource access path nodes;

[0037] Based on the overlap of the time windows between the directly triggered resource access path node and the policy triggering sequence connection edge, determine whether there is a direct dependency relationship with the current policy change request;

[0038] By combining resource access path nodes that satisfy direct dependencies with associated policy-triggered sequential connection edges, structured data of independent resource access chains is generated.

[0039] In a preferred embodiment, permission correction rules are generated based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions, comprising:

[0040] Based on the numerical range of resource sensitivity weights, the permission downgrade gradient levels are divided. The higher the resource sensitivity weight, the more stringent the permission downgrade gradient.

[0041] Path isolation constraints are generated based on the resource storage location and path of the resource access path nodes. The path isolation constraint rules include prohibiting cross-storage location access and restricting access protocols for highly sensitive resource paths.

[0042] Extract the time window information of the timing connection edge triggered by the policy, and configure the timing blocking conditions. The timing blocking conditions include prohibiting permission change requests from being initiated outside the time window and limiting the number of concurrent access requests.

[0043] The permission downgrade gradient, path isolation constraint, and time sequence blocking condition are combined into permission correction rules, which are then bound to the corresponding resource access path nodes and tenant identity identifiers.

[0044] In a preferred embodiment, an access control rule is injected and a timing blocking condition is triggered to perform tiered verification and isolation on cross-tenant operation requests, and a cross-tenant risk flag is added for failed verifications, including:

[0045] Inject the permission correction rules into the rule base of the zero-trust policy engine to trigger the real-time effect of the time-series blocking conditions;

[0046] Parse the resource access path and tenant identity in cross-tenant operation requests, and match them with permission degradation gradients and path isolation constraints in the rule base;

[0047] Based on the matching results, the request is subjected to hierarchical verification, with verification levels including complete blocking, partial demotion, and log monitoring only.

[0048] For requests that fail verification, trigger path isolation constraints and timing blocking conditions to block the corresponding access or limit concurrent operations;

[0049] Generate cross-tenant risk markers for failed verifications. The markers include the resource path that triggered the blocking, the tenant's identity, and the type of violation. The marker data is then associated with the corresponding node in the policy-dependent topology.

[0050] On the other hand, the present invention provides a data space multi-tenant isolation system based on a zero-trust architecture, comprising:

[0051] Policy acquisition and parsing module: Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships;

[0052] Topology construction module: Based on policy triggering sequence and tenant resource sharing relationship, construct a policy dependency topology structure including tenant permission nodes, resource access path nodes and policy triggering sequence connection edges;

[0053] Resource weighting module: Dynamically assigns resource sensitivity weights to resource access path nodes based on tenant's historical access behavior;

[0054] Conflict node filtering module: Analyzes the logical coupling between the policy triggering sequence connection edge and the resource access path node, and filters conflict nodes with sensitivity weights higher than a preset threshold based on resource sensitivity weights;

[0055] Reverse backtracking separation module: Reverse backtracks the resource access path nodes of conflicting nodes, and separates independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology structure;

[0056] Permission rule generation module: Generates permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions;

[0057] Risk verification and marking module: Injects permission correction rules and triggers time-series blocking conditions, performs hierarchical verification and isolation on cross-tenant operation requests, and adds cross-tenant risk markings for failed verifications.

[0058] Compared with the prior art, the present invention has the following beneficial effects:

[0059] 1. By dynamically constructing a policy dependency topology, the system uniformly models the permission nodes, resource paths, and policy triggering sequences in multi-tenant scenarios, accurately depicting the complex dependencies of cross-tenant permission changes; based on dynamic labeling and logical coupling analysis of resource sensitivity weights, it can identify highly sensitive conflict nodes in real time and reversely strip away unrelated resource chains, effectively avoiding the problem of blurred permission boundaries caused by policy adjustments; through a hierarchical isolation mechanism for permission correction rules, combined with timing blocking conditions and path constraints, it achieves fine-grained dynamic adaptation of permission control, ensuring strict isolation of multi-tenant resources while reducing interference with normal access processes, significantly improving the flexibility of policy execution and system stability;

[0060] 2. Through closed-loop verification and risk marking mechanisms, a complete link from policy change to risk feedback is constructed; the separation of independent resource access chains and the dynamic matching mechanism of permission gradients ensure that permission adjustments only affect directly related resources, minimizing the impact of policy execution on the global system; at the same time, cross-tenant risk marking and topology node association provide traceable data support for subsequent policy optimization, forming a virtuous cycle of risk perception, isolation and blocking, and policy iteration; this proactive defense system can continuously maintain the consistency of permission logic in complex and ever-changing shared environments, providing reliable and low-intrusion support for the secure management of multi-tenant data spaces. Attached Figure Description

[0061] Figure 1 This is a flowchart of the data space multi-tenant isolation method based on zero-trust architecture of the present invention;

[0062] Figure 2 This is a schematic diagram of the data space multi-tenant isolation system based on zero-trust architecture according to the present invention. Detailed Implementation

[0063] 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 of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0064] Example 1: Figure 1 This invention presents a data space multi-tenant isolation method based on a zero-trust architecture, which includes the following steps:

[0065] S1. Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships, including:

[0066] Parse the operation timestamp and policy trigger event type in the dynamic access policy change request, and generate a policy trigger sequence arranged in chronological order;

[0067] Identify tenant identities and associated resource paths from policy-triggered event types, and extract shared resource access dependencies between tenants;

[0068] Based on the timestamp order of the policy trigger sequence, a mapping table is established between policy trigger event types and shared resource access dependencies, generating structured data on policy trigger timing and tenant resource sharing relationships.

[0069] During the acquisition and parsing of dynamic access policy change requests, the operation timestamp is extracted from the time field in the request message header, and the policy trigger event types include permission change instructions or resource access requests.

[0070] When the policy trigger event type is a permission change instruction, the permission level adjustment parameters and effective time range in the request body are parsed to generate a policy trigger sequence arranged in ascending order of timestamps. For example, the permission downgrade instruction with timestamp T1 is arranged before the resource access request with timestamp T2.

[0071] Tenant identity is obtained by parsing the tenant ID field in the request header. The associated resource path is extracted from the resource locator in the request body. The resource locator contains the shared storage path or API interface address. For example, when the resource path is " / data / tenant_A / file1", the tenant identity is identified as "tenant_A".

[0072] Shared resource access dependencies are generated based on concurrent access records of the same resource path identified by different tenant identities. For example, when a tenant identified as “tenant_B” requests access to the resource path “ / data / tenant_A / file1”, it is marked that tenants “tenant_B” and “tenant_A” have a shared resource access dependency relationship.

[0073] The mapping table between policy triggering sequence and shared resource access dependency is generated by binding the event type corresponding to each timestamp in the policy triggering sequence with the tenant identity and associated resource path. For example, the permission downgrade instruction of timestamp T1 is mapped to the access dependency of tenant "tenant_A" on the resource path " / data / tenant_A / file1".

[0074] Structured data is stored in key-value pairs, where the key is the timestamp of the policy trigger time and the value is a combination of tenant identity, associated resource path, and shared resource access dependency.

[0075] S2. Based on policy triggering sequence and tenant resource sharing relationships, construct a policy dependency topology structure including tenant permission nodes, resource access path nodes, and policy triggering sequence connection edges, including:

[0076] Based on the timestamp order of the policy trigger sequence, create tenant permission nodes and mark the permission level and effective time range;

[0077] Based on the associated resource paths in the tenant resource sharing relationship, generate resource access path nodes and mark the resource storage location and access permission type;

[0078] Tenant permission nodes and resource access path nodes are associated with policy-triggered time-series connection edges. These policy-triggered time-series connection edges include the trigger time window and the permission change action type, forming a policy-dependent topology.

[0079] The policy-dependent topology is stored in a graph database, where tenant permission nodes, resource access path nodes, and policy triggering sequential connections are represented as vertices, vertices, and edges, respectively.

[0080] During the creation of tenant permission nodes, permission change events corresponding to each timestamp are extracted from the policy trigger sequence based on the timestamp order of the policy trigger sequence.

[0081] The permission level is determined based on the operation type in the permission change event, including read and write permissions, read-only permissions, and no permissions. Read and write permissions correspond to the high permission level, read-only permissions to the medium permission level, and no permissions to the low permission level.

[0082] The effective time range is determined based on the effective timestamp and expiration timestamp in the permission change event. For example, if the effective timestamp is T1 and the expiration timestamp is T2, the effective time range is marked as T1 to T2.

[0083] During the generation of resource access path nodes, the associated resource path is extracted from the shared resource access dependency relationship of the tenant resource sharing relationship. For example, the resource path is " / data / tenant_A / file1" in shared storage or " / api / tenant_B / data" in API interface.

[0084] The resource storage location is determined based on the protocol type and path prefix of the resource path. For example, if the path prefix is ​​" / data", it is marked as local storage, and if the prefix is ​​" / api", it is marked as a remote service interface.

[0085] The access permission type is determined based on the binding relationship between the tenant identity and the resource path in the shared resource access dependency relationship. For example, if the tenant identity is "tenant_B" and the resource path is " / data / tenant_A / file1", the access permission type is marked as read-only.

[0086] During the association process of policy-triggered sequential connection edges, the trigger time window is determined according to the timestamp order of the policy trigger time sequence. For example, the time window between the permission change event with timestamp T1 and the resource access event with timestamp T2 is T1 to T2.

[0087] Permission change actions include permission upgrade, permission downgrade, and permission maintenance. For example, when the permission level changes from read-only to read-write, it is marked as permission upgrade, and when it changes from read-write to read-only, it is marked as permission downgrade.

[0088] In the storage process that depends on the topology, tenant permission nodes are stored in the graph database as vertices. Vertex attributes include permission level, effective time range, and associated tenant identity identifier.

[0089] Resource access path nodes are stored in the graph database as vertices. Vertex attributes include resource storage location, access permission type, and associated resource path.

[0090] The policy trigger sequence connection edges are stored in the graph database in the form of edges. The edge attributes include the trigger time window, the permission change action type, and the associated timestamp.

[0091] In a graph database, vertices and edges are associated with unique identifiers. For example, the vertex ID of a tenant permission node is “P_tenant_A”, the vertex ID of a resource access path node is “R_ / data / tenant_A / file1”, and the ID of a policy-triggered sequential connection edge is “E_T1_T2”.

[0092] S3. Dynamically assign resource sensitivity weights to resource access path nodes based on tenant's historical access behavior, including:

[0093] Extract resource access frequency and operation type from tenant's historical access behavior. Operation types include data query, modification, and deletion.

[0094] The basic sensitivity weight is calculated based on the resource access frequency; the higher the resource access frequency, the greater the basic sensitivity weight.

[0095] The basic sensitivity weights are adjusted based on the operation type, with the weighting coefficient for deletion operations being higher than that for modification operations, and the weighting coefficient for modification operations being higher than that for query operations.

[0096] The weighted resource sensitivity weights are dynamically marked to the resource access path nodes and associated with the corresponding tenant identity and resource storage location.

[0097] Tenant historical access behavior is extracted from the log database of the zero-trust policy engine. The log database records the tenant's identity, resource access path, and operation type.

[0098] Resource access frequency is determined by counting the number of requests made by the same tenant identity to the resource access path within a preset time window. For example, it counts the total number of times the tenant identity “tenant_A” accesses the resource path “ / data / tenant_A / file1” in the past 24 hours.

[0099] Operation types are categorized according to the operation instruction fields in the log database: data query corresponds to the "GET" instruction, data modification corresponds to the "PUT" instruction, and data deletion corresponds to the "DELETE" instruction.

[0100] The basic sensitivity weight is positively correlated with the frequency of resource access. The higher the access frequency, the greater the basic sensitivity weight. For example, the basic sensitivity weight of a frequently accessed resource path is set higher than that of a low-frequency accessed resource path.

[0101] The weighted adjustment is based on the degree of impact of the operation type on data security. The weighting coefficient for deletion operations is set higher than that for modification operations, and higher than that for query operations. For example, the weighting coefficient for deletion operations is the preset highest value, and the weighting coefficient for query operations is the preset lowest value.

[0102] Resource sensitivity weights are calculated by multiplying a base sensitivity weight by a weighting coefficient for the corresponding operation type. For example, if a resource path has a base sensitivity weight of medium and the operation is deletion, the final sensitivity weight will be adjusted to a higher level. During dynamic tagging, resource sensitivity weights are bound to resource access path nodes. These nodes are associated with the corresponding tenant identity and resource storage location. For example, the node for the resource path " / data / tenant_A / file1" tags the tenant identity "tenant_A" and the local storage location.

[0103] The location of resource storage is determined based on the protocol type or path prefix of the resource access path. For example, if the path prefix contains "http: / / ", it is marked as cloud storage, and if the prefix is ​​" / data", it is marked as local storage.

[0104] The marked resource sensitivity weights are stored in the graph database. The attribute fields of vertices in the graph database contain resource access paths, tenant identities, and resource sensitivity weights. For example, the sensitivity weight of the resource path " / data / tenant_A / file1" recorded in the vertex attributes is 0.9.

[0105] The preset value of the weighting coefficient can be configured through the management interface of the zero-trust strategy engine, and can be dynamically adjusted according to business scenarios. For example, in the financial data scenario, the weighting coefficient for deletion-type operations can be set to twice that of the industrial scenario.

[0106] The resource sensitivity weight is updated through a scheduled task, such as re-counting the access frequency and updating the weight value every hour to ensure that the weight value is consistent with real-time access behavior.

[0107] S4. Analyze the logical coupling between the strategy-triggered sequential connection edges and resource access path nodes, and filter conflicting nodes with sensitivity weights higher than a preset threshold based on resource sensitivity weights, including:

[0108] The number of resource access path nodes associated with the timing connection edge triggered by the statistical strategy is counted, and the logical coupling degree between the timing connection edge triggered by the strategy and the resource access path node is calculated.

[0109] The conflict risk value is calculated based on the logical coupling degree and the resource sensitivity weight. The conflict risk value is the product of the logical coupling degree and the resource sensitivity weight.

[0110] Conflict nodes with a conflict risk value greater than a preset threshold are selected. The preset threshold is dynamically adjusted based on historical conflict data.

[0111] The selected conflict nodes are associated with the corresponding policy triggering sequence connection edges and resource access path nodes to generate a set of conflict nodes.

[0112] During the calculation of logical coupling, the number of resource access path nodes associated with the policy-triggered sequential connection edge is counted by traversing the connection vertices of the edges in the policy-dependent topology. Each vertex associated with the policy-triggered sequential connection edge is a resource access path node.

[0113] The number of resource access path nodes is the total number of resource access path nodes directly connected by the policy-triggered sequential connection edge. For example, if an edge connects 3 resource access path nodes, then the number is 3.

[0114] The preset baseline value is set according to the resource scale of the multi-tenant data space. When the total number of resources is less than 100, the baseline value is 5, and when it is greater than 100, the baseline value is 10. For example, if the total number of resources is 80, the baseline value is 5.

[0115] Logical coupling is calculated by dividing the number of nodes in the resource access path by a preset baseline value. For example, when the number of nodes is 3 and the baseline value is 5, the logical coupling is 3 divided by 5, which equals 0.6.

[0116] The conflict risk value is the product of the logical coupling degree and the resource sensitivity weight. For example, if the logical coupling degree is 0.6 and the resource sensitivity weight is 1.2, the conflict risk value is 0.72.

[0117] Historical conflict data is extracted from the log database of the zero-trust policy engine, including conflict risk value records for all conflict nodes in the past 30 days.

[0118] The preset threshold is determined by calculating the arithmetic mean of historical conflict data. For example, when the historical conflict risk values ​​include 0.5, 0.8 and 1.0, the average value is 0.77. The update cycle of the preset threshold is achieved by configuring a scheduled task, such as recalculating the average value of historical conflict data and updating the threshold at 0:00 every day.

[0119] When filtering conflict nodes, the current conflict risk value is compared with a preset threshold. For example, if the conflict risk value of 0.72 is greater than the threshold of 0.77, it will not be included in the set of conflict nodes, and if it is less than or equal to the threshold, it will be included.

[0120] During the generation of the conflict node set, the conflict nodes and the corresponding policy triggering sequence connection edges are associated through the edge attributes in the graph database. The edge attributes record the conflict node identifier and conflict risk value.

[0121] Update the conflict status flag in the vertex attributes of the resource access path node. The conflict status includes high risk, medium risk and low risk. For example, if the conflict risk value is greater than the threshold, it is marked as high risk.

[0122] S5. Reversely trace the resource access path nodes of the conflicting nodes, and separate independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology, including:

[0123] Starting from the conflict node, traverse the policy dependency topology in reverse along the policy triggering sequence connection edge, and count the number of resource access path nodes directly associated with the current policy change request.

[0124] Remove indirect resource access path nodes in the policy-triggered sequential connection edges that are not directly related to the current policy change request, and retain directly triggered resource access path nodes;

[0125] Based on the overlap of the time windows between the directly triggered resource access path node and the policy triggering sequence connection edge, determine whether there is a direct dependency relationship with the current policy change request;

[0126] By combining resource access path nodes that satisfy direct dependencies with associated policy-triggered sequential connection edges, structured data of independent resource access chains is generated.

[0127] During the reverse traversal strategy, which depends on the topology, all tenant permission nodes and resource access path nodes are traversed in the reverse direction along the policy triggering sequence connection edge, starting from the resource access path node corresponding to the conflict node.

[0128] The number of directly associated resource access path nodes is determined by counting the number of nodes associated with the policy triggering time sequence connection edge that overlaps with the effective time range of the current policy change request. For example, if the effective time range of the current policy change request is T1 to T2, then the connection edge associated nodes within the time window of T1 to T2 are counted as directly associated.

[0129] The stripping of indirect resource access path nodes is achieved by determining whether the time window of the policy-triggered sequential connection edge does not overlap with the effective time range of the current policy change request. For example, if the time window is from T3 to T4 and T3 is greater than T2, it is determined to be an indirectly associated node and stripped.

[0130] The conditions for retaining directly triggered resource access path nodes include overlapping time windows and the permission change action type being consistent with the current policy change request. For example, if the current request is a write permission downgrade, only nodes associated with the write permission change action type will be retained.

[0131] The determination of overlapping time windows is achieved by comparing the effective time range of the resource access path node with the effective timestamp of the current policy change request. For example, if the effective time range of the node is T1 to T2 and the request timestamp is T (T1≤T≤T2), it is determined to be overlapping.

[0132] Verification of direct dependencies includes checking whether resource access path nodes are directly connected to the tenant permission node of the current policy change request through policy-triggered sequential connection edges. For example, node A is connected to tenant permission node P_tenant_A through edge E1, and P_tenant_A is the node that initiated the current request.

[0133] During the generation of structured data for independent resource access chains, resource access path nodes that satisfy direct dependencies and associated policy trigger timing connection edges are arranged in the order of time windows. For example, node A (time window T1-T2), edge E1, and node B (time window T2-T3) form an ordered chain.

[0134] The generated structured data is stored in a separate data table in the graph database. The data table fields include resource access path, tenant permission node identifier, policy triggering time sequence connection edge identifier, and time window information.

[0135] The unique identifier of the independent resource access chain is bound to the identifier of the current policy change request. For example, when the request ID is "Req_20231001", the independent chain identifier is "Chain_Req_20231001".

[0136] Stripped indirect resource access path nodes are marked as non-conflict states, and the conflict state field in their vertex attributes is updated to "stripped". For example, the conflict state of node C changes from "high risk" to "stripped".

[0137] T1, T2, T3, and T4 are timestamp variables representing the absolute time or time range of a specific event. Their definitions and relationships are as follows: T1 represents the start time of the current policy change request, obtained by parsing the "Effective Time" field in the request message; T2 represents the end time of the current policy change request, obtained by parsing the "Expiration Time" field in the request message; T3 represents the start time of the time window for triggering sequential connection edges by other policies, extracted from the "Trigger Time Window" attribute of the edge in the policy-dependent topology; T4 represents the end time of the time window for triggering sequential connection edges by other policies.

[0138] If T3 ≥ T1 and T4 ≤ T2, the time windows are considered to be completely overlapping; if T3 < T1 or T4 > T2, the time windows are considered to be non-overlapping; T1 to T2 is the effective time range of the current policy change request, and other time windows (such as T3 to T4) are the time range of historical or concurrent policy triggering events.

[0139] S6. Generate permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions, including:

[0140] Based on the numerical range of resource sensitivity weights, the permission downgrade gradient levels are divided. The higher the resource sensitivity weight, the more stringent the permission downgrade gradient.

[0141] Path isolation constraints are generated based on the resource storage location and path of the resource access path nodes. The path isolation constraint rules include prohibiting cross-storage location access and restricting access protocols for highly sensitive resource paths.

[0142] Extract the time window information of the timing connection edge triggered by the policy, and configure the timing blocking conditions. The timing blocking conditions include prohibiting permission change requests from being initiated outside the time window and limiting the number of concurrent access requests.

[0143] The permission downgrade gradient, path isolation constraint, and time sequence blocking condition are combined into permission correction rules, which are then bound to the corresponding resource access path nodes and tenant identity identifiers.

[0144] The division of permission downgrade gradients is based on the numerical range of resource sensitivity weights. The numerical range is determined by the distribution statistics of resource sensitivity weights in historical conflict data. For example, the sensitivity weight values ​​of all resources in the past 90 days are statistically analyzed, and the range of weight values ​​with the highest 20% (such as 0.8-1.0) is defined as the high sensitivity range.

[0145] The permission degradation gradient corresponding to the high sensitivity range is complete blocking of access, the medium sensitivity range (such as 0.5-0.8) is partial degradation (only allowing read) and the low sensitivity range (0-0.5) is logging only without blocking.

[0146] The resource storage location is extracted from the vertex attributes of the resource access path node. For example, resources marked as "local storage" in the vertex attributes are isolated from the path, and access is prohibited by remote protocols (such as HTTP) and only local protocols (such as the File protocol) are allowed.

[0147] Access protocols for highly sensitive resource paths are restricted to mandatory use of encrypted protocols. For example, access protocols for the resource path " / data / tenant_A / file1" are restricted to HTTPS or SFTP. If the request protocol is HTTP, the blocking rules of path isolation constraints will be triggered.

[0148] The time window information for triggering the policy on sequential edges is parsed from the "Trigger Time Window" field of the edge attribute in the graph database. For example, the time window recorded in the edge attribute is "2023-10-01 08:00:00 to 2023-10-01 18:00:00". The time-series blocking condition is configured to allow permission change requests only within the time window. For example, requests initiated outside the time window will be blocked and a violation log will be recorded.

[0149] The limit on the number of concurrent access requests is preset through the management interface. For example, the maximum number of concurrent requests allowed within the same time window is 10. Once this limit is exceeded, new requests will be temporarily blocked and queued.

[0150] During the combination of permission correction rules, permission degradation gradients, path isolation constraints, and time-series blocking conditions are integrated into a rule set based on the unique identifier of the resource access path node (such as "R_ / data / tenant_A / file1").

[0151] The rule set and the tenant identity are linked through a database foreign key. For example, the tenant identity “tenant_A” is associated with the rule ID “Rule_001”. The record corresponding to the rule ID contains detailed parameters of permission downgrade gradient, path isolation constraint and time sequence blocking condition.

[0152] The bound permission correction rules are stored in the "Permission Rules Table" of the relational database. The table structure fields include resource path (VARCHAR), tenant ID (VARCHAR), permission gradient (ENUM), protocol restriction (TEXT), and time sequence blocking condition (JSON).

[0153] After the rule takes effect, the zero-trust policy engine prioritizes matching the resource path and tenant ID when intercepting requests. If the rule is matched, it will execute blocking, demotion, or logging according to the permission gradient. For example, under the complete blocking gradient, it will directly return the HTTP 403 status code.

[0154] S7. Inject permission correction rules and trigger timing blocking conditions to perform hierarchical verification and isolation on cross-tenant operation requests, and add cross-tenant risk flags for failed verifications, including:

[0155] Inject the permission correction rules into the rule base of the zero-trust policy engine to trigger the real-time effect of the time-series blocking conditions;

[0156] Parse the resource access path and tenant identity in cross-tenant operation requests, and match them with permission degradation gradients and path isolation constraints in the rule base;

[0157] Based on the matching results, the request is subjected to hierarchical verification, with verification levels including complete blocking, partial demotion, and log monitoring only.

[0158] For requests that fail verification, trigger path isolation constraints and timing blocking conditions to block the corresponding access or limit concurrent operations;

[0159] Generate cross-tenant risk markers for failed verifications. The markers include the resource path that triggered the blocking, the tenant's identity, and the type of violation. The marker data is then associated with the corresponding node in the policy-dependent topology.

[0160] When permission correction rules are injected into the rule base of the zero-trust policy engine, the rule base is stored in a MySQL database table. The table structure includes resource path (VARCHAR 255), tenant identity (VARCHAR 50), permission degradation gradient (ENUM('completely blocked', 'partially degraded', 'log only')), path isolation constraint (TEXT), and time-series blocking condition (JSON).

[0161] The real-time effect of triggering the timing blocking condition is achieved by updating the status field of the rule base to "ACTIVE". The zero-trust policy engine polls the status field every 5 seconds and loads the rule immediately after detecting the "ACTIVE" status.

[0162] During the cross-tenant operation request parsing process, the resource access path is parsed from the URL path of the HTTP request. For example, when the URL is "https: / / api.example.com / data / tenant_A / file1", the parsed path is " / data / tenant_A / file1".

[0163] The tenant identity is extracted from the "sub" field of the JWT token. For example, if the token payload contains "{"sub": "tenant_A", ...}", "tenant_A" is extracted as the tenant identity.

[0164] Rule matching is achieved by executing SQL queries, such as executing "SELECT * FROM rule_table WHEREresource_path = ' / data / tenant_A / file1' AND tenant_id = 'tenant_A'" to obtain matching rules.

[0165] When performing graded verification, gradients are completely blocked from returning HTTP 403 and logged to the "block_log" table. Some downgraded gradients have their request permissions modified to read-only and HTTP 200 is returned. Only the gradients monitored by the log are logged to the "access_log" table but their requests are not modified.

[0166] The path isolation constraint verifies the request protocol. For example, if the rule restricts the request to HTTPS but the request protocol is HTTP, the request is blocked and "protocol violation" is recorded in the risk flag.

[0167] The timing blocking condition verifies the request timestamp. For example, if the rule time window is "08:00-18:00" and the request time is "20:00", the request is blocked and marked as "timeout".

[0168] The number of concurrent requests is limited by a Redis counter, for example, the counter key is "concurrent:tenant_A:20231001", the counter increments with each request, and after reaching the maximum value of 10, a new request returns an HTTP 429 error.

[0169] After the risk flag for the failed verification is generated, the data is inserted into the "risk_log" table, with fields including timestamp (DATETIME), resource_path (VARCHAR), tenant_id (VARCHAR), and violation_type (ENUM('protocol violation', 'timeout access', 'concurrency limit exceeded')).

[0170] When risk tags are associated with policy-dependent topology nodes, the graph database is queried based on resource_path and tenant_id to update the "risk_tags" attribute of the corresponding resource access path node, for example, by adding "timeout access: 2023-10-01 20:00:00".

[0171] The scheduled task uses the Quartz scheduler to synchronize the "risk_log" table data to the graph database every 30 minutes. During synchronization, nodes are associated using resource_path and tenant_id as foreign keys, and in case of conflicts, the latest tag overwrites the old data.

[0172] Example 2: Figure 2 A schematic diagram of the data space multi-tenant isolation system based on zero-trust architecture of the present invention is given. The data space multi-tenant isolation system based on zero-trust architecture includes:

[0173] Policy acquisition and parsing module: Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships;

[0174] Topology construction module: Based on policy triggering sequence and tenant resource sharing relationship, construct a policy dependency topology structure including tenant permission nodes, resource access path nodes and policy triggering sequence connection edges;

[0175] Resource weighting module: Dynamically assigns resource sensitivity weights to resource access path nodes based on tenant's historical access behavior;

[0176] Conflict node filtering module: Analyzes the logical coupling between the policy triggering sequence connection edge and the resource access path node, and filters conflict nodes with sensitivity weights higher than a preset threshold based on resource sensitivity weights;

[0177] Reverse backtracking separation module: Reverse backtracks the resource access path nodes of conflicting nodes, and separates independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology structure;

[0178] Permission rule generation module: Generates permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions;

[0179] Risk verification and marking module: Injects permission correction rules and triggers time-series blocking conditions, performs hierarchical verification and isolation on cross-tenant operation requests, and adds cross-tenant risk markings for failed verifications.

[0180] The above formulas are all dimensionless calculations. The formulas are derived from software simulations using a large amount of collected data, and are the closest to the real situation. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0181] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0182] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0183] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0184] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0185] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0186] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0187] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0188] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0189] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A data space multi-tenant isolation method based on zero-trust architecture, characterized in that, Includes the following steps: S1. Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships; S2. Based on the policy triggering sequence and tenant resource sharing relationship, construct a policy dependency topology structure that includes tenant permission nodes, resource access path nodes and policy triggering sequence connection edges. S3. Dynamically assign resource sensitivity weights to resource access path nodes based on tenants' historical access behavior; S4. Analyze the logical coupling between the strategy-triggered sequential connection edge and the resource access path node, and filter conflict nodes with sensitivity weights higher than the preset threshold based on the resource sensitivity weight. S5. Backtrack the resource access path nodes of the conflicting nodes and separate the independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology. S6. Generate permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions; S7. Inject permission correction rules and trigger timing blocking conditions to perform hierarchical verification and isolation on cross-tenant operation requests, and add cross-tenant risk flags for failed verifications.

2. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships, including: Parse the operation timestamp and policy trigger event type in the dynamic access policy change request, and generate a policy trigger sequence arranged in chronological order; Identify tenant identities and associated resource paths from policy-triggered event types, and extract shared resource access dependencies between tenants; Based on the timestamp order of the policy trigger sequence, a mapping table is established between policy trigger event types and shared resource access dependencies, generating structured data on policy trigger timing and tenant resource sharing relationships.

3. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, Based on policy triggering sequence and tenant resource sharing relationships, a policy dependency topology structure is constructed, including tenant permission nodes, resource access path nodes, and policy triggering sequence connection edges, including: Based on the timestamp order of the policy trigger sequence, create tenant permission nodes and mark the permission level and effective time range; Based on the associated resource paths in the tenant resource sharing relationship, generate resource access path nodes and mark the resource storage location and access permission type; Tenant permission nodes and resource access path nodes are associated with policy-triggered time-series connection edges to form a policy-dependent topology; Store the strategy-dependent topology in a graph database.

4. The data space multi-tenant isolation method based on zero-trust architecture according to claim 3, characterized in that, The policy triggering sequence connection edge includes the triggering time window and the permission change action type; Tenant permission nodes, resource access path nodes, and policy triggering sequence connections are represented as vertices, vertices, and edges, respectively.

5. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, Based on the tenant's historical access behavior, resource sensitivity weights are dynamically assigned to nodes along the resource access path, including: Extract resource access frequency and operation type from tenant's historical access behavior. Operation types include data query, modification, and deletion. The basic sensitivity weight is calculated based on the resource access frequency; the higher the resource access frequency, the greater the basic sensitivity weight. The basic sensitivity weights are adjusted based on the operation type, with the weighting coefficient for deletion operations being higher than that for modification operations, and the weighting coefficient for modification operations being higher than that for query operations. The weighted resource sensitivity weights are dynamically marked to the resource access path nodes and associated with the corresponding tenant identity and resource storage location.

6. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, The analysis determines the logical coupling between the timing-triggered connection edges and resource access path nodes, and uses resource sensitivity weights to filter conflicting nodes whose sensitivity weights exceed a preset threshold, including: The number of resource access path nodes associated with the timing connection edge triggered by the statistical strategy is counted, and the logical coupling degree between the timing connection edge triggered by the strategy and the resource access path node is calculated. The conflict risk value is calculated based on the logical coupling degree and the resource sensitivity weight. The conflict risk value is the product of the logical coupling degree and the resource sensitivity weight. Conflict nodes with a conflict risk value greater than a preset threshold are selected. The preset threshold is dynamically adjusted based on historical conflict data. The selected conflict nodes are associated with the corresponding policy triggering sequence connection edges and resource access path nodes to generate a set of conflict nodes.

7. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, By tracing back the resource access path nodes of the conflicting nodes, and separating independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology, including: Starting from the conflict node, traverse the policy dependency topology in reverse along the policy triggering sequence connection edge, and count the number of resource access path nodes directly associated with the current policy change request. Remove indirect resource access path nodes in the policy-triggered sequential connection edges that are not directly related to the current policy change request, and retain directly triggered resource access path nodes; Based on the overlap of the time windows between the directly triggered resource access path node and the policy triggering sequence connection edge, determine whether there is a direct dependency relationship with the current policy change request; By combining resource access path nodes that satisfy direct dependencies with associated policy-triggered sequential connection edges, structured data of independent resource access chains is generated.

8. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, Based on resource sensitivity weights, permission correction rules are generated, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions. Based on the numerical range of resource sensitivity weights, the permission downgrade gradient levels are divided. The higher the resource sensitivity weight, the more stringent the permission downgrade gradient. Path isolation constraints are generated based on the resource storage location and path of the resource access path nodes. The path isolation constraint rules include prohibiting access across storage locations and restricting access protocols for highly sensitive resource paths. Extract the time window information of the timing connection edge triggered by the strategy, and configure the timing blocking conditions. The timing blocking conditions include prohibiting permission change requests from being initiated outside the time window and limiting the number of concurrent access requests. The permission downgrade gradient, path isolation constraint, and time sequence blocking condition are combined into permission correction rules, which are then bound to the corresponding resource access path nodes and tenant identity identifiers.

9. The data space multi-tenant isolation method based on zero-trust architecture according to claim 1, characterized in that, Inject permission correction rules and trigger time-series blocking conditions to perform tiered verification and isolation on cross-tenant operation requests, and add cross-tenant risk flags for failed verifications, including: Inject the permission correction rules into the rule base of the zero-trust policy engine to trigger the real-time effect of the time-series blocking conditions; Parse the resource access path and tenant identity in cross-tenant operation requests, and match them with permission degradation gradients and path isolation constraints in the rule base; Based on the matching results, the request is subjected to hierarchical verification, with verification levels including complete blocking, partial demotion, and log monitoring only. For requests that fail verification, trigger path isolation constraints and timing blocking conditions to block the corresponding access or limit concurrent operations; Generate cross-tenant risk markers for failed verifications. The markers include the resource path that triggered the blocking, the tenant's identity, and the type of violation. The marker data is then associated with the corresponding node in the policy-dependent topology.

10. A data space multi-tenant isolation system based on zero-trust architecture, used to implement the data space multi-tenant isolation method based on zero-trust architecture as described in any one of claims 1-9, characterized in that, include: Policy acquisition and parsing module: Real-time acquisition of dynamic access policy change requests from multiple tenants, extraction of policy triggering sequence and tenant resource sharing relationships; Topology construction module: Based on policy triggering sequence and tenant resource sharing relationship, construct a policy dependency topology structure including tenant permission nodes, resource access path nodes and policy triggering sequence connection edges; Resource weighting module: Dynamically assigns resource sensitivity weights to resource access path nodes based on tenant's historical access behavior; Conflict node filtering module: Analyzes the logical coupling between the policy triggering sequence connection edge and the resource access path node, and filters conflict nodes with sensitivity weights higher than a preset threshold based on resource sensitivity weights; Reverse backtracking separation module: Reverse backtracks the resource access path nodes of conflicting nodes, and separates independent resource access chains that have a direct dependency relationship with the current policy change request based on the policy dependency topology structure; Permission rule generation module: Generates permission correction rules based on resource sensitivity weights, including permission downgrade gradients, path isolation constraints, and time-series blocking conditions; Risk verification and marking module: Injects permission correction rules and triggers time-series blocking conditions, performs hierarchical verification and isolation on cross-tenant operation requests, and adds cross-tenant risk markings for failed verifications.

Images