O dispositivo consegue emitir registos, o coletor está do outro lado da internet, e a primeira pergunta que todos fazem é qual túnel construir. Esse enquadramento começa no lugar errado. O que decide o transporte é o formato que o dispositivo consegue produzir, a autenticação que o coletor aceitará e o que «entregue» deve significar quando a ligação cai. Escreva essas três respostas, e o transporte escolhe-se normalmente sozinho.

Comece pelo que o dispositivo consegue emitir

Na prática existem apenas três formas. Eventos syslog individuais por UDP ou TCP, um carregamento HTTPS autenticado incorporado no produto, ou ficheiros completos escritos no disco que têm de ser movidos. Uma firewall que só consegue enviar syslog UDP não se torna um emissor TLS por ter acrescentado um túnel; continuará a enviar datagramas sem confirmação, agora dentro de um envelope cifrado.

Assim, comece por inventariar o emissor: protocolo, suporte de TLS e que biblioteca TLS, se consegue validar o certificado do coletor, se consegue apresentar um certificado de cliente e se o buffer de envio sobrevive a um reinício. Tudo o que o dispositivo não consegue fazer tem de ser feito por outra coisa no caminho, e essa outra coisa passa a fazer parte do seu desenho.

Syslog TLS: o caminho mais curto quando ambos os lados o falam

Se o dispositivo suporta syslog sobre TLS e o coletor o termina, use isso e pare. O protocolo de aplicação protege-se a si mesmo, o coletor autentica o emissor e não há nenhum salto adicional cuja disponibilidade agora possua. A armadilha é que «syslog TLS» cobre uma vasta gama de implementações, e as orientações atuais para syslog seguro foram além das listas de cifras dos tutoriais antigos, e é por isso que um reencaminhador a funcionar se estraga após uma atualização de biblioteca.

No rsyslog, o nome do módulo de transporte já lhe diz em que era está: lmnsd_gtls envolve o GnuTLS, enquanto lmnsd_ossl envolve o OpenSSL e é o que os pacotes 8.x atuais fornecem. Uma ação de reencaminhamento com validação de certificado parece-se aproximadamente com isto, e vale a pena verificar os nomes exatos dos parâmetros com a versão 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 ponto final antes de depurar o emissor. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ou completa um aperto de mão com uma cadeia válida ou diz-lhe exatamente que verificação falhou. Teste a partir do dispositivo, não do seu portátil, porque é o armazém de confiança do dispositivo que importa.

SFTP: bom para ficheiros, errado para fluxos

A entrega baseada em ficheiros adequa-se a dispositivos que escrevem registos rotativos e nada mais. A transferência por SSH dá-lhe chaves de anfitrião, chaves por conta e um sistema de ficheiros que pode auditar, o que é uma história de confiança razoável para um dispositivo que não consegue fazer TLS de todo. É uma má escolha para fluxos de eventos, onde «o ficheiro é escrito a cada hora» significa que uma falha lhe custa a cauda da hora atual.

Mantenha a verificação de anfitrião ligada. Uma invocação em lote que a desliga para evitar um pedido destrói a única autenticação que o transporte tem:

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

Fixe a chave de anfitrião no known_hosts da conta durante o aprovisionamento, restrinja a conta ao diretório de destino e prefira o subsistema internal-sftp com chroot. Planeie também a história do reenvio: se um ficheiro for reenviado após uma falha parcial, o coletor tem de distinguir um duplicado de um ficheiro novo, normalmente pelo nome mais a soma de verificação e não pela hora de chegada.

Quando um gateway local ou um túnel é a resposta honesta

Alguns dispositivos só sabem falar um formato que ninguém quer expor. Nesse caso, um coletor autorizado na própria rede do dispositivo recebe o formato nativo e reencaminha-o por TLS. É um desenho legítimo, mas seja preciso sobre o que compra: a cifragem que começa no gateway não protege retroativamente o segmento entre o dispositivo e o gateway, pelo que esse salto continua a precisar da sua própria fronteira de confiança e controlo de acesso.

Um túnel encaminhado de site ou de dispositivo é a opção mais pesada e a correta quando o coletor tem de conservar um endereço privado e transportar vários serviços, não apenas registos. Traz planeamento de endereços, regras de acesso, caminhos de retorno e o ciclo de vida do ponto final do túnel. Também não melhora o protocolo interno: o syslog UDP dentro de um túnel IPsec continua a ser um serviço de datagramas sem confirmação de entrega.

Escolha o que escolher, mantenha a autorização do coletor mais estreita do que o transporte. A identidade de um túnel pertence a um ponto final e não diz nada sobre que dispositivo a jusante produziu um determinado campo de nome de anfitrião numa mensagem.

Escreva o contrato de entrega antes de enviar

Cifragem, autenticação e retenção respondem a perguntas diferentes, e uma fila não é uma política de retenção. Antes de o primeiro registo sair do dispositivo, decida o que uma confirmação significa realmente neste coletor: recebido no cabo, aceite para processamento ou escrito de forma duradoura no armazenamento. São três garantias diferentes e só a última sobrevive a um reinício do coletor.

Depois responda por escrito às perguntas operacionais. Onde esperam os eventos não enviados, e esse buffer sobrevive a um corte de energia? O que acontece quando enche, e quem é avisado? Como são limitadas as tentativas, e como são identificados os duplicados? Que campo prova a identidade do emissor, dado que um salto de reencaminhamento pode reescrever o nome de anfitrião?

Mantenha o desenho suficientemente pequeno para o explicar num parágrafo: o menor transporte suportado que transporta os eventos necessários, mais uma declaração explícita das garantias que não oferece. Se a resposta precisar de dois saltos, diga-o no runbook e dê a cada salto um responsável.

Artigos relacionados