So far, I have discussed generic security concepts, IAM and Networking pertains to OCI Gen-2 Cloud. In this part I am going to discuss the Key Management Service that is available in Oracle Cloud Infrastructure OCI Gen-2 Cloud.
Oracle Cloud Infrastructure Key Management Service OCI KMS is a managed service that provides you with centralized management of the encryption of your data. KMS can be used to create master encryption keys and data encryption keys. KMS helps to rotate keys to generate new cryptographic material, enable or disable keys for use in cryptographic operations, assign keys to resources, and use keys for encryption and decryption.
OCI Object Storage and OCI Block Volume integrate with KMS to support encryption of data in buckets and block or boot volumes. Integration with OCI Identity and Access Management (IAM) lets you control who and what services can access which keys and what they can do with those keys. OCI Audit integration gives you a way to monitor key usage. Audit tracks administrative actions on keys and vaults.
Keys are stored on highly available and durable hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification. KMS uses the Advanced Encryption Standard (AES) as its encryption algorithm and its keys are AES symmetric keys. This means that the HSM hardware is tamper-evident, has physical safeguards for tamper-resistance, requires identity-based authentication, and deletes keys from the device when it detects tampering.
Key Management Concepts
Keys are logical entities that represent one or more key versions that contain the cryptographic material used to encrypt and decrypt data, protecting the data where it is stored. When processed as part of an encryption algorithm, a key specifies how to transform plain-text into cipher-text during encryption and how to transform cipher-text into plain-text during decryption. KMS recognizes two types of encryption keys – Master Keys and Data Encryption Keys. Master encryption keys are created using the Console or API. KMS stores those keys in a key vault. After you have a master encryption key, you can then use the API to generate data encryption keys. KMS introduces master encryption keys as an OCI resource.
Key vaults are logical entities where KMS creates and durably stores keys. Vaults are partitions on a hardware security module that are isolated from one another to ensure the security and integrity of the encryption keys that are stored on them. The type of vault determines features and functionality such as degrees of storage isolation, access to management and encryption, scalability, and pricing. One virtual private vault can be created in each tenancy. KMS designates vaults as an OCI resource.
Each master encryption key is automatically assigned a key version. Rotation of keys results in KMS generating a new version. Periodically rotating keys limits the amount of data encrypted by one key version. Key rotation thereby reduces the risk if a key is ever compromised. A key’s unique, Oracle-assigned identifier, called an Oracle Cloud ID (OCID), remains the same across rotations, but the key version enables KMS to seamlessly rotate keys to meet any compliance requirements. Older key versions cannot be used for encryption after you rotate it, the key version remains available to decrypt any data that it previously encrypted. KMS removes the need to track which key version was used to encrypt what data because the key’s cipher-text contains the information that KMS requires for decryption.
Hardware Security Modules
Upon creation of a master encryption key, KMS stores the key version within a hardware security module (HSM) to provide a layer of physical security. Any given key version, after it’s created, is replicated within the service infrastructure as a measure of protection against hardware failures. Key versions are not otherwise stored anywhere else and cannot be exported from an HSM. Key Management uses HSMs that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification. This means that the HSM hardware is tamper-evident, has physical safeguards for tamper-resistance, requires identity-based authentication, and deletes keys from the device when it detects tampering.
The data encryption key used to encrypt your data is, itself, encrypted with a master encryption key. This concept is known as envelope encryption. OCI services do not have access to the plain-text data without interacting with Key Management and without access to the master encryption key that is protected by OCI Identity and Access Management (IAM). For decryption purposes, Object Storage and Block Volume store are the only the encrypted form of the data encryption key.
Key Management – Design Considerations
- Regional service, replicates encryption keys across 3 ADs in a region
- Block Volumes and Object Storage are integrated with KMS
- 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
- You cannot import a key from your existing key management solution to Oracle Key Management. You cannot export encryption keys from the Oracle Key Management key vaults
- You cannot delete keys, but can disable them. You can delete key vaults
- You can schedule the deletion of a key vault by configuring a waiting period for deletion from 7 – 30 days
- The key vault and all the keys created inside the key 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 key vault is deleted, it can’t be recovered
In this article I have discussed the Key Management Service that is available in the OCI that helps protecting the OCI resources. This article defines the various concepts in the Key Management Service and the best practices to follow to achieve the necessary security in OCI.
I will discuss the Edge Security in OCI in the next article and that would be the fifth and final of this series.