US-12627488-B2 - Handling of database encryption key revocation

US12627488B2US 12627488 B2US12627488 B2US 12627488B2US-12627488-B2

Abstract

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.

Inventors

Beomsoo Kim
Yong Sik Kwon
Ji Hoon Jang
Hyeong Seog Kim

Assignees

SAP SE

Dates

Publication Date: 20260512
Application Date: 20221213

Claims (17)

1 . A database system comprising: a persistent storage system; a volatile memory; and a processing unit to execute program code of a database instance to cause the database system to: store a plurality of encrypted data pages of a row store database table at a database savepoint; detect a database restart and, in response to detection of the database restart: determine, based on a header of one of the plurality of encrypted data pages, a first encryption key used to encrypt a body of the one of the plurality of data pages; determine that the first encryption key has been revoked; in response to the determination that the first encryption key has been revoked, add a portion of the volatile memory allocated to the one of the plurality of data pages to a free list of the volatile memory; determine a plurality of encrypted undo data pages of uncommitted transactions of the database savepoint in the persistent storage system; determine, based on a header of one of the plurality of encrypted undo data pages, a third encryption key used to encrypt a body of the one of the plurality of encrypted undo data pages; determine that the third encryption key has been revoked; and in response to the determination that the third encryption key has been revoked, clear a body of the one of the plurality of encrypted undo data pages and provide the one of the plurality of undo data pages with the cleared body to a rollback mechanism of a database instance.
2 . A system according to claim 1 , wherein the processing unit is to execute program code of the database instance to cause the database system to: determine, based on a second header of a second one of the plurality of encrypted data pages, a second encryption key used to encrypt a second body of the second one of the plurality of data pages; determine that the second encryption key has not been revoked; in response to the determination that the second encryption key has not been revoked, decrypt the second body of the second one of the plurality of data pages using the second encryption key; and load a second data page comprising the second header and the second decrypted body in the volatile memory.
3 . A system according to claim 2 , wherein determination that the first encryption key has been revoked comprises determination that a key encryption key used to encrypt the first encryption key has been revoked.
4 . A system according to claim 3 , wherein determination that the key encryption key used to encrypt the first encryption key has been revoked comprises polling of a key management system storing the key encryption key.
5 . A system according to claim 1 , wherein determination that the first encryption key has been revoked comprises determination that a key encryption key used to encrypt the first encryption key has been revoked.
6 . A system according to claim 5 , wherein determination that the key encryption key used to encrypt the first encryption key has been revoked comprises polling of a key management system storing the key encryption key.
7 . A method comprising: storing a plurality of encrypted data pages of a row store database table in a persistent storage system at a database savepoint; detecting a database restart and, in response to detecting the database restart: determining, based on a header of one of the plurality of encrypted data pages, a first encryption key used to encrypt a body of one of the plurality of encrypted data pages; determining that the first encryption key has been revoked; in response to determining that the first encryption key has been revoked, adding a portion of volatile memory allocated to the one of the plurality of data pages to a free list; determining a plurality of encrypted undo data pages of uncommitted transactions of the database savepoint in the persistent storage system; determining, based on a header of one of the plurality of encrypted undo data pages, a third encryption key used to encrypt the one of the plurality of encrypted undo data pages; determining that the third encryption key has been revoked; and in response to determining that the third encryption key has been revoked, clearing a body of the one of the plurality of encrypted undo data pages and providing the one of the plurality of undo data pages with the cleared body to a rollback mechanism of a database instance.
8 . A method according to claim 7 , further comprising: determining, based on a second header of a second one of the plurality of encrypted data pages, a second encryption key used to encrypt a second body of the second one of the plurality of data pages; determining that the second encryption key has not been revoked; in response to determining that the second encryption key has not been revoked, decrypting the encrypted second body of the second one of the plurality of encrypted data pages using the second encryption key; and loading a second data page comprising the second header and the decrypted second body into the volatile memory.
9 . A method according to claim 8 , wherein determining that the first encryption key has been revoked comprises determining that a key encryption key used to encrypt the first encryption key has been revoked.
10 . A method according to claim 9 , wherein determining that the key encryption key used to encrypt the first encryption key has been revoked comprises polling a key management system storing the key encryption key.
11 . A method according to claim 7 , wherein determining that the first encryption key has been revoked comprises determining that a key encryption key used to encrypt the first encryption key has been revoked.
12 . A method according to claim 11 , wherein determining that the key encryption key used to encrypt the first encryption key has been revoked comprises polling a key management system storing the key encryption key.
13 . A non-transitory computer-readable medium storing program code executable by one or more processing units to cause a computing system to: store a plurality of encrypted data pages of a row store database table in a persistent storage system at a database savepoint; detect a database restart and, in response to detection of the database restart: determine, based on a header of one of the plurality of encrypted data pages, a first encryption key used to encrypt a body of one of the plurality of encrypted data pages; determine that the first encryption key has been revoked; in response to the determination that the first encryption key has been revoked, add a portion of volatile memory allocated to the one of the plurality of data pages to a free list; determine a plurality of encrypted undo data pages of uncommitted transactions of the database savepoint in the persistent storage system; determine, based on a header of one of the plurality of encrypted undo data pages, a third encryption key used to encrypt the one of the plurality of encrypted undo data pages; determine that the third encryption key has been revoked; and in response to the determination that the third encryption key has been revoked, clear a body of the one of the plurality of encrypted undo data pages and provide the one of the plurality of undo data pages with the cleared body to a rollback mechanism of a database instance.
14 . A medium according to claim 13 , the program code executable by one or more processing units to cause a computing system to: determine, based on a second header of a second one of the plurality of encrypted data pages, a second encryption key used to encrypt a second body of the second one of the plurality of data pages; determine that the second encryption key has not been revoked; in response to the determination that the second encryption key has not been revoked, decrypt a second body of the second one of the plurality of encrypted data pages using the second encryption key; and load a second data page comprising the second header and the decrypted second body into the volatile memory.
15 . A medium according to claim 14 , wherein determination that the first encryption key has been revoked comprises determination that a key encryption key used to encrypt the first encryption key has been revoked.
16 . A medium according to claim 15 , wherein determination that the key encryption key used to encrypt the first encryption key has been revoked comprises polling of a key management system storing the key encryption key.
17 . A medium according to claim 13 , wherein determination that the first encryption key has been revoked comprises determination of whether a key encryption key used to encrypt the first encryption key has been revoked.

