When building a cyber vault, one of the most important items to manage is encryption keys. Encrypting your data is a fundamental pillar of ransomware protection, but encryption key management is often forgotten.
Ensuring your Cyber Vault has a current copy of your encryption keys associated with your Oracle Databases is critically important for a successful restore and recover after an attack.
Starting with the Oracle Key Vault (OKV) 21.11 release, Oracle Key Vault includes a preview of the Key Transfer Across Oracle Key Vault Clusters Integration Accelerator. You can use this feature to transfer security objects from one OKV cluster to another.
You can find more detail on this feature here, and I will describe it's benefits in this post.
The diagram below shows a typical cyber vault architecture to protect Oracle Databases with the Zero Data Loss Recovery Appliance (ZDLRA) and OKV .
 |
| Transferring keys into a cyber vault with OKV |
Encryption Key Architecture
Encryption key management is a critical piece of data protection, and it is important to properly manage your keys. Good cyber protection begins with proper encryption key management.
Local Wallets
With Oracle databases, the default (and simplest) location for encryption keys is in a locally management wallet file. The keys are often stored in an auto-login wallet, which is automatically opened by the database at startup making key management transparent and simple, but not very secure.
Why aren't wallets secure ?
- They are often auto-login (cwallet.sso) which allows the database to open the wallet without requiring a password. This wallet file gives full access to the encryption keys.
- The wallet file is stored with the database files. A privileged administrator, such as a DBA has access to both the database and the keys to decrypt the data directly from the hosts. They also have the ability to delete the wallet file.
- Often the wallet file is backed up with the database, which includes an auto-login wallet. This allows anyone who has access to backups, to also be able to decrypt the data.
- Securely backing up the wallet file separate from the database is often forgotten, especially when ASM is used as the wallet location. Not having the wallet file when restoring the database makes restoration and recovery impossible.
Steps you can take
- Create both a passworded wallet (ewallet.p12) and local auto-login wallet (cwallet.sso). With a local auto-login wallet, the wallet can only be opened on the host where the wallet was created.
- Backup the passworded wallet only (ewallet.p12). The auto-login wallet can always be recreated from the passworded wallet.
- Properly store the password for you passworded encryption wallet. You will need the password to rotate your encryption keys, and create the auto-login wallet.
Oracle Key Vault (OKV)
The best way to securely manage encryption keys is with OKV.
Why ?
- Keys are managed outside of the database and cannot be accessed locally outside of the database.
- Access to keys is granted to a specific database instance.
- OKV is clustered for High Availability, and the OKV cluster can be securely backed up.
- Key access is audited to allow for early detection of access.
Encryption Keys in a cyber vault architecture
Below is a diagram of a typical cyber vault architecture using ZDLRA. Because the backups are encrypted, either because the databases are using TDE and/or they are creating RMAN encrypted backups sent to the ZDLRA, the keys need to be available in the vault also.
Not only is the cyber vault a separate, independent database and backup architecture, the vault also contains a separate, independent OKV cluster.
This isolates the cyber vault from any attack to the primary datacenter, including any attack that could compromise encryption key availability.
Encryption Keys in an advanced cyber vault architecture
Below is a diagram of an advanced cyber vault architecture using ZDLRA. Not only are the backups replicated to a separate ZDLRA in the vault, they are internally replicated to an Isolated Recovery Environment (IRE). In this architecture, the recover area is further isolated, and the OKV cluster is even further isolated from the primary datacenter. This provides the highest level of protection.
OKV Encryption Key Transfer
This blog post highlights the benefit of the newly released (21.11) OKV feature to allow for the secure transfer of encryption keys.
Periodic rotation of encryption keys is a required practice to protect encryption keys, and ensuring you have the current key available in a cyber vault is challenging.
OKV solves this challenge by providing the ability to transfer any new or changed keys between clusters.
Implementing OKV in a cyber Vault
When building a cyber vault, it is recommend to build an independent OKV cluster. The OKV cluster in the vault is isolated from the primary datacenter and protected by an airgap. The nodes in this cluster are not be able to communicate with the OKV cluster outside of the vault.
The OKV cluster in the vault can be created using a full, secure, backup from the OKV cluster in the primary datacenter. The backup can be transferred into the vault, and then restored to the new, independent OKV cluster providing a current copy of the encryption keys.
Keeping OKV managed keys updated in a cyber Vault
The challenge, once creating an isolated OKV cluster has been keeping the encryption keys within the cluster current when new keys are created. This was typically accomplished by transferring a full backup of OKV into the vault, and rebuilding the cluster using this backup.
OKV 21.11 provides the solution with secure Encryption Key Transfer. Leveraging this feature you can securely transfer just the keys that have recently changed allowing you to manage independent OKV clusters that are synchronized on a regular basis.
The diagram below shows the flow of the secure Encryption Key Transfer package from the primary OKV cluster into the vault when the air-gap is opened.
This new OKV feature provides a much better way to securely manage encryption keys in a Cyber Vault.
Summary
As ransomware attacks increase, it is critical to protect a backup copy of your critical database in a cyber vault. It is also critical to protect a copy of your encryption keys to ensure you can recovery those databases. OKV provides the architecture for key management in both your primary datacenter and in a cyber vault. The new secure key transfer feature within OKV allows you to synchronize keys across independent OKV clusters.
