Cómo enviar los registros de un dispositivo a un colector remoto de forma segura

El dispositivo puede emitir registros, el colector está al otro lado de internet y la primera pregunta que todos hacen es qué túnel construir. Ese planteamiento empieza en el lugar equivocado. Lo que decide el transporte es el formato que el dispositivo puede producir, la autenticación que aceptará el colector y qué debe significar «entregado» cuando cae el enlace. Escriba esas tres respuestas y el transporte suele elegirse solo.

Empiece por lo que el dispositivo puede emitir

En la práctica solo hay tres formas. Eventos syslog individuales por UDP o TCP, una carga HTTPS autenticada integrada en el producto, o archivos completos escritos en disco que hay que mover. Un cortafuegos que solo puede enviar syslog UDP no se convertirá en emisor TLS porque haya añadido un túnel; seguirá enviando datagramas sin confirmación, ahora dentro de un sobre cifrado.

Así que primero haga inventario del emisor: protocolo, soporte de TLS y qué biblioteca TLS, si puede validar el certificado del colector, si puede presentar un certificado de cliente y si el búfer de envío sobrevive a un reinicio. Todo lo que el dispositivo no puede hacer tiene que hacerlo otra cosa en el camino, y esa otra cosa pasa a formar parte de su diseño.

Syslog TLS: el camino más corto cuando ambos extremos lo hablan

Si el dispositivo admite syslog sobre TLS y el colector lo termina, use eso y deténgase. El protocolo de aplicación se protege solo, el colector autentica al emisor y no hay ningún salto adicional cuya disponibilidad usted posea ahora. La trampa es que «syslog TLS» cubre una amplia gama de implementaciones, y las directrices actuales de syslog seguro han ido más allá de las listas de cifrados de los tutoriales antiguos, y por eso un reenviador que funciona se rompe tras actualizar una biblioteca.

En rsyslog, el nombre del módulo de transporte ya le dice en qué época está: lmnsd_gtls envuelve GnuTLS, mientras que lmnsd_ossl envuelve OpenSSL y es lo que traen los paquetes 8.x actuales. Una acción de reenvío con validación de certificado se parece aproximadamente a esto, y conviene comprobar los nombres exactos de los parámetros con la versión instalada:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Verifique el extremo antes de depurar el emisor. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error o bien completa un saludo con una cadena válida o bien le dice exactamente qué comprobación falló. Pruebe desde el dispositivo, no desde su portátil, porque el almacén de confianza del dispositivo es el que importa.

SFTP: bueno para archivos, equivocado para flujos

La entrega basada en archivos conviene a dispositivos que escriben registros rotativos y nada más. La transferencia por SSH le da claves de host, claves por cuenta y un sistema de archivos que puede auditar, lo que es una historia de confianza razonable para un dispositivo que no puede hacer TLS en absoluto. Es una mala opción para flujos de eventos, donde «el archivo se escribe cada hora» significa que una caída le cuesta la cola de la hora actual.

Mantenga activada la verificación del host. Una invocación por lotes que la desactiva para evitar un aviso destruye la única autenticación que tiene el transporte:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Fije la clave del host en el known_hosts de la cuenta durante el aprovisionamiento, restrinja la cuenta al directorio de destino y prefiera el subsistema internal-sftp con chroot. Planifique también la historia de reenvío: si un archivo se reenvía tras un fallo parcial, el colector debe distinguir un duplicado de un archivo nuevo, normalmente por el nombre más la suma de comprobación y no por la hora de llegada.

Cuando una puerta de enlace local o un túnel es la respuesta honesta

Algunos dispositivos solo saben hablar un formato que nadie quiere exponer. En ese caso, un colector autorizado en la propia red del dispositivo recibe el formato nativo y lo reenvía por TLS. Es un diseño legítimo, pero sea preciso sobre lo que compra: el cifrado que empieza en la puerta de enlace no protege retroactivamente el segmento entre el dispositivo y la puerta, así que ese salto sigue necesitando su propia frontera de confianza y control de acceso.

Un túnel enrutado de sitio o de dispositivo es la opción más pesada y la correcta cuando el colector debe conservar una dirección privada y transportar varios servicios, no solo registros. Aporta planificación de direcciones, reglas de acceso, rutas de retorno y el ciclo de vida del extremo del túnel. Tampoco mejora el protocolo interno: el syslog UDP dentro de un túnel IPsec sigue siendo un servicio de datagramas sin confirmación de entrega.

Elija lo que elija, mantenga la autorización del colector más estrecha que el transporte. La identidad del túnel pertenece a un extremo y no dice nada sobre qué dispositivo posterior produjo un campo de nombre de host concreto en un mensaje.

Escriba el contrato de entrega antes de enviar

Cifrado, autenticación y retención responden a preguntas distintas, y una cola no es una política de retención. Antes de que el primer registro salga del dispositivo, decida qué significa realmente una confirmación en este colector: recibido en el cable, aceptado para procesamiento o escrito de forma duradera en el almacenamiento. Son tres garantías distintas y solo la última sobrevive a un reinicio del colector.

Después responda por escrito las preguntas operativas. ¿Dónde esperan los eventos no enviados y ese búfer sobrevive a un corte de luz? ¿Qué ocurre cuando se llena y a quién se avisa? ¿Cómo se limitan los reintentos y cómo se identifican los duplicados? ¿Qué campo demuestra la identidad del emisor, dado que un salto de reenvío puede reescribir el nombre de host?

Mantenga el diseño lo bastante pequeño para explicarlo en un párrafo: el transporte admitido más pequeño que lleve los eventos necesarios, más una declaración explícita de las garantías que no ofrece. Si la respuesta necesita dos saltos, dígalo en el runbook y dé a cada salto un responsable.