Description

BACKGROUND Multi-tenancy is a software architecture pattern which facilitates the sharing of computing resources among disparate groups of users. For example, a single multi-tenant application (e.g., a Software-as-a-Service (SaaS) application) may serve multiple end user groups (i.e., customers) within a single software instance. Such a software instance uses a much smaller computing resource footprint than would be required to provision one software instance per customer. Multi-tenancy can therefore provide substantial cost benefits. The data of each customer in a multi-tenant architecture is typically mapped to a corresponding tenant in the underlying data layer. This mapping allows for logical separation of the data within the data layer and facilitates access thereto by the multi-tenant application. In some multi-tenant architectures, the data of each tenant is managed by a different database instance executing within a same computing system (e.g., a rack server). These architectures provide excellent separation of tenant data but it may be cost-inefficient in some scenarios to require a full database instance per tenant. For example, a smallest database instance may consume 32 Gb of memory, which may represent significantly more computing resources than should be required by a small tenant. Other multi-tenant data architectures use a single database instance to manage the data of multiple tenants. Since the data in such an architecture is not physically separated, the multi-tenant application is responsible for storing and managing the data in a tenant-aware manner. For example, a database system may use one schema of a single instance for all tenants, where the data of each tenant is partitioned via a discriminating column. The multi-tenant application uses the values of the discriminating column to identify the data belonging to specific tenants. In another example, the multi-tenant application associates a dedicated schema to each tenant. In either case, the database system is unaware of the existence of the multiple tenants and operates in the same manner as if it were being accessed by a single-tenant application. Data volumes and log segments of a database system may be persisted to disk. This data, which includes all the customer (i.e., tenant) data stored in the database system as well as data and metadata not specific to any customer, is conventionally encrypted using a key associated with the database system (i.e., a symmetric data encryption key) prior to storage thereof on disk. The data encryption key is generated by a provider of the database system is stored local to the database. Recent systems provide such database-instance-level encryption features on a tenant-level, where the data of each database tenant is encrypted with its own tenant-specific key. On restart or restoration from a backup, persisted data on the disk is decrypted using appropriate tenant-specific keys and loaded into memory. However, if one or more required tenant-specific keys are no longer available (e.g., due to revocation or other phenomena), the persisted data associated with those keys cannot be decrypted and is unusable by the database. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram of a database system providing handling of tenant-specific key revocation within a multi-tenant database according to some embodiments. FIG. 2 is a block diagram of database memory portions according to some embodiments. FIG. 3A illustrates an unencrypted data page including a tenant-identifying header portion according to some embodiments. FIG. 3B illustrates an encrypted data page including a key-identifying header portion according to some embodiments. FIGS. 4A and 4B include a flow diagram of a restart process for handling tenant-specific key revocation according to some embodiments. FIG. 5 is a block diagram of a database system providing native multi-tenancy and tenant-level encryption according to some embodiments. FIG. 6 is a block diagram of a cloud-based system according to some embodiments. DETAILED DESCRIPTION The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will be readily-apparent to those in the art. Generally, all database system data not actively being processed (i.e., data “at rest”) resides encrypted in persistent storage, where the data of each database tenant is encrypted with its own tenant-specific symmetric key. Data and metadata which is shared by all tenants (e.g., database catalog, users, shared containers) may be encrypted in persistent storage using a database instance-specific symmetric key. Such encryption may prevent data leakage and provide defense in case of a third-party breach. The keys may be customer-supplied and can be controlled (i.e., revoked) to prevent the database provider from accessing customer data. In a multi-tenant scenario, where the database system may include data of two or