Configurar Oracle Transparent Data Encryption (TDE)

¿Qué es TDE y por qué es importante?

TDE (Transparent Data Encryption) te permite cifrar datos sensibles almacenados en tablas, tablespaces e incluso en copias de seguridad de la base de datos. Esto es crucial para proteger información sensible en caso de un acceso no autorizado.

Importante:
Antes de aplicar TDE asegúrate que tienes una licencia «Advanced Security Option», con coste adicional antes de continuar. En Oracle Autonomous Databases y en Database Cloud Services, está incluida, configurada y habilitada, pero no así en otras arquitecturas.

Nota: Estas pruebas están simuladas en una BBDD Oracle 21.3.0.0. La simulación emula un entorno «standalone», sin multitenant. Realizaré nuevas entradas específicas de TDE en entornos con arquitectura multitenant.

Cómo funciona la encriptación de datos para el usuario.

Una vez que los datos están cifrados, estos se descifran de forma transparente para los usuarios o las aplicaciones autorizadas cuando acceden a ellos. Es decir, el cifrado y descifrado de los datos para aquellos usuarios autorizados es transparente.

¿Cómo evita TDE el descifrado no autorizado?

El TDE cifra los datos confidenciales almacenados en los archivos de datos. Oracle para descifrar o proteger estos archivos, ofrece el cifrado de datos transparente (TDE). Para evitar el descifrado no autorizado, el TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos.
Para ello Oracle dispone de los siguientes módulos:

  • TDE Wallets: «caretar de Wallets». Son los Wallets que se utilizan para el TDE. En versiones anteriores simplemente se llamaban «wallets».
  • External keystore: Son almacenes de claves externos (cómo Oracle Key Vault, OCI Key Management Service (KMS).
  • Keystores: Término que abarca tanto los TDE wallets cómo a los almacenamientos de claves externas.

Beneficios TDE

  • Los datos están cifrados, por tanto es un medio de seguridad en caso de robo de los datos.
  • El uso de TDE ayuda a abordar cumplimientos normativos relacionados con la seguridad.
  • No es necesario realizar cambios de código, ni cambios en aplicaciones, la base de datos gestiona el cifrado y descifrado de datos.
  • Los usuarios y aplicaciones de bases de datos no necesitan saber que los datos a los que está accediendo están encriptados.
  • Es posible cifrar los datos sin tiempo de inactividad en los sistemas de producción. También es posible realizar el cifrado durante periodos de mantenimiento.
  • Las operaciones de gestión de claves de cifrados de los wallets puede ser automatizado por Oracle. El usuario final o la aplicación no necesita administrar las claves de cifrado de los wallets TDE.

Tipos de Cifrado en TDE

Es posible encriptar datos sensibles de dos formas: A nivel de columna o a nivel de tablespaces.

A nivel de columna: Puedes cifrar datos sensibles en columnas específicas de las tablas de la aplicación.

A nivel de tablespaces: Cifra todos los datos almacenados en un tablespaces. Es el cifrado más utilizado ya que es más fácil de aplicar y no requiere un análisis detallado de cada columna de tabla para determinar qué columnas necesitan cifrado.

Nota: Los datos BFILE no se cifran ya que están ubicados físicamente en un archivo del sistema operativo, no en el tablespace de la base de datos.

Pasos para implementar un TDE

En primer lugar para configurar el TDE, tenemos que hacer una configuración inicial en la base de datos. Básicamente tenemos que configurar el parámetro WALLET_ROOT (estático) y el parámetro TDE_CONFIGURATION (dinámico).

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

Nota: En versiones anteriores, se usaba el parámetro SQLNET.ENCRYPTION_WALLET_LOCATION. Este parámetro ha quedado obsoleto. Oracle recomienda usar los parámetros de inicialización estática WALLET_ROOT y dinámica TDE_CONFIGURATION.

Configuración del WALLET_ROOT

En primer lugar creamos el directorio donde se guardará el wallet a nivel de SSOO.

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

Comprobamos los parámetros de la BBDD:

Antes de realizar un cambio de parámetros, aconsejo realizar un backup del spfile.

WALLET_ROOT

Parámetro estático para guardar el directorio del wallet. Cambiamos el parámetro WALLET_ROOT, y lo guardamos en el spfile. Reiniciamos la base de datos.

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

TDE_CONFIGURATION

Especificamos el parámetro TDE_CONFIGURATION para especificar el tipo de TDE wallet. En esta ocasión usaremos tipo FILE.

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

Comprobamos que los parámetros son correctos.

TDE Wallets

Existen tres tipos diferentes de TDE wallets : protegidas por contraseña, de inicio automático y de inicio automático local.

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

Cómo ya hemos configurado WALLET_ROOT y TDE_CONFIGURATION, solo necesitamos ejecutar el comando 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.

Pudedes comprobar que se ha creado de forma automática sobre el directorio WALLET_ROOT un directorio /tde, donde verás el fichero ewallet.p12, que es nuestro TDE wallet protegido por password.

[oracle@localhost tde]$ ls -la /u01/app/oracle_base/admin/testing/wallet/tde
total 12
drwxr-x---. 2 oracle oracle 4096 ago 15 13:36 .
drwxrwxr-x. 3 oracle oracle 4096 ago 15 13:36 ..
-rw-------. 1 oracle oracle 2555 ago 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.

Tenga en cuenta que si tiene una base de datos RAC y se especifica LOCAL, solo el nodo que creó el archivo de autologin podrá abrirlo. En un entorno RAC, para mayor simplicidad, es mejor no especificar la palabra clave LOCAL. De lo contrario, tendrá que crear múltiples archivos cwallet.sso para cada nodo que contenga las mismas credenciales.

En este punto, si reiniciáramos la Base de datos veríamos cómo nuestro wallet está en estado closed, y deberíamos usar el comando «ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY »»; para abrirlo.

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

Como puedes ver, se ha creado el archivo cwallet.sso, que es el autologin.

Establecer la Master Key encription

Antes de realizar algún cifrado, debemos crear/establecer nuestra clave maestra de cifrado, ya que aún no tenemos una.

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

En este punto ya puede comenzar a encriptar su base de datos (tablespaces, tablas, etc). Veremos cómo hacerlo en siguientes entradas.

NOTA: Si se pierden los ficheros wallet u olvida la contraseña, no tendrá forma de recuperar los datos cifrados. La base de datos no podrá ser recupera de ninguna forma (backup, etc), si no se dispone de este fichero. No hay ninguna «puerta trasera», la base de datos tendrá que ser reconstruida. Por tanto es necesario realizar backup de forma continúa de estos ficheros.

Una vez que hayas implementado TDE, recomiendo lo siguiente:

  1. Custodiar la contraseña TDE.
  2. Realizar copias de seguridad del fichero wallet frecuentemente.

Conclusión

El beneficio de Oracle Transparent Data Encryption (TDE) es muy grande, comenzando por la protección de los datos sensibles. Este cifrado protege la información y asegura que la información sea segura. Además, TDE presenta varios beneficios clave, incluyendo el cumplimiento con regulaciones relacionadas con la seguridad. Se puede aplicar de forma sencilla y sin impacto en las aplicaciones existentes.
Es importante tener en cuenta que una vez que TDE se implementa, no se puede deshabilitar.

En los siguientes post vamos a poner en práctica la encriptación de datos y tablespaces para comprobar la dimensión de esta arquitectura.

Scroll al inicio