Настройка PostgreSQL SSL/TLS для шифрования подключений

Почему трафик к PostgreSQL уходит в открытом виде

По умолчанию сервер поднимается с выключенным шифрованием: в pg_hba.conf для большинства сетей стоит правило host, которое одинаково допускает и открытый, и защищённый канал. Клиент со sslmode=prefer молча согласится на незашифрованный вариант, если рукопожатие почему-то не сложилось — и никто не узнает, что данные пошли открытым текстом.

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

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

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

Настройка SSL/TLS для PostgreSQL: что это закрывает

До включения шифрования обмен между клиентами и PostgreSQL идёт открытым текстом: учётные данные в момент аутентификации и сами данные видны любому, кто получает доступ к трафику — зеркалированию порта, промежуточному прокси или записи дампа. SSL/TLS превращает канал в зашифрованный поток, и этот класс отказов уходит целиком, а не ослабляется частично.

Режим задаётся с двух сторон. В pg_hba.conf строка host меняется на hostssl — незашифрованные подключения перестают приниматься административно, и «забытая» конфигурация по умолчанию не оставляет открытую дверь. На клиенте sslmode=require гарантирует только шифрование, тогда как verify-ca и verify-full дополнительно проверяют цепочку сертификатов и совпадение имени хоста — именно они закрывают подмену сервера посредником.

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

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

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

Режимы защиты подключений: от проверки сертификата до туннеля

В PostgreSQL шифрование канала включается параметрами ssl в postgresql.conf, но режим выбирает клиент — через sslmode в строке подключения и правила pg_hba.conf. Разница между режимами не в стойкости шифра, а в том, проверяется ли сертификат сервера, требуется ли сертификат клиента и где завершается шифрованный участок.

Комбинацию выбирают по границам доверия, а не по принципу «чем строже, тем лучше»: взаимная аутентификация внутри контура добавляет только ротацию сертификатов, а require на публичном адресе оставляет подмену сервера возможной. Ограничения режимов стоит зафиксировать письменно — иначе при разборе инцидента выясняется, что проверялся лишь факт шифрования.

Порядок внедрения: от аудита схемы до передачи регламентов

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

1. Аудит схемы подключений. Собираем карту потребителей: какие сервисы ходят в базу, с каких адресов, какие драйверы поддерживают шифрование и где строка подключения зашита в образ или в сборочный конвейер. Без этой карты любая настройка делается вслепую и отключает часть клиентов.
2. Проектирование схемы доверия. Определяем строгость: только шифрование канала или взаимная проверка клиентских сертификатов, кто подписывает, какой срок жизни, как отзывается сертификат. Решение фиксируем письменно — от него зависят остальные шаги.
3. Выпуск сертификатов. Генерируем на защищённом узле, приватные ключи не покидают сервер, выставляем права на файлы и готовим цепочку доверия для проверки.
4. Настройка сервера. Включаем шифрование, задаём, какие подключения допустимы, и перечитываем конфигурацию без остановки обслуживания. Первый прогон — в мягком режиме: сначала предупреждения в журнале, затем запрет незашифрованных сессий.
5. Проверка шифрования. Подключаемся принудительно с шифрованием и без него, разбираем журналы, убеждаемся, что политика применяется, а не просто объявлена. Отдельно проверяем поведение при истёкшем и подменённом сертификате.
6. Передача регламентов. Отдаём инструкции по ротации, точки контроля, порядок восстановления доступа при потере ключа и сценарий отката.

Пакет передачи: конфигурации, доверенные цепочки, регламенты ротации

На выходе заказчик получает не набор разрозненных команд, а воспроизводимый комплект для PostgreSQL: конфигурации, схему доверия сертификатов и регламенты, по которым контур живёт дальше. Каждый пункт принимается по факту — применённая настройка, проверенное соединение, проигранный на стенде откат.

