Налаштування 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 по рядках — хоча б фрагмент, де видно методи аутентифікації, щоб зрозуміти, що доведеться міняти при переході на шифрування.
• Схема мережі: де балансувальники, де проксі підключень, чи є проміжні вузли, які теж повинні пропускати зашифрований трафік.
• Поточний режим відмовостійкості: репліки, резервне копіювання, вікна обслуговування — від них залежать терміни впровадження.

За цими даними ми знімемо фактичну картину підключень, зафіксуємо, які вузли доведеться оновити і в якому порядку, щоб не погасити працюючі сервіси.

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