1. Using Oracle Autonomous Database Serverless
  2. Features
  3. Security
  4. Manage Encryption Keys on Autonomous Database
  5. Notes for Using Customer-Managed Keys with Autonomous Database

Notes for Using Customer-Managed Keys with Autonomous Database

Provides additional information and notes for using customer-managed keys with Autonomous Database

Parent topic: Manage Encryption Keys on 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.

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database

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.

    The database becoming inaccessible can take up to 15min after Oracle Cloud Infrastructure Vault key operations (Autonomous Database checks Oracle Cloud Infrastructure Vault at 15 minute intervals).

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

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database

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.

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database

Notes for Customer-Managed Keys with Autonomous Data Guard

Autonomous Data Guard is fully supported when using customer-managed keys with a standby database.

Note:

When you are using Oracle-managed keys you can only switch to customer-managed keys from the primary database. Likewise, when you are using customer-managed keys you can only rotate keys or switch to Oracle-managed keys from the primary database. The Manage encryption key option under More actions is disabled for a standby database.

Note the following when you are using Autonomous Data Guard with a standby database and customer-managed keys:

  • In order for a remote standby to use the same master encryption key as primary, the master encryption key must be replicated to the remote region. Replication of vaults across regions is only possible if you select the virtual private vault option when you create the vault.

    See the following for more information:

  • The primary database and the standby database use the same key. In the event of a switchover or failover to the standby, you can continue to use the same key.

  • When you rotate the customer-managed key on the primary database, this is reflected on the standby database.

  • When you switch from customer-managed keys to Oracle-managed keys the change is reflected on the standby database.

  • When the Oracle Cloud Infrastructure Vault is unreachable, there is a 2-hour grace period before the database goes into the INACCESSIBLE state. You can perform a failover during or after this 2-hour grace period.

  • If you disable or delete the Oracle Cloud Infrastructure master encryption key that your Autonomous Database is using with customer-managed keys while Autonomous Data Guard is enabled, Autonomous Data Guard does not perform an automatic failover.

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database

Notes for 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.

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database

Notes for Customer-Managed Keys with Vault in Remote Tenancy

To use customer-managed master encryption keys with a Vault in a remote tenancy, note the following:

When you use customer-managed master encryption keys with a Vault in a remote tenancy, the Vault and the Autonomous Database instance must be in the same region. To change the tenancy, on the sign-on page click Change tenancy. After you change the tenancy, make sure to select the same region for both the Vault and the Autonomous Database instance.

Parent topic: Notes for Using Customer-Managed Keys with Autonomous Database