• Конфигурации сервера: включённый SSL, пути к сертификату, ключу и цепочке, минимально допустимая версия протокола — управляемыми шаблонами, а не правками на живой базе.
• Правила доступа: pg_hba.conf, где прикладные хосты допускаются только через hostssl, а незашифрованные подключения снаружи запрещены явно.
• Доверенные цепочки: корневой и промежуточные сертификаты, порядок их выкладки и проверка соответствия ключа сертификату.
• Ротация ключей: расписание перевыпуска, порядок смены без разрыва активных соединений и способ отзыва через список отзыва.
• Регламент отката: где хранится предыдущая пара, какие шаги возвращают контур в работу и за какое время это проверяется на стенде.
• Документация по подключениям: строки подключения, требования к клиентам, готовый чек-лист для новых сервисов и подрядчиков.
• Контроль срока действия: алерты по датам сертификатов и ошибкам рукопожатия — предупреждение до истечения, а не после.
• Матрица ответственности: кто выпускает, кто подтверждает, кто отзывает.

Кейс: закрыли открытый трафик между сервисами и репликами

Что было

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

Как шли без простоя

Сначала подняли внутренний центр сертификатов и выпустили отдельный сертификат на каждый сервис и каждую реплику. Сервер перевели в режим, где защищённые и обычные подключения принимаются одновременно, — это дало окно для постепенного перевода. Дальше меняли клиентов по одному: строка подключения с обязательной проверкой сертификата (sslmode=verify-full), перезапуск по одному экземпляру, проверка чтения с реплики. Репликацию перевели на потоковый режим с проверкой сертификата, базовая копия снималась уже по защищённому каналу, а обычные подключения отключили в конце — отдельным изменением.

Что изменилось

• доля подключений по защищённому каналу: 0 → 100%, включая репликацию;
• простой при переводе: ноль, откат на любой шаг занимал минуты;
• задержка отклика на p99 не выросла заметно;
• ротация сертификатов вместо ручных правок на сорока сервисах — автоматическая.

Чем отличается терминация на балансировщике от сквозного шифрования?

Терминация на балансировщике означает, что защищённый участок заканчивается на входном узле: клиент ставит TLS-сессию с балансировщиком, тот расшифровывает поток и передаёт его к серверу базы уже в открытом виде. Снаружи трафик нечитаем, внутри сети — обычный текстовый протокол, доступный любому на том же сегменте.

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

Сквозное шифрование переносит границу защиты до самого экземпляра PostgreSQL: TLS-сессия идёт между клиентом и сервером, а промежуточный узел видит только адреса, порты и объём переданного. Требования к настройке ssl postgresql жёстче: сертификат и ключ нужны каждому серверу, клиенты переходят на проверку цепочки и имени хоста — иначе соединение шифруется, но подмена узла остаётся возможной.

Цена — потеря осведомлённости о содержимом: маршрутизация по типу запроса и разделение чтения и записи на уровне прокси перестают работать, проверка состояния сервера уходит на служебное соединение.

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

Технические сомнения: совместимость, сертификаты, откат

Сомнения при внедрении шифрования обычно одни и те же: не отвалится ли старый клиент, что произойдёт при перевыпуске сертификата на живой системе, как убедиться, что шифрование действительно работает, и как вернуться назад, если что-то пойдёт не так. Ниже — ответы, которые мы даём до начала работ, чтобы картина была полной.

Как перевыпустить сертификаты без остановки сервиса?

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

Можно ли вернуть всё назад?

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

Как проверить, что шифрование действительно работает?

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

Обсудим задачу: снимем текущую схему и вернёмся с планом

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

• Вывод SHOW ssl; и параметры ssl_cert_file, ssl_key_file, ssl_ca_file из postgresql.conf (или пометку, что они не заданы) — это ядро оценки.
• Список клиентов, которые ходят в базу: приложение, сервисы аналитики, репликация, админские консоли — с пометкой, какие из них умеют TLS и какие нет.
• Как выпускаются и где лежат сертификаты: внутренний центр сертификации, внешний или самоподписанные; кто и как часто их ротирует.
• Правила доступа в pg_hba.conf по строкам — хотя бы фрагмент, где видно методы аутентификации, чтобы понять, что придётся менять при переходе на шифрование.
• Схема сети: где балансировщики, где прокси подключений, есть ли промежуточные узлы, которые тоже должны пропускать зашифрованный трафик.
• Текущий режим отказоустойчивости: реплики, резервное копирование, окна обслуживания — от них зависят сроки внедрения.

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

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