Используйте что-то еще, кроме JDBC через межсетевой экран

Question

У меня есть простое сервер-клиентское приложение, которое использует JDBC для подключения к базе данных, и все работает нормально. Приложение делает несколько простых вещей с подключением JDBC (получить данные, вставить новую строку и несколько других).

Теперь я хотел бы сохранить то же приложение, но использовать его вне брандмауэра - поэтому я бы поместил что-то другое на некоторый хост: порт (и открыл этот порт для внешнего мира) - вместо того, чтобы JDBC открывал доступ к базе данных напрямую.

Я предполагаю, что с этой проблемой сталкивались много-много раз и уверен, что есть много подходов.
Одним из способов может быть создание сервлета на одной стороне, доступ к нему на стороне клиента.
Я думаю, я еще не прикасался к Spring, может быть, другим было бы сделать Java-класс POJO и использовать Spring для настройки его в качестве http-сервиса. Я также слышал "слухи", что у Jetty есть кое-что, что может помочь в этом случае (чтобы минимизировать кодирование на стороне сервера и клиента)

Я бы предпочел что-то такое:
- не сложно (легкий путь обучения)
- повторно использовать то, что уже сделано.

Какой подход вы бы порекомендовали?

Спасибо и всего наилучшего,
Игорь

Answer 1

Нормальным подходом было бы внедрение веб-сервиса, который может быть довольно простым в наши дни с Axis и т. Д.

Вы действительно не хотите открывать прямой JDBC для клиентов вне брандмауэра путем туннелирования по HTTP ... сервер должен строго контролировать, какое взаимодействие происходит с базой данных.

Answer 2

Я думаю, это было бы ненужным осложнением. Ваша СУБД (обычно) обеспечивает контроль доступа и безопасность транспортного уровня. Если вы вводите свой собственный слой, вы уверены, что можете сделать его более безопасным, чем прямое соединение с БД?

Я вижу ваше обоснование, но если для этого нет основы, не создавайте свою собственную! Например, PostgreSQL поставляется с множеством изящных опций, чтобы связать вещи. Например, требует аутентификации на основе сертификатов SSL на транспортном уровне (клиенты должны предоставить сертификат, который проверяет сервер) или доступа на основе IP.

Конечно, вы все еще должны доверять своей реализации СУБД, чтобы получить базовые детали, такие как право контроля доступа (= "не взломать"), но вам все равно нужно полагаться на это в любом случае после того, как черные шляпы проникли в ваш веб-прокси;)

@ dtsazza: Возможно, отредактируйте свой ответ, включив в него ключевое слово "VPN"? Туннели ssh, вероятно, плохо масштабируются вне частной установки.

Volker

Answer 3

Я бы порекомендовал использовать что-то вроде туннелей SSH для переноса ваших соединений JDBC через брандмауэр. Настройте туннель на машине DMZ на любой публично открытый порт, который вы можете, и подключите другой конец туннеля к соответствующему порту на сервере БД.

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

Если это проблема ИТ-политики, поскольку они не позволят вам получить прямой доступ к базе данных, вам нужно будет решить, что вам разрешено делать , и работать с этим настолько, насколько это возможно. возможный. В этом случае переход к JDBC на другой метод доступа вряд ли будет приемлемым для ИТ-политики.

Редактировать : после прочтения ответа Джона он может быть прав. Я предполагал, что проблема была в связи между вашим сервером / веб-приложением и сервером базы данных. Если вы говорили о клиенте, создающем прямые JDBC-соединения с базой данных, то да - брандмауэр или нет, это очень плохая практика. Клиент должен обратиться к вашему серверу, чтобы узнать, чего он хочет, а ваш сервер должен выполнить запросы к БД, необходимые для получения информации.