Вчера мне показали такой финт:
Если иметь доступ к служебной базе ISC4.GDB, то чтобы добраться до всех данных в любой базе не зная пароля SYSDBA, достаточно подменить существующий ISC4.GDB на "чистый" созданный сбоку в свежеустановленном интербейсе. И все -- SYSDBA будет со стандартным паролем.
Нормально ли это?
Я понимаю, в системе клиент-сервер никто кроме админа БД не может иметь прав доступа к файлам БД. Но все же? Если Interbase запущен не на отдельном серваке а на обычной рабочей машине?

Именно так. Это слабое место IB/FB.
Лично я считаю, что защита данных от доступа со стороны злоумышленника, в IB/FB реализованна не очень хорошо. Точнее даже плохо.
Но, я все равно его люблю
Как ты правильно отметил, проблема в основном только при работе IB/FB-сервера на машине клиента.

Мдя... очччень неприятное разочарование....
А что можно сделать для максимальной защиты данных в таком случае (когда нет отдельного сервера БД)?

Cколько пользователей?

2Alex
Сейчас -- всего 5. Возможно небольшое увеличение

Тогда проблем нет, есть одна машина, на которую ставится сервер и база данных, доступ к папке сервера и базы данных делается не доступным из сети, на машинах пользователей ставь только клиентскую часть. И все, настраивай строку коннекта и вперед. Пользователь просто не сможет копирнуть твою базу, а IB/FB все равно расшарена папка на серваке с базой или нет, он до нее в любом случаи доберется.

Цитата

Лично я считаю, что защита данных от доступа со стороны злоумышленника, в IB/FB реализованна не очень хорошо. Точнее даже плохо.

Сами разработчики IB считают, что защита информации в БД не должна ложиться на сервер БД, информация должна защищаться средствами ОС, т.е. об этом должен думать админ БД, а не разработчики IB, жаль.

Цитата(dsergey @ 5.2.2005, 12:18)

Сами разработчики IB считают, что защита информации в БД не должна ложиться на сервер БД, информация должна защищаться средствами ОС, т.е. об этом должен думать админ БД, а не разработчики IB, жаль.

В принципе, я абсолютно согласен с разработчиками.
Просто дело в том, что IB/FB очень компактный SQL-сервер. Это провацирует на использование его в небольших, в том числе однопользовательских приложениях. Естественно, для таких приложений неразумно использование отдельного компьютера для SQL-сервера. Более того, FB v >= 1.5 вообще имеет однопользовательский вариант SQL-сервера реализованный в виде DLL, так называемый Embedded Server.
Но, тут как всегда, одни свойства приносятся в жертву другим.
Так что, если уж клиенту (потребителю приложения) требуется обеспечение защиты доступа к БД, ему просто необходимо полноценное использование SQL-сервера в том виде как описал Alex - за безопасность всегда приходится чем-то платить.
Замечу, более продвинутые в области безопасности SQL-сервера, тоже вряд-ли обеспечат высокий уровень защиты если они работают на клиентском компьютере. К данным может и не доберешся, но уж "снести" их не будет проблем.

Добавлено @ 14:26
Впротчем, если бы в IB/FB было бы хотя бы элементарное шифрование хранимых данных на основе некоторого, определяемого приложением ключа, я бы сказал разработчикам большое спасибо

Цитата

Впротчем, если бы в IB/FB было бы хотя бы элементарное шифрование хранимых данных на основе некоторого, определяемого приложением ключа, я бы сказал разработчикам большое спасибо

Вот-вот! Как с языка мне снял