blog

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:

Cuando se realiza esta configuración con Oracle Net Manager el contenido de sqlnet.ora se modificará, dependiendo de la selección que se haya realizado, añadiendo las líneas siguientes:

Para el cifrado en el servidor:

Para el cifrado en el cliente:

Para la integridad en el servidor:

Para la integridad en el cliente:

Como se ha visto, es posible, tanto para el cliente como para el servidor, soportar más de un algoritmo de cifrado o integridad. Cuando la conexión se realiza, el servidor busca una coincidencia entre los algoritmos disponibles, tanto en el cliente como en el servidor, y escoge el primer algoritmo de su lista que también aparezca en la del cliente. Si uno de los dos (o ambos) no especifica una lista de algoritmos, todos los algoritmos instalados son aceptables. En caso de que no haya coincidencia, la conexión falla.

Para negociar si activar el cifrado y la integridad, se pueden especificar cuatro posibles valores en los parámetros de configuración. Estos valores se nombran a continuación, en orden de menos seguro a más seguro, es decir, el valor REJECTED proporciona el mínimo de seguridad y el valor REQUIRED proporciona el máximo:

• REJECTED
• ACCEPTED
• REQUESTED
• REQUIRED

El valor por defecto tanto para servidor como para cliente es ACCEPTED, esto significa que se pueden activar los ajustes deseados de cifrado e integridad simplemente configurando un lado de la conexión, ya sea servidor o cliente. De esta manera, si por ejemplo se tuviesen muchos clientes conectándose a una base de datos, se puede realizar la configuración de cifrado en integridad para todas esas conexiones, haciendo los cambios apropiados únicamente en la base de datos. No es necesario realizar esta configuración en cada cliente de manera separada.

Las implicaciones de cada valor son las siguientes:

• REJECTED: seleccionar este valor si se elige no activar el servicio de seguridad, aunque sea requerido por el otro lado de la conexión. En este escenario, este lado de la conexión especifica que el servicio de seguridad no está permitido. Si el otro lado de la conexión está configurado a REQUIRED, la conexión da error. Si el otro lado de la conexión está configurado a REQUESTED, ACCEPTED, o REJECTED, la conexión continúa sin error y sin la seguridad activada.
• ACCEPTED: seleccionar este valor para activar la seguridad si es requerida o solicitada por el otro lado de la conexión. En este escenario, este lado de la conexión no requiere seguridad, pero se activa si en el otro lado está configurada a REQUIRED o REQUESTED. Si en el otro lado está configurada a REQUIRED o REQUESTED, y se encuentra una coincidencia en el algoritmo de cifrado o integridad, la conexión continua sin error y con el servicio de seguridad activado. Si el otro lado está configurado a REQUIRED y no se encuentra una coincidencia en el algoritmo, la conexión termina con error. Si el otro lado está configurado a REQUESTED y no se encuentra una coincidencia en el algoritmo, o si está configurado a ACCEPTED o REJECTED, la conexión continua sin error y sin el servicio de seguridad activado.
• REQUESTED: seleccionar este valor para activar el servicio de seguridad si el otro lado lo permite. En este escenario, este lado de la conexión especifica que el servicio de seguridad es deseado pero no requerido. El servicio de seguridad se activa si el otro lado especifica ACCEPTED, REQUESTED o REQUIRED. Debe haber una coincidencia de algoritmo disponible en el otro lado, si no el servicio no se activa. Si el otro lado especifica REQUIRED y no hay coincidencia de algoritmo, la conexión falla.
• REQUIRED: seleccionar este valor para activar el servicio de seguridad o impedir la conexión. En este escenario, este lado de la conexión especifica que el servicio de seguridad debe estar activado. La conexión falla si el otro lado especifica REJECTED o si no hay un algoritmo compatible.

La tabla siguiente muestra todas las combinaciones de valores en cliente y servidor, y el resultado de esta combinación, si se activa el servicio de seguridad, si no, o si falla la conexión:

Hemos visto cómo configurar el tráfico de datos seguros entre un servidor de base de datos y sus clientes. Como conclusión se podría sacar que, si se desea activar esta seguridad con una intervención mínima y un impacto prácticamente nulo, bastaría con poner el servidor en REQUESTED. Como siempre, antes de configurarlo en un entorno productivo, es recomendable probarlo en desarrollo y/o preproducción.