Интеграция веб-интерфейса с приложением. Безопасность?

[wwswowsogon]

Всем доброго времени суток!

Некоторое время назад передо мной встала интересная задача. Необходимо сделать на сайте некий функционал, позволяющий пользователю делать запросы к БД клиент-серверного приложения, сделанного на FPC + FB.

В случае, если разработчиком сайта я не являюсь (а так, скорее всего, и будет) то способ решения этого вопроса представляется следующим:

1) запилить некий веб-сервис, с адресом и портом например, на Python'е.
2) У этого веб-сервиса будет реализован некий API, через который сайт от пользователя будет передавать данные веб-сервису.
3) А веб-сервис, в свою очередь, будет передавать данные прямо в БД, или, возможно, в некое промежуточное хранилище, из которого потом основной софт будет забирать данные, обрабатывать должным образом и уже сам их писать в БД.

Собственно, вопрос, насколько безопасен данный подход? Я что-то не очень соображаю.

Веб-сервис означает IP-адрес, который будет торчать в интернет, вероятно.

А значит, будет подвержен атакам. Второй вариант (с промежуточным хранилищем) представляется в этом плане лучше, поскольку, если злодей взломает веб-сервис, он не сможет через него напрямую писать данные в БД/делать запросы.

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

[Ichthyander]

Безопаснее и удобнее сделать трехзвенную архитектуру. То есть максимально изолировать базу данных. Доступ к базе данных запретить извне само собой.
Почти как Вы сказали. Про промежуточное хранилище не понял как и зачем.
Запиливаете веб-сервис, с которым через API фронтенд клиенты (в т.ч. ваш сайт), как я понимаю через Ajax?
Кстати, веб-сервис Вы также можете выполнить на FPC. Никаких промежуточных доп. сервисов не потребуется тогда. Просто этот веб-сервис будет и веб-сервером и API шлюзом. То есть на нем будет реализована вся логика и он же будет обращаться к базе данных. Дальше у него может быть несколько интерфейсов. Веб-интерфейс для сайта, API для возможного подключения в будущем, к примеру, мобильных приложений, можно будет также прикрутить телеграм/slack интерфейс и т.д.

Добавлено спустя 1 минуту 27 секунд:
<<Я понимаю, что вопрос, может быть, больше к системным администраторам, но если кто выскажет соображения, буду весьма признателен.>> То есть если говорить о безопасности, нужно чтобы не было доступа к Вашей базе данных снаружи. Только опосредованно через ваш веб-сервис, промежуточное звено

[Снег Север]

wwswowsogon, размещая данные удаленно, вы, по определению, "торчите в интернете" и потенциально являетесь объектом атаки. А про стандартный подход вам выше всё правильно написали.

[Alex2013]

По моему наблюдается некий избыток паранойи . Любой комп подключенный к интернету это "IP-адрес, который торчит в интернет". Но (ИМХО) досточно замаскировать внешний вид сервиса (при проверке портов сканером ) под что-то стандартное и "скучное" вероятность "случайного взлома" упадет в разы. "Направленный взлом" тоже можно заметно усложнить например "белым списком контактов" который-бы освежался например при входе на сервис "через почту" ( то бишь автоматически отсылаемым с программы-клиента письмом на внешний ящик ) .

[wwswowsogon]

Всем спасибо за комментарии.

Про промежуточное хранилище не понял как и зачем.

Ну, типа, отдельный сервер/общая папка с файлом/файлами, куда пишется инфо веб-сервисом. А потом оттуда забирается сервисом самого приложения и пишется в БД.

как я понимаю через Ajax?

AJAX не будет, думаю. Во-первых, я его не умею, во-вторых, он не сильно и нужен. Поток данных небольшой и не слишком частый предполагается.

веб-сервис Вы также можете выполнить на FPC.

- подумывал над этим Но есть опасения, что это усложнит разработку. К тому же, опять же, я не самый классный программист
Если можно, посоветуйте для этого FPCшные библиотеки, желательно кроссплатформенные. Indy?

сервис будет и веб-сервером и API шлюзом.

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

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

- да, логично. Но все же посещают параноидальные мысли насчет того, что, если сервис будет взломан. Это маловероятно, конечно.

По моему наблюдается некий избыток паранойи

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

. Любой комп подключенный к интернету это "IP-адрес, который торчит в интернет". Но (ИМХО) досточно замаскировать внешний вид сервиса (при проверке портов сканером ) под что-то стандартное и "скучное" вероятность "случайного взлом" упадет в разы.

можно заметно усложнить например "белым списком контактов"

- эт чё такое?

[Alex2013]

"Белый список контактов" это когда соединение по определенному протоколу возможно только для определенных IP .
(все остальные вообще этот протокол или порт не замечают )

[wwswowsogon]

Ясно, спасибо

[Ichthyander]

- подумывал над этим Но есть опасения, что это усложнит разработку. К тому же, опять же, я не самый классный программист
Если можно, посоветуйте для этого FPCшные библиотеки, желательно кроссплатформенные. Indy?

Инди/синапс это скорее просто обертка над сетевыми протоколами. Если делать сайт/API, то предполагается веб-фреймворк как минимум. Есть нативный fcl-web, а есть brookframework. Его я рекомендую. Есть еще Мормот, но его не юзал