Oracle Base Database Service encrypts data stored in tables and tablespaces using Transparent Data Encryption (TDE).

Transparent Data Encryption

The Base Database Service uses TDE to encrypt and decrypt all user-created tablespaces.

Encryption Keys

You can choose to encrypt the database using your own encryption keys ("customer-managed keys") or use Oracle-managed keys. By default, the Base Database Service uses Oracle-managed keys. The customer-managed key is stored in the OCI Vault, which is external to the database host.

OCI Vault Key

In the OCI Vault, the Encryption keys are logical entities that contain one or more key versions that are used for encryption and decryption. These key versions can be auto-generated by OCI Vault or imported from an external source (Bring-Your-Own-Key).

For more information, see Introduction to Transparent Data Encryption and OCI Vault Key Management.

Required IAM Policy

If you want to use your own encryption keys to encrypt a database, then you must create a dynamic group and assign specific policies to the group for customer-managed encryption keys. See Managing Dynamic Groups and Let security admins manage vaults, keys, and secrets topic in Common Policies.

While creating a new DB system, a key will be assigned to both the container database and pluggable database.

The key version, if provided, will only be used for the container database and not for its pluggable database. The pluggable database will be assigned an automatically generated new key version. Specific key versions cannot be assigned to the pluggable databases during creation.

The pluggable database will always use the same key as the container database, but with the same or a different key version.

You can specify any key version, including the latest version of the selected key.

By default, the database is configured using Oracle-managed keys. However, you can choose to configure it using customer-managed keys.

The rotate encryption key operation generates a new key version for the same key.

You can perform any number of key rotations. Periodically rotating keys limits the amount of data encrypted or signed by one key version. The history of retired keys is also maintained, which enables you to rotate the key and still be able to decrypt data that was encrypted by an earlier key.

The rotate key at container database and pluggable database levels works independently of each other. The rotate key operation on a container database will not rotate keys in the pluggable databases. Similarly, rotating keys in one pluggable database will not rotate keys in other pluggable databases or its container database.

To ensure you are using the latest version, rotate keys from the database details page on the OCI Console instead of the Vault service's Console page.

To rotate an encryption key using the OCI Console, see Rotate Encryption Key for a Database and Rotate Encryption Key for a Pluggable Database.

You can create and assign new key versions for both container databases and pluggable databases. Only the key version can be changed. The key cannot be changed.

To assign the key version using the OCI Console, see Assign a New Key Version for a Database and Assign a New Key Version for a Pluggable Database.

You can switch from Oracle-managed keys to customer-managed keys on existing databases. However, switching from customer-managed keys to Oracle-managed keys is not supported.

When a key is changed for a container database, it is also automatically applied to a pluggable database. The key of a pluggable database cannot be changed independently. The pluggable database will always use the same key as that of the container database, but they can use the same or a different key version.

When switching to customer-managed keys, the container database and all its pluggable databases must be open, and all tablespaces must be in read/write mode.

To change the key management type using the OCI Console, see Change Key Management Type for a Database.

The cloned database will use the same key version as the source database when cloning a DB system that uses customer-managed encryption keys.

The source and target databases must use the same key but can have a different key version. The remote cloning or relocating operation fails if the source and target databases use different keys.

The keys are rotated in the target key vault after remote cloning and relocation operations. So new key versions will be generated for the remote cloned or relocated pluggable database in the target database.