Archive

Archivo de Autor

Intercambio seguro de datos con Oracle Database

Uno de los puntos de seguridad que se suelen olvidar a menudo es el intercambio de datos entre servidores. Se dedican muchos esfuerzos a proteger los datos en la misma base de datos (con políticas de usuarios y contraseñas, herramientas de cifrado de datos, segregación de funciones, auditoría, etc.) pero por otro lado se permite que estos datos circulen libremente y en texto plano por la red, cuando existen múltiples herramientas para capturar y modificar esta información.

Un usuario malintencionado podría capturar datos en tránsito, modificarlos y retransmitirlos. Por ejemplo, podría capturar todos los datos de las tarjetas de crédito para usarlos posteriormente. También podría capturar un depósito de cierta cantidad en una cuenta bancaria, modificar el importe y/o la cuenta de destino y retransmitir esta información, o retransmitir de manera continua la información de este depósito para multiplicar el importe recibido.

Debido a esto, es muy recomendable añadir seguridad en las comunicaciones si queremos tener un entorno más protegido. Esta seguridad puede implicar controles de cifrado e integridad de los datos: de cifrado para que la información viaje sin que terceras partes puedan verla tal cual y de integridad para que nadie pueda modificarla.

Para configurar el cifrado y la integridad de los datos en las comunicaciones entre servidor de base de datos y clientes, es necesario modificar el fichero ‘sqlnet.ora’. Esto se puede hacer manualmente o mediante la herramienta Oracle Net Manager como se muestra en las siguientes capturas:

cifrado Leer más…

Transparent Data Encryption – Cifrar por columna o tablespace

Transparent Data Encryption (TDE) es la opción de seguridad que proporciona Oracle para cifrar los datos a nivel de sistema operativo. En este post hice una pequeña introducción de este producto y dentro del Oracle Security Tour hablamos más en profundidad sobre él, en concreto en el webinar desde la óptica de la regulación.

Cuando se desea cifrar los datos de la base de datos con TDE, una de las primeras cuestiones que se plantea es qué tipo de cifrado aplicar.

TDE puede cifrar a nivel de columna o de tablespace.

Tipos de cifrado

Tipos de cifrado

 

En el cifrado a nivel de columna se elige qué columna o columnas, de qué tabla o tablas se desean cifrar, y se aplica el cifrado. En el cifrado a nivel de tablespace se crea un tablespace cifrado y todos los objetos que se creen o se muevan ahí estarán cifrados. Cada uno tiene sus ventajas, inconvenientes y puntos a tener en cuenta, que se resumen en la siguiente tabla:

CIFRADO DE COLUMNA CIFRADO DE TABLESPACE
Se conoce dónde está la información sensible Se desconoce dónde está la información sensible
Menos del 5% de las columnas de la aplicación son candidatas a cifrarse La mayoría de los datos de la aplicación se han definido como sensibles o aplica algún tipo de legislación vigente
El tipo de datos y la longitud están soportados por cifrado de columna No todos los tipos de datos que contiene está soportados por cifrado de columna
Las columnas candidatas a ser cifradas no son claves ajenas Las columnas candidatas a ser cifradas son claves ajenas
Los índices sobre las candidatas son índices b-tree normales Los índices de las candidatas a ser cifradas son índices funcionales
La aplicación no realiza escaneos de rango sobre los datos cifrados La aplicación realiza búsquedas por rangos sobre los datos sensibles
Es aceptable un incremento de almacenamiento de 1 a 52 bytes por valor cifrado No es aceptable un incremento en la ocupación de almacenamiento
El impacto en el rendimiento depende del porcentaje de columnas cifradas, con qué frecuencia los valores cifrados son seleccionados o actualizados, el tamaño de los datos cifrados y otras variables Se desea tener un impacto constante de rendimiento por debajo del 10%
Se desea beneficiarse de aceleración de cifrado por hardware
Se desea beneficiarse de cifrado y compresión al mismo tiempo

Investigar reinicios de servidores Linux con kdump

En algunos sistemas puede suceder que algún servidor se reinicie sin motivo aparente y sin dejar rastro en ningún log. Cuando esto sucede en entornos productivos, y de manera continua, puede convertirse en un verdadero problema. Si se trata de un servidor con sistema operativo Linux, podemos hacer uso de la herramienta kdump para investigar el origen de la caída y aplicar medidas correctivas.

kdump es un mecanismo del kernel de Linux que vuelca información sobre la caída del sistema, creando una imagen de la memoria (vmcore) que puede ayudar a determinar la causa del problema.

