Applies toOCI Vault (default and virtual private vaults), Key Management (HSM-protected and software-protected keys), OCI Dedicated KMS, OCI External KMS, customer-managed keys for Block Volume, Object Storage, Database services
1. Oracle-managed or customer-managed keys?
All OCI storage is encrypted at rest by default with Oracle-managed keys. Customer-managed keys (CMKs) in Vault add:
| Benefit | Cost |
|---|---|
| Control over key lifecycle (disable to cut access) | Key disabled or deleted = data unavailable (see the Vault Sev1 post) |
| Separation of duties, audit of key use | Policies, rotation and DR to manage |
| Some regulatory requirements | Some service features need extra steps with CMKs |
Use CMKs where policy or regulation requires them, or for data where you want an explicit "kill switch".
2. Vault options
| Option | What you get | When |
|---|---|---|
| Default vault | Keys in shared HSM partitions | Most CMK needs |
| Virtual private vault | Isolated partition on the HSM, higher limits | Isolation requirements, high key operation volume |
| Dedicated KMS | Single-tenant HSM cluster you control | Strict regulatory/key custody requirements |
| External KMS | Keys stay in your own third-party HSM outside OCI | Requirement that keys never reside in the cloud provider |
Each step up adds cost and operational responsibility. Check service support (not every service supports every key option).
3. Key protection mode
- HSM-protected keys: key material never leaves the HSM. The default choice for CMKs.
- Software-protected keys: lower cost, protected by an HSM-held root key, usable for client-side crypto. Suitable for less sensitive use.
4. Structure
- Vault per environment (prod/non-prod) per region at minimum; per business unit or regulated workload where separation is needed.
- Key per workload and data class (
orders-prod-db-tde,orders-prod-objstore). - Defined tags for owner, data classification, rotation policy.
5. IAM: separate admins from users
Allow group KeyAdmins to manage vaults in compartment security
Allow group KeyAdmins to manage keys in compartment security
Allow service blockstorage, objectstorage-<region> to use keys in compartment security where target.key.id = '<key-ocid>'
Allow dynamic-group orders-app to use keys in compartment security where target.key.id = '<key-ocid>'
- Key admins manage keys but don't need data access.
- Services and workloads get
use keysscoped to specific keys. - Deny-style protection: keep
manage keys(which includes delete) restricted to a small group, with alerts onScheduleKeyDeletionandDisableKeyevents.
6. Rotation
- Rotate keys on a schedule (manual rotation creates a new key version; auto-rotation is available for supported key types; check current support). Old versions stay available to decrypt existing data.
- Some services re-encrypt with the new version on next write or need an explicit re-key; know the behaviour for each service you use.
7. Backup and DR
- Cross-region vault replication (virtual private vaults) or key backup/restore to another region's vault so DR copies (replicated volumes, buckets, Data Guard standbys) can be decrypted there.
- Test a DR restore with CMK-encrypted resources. Missing key access in the DR region is a common drill failure.
Caution
Key deletion has a waiting period (days to weeks), after which the key and everything encrypted with it are gone permanently. Protect deletion with tight IAM, event alerts and a documented approval process.
Checklist
- CMK need decided per data class
- Vault option chosen (default, private, Dedicated KMS, External KMS)
- Vault/key structure with tags
- IAM separates key admins and users; deletion protected
- Rotation schedule and service behaviour known
- DR key availability tested