Notes for Using Customer-Managed Keys with Autonomous Database

Caution for Customer-Managed Encryption Keys when Oracle Cloud Infrastructure Vault is Unreachable

After you switch to customer-managed keys, some database operations might be affected when Oracle Cloud Infrastructure Vault is unreachable, as follows:

If the database is unable to access Oracle Cloud Infrastructure Vault for some reason, such as a network outage, then Autonomous Database handles the outage as follows:

  • There is a 2-hour grace period where the database remains up and running.

  • If Oracle Cloud Infrastructure Vault is not reachable at the end of the 2-hour grace period, the database Lifecycle State is set to Inaccessible. In this state existing connections are dropped and new connections are not allowed.

  • If Autonomous Data Guard is enabled, during or after the 2-hour grace period you can manually try to perform a failover operation. Autonomous Data Guard automatic failover is not triggered when you are using customer-managed encryption keys and the Oracle Cloud Infrastructure Vault is unreachable.

  • If Autonomous Database is stopped, then you cannot start the database when the Oracle Cloud Infrastructure Vault is unreachable.

    For this case, the work request shown when you click Work Requests on the Oracle Cloud Infrastructure console under Resources shows:

    The Vault service is not accessible. 
    Your Autonomous Database could not be started. Please contact Oracle Support.

Caution for Using Customer-Managed Encryption Keys When the Master Key is Disabled or Deleted

After you switch to customer-managed keys, some database operations might be affected if the Oracle Cloud Infrastructure Vault key is disabled or deleted.

  • For disable/delete key operations where the Oracle Cloud Infrastructure Vault Master Encryption Key State is any of the following:

    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION

    The database becomes Inaccessible after the Oracle Cloud Infrastructure Vault key lifecycleState goes into one of these states. When the Oracle Cloud Infrastructure Vault key is in any of these states, Autonomous Database drops existing connections and does not allow new connections.

  • If you disable or delete the Oracle Cloud Infrastructure Vault key used by your Autonomous Database while Autonomous Data Guard is enabled, Autonomous Data Guard will not perform an automatic failover.

  • If you enable a disabled key, the database automatically goes into the Available state.

  • If you delete the master key you can check the key history in the Oracle Cloud Infrastructure Console to find the keys that were used for the database. The history shows you which Oracle Cloud Infrastructure Vault key OCIDs were used, along with an activation timestamp. If one of the older keys from the history list is still available in the Vault, then you can restore the database to the time when the database was using that key, or you can clone from a backup to create a new database with that timestamp.

See View History for Customer-Managed Encryption Keys on Autonomous Database for more information.

Caution for Using Customer-Managed Encryption Keys History and Backups

After you switch to customer-managed keys, some database operations might be affected if the master key is rotated, disabled, or deleted and you do not have a valid key to restore your data from a previously saved backup or from a clone.

  • It is recommended that you create a new Vault key that hasn't been used for rotation in the last 60 days and use that for key rotation. This makes sure that you can go back to a backup if the current Vault key is deleted or disabled.

  • When you perform multiple encryption key rotations within 60 days, it is recommended that you either use Oracle Cloud Infrastructure Vault to create a new key for each master encryption key rotation operation or specify a vault key OCID that has not been used in the last 60 days. This helps to save at least one vault key that you can use to recover your data from a backup, in the case where a customer-managed master encryption key is disabled or deleted.

See View History for Customer-Managed Encryption Keys on Autonomous Database for more information.

Using Customer-Managed Keys with Autonomous Data Guard

Autonomous Data Guard is fully supported when using customer-managed keys with a local standby database. Customer-managed keys are not supported when Autonomous Data Guard is enabled with a cross-region standby.

  • If you are using Autonomous Data Guard with a local standby database and you do not enable an Autonomous Data Guard remote standby, when you select customer-managed keys the primary database and the local standby database use the same key. In the event of a switchover or failover to the local standby, you can continue to use the same key.

  • If you disable or delete the Oracle Cloud Infrastructure Vault key used by your Autonomous Database while Autonomous Data Guard is enabled, Autonomous Data Guard does not perform an automatic failover.

  • Switching to customer-managed keys is not allowed when Autonomous Data Guard is enabled with a remote standby.

  • Enabling Autonomous Data Guard with a remote standby is not allowed if the Autonomous Database is using customer-managed keys.

Using Customer-Managed Encryption Keys with Cloning

  • Autonomous Database does not support using customer-managed encryption keys with a refreshable clone. You cannot create a refreshable clone from a source database that uses customer-managed encryption keys. Additionally, you cannot switch to a customer-managed encryption key on a source database that has one or more refreshable clones.