Oracle Database 19c: Creando un tablespace seguro para almacenamiento de datos

La seguridad es siempre un tema de discusión y no es para menos, cada vez, nos vemos más agobiados con las constantes noticias de hackeos de datos confidenciales y no confidenciales.

En un mundo lleno de desafíos por el resguardo de la información, ni el famoso Chema Alonso, a logrado salir libre de culpa, cuando hace poco más de 3 años, un 12 de mayo de 2017, la red interna de Telefónica Española, sufrió un fuerte ataque, al igual que otras grandes companías en España.

En el aquel entonces, se presumío que el ataque había sido enviado desde China y se solicitaba un rescate de poco más de medio millón de Euros en la criptomoneda Bitcoin.

El ataque masivo de ransomware, afectó un número indefinido de servidores de Telefónica y tuvo como consecuencias el paro de labores de la compañía. A pocos horas del inicio del ataque, las figura más mediática en lo que respecta a la seguridad de Telefónica, Chema Alonso, acudido a Twitter para quitar hierro al ataque. "Las noticias son exageradas y los compañeros están trabajando en ello ahora mismo", aseguró.

Sin embargo, la estocada, ya había surtido efecto. Empresas como BBVA, Vodafone y Capgemini, negaban contundemente, que no habían sido víctimas de dicho ataque.

Y es que en el ciberespacio, no hay un lugar seguro del todo y es necesario, tomar medidas para mitigar el impacto de los miles de intentos de ataques, que se dan a cada minuto.

De facto en una base de datos, los datafiles, que son los repositorios de datos para los tablespaces, no son encriptados. Esto supone un alto riesgo de exposición de información, sin necesidad de hacer tan siquiera LOGIN en la base de datos.

A través de comandos de sistema operativo, es posible extraer información plana de los datafiles y tener acceso a datos confidenciales.

Para evitar esto, podemos crear tablespaces encriptados y evitar así, el acceso no autorizado a dicha información, por usuarios conectados a nivel de sistema operativo.

Esta opción es posible, gracias al opcional de Advanced Security, de la base de datos.

Primero que todo, vamos a echar un vistazo a los nombres de los datafiles creados en la instacia PDB de mi contenedor.

SQL> connect / as sysdba
Connected.
SQL> alter session set container=pdb1;

Session altered.

SQL> SELECT tablespace_name, file_name, bytes/1024/1024 size_mb
 FROM dba_data_files 
/

Vamos a crear un nuevo tablespace en la instancia de base de datos, pero esta vez, vamos a agregar el parámetro que me permite indicar que el tablespace va a estar protegido a través de un método de encriptación.

SQL> set linesize 200
SQL> create tablespace tbs_datos_seguros encryption using 'AES256' encrypt;
create tablespace tbs_datos_seguros encryption using 'AES256' encrypt
*
ERROR at line 1:
ORA-28365: wallet is not open

SQL> show con_id

CON_ID
------------------------------
3

A la hora de ejecutar el comando, me da un error en donde me indica que la bóveda de seguridad no se encuentra disponible.

Vamos entonces a realizar unos pequeños ajustes, tanto a nivel del contenedor de la base de datos, como en la PDB

SQL> connect / as sysdba
Connected.

SQL> administer key management set keystore open identified by oracle19 container=all;

keystore altered.

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY oracle19 WITH BACKUP USING 'cdb1_key_backup' 
/

keystore altered.

SQL> alter session set container=pdb1;

Session altered.

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY oracle19 WITH BACKUP USING 'pdb1_key_backup';

keystore altered.

Ahora que hemos creado la bóveda y una llave de administración, podemos continuar con la creación del tablespace encriptado.

SQL> create tablespace tbs_datos_seguros encryption using 'AES256' encrypt;

Tablespace created.

Vamos a brindar privilegios de espacio en dicho tablespace al usuario de esquema HR.

SQL> alter user hr quota unlimited on tbs_datos_seguros;

User altered.

Ahora vamos a crear una tabla en dicho tablespaces e insertamos un registro de prueba, para validar si efectivamente la información, no es accesible desde el sistema operativo.

SQL> create table hr.datos_super_seguros( banco varchar2(200), clave varchar2(100)) tablespace tbs_datos_seguros;

Table created.

SQL> insert into hr.datos_super_seguros values ('Banco Cloud Oracle','TENGOUNPASSWORDMALO');

1 row created.

SQL> commit;

Commit complete.

SQL>

Vamos a obtener el nombre del datafile asignado a dicho tablespaces y validar con el comando STRINGS, que no se encuentra la información disponible desde el sistema operativo.

SQL> col file_name format a95

SQL> SELECT tablespace_name, file_name FROM dba_data_files
/

SQL>
[oracle@instancia-oracledbacr-ol7 datafile]$ strings o1_mf_tbs_dato_hd12ko39_.dbf|more
}|{z
`Ti
TBS_DATOS_SEGUROS
Ye_
F/*p
ie)M
;\9}
_`E}K
/MwV:P
        Nz^
UsX/
^Xd`
uIT0
|7?4i
bvCs
&\?'
~#G#
;AO^
9Ym1
i       Xr
ho}#
k_in
,[:zs
2_t4u6!|
k:)%
b~0ZY
{7{l*
kx"]
Z*3G
e4>;
"_Uh
MN+l
lIoJ-
#!Jz
Fr%C
>KE#P
63iWr
N~6V
L4u>
,=[6
--More--

Listo, ahora podemos dormir un poco más tranquilos, que nuestra información se encuentra bien protegida.