Refreshing and rewinding a TDE-enabled vPDB

Just like a non-TDE-enabled vPDB, a TDE-enabled vPDB can be refreshed from the dSource or rewound to a previous snapshot or point in time. In each case, no additional manual steps or input from the user is required. The first step of a refresh or rewind operation is to disable the existing vPDB, which will result in a new keyfile exported to the artifact directory. The appropriate snapshot files are then mounted for the auxiliary database so that it can be recovered and brought to a consistent state. Since the vPDB is TDE-enabled, a keystore is needed for the recover operation. For a refresh, the Delphix Engine will use the parent keystore, and for a rewind, the Delphix Engine will use the target keystore, as shown below.

Overview of Key Rotation

Some customers have strict security compliance standards that mandate that production master keys cannot be shared into non-production zones. Delphix supports the ability to perform automated keystore sanitization of a vPDB. In simpler terms, Delphix allows provisioning a vPDB that has no previous production keys associated with it. A freshly provisioned vPDB will thus contain one and only one newly-set master encryption key that can be imported into the target CDB keystore to resolve TDE-plugin violations at the end of a provision job. Note that the tablespace encryption keys, which are themselves encrypted by the PDB key, are not rotated. In such a scenario, this new encryption key is expected to be the only key imported by the target container database (CDB) at the end of the provision job. It is important to note that Delphix does not re-encrypt the actual data files when the production master key is rotated.

There are two potential places for keys to be rotated in a vPDB environment:

1. dSource: If the dSource keys are rotated and a new snapshot taken with the new key, the customer is responsible for updating the parent keystore before refreshing from the later snapshot encrypted with the new key. The parent keystore would then contain both the new key and the original keys.

2. Target: If the target CDB keys are rotated, the target keystore will be updated. This is why the Delphix Engine uses the target keystore for rewind operations.

In either scenario, the keystore used for recovery will contain the current and all prior keys used to encrypt the datafiles and archive logs, for both the vPDB and CDB used in the auxiliary container.

vPDB encryption key management

During the provisioning process of a TDE-enabled vPDB, Delphix generates a unique encryption key for the vPDB. This unique key is not associated with the parent keystore to ensure that no keys from the parent are imported by the target. During refresh and rewind operations, Delphix reuses that key after recovery has finished. It is possible to customize the key that is used by updating the tdeKeyIdentifier parameter of the source via the CLI. If a valid key_id is entered for a key that is already present in the keystore, that key will be used as the active encryption key for the vPDB at the end of refresh/rewind. If the field is unset, Delphix will generate a new encryption key for the vPDB to be used from that point onward. This procedure is the same when using a vCDB, in which case Delphix will also generate a new unique encryption key for the vCDB that is reused for refresh and rewind, and which can be customized by updating the tdeKeyIdentifier parameter of the CDB source. See the CLI steps for Locating and Updating the Value of tdeEncryptionKey.