TLS PSK в Zabbix: как защитить канал между агентом и сервером

Метрики часто проходят через несколько узлов. Агент собирает данные на сервере. Затем он передаёт их Zabbix Server или прокси. Если канал открыт, злоумышленник может увидеть значения и вмешаться в обмен.

TLS PSK закрывает этот канал шифрованием. PSK означает предварительно согласованный ключ. Стороны заранее знают общий секрет и проверяют друг друга во время соединения.

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

🔍 Что именно защищает TLS PSK

Шифрование скрывает данные от наблюдателя в сети. Это важно для метрик, имён узлов и служебного обмена. Защита действует только между участниками TLS-соединения.

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

При этом PSK не доказывает безопасность операционной системы. Вредоносная программа с доступом к файлу ключа может использовать этот секрет. Компрометация агента поэтому требует отдельного расследования.

Шифрование не равно полной защите

Канал может быть зашифрован, а права на метрики останутся чрезмерными. Сервис мониторинга может иметь доступ к лишним файлам. Пароль базы может лежать рядом с ключом PSK.

Нельзя смешивать три значения. Идентификатор PSK сообщает имя ключа. Сам PSK является секретом. Пароль PostgreSQL относится к учётной записи базы.

Что сделать сейчас: составьте перечень секретов. Отдельно укажите PSK, его идентификатор и учётные данные PostgreSQL.

🧩 Как устроен обмен в Zabbix

В типовой схеме агент работает на контролируемом узле. Он получает параметры от сервера или отправляет собранные значения. Сервер принимает данные и хранит состояние мониторинга.

Прокси занимает промежуточное положение. Он собирает метрики в отдельном сегменте. Затем передаёт их серверу по своему защищённому соединению.

Для каждого направления задают режимы подключения. Один параметр описывает, как компонент подключается. Другой определяет, какие подключения компонент принимает.

Нельзя считать прокси частью одного общего доверенного канала. У него есть собственные соединения и собственные настройки. Каждый участок проверяют отдельно.

Одна ошибка в имени узла, порте или режиме шифрования останавливает передачу. Метрики при этом могут успешно собираться локально. Проблема проявляется только на этапе отправки.

Что сделать сейчас: нарисуйте схему потоков. Для каждого потока запишите сторону подключения, сторону приёма и используемый ключ.

⚙️ Параметры TLS в конфигурации

В Zabbix для выбора режима подключения используют параметр TLSConnect. Он задаёт способ, которым компонент устанавливает соединение. В защищённом контуре выбирают режим с PSK.

Параметр TLSAccept определяет допустимые входящие соединения. Он нужен серверу, прокси и агенту, если компонент принимает данные. Значение должно соответствовать политике конкретного узла.

TLSPSKIdentity хранит идентификатор ключа. Это не сам секрет. Идентификатор должен однозначно указывать на нужную пару настроек.

TLSPSKFile указывает файл с предварительно согласованным ключом. Файл содержит секрет и требует строгого контроля доступа. Его нельзя считать обычным текстовым параметром.

• TLSConnect — режим исходящего подключения.
• TLSAccept — режим принимаемых подключений.
• TLSPSKIdentity — открытый идентификатор PSK.
• TLSPSKFile — путь к файлу с секретом PSK.

Параметры должны совпадать по смыслу на обеих сторонах. Идентификатор и ключ также должны соответствовать друг другу. Даже один лишний символ ломает проверку.

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

🛡️ Как выбрать и хранить PSK

Ключ должен быть случайным и достаточно длинным. Не создавайте его из имени узла, даты или пароля администратора. Такие значения легко угадываются по инвентарю.

Для каждого агента лучше использовать отдельный ключ. Допустима общая пара для небольшой группы с одной зоной доверия. Один ключ на всю инфраструктуру создаёт большой радиус компрометации.

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

Ключ не передают в командной строке. Командная строка попадает в историю и списки процессов. Секрет также не помещают в систему контроля версий.

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

• Создайте уникальный случайный ключ.
• Назначьте отдельный файл для каждой зоны доверия.
• Ограничьте чтение файла процессом Zabbix.
• Исключите файл из репозиториев и резервных копий общего доступа.
• Проверьте права после изменения владельца или пакета.

