DFilushinМне главное чтобы случайными средствами не подключались к БД.Где-то на форуме уже писал об этом. Отвечу для земляка :)

В качестве усиления надежности и защищенности предлагаю ПЛЮС к тому, что уже планируется (идею с ролями или без):

Скрывать от юзеров их реальный пароль БД (у меня двухфазная авторизация, а можно просто хитро обфусцировать введенный пароль).
В результате пользователь, помимо программы (допустим через IBExpert) не сможет зайти.

Хороший хакер таки сможет войти в базу под СВОИМ ЗАКОННЫМ логином и паролем,
ну что ж… для таких работает исходный уровень защиты!
Роли и права, которые топикстартер и так будет раздавать, все равно сделают свою работу.

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

Еще одна рекомендация по «надёжности и защищенности»:

У меня никто из пользователей не имеет DML прав на таблицы. Эти права есть у процедур.
Хакер даже залогинясь в БД не может изменить данные в таблицах, минуя мои процедуры.
А процедуры не делают ничего противоречащего логике программы. Ведут журнал своей работы.
Хакеру остается крайне тесное поле деятельности.

Мне с лихвой хватает описанного уровня защиты,
но при желании можно реализовать и следующий, параноидальный этап квеста:

Все мои DML-процедуры ведут журнал.
Если в момент записи журнала организовать сверку,
задано ли перед началом работы программой определенное число в определенном месте,
хитро вычисляемое от ID конкретной сессии и, если желаете, дате коннекта :)
Если не задано, извините, получите Exception, с записью в журнал попыток взлома системы.

Придется хакеру определять алгоритм вычисления/сверки этого числа, можно назвать его хэшем.
Исходника сверки в БД естественно нет, дотошному хакеру придется разбираться с BLR, если конечно есть доступ к файлу БД.

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

К сожалению для хакера, триггер on-connect делает много полезного, в частности назначает некоторые id,
без которых ни одна DML процедура не заработает. Придется разбираться, что делает программа, чтобы коннект был признан корректным.

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