Comment envoyer les journaux d'un appareil vers un collecteur distant en toute sécurité

L'appareil peut émettre des journaux, le collecteur se trouve de l'autre côté d'Internet, et la première question que tout le monde pose est quel tunnel construire. Ce cadrage part du mauvais endroit. Ce qui décide du transport, c'est le format que l'appareil peut produire, l'authentification que le collecteur acceptera et ce que « livré » doit signifier lorsque le lien tombe. Écrivez ces trois réponses, et le transport se choisit généralement tout seul.

Partez de ce que l'appareil peut émettre

En pratique, il n'existe que trois formes. Des événements syslog individuels sur UDP ou TCP, un envoi HTTPS authentifié intégré au produit, ou des fichiers complets écrits sur disque qu'il faut déplacer. Un pare-feu qui ne peut envoyer que du syslog UDP ne deviendra pas un émetteur TLS parce que vous avez ajouté un tunnel ; il continuera d'envoyer des datagrammes non acquittés, désormais dans une enveloppe chiffrée.

Commencez donc par inventorier l'émetteur : protocole, prise en charge de TLS et quelle bibliothèque TLS, s'il peut valider le certificat du collecteur, s'il peut présenter un certificat client et si le tampon d'envoi survit à un redémarrage. Tout ce que l'appareil ne peut pas faire doit être fait par autre chose sur le chemin, et cette autre chose fait partie de votre conception.

Syslog TLS : le chemin le plus court quand les deux extrémités le parlent

Si l'appareil prend en charge syslog sur TLS et que le collecteur le termine, utilisez-le et arrêtez-vous. Le protocole applicatif se protège lui-même, le collecteur authentifie l'émetteur, et il n'y a pas de saut supplémentaire dont vous possédez désormais la disponibilité. Le piège, c'est que « syslog TLS » couvre un large éventail d'implémentations, et les recommandations actuelles pour un syslog sûr ont dépassé les listes de chiffrement des anciens tutoriels, ce qui explique qu'un redirecteur fonctionnel devienne cassé après une mise à jour de bibliothèque.

Sur rsyslog, le nom du module de transport indique à lui seul à quelle époque vous êtes : lmnsd_gtls enveloppe GnuTLS, tandis que lmnsd_ossl enveloppe OpenSSL et c'est ce que livrent les paquets 8.x actuels. Une action de réexpédition avec vérification de certificat ressemble à peu près à ceci, et les noms exacts des paramètres méritent d'être vérifiés par rapport à votre version installée :

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")

Vérifiez le point de terminaison avant de déboguer l'émetteur. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error achève soit une poignée de main avec une chaîne valide, soit vous dit précisément quelle vérification a échoué. Testez depuis l'appareil, pas depuis votre ordinateur portable, car c'est le magasin de confiance de l'appareil qui compte.

SFTP : bon pour les fichiers, mauvais pour les flux

La livraison par fichiers convient aux appareils qui écrivent des journaux rotatifs et rien d'autre. Le transfert via SSH vous donne des clés d'hôte, des clés par compte et un système de fichiers que vous pouvez auditer, ce qui est une histoire de confiance raisonnable pour un appareil qui ne sait pas faire de TLS du tout. C'est un mauvais choix pour les flux d'événements, où « le fichier est écrit toutes les heures » signifie qu'une panne vous coûte la fin de l'heure en cours.

Gardez la vérification d'hôte activée. Une invocation par lots qui la désactive pour éviter une invite détruit la seule authentification dont dispose le transport :

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

Épinglez la clé d'hôte dans le known_hosts du compte lors du provisionnement, limitez le compte au répertoire cible et préférez le sous-système internal-sftp avec chroot. Planifiez aussi l'histoire de la réexpédition : si un fichier est renvoyé après un échec partiel, le collecteur doit distinguer un doublon d'un nouveau fichier, généralement par le nom plus la somme de contrôle plutôt que par l'heure d'arrivée.

Quand une passerelle locale ou un tunnel est la réponse honnête

Certains appareils ne savent parler qu'un format que personne ne veut exposer. Dans ce cas, un collecteur autorisé sur le réseau de l'appareil reçoit le format natif et le réachemine via TLS. C'est une conception légitime, mais soyez précis sur ce qu'elle achète : le chiffrement qui commence à la passerelle ne protège pas rétroactivement le segment entre l'appareil et la passerelle, donc ce saut a toujours besoin de sa propre frontière de confiance et de son contrôle d'accès.

Un tunnel routé de site ou d'appareil est l'option la plus lourde et la bonne lorsque le collecteur doit conserver une adresse privée et transporter plusieurs services, pas seulement des journaux. Il apporte la planification d'adresses, les règles d'accès, les chemins de retour et le cycle de vie du point de terminaison du tunnel. Il n'améliore pas non plus le protocole interne : le syslog UDP dans un tunnel IPsec reste un service de datagrammes sans accusé de livraison.

Quoi que vous choisissiez, gardez l'autorisation du collecteur plus étroite que le transport. L'identité d'un tunnel appartient à un point de terminaison et ne dit rien sur l'appareil en aval qui a produit tel champ de nom d'hôte dans un message.

Rédigez le contrat de livraison avant d'expédier

Le chiffrement, l'authentification et la rétention répondent à des questions différentes, et une file n'est pas une politique de rétention. Avant que le premier journal ne quitte l'appareil, décidez ce qu'un accusé signifie réellement sur ce collecteur : reçu sur le fil, accepté pour traitement ou écrit durablement dans le stockage. Ce sont trois garanties différentes et seule la dernière survit à un redémarrage du collecteur.

Répondez ensuite par écrit aux questions opérationnelles. Où attendent les événements non envoyés, et ce tampon survit-il à une coupure de courant ? Que se passe-t-il lorsqu'il se remplit, et qui est prévenu ? Comment les nouvelles tentatives sont-elles bornées, et comment les doublons sont-ils identifiés ? Quel champ prouve l'identité de l'émetteur, sachant qu'un saut de réexpédition peut réécrire le nom d'hôte ?

Gardez la conception assez petite pour l'expliquer en un paragraphe : le plus petit transport pris en charge qui achemine les événements requis, plus un énoncé explicite des garanties qu'il ne fournit pas. Si la réponse nécessite deux sauts, dites-le dans le runbook et donnez un responsable à chaque saut.