There are two options to manage your database encryption keys for the Autonomous Database on Dedicated Exadata Infrastructure,
1. Automatic lifecycle management of encryption keys via autonomous operations i.e. Oracle automation controlled key management
2. Customer controlled key management
Option #1 is self managing and there is nothing much to do for the service user. Let's talk about what customer controlled key means and how to go about using that option. Option #2 is for customers whose corporate security policies mandate tighter control of encryption keys.
Customer controlled key management option allows for 3 key features.
1. Master Encryption Key (MEK) generation is on a separate HSM based key management service in the Oracle Cloud Infrastructure.
2. Customer controls MEK lifecycle management and key rotation.
3. Access to MEK can be controlled using IAM policy based role separation.
Oracle Cloud Infrastructure (OCI) offers an HSM based service called the 'Vault' to manage all your keys, certificates and other secrets. OCI Vault runs on a FIPS-140 security level 3 certified HSM device to meet the highest security standard.
The autonomous database on dedicated exadata infrastructure provides integration with the OCI Vault service so that database master encryption keys may be generated and stored in the vault rather than on the database host.
How database encryption works?
All data in the Oracle autonomous database is encrypted in memory before being stored on disk or other persistent memory. This includes all data files, redo logs, backups and replication streams. The data encryption keys (DEK) are part of the data dictionary and are accessed frequently as data is read and written to the database. These keys are however encrypted and the master encryption key may be stored either in a PKCS#12 software wallet, or externally on an HSM device in the Vault service. In a cloud@customer deployment, master keys may be stored on-premises in the Oracle Key Vault a security hardened key management appliance.
To setup encryption key management in OCI Vault there are 3 things you need to do.
While this may seem like lot to do before you can start using externally managed keys, the idea is to provide enterprise customers the fine grained access control that most security policies mandate. Nothing is assumed. You, the customer decides which specific Exadata infrastructure has access to a vault or keys.
Note that the concept of a 'Key' in the OCI Vault service is similar to that of a 'wallet' i.e. each wallet can store numerous MEKs. Therefore, as a best practice, it recommended that each Autonomous Container Database have its own OCI Vault Key ( think wallet) which becomes a holder of all MEK for the container database (ACD) itself and all associated Autonomous Databases (ADBs).
Once the OCI Vault is setup with a Key, the IAM policies are in place and a network path is setup, you are ready to deploy container databases with customer managed keys in the OCI Vault. This choice of using Oracle Managed / Customer managed is to be made only at the ACD level. The PDB / ADB consumer does not need to worry about key management. This allows for a simpler end-user experience for an ADB user or developer who is simply interested in deploying applications and basic database lifecycle operations.
This Video tutorial and step-by-step lab guide provides all the details you need to start using Customer managed keys with your autonomous database on dedicated infrastructure.