Skip to end of metadata
Go to start of metadata



Índice

0. Visión general

WBSAirback® provee una solución unificada para la consolidación de almacenamiento y archivado de datos, así como la gestión de la seguridad de los mismos, permitiendo establecer diferentes niveles de acceso a estos en virtud de sus requerimientos de disponibilidad.

WBSAirback® supone una nueva generación en los sistemas de gestión y protección del almacenamiento, incluyendo funcionalidades capaces de gestionar almacenamiento heterogéneo para su uso como almacenamiento primario o como repositorio de backup, así como funcionalidades para la gestión del ciclo de vida del backup. Dichas funciones son gestionadas de una manera muy sencilla debido a que abstraen parte de la complejidad técnica y conceptual de los mencionados servicios.

WBSAirback® está basado en una plataforma de tipo appliance que integra todos los componentes lógicos necesarios en una única plataforma. No requiere la adquisición ni instalación de sistemas operativos ni aplicaciones de terceros para funcionar. Puede adquirirse como un appliance físico incluyendo la plataforma hardware adecuada a cada necesidad, o como un appliance virtual incluyendo los ficheros estándar necesarios para desplegar una máquina virtual en las principales plataformas de virtualización.

A través de una sencilla interfaz web accesible desde cualquier navegador, se puede realizar toda la administración y configuración del sistema y de sus funcionalidades principales.

Desde dicha interfaz se realiza la actualización de versiones, actualizaciones, parches, etc. con tan sólo dos o tres clicks.

El esquema general de la solución es el siguiente:


Figura 0: Visión general WBSAirback®

En este documento se presenta la funcionalidad que permite cifrar las comunicaciones entre los distintos actores que intervienen en un sistema WBSAirback®, proporcionando un nivel de seguridad adicional en la protección de los datos que viajan por las redes intermedias.

1. Introducción

La protección de los datos es uno de los mayores retos a los que se enfrentan las organizaciones TI en nuestros días. WBSAirback® presenta soluciones a varios niveles en este sentido, ya que es capaz de cifrar datos en los destinos de almacenamiento, perfilar y restringir a los usuarios del sistema de backup o utilizar un protocolo de acceso seguro en su capa de administración web, entre otras características. En el presente documento, presentamos el cifrado de las líneas de comunicación entre los diferentes servicios de backup que componen un entorno basado en WBSAirback®.

WBSAirback® está formado por tres servicios de backup:

  • El servicio Director es el encargado de orquestar y ejecutar todas las acciones del sistema: planificará backups, contactará con los agentes implicados, gestionará tiempos de ejecución, selecciona los dispositivos finales de almacenamiento. Tal y como el nombre sugiere, se trata del servicio principal que dirige la acción del módulo de backup. En un entorno WBSAirback®, este servicio será único y estará situado en un único equipo WBSAirback® (a menos que se utilice la función de alta disponibilidad, con la que tendríamos 2 equipos).
  • El servicio Storage se encarga de gestionar uno o varios dispositivos de almacenamiento: discos o cabinas de almacenamiento, librerías, dispositivos en la nube, etc. Un mismo servicio director puede gestionar y contactar con diversos servicios Storage. Cada uno de ellos se situaría en una unidad independiente de WBSAirback®. En un entorno WBSAirback®, podemos tener múltiples unidades que actúen únicamente como servicio storage, estas unidades se denominan MediaServers.
  • El servicio File o servicio de Cliente, es el encargado de leer datos de backup o escribir datos de recuperación en cada uno de los equipos finales que se han de respaldar en un entorno que use WBSAirback®. Por lo tanto, tendremos un servicio File por cada equipo cliente a respaldar.

Cada uno de estos 3 servicios de backup, se comunica con los demás utilizando una red basada en el protocolo TCP/IP durante el proceso de backup. En general, se recomienda situar la solución de backup en una red aislada, detrás de una DMZ, para evitar posibles interceptaciones o accesos no deseados a los datos respaldados. Sin embargo, esta medida no siempre es posible y tampoco es suficiente por sí misma para garantizar un nivel alto de seguridad sobre los datos que son transmitidos por la red. Para ofrecer ese nivel extra de seguridad, WBSAirback® ofrece la posibilidad de cifrar todas las comunicaciones entre sus 3 servicios de backup utilizando el protocolo de transporte seguro (Transport Layer Secure) TLS.

