TDE quickstart and keystore hygiene

Problem

I wanted data at rest encrypted without rewriting applications. Transparent Data Encryption (TDE) does that, and the application stays unaware. The real work is operational: where the keystore lives, who knows its password, and what happens when it is closed or lost.

A lost keystore means unreadable data, so the hygiene matters more than the encryption command.

Options and trade-offs

• Tablespace encryption: broad protection and a simple rollout with little application impact.
• Column encryption: targeted protection with more DDL planning, and special care around indexes and salt.
• Software keystore versus external key management such as OKV or OCI Vault: the software keystore is simpler, and external management centralizes keys and operations.

My recommendation

Encrypt tablespaces by default and reserve column encryption for specific fields. Configure the keystore location once, take a backup before every key change, and write the operator runbook before the first production cutover.

Worked example

Configure the keystore location. WALLET_ROOT is a static parameter, so it needs a restart. TDE_CONFIGURATION can then be set dynamically.

ALTER SYSTEM SET WALLET_ROOT = '/u01/app/oracle/admin/ORCL/wallet' SCOPE = SPFILE;
-- restart the instance, then:
ALTER SYSTEM SET TDE_CONFIGURATION = 'KEYSTORE_CONFIGURATION=FILE' SCOPE = BOTH;

Create and open the keystore, back it up, then create the master key and an auto-login keystore so the database can reopen after a restart:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "<password>";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<password>";
ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'before_first_key' IDENTIFIED BY "<password>";
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "<password>" WITH BACKUP;
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY "<password>";

Create an encrypted tablespace, or convert an existing one online on Oracle Database 12.2 and later, then verify:

CREATE TABLESPACE secure_ts DATAFILE '<path>' SIZE 100M
  ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
 
ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT;
 
SELECT wrl_type, status, wallet_type FROM v$encryption_wallet;
SELECT ts#, encryptedts FROM v$encrypted_tablespaces;

Defaults differ between releases, and multitenant databases add container-level options, so check the TDE documentation for your version before running any of this.

Checklist

1. Set the keystore location once, and write the path down.
2. Use AES256 for tablespace encryption unless policy says otherwise.
3. Back up the keystore before and after every key operation.
4. Store the keystore password and the backups separately from the database host.
5. Check keystore status after every restart.
6. Test export and import, and Data Guard behavior, before production.

Where this doesn't apply

Autonomous Database and many managed services already encrypt data at rest for you, so there is nothing to configure. Other database engines have their own native encryption features.

One honest limitation

The keystore is an operational dependency. If it is closed at the wrong moment, or a key rotation goes badly, the database can stop serving data. Rehearse the runbook on a non-production system first.

Sources

• Oracle Database Advanced Security Guide: Introduction to Transparent Data Encryption
• Oracle Database Advanced Security Guide: Configuring Transparent Data Encryption
• Oracle Database SQL Language Reference: ADMINISTER KEY MANAGEMENT