| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Защита БД [D7, Firebird 1.0]
SaperXL © (2003-12-28 16:13:00)
Допустим я разработал крутую базу (чисто гипотетически).
Она хранится в gdb файле. Как не дать никому посмотреть (и уж тем более) редактировать её? На скольок я понял username и password не имеют никакого отношения к самой базе (а только к СУБД), т.е. достаточно присобачить базу к другой СУБД и пароль становится SYSDBA:masterkey (или другой заданный)...
Danilka (2004-01-05 14:46:00) [1]
[23] saperxl (05.01.04 12:17)
> А то есть у них же в локальное сети на сервак поставить
> СУБД и базу, а серверную закрыть на ключ?..
Угу. И ни в коем случае, никаким юзерам не давать доступа по сети к файлу БД. Тогда все будет ок, если конечно админ сам ее не утянет и не раздаст друзьям.
Danilka (2004-01-05 14:40:00) [2]
А вообще-то, если в "89 субъектах", то ничего не спасет от разгильдяйства.
Накикие СУБД, никакие пароли. :((
Danilka (2004-01-05 14:35:00) [3]
[18] Sergey13 © (05.01.04 11:05)
>А вообще, при желании серьезной софтовой защиты, берут не общедоступные
>(даже в коде) и бесплатные сервера, а нечто более сурьезное.
А какие есть СУБД, хоть платные, хоть бесплатные, в которы нельзя получить полный доступ к данным, имея файл(ы) БД? Если не ошибаюсь, MsGuns говорил про какую-то СУБД, но там данные шифруются по паролю юзверя, поэтому только он имеет доступ к этим данным, что, вобщем-то, можно проделать клиентом для любой СУБД.
paul_k (2004-01-05 12:56:00) [4]
2saperxl
а можно в договоре прописать штрафы немерянные за появление данных на рынке. судя по масштабности заказчик то один...
и жить потом спокойно, иногда таскаясь по судам и получая дивиденды от правильно составленного договора
saperxl (2004-01-05 12:17:00) [5]
А то есть у них же в локальное сети на сервак поставить СУБД и базу, а серверную закрыть на ключ?..
saperxl (2004-01-05 12:11:00) [6]
RUYurik
А как это "по сетке отдельно". Что-то я не понимаю, наверное...
Vemer (2004-01-05 12:05:00) [7]
Невскрываемых защит нет, но прогу (и алгоритм шифрования в ней) намного легче защитить чем GDB базу, а если еще шифрование на ключик повесить, который к LPT сервера подцепить, который в запертой серверной стоит и к которому админа можно и не пускать, то смысла тащить базу нет никакагого..
Sergey13 (2004-01-05 11:20:00) [8]
2Vlad © (05.01.04 11:11) [19]
А расшифровать при наличии кодирующей проги и полного доступа нельзя? Было бы желание. Нет как известно, таких крепостей, которые бы....
Vlad (2004-01-05 11:11:00) [9]
> Sergey13 © (05.01.04 11:05) [18]
> Да фигня все эти защиты. Никакая защита не помешает имеющему
> доступ юзеру/админу сплавить базу налево.
Интересно, кому можно сплавить базу "налево", если все данные в ней криптографически зашифрованы ? Т.е. кому такая база будет интересна ? :-)
Sergey13 (2004-01-05 11:05:00) [10]
Да фигня все эти защиты. Никакая защита не помешает имеющему доступ юзеру/админу сплавить базу налево. Наибольший эфект как правило достигается при использовании административных методов, ИМХО.
А вообще, при желании серьезной софтовой защиты, берут не общедоступные (даже в коде) и бесплатные сервера, а нечто более сурьезное.
Vemer (2004-01-05 10:49:00) [11]
как вариант - шифруй текстовые поля, простенький образец в базе бесплатных решений есть. Алгоритм можно усложнить до нужной кондиции. А числовые поля без текста малоинформативны, но с ними тоже можно что-нибудь сотворить при необходимости.
paul_k (2004-01-05 10:17:00) [12]
1. до самого файла БД пользователь прямого доступа не имеет
он не может его скопировать/просмотреть/изменить/удалить. До файла имеет доступ сам сервер данных к которому обращается клиентское приложение и он(сервер) отдает клиенту данные (или не отдает) согласно настройкам доступа ролей пользователей и так далее.
2. подумай на тему кто может спереть данные. так называемая модель нарушителя должна иметь место быть.
Имея логин-пароль подсоединится к базе, сделать селект (или выполнить ХП) можно не только из твоего приложения. Следовательно можно получить данные скопировать на дискету и унесть. А можно с экрана переписать на бумажку и унесть . А можно отчеты распечатать. А еще юзера вечно хотят отчеты в ворд-эксель. тоже дыра
То есть выясни кто враг и от него защищайся.
Sergey13 (2004-01-05 08:33:00) [13]
2saperxl
>...я пишу систему для использования в гос. учреждениях во всех 89 субъектах РФ...
>...я новатор во внедрении и первейшее лицо заинтересованное в успешном внедрении...
Здравствуйте Владимир Владимирович. 8-)
RUYurik (2004-01-05 04:56:00) [14]
> saperxl (05.01.04 03:51) [13]
Вот и пускай "по сетке" все работает отдельно, ну и базы сливай хоть раз в год, да и хоть сколько (для сдивания пример - http://www.delphimaster.ru/cgi-bin/download.pl?look=1&id=1072686652&n=1)
saperxl (2004-01-05 03:51:00) [15]
Sergey_Masloff
Я правильно понимаю, что для того чтобы не было физического доступа к файлу базы надо чтобы база лежала на сервере (некоторой сети), а программы запускались на клиентских машинах и при этом обращались к удаленной базе?
Если не так, то расскажи как на пальцах, пожалуйста.
Если так, то это не реально. По крайней мере в условиях нашей экономики. Предоставить любую сеть (даже, интернет) на все возможные объекты использования клиентских приложений - невозможно. А вот вполне возможно было бы посадить каждого клиента со своей базой отдельно, но раз в год склеивать базы ото всех клиентов (спроектированная БД позволяет).
А по поводу "это не мои проблемы" - в том то и дело, что я новатор во внедрении и первейшее лицо заинтересованное в успешном внедрении...
Andriano (2003-12-31 08:18:00) [16]
Можно использовать секретный IP туннель, каких сейчас пруд пруди. Например, zebedee (бесплатен). Тогда даже несанкционнированное подключение к серверу БД - из области фантастики.
Sergey_Masloff (2003-12-31 06:56:00) [17]
saperxl (31.12.03 01:40) [10]
Вобщем, ты ничего не понял. Говорю еще раз - при наличии физического доступа к файлу .GDB у "врага" ты ничего не защитишь. Да это и не твоя забота - твоя забота написать софт и возможно регламент мероприятий по защите данных. Остальное не твое дело.
Защита от действий пользователя решается раздачей соответствующих грантов на объекты БД и грамотной реализацией клиентского софта.
И абсолютно пофиг происходит это в 89 субъектах РФ или еще где-то.
saperxl (2003-12-31 01:40:00) [18]
все типа крутые...
БД я разрабатывал, чтобы продать (вместе с программным обеспечением)... Просто слишком много умных развелось: сопрут метаданные - полбеды, сопрут данные - полный абзац.
Что касается изменения данных - надо предполагать (для тех кто не знает), что пользователь абсолютно тупое создание, я хочу чтобы те данные которые я позволю (написав соотв. ПО) редактировать - редактировал, остальное привелегии богов...
Потом что-то было про клиентские приложения?! Как бы по сетке получается запросы к БД?! Не пойдет - не хочу расстраивать, но как бы не в Америке живем: я пишу систему для использования в гос. учреждениях во всех 89 субъектах РФ, и по какой, простите, сетке предложите обращаться к БД?!
Про безопасность в СУБД, кажется, уже обмывали...
DCoder (2003-12-29 11:45:00) [19]
Если речь идет о программных методах защиты, а не о физических, то необходимо разработать политику безопасности.
Разобраться кто из персонала на какие действия имеет права по отношению к информации в БД и самого файла БД.
Реализовать эту политику :
1) частично в клиентском приложении путем ограничения каких либо функций
2) В ОС клиентских машин установить пароли для пользователей (Если это НТ-платформа)
3) Настроить политику безопасности в ОС сервера (Желательно использовать линукс) Файрвол и т.д.
4)В самой БД распределить права пользователей используя средства
GRANT/REVOKE
Я, например, при подключении к БД на программном уровне сверяю клиентское имя ПК (можно добавить еще и имя Юзера) с табличкой - списком юзеров в БД. К именам привязан код, который характеризует права этого пользователя
1-продавец
2-бухгалтер
3-админ
4-директор.
В соотв с этим кодом разрещаю/блокирую опр. функции в программе.
Таким образом она для всех одинаковая с точки зрения кода, а с точки зрения прав - разная
Димыч
Desdechado (2003-12-29 11:16:00) [20]
а для чего ты ее делал, чтоб никто не мог залезть в нее? для своего домашнего пользования - так и пользуйся дома :)
а если тебя волнуют не данные, а метаданные при распространении, то есть на ibase.ru утилитка их зачистки
ну, а БД с доступом только для чтения можно сделать утилитами самого IB
| |
Страницы: 