Introduction
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 keystore.
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-encrypted 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 but with plugin violations. Importing the keys is necessary to resolve the plugin violations and start up the PDB in a regular 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 in 6.0.6
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 toolkit 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 as of 6.0.6 has the following requirements:
- TDE-enabled vPDBs must be provisioned to a linked CDB, not a vCDB.
- Provisioning a RAC vPDB to a target environment which is discovered as a cluster environment in Delphix is not supported. Delphix supports provisioning a vPDB dSource to a target environment which is added as a standalone environment but could still be part of a cluster.
- The Oracle version must be 12cR2 or higher (12cR1 is not supported).
- System tablespaces (either in the CDB or PDB) must not be encrypted.
- Keystores must not be on ASM storage.
- Migration of a TDE-enabled VPDB from one CDB to another requires manual steps that must be completed for migrate VDB to be successful and to support refresh and rewind operations on the migrated vPDB.
- The location of the keystore must be configured in sqlnet.ora, as opposed to the wallet_root initialization parameter. This is true for the dSource as well as the target container. See Wallet Location Configuration below.
- 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 in 6.0.6 for approved customers.
Some or all of these restrictions may be relaxed in future versions of Delphix.
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 sqlnet.ora
The wallet_root initialization 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 only the configuration in sqlnet.ora via ENCRYPTION_WALLET_LOCATION, 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. This has implications for the configuration for Delphix, as the auxiliary container database used during provisioning will use the same home as the target container database. As a result, it is necessary that the path to the wallet be unique for each database, even though they are both using the same configuration file. This is accomplished by using an environment variable that is unique to each database, such as $ORACLE_UNQNAME or $ORACLE_SID. Such a specification in sqlnet.ora is required for Delphix in 6.0.6. 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.
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 copied from a user-specified location to the location specified in sqlnet.ora. The Delphix user does this copy. Thus, the Delphix user must have the necessary O/S privileges to read the parent keystore and the necessary O/S privileges to write into the wallet location. After the parent keystore is copied, Delphix will invoke Oracle commands to create an autologin wallet. 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 wallet location has group write privileges.
In Delphix version 6.0.6, these requirements are necessary for all Oracle versions. In Delphix version 6.0.7 and Oracle versions 18c or higher, the Delphix Engine will create a wallet location specifically to use the auxiliary database with the necessary permissions. Note that for Oracle version 12c the wallet location must have group write privileges for both 6.0.6 and 6.0.7.
Related Topics