Что сделать сейчас: найдите все копии PSK. Удалите секреты из команд, репозиториев и открытых рабочих заметок.

🔄 Ротация и отзыв ключей

PSK нельзя считать вечным паролем. Ключ меняют при увольнении администратора, подозрении на утечку или переносе узла. Ротация также входит в плановую работу.

Без плана замена вызывает простой мониторинга. Сначала определяют владельца секрета. Затем готовят новый ключ и окно изменения.

При ротации меняют настройки на обеих сторонах. После этого проверяют установку TLS-соединения. Затем смотрят поступление новых метрик и ошибки старого ключа.

Отзыв нужен быстрее плановой замены. Скомпрометированный секрет удаляют из доверенных настроек. Одновременно проверяют журналы и доступ к файлу.

Безопасная последовательность

1. Определите агента, сервер или прокси, которые используют ключ.
2. Создайте новый PSK и новый идентификатор.
3. Ограничьте доступ к новому файлу.
4. Синхронно измените настройки соединения.
5. Перезапустите нужный компонент по принятой процедуре.
6. Проверьте журнал TLS и поступление метрик.
7. Удалите старый секрет после подтверждения результата.

Храните сведения о замене в журнале изменений. Не записывайте туда сам ключ. Достаточно указать узел, время, идентификатор и ответственного.

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

🗄️ Почему PostgreSQL требует отдельной защиты

Mamonsu подключается к PostgreSQL и собирает специализированные метрики. Затем он передаёт значения в Zabbix. Эти два соединения имеют разные настройки безопасности.

TLS PSK между отправителем и Zabbix не защищает подключение Mamonsu к PostgreSQL. У базы есть собственные учётные записи, права и сетевые правила.

Для PostgreSQL отдельно настраивают TLS-сертификаты. Доступ контролируют через pg_hba.conf. Удалённое подключение отключают, если оно не нужно.

Учётная запись мониторинга получает минимальные привилегии. Ей не нужны права администратора без ясной причины. Пароль базы не совпадает с PSK.

Такое разделение снижает последствия ошибки. Утечка ключа Zabbix не должна автоматически давать доступ к базе. Утечка пароля базы не должна открывать канал мониторинга.

• Проверьте сертификаты и режим TLS PostgreSQL.
• Проверьте правила pg_hba.conf.
• Запретите ненужные удалённые подключения.
• Оставьте мониторингу только нужные права.
• Используйте отдельные учётные данные и секреты.

Что сделать сейчас: составьте две проверки. В первой укажите канал Zabbix. Во второй укажите доступ Mamonsu к PostgreSQL.

🧪 Диагностика, если метрики не доходят

Начинайте проверку с локального сбора. Mamonsu должен видеть PostgreSQL и формировать значения. Если этого нет, TLS Zabbix ещё не является главной проблемой.

Следующий шаг — журнал отправителя. Ищите ошибки соединения, идентификатора и чтения файла. Не ограничивайтесь сообщением «метрики отсутствуют».

Затем сравните адрес, порт и имя узла. Проверьте режимы TLSConnect и TLSAccept. Отдельно проверьте доступ процесса к TLSPSKFile.

Практический кейс показывает важность такого разделения. В Mamonsu версии 3.5.17 метрики собирались успешно. Но отправитель создавал обычный TCP-сокет без поддержки TLS PSK.

В такой ситуации смена пароля PostgreSQL не исправит передачу. Не поможет и повторная проверка списка метрик. Нужно проверять поддержку выбранного режима в компоненте отправки.

Короткая последовательность проверки

1. Подтвердите сбор метрик на узле.
2. Проверьте поддержку TLS PSK конкретной версией компонента.
3. Сверьте TLSConnect и TLSAccept.
4. Сверьте TLSPSKIdentity на обеих сторонах.
5. Проверьте путь и права TLSPSKFile.
6. Изучите журналы сервера, прокси и агента.
7. Проверьте новые значения после исправления.

Не меняйте сразу все параметры. Иначе журнал не покажет причину. Изменяйте один блок настроек и фиксируйте результат.

Что сделать сейчас: воспроизведите одну отправку в тестовом контуре. Сохраните журнал до и после изменения настройки.

📋 Журналирование и контроль событий

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

