Защита БД

← →
SaperXL (2003-12-28 16:13) [0]

Допустим я разработал крутую базу (чисто гипотетически).
Она хранится в gdb файле. Как не дать никому посмотреть (и уж тем более) редактировать её? На скольок я понял username и password не имеют никакого отношения к самой базе (а только к СУБД), т.е. достаточно присобачить базу к другой СУБД и пароль становится SYSDBA:masterkey (или другой заданный)...

← →
Anatoly Podgoretsky (2003-12-28 16:25) [1]

Ни в коем случае не давать прямого доступа до файла(ов) базы данных

← →
Vlad (2003-12-28 16:43) [2]

Все пользователи и пароли сервера хранятся в отдельной системной базе isc4.gdb, поэтому "взломщику" достаточно будет подменить лишь этот файл на свой чтобы получить доступ ко всем БД сервера.
Поэтому, думаю, единственный путь - Anatoly Podgoretsky © (28.12.03 16:25) [1]

← →
gestern (2003-12-28 17:49) [3]

<img src=" http://delphi.mastak.ru/i/smile13.gif">
> Ни в коем случае не давать прямого доступа до файла(ов)
> базы данных

Что имеется в виду. И как их припрятать можно.

← →
Sergey_Masloff (2003-12-28 22:06) [4]

>Что имеется в виду. И как их припрятать можно.
база на сервере. сервер в серверной за железной дверью. за неоткрытие этой двери отвечает персонально человек. Я думаю имеется в виду именно это.

← →
SaperXL (2003-12-28 22:08) [5]

Да я тоже не совсем не понимаю, что значит "не давать прямого доступа"...
Можно конечно как-то кодить файл по ключу, нарезать частями и разбрасывать. А перед началом работы все проделывать назад, но... ведь во время работы прграммы нужен файл gdb. И злоумышленник всегда может запустить программу посмотреть где есть файл базы, пойти и взять его...
Так как "не давать прямого доступа до файлов"?

← →
Плохиш_ (2003-12-28 22:49) [6]

>SaperXL (28.12.03 22:08) [5]

> пойти и взять его...

Вот это и имелось в виду

← →
Anatoly Podgoretsky (2003-12-29 00:23) [7]

SaperXL (28.12.03 22:08) [5]
Для работы программы не требуется прямой достуа до файла, только до сервера.

← →
Desdechado (2003-12-29 11:16) [8]

а для чего ты ее делал, чтоб никто не мог залезть в нее? для своего домашнего пользования - так и пользуйся дома :)
а если тебя волнуют не данные, а метаданные при распространении, то есть на ibase.ru утилитка их зачистки
ну, а БД с доступом только для чтения можно сделать утилитами самого IB

← →
DCoder (2003-12-29 11:45) [9]

Если речь идет о программных методах защиты, а не о физических, то необходимо разработать политику безопасности.
Разобраться кто из персонала на какие действия имеет права по отношению к информации в БД и самого файла БД.
Реализовать эту политику :
1) частично в клиентском приложении путем ограничения каких либо функций
2) В ОС клиентских машин установить пароли для пользователей (Если это НТ-платформа)
3) Настроить политику безопасности в ОС сервера (Желательно использовать линукс) Файрвол и т.д.
4)В самой БД распределить права пользователей используя средства
GRANT/REVOKE

Я, например, при подключении к БД на программном уровне сверяю клиентское имя ПК (можно добавить еще и имя Юзера) с табличкой - списком юзеров в БД. К именам привязан код, который характеризует права этого пользователя
1-продавец
2-бухгалтер
3-админ
4-директор.
В соотв с этим кодом разрещаю/блокирую опр. функции в программе.
Таким образом она для всех одинаковая с точки зрения кода, а с точки зрения прав - разная

Димыч

← →
saperxl (2003-12-31 01:40) [10]

все типа крутые...
БД я разрабатывал, чтобы продать (вместе с программным обеспечением)... Просто слишком много умных развелось: сопрут метаданные - полбеды, сопрут данные - полный абзац.
Что касается изменения данных - надо предполагать (для тех кто не знает), что пользователь абсолютно тупое создание, я хочу чтобы те данные которые я позволю (написав соотв. ПО) редактировать - редактировал, остальное привелегии богов...
Потом что-то было про клиентские приложения?! Как бы по сетке получается запросы к БД?! Не пойдет - не хочу расстраивать, но как бы не в Америке живем: я пишу систему для использования в гос. учреждениях во всех 89 субъектах РФ, и по какой, простите, сетке предложите обращаться к БД?!
Про безопасность в СУБД, кажется, уже обмывали...

← →
Sergey_Masloff (2003-12-31 06:56) [11]

saperxl (31.12.03 01:40) [10]
Вобщем, ты ничего не понял. Говорю еще раз - при наличии физического доступа к файлу .GDB у "врага" ты ничего не защитишь. Да это и не твоя забота - твоя забота написать софт и возможно регламент мероприятий по защите данных. Остальное не твое дело.
Защита от действий пользователя решается раздачей соответствующих грантов на объекты БД и грамотной реализацией клиентского софта.
И абсолютно пофиг происходит это в 89 субъектах РФ или еще где-то.

← →
Andriano (2003-12-31 08:18) [12]

