Мониторинг редко начинается с разработки собственного кода. Обычно всё гораздо прозаичнее: устанавливаешь готовый агент, подключаешь его к существующей системе мониторинга, убеждаешься, что метрики поступают, и переходишь к следующей задаче.
У нас получилось немного иначе.
При подключении нового пилотного контура PostgreSQL к Zabbix выяснилось, что Mamonsu успешно работает с базой данных и собирает метрики, но не может передать их на сервер мониторинга, если тот принимает от узла только защищённые соединения с TLS PSK.
Можно было изменить настройки Zabbix или построить обходную схему вокруг штатного zabbix_sender. Вместо этого мы решили доработать сам Mamonsu. В результате появилась поддержка TLS PSK и сертификатов с сохранением совместимости как со старыми серверными версиями Python, так и с современными версиями Python, где PSK уже поддерживается стандартным модулем ssl.
Доработку проверили на пилотном контуре, после чего отправили разработчикам Mamonsu в upstream.
О публикации. Работа, описанная в статье, выполнена мной в рамках должностных обязанностей в Федеральном государственном автономном учреждении «Национальный исследовательский центр телекоммуникаций имени М.И. Кривошеева» — ФГАУ НИЦ Телеком. Материал публикуется в личном блоге с разрешения организации. Названия внутренних узлов, адреса и иные сведения об инфраструктуре в примерах обезличены. Статья посвящена технической стороне выполненной работы и не является официальным толкованием организацией нормативных требований.
Началось всё с обычного подключения пилотного контура
В рамках развития мониторинга PostgreSQL мы подключали к существующей системе Zabbix новый пилотный контур. Для получения специализированных метрик PostgreSQL использовали Mamonsu — российский инструмент с открытым исходным кодом, развиваемый Postgres Professional.
Установка и первоначальная настройка прошли штатно. Mamonsu подключался к PostgreSQL, а его собственный агент видел доступные метрики:
mamonsu agent metric-list
Локальные проверки также подтверждали, что сбор данных работает, но в Zabbix значения не появлялись.
Сначала всё выглядело как обычная проблема интеграции: имя узла, адрес сервера, порт, права, ключ элемента данных или ошибка в конфигурации. Однако анализ журналов постепенно локализовал проблему именно на этапе передачи данных.
Mamonsu PostgreSQL видел. Метрики формировались. Но до Zabbix Server они не доходили.
Изучение реализации sender показало причину: в Mamonsu 3.5.17 соединение с Zabbix Server создавалось как обычный TCP‑сокет. Поддержки TLS PSK в этом канале не было.
В нашем случае Zabbix для подключаемого узла принимал только защищённые соединения.
Проверяем гипотезу через zabbix_sender
Прежде чем менять исходный код Mamonsu, хотелось окончательно отделить проблему самого агента от возможной ошибки в конфигурации Zabbix. Для этого мы попробовали передать одну из тех же метрик штатной утилитой zabbix_sender, явно указав используемые параметры TLS PSK:
zabbix_sender -c /etc/zabbix/zabbix_agentd.conf \ -z <FQDN_or_IP_zabbix_server> \ -p 10051 \ -s <HOSTNAME_IN_ZABBIX> \ -k 'pgsql.ping[]' \ -o 1 \ --tls-connect psk \ --tls-psk-identity '<PSK_NAME>' \ --tls-psk-file /etc/zabbix/zabbix_agentd.psk
И получили ожидаемый результат:
processed: 1; failed: 0; total: 1
Параметры ‑tls‑connect, ‑tls‑psk‑identity и ‑tls‑psk‑file штатно поддерживаются zabbix_sender [5].
Это существенно сузило область поиска. Zabbix Server доступен, узел существует, PSK корректен, значение принимается. PostgreSQL здесь вообще ни при чём.
zabbix_sender через TLS PSK работал, встроенный sender Mamonsu — нет.
После этого ограничение уже можно было искать непосредственно в исходном коде Mamonsu.
TLS PSK в Zabbix появился далеко не вчера
Поддержка шифрования соединений между компонентами появилась ещё в Zabbix 3.0. Тогда Zabbix получил TLS для server, proxy, agent и утилит командной строки, а в качестве способов аутентификации были добавлены сертификаты и предварительно общие ключи — PSK. Соответствующие параметры появились и у zabbix_sender [3].
Поэтому обнаруженная проблема не связана с какой‑то новой особенностью Zabbix 7.x. Между возможностями двух проектов просто существовал функциональный разрыв: Zabbix давно позволял запретить незашифрованные подключения, тогда как Mamonsu продолжал отправлять данные через обычный TCP.
Испытания нашей доработки проводились с Zabbix Server 7.4, однако сам созданный транспорт к этой версии не привязан.
Нижней границей с точки зрения наличия TLS PSK на стороне Zabbix можно считать Zabbix 3.0, при условии что конкретная сборка сервера имеет поддержку TLS/PSK и между клиентом и сервером имеется совместимый набор шифров TLS 1.2. Современный Zabbix поддерживает защищённые соединения по TLS 1.2 и 1.3 в зависимости от используемой криптографической библиотеки [4].
Совместимость нового TLS‑транспорта с Zabbix 3.0+ не означает автоматически, что современный Mamonsu 3.5.17 со всеми его шаблонами и метриками полностью совместим с любой старой версией Zabbix. В данной статье речь именно о канале Mamonsu → Zabbix Server.
Почему просто не разрешить обычный TCP
Самый быстрый способ заставить такую конфигурацию работать очевиден: разрешить для узла в Zabbix незашифрованные соединения.
С технической точки зрения это заняло бы несколько минут.
Но в защищаемой инфраструктуре такая постановка вопроса выглядит неправильно. Не система мониторинга должна снижать установленный уровень защиты из‑за ограничения одного агента — агент должен уметь работать в принятой модели безопасности.
У этой задачи есть и нормативный контекст. Федеральный закон от 26 июля 2017 года № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» устанавливает для субъектов, которым принадлежат значимые объекты КИИ, обязанность «соблюдать требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры» [1].
Одним из документов, конкретизирующих соответствующие требования, является приказ ФСТЭК России от 25 декабря 2017 года № 239. В составе мер по обеспечению безопасности для значимых объектов присутствует ЗИС.19:
«Защита информации при ее передаче по каналам связи».
Мера ЗИС.19 входит в базовый набор для I, II и III категорий значимости [2]. При этом важно не приписывать нормативным документам более сильное требование, чем в них содержится. Ни Федеральный закон № 187-ФЗ, ни приказ ФСТЭК № 239 не говорят, что любая телеметрия мониторинга должна передаваться именно через TLS PSK. Конкретный способ защиты определяется применительно к конкретной информационной системе, её архитектуре, модели угроз и установленным требованиям.
Но данные мониторинга тоже являются информацией, передаваемой между компонентами системы. Телеметрия может содержать сведения о состоянии сервисов, именах узлов, загрузке оборудования, состоянии баз данных и репликации, количестве соединений, ошибках, версиях компонентов и других характеристиках инфраструктуры. Поэтому сам по себе аргумент «это всего лишь метрики мониторинга» не делает канал автоматически не требующим защиты.
В нашем случае практическая сторона вопроса была ещё проще: для подключаемого узла уже требовался защищённый канал. Следовательно, адаптировать нужно было Mamonsu.
Отдельно отмечу, что наличие TLS и использование OpenSSL сами по себе не означают автоматического выполнения всех возможных требований к применению средств криптографической защиты информации. Если для конкретной системы установлено требование применять определённые или сертифицированные СКЗИ, это отдельный вопрос. Здесь речь идёт именно о реализации TLS‑транспорта, поддерживаемого Zabbix.
Почему не оставить zabbix_sender
После успешной ручной проверки был очевиден и другой вариант: не изменять Mamonsu, а использовать zabbix_sender как внешний транспорт.
Такую схему можно реализовать. Mamonsu собирает данные, промежуточный механизм передаёт их внешней утилите, а та уже устанавливает TLS PSK‑соединение с Zabbix Server. Но это означало бы появление ещё одного слоя со своей конфигурацией, обработкой ошибок и жизненным циклом. При этом внутри Mamonsu уже существовали очередь метрик, формирование пакета Zabbix Sender Protocol, повторная отправка и обработка ответа сервера.
Фактически не хватало только одного элемента — защищённого транспорта.
Поскольку Mamonsu имеет открытый исходный код, мы решили попробовать устранить ограничение непосредственно в проекте, а не строить постоянный обходной механизм вокруг него.
Протокол оставляем прежним, меняем транспорт
Один из принципов доработки заключался в том, чтобы минимально вмешиваться в существующую логику Mamonsu.
Сам протокол отправки уже работал. Менять очередь метрик, JSON, повторную отправку и обработку ответа Zabbix не требовалось.
Поэтому выбор транспорта был вынесен в отдельный этап. В сокращённом виде реальный код из доработки выглядит так:
def _connect(self): if self.tls_connect == TLS_PSK: return tls.connect_psk( self.host, self.port, self.tls_psk_identity, self._psk, int(self.timeout), self.tls_cipher_psk) if self.tls_connect == TLS_CERT: return tls.connect_cert( self.host, self.port, self.tls_ca_file, self.tls_cert_file, self.tls_key_file, int(self.timeout), crl_file=self.tls_crl_file, ciphers=self.tls_cipher_cert, server_cert_issuer=self.tls_server_cert_issuer, server_cert_subject=self.tls_server_cert_subject) ... return sock
Существующая senddata() по‑прежнему формирует тот же пакет Zabbix Sender Protocol и работает с объектом, предоставляющим привычные sendall(), recv() и close(). Меняется не протокол, а объект соединения.
В конфигурации появились три режима: unencrypted, psk и cert.
Для PSK достаточно указать:
[zabbix] tls_connect = psk tls_psk_identity = PSK monitor-01 tls_psk_file = /etc/zabbix/zabbix_agentd.psk
Сертификатный вариант использует тот же транспортный слой:
[zabbix] tls_connect = cert tls_ca_file = /etc/zabbix/ca.crt tls_cert_file = /etc/zabbix/mamonsu.crt tls_key_file = /etc/zabbix/mamonsu.key
А значением по умолчанию осталось:
tls_connect = unencrypted
Это сделано намеренно ради обратной совместимости. Если пользователь не добавляет новые параметры, существующий agent.conf продолжает работать так же, как в Mamonsu 3.5.17.
Не только agent.conf: добавили и параметры командной строки
У Mamonsu уже существуют сценарии, где параметры задаются или переопределяются при запуске. Поэтому ограничить TLS только конфигурационным файлом означало бы нарушить существующую модель управления программой.
Для новых настроек добавили соответствующие CLI‑параметры: ‑zabbix‑tls‑connect, ‑zabbix‑tls‑psk‑identity, ‑zabbix‑tls‑psk‑file, а также параметры CA, CRL, сертификата, ключа, issuer и subject.
Например, PSK можно задать при запуске без изменения основного конфигурационного файла:
mamonsu -c /etc/mamonsu/agent.conf \ --zabbix-tls-connect psk \ --zabbix-tls-psk-identity '<PSK_NAME>' \ --zabbix-tls-psk-file /etc/zabbix/zabbix_agentd.psk
При этом явно переданные параметры переопределяют значения из конфигурации, а остальные настройки сохраняются. В реальном коде это реализовано следующим образом:
def apply_zabbix_tls_args(cfg, args): options = ( ('tls_connect', args.zabbix_tls_connect), ('tls_psk_identity', args.zabbix_tls_psk_identity), ('tls_psk_file', args.zabbix_tls_psk_file), ('tls_ca_file', args.zabbix_tls_ca_file), ('tls_crl_file', args.zabbix_tls_crl_file), ('tls_cert_file', args.zabbix_tls_cert_file), ('tls_key_file', args.zabbix_tls_key_file), ('tls_server_cert_issuer', args.zabbix_tls_server_cert_issuer), ('tls_server_cert_subject', args.zabbix_tls_server_cert_subject)) for key, value in options: if value is not None: cfg.config.set('zabbix', key, value)
Та же логика используется не только при обычном запуске агента, но и для mamonsu upload. Таким образом, поддержка TLS появилась не как отдельный специальный режим, а была встроена в уже существующие способы работы Mamonsu.
Python уже умеет PSK. Но только начиная с 3.13
На этом месте возникает закономерный вопрос: зачем вообще понадобилось обращаться напрямую к OpenSSL, если Python имеет стандартный модуль ssl?
В современном Python действительно существует SSLContext.set_psk_client_callback(). Это штатный API для создания клиентских TLS PSK‑соединений. Но появился он только в Python 3.13 [6].
Если бы Mamonsu запускался исключительно на свежих версиях Python, проблема на этом была бы практически решена. Инфраструктурный агент, однако, живёт не на ноутбуке разработчика. Он устанавливается на серверную операционную систему, жизненный цикл которой может составлять многие годы.
Если реализовать TLS PSK только через API Python 3.13, новая возможность окажется недоступна на значительной части реально используемых серверов.
Для примера:
Дистрибутив | Базовая ветка Python | Транспорт PSK в нашей реализации |
|---|---|---|
Astra Linux 1.7 | 3.7 | ctypes → OpenSSL |
РЕД ОС 7.3 | 3.8 | ctypes → OpenSSL |
Ubuntu 20.04 LTS | 3.8 | ctypes → OpenSSL |
Альт Сервер 10.4 | 3.9 | ctypes → OpenSSL |
RHEL 9 | 3.9 | ctypes → OpenSSL |
Ubuntu 22.04 LTS | 3.10 | ctypes → OpenSSL |
Astra Linux 1.8 | 3.11 | ctypes → OpenSSL |
РЕД ОС 8 | 3.11 | ctypes → OpenSSL |
Debian 12 | 3.11 | ctypes → OpenSSL |
Альт Сервер 11 | 3.12 | ctypes → OpenSSL |
Ubuntu 24.04 LTS | 3.12 | ctypes → OpenSSL |
RHEL 10 | 3.12 | ctypes → OpenSSL |
Debian 13 | 3.13 | стандартный ssl |
Для Astra Linux 1.8 документация производителя указывает Python 3.11.2 [7]. РЕД ОС 7.3 использует ветку 3.8.2, а в РЕД ОС 8 по умолчанию установлен Python 3.11 [8, 9]. Альт Сервер 10.4 содержит Python 3.9.20, а одиннадцатая платформа перешла на Python 3.12 [10, 11].
Картина за пределами российских дистрибутивов такая же. Ubuntu 20.04 использует Python 3.8, Ubuntu 22.04 — 3.10, Ubuntu 24.04 — 3.12 [12–14]. В RHEL 9 системной реализацией остаётся Python 3.9, а в RHEL 10 — Python 3.12 [15, 16]. Debian 12 поставлял Python 3.11, и только Debian 13 перешёл на 3.13 [17].
Поэтому предложение «просто установите Python 3.13» для серверного агента выглядит сомнительно. Особенно если речь идёт о стабильной или сертифицированной серверной ОС, где замена системного Python ради одной функции агента мониторинга может создать гораздо больше проблем, чем решить.
ctypes как слой совместимости, а не собственный TLS
Мы решили поддержать оба варианта.
На Python, где стандартная библиотека уже предоставляет PSK API, используется обычный ssl. Проверка в реальном коде выглядит буквально так:
def stdlib_psk_supported(): return hasattr(ssl.SSLContext, 'set_psk_client_callback')
А выбор реализации PSK — так:
def connect_psk(host, port, identity, psk, timeout, ciphers=None): ... sock = socket.create_connection((host, port), timeout=timeout) try: if stdlib_psk_supported(): return _wrap_stdlib(sock, identity, psk, ciphers) return OpenSSLSocket(sock, identity, psk, timeout, ciphers) except Exception: sock.close() raise
То есть код не привязывается жёстко к номеру версии Python. Он проверяет наличие необходимой возможности в самом ssl. Если она доступна — используется стандартная библиотека. Если её нет, на Linux задействуется системная OpenSSL через стандартный модуль Python ctypes.
Мы не реализовываем TLS самостоятельно. Криптографические алгоритмы, TLS handshake, наборы шифров и работа с PSK остаются внутри OpenSSL. ctypes используется лишь для обращения к публичному API системной libssl.
На старой системе цепочка получается: Mamonsu → Python → ctypes → системная OpenSSL → TLS PSK. На новой: Mamonsu → Python ssl → TLS PSK.
Это позволяет рассматривать ctypes не как альтернативную криптографическую реализацию, а именно как слой совместимости. По мере перехода серверных дистрибутивов на Python 3.13 и новее этот код будет использоваться всё реже, а конфигурацию Mamonsu при этом менять не потребуется.
Почему PSK пока ограничен TLS 1.2
При использовании низкоуровневого OpenSSL API PSK‑соединение в нашей реализации ограничено TLS 1.2.
Это связано с различиями API OpenSSL. Классический PSK callback TLS 1.2 и механизм PSK в TLS 1.3 работают по‑разному. Для TLS 1.3 потребовалась бы отдельная реализация через механизм psk_use_session.
Для исходной задачи это не было необходимо. Zabbix поддерживает TLS 1.2, а его конфигурация отдельно предусматривает наборы шифров PSK для TLS 1.2 и TLS 1.3 [4]. Поэтому первую реализацию решили не усложнять и явно зафиксировали TLS 1.3 PSK как известное ограничение. Архитектурно это не мешает добавить его позднее.
Ошибка TLS не должна незаметно отключать TLS
Отдельное внимание пришлось уделить поведению при ошибках конфигурации.
Предположим, администратор указал:
tls_connect = psk
но ошибся в PSK identity, указал недоступный файл или сам файл содержит некорректное значение.
С эксплуатационной точки зрения можно было бы попробовать обычный TCP: не получилось зашифрованно — зато метрики продолжают поступать. С точки зрения безопасности это означало бы скрытый даунгрейд.
Если администратор явно выбрал psk или cert, невозможность установить защищённое соединение считается ошибкой. Автоматического перехода на незашифрованный транспорт нет.
Это правило действует и для обычного агента, и для mamonsu upload.
PSK не хранится в agent.conf
Сам предварительно общий ключ в конфигурационный файл Mamonsu не записывается. В нём хранится только путь:
tls_psk_file = /etc/zabbix/zabbix_agentd.psk
Ключ считывается при запуске процесса. При этом проверяется его формат, а содержимое PSK не должно попадать ни в журнал, ни в текст исключения. Файл, разумеется, должен быть защищён правами файловой системы и доступен пользователю, от имени которого работает Mamonsu. Пока PSK читается один раз при старте, поэтому после ротации ключа агент необходимо перезапустить.
TLS нужно проверять настоящим TLS
Для подобной доработки тестов только с mock‑объектами недостаточно. Можно идеально проверить вызов connect_psk() и при этом получить код, который ни разу не выполнял настоящий TLS handshake. Поэтому часть тестов поднимает реальный openssl s_server и устанавливает соединение с ним.
Проверяются успешный PSK handshake и передача данных, отказ при неправильном ключе, сертификатный режим, неизвестный центр сертификации и несовпадение параметров сертификата. Отдельные тесты проверяют чтение PSK‑файла и отсутствие секрета в диагностических сообщениях.
Проверяется не только то, что новый TLS‑транспорт работает, но и то, что старый незашифрованный транспорт не был сломан.
На момент оформления pull request набор тестов давал 35 passed, 2 skipped. Сохранение прежнего wire format, отсутствие автоматического отката к plaintext и отсутствие новых runtime‑зависимостей также зафиксированы в описании PR [20].
Проверяем на пилотном контуре
Лабораторные тесты необходимы, но главный вопрос оставался прежним: заработает ли реализация именно в той среде, ради которой она создавалась.
Проверку PSK провели на пилотном контуре с Astra Linux Special Edition 1.7.6, Python 3.7, OpenSSL 1.1.1 и Zabbix Server 7.4.
Это был особенно важный тест, поскольку использовался именно путь совместимости через ctypes, а не PSK API нового Python:
Python 3.7 → ctypes → libssl.so.1.1 → TLS 1.2 PSK → Zabbix Server 7.4.
После настройки нового транспорта Mamonsu начал штатно передавать метрики в Zabbix без необходимости разрешать для узла No encryption. Тем самым исходная задача пилотного контура была решена. Эта проверка также зафиксирована в описании upstream PR [20].
От локальной доработки к upstream
На этом технически можно было остановиться. Исправленный DEB‑пакет можно было разместить во внутреннем репозитории и использовать в собственной инфраструктуре.
Но такой подход означал бы необходимость самостоятельно переносить изменения на последующие версии Mamonsu и контролировать их совместимость.
При этом проблема явно не специфична для одного пилотного контура. С ней потенциально столкнётся любой пользователь Mamonsu, если его Zabbix Server запрещает незашифрованные соединения от узлов.
Поэтому изменение оформили как полноценную доработку проекта: добавили конфигурацию PSK и сертификатов, поддержку командной строки, документацию, тесты нового транспорта и regression‑тесты старого режима.
После проверки изменения были предложены разработчикам Postgres Professional: Pull request #235 — Encrypt the agent to Zabbix channel with TLS (PSK or certificate). На момент подготовки этой редакции статьи pull request остаётся открытым и ещё не слит в основную ветку [20].
В результате путь от эксплуатационной проблемы до upstream получился довольно прямым: пилотный контур → диагностика → проверка через zabbix_sender → анализ Mamonsu → реализация TLS → тестирование → проверка на Astra Linux → pull request.
На мой взгляд, это один из наиболее полезных сценариев использования открытого программного обеспечения в инфраструктуре. Не всегда необходимо ждать исправления от разработчиков или годами поддерживать внешний обходной механизм. Иногда проблему можно устранить в самом проекте и затем предложить решение всем его пользователям.
Пока pull request рассматривается
До принятия изменений исходный код реализации доступен в моём форке Mamonsu — ветка zbx‑tls‑psk
При необходимости репозиторий можно клонировать и собрать DEB‑пакет стандартными средствами самого проекта. Для своей сборки я использовал номер версии 3.5.17.1.
Это позволяет пакетному менеджеру отличать её от исходной версии 3.5.17 и воспринимать как более новую версию при использовании локального репозитория или средств автоматизации. При этом 3.5.17.1 не претендует на номер будущего официального выпуска Mamonsu — версионирование upstream определяют разработчики проекта.
Надеемся, что после рассмотрения pull request поддержка защищённого транспорта войдёт в один из следующих официальных выпусков Mamonsu. В таком случае необходимость поддерживать отдельную сборку отпадёт.
Что осталось
Текущая реализация решает исходную задачу, но у неё есть известные ограничения.
PSK через совместимый с прежними Python транспорт пока использует TLS 1.2, без реализации отдельного PSK API TLS 1.3. После ротации ключа требуется перезапуск Mamonsu. На Windows для PSK необходим Python с поддержкой стандартного PSK API, поскольку использовать системную libssl тем же способом, что на Linux, нельзя.
Сертификатный режим появился в рамках общей транспортной архитектуры, хотя первоначальная производственная задача была связана именно с PSK. Он протестирован с openssl s_server, тогда как на пилотном контуре проверялся PSK.
Наконец, реализация ещё может измениться по результатам upstream review — это нормальная часть работы с открытым проектом.
Главная задача при этом уже решена: Mamonsu может передавать PostgreSQL‑метрики в Zabbix через TLS PSK без необходимости отключать защищённый режим на сервере и без требования обновлять старую серверную ОС до Python 3.13 только ради агента мониторинга.
Вместо заключения
Эта история началась с достаточно банального симптома: на новом пилотном контуре Mamonsu видит PostgreSQL и собирает метрики, но Zabbix их не получает.
Одна команда zabbix_sender позволила отделить проблему системы мониторинга от проблемы самого Mamonsu. Анализ исходного кода показал отсутствующий транспортный слой, а открытая модель разработки позволила не ограничиваться локальным обходным решением.
Наиболее интересной частью в итоге оказалась даже не поддержка TLS как таковая. Python уже получил штатный PSK API. Но инфраструктурное программное обеспечение живёт в другом временном масштабе. Python 3.7, 3.8, 3.9, 3.10, 3.11 и 3.12 продолжают использоваться в серверных операционных системах. Требование заменить системный Python ради одной функции агента мониторинга плохо сочетается с консервативным жизненным циклом таких систем. Поэтому поддержка современного API и поддержка старых систем вовсе не обязаны противоречить друг другу.
В нашем случае на новых системах используется стандартный ssl, а там, где PSK API в Python ещё нет, — тот же системный OpenSSL через небольшой слой совместимости. По мере обновления серверных ОС этот слой будет использоваться всё реже без каких‑либо изменений конфигурации Mamonsu.
А небольшая задача по подключению мониторинга пилотного PostgreSQL‑контура в итоге превратилась в ещё один вклад в открытый российский проект.
Источники и материалы
Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», статья 9. Ссылка
Приказ ФСТЭК России от 25.12.2017 № 239. Приложение: мера ЗИС.19 «Защита информации при ее передаче по каналам связи». Ссылка
Zabbix 3.0 Documentation — What’s new in Zabbix 3.0.0: Encryption support. Ссылка
Zabbix Documentation — Encryption. Ссылка
Zabbix Documentation — zabbix_sender. Ссылка
Python Documentation — ssl: SSLContext.set_psk_client_callback(). Ссылка
Astra Linux — документация по Python для Astra Linux 1.8. Ссылка
РЕД ОС 7.3 — материалы по пакетам Python 3.8.2. Ссылка
РЕД ОС 8 — список изменений и доступные версии Python. Ссылка
Базальт СПО — Альт Сервер 10.4, Python 3.9.20. Ссылка
Альт Сервер 11 — переход на Python 3.12. Ссылка
Ubuntu 20.04 LTS — Python 3.8. Ссылка
Ubuntu 22.04 LTS Release Notes — Python 3.10.4. Ссылка
Ubuntu 24.04 LTS Release Notes — Python 3.12. Ссылка
RHEL 9 Documentation — Python 3.9 as the default implementation. Ссылка
RHEL 10 Documentation — Python 3.12 as the default implementation. Ссылка
Debian 13 Release Notes — Python 3.11 in Debian 12 and Python 3.13 in Debian 13. Ссылка
Mamonsu — основной репозиторий Postgres Professional. Ссылка
Mamonsu — форк с реализацией TLS, ветка zbx‑tls‑psk. Ссылка
Pull request #235 — Encrypt the agent to Zabbix channel with TLS (PSK or certificate). Ссылка