Для расследования важны границы доверия. Нужно знать, какой агент устанавливает соединение. Также важно понимать, идёт ли трафик напрямую или через прокси.

Сам секрет в журнал не записывают. Идентификатор можно использовать для поиска события. Он помогает отличить один ключ от другого.

Мониторинг должен показывать не только наличие значения. Полезно контролировать состояние отправки, ошибки TLS и задержки. Отдельно отмечают резкое исчезновение данных от одного узла.

Современные системы наблюдения учитывают действия и контекст. Для защищённого мониторинга это означает связь события с узлом, каналом и секретом. Такой контекст ускоряет проверку инцидента.

После смены ключа сравните события до и после операции. Старый идентификатор не должен продолжать работать. Если он работает, проверьте копии конфигурации и прокси.

Что сделать сейчас: создайте правило оповещения о повторных ошибках TLS. Добавьте в событие имя узла и направление соединения.

📊 PSK или сертификаты: что выбрать

PSK проще начать использовать. Не нужно выпускать сертификат для каждого участника. Это сокращает число шагов в небольшом контуре.

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

PSK сложнее масштабировать без дисциплины. При общем ключе растёт зона доверия. При отдельных ключах увеличивается число секретов и операций ротации.

Критерий	TLS PSK	Сертификаты
Запуск	Проще при малом числе узлов	Требует инфраструктуры сертификатов
Секреты	Общий ключ у пары участников	Закрытый ключ и сертификат узла
Масштабирование	Нужен контроль множества PSK	Нужны выпуск и отзыв сертификатов
Риск общего доверия	Высокий при одном ключе	Ниже при раздельных сертификатах

Незашифрованное подключение проще технически. Но оно не скрывает метрики и не проверяет общий секрет. Такой режим не подходит для недоверенной сети.

Выбор зависит от размера и зрелости контура. PSK не является универсальной заменой сертификатной инфраструктуре. Его применяют только при поддержке нужного режима.

Что сделать сейчас: оцените число узлов и частоту ротации. Если ключей становится трудно контролировать, пересмотрите модель доверия.

✅ Итоговый чек-лист внедрения

Сначала опишите потоки данных. Отдельно отметьте агент, сервер и прокси. Для каждого участка укажите направление соединения.

Затем проверьте режимы TLS. Убедитесь, что компонент действительно поддерживает PSK. Это особенно важно для сторонних отправителей метрик.

• Задан TLSConnect для исходящего соединения.
• Задан TLSAccept для входящего соединения.
• Идентификатор PSK совпадает на обеих сторонах.
• Файл TLSPSKFile существует и доступен нужному процессу.
• Ключ случайный и не используется в других зонах.
• Секрет не находится в командной строке и репозитории.
• Для PostgreSQL настроен отдельный TLS-контур.
• Правила pg_hba.conf ограничивают доступ.
• Учётная запись мониторинга имеет минимум прав.
• Журналы фиксируют ошибки TLS без раскрытия секрета.
• Есть процедура ротации и экстренного отзыва.

После включения защиты проверьте не только статус соединения. Убедитесь, что значения реально поступают. Проверьте также прокси, если он участвует в передаче.

Главный результат — не сам факт включения TLS. Важнее управляемый канал, раздельные секреты и понятная реакция на ошибку.

Что сделать сейчас: пройдите чек-лист на одном тестовом узле. После проверки перенесите подтверждённые настройки на остальные зоны.

📚 Читайте также

• Безопасный интернет-шлюз: что проверить перед запуском
• DNS Rebinding: как закрыть доступ браузера к локальным сервисам
• Обнаружение APT-групп через анализ сетевого трафика и логов: методы 2026
• Почему опасно обходить блокировки, 8 механизмов которые могут привести к взлому вашей инфраструктуры и утечке данных
• Безопасность NFC и бесконтактных платежей: реальные угрозы 2026 года

📖 Термины

PostgreSQL · TLS · Криптография · Шифрование

🔗 Источники

• SOC для мониторинга ИИ-агентов(2026-09-09 ✓)
• TLS PSK для Mamonsu: как мы добавили защищённую передачу PostgreSQL-метрик в Zabbix(2026-09-09 ✓)
• Атаки на агентные системы и защита данных(2026-09-09 ✓)