Можно использовать секретный IP туннель, каких сейчас пруд пруди. Например, zebedee (бесплатен). Тогда даже несанкционнированное подключение к серверу БД - из области фантастики.

← →
saperxl (2004-01-05 03:51) [13]

Sergey_Masloff
Я правильно понимаю, что для того чтобы не было физического доступа к файлу базы надо чтобы база лежала на сервере (некоторой сети), а программы запускались на клиентских машинах и при этом обращались к удаленной базе?
Если не так, то расскажи как на пальцах, пожалуйста.
Если так, то это не реально. По крайней мере в условиях нашей экономики. Предоставить любую сеть (даже, интернет) на все возможные объекты использования клиентских приложений - невозможно. А вот вполне возможно было бы посадить каждого клиента со своей базой отдельно, но раз в год склеивать базы ото всех клиентов (спроектированная БД позволяет).
А по поводу "это не мои проблемы" - в том то и дело, что я новатор во внедрении и первейшее лицо заинтересованное в успешном внедрении...

← →
RUYurik (2004-01-05 04:56) [14]

> saperxl (05.01.04 03:51) [13]

Вот и пускай "по сетке" все работает отдельно, ну и базы сливай хоть раз в год, да и хоть сколько (для сдивания пример - http://www.delphimaster.ru/cgi-bin/download.pl?look=1&id=1072686652&n=1)

← →
Sergey13 (2004-01-05 08:33) [15]

2saperxl
>...я пишу систему для использования в гос. учреждениях во всех 89 субъектах РФ...
>...я новатор во внедрении и первейшее лицо заинтересованное в успешном внедрении...
Здравствуйте Владимир Владимирович. 8-)

← →
paul_k (2004-01-05 10:17) [16]

1. до самого файла БД пользователь прямого доступа не имеет
он не может его скопировать/просмотреть/изменить/удалить. До файла имеет доступ сам сервер данных к которому обращается клиентское приложение и он(сервер) отдает клиенту данные (или не отдает) согласно настройкам доступа ролей пользователей и так далее.
2. подумай на тему кто может спереть данные. так называемая модель нарушителя должна иметь место быть.
Имея логин-пароль подсоединится к базе, сделать селект (или выполнить ХП) можно не только из твоего приложения. Следовательно можно получить данные скопировать на дискету и унесть. А можно с экрана переписать на бумажку и унесть . А можно отчеты распечатать. А еще юзера вечно хотят отчеты в ворд-эксель. тоже дыра
То есть выясни кто враг и от него защищайся.

← →
Vemer (2004-01-05 10:49) [17]

как вариант - шифруй текстовые поля, простенький образец в базе бесплатных решений есть. Алгоритм можно усложнить до нужной кондиции. А числовые поля без текста малоинформативны, но с ними тоже можно что-нибудь сотворить при необходимости.

← →
Sergey13 (2004-01-05 11:05) [18]

Да фигня все эти защиты. Никакая защита не помешает имеющему доступ юзеру/админу сплавить базу налево. Наибольший эфект как правило достигается при использовании административных методов, ИМХО.
А вообще, при желании серьезной софтовой защиты, берут не общедоступные (даже в коде) и бесплатные сервера, а нечто более сурьезное.

← →
Vlad (2004-01-05 11:11) [19]

> Sergey13 © (05.01.04 11:05) [18]
> Да фигня все эти защиты. Никакая защита не помешает имеющему
> доступ юзеру/админу сплавить базу налево.

Интересно, кому можно сплавить базу "налево", если все данные в ней криптографически зашифрованы ? Т.е. кому такая база будет интересна ? :-)

← →
Sergey13 (2004-01-05 11:20) [20]

2Vlad © (05.01.04 11:11) [19]
А расшифровать при наличии кодирующей проги и полного доступа нельзя? Было бы желание. Нет как известно, таких крепостей, которые бы....

← →
Vemer (2004-01-05 12:05) [21]

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

← →
saperxl (2004-01-05 12:11) [22]

RUYurik
А как это "по сетке отдельно". Что-то я не понимаю, наверное...

← →
saperxl (2004-01-05 12:17) [23]

А то есть у них же в локальное сети на сервак поставить СУБД и базу, а серверную закрыть на ключ?..

← →
paul_k (2004-01-05 12:56) [24]

2saperxl
а можно в договоре прописать штрафы немерянные за появление данных на рынке. судя по масштабности заказчик то один...
и жить потом спокойно, иногда таскаясь по судам и получая дивиденды от правильно составленного договора

← →
Danilka (2004-01-05 14:35) [25]

[18] Sergey13 © (05.01.04 11:05)
>А вообще, при желании серьезной софтовой защиты, берут не общедоступные
>(даже в коде) и бесплатные сервера, а нечто более сурьезное.

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

← →
Danilka (2004-01-05 14:40) [26]

А вообще-то, если в "89 субъектах", то ничего не спасет от разгильдяйства.
Накикие СУБД, никакие пароли. :((

← →
Danilka (2004-01-05 14:46) [27]

[23] saperxl (05.01.04 12:17)
> А то есть у них же в локальное сети на сервак поставить
> СУБД и базу, а серверную закрыть на ключ?..

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

Защита БД Найти похожие ветки