| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как создать базу данных динамически для Interbase6.0 FireBird1.x? [D6, D7, IB6.x]
France © (2003-09-22 19:14:00)
Требуется динамически создать базу данных FireBird/InterBase6.0.
При этом ограничить к ней доступ всем, кроме одного из пользователей (как добавить пользователя знаю...)
Какие есть мысли? Желательно кодом... :)
France (2003-10-08 15:52:00) [21]
Danilka © (08.10.03 15:40) [43]
А, кгм, если я не могу быть уверенным, что у клиента будет этот админ (без кривых ручек)? Может Вы разрабатываете программное обеспечение только для той фирмы, в которой работаете, или для заказчика, а администрирование предоставляется уже самому клиенту (за что он и держит собственно этого администратора)?
Кроме того, бэкап делает еще тот же владелец базы...
А если бы клиенты были готовы выкладывать деньги за БД, нашел бы такую в которой администрирование развито на соответствующем уровне (например, Oracle)... Преимущество IB как раз в том, что для его работы, собственно, особого администрирования и не нуно...
Danilka (2003-10-08 15:40:00) [22]
[42] France (08.10.03 14:44)
Во-первых - админ это не юзер с кривыми ручками, ему за это деньги платят, за то что у него руки не кривые.
Во-вторых админу абсолютно пофигу содержимое базы.
В третьих, если в базе глюки - то он и есть самый крайний, он и отгребет в случае чего, ибо за это ему деньги платят, как и за то, чтобы всегда бакаб был, а если не будет в нужный момент, то тоже отгребет.
Конечно, если у тебя все так плохо, что пароль sysdba есть у всех юзеров с кривыми ручками, то это уже орг. проблемы, сам виноват. Точно также будешь сам виноват, если всем кому не лень давать доступ к физ.файлам БД.
>Если б не жадность клиентов, я бы не рыпался в FreeWare БД...
А что-бы ты сделал? Расскажи, допустим клиенты купят все, что ты им скажешь, что ты сделаешь?
France (2003-10-08 14:44:00) [23]
Sergey13 © (08.10.03 09:05) [40]
Danilka © (08.10.03 09:29) [41]
Отвечу сразу на оба момента - если информация является важной и ее изменение несанкционированным образом ведет к: а)сбою в работе системы в целом (вплоть до разрушения БД - т.е. информация после этого будет представлять собой БОЛЬШУЮ кучу мусора); б)невозможности в дальнейшем найти "крайнего" - того, кто сделал каку, - то я предпочитаю, предоставлять доступ к изменению данных только в рамках своего ПО (а значит юзер с кривыми ручками доступ к базе не получит - его получит ПО, которое само создаст базу и само же будет ее вести), а самое главное все остальные угрозы буду решать только в рамках своего ПО (за что могу конечно тоже быть "поглаженным по головке", но это называется ОТВЕТСТВЕННОСТЬЮ). Так что, господа, Ваши аргументы не уместны...
Если б не жадность клиентов, я бы не рыпался в FreeWare БД...
Danilka (2003-10-08 09:29:00) [24]
[40] Sergey13 © (08.10.03 09:05)
Добавлю до кучи, на счет угроз, юзер, работающий с базой и имеющий права на изменение данных представляет ничуть не меньше угрозы чем, например, админ.
Sergey13 (2003-10-08 09:05:00) [25]
Может и не стоило поднимать ветку, но стерпеть не мог... 8-(
2France (07.10.03 17:31) [39]
>админ является угрозой (потенциальной) для данных хранящихся в базе...
Угрозой является еще Чубайс (он всегда виноват, потому что рыжий 8-), вырубающий электричество, производители компонентов компьютера (всех, особенно HDD), производитель ОС и СУБД. А самое главное - прикладной программист, у которого мании преследования и величия одновременно. Потому, что он думает, что его дачный огродик - это полный аналог мирового сельского хозяйства. И при этом даже не знаком с соседом по даче.
ЗЫ: Ветку ИМХО в "потрепаться".
France (2003-10-07 17:31:00) [26]
Danilka © (06.10.03 14:40) [38]
> Для СуперМегаСикретных данных, просмотр которых нельзя доверить админу, даже под страхом кастрации,
А как быть с ИЗМЕНЕНИЕМ данных???
Пусть смотрит - это уж вопрос такой.... Но вносить изменения - извольте... Именно об этом и идет речь!
>можно предусмотреть шифрование на клиенте, и в базу ложить уже в >зашифрованом виде.
Можно, но суть проблемы не меняется - админ является угрозой (потенциальной) для данных хранящихся в базе...
Danilka (2003-10-06 14:40:00) [27]
[37] MsGuns © (06.10.03 14:26)
Интересный подход. А как быть с индексами, они тоже шифруются? Боюсь, что все это может быть в ущерб скорости.
Все-таки я считаю что это экзотика. Для СуперМегаСикретных данных, просмотр которых нельзя доверить админу, даже под страхом кастрации, можно предусмотреть шифрование на клиенте, и в базу ложить уже в зашифрованом виде.
MsGuns (2003-10-06 14:26:00) [28]
>Danilka © (06.10.03 14:14) [35]
>Приведи, плиз, пример какой-нибудь СУБД, в которой было-бы по другому, пусть хотя-бы и самой-пресамой дорогой? :))
ADABAS. Насколько помню, там был владелец шифра (или что-то в этом духе). Причем буквально на каждую таблу и даже домен.
France (2003-10-06 14:25:00) [29]
Danilka © (06.10.03 14:14) [35]
Устранить "проблемку" и сами могем... :) На это и учились... а сорсники FireBird для этого я уже выкачал... Вопрос весь заключается: а) в концепции БД, которую я считаю немного странноватой (как минимум) и говорить, что так делают все, здесь не уместно... б) в конфиденциальности - это можно решить разными путями (раз не позаботились разработчики БД) в) в том, какой из вариантов пункта (б) выбрать, дабы уменьшить трудозатраты и при этом не ухудшить функциональных возможностей продукта... :)
Спасибо всем, кто откликнулся и давал советы...
Думаю, что тема себя уже исчерпала в рамках данного форума... :)
Удачи...
Danilka (2003-10-06 14:14:00) [30]
[34] France (06.10.03 13:59)
В любую - не зайдешь, если не будешь знать пароля sysdba и не будешь иметь физический доступ к БД.
Приведи, плиз, пример какой-нибудь СУБД, в которой было-бы по другому, пусть хотя-бы и самой-пресамой дорогой? :))
>Зачем делать БОГА, чтобы потом ждать от него сюрпризов...
Делать бога, чтобы он отгреб, если вдруг в базе будут какие-то сюрпризы, или утечка информации. Повторяю, в любой БД обстоит дело так. Обратись в открытым письмом к разработчикам Орокла, МС-СКЛ-а, ИБ, ФиреБирда и проч., пусть устранят, лично для тебя, эту проблемку.
France (2003-10-06 13:59:00) [31]
MsGuns © (06.10.03 13:54) [33]
Вот это-то мне и не понятно... :) Зачем делать БОГА, чтобы потом ждать от него сюрпризов... Я в любую базу в IB зайду как SYSDBA и наваяю по образу и подобию своему... Честно говоря я расчитывал на более содержательную политику безопасности... Обманулся...
MsGuns (2003-10-06 13:54:00) [32]
Может, стоит поинтересоваться, как этот вопрос (конфеденциальность) решается, к примеру, в Novell - фирме, много собак съевшей именно в подобных вопросах. Там тоже есть Supervisor со своим пассвордом, но есть еще и группы и юзера, которые имеют свои права, но ТОЛЬКО В ПРЕДЕЛАХ СВОИХ КАТАЛОГОВ.
Принцип такой - сисадмин (supervisor) могет убить любого юзера или даже группу, но НЕ МОЖЕТ ПРОЧИТАТЬ СОДЕРЖИМОЕ ИХ КАТАЛОГОВ. (А вот удалить может !).
А вот в БД почему-то прнят другой стандарт.
France (2003-10-06 13:33:00) [33]
mOOx_ © (04.10.03 12:07) [31]
>А если ты руту все обрежешь? Как он будет реанимировать, меня >итересует?
А так же как и в данном случае... Backup|Restore - никто не отменял... :) Кроме того процесс реанимации всегда можно сделать изящным.... :) Реанимация со стороны рута - это крайняя мера, остальное дело owner-a... Да и потом, никто не собирается отбирать права у рута, суть такова, что на базе созданной не им, он всего лишь наблюдатель да, в крайнем случае, тот самый главный дохтор... :)
А с шифрованием - это можно и сколько угодно... :) Насколько это будет удобно? А если я хочу предоставить доступ "только чтение" в последстивии для какого-нить юзера и скажу "по-секрету" это пользователям в программе...?
mOOx_ (2003-10-04 12:07:00) [34]
А если ты руту все обрежешь? Как он будет реанимировать, меня итересует? Я так понял, что инфа НУ ОЧЕНЬ ВАЖНА. Значит шифруй (сам и предложил :) ). По поводу "...рут всемогущий, но от этого и все траблы ...": а ты заранее прикинь, сколько будет траблов, если ты рута из рута в банального юзера запишешь! РАзработчики, значит, делают все, чтоб рута не урезали в правах, а ты хочешь разработчиков обмануть. Проще, наверное, вынь98 поламать :). Вообщем, шифруй в таком случае. Хотя бы какой-нибуть банальной логикой. Хотяб напрямую будет не понятно. Можно еще таблицам названия дать типа "123456" или "йцукен" или "qwerty". И пусть гадские хацкеры головы ломают: что там у тебя храниться. Прогу компильни и удали исходники, чтоб уж алгоритм шифрования не выведали и т.д. и т.п.
Удачи :)
France (2003-10-03 15:37:00) [35]
Sergey13 © (03.10.03 11:26) [28]
mOOx_ © (03.10.03 11:39) [29]
Матами обкладывать в школе так и не научили, хотя физкультуру любил... :)
НО вот принципы поколебать могу.... Да, рут всемогущий, но от этого и все траблы - как сохранить конфиденциальностьинформации? Поменять пароль руту нельзя (!!!), не хочу и не буду... Хранить инфу зашифрованную - велика радость... Конечно, может это издержки OpenSource? :) Нафиг им конфиденциальность... Куда-нить, лишь бы не в текстовые файлы! :)
Че-то я разгарячился.... Это то, что касается принципов... Рут в системе отличается от рута для БД в моем представлении... Для БД рут должен выполнять функции реаниматора (ну когда уже совсем плохо).
mOOx_ (2003-10-03 11:39:00) [36]
France, хр парить! РУТ он на то и РУТ, чтоб все и везде. И нефиг тут притензии предъявлять к тем принципам, которые начали вырабатывались еще задолго до того, как ты на свет появился. Если так сделано, значит по другому никак. Без человеческого фактора эта схема не работоспособна. Смени пароль дба и все тут. Запиши его на бумажку, прочитай 3 раза и сожги ее.
ЗЫ: Надеюсь, матом меня никто не кроет :)
Sergey13 (2003-10-03 11:26:00) [37]
2France (03.10.03 11:12) [27]
>велик шанс нарваться на то, что кто-то возьмет функции "творца" в свои руки и похацкает все и вся...
Вообще то этот "Бог" и призван с этим бороться. Более того он именно за это и отвечает. И именно от него требуют, что бы крутилось все с минимальными простоями, или вообще без них. Ты вспомни поговорку "у семи нянек дитя без глазу". Это как раз тот случай.
France (2003-10-03 11:12:00) [38]
Sergey13 © (03.10.03 11:01) [26]
Как раз слова я дослушал... Просто этого наверное не проверял и тот человек, кто мне данную информацию дал...
Я все равно склоняюсь к тому мнению, что создавая "Бога" в рамках БД, велик шанс нарваться на то, что кто-то возьмет функции "творца" в свои руки и похацкает все и вся... Процесс реализации возможностей суперпользователя должен быть достаточно сложным и трудоемким процессом, чтобы использовать эти возможности в крайних случаях.... Это к слову...
А для ДБА нет ничего не возможного, в этом (увы) убедился сам... И делает он это все с легкостью из обыкновенного isql... Хочешь - попробуй.... У меня на firebird 1.0.3 sysdba имеет полную вседозволенность... :)
Sergey13 (2003-10-03 11:01:00) [39]
2France (03.10.03 10:51) [24]
>В Оракле есть возможность (со слов - не проверял) поставить на процедуру подключения к базе триггер и запретить вход даже System/manager-у...
Ты наверное недослушал те слова. Тригер поставить можно, но при входе sys-ом сервак пилюет на эти тригеры.
>А под администрированием я имел в виду процесс изменения доступа к данным со стороны других пользователей... :)
Это очень маленькая часть работы DBA. Да и вообще не его это работа, а именно владельца схемы (в терминологии Оракла). Тем паче что ДБА и не может этого.
France (2003-10-03 10:54:00) [40]
Anatoly Podgoretsky © (03.10.03 10:43) [23]
Делать смену пароля SYSDBA я не могу, тем более не глядя...! Как я могу гарантировать, что этот пользователь (root) не используется в других программах? Моя прога значит станет, пароль сменит, а остальным - застрелится??? :)
| |
Страницы: 