Oracle Cloud Infrastructure Documentation

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 the Key is Unreachable

After you switch to customer-managed keys, some database operations might be affected when the key is unreachable.

If the database is unable to access your key 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 the key 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 when using Oracle Cloud Infrastructure Vault, 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.

    Note

    Only Oracle Cloud Infrastructure Vault is supported with Autonomous Data Guard.

  • If Autonomous Database is stopped, then you cannot start the database when the keys are unreachable.

    For this case, the work request shown when you click the Work requests tab on the Autonomous Database details page on the Oracle Cloud Infrastructure Console 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 master key is disabled or deleted.

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

    Key Vault Key State
    Oracle Cloud Infrastructure (OCI) Vault
    • DISABLING
    • DISABLED
    • DELETING
    • DELETED
    • SCHEDULING_DELETION
    • PENDING_DELETION
    AWS Key Management System (KMS)
    • Disabled
    • PendingDeletion
    Azure Key Vault
    • DISABLED
    • DELETED
    Oracle Key Vault (OKV)
    • COMPROMISED
    • DEACTIVATED
    • DESTROYED

    The database becomes Inaccessible after the key Lifecycle state goes into one of these states. When the 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 15 min after the key operations (Autonomous Database checks the key provider 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.

    Note

    Only Oracle Cloud Infrastructure Vault is supported with Autonomous Data Guard.

  • 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 the key name, along with an activation timestamp. If one of the older keys from the history list is still available, 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 key that hasn't been used for rotation in the last 60 days and use that key for rotation. This makes sure that you can go back to a backup if the current key is deleted or disabled.

  • When you perform multiple encryption key rotations within 60 days, it is recommended that you either create a new key for each master encryption key rotation operation or specify a key that has not been used in the last 60 days. This helps to save at least one key 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.

Notes for Customer-Managed Keys in OCI Vault with Autonomous Data Guard

Autonomous Data Guard is supported when using customer-managed keys with the key provider Oracle Cloud Infrastructure Vault.

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 on a standby database.

Note the following when you are using Autonomous Data Guard with a standby database with 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.

    Customer-Managed Encryption Keys are only supported with a single cross-region Autonomous Data Guard standby. Multiple cross-region standbys are not supported because Oracle Cloud Infrastructure Vault only supports replication to one remote region.

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

  • Customer-Managed Encryption Keys are not supported with Cross Tenancy Autonomous Data Guard.

See the following for more information:

Notes for Customer-Managed Encryption Keys with Refreshable Clones

Lists limitations and notes for using customer-managed keys with refreshable clones.

Note

The option to use customer-managed keys with a refreshable clone is only available when the source database uses the ECPU compute model.

Same Region Refreshable Clone with Source Using Customer-Managed Encryption Keys Notes

Autonomous Database supports using customer-managed encryption keys with a refreshable clone in the same region, as follows:

  • When the source database uses customer-managed keys, you can create one or more local (same region) refreshable clones. The refreshable clones use the same customer-managed keys as the source database and do not support the option to independently select a different key or to change the key type on refreshable clones.

  • All of the supported customer-managed key providers are supported for a same region refreshable clone, including: Oracle Cloud Infrastructure Vault, Microsoft Azure Key Vault, Amazon Web Services (AWS) Key Management Service (KMS), and Oracle Key Vault (OKV).

    See About Master Encryption Key Management on Autonomous Database for more information.

  • You can change the key type or rotate the key on the source database when the source database has one or more local refreshable clones. In this case, after the source database is switched to a different key type or its key is rotated, a refreshable clone keeps using the existing old key. After a refreshable clone is refreshed, the refreshable clone switches to use the new source key type or to use the rotated key.

  • When provisioning a refreshable clone from a source using a customer-managed key, the dynamic groups and policies must cover the refreshable clone so that the refreshable clone can access the key as well. If the dynamic groups and policies do not include the refreshable clone, provisioning fails. Similarly, if the source already has a refreshable clone and is switching from Oracle-managed keys to customer-managed keys, the switch will not be successful if the dynamic groups and policies do not include the refreshable clone.

    See Prerequisites for Creating a Refreshable Clone for more information.

See Create a Refreshable Clone for an Autonomous Database Instance for more information.

Cross-Region Refreshable Clone with Source Using Customer-Managed Encryption Keys Notes

Autonomous Database supports using customer-managed encryption keys with a cross-region refreshable clone, as follows:

  • When the source database uses customer-managed keys, you can create one cross-region refreshable clone. The refreshable clone uses the same customer-managed keys as the source database and does not support the option to independently select a different key or to change the key type on the refreshable clone.

    In this case, only OCI Vault is supported for the cross-region refreshable clone and the source's key must be replicated in the remote region.

  • The supported customer-managed key provider with a cross-region refreshable clone is: Oracle Cloud Infrastructure Vault.

    See About Master Encryption Key Management on Autonomous Database for more information.

  • When a cross-region refreshable clone uses a customer-managed key, the dynamic groups and policies must cover the refreshable clone. If the dynamic groups and policies do not include the refreshable clone, provisioning fails. Similarly, if the source already has a refreshable clone and is switching from Oracle-managed keys to customer-managed keys, the switch will not be successful if the dynamic groups and policies do not include the refreshable clone.

    See Prerequisites for Creating a Refreshable Clone for more information.

See Create a Cross Tenancy or Cross-Region Refreshable Clone for more information.

Cross Tenancy Refreshable Clone with Source Using Customer-Managed Encryption Keys Notes

Autonomous Database does not support using customer-managed encryption keys with a cross tenancy refreshable clone.

See Create a Cross Tenancy or Cross-Region Refreshable Clone for more information.

Restore Source Database with a Refreshable Clone Using Customer-Managed Encryption Keys Notes

If a source database has a refreshable clone and the source database is restored from backups, the source database will start using the key that was in use at the point in time when the source database was restored.

In this case, consider the following cases:

  • If the refreshable clone was lagging and its refresh point was before the restore point, meaning the refreshable clone had data that was older than the restored source database, it will start using the same key as the source database after the next refresh (a refresh recreates the refreshable clone from the source database).

  • If the refreshable clone's refresh point was later than the restore point, meaning the refreshable clone had more recent data than the restored source database, the refreshable clone is automatically recreated when it reaches the same point in time with refreshes. At that time, it should start showing the same key as the source.

See Restore and Recover your Autonomous Database for more information.

Disconnected Refreshable Clone Using Customer-Managed Encryption Keys Notes

If a refreshable clone with a source database using customer-managed keys is disconnected, the refreshable clone can reconnect to the source database. If while the refreshable clone is disconnected from the source, the key on the source database changes, the refreshable clone switches to use the new key when the refreshable clone is reconnected and refreshed.

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.