Nota: A partir de la versión 19.00.00 de , las comunicaciones van cifradas por defecto. Por lo tanto, utilice sólo este tipo de configuración si considera necesario personalizar los certificados implicados.

2. El protocolo TLS

El protocolo TLS (Transport Layer Secure) es una evolución del protocolo clásico de acceso seguro SSL. En la actualidad es muy habitual hablar de una conexión de acceso seguro SSL, especialmente en un entorno web, cuando realmente se está utilizando el protocolo TLS.

Con este protocolo se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor. Así el intercambio de información se realiza en un entorno seguro y libre de ataques. La última propuesta de estándar está documentada en la referencia RFC 2246.

Normalmente el servidor es el único que es autenticado, garantizando así su identidad, pero el cliente se mantiene sin autenticar, ya que para la autenticación mutua se necesita una infraestructura de claves públicas (o PKI) para los clientes. En WBSAirback® será necesario tener autenticadas ambas partes para el correcto funcionamiento de esta tecnología de cifrado.

El uso de este tipo de protocolos permiten prevenir escuchas de un posible intruso que se situase en medio de dos elementos del sistema (Man-in-the-middle), evitar la falsificación de la identidad del remitente y mantener la integridad del mensaje en una aplicación cliente-servidor.

A continuación se detallan las fases básicas implicadas con este protocolo:

  1. Negociación: Los dos extremos de la comunicación negocian que algoritmos criptográficos utilizarán para autenticarse y cifrar la información. Existen diferentes opciones:
    1. Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm).
    2. Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Standard).
    3. Con funciones hash: MD5 o de la familia SHA.
  2. Autenticación: Se autentican los extremos mediante certificados digitales e intercambian las claves para el cifrado, según la negociación.
  3. Transmisión: Se inicia la comunicación y transmisión de datos cifrados.

3. Requisitos

Para poder activar esta funcionalidad es necesario disponer de los certificados digitales adecuados para cada una de las partes. En WBSAirback® necesitaremos:

  • Un certificado raíz o CA que será compartido por todos los equipos WBSAirback® y clientes finales
  • Un certificado generado a partir del certificado CA para cada uno de los equipos implicados. Uno para cada WBSAirback® y uno para cada cliente final
    • El archivo de clave asociado a cada uno de estos certificados.

Para poder conseguir un certificado CA autorizado, será necesario que adquiera uno a través de los diferentes comercializadores de certificados PKI disponibles por la red. También puede elegir convertirse usted mismo en entidad certificadora CA.

Los certificados utilizados, deben estar en formato PEM (RFC 1421-1424).

Esta característica de cifrado está soportada a partir de la versión 15.5.7 de WBSAirback®.

4. Certificados autofirmados

Aunque no es el objetivo de este documento, a continuación se presenta un procedimiento sencillo para generar certificados auto-firmados con la herramienta OpenSSL que podrían ser empleados para construir una comunicación exitosa con el protoclo TLS en WBSAirback®. Por supuesto, nuestra recomendación es la adquisición de certificados reales firmados por la correspondiente entidad certificadora.

4.1. Generar certificado CA

El primer paso es generar el certificado CA con su correspondiente clave. Es importante generar la clave en un equipo totalmente seguro. Idealmente, este equipo debería estar en un lugar seguro y completamente aislado de cualquier red de datos cableada o inalámbrica.

Clave CA
openssl genrsa -aes256 -passout pass:wbstest -out ca.key.pem 4096

Una vez tenemos la clave, podemos generar el certificado CA que se haga servir de la misma. En este caso, introduciremos datos de WBS:

Certificado CA
openssl req -key ca.key.pem -new -x509 -days 10000 -sha256 -extensions v3_ca -out ca.cert.pem -passin pass:wbstest -subj "/C=ES/ST=Madrid/L=LasRozas/O=WHITEBEARSOLUTIONS/OU=ResearchAndDevelopment/CN=wbsgo.com"

