Transparent data encryption and Delphix

Overview

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.

• Delphix does not support Isolated keystore mode. In isolated mode, a pluggable database (PDB) has its own keystore and the keystore and its TDE master encryption keys can be managed from the PDB only. Only United keystore mode is supported.

• The dSource from which the initial provision is done must be encrypted when it is linked. If a dSource is encrypted after it is linked, a full backup must be taken and the resulting new dSource snapshot should be used for provisioning any TDE enabled vPDBs, otherwise provisioning will fail with ORA-28311: Oracle encrypted data block not encrypted (file # 1, block # 520).

• 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.

Delphix does not support converting an unencrypted vPDB/vCDB into an encrypted one. These will need to be recreated from a new snapshot that is generated after taking a full backup of the corresponding PDB dSource.

Definitions

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.

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:

1. The ENCRYPTION_WALLET_LOCATION parameter in sqlnet.ora.

2. 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 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.