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

[de3m0n]

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

 

[Ognev]

Подскажите, пожалуйста, можно ли каким-то образом запретить SYSDBA подключаться к базе.

Если речь про FB, то можно с помощью глобальных триггеров (вроде начиная с версии 2.1 они появились). Но с такой же легкостью можно этот запрет преодолеть. То есть можете попробовать этот вариант, но только в расчете на лохов.

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

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

Задачка простая и поэтому не хотелось бы шифровать данные(дольше буду разбираться с шифрованием, чем писать программу), а клиента очень волнует вопрос безопасности.

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


P.S. Не стоит ходить по полю с граблями. Если клиент так озабочен безопасностью, пусть хранит БД на своем серваке, для доступа к ней использует VPN, права на него раздает под строгим учетом, и, в случае необходимости, применяет к проштрафившимся юзерам недетские меры.

 

[de3m0n]

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

 

[Ognev]

> достаточно ли будет того, что пользователь будет работать в винде под ограниченной учетной записью, не имея доступа к файлу БД

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


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

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

 

[Ognev]

Если уверены, что ваше приложение будет иметь строго определенное название и пользователи не будут его менять, то для контроля можете использвовать MON$REMOTE_PROCESS.

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

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

 

[YuriyR]

В версии 25 сделали редирект админских полномочий так что SYSDBA можно истребить как класс.

Я шифрую пароль и его может расшифровать только клиент, а больше про него никто не знает )

 

[Donk]

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

 

[wb77]

... можно ли каким-то образом запретить SYSDBA подключаться к базе

Смените пароль для SYSDBA и забудьте его

 

[zashiki2009]

Смена пароля для SYSDBA и его забытие чревато, например, при переустановке сервера, если, конечно, в случае с FireBird при переустановке затерается база security2.fdb.
Несколько непонятен вопрос про смену пароля, ведь это делается в элементе посредством, например, тех же компонентов FibPlus (SecurityService) или посредством командной строки (скрипта) и gsec.exe.
А решить полноценно проблему с SYSDBA возможно только через пароль и про это выше уже очень много написали.

 

[vlad-mal]

Смените пароль для SYSDBA...

Если ограничен физический доступ к серверу, этого 100% достаточно.

 

[formeram]

Запретить SYSDBA

В версии 2.5 у SYSDBA можно отнять права.

 

[xSer]

Странно, SYSDBA - это найполнейший доступ, ограничив права разве можно завести еще одного пользователя который был бы над SYSDBA?

 

[megaevgen]

А откуда такая задача вообще? Почти во всех СУБД есть системный пользователь, который нужен для системных операций. Или заказчику бекап-рестор никогда не понадобится? Достаточно чтобы не было физического доступа к серверу. Остальное сам FB сделает.

 

[maremora]

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

 

[Weasel]

Попросить кого нить придумать и ввести два раза очень сложный пароль для SYSDBA
а потом его в Москву реку.

 

[and_kors]

Не забывайте про возможность утащить файл базы на другую машину и там свободно его смотреть через локальный сервер под SYSDBA.

 

[pppDSV]

Не забывайте про возможность утащить файл базы на другую машину и там свободно его смотреть через локальный сервер под SYSDBA.

+1 - Все защиты от сисадмина - величайшая глупость. Если он имеет прямой доступ к файлам БД - не защитишься
ни чем.

 

[F_AV_N]

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

 

[Tinitus]

Попросить кого нить придумать и ввести два раза очень сложный пароль для SYSDBA
а потом его в Москву реку.

На сколько я знаю, это не поможет. Юзер делает backup и потом делает restore со своей паролью, после чего он может подключаться к БД с SYSDBA и этой паролью.

А откуда такая задача вообще? Почти во всех СУБД есть системный пользователь, который нужен для системных операций. Или заказчику бекап-рестор никогда не понадобится? Достаточно чтобы не было физического доступа к серверу. Остальное сам FB сделает.

По крайней мере в моём случае дело в том, что некоторые конкуренты тоже пользуються Firebird. Таким образом они могут заглядывать в мою ДБ и видеть что я там делаю и как. Это их не касается.

Дополнительно к этому некоторые клиенты тоже интересуются этим и начинают химичеть, хотя это и их не касается.

Поэтому я тоже интересуюсь возможностями предотвращения доступа к ДБ, если не известна пароль.

Интересно было-бы узнать подробности об этих двух коментарах:

В версии 25 сделали редирект админских полномочий так что SYSDBA можно истребить как класс.

Я шифрую пароль и его может расшифровать только клиент, а больше про него никто не знает )

В версии 2.5 у SYSDBA можно отнять права.

...Или о других возможностях.

 

[tomor]

Смена пароля из командной строки
gsec.exe -user SYSDBA -password masterkey -modify SYSDBA -pw 'Новый пароль'