Шифрование соединения в 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;

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

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

Права и путь обновления

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

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