Transparent data encryption and Delphix
Overview
The Oracle Transparent Data Encryption (TDE) feature encrypts the sensitive data (database tables and tablespaces) stored on the disk. This prevents misuse of the data if the disks or storage mediums are lost or stolen. The data is transparently decrypted for the authorized users when they access the data.
Data is encrypted with the help of encryption keys which are stored in an external module or file, known as the wallet or keystore. The keystore is managed by an authorized user and can be either a hardware or software keystore. In order to decrypt the data successfully, the encryption keys must be made available to the database by the authorized user.
In the Oracle database, the data is organized into tables that are located within a tablespace, which is in turn made up of one or more files on disk. With TDE either individual tables or an entire tablespace can be encrypted. The keys used to encrypt the data are stored within the database itself, in the data dictionary. The keys themselves are further encrypted using the wallet keys. By using 2 layers of encryption in this manner, access to all of the encrypted data can be achieved with just access to the keys in the keystone.
![](../../__attachments/131736629/tablespaces.png?inst-v=9f5cd9ef-94fe-4677-b3c4-6c5d1617af5c)
In the remainder of this document, the term key will refer to the master key stored in the external keystore, rather than the table keys stored in the data dictionary. In the case of a multi-tenant database, the same principle applies, namely that the keys are stored in the keystore which is located external to the database. However, not all of the PDBs within the container need to be encrypted. The CDB itself must always have a key associated with it, even if the CDB datafiles themselves are not encrypted. This is the case because Oracle will encrypt both the datafiles belonging to the PDB, as well as the archive logs, which are located in the CDB, as illustrated in the following diagram.
In the diagram below, PDBs 1 and 2 are encrypted, but PDB 3 is not. Note that the keystore contains all of the keys for the entire multitenant database, in this case, keys for the CDB, PDB 1, and PDB 2.
![](../../__attachments/131736629/PDBs%20encrypted.png?inst-v=9f5cd9ef-94fe-4677-b3c4-6c5d1617af5c)
In order to unplug a TDE-enabled PDB, the key(s) for that PDB must be exported from the keystore into a new file, known as an exported keyfile. Oracle will prevent the PDB from being unplugged unless the keys have first been exported. The exported keyfile is encrypted with a password (known as the keyfile secret) that is specified during the export. The diagram below illustrates the scenario where PDB 2 has been unplugged. Note that the key for PDB 2 still remains in the keystore. This illustrates an important point about Oracle keystores - once added, a key cannot be easily removed from a keystore.
![](../../__attachments/131736629/TDE-key-diagram2.png?inst-v=9f5cd9ef-94fe-4677-b3c4-6c5d1617af5c)
You can plug back a PDB into a new CDB before importing the new keys. This results in the PDB being plugged in in restricted mode with plugin violations. Importing the keys is necessary to resolve the plugin violations and start up the PDB in unrestricted READ WRITE mode.
The design of TDE allows for the keys for a given CDB or PDB to be changed, via the ADMINISTER KEY MANAGEMENT SET KEY
command. This process is known as key rotation and will update the master encryption key in the keystore while leaving the table keys in the data dictionary. The table keys themselves will be encrypted with the new master encryption key, and any future updates to that data will use the new key. Existing data already written to the datafile or archive log will still be encrypted with the original key, however. For this reason, keys are never removed from an existing wallet, only new keys are added. To decrypt all of the data in a given database, all current and prior keys will be needed.
For more information on TDE and how it is configured and enabled, see the Oracle documentation.
Oracle TDE support for external key managers
Oracle database provides a comprehensive key management framework designed for TDE. This framework facilitates the storage and management of keys and credentials.
The key management capabilities within the Oracle database encompass support for various options, including software keystores, Oracle Key Vault (OKV), and other devices or key management applications compatible with the PKCS#11 standard. This diverse range of key management solutions provides you with the flexibility and choice to tailor your TDE implementations according to your security and operational requirements.
The below image illustrates the types of keystores that the Oracle database supports.
![TDE with EKM.png](../../__attachments/131736629/TDE%20with%20EKM.png?inst-v=9f5cd9ef-94fe-4677-b3c4-6c5d1617af5c)
Delphix has introduced compatibility with External Key Managers (EKMs) for Oracle Multitenant databases. This enhancement will allow you to leverage robust key management solutions like OKV and Hardware Security Modules (HSMs) to enhance the security of your sensitive data and use Delphix Continuous Data Engine workflows to create virtual data copies and accelerate project deliveries.