Haciendo uso de la herramienta kexec para arrancar un segundo kernel (también llamado crash kernel) consigue reservar una pequeña parte de la memoria del sistema de manera exclusiva que, por tanto, no estará disponible para otros usos. Cuando se activa, el sistema se arranca desde el contexto de este segundo kernel, que hará uso de la memoria reservada para él, y cuyo único propósito es capturar la imagen del volcado de la memoria (o core dump) en caso de que el sistema se caiga.

kdump se puede configurar en el momento de instalación del sistema, aunque si no se ha hecho podemos configurarlo posteriormente sin ningún tipo de problema, con el inconveniente de que hará falta reiniciar la máquina. El primer paso para poder hacer uso de kdump en nuestro sistema será instalar el paquete kexec-tools en caso de que no lo tengamos. Adicionalmente, se pueden instalar los paquetes crash y kernel-debuginfo para investigar el origen del problema a partir del vmcore generado.

Una vez instalados estos paquetes, habrá que configurar kdump. Este paso se puede realizar de dos maneras:

  1. Con la interfaz gráfica. Se necesitará tener instalado el paquete system-config-kdump.Configurar kdump
  2. Desde línea de comando editando los ficheros a mano. El principal fichero a modificar es grub.conf, al que es necesario añadir a la línea de carga del kernel el parámetro crashkernel con el valor de memoria a configurar, pudiendo ser un valor determinado como crashkernel=M, o un valor automático como crashkernel=auto, aunque este último caso tiene sus limitaciones.

La línea del kernel debe quedar algo parecido a lo siguiente:

title Oracle Linux Server Unbreakable Enterprise Kernel (2.6.39-400.248.3.el5uek)
        root (hd0,0)
        kernel /vmlinuz-2.6.39-400.248.3.el5uek ro root=/dev/VolGroup00/LogVol00 rhgb quiet numa=off transparent_hugepage=never crashkernel=128M@48M
        initrd /initrd-2.6.39-400.248.3.el5uek.img

El fichero de configuración de kdump es /etc/sysconfig/kdump, el cual posee varias opciones configurables, una de ellas es dónde queremos guardar los volcados de memoria. Por defecto se guarda en /var/crash, pero se puede modificar para que se almacene en otro filesystem disponible en la máquina, un dispositivo RAW o un directorio remoto mediante NFS o SSH.

También hay que tener en cuenta el tamaño de la memoria y el espacio disponible en disco, es decir, si la máquina tiene 32GB de memoria, es posible que el volcado de memoria llegue a necesitar ese espacio Para solucionar esto se puede activar otra de las características de kdump, el ‘core collector’, configurándolo para que comprima el volcado o elimine cierta información.

Una vez configurado kdump únicamente queda arrancar el servicio y habilitarlo para que se inicie junto con la máquina:

#chkconfig kdump on
#service kdump start
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.39-200.24.1.el6uek.x86_64kdump.img
Starting kdump:                                            [  OK  ]

Por último se puede revisar el estado con service kdump status, si es correcto nuestro sistema ya estará preparado para guardar volcados de memoria en caso de caídas del sistema. La documentación de kdump para Oracle está disponible en este link.

Categorías:Sistemas Etiquetas: ,

Transparent Data Encryption – Creación de wallets

Cuando se desea cifrar la información dentro de una base de datos Oracle, se recomienda usar el producto Transparent Data Encryption (TDE) que forma parte de Advanced Security Option (ASO). Esta opción de la BBDD, como su nombre indica, permite cifrar los datos de manera “trasparente” para las aplicaciones, esto es, que las aplicaciones sigan accediendo a los datos normalmente (como lo hacían antes del cifrado): no es necesario modificarlas ni adaptarlas, pero a nivel de sistema operativo/backups los datos quedan almacenados en forma cifrada, evitando que si alguien tienen acceso a ellos pueda extraer la información. ASO es una opción disponible en Oracle Database Enterprise Edition.

Arquitectura TDE

TDE es capaz de utilizar diferentes algoritmos al cifrar la información y todos ellos hacen uso de una clave de cifrado maestra (Master Encryption Key). Esta clave se guarda en un almacén externo de claves (keystore) que puede ser hardware o software. En sqlnet.ora se indica dónde está el almacén de claves y de qué tipo es. Es altamente recomendable hacer backup del almacén de claves al mismo tiempo que se hace backup de la base de datos.

A continuación vamos a hablar de las opciones existentes para crear un almacén de claves software en nuestro entorno, consistentes en hacer uso de wallets de Oracle. Existen 3 tipos de wallets (Password-based, Auto-login y Local auto-login) y se deberá escoger dependiendo de las necesidades de cada entorno. El siguiente paso sería cifrar la información de nuestra base de datos, pero eso ya cae fuera del alcance de este post.

