12.3 OCI Vault Key Management: Vault Types, Protection Modes, Dedicated KMS & External KMS
Key Takeaways
A virtual private vault is an isolated partition on a hardware security module, while other vaults share HSM partitions; Key Management HSMs meet FIPS 140-2 Security Level 3.
An HSM-protected key cannot be exported from the HSM, while a software-protected key is stored on a server, encrypted by an HSM root key, and can be exported.
Automatic key rotation is available for keys in a virtual private vault, with a rotation interval between 60 and 365 days.
Dedicated KMS provides a customer-managed, single-tenant HSM partition as a service, with an HSM cluster of three automatically synchronized partitions.
External KMS keeps master encryption keys in a third-party key management system outside OCI, and OCI stores only key references.
Why Key Management Matters
All OCI storage services encrypt data at rest by default with Oracle-managed keys. Many regulations and security policies require more: control over who can use the keys, the ability to rotate or disable them, and proof of where they are stored. OCI Vault (the Key Management service) provides customer-managed keys for services such as Block Volume, Object Storage, File Storage, and databases. Keys are used only by the services and principals that IAM policies allow.
Vault Types
| Vault type | Isolation | Cost model | Notes |
|---|---|---|---|
| Virtual private vault | An isolated partition on an HSM, effectively a virtual independent HSM | Includes 1,000 key versions | Supports vault backup and automatic key rotation |
| Default (shared) vault | Shares HSM partitions with other vaults | Pay for key versions individually | A lower-cost choice when the extra isolation is not required |
Oracle's HSMs meet FIPS 140-2 Security Level 3: the hardware is tamper-evident, has physical tamper resistance, requires identity-based authentication, and deletes keys when it detects tampering.
Protection Modes
Each master encryption key has a protection mode, chosen at creation. It affects pricing and cannot be changed later:
| Protection mode | Where the key lives | Export | Where cryptographic operations happen |
|---|---|---|---|
| HSM | Stored on the HSM | Cannot be exported | Inside the HSM |
| Software | Stored on a server, encrypted at rest by an HSM root key | Can be exported | On the server, or on the client after export |
Key Algorithms
| Algorithm | Encrypt/decrypt | Sign/verify | Typical use |
|---|---|---|---|
| AES (symmetric) | Yes | No | Encrypting data in OCI services; secrets must use a symmetric key |
| RSA (asymmetric) | Yes | Yes | Wrapping keys, signing, image signing in OCIR |
| ECDSA (asymmetric) | No | Yes | Digital signatures |
Every vault also includes an RSA 4096-bit wrapping key used to wrap your own key material when you import keys (bring your own key, BYOK).
Envelope Encryption
Encrypting large volumes of data directly in an HSM would be slow. OCI services use envelope encryption: data is encrypted with a data encryption key (DEK), and the DEK is itself encrypted with your master encryption key (MEK) in Vault. Services such as Object Storage, Block Volume, and File Storage store only the encrypted DEK alongside the data. To read the data, the service asks Vault to decrypt the DEK, which requires IAM permission to use the MEK. Disabling the MEK therefore makes the data unreadable by the service.
Two rules come up in scenarios:
- Same region. An OCI service can use a master encryption key only when the service and the vault holding the key are in the same region. Cross-region copies, such as replicated volumes or copied backups, need a key in the destination region.
- Service authorization. The service itself must be allowed to use the key, for example
Allow service blockstorage, objectstorage-us-ashburn-1 to use keys in compartment Security where target.key.id = '<key-ocid>'.
Rotation and Key Versions
Rotating a key creates a new key version while the key's OCID stays the same, so services keep referring to the same key. New encryption uses the newest version, and older versions remain available to decrypt data they protected. For symmetric keys, the ciphertext records which version was used, so you do not need to track it; for asymmetric keys you must track which version encrypted or signed what.
Automatic rotation is available for keys in a virtual private vault. You set a rotation interval between 60 and 365 days and a start date. It works for HSM and software keys and for symmetric and asymmetric keys, the key must be enabled, and a failed rotation can trigger an event notification.
Disabling and Deleting Keys
- Disabling a key immediately stops its use for cryptographic operations; you can enable it again.
- Deleting a key is scheduled with a waiting period of 7 to 30 days (pending deletion), during which the deletion can be canceled. After deletion, data encrypted only with that key cannot be decrypted.
Resilience, Backup, and Replication
Vault keeps copies of keys across all availability domains in multi-AD regions (and across fault domains in single-AD regions), so keys stay available if an AD fails. For disaster recovery:
- Cross-region vault replication creates a replica of a vault in another region in the same realm. Creating, updating, deleting, and moving keys and key versions in the source vault are synchronized to the replica. Keys travel only as encrypted objects between FIPS 140-2 Level 3 HSMs, and Audit logs the start and deletion of replication. All private vaults support replication; some older virtual vaults do not.
- Backup and restore of virtual private vaults and keys can write encrypted backups to Object Storage or outside OCI.
Dedicated KMS
Dedicated KMS gives a customer-managed, highly available, single-tenant HSM partition as a service. The HSM cluster has three partitions by default, kept in sync automatically. You own the partition, its users, and its keys, and you manage them with client utilities and PKCS #11 libraries from OCI compute instances. Dedicated KMS supports HSM-protected keys only (no software keys) and AES, RSA, and ECDSA algorithms. Choose it when policy requires that you, not Oracle, administer the HSM partition.
External KMS: Hold Your Own Key
External KMS lets you keep master encryption keys in a third-party key management system hosted outside OCI. OCI stores only key references; the actual key material stays in the external system, and you can disable the keys at any time to cut off OCI's ability to decrypt. This addresses regulations that require keys to be stored outside any cloud provider's premises.
Choosing an Option
| Requirement | Best fit |
|---|---|
| Customer-managed keys at low cost | Default vault with HSM-protected keys |
| Isolation, vault backup, and automatic rotation | Virtual private vault |
| Customer administration of the HSM partition through PKCS #11 | Dedicated KMS |
| Keys must never be stored in OCI | External KMS |
A bank requires that its own security staff administer the HSM partition, users, and keys through PKCS #11 from OCI compute instances, with HSM-protected keys only. Which OCI option fits?
Dedicated KMS, a customer-managed single-tenant HSM partition
A default vault with software-protected keys and rotation
A virtual private vault with automatic key rotation enabled
External KMS, with keys held in an on-premises key manager
Block volumes in Ashburn are encrypted with a customer-managed key, and their volume group replicates to Phoenix. During a DR test, the team wants the activated volumes in Phoenix to use a customer-managed key as well. What must be in place?
The Ashburn key, because a key OCID works in every region of the realm
Oracle-managed keys only, because customer keys cannot be used with replication
A key in Phoenix, from a replica of the Ashburn vault or a Phoenix vault
A plaintext export of the HSM-protected Ashburn key imported into Phoenix
A security policy requires annual rotation of a master encryption key without changing the configuration of the many buckets and volumes that use it. What happens when the key is rotated?
Every resource must be updated to use a new key OCID after rotation
All data is re-encrypted at once with the new version, causing downtime
The old key version is deleted, so data must be restored from backup
A new key version is used for new encryption; older versions still decrypt
Sections you finish are checked off in the contents.