The Oracle Transparent Data Encryption 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.
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.
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.
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. In order 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.
Delphix implementation of TDE
Oracle recommends that the keystore be stored on a separate disk from the datafiles. In accordance with this recommendation, neither keystores nor exported keyfiles are stored on Delphix storage. Rather, they are placed on customer storage. Exported keyfiles generated by Delphix are stored in the artifact directory under the keystores root directory, while keystores generated by Delphix are stored in the location specified by sqlnet.ora for the target container database. It is the customer's responsibility to maintain these storage locations and ensure they are backed up as needed, just like database files. If the keystore or exported keyfile is lost, the data in the associated vPDB may not be recoverable and the vPDB will cease to operate.
Delphix support for TDE has the following requirements:
The Oracle version must be 12cR2 or higher (Oracle 12cR1 is not supported).
Parent keystores of the source PDB must not be on ASM storage. Target CDB keystores, however, can be on ASM storage.
Migration of a TDE-enabled vPDB from one CDB to another requires manual steps that must be completed for migrate vPDB to be successful and to support refresh and rewind operations on the migrated vPDB.
Only software keystores on the same host as the database files are supported, in particular, Oracle Key Vault is not supported.
The dSource from which the initial provision is done must be encrypted when it is linked. Existing dSources can not be encrypted without unlinking and creating a new dSource.
There is currently no supported transition path from existing TDE-enabled vPDBs using the TDE workaround to the full product solution. The TDE workaround continues to be supported for approved customers.
For linked provisions, the target container database should have an autologin Keystore configured. For a cluster target, the autologin keystore is shared. For vCDB provisions, Delphix will create an autologin Keystore when configuring the vCDB Keystore.
Some or all of these restrictions may be relaxed in future versions of Delphix.
The following terms are used throughout TDE documentation and are summarized here for clarity. Note that the first occurrence of these terms may be on other documentation pages.
File found on the Oracle host which stores the keys used to encrypt and decrypt the internal table keys in a database. Every keystore has a password which is set when it is first created, and must be supplied for operations on it.
Keystore with the keys used to encrypt the dSource PDB files.
Keystore for the target CDB into which the TDE-enabled vPDB is plugged.
Directory on the target system (not on Delphix storage) which stores keys needed to support Delphix workflows on TDE-enabled vPDBs. It is located under the keystores root directory.
File located on the target Oracle host which contains keys that have been exported from the keystore. It is encrypted with a secret that is specified when it is exported. The exported keyfile itself cannot be used as a keystore, but its contents can be imported into a new keystore.
Process for changing the master encryption key in the keystore via the
Auxiliary container database (CDB)
Provisioning an Oracle vPDB requires running recovery to bring the snapshotted datafiles into a consistent state. This needs to be done in the context of a container database, which is created on the target system. After recovery is complete, the vPDB is unplugged and plugged into the target container, and the auxiliary container is deleted.
Password used to encrypt an exported keyfile.
Keystores root directory
User-specifiable location on the target system under which all TDE related artifacts such as keystores and exported keyfiles created by Delphix are stored. This includes both the artifact directories used for vPDBs and temporary directories used for auxiliary CDB keystores.
Wallet location configuration
Oracle requires that the keystore location be specified to the database so that it can be accessed when reading from or writing to the database files. This location can be specified in 2 ways:
The ENCRYPTION_WALLET_LOCATION parameter in
wallet_rootinitialization parameter is available starting in Oracle 18, while ENCRYPTION_WALLET_LOCATION is available in Oracle 12.2. Oracle has indicated that support for ENCRYPTION_WALLET_LOCATION will end starting with Oracle 20.
Delphix supports both configurations for the appropriate releases (i.e. ENCRYPTION_WALLET_LOCATION only in 12.2, and both ENCRYPTION_WALLET_LOCATION and
wallet_root in 18+). When using ENCRYPTION_WALLET_LOCATION, Delphix recommends referencing an environment variable, for example:
Encryption wallet location
ENCRYPTION_WALLET_LOCATION= (SOURCE= (METHOD=FILE) (METHOD_DATA= (DIRECTORY=/u03/app/ora12201/admin/$ORACLE_UNQNAME/wallet/)))
As there is only one
sqlnet.ora file found under $ORACLE_HOME, it will be used for all databases that use that home. Specifying an environment variable such as $ORACLE_UNQNAME allows a different location for each database in the same $ORACLE_HOME. Any environment variable referenced in
sqlnet.ora must always be set in the environment for the Oracle user. Delphix explicitly sets only $ORACLE_HOME, $ORACLE_SID, and $ORACLE_UNQNAME in the connections which are established by the Delphix engine, so it is recommended that only these variables be referenced in
sqlnet.ora. For a 12.2 TDE vPDB provision, Delphix creates a unique
sqlnet.ora file for the use of the auxiliary database during the provision. For provisions to vCDB targets, Delphix will set the
wallet_root parameter to a user-provided path for versions 18c or higher and will use the path in
sqlnet.ora for version 12.2.
Required O/S permissions for the Delphix user
The provision itself is executed within the context of the environment user specified during the provision. This user does not have to be the Oracle user, and in fact, often is not. The Delphix user must be a member of the oracle group. During a TDE-enabled vPDB provision, the parent keystore is merged from a user-specified location to a location under the keystores root directory. The Delphix user does this copy via
ADMINISTER KEY MANAGEMENT command. Since the Oracle user will do this, the Oracle user must be able to also create files in the wallet location.
The privilege requirements are satisfied by ensuring that the parent keystore has group read privileges, and the keystores root directory (owned by the Delphix user) has group write privileges.