Como enviar os rexistros dun dispositivo a un colector remoto de forma segura

O dispositivo pode emitir rexistros, o colector está na outra beira de internet e a primeira pregunta que todos fan é que túnel construír. Ese enfoque comeza no lugar equivocado. O que decide o transporte é o formato que o dispositivo pode producir, a autenticación que aceptará o colector e o que debe significar «entregado» cando cae a ligazón. Escriba esas tres respostas e o transporte adoita elixirse só.

Comece polo que o dispositivo pode emitir

Na práctica só hai tres formas. Eventos syslog individuais por UDP ou TCP, unha carga HTTPS autenticada integrada no produto, ou ficheiros completos escritos no disco que hai que mover. Unha devasa que só pode enviar syslog UDP non se converterá en emisor TLS porque engadise un túnel; seguirá enviando datagramas sen confirmación, agora dentro dun sobre cifrado.

Así que primeiro faga inventario do emisor: protocolo, soporte de TLS e que biblioteca TLS, se pode validar o certificado do colector, se pode presentar un certificado de cliente e se o búfer de envío sobrevive a un reinicio. Todo o que o dispositivo non pode facer ten que facelo outra cousa no camiño, e esa outra cousa pasa a formar parte do seu deseño.

Syslog TLS: o camiño máis curto cando ambos os extremos o falan

Se o dispositivo admite syslog sobre TLS e o colector remátao, use iso e detéñase. O protocolo de aplicación protéxese a si mesmo, o colector autentica o emisor e non hai ningún salto adicional cuxa dispoñibilidade agora posúa. A trampa é que «syslog TLS» cobre unha ampla gama de implementacións, e as directrices actuais de syslog seguro pasaron das listas de cifrados dos titoriais antigos, e por iso un reenviador que funciona rompe tras actualizar unha biblioteca.

En rsyslog, o nome do módulo de transporte xa lle di en que época está: lmnsd_gtls envolve GnuTLS, mentres que lmnsd_ossl envolve OpenSSL e é o que traen os paquetes 8.x actuais. Unha acción de reenvío con validación de certificado parécese aproximadamente a isto, e paga a pena comprobar os nomes exactos dos parámetros coa 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 o extremo antes de depurar o emisor. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ou ben completa un saúdo cunha cadea válida ou ben lle di exactamente que comprobación fallou. Probe desde o dispositivo, non desde o seu portátil, porque o almacén de confianza do dispositivo é o que importa.

SFTP: bo para ficheiros, equivocado para fluxos

A entrega baseada en ficheiros convén a dispositivos que escriben rexistros rotativos e nada máis. A transferencia por SSH dálle claves de host, claves por conta e un sistema de ficheiros que pode auditar, o que é unha historia de confianza razoable para un dispositivo que non pode facer TLS en absoluto. É unha mala opción para fluxos de eventos, onde «o ficheiro escríbese cada hora» significa que unha caída lle custa a cola da hora actual.

Manteña activada a verificación do host. Unha invocación por lotes que a desactiva para evitar un aviso destrúe a única autenticación que ten o transporte:

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

Fixe a clave do host no known_hosts da conta durante o aprovisionamento, restrinxa a conta ao directorio de destino e prefira o subsistema internal-sftp con chroot. Planifique tamén a historia de reenvío: se un ficheiro se reenvía tras un fallo parcial, o colector debe distinguir un duplicado dun ficheiro novo, normalmente polo nome máis a suma de comprobación e non pola hora de chegada.

Cando unha pasarela local ou un túnel é a resposta honesta

Algúns dispositivos só saben falar un formato que ninguén quere expor. Nese caso, un colector autorizado na propia rede do dispositivo recibe o formato nativo e reenvíao por TLS. É un deseño lexítimo, pero sexa preciso sobre o que compra: o cifrado que comeza na pasarela non protexe retroactivamente o segmento entre o dispositivo e a pasarela, así que ese salto segue necesitando a súa propia fronteira de confianza e control de acceso.

Un túnel encamiñado de sitio ou de dispositivo é a opción máis pesada e a correcta cando o colector debe conservar un enderezo privado e transportar varios servizos, non só rexistros. Aporta planificación de enderezos, regras de acceso, rutas de retorno e o ciclo de vida do extremo do túnel. Tampouco mellora o protocolo interno: o syslog UDP dentro dun túnel IPsec segue sendo un servizo de datagramas sen confirmación de entrega.

Elixa o que elixa, manteña a autorización do colector máis estreita que o transporte. A identidade do túnel pertence a un extremo e non di nada sobre que dispositivo posterior produciu un campo de nome de host concreto nunha mensaxe.

Escriba o contrato de entrega antes de enviar

Cifrado, autenticación e retención responden a preguntas distintas, e unha cola non é unha política de retención. Antes de que o primeiro rexistro saia do dispositivo, decida que significa realmente unha confirmación neste colector: recibido no cable, aceptado para procesamento ou escrito de forma duradeira no almacenamento. Son tres garantías distintas e só a última sobrevive a un reinicio do colector.

Despois responda por escrito as preguntas operativas. Onde esperan os eventos non enviados e ese búfer sobrevive a un corte de luz? Que ocorre cando se enche e a quen se avisa? Como se limitan os reintentos e como se identifican os duplicados? Que campo demostra a identidade do emisor, dado que un salto de reenvío pode reescribir o nome de host?

Manteña o deseño o bastante pequeno para explicalo nun parágrafo: o transporte admitido máis pequeno que leve os eventos necesarios, máis unha declaración explícita das garantías que non ofrece. Se a resposta necesita dous saltos, dígao no runbook e dea a cada salto un responsable.