Database Page Key Handling Under Tenant Key Revocation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-tenant database systems, the revocation of tenant-specific encryption keys renders encrypted data unrecoverable, leading to loss of tenant data and inefficiencies in resource management.
Innovation Solution
Implement a system where data pages include a tenant identifier in their headers, allowing decryption using database instance-specific keys, ensuring data recovery even if tenant-specific keys are revoked, and manage tenant lifecycle independently of database artifacts.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If tenant-specific encryption keys are used for each tenant's data, then data security and isolation are improved, but key management complexity and liability increase when keys are revoked
Solution Approach 1:
The patent segments the encryption key management by introducing a hierarchical structure with database-level encryption keys (DEKs) for each tenant and a master key encryption key (KEK). Each tenant's data is encrypted with their specific DEK, while the KEK encrypts the DEKs. This segmentation allows individual tenant keys to be managed independently, improving security isolation while providing a centralized mechanism through the KEK to handle key revocation without affecting other tenants.
Solution Approach 2:
The patent introduces the master key encryption key (KEK) as an intermediary between the database system and tenant-specific decryption keys. The KEK serves as a mediator that encrypts and protects all tenant DEKs in a unified key store. When key revocation is needed, the system can manage revoked keys through the KEK without requiring direct access to individual tenant keys, thereby reducing management complexity while maintaining security.
2Loss of energy
If a single database instance manages multiple tenants' data, then cost efficiency is improved, but data isolation and security are worsened
Solution Approach 1:
The patent applies local quality by implementing tenant-specific encryption keys (DEKs) for each tenant's data within the shared database instance. While the physical storage is consolidated in a single database instance for cost efficiency, each tenant's data pages are encrypted with their unique DEK, providing local security quality. The encryption metadata in data pages identifies the appropriate DEK, ensuring that data isolation and security are maintained at the tenant level even within a shared instance.
3Speed
If tenant-specific decryption keys are stored locally in the database, then decryption speed is improved, but security and control are worsened when key revocation is needed
Solution Approach 1:
The patent implements a nested key structure where tenant-specific DEKs are nested within the encrypted key store protected by the master KEK. The DEKs remain stored locally in the database for fast decryption access, while the KEK provides an additional layer of encryption and control. This nested structure allows the system to maintain decryption speed by keeping DEKs locally available while simultaneously improving key control through the KEK, which can revoke or manage access to all DEKs centrally when needed.
Data Source
AI summary
Systems and methods include storage of a plurality of encrypted data pages of a row store database table in a persistent storage system, determination of a first encryption key associated with one of the plurality of encrypted data pages based on a header of the one of the plurality of encrypted data pages, determination of whether the first encryption key has been revoked, and, if it is determined that the first encryption key has been revoked, adding of a portion of volatile memory allocated to the one of the plurality of data pages to a free list.