Nota: Todos los ejemplos se han realizado en una base de datos 11gR2 Enterprise Edition.

1) Password-based
Los wallets basados en password o password-based necesitan de su apertura explícita con una contraseña antes de poder ser usados. Si no se hace así, al intentar acceder a los datos cifrados la base de datos da el error ‘ORA-28365: wallet is not open’.

Hay que diferenciar entre la contraseña para abrir el wallet y la Master Encryption Key. La primera es la que nos permite acceder al contenido del wallet y hacerlo disponible a la base de datos. La segunda es la que se utiliza para cifrar los datos de la base de datos. Pueden ser iguales, aunque se recomienda que ambas sean contraseñas complejas y diferentes.

Para crear un wallet de este tipo se puede hacer de dos formas. La primera ejecutando desde sqlplus:

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "password";

Lo que esta sentencia hace realmente es asignar la Master Encryption Key al wallet. Dado que no tenemos un wallet definido en nuestro entorno, lo crea con la Master Encryption Key especificada en una ruta por defecto (ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet o también ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet) que no es necesario registrar en el fichero sqlnet.ora. El password para abrir el wallet y la Master Encryption Key serán idénticos.

Si cuando se crea el wallet de esta manera da el error ‘ORA-28368: cannot auto-create wallet’, suele ser porque no existen los directorios y es necesario crearlos manualmente. Una vez creado, se puede consultar información del wallet en la vista V$ENCRYPTION_WALLET:

SQL> select * from V$ENCRYPTION_WALLET;

WRL_TYPE             WRL_PARAMETER                                                STATUS
-------------------- ------------------------------------------------------------ ------------------
file                 /u01/app/oracle/product/11.2.0/dbhome_2/admin/orcl/wallet    OPEN

Si se renicia la base de datos se puede abrir el wallet ejecutando:

SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "welcome1";

System altered.

Leer más…

Limitar recursos asignados a Servicios de BBDD Oracle

diciembre 16, 2014 Deja un comentario

Cuando las decisiones sobre la asignación de recursos de base de datos se dejan al sistema operativo, pueden aparecer (entre otros) los siguientes problemas con la gestión de la carga de trabajo:

  • Sobrecarga excesiva
  • Planificación ineficiente
  • Asignación de recursos inapropiada
  • Imposibilidad de gestionar recursos específicos de base de datos.

El Gestor de Recursos (Resource Manager) de la base de datos ayuda a solucionar estos problemas otorgando a la base de datos más control sobre cómo se asignan los recursos. Proporciona las siguientes opciones (entre otras):

  • Garantizar a ciertas sesiones una cantidad mínima de CPU, al margen de la carga del sistema y del número de usuarios.
  • Distribuir la CPU disponible mediante la asignación de porcentajes de tiempo de CPU a diferentes usuarios y aplicaciones.
  • Limitar el grado de paralelismo de cualquier operación efectuada por miembros de un grupo de usuarios.

Los elementos del Gestor de Recursos que se ven involucrados son los siguientes:

  • Grupo consumidor de recursos (resource consumer group): Es un conjunto de sesiones que se agrupan basándose en los requisitos de recursos. El Gestor de Recursos asigna recursos a grupos consumidores de recursos, no a sesiones individuales.
  • Plan de recursos (resource plan): Es un contenedor de directivas que especifica cómo se asignan recursos a los grupos consumidores de recursos. Se especifica cómo asigna recursos la base de datos mediante la activación de un plan de recursos específico.
  • Directiva de plan de recursos (resource plan directive): Asocia un grupo consumidor de recursos con un plan en concreto y especifica cómo se asignan los recursos al grupo consumidor.

Para más información se puede consultar aquí la documentación.

A continuación se muestra un ejemplo de cómo es posible realizar una configuración para limitar el consumo de recursos de los usuarios que se conectan a nuestra base de datos, en base a los servicios de ésta.

Crear servicios

En primer lugar se crean los servicios que se deseen para facilitar la gestión de la carga siguiendo los pasos explicados en este post anterior de nuestro blog. En nuestro caso se han creado los servicios ‘SERVICIO_PRIORITARIO’ y ‘SERVICIO_NO_PRIORITARIO’, añadiendo las entradas correspondientes en el fichero tnsnames.ora. Antes de continuar se comprueba que el listener posee los servicios:

[oracle@centos1 ~]$ lsnrctl status listener_orcl

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 20-OCT-2014 16:43:36

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=orcl-vip)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     listener_orcl
Version                   TNSLSNR for Linux: Version 11.2.0.4.0 - Production
Start Date                20-OCT-2014 07:13:19
Uptime                    0 days 0 hr. 30 min. 17 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/11.2.0/dbhome_1/log/diag/tnslsnr/centos1/listener_orcl/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.93.140)(PORT=1521)))
Services Summary...
Service "orcl.avanttic.com" has 2 instance(s).
  Instance "orcl", status UNKNOWN, has 1 handler(s) for this service...
  Instance "orcl", status READY, has 1 handler(s) for this service...
