Cross-tenant data leakage isolation in multi-tenant databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud-based applications with multi-tenancy architecture are vulnerable to data leakage due to shared database resources, and existing solutions for cross-tenant isolation, such as physical or logical separation, are not scalable and efficient, especially as the number of tenants grows, and are prone to access control vulnerabilities.
Innovation Solution
Implementing a system with a global tenant table and a proxy that monitors and modifies database requests and responses to ensure that access is restricted to only permissible tenants, using a unique tenant ID for each table and enforcing strict access controls through a proxy deployed between the server and database, which modifies queries and responses to prevent unauthorized data access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If physical separation (different databases per tenant) is implemented, then cross-tenant data leakage is prevented, but device complexity and resource requirements increase significantly
Solution Approach 1:
The patent merges all tenant data into a single shared database instance, eliminating the need for multiple separate databases per tenant. This consolidation reduces infrastructure complexity while maintaining security through logical isolation mechanisms (tenant identifiers in queries and views) rather than physical separation.
Solution Approach 2:
The patent introduces intermediary layers including database views and application-level logic that mediate between tenants and the shared database. These intermediaries enforce tenant-specific access controls and data filtering, providing security without requiring physical database separation.
2Reliability
If logical separation (separate tables per tenant) is implemented, then cross-tenant data leakage is prevented, but scalability deteriorates as tenant numbers grow
Solution Approach 1:
The patent consolidates all tenant data into unified database tables rather than creating separate tables per tenant. This approach maintains scalability by avoiding the proliferation of database objects as tenants increase, while still providing logical isolation through tenant identifier filtering and view-based access control.
Solution Approach 2:
The patent applies local quality by incorporating tenant-specific identifiers and access control logic at the data row level rather than requiring separate table structures. Each data access operation is locally filtered by tenant context, enabling scalable multi-tenancy within shared tables.
3Ease of operation
If access controls are relaxed to allow tenant customization, then ease of operation improves, but data leakage vulnerability increases
Solution Approach 1:
The patent implements feedback mechanisms where the system continuously validates tenant identity and access permissions against the shared database structure. Access control logic dynamically adjusts query parameters and view definitions based on tenant context, providing both customization flexibility and security enforcement through active validation rather than static restrictions.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
A method and proxy device for cross-tenant data leakage isolation in a multi-tenant database are provided. The method includes monitoring, by a proxy device, traffic flows between a server executing at least one cloud-based application and the multi-tenant database, wherein the proxy device is communicatively connected between the server and the multi-tenant database; capturing, by the proxy device, at least a request to access the multi-tenant database, wherein the request is communicated using a database-specific protocol; analyzing the request to determine if the request is legitimate; upon determining that the request is not legitimate, modifying the request to point to a global-tenant table and to designate a unique tenant identifier, wherein the unique tenant identifier corresponds to a tenant-specific table name designated in the global-tenant table; and sending the modified request to the multi-tenant database using the database-specific protocol.