Шифрування з'єднання у Firebird 3 і VPN — дві різні межі

VPN підключається, клієнт відкриває сеанс, і всі припускають, що з'єднання з базою даних захищене. Щойно змішали три різні речі. Чи слухач взагалі доступний, чи сервер прийняв користувача і чи Firebird домовився про шифрування з'єднання — це окремі механізми з окремими доказами. Тунель відповідає лише на перше, і лише для тих джерел, які ви дозволили.

Дві межі, і вони не перетинаються

Межа VPN захищає пакети між клієнтом і шлюзом. Шифрування з'єднання у Firebird захищає протокол бази даних між клієнтською бібліотекою і процесом сервера. Обидва можуть існувати, і жодне не замінює інше.

Якщо тунель закінчується раніше за хост бази даних, трафік за ним захищений лише тим, про що домовився сеанс бази даних. Саме в цій прогалині огляд зазвичай і знаходить сюрприз. Схема тунелю закінчується на шлюзі, а з'єднання, що несе ваш запит, продовжується далі. Кожен, хто пізніше прочитає цю схему, успадковує це припущення.

Межа перша: хто може відкрити слухач

Визначте справжню адресу сервера і налаштований порт, який дорівнює 3050, якщо його не змінювали, потім дозвольте лише схвалені джерела VPN у брандмауері хоста і мережі. Врахуйте будь-яке перетворення адрес на шлюзі VPN і дайте хосту бази даних зворотний маршрут до пулу клієнтів, якщо шлюз окремий.

Потім доведіть заперечення. Зовнішній шлях, який має бути відхилений, повинен залишитися відхиленим, бо відкриття тунелю саме по собі не обмежує слухач Firebird.

Межа друга: про що домовляється Firebird

Firebird 3 запровадив рамки шифрування з'єднання із серверною політикою, яку можна вимкнути, увімкнути або зробити обов'язковою. Політика задає нижню межу. Фактичний сеанс усе ще залежить від клієнтської бібліотеки, яку завантажує програма, і від плагінів, які підтримують обидві сторони.

У примітках до випуску Firebird 3 Arc4 указано як типовий плагін шифрування з'єднання для цього випуску. Arc4 — історичне значення за замовчуванням, а не рекомендація сучасного шифру, і це не те саме, що зовнішній захист VPN.

Автентифікація — третя змінна в тих самих переговорах. Сервер приймає набір плагінів автентифікації, клієнтська бібліотека пропонує деяку підмножину, і вони мають перетинатися.

Пастка Legacy_Auth

Підтримка Legacy_Auth вимагає послаблення типової політики обов'язкового шифрування на сервері. Це документована ціна сумісності, і тому зниження політики, щоб заглушити помилку з'єднання, є зміною безпеки, а не виправленням.

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

Перевірте з'єднання, яке має значення

У збірці, яка надає контекстну змінну, цей запит повідомляє стан шифрування поточного з'єднання:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

Запишіть разом версію клієнтської бібліотеки, збірку сервера і результат, бо жодне з них окремо не читається.

Права і шлях оновлення

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

Нарешті, ставтеся до довготривалого розгортання як до питання обслуговування. Тунель не робить застарілу клієнтську бібліотеку безпечною назавжди, і підтримуваний шлях оновлення дешевший, ніж виявити, що потрібний їй плагін видалено.