Всем Привет!
Задача следующая: планируется проект CRM на DXE7 с базой на удаленке, VDS-сервер. В качестве СУБД планируется Firebird 3.х (пока не вышла четверка). Сейчас в качестве архитектурной основы рассматривается способ подключения напрямую (не трехзвенка) и далее поясню почему. Пользователи будут все программные, кроме одного (у которого полный доступ) с самым сложным заводским паролем, который будет вычисляемый и по частям зашит в разных местах проекта, а сам экзешник будет защищен с помощью Vmprotect, с максимальной опцией Ultra. Такие экзешники сейчас никто ломать не будет, даже за деньги, ибо те времена прошли. Да и проект обычный коммерческий, не для госструктур или оборонки. Это к вопросу «вскрыть пароль главного админа», если вдруг есть доступ к базе извне у кого то… Ну и порт будет конечно же не 3050.
Далее, ближе к теме в заглавии, раскрою еще один интересный нюанс… Есть мысль использовать обычную fbclient.dll для связи по удаленке, а embedded-версию для кэширования справочников на машину клиента (в монопольном доступе, что, в общем, норм). Еmbedded здесь по причине ненужности установки серверной части на клиенте.
Так вот о кэшировании – дабы сильно облегчить нагрузку на сервер, базовые справочники и справочники контрагентов (самый пухлый справочник) хочется сразу же, после первого подключения выгрузить на локальную машину клиента, а затем, при последующих подключениях по удаленке, в фоновых потоках делать лишь сверку изменений в справочниках. Через триггерное логгирование в базе это все не сложно отслеживать.
Таким образом, есть мысль сильно все ускорить, в конечном итоге благодаря такой схеме. Однако, теория теорией, а практика дело непростое. Есть ли какие то существенные «проколы» в моей схеме?

Да, я сейчас в процессе перевода проектов с FB 2.5 на тройку, поэтому вопрошаю тут тоже.

То, что она не использует аутентификацию? Или о чем то другом речь?

В общем, коллегиально и настоятельно меня убедили не использовать никаких кэширований именно в базу на машину клиента. А если уж сильно надо активно и при этом "эскуэльно" работать со справочниками, лучше чуть больше подождать, но выкачивать их полностью в память на клиента при загрузке ПО. А поиск\фильтрацию делать в памяти, например при помощи in-memory датасетов, таких как https://www.aidaim.com/in-memory_sql_database_delphi.htm. Ну чтобы минимизировать обращения к серверу по части работы со справочниками, в особенности теми, где 10-20 тыс. записей (я про пресловутый справочник контрагентов).

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

А лично я бы пошёл как раз обратным путём: полное дублирование целой базы на машине
клиента и фоновая репликация на центральный сервер и обратно.

Так если в тройке нет embedded, значит для связи с локальной версией базы (репликой на клиенте) используется та же самая библиотека? Получается, что серверную часть FB на клиенте ставить не нужно, достаточно несколько файликов приложить в папке с проектом ? Или таки Firebird надо полноценно устанавливать на клиенте? Что то я запутался)

Ну ладно, ладно, нашел, распутался))

MDT вроде как уже неживой проект?
Вот вариант, который предложил Дмитрий Сибиряков с полной репликацией у меня опробован и работает вполне замечательно, но... захотелось что то попроще, без установки и настройки репликации на машинах клиентов. Кто бы как поступил на моем месте?

Пускание пыли в глаза и распил бюджета. Добросовестный, от неграмотности.
Вроде ж в начале все расписал:) Пользователи программные, а не настоящие. То есть по сути все будут коннектиться де-факто через одну и ту же учетку, с полными правами. В одном из проектов у меня так и работает. А пароль так сильно прячу, чтобы не было возможности его вскрыть. Даже теоретически.


1. Пока 2-3 сотни, дальше видно будет.
2. Будем искать поставщиков с хорошим пингом, максимально коротким.

