Наши преимущества

Запретить пользователю SYSDBA доступ к базе Firebird

de3m0n

Турист
Credits
0
Подскажите, пожалуйста, можно ли каким-то образом запретить SYSDBA подключаться к базе.
Задачка простая и поэтому не хотелось бы шифровать данные(дольше буду разбираться с шифрованием, чем писать программу), а клиента очень волнует вопрос безопасности.
Вобщем, необходимо сделать так, чтобы доступ к базе осуществлялся только из клиентского приложения
 
Подскажите, пожалуйста, можно ли каким-то образом запретить SYSDBA подключаться к базе.
Если речь про FB, то можно с помощью глобальных триггеров (вроде начиная с версии 2.1 они появились). Но с такой же легкостью можно этот запрет преодолеть. То есть можете попробовать этот вариант, но только в расчете на лохов.


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


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


P.S. Не стоит ходить по полю с граблями. Если клиент так озабочен безопасностью, пусть хранит БД на своем серваке, для доступа к ней использует VPN, права на него раздает под строгим учетом, и, в случае необходимости, применяет к проштрафившимся юзерам недетские меры.
 
Я пока этим и ограничился
Поставил триггер on connect
И сказал клиенту, чтобы запретил доступ к файлу БД
Кстати, достаточно ли будет того, что пользователь будет работать в винде под ограниченной учетной записью, не имея доступа к файлу БД
Я так понимаю, что и используя VPN, я смогу, допустим, через IB Expert подключиться к базе
 
> достаточно ли будет того, что пользователь будет работать в винде под ограниченной учетной записью, не имея доступа к файлу БД

Огранниченность учетной записи в винде никак не сказывается на работе этого юзера с БД, так как работа происходит через сервер СУБД, а на нем раздача привелегий идет по своим правилам. Юзер может быть гостем в винде и sysdba при доступе к БД. Можете попробовать испоьзовать для доступа к БД аутентификацию винды, но тогда любой админ в ней у вас автоматически станет sysdba.


> Я так понимаю, что и используя VPN, я смогу, допустим, через IB Expert подключиться к базе

Любой по VPN может подключиться к БД, если он знает пароль-логин кого-то из легальных юзеров. VPN поможет только от внешнего несанкционированного подключения, для борьбы со своими пользователями он бесполезен.
 
Если уверены, что ваше приложение будет иметь строго определенное название и пользователи не будут его менять, то для контроля можете использвовать MON$REMOTE_PROCESS.

Select MON$REMOTE_PROCESS from MON$ATTACHMENTS where MON$ATTACHMENT_ID = Current_Connection

И обрабатывать название приложения, которым подключились в том же триггере на коннект. Но не забывайте, что Sysdba при желании всегда может подключиться к базе отключив все триггеры.
 
В версии 25 сделали редирект админских полномочий так что SYSDBA можно истребить как класс.

Я шифрую пароль и его может расшифровать только клиент, а больше про него никто не знает )
 
In the actual Versions of Firebird protecting your database is only possible by protecting the acces of the fdb File and the program folder of firebird

The user Controll is stored in the firebird programm folder

yust deinstall firebird and reinstall it and you have acces to your Database if the file isn't protected you can yust copy it to an other computer and have full access on it
 
Смена пароля для SYSDBA и его забытие чревато, например, при переустановке сервера, если, конечно, в случае с FireBird при переустановке затерается база security2.fdb.
Несколько непонятен вопрос про смену пароля, ведь это делается в элементе посредством, например, тех же компонентов FibPlus (SecurityService) или посредством командной строки (скрипта) и gsec.exe.
А решить полноценно проблему с SYSDBA возможно только через пароль и про это выше уже очень много написали.
 
Странно, SYSDBA - это найполнейший доступ, ограничив права разве можно завести еще одного пользователя который был бы над SYSDBA?
 
А откуда такая задача вообще? Почти во всех СУБД есть системный пользователь, который нужен для системных операций. Или заказчику бекап-рестор никогда не понадобится? Достаточно чтобы не было физического доступа к серверу. Остальное сам FB сделает.
 
обычно задача, которую описывает автор поста возникает, когда сервером приходится Делиться тоесть несколько программ разных производителей вынуждены работать под FB секурити одного сервера и в таких ситуациях права и соответственно пароль SYSDBA у администратора железки...
защититься же собирается владелец базы он же разработчик
если мое предположение верно, то помочь разработчику нечем.
единственное решение, которая на сегодня дает
более менее адекватную защиту, это полный контроль над физическим сервером FB
 
Попросить кого нить придумать и ввести два раза очень сложный пароль для SYSDBA
а потом его в Москву реку.
 
Верх