Automatically Manage and Maintain Oracle Transparent Database Encryption Secrets Using Oracle Clusterware Resource and Hashicorp Vault

Background

A couple of years ago, a Version 1 customer took the strategic decision for all Oracle databases to use database encryption technologies as part of the encryption standards independent of the encryption at rest/in transit standards for disks/storage. In order to achieve this, Oracle's TDE solution had been adopted and currently is being used on all Oracle databases, on both on-premise and cloud platforms.

Problem Statement

TDE uses encryption keys that need to be available in the wallet during database startup, if keys are missing or lost then Oracle’s database could not be recovered.

Across customer state, Oracle wallets are being created and stored locally on a database server and use standard keys, so if someone gets into the host and gets hold of one key then they can access data in all databases. Hence, as a strategic solution to strengthen the data security measures, the customer has taken a decision to remove TDE keys from the local wallet and keep them in Vault. The requirement was to integrate TDE with Hashicorp vault as a wallet security solution. The reason to use Hashicorp vault for this purpose was to keep this solution cloud-agnostic.

Below are the key technical requirements:

1. Uploads TDE encryption keys from local wallet into Vault.
2. Download TDE encryption keys from Vault into local wallet and startup database successfully.
3. Remove key after database and encryption wallet are OPEN.
4. Continuously, scan wallet after database is up and running and make sure keys are not present in local wallet.

Solution

TDE vault integration solution was very important for the customer for security and managing the encryption keys as it will be leveraged across all other projects.

The solution is to upload/download binary files to/from vault using b64 encryption.

Uploading Local Wallet in Hashicorp Vault

wallet_upload.sh

cat <path_to_wallet_location>/cwallet.sso | base64 | vault kv put <path_to_secret> cwallet.sso=-

cat <path_to_wallet_location>/ewallet.p12 | base64 | vault kv patch <path_to_secret> ewallet.p12=-

Downloading Keys from Hashicorp Vault to Local Wallet

wallet_download.sh

vault kv get -field=cwallet.sso kv/<path_to_secret> | base64 — decode > <path_to_wallet_location>/cwallet.sso

vault kv get -field=ewallet.p12 kv/<path_to_secret> | base64 — decode > <path_to_wallet_location>/ewallet.p12

After, having this solution in place we automated the process of uploading and downloading the keys by creating a fully integrated Oracle clusterware resource.

This automation performs the tasks below seamlessly in a given sequence:

1. Upload TDE wallet into Vault during provisioning.
2. Remove local TDE wallet
3. Download wallet from Vault during DB startup.
4. Remove local TDE wallet post DB startup.
5. Continuously, scan local wallet and delete keys if available.

Installation Steps

1. Set up Vault for TDE keys
2. Grant iam_role to “grid” user to allow vault access
3. Add new cluster CopyKey Resource.

crsctl add resource CopyKey -type local_resource -attr “ACTION_SCRIPT=<script_location>/<manage_keys_script>.sh”

4. Modify database cluster resource to change START_DEPENDENCIES include CopyKey resource.

crsctl modify resource ora.<db_resource>.db -attr “START_DEPENDENCIES=’hard(ora.DATA_DG.dg,ora.REDO_DG.dg, ora.FRA_DG.dg, CopyKey) pullup(ora.DATA_DG.dg,ora.REDO_DG.dg, ora.FRA_DG.dg, CopyKey) weak(type:ora.listener.type, uniform:ora.ons)’”

5. Modify CopyKey cluster resource to change STOP_DEPENDENCIES on database resource

crsctl modify resource CopyKey -attr “STOP_DEPENDENCIES=’hard(shutdown:ora.<db_resource>.db, intermediate:ora.<db_resource>.db, shutdown:ora.<db_resource>.db, shutdown:ora.<db_resource>.db)’”

Benefits

• Cost efficient
• Cloud agnostic
• Fully automated solution
• Best support standard
• Simplified wallet manipulation

About the Author:
Fawad Haider is an Oracle Architect here at Version 1.