А можно подробнее ?
P.S: Я как то лет 5 назад поднимал дискуссию про программных юзеров, мнения разделились:
https://www.sql.ru/forum/1160938-2/programmnye-polzovateli-chrevato

И, кстати, вход будет не по SYSDBA, а по другому пользователю, но с полными правами. Все как завещал kdv! :)

Да. С аппетитом.


см. тут: https://www.sql.ru/forum/1160938/programmnye-polzovateli-chrevato

Я же и говорю: от полной неграмотности в части компьютерной безопасности. Ключ от квартиры
ты можешь прятать как угодно глубоко, но всегда приходит момент, когда его надо воткнуть в
замок...
Дмитрий, расшифруйте, будьте так любезны... применительно к моему случаю. А то в данном случае, иносказательно я не совсем понимаю.
Имеется ввиду, что в момент удаленного подключения "ключ"(пароль) перехватить можно легко?

В окне авторизации вводим "логин + пароль", из этой пары получаем хэш, который программа через sql-запрос проверяет через коннект под той самой учеткой, с полными правами и сложным паролем. Если такой хэш нашелся, определяем пользователя из таблицы пользователей. Ну, а далее, в зависимости от настроек прав, разрешаем\запрещаем те или иные возможности. Вот что имелось ввиду под программными пользователями.

Да. В момент любого подключения. Об этом тебе и твердят. Базовый парадокс: безопасность
против юзабельности. "Абсолютно безопасной системой абсолютно невозможно пользоваться." (с)
Мир придумал сертификаты и https как инструмент шифрования трафика, а что делать тем кто работает с прямым подключением к базе? Неужели ничего нет для нас? Шифрование строки коннекта имею ввиду.

Ну так я же в облако то еще не выходил:))
То было на уровне локальных экспериментов.
Вот щас дошло дело до дела, поскольку переделываем проекты с FB 2.5 на тройку.

Правильные ответы не стареют.
Золотые слова :)

Внезапно... для меня конечно же :)

SRP-аутентификация, а также WireCrypt = Enabled в опциях сервера вроде как именно то, что мне нужно для исключения проблемы с расшифровкой перехваченного коннекта? Или я заблуждаюсь?

Dimitry Sibiryakov,

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

В тройке клиент не надо патчить. За час собирается плагин с заглушками всюду кроме
attachDatabase() и подсовывается первым в список провайдеров в firebird.conf. Всё, телемаркет.
Хмм, если все так просто, неужели это нельзя пресечь уже сейчас в тройке? И тем более, в четверке предстоящей. Которая "релиз-кандидат"(!).

А откуда он (полный доступ) возьмется то? Мы же не про рутового пользователя говорим, а с "условно полным доступом". Поэтому я и спрашиваю, если пресечь то, о чем говорит Dimitry Sibiryakov, базу не вытащить (upd: хочется верить).

Для этого ей придётся-таки образцово-показательный конфиг приложить, поскольку по
умолчанию он на клиенте отсутствует и проверять, таким образом, нечего. И как-то
проследить чтобы никто не установил переменную окружения FIREBIRD, которая укажет на
совсем другой конфиг. И т.д. и т.п. Аффтар ниасилит.
Аффтар давеча вычитал вот еще какую тему (см. справку протектора), и проверил. Работает схема - любые клиенты-dll имеющиеся на диске теперь не важны - fbclient.dll из памяти грузится. Правда пока из екзешника в память распакуется тоже ждать секунд 5 приходится, но тем не менее:

А потом проверяет наличие firebird.conf в каталоге откуда запущено приложение и загружает
все прописанные там провайдеры. "Поздравляю, Шарик..." (с)
Хмм.. А где он (взломщик гипотетический) возьмет параметры коннекта: логин, пароль, саму строку подключения с портом? Если их (строку подключения и порт) запрятать во внешний зашифрованный файл, как некий кастомный конфиг подключения ? Я то знаю как его расшифровать и как он называется и где лежит, а вот товарищ-взломщик гадать будет...