#sql #postgresql #delphi #https
#sql #postgresql #delphi #https
Вопрос:
Я написал несколько приложений на Delphi для производственной компании, целью этого приложения является печать этикеток и сбор производственных данных.Все эти приложения являются клиент-серверными (с использованием ZeosLib, подключающимися непосредственно к PostgreSQL через порт 5432).
В последние дни компания приобрела другие производственные сайты и хочет установить мое программное обеспечение на этих сайтах. Невозможно установить соединение LAN2LAN, и единственный способ связи с внешних производственных площадок в штаб-квартиру корпорации — через HTTP (https) сервер через интернет-соединение.
Когда я столкнулся с проблемой, первое, о чем я подумал, это преобразовать приложения для использования REST и написать все запросы на стороне сервера, вызывающие нужные конечные точки. Однако для этого требуется много работы: приложениям нужно переписать много запросов.
Поэтому по соображениям времени я попытался создать PHP-скрипт на стороне сервера, способный получать запросы, написанные на SQL, подключаться к PostgreSQL и отвечать в данных JSON. После этого я модифицировал свое приложение, расширив соединения ZeosLib дополнительным протоколом (с именем websql), способным перенаправлять SQL-запросы в PHP-скрипт и преобразовывать полученные данные JSON в формат, совместимый с Delphi DataSet.
Все работает нормально: во всех моих приложениях теперь я могу изменить протокол подключения с помощью нового «websql», и я мог бы быстро установить новые версии в филиалах. офисы.
Выполнение этого теста было очень простым, но теперь возникла проблема безопасности: веб-соединение защищено пользователем / паролем и https, но достаточно ли этого? Должно ли клиентскому приложению быть разрешено отправлять запросы через https? Перед установкой приложений в производство я хотел бы знать, есть ли способ сделать эту архитектуру максимально безопасной или целесообразно переписать все приложения с помощью REST communication.
Спасибо всем,
Андреа
Комментарии:
1. Если вы хотите большей безопасности, сервер может проверить IP-адрес клиента (через белый список). Или, как предложил fpiette, вы могли бы использовать клиентские сертификаты, но для настройки требуется больше работы.
2. Еще одна вещь, которую следует учитывать: ваше приложение будет зависеть от подключения к Интернету. Если соединение недоступно в течение некоторого времени, не является ли это проблемой для вашего «сбора производственных данных»? Почему бы не использовать локальную базу данных PostgreSQL?
3. Привет, Оливер, основные системные данные часто меняются и должны обновляться каждый раз, когда создается новая метка. created…so мне нужно получить и отправить информацию в основную базу данных PostgreSQL
Ответ №1:
Предоставление шлюза JSON для запуска SQL со стороны клиента не является надлежащим REST и не должно использоваться для какой-либо серьезной работы.
Несколько причин:
- Любой пользователь на стороне клиента с учетными данными может запускать любые операторы SQL, что может быть довольно небезопасно, например, УДАЛЕНИЕ ТАБЛИЦЫ или УДАЛЕНИЕ базы ДАННЫХ в середине инструкции SELECT . Или он может получить доступ к данным от других клиентов.
- У вас все еще есть логика на стороне клиента. Это не n-уровневый, это замаскированный 2-уровневый. Тот факт, что вы используете HTTPS JSON вместо прямого подключения к БД, не меняет глобальную архитектуру.
- HTTPS безопасен, только если обе стороны (клиент и сервер) принудительно используют свои сертификаты для взаимной аутентификации. В противном случае MiM-атаки очень распространены. Может помочь использование VPN или SSH-туннеля.
- Производительность может быть не очень хорошей, поскольку вы не кэшируете данные, а задержка в сети в Интернете хуже, чем в локальной сети.
- Если вы действительно хотите пойти в этом направлении, не изобретайте велосипед и используйте более отлаженное решение, такое как наш SynDBRemote с открытым исходным кодом, который очень хорошо работает с Zeos / ZDBC или проприетарными альтернативами.
Но я бы предпочел переключиться на архитектуру REST с логикой на стороне сервера и SQL на этой стороне сервера. Это будет проще поддерживать и масштабировать, а также разрешать клиентам, не связанным с Delphi, например, клиентам JavaScript на настольных компьютерах или мобильных устройствах.
Комментарии:
1. ОП сказал, что VPN или SSH не могут быть использованы: через интернет-соединение можно использовать только HTTPS. Как VPN, так и SSH будут действительно безопасными при использовании сертификатов. На стороне клиента сертификат может быть опущен при использовании digipass (аппаратного устройства) с pin-кодом.
2. Спасибо, проверка указанных вами пунктов привела меня к дальнейшим соображениям. Я согласен в целом, я задал этот вопрос, потому что это серьезное приложение, и я хочу сделать правильный выбор, но это также приложения, специфичные для конкретной компании, и мы должны использовать ограниченного пользователя, зарегистрированного в PostgreSQL (для предотвращения УДАЛЕНИЯ ТАБЛИЦЫ и т. Д.).). Для клиентской части мы создали наш протокол «websql», потому что мы также используем Lazarus sqlDb (у нас также есть терминалы WinCE 6.0) Zeos несовместим с WinCE, поэтому мы создали websql-соединение для ZeosLib и sqlDB с нуля.
3. Возможно, на первом этапе мы установим программное обеспечение таким образом с сертификатами обеих сторон (как также предложил @fpiette), затем одно за другим мы преобразуем все приложения в REST (по согласованию с основной компанией).
Ответ №2:
HTTPS достаточно и безопасно, если вы используете сертификаты с обеих сторон и, очевидно, проверяете действительность сертификата.
При использовании сертификата клиент обязательно подключается к серверу, к которому, по его мнению, нужно подключиться, или он получает ошибку сертификата. То же самое для сервера: когда клиент использует сертификат, сервер может быть уверен, что клиент является законным клиентом.
Комментарии:
1. Привет, спасибо. Фактически, мой вопрос заключается в том, чтобы понять, гарантирован ли уровень безопасности в связи с тем фактом, что клиент может запускать SQL (используя компонент TZQuery) через https-соединение, если это возможно для приложений такого рода… в моей компании был спор по этому поводу 🙂
2. HTTPS с сертификатом — это не то же самое, что HTTPS без сертификата! Как я уже сказал, используя сертификат, каждая часть уверена, что другая часть является той, за которую она себя выдает. Это действительно высокий уровень безопасности. Это предотвратит атаку «человека посередине».
3. И, кстати, пожалуйста, отметьте мой ответ как «принятый» (галочка), если вы считаете его правильным ответом на свой вопрос.
4. HTTPS с сертификатами на стороне сервера может быть скомпрометирован и скомпрометирован почти во всех крупных компаниях. Эти ИТ-инфраструктуры обычно используют прокси и регистрируют свой собственный корневой сертификат на каждом компьютере компании. Таким образом, все не зашифровано, проверено и повторно зашифровано на ИТ-прокси-сервере.
5. @ArnaudBouchez Эти прокси не проблема. OP хочет обеспечить защиту между внешними производственными сайтами и корпоративной штаб-квартирой, а HTTPS с сертификатом обеспечивает необходимую защиту. И, очевидно, компания, имеющая такой прокси, доверяет своей системе и заставляет прокси проверять сертификаты.