En las primeras versiones una de las cosas que más se echaban en falta era la encriptación en las comunicaciones entre los diversos elementos de la arquitectura.

Esto provocaba la necesidad, de cara a garantizar la seguridad de nuestras instalaciones, que se solventase mediante VPNs, túneles SSH y otras soluciones habituales para proteger servicios no seguros . Esto suponía una sobrecarga de los sistemas y complicaba su administración y mantenimiento.

Afortunadamente, la gente de Zabbix lo han solucionado y ya existe soporte, desde la versión 3.0, para cifrado de las comunicaciones basado en TLS v.1.2.

Como primer apunte técnico, y que nos parece una excelente idea es el soporte que han dado para 3 librerías diferentes: OpenSSL, GnuTLS y mbedTLS. Esto, además de dar una gran flexibilidad a la hora de utilizar alguna característica específica que nos pueda interesar de alguna de estas librerías o bibliotecas, puede ser vital en caso de que se descubra alguna vulnerabilidad en alguna de ellas (el infame Heartbleed por ejemplo), permitiendo cambiar a otra más segura de forma más o menos sencilla.

Una vez dicho esto, vamos a ver que 2 métodos de encriptado nos proponen:

• Clave precompartida (Pre-Shared Key): es el método más sencillo de configurar, pero probablemente el más difícil de gestionar a gran escala.
  
  Esencialmente se trata de generar una clave -de entre 32 y 512 caracteres- que tengan ambos -e idealmente solo ambos- extremos de la comunicación suficientemente compleja para que sea difícil de adivinar. Se configura en el campo que vemos en la imagen llamado "PSK". El campo "PSK identity" es un identificador básico que no es secreto y no se cifra; podríamos poner "muutech", por ejemplo, o un dominio.
  
  
• Basada en certificados: es el método más complejo de configurar (si no se está habituado a trabajar con certificados) pero sin duda es también la opción que mejor escala y mejor se puede gestionar al existir diversos métodos y software para la gestión segura de certificados.
  
  Como casi siempre que se trabaja con certificados, es necesario una entidad certificadora (CA o Certificate Authority) que firme los certificados que generamos. Zabbix no acepta certificados "auto-firmados". Esta entidad certificadora podemos ser nosotros mismos (es una cuestión de confianza) o usar un agente externo (tipo FNMT, GlobalSign, etc.). En Internet podréis encontrar 1001 tutoriales que os explicarán como se pueden generar y firmar estos certificados. La idea es generar y firmar un certificado para el servidor, para cada agente, proxy, etc cuya comunicación queramos cifrar. Estos certificados se meten el directorio adecuado para cada elemento, configuramos en el host / proxy lo que necesitemos como se ve en la imagen... et voilà!

Una de las cosas que nos gusta mucho es que no es obligatorio activar la encriptación para todas las comunicaciones, si no que se puede ir haciendo host a host, de manera gradual y compatible con agentes que tengamos instalados de versiones anteriores, permitiendo seleccionar individualmente el método elegido según el sentido de la comunicación: para las conexiones salientes podemos escoger sólo uno, pero para las entrantes podemos poner varias opciones, dando esa compatibilidad que buscamos.

En nuestra vista de hosts, podemos ver el tipo de encriptación en cada sentido. La primera casilla la encriptación del tráfico saliente ("NONE" en el ejemplo), que representaría la conexión del servidor con el agente por ejemplo, y en los 3 cuadrados de la derecha los método posibles para el tráfico entrante del agente al servidor:

¡Esperemos que os haya resultado útil! Cualquier duda o consulta, aquí estamos :)