Service "orclXDB.avanttic.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
Service "servicio_no_prioritario.avanttic.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
Service "servicio_prioritario.avanttic.com" has 1 instance(s).
  Instance "orcl", status READY, has 1 handler(s) for this service...
The command completed successfully

Limitar recursos

Para poder limitar los recursos que utiliza cada servicio es necesario dar 3 pasos: crear grupos, asignar servicios a grupos y crear el plan de gestión de recursos sobre los grupos.

Estos 3 pasos se pueden realizar desde Enterprise Manager o desde línea de comandos. De cara a facilitar la explicación se va a hacer únicamente con Enterprise Manager.

Leer más…

Ofuscar código PL/SQL

octubre 3, 2014 1 comentario

En ocasiones deseamos que nuestro código PL/SQL no sea fácilmente accesible a los usuarios y/o administradores de las BBDD en las que lo tenemos instalado, sea para evitar copias o modificaciones no autorizadas.

En parte estos objetivos los podemos conseguir “ofuscando” nuestro código. Notar que el objetivo no es “cifrar” el código, ya que existen maneras de llegar a revertir el proceso, mas bien se trata de no permitir un acceso libre a él. Es posible conseguirlo utilizando la utilidad de línea de comando PL/SQL Wrapper o el procedimiento de base de datos DBMS_DDL.WRAP.

El objetivo de este post va a ser mostrar cómo ofuscar el código PL/SQL de nuestras aplicaciones mediante la utilidad de línea de comando PL/SQL Wrapper.

  • La documentación para la versión 11gR2 en el momento de creación de este post se puede consultar en este link.
  • Se puede ofuscar el código de paquetes (tanto especificación, como cuerpo, como ambos), tipos (tanto especificación, como cuerpo, como ambos), funciones y procedimientos. No se puede ofuscar triggers, aunque desde el trigger sí se puede referenciar a un procedimiento ofuscado.
  • El código ofuscado se puede compilar, exportar e importar como el código “en claro”, pero hay que tener cuidado con las versiones de base de datos, ya que no existe compatibilidad hacia atrás, es decir, el código compilado en una versión 11g no funcionará en una 10g, el de la 10g no funcionará en una 9i y así.
  • Oracle no proporciona mecanismos ni herramientas para revertir esa ofuscación una vez se ha ofuscado el código,  y, aunque existen formas de conseguirlo, no es el alcance de este post. Si se desea modificar el código es necesario editar el fichero original, volverlo a ofuscar y cargarlo en la base de datos.

Leer más…

Categorías:Seguridad Etiquetas: , , , ,

Eliminar usuarios/contraseñas de base de datos del código de las aplicaciones

septiembre 30, 2014 1 comentario

Es habitual que tanto algunas aplicaciones como shell scripts tengan los datos de conexión a base de datos (incluyendo el usuario y la contraseña) almacenados en ficheros de texto. Esto implica, principalmente, un problema de seguridad, ya que cualquiera que tenga acceso a estos ficheros tendrá acceso a los datos de conexión a la base de datos, pero además, supone un serio problema a la hora de modificar las contraseñas de los usuarios, porque esto provoca que haya que modificar el código de las aplicaciones y los shell scripts.

Para solucionar esto, Oracle posee la opción Secure External Password Store (SEPS) que, mediante la creación de un wallet que almacena las credenciales, permite que las aplicaciones y los shell scripts se conecten a la base de datos utilizando ‘/@<cadena_de_conexión>’. SEPS está disponible a partir de la versión 10gR2 y no necesita licenciamiento adicional, es posible utilizarlo con cualquier edición de la base de datos, ya sea Standard o Enterprise.

La configuración de SEPS se deberá efectuar en todos los clientes que se vayan a conectar a la base de datos y quieran hacer uso de esta opción. En la imagen siguiente está configurado en un servidor de aplicaciones y en una máquina con un cliente Oracle.

Uso de SEPS

Vamos a explicar con un paso a paso como realizar la configuración de Secure External Password Store para conectarse a nuestra base de datos. Esto nos permitirá tener acceso sin explicitar las credenciales. Todos los pasos que se muestran se han efectuado con una versión 11gR2 en un Oracle Linux 5. En este caso, el cliente y la base de datos son la misma máquina, pero se procedería de manera similar si el cliente estuviera en otra máquina.

Leer más…