How to manage encryption keys on Oracle Cloud

Why this matters

Oracle Cloud encrypts most block storage, object storage and managed databases at rest by default, with keys that Oracle holds. That ticks a box. It does not tell you who decrypted a bucket last Tuesday, and it does not let you cut off access to a volume when a laptop with a session token goes missing.

Customer-managed keys move that control to you. In OCI Vault you create a master encryption key, the key material stays inside a hardware security module, and IAM policy decides who may encrypt with it and who may only rotate or disable it. Oracle Cloud writes every Vault call to the Audit service, and disabling the key stops reads of the data it protects.

The hard part is ownership, not cryptography. Name one team that owns the vault, write down which resource uses which key, and keep the list of people who can decrypt short.

Before you start

Vaults are regional. Create a compartment for security work, separate from the compartments that hold workloads, and build the vault in the same region as the data. Run two regions and you plan two vaults. Check whether vault replication covers the services you use before you rely on it.

Pick the vault type with your eyes open. A default vault keeps keys in a shared HSM partition: fast to create, nothing to size. A virtual private vault gives you a dedicated HSM partition with predictable crypto throughput, takes longer to provision and costs more. Most teams start with the default and isolate a workload when a customer asks.

Write the IAM policies before the first key exists, and test them with a second admin user. If your only admin group cannot read keys in the new compartment, recovery turns into a support ticket. Keep a break glass group with manage keys that has two named members, and sign in with it once.

Do a short inventory. Block Volume, Boot Volume, Object Storage buckets, File Storage, Container Engine for Kubernetes, Autonomous Database and Database systems using Transparent Data Encryption all accept customer-managed keys. Note which already run on Oracle-managed keys, because those need a migration plan.

How to do it

Build the vault once, then add keys as data domains appear. One key per data domain keeps rotation intervals and access reviews honest. A single key for the tenancy means one policy mistake exposes everything.

Several services only accept a customer-managed key when the resource is created. Block Volume is the usual trap: an existing volume keeps its key for life, so moving it means copying the data to a new volume with the key set, then cutting over. Read the creation form before you plan a migration around a setting that is not there.

1. Create the security compartment and the vault. In the Console, open Identity and Security, then Vault, and create the vault in the compartment you reserved. Note both endpoints, the management endpoint and the crypto endpoint, because CLI and SDK calls use different ones.
2. Write the IAM policies before the first key. Create a group for key administrators and a group for the applications that need to encrypt. Grant manage keys in the security compartment to the admins and use keys to the application group, then sign in as each to prove the policy works.
3. Create one master encryption key per data domain. Name keys after the data they protect, such as finance-db-prod or audit-logs, and keep them in the security compartment. Set the protection mode and leave auto-rotation off until you have rotated a non-production key by hand.
4. Point new resources at the key. When you create a bucket, volume, file system or database, choose the customer-managed key option and select the key. For anything already running on Oracle-managed keys, plan a copy or restore into a new resource.
5. Keep key users away from key administration. Give application teams use keys only, scoped to the compartment that holds the key. Remember that manage keys includes use, so every key administrator can also decrypt.
6. Turn on rotation with an interval you can defend. Set auto-rotation on the master encryption key and write the interval next to the key owner. Rotation makes a new key version primary for new writes and leaves older versions enabled so existing data still decrypts.
7. Move secrets into the same vault. Store connection strings and API tokens as vault secrets with their own versions, and rotate them on a schedule. Applications read the secret at start, so a rotation does not need a redeploy.
8. Record each key, its owner and its resources. Keep a short table of key OCID, resource, owner and rotation interval, and check it before any deletion. Key deletion has a 7 to 30 day waiting period and then the data is unrecoverable.

How to check it worked

Open each resource and read the encryption line. A block volume shows the key OCID, an Object Storage bucket shows Customer Managed Key with the vault and key name, and an Autonomous Database shows the key in its details. If a resource still says Oracle managed, the attachment did not happen.

Run a negative test. Take a principal that should not touch the key, call oci kms crypto encrypt against the crypto endpoint, and confirm you get an authorization error instead of ciphertext. Repeat as a member of the application group and confirm success.

Check the Audit service for Vault events in the compartment that holds the vault. You should see key creation, encrypt and decrypt calls from the right principals. Rotate once by hand, confirm the new key version is primary and the old one still enabled, then decrypt a value the old version produced.

Finish with a restore. Back up one encrypted volume, restore it while the key is enabled, and mount it.

Mistakes to avoid

Disabling a key is not a test. It is an outage. Every volume, bucket and database that uses the key stops serving reads, and the application errors rarely mention encryption. Try it on a key that protects a scratch resource, and tell the on-call engineer first.

Deleting a key is permanent once the waiting period ends. OCI Vault gives you 7 to 30 days to change your mind; after that the key material is gone and so is the data. If you imported your own key material, the copy outside the HSM is now part of your recovery plan.

One key for everything is the other common failure. Every access review becomes a negotiation, and one rotation window covers unrelated systems. Tag each key with an owner, which turns a list of OCIDs into something a person can audit.

Watch the endpoints. Vault has a management endpoint for creating and rotating keys and a crypto endpoint for encrypt and decrypt. Samples that mix them produce errors that look like permission problems.

An outside read helps when the vault has outgrown its notes. The Cloud security review from Cloudverg is $6,500/month, a fixed scope of 2 to 3 weeks that covers encryption checks alongside identity and public exposure across up to 5 cloud accounts. It is one option next to an internal audit or a consultant-led review.

Frequently asked questions