Как безопасно отправлять журналы устройства на удалённый коллектор

Устройство может выдавать журналы, коллектор находится на другой стороне интернета, и первый вопрос, который все задают, — какой туннель строить. Такая постановка начинается не с того места. Транспорт определяют формат, который устройство способно создавать, аутентификация, которую примет коллектор, и то, что должно означать «доставлено», когда связь оборвётся. Запишите эти три ответа, и транспорт обычно выбирается сам.

Начните с того, что устройство может выдавать

На практике есть только три формы. Отдельные события syslog по UDP или TCP, аутентифицированная загрузка HTTPS, встроенная в продукт, или целые файлы, записанные на диск, которые нужно переместить. Межсетевой экран, умеющий отправлять только syslog по UDP, не станет отправителем TLS из-за того, что вы добавили туннель; он продолжит слать неподтверждённые датаграммы, теперь внутри зашифрованного конверта.

Поэтому сначала проведите инвентаризацию отправителя: протокол, поддержка TLS и какая именно библиотека TLS, умеет ли он проверять сертификат коллектора, может ли предъявить клиентский сертификат и переживает ли буфер отправки перезагрузку. Всё, чего устройство не умеет, должен сделать кто-то другой на пути, и этот кто-то становится частью вашего проекта.

TLS syslog: самый короткий путь, когда обе стороны его понимают

Если устройство поддерживает syslog через TLS, а коллектор его терминирует, используйте это и остановитесь. Прикладной протокол защищает сам себя, коллектор аутентифицирует отправителя, и нет лишнего перехода, доступность которого теперь на вас. Ловушка в том, что «TLS syslog» охватывает широкий спектр реализаций, и нынешние рекомендации по безопасному syslog ушли дальше списков шифров из старых руководств, и поэтому работающий пересыльщик ломается после обновления библиотеки.

В rsyslog уже само имя транспортного модуля говорит, в какой вы эпохе: lmnsd_gtls оборачивает GnuTLS, а lmnsd_ossl оборачивает OpenSSL и именно это поставляют текущие пакеты 8.x. Действие пересылки с проверкой сертификата выглядит примерно так, и точные имена параметров стоит сверить с установленной версией:

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

Проверьте конечную точку, прежде чем отлаживать отправителя. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error либо завершает рукопожатие с корректной цепочкой, либо точно сообщает, какая проверка не прошла. Тестируйте с устройства, а не с ноутбука, потому что важен именно набор доверенных сертификатов устройства.

SFTP: хорош для файлов, плох для потоков

Доставка на основе файлов подходит устройствам, которые пишут только ротируемые журналы. Передача по SSH даёт ключи хоста, ключи на каждый аккаунт и файловую систему, которую можно проверять, — разумная история доверия для устройства, которое вообще не умеет TLS. Для потоков событий это плохой выбор: «файл пишется каждый час» означает, что сбой стоит вам хвоста текущего часа.

Оставьте проверку хоста включённой. Пакетный вызов, который отключает её, чтобы избежать запроса, уничтожает единственную аутентификацию, которая есть у транспорта:

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

Закрепите ключ хоста в known_hosts аккаунта при подготовке, ограничьте аккаунт целевым каталогом и предпочитайте подсистему internal-sftp с chroot. Продумайте и историю повторной отправки: если файл отправляют снова после частичного сбоя, коллектор должен отличать дубликат от нового файла, обычно по имени и контрольной сумме, а не по времени поступления.

Когда локальный шлюз или туннель — честный ответ

Некоторые устройства умеют говорить только в формате, который никто не хочет выставлять наружу. В этом случае уполномоченный коллектор в сети самого устройства принимает исходный формат и передаёт его дальше по TLS. Это законный проект, но будьте точны в том, что он покупает: шифрование, начинающееся на шлюзе, не защищает задним числом участок между устройством и шлюзом, поэтому этому переходу всё ещё нужны собственные граница доверия и контроль доступа.

Маршрутизируемый туннель площадки или устройства — самый тяжёлый вариант и правильный, когда коллектор должен сохранить частный адрес и нести несколько сервисов, а не только журналы. Он приносит планирование адресов, правила доступа, обратные маршруты и жизненный цикл конечной точки туннеля. Он также не улучшает внутренний протокол: syslog по UDP внутри туннеля IPsec остаётся службой датаграмм без подтверждения доставки.

Что бы вы ни выбрали, держите авторизацию коллектора уже транспорта. Идентичность туннеля принадлежит конечной точке и ничего не говорит о том, какое нижестоящее устройство создало данное поле имени хоста в сообщении.

Запишите договор о доставке до отправки

Шифрование, аутентификация и хранение отвечают на разные вопросы, а очередь не является политикой хранения. Прежде чем первый журнал покинет устройство, решите, что подтверждение на этом коллекторе означает на самом деле: получено по сети, принято в обработку или надёжно записано в хранилище. Это три разные гарантии, и только последняя переживает перезапуск коллектора.

Затем письменно ответьте на эксплуатационные вопросы. Где ждут неотправленные события и переживает ли этот буфер отключение питания? Что происходит при заполнении и кого об этом извещают? Как ограничены повторы и как определяются дубликаты? Какое поле доказывает личность отправителя, учитывая, что переход пересылки может переписать имя хоста?

Держите проект достаточно малым, чтобы объяснить его одним абзацем: самый маленький поддерживаемый транспорт, который несёт нужные события, плюс явное заявление о гарантиях, которых он не даёт. Если ответ требует двух переходов, скажите это в runbook и назначьте каждому переходу владельца.