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, ensure you have an "Advanced Security Option" license, which comes at an additional cost, before continuing. In Oracle Autonomous Databases and Database Cloud Services, it is included, configured, and enabled, but this is not the case in other architectures.

Note: These tests are simulated in an Oracle 21.3.0.0 database. The simulation emulates a standalone environment, without multitenant. I will make new specific entries for 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 confidential data stored in data files. Oracle offers transparent data encryption (TDE) to decrypt or protect these files. To prevent unauthorized decryption, TDE stores encryption keys in a security module external to the database.
Oracle offers the following modules for this purpose:

• TDE Wallets: "caretar de Wallets". These are the wallets used for the TDE. In previous versions they were simply called "wallets".
• External keystore: Son almacenes de claves externos (cómo 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.
• Encryption key management operations for wallets can be automated by Oracle. The end user or application does not need to manage encryption keys for TDE wallets.

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).

• Parámetro WALLET_ROOT: Especifica el directorio principal para varios almacenes de claves de software. En nuestro caso, para TDE, será el directorio para el descubrimiento automatizado del wallet que será WALLET_ROOT/tde.
• Parámetro TDE_CONFIGURATION: Especifica el tipo de almacen de claves o keystore (almacén de claves de software u Oracle Key Vault). Configurado el tipo de almacén de claves (TDE_CONFIGURATION), cuando se crea el keystore, Oracle crea un directorio en la ubicación del parámetro WALLET_ROOT, en nuestro caso 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 initialization parameter WALLET_ROOT and the dynamic initialization parameter TDE_CONFIGURATION.

WALLET_ROOT configuration

First, we create the directory where the wallet will be stored at the 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.

Creación de un Almacén de Claves de Software Protegido por Contraseña

As we have already configured WALLET_ROOT y TDE_CONFIGURATIONwe only need to execute the command ADMINISTER KEY MANAGEMENT CREATE KEYSTORE para crear el wallet. Un almacén de claves de software protegido por contraseña requiere una contraseña, que se usa para proteger las claves maestras del TDE. Para ello es necesario que el usuario tenga uno de estos dos privilegios, 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-x. 3 oracle oracle 4096 Aug 15 13:36 ..
-rw-------. 1 oracle oracle 2555 Aug 15 13:36 ewallet.p12

Creación de un Almacén de Claves de Software de Inicio Automático o de Inicio Automático Local

En este punto tenemos un almacén de claves protegidos por contraseña. Como opción puedes crear un almacén de claves de software de inicio automático o de inicio automático local. La diferencia es que el software de inicio automático se puede abrir desde varios ordenadores, mientras que el almacén de claves de inicio local, es local, y debe abrirse en cada ordenador desde del que fue creado. Por defecto, si no se especifica LOCAL, el archivo será 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

Cómo esta no es nuestra intención y queremos que se abra de forma automática al abrirse la base de datos vamos a crear en primer lugar el software de inicio de sesión automático o inicio sesión automático local, en nuestro caso inicio automático (obviamos la palabra 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/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/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 benefits of Oracle Transparent Data Encryption (TDE) are significant, starting with the protection of sensitive data. This encryption protects information and ensures that it remains secure. In addition, TDE offers several key benefits, including compliance with security-related regulations. It can be easily applied without impacting 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.