Es importante introducir el dominio general de la entidad en el campo CN. Por otro lado, en este caso de testing, no pretendemos que el certificado caduque, por ello hemos indicado 10000 días.

4.2. Generar un certificado en base al certificado CA

Sería necesario realizar este paso para cada uno de los servidores que compongan el entorno. Uno para cada WBSAirback®  y otro para cada cliente final. El procedimiento consiste en:

4.2.1. Generar clave

Generar clave
openssl genrsa -out key.pem 4096

4.2.2. Generar petición de certificado

Generar csr
openssl req -new -key key.pem -out cert.csr -passin pass:wbstest -subj "/C=ES/ST=Madrid/L=LasRozas/O=WHITEBEARSOLUTIONS/OU=ResearchAndDevelopment/CN=wbsairback/subjectAltName=DNS.1=localhost,DNS.2=192.168.1.85"

Es en este punto donde tendremos que indicar los nombres de dominio para la máquina concreta que va a utilizar el certificado generado. El valor de DNS se ha de indicar en el parámetro CN. Aunque también podemos indicar nombres alternativos en el campo subjectAltName, tal y como muestra el ejemplo. Es importante definir correctamente estos valores, tanto si se trata de un certificado auto-firmado como sino. En caso de que el motor de backup de WBSAirback® detecte que el nombre de host de la máquina no se corresponde con el CN o los valores alternativos, la conexión TLS no tendrá éxito.

4.2.3. Generamos el certificado final en base a la petición

Certificado Final
openssl x509 -req -days 3650 -in cert.csr -CA ca.cert.pem -CAkey ca.key.pem -passin pass:wbstest -set_serial 01 -out cert.crt

Con este último paso ya tendríamos el certificado y clave final para su uso en WBSAirback®. En este ejemplo, los 3 ficheros generados que nos haría falta utilizar son:

  • ca.cert.pen: Certificado CA
  • cert.crt: Certificado
  • key.pem: Clave para el certificado

5. Configuración

5.1. Configuración en WBSAirback®

Antes de configurar TLS en WBSAirback®, es muy importante considerar la importancia del nombre de host cuando configuramos certificados en cualquier entorno. El certificado generado para WBSAirback® debe reflejar en su CN el nombre de host configurado. El nombre de host por defecto es wbsairback. Si es necesario ajustarlo, es posible hacerlo accediendo a la pantalla de configuración de red (Sistema > Opciones de red):

Figura 1: Hostname


El segundo punto importante a considerar, es cómo afecta el nombre de host a los repositorios. Los repositorios configurados para el servicio storage de un WBSAirback®, utilizan su IP  o nombre configurado para comunicarse con el resto de servicios. Cuando se activa TLS, es importante configurar el nombre o CN del certificado en cada uno de los respositorios configurados. Por ejemplo, para el CN=wbsairback que hemos utilizado de ejemplo, sería necesaria la configuración que se muestra en la imagen siguiente:

 

Figura 2: Repositorio TLS


En caso de no ajustar correctamente estos valores, los trabajos finalizarán con código 193, mostrando mensajes de este tipo:


22/02/2017 18:45winSQL JobId 2323: Fatal error: lib/bnet.c:274 TLS host certificate verification failed. Host name "192.168.1.85" did not match presented certificate
22/02/2017 18:45winSQL JobId 2323: Fatal error: TLS negotiation failed.

Tras resolver estas primeras consideraciones, la configuración del cifrado TLS es muy sencilla en WBSAirback®. Es necesario activar la característica y subir los archivos de certificado y claves asociados en la pestaña de configuración del sistema (Sistema > Opciones genéricas):

Figura 3: Configuración de TLS

En los ejemplos del apartado 4 del presente documento, sería necesario subir los 3 archivos finales obtenidos.

No es posible activar TLS cuando hay trabajos en ejecución, pues esta configuración requiere del reinicio de los servicios de backup. Además, se recomienda configurar esta característica con suficiente ventana de actuación, en la que no se estén realizando o planificando backups, para permitir cualquier tipo de acción correctiva en cuanto a la generación y/o modificación de los certificados y sus formatos asociados.


