Oracle Cloud Infrastructure (OCI) Vault lets you to centrally manage and control use of keys and secrets across a wide range of OCI services and applications. OCI Vault is a secure, resilient managed service that lets you focus on your data encryption needs without worrying about time-consuming administrative tasks such as hardware provisioning, software patching, and high availability.
Key Management uses hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification, to protect your keys. You can create master encryption keys protected either by HSM or software. With the HSM- protected keys, all the cryptographic operations and storage of keys are inside the HSM. With the software-protected keys, your encryption keys are stored and processed in software, but are secured at rest with a root key from HSM.
OCI Vault and Oracle Key Vault are two key management products from Oracle.
OCI Vault—Key Management is a fully managed service and provides centralized management of your encryption keys to protect your data stored only in OCI. The vision of Key Management is to support different types of encryption keys—symmetric and asymmetric—and generic set of workloads including Oracle Database TDE and non-database workloads. OCI Vault is the native Gen2 Cloud encryption service.
Oracle Key Vault provides key management for TDE-enabled Oracle databases running in both on-premises (that includes Oracle Exadata Cloud@Customer and Oracle Autonomous Database—Dedicated) and OCI, as well as key management for encrypted Oracle GoldenGate trail files and encrypted ACFS file systems.
Oracle Managed is the default encryption for many OCI services. Oracle Managed means data will be encrypted at rest with an encryption key whose lifecycle management is controlled by Oracle. Customers who don’t want to manage or access their encryption keys and are looking for an easiest way to protect all their data stored in OCI can choose Oracle Managed encryption.
Customer-Managed encryption is offered by OCI Vault—Key Management service where the customer controls and manages the keys that protect their data. In addition, customers who require elevated security and FIPS 140-2 Level 3 protection to meet compliance choose Customer Managed as the encryption keys are stored in hardware security modules (HSMs).
OCI Vault is also defined as a logical grouping of-Keys. Vault must be created before any keys can be generated or imported.
There are two types of Vault: Virtual Private Vault and the default Vault. The type of Vault you create determines the degree of isolation and performance for your keys. Each tenant can have zero to many Vaults.
A Virtual Private Vault provides dedicated partition on the HSM (single tenant). A partition is a physical boundary on the HSM which is isolated from other partitions. Virtual Private Vault provides better and consistent transactions per second for cryptographic operations.
The default Vault uses a multitenant partition, so it has a moderate level of isolation.
1. Ensure that the limits for your tenancy allow for creation of the Vault type you intend to create.
2. Ensure that Oracle Identity and Access Management (IAM) policies have been created for the user account to have the necessary permissions to create a Vault. See IAM Policy Reference to construct a statement.
3. You first create a Vault by selecting Security from the Oracle Cloud Infrastructure Console, and then Vault.
Create a Vault and select from one of the two available Vault types that best fits your isolation and processing requirements:
4. Create the [Master Encryption] Key(s) inside your Vault. Master encryption keys can have one of two protection modes: HSM or software.
5. Ensure that IAM policies for the service or entity calling Vault has the necessary permissions.
Example: allow service objectstorage-us-ashburn-1 to use keys in compartment
Use the key(s):
Crypto operations are available in SDK and API as well. For more details, see Overview of Vault in the documentation.
6. Monitor your usage of operations with metrics in the console and Monitoring service. See the metrics and dimensions.
Virtual Private Vault limit is 0 by default. User should request for limit increase to use it. Once Virtual Private Vault is enabled, user gets a soft limit of 1000 and hard limit of 3000 symmetric key versions.
When you use the default Vault to store your keys, there is no hard limit. The default is 10 Vaults with 100 keys per vault.
All key versions you store in a Vault count towards this limit, regardless of the corresponding key being enabled or disabled.
The limits imposed on OCI Vault is governed by OCI service limits. Default limits are set for all tenancies. Customers can request a service limit increase for keys stored inside a Vault by following the steps in Requesting a Service Limit Increase of the Oracle Cloud Infrastructure documentation. As both enabled and disabled keys count towards the limit, Oracle recommends deleting disabled keys that you no longer use.
The following key management capabilities are available when you use the Vault service. For more details, see Overview of Vault in the documentation.
When you create a key, you can choose a key shape that indicates the key length and the algorithm used with it. All keys are currently Advanced Encryption Standard (AES - GCM), and you can choose from three key lengths: AES-128, AES-192, and AES-256. AES-256 are recommended.
Key Management is available in all Commercial and Government Oracle Cloud Infrastructure regions.
Yes. You can regularly rotate your keys in alignment with your security governance and regulatory compliance needs or ad hoc in case of a security incident. Regularly rotating your keys (for example, every 90 days) by using the Console, API, or CLI limits the amount of data protected by a single key.
Note: Rotating a key does not automatically re-encrypt data that was previously encrypted with the old key version; this data is re-encrypted the next time it’s modified by the customer. If you suspect that a key has been compromised, you should re-encrypt all data protected by that key and disable the prior key version.
Yes. You can import a copy of your key from your own key management infrastructure to Vault and use it with any integrated OCI services or from within your own applications.
Yes, but not immediately. You can schedule the deletion by configuring a waiting period from 7 to 30 days. The Vault and all the keys created inside the Vault are deleted at the end of the waiting period, and all the data that was protected by those keys is no longer accessible. After a Vault is deleted, it can’t be recovered.
Yes, but not immediately. You can schedule the deletion by configuring a waiting period from 7 to 30 days. You can also disable a key, which will prevent any encrypt/decrypt operations using that key.
You can directly submit data to Key Management APIs to encrypt and decrypt using your master encryption keys stored in the Vault.
Also, you can encrypt your data locally within your applications and OCI services using a method known as Envelope encryption.
With envelope encryption, you generate and retrieve Data Encryption Keys (DEK) from Key Management APIs. DEKs are not stored or managed in Key Management service but are encrypted by your Master Encryption Key. Your applications can use DEK to encrypt your data and store the encrypted DEK along with the data. When your applications want to decrypt the data, you should call decrypt to Key Management API on the encrypted DEK to retrieve the DEK. You can the decrypt your data locally with the DEK.
Key Management supports sending up to 4 KB of data to be encrypted directly. In addition, envelope encryption can offer significant performance benefits. When you encrypt data directly with Key Management APIs, it must be transferred over the network. Envelope encryption reduces the network load since only the request and delivery of the much smaller DEK go over the network. The DEK is used locally in your application or encrypting OCI service, avoiding the need to send the entire block of data.
Oracle uses a cluster of nodes and HSMs to store replica of your keys in the same region where they were created, which enables us to provide 99.9% SLA and 99.99 % SLO for Key Management. Please see Oracle PaaS and IaaS Public Cloud Services Pillar Document.
Yes. Key Management supports cross-region backup and restore for Virtual Private Vault so that keys can be used in a region different from where they were created. Backup and restore meets FIPS requirements as real key materials are not exported, rather a binary object that represents the key material. Restore operations can happen only to the OCI managed HSMs.
You are charged based on the type of Vault that’s created.
By default, your Vault is charged based on the number of key versions. Software-protected keys are free but HSM protected keys are charged 50 cents per key version. (first 20 key versions are free).
However, if you create a Virtual Private Vault (single-tenant HSM), you are priced per hour. The pricing starts from the time of creation of the Vault and continues until the vault is scheduled to be deleted. You are not charged for key versions within a Virtual Private Vault.
For more details, please refer to Oracle Cloud Security pricing.
No, you aren’t billed for the keys that are scheduled for deletion. If you cancel the deletion of your keys, then the billing resumes.
When you request the service to create a key with protection mode HSM, Key Management stores the key and all subsequent key versions in the HSM. Plain-text key material can never be viewed or exported from the HSM. With protection mode Software, keys are stored on Key Management servers but protected at rest by a root key from HSM.
Only users, groups, or services that you authorize via an IAM policy can use the keys by invoking Key Management to encrypt or decrypt data.
Yes. If you create a key with protection mode Software, the key material can be exported in plain text. However, if you create your keys with protection mode HSM, you cannot export the key material as the key never leaves the HSM. You are able to back up the key material in order to restore it the same or a different region. However, that backup does not give access to the key material.