Configuring Oracle Transparent Data Encryption (TDE)

By /

What is TDE and why is it important?

TDE (Transparent Data Encryption) allows you to encrypt sensitive data stored in tables, tablespaces and even database backups. This is crucial to protect sensitive information in case of unauthorized access.

Important:
Before applying TDE make sure you have an "Advanced Security Option" license.license, at additional cost before proceeding. In Oracle Autonomous Databases and Database Cloud Services, it is included, configured and enabled, but not in other architectures.

Note: These tests are simulated on an Oracle DB 21.3.0.0.0. The simulation emulates a "standalone" environment, without multitenant. I will make new entries specific to TDE in environments with multitenant architecture.

How data encryption works for the user.

Once data is encrypted, it is decrypted transparently to authorized users or applications when they access it. In other words, data encryption and decryption is transparent to authorized users.

How does TDE prevent unauthorized decryption?

TDE encrypts sensitive data stored in data files. Oracle offers Transparent Data Encryption (TDE) to decrypt or protect these files. To prevent unauthorized decryption, TDE stores the encryption keys in a security module external to the database.
The following modules are available for this purpose from Oracle:

  • TDE Wallets: "caretar de Wallets". These are the wallets used for the TDE. In previous versions they were simply called "wallets".
  • External keystore: These are external keystores (such as Oracle Key Vault, OCI Key Management Service (KMS).
  • Keystores: A term that encompasses both TDE wallets and external keystores.

TDE Benefits

  • The data is encrypted, therefore it is a means of security in case of data theft.
  • The use of TDE helps to address safety-related regulatory compliance.
  • No code changes are required, no application changes, the database handles data encryption and decryption.
  • Database users and applications do not need to know that the data they are accessing is encrypted.
  • It is possible to encrypt data without downtime on production systems. Encryption during maintenance periods is also possible.
  • The wallet encryption key management operations can be automated by Oracle. The end user or application does not need to manage the TDE wallet encryption keys.

Types of Encryption in TDE

It is possible to encrypt sensitive data in two ways: At the column level or at the tablespace level.

Column level: You can encrypt sensitive data in specific columns of the application tables.

At tablespace level: Encrypts all data stored in a tablespace. It is the most commonly used encryption because it is easier to apply and does not require a detailed analysis of each table column to determine which columns need encryption.

Note: BFILE data is not encrypted as it is physically located in an operating system file, not in the database tablespace.

Steps to implement a TDE

First of all to configure the TDE, we have to make an initial configuration in the database. Basically we have to configure the WALLET_ROOT parameter (static) and the TDE_CONFIGURATION parameter (dynamic).

  • WALLET_ROOT parameter: Specifies the home directory for various software keystores. In our case, for TDE, it will be the directory for automated wallet discovery which will be WALLET_ROOT/tde.
  • TDE_CONFIGURATION parameter: Specifies the keystore type (software keystore or Oracle Key Vault). Configured the keystore type (TDE_CONFIGURATION), when the keystore is created, Oracle creates a directory at the location of the WALLET_ROOT parameter, in our case WALLET_ROOT/tde .

Note: In previous versions, the SQLNET.ENCRYPTION_WALLET_LOCATION parameter was used. This parameter has been deprecated. Oracle recommends using the static WALLET_ROOT and dynamic TDE_CONFIGURATION initialization parameters.

WALLET_ROOT configuration

First we create the directory where the wallet will be stored at SSOO level.

mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/wallet

We check the DB parameters:

Before making a parameter change, it is advisable to make a backup of the spfile.

WALLET_ROOT

Static parameter to save the wallet directory. We change the parameter WALLET_ROOT, and save it in the spfile. Restart the database.

SQL> alter system set wallet_root='$ORACLE_BASE/admin/$ORACLE_SID/wallet' scope=spfile;
System altered.

TDE_CONFIGURATION

We specify the parameter TDE_CONFIGURATION to specify the type of TDE wallet. This time we will use type FILE.

SQL> ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=both;
System altered.

We check that the parameters are correct.

TDE Wallets

There are three different types of TDE wallets: password protected, auto-start and local auto-start.

Creating a Password Protected Software Keystore

As we have already configured WALLET_ROOT y TDE_CONFIGURATIONwe only need to execute the command ADMINISTER KEY MANAGEMENT CREATE KEYSTORE to create the wallet. A password-protected software keystore requires a password, which is used to protect the TDE master keys. This requires the user to have one of two privileges, ADMINISTER KEY MANAGEMENT o SYSKM:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "oracleconraul";
keystore altered.

You can see that a /tde directory has been automatically created on the WALLET_ROOT directory, where you will see the file ewallet.p12, which is our password-protected TDE wallet.

[oracle@localhost tde]$ ls -la /u01/app/oracle_base/admin/testing/wallet/tde
total 12
drwxr-x---. 2 oracle oracle 4096 Aug 15 13:36 .
drwxrwxr-xr-x. 3 oracle oracle 4096 Aug 15 13:36 ..
-rw-------. 1 oracle oracle 2555 Aug 15 13:36 ewallet.p12

Creating an AutoStart or Local AutoStart Software Keystore

At this point we have a password protected keystore. As an option you can create an autostart or local autostart software keystore. The difference is that the autologin software can be opened from multiple computers, while the local autologin keystore is local, and must be opened on each computer from which it was created. By default, if LOCAL is not specified, the file will be autologin.

Please note that if you have a RAC database and you specify LOCALIn a RAC environment, for simplicity only the node that created the autologin file will be able to open it. In a RAC environment, for the sake of simplicity, it is better not to specify the keyword LOCAL. Otherwise, you will have to create multiple cwallet.sso for each node containing the same credentials.

At this point, if we restart the database we will see how our wallet is in closed state, and we should use the command "ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY ""; to open it.

SQL> select con_id, wrl_parameter, status from gv$encryption_wallet;

 CON_ID WRL_PARAMETER STATUS
---------- ------------------------------------------------------------ ------------------------------------------------------------ ------------------------------
1 /u01/app/oracle_base/admin/testing/wallet/tde/CLOSED

As this is not our intention and we want it to open automatically when the database is opened we will first create the automatic login software or local automatic login, in our case automatic login (we omit the word LOCAL).

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY "oracleconraul";
SQL> select con_id, wrl_parameter, status from gv$encryption_wallet;

 CON_ID WRL_PARAMETER STATUS
---------- ------------------------------------------------------------ ------------------------------
1 /u01/app/oracle_base/oracle_base/admin/testing/wallet/tde/OPEN_NO_MASTER_KEY

As you can see, the file cwallet.ssowhich is the autologin.

Set Master Key encryption

Before performing any encryption, we must create/set our master encryption key, as we do not have one yet.

SQL> ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY "oracleconraul" WITH BACKUP ;

keystore altered.
  sql> select con_id, wrl_parameter, status from gv$encryption_wallet

 CON_ID WRL_PARAMETER STATUS
---------- ------------------------------------------------------------ ------------------------------------------------------------ ------------------------------
1 /u01/app/oracle_base/oracle_base/admin/testing/wallet/tde/OPEN

At this point you can start encrypting your database (tablespaces, tables, etc). We will see how to do it in the following posts.

NOTE: If you lose the wallet files or forget the password, you will have no way to recover the encrypted data. The database cannot be recovered in any way (backup, etc), if you do not have this file. There is no "back door", the database will have to be rebuilt. It is therefore necessary to continuously backup these files.

Once you have implemented TDE, I recommend the following:

  1. Custody of the TDE password.
  2. Make backup copies of the wallet file frequently.

Conclusion

The benefit of Oracle Transparent Data Encryption (TDE) is great, starting with the protection of sensitive data. This encryption protects information and ensures that information is secure. In addition, TDE has several key benefits, including compliance with security-related regulations. It can be implemented easily and with no impact on existing applications.
It is important to note that once TDE is implemented, it cannot be disabled.

In the following posts we will implement data encryption and tablespaces to test the dimension of this architecture.

Scroll to top