5.1.1. Requerir TLS

El check 'Requerir TLS' forzaría una correcta configuración TLS, como requisito para cualquier elemento que intente contactar con este WBSAirback®. Cualquier cliente o WBSAirback® con el rol MediaServer que no tuviese una configuración TLS correcta y activa, no  podría contactar con esta unidad WBSAirback. En general, a menos que exista seguridad de que todos los actores implicados utilizarán esté método de cifrado de conexiones, se recomienda dejar la opción desactivada.

En caso de intentar conectar un cliente sin TLS a un equipo que WBSAirback® que si tiene activada esta característica, los trabajos de backup finalizarán con el código de retorno 8 y mensajes de este tipo:

21/02/2017 18:35winSQL JobId 2288: Fatal error: Authorization problem: Remote server requires TLS.
21/02/2017 18:35airback-dir JobId 2288: Start Backup JobId 2288, Job=jobDiferente.2017-02-21_18.35.12_10
21/02/2017 18:35airback-dir JobId 2288: Using Device "repoWin-vDrive-1" to write.
21/02/2017 18:35airback-sd JobId 2288: Fatal error: Authorization problem: Remote server did not advertize required TLS support.
21/02/2017 18:35airback-sd JobId 2288: Fatal error: Incorrect authorization key from File daemon at client rejected.
For help, please see: http://www.bacula.org/rel-manual/en/problems/Bacula_Frequently_Asked_Que.html
21/02/2017 18:35airback-sd JobId 2288: Fatal error: Unable to authenticate File daemon

5.2. Configuración de cada cliente

Una vez TLS está activado a nivel de WBSAirback, es necesario activarlo en cada uno de los clientes oportunos. La activación consta de dos partes. En primer lugar, es necesario activarlo en la pantalla de edición de cliente en WBSAirback® con el check correspondiente:

Figura 4: Cifrado TLS en un cliente

En segundo lugar, será necesario llevar los certificados oportunos (Certificado CA, certificado y clave específicos para cada máquina) a la máquina cliente final.

Es necesario situar estos certificados en un directorio accesible para el usuario que ejecuta el servicio Bacula-fd. Por ejemplo, podemos crear un directorio 'SSL' en la ruta de instalación de Bacula. En los ejemplos del punto 4, sería necesario genera otro certificado para esta máquina final (sección 4.2).

Una vez tenemos situados los certificados, es necesario incluir las siguientes líneas de configuración en el archivo de configuración del servicio File (bacula-fd.conf):

bacula-fd.conf
FileDameon {
... 
  TLS Enable = yes
  TLS Require = yes
  TLS CA Certificate File = "C:\\Program Files\\Bacula\\ssl\\ca.cert.pem"
  TLS Certificate = "C:\\Program Files\\Bacula\\ssl\\cert-win.crt"
  TLS Key = "C:\\Program Files\\Bacula\\ssl\\key-win.pem"
...
}
...


Tras modificar el fichero, es necesario reiniciar el servicio.

Se recomienda comprobar la correcta conexión entre WBSAirback® y cada cliente con TLS tras la activación de esta característica en cada uno de los equipos. También lanzar un primer backup que certifique que la conexión es exitosa.

6. Contacto

Consultas o dudas relativas al presente documento, pueden dirigirlas a:

e: jorge.gea@wbsgo.com


WBSAirback
15

WhiteBearSolutions, WBSgo y sus correspondientes logos son marcas registradas propiedad de WhiteBearSolutions, S.L.
WhiteBearSolutions realiza los mayores esfuerzos para asegurar que la información facilitada en el presente documento es precisa y exacta. No obstante, no se responsabiliza de cualquier error o inexactitud de la misma recogido en el documento.
Las especificaciones e informaciones recogidas en el presente documento pueden ser modificadas sin previo aviso.

WhiteBearSolutions

Calle Severo Ochoa 3, Planta 1, Of. 7A - 28232, Las Rozas (Madrid)
t. 902 90 69 69 f. 902 90